Difference between revisions of "CommentResponse:ST-1"

From SPARQL Working Group
Jump to: navigation, search
(Created page with 'Sebastian, Thank you for you message to the SPARQL Working Group. I apologize for not responding before now. > Looking at named graphs as "just" a fourth node IMHO it makes pe…')
 
(Responded correctly to the CONSTRUCT portion, and removed error from description of DROP)
Line 31: Line 31:
 
  > ...... }
 
  > ...... }
  
This example is unclear to me. I do not know what it means to "CONSTRUCT" a graph with triples in it like this.
+
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, but will not be available before SPARQL 1.1 is finalized.
 
+
Also, because empty graphs need not be supported, INSERT operations *must* create a graph if it does not already exist. For this reason, your CONSTRUCT operation here would be perfectly valid if the term INSERT were used instead. This would both construct the specified graphs and populate them.
+
  
 
  > Thus, my question is: is there any good reason against allowing
 
  > Thus, my question is: is there any good reason against allowing
 
  > templated named graphs in pretty much every command?
 
  > templated named graphs in pretty much every command?
  
Templated graphs already appear in most commands, 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. The main operations you may wish to consider are CREATE and DROP, however, these operations are included for administrative convenience in just those stores that support empty graphs, and will be implemented as no-ops in most systems. In these circumstances, we do not consider it useful to update these commands.
+
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,
 
Regards,
  
 
Paul Gearon
 
Paul Gearon

Revision as of 13:46, 30 June 2010

Sebastian,

Thank you for you message to the SPARQL Working Group. I apologize for not responding before now.

> 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 a 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. 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, but will not be available before SPARQL 1.1 is finalized.

> 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