- From: Steve Harris <steve.harris@garlik.com>
- Date: Tue, 1 Sep 2009 14:34:25 +0100
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
On 1 Sep 2009, at 14:10, Seaborne, Andy wrote: > >> -----Original Message----- >> From: Steve Harris [mailto:steve.harris@garlik.com] >> Sent: 1 September 2009 10:22 >> To: Seaborne, Andy >> Cc: public-rdf-dawg@w3.org Group >> Subject: Re: Semantics of aggregates >> >> On 31 Aug 2009, at 23:25, Seaborne, Andy wrote: >> >> [snip] >> >>>> 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, > > My idea of a common case is when all the rows grouped have the same > type or are undefined. Is that your common case? No. Our apps have two cases, one where we control the data (or at least the conversion of it) and one where take in arbitrary data from outside. I imagine that some people have apps with some combination of these two, but currently we don't. In the first case it's as you say, either it's not present, or it's a known datatype, in the second case you get all kinds of values. >> though obviously that's something that's >> extremely hard (potentially impossible) to define. >> >>> Unknown datatypes are certainly a problem as well. >> >> Yes. >> >> 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 > > I'm not sure what the cast proposal is. A cast isn't a datatype > restriction: I said "more like a cast" I was thinking back to the discussion we had on this topic around F2F1, but couldn't remember the exact proposals. - 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 9AD
Received on Tuesday, 1 September 2009 13:35:02 UTC