Make any deviation of SPARQL UPDATE explicit

[RubenVerborgh]

[kjetilk]

Yes, indeed, this is relevant in the context of #85 and #125 .

[acoburn]

We have implemented only standard SPARQL 1.1

[michielbdejong]

Solid OS uses this willful violation.
NSS and PSS support it.
Neither CSS nor ESS do.
@acoburn is right, we could achieve a very similar effect with If-Match.
It wouldn't be too much work to implement that in rdflib if the consensus is that it's better to align with upstream sparql-update on this.

@timbl what should we do?

[timbl]

@RubenVerborgh - I agree. "I think that, if we make such deviations, they should be made explicit".

What do you suggest is the best way? We could flag it in the content type.

Maybe the ideal is to use a recognizably different syntax in the file, like REMOVE (which fails) instead of DELETE (which never fails) and so extend sparql in a way the WG could potentially agree to be generally adopted.

That would mean for us the cost of changing our syntax,

We could then flag it like with a ; remove=true or something on the content type.So we would be extending SPARQL UPDATE and not changing it. There must be a lot of discussion of this already elsewhere.

[michielbdejong]

OK, so to summarize, the proposed change would be:

• instead of application/sparql-update all Solid apps will send content-type application/sparql-update; remove=true
• instead of DELETE DATA { ... }; INSERT DATA { ... } all Solid apps will write REMOVE DATA { ... }; INSERT DATA { ... }
• when clients do this, servers will only execute the 'INSERT' if the 'REMOVE' matched, and fail the entire request otherwise

Right?

[michielbdejong]

Great!