Biblio Tech
Review
Information Technology for Libraries

Z39.50

Updated: 12 April, 2001


Picture

Tech briefings

RFID
ILL Update
Z39.50 part 2
Lotus Notes
Z39.50
Java, NCs and NetPcs
Databases
Barcoding

Advertise in BTR


The most focussed advertising resource in the library automation industry.
 

Line

Z39.50: Part 1- an overview

Obtain a PDF version of this complete Z39.50 2 part article - suitable for printing - for just £15 ($21.00) Click the Get-a-Copy icon

 

Contents

Introduction, Basic Z39.50, Basic Benefits, Search features, Additional features, Extended services, Implications for libraries, Cataloguing, SDI, ILL, CD-ROM, Web searching, Database updates, Z39.50 products and systems, Assessing products, Implications for suppliers, Problems, History, Sources, Configuration DiagramsProduct Reviews

Introduction

Z39.50 is an international standard for communication between computer systems primarily, library and information related systems.  Z39.50 is becoming increasingly important to the future development and deployment of inter-linked library systems.  This technical briefing aims to explain the substance and significance of the standard to library and information system managers. Part 2 of this briefing covers more of the technical detail.

Basic Z39.50

More technical detail will be given in part 2 of this article.  Here, just the basic protocol is outlined in non-technical terms. See also the animated diagram of the process.

The typical (simplified) search process involved in a Z39.50 session is as follows:

  • OPAC user selects Target library (Z-server) from an OPAC menu.
  • OPAC user enters search terms
  • OPAC software sends search terms and Target library details to a “Z-client”  a piece of software usually running as part of the library system.
  • Z-client translates the search terms into “Z-speak” and contacts the Target library’s Z-server software.
  • There is a preliminary negotiation between the Z-client and Z-server to establish the rules for the “Z-Association” between the two systems.
  • Z-server translates the “Z-speak” into a search request for the Target library’s database and receives a response about numbers of matches etc.
  • Z-client receives records
  • Records are presented to the OPAC interface for the user.

Basic Benefits

As is often the case, the basic technology is simple, but the ramifications are complex and far-reaching. Three key points have turned a process designed for simplifying a searcher’s life into a powerful force for changing all aspects of library activity.

  • Modern Z-clients can send requests to several libraries simultaneously either the same request or different ones.  This feature allows tremendous time saving when searching for rare items or for large numbers of records.
  • The basic record format used for interchange is MARC.  The Z-client is presented with a MARC record for display and possible further processing.  All libraries “trade” in bibliographic records one way or another. Z39.50 opens up that trade by making standardising the basic search and retrieve functions.
  • Extended services for ordering documents, updating databases and storing searches can be defined and controlled via Z39.50. By using Z39.50 as a basis, many other library processes, particularly ILL, can become “open”.

Some details

A full appreciation of the possibilities of Z39.50 comes from understanding what it can do.  Some of the more important features are listed here. More detail can be got from further sources and from part 2 of this article.

Search features

The latest version of Z39.50 (V.3 1995), allows extremely powerful search statements to be defined including:

  • Complex Boolean statements involving all the standard operators  AND, OR, NOT
  • Comparison operators for dates e.g. Greater than, equal to etc.
  • Proximity searching
  • Truncation
  • Completeness i.e. part of field, complete field etc.

Additional features

As well as searching, Z39.50 enables

  • Authentication allowing the Z-server to control who accesses their databases.
  • Accounting/resource control  to allow access to be charged for.
  • “Explain” facility to allow information about the remote database services available etc. to be transmitted to the Z-client.
  • Index browsing as typically available in OPAC systems.
  • Defining record formats e.g. MARC format

Extended services

Version 3 also defines how to use the standard to implement what are called “Extended services”. These are not defined in the standard but may use Z39.50 as a control method.  The types of tasks within the extended services area have been defined:

  • Save a result set for later use:
  • Save a query for later use
  • Define a periodic search schedule
  • Order an item
  • Update a database
  • Create an export specification

The implications for libraries as systems begin to implement these and the basic services are profound

Implications for libraries

The implications for the library and information services are profound.  Over the next few years, services will become “Z39.50 enabled” in much the same way that library OPACs have become “Web enabled”. The process will be somewhat slower than the Web revolution but more far-reaching and structural. Some possible effects on library operations are explored here:

OPACs

Many OPACs have been Z39.50 for a few years now. This is the basic benefit of Z39.50 operation for a typical user. Access any and all of the world’s major library catalogues or just the local sources with a single search.

