Shared publicly  - 
Better property URIs for Microdata Terms.

I just released a new version of my Ruby Microdata parser( I added a non-standard option for generating URIs from @itemprop terms. The spec creates terms that are a bit unwieldy.

Also, in parsing seemingly equivalent RDFa and Microdata markup, it's useful to have property URIs that are the same.

The :rdf_terms option changes the processing algorithm for generating URIs from @itemprop values that are not already an absolute URI. Using the in-scope type (from @itemtype, or fallback_type), replace everything following the last '/' or '#' with the term. This results in more familiar URIs, and works so long as normal RDF vocabularies are used for minting types.

For example, consider the case where @itemtype is "" and @itemprop is "name". Using the standard scheme, the generated property URI would be <>. Using the :rdf_terms option, it will generate the following URI: <>.

I think this is much more useful for people in general. There may be some corner-cases where this doesn't work, and I'd be interested in comments from the community.
rdf-microdata - Microdata parser for RDFa
Former Gavin Carothers's profile photoPhilip Jägenstedt's profile photoKANZAKI Masahide's profile photo
Is "Microdata parser for RDFa" a typo? Should be RDF?

Your method doesn't seem to work for If there is ever introduced a type to describe the rights a particular license grants, it would conflict with the predicates your algorithm generates for, right?

It seems silly of to throw all properties into a single global namespace, making it impossible to ever have same-name properties that mean different things.
Gregg, it's quite fine that and can mean the same thing, but it's less fine if they must be. Assume that was set up to do community-driven vocab development similar to the microformats community, and that they develop things like and independently. Having all the properties be in a global namespace where they may collide doesn't seem like a very attractive feature at all. Iguana.

Is there any way to fix the predicate URI generation that gives both pretty URIs and cannot collide? I think it would really have to involve appending the property name to the type name in some fashion, perhaps That would be unique if we banned the use of "." in the path component of item types. Would that be more palatable?
In microdata properties are scoped by their items, it's just the suggested RDF conversion that would turn it into a flat namespace. It would appear that the models are just different, so what makes sense in microdata is ugly in RDF and vice-versa. Given this, I wouldn't call microdata an RDF serialization or vice-versa.
Absolutely, if you have control over the input, then the algorithm can make lots of assumptions. However, if you don't think that the RDF conversion should be dropped from the spec, what should it actually be? You're obviously not happy with what it currently says...
The spec'd algorithm is vocabulary agnostic. Would you use something like white-listing of item types for which your method is safe and fall back to the current horror for the rest? I ask because if no sensible algorithm exists, then I expect that +Ian Hickson will just drop it from the spec. (At which point I'd drop my implementation from MicrodataJS, not that anybody has ever used it.)

Working with is great, but as far as I can tell, it makes mashed potatoes of 2 of the 3 item types that are in the spec: and but not
OK, so perhaps separating with a period should at least be considered. The biggest wrinkle with that is that it forbids the use of periods in the type URL, but I'm not sure what kind of breakage that would result in.
Add a comment...