W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > September 2011

Re: Draft response to ISSUE-105: @itemref support

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>
Message-ID: <20110919130718.435f31c6@miranda.g5n.co.uk>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:17 GMT