Re: Comments about property paths

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