Re: Discrepancies between RDFa implementations [Was: Re: follow your nose, HTML widgets, GRDDL spec#issue-tx-elt, TAG issue xmlFunctions-34 [was: [RDFa] Use Case...]]

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:15 UTC