W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > May 2008

Re: Nested hanging rels

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Wed, 14 May 2008 11:10:16 +0100
Message-ID: <a707f8300805140310h55311c2aiaeba0a79cb7563da@mail.gmail.com>
To: "Tore Eriksson" <tore.eriksson@po.rd.taisho.co.jp>
Cc: public-rdf-in-xhtml-tf@w3.org

Hi Tore,

You'll be pleased to hear that after much discussion on this topic on
the list, we resolved to change the spec in exactly the way you

It wasn't because of the processing, because the old rules don't
require you to 'jump through hoops' to get rid of the triples--the
changes to the processing steps to retain the triples only required
swapping the sequence of the recursive step and the
'complete-the-triples' step.

The change was made because essentially--like you--many people felt
uneasy about losing potentially useful information.

I confess that I had no problem with losing the triples. :) But I'm
now very glad that my view was in the minority, because during a
different discussion the other day, a related scenario emerged.

Since a processor is perfectly entitled to generate multiple graphs
from a document, you could easily end up with a situation like this:

Default graph:

  <> foaf:knows _:a .
  _:a foaf:knows _:b .
  _:b foaf:knows _:c .

Second graph, obtained from processing microformats, such as hCard:

  _:a h:fn "Tore Eriksson" .
  _:b h:fn "Mark Birbeck" .

The triples from the document would be the union of both graphs, so
although the 'default' graph appears to contain 'useless' triples,
without them the second graph would be meaningless.

Anyway, that's not directly relevant...but hopefully it shows that the
task-force made the right decision for a number of different reasons.



2008/5/14 Tore Eriksson <tore.eriksson@po.rd.taisho.co.jp>:
>  Hi,
>  I am sorry to bring up a seemingly old subject, but I would like for
>  some elaboration on a design issue as I am currently (re)writing a SAX
>  filter to extract RDF/a according to the current spec [1]. In section
>  5.5/step 11 there is a passage about chained rel attributes, which
>  concludes that
>  [[
>  <div rel="foaf:knows">
>   <div rel="foaf:knows">
>     <div rel="foaf:knows">
>       ...
>     </div>
>   </div>
>  </div>
>  Although this could generate the following triples:
>  <> foaf:knows _:a .
>  _:a foaf:knows _:b .
>  _:b foaf:knows _:c .
>  there is no point in doing so, since the triples are useless.
>  ]]
>  Looking back in the mailing list, I couldn't find much discussion on
>  this issue, I only found it mentioned as a fact in [2]. Personally, I
>  can't really agree with the final statement above. Even though the blank
>  nodes lack properties, using the foaf ontology we could infer that
>  <> a foaf:Person .
>  _:a a foaf:Person .
>  _:b a foaf:Person .
>  _:c a foaf:Person .
>  The graph could of course also be used when computing the size of the
>  foaf network of <>. You could certainly argue that the information
>  provided is very limited and might also be useless, but if these
>  attributes were put there by the document author I don't se why it is
>  necessary to jump through hoops to avoid producing the corresponding
>  triples. Furthermore, reading and implementing the spec would in my
>  opinion be easier if hanging rels produce triples when a completing
>  subject or object is found in a child element, even if the the node is a
>  lone bnode. Is there any other unwanted consequences of allowing for
>  this that I have missed?
>  Regards,
>  Tore Eriksson
>  [1] http://www.w3.org/TR/2008/WD-rdfa-syntax-20080221
>  [2] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Nov/0101.html
>  _______________________________________________________________
>  Tore Eriksson [tore.eriksson ad po.rd.taisho.co.jp]

 Mark Birbeck

 mark.birbeck@x-port.net | +44 (0) 20 7689 9232
 http://www.x-port.net | http://internet-apps.blogspot.com

 x-port.net Ltd. is registered in England and Wales, number 03730711
 The registered office is at:

 2nd Floor
 Titchfield House
 69-85 Tabernacle Street
Received on Wednesday, 14 May 2008 10:10:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:28 UTC