Re: Updated LD Patch specification

• From: Steve Speicher <sspeiche@gmail.com>
• Date: Mon, 24 Nov 2014 16:00:16 -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>
• Message-ID: <CAOUJ7JpPXoQEome49g=BrzFf14S=EGbdwtKtUdGyLs82pcLNLA@mail.gmail.com>

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]
[1]: https://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]: https://www.w3.org/TR/sparql11-update/#deleteData
>>
>> Thanks,
>> Steve Speicher
>> https://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
>>>> https://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] https://lists.w3.org/Archives/Public/public-ldp-wg/2014Nov/0064.html

Received on Monday, 24 November 2014 21:00:46 UTC