- From: Steve Speicher <sspeiche@gmail.com>
- Date: Mon, 24 Nov 2014 16:00:16 -0500
- To: Alexandre Bertails <alexandre@bertails.org>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, Arnaud Le Hors <lehors@us.ibm.com>, Tim Berners-Lee <timbl@w3.org>, Sandro Hawke <sandro@w3.org>
On Mon, Nov 24, 2014 at 3:52 PM, Alexandre Bertails <alexandre@bertails.org> wrote: > On Mon, Nov 24, 2014 at 3:42 PM, Steve Speicher <sspeiche@gmail.com> wrote: >> On Mon, Nov 24, 2014 at 2:30 PM, Alexandre Bertails >> <alexandre@bertails.org> wrote: >>> On Mon, Nov 24, 2014 at 2:10 PM, Steve Speicher <sspeiche@gmail.com> wrote: >> ...snip... >>>> >>>> <#delete-statement> I wonder about this requirement: >>>> "It fails if one of those triples does not exist in the target graph." and later >>>> "If a Delete attempts to remove a non-existing triple, then a HTTP 422 >>>> (Unprocessable Entity) error status code must be returned." >>>> I wonder why this requirement exists? I could see cases where I might >>>> want to "blind delete" triples, for example I'm delete'ing a web >>>> resource and I want to bulk a number of other resources that link to >>>> it (i.e. contain triples with known pattern). Given the quoted >>>> requirement, I would first need to GET every resource that I believe >>>> could have a link-to triple, then formulate the PATCH and submit the >>>> patch. Reading PATCH (RFC5789) I don't see where this requires this, >>>> if if the operation "Delete" is successful the graph doesn't contain >>>> the triple. This seems like it doesn't align with the fact that Add >>>> MUST NOT fail if the graph already contains the triple. >>> >>> That is a very good remark that Pierre-Antoine, Andrei, and I debated >>> *a lot* :-) Note that it applies to Add as well, i.e. is it ok to add >>> an already existing triple? >>> >>> We know that we want the default to be non-silent on that kind of >>> errors (for Delete at least as Add doesn't fail in the dual case). >>> That was a requirement we had from different people, including TimBL >>> re: silent fail is bad. >>> >> I agree that silent failure is bad. I don't see this as silent >> failure. I guess it is your perspective. Giving a set of PATCH >> operations, my goal is to get the resource to the desired end state >> (target end graph). If some of the operations along the way are >> skipped or don't apply, I don't see it as an error (or silent >> failure). >> >>> That being said, we also agree that "blind delete" is a very valid >>> use-case. We thought about adding a directive in LD Patch so that one >>> can change the default. We didn't do it, because 1. that would have >>> been an arbitrary choice from us without having other people bringing >>> the use-case, while we were trying to deliver a stable specification, >>> and 2. because this could have been easily added as a _conservative >>> extension_ in a second version. >>> >> >> I'm not sure what you are proposing to change: delete, add or both (or >> some global parameter). >> >>> But now that you brought it, and because it is easy to add, and >>> because we have one more week to do so, we can think about doing it. I >>> already know that Andrei and Pierre-Antoine are totally fine with this >>> addition. >> >> I personally believe the correct approach would be to not fail when: >> a) Adding an identical triple >> b) Delete'ing a triple that doesn't exist >> >> Could there be cases where this matters? Maybe, I struggle to find >> them because the semantics are to have the resource (graph) to the >> desired target state. > > I see. > > I guess the use-case is more about making sure that you don't end up > doing a modification that was not intended, but that could (should?) > be done with etags, instead of *inside* the language. > > Here is a proposition (I haven't talked to Pierre-Antoine and Deiu > about it yet): what about having the behaviours in a) and b), and > adding a section recommending the use of etags to prevent one to make > unwanted deletions? > PATCH already some of this language, as well as LDP, though I agree it would be helpful to make it obvious in LD Patch. [1] [1]: http://tools.ietf.org/html/rfc5789 - Steve > Alexandre > >> >> How SPARQL Update handles deletion: >> "Note that the deletion of non-existing triples has no effect, i.e., >> triples in the QuadData that did not exist in the Graph Store are >> ignored." [1] >> >> [1]: http://www.w3.org/TR/sparql11-update/#deleteData >> >> Thanks, >> Steve Speicher >> http://stevespeicher.me >> >>> So the question is now for Arnaud: is it ok for me to proceed and make >>> such an addition to the spec? >>> >>> Alexandre >>> >>>> >>>> >>>> [1]: https://dvcs.w3.org/hg/ldpwg/file/cd2b89e3cdc8/ldpatch.html >>>> >>>> Thanks, >>>> Steve Speicher >>>> http://stevespeicher.me >>>> >>>> >>>> On Fri, Nov 21, 2014 at 5:13 PM, Alexandre Bertails >>>> <alexandre@bertails.org> wrote: >>>>> All, >>>>> >>>>> We have updated the LD Patch specification [1]. >>>>> >>>>> We may have few fixes over the week-end, but we believe it is now >>>>> stable and ready for review. You can find a summary of the changes at >>>>> the end of the document. >>>>> >>>>> Most notably: >>>>> >>>>> * this includes TimBL's proposal to accept Turtle in Add statements. >>>>> * ISSUE-100 is *pro-actively resolved*, please see [2] >>>>> * we believe that comments from TimBL, Steve, and Sandro are addressed. >>>>> >>>>> Cheers, >>>>> >>>>> Alexandre >>>>> >>>>> [1] https://dvcs.w3.org/hg/ldpwg/raw-file/ldpatch/ldpatch.html >>>>> [2] http://lists.w3.org/Archives/Public/public-ldp-wg/2014Nov/0064.html
Received on Monday, 24 November 2014 21:00:46 UTC