On @role and @class in RDFa: How do we get rdf:type?

[This is my action item from the XHTML2 WG telecon a week or two ago.]

The current state of play with @role and @class is that @role
represents a predicate of xh:role, whilst @class represents a
predicate of rdf:type. The main motivations were as follows:

 * we need to do _something_ with @class, since it is widely used;

 * we need an easy way of indicating rdf:type;

 * having a 'role' of 'toolbar' is not the same as _being_ a toolbar,
and so @role shouldn't
   be used for rdf:type.

I don't mind this position, and I think it works fine, but I'd like to
throw some observations into the pot which might help people decide
one way or the other.

I've been trying to provoke an RDF-based response for a while now
about whether (at a *logical* level) if something _plays the role_ of
something it *is* that thing. My feeling has generally been that it
isn't, which I'll try to illustrate.

Say I have the following mark-up:

  <div role="xf:range">
    ...
  </div>

I basically have a 'div' that I am suggesting plays the role of an
XForms range control. I'm happy with this, since exactly 'how' the
'div' plays this role is not my concern, I've simply said it does. But
I haven't said it *is* a range control, since that would imply certain
components such as a handle to grab, certain methods and properties,
extra CSS classes that can be set to format the indicators, indicate
whether it's a vertical or horizontal control, and so on. In other
words, reversing the more familiar formula, I'm saying that if it
doesn't quack or walk like a duck, then chances are it isn't a duck.
(If the 'div' doesn't have the methods and properties of a range
control, then it isn't one.)

However, we've discussed this many times on the HTML calls, and I've
yet to be able to explain successfully to anyone who is actually using
@role what the difference is! So I'm increasingly beginning to wonder
whether it's really worth bothering with such a distinction. I'm
pretty sure I know what the problem is, though.

Most people who are using @role are using it as a hook for server-side
translation, or even run-time augmentation. This means that--to return
to the more familiar form of the familiar formula--if they see a 'div'
with @role="duck", then they add webbed feet, a beak, and a method
called quack(). In short, by the end of the process, the element
really *is* what the @role attribute says it is.

So the question we need to ask is whether this is just one use case of
@role, or the *main* use case. If it's one use case amongst many, then
those who are currently using @role to carry out server-side
transformations will need to add an inference rule to their triple
stores that says that the predicate xh:role is equivalent to rdf:type.
This would keep the mapping local to their system, not affecting
others, and of course it would be a true reflection of their system,
since by the end of the process the elements 'really are' the thing
that they are impersonating.

But this would be unnecessary if we can't think of situations where
having an rdf:type value set 'automatically' would cause a problem.
For example, in Firefox's implementation of @role, the presence of the
attribute and its value does actually change the nature of the element
that the attribute is attached to. (See
http://developer.mozilla.org/en/docs/Accessible_DHTML.)

So, I'm now wondering...since:

 * the logic experts have not thought the distinction significant
enough to warrant
   a comment;

 * and the users of @role don't see the difference (because they'd
rather there was
   no difference);

then perhaps there is no meaningful difference? Should we just return
to having @role provide rdf:type? (I say 'return' although technically
we never had it in the spec, it just so happened that people found it
a convenient way to indicate rdf:type, so they started using it.)


SUMMARY

I still believe that we need rdf:type from somewhere, so the only
thing I'm raising is whether it should be @role or @class. In terms of
the 'logic' I personally believe that @role should _not_ equal
rdf:type, but as I've shown here, the arguments in favour of this may
be so marginal--and the weight of opinion behind using @role to carry
rdf:type may be so strong--that you could argue, why not just go for
@role as rdf:type.

What might tip the balance decisively would be if there were any other
uses that could be found for @class, or if arguments against using
@class for rdf:type were to be put forward.

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Sunday, 22 April 2007 22:30:03 UTC