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

Re: Updated LD Patch specification

From: Sandro Hawke <sandro@w3.org>
Date: Tue, 25 Nov 2014 18:03:54 -0500
Message-ID: <54750ADA.8040609@w3.org>
To: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>, Alexandre Bertails <alexandre@bertails.org>
CC: Steve Speicher <sspeiche@gmail.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, Arnaud Le Hors <lehors@us.ibm.com>, Tim Berners-Lee <timbl@w3.org>
On 11/25/2014 02:16 PM, Pierre-Antoine Champin wrote:
> 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 ? :)
>

Just think of graphs like numbers.    You can subtract from a number but 
you cannot decrement a number.  (Rather, you decrement a variable.)

And, of course, we're all familiar with immutable data structures. 
Graphs are necessarily immutable in the RDF model.

The intent of the term "RDF Source" was to capture the idea of a 
Resource whose state is an RDF Graph.

        -- Sandro
> 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 <mailto:alexandre@bertails.org>> wrote:
>
>     On Tue, Nov 25, 2014 at 9:32 AM, Steve Speicher
>     <sspeiche@gmail.com <mailto:sspeiche@gmail.com>> wrote:
>     > On Tue, Nov 25, 2014 at 9:27 AM, Alexandre Bertails
>     > <alexandre@bertails.org <mailto:alexandre@bertails.org>> wrote:
>     >> Hi Steve,
>     >>
>     >> On Tue, Nov 25, 2014 at 8:44 AM, Steve Speicher
>     <sspeiche@gmail.com <mailto:sspeiche@gmail.com>> wrote:
>     >>> On Mon, Nov 24, 2014 at 10:51 PM, Alexandre Bertails
>     >>> <alexandre@bertails.org <mailto:alexandre@bertails.org>> wrote:
>     >>>> On Mon, Nov 24, 2014 at 2:30 PM, Alexandre Bertails
>     >>>> <alexandre@bertails.org <mailto:alexandre@bertails.org>> wrote:
>     >>>>> On Mon, Nov 24, 2014 at 2:10 PM, Steve Speicher
>     <sspeiche@gmail.com <mailto: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 <mailto: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 23:03:57 UTC

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