Re: limit per resource rethought...

On 13 Aug 2010, at 12:03, Steve Harris wrote:

> On 2010-08-13, at 11:53, Axel Polleres wrote:
> >
> > On 13 Aug 2010, at 11:29, Steve Harris wrote:
> >
> >> On 2010-08-13, at 10:21, Axel Polleres wrote:
> >>
> >>>> 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
> >>
> >> That's true, but it's rather widely implemented. I think MS SQL was the last to hold out, and they added it recently.
> >>
> >>> http://en.wikipedia.org/wiki/Select_%28SQL%29#Limiting_result_rows
> >>> in ISO SQL:2008 FETCH FIRST should work...
> >>
> >> That's just a standard way to write LIMIT, it doesn't alter the execution model.
> >>
> >>> 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
> >>
> >> And you still won't get the behaviour you'd like, it's evaluated bottom-up. See my other mail.
> >
> > Hmmm, I understood that FILTER's are always evaluated "per binding", i.e. the FILTER expression
> > is evaluated after the existing bindings have been replaced...
> 
> We don't have any semantics for that kind of subquery in SPARQL, but in SQL that's not what happens. The subquery is executed first, so the FILTER/WHERE would always see the same table against the IN.
> 
> > in that ontext, as for your other mail...
> >
> >> Your query - though not really equivalent to a SPARQL-style subquery,
> >
> > True, indeed, it would need subqueries allowed in IN in FILTERS with the mentioned behavior, i.e.
> > that existing bindings are "injected" in the FILTER before the subquery is evaluated.
> 
> Right, which would mean that part of our algebra as top-down, and part bottom-up.

Hmmm, which is something we partially have already with FILTERs in OPTIONALs...?

> I suspect it would be very hard to specify that without introducing non-deterministic results.

As long as this only affected subqueries in FILTER evaluation (which though - admittedly - would imply reopening ISSUE-6), 
I can't see a big problem. As I said, aren't FILTERs already supposed to be evaluated only after replacement of the variables?

I am trying to sum up:

On the one hand, the specific use case might be viewed as new information, so it might be 
ok to reopen issues, such as ISSUE-6.

On the other hand, it all depends, I don't really know whether others also consider this use case as such valid for 
this round of SPARQL or exotic... Personally, I somehow had the (wrong) understanding that "LIMIT per resource" 
would also allow me to do this kind of queries, only now realising that it is orthogonal to the original "LIMIT 
per resource" use case.

So: 
 1) Do we consider these kinds of queries (let's call them "orthogonal LIMIT per resource") relevant enough?
 2) If yes, which way to go? (it seems there'd be at least two extensions of the current subquery mechanism on the table to allow that)  

Axel

> 
> >> and not legal SQL :)
> >
> > Not sure what you mean here? I tried out my SQL query in SQLite and it behaved as intended
> 
> OK, the table rename without AS, combined with use of uppercase for table names threw me.
> 
> - 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 12:17:27 UTC