Cataloguing

Bibliographic record sourcing.

Searching for and downloading bibliographic records using a Z39.50 tool is simple and very efficient since multiple sources can be searched simultaneously and records easily compared. Currently libraries are often “locked in” via service agreement and proprietary software to a bibliographic utility. A Z39.50 world will allow users to establish relationships with a variety of sources without penalties of complexity generated by different software. Resource control how much have I spent? is built in to Z39.50 to make management easy. Note that the ease with which “free” records can be downloaded from libraries creates copyright issues that must be addressed. Again the mechanism for notifying a source library that a record has been used for cataloguing purposes is built into Z39.50  implementation is the real issue.

Union Catalogues

Union catalogues - combined catalogues of several libraries - have been a valuable tool for decades within groups of otherwise separate libraries wanting to co-operate for inter-lending, co-operative purchase, and general reader service. They are, however, difficult and expensive to manage.  Even using automated systems the co-ordination and maintenance required can be daunting from both an organisational and technical viewpoint. Using Z39.50 enabled catalogues and OPACs, a “virtual” union catalogue can be assembled without any changes to the individual organisation's methods and procedures.  A user may sit at an OPAC screen and search several catalogues simultaneously as if they were one. Useful material and its location can be displayed with no additional work by library management apart from set-up of Z-clients. Ad-hoc groupings of libraries can be assembled to suit the needs of the users without any technical or administrative fuss. Colleges or companies suddenly merged or taken over, co-operative degrees, stock sharing schemes  any scenario where it might be useful to have a consolidated view of library and information resources is simple to set up and administer.

Inter-Library Loan (ILL)

The immediate benefit of a virtual union catalogue means that ILL is made easier the user can immediately identify the location of required items.  The extended services of Z39.50 allows systems to arrange for the delivery, including account verification and billing, of an item to the enquirer. ILL services are currently either mostly manual or rely on disparate incompatible services from the large suppliers like OCLC and the British Library. In a Z39.50 enabled ILL future, libraries will be able to search and order items in one operation and deal directly with whichever library serves their needs all via their own library OPAC search tools.

CD-ROM access

Despite the steady migration of CD-ROM information providers to Web based services, CD networks will be a feature of library services for some time. Apart from the idiosyncratic means required to force CD-ROMs to a networkable state, there remains the practical problem, when using them, of having to understand each different software interface and having to search each database separately.  Using Z39.50, it would be possible to search each database using a single familiar interface and, additionally, several databases at the same time. Z 39.50 also solves the problems of being able to use different clients e.g. Macs, UNIX Workstations - even dumb terminals could be used.  The SilverPlatter ERL technology actually provides similar facilities - but it is a proprietary standard and of limited application outside the CD-ROM area.

Selective Dissemination of Information

Version 3 of Z39.50 allows the user to specify search statements to be saved and run at intervals.  Thus the user may for instance identify useful libraries and information resources and set up SDI profiles using a single interface.  Searches can be automatically run when required and the results downloaded from the database to a specified destination e.g. fax or e-mail.  Z39.50 makes the much-vaunted Push Technology seem Stone Age in comparison.

Commercial Information databases

Library catalogues are only a fraction of the searchable information available.  There are hundreds of commercially available information service providers like Dialog, Lexis Nexis, FT Profile etc. These services allow very complex search statements and Z39.50 (version 3) contains equivalent search statements including proximity searching, term highlighting, image retrieval, individual chapter retrieval, specification of variant forms for downloading e.g. Word, Word Perfect etc.  Accounting and authorisation controls are also built in.  Again, by using Z39.50 protocols, the complexity of searching disparate databases can be reduced.

Web Searching and filtering

Searching the Web is frustrating for some of the very reasons that Z39.50 was developed i.e. many different search engines and user interfaces.  By adding an optional Z39.50 interface to Search Engines, much of the frustration and time wasting could be avoided.  The much-discussed topic of filtering unwanted areas of Web content could be attacked through an extended service. Each library could set their own filter parameters on the Z39.50 client used to access the major Search Engines.

Given the rapid development and constant vying for competitive edge in the Web Search Engine arena Z39.50 server technology has probably a low priority. As the benefits of Z39.50 begin to be appreciated by professionals, however, it will only need one Search Engine to add the feature and there will be an avalanche of followers.  See also a paper from Index Data for a useful discussion of Z39.50 on the Web.

Database updates

