FW: Response to comment RV-4

Yes my comments were answered to my satisfaction

Regards,

Rob Vesse

-----Original Message-----
From: Steve Harris [mailto:steve.harris@garlik.com] 
Sent: 20 October 2010 00:10
To: Rob Vesse
Subject: Re: Response to comment RV-4

Hi Rob,

We need a formal record of this, is it OK if I forward this message? Or
could you reply to the message on the comments list?

Regards,
   Steve

On 2010-10-19, at 14:58, Rob Vesse wrote:

> Yes my comments on this have been answered to my satisfaction
> 
> Thanks
> 
> Rob Vesse
> 
> -----Original Message-----
> From: public-rdf-dawg-comments-request@w3.org
> [mailto:public-rdf-dawg-comments-request@w3.org] On Behalf Of Steve Harris
> Sent: 15 October 2010 11:43
> To: Rob Vesse
> Cc: public-rdf-dawg-comments@w3.org
> Subject: 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
> 
> 
> 

-- 
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 Wednesday, 20 October 2010 09:44:20 UTC