RE: Does the expressive power of SPARQL include all forms of default negation?



> -----Original Message-----
> From: Danny Ayers [mailto:danny.ayers@gmail.com]
> Sent: 2 September 2009 12:13
> To: Seaborne, Andy
> Cc: Lee Feigenbaum; Chimezie Ogbuji; public-sparql-dev@w3.org
> Subject: Re: Does the expressive power of SPARQL include all forms of
> default negation?
> 
> 2009/9/2 Seaborne, Andy <andy.seaborne@hp.com>:
> 
> >> 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

Received on Wednesday, 2 September 2009 15:19:18 UTC