The W3C RDFa specification is now in Candidate Recommendation phase, with an explicit call for implementations (of which there are several). Momentum for RDFa is steadily building. What about eRDF, which favors the existing HTML syntax over new attributes?
There’s still a place for a simpler syntactic approach to embedding RDF in HTML, as evidenced by projects like Yahoo! SearchMonkey. And eRDF is still the only game in town when it comes to annotating RDF within HTML-without-the-X.
One thing the RDFa folks did was define src as a subject-bearing node, rather than an object. At first I didn’t like this inversion, but the more I worked with it, the more it made sense. When you have an image, which can’t have children in (X)HTML, it’s very often useful to use the src URL as the subject, with a predicate of perhaps cc:license.
So I propose one single change to eRDF 1.1. Well, actually several changes, since one thing leads to another. The first is to specify that you are using a different version of eRDF. A new profile string of:
"http://purl.org/NET/erdf11/profile"
The next is changing the meaning of a src value to be a subject, not an object. Perhaps swapping the subject and object. Many existing uses of eRDF involving src already involve properties with readily available inverses. For example:
<!-- eRDF 1.0 --> <img class="foaf.depiction" src="http://example.org/picture" /> <!-- eRDF 1.1 --> <img src="http://example.org/picture" class="foaf.depicts" />
With the inherent limitations of existing syntax, the use case of having a full image URL and a license URL won’t happen. But XHTML2 as well as a HTML5 proposal suggest that adding href to many attributes might come to pass. In which case this possibility opens:
<img src="http://example.org/picture" class="cc.license" href="http://creativecommons.org/licenses/by/2.0/" />
Comments? -m
As the developer of an eRDF parser, I have one major problem with eRDF which is not addressed by this proposed update — the hijacking of the “id” attribute. While authoring eRDF from scratch, eRDF’s use of @id makes it awkward to add eRDF to existing pages. If your blog contains a DIV element with id=”sidebar” say, you cannot use eRDF within that sidebar to mark up information about the page as a whole: all the eRDF within the sidebar will be assumed to apply to the sidebar only!
RDFa doesn’t have that problem. Yes, the RDFa spec is only defined in terms of XHTML, but in practice virtually all RDFa parsers support HTML as well. You may still have problems with validation, but using a custom DOCTYPE such as the one used here — http://buzzword.org.uk/2008/html4plus-example — solves most of them (except xmlns attributes).
I think an effort to get RDFa working in HTML is more worthy than one to update eRDF.
I always faced many problems while using eRDF