RE: Sync'ing triplestores

> -----Original Message-----
> From: Joshua Allen [mailto:joshuaa@microsoft.com]
> Sent: Monday, April 04, 2005 3:14 PM
> To: Geoff Chappell; Bill de hÓra; semantic-web@w3.org
> Cc: Danny Ayers
> Subject: RE: Sync'ing triplestores
> 
> Yeah, I was thinking just don't support bnodes -- replace them with some
> urn:bnode:random-guid syntax

Works fine within the walls of a closed system - e.g. bnodes are implemented
that way within rdf gateway, but are converted from guids to true bnodes
(and vice versa) at the edges. 

I wonder what interop problems you introduce if you force each system to
maintain global names for bnodes outside of their walls. For example a
client dumps some rdf into a replicated triplestore:

	[a rdfs:Class; rdfs:label "MyClass"].

then reads it back and gets:

	<guid:_123456789> a rdfs:Class; rdfs:label "MyClass".

Isn’t that problem? I suppose you could say that the system would be
selective about when it gives the bnode's global vs. local name - e.g. using
the local name for all client access except replication clients. But that's
essentially requiring that all systems that want to participate in
replication must modify their inner workings and handling of bnodes -- talk
about being DOA in terms of deployment.

I suspect it's better to just bite the bullet and deal with identification
of bnodes by description. There is always a description in a particular
graph that is sufficient to identify a bnode in that graph (if there are
multiple subgraphs that match the description then they're redundant info
anway and can be merged). Maybe an approach like this would work:

For each bnode in a delta statement:

- get the anonymously connected subgraph that contains that bnode (i.e. the
node and all nodes it is connected to plus recursively any of those nodes
that are also bnodes)
- compute a hash of some canonical representation of that subgraph

Then use the hash as the id of the bnode.

Alternatively, you could pass the whole subgraph as some sort of selector
(e.g. a sparql query). Could get a little expensive for massively connected
bnode graphs - but they suck for a lot of other reasons as well.

Another approach would be to just deal with updates on a cbd basis - i.e.
always fully update the full description of a named object.

Geoff

Received on Tuesday, 5 April 2005 13:19:06 UTC