Re: Updated LD Patch specification

Re. "RDF Graph" vs. "RDF Source" : very well spotted. Indeed, RDF 1.1
Concepts insists on the fact that a graph is a mathematical set, hence not
something that can be modified... However, changing the spec to replace
"the target graph" by something like "the state of the target RDF source"
would make it harder to read.

If I read RDF 1.1 Concepts on that topic, it says:

  Since RDF graphs <http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-graph> are
defined as mathematical sets, adding or removing triples
<http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-triple> from an RDF graph
yields a different RDF graph.

So it does, in a way, endorse the language "adding or removing triples from
a graph", right ? :)

I would suggest we discard this issue when defining "target graph" (saying
that this is the state of the LDP-RS being patched), and then stick to the
actual wording.

On Tue, Nov 25, 2014 at 3:49 PM, Alexandre Bertails <alexandre@bertails.org>
wrote:

> On Tue, Nov 25, 2014 at 9:32 AM, Steve Speicher <sspeiche@gmail.com>
> wrote:
> > On Tue, Nov 25, 2014 at 9:27 AM, Alexandre Bertails
> > <alexandre@bertails.org> wrote:
> >> Hi Steve,
> >>
> >> On Tue, Nov 25, 2014 at 8:44 AM, Steve Speicher <sspeiche@gmail.com>
> wrote:
> >>> 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.
> >>
> >> The LDP spec says that an LDP-RS is an LDPR, that is, a "resource
> >> whose state is represented in any way that *conforms* to the simple
> >> lifecycle patterns and conventions in section 4. Linked Data Platform
> >> Resources." (emphasis mine)
> >>
> >> If we say "Linked Data resource, aka. LDP-RS" then all of a sudden,
> >> aren't we saying that all Linked Data resources must conform to the
> >> "simple lifecycle patterns and conventions in section 4. Linked Data
> >> Platform Resources"? Wouldn't that make LD Patch artificially tied to
> >> those "special" resources?
> >>
> >> I just want to make sure that this is the change you are asking for.
> >> Please tell me if I misread something, either in the LDP spec, or in
> >> your proposal.
> >>
> > No, I wasn't suggesting to raise the bar for those that want to
> > leverage LD Patch.  I was just trying to align terminology, so RDF
> > concepts defines: "RDF Graph" and "RDF Source".  In LDP we were
> > careful to select "RDF Source".  Perhaps you really want to use graph,
> > which could be fine.
>
> "RDF Graph" and "RDF Source" would lack the connection with the target
> URI. The one reference to "RDF Source" in LDP doesn't have this
> problem in the context of its use: it is just a "see also" in the
> LDP-RS definition.
>
> I would agree that "Linked Data resource" may not be properly defined
> in any spec. But I do not think this is a problem here. After all,
> this terminology was introduced after a suggestion by Andy Seaborne in
> [1].
>
> Alexandre
>
> [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2014Aug/0064.html
>
>
> >
> > To be clear, I'm not saying this is an issue, I was just trying to
> > suggest a little more consistency if it makes sense.
> >
> > -Steve
> >
> >> Alexandre
> >>
> >>>
> >>> - 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
>
>