Re: bNodes for named graphs

Seaborne, Andy wrote:
> I noticed that in the Named Graphs document bNodes are not allowed in
> naming a graph.  I wondered why - what are the technical reasons for
> this?  

Hi Andy,

this was a conscious decision on our part. The original version [1] of 
the named graphs work (from me and Patrick) allowed bnodes as graph 
names. When we started working on the formal semantics (or more 
accurately, when Pat joined in to help with the formal semantics), it 
became clear that there were formal problems.

The key problem is that bnodes between graphs have unclear, or 
complicated semantics.
A second problem is that legacy RDF/XML encoded graphs are more 
naturally mapped onto URIs (the retrieval URL or the xml:base). There is 
no manner in which to encode a bnode named graph into RDF/XML.

Some examples:

_:b {
[... graph1 ...]

}
<uri-graph2> {
   _:b dc:creator "Jeremy Carroll" .
}


Here we appear to be saying that graph1 is authored by me. And the bnode 
has existential scope in graph2. How to tie that bnode up with its use 
in the first graph is a greater break with RDF semantics than using a 
URI, whose interpretation is constrained.

Moreover, if we allow graph2, then we would seem to want to allow graph3

<uri-graph3> {
   _:b eg:uniqueCreator "Joe Bloggs" .
}


With the bnode still understood as meaning graph1.
In this case, we then, by forgetting some things and monotonicity, have

<uri-graph2> {
   _:b dc:creator "Jeremy Carroll" .
}
<uri-graph3> {
   _:b eg:uniqueCreator "Joe Bloggs" .
}

as a legit collection of named graphs, with the understanding that the 
bnode really is shared between graph2 and graph3, again this causes 
additional difficulties in the semantics, and also in notions such as 
graph isomorphism in the abstract syntax. While it would be possible to 
define an isomorphism across these NamedGraphs with bnodes, it is 
distinctly more complicated than RDF graph isomorphism.

While I saw legitimate uses for bnodes naming graphs, the 80/20 rule 
seemed to suggest that the amount of effort on the formal side needed to 
get it to work, was not worth the candle. Some of the attractiveness of 
RDF is simplicity, which is overly compromised by allowing bnodes to 
have scope greater than a single graph.

The discussion about this feature of named graphs was held in 
www-archive, some pointers are [2], [3], [4].

Jeremy


[1] first TriX TR
http://www.hpl.hp.com/techreports/2003/HPL-2003-268.html
(superceded by
http://www.hpl.hp.com/techreports/2004/HPL-2004-56.html
)
[2]
http://lists.w3.org/Archives/Public/www-archive/2004Mar/0135.html
particularly
[[
Don't mess with blank nodes: we had them completely understood, and
they are totally debugged by 60 years of close attention from the
logicians. All we have to do is to stick to the idea that they are
bound in a graph, and have no connection with any names in any other
graph. Use URIs for any naming process larger than a graph (including
naming the graph.)
]]
[3]
http://lists.w3.org/Archives/Public/www-archive/2004Mar/0138.html
particularly:
[[
I have no problem with blank nodes REFERRING to anything, graphs
included. But referring, and being used to identify, are not the same
thing.  Using a blank node as a name or a label seems to me like
talking about a hammer and expecting that to drive the nails in.

Look, its *logically valid* to substitute any bnode label for any
other, as long as you do it systematically throughout the graph. So
any use of a bnode to be a label is *logically invalid*.  No matter
how lexically convenient it might be, that's a bad place to start.
]]
[4] bnodes as graph names
http://lists.w3.org/Archives/Public/www-archive/2004Mar/0247.html

Received on Tuesday, 5 October 2004 12:51:44 UTC