Re: Comments about property paths

 > I still don't understand why the
 > semantic of property paths is defined allowing different results for
 > equivalent regular expressions.

Sebastián,

In the previous reply, we pointed out that equivalences you describe are 
not part of the property path specification. The working group has 
reviewed your comments and has decided that the design in the published 
documents is the most appropriate design.

That design of property paths is a balance and needs to integrate in 
with the overall evaluation of a SPARQL query. I would stress that it is 
a balance - there are competing design dimensions that need to be 
resolved, in particular, fitting in with expectations driven by reading 
a property path expression as a short form of paths that can be written 
out in full without property paths. The working group feels that the 
expansion approach reduces implementation burden, exploiting 
implementation techniques used in SPARQL 1.0, and provides convenient 
shorter forms for BGPs that could be written out in full.

 > But I couldn't find any use case that motivates the semantics of
 > "Property Paths" proposed in the SPARQL 1.1 draft document. In fact,
 > in the second document there are only 3 simple examples that justify
 > neither the need to define the semantics of "Property Paths" as it is
 > done in the SPARQL 1.1 draft document, nor the need to have repeated
 > mappings on the query result. Is there another document where I can
 > find more detailed examples or use cases?

The "SPARQL New Features and Rationale" document is not a complete 
design for property paths; that is not the purpose of the document. The 
working group created the design through discussions within the working 
group as well as experience from existing systems. This is documented in 
the email archive for the working group, including discussions on test 
cases, especially around the operators for * and +.

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 working group.

On 06/06/11 22:16, Sebastián Conca wrote:
> Dear Andy,
>
> Thank you again for your reply. I still don't understand why the
> semantic of property paths is defined allowing different results for
> equivalent regular expressions. I have been trying to understand for
> which applications this semantic is needed. So, I looked for the
> SPARQL 1.1 use cases, and I found the following documents:
>
> RDF Data Access Use Cases and Requirements:
> http://www.w3.org/TR/rdf-dawg-uc/
> SPARQL New Features and Rationale: http://www.w3.org/TR/sparql-features/
>
> But I couldn't find any use case that motivates the semantics of
> "Property Paths" proposed in the SPARQL 1.1 draft document. In fact,
> in the second document there are only 3 simple examples that justify
> neither the need to define the semantics of "Property Paths" as it is
> done in the SPARQL 1.1 draft document, nor the need to have repeated
> mappings on the query result. Is there another document where I can
> find more detailed examples or use cases? Thank you very much.
>
> With best regards,
> Sebastián Conca
>
>
>
> El 20 de mayo de 2011 08:22, Andy Seaborne
> <andy.seaborne@epimorphics.com <mailto:andy.seaborne@epimorphics.com>>
> escribió:
>
>     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>
>         <mailto: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 Tuesday, 21 June 2011 15:33:25 UTC