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

Received on Friday, 15 October 2010 10:43:32 UTC