Re: Draft response for CommentResponse:JP-2

On 20/01/11 09:26, Axel Polleres wrote:
> 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."
>

I don't think that adds anything because discussion is framed by SUM 
which is a use case.  The comment asserts that unique results are the 
right answer so we need only show one reasonable other case.  The reply 
points out that DISTINCT can be used to go from multiple to unique if 
required.  The only thing remaining would be to emphasis that the 
implementation can chnage strategy based on DISTINCT but I took that as 
obvious.

(This would all be more interesting is RDF had adopted untidy literals 
but then the whole of SPARQL 1.0 BGP matching would be rather weird.)

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

The issues of use case is as (1) and the comment has already mentioned 
DISTINCT.

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

I don't see the rewrite adds anything.  It's just writing style.


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

Good idea - the following added to rq25.

[[
Note that the  algorithm given here serves to specify
the feature. An implementation is free to implement
evaluation by any method that produces the same results
for the query overall.
]]


	Andy

>
> 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 22:18:23 UTC