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

Re: Updated LD Patch specification

From: Steve Speicher <sspeiche@gmail.com>
Date: Tue, 25 Nov 2014 08:44:43 -0500
Message-ID: <CAOUJ7JpBwpLWBcPgZW8bni5RWRAGJUGkY-ALtdEwv1sm8ATddw@mail.gmail.com>
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>
On Mon, Nov 24, 2014 at 10:51 PM, Alexandre Bertails
<alexandre@bertails.org> 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:
>>> Some additional feedback on the latest editor's draft last modified
>>> 23-November-2014 [1].
>>>
>>> Overall a great improvement, one red flag for me is that the entire
>>> document contains 13 RFC2119 conformance keywords, that seems very
>>> low.  For an example, LDP's last publication contained about 103.
>>> Below are some specific comments.  The biggest issues are the keywords
>>> and the different between Add and Delete when they can ignore an
>>> operation (one case it is success and the other failure).
>>>
>>> <#introduction> Seems it would be good to use some LDP terminology
>>> here, for example:
>>> "LD Patch language (or LD Patch document) defines a list of operations
>>> to be performed against a Linked Data resource"
>>> adding " (also known as LDP RDF Source [[LDP]])".
>>
>> Agreed.
>
> Sorry, I responded too quickly on that one.
>
> LD Patch enables PATCHing for LDP-RS as defined in LDP, but it is not
> restrained to them.
>
Not sure I understand this point.  LDP-RS is a definition which
matches mostly the terminology you have.  So not sure why to create
something new, esp. if produced by the LDPWG.   I wasn't suggesting
that LD Patch only applied to LDP-RS, I was suggesting that we are
consistent in terminology.  It should help the reader.

- Steve

>>
>>>
>>> <#list-manipulation-examples> Suggested improvements here.  I don't
>>> have much background on using this slicing approach, so I tried to
>>> learn it from the examples but I found myself having a little trouble,
>>> I could imagine others would.  It would help to see the result, have
>>> each example use the output from the previous as input to the next.
>>
>> Agreed seeing results. But I don't think that keeping a state for the
>> previous operations help for readability: it's better to always reuse
>> the same input.
>
> Done.
>
>>
>>>
>>> <#semantics> (intro paragraph) Again the terminology is near LDP-RS
>>> but different, the "target graph" is the "LDP RDF Source" or "target
>>> LDP-RS".  Not sure your terminology should completely change to LDP's
>>> but I think there should be some connection made.
>>
>> Yes, this is a good remark.
>
> Same remark than above.
>
>>
>>>
>>> <#semantics> Section is not marked "non-normative" but in all 3.1-3.3
>>> sections I only see 1 statement with a RFC2119 conformance keyword,
>>> 3.4 has a list of them though.  Is this intentionally?  ReSpec only
>>> recognizes 13 RFC2119 keywords in the whole document, that seems low.
>>
>> Well, there are only 2 kinds of errors: static/syntactic, or at
>> runtime. So it either goes well, or if it doesn't go well, then
>> <#error-handling> tells you what you must do.
>>
>> I know it doesn't like a lot, but not that much can happen in LD Patch.
>>
>>>
>>> <#bind-statement> Is "RDF Term" the same thing as "RDF terms" from
>>> http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-term ?  Assume so, would
>>> be good to put a reference in and be consistent in style (it doesn't
>>> use uppercase T in terms).
>>
>> I'll look into it.
>
> Good catch. I have made the change to all occurrences of RDF Term.
>
>>
>>>
>>> <#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.
>
> Still have to work on that one.
>
> Cheers,
>
> Alexandre
>
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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 Tuesday, 25 November 2014 13:45:15 UTC

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