- From: Alexandre Bertails <alexandre@bertails.org>
- Date: Mon, 24 Nov 2014 15:52:55 -0500
- To: Steve Speicher <sspeiche@gmail.com>
- 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: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? 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 20:53:22 UTC