Re: SPARQL Query 1.1 review

On 11/02/11 12:36, Birte Glimm wrote:
> Similarly, I am concerned about FILTER EXISTS and FILTER NOT
> EXISTS. MINUS is a proper algebra operator, which combines
> solutions sequences, but having EXISTS and NOT EXISTS defined as
> filters is not in line with how filters previously worked, i.e., by
> working on RDF terms that result from applying given solutions to the
> variables followed by evaluating the filter expression (see also
> description in the itemise of 17.2). FILTER EXISTS and FILTER NOT
> EXISTS require the evaluation of BGPs, so that is quite a different
> thing and would require an algebra translation that somewhere has a
> Bgp(...) element in it, which does not seem to be the case at the
> moment. This might just be the case because Section 18 is not yet
> ready, but even though FILTER [NOT] EXISTS uses the FILTER keyword, it
> might be better to not treat them in the same way as other filters or
> not even use the FILTER keyword at all. I would rather like to see
> them as first class operators like MINUS or OPTIONAL.

We have seen that both NOT EXIST and MINUS reflect ways of thinking 
about negation.

FILTER NOT EXISTS may be usefully combined with other conditions with ||.

This is why having the FILTER ([NOT] EXISTS ....) and short form NOT 
EXISTS makes sense to me.

For example:

   ?x a :Climber .
   ?x :age ?age .
   FILTER ( EXISTS { ?x :signedoff true } || ?age >= 18 )

filters for people who have either been signed off for climbing without 
supervision or who are 18 or over (and hence don't need supervision).

This reflects SQL EXISTS <table subquery> usage where references inside 
the <table subquery> refer to the current row.

I believe that the other subquery situations from SQL (<scalar 
subquery>, <row subquery>) will be desirable in SPARQL sometime.  This 
would place graph patterns in expressions for a scalar subquery, for 
example.

 Andy

Received on Saturday, 12 February 2011 17:47:17 UTC