W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

Re: Semantics of aggregates

From: Steve Harris <steve.harris@garlik.com>
Date: Tue, 1 Sep 2009 10:22:08 +0100
Cc: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
Message-Id: <7D4A6EDE-38DF-4422-B1C6-0067419918C8@garlik.com>
To: "Seaborne, Andy" <andy.seaborne@hp.com>
On 31 Aug 2009, at 23:25, Seaborne, Andy wrote:


>> What would be the expected behaviour given
>>   SELECT min(?x) min(?y) min(?z) { ... }
>> where x, y, and z each take some subset of numbers, dates etc? Also
>> unknown datatypes pose a problem.
> I don't know (for several of the designs).
> We have to have a design that copes with the situation of mixed sets  
> of numbers although I hope it's more of a corner case to be dealt  
> with rather than a driver for the overall design.  (FWIW I value  
> consistency of results across implementations and also not having  
> errors during query evaluation aborting the overall query.)

Agreed, but I also value a solution that gives the most helpful  
results for common usecases, though obviously that's something that's  
extremely hard (potentially impossible) to define.

> Unknown datatypes are certainly a problem as well.


I think I'm currently leaning towards a solution that handles this  
problem more like a cast or datatype restriction. It seems like the  
easiest thing to understand that produces a single value from the  
aggregate function, which seems like it will make it easier to  
understand from the users point of view.

That said, we've not implemented many aggregates yet, so we don't have  
much experience of working with them.

- Steve

Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
Received on Tuesday, 1 September 2009 09:22:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:57 UTC