Hi Ralph;

The query syntax should be unambigous in general - not just in the
(implicit) context of some parser at OCLC.

If the symbol "NOT" designates the well-known unary boolean operator which
operates on a logical (true/false) expression, then we should say so.

 etc
  
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.

(NOT(a AND b)) is different than a (a AND (NOT b)) according to my rusty
memories of boolean algebra:

a  b  (a AND b)  NOT(a AND b)  (a AND (NOT b))
T  T      T          F                F
T  F      F          T                T
F  T      F          T                F
F  F      F          T                F

Best regards,
Poul Henrik
mailto:[log in to unmask]



-----Original Message-----
From: LeVan,Ralph [mailto:[log in to unmask]]
Sent: 24. september 2001 14: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
> > 
>