Lightweight semaphore mechanism

[kjetilk]

@timbl suggested in his RWW Design Issue that DELETE INSERT WHERE queries could be used for a semaphore mechanism, so that if the DELETE part fails, a conflict flag should be raised.

I think the mechanism can be illustrated with simpler DELETE DATA/INSERT DATA queries, so here's my description:

Say that client 1 goes:

DELETE DATA { <foo> <baz> "Dahut" } ;
INSERT DATA { <foo> <baz> "Bar" }

independently, client 2 goes

DELETE DATA { <foo> <baz> "Dahut" } ;
INSERT DATA { <foo> <baz> "Foobar" }

before the first client as finished. In that case, the Solid implementation
would return a 409 Conflict to the second client.

There are a few problems, as noted in solid/solid-spec#193 it is a willful violation of the SPARQL 1.1 specification, which says:

Deleting triples that are not present, or from a graph that is not present will have no effect and will result in success.

Moreover, reporting a success or failure status to DELETE queries are problematic from a confidentiality perspective, as is the topic of #2 .

[kjetilk]

My proposal to fix both this problem and the problem in #2 is to keep the current SPARQL 1.1 behaviour, but design a new reporting mechanism, so that the status report becomes optional, and thus can separately be subjected to acl:Read requirement.

I have posted the strawman proposal that details this to the SPARQL-1.2 CG in
https://lists.w3.org/Archives/Public/public-sparql-12/2020Jan/0000.html

[kjetilk]

Also note that I had an earlier discussion on this in the SPARQL-1.2 CG in w3c/sparql-dev#60

[RubenVerborgh]

the current SPARQL 1.1 behaviour

Specifically, you want to keep the SPARQL UPDATE 1.1. semantics in the context of HTTP PATCH (as opposed to the current NSS semantics)?

[kjetilk]

Yes, I think we need to do that to solve #2 . Also because it is nice to not break specs :-)