Re: Comments on SPARQL 1.1 Update (3)

On 2010-09-02, at 13:59, Andy Seaborne wrote:

>> 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:
>>    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.

No, it's not, 4store has both a quad store, and a triple store in it (there's a hash table where the key is the graph, and the value is a list of triples). 5store is a pure quad store however.

> 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?)

It can be in any system, yes.

> 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.

It can always return an error.

Either way you're going to get an error when you try and do that, if the system doesn't support it. MAY seems far too vague for something that falls naturally out of the syntax. If a significant number of implementors say they can't implement this for some reason, then it might be worth considering making it optional, or banning it in the syntax.

- Steve

Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Received on Friday, 3 September 2010 11:16:33 UTC