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

Hi everyone,

As we established on the XHTML call yesterday, the role/rdf:type issue
is still not clear. There was a request for examples, but as I said on
the call, the problem is that the issue really is more to do with
making use of the triples generated, rather than with the mark-up
itself.

In particular, as I said before I'm flagging up the problem because I
want to be sure that we don't block any _future_ use-cases by saying
that rdf:type == xh:role. One such use-case is actually illustrated by
a technique that is being used in the Ajax community, an example of
which is here:

  <http://www.almaer.com/blog/archives/001459.html>

What is being done here is that authors are using the @class attribute
as a hook to indicate that they want some HTML element to be used as a
widget of some type--it's called 'unobtrusive JavaScript' in the Ajax
community. So, in the example we have mark-up like this:

  <div class="feedbillboard access:randomly">
    ...
  </div>

A JavaScript process obtains a list of all the elements in the
document that have the class 'feedbillboard', and adds functionality
to the elements. It's a nice simple technique, and the only problem
with it is that the class names are not namespaced. Actually, there's
another problem which is the disturbing trend towards using the class
attribute to carry parameters for these widgets, in the form of
name/value pairs that use ':' as the separator! For example:

  feedbillboard numberofentries:4 access:randomly timeinterval:4.

But let's put that aside for now, since hopefully we can propose a
better solution before it's too late. :)

Anyway, how would we do this 'properly', so to speak?

Well, the first thing we'd do is define more precisely what it is that
we're trying to achieve, and say that we want the 'div' to 'play the
role' of a billboard. Obviously we'll therefore use @role (I'll leave
aside the parameter question, for now):

  <div role="almaer:feedbillboard">
    ...
  </div>

The syntax is easy bit, but the trickyness comes when deciding what
logic to use to actually add the billboard functionality.

One way to do it is to say that all we need do is act exactly as
before, but instead of acting on @class we act on @role. That's fine,
and if that is the way to do it, rdf:type doesn't even enter into it.

But if we were to say that xh:role == rdf:type, then the way the
functionality should be added is to let an RDFa parser have a go at
the document, and then query the triples generated; we'd be looking
for all elements that have an rdf:type of almaer:feedbillboard. Of
course the problem with this technique is that you will find elements
that were added without using @role:

  <link about="#b" rel="rdf:type" href="almaer:billboard" />

  <div id="b">
    ...
  </div>

The point is not that we have an ambiguity over what
'almaer:billboard' means, but that we have no way of knowing how the
rdf:type triple was added. In this example we would get the following
triples:

  <#b> rdf:type almaer:billboard .

But if we use @role to mean rdf:type, we get this:

  <blah> xh:role almaer:billboard .
  <blah> rdf:type almaer:billboard .

Once we have added that extra triple (by defining @role to mean
rdf:type), we can never remove it--in other words, we'll never be able
to use @role to indicate something other than rdf:type. (I suppose to
put it a different way, we _lose_ the meaning of 'plays the role of',
since now all we have is the meaning 'is a type of'.)

As always, the question is whether this fits with the original
intention of @role. My feeling is it doesn't, and as you may have
noted, I'm talking myself back round to the idea that we shouldn't
make @role indicate rdf:type! Such is the nature of these things......

Regards,

Mark

On 23/04/07, Mark Birbeck <mark.birbeck@x-port.net> wrote:
> 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.
>


-- 
  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 Thursday, 26 April 2007 12:26:43 UTC