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

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

Last modified on 27 July 2010, at 11:02