Re: limit per resource rethought...

On 2010-08-12, at 09:36, Andy Seaborne wrote:
> 
> On 12/08/10 08:36, Axel Polleres wrote:
>> The only way I'd see that fit into our current model would be allowing unary SELECT queries as project expressions... something like:
> 
> Another way would be to allow aggregates to return multiple rows for each key of the group.  Then we can have a (custom) aggregate that returns the top 3 in a group:
> 
> SELECT ?P top(3, ?name, desc)

That will do funny things to the cardinality, and often still leaves you with some joining up to do in the app. Given:

<a> :name "foo", "bar", "baz" .
<b> :name "qux" .

The results will look like

?p    ?top
<a>   "foo"
<a>   "baz"
<a>   "bar"
<b>   "qux"
[ maybe with
<b>   
<b>   
depending on exact semantics]

Personally I would prefer something that returned just one value, with a fixed offset, e.g.

SELECT ?p (SCALAR(1, DESC ?name) AS ?n1) (SCALAR(2, DESC ?name) AS ?n2) (SCALAR(3, DESC ?name) AS ?n3)

So you get

?p    ?n1    ?n2    ?n3
<a>   "foo"  "baz"  "bar"
<b>   "qux"

For most of our uses of this kind of feature, it would be preferable. e.g. find 1-2 alternative names, 1-3 email addresses, and 1-2 postcodes for people called John Smith.

I can do that as a bunch of separate queries of course, which is what we do now, but it's not convenient or efficient.

- Steve

-- 
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 Thursday, 12 August 2010 15:33:20 UTC