- From: Steve Harris <steve.harris@garlik.com>
- Date: Fri, 15 Oct 2010 11:42:56 +0100
- To: Rob Vesse <rav08r@ecs.soton.ac.uk>
- Cc: public-rdf-dawg-comments@w3.org
> 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
Received on Friday, 15 October 2010 10:43:32 UTC