Re: ISSUE-100: Should ld-patch use a slash like sparql does, instead of as it currently does?

On Mon, Aug 18, 2014 at 3:42 PM, Sandro Hawke <sandro@w3.org> wrote:
> Okay, I guess we're now clear on the disagreement, and can throw it open to
> the wider group:
>
> Should it be a design goal for the ld-patch path expression language be
> compatible with the sparql path expression language on the points where they
> overlap in functionality?
>
> I say yes, and I hear you saying no.

You don't hear what I say: I say *yes*, but I disagree where you think
there is overlap.

>
> My argument is primarily about people re-using what they've learned in other
> parts of the semweb stack.   In some cases, this might even involve cutting
> and pasting.    This reminds me of RDF-WG's ISSUE 1, which was resolved with
> consensus that Turtle and SPARQL should align where feasible.

Again, I don't disagree.

>
> You counter, that xpath is just as valid a thing to align with.

The spec doesn't mention xpath more than it mentions SPARQL as a starting point.

My comment is that in the context of that discussion, xpath is as
legitimate as SPARQL. If the conclusion you draw from there is "it's
not legitimate at all" then it is fine with me.

>   My sense
> is it's not; I think the LDP and SPARQL user bases will overlap about 50%
> and the LDP and XPATH user bases will overlap about 10%.

Ok, please forget that xpath thing, my comment was *never* about
communities. And I took your comment as being related to the language,
sorry if I misunderstood you.

As I said before, I hope people won't think too much about SPARQL when
they see LD Patch, because it's misleading.

>    Of course I'm
> completely making up those numbers, but I wanted to be clear about what my
> expectations are.    If I'm right about those numbers, I think that would be
> a compelling case for alignment.

If people have SPARQL, I don't think they really need LDP at all. If I
could have SPARQL for my use-case, I would go with it. But I would
probably design different applications then :-)

>
> To go meta for a second here -- we don't need to resolve ISSUE-100 before
> FPWD, we just need to make it as an issue highlighted in the draft.    So
> perhaps we should table this discussion until after FPWD, and until then
> focus on that FPWD text.

What do you want exactly to highlight in the draft? We are already
saying the following:

[[
The LD Patch format described in this document should be seen as an
"assembly language" for updating RDF Graphs. It is the intention to
confine its expressive power to an RDF diff with minimal support for
blank nodes and rdf:list manipulations. For more powerful operations
on RDF Graphs and Quad Stores, the LDP WG recommends the reader to
consider SPARQL Update.
]]

Alexandre

