My reason for never supporting a unary NOT is that it requires the concept
of a "universe set".  Somewhere there must be a defined set of all the
records so that you can NOT out the undesired records.  It's been too much
trouble to maintain such a set and I have never had a user that wanted the
unary NOT.  Why would I do the search "NOT dog"?  (I know, "NOT english" is
an almost useful search, but usually in combination with some other term.)

I don't think there are any users that could possibly understand what an OR
NOT operator would do.  I can draw the Venn diagrams for it, but I'm not
sure what really happens.

Ralph

> -----Original Message-----
> From: Matthew Dovey [mailto:[log in to unmask]]
> Sent: Monday, September 24, 2001 11:45 AM
> To: [log in to unmask]
> Subject: Re: CQL NOT Operator
> 
> 
> A separate matter is whether we want to revisit the boolean 
> operators we
> have in Z39.50 type-1 (AND, OR, AND-NOT).
> 
> This has always struct me as odd, since this particular combination is
> (I'm pretty sure, but don't have a proof to have) not expressively
> comprehensive. i.e. there are some Boolean expressions we can't have
> 
> For example NOT A, A OR (NOT B) etc.
> 
> If this was merely a way of avoiding having any unary operators, then
> NAND (A NAND B is equiv to NOT (A AND B) ) would have been a 
> far better
> choice since the standard Boolean operators (NOT, AND, OR) 
> are derivable
> using just NAND.
> 
> I've assumed that it was to avoid queries which would return excessive
> hits
> 
> (NOT Author=Smith for example would be a very large set in most
> databases)
> 
> Matthew
> 
> > -----Original Message-----
> > From: Ray Denenberg [mailto:[log in to unmask]]
> > Sent: 24 September 2001 15:22
> > To: [log in to unmask]
> > Subject: Re: CQL NOT Operator
> > 
> > Poul Henrik Jørgensen wrote:
> > 
> > > If alternatively we wish to introduce a new boolean operator
> composed of
> > the
> > > well binary operator AND in some combination with the 
> unary operator
> NOT,
> > > then we should call it something else e.g. either AND-NOT or
> NOT-AND.
> > 
> > We're not introducing a new boolean operator. It's the same 
> "and-not"
> that
> > we
> > have in the type-1 query. (If you want to view it as some 
> combination
> of
> > unary
> > NOT and binary AND, fine, but that doesn't change the fact that it's
> the
> > same
> > binary and-not we've always had in Z39.50.)
> > 
> > --Ray
> > 
> > --
> > Ray Denenberg
> > Library of Congress
> > [log in to unmask]
> > 202-707-5795
>