- From: Toby Inkster <tai@g5n.co.uk>
- Date: Mon, 19 Sep 2011 13:07:18 +0100
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Jeni Tennison <jeni@jenitennison.com>, RDFa WG <public-rdfa-wg@w3.org>
On Tue, 13 Sep 2011 21:54:50 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > Until this point, one could do a one-pass RDFa processor > implementation. Doesn't <base href="..." /> already make a one-pass processor impossible? Obviously this element is only allowed inside <head>, so there's a limit to how far you need to read ahead to find it. > we have not seen a single, real-world use case that would greatly > benefit from the feature. Chaining with @rev makes it redundant in some cases. For example, to say that several people share a web page: <p><a href="foo">This web page</a> is about:</p> <ul about="foo" rev="foaf:page"> <li typeof="foaf:Person" property="foaf:name">Alice</li> <li typeof="foaf:Person" property="foaf:name">Bob</li> <li typeof="foaf:Person" property="foaf:name">Carol</li> </ul> You get the following Turtle: [] a foaf:Person; foaf:name "Alice"; foaf:page <foo>. [] a foaf:Person; foaf:name "Bob"; foaf:page <foo>. [] a foaf:Person; foaf:name "Carol"; foaf:page <foo>. That is, they all share the same value for foaf:page, without us needing to repeat the page URI for each person. However, what if we wanted Alice, Bob and Carol to all share the same value for a literal. With @itemref, that's possible. <p id="p"> These people want to <b property="foaf:plan">take over the world</b>: </p> <ul> <li typeof="foaf:Person" property="foaf:name" itemref="#p">Alice</li> <li typeof="foaf:Person" property="foaf:name" itemref="#p">Bob</li> <li typeof="foaf:Person" property="foaf:name" itemref="#p">Carol</li> </ul> Gives us: [] a foaf:Person; foaf:name "Alice"; foaf:plan "take over the world". [] a foaf:Person; foaf:name "Bob"; foaf:plan "take over the world". [] a foaf:Person; foaf:name "Carol"; foaf:plan "take over the world". Without @itemref, it would require creating a hidden element within each <li> element for the foaf:plan. This might be an empty span with a @content attribute. That said, supporting something like @itemref adds a backwards compatibility issue. The above example would generate the following in an RDFa 1.0 processor: <> foaf:plan "take over the world" . i.e. the processor, ignoring the @itemref attribute as unrecognised, would take the foaf:plan as applying to the subject determined by nesting. Even in an RDFa 1.1 processor, it's non-trivial to avoid that triple being generated. Times when @itemref is useful: 1. Wikipedia disambiguation pages (e.g. all these people share the same name.) 2. Tables with grouping: ============================================================ Name Phone Number ------------------------------------------------------------ Department: Marketing ------------------------------------------------------------ Alice 01234 567 890 Bob 01234 567 891 Carol 01234 567 892 ------------------------------------------------------------ Department: Accounts ------------------------------------------------------------ Alex 01234 567 860 Betty 01234 567 861 Charles 01234 567 862 ============================================================ (i.e. Alice, Bob and Carol need to share the same org:dept_name. Alex, Betty and Charles do too.) The question is whether the use cases justify breaking backwards compatibility with 1.0 and significantly complicating implementations. (I've written a Microdata parser, and I can tell you that @itemref is one of the hardest parts to handle.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk>
Received on Monday, 19 September 2011 12:06:49 UTC