Re: Review of Property Path Sections in Query Doc

Ah - I'll change it to vy, which is probably what it was meant to be.

 Andy

On 28/02/11 13:05, Matthew Perry wrote:
> Hi Andy,
>
> Thanks for the explanation.
>
> Ok. I see how loops back to the starting point are included now.
>
> About the (term, path, term) definition. After looking at it again, I understand. The set terminology is fine, my confusion came from using "y" as both a variable and a constant term in the same definition. I think it would be clearer if a different letter was used for the variable.
>
> - Matt
>
>
> ----- Original Message -----
> From: andy.seaborne@epimorphics.com
> To: matthew.perry@oracle.com
> Cc: public-rdf-dawg@w3.org
> Sent: Monday, February 28, 2011 6:23:38 AM GMT -05:00 US/Canada Eastern
> Subject: Re: Review of Property Path Sections in Query Doc
>
>
>
> On 21/02/11 19:41, Matthew Perry wrote:
>> Hi Andy,
>>
>> I went through the property path sections of the query doc. Overall, the
>> textual descriptions of each property path operator sound good. Some
>> more detailed comments are below.
>>
>> Section 9.3
>>
>> Evaluation of [a property path expressions =>  property path expressions]
>> can lead to duplicates in the results.
>>
>> Where the query matches on arbitrary length paths, each cycle is
>> considered at most once by stopping if [a triple =>  an RDF term] in the
>> data would be a matched again in the evaluation of the + property path
>> operator.
>
> Done thanks.
>
>>
>> Section 18.4
>>
>> The arbitrary length path operators are described in Section 18.4 as
>> allowing the start node of a path to also be the end node of the path
>> (i.e. a cycle back to the starting point is allowed). From my
>> understanding of the evaluation semantics in Section 18.5, the ALP
>> Function will not allow this loop back to the starting point because the
>> starting node is added to V in the first step, so ALP will return
>> without adding the starting point when it is encountered at the end of a
>> loop.
>
> For the case of "*" (ZeroOrMorePath), the initial point is added
> immediately in the first call of ALP because V = empty set.
>
> For the case of "+" (OneOrMorePath), one step of ALP is done with no
> adding of the node to the vertex set, and so if it loops back, it's in
> once only.
>
> A loop back to the starting point is allowed (i.e. matched) because ALP
> only follows possibilities.  It does not backtrack on negative
> possibilities although the underlying path might.
>
> ZeroOrMorePath(:x, :p, :x) =>
>     ZeroOrMore(:x, path, var) =>
>     ALP(:x, path) =>
>     ALP(:x, path, {}, {}) =>
>       includes :x immediately.
>
> OneOrMorePath(:x, :p, :x) =>
>     OneOrMorePath(:x, path, var) =>
>       Do path once to get X = :n1, :n2, etc.
>       ALP(:n1, path) =>
>       ALP(:n2, path, {}, {}) =>
>         includes :n2 if loops back.
>
>> I don't understand the (term, path, term) definitions:
>> { { } } if (v,y:var) in eval(D(G), ZeroOrMore(x, path, y); card[{ }] = 1
>
> Multisets are defined as a set of elements and a cardinality of the
> elements.
>
> { { } } is a set of one element, which is itself the empty set of
> bindings (no columns).   Nothing to do with SPARQL patterns.
>
> The result of "SELECT * {}" - the two uses of "{}" for SPARQL patterns
> and sets/mulitsets does make this confusing.  I hope they are never
> mixed in the same expression.  If there is a way to make this clearer,
> please suggest it.
>
>
>> Thanks,
>> Matt
>
>  Andy
>
>

Received on Monday, 28 February 2011 13:19:50 UTC