Re: Property Paths drafting

Greg,

Many thanks for the review -- processed as below:

 Andy

On 04/05/12 21:03, Gregory Williams wrote:
> 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 """
>
Removed.
(fairly sure I've removed them before as well - spooky)

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

This one does not generate duplicates.

To the general point of whether 9.2 examples should systematicallysay 
"duplicates" or not, I'm inclined to leave as is because the answers are 
not given.  Duplicates get discussed next.  I think some reordering 
would be needed to put discussion first then examples.  Happy to do that 
if the feedback is it would make it better but I'm OK with examples as 
illustrating, not too much detail and then more detailed description. 
I'd rather not have to come up with data and answers for each example.

Are any particularly confusing?  May be rewording the example is a 
better approach.

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

Yes, elt? is a bit weird and really there for completeness -- think a 
sort of difference of  elt* and elt+.

If anyone has an example, I'm happy to add it.

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

Done.

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

Added rdf: -- whole queries are suppose to be complete.

>> 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*"?

Done.

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

Fixed. Removed endpoints - old stuff and faailure to fix up when I went 
from algebra operators to one operator "Path(...)" and path expressions. 
The whole process has been put on a more sound and complete basis.

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

Added to notes.

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

yes - fixed.

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

Done.

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

Done.

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

Yes - added text to this effect:

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

Previous fix.  It's ZeroOrMorePath(path)

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

All correct.

Fixes applied.


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

Done.

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

Done.

> "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(?).

Removed.

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

Done.

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

Done

>
> 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)"?

Yes - added.

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

"based *on* distinct nodes"

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

Either - "otherwise" looks better - changes (2) made.

Received on Thursday, 10 May 2012 14:17:46 UTC