Z39.50 is not just a search and retrieve tool  as mentioned, extended services such as ILL are now being linked into the standard by leading companies.  Another task type that may be used as an extended service is updating a database. Thus a Z-client may for example retrieve a record from a database, edit it and then send it back to update the database  GeoCAT product from Geac illustrates this function nicely since it may be used as a standard tool with either the ADVANCE or PLUS Library Management systems.  Diagram.

Z39.50 products and systems

Z39.50 can be incorporated into all sorts of products and systems  only a few of which are currently being exploited. Z39.50 can be implemented on any computer system and so opens the way for true “interworking”. Thus a Mac Z-client can access a UNIX and a Windows NT based system simultaneously and seamlessly. See the System Diagrams for sample implementations.

OPACs

Integrated into a Library Management System (LMS), a Z39.50 OPAC allows users to search the local library catalogue and also to select from a set of library defined external library catalogues. This is the commonest use for a Z-client.  OPAC Z-clients can be on the desktop, on a local private LMS server or publicly available over the Internet. They can be built as Windows, UNIX, Java or Web clients  independent of the systems that they are accessing. See the system diagrams for examples.

Cataloguing and other clients

A cataloguing client normally communicates with the database in an LMS via a proprietary piece of software and/or SQL.  Geac's GeoCAT is the only example so far of a Z-client being used for catalogue update purposes. It works with Geac’s Advance and Plus but could work with other systems in theory.  By using a Z-client, it is possible to:

  • use one cataloguing tool against several databases from different vendors
  • update two databases at once
  • catalogue items remotely over the Internet e.g. to catalogue collections before they are physically transferred
  • Notify a bibliographic utility that a record has been used rather than just viewed for accounting purposes.

Geac have also built extended services for accessing patron records  so a user may request, look at account information, place ILLs etc. from a Web Z-client. Here the use of a Z-client is not apparent to the user but it has paid dividends to Geac since they have only one client to maintain against ADVANCE and PLUS.  See diagram.

Personal bibliographic tools

Several personal or stand alone Z39.50 clients are available as desktop tools for librarians and researchers whose local LMS does not have a Z39.50 capability.  BookWhere, SLS PC Browser and ZNavigator are good examples. Reviews of these products appear in Biblio Tech Review.

Z-Technology packages

The first companies with Z-products were the large system suppliers like Ameritech, DRA, Innovative, Geac etc. They provided both Z-clients and Z-server packages with their systems and so if you run one of the big systems you are “in the club” as far as bibliographic records are concerned. But what about libraries with systems that don’t have Z39.50 or with special collections not on their main library system?  One answer is to load a separate copy of your catalogue on a specialist Z-server database engine and buy a Z-client OPAC to view your own and any other databases.  Combinations of Z-client and Z-server software are being marketed as “Z-Technology” packages now. They typically provide Z-server, database engine with loading and indexing routines, PC Z-clients and Web Z-clients.  OCLC’s SiteSearch is a good example of such technology.

Assessing products

The assessment of Z39.50 offerings is tricky because the standard allows for differences in the implementation during the initialisation phase the Z-client and Z-Server agree what they can offer each other before starting out on a “Z-Association”. You need to do the same with a potential system supplier  these are the questions you need to ask yourself and your supplier.

  • Does the product have both Z-client and Z-server? 
  • Do you need both Z-client and Z-server?  It is fairly simple to bolt on a Z-client to an OPAC but more difficult to add a Z-Server to a database engine.  If all you want to do is to search other systems then a Z-Server may not be essential  but think about future ILL add-ons and users wanting to access you over the Internet using their own personal Z39.50 clients e.g. BookWhere.
  • Is the Z-client integrated with the OPAC?  One of the advantages of a Z39.50 is that it can provide a seamless gateway to other systems.  If you merely transfer from your OPAC interface to a Z39.50 interface then you lose one of the benefits  you may as well buy a stand alone Z-client and provide a link to it.
  • What version of Z39.50 is being offered? Version 3 has been out for 2 years and provides many more facilities for advanced retrieval and extended services like ILL  see part 2 of this article next month for details or check out the additional sources. If version 3 is being offered, get a list of the features supported. A product can be level 3 compliant yet offer none of the enhanced features. Check out accounting and access control on the Z-Server if you want to be able to charge for access to your database.
  • What is the development path for Z39.50? Is the product going to implement further features? Is there a “road map” for this development?  Will ILL become Z39.50 compliant?
  • Is the Web OPAC Z39.50 capable?  It may be that just the standard OPAC is Z39.50 compliant?  Or just the Web OPAC? Or both?  check it out.
  • How easy is it to set up?  A Z-client requires the librarian to administer the Target addresses, database names often how the data is presented to the user. Check out how easy this is to do.  See the reviews for Z-clients in Biblio Tech Review.  Try out the free versions on the Web to get a feel of how they work.
  • If you have just got a new system and it doesn’t have Z39.50 what do you do?  Look at the stand alone Z-client like ZNavigator and BookWhere and look at ways that you can integrate them into your operations. See the reviews.

