No Z39.50 Target supporting pure Type-1/Type-101 supports Unary NOT
since it isn't in the Type-1/101 query language.

However, most database/indexing systems (which would underpin many of
these targets) do.

Depends who the *primary* target audience is - adding ZNG to existing
Z39.50 systems or adding ZNG to new (non-Z39.50) systems.

Matthew

> -----Original Message-----
> From: Stevens, Pat [mailto:[log in to unmask]]
> Sent: 24 September 2001 16:59
> To: [log in to unmask]
> Subject: Re: CQL NOT Operator
> 
> I believe that our focus in ZNG was on taking functionality that
Z39.50
> offered into a new network platform.  My understanding was that the
> operators were chosen because they represented both what available
targets
> could support.
> 
> With the CQL are we trying to express the range of operators likely to
be
> used in the ZNG environment or a comprehensive set of logical
operators.
> If
> the first, I suppose we should be examining the universe of operations
> supported in the environment we wish to support.  Is a unary not
supported
> by many or any targets?
> 
> Pat
> 
> -----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