Re: Updated LD Patch specification

On the substance: it's not clear to me that if I ask for deletion of a 
triple that is not there it is a failure, given that I actually end up 
with exactly what I want: not to have this triple present. So, I don't 
think the argument about silent failure applies here.

You said you didn't have a use case for blind delete but what is the use 
case for knowing whether the deletion really took place rather than just 
knowing that the triple is not or no longer there? I can see how one wants 
to make sure that they know what the state of the resource is, I don't see 
why they would care how they get it.

On the form: it's really up to the WG. You can always make the change - 
it's an editor's draft - but by making the change without discussion by 
the WG you run the risk of having the WG decide otherwise. Just like it 
happened for /.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Standards - IBM 
Software Group


bertails@gmail.com wrote on 11/24/2014 11:30:18 AM:

> From: Alexandre Bertails <alexandre@bertails.org>
> To: Steve Speicher <sspeiche@gmail.com>
> Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, Arnaud Le Hors/
> Cupertino/IBM@IBMUS, Tim Berners-Lee <timbl@w3.org>, Sandro Hawke 
> <sandro@w3.org>
> Date: 11/24/2014 11:30 AM
> Subject: Re: Updated LD Patch specification
> Sent by: bertails@gmail.com
> 
> 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.
> 
> >
> > <#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.
> 
> >
> > <#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.
> 
> >
> > <#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.
> 
> >
> > <#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.
> 
> 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
>