- From: Rob Vesse <rav08r@ecs.soton.ac.uk>
- Date: Wed, 20 Oct 2010 10:43:28 +0100
- To: <public-rdf-dawg-comments@w3.org>
- Cc: "'Steve Harris'" <steve.harris@garlik.com>
Yes my comments were answered to my satisfaction Regards, Rob Vesse -----Original Message----- From: Steve Harris [mailto:steve.harris@garlik.com] Sent: 20 October 2010 00:10 To: Rob Vesse Subject: Re: Response to comment RV-4 Hi Rob, We need a formal record of this, is it OK if I forward this message? Or could you reply to the message on the comments list? Regards, Steve On 2010-10-19, at 14:58, Rob Vesse wrote: > Yes my comments on this have been answered to my satisfaction > > Thanks > > Rob Vesse > > -----Original Message----- > From: public-rdf-dawg-comments-request@w3.org > [mailto:public-rdf-dawg-comments-request@w3.org] On Behalf Of Steve Harris > Sent: 15 October 2010 11:43 > To: Rob Vesse > Cc: public-rdf-dawg-comments@w3.org > Subject: Response to comment RV-4 > >> Hi Gregory >> >> That answers most of my comments but I just want to pick up on a couple > of >> points you raised > > Rob, could you please indicate whether the previous Comment (ref. RV-3) was > answered to your satisfaction? > >>> The group has decided to allow DISTINCT as a flag to all aggregates, as >> per SQL. >> >> I'm happy with this but I'm wondering how exactly this applies in the > case >> of numeric aggregates, so say I'm doing a SUM over some variable which > has >> the following values bound to it: >> >> "1"^^xsd:integer >> "1"^^xsd:decimal >> "1"^^xsd:double > > The DISTINCT keyword causes the values to be made distinct at the term > level, > not the value level, c.f. > http://www.w3.org/TR/2010/WD-sparql11-query-20100601/#defn_algDistinct > >> Should the result be 3 since each value is distinct in terms of >> term-equality or should the result be 1 since the values are non-distinct > in >> terms of value-equality? The latter strikes me as potentially being >> computationally more complex to compute > > The result will be the same as (1 + 1.0 + 1.0e0), i.e. 3.0e0. > >> Also I assume that SAMPLE(DISTINCT ?x) is functionally equivalent to >> SAMPLE(?x) since the DISTINCT modifier doesn't make obvious sense for > SAMPLE > > That is correct. > >> Providing lengths is not currently planned. This does weaken the >> usefulness of property paths but, as a time >> permitting feature, the WG is inclined to leave analysis and > specification >> of including lengths to a later >> group when more deployed experience is available. The WG believes it has >> not designed out the possibility >> - for example, potential syntax forms have been considered to make sure >> the synatx is not a barrier to a >> future WG. >> >> I previously objected to path lengths as I thought they'd be a pain to >> implement but having now implemented paths in my engine I realised I got >> path lengths for free so I've added a syntax extension like so: >> >> SELECT * WHERE { ?x foaf:knows+ LENGTH ?distance ?y} >> >> This evaluates the path ?x foaf:knows+ ?y and binds the length of the > path >> to the variable ?distance. While it's not the prettiest of syntaxes it >> seemed the easiest way to shoehorn the feature in there. > > The group is resolved not to include a path length accessor to the property > path feature in this iteration of the working group. > > Regards, > Steve Harris, on behalf of the SPARQL WG. > > -- > Steve Harris, CTO, Garlik Limited > 1-3 Halford Road, Richmond, TW10 6AW, UK > +44 20 8439 8203 http://www.garlik.com/ > Registered in England and Wales 535 7233 VAT # 849 0517 11 > Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD > > > -- Steve Harris, CTO, Garlik Limited 1-3 Halford Road, Richmond, TW10 6AW, UK +44 20 8439 8203 http://www.garlik.com/ Registered in England and Wales 535 7233 VAT # 849 0517 11 Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Wednesday, 20 October 2010 09:44:20 UTC