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

Nested hanging rels

From: Tore Eriksson <tore.eriksson@po.rd.taisho.co.jp>
Date: Wed, 14 May 2008 17:50:25 +0900
To: public-rdf-in-xhtml-tf@w3.org
Message-Id: <20080514173924.3326.TORE.ERIKSSON@po.rd.taisho.co.jp>


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">
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?


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]
Received on Wednesday, 14 May 2008 08:52:11 UTC

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