solid
Reevaluating N3 Patch vs. SPARQL Update in the Solid Protocol
This is not a new topic by any means but it may be worthwhile to revisit. Issues, PRs, minutes touching on "n3 patch" or "sparql update".
There are several hurdles related to N3 Patch in the Solid Protocol, ranging from the extent to which the N3 format needs to be standardised to the overall maturity of N3 Patch itself. Some of these concerns are technical, while others are process-oriented (within W3C and the broader standards community), and they need to be addressed. Additionally, implementation feedback must be taken into account, whether from actual verifiable implementations, public commitments to implement (which demonstrate tangible progress and genuine leadership), or other relevant factors.
To be brief: we originally used and implemented SPARQL Update in pre-v0.9 versions of the Solid Protocol (i.e., in drafts prior to the Solid CG or any publication of the specification), before switching to N3 Patch. That was largely due to certain implementation preferences and our needs. The reasoning behind this switch is documented in issues, PRs, and public discussions. And that was the best decision we were able to make at the time.
That said, there are multiple possible ways forward, and I'd be interested in exploring what may be most suitable given the current landscape. Any solution that the community is willing to adopt in a healthy way should be considered. Even a willful violation of SPARQL Update - but for example clarifying different status/error codes depending on the request/response payload - could be acceptable if it helps us move forward. At the same time, advancing N3 Patch and its related dependencies also remains desirable, as well as correcting implementations towards a desirable behaviour, but we need to see more concrete actions and progress toward adequate implementation experience.
From Tim. Berners-Lee:
The problem with SparqlUpdate was that requirements differed between SolidOS and the SPARQL community. SolidOS stack needs to be able to use a DELETE as a P/V flag which fails 409 if you do not win the lock. SPARQL DELETE never fails, and never finds out whether the triples you deleted in fact existed before the DELETE. So there is no way to make a lock. N3 Patch there is -- but also can more metadata about who made the change etc, so using the flexibility of n3 to extended it too.
Source message was posted the 2025, February 23td in the Solid specification Gitter chat channel.
So even if we do say in the Solid spec that a 409 must be returned if the lock has not been won it might not work with Solid servers relying on a SPARQL backend. Unless these SPARQL backends are adapted. Doing so would just break the SPARQL rules.
Tim. Berners-Lee indicated that "Move to N3Patch removes that tension". Source
May I also suggest https://www.w3.org/TR/ldpatch/ ? (full disclosure: I was a co-editor of this spec, which didn't make it to REC track because the LDP WG was at the end of its charter)
Reading about your discussion: We had a community group for N3 and I would be willing to push N3 further. Would you be interested in that to have formal support for N3 patches?
I believe there was support or at least sufficient interest/signal in using N3 to patch resources since Solid Protocol v0.9 (2021).
From the point of the LWS WG charter, there was explicit interest in N3 Patch (2023) being further worked on:
To investigate the possibility of transferring Solid Protocol's N3 Patch to the N3 CG where its standardisation development can continue with broader applicability.
Perhaps we (the Solid CG), myself as the chair then, the authors of N3 Patch, LWS WG team contact, chairs etc. didn't communicate the needs to the N3-Dev CG well enough or "formally". Here we are.
Given that N3 Patch is a WIP, the general patch format - defining insertions, deletions, conditions for updates, etc. - doesn't need to be tied to Solid-specific constructs/vocab at all. It would be better for the Solid/LWS Protocol to simply apply (or extend) the format in its (HTTP) interactions.
Sensible options with caveats (ordered roughly from simplest to most complex or involved):
- N3-Dev to take Solid Protocol's N3 Patch as input, work out its kinks, and whatever needs to be improved in lower-level N3, and to define N3 Patch once and for all. In this path, N3-Dev leads the work, and coordinates with Solid, LWS, and other groups. Check interest and aim to publish it as a separate CG-DRAFT/FINAL in ~6 months.
- Revisit the SPARQL Update path, work through locking concerns (consider settling on happy paths..), introduce wilful violations, and move on. Possible but might make some folks uncomfortable. At least builds on a well-tested and deployed foundation. Solid CG can consider incubating this work - it already has some background work/material. (RDF-Star WG probably won't bother to pick something like this up at this point and considering their charter but could nudge them for input/direction..)
- Pick up LDP Patch and bring it to completion. This is a rough switch for the Solid Protocol, so it may be best to to sit tight and see if LWS wants to pick it up. Solid CG folks can still experiment / incubate of course if of interest.
I strongly recommend against any group attempting to define a yet another patch format! That said, nothing stops individuals from exploring alternatives and sharing publicly verifiable implementation experiences.
At this point, relatively arbitrary changes to the Solid Protocol - such as moving N3-related elements out - would be mostly cosmetic. Better put energy on one of the options above, and then only update if and only when things are in the clear.
From Tim. Berners-Lee:
The problem with SparqlUpdate was that requirements differed between SolidOS and the SPARQL community. SolidOS stack needs to be able to use a DELETE as a P/V flag which fails 409 if you do not win the lock. SPARQL DELETE never fails, and never finds out whether the triples you deleted in fact existed before the DELETE. So there is no way to make a lock. N3 Patch there is -- but also can more metadata about who made the change etc, so using the flexibility of n3 to extended it too.
Source message was posted the 2025, February 23td in the Solid specification Gitter chat channel.
So even if we do say in the Solid spec that a 409 must be returned if the lock has not been won it might not work with Solid servers relying on a SPARQL backend. Unless these SPARQL backends are adapted. Doing so would just break the SPARQL rules.
Tim. Berners-Lee indicated that "Move to N3Patch removes that tension". Source
Ugh, this is like writing an rm that does not return an error code on a miss. (The staff contact for the SPARQL 1.1 WG deserves to be shot.)
I propose a bit of civil disobedience with a note saying that SPARQL implementations should be updated to distinguish between DELETE misses and hits. GSP and REST (and rm) provide a bit of precendt. SQL doesn't but people usually stuff use IF before the delete.
The timeline for such an action is pretty straight-forward; we'd ask for feedback from a few implementors and the SPARQL WG. We'd have to have a concrete proposal, e.g. divide the hit and miss amoungst two 2xx codes or, my preference, make the miss a 404.
make the miss a 404.
But what then is not found? Is it the SPARQL endpoint? Or one or more triples that are not present to be deleted? (I might be convinced that 404 is the appropriate code, but there must be some way to provide detail, e.g., "Of the 18 triples that you asked to delete, these 3 were not present. Do you still want to delete the other 15?")
(The staff contact for the SPARQL 1.1 WG deserves to be shot.)
Violence is never called for in standards development, no matter how frustrating the person's behavior. Please edit to advocate a different corrective measure.