[Mulgara-dev] Round-tripping Blank-nodes.

Paul Gearon gearon at ieee.org
Fri Mar 28 04:17:21 UTC 2008


On Thu, Mar 27, 2008 at 10:51 PM, Andrae Muys <andrae at netymon.com> wrote:

> On the other hand this does beg the question, how do you 'refer' to a
> blank-node?  Blank-node-ids aren't scoped globally, but instead to
> the graph - and as such do lack a global identifier.  It would
> however be consistent with my understanding of RDF semantics if we
> combine a graph-name (in our case a multi-graph-name[1]) with a blank-
> node-id to produce a global identifier.
>

For the sake of utility, I imagine that standard vocabulary would be
desirable (eg _:123) but this will break down the moment we talk to multiple
servers in the same query, since each server is free to allocate it's own
version of _:123.  Do we want to allow the simple form when talking with a
single server?  Then we're using different identifiers in different
circumstances.

The problems become more complex with multiple graphs on the same server.
Theoretically, it is possible for the same blank node to be present in more
than one graph, but the semantics of queries explicitly makes it impossible
to insert a blank node from one place and insert it somewhere else.  This
means that an insert/select query MUST change blank node IDs if it goes into
another graph.... but SHOULDN'T change them if they're going into the same
graph.  In reality, many systems allow the former, and the latter is next to
impossible if the former is attempted.

To imagine the difficulty, think of doing a query from the union of graphs A
and B, and insert the results into B.  Blank nodes from B shouldn't change,
but blank nodes from A are supposed to change before being written.  And we
have no clear way to associate blank nodes with particular graphs, without
doing expensive lookups for each one we see.  Systems often forgo this
requirement, due to (a) the difficulty, and (b) the fact that the semantics
are unintuitive, and developers usually don't want that behavior!  :-)

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-dev/attachments/20080327/bc5866f6/attachment.htm>


More information about the Mulgara-dev mailing list