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

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.

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.

You counter, that xpath is just as valid a thing to align with. 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%.    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.

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.

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