W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2010

Re: limit per resource rethought...

From: Steve Harris <steve.harris@garlik.com>
Date: Fri, 13 Aug 2010 15:55:43 +0100
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>, Andy Seaborne <andy.seaborne@epimorphics.com>, Paul Gearon <gearon@ieee.org>
Message-Id: <183B6B34-75E0-4572-AF15-CBE3248D87CB@garlik.com>
To: Axel Polleres <axel.polleres@deri.org>
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.

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

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

- 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 14:56:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:01 UTC