Re: Updated LD Patch specification

I agree that Steve and Arnaud are making a very valid point :
ETags are probably the best way to ensure that the graph being patched has
not be modified behind our back.

It should be noted however that LD Patch documents are not always
idempotent... Namely, Adding fresh bnodes, Cutting or UpdateList'ing would
not be (in general). I think however that one could determine statically
(i.e. solely based on the LD Patch document) whether it is idempotent or
not...


On Mon, Nov 24, 2014 at 10:00 PM, Andrei Sambra <andrei@w3.org> wrote:

>
>
> On 11/24/2014 03:52 PM, Alexandre Bertails 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?
>
> Actually, that is a very good point. I've been meaning to add a section
> about the use of ETags but I got distracted by other things.
>
> The point is that clients should always send an If-Not-Modified header
> when attempting to patch a document. If nothing else, just consider it
> as best practice. That should fix the concurrency issues we may get.
>
> (I can take an action to add this section)
>
> -- Andrei
>
> >
> > 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
> >
>
>