JAFER is a project funded by the JISC. (http://www.jisc.ac.uk) in the UK under their Distributed. National Electronic Resource (DNER) programme. The.
JAFER ToolKit Project – Interfacing Z39.50 and XML Antony Corfield, Matthew Dovey, Richard Mawby, & Colin Tatham Systems and Electronic Resources Service, Oxford University Library Services 99 Banbury Road, Oxford, OX2 6JX, UK Tel: +44 1865 284454 [antony.corfield | matthew.dovey | richard.mawby | colin.tatham]@sers.ox.ac.uk query language used for submitting queries to the bean is based on an XML schema, so it can be passed to the bean as an XML structure. However, the bean also provides a QueryBuilder object which can be used to build the query programmatically. The query supported by the bean has the natural Boolean operators of AND, OR and NOT. Z39.50 however, has three binary operators AND, OR and ANDNOT. The JAFER bean applies de Morgan rules to convert queries using the more natural Boolean operators to the Z39.50 operators. The bean then handles the process of establishing a Z39.50 connection and issuing the search.
ABSTRACT
In this paper, we describe the JAFER ToolKit project which is developing a simplified XML based API above the Z39.50 protocol[1]. The ToolKit allows the development of both Z39.50 based applications (both clients and servers) without detailed knowledge of the complexities of the protocol. Categories and Subject Descriptors: H.3.3 [Information Storage and Retrieval]: Information Search and Retrieval---Query formulation, Retrieval Models; H.3.7 [Information Storage and Retrieval]: Digital Libraries---Standards. General Terms: Standardization, Experimentation. Additional Keywords and Phrases: Z39.50, XML, XSLT, Java, programming INTRODUCTION
JAFER is a project funded by the JISC (http://www.jisc.ac.uk) in the UK under their Distributed National Electronic Resource (DNER) programme. The DNER aims to produce a national managed environment for accessing high quality assured information resources. The DNER sees the Z39.50 protocol as one of the key components of this initiative, however the complexity of the Z39.50 protocol has prevented wide-scale uptake. The JAFER toolkit is developing a simplified XML based Application Programming Interface (API) above the Z39.50 protocol. ARCHITECTURE
The primary goal of the JAFER project is to produce a toolkit which allows the development of applications which use the Z39.50 protocol but which hides its complexities. In both the case of the client and server, the JAFER toolkit provides an abstraction layer above the Z39.50 protocol. As we developed the toolkit we based this abstraction layer very heavily on XML; in many aspects JAFER behaves as a bridge between Z39.50 and XML.
Figure 1 - JAFER Client Architecture In terms of record retrieval, the bean offers a record cursor based API. The function SetCurrentRecord is used to indicate the record of interest. The bean checks whether this record has already been retrieved into the cache, and if not then uses the Z39.50 Present service to pull down a number of records into the cache. Fine tuning of the cache behaviour can be achieved by changing the properties of the JAFER bean. The record can be accessed directly in its raw format, but the power of the JAFER bean is that it can present the record to the user in an XML format. This is a two stage process. An XML serialiser converts the record from its binary format to an XML representation of the format, for instance a MARC record (such asUKMARC, MARC21 etc. see http://www.loc.gov/marc) is converted to the Open Archives
JAFER Client
The JAFER client has been implemented as a Java bean so that it can be used in a variety of applications and environments. Its overall structure is shown in Figure 1. The Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. JCDL’02, July 13-17, 2002, Portland, Oregon, USA. Copyright 2002 ACM 1-58113-513-0/02/0007…$5.00.
289
an XML layer above the Z39.50 protocol, the server can be viewed as providing a Z39.50 layer above XML. This is illustrated in Figure 2.The server handles incoming Z39.50 requests by querying against an XML view of a database, and in this case uses a serializer when responding to Z39.50 requests to convert from a suitable XML format (for example OAI MARC XML) to the required binary format (for example MARC). The data-provider is responsible for providing a suitable XML view of the data. This may be a simple XSLT transformation if the data is coming from an XML database, or maybe an XML binding to a relational database.
Initiative (OAI) XML schema for MARC (http://www.openarchives.org/OAI_protocol/openarchivesprotocol.html#marc/). The record can be accessed in this format, but this is often not an intuitive format to work with. The bean can therefore transform this XML to a more “user-friendly” XML schema, for instance the OAI MARC XML is converted to MODS schema (a new schema for bibliographic records being developed by the Library of Congress). This transformation is controlled by an XSLT transform so can be configured as required. The whole configuration of the bean (such as serialisers and transformers for different record syntaxes) is also configured by XML.
The JAFER client bean may itself be used as an XML datasource for the JAFER server. This allows the construction of Z39.50 proxies for authentication purposes or additional record processing on the fly (for example providing record syntax conversion services). It also allows multiple separate physical Z39.50 services to be combined as a single Z39.50 server for the purposes of cross-searching. APPLICATIONS
We have used the JAFER toolkit to build a number of applications illustrating various aspects of the toolkit including its versatility and ease of use. These applications have been developed rapidly once the toolkit had been developed. The applications include: • • •
• • Can modify queries on the fly e.g. convert to Bath Profile queries.
Can modify record on the fly— e.g. adding URLs dynamically.
• •
Figure 2 - JAFER Server Architecture
An OpenURL (http://www.sfxit.com/OpenURL) to Z39.50 java servlet gateway A simple Java Server Page (JSP) based search interface More sophisticated cross-searching web interfaces based on JSP for the BookHAD (Book History and Design) project (http://www.bookhad.ac.uk) and the Music Libraries Online project (http://www.musiconline.ac.uk) A WAP to Z39.50 gateway A prototype Music Content search proxy developed in conjunction with the OMRAS project[2] Various reading list tools including a web based tool and a FrontPage plugin An experimental ZiNG (http://www.loc.gov/z3950/agency/zing/zing.html) to Z39.50 gateway
Given its XML nature, we are also developing interfaces so that it can be transparently used in XML publishing frameworks such as Cocoon (http://xml.apache.org/-cocoon).
The user of the JAFER bean can then process the XML record in a number of ways – they can use their own tools for walking the DOM such as a SAX parser; they can use a simplified interface supplied by the bean for accessing XML elements based on a GetField API, or they can convert the XML to a suitable form via an XSLT engine (the XSLT utility classes used by the bean can be re-used for this purpose).
REFERENCES 1. ANSI/NISO Z39.50 Protocol. http://www.cni.org/pub/NISO/docs/Z39.50.brochure/50.brochure.toc.html
2.
JAFER Server
The JAFER Server component of the toolkit is almost a mirror image of the client bean. Whereas the client provides
290
“Adding Content Based Searching to a Traditional Library Catalogue Server”. Proceedings of the First ACM/IEEE-CS Joint Conference on Digital Libraries, 2001. ISBN 1-58113-34
