Re: Comments about the semantics of property paths

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

Received on Thursday, 2 December 2010 11:21:23 UTC