- From: Steve Harris <steve.harris@garlik.com>
- Date: Fri, 13 Aug 2010 11:29:33 +0100
- To: Axel Polleres <axel.polleres@deri.org>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>, Andy Seaborne <andy.seaborne@epimorphics.com>, Paul Gearon <gearon@ieee.org>
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. - 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 10:30:09 UTC