Re: SPARQL, named graphs and default graph

Chimezie Ogbuji wrote:
> The Graph API's do most of the leg work of named graph
> aggregation. ConjunctiveGraph is an (unamed) aggregation of all the
> named graphs within the Store.  It has a 'default' graph, whose name
> is associated with the ConjunctiveGraph throughout it's life.  All
> methods work against this default graph.  Its constructor can take an
> identifier to use as the name of this 'default' graph or it will
> assign a BNode.  In practice (at least how *I* use RDFLib), I
> instanciate a ConjunctiveGraph if I want to add triples to the Store
> but don't care to mint a URI for the graph (the scenario which
> triggered this thread).  These triples can still be addressed.

Okay, in the context of this discussion, what RDFLib does is that
every time a ConjunctiveGraph is instantiated, it creates a new blank
node and uses that throughout the life of the ConjunctiveGraph
object. And the default graph is the merge of all graphs in the store.

So triples without an origin will be associated with a blank node,
which is shared between added triples, but distinct between different
ConjunctiveGraph objects. This probably coincides rather nicely with
most usages of the API. Single "sessions" of manipulating nodes will
have the blank node origin shared.

And the possible problems are mostly what was already mentioned
earlier about an approach like this. The blank node identities might
not coincide with the actual separateness of the sources graphs -
making a query which matches several statements out of a single graph
might not be too meaningful for these blank nodes. It is difficult to
query only nodes which have no specific origin. And since the graph
name is a blank node, there is no way to explicitly specify the graph
name to be specific blank node, as the SPARQL syntax doesn't allow
this.

-- Naked

Received on Wednesday, 13 September 2006 17:28:11 UTC