I can't speak for tex IR systems but I'd be very surprised to come
across a flat file, relational or object database system which did not
support unary NOT (all the SQL databases for example would support unary
NOT)

Matthew

> -----Original Message-----
> From: Mark Needleman - DRA [mailto:[log in to unmask]]
> Sent: 24 September 2001 17:56
> To: [log in to unmask]
> Subject: Re: CQL NOT Operator
> 
> Matthew
> 
> I would call it a stretch to say "most" underlying database/indexing
> systems support unary not - some probably do but many probably dont
> 
> mark
> 
> 
> On Mon, 24 Sep 2001, Matthew Dovey wrote:
> 
> > 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
> >