Re: Property Paths drafting

In general, this looks really good. The only major issue I found was inconsistent treatment of the translation process for ZeroOrMorePath. Details below.

I've also updated the property path test cases to align (I hope) with the current path semantics. I changed expected results for tests using + and * (changing their approval status back to "unclassified"), and removed tests that use the {n,m} syntax from the manifest.

.greg



On May 4, 2012, at 8:49 AM, Andy Seaborne wrote:

> Currently, all the material is in place in the editors' working draft.
> At this point, I thinks it's ready for review.
> 
> 
> Section: 9 Property Paths
> This is the descriptive text for property paths
> http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#propertypaths

At the end of section 9.1, I'm not sure why the three path expression names are listed:

"""
ZeroOrMorePath

OneOrMorePath

ZeroOrOnePath
"""



In 9.2, I wonder if this example should mention that you may get duplicates (I've been comfortable not mentioning it in all the examples until this point):

"""
Negated Property Paths: Find nodes connected but not by rdf:type (either way round):

  { ?x !(rdf:type|^rdf:type) ?y }
"""


Section 9.2 obviously needn't be exhaustive, but it doesn't give any examples of "elt?". Realistic use cases using just ? might be weird, but should we try to come up with one?


In 9.3, remove 'the' in: "Some the property paths..."


In 9.4, the first example query defines the rdfs prefix, but not rdf. Since both are defined in section 1.2.1 Namespaces, I'd think either the rdfs definition could be dropped, or an rdf definition could be added.


> The translation to the algebra has two parts:
> Section: 18.2.2.2 Translate Property Path Expressions
> Convert abstract syntax to an algebra form.
> 
> http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#sparqlTranslatePathExpressions

"The next after this one…"; Should this be "next *step*"?

In the table showing the equivalence between syntax and algebra, some rows have the syntax include the path end nodes/variables (X and Y) while others don't. The rows that do include X and Y don't ever use them in the algebraic equivalent, so I'm not sure why they're necessary. However, the row for "path*" doesn't include X and Y in the syntax form, but uses them in the algebra form. Given that the algebra form uses the path endpoints, I'm not sure what 18.2.2.2 would have me do when trying to translate a path that includes a * operator inside another path operator.

> Section: 18.2.2.3 Translate Property Path Patterns
> Translate some forms to triple patterns and put a top level "path" oeprator into the algebra. (the only forms flattened here are the ones needed to create basic graphs patterns anad hence form with entailment)
> 
> http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#sparqlTranslatePathPatterns

The algebra->translation table here introduces fresh variables in the "X seq(P, Q) Y" case, but the fact that the variable (?V) needs to be fresh isn't explicitly mentioned (though it is mentioned in the immediately following example using the similarly named ?_V variable).

In the "X seq(P,Q) Y --> X P ?V .. ?V Q P" row, is the double-dot meant to be a single dot (simply indicating adjacent algebra patterns)?

I found the default-case "X P Y" row of the table to be a bit confusing, as "P" isn't defined anywhere (like the preceding notes define what "X" and "Y" are). Could the notes include a bullet making explicit that P and Q are path expressions?

"path()" should be capitalized in "The final translation simply wraps any remaining property path expression to use a common form path(…)."

In the examples, I assume we're seeing the translation effects of *both* sections 18.2.2.2 *and* 18.2.2.3? (From what looks like sparql syntax to algebra patterns?

I'm confused by the example for "?s :p* ?o".  It shows the resulting algebra as "Path(?s, ZeroOrMorePath(link(:p)), ?o)". But 18.2.2.2 indicates that the ZeroOrMorePath algebra takes the form "ZeroOrMorePath(X, path, Y)" (with the endpoints included). How do the endpoints get lifted out of the ZeroOrMorePath() and into the Path() algebra?

The final example for ":list rdf:rest*/rdf:first ?member" doesn't seem to be recursively applying the translation steps. Modulo my questions about how the arguments to ZeroOrMorePath work, I would have expected the resulting algebra to be something like:

"""
Path(:list, ZeroOrMorePath(link(rdf:rest)), ?_V) .
?_V rdf:first ?member
"""

(note also that the dot used to visually separate algebra patterns in the last example appears after the wrong pattern).


> And then there's evaluation; now every path form is defined fro evaluation because translation does not deal with one form inside another (this was a weakness of the previous specs).
> 
> Section 18.4 Property Path Patterns
> http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#PropertyPathPatterns

Typo: "All remaining property path ***expressi*** are present in the algebra in the form Path(X, path, Y) for endpoints X and Y."

Typo: "This *** a multiset of solution mappings μ,…" Maybe 'this produces a multi set…'?


"The IRI may also be the keyword a, for rdf:type." This seems a bit of a tangent, as presumably 'a' has been expanded to a full IRI in the algebra translation process(?).

In "Definition: Evaluation of Sequence Property Path", "join(…)" should be capitalized "Join(…)", and "project(…)" should be "Project(…)".

In "Definition: Evaluation of Alternative Property Path", "union(…)" should be capitalized.

In "Definition: Evaluation of ZeroOrOnePath", s/ ZeroOrOne(P) / ZeroOrOnePath(P) /

"eval(Path(X:var, ZeroOrOne(P), Y:var)) = 
    { (Y, yn) (X, xn) | either (yn in nodes(G) and xn in nodes(G)) or (vx,vy) in eval(Path(X,P,Y)) }"
For the first clause here, shouldn't it also test for equality? That is, "(yn in nodes(G) and xn = yn)"?

Is there a word missing in: "… return matches based distinct nodes connected by the path."?


"""
eval(Path(x:term, ZeroOrMorePath(path), y:term)) = 
    { { } } if { (vy:var,y) } in eval(Path(x, ZeroOrMorePath(path) vy)
    { } if y not in ALP(x, path)
"""
Why isn't the second conditional "if y not in ALP(x, path)" not simply "otherwise"? Similarly for the definition of OneOrMorePath.

Received on Friday, 4 May 2012 20:04:25 UTC