- 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