Re: Review of Property Path Sections in Query Doc

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

{ { } } 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


Received on Monday, 28 February 2011 13:07:43 UTC