Re: LD Patch initial comments

On Tue, Jul 15, 2014 at 12:51 PM, John Arwe <johnarwe@us.ibm.com> wrote:
> From July 14 minutes >  Draft added to Mercurial
> http://dvcs.w3.org/hg/ldpwg/raw-file/ldpatch/ldpatch.html
>
> I note this is on its own branch.  What's the utility of that?  It's not
> like the sensible case we had with bblfish where he was making "prospective
> updates" to existing documents that others were hacking away at in parallel.
> This is one file, in most cases the editors are going to fuss with it and no
> one else.  I was going to fix some clear typos myself, but creating a new
> repo locally to keep the branches untangled is more effort than it's worth
> to me.

Just do `hg update ldpatch` to switch branches. No need for another
repo. You may have to pull it first.

>
> Non-typo comments:
>
> 1: This seems "bigger than a breadbox".  I'm honestly not sure it fits in 5
> months, given its current state.  Unless Sandro et al. warrants that nearly
> all of the Frankensyntax is re-used, and with all the dependencies it needs
> easily added, this feels like another iteration of "oh for pete's sake how
> hard could this possibly be?" playing out.

The 3 authors have spent time trying to make it as simple as possible.
I am very interested in what you can "remove" from the approach to
make it "easier" (not simpler I guess), while respecting the use-case.
Remember, we don't have skolemization and we still want to change
non-pathological graphs with bnodes.

Also, most of the syntax is _copy/pasted_ from Turtle. My claim is
that the "new" productions are extremely easy to handle compared to
Turtle's.

>
> 2: Printing on std US paper at a reasonable font size, many of the examples
> overflow the right margin at least once.  Anything with a path is likely to
> overflow, for starters.

I am sure we can work on that. Also, paths can span on several lines if needed.

>
> 3: My sensible side assumes that whitespace between lexical tokens is (a)
> allowed and (b) follows the common definitions, but I can't actually verify
> that from the BNF body parts in here (I seem to be on a Halloween theme
> today), so there may be unstated "global" assumptions that need to be added
> ... and if so, one hopes that they are compatible with all the graves whence
> the parts were collected.

The concrete syntax is broken in 3 parts: the LD Patch specific rules,
the ones copied from Turtle and the ones from SPARQL. Production rules
for terminal are in upper case. We can certainly add a sentence to
explain how the tokens are parser wrt whitespaces. I can see with Eric
how they did in Turtle (couldn't find a specific sentence).

>
> 4: The text media type tree seems like an odd choice.  I expected
> application/

We asked around and others were expecting text/. It was arbitrary. I
personally don't care. Really.

>
> 5: The unicity constraint definition leaves me hanging on the "...or what?"
> I.e. what if the path is NOT unique up to the point where the ! occurs?  I'd
> guess you're implying that's an error, but I find nothing in the text really
> to support my supposition ... it's just the least surprising choice (to me).

>From the introduction:

[[
Note that each step can, in general, result in several matching nodes,
as a given node can have several (incoming or outgoing) arcs with the
same predicate.
]]

The error part will be specified in the semantics.

>
> 6: 2.4 talks about the variable "pointing" at an RDF Term (sic).  Keeping
> with the binding theme instead of switching to "point*" might be clearer.
> E.g. "...will be bound" or just "...is bound".

Yes, we meant "bound", not "point". The text will be updated accordingly.

>
> 7: 2.6 suggests (by omission) that it is impossible to delete a list,
> although (in later sections) it's possible to empty a list.  The asymmetry
> of being able to add a list, but not delete it again later, seems vaguely
> suspect although I have no concrete use cases requiring it.  At some level I
> think about it as: can I undo whatever havoc I cause?  ...and the answer
> here appears to be 'no'.

You should UpdateList as syntactic sugar for manipulating the
structure of a list. As I don't understand what you think you cannot
do, I will ask you to provide an example.

>
> 8:  The (first) Path BNF is ( step | constraint ) *  ... so I can have two
> consecutive constraints.

Yes, you can.

> The end of 2.4 is all I see wrt those constraints,
> so if I put >1 on here, how do I know their relation?  Guessing again, you
> want And... as in, meets all constraints.

No. You read it from left to right. Each step will produce a new set
of nodes, by following predicates (ie. pattern s p ?o). A constraint
will restrict the current set.

In the spirit, it's a bit like xpath, but I don't want to use the
comparison too much.

>
> 9:  I don't see any Abstract Syntax definition for UNICITY_CONSTRAINT.

It's a singleton.  Or imagine something like `UNICITY_CONSTRAINT ::= ()`.

Truth is I don't know how to represent that explicitly, so I just used
upper case for the name.

>
> 10: I'm not sure how to reliably interpret section 4, even after following
> my nose to the first 2 links.  I get the sense that you're asking me to
> somehow apply BNF syntax to the content of those pages, which don't appear
> to have any remotely similar syntax.

The abstract syntax is what I can use in the semantics. The approach
follows exactly what was done in RDB2RDF Direct Mapping.

>
> 11:  Given that Constraint wanders into comparison for equality, you need
> rules for that if anyone is going to reliably interop on it.  In paging, we
> re-used SPARQL's rules.  Otherwise you have to lay out the various cases
> like typed ?= untyped if the lexical value is otherwise identical, which
> history shows are not trivial to get complete and right.

It is _strict_ equality: in the case of a literal, the three
components must be the same(lexical form, datatype, langtag if
present). No magic like in SPARQL, the use-case here is very
different.

Regards,

Alexandre.

PS: I am joining my slides for tomorrow, hoping that I will be able to
point to them tomorrow from the archives.

>
> Best Regards, John
>
> Voice US 845-435-9470  BluePages
> Cloud and Smarter Infrastructure OSLC Lead