You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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 ?
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.
Activity
timbl commentedon Oct 27, 2021
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-patchheader of course allows us a smooth transition, with servers advertising what they support, and being able to support both for a time.timbl commentedon Oct 27, 2021
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 commentedon Oct 27, 2021
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 thentext/n3?bourgeoa commentedon Oct 27, 2021
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 commentedon Oct 27, 2021
In terms of existing now - N3 patch works in rdflib, solid-rest, and solid-file-client. I find it a very workable format.
kjetilk commentedon Nov 1, 2021
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
PATCHbody 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.
Draft initial N3 Patch proposal.
Draft initial N3 Patch proposal.
Draft initial N3 Patch proposal.
Draft initial N3 Patch proposal.
Draft initial N3 Patch proposal.