> On 2021-02-23, at 17:37:52, Andy Seaborne <a...@apache.org> wrote:
>
>
>
> On 23/02/2021 15:44, james anderson wrote:
>>> On 2021-02-23, at 15:10:23, Andy Seaborne <a...@apache.org> wrote:
>>>
>>>
>>>
>>> On 22/02/2021 15:31, james anderson wrote:
>>>> why did the authors exclude path variables when considering the
>>>> alternatives.
>>>> this formulation appears intuitive.
>>>> ASK { <x> ?p+ <y> }
>>>
>>> Which is almost:
>>>
>>> ASK { <x> (!<>)+ <y> }
>> but for that it should yield bindings.
>
> ASK does not yield bindings so the rewrite is valid.
>
> And only because it's ASK.
> Which is what you asked!
that was circumstantial, following from the original question, and not to the
actual point, which is how the bgp behaves.
>
>>>> why was it rejected?
>>>
>>> Time mostly.
>>>
>>>> discussions appear here and elsewhere as to the wildcard predicate
>>>> expression and its variants.
>>>> why was it not permitted as a direct expression?
>>>
>>> ASK is not special in its evaluation of patterns.
>>>
>>> In SELECT and more general path settings:
>>>
>>> What would the answer be? And how many? What if there are DAGs?
>> why would one not interpret it analogous to
>> { ?z <z>+ ?y }
>
> What is the analogy?
apply the same interpretation mechanism.
> (Did you mean variables in S and O?)
>
> How many rows are you expecting to { <x> ?p+ <y> }
that would depend on the dataset.
thus the “analogy” notion, above and the “when implemented …”, below.
>
> One? if so, what about "?p*" and "?p?" ?
>
> Many? But there are different ways of "many" in a graph with DAGs and SPARQL
> distinct connectivity semantics.
>
>> that is, as yielding successive bindings which correspond to the progression
>> through the graph.
>
> The specs uses "ALP" (which is not join based) which is an algorithm for
> connectivity without presuming which route is taken to encountered a node.
> That affects cardinality.
the reference to “join based” was an attempt to answer the question "What would
the answer be? And how many?”.
the recommendation’s described algorithm is not the only possible answer.
the alternative interpretation, in terms of joins, provides a clear answer.
>
> If the route is required, there are sometimes multiple routes. DAGs - which
> occur in e.g. RDFS quite naturally.
>
> The common user request is path length or minimum path length, more common
> than ?p* effects.
>
>> when implemented in terms of the known approach with joins, the questions
>> would be if a given initial solution fixes successive joins to just that
>> respective predicate binding or if the successive joins are over the full
>> matched set of predicates and, in the first case, whether they are distinct
>> or enumerated.
>
> What about the more general path?
>
> (?p1/<property>/?p2)*
>
> (?p1*/?p2*)
as i understand the join-based implementation, it covers those as well.
>
> This seems to be a complex requirement with no natural single definition.
> Certain special cases look like they some natural definitions but each has to
> considered separately and specially called out.
>
---
james anderson | ja...@dydra.com | http://dydra.com
