Re: Comments about property paths

Sebastián,

The design of property paths is a balance and needs to integrate in with 
the overall evaluation of a SPARQL query. The equivalences you describe 
are not part of the property path specification.

Consider even a simple pattern like:

{ ?x :p/:q ?y }

The working group has decide to make that equivalent to

  SELECT ?x ?y { ?x :p ?V . ?V :q ?y }

that is, projecting ?V away but not requiring distinct results.

So to take one of your examples:

SELECT * WHERE { :a (:p*)/(:p*) ?x }

SELECT ?x WHERE { :a (:p*) ?V .
                   ?V (:p*) ?x }

and the multiple cardinality of the overall query because each :p* stops 
following cycles but the second one is acting on all possible starting 
points.

The operations for path*, path{0} and path+ provide algebra operations 
and these can be combined using "/" and other path operators. There is 
no overall per-path expression condition on cardinality, instead the 
combination of operations leads to the cardinality.

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-WG

On 07/04/11 19:42, Sebastián Conca wrote:
> Dear Andy,
>
> First, I am sorry for the long delay in answering your email.
>
> Thank you very much for your reply. I read the Editor's Draft document
> that you mentioned, and I still have some concerns about the definition
> of the semantics of property paths; despite the fact that some of the
> counterintuitive results described in my previous mail were solved with
> the new definition of this semantics, there are still queries containing
> equivalent regular expressions that return different answers, as shown
> below. This time, the examples were not tested in ARQ, because the last
> version of ARQ is working with the semantics described on the Working
> Draft document, so I apologize if there are incorrect results in some of
> the examples (to the best of my understanding they are correct).
>
> Consider the graph G:
>
> :a :p :b
> :b :p :c
> :c :p :a
>
> and the following query Q1:
>
> SELECT * WHERE { :a (:p*) ?x }
>
> The result of applying Q1 over G is:
>
> ?x= :a, :b, :c
>
> Now consider the query Q2:
>
> SELECT * WHERE { :a (:p?)/(:p*) ?x }
>
> The result of applying Q2 over G is:
>
> ?x= :a, :b, :c, :b, :c, :a
>
> Clearly the path properties used in the above queries are equivalent
> (regular expressions). Notice that the operator * is not nested in the
> regular expressions in Q1 and Q2.
>
> Now consider the following query Q3, containing a regular expression
> that is equivalent to the expressions in the previous examples:
>
> SELECT * WHERE { :a (:p*)/(:p*) ?x }
>
> Now, the result of Q3 over G is:
>
> ?x = :a, :b, :c, :b, :c, :a, :c, :a, :b.
>
> I don't know how the user could interpret the above results.
>
> I would really appreciate it if you could tell me your opinion about
> these examples.
>
>
> Thank you very much.
> With best regards,
> Sebastián Conca
>
> El 25 de marzo de 2011 09:07, Andy Seaborne
> <andy.seaborne@epimorphics.com <mailto:andy.seaborne@epimorphics.com>>
> escribió:
>
>     Sebastián,
>
>     The details of the property path expressions is something the WG has
>     been working on recently and there are changes in the specification
>     since the last published working draft in response to comments from
>     the community and from discussions with the working group. You can
>     see the changes in the editors' draft at
>     http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml.
>
>     The path evaluation has changed recently to make it in-line with the
>     decisions of the SPARQL-WG as the WG works through the exact
>     specification of property paths.
>
>     For both queries:
>
>
>     SELECT * WHERE { :a (:p+) ?x }
>     SELECT * WHERE { :a :p/(:p*) ?x }
>
>     the results would be:
>
>     ------
>     | x  |
>     ======
>     | :b |
>     | :c |
>     | :a |
>     ------
>
>     The expression (:p+)+ is not equivalent in terms of cardinality of
>     the elements although it should return the same elements. SELECT
>     DISTINCT may be useful.
>
>     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-WG
>
>
>     On 18/03/11 20:04, Sebastián Conca wrote:
>
>         Dear All,
>
>         I have been trying some examples of SPARQL 1.1 property paths, and I
>         have gotten some results that seem to be counterintuitive. For
>         instance, consider a graph G:
>
>         :a :p :b
>         :b :p :c
>         :c :p :a
>
>         and the following query Q1:
>
>         SELECT * WHERE { :a (:p+) ?x }
>
>         According to the semantics proposed in the Working Draft
>         document, the
>         result of the query Q1 over G is:
>
>         ?x = :b, :c, :a
>
>         Now, consider a query Q2:
>
>         SELECT * WHERE { :a :p/(:p*) ?x }
>
>         According to the semantics proposed in the Working Draft
>         document, the
>         result of the query Q2 over G is:
>
>         ?x = :b, :c, :a, :b
>
>         I tested both queries in ARQ, getting the same results shown above.
>         The paths used in the queries are equivalent regular expressions
>         (the
>         regular languages represented by (:p+) and :p/(:p*) are the
>         same), so
>         the results of these queries over G should be the same. Am I missing
>         something?
>
>         I also executed in ARQ a third query Q3 containing a regular
>         expression that is equivalent to (:p+) and :p/(:p*):
>
>         SELECT * WHERE { :a (:p+)+ ?x }
>
>         But this time I got the result:
>
>         ?x = :b, :c, :a, :b, :c, :a, :b, :c, :a, :b, :c, :a, :b, :c, :a
>
>         What should be the interpretation of this result? I would really
>         appreciate it if you could let me know whether I am missing
>         something.
>         Thank you very much.
>
>         With best regards,
>
>         Sebastián Conca
>
>

Received on Friday, 20 May 2011 12:22:50 UTC