Re: Updated LD Patch specification

On Mon, Nov 24, 2014 at 3:42 PM, Steve Speicher <> wrote:
> On Mon, Nov 24, 2014 at 2:30 PM, Alexandre Bertails
> <> wrote:
>> On Mon, Nov 24, 2014 at 2:10 PM, Steve Speicher <> 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?


> 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]:
> Thanks,
> Steve Speicher
>> So the question is now for Arnaud: is it ok for me to proceed and make
>> such an addition to the spec?
>> Alexandre
>>> [1]:
>>> Thanks,
>>> Steve Speicher
>>> On Fri, Nov 21, 2014 at 5:13 PM, Alexandre Bertails
>>> <> 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]
>>>> [2]

Received on Monday, 24 November 2014 20:53:22 UTC