- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Sat, 3 Jun 2006 22:21:03 +0100
- To: "'public-rdf-in-xhtml task force'" <public-rdf-in-xhtml-tf@w3.org>
Hello all, I said recently on a telecon that we should ensure that @class 'means something' in RDFa. I've had this view for a long time, and the two reasons I put forward on the call were: * I feel it is far more appropriate to indicate rdf:type with @class than with @role; * @class is already used in HTML 'properly' by many authors, in the sense that people already use it to provide semantic meaning--it is therefore important to 'leverage' this in just the same way that we have leveraged <link> and <meta>. This email is to raise the issue again, and to motivate why we should try to resolve it quickly. XHTML 1.x One reason I feel it can't wait much longer is that the growing interest in RDFa seems to be being accompanied by a number of confusions, and one of them is that you need XHTML 2 before you can do anything with RDFa. Although it's true that there are some new attributes in 'full' RDFa, one of the most important things that we have done is to take the approach of trying to 'define' the RDF triples that would be generated from a 'normal' HTML document. We already knew what <meta> and <link> generated, but we've now clarified @rel and @rev, and I feel it is important to add @class to this list. Since @rel and @rev are standard HTML it's possible to do a lot of work with a subset of RDFa and still keep your HTML or XHTML completely valid. By adding an RDFa interpretation of @class we increase the range of statements you can make in a kind of RDFa-minimal mode. MICROFORMATS The second reason I think we should sort this out quickly is that the growing interest is also accompanied by a number of worries. The main one is a concern that the RDFa approach is creating a separate 'path' that is running in parallel with microformats--one that could fragment the budding 'metadata in XHTML' space. It's interesting that this view is also accompanied by an acknowledgement that RDFa is a better approach in the long term--hardly surprising since the *whole point* of RDFa was to create a solution that would scale to allow many vocabularies to be mixed, and that could provide the full power of RDF. So although I wouldn't give any credence to the idea that it is RDFa that is causing the fragmentation, it's certainly the case that if we can bridge the gap between microformats and RDFa in various ways then we should. I believe that defining how exactly @class fits into RDFa is a step towards this. (Having said that, my feeling is that many people seem to be being too polite to the Emperor about his latest choice of clothing--microformats vocabularies generally twist HTML to make it work, and simply *do not scale*. The fact is that microformats is hitting a limit, and we need a generic solution. Speaking personally, I don't see any reason to be apologetic about that since it's the whole reason that myself and others have been working for a number of years on finding a solution.) So, to restate my position on @class/@role and rdf:type, I've always said that @role should represent a predicate that has as the object part of the triple the value of the @role attribute itself. In other words, the following: <div role="wai:toolbar"> ... </div> is equivalent to this: <div> <link rel="xh:role" href="[wai:toolbar]" /> ... </div> To clarify what @class should do, I'm also suggesting that this: <div class="foaf:Person"> ... </div> should be equivalent to this: <div> <link rel="rdf:type" href="[foaf:Person]" /> ... </div> The 'equivalence' is being expressed using the CURIE syntax which is part of 'full' RDFa. NOTE: The RDFa primer is still a draft, and although it suggests using @role to represent rdf:type, this was put in by Ben 'at the last minute' as a kind of working hypothesis, and doesn't reflect a final decision. Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 b: http://internet-apps.blogspot.com/ w: http://www.formsPlayer.com/ Download our XForms processor from http://www.formsPlayer.com/
Received on Saturday, 3 June 2006 21:21:24 UTC