Indicate `DELETE` misses

[jeswr]

This is a feature request for the specification to mandate responses that identify DELETE misses. Here a delete miss is defined to be one where the data specified in a delete statement does not exist in the dataset, and so not all specified statements are removed from the dataset.

Why?

The rationale for this request is that the Solid Community cannot use SPARQL for PATCHing RDF documents because there is no indication of whether there was an attempt to DELETE non-existant triples. This prevents implementation of certain locking behaviours.

Contended locks are the most common use-case in Solid, where multiple clients applications are writing to the same resource in parallel (e.g. two chat clients writing to the same document as two people are messaging each other).

As noted by @afs this may relate to other areas such as transactions, compound requests (update and query as an atomic step) or conditional actions based on guards.

Also - there has been interest in the SHACL working group for "RDF transformation" which seems to be more general that single SPARQL Update requests e.g. involves flow control. It's beyond SHACL Rules.

Open Questions

• Are there other operations (e.g. INSERT not inserting any new statements) where there should be similar behavior?
  • I lean towards yes
• Should this apply only to DELETE DATA statements with a fixed set of statements, or should it also apply to DELETE WHERE statements
  • I lean towards yes where the condition for detecting a DELETE miss in a DELETE WHERE statement is that no statement was removed when the operation was executed.

Previous work

unknown

Proposed solution

In solid/specification#715 both 409 and custom 2xx response codes are suggested to identify DELETE misses. You could also use RFC 7807 - Problem Details to recommend a structured response to DELETE misses.

I would suggest:

• A 409 response code
• A recommended problem details response, which distinguishes:
  • A DELETE miss with all statements in the DELETE statement missing from the database
  • A DELETE miss with a subset of the statements in the DELETE statement missing from the database

As noted by @kasei this may also call for extending the existing semantics of the SPARQL Update operations with extensions to the Update semantics, and a way to use those extended semantics (either with new syntax, or maybe some enabling mechanism in the Protocol).

Considerations for backward compatibility

If a 409 response code is used then some clients may error unexpectedly when trying to perform legitimate no-op operations.

---

Originally raised in w3c/sparql-protocol#42