Re: limit per resource rethought...

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