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

Re: Updated LD Patch specification

From: Steve Speicher <sspeiche@gmail.com>
Date: Mon, 24 Nov 2014 14:10:47 -0500
Message-ID: <CAOUJ7JrL=JYuPcQepOApqLCLwJn0muaRh--NCHBNvot_Jryjrw@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>
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]])".

<#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.

<#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.

<#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.

<#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).

<#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.

[1]: https://dvcs.w3.org/hg/ldpwg/file/cd2b89e3cdc8/ldpatch.html

Steve Speicher

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 19:11:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:52 UTC