| « Cooperative Cataloging | Staff Core Competencies » |

This double program attempted to introduce the audience to what Z39.50 is, how it works, and how it can be used. The morning program featured three speakers who described Z39.50 and how it works. In the afternoon, four panelists demonstrated how they use it in real life.

In the morning, Mary Jane Kelsey of Yale went over some of the basics of a Z39.50 interface. Kelsey first gave thought to Z39.50 when Yale acquired Innovative’s GUI catalog. She thought it would enable the kind of "better faster cheaper" workflow she wanted. Not surprisingly, things turned out to be a bit more complicated.

What Z39.50 does do is to enable OPACs to talk to one another. It means that you can search other, or "foreign" catalogs using the search interface of your catalog. Z39.50 is a NISO standard, and was begun as an attempt by LC, OCLC, WLN and RLIN to allow for cross-seaching of databases using the home search interface. Since 1988, the standard has been maintained by LC. In 1990, the ZIG, or Z39.50 Implementers Group, was formed as a way to further evolve the standard.

Complications arise from the fact that while Z39.50 is a NISO standard, the implementation of that standard is not yet quite standardized. In addition, a standard for searching databases cannot compensate for local practices, i.e. eccentric local authority practice. And, since Z39.50 is not a search engine, it can’t rank results for relevancy the way a search engine can. The first complication is perhaps the most difficult, but also the most likely to be solved. The Z39.50 standard allows for some options in how it is implemented, chiefly in allowing some variety in the way each library sets the "attributes" of its Z39.50 connection. One such attribute is "use," or access point, as in author, title, subject, etc. Suppose that your database allows subject access, and you then use it to search, by Z39.50, a database that does not have the use attribute "subject." You won’t get any hits. You may mistakenly suppose that the other library has no books on your subject. Without further research, it will not be clear that that database simply does not allow subject searching. Other attributes govern things like position, which specifies which position within fields data must occupy; structure, specifying type of search, i.e. phrase, word, year, etc.; truncate, specifying whether there is truncation, and if so, if it is left, right or both; and complete-ness, specifying whether the search term occupies an incomplete subfield, a complete subfield, or the complete field. What this means is, if you search another database whose attributes are set very differently from yours, you may get incorrect results. For this reason, most major databases publish guidelines to the way they have implemented Z39.50, and it is important to consult them when setting up connections to them. Also, there are default attributes that are supported by most major databases, which makes things easier.

To this end, a new effort at standardization of implementation is in the works. It is called the Bath Profile, and its efforts can be read at: http://www.ukoln.ac.uk/interop-focus/bath/. Since the Bath Profile seems likely to become the standard implementation of Z30.50, Larry Dixon, the next speaker, recommended consulting the Bath Profile if you are in the market for a new system.

Kelsey concluded her talk by stating that although "a standard doesn’t imply standardized implementation," a Z39.50 compatible database does provide the potential for cataloging at the point of ordering, does streamline workflow, and does by-pass the complexities of downloading from utilities in the traditional method.

Larry Dixon, of the Library of Congress, gave more background on how the Z39.50 standard came about, and how the implementation is being standardized through the Bath Profile. Ed Glazier, of Research Libraries Group, talked about RLG’s Z39.50 server, Zephyr, http://www.rlg.org/zephyr.html, which provides access to, among other things, three remote catalogs in Great Britain, Germany and Australia. RLG is also working on a project that would allow access to members holding information on their local servers though RLIN, so that an RLIN search would provide access to the more up-to-date holdings information available in the libraries’ local catalogs.

The afternoon session provided glimpses of Bookwhere (http://www. bookwhere.com), courtesy of Tim Knight. Bookwhere is a product that uses Z39.50 to make it easy for a library to search a number of different catalogs simultaneously, and to download the desired records into its own catalog. It can be considered a cheaper alternative to a catalog utility. Kathryn Harnish showed how Voyager uses Z39.50, Sandy Westfall demonstrated the same in Innovative Interfaces, and Pam Deemer showed the same in Sirsi.

| « Cooperative Cataloging | Staff Core Competencies » |