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

Hi Steven,

On 23/04/07, Steven Pemberton <steven.pemberton@cwi.nl> wrote:
> On Mon, 23 Apr 2007 00:29:59 +0200, Mark Birbeck <mark.birbeck@x-port.net>
> wrote:
> > 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;
>
> Bzz! False! Just because it is widely used is not a reason to use it. In
> fact my argument is that that is exactly the reason *not * to use it :-)
> People expect it to mean other things. Start with a clean sheet.

But as I illustrated in my other post on semantic mark-up, @class is
definitely widely used in a proper, semantic way. Microformats is the
highest profile use, but people do know how to use it correctly. So I
believe we need to leverage that knowledge, and work out what @class
means from an RDF stand-point.


> >  * we need an easy way of indicating rdf:type;
>
> Agree.
>
> >  * having a 'role' of 'toolbar' is not the same as _being_ a toolbar,
> > and so @role shouldn't
> >    be used for rdf:type.
>
> I know you think this, and I have considered your explanations of why, and
> I am still not convinced. I'm personally happy with @role being rdf:type.

Lot's of people are happy with using @role to represent rdf:type, but
the question is about whether the whole system works if we do that,
not whether people are happy with it.

To illustrate the problem, let's say that an 'alert' is defined
somewhere as having two methods, show() and hide(), as well as a child
element which is a 'close' button. Now let's say that in some document
I discover this mark-up:

  <div role="abc:alert">
    ...
  </div>

Should I now be able to find the methods show() and hide() on the
'div' element? Or should the presence of @role on the 'div' indicate
to me that these methods need to be added?

If @role is an indicator that some kind of processing is required,
then it's clear that the 'div' is not of type 'alert' until the
processing has been done. In that case I would say that it is more
logical that the 'div' has an xh:role predicate, with a value of
'alert', but it does _not_ have an rdf:type of 'alert'.

(Contrary to what Richard is saying in his post, @role as originally
proposed had nothing to do with RDF.)

Now, the interesting thing is that if you deliver an XHTML document to
Firefox with the @role attribute set to certain values, then the
element that the attribute is on does actually acquire the methods and
properties defined for that role value. Using my simple example, if
you pass the mark-up above to Firefox, then the 'div' actually
acquires the trappings of an 'alert'.

(Hence the references to duck typing in my previous post, with which
this shares some ground.)

So the big question is, by taking the approach that an element with a
role 'becomes' an object of that type, do we mess anything up for
future use cases that we haven't thought of. I hear what people are
saying, that having @role represent rdf:type just 'feels right', but
I've not seen an explanation that seems to have been through this in
enough detail to guarantee that we are safe if we take that route.

But since I've always said I can live with @role being the carrier of
rdf:type, even though I think it is logically wrong (because exactly
_how_ wrong seems to be balanced precariously on the head of a pin) I
really don't mind if people don't want to get into the logical side of
this. Of course it would be great to see some considerations of the
question before we finally wrap this up, but it's not terrible if we
don't.

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 Monday, 23 April 2007 14:42:34 UTC