- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Wed, 6 Dec 2006 11:01:56 +0000
- To: public-rdf-in-xhtml-tf@w3.org
- Cc: "SWD WG" <public-swd-wg@w3.org>
Hi Ivan, > Caveat: I am not sure which RDFa version was taken into account by > Fabien and by Elias. All these may not be 'bugs' but design, just > referring to different versions of RDFa.... I does sound like they are looking at different versions of RDFa. In relation to @role and @rdf:type, I'm afraid some confusion was caused by the premature adoption in one document of @role as defining rdf:type. What @role expands to, along with whether @class can be used in RDFa, have both been topics of much discussion. I'll just briefly recount the various views, so that we have them in one place, and it may help other implementers. (The other question, on XMLLiteral, is, as you say, still an open issue.) THE '@ROLE AND @RDF:TYPE' DEBATE There was a view that @role should generate a triple that has a predicate of rdf:type and an object which is the same as the @role value. This approach was much favoured by people in the accessibility space, with the idea being that if a 'div' plays the _role_ of a toolbar, then it *is* a toolbar. In other words, if we have this: <div role="wai:toolbar"> ... </div> then to all intents and purposes we have this: _:x rdf:type wai:toolbar There is certainly a need for a shorthand for rdf:type, and those who felt that @class shouldn't be used (see below) also favoured using @role. However, just because something _plays the role of something_ does not mean that it _is_ that thing. This is best illustrated with a look at what the WAI group are doing with @role. The WAI group are defining taxonomies to use with @role, and they are defining the characteristics of UI features like toolbars. In their taxonomy they can say that 'a toolbar' has features A, B and C. This would therefore mean that if we were to say that @role is equivalent to @rdf:type, then we would be implying that anything that any HTML element assigned to _play the role_ of widget would by inference have all of the features that an object of this type would have. This is obviously not the case, and the aim of @role was always to provide metadata that would allow some process to make informed decisions about translations it might make to help users interacting with a document. For example, if we had this: <script role="tooltip"> ... </script> a server-side process could know from some RDF taxonomy that 'a tooltip' is only relevant on a visual system (agree with me here, for the sake of the argument. :) and that this script can safely be removed when rendering to a voice system. Or in this situation: <div role="menu"> ... </div> a server could know from the RDF schemas that if space is at a premium (say, on a mobile device) then menus can be hidden or relocated. But note that what is inside the 'div' for the menu is irrelevant. Anyway, we've now agreed that @role does not map to @rdf:type, and that the triples generated for @role would be something like this: <div role="wai:toolbar"> ... </div> _:x xh:role wai:toolbar If some system wanted to add a further inference that xh:role => rdf:type, then that is of course up to them. @CLASS BEARING @RDF:TYPE DEBATE However, it is certainly the case the a construct that generates rdf:types is extremely handy, and perhaps you could say, a necessity. In HTML, the obvious choice for @rdf:type is @class since its semantics are both sufficiently vague but widely understood. But there was some resistance to this, since it was felt not unreasonably that using @class may be seen as 'hijacking' the attribute. The resolution was that since non-namespace prefixed values of @class would only generate 'local' triples (i.e., triples that have no meaning outside of the document) then it was pretty safe to use @class. For example, this: <div class="address"> ... </div> would generate: _:x rdf:type _:address i.e., it would generate a 'locally scoped' notion of an 'address'. This pretty much fits what is already happening on the web, since the notion of address on your web-site will be different to the notion on mine. But if we change our mark-up to this: <div class="foaf:address"> ... </div> we get the following, which is unambiguous: _:x rdf:type foaf:address Note that regardless of whether people are for or against RDFa, there is enormous advantage to having globally agreed upon HTML class names. By using QName-class names it means that I could define my own personal CSS stylesheet that causes all FOAF contacts to be shown in blue, whilst you could choose green. Provided that sites use: <div class="foaf:person"> ... </div> then we all know what is being said. I'd say that's pretty much the latest on these issues, and I believe this continues one of the goals that we have of clearly defining how to interpret an HTML document from the point of view of RDF. Regards, Mark On 06/12/06, Ivan Herman <ivan@w3.org> wrote: > > > Dan Connolly wrote: > > > > but I heard from Ivan that it produces different results > > from Elias's parser. Did he report that problem? Hmm... > > I can't find it in the -tf archives. > > > > Actually, no, I have contacted Fabien directly. But you are right, it > makes sense to document it here. > > http://www.w3.org/People/Ivan/ is the original page where I detected the > problem. Part of the page is RDFa-d, the whole page is GRDDL-able > including the > > http://www-sop.inria.fr/acacia/soft/RDFa2RDFXML.xsl > > and there is a pointer to Elias' RDFa service > > script. > > The relevant XHTML portion is: > > <div class id="me" role="foaf:Person" ...> > <h1 property="foaf:name">Ivan Herman</h1> > ... > <p> .... <a rel="foaf:schoolHomepage" href="http://www.elte.hu">.....</a> > .... > </p> > </div> > > The relevant portion as produced by Elias' script output is: > > <foaf:Person rdf:about="http://www.w3.org/People/Ivan/#me"> > <foaf:name rdf:datatype="...XMLLiteral">Ivan Herman</foaf:name> > ... > <foaf:schoolHomepage rdf:resource="http://www.elte.hu"/> > </foaf:Person> > > The relevant portion of Fabien's script output is (Fabien uses xml:base, > so "#me" is o.k.: > > <rdf:Description xmlns:h="http://www.w3.org/1999/xhtml" rdf:about="#me"> > <foaf:name xmlns:foaf="http://xmlns.com/foaf/0.1/">Ivan > Herman</foaf:name> > </rdf:Description> > <rdf:Description xmlns:h="http://www.w3.org/1999/xhtml" rdf:about=""> > <foaf:schoolHomepage xmlns:foaf="http://xmlns.com/foaf/0.1/" > rdf:resource="http://www.elte.hu/"/> > </rdf:Description> > > > and I did not find anything that said > > <#me> a foaf:Person. > > In Fabien's output. > > There are several issues here. > > 1. Elias's script assigns both literal and resource objects to the > subject identified by 'id' (see below on that one!), whereas Fabien does > it for literal objects and not for URI-s. > > However, looking at the code again and having re-read the spec yesterday > I realised that the correct coding should have been > > <div class id="me" about="#me"...> > > having added that, both scripts assigns the same subjects. > > What this means is that: > > - Elias' script is buggy, because it took into accound 'id' for all > the objects and it should not have > - Fabien's script makes this mistake for part of the objects. > > 2. The 'role' attribute is not understood by Fabien's script > > 3. Elias' script assigns an XMLLiteral datatype, Fabien does not. Elias > follows the spec in this respect, but this has been reported elsewhere > and I think it is still an open issue[1] whether the spec should be kept > that way. > > > Ivan > > > [1] http://www.w3.org/mid/4549CAF0.8060506@w3.org > > > > -- > > Ivan Herman, W3C Semantic Web Activity Lead > URL: http://www.w3.org/People/Ivan/ > PGP Key: http://www.cwi.nl/%7Eivan/AboutMe/pgpkey.html > FOAF: http://www.ivan-herman.net/foaf.rdf > > > -- Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ b: http://internet-apps.blogspot.com/ Download our XForms processor from http://www.formsPlayer.com/
Received on Wednesday, 6 December 2006 11:02:12 UTC