Re: Draft response for CommentResponse:JP-2

On 20 Jan 2011, at 22:17, Andy Seaborne wrote:

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

My point is, that there might be many use cases where multiple paths don't matter, my slight rewording and moving the sentence about distinct up should only stress that, sure we also cater for those where they don't, but that we explicitly want to cater for both.
Does that make sense?
 

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

That's why I said "again, depending on the use case". I just added that... to re-emphasize the point above.

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

yes, again, just added "Although of course," for emphasis. 


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

Perfect! I think we could hint on that in the reply, as it shows that we take his comment serious!

Axel

> 
>         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 Friday, 21 January 2011 08:55:25 UTC