|
|
Re: Discrepancies between RDFa implementations [Was: Re: follow your nose, : msg#00018org.w3c.html.rdf
Hi Ivan, Caveat: I am not sure which RDFa version was taken into account by 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@xxxxxx> wrote:
-- Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@xxxxxxxxxx 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/ |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| News | FAQ | advertise |