- From: Steve Speicher <sspeiche@gmail.com>
- Date: Mon, 24 Nov 2014 15:42:52 -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 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. 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:43:19 UTC