- From: W Martens <martens.wim@gmail.com>
- Date: Fri, 20 Apr 2012 14:35:19 +0200
- To: public-rdf-dawg-comments@w3.org
Dear Lee, first of all, we would like to thank the entire WG for taking our comments into consideration seriously. The answer that you posted mainly seems to be aimed towards dealing with the counting versus non-counting issue of operators in property paths and largely seems to follow the following proposal by Andy Seaborne on public-rdf-dawg: - http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0285.html (part one) - http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0286.html (part two) Recall that we had a two-part comment, in which one part was addressed towards "simple paths" versus "regular path" semantics and the other part was addressed towards counting paths in the result of property path evaluation. Regarding the simple paths versus regular path semantics: -------------------------------------------------------------- It seems that in Andy Seaborne's proposal (above), the simple path issue was resolved; the informal description of ZeroOrMorePath in (http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0286.html) states ZeroOrMorePath: "An arbitrary length path P = (X (path)* Y) is all solutions from X to Y by repeated use of path. It collects the set of nodes visited by repeated applying path." In this form, property paths would now be allowed to visit a node multiple times, which would indeed resolve the computational complexity issues we raised in our discussion about "simple path" versus "regular path" semantics. However, from the your reply it is not clear to us whether the WG is actually going to follow "Option 6" as described by Andy Seaborne in this respect or not. (Maybe we missed it somewhere...) If the WG would follow it, we would consider the issue on simple paths to be resolved. Regarding counting versus not counting ------------------------------------------------------- It seems to us that, in the current WG's response, several issues regarding the complexity of counting paths will indeed be resolved. Indeed; several of the complexity hardness proofs of our paper will not apply anymore to the definition of SPARQL property paths if SPARQL property paths would be updated accordingly. However, we are not certain what to think about the user-friendliness and elegance of the new approach. What we mean is that it may be confusing for users if several operators have a "counting paths" semantics, whereas other operators do not have a "counting paths" semantics. We feel that this is a point that can still be improved and we do hope that we can still make suggestions to the WG in the future in order to further improve the language. A remark about {n,m}, {,n}, etc. ----------------------------------------- We find it a pity that the (variations of the) operator {n,m} is likely to be removed from property paths, because we showed in our PODS 2012 paper that these operators can, in fact, be evaluated efficiently. To Conclude ------------- We are very grateful to the WG for taking our comments very seriously. If the above mentioned definition of ZeroOrMorePath is adopted, we consider the "simple path" issue to be resolved. The WG's answer on counting paths solves complexity issues at least partly; but we feel that an even better solution may be possible. We will continue working on this topic and we are open to continue the discussion with the group and, if necessary, cooperate with the group towards a proposal for property paths that will optimize all the aspects you mentioned below: Use case expressivity, Users' learning curve / intuition, Ease of implementation, Potential for efficient evaluation, and, hopefully, Schedule. Best regards, Wim Martens Katja Losemann
Received on Friday, 20 April 2012 12:36:40 UTC