RE: negation (was: Question regarding subselect)



> -----Original Message-----
> From: Steve Harris [mailto:steve.harris@garlik.com]
> Sent: 1 May 2009 10:20
> To: Seaborne, Andy
> Cc: 'RDF Data Access Working Group'
> Subject: Re: Question regarding subselect
> 
> On 1 May 2009, at 09:43, Seaborne, Andy wrote:
> >> -----Original Message-----
> >> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> >> request@w3.org] On Behalf Of Steve Harris
> >> Sent: 1 May 2009 08:51
> >> To: SPARQL Working Group
> >> Subject: Re: Question regarding subselect
> >>
> >> Yes, that's my fault, I think I created that wiki page - SubQuery
> >> would have been a better name, and was my intention. It's SQL legacy
> >> where the only query verb is SELECT. Well... actually there's SHOW,
> >> but it's a bit different and you can't do sub-shows.
> >>
> >> SubASKs don't have to go in a FILTER, they're also useful in WHERE
> >> clauses, assuming they project either a solution with no bindings
> >> (for
> >> true) or no solutions (for false).

On reflection (well, have to think of something on my lunchtime run), I think it's a bit more involved for negation (!ASK) because of variable scoping.  The usage I have in mind is that NOT EXIXTS {pattern} is testing to see if the pattern does not match and the variables in-scope include those from the previous part of the query (it's not bottom up evaluation).  This form of negation is order dependent as is OPTIONAL/!BOUND - NOT EXISTS has the same effect except it does not rely on at least one free variable.  Without assignment, NOT EXIST (in pattern or in filter) is much easier to use than OPTIONAL/!BOUND. 

Let's sketch some examples around the F2F.  We probably in strong agreement but using different words. 

 Andy

> >> Which I believe matches the SPARQL
> >> algebra (it matches my implementation of ASK, at least).
> >
> > The result from ASK is a boolean.
> >
> > We can make it go in patterns - like UNSAID would have - it's a
> > filter in disguise
> >
> > But then ({}) and () (that's a solution of one row, no bindings and
> > a solution of no rows) for true and false work so you get the right
> > answers.
> 
> Sorry, I was being a bit lax in what I wrote (pre-coffee).

:-)

> I meant
> that the result of the WHERE part of the ASK is ({}) or (). Inside my
> implementation it looks a lot like SELECT /*nothing*/ WHERE { ... }
> LIMIT 1. The ASK verb translates that into boolean true or false.
> 
> I may be wrong on the projection though, is it actually ({}+)? Or is
> there an implied LIMIT 1?
> 
> >> I'm not convinced FROM { CONSTRUCT ... } achieves anything, but it
> >> may
> >> aid composability.
> >
> > Observation: If this is a SELECT with a FROM/CONSTRUCT, putting the
> > pattern of the CONSTRUCT onto the front of the SELECT pattern will
> > expose the same information (won't it?).  Currently, a CONSTRUCT
> > template can generate bNodes and introduce new constants but other
> > wise it's the same variables as the pattern.
> 
> Yes, that was my impression too.
> 
> - Steve
> 
> --
> Steve Harris
> Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
> +44(0)20 8973 2465  http://www.garlik.com/

> Registered in England and Wales 535 7233 VAT # 849 0517 11
> Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10
> 9AD

Received on Friday, 1 May 2009 12:56:59 UTC