- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Tue, 05 Oct 2004 13:50:41 +0100
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- CC: Chris Bizer <chris@bizer.de>, Patrick.Stickler@nokia.com, Pat Hayes <phayes@ihmc.us>, www-archive@w3.org
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