- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Tue, 12 Jul 2011 11:29:10 -0400
- To: Sebastián Conca <sconca87@gmail.com>
- CC: Andy Seaborne <andy.seaborne@epimorphics.com>, public-rdf-dawg-comments@w3.org
Hi Sebastian,
At this point, the Working Group has considered your preferred design
and has decided to stay with the existing design. The main reasons for
this are documented in the messages earlier in the thread, particularly:
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011May/0034.html
and
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011Jun/0011.html
As a W3C Working Group, we are obligated to formally address every
comment we receive. Per the W3C process, given that the group has not
decided to adopt your suggested change, you have two options:
1) Acknowledge that the group has responded to your comment, even though
no change has been made
2) Formally object to the advancement of the specification
You can read more about formal objections here:
http://www.w3.org/2005/10/Process-20051014/tr#doc-reviews
...but basically, a Formal Objection means that you believe that the
current design is flawed to such an extent that the document should not
advance further within the W3C Recommendation track without being fixed.
When the Working Group attempts to advance the document further in the
process, the W3C Director considers any/all formal objections and
decides whether or not to advance the document or ask the WG to further
consider the issue.
Can you please either acknowledge that your comment has been responded
to or let us know that you'd like to formally object to the Working
Group's decision on this issue?
many thanks,
Lee
On behalf of the SPARQL Working Group
PS As with all Working Group decisions, if you or anyone else has new
information that pertains to this issue that has not previously been
discussed, the Chairs may decide to re-open the discussion.
On 7/5/2011 12:01 PM, Sebastián Conca wrote:
> Dear Andy,
>
> I read the discussion about my last email on the
> public-rdf-dawg@w3.org <mailto:public-rdf-dawg@w3.org> mailing list, and
> I discovered that you said
> that in my messages there weren't any proposal. I am sorry about this,
> I didn't realize that the group was expecting a proposal from me. I
> think that the current design of property paths can be improved, and I
> was only looking for some motivation or use cases that support the
> current semantics of property paths proposed by the group, so I am
> sorry for my critical attitude.
>
> If you want to know my opinion, I think that the best way to solve
> this problem is by using an "existential" semantic, that is, a query
> like ?x p ?y, where p is a property path, should return the pairs
> (a,b) of resources such that there exists a path from a to b whose
> labels are in the regular language accepted by p. In the previous
> emails, you told me that this is the same that using the DISCTINT
> operator, but the difference is in the complexity, because counting
> the number of paths between two nodes is very hard. I think that if
> counting is an important feature, then the language could include an
> operator to explicitly say that one wants to counts the number of
> paths from a to b that conforms to a particular regular expression
> (something like ?x COUNT(p) ?y, where p is a property path). But my
> guess is that most of the time (if not all the time), people would
> only want to use the faster existential semantic, instead of counting
> the number of paths (as it is done in XPath, XQuery and many graph
> query languages).
>
> With best regards,
>
> Sebastián Conca
>
> El 21 de junio de 2011 11:32, Andy Seaborne
> <andy.seaborne@epimorphics.com <mailto:andy.seaborne@epimorphics.com>>
> escribió:
>
> > 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/
> <http://www.w3.org/TR/rdf-dawg-uc/>
> SPARQL New Features and Rationale:
> http://www.w3.org/TR/sparql-__features/
> <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>
> <mailto: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>>
> <mailto: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
> <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, 12 July 2011 15:29:44 UTC