Re: Notification: Role Attribute Editor's Draft available

OK, I understand. So let me be a bit provocative: what is the use case to bind this into RDFa? It seems that a separate spec that describes how @role gets into RDF, if needed, is easy to describe. Separate Role processors can the extract data. We can even have _applications_ that do both RDFa and Role processing and merge the result in a graph (just as applications can process RDFa as well as embedded rdf/xml, do you remember this issue a few weeks ago?). I am not sure that necessarily forcing the management of @role into the RDFa processing is necessary and useful...

Now you can shoot me:-)

Ivan



On Apr 22, 2010, at 11:48 , Mark Birbeck wrote:

> Hi Ivan,
> 
> The key thing about @role is that it describes your document, not the
> content of your document.
> 
> The latter is the kind of thing we're familiar with in RDFa -- things
> like "I know Ivan Herman". But the former is essentially a different
> sphere -- "this area of the page is a footer".
> 
> This is why we need two bnodes -- one for "Ivan Herman" and one for the footer.
> 
> I did a talk on this topic at a W3C mobile event in Ireland some years
> ago (in my capacity as an XHTML 2 WG member), and I have to say that
> the mobile people thought the approach was sound. For them, they
> needed to be able to do fancy things with the page 'as a page', as
> well as do stuff with the data.
> 
> I'll try to find the slides from that event, since it might explain
> things better.
> 
> (I realise that this doesn't solve the issue, but hopefully it gives
> some insight into why we can't simply transform @role into @rel, or
> share bnodes, or share @about.)
> 
> Regards,
> 
> Mark
> 
> On Thu, Apr 22, 2010 at 9:53 AM, Ivan Herman <ivan@w3.org> 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?
>> 
>> (Note that this is different than SVG. SVG does not change anything on the RDFa attribute sets neither does it add to it. Ie, if I take a file with a content type applications/svg+xml, I can simply drop the 'svg' part, so to say, and run it through RDFa 1.1 Core.)
>> 
>> 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? Does it means that @id makes the processor to ignore @about, but only for this element? 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)? Will the second BNode be a subject for the RDFa statements within <div>?
>> 
>> 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...
>> 
>> Ivan
>> 
>> 
>> On Apr 21, 2010, at 19:31 , Shane McCarron wrote:
>> 
>>> There is a draft of the Role Attribute spec available at http://www.w3.org/WAI/PF/role-attribute - this specification includes ties to RDFa Core and describes how triples should be raised when @role is encountered in languages that incorporate @role and RDFa Core.  Please review this document, in particular Appendix A, so that you understand what we are trying to do and that you agree with the direction I am taking that spec in.
>>> 
>>> Thanks!
>>> 
>>> --
>>> 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
>> 
>> 
>> 
>> 
>> 
>> 


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