- From: Sandro Hawke <sandro@w3.org>
- Date: Tue, 25 Nov 2014 18:03:54 -0500
- 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>
- Message-ID: <54750ADA.8040609@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