Configurations

The Z39.50 standard is a messaging standard between an "origin" (Z client) and "target" (Z-server).  It does not determine how systems will be built, how they will present information to the user and so on. Z39.50 systems have been put together in many ways to suit different needs. Possible architectures are:

  • PC origin direct to target e.g. BookWhere, ZNavigator, SLS PC Browser. Diagram
  • User terminal (PC, dumb terminal Web browser) to local private origin thence to remote target e.g. Sirsi Unicorn.  The most common configuration for library systems. Diagram
  • Web Browser to shared origin and thence to target. Allows anyone with a Web browser to access any Z-Server. Needs no special PC software. Try out the Europagate Web Z-client. Diagram
  • PC Origin -- local Private Target e.g. Geac’s GeoCAT.  An illustration of how an extended service - catalogue update - can be used. Diagram.
  • PC origin  multiple local private Targets e.g. CD-ROMs - gets round the problems of many user interfaces.

Problems

It is easy to become enthusiastic about the capabilities of Z39.50 and the range of benefits it can bring in terms of library cooperation, reader services and systems integration. Make no mistake, Z39.50 compliant products will become the norm in a few years. However, there are some practical problems when using Z-clients that users need to be aware of. The problems revolve around the levels of service supported within and between the particular implementation of Z-client and Z-server and also the capabilities and implementation of the host Library Management System (LMS).

When building a Z39.50 Z-client, the designer has to decide which version and which features to implement. The standard defines many facilities and it is not necessary to implement all of them. Differences between the facilities on Z-client and Z-server are sorted out via a “negotiation” prior to a search taking place.  However the exact nature of the “discussion” is not usually relayed to the user interface and assumptions may be made about what can be achieved and what cannot.  For example, a local search may routinely search personal authors and corporates in the same index.  When applied to a remote Z-server, an author search may be personal authors only.

Combinations of such disparities and differences both in the version of the standard and in extended services supported are common.  This means that not all of the pain has been taken out of accessing non-familiar databases. Use “foreign” databases with caution.  As time goes on implementations are getting richer and great service benefits for libraries will accrue.  A standard feature of the Z39.50 standard designed to cover the problem of mis-matching of services is the “Explain” facility that allows a Z-client to ask a Z-Server what services it provides. Future clients will ask servers what they can and cannot do and present a description to the user of the OPAC to help them manage their expectations of the search.

For complex searching of some databases, users may always prefer to have the control and extra facilities of the original interface software rather than risk “losing something in the translation”.

Implications for Suppliers

All of the major suppliers now have some level of Z39.50 capability within their products. Amongst the smaller suppliers, the picture is patchy with some companies developing a leadership role e.g. Fretwell-Downing and others leaving the technology aside as they struggle for market share at the smaller college and corporate level.  These suppliers must begin to think Z39.50 if they are to offer products to libraries that want to co-operate with their neighbours.  Colleges share programmes with other colleges nationally and internationally. Corporate libraries may have branches worldwide. Even schools may find it useful to co-operate.  To assist with the demanding development curve, several companies now offer Z39.50 toolkits to help developers to get an implementation up and running quickly. Crossnet and Index Data are well established experts used by some of the big suppliers themselves.  A list of Z39.50 active companies and activities can be found on the LC list of implementors.

History

The Z39.50 standard was originally proposed in 1984 to provide a standard way of interrogating bibliographic databases. Since then, it has gone through 3 versions - in 1988 (v1),1992(v2) and 1995(v3). Version 2 in 1992 also incorporated and became compatible with an ISO standard (10162/3) called Search and Retrieve.  Version 3 in 1995 extended the features of the protocol - it is this version that most suppliers are now implementing.  It is maintained by the Z39.50 Maintenance Agency - administered by the Library of Congress. For more information on the history and future of Z39.50 see Clifford Lynch’s article in D-Lib April 1997.

Further Sources

Top of page