Re: Comments on SPARQL 1.1 Update (3)

On 02/09/10 10:06, Steve Harris wrote:
> On 2010-09-01, at 23:47, Andy Seaborne wrote:
>
>> 4.1.3 DELETE/INSERT
>>
>> [[
>> If an operation tries to insert into a graph that does not exist, then that graph *must* be created.
>> ]]
>>
>> Surely this is wrong? For stores that distinguish empty graphs from non-existent graphs, we have CREATE GRAPH.  Automatic creation is at odds with that setup.
>>
>> [[
>> Deleting triples that are not present, or from a graph that is not present will have no effect and will result in success.
>> ]]
>>
>> seems inconsistent - why can't an error be generated for this case when stores do different graph existence from emptiness?
>
> I'm fairly sure we agreed that SPARQL Update implementations should be required to implicitly create graphs at a F2F. 4store had to do this, and it wasn't too much of an implementation burden, just test for existence before asserting the first triple in each graph.
>
> Consider:
>
> INSERT {
>     GRAPH ?s {
>       ?s ?p ?o
>     }
> }
> WHERE {
>     ?s a<Thing>  .
>     ?s ?p ?o .
> }
>
> Without this requirement, updates like the above can't be guaranteed to work across all stores, which would be unfortunate.

4Store is pure quads store with no special graph management IIRC so the 
situation makes sense.  As to implementation burden, then it falls out 
naturally in a quad table with no explicit test needed (and CREATE GRAPH 
is a no-op anyway isn't it?)

The text is slanted to one style of system.  What about a store that 
just manages a single graph, as the default graph?  As written, it 
*must* create a graph.  That seems a huge burden.  But I'd hope a system 
allowing update to one graph was could be considered conformant.

(A store that wishes to separate out graph management operations from 
data manipulation operations also seem reasonable to me but less common.)

Use of MAY would be better language (I assume that the same applies for 
INSERT DATA) and also, given the text though, what about

   INSERT { GRAPH <g> { } } WHERE {}
or
   INSERT { GRAPH <g> { ?s ?p ?o} } WHERE {}  # Skip unbound

These are trying to insert data.  MAY seems to allow free interpretation 
of these.  SHOULD is possible but I prefer the more neutral MAY here. 
Not sure what to say about the empty quads cases.


Tests are going to have to be clear as to requirements of a store. 
Maybe we need to separate the test suites into two bundles, one for 
single graph, one for named graphs.

	Andy

Received on Thursday, 2 September 2010 13:00:33 UTC