- From: Ivan Herman <ivan@w3.org>
- Date: Mon, 19 Sep 2011 14:32:08 +0200
- To: Toby Inkster <tai@g5n.co.uk>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, Jeni Tennison <jeni@jenitennison.com>, RDFa WG <public-rdfa-wg@w3.org>
Hey Toby, (nice to see you active again, I have not seen you on the list for a long time!) On Sep 19, 2011, at 14:07 , Toby Inkster wrote: > 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. Another possibility, that Gregg explored, was to allow multiple abouts. Having something like > <p id="p"> > These people want to > <b about="_:a _:b _:c" property="foaf:plan">take over the world</b>: > </p> > <ul> > <li about=":_a" typeof="foaf:Person" property="foaf:name">Alice</li> > <li about=":_b" typeof="foaf:Person" property="foaf:name">Bob</li> > <li about=":_c" typeof="foaf:Person" property="foaf:name">Carol</li> > </ul> Which is of course slightly more complicated than the usage of @itemref, but is a much more "natural" extension of the current RDFa 1.1 concepts and spec: everywhere where we have a single resource (ie, for @about and @resource) we would have an array, with the multiplication of triples. After all, we already have that for @rel, @rev, @typeof, @property, ie, it is not a huge leap in concepts. > > 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. I guess the only way to avoid that is that the @id appears or does not appear in an @itemref and not to allow the RDFa generation. Of course, as your example shows, the @id may appear 'higher up', which makes it difficult. And it would definitely go against the wish of Manu to have it run in a SAX machine! > > 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. Indeed. These examples are of course fine, but I find it interesting to note that users like Drupal do not need this features, at least not up until now... > (I've written a Microdata parser, and I can tell you that @itemref is > one of the hardest parts to handle.) > I concur. Ivan > -- > Toby A Inkster > <mailto:mail@tobyinkster.co.uk> > <http://tobyinkster.co.uk> > ---- 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 Monday, 19 September 2011 13:29:40 UTC