From SPARQL Working Group
Jump to: navigation, search
> 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.