Re: Request for named graph templates "everywhere"

Sebastian,

Thank you for you message to the SPARQL Working Group. We apologize
for not responding earlier.

> Looking at named graphs as "just" a fourth node IMHO it makes perfect
> sense to allow templates for graphs in all commands.

Not all graph stores allow for named graphs. SPARQL specifically
avoids requiring a "fourth" node, though it is supported. Also, many
storage APIs treat graphs as a separate type of entity to a triple,
despite the storage mechanisms removing this distinction. For these
reasons graphs are necessarily treated differently to the other
elements in a "triple".

> A simple example would be:
>
> drop graph ?g where { ?g <foo> <bar> . }
>
> But this also applies to insert queries:
>
> insert {
>   graph ?g { ?s ?p ?o . }
> }
> where {
>   blabla .
>   ?g foo bar .
> }

SPARQL 1.1 Update has left the issue open as to whether or not a graph
store allows empty graphs. Consequently deleting all the elements in a
graph *may* result in that graph being deleted as well. This means
that your first example can be duplicated on many stores using a
DELETE operation. This Working Group has defined a limited feature
set, and this has been considered adequate for the moment.

Your INSERT example is already supported explicitly in the spec.

> In the spirit of completeness one could even think of finally completing
> construct queries and allowing for the following:
>
> construct { graph ?g { ?s ?p ?o . } . graph <foobar> { .... } } where {
> ...... }

This is a worthwhile suggestion and one that has already been
considered. However, it requires a result format that supports quads.
The working group is required to use a standardized format for
results, and currently there is no W3C standard for encoding multiples
graphs in a single file. Such standards have been proposed, and are
particularly under discussion in the current RDF WG, but will not be
available before SPARQL 1.1 is finalized, so we can't cover them
within our charter.

> Thus, my question is: is there any good reason against allowing
> templated named graphs in pretty much every command?

CONSTRUCT is a query, rather than an update operation, but your point is made.

Templated graphs already appear in most operations, with the exception
of the graph operations: CREATE, DROP, CLEAR and LOAD. LOAD is a
unique operation, used for data transfer, and CLEAR is simply a
shorthand for a specific DELETE operation. CREATE is redundant and may
be useful for graph administration on some systems. Similarly, DROP is
a combination operation that both clears a graph and removes it. For
systems that do not support empty graphs, CREATE is a no-op and DROP
is identical to CLEAR.

Please indicate by email if this addresses all of the concerns you have raised.

Regards,
Paul Gearon

Received on Wednesday, 4 May 2011 00:15:20 UTC