As of 22 April 2009 this website is 'frozen' in time — see the current IFLA websites
This old website and all of its content will stay on as archive –
During the early 1970's a group of Canadian academic libraries developed UTLAS, a shared cataloguing system which over the years became a second national-level union catalogue. Eventually the system was sold to the private sector and is now a commercial system owned by a-g canada ltd. This database supports a number of cataloguing and reference activities but also acts as a second union catalogue for Canadian libraries.
Many regional union catalogues also exist in Canada. Some are based on CD-ROM technology but most of these are evolving towards being on-line catalogues available via telnet, web, or Z39.50. Eighteen union catalogues exist which contain the holdings of public libraries, but these catalogues represent only a small percentage of the holdings of all 1,025 public library administrative units in Canada. The situation is similar when you look at academic, special and school libraries. A decentralized catalogue, thus, is the only practical means of comprehensively making available the holdings of most, if not all, Canadian libraries.
Between 1980 and 1985 a series of nationwide consultations were conducted by the National Library. These consultations provided a snapshot of the situation as it existed and formed the basis for the development of a national resource sharing strategy.
One of the fundamental principles of the strategy is that national initiatives will build on and enhance regional activities. Given the number of existing union catalogues identified during the consultations, a decentralized union catalogue formed by the linking of existing union catalogues and individual library databases was seen as a possible solution to the problem of creating a comprehensive national union catalogue. While the National Library is committed to maintaining and enhancing the existing national union catalogue the National Library does not have the human or machine resources to add several thousand Canadian libraries to the database. Since the late 1980's, Canadian libraries have been eagerly monitoring the development of the Z39.50 standard and, in 1995, the Canadian library community asked the National Library to make investigation of a virtual union catalogue a priority. This resulted in the vCuc pilot project.
Twenty-one libraries responded to the call for participation. They represented all types of libraries from all regions of the country, both anglophone and francophone. Some were already experienced users of Z39.50, whereas others had never used the software prior to the project. The participants were using different hardware platforms, including Geac, Ameritech, DRA, BestSeller, Sirsi, Innovative Interfaces, Endeavor, AMICUS, Zebra, and one locally-developed system. Of the original 21 libraries, 3 were unable to implement their servers before the end of the project. The list of participants is included at the end of this paper.
The majority of these libraries were large libraries. Representatives of small special libraries approached the National Library expressing concern that the needs of smaller libraries would not be taken into account. Consequently, a second group of participants was formed consisting of representatives from small special, government, college, and regional libraries. These libraries did not implement Z39.50 systems but used client software to search the target systems of the other participants. The client software was loaned to the libraries by Sirsi Corporation and SeaChange Corporation for the duration of the pilot project.
The purpose of the interoperability testing was to ensure that different vendor systems could communicate one with the other. The National Library provided sample bibliographic records which participants used to search each of the databases. These searches identified interoperability problems between systems. Once these problems were resolved, the main testing began.
During the controlled searching phase, the National Library again provided test records. Each tester was asked to search all of the available databases for these records, using specified search terms and indexes. The search results, including any error messages, were recorded and sent to the National Library for analysis. This analysis was instrumental in identifying the issues which are discussed later in this paper.
Once the controlled searches had been completed, libraries were asked to continue searching the virtual catalogue using requests received from their own patrons. The controlled searches had increased users' familiarity with the characteristics of Z39.50 searching on the various databases, so they were now able to select the databases which would be most appropriate for the specific request. For example, one database contained only scientific material in the French language and thus was an inappropriate choice if the request was for an English-language humanities title. Participants continued to note any problems which they encountered.
Evaluation questionnaires were sent to the original 21 participating institutions during April 1998. Separate questionnaires were included for the staff who had done the testing and the technical staff responsible for configuration of the software and maintenance of the Z39.50 servers.
The National Library, for its part, implemented a http/Z39.50 gateway based on the GeoWeb software of Geac Canada. The gateway was made available to a selected group of small libraries who were asked to comment on the usefulness of vCuc.
The vCuc was used during the project primarily for interlibrary loan (40.7% of the participants). Copy cataloguing was cited by 34.6%; and 11.1% used it for both interlibrary loan and copy cataloguing. Other uses included testing, reference and retrospective conversion. The majority of participants have continued to use Z39.50 since the conclusion of the testing, mainly for copy cataloguing and interlibrary loan. Of those who have not, the reasons cited were that it was too slow, not practical to use at this point, or not required for their work.
Over 81% of the participants found Z39.50 searching to be easy to learn because they were using their local catalogue interface; however, they did not find interpreting the search results to be as easy. Some had difficulty understanding the symbols used to identify the library which held an item when they searched union catalogues. This problem occurred not only when the database used locally developed symbols but also when the national standard symbol was used. This indicates that the use of symbols to identify libraries can be problematic. Ideally, the searcher should be able to click on the symbol and be taken to a directory which would provide the full name of the library, address information, policy information, etc.
Thirty-seven percent of the participants found Z39.50 useful for interlibrary loan. Those who did not cited as reasons the lack of holdings information, inconsistent search results, and slow response time. Problems with inconsistent search results were noted by several participants and, in fact, only 37% of the respondents thought they received accurate and relevant search results. Problems noted included inconsistencies created by differing definitions of what is a keyword search, problems created on some systems by the presence of an apostrophe, and retrieval of records irrelevant to the search.
The evaluation questionnaire included a list of features which could be included in a Z39.50 client and the participants were asked to indicated which were the most important, important and least important. The seven most important features (in no particular order) are:
Important features for the use of Z39.50 in a virtual catalogue environment are:
The least important features were considered to be:
Searching non-bibliographic databases is not a function generally performed by interlibrary loan and cataloguing staff, which may explain why it was not considered to be important.
Most of the participants had configured their client software in-house rather than using the default configuration provided by the vendor. The time required to configure the client for each database was minimal -- most cited about 15-20 minutes. This did not include the time necessary to track down the configuration information, which could take hours. The National Library's experience with configuring the vCuc gateway for each server indicates that the total process -- including configuration, identifying the server, acquiring the information and testing -- takes an average of about 7 hours per site.
The majority of the participants did not configure their servers themselves but rather used the configuration provided by the vendors. This took between 2 hours and 1.5 days. Ongoing maintenance and operation of the servers did not require significant staff time.
Vendors were viewed as being responsive to the participants and provided good support when difficulties were encountered. Some participants, however, felt that the documentation and training provided by the vendors were inadequate.
Over 81% indicated that they would use vCuc frequently for interlibrary loan, copy cataloguing, retrospective conversion, reference and collection development if an operational vCuc catalogue were implemented.
The specific benefits identified for a decentralized catalogue were:
One of the participants summarized the feelings of many when he stated: "as a general mechanism for searching information systems, Z39.50 is second to none. The limitations have far more to do with server implementations and the real complexities of information retrieval."
To date, however, participants have not identified service and policy issues, although it has been stated that a definition of the obligations of vCuc participation needs to be developed. Institutions which charge for access to their database are also wrestling with questions of charging policy, as well as the practicalities of how implement and monitor charging in this environment. Some are also raising questions of copyright concerning third party use of 'free' MARC records derived from cataloguing utilities such as OCLC.
One early proposal suggested that, if a target exports summary holdings with the bibliographic record, the information should be included in the MARC 852, 866, 867, and 868 tags. If necessary, the target would convert from the locally-used tag to these tags.
When this proposal was discussed with the vendors, it was rejected because to develop this type of conversion software is not a trivial task. The vendors indicated that they would prefer to implement the OPAC/Holdings Proposal being developed by the Z39.50 Implementor's Group. (1) This proposal includes a schema for an OPAC record to carry detailed holdings information, circulation data or summary holdings information within a Z39.50 result set. It is hoped that agreement will be reached on this proposal at the next ZIG meeting in June 1998. Even so, it will likely be 18 months or more before the proposal gets implemented in the installed base of Z39.50 systems. In the interim, holdings will continue to be a barrier to optimal use of a decentralized catalogue for interlibrary loan.
Location information is an essential piece of holdings data. The difficulty experienced by the testers in interpreting the symbols indicates that directory information giving library names and policies are necessary. Directories will form a vital component of the information landscape which must be defined to support the vCuc.
For example: a searcher may be looking for a book written by a specific author and may not want to receive hits for works where the specified name is the subject of the work. Some databases, however, have an integrated index which combines all name headings and so include hits for subject, even if the client system has specified use attribute 1003 author-name which does not include subject name headings. This type of mapping discrepancy can lead to very large result sets when using a virtual catalogue.
The definition of a keyword is also variable. Some servers will only search for author keywords, even if the searcher specifies a title keyword. Other servers will search for keywords in all indexes, even if the searcher specifies only a title keyword search.
The combination of attributes, especially position and structure, is very important. Within the project, the most commonly-supported structure attributes were 1 phrase, 2 word, and 6 word list. Many clients support structure attribute word; and if multiple terms are entered they use an implicit Boolean by 'and-ing' the terms together. Some servers, which support word list, cannot successfully execute a search when this is done and may produce strange results or return an error message. Other servers will reject a search if more than one term is included when the structure word is sent. Due to problems with the definition of word list, the Z39.50 Implementor's Group is now strongly suggesting it not be used although it has been implemented by several vendors with a substantial installed system base.
The use of a profile which defines attributes and attribute combinations will help to minimize these problems. A virtual catalogue profile (3) defining a minimum set of attributes and attribute combinations was drafted as part of the vCuc project. It is expected that all servers will support a much richer set of attributes, but the profile is intended to present the minimum required to facilitate simple inter-system searching.
Several other profiles have been developed by groups in Europe and Australia. (4) This proliferation of profiles is causing concern for the North American vendors, who are selling their products in a global marketplace. The vCuc project is now working with project groups in the United States, England and Australia to create a consensus for a common union catalogue profile.
The directory was created for the project by Scott Nickerson of Novanet, whose software has subsequently been used by the National Library of Australia to create a similar directory.
Throughout the project, vendors have been very co-operative. They have worked together to find solutions to problems of interoperability between the various systems. Project meetings between the libraries and vendors were informative, and the knowledge of the librarians about vendor concerns and the vendor knowledge of library concerns increased significantly.
Very early in the project, the National Library made a decision to be as open as possible about the project -- what we were doing and, more importantly, what we were finding. Several articles and presentations have been given, but the vCuc web site has been the most important means for communicating information about the project. (6) This site provides access to the Directory of Z39.50 Targets in Canada, to information about the Z39.50 standard, and to project reports and discussion papers about the use of Z39.50 in libraries. Eventually, the site will also provide a link to the vCuc gateway at the National Library when a vCuc service is implemented.
Z39.50 definitely has a role to play in the infrastructure of a virtual union catalogue. The virtual catalogue provides a good way to locate free MARC records, it fits into an interlibrary loan strategy when the usual location sources have been exhausted and the searcher needs to access an infrequently used database. Z39.50 is generally easy to learn, but some training is still required. Staff time can be saved. The issues identified in this paper must be resolved; and it will be important to identify solutions which can be applied internationally, since information retrieval is a global activity.
Z39.50 products are evolving, and the use of vCuc will evolve as the products improve. As products which are able to export and display holdings appear on the market, and as other issues related to searching are resolved, the use of vCuc will increase for interlibrary loan searching. Well-designed client software is essential for the acceptance and use of a decentralized union catalogue.
The project goal was to assess whether or not Z39.50 could be used to emulate a centralized union catalogue. The answer is that it can be used to emulate a centralized union catalogue for some functions. Potentially, it will be able to expand the capacity of a traditional catalogue. The table below summarizes some of the differences between a virtual and a centralized catalogue.
The features which are needed to maximize the ability of Z39.50 to emulate a centralized catalogue are:
In summary, Z39.50 cannot yet replace a well-managed centralized union catalogue; but it does provide an excellent means of searching catalogues which are accessed infrequently or for finding cataloguing copy. Over the next 2-3 years, as new capabilities are added to the existing products and as the issues identified in this paper are resolved, the vCuc will become a reality, creating a truly national catalogue by linking the major existing union catalogues and individual catalogues. In providing access to electronic documents through clickable links incorporated in cataloguing records, this catalogue will extend the capabilities of a traditional union catalogue. Links to other types of databases describing the collections of archives, museums and galleries will enable vCuc to act as a gateway to Canadian information. The end is in sight!