Re: Updated LD Patch specification

On Mon, Nov 24, 2014 at 4:00 PM, Steve Speicher <> wrote:
> On Mon, Nov 24, 2014 at 3:52 PM, Alexandre Bertails
> <> wrote:
>> 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?
> 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]

Note that this change will *not* be consistent with JSON PATCH [2]:

The "remove" operation removes the value at the target location.

The target location MUST exist for the operation to be successful.

Nor it will be with XML PATCH, whose deletion relies on the sel attribute [3]:

   <unlocated-node>:  A single unique node (typically an element) could
      not be located with the 'sel' attribute value.  Also, the location
      of multiple nodes can lead to this error.



> [1]:
> - 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]:
>>> 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 21:08:22 UTC