Re: Draft response for CommentResponse:JP-2

Some small suggestions:

1)
"Repetition of literals is significant, consider SUM applied to a purchase order where two items have the same price, so multiple paths to the same endpoint do matter."
[...]
"SPARQL has the keyword DISTINCT so an application can choose between duplicates and no duplicates. A query engine can exploit this if it chooses to; use with sub-queries mean that solution modifiers can be applied to specific parts of the query such as a path."

-->

"Repetition of literals is significant, consider SUM applied to a purchase order where two items have the same price, so - depending on the use case - multiple paths to the same endpoint do matter. That is, the group did not want to restrict to one use case, where only distinct paths are returned. Anyways, SPARQL has the keyword DISTINCT so an application can choose between duplicates and no duplicates. A query engine can exploit this if it chooses to; use with sub-queries mean that solution modifiers can be applied to specific parts of the query such as a path."

 2)

"SPARQL property paths do not apply uniqueness to property paths and the property path expression is, where appropriate, the same the expansion in terms of triple patterns. It is not a matter of efficiency because the answers concerning duplicate literal values would be rather unexpected if only distinct values were returned."

-->

"SPARQL property paths do not apply uniqueness to property paths and the property path expression is, where appropriate, the same the expansion in terms of triple patterns. It is not a matter of efficiency only because - again, depending on the use case - the answers concerning duplicate literal values would be rather unexpected if only distinct values were returned."


3) 
"An implementation is free to implement evaluation in anyway it chooses proved it results in the same answers, the WG felt that using an algorithm was the most helpful way to specify the feature, especially to implementers."
-->
"Although of course, an implementation is free to implement evaluation in anyway it chooses proved it results in the same answers. The WG felt that using an algorithm was the most helpful way to specify the feature, especially to implementers."

4) 
Additionally, I would suggest that we could add a remark in this regard as follows in the working draft, after the "Definition: Evaluation of ArbitraryLengthPath":

"Note that the matching algorithm given here mainly serves to specify the feature. An implementation is free to implement evaluation in anyway it chooses proved it results in the same answers, particularly for path expressions in combination with DISTINCT (sub-)queries there might be more efficient algorithms." 


that would be all from my side, if you're ok with these changes, I can go ahead and put them on the wiki.

Axel


On 27 Dec 2010, at 19:16, Andy Seaborne wrote:

> Draft ready:
> 
> http://www.w3.org/2009/sparql/wiki/CommentResponse:JP-2
> 
>         Andy
> 
>

Received on Thursday, 20 January 2011 09:27:53 UTC