Z39.50 and all that

[Kevin C. Marsh]

>I have plowed through many documents related to Z39.50 as best I could, but
>I still have these very basic questions:
>
>1. how can one determine if a database can be adapted to be compliant with
>Z39.50?  For example, some of us are looking at our mainframe library
>catalog and wonder if its ugly but honest soul could be made Z39.50
>compliant. 

This is an easy one - many library automation vendors (Ameritech, DRA,
SIRSI, etc.) offer Z39.50 modules for their systems.  These products are an
excellent choice for bibliographic data.

>For another example, we have all these little widgety
>databases--SARA this and RCRA that--which it would be great to cluster
>under a standard search umbrella.  How do we know?  What questions do we
>need to ask?

Loading local custom databases is tougher.  Your choices seem to be:
A. Load your data into one of the aforementioned library automation systems.
B. Export your data periodically and re-index it in a freeware
implementation of Z39.50 (ISite, Prise, Zebra, etc.).  Unfortunately these
systems seem to be designed by and for Unix systems developers.  Indexing
structured fields of data may be difficult.  You will want to match your
current field names with Bib1 or STAS standard fields.  This option should
work well if you have significant, available, in-house Unix expertise.
C. Export your data periodically and re-index it in a more mature freeware
package like freeWAIS-sf that permits mere mortals to install software and
index data with minimal system administrator support (about 4 hours for a
typical installation).  The problem with this is that WAIS is not compatible
with the current Z39.50 standard.  While intersearchability between WAIS and
Z39.50 servers is possible and has been demonstrated, it is not implemented
in any available software to the best of my knowledge.  (I would be
delighted if someone would prove me wrong on this.)
D. Use a commercial package like KE Texpress for database management and
generate HTML or other formatted search results on the fly.  KE Texpress
promises Z39.50 support in the 2nd quarter of 1996, others may have
implemented it already.  Note that this software may cost more than you want
to pay to support your "widgety databases".

>
>2. When a vendor says (as vendors have said to me), "oh yeah, XYZ is Z39.50
>compliant," what should my next questions be?  I am tempted to think my
>first question should be, "which version?"--which I suspect some could not
>answer--but perhaps there is a more direct question?

Ask for the list of Z39.50 clients they have tested with their server, the
URL for their demonstration page on the Web, and the URLs of other Web pages
that provide intersearchability of their server along with other servers
(like http://lcweb.loc.gov/z3950/gateway.html).

>3. As my organization evaluates WWW server options, what can I offer in
>terms of selection advice to facilitate a pathway toward Z39.50 for
>information services?

Right now the usual pathway is WWW form-> CGI script (Z39.50 client)
->Z39.50 server, so any Web server that supports forms and CGI should be
fine.  USGS and others are working on Z39.50 clients that add on to a Web
client, but until that approach is widely implemented I would advise
providing a CGI Z39.50 client at any site where you run a Z39.50 server.

>thanks for any light you can shine!

I hope that this has helped!  Z39.50 is a key technology in the development
of a global information infrastructure, yet the Library community has been
largely uninvolved with and uninformed about the evolution of this standard.
I am working to change that, as are others.

Kevin C. Marsh, Executive Director
Information Access Institute
KMarsh at Information.org     http://Information.org