Message-Id: <199602090210.UAA06910@library.wustl.edu> Date: Thu, 8 Feb 1996 19:41:57 PST From: "Donald J. Reilly" <mailto:reilly@PSYCLONE.ENDINFOSYS.COM> Subject: Re: URLs To: Multiple recipients of list WEBCAT-L <mailto:WEBCAT-L@WUVMD.WUSTL.EDU>
I think we need to keep in mind that the point of the "Webcat" products, from
the
library point of view, is to put their collection on the web. So, a URL that
points to a particular
bib record in their collection is appropriate, since the point is to navigate
their collection. Maybe
I too am looking at this the wrong way, but it seems to me the value of
Z39.50/Web products was
to the vendors. They then had the ability to sell their web products to other
vendors (because
Z39.50 is a protocol designed to provide access to multiple vendors systems).
But since the
library wants a product that presents their collection to the web, what value
does Z39.50 have to
that product?
For example, your library is automated by EEE library vendor, when you buy the
WebEEE from that vendor, it pretends not to know anything about the internal
structure of its
own database, right? That's the point of Z39.50, that you can have access to a
vendor's system
without knowing the internal workings of that vendor's system. But does it make
any sense,
when most vendors have a Web product and most people buy the Web product from
the same
vendor as the one automating their library? Z39.50 has some inherent
limitations, like it's
inability to deal with circulation information (I understand that this is being
addressed, but there
are other limitations as well). It has been our approach that a web product
that understands and
interprets Voyager data is in a better position to robustly put that information
on the Web, than
one that tries to do it in a generic, least-common-denominator approach like
Z39.50. We are
providing a Web interface to the OPAC that is designed to be every bit as
functional as the
Windows OPAC. When we deal with serials data and acquisitions data and other
pieces, you get
a sense of how far OPAC functionality outstrips the ability of Z39.50 to keep
pace.
Now that I have made a target of myself with the previous heresy, let me
quickly add
that this is my personal view, not necessarily that of my employer.
Sincerely,
Don Reilly
---------------Original Message---------------
Folks,
I watched some discussion fly by as I plowed though a ton of back email... and I
want to toss a thought out. Isn't publishing a URL that refers to a specific bib
record like telling a patron that they will find the card for Huck Finn in the
seventh drawer from the top, as the 57th card in the drawer? Worse, isn't
publishing a URL that refers to a specific holdings record like telling a patron
that they will find Huck Finn in the fourth aisle, nineth shelf, 6.7 inches from
the left?
The URL is really an implementation detail of your library automation system. I
don't think you really want to publish that.
I believe that repeating the search is the "right" way to do it. So instead, I
want to publish a URL that executes a search that returns exactly one bib record
or exactly one holdings record. (Hopefully, it returns the *right* record! :-)
I've been way off base before, so I'm open to opinions that I'm way off base
again.
--
-- Art Z.
http://www2.dra.com/art/bio.html
----------End of Original Message----------
*****************************************
Donald J. Reilly
Director of Sales
Endeavor Information Systems, Inc.
(708) 292-2292 x2604 Fax: (708) 292-2296
mailto:Reilly@endinfosys.com
*****************************************