# CommentResponse:RV-4

From SPARQL Working Group

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