W3C home > Mailing lists > Public > public-ldp-comments@w3.org > September 2014

Re: Comments on Linked Data Patch Format FWPD

From: Pierre-Antoine Champin <pchampin@liris.cnrs.fr>
Date: Fri, 26 Sep 2014 18:06:12 +0200
Message-ID: <CA+OuRR_W-9EzC=YJD75086dKsnWpp5i7GDfSk6nG4zqxQFN=1g@mail.gmail.com>
To: Alexandre Bertails <alexandre@bertails.org>
Cc: Tim Berners-Lee <timbl@w3.org>, Arnaud Hors <lehors@us.ibm.com>, Ralph Swick <swick@w3.org>, "team-ldp-chairs@w3.org" <team-ldp-chairs@w3.org>, Andrei Sambra <asambra@mit.edu>, Sandro Hawke <sandro@w3.org>, "public-ldp-comments@w3.org" <public-ldp-comments@w3.org>

thanks indeed Tim for this feedback. A few complements on Alexandre's reply

On Fri, Sep 26, 2014 at 4:31 PM, Alexandre Bertails <alexandre@bertails.org>

> Hi Tim,
> Thanks for the review. Please find my comments in line.
> On Fri, Sep 26, 2014 at 5:17 AM, Tim Berners-Lee <timbl@w3.org> wrote:
> > Arnaud et al
> >
> > Here some immediate technical comments on
> > http://www.w3.org/TR/2014/WD-ldpatch-20140918/
> >
> > 1) " then the server must not apply any of the changes."  What HTTP
> error code is then returned?  You must spec the little network protocol
> bits here I think. Or is that in LDP already?
> It may not always be clear in this FPWD but the semantics of the
> request at the HTTP level is already defined in RFC 5789. That phrase
> was actually copied from there.
> Error handling is defined at
> http://tools.ietf.org/html/rfc5789#section-2.2 .
> I agree that the connection must be made more explicit. We could
> provide a section with examples of HTTP PATCH interactions, including
> failing ones.
> >
> > 2) - Why do some production names are in bold in the concrete syntax and
> some not?
> No idea. We will fix that.
> >
> > 3) Step ::= '/' ( '^' iri | iri | INDEX )         eh?    Do you mean
> Step ::=   (  '/'  '^'?    iri )   iri   |   INDEX
> A Step is when you move your pointer. A Step is introduced with '/'.
> Then you find the 3 possibilities: StepBackward, StepForward, and
> StepAt. These options are informally introduced in [1].
> [1] http://www.w3.org/TR/2014/WD-ldpatch-20140918/#path-expression

I don't really understand how you go from our rule to yours...
We could of course have written it

  Step ::= '/' ( '^'? iri | INDEX )

but it seemed better to reflect in the grammar the 3 possibilities
mentionned by Alexandre.

> > 4) "The Bind operation is used to create a new variable by binding or
> assigning an RDF Term to the variable."
> > Do you mean one or many?  Happy with either, both have their uses. I
> thought I saw many allowed somewhere in the document.
> > Probably veer toward many, for consistency with SPARQL.  You have a
> unicity operator for
> Only one. This will be very clear in the formal semantics (coming
> soon) but could be made more explicit in the informative section.
> If you see LD Patch as a diff (you should), a variable being a set of
> nodes (1 node or more, not 0) changes the semantics quite a lot.

I concur. The purpose of 'Bind' is not to match whatever node(s) that
is/are accessible by the path, they are here to identify a precise blank
node. If, on the server side, that path identifies 0 or 2+ node(s), this is
the symptom of an inconsistency between the client's view and the server's
view, so it should be treated as an error.

> >
> > 5)   Add s  p o  vs.   insert { ... }   I  prefer the latter I must say
> >  --- why be arbitrarily different from SPARQL, turtle, etc?
> Actually, it is arbitrary similar to RDF Patch [2] :-) Pierre-Antoine
> did mention where he was coming from in his proposal.

Correct. Also, in SPARQL Upadte, an INSERT may have no effect (if its
variables are not bound), and the next one could still have an effect. In
LD-Patch, if a Bind ?x fails, every Add (including those not involving ?x)
will fail -- actually, the whole patch will. So being to similar to SPARQL
may break expectations.

> As for supporting both "Add" and "A", this is actually from... you!
> Andrei and I were showing you Pierre-Antoine's solution after the last
> F2F in Boston, and you suggested that you would prefer to see the
> entire word if possible :-)
> [2] http://afs.github.io/rdf-patch/#further-rdf-patch-examples
> >  --- I already have a { stuff } parser as do many people
> > --- it is a pain to have to write a separate line for each
> > -- I'd like to use [] for bnodes in the insert bit.
> That would not change the semantics, but it would make the syntax a
> superset of Turtle. So more work if one is starting with the grammar
> from scratch.

Not strictly a superset, I guess, but still something more complex that the
current syntax.
Our fear was that it would make it significantly harder to implement an
LD-Parch parser...
However, I'm not totally against either.

I am personally not against that, but you have to understand that this
> a departure from the original design: LD Patch started as being syntax
> compatible with RDF Patch, and added just what was needed for the LDP
> use-case (bnode and rdf:list support).
> Feel free to insist on that, and I am asking others to voice their
> opinion as well. I would prefer this change to be formally approved by
> the group. But I don't see good reasons for not doing it.

> 6)  The '!' constraint: with the uniqueness constraint,  if the test
> fails, is that an error and the whole thing is aborted, or that brach of
> the query is silently abandoned? "Is it select all those people with one
> home." or "select all people. Assert a person only has one home".   Or is
> it "Just pick any one and proceed".
> Another example of something that can be improved in the informative
> section, and that will be super explicit in the formal semantics.
> The editors all agreed that silent failure would always be avoided in
> LD Patch. If something doesn't match, then it's an error.
> So in the case of a failing '!' constraint, it is seen as a runtime
> error, so per RFC 5789 the whole query fails.

Think of '!' as an assertion, to ensure consistency between the client's
view and the server's view.

> >
> > 7) Maybe :: or some thing as a index operator, not just a space.   The
> conventional [] are overused already, of course.
> Can you please clarify? I am not sure to understand what you mean.
> Maybe an example?

It might have to do with our misunderstanding on 3).
Currently, if I want to match the location of the third author, I have to

  Bind ?loc <#doc>/v:authors/2/v:location .

So there are '/', not just spaces...
What is it exactly you suggest? Something like:

  Bind ?loc <#doc>/v:authors::2/v:location .

I'm not sure I see the value of a different separator. As explained in the
spec <http://www.w3.org/TR/2014/WD-ldpatch-20140918/#path-expression>, you
can think of integers (in the Step production rules) as syntactic sugar for
the corresponding sequence of rdf:rest and rdf:first, as the path above is
equivalent to

  Bind ?loc <#doc>/v:authors/  rdf:rest/rdf:rest/rdf:first  /v:location .

hence the choice to use the same separator for IRIs and integers.


> Cheers,
> Alexandre
> >
> > My 2ยข worth anyway
> >
> > Tim
> >
> > Developer hat on
> > Director hat off
> >
> >
> >
> >
Received on Friday, 26 September 2014 16:07:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:16:45 UTC