From SPARQL Working Group
Jump to: navigation, search

Status: Draft in progress

Response to


Thank you for your comments on the first working draft of the property paths feature

> (This is not intended as a formal comment, and can be excluded from W3C 
> process requirements)

and thank you for making that clear. The property path material has been incorporated into the main query specification.

There are also a number of changes that relate to your comments.

> then the path [ eg:p {3, 7 } ] links eg:a with both eg:a and eg:b

The definition of :property{N,M} (fixed integers for N and M) has been clarified as being the union of the possibilities  :property{N}, :property{N+1}, ... :property{M} and is the same as the full expression had been written out in SPARQL. This includes the possibilities of duplicates.

The only new operations in the SPARQL algebra relate to the forms :property{0} and :property+ and negated property sets. All property paths expressions are translated to existing SPARQL forms or the use of the operations to support these cases.

> Practically I wonder if it may be more useful to prohibit cycles, i.e. 
> property paths are simple paths in the graph theoretic sense (using 
> terminology from Wikipedia [1]), i.e. do not contain the same node 
> twice. In this case the only path in [ eg:p {1,} ] is one from eg:a to 
> eg:b. (the zero length path from eg:a to itself is still there in [ eg:p 
> {0, } ] .. in fact I would be inclined to require n >0, or at least if 
> n=0 then at least one end of the path should be anchored (do we really 
> want ?v eg:p {0} _ to select all the nodes in the graph - this concept 
> is not even well-defined in RDF, would an implementation be incorrect to 
> return a node that did not occur in any triple in the graph?)

The cycle handling for arbitrary length paths has changed to be based on never traversing the same triple (arc) twice in :property+. rather than being node based.

> The practical value of requiring simple paths is to do with cyclic 

We would be grateful if you would acknowledge that your comment has been answered by sending a reply to this mailing list.

on behalf of the SPARQL working group