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

On 08/18/2014 01:13 PM, Alexandre Bertails wrote:
> 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.

Okay, well that's a step forward.    Then it comes down to the thread 
with Andy Seaborne.   Not surprisingly, like Andy, I don't see this 
difference you seem to be seeing.   Yes, the formal semantics might be 
specified differently, but the practical semantics are the same, and I 
bet the formal semantics could be made the same.

I see both languages having / and ^, with the same meaning (but an oddly 
different syntax, which is why I raised ISSUE-100).

I see ld-patch path expressions also having [... = ...], which is okay.

I see SPP also having other operators: |*+?!(), which is fine, since 
they're not necessary for ld-patch.

So now the question is: what expressions using / and ^ can you make in 
LD-Patch that have a different meaning than the corresponding 
expressions in SPARQL?


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

I hope that, too, but I don't think it's realistic to assume. Instead, 
I'd assume many of them think about SPARQL every day, and it will be 
solidly at the fore when they look at ld-patch.


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

Interestingly, SPARQL has no way to do what HTTP POST does in LDP. 
Hopefully 1.2 will add it, along with list operations.

I think both LDP and SPARQL have a long future.   Even when a server 
provides both views, some clients will prefer one, some the other; some 
developers will prefer one, some the other.     LDP is great if you just 
need to read/write within well known bounds; SPARQL is great when you 
want to gather from many different sources.

My expectation is that in time, senior developers working with this 
stack will need to know SPARQL and will occasionally also be looking at 
LD-Patch.    So having them gratuitously conflict will turn out to be 
problematic.

>> 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.
> ]]

In terms of ISSUE-100 what I want is what we always do for issues. Look 
for "issue" in:

http://www.w3.org/TR/2013/WD-ldp-20130307/

     -- Sandro

> 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 Wednesday, 20 August 2014 00:51:07 UTC