- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Thu, 22 Apr 2010 14:10:21 +0100
- To: Ivan Herman <ivan@w3.org>
- Cc: Shane McCarron <shane@aptest.com>, RDFa WG <public-rdfa-wg@w3.org>
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. 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 > > > > > >
Received on Thursday, 22 April 2010 13:11:00 UTC