Re: Notification: Role Attribute Editor's Draft available

Without going into the details below, I think your remark:

[[[
> @role is largely orthogonal to RDFa.

]]]

is the crucial point here. I do not see any reason why formally 'binding' RDFa and Role. There is RDFa, with its own processing rules, and there is Role, with its own processing rules. Applications may decide to implement both, or only one of the two, but that is (as I said before) on the same level as applications that decide to interpret embedded RDF/XML and merge the resulting graphs to the end result.

Very specifically, I would change Appendix A in the Role documentation to something that describes how RDF triples can be created from a document with a @role attribute, without any reference to RDFa processing. And I do not think there should be any reference to @role in the HTML+RDFa document.  

(I have no problem with Role referring to the URI/CURIE mechanism of RDFa, of course, but that is a different matter.)

It might also be worth considering defining a 'role' object in an API, that could refer to the core RDFa API elements like triplets or blank nodes. But, again, that should be disjoint from the strictly rdfa part of the API.

Sorry if I sound a bit harsh...:-)

Ivan

On Apr 22, 2010, at 16:20 , Shane McCarron wrote:

> 
> 
> Ivan Herman wrote:
>> Hm. I feel a little bit uneasy here, though I am not sure how to solve this.
>> 
>> Appendix A says:
>> 
>> """
>> When @role is included in a markup language that also includes RDFa Core attributes [RDFA-CORE], an RDFa Processor MUST process the role values as follows:
>> """
>> 
>> So if, say, HTML5 includes @role and we also have the RDFa attributes in HTML then a conformant RDFa processor MUST implement @role and @id, too. This means that if I am an implementer of RDFa, I am supposed to know and look at a very different recommendation produced by a different group, than the ones published by the RDFa and the HTML WGs. Is this really o.k.? I am not sure. Also, how do I know whether a specific XML file should be processed with the role attribute? Do we rely on the DTD alone?
>>  
> 
> Well...  if HTML+RDFa wanted to incorporate the requirements of the Role Attribute, that specification would need to normatively reference the Role Attribute specification.  In that way it is really no different than any other normative reference (e.g., URI).
> 
>> 
>> 
>> Then... o.k., I swallow that and I try to implement this. @role looks like a @rel with a fixed URI and the value is a list of, essentially, URIs. It has no direct counterpart in RDFa, so the processing steps have to be adapted for @role. It also says that the subject is @id. Is the value of @id inherited in the source tree (as you would expect in RDFa) or is the subject setting valid on the element only? 
> 
> Err.... why would you think that?  @id has explicit semantics in XML (and HTML).  It is not inherited.  The text says if there is an @id then use that as the subject (actually, use the base + '#' + that, but whatever).  If there is no @id, then create a unique (distinct) bnode.  The subject is used for this triple.  We are not setting the local subject for other RDFa processing.
> 
>> Does it means that @id makes the processor to ignore @about, but only for this element? 
> 
> No.  @about still works.  We didn't say anything about that. Nothing in that very small set of steps should effect the other processing of RDFa.
> 
>> Also, what is the relationship with the other RDFa attributes? Eg:
>> 
>> <div typeof="" role="something">....</div>
>> 
>> Do I have to generate two different BNodes (one for typeof and one for role)? 
> 
> Yes. @role gets a unique bnode.  @typeof always also creates a bnode.
> 
>> Will the second BNode be a subject for the RDFa statements within <div>?
>>  
> 
> Yes, as per the RDFa Core Processing Instructions.
> 
>> There are probably other issues to solve to get it right with the RDFa processing steps.
>> 
>> I wonder whether another approach would not be possible. We used the conceptual model of hGRDDL before, I think: is there way to define a DOM -> DOM transformation that would map the @role attribute into bona fide RDFa structures? If such transformation was possible, then the core RDFa processing steps would remain unchanged... The issue I see is that a transformation of the form
>> 
>> <div @about="XXX" rel="xhv:role" resource="values of the original role attribute">...
>> 
>> does not work because @resource takes one single URI, whereas role seems to take more...
>> 
>> Sigh. I am not sure how to solve all this, I must admit, probably because I know very little of the origins of role. I wonder whether the original goals of role could not be fulfilled by using RDFa directly...
> 
> Definitely not.  @role is largely orthogonal to RDFa.  It has a specific semantic for the assistive technology community and a11y in general.   However, in the XHTML2 Working Group the players seemed to feel strongly @role should also integrate with the metadata that was being exposed by what is now RDFa.  That's the only reason there is any treatment of RDFa in the Role draft at all.  I don't think the PFWG has any real concerns about this - it is down to us.  In my mind I really want the RDFa triples in the same graph because I want it accessible by our RDFa DOM API.  It makes it easier for application developers and assistive technology manufacturers to embrace the broader RDFa and A11Y at the same time.
> 
> -- 
> Shane P. McCarron                          Phone: +1 763 786-8160 x120
> Managing Director                            Fax: +1 763 786-8180
> ApTest Minnesota                            Inet: shane@aptest.com
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf