Re: Updated LD Patch specification

On Mon, Nov 24, 2014 at 4:00 PM, Steve Speicher <sspeiche@gmail.com> wrote:
> On Mon, Nov 24, 2014 at 3:52 PM, Alexandre Bertails
> <alexandre@bertails.org> 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?
>>
>
> 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.
]]

Alexandre

[2] https://tools.ietf.org/html/rfc6902#section-4.2
[3] https://tools.ietf.org/html/rfc5261#page-18

>
> [1]: http://tools.ietf.org/html/rfc5789
>
> - 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]: 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 21:08:22 UTC