CommentResponse:ST-1

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.

Regards,

Paul Gearon