> -----Original Message-----
> From: Danny Ayers [mailto:[email protected]]
> Sent: 2 September 2009 12:13
> To: Seaborne, Andy
> Cc: Lee Feigenbaum; Chimezie Ogbuji; [email protected]
> Subject: Re: Does the expressive power of SPARQL include all forms of
> default negation?
>
> 2009/9/2 Seaborne, Andy <[email protected]>:
>
> >> Chimezie Ogbuji wrote:
>
> >> > Basically, the problem is one where I want to find "all resources
> that
> >> are
> >> > not a member of a specific class". This seems to be especially
> >> problematic
> >> > for RDF graphs where each resource has *multiple* rdf:type
> statements.
> >> > Consider the graph:
> >> >
> >> > _:b rdf:type D
> >> > _:a rdf:type C
> >> > _:a rdf:type D
> >> > _:a rdf:type B
> >> >
> >> > And we want to find "all resources that are not a member of the C
> >> class,"
> >> > where the *not* in this case is meant in the closed world sense
> (i.e.,
> >> > basically there is no statement of the form: ?RESOURCE a C in the
> >> graph).
>
> Excuse me folks, but I'm not quite grasping something here - would NOT
> EXISTS/UNSAID be introducing something new, or would it be sugar for
> the kind of convoluted !BOUND query Chime described?
The NOT EXISTS proposal is a filter - it takes the pattern and sees if it can
be matched for the variables of the current row, substituting in the variables
in the pattern that are the same. As such it behaves very like OPTIONAL/!bound
except you don't have to go through hoops to ensure there is a unused variable
for the bound to test
OPTIONAL { ?x a ?t2 . FILTER(?t2 = :C) }
There can be differences for some more complicated patterns e.g. if the NOT
EXISTS involves an OPTIONAL inside it's pattern and that OPTIONAL involves a
variable only used in the thing being tested (the double nested optional
situation from current SPARQL). In my experience, such complicated patterns
are very rare in practice and even then often the wrong thing to do. Given
that the test for the difference or not is a static test of the query, an
optimizer can choose either strategy.
So it's not directly sugar but it does provide a way for many optional/bound()
to be written in a clearer fashion. Few people find the OPTIONAL/!bound very
clear.
More details will be in the FPWD of the query language changes.
Andy
>
> Cheers,
> Danny.
>
> --
> http://danny.ayers.name
