W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2014

Re: Updated LD Patch specification

From: Alexandre Bertails <alexandre@bertails.org>
Date: Mon, 24 Nov 2014 15:52:55 -0500
Message-ID: <CANvn8kwcvvhKWYhbX9hSnAO6OYZepPwyfSRJuv0zUYTyM3v4Mw@mail.gmail.com>
To: Steve Speicher <sspeiche@gmail.com>
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>
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?

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 20:53:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:59 UTC