property paths review

This is my review of in 
discharge of action-169.

Overall, I support publication of th document as-is as First Public 
Working Draft.


* "The N3 path syntax" is a fragment, and it's unclear whether this is a 
suggestion as a possible alternative, or something else.

* The second issue, about the order of RDF lists, is conflated with the 
issue of access to path lengths. It might be helpful if this were made a 
bit clearer:

* While property paths as currently specified can be used to access RDF 
lists (e.g. rdf:rest*/rdf:first), the Working Group notes that this 
would be more useful if results were returned in the order they occur in 
the RDF list. This presents significant complexity in the context of the 
existing SPARQL algebra.

* The WG has discussed providing access to the length of matched paths, 
which would provide greater functionality but would complicate path 
evaluation. At this time, the WG's primary aim is to specify a core set 
of functionality while not blocking future enhancements.

(FWIW, I do not think we should tackle either the order question or the 
path length question at this time, though I realize this leaves the RDF 
list situation somewhat unsatisfactory.)

* In Section 3, what is "elt"? I'd expect that to be "path" instead, but 
maybe I'm misunderstanding?

* I support ^ as purely a unary operator, but do not feel strongly about it.

* The Path Terminology section introduces two terms (simple and complex 
paths), and the rest of the section reads like design notes. I'm not 
sure how much it adds to the document. I suspect it might be better to 
remove it and just let the introduction, the examples, and the formal 
algebra speak for itself.

* "strict SPARQL query" -> "SPARQL 1.0 query" ?

* I don't think the "Filtering duplicates" example adds much to the 
elucidation of property paths.

* 5.2 should be split into individual examples.

* I don't recall the most recent discussions around cardinality. 
Currently, the draft says that we only ever get one path between 2 nodes 
in the graph. This seems to conflict with the basic behavior we have in 
SPARQL for "?s ?p ?o", but maybe that's OK and necessary to make 
property path evaluation tractable?


Received on Wednesday, 6 January 2010 09:03:44 UTC