W3C home > Mailing lists > Public > www-archive@w3.org > October 2004

RE: bNodes for named graphs

From: <Patrick.Stickler@nokia.com>
Date: Wed, 6 Oct 2004 10:00:51 +0300
Message-ID: <1E4A0AC134884349A21955574A90A7A50A1DC7@trebe051.ntc.nokia.com>
To: <jjc@hplb.hpl.hp.com>, <andy.seaborne@hp.com>
Cc: <chris@bizer.de>, <phayes@ihmc.us>, <www-archive@w3.org>


I think Jeremy's comments nail it down pretty well. I wanted to
offer one additional comment...

Even if a URI is required as a graph name, it need not involve
any significant mental or management effort to decide what URI
to use, if either (a) one does not care if the URI is human
readable (mnemmonic) and/or (b) one does not care if the URI
is dereferencable (though I think folks should).

E.g. one can simply employ UUIDs either in an http: URI

   http://example.com/id/dae07413-018c-43dc-9a0e-503a46484585

or in a uuid: or guid: URI

   uuid:dae07413-018c-43dc-9a0e-503a46484585
   guid:dae07413-018c-43dc-9a0e-503a46484585

or in a urn:uuid: URN

   urn:uuid:dae07413-018c-43dc-9a0e-503a46484585

etc. etc.

Thus, folks who tend to get their undies in a wad about having to
use http: URIs for stuff they don't consider "web accessible" or
folks who suffer angst about the linguistic baggage potentially
carried by a human readable URIs can relax (a bit). 

Cheers,

Patrick


> -----Original Message-----
> From: ext Jeremy Carroll [mailto:jjc@hplb.hpl.hp.com]
> Sent: 05 October, 2004 15:51
> To: Seaborne, Andy
> Cc: Chris Bizer; Stickler Patrick (Nokia-TP-MSW/Tampere); Pat Hayes;
> www-archive@w3.org
> Subject: 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 Wednesday, 6 October 2004 07:06:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:46 GMT