# Re: limit per resource rethought...

From: Axel Polleres <axel.polleres@deri.org>
Date: Fri, 13 Aug 2010 18:51:57 +0100
Cc: "SPARQL Working Group" <public-rdf-dawg@w3.org>, "Andy Seaborne" <andy.seaborne@epimorphics.com>, "Paul Gearon" <gearon@ieee.org>
Message-Id: <59878C80-4F0C-4396-839B-5CB915CF4F12@deri.org>
To: Steve Harris <steve.harris@garlik.com>
```
On 13 Aug 2010, at 15:55, Steve Harris wrote:

> On 2010-08-13, at 13:16, Axel Polleres wrote:
> ...
> >>> 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...?
>
> A OPTIONAL { B . FILTER(C) } is defined as LeftJoin(A, B, C). C can't contain any bottom-up expressions, as os SPARQL 1.0.

http://www.w3.org/TR/rdf-sparql-query/#sparqlAlgebra

Definition: LeftJoin

the explanation after the definition makes clear that the filter expression C is evaluated over the merge of the solution mappings for A an B
which means you can't evaluate the pattern { B . FILTER(C) } purely bottom-up.

Example: "Give me email address only for those people over 20"

SELECT ?P ?M  { ?P a person; age ?A . OPTIONAL { ?P mbox ?M . FILTER (?A > 20) } }

> >> 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?
>
> Yes, but the algebra is not.

it is, see above.

>
> > 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.
>
> We already knew this particular usecase was going to be tricky/verbose, when it was discussed with subquery syntax. so it's not new information.
>
> My feeling is much like Paul's. I think we don't have enough time to finish what we have on our plate now, without bringing in new use-cases.

Fair enough, I just wanted to bring this use case in again before we close down entirely, but am happy enough to postpone it also for a possible future WG.

The main goal of bringing up these things (like the syntax question/proposal from an earlier mail) was to collect such things which had been
on my mind for a while without a lot of concrete discussion and put them on the table, before we go to last call.

Was there a concrete procedure for "postponed issues" in DAWG? In other words, shall we still record these things as ISSUEs which we can put aside for a later WG?

best,
Axel

>
> - 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