Re: Updated LD Patch specification

Sandro,

On Wed, Nov 26, 2014 at 12:03 AM, Sandro Hawke <sandro@w3.org> wrote:

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

I understand that. And so when the LD Patch spec reads "remove triple X
from the target graph", it actually means "replace the state of the RDF
source being patched by the result of removing X from the target graph". My
question was rather: do we agree that the second phrasing is overly
complicated and that the current phrasing is clear enough ?

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