- From: Andy Seaborne <andy.seaborne@talis.com>
- Date: Fri, 6 Nov 2009 13:19:56 +0000
- To: Steve Harris <steve.harris@garlik.com>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
2009/11/6 Steve Harris <steve.harris@garlik.com>: > On 6 Nov 2009, at 08:58, Andy Seaborne wrote: > >> Proposed response: >> >> http://www.w3.org/2009/sparql/wiki/CommentResponse:ldodds-query-1 > > Re. FILTER( EXISTS { ... }) > > I think that at the F2F that agreed that we wouldn't allow for EXISTS inside > FILTER for this reason, and because there was some reluctance to have BGP > expressions in the FILTER syntax. > > If that matches the minutes, and/or other people's recollection it might be > worth pointing that out, as it answers the concern. > I wasn't there and I'll wait for the formal outcomes but I read the logs as discussing sub-SELECT in FILTER. That does make sense because (1) we have named variables so it's a lot less necessary to be able to put a scalar sub-SELECT into a FILTER for testing and (2) FILTER motion can complicate the scoping rules. Neither of these apply for EXISTS. On (1), the best I came up with is { SELECT (count(*) > 0 AS ?boolean) WHERE { pattern1 . EXISTS{pattern2} } } which I think we'd agree is "inconvenient" :-) and inefficient. { SELECT (count(*) > 0 AS ?boolean) WHERE { SELECT * { pattern1 . EXISTS{pattern2} } LIMIT 1 } } is faster and worse to write. Note: pattern1 is the part preceding the EXISTs and needs to be repeated. This duplication of a pattern part is highly undesirable. I worry about asymmetries being introduced although some can be necessary. Andy http://dev.mysql.com/doc/refman/5.4/en/subqueries.html
Received on Friday, 6 November 2009 13:20:37 UTC