Hirst, 'Z39.50: Implementation and Impact', LITA Newsletter v15n04 URL = ftp://dewey.lib.ncsu.edu/stacks/serials/lita/lita-v15n04-hirst-z3950 V15N4.Z3950 LITANEWS -------------------- Z39.50: Implementation and Impact Donna L. Hirst This LITA program (cosponsored by the Online Catalog Interest Group and Technical Standards for Library Automation Committee, TESLA) was poorly attended as was virtually every ALA Miami program or committee meeting I attended. I do not feel that the poor attendance was due to lack of interest by convention attendees, but rather to the insufferable transportation complications in getting from meeting to meeting across the bay. The program was very informative, offering diverse perspectives on a large range of issues around implementing Z39.50 functions. The room was large, and the visual support for overheads was only marginally adequate. Mark Hinnebusch, as moderator, introduced the program and the speakers. The program was designed to offer strategies for implementing Z39.50 and also highlight challenges that have surfaced over the past year in implementing Z39.50 in particular systems. One Year Later: Z39.50 Public and Technical Services Issues at PSU Dace Freivalds (Pennsylvania State University) gave some background information about the Z39.50 connection for LIAS, Penn State's local system. LIAS serves 21 campuses with a DEC VAX 1000. The LIAS Client-Server software was developed though a grant from DEC. In January 1993, the EIP (EI Page One) database at RLIN was put into production at Penn State. Penn State experienced a number of Z39.50 problems as they first worked with the system. Keywords were searchable, but they didn't all display in the online catalog. Searchers would unexpectedly get logged off by the system. Initially there was a long waiting time (15 seconds) for a remote connect. The Use Attributes required some refining. Training and documentation for the public turned out to be difficult. Workshops were held. Online Help screens were created. Both handouts and newsletters were created. As additional databases were added, differences between the databases became apparent. The EIP database did not display subjects. Some, but not all, databases included abstracts. Some databases were available 24 hours a day, but others had limited hours. Valid commands differed from database to database. Even when using the same valid command, databases varied as to protocols for entering the value to be searched. The handling of truncation differed from database to database. Z39.50 does not allow retrieval of local information. Call number searching is not valid, and location information cannot be retrieved. Following Dace's talk, Sylvia Carson (also Penn State) addressed several Z39.50 technical services issues. In early 1992 Penn State implemented an import facility from OCLC to LIAS, but RLIN data had always been entered into LIAS manually. Sylvia limited her discussion of Z39.50 for technical services to the RLIN interface on LIAS. She described both a "compare" command and a "new" command. The "compare" works from the index and prevents redundancy when transferring records. The "new" command copies the record into LIAS. As with reference database searching, Sylvia described differences in commands between RLIN and LIAS, with some commands missing and some existing in only one of the systems. Large records were a problem, but a fix was made in LIAS to handle the large records. The clustered database in RLIN presented some complications. Z39.50 sends only the primary cluster member, but staff sometimes want one of the other records in the group. The call number is not transferred, so a subsequent search for the call number is necessary. Penn State wants to add an ID number search to support this function, and would also like to delete the 952 field during the transfer. Issues regarding cost are still open. Some early LIAS use statistics of Z39.50 have revealed that 41.1 percent of the users are public, 39.6 percent are staff, and 19.3 percent are remote. Z39.50: A Public Library Perspective, From the Outside Looking In Robert Carterette (Cleveland Public Library) described his experience with DRA software, Z39.50 and CLEVNET. Z39.50 access included remote databases such as General Periodical Index, FirstSearch and others. The success of the connection sometimes depends on characteristics of the remote database itself. Searching Art Index was very successful and links to local holdings were present. MELVYL, on the other hand, rejected author searches because no personal author attribute was present. When a new database was introduced, DRA created a configuration file for the database. A special display format was created and a unique help file was built. The startup file was defined. After the connection was made, a known result search was conducted to validate the connection. Robert relayed a few "war stories" related to specific databases. In FirstSearch, Z39.50 searching has less functionality than searching native FirstSearch software. The Disclosure database on FirstSearch presented special problems with Z39.50. In native mode, Disclosure is displayed in labeled columns. With Z39.50 the Disclosure data is very difficult to read since the formatted text does not transmit well. The Wilson Business Index does not allow a link to local holdings since the ISSN is in an 069 field. As with most computer applications, the environment is far from static. Servers vary in the version of Z39.50 that has been implemented, and the features present in different servers vary. Targeted databases vary in format and other characteristics over time. Proprietary interests continue to be strong. Carterette made two pleas for the future. He was very interested in CD-ROM vendors participating in Z39.50 development. He also indicated that a Z39.50 link based on an 856 field was needed to automatically launch access to the journal itself. Z39.50: Bibliographic Database Access and Beyond Genevieve Engel (University of California Division of Library Automation) discussed three separate Z39.50 projects active at UC DLA. They are trying to make various OCLC databases available via Z39.50. This work seems to be similar in level of work to mounting a local database, but no local storage is required. Additional user education will definitely be required. A second project, the TULIP project, will allow access to 43 online journals and is a cooperative project between the University of California and Elsevier. Through the use of a special TULIP password, University of California users will be able to search contents pages and also bitmapped images of the articles. Searchers will be able to page through articles using scroll bars. In exchange for access to the journal data, DLA will do statistical analysis on users of TULIP and share the results with Elsevier. DLA has enhanced their Z39.50 server to handle scroll bars, buttons and the transportation between different types of data. Printer options have been added so that a particular local printer is prompted for each device, but a user can alternatively enter another specific printer if desired. The third Z39.50 effort at DLA has been capturing circulation information from a DRA system on the Davis campus and adding this to the MELVYL system. The Davis circulation information now displays as a last line of the bibliographic display in MELVYL and is being tested now. The Z39.50 Holy Wars Several items were highlighted by Denise Troll (Carnegie Mellon University) as major goals of the crusades. Included among these were interoperability, maintainability and usability. Problem areas that affect these goals are error messages, character sets and attributes. Additional problems around communication and natural language were discussed. Z39.50 error messages tend to be obscure and confusing to users. Troll cited several error messages that have been confusing: malformed query; illegal case value; unspecified error; unsupported use attribute and temporary system error. Character sets have presented problems. Z39.50 downgrades everything to ASCII and systems lose information in the process. Z39.50 needs to support multiple languages and scripts. Attribute sets are ambiguous and can be difficult to map into a given system function. Communication through the server may be less precise than desired. Many systems haven't implemented the Explain feature and users may find difficulty in learning about features of the server. Denise suggested trying multiple searches using various features like phonetic searching, stemming (truncation), weakened proximity and stop words. Systems need to add natural language searching. Keyword Boolean retrieval is inadequate for full-text searching. Extending services beyond strict Z39.50 services need to be accommodated. Z39.50 needs to be able to pass a request for special services by utilizing a function like Explain Services. Four major functions are supported by Z39.50: create, modify, delete and permissions. Additional services of Z39.50 should include order items, database update, usage accounting, export specification and persistent result set. The issues around deleting and adding to a Z39.50 database are complex. For example, if a record is added, the status of an existing result set could become ambiguous. Z39.50: Not a Panacea In an overview session, Mark Hinnebusch (Florida Center for Library Automation) reiterated the purpose of this Z39.50 program as highlighting some of the problems in using the standard. He indicated that the most important problem to be aware of is the issue of complexity. Many variations and misunderstandings exist as to what the standard does. Retrieval drives a number of issues. Copyright concerns must be addressed. Implementing system security often introduces complexity. Billing and reimbursement can present difficulties. Indexing between systems varies, and these differences need to be resolved as completely as possible. Normalization of terms can result in variation in search results. Diacritics and especially punctuation can often be the cause of inconsistencies. Hinnebusch indicated that it would be desirable to provide users with subject-based menus. Users tend to be interested in general subject areas rather than particular database names. A challenge for the future will be interleaving results from searching citation, image and full-text databases. Z39.50 online services will dramatically affect library units. Interlibrary loan units are being overwhelmed. Users expect local holdings to be attached to remote Z39.50 databases, and availability of this information will drive usage of local collections. A reverse response from administrators may be, "Why buy these books or journals if you can get them via Z39.50 from other libraries?" Questions and Comments One individual asked about how someone could get caught up on the details of Z39.50. Mark referenced the upcoming book, From A to Z39.50: a Networking Primer by James J. Michael and Mark Hinnebusch. The book is being published by Mecklermedia and is expected in August 1994. Mark also indicated that acquiring the draft standard is an excellent way to learn about Z39.50. The standard can be obtained by anonymous ftp at ftp.loc.gov in directory /pub/z3950. The standard exists in PostScript and WordPerfect forms. Donna L. Hirst is Head of the Library Automation Office at the University of Iowa.