Re: Notification: Role Attribute Editor's Draft available

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

Received on Thursday, 22 April 2010 11:28:08 UTC