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

Mark,

Most people that are using @role to today are using it to allow the browser
to map the role to the Accessibility Role on the operating system or to
have an assistive technology perform a similar function to determine the
type of the object from the DOM. The accessible role is the type of the
object. Longer term we will use the role to adapt parts of the UI to the
individual or device.

Unfortunately, although @class was defined to be used as you suggest in
actual practice most web sites today use class for styling with no rhyme or
reason for the name and without any way to infer the type of the object. It
is meaningless.

I might also add that to infer a type you must also know what states it
provides. Class provides no mechanism to infer any of that at this point.

The reason you, I, Steven, and Raman introduced role is because of the
legacy way people used class. Given the way @class is used on the Web today
you cannot guarantee that an object is of type X. All that you can infer is
that some object has some stype properties. Those style properties also
don't have to map to supported states of an object. People who are creating
Rich Internet Applications today are creating dynamic UI objects and those
objects should have predetermined states. For example, a menu item may
support "haspopup" to indicate the object when activated launches a pop-up
menu. You cannot go to the @class to get this information.

In ARIA the role point to an RDF type whose "class" in and RDF/OWL taxonomy
indicates what properties or states it has. @class provides none of this. I
would also argue that a type can be styled in many different ways but it is
the properties of that object which determines type of the object.

It seems to me that the only reason that class is being used is because it
exists in HTML today as unfortunately, for better or for worse, class today
is used to add a CSS style to an object which no ability to infer the type
of the object. If industry had actually used class properly then we could
have done what you suggest and we would not have had to introduce role.

Rich


Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review  Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer


                                                                           
             "Mark Birbeck"                                                
             <mark.birbeck@x-p                                             
             ort.net>                                                   To 
             Sent by:                  RDFa                                
             public-xhtml2-req         <public-rdf-in-xhtml-tf@w3.org>,    
             uest@w3.org               "XHTML2 WG" <public-xhtml2@w3.org>  
                                                                        cc 
                                                                           
             04/22/2007 05:29                                      Subject 
             PM                        On @role and @class in RDFa: How do 
                                       we get rdf:type?                    
                                                                           
             Please respond to                                             
             mark.birbeck@x-po                                             
                  rt.net                                                   
                                                                           
                                                                           





[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.