W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > April 2007


From: Ben Adida <ben@adida.net>
Date: Tue, 17 Apr 2007 08:12:19 -0400
Message-ID: <4624B9A3.6070401@adida.net>
To: José Manuel Cantera Fonseca <jmcf@tid.es>
CC: RDFa <public-rdf-in-xhtml-tf@w3.org>


Thanks for your input! Let me attempt to clear up a few things first,
and then see if we can get to the root of your objection.

In fact, the CLASS attribute is not meant solely for presentational
purposes. Note the HTML4 spec [1], which indicates that CLASS is also
meant for general user-agent processing. Even in the presentation use
case, the CLASS *should* designate a semantic role for the element, e.g.
class="menubar", and then the stylesheet indicates how to perform the
presentation for that semantically designated portion of the page.

In other words, we are not really bowing to browser vendor pressure
here, we're simply saying that CLASS has always been about semantics, so
let's make sure that is reflected in the RDF triples we produce, and the
clearly relevant predicate is rdf:type.

In the case of the ROLE attribute, all we're doing is outputting an
xh:role predicate that corresponds exactly to the ROLE attribute placed
on the element. We think that maps exactly to the accessibility case,
and our brief interactions so far with the WAI group seem to confirm
this, though I hope they will chime in if that's not the case!

To sum things up: with RDFa, we've always tried to use existing HTML
attributes where these attributes *already* have semantic connotation.
REL and REV obviously fit the description, and I'm guessing you don't
object to their use for RDFa? We believe CLASS fits in the same
category. We're still discussing how UL, OL, and LI may have RDF list
semantics, though that is still very much in flux. I hope the above
helps make our reasoning clearer.

So, getting back to your objection: is there a use case you're worried
about? Or a piece of markup you think would yield a "bad" set of
triples? I want to dig a bit deeper, because if we adopt the principle
that we must only use new attributes, then we will be missing out on
existing HTML semantics, and a number of natural RDFa examples, in
particular the ones that use the REL attribute, would have to go away by
the same principle.


[1] http://www.w3.org/TR/html401/struct/global.html#h-7.5.2

José Manuel Cantera Fonseca wrote:
>  Dear members of the RDF-A group,
> My name is Jose Cantera, I'm with Telefonica and  I represent Telefonica
> in some W3C groups. I'm writing this e-mail to express our strong
> disagreement with respect to the usage of the class attribute in RDF/A.
> The class attribute has presentational connotations but not semantic
> connotations. You are mixing things in a very dangerous and confusing
> manner.
> We think it's a big mistake you are making. *New attributes are needed
> for expressing the semantics* and not reusing existing ones that
> initially were intended to other purposes. Semantic-annotation
> attributes should be different than other attributes and should easily
> be distinguished from the other.
> Regarding the role attribute the same comment applies. Role attribute
> has connotations related to accessibility but not to semantics. New
> attributes for semantics are needed, although we know that you are, as
> usual, adopting the ideas of browser vendors who are not willing to
> create or consider new attributes in HTML-like languages.
> This issue, for us is a big issue, and somehow would "limit and stop"
> our adoption of RDF-A in our research work.
> Kind regards
> Ben Adida escribió:
>> Hi all,
>> Though we have discussed the CLASS and ROLE issue, we haven't quite
>> resolved the last consensus we came to. So, I want to phrase the
>> consensus as best as I understand it. We will vote to resolve this (or a
>> modified version if need be) at next week's telecon on 4/23, so please
>> send all comments ASAP.
>> Proposed Resolution:
>> In all RDFa-compliant HTML documents (e.g. XHTML1.1+RDFa), the CLASS
>> attribute is of type CURIEs, a space-separated list of values. Each
>> qualified CURIE value yields an rdf:type assertion on the subject
>> corresponding to the attribute's element, exactly as if the element had
>> a child LINK element. Unqualified CURIEs are ignored, e.g. class="foo".
>> e.g.
>> <div id="foo" class="big foaf:Person">
>> ...
>> </div>
>> yields
>> <#foo> rdf:type foaf:Person .
>> Where the ROLE attribute is defined, e.g. XHTML2, its value is also
>> CURIEs, thought this time it yields an xh2:role assertion (with xh2 the
>> XHTML2 namespace). The subject resolution is identical to that of the
>> CLASS attribute. As there is no "backwards compatibility" issue with
>> this attribute, all values yield triples
>> e.g.
>> <div role="wai:Menu nav">
>> ...
>> </div>
>> yields
>> _:div0 xh2:role wai:Menu .
>> _:div0 xh2:role :nav .
>> -Ben
Received on Tuesday, 17 April 2007 12:12:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:22 UTC