Re: limit per resource rethought...

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

Just adding a few notes here: 
1)  LIMIT is actually not standard in SQL
  http://en.wikipedia.org/wiki/Select_%28SQL%29#Limiting_result_rows
in ISO SQL:2008 FETCH FIRST should work...

2) this SQL version using IN here, actually rather amounts to allowing IN along with unary SELECTs in FILTERs for us... 
   which would reopen ISSUE-6 in which case the query would probably look be something like:

   SELECT ?A ?B WHERE { ?A :knows ?B FILTER ( ?B IN ( SELECT ?B1 WHERE {?A :knows ?B1} LIMIT n ) ) }

BTW, I acknowledge of course that this whole use case is kind of complementary to the original LIMIT per resource [1] use case

Axel

1. http://www.w3.org/2009/sparql/wiki/Feature:LimitPerResource 

On 13 Aug 2010, at 09:59, Axel Polleres wrote:

>> 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:21:41 UTC