Re: Comments on Linked Data Patch Format FWPD

Hi,

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

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

  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.

 best


> Cheers,
>
> Alexandre
>
> >
> > My 2¢ worth anyway
> >
> > Tim
> >
> > Developer hat on
> > Director hat off
> >
> >
> >
> >
>