Alternative update support with N3 patch

[RubenVerborgh]

No description provided.

[timbl]

This is interesting for all the reasons given above. Having the patch format in N3 allows us to extend it to add things we may need in the future. The solid world has for many years worked well with this where/delete/insert functionality for patching a single resource. So switching from a mis-appropriation of SPARQL UPDATE to N3 would mean we could keep the functionality while switching to a more extensible syntax.

The accept-patch header of course allows us a smooth transition, with servers advertising what they support, and being able to support both for a time.

[timbl]

The sorts of things one could imagine going into future more powerful patch languages include for example patching more than one resource at once, making small adjustments to an array (rdf Collection), tracking the authorship and provenance of the change, and metadata which might come with collaborative editing systems like CRDTs, and so on I think it is important to not be tempted to slip those in in the same change as we make the syntax.

[timbl]

I'd question the "0.9" tag as release 0.9 is documenting existing solid which works now. So 0.9 should document our SPARQL/Update-like-thing, and a future one introduce this. But we can add it to existing servers immediately. Is the Accept-patch: value then text/n3 ?

[bourgeoa]

As said above it is working on NSS since 2017, but also on solid-rest.
So 0.9 with both PATCH support could be considered.
It was also implemented in solid-file-client library https://github.com/jeff-zucker/solid-file-client#patchfile-fileurl-patchcontent-patchcontenttype-

[jeff-zucker]

In terms of existing now - N3 patch works in rdflib, solid-rest, and solid-file-client. I find it a very workable format.

[kjetilk]

I'm having conflicting feelings about this... Perhaps part of that conflicting feeling is just a sunk cost fallacy because I've put so much time into a SPARQL patch...

On one hand, I'd wouldn't want to mangle SPARQL way out what it was designed for, and I feel that we were getting to a place where we shouldn't. Using SPARQL for a PATCH body is not a misappropriation, that is actually a use case of SPARQL.

OTOH, I feel that what we could do to support the semaphore mechanism isn't that bad, if we could just examine what we really need. In particular, I don't feel I have a good answer to the question:

When needing the semaphore mechanism, is the triple that is being changed known to the client?

If the answer to that is "yes", or "I guess that's good enough", I think we can design a simple mechanism that is easy to implement with SPARQL that is also likely to find support in a future SPARQL WG. If the answer is a definitive "no", then much more extensive work is required to come up with something that would sit well in a future SPARQL WG.

Now, I still feel that we should have an answer to that question, because it should influence the design of an N3 patch too.