- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Thu, 12 Aug 2010 09:36:54 +0100
- To: Axel Polleres <axel.polleres@deri.org>
- CC: Paul Gearon <gearon@ieee.org>, SPARQL Working Group <public-rdf-dawg@w3.org>
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) { ?P foaf:knowns ?Q . ?Q foaf:name ?name . } GROUP BY ?p c.f. SAMPLE which is "choose any one" Some ordering would be preserved (i.e. all the group keys are over adjacent rows). > > SELECT ?P > ({ SELECT ?P1 WHERE { ?P :knows ?P1 } ORDER BY ?P1 LIMIT 3 } AS ?F ) > WHERE {?P a :Person} presumably with the scale scoping rules (conceptually, the sub-query is executed for each row with ?P bound to the value for the current row). BTW this is the same scoping rules for EXISTS. I am suggesting it scoping for SERVICE as well because it deals with the issue of when the service URL is bound in "SERVICE ?service" and works well with BINDINGS. > In one sense that seems to work conceptually, since for project expressions we have left-to right propagation of bindings, but > at the same time it would be quite a big step as unary SELECT queries are not scalar functions, but return a set of bindings and > this set would need to be interpreted as kind of Kartesian product here, right? Either the way Paul described with nested tables or turn each row into several rows (which is what I think you describe). The result set format could easily add nested tables - we had discussed them in DAWG (Simon Raboczi [Tucana] explained the Mulgara approach). It might, however, have a significant impact on implementations APIs and tool chains around SPARQL results. > (Side remark: if we'd allow this, it kind of raises the question why not allow SELECT queries likewise in other places > where expressions are allowed, see closed issues ISSUE-6 and ISSUE-13 ... ) > > Axel Andy
Received on Thursday, 12 August 2010 08:37:54 UTC