- 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