I'm in favour of calling this ANDNOT. I don't agree with Ralph that this
is just as arbitrary as

a) the name "ANDNOT" carries the implication that this is not a unary
operator, whereas NOT carries no such implication

b) the name NOT has clearly caused confusion already.

Moreover, an aim of ZNG is to lower the barriers of access to the
protocol. In every computer language I've encountered to date (C, C++,
C#, Pascal, Oberon, Basic, Modula, Java, etc.) NOT is an unary operator.
When I studied logic at university, I studied Boolean, classical logic,
modal logic, temporal logic, intuitionistic logic etc. and again is all
those NOT was a unary operator. It is only since dealing with Z39.50/CQL
etc. that I've encountered the concept of NOT being binary (even then it
is really short hand for something else namely AND-NOT). So I would
argue that for many coming to ZNG from outside the Z39.50 community,
calling this operand NOT would imply that it is unary.

Matthew  

> -----Original Message-----
> From: LeVan,Ralph [mailto:[log in to unmask]]
> Sent: 24 September 2001 13:57
> To: [log in to unmask]
> Subject: Re: CQL NOT Operator
> 
> Of the examples you give, only Exp1 AND (NOT Exp2) is legal for us.
More
> clearly, the query, "NOT English" will fail.
> 
> Ralph
> 
> > -----Original Message-----
> > From: Poul Henrik Jørgensen [mailto:[log in to unmask]]
> > Sent: Monday, September 24, 2001 8:53 AM
> > To: [log in to unmask]
> > Cc: [log in to unmask]
> > Subject: RE: CQL NOT Operator
> >
> >
> > Hi Ralp,
> >
> > You state, that your "NOT" is not (sic) a unary operator. But
> > ist seems to
> > me, that you ARE in fact using "NOT" to designate the unary
> > operator, which
> > negates a corresponding logical expression, e.g.:
> >
> > NOT Exp1  (NOT "Poul Henrik understands this") => "Poul
> > Henrik is confused"
> > Exp1 AND (NOT Exp2)
> > Exp1 OR (NOT Exp2)
> > NOT (Exp1 AND Exp2)
> > NOT (Exp1 OR Exp2)
> >
> > Best regards,
> > Poul Henrik
> > mailto:[log in to unmask]
> >
> >
> >
> >
> > -----Original Message-----
> > From: LeVan,Ralph [mailto:[log in to unmask]]
> > Sent: 24. september 2001 14:31
> > To: [log in to unmask]
> > Subject: Re: CQL NOT Operator
> >
> >
> > I don't know of many systems that support the unary NOT.  None of
the
> > systems that I have ever worked on support it.
> >
> > I mean for NOT to mean AND NOT, which is usually just
> > shortened to NOT.  If
> > you really think this is going to cause confusion, then we
> > can use the name
> > ANDNOT, but that is just as arbitrary and just telling folks
> > that NOT is a
> > binary operator.
> >
> > Ralph
> >
> > > -----Original Message-----
> > > From: Poul Henrik Jørgensen [mailto:[log in to unmask]]
> > > Sent: Sunday, September 23, 2001 3:31 PM
> > > To: [log in to unmask]
> > > Cc: [log in to unmask]
> > > Subject: CQL NOT Operator
> > >
> > >
> > > Hi Ralp,
> > >
> > > In CQL, do you intend "NOT" to represent the binary operator,
> > > that is often
> > > called "NOT EQUAL"?
> > >
> > > If that is the case; I propose to denote the operator
> > > something else (eg.
> > > "<>" or "NE", since "NOT" usually denote the 1-ary operator.
> > >
> > > Best regards,
> > > Poul Henrik
> > > mailto:[log in to unmask]
> > >
> > >
> > > -----Original Message-----
> > > From: LeVan,Ralph [mailto:[log in to unmask]]
> > > Sent: 22. august 2001 14:50
> > > To: [log in to unmask]
> > > Subject: Re: CQL
> > >
> > >
> > > > -----Original Message-----
> > > > From: Rob Koopman [mailto:[log in to unmask]]
> > > > Sent: Tuesday, August 21, 2001 5:52 PM
> > > >
> > > > you on purpose exclude:
> > > > 1) NOT title:second W title:war (NOT as unary operator)
> > >
> > > Yes.
> > >
> > >
> > > > 2) author:ralph,levan OR womble,kelly (qualifier implicitly
> > > repeated)
> > >
> > > Yes.
> > >
> > >
> > > > 3) NEAR
> > >
> > > Yes, but I have no problem putting it in.
> > >
> > >
> > > > Can we get away with ? meaning zero or one as a large part of
> > > > the world uses
> > > > it now as zero or more. I am a bit worried about: isbn: 123?456
> > >
> > > I'm open to suggestions on how to handle wildcards.  I think
> > > we need to nail
> > > down wildcard behavior and then allow the servers to declare
> > > which wildcards
> > > they support.  I know that not all servers can support them
> > > all and don't
> > > want to mandate something that can't be done.
> > >
> > > I don't feel badly about keeping this language a little
> > > strict.  It was not
> > > my intention that end-user searches could just be dumped into
> > > a URL.  I'm
> > > still expecting some kind of expert (human or software) to
> > > craft the query
> > > from user input; I'm just trying to make it easier.
> > >
> > > Ralph
> > >
> >