>
>       -- Sandro
>
>
>
>
> On 08/18/2014 11:58 AM, Alexandre Bertails wrote:
>
> On Mon, Aug 18, 2014 at 12:55 PM, Sandro Hawke <sandro@w3.org> wrote:
>
> On 08/18/2014 09:30 AM, Alexandre Bertails wrote:
>
> On Mon, Aug 18, 2014 at 12:00 PM, Sandro Hawke <sandro@w3.org> wrote:
>
> On 08/18/2014 08:17 AM, Alexandre Bertails wrote:
>
> Just to be more precise, this concerns the path expressions [1]. There
> are already slashes being used there.
>
> So I guess Sandro's proposal is to make LD path expressions *look
> like* SPARQL property paths.
>
> That's not my proposal.
>
> In general my view is that when the semantics are the same, the syntax
> should be the same, and when the semantics are different, the syntax
> should
> be different.  I hope we would all agree with that, in principle.
>
> After that, it's details.   Important details, like whether the semantics
> are the same.
>
> SPARQL as a path expression language and LD-Patch has path expression
> language.   There is no question they have different expressiveness.    I
> would argue that when they are saying the same thing, however, they
> should
> use the same syntax.
>
> For example, "start with node <a> then follow the <p1> property twice,
> then
> the <p2> property once".
>
> In SPARQL that looks like:
>
> <a> <p1>/<p1>/<p2>
>
> in LD-Patch that looks like:
>
> <a> /<p1>/<p1>/<p2>
>
> Let me give you the rationale behind that. Also note that you may
> understand better what's going on if you forget SPARQL for a moment
> and start with a fresh mind.
>
> That's a pretty awkward place to start.     Is the spec going to say "if you
> already know SPARQL Property Paths (SPP), do your best to forget them before
> you read on"?
>
> The only reason I said that is because it appears as if you try to
> find SPARQL in LD Patch wherever you can, and this is the wrong
> approach, because 1. the spec does not build on top of existing
> SPARQL, and 2. it is actually much closer to xpath as we discussed
> earlier.
>
> If you look at the syntax and the abstract model, a path expression is
> a list of path elements (either steps or constraints). There are meant
> to be applied *to a set of nodes* (possibly with one element eg. the
> starting node in a Bind), from left to right, and recursively when
> nested.
>
> I don't see this being different from SPP.
>
> LD path expressions are simpler in their definition as the left
> operand is always a concrete node (a variable would be interpreted
> first).
>
>
> In that context, / is an infix operator, the left hand side being a
> set of nodes, and right hand side being a step.
>
> I think I understand, but it seems like a gratuitous change from SPP.
>
> If you assume that SPP was the starting point, then I would agree. But
> that's not the case.
>
>
> The intuition is that when you see `node(s) / p1 / p2`, it means that
> you start with the current nodes and try to follow p1, this gives you
> a new set of nodes, on which you can now apply p2.
>
> Same with SPP.
>
> The subject and the object can be variables in SPP. You need something
> more general than node sets: multisets of solution mappings.
>
>
> Then you may object that this seems to not work anymore when used in
> constraints eg. `node(s) / p1 / p2 [ / p3 ]`. Actually, the set of
> nodes when in a constraint is there *implicitly*, a constraint being
> exactly like a higher-order function, whose argument is the set of
> nodes before getting into the constraint.
>
> I'm not concerned with constraints for the purposes of issue-100.
>
> But they are relevant to your question, so you cannot just ignore
> them. Their semantics really are higher-order functions as predicates,
> taking node sets, therefore the operator is applied there as well.
>
> / is used consistently in the whole path, including its semantics.
>
> I'm not saying it's internally inconsistent, just that it's gratuitously
> different from SPP, as far as I can tell.
>
> I think it's very important that we borrow whichever bits of SPP work
> reasonably well for LD-Patch.
>
> ^ doesn't harm anybody, and it really is the inverse path.
>
> / are used to create StepForward and StepBackward. Not to construct a Path.
>
> Also, your comment (re: borrowing bits) also applies to other
> technologies, like xpath...
>
> Alexandre
>
>
> Now again, same argument as last email, changing that would be a -0.9 for
> me.
>
> The semantics are (arguably) the same; the syntax is extremely similar,
> differing only in the leading slash.
>
> To me that difference is a show-stopper.  That's ISSUE-100.
>
> A show-stopper? As in -1 or -0.9 ?
>
> I'm not going to -1 any design decisions here, but I think it's critical to
> answer the questions I raise above.  I'm entirely confident we'll have to
> answer them later with this design, and at that point it'll be much harder.
>
>
>        - s
>
> Alexandre
>
>        -- Sandro
>
>
>
> But unlike SPARQL, LD path expressions can be nested, and include
> constraints. SPARQL does that with FILTER and new constraints in the
> BGP. The grouping in SPARQL (using parenthesis) is very different from
> the constraints (square brackets and exclamation mark).
>
> I think it's a bad idea to make them feel like they behave the same,
> which could be induced by the choice of the syntax.
>
> I don't want to stop the group with syntactical questions thought, so
> just a -0.9 for me.
>
> Alexandre
>
> [1]
>
> https://dvcs.w3.org/hg/ldpwg/raw-file/ldpatch/ldpatch.html#path-expression
>
> On Mon, Aug 18, 2014 at 10:59 AM, Linked Data Platform  Working Group
> Issue Tracker <sysbot+tracker@w3.org> wrote:
>
> ISSUE-100: Should ld-patch use a slash like sparql does, instead of as
> it
> currently does?
>
> http://www.w3.org/2012/ldp/track/issues/100
>
> Raised by:
> On product:
>
>
>
>
>
>

Received on Monday, 18 August 2014 20:13:37 UTC