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 because it is the one vocabulary that Google supports. 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 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.
Multiple itemtypes in Microdata. Posted on August 2, 2011 by Richard Cyganiak. There's a lot of discussion recently around HTML5′s microdata proposal, and how it relates to W3C's earlier RDFa ...
Richard Cyganiak's profile photoPhilip Jägenstedt's profile photo
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. (requires banning # in itemtype)
2. (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 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 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 doesn't really work either. There's no machine-checkable restriction one could make on itemtype to ensure that doesn't conflict with another type.

It also seem dubious to assume that same-name properties on types and always mean the same thing.
Add a comment...