CommentResponse:JP-1

Status: Response sent.

Jorge,

Thank very much for your comments.

The working group considered a number of factors in designing the property path features. In addition to the points you raise, the WG also included consideration that, while this working group is not adding a path datatype (needed to enquire about any path matched later in the query), nor the specific case of access to path length, the WG should leave open as many possibilities here for future work. Another factor in the design is the relationship of some property path expressions to triple pattern forms.

Although not specifying returning the path length of a match, nor specifying returning the matched path itself, the WG felt that, on balance, the design in the working draft gave maximum scope for any later standardization work. The issue of path length particularly was considered as a feature for this round of work but, when considered against all the other work items the WG has taken on, it didn't make the final list of work items. This lead to the conclusion that counting path possibilities, not a "there exists" condition, was the better choice for this round of standardization. Adding access the the path matched is better served if all paths are considered.

Another consideration was the relationship of property paths and existing queries using triple patterns.

{ ?x :p{2} ?y }

and

{ ?x :p ?Z . ?Z :p ?y }, with ?Z projected away.

The WG decided to make these equivalent, including in terms of numbers of solutions. This gives the semantics of many path forms in terms of SPARQL graph pattern operators. This was felt to be intuitive and to utilize the capabilities of query engines: rather that requiring yet another mechanism, the equivalence means that join-technology (for example) can be used to solve the pattern.

This then leaves the issue of cycles in the "+" operator. The design is one in which the cycles in "+" operator are handled by traversing a directed edge (triple in the data) once. This will be explained in the final version of the query specification - there is a placeholder for it in the current editors working draft. The current working draft has been clarified to use "multiset-union" for the union in the ArbitraryLengthPath definition.

This overall design is a tradeoff of implementation, future possibilities, and equivalence of patterns on graphs. The WG is aware that there can be corner cases can arise where different intuitions are not compatible. On balance, the WG feels that the current design is most suitable for this round of standardization.

Again, that you for your helpful comments.

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

Andy
on behalf of the SPARQL Working Group.