W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

Re: Draft Response for "Comments on SPARQL 1.1 WD 20091022"

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Fri, 6 Nov 2009 13:19:56 +0000
Message-ID: <58495e3d0911060519k6e1263dh8872c615e23d7cca@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:40 GMT