Re: Updated LD Patch specification

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]


- 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:00:46 UTC