Re: Property paths

On 19/06/12 20:45, Paul Gearon wrote:
> Apologies that this hasn't come through before now...

And apologies for not responding - I saw the *fixed* and

>
> This review is restricted to section 9 of the query document, and the
> property path sections of the algebra.
>
> 9.1 Property Path Syntax
>
> Is the description of "zero or more occurrences" and "one or more
> occurrences" clear enough to a user who is unfamiliar with the
> concept. We understand that a path involves walking from one node to
> another using connecting predicates, and the "occurrences" refers to
> how many steps are taken, but will that always be understood? If not,
> then perhaps it could be mentioned in 9.4.

Good point but this is in table of definitions/explanations so I'm less 
worried about it.

What about "matches" as in " zero or more matches" given the table 
column is "Matches"? (This change made)

> 9.2 Examples
>
> "Inverse Path Sequence"
>
> This is fine, but given the prior examples with equivalent queries
> then I'd have expected a similar example here, something like:
>
> {
>      ?x foaf:knows ?k .
>      ?y foaf:knows ?k .
>      FILTER(?x != ?y)
> }

Done.

> 9.3 Property Paths and Equivalent Patterns
>
> All good.
>
>
> 9.4 Arbitrary Length Path Matching
>
> As I said earlier, an understanding of "zero or more" and "one or
> more" property paths is presumed. Given the level of understanding of
> some of the audience, this may be worthwhile explaining. If there is
> agreement with me, then a simple explanatory sentence might be:
>
> "The length of a property path is the number of steps taken to
> traverse a graph from one node to another using a given set of
> properties, where a step from one node to another is described by a
> triple in the graph with the two nodes as subject and object, and
> having one of the desired predicates."
>
> ... or words to that effect.

Good idea to expand the text - it's more than just repeated use of a 
predicate.  I don't want to define "length" e.g. (:p/:q?)*

Change made:

[[
Each of these operators uses the property path expression
to take steps between subject and object. The number of steps taken
depends on the operator.
]]

Other suggestions welcome - this is not meant to be definitional, it's a 
loose explanation for the new reader.

> Algebra
>
> This first one was posted to Andy offline and fixed, but I'll mention
> it here so that it's documented.
>
> The definition for "Evaluation of ZeroOrOnePath" was incorrect. The
> first part of the definition previously read:
>
>    eval(Path(X:term, ZeroOrOnePath(P), Y:var)) = { (Y, yn) | yn = X or
> (yn,X) in eval(Path(X,P,Y)) }
>    eval(Path(X:var, ZeroOrOnePath(P), Y:term)) = { (X, xn) | xn = Y or
> (xn,Y) in eval(Path(X,P,Y)) }
>
> It now correctly reads:
>
>    eval(Path(X:term, ZeroOrOnePath(P), Y:var)) = { (Y, yn) | yn = X or
> {(Y, yn)} in eval(Path(X,P,Y)) }
>    eval(Path(X:var, ZeroOrOnePath(P), Y:term)) = { (X, xn) | xn = Y or
> {(X, xn)} in eval(Path(X,P,Y)) }
>
> *fixed*

Yes - fixed

> Definition: Function ALP
>
>    "Let eval(x:term, path) be the evaluation of 'path', returning a
> multiset of RDF terms reached by path."
>
> This does not describe the element "x:term". Suggest adding the following:
>
>    "Let eval(x:term, path) be the evaluation of 'path' starting at the
> term x, returning a multiset of RDF terms reached by path."

[[
Let eval(x:term, path) be the evaluation of 'path', starting at RDF term 
x, and returning a multiset of RDF terms reached
by repeated matches of path.
]]

>
>
> Regards,
> Paul Gearon
>

	Thanks
	Andy

Received on Wednesday, 11 July 2012 10:26:14 UTC