Re: Notification: Role Attribute Editor's Draft available

On Apr 22, 2010, at 15:10 , Mark Birbeck wrote:

> Hi Ivan,
> 
> I wouldn't shoot you at all! You're exactly right that we can put the
> @role data into a separate graph, if we want.
> 
> But that only solves the 'do we mandate role processing' question. We
> still need to say that the bnodes are distinct...unfortunately.
> 

No we don't have to. Because the Role processing and the RDFa processing are distinct, ie, producing different graphs, the corresponding bnodes are automatically distinct. That is the nature of bnodes...

Ivan

> The reason is that we already allow bnodes to be aligned, even if they
> appear in different graphs. For example:
> 
>  <div rel="mycurie dc:creator">
> 
> We've already agreed that we won't stop an RDFa parser from putting
> 'mycurie' into a different graph, if it understands it, even though we
> know that the core RDFa processor doesn't understand it. But we've
> also said that the 'dc:creator' triple that goes into the default
> graph will have the same bnode as the triple going into 'mygraph'.
> 
> @role is the converse; we can't allow a person and an HTML element to
> have the same bnode, even if they are in different graphs. So we can't
> say that we don't care about the bnode use by @role, because it's in a
> separate graph, because that doesn't give you any protection in our
> 'multi-graphed' world.
> 
> Regards,
> 
> Mark
> 
> On Thu, Apr 22, 2010 at 1:57 PM, Ivan Herman <ivan@w3.org> wrote:
>> 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
>> 
>> 
>> 
>> 
>> 
>> 


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