Re: Additional comments on the semantics of property paths

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