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
|