W3C home > Mailing lists > Public > semantic-web@w3.org > October 2014

Re: deterministic naming of blank nodes

From: Sampo Syreeni <decoy@iki.fi>
Date: Tue, 7 Oct 2014 23:25:01 +0300 (EEST)
To: Sandro Hawke <sandro@w3.org>
cc: Alan Ruttenberg <alanruttenberg@gmail.com>, David Booth <david@dbooth.org>, Tim Berners-Lee <timbl@w3.org>, SW-forum Web <semantic-web@w3.org>, Pat Hayes <phayes@ihmc.us>
Message-ID: <alpine.DEB.2.02.1410072310560.30077@lakka.kapsi.fi>
On 2014-10-07, Sandro Hawke wrote:

> That may be true, but it is hard for me to see how any benefit this 
> could bring would outweigh the absolute pain in the ass it would be 
> for everyone to change their RDF stacks.

So, why not subdivide the process? It ought to be easy and efficient 
enough to detect a rather expansive subset of graphs which do admit 
unique and efficient labeling. At the very least graphs which only use a 
blank node precisely twice (to define something and to refer to it once 
as in the bracket notation) are pretty simple, using a simple hash table 
with counters -- that perhaps being the commonest case as well.

If the test succeeds, define a unique labeling based on the rest of the 
attributes of the triple and lexical ordering; if not, ask the user 
whether general graph isomorphism comparison is wanted, and if so, do 
that, somehow signaling that it really went that far (perhaps inband in 
the format of the labels? or out of band as the case may be); if not, or 
if you can't do graph isomorphism in your code, then slap on nonunique 
labels, again differentiating them somehow from the first two cases.

That is certainly not an easy or clean solution, but it doesn't break 
the stack, and it works in most of the places where you want to do fast 
path processing under the assumption that in fact the labels are 
canonical, and can be relied upon to have 1-1 correpondence from syntax 
to node.
-- 
Sampo Syreeni, aka decoy - decoy@iki.fi, http://decoy.iki.fi/front
+358-40-3255353, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
Received on Tuesday, 7 October 2014 20:25:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:25 UTC