Shared publicly  - 
 
(I'm new to this Google Plus thing.)

I've been thinking a lot about microdata lately. One of the things that bothers me: microdata very much encourages authors to use a single vocabulary. Combining vocabularies is difficult and often requires repeating content. This drives authors to schema.org because it is the one vocabulary that Google supports.

Schema.org is a closed, proprietary play. It is unclear how design decisions are made, who decides about extensions and changes, what one would have to do to get one's input listened to.

But because of Google's market power and the single-vocabulary issue, others don't even need to bother trying to define new vocabularies overlapping with schema.org. It's hard to see how other, better or more open, community-based alternatives like microformats could ever develop.

So I wrote a blog post today about how microdata could be extended to better support multiple vocabularies. It's not as simple as I'd like; I can definitely appreciate the technical reasons for restricting microdata to a single vocabulary per scope … Anyway, the link is below.
9
7
Andrea Kempter's profile photoRichard Cyganiak's profile photoPhilip Jägenstedt's profile photo
4 comments
 
I still tend to think that if the full names of properties were short and obvious enough, people could just use those. The two least crappy options I know of for that are:

1. http://schema.org/Person#name (requires banning # in itemtype)
2. org.schema.Person.name (requires introducing Java-style identifiers)

The problem with both of these is that there are now two ways of expressing the same property. It's likely that many processors will only consider one of them and just fail when the longer form is used.
 
If it was possible to design vocabularies in a way that there is a full URL “long form” for every short property name, then this would be a solution to the problem, and probably preferable to my proposal here.

I don't like the org.schema.Person.name style because it is just too weird. It ignores 20 years of history when it comes to distributed naming on the web. Today, everyone expects global identifiers on the web to be some sort of URL, and other approaches to identification won't fly. This ship has sailed.

I have mixed feelings about the #property style. It kind of would work, but it places an arbitrary restriction on the URLs that can be used for itemtypes and properties, and hence on the design of vocabularies. For example in schema.org with its proliferation of types, it makes sense to share properties between types, and the Landform#name, LocalBusiness#name style isn't such a good idea.
 
Yes, I can see why that would seem a bit silly from an RDF perspective. However, simply resolving the property against the itemtype and getting things like http://schema.org/name doesn't really work either. There's no machine-checkable restriction one could make on itemtype to ensure that http://schema.org/name doesn't conflict with another type.

It also seem dubious to assume that same-name properties on types http://example.com/T1 and http://example.com/T2 always mean the same thing.
Add a comment...