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.
>=20
> However, most database/indexing systems (which would underpin many of
> these targets) do.
>=20
> Depends who the *primary* target audience is - adding ZNG to existing
> Z39.50 systems or adding ZNG to new (non-Z39.50) systems.
>=20
> Matthew
>=20
> > -----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
> >=20
> > 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.
> >=20
> > 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?
> >=20
> > Pat
> >=20
> > -----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
> >=20
> >=20
> > A separate matter is whether we want to revisit the boolean operators
> we
> > have in Z39.50 type-1 (AND, OR, AND-NOT).
> >=20
> > 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
> >=20
> > For example NOT A, A OR (NOT B) etc.
> >=20
> > 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.
> >=20
> > I've assumed that it was to avoid queries which would return excessive
> > hits
> >=20
> > (NOT Author=3DSmith for example would be a very large set in most
> > databases)
> >=20
> > Matthew
> >=20
> > > -----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=F8rgensen 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
>=20
|