Re: limit per resource rethought...

> 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"

*Personally* (= </chair>) , I like 

> ?p    ?top
> <a>   "foo"
> <a>   "baz"
> <a>   "bar"
> <b>   "qux"

better (at least that reflects more the intention I had in mind with the original query)

Also, in your approach, for varying 'n' I need to put n times "(SCALAR(1, DESC ?name) AS ?n1)"
which is a lot like my earlier ugly version with OPTIONAL
whereas with 

SELECT ?P
      ({ SELECT ?P1 WHERE { ?P :knows ?P1 } ORDER BY ?P1 LIMIT n } AS ?F )
WHERE {?P a :Person}

a la Paul, I'd just have to change 'n' as a parameter of LIMIT in the query. Admittedly, 
I find that quite appealing, whereas I am not really sure whether inventing new 
aggregates solves this or similar queries adequately. :-|


Just for comparison... this is how that would work in SQL ... assume I have the 
knows relation in a table KNOWS(A,B):

SELECT A,B FROM KNOWS k1 WHERE B IN (SELECT B FROM KNOWS k2 WHERE k1.A=k2.A LIMIT n);


Axel


On 12 Aug 2010, at 16:32, Steve Harris wrote:

> 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 Friday, 13 August 2010 09:00:16 UTC