From: Andy Seaborne <andy.seaborne@epimorphics.com>

Date: Fri, 20 May 2011 13:22:18 +0100

Message-ID: <4DD65CFA.8020505@epimorphics.com>

To: Sebastián Conca <sconca87@gmail.com>

CC: public-rdf-dawg-comments@w3.org

Date: Fri, 20 May 2011 13:22:18 +0100

Message-ID: <4DD65CFA.8020505@epimorphics.com>

To: Sebastián Conca <sconca87@gmail.com>

CC: public-rdf-dawg-comments@w3.org

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

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 20:52:11 UTC
*