The NORDIC SR-NET PROJECT

Juha Hakala, Data communications specialist, Automation Unit of the Finnish Research Libraries (TKAY). P.O.Box 26, FIN-00014 Helsinki University, Finland (Juha.Hakala@Helsinki.FI)

Abstract

This article describes Nordic SR-net, a cooperative Nordic project funded by NORDINFO. The project aims to link the union catalogues of the Scandinavian countries using the OSI application layer protocol, Search and Retrieve (SR). This article describes the planning and results of the project, and also issues of interworking with Z39.50-based services. It describes the role of the SR protocol machine, considers some limitations of SR, and points to future areas of work.

Environment

The Scandinavian countries have a long and well-established tradition of co-operation. In the library and information services sector, NORDINFO has often funded cooperative initiatives. One of these has been the Nordic SR-net project, probably the most ambitious Nordic library automation project thus far. In this article I will give an overview of the project and its results. A glossary of terms used is included at the end of the article.

All the Nordic countries have well-established academic library networks, often using the national research network infrastructure to provide connectivity. [8] As a sort of jewel in the crown,  each has a central system (see Table 1) which contains the union catalogue of participating libraries and often several other databases as well. These central systems are managed by the National Libraries or by other organizations. In three cases (Denmark, Norway, Sweden), the central system OPAC and other software needed to run the system has been locally developed; in Finland and Iceland, third-party vendor programs (VTLS and Libertas, respectively) are used.

	--------------------------------------------------------------------------------------------------------------
	  Organization		  	Database
	-------------------------------------------------------------------------------------------------------------------------------
	 BIBSYS, Norway		Bibsys, the library system and union 
				catalogue for the university and research 
				libraries in Norway
	----------------------------------------------------------------------------------------------------------------------------------
	 DANBIB,  Denmark		DANBIB, the Danish union catalogue 
				for the research and public libraries 
	---------------------------------------------------------------------------------------------------------------------------------
	LIBRIS, Sweden		LIBRIS, the Swedish union catalogue for
				the research libraries
	---------------------------------------------------------------------------------------------------------------------------------
	TKAY, Finland			LINDA,  the Finnish union catalogue for
				the university libraries (incl. National
				Bibliography)
				MANDA, the Finnish union catalogue for
				the public libraries
	---------------------------------------------------------------------------------------------------------------------------------
	University of Iceland		GEGNIR, the Icelandic union catalogue
	----------------------------------------------------------------------------------------------------------------------------------
	University of Oslo, Norway		UBO:BOK, the Norwegian union catalogue
				and National Bibliography
				TRIP; includes NOSP, Nordic union 
				catalogue for periodicals, among many
				other databases
	----------------------------------------------------------------------------------------------------------------------------------

	Table 1. Nordic Union Catalogues and their maintenance organizations
	
Learning to use these systems or, more generally, the more than a thousand library OPACs available on the Internet, is difficult for librarians, and even more so for end-users. Very few can master more than a handful of OPAC syntaxes well, but there is a multitude of them awaiting the Internet browser. A further complication is the different native languages: Finnish, for example, is not widely understood in other Scandinavian countries, or Japanese in Europe. One of the problems the Nordic SR-net project  set out to solve, was how to give users easy access to Nordic Union Catalogues and other sources of  bibliographic information on the Internet, and hide them from problems posed by different OPAC syntaxes and native languages. 

The problem of interconnecting different library systems is a complex one. No project with this goal can - or should - start from a tabula rasa. In the case of the Nordic SR-net, success has been based on much well-founded preparatory work.

Background

In Norway, there have been experiments in library networking since the early 1980s. Bibnett projects 1 and 2 were carried out between 1980 and 1985 in BRODD by Liv Holm and her colleagues. These projects  yielded much information about how to connect library systems. [3] Without these pioneering efforts and those of the Linked System Project by the Library of Congress and partners in the US, it would have been difficult and time-consuming to develop the SR and Z39.50 standards. On the other hand, due to the involvement in pre-SR networking experiments and development of the standard itself, BRODD personnel had a keen interest in trying to develop SR gateways to production systems. 

Any networking project has to rely on protocols. It these are experimental or proprietary, the chances of attaining interoperability between many different systems are fairly limited. An international standard is often - though not always - the best possible protocol definition, as it will be stable and probably also widely utilised. For the SR-net project, ISO SR (ISO 10162, 10163) was a prerequisite. In fact, it is difficult to see how such a multinational project could succeed without a well-established international standard. [4] 

When SR version 1 was completed in Spring 1991, the idea of launching SR-based networking projects occurred simultaneously to several Nordic institutions. A plan for the Nordic SR-net project was designed in a joint effort led by Liv Holm with the goal of being able to offer SR-based operational services to the participating libraries by the end of the project.

Phases of the project

The project started in October 1991, managed by Liv Holm. Every union catalogue maintenance organization participated. Geir Pedersen from Institute of Information Studies (USIT) in Oslo University joined the group as programmer and network specialist. Each of the participating organizations promised to invest at least 300 work hours. The NORDINFO share of funding was about £300,000. The budget was not exceeded, even though the original dead-line was not met. The project was completed by the end of February 1994.

The SR-net project was carried out in seven phases. The first began by getting acquainted with the SR standard,  related ISO documents and other relevant sources. In 1991 it was not easy to find out about SR or about Z39.50 (Z39.50 is a US national standard which is parallel to SR. Version two of Z39.50 is largely a superset of SR, but see further comments below). ISO standards and ISO publications, the only information sources available at that time, were difficult to read and understand for the uninitiated members of the project group. Explanatory articles now exist for beginners instead of the original, somewhat cryptic ISO documents. [2] 

The group then defined the requirements of Nordic SR-net's SR implementation and an API between the library systems and the SR protocol implementation itself. The former is available as Appendix 7 of the project's final report (Profile for the SR protocol in Nordic SR-net), the latter as a separate document.[6]

In the second phase, the mode of operation and limitations of the networking tool ISODE were tested. With ISODE it was possible to implement an OSI network access module while using lower layers of the standard TCP/IP stack. The interface between OSI and TCP/IP stacks is defined in RFC1006. [6] The project group decided which protocols to use in the complete network stack. The project's aim was thus to implement SR on top of a hybrid network stack comprising OSI ACSE, presentation layer, session layer and transport layer, and TCP/IP lower layers. In addition, changes needed to the library systems were also charted in this phase.  

In phases 3-5, an implementation of the SR protocol, the so-called protocol machine, was built. The project group also designed conformance test tools. Implementation of changes in library systems was completed in two of the sites. Communication between the protocol machine and library systems was tested, and, finally, interoperability between origins and targets in different systems was tested. The last two phases consisted of real-life testing done with end-users, and reporting. 

For various reasons it was difficult to follow the project plan to the letter. Occasionally it was difficult to complete all the tasks defined in time, and sometimes early decisions had to be revised later in the project, for example, the network stack choice, to allow the project to take advantage of Nordunet facilities.

Aims of the project

The most important aim of the Nordic SR-net project was to implement SR and thus connect the Scandinavian union catalogue databases to one another and to Z39.50-based systems in such a way that the users could easily search remote databases with their own system's OPAC. I will report on this more fully in the next section; some secondary aims that are worth discussing here were:

1.	To increase the awareness of the use of library OSI protocols in the Nordic countries.
2.	To influence further development of the library OSI protocols.
3.	To simplify search and retrieval of MARC records from bibliographic databases accessible via Z39.50 targets (or 'servers').
4.	To prepare a basis for the general use of SR in the academic networks and in the library community by making a general implementation of SR available and reporting experiences gathered during the project. 

Although members of the project group have written several articles about the SR protocol and the project (see Appendix 2 of the Final report of the project [6]), more should probably have been done to inform librarians or other potential implementors in Scandinavia about the project. However, it is fairly difficult to popularise the SR protocol or other project issues in any detail to colleagues. In Finland, not many librarians are well informed about OSI library protocols or OSI services generally (or about TCP/IP services). Training and practical experience will change this fairly soon. 

It is important to understand the limitations of current SR and Z39.50 implementations, and to know if  they arise from the current versions of the protocols themselves or are due to choices made during implementation. These limitations cannot really be understood without some understanding of how these  protocols 'work'. The same applies to development of applications by vendors - it is difficult to steer the development work to the most promising areas, if the user population is not familiar with SR or Z39.50. Of course, participation to the development of the standard itself is even more difficult. Practical experience from the SR-net project has yielded some ideas on how the SR protocol should be enhanced in the future. These have been passed to ISO/TC46/SC4/WG4, which is responsible for development of SR. 

Interaction between SR origins (or 'clients') and Z39.50 targets (and vice versa) proved to be a more difficult task than the project group anticipated. According to the Z39.50 protocol, Z39.50 implementations should be built in such a way that they are fully compatible with SR implementations. In practice, Z39.50 implementors in the USA and elsewhere have not  included required SR-related features (like support for SR OIDs) in their programs. The reason for this is that there are still only a few SR implementations, whereas the number of Z39.50 implementations is growing rapidly. [10] And after the SR-net protocol machine was equipped with features needed for Z39.50 interoperability, there are even fewer reasons to add SR support to Z39.50 origins and targets. 

Finally, the software developed in the project will be released into the public domain. NORDINFO decided to do this. In fact, commercial entrepreneurs can acquire programs and other outputs of the project without charge; the only limitation is that they must offer their implementations to their users without charge. They can, of course, charge clients for support of their SR origin and target applications.

SR implementation

In this section, I take a closer look on the SR protocol machine and various related programs developed during the SR-net project. Some notes on likely future developments are also included.

The SR protocol machine on various UNIX platforms

An implementation of the SR application protocol, the SR protocol machine, was built on the UNIX platform. The services available are those listed in the first version of the standards document, i.e. Initialize, Search, Present, Delete result set, Abort and Release. SR addendi Scan and Explain (and other new services under development, like Access control and Resource control) were not implemented, as in 1992 there was a risk that they might change considerably before being passed by ISO. 

All the union catalogue databases involved in the project used different hardware platforms, which caused some technical problems. Bibsys and Libris run on IBM mainframes with different operating systems; the University of Oslo and the University of Iceland have DEC VAX/VMS computers; the new Danbib uses a DEC Ultrix system (Unix from DEC) and TKAY's VTLS software requires an HP3000 computer with HP's proprietary MPE operating system. Instead of porting the protocol machine to all different platforms, a decision was made to build the protocol machine on UNIX. As a result, most organizations had to buy a UNIX front-end. The UNIX computers chosen were supplied by DEC, HP, IBM and Sun.

One more benefit of choosing a UNIX platform was the possibility of using ISODE. ISODE does not run on operating systems other than UNIX, and not necessarily on all UNIXes either; all UNIX brands in SR-net front-ends (AIX, HP-UX, SunOS and ULTRIX) were known to be able to run ISODE versions 7 and 8. 

From the implementor's point of view,  ISODE has pros and cons. One benefit is that origin and target implementations using presentation layer  features can negotiate Init parameters in an effective way. The applications running directly on top of TCP/IP have limited capabilities in this area. More information on how to run Z39.50 (or SR) on top of TCP/IP, can be found elsewhere. [5] On the negative side, ISODE limits the number of application contexts that can be negotiated between the origin and the target to two. Neither in our experience does ISODE perform very well; this is partly due to the fact that ISODE reads the whole APDU from the network before it returns control to the application. 

Unfortunately, applications running directly on top of TCP/IP and those running on top of ISODE are not interoperable. Currently most US implementations of Z39.50 run directly on top of TCP/IP, due to (among other things) lack of suitable OSI tools for some of the hardware platforms on which the Z39.50 application development work has been done. 

In order to get the best from both worlds, a new version of the SR-net protocol machine was developed. The new implementation is able to run both directly on top of TCP/IP and through ISODE. In the former case, nothing of  ISODE was used but its ASN.1 compiler. The SR-net protocol machine is therefore capable of using OSI features when connecting to applications utilising OSI network access module, and switching to a 'plain vanilla' TCP/IP alternative when needed.

Had the protocol machine not been modular, this kind of dual stack capability would not have been possible. Modularity means that it is fairly easy to add new features to the protocol machine, or to replace old software blocks with new ones. For example, it should be easy to replace ISODE by an another program package capable of utilising the mOSI (minimal OSI) features currently under development. We hope that mOSI-based tools would eventually bring together the two approaches currently used.

The structure of the protocol machine at the end of the project is shown in Table 2:

	-----------------------------------------------------------------------------------                           
		LIBRARY SYSTEM
	-----------------------------------------------------------------------------------                           
	ORIGIN 			TARGET
	------------------------------------------------------------------------------ API            
		TOOLKIT 
	------------------------------------------------------------------------------ API                      
		THE PROTOCOL MACHINE
	------------------------------------------------------------------------------ API                      
		ISODE-SPECIFIC MODULE
	------------------------------------------------------------------------------------                          
		TCP/IP
	------------------------------------------------------------------------------------                          
Table 2: structure of the protocol machine

Any client/server application usually contains one or more APIs. The API is basically a library of subroutines that can be called or compiled into a program, depending on implementation. 

The SR-net stack contains three APIs:  the High Level API between the origin/target and toolkit, and 'ordinary' APIs between toolkit and protocol machine and between protocol machine and ISODE-module. The concept of a High Level API was conceived rather late in the project. Its purpose was to offer a simplified interface to the protocol machine per se and thus make application development easier. The High Level API 'hides' some of the error checking, reference ID control routines and various other details from the programmer. 

The SR-net project decided to use RPN as the query language and UNIMARC as a generic exchange format between the national MARC formats. Because Bibsys used CCL as it's internal query language, a decision was made to implement CCL-type queries also. There was also need to convert from various Nordic MARC formats to UNIMARC and vice versa. The toolkit part of the protocol machine is where these and many other conversion programs have been placed - for example, a program which translates SR OIDs to Z39.50 OIDs. 

The MARC conversion program package includes two programs. One converts from a Nordic national format, UKMARC or USMARC to UNIMARC, another from UNIMARC to other formats. The programs are written in ANSI C (as is the rest of the protocol machine) and they are based on the use of a conversion table, which contains all relevant data like tags, subtags and codes from the MARC formats. The table was built in close co-operation with national MARC response centres in order to guarantee the high quality of the final outcome. Several special procedures were needed for conversion in addition to the 'simple' conversion table. These include routines to split data from one subfield to several subfields, routines to collect data from several subfields into one subfield, creation of new tags, individual treatment of some 'difficult' tags and indicator processing routines. No data filtering is done to tags and codes used in national bibliographic level cataloguing. In fact, if there is no correct place for the tag to be converted, its contents are written into the tag 999. For the time being we do not know yet how successful the conversions for different formats and material types will be, as programming of the procedures is not yet quite complete. We hope that the conversion table and procedures will be kept up-to-date even though the formats are changing rapidly. 

There has already been some discussion about converting directly from one national format to another, as UNIMARC-mediated conversion tends to lose more data than direct conversion. Thanks to the modularity of our programs, it should be possible to use the conversion program as a separate product. It may prove its usefulness to many organizations looking for MARC conversion programs. If necessary, new MARC formats can be added to the table, and it should not be too difficult to add special procedures needed by these new formats to the existing programs.

Local modifications

The SR protocol machine was developed by Geir Pedersen and his colleagues at the Institute of Information Studies (USIT) in Oslo University. In the application environment, the SR protocol machine on a UNIX front-end computer had to be able to 'talk' with the local database management system. The work required for this was done by the participating organizations themselves, with some expert advice from USIT. The organizations, front-ends and the involved were :

	Bibsys		IBM, Adabas
			Protocol machine on a HP9000 using HP-UX and on 
			IBM 6000 using AIX
	DANBIB		UNIX, RDBMS
			Protocol machine on a DEC 5100 using ULTRIX
	Libris		IBM, Stairs
			Protocol machine on a Sun workstation using SunOS
	University of Oslo	VAX/VMS, TRIP DBMS
			VAX/VMS, UBO:BOK DBMS
			Protocol machine on a Sun workstation using SunOS

Of these, Bibsys has had both origin and target applications running since Summer 1993. They are integrated into the Bibsys software so that searches from remote databases in UBO can be done in the same way as searches from local databases, although, due to limitations of SR, much of the functionality built into the Bibsys search system is missing. Bibsys has also completed end-user testing; results have been favourable.

The University of Oslo has had an operational target application since Summer 1993. The origin application reached alpha status in Winter 1993. Libris started internal testing of a prototype target in March 1994; it is being tested against a rudimentary origin built into the High Level API of the SR-net protocol machine. According to current plans, the target should be made available to the other SR-net sites for testing purposes in May 1994. [9] DANBIB completed the successful transfer of its databases to a new hardware and software platform in January 1994. Therefore the work with SR implementation was postponed until March 1994. 

For the time being, the targets and/or some databases accessible via them, do not support all the features required for full interoperability with other SR/Z39.50 implementations. For example, Bibsys supports only CCL searches, though support of RPN search syntax was defined as a mandatory feature in the SR-net ISPICS, described further below. Moreover, not all target applications can use ISO 2709 as a transfer syntax. These limitations will be removed during 1994. For instance, we have scheduled the testing of the VTLS Z39.50 origin application against the Bibsys SR target for Summer 1994. 

Implementation of an SR origin may require many laborious changes to a library system's OPAC. To mention two obvious things: an SR-capable OPAC has to support creation (and deletion) of result sets, and there has to be a menu in the OPAC from which its users can choose the remote database they want to use. Depending on the current capabilities of the library system, these changes may require a lot of time and effort. Luckily, the systems involved in the Nordic SR-net project did not need extensive modifications, as the required functionality was largely already present in the systems.

Based on our experiences of communication between the SR protocol machine on UNIX and library systems on different hardware platforms,  it seems that there were no major differences between the library systems as regards the complexity of the implementation. It should be noted that the computers housing the Nordic union catalogues were already connected to the Internet, and in all cases the BSD or BSD-like TCP/IP sockets library was available as a part of the operating system. Without these prerequisites, the task of interlinking the protocol machine and the library system may have been a lot more difficult. 

SR-net results prove that it is  feasible to put the protocol machine software on a separate front-end computer. An additional benefit of this solution is that part of the extra computing required by the SR origin and target applications can be offloaded from the main system. Since an SR target sends full MARC records converted to ISO 2709 to the origin, which in turn converts the records to the form preferred by the end-user, the overhead required by these applications may be significant.

Conformance test suites

The International Standardized Profile (ISP) is a document which defines a meaningful way of implementing an ISO standard. SR ISPs for different network environments are developed by IFOBS, the International Forum on Open Bibliographical Systems. In short, the profile tells whether a service or service parameter defined in a standard is  mandatory,  optional or conditional. Any implementor should also fill an International Standard Profile Implementation Conformance Statement (ISPICS) proforma. In this document, he/she tells which services and parameters are supported, and what range of values a certain parameter may have in his/her implementation. 

The SR project group defined an ISPICS in a relatively early phase of the project, but it seems that not all other implementors do the same, at any stage of implementation. Non-availability of ISPICS documents makes assessment and comparison of SR (Z39.50) applications more difficult, and it definitely does not make testing Z39.50 or SR origin and target implementations from different vendors easier.

In spite of the existence of the SR ISPs, interoperability of different SR implementations is far from guaranteed. In part, this is caused by the complexity of the protocol, a common problem among OSI standards. Conformance testing is therefore needed to increase the chances of success. In SR-net, a tool  called PROTEST  was used to set up a test environment. The tool has been used by the Norwegian PTT to test X.400 implementations. PROTEST can establish an association to the implementation to be tested, construct APDUs and send/receive them. Some modifications to PROTEST itself were needed to make it possible to test the SR protocol machine.

Once PROTEST had been modified, the conformance test group defined the test suites and carried out the capability testing. In this phase, the group checked whether the protocol machine could send mandatory and optional PDUs. The group also tested the support for each of the subfields in PDUs, and support for the range of values possible for the different subfields. Finally a behaviour test was done; in this step the test group checked that the protocol machine behaved according to the rules set up in the SR standard.

Libertas and VTLS

The University of Iceland and TKAY in Finland do not use 'home-made' systems, but third party software. These are Libertas, from SLS Ltd, and VTLS, from VTLS, Inc. Both firms are working on Z39.50 implementations, which will interoperate with the implementations based on the SR-net protocol machine.

VTLS, Inc. is already marketing version 1.0 of it's Z39.50 origin. It requires a PC with Windows 3.1, a connection to the Internet and a Winsock implementation. The origin is a Z39.50-1992 implementation which for the time being doesn't have Access Control or Resource Control services. These and other new services will be implemented later. Like most Z39.50 implementations, the VTLS origin runs directly on top of the TCP/IP.

TKAY was involved with tests of the VTLS origin's beta version in late 1993. TKAY will also test the interoperability of the origin against the SR-net targets once they support RPN queries and ISO 2709 transfer syntax. Use of the Z39.50 targets in the US with the VTLS origin application has been an interesting experience. Response times over the Internet have been surprisingly short: it takes very little time to open a connection from Helsinki, Finland to, say, the Melvyl database in California. Search and transfer of records may take a while, but this is understandable since it is a time-consuming job to create a result set, build MARC records, convert them to ISO 2709 and send the requested records over the Internet to the origin application.
 
VTLS is also building an integrated target application for its library system. It should reach alpha status during Summer 1994. The target will later be ported from HP3000 to other VTLS platforms (HP9000 and IBM MVS/XA) as well.

VTLS licensed OCLC's API for its origin. SLS (Libertas) Z39.50 products and systems are based on the National Library of Canada's public domain 'IRtool' API and toolkit. This is a full Z39.50-1992 system running directly over TCP/IP. SLS Z39.50 origins will run on VAX/VMS and AXP/OpenVMS platforms as integral subsystems within LIBERTAS. The prototype Z39.50 target will run on MIPS/ULTRIX, with a view to porting to other platforms later.

The LIBERTAS origin should be delivered to users in Summer 1994. A Z39.50 target for research and test purposes is planned to be available then also. In early 1995, a production version of the target will provide Z39.50 access to the SLS MARC database in the UK. Enhanced versions of the origins will be more closely integrated to the LIBERTAS software. Beyond this point, SLS intends to enhance the NLC API and toolkit to support Z39.50-1994 (version 3) features such as Scan and Explain, and to introduce support for non-MARC record syntaxes suitable for document and image delivery. [1]

Further work

Following the project, all SR-net sites will complete their implementations. This involves some final details only on the Bibsys and UBO systems, where SR applications are already running. On the other hand, Danbib has considerable work to do before the SR origin and target are running. 

Once all the applications are ready to be used, it will be necessary to promote the new facilities and arrange training courses for end-users. At a later stage, interoperability of Z39.50-based SLS and VTLS origin and target applications against other SR-net applications has to be tested. Once this step is complete, interoperability testing against other Z39.50 targets will be carried out. The number of existing Z39.50 applications and the databases available via them is growing rapidly, so these tests will certainly be quite laborious.

An implementors' guide for organizations wishing to facilitate the use of software products developed in the project is also being planned. While the programs can be installed and utilised without any further documentation, a proper guide on how to do it will make it easier to build new applications based on the SR-net protocol machine. Since NORDINFO has made a decision to put all the code and documentation developed in Nordic SR-net into the public domain,  it is to be hoped that there will be several new SR-implementations based on SR-net protocol machine in the future. At the moment there are two rather important sites working with SR-net code, the British Library and Deutsche Bibliothek. 

The services as defined in the version 1 of the SR protocol are inadequate for building really user-friendly interfaces from one library system to others. New services like Access control, Resource control, Scan, Explain and Proximity should be added  to the SR standard. Once this has been done, it will be possible to build an enhanced version of the SR protocol machine which offers greatly improved user interface possibilities. It should be noted in passing that the Z39.50 standard already contains the first two services mentioned above. 

There are only three languages (English, Swahili and Hawaiian) that can do with the basic ASCII 7-bit character set. In spite of this, conversions between character sets are pretty much an open issue in any existing SR or Z39.59 implementation. To make the situation worse, implementors can hardly reach an agreement on using the same character set. SR-net uses ISO 8859-1 (with the exception of Finland's ISO 6937/2) whereas in Germany the DBV-OSI II project, which is also implementing SR-based applications, will utilise ISO646/5426 (UNIMARC character set), and UNICODE and ISO 10646 are waiting for the future use. Moreover, neither SR nor Z39.50-1992  define a way to handle character set conversions. 

The next version of the Z39.50 standard will contain methods for doing conversions between different character sets, as these methods are currently under development within the Z39.50 Implementors' Group. It may, however, take some time before the existing Z39.50 applications have adopted these conversion features. In the case of SR, because of the complexity of the ISO standardization process it will take quite a while before SR defines character set conversion procedures, even though the aim of SR developers is  to transfer new services from Z39.50 version 3 to SR as soon as possible. 

When the documentation (which is still quite limited) and some additional coding and troubleshooting have been completed, all Nordic SR-net project tasks are completed. However, the project group has no intention to quit SR-related work. A bid has been made for funding under the libraries programme of the EU. This is for a project which aims to a) interconnect the existing SR- and Z39.50-based applications in Europe, and b) add new services like Scan and Sort to the SR-net protocol machine. At the time of writing, this project is still under negotiation. It is called ONE, OPAC Network in Europe. Independently of ONE, there are also preliminary plans to implement the ISO ILL standard in addition to SR, in order to enable ILL procedures between the Nordic Union Catalogue systems, many of which are also important ILL service centres. In this way, we are working towards a framework for transparent user access to the collective bibliographic resource of the Nordic countries and beyond. The construction of systems and services based on open standards are a prerequisite for such a framework.

References

Unless otherwise noted, the information presented in this article has been extracted from the Final report of the Nordic SR-net project (see reference 6). The report will be published by NORDINFO in Summer 1994.

1. Davidson, Edward. Status of the Libertas Z39.50 implementation. Private communication dated 25.3.1994.

2. Hinnebusch, Mark: A primer on Z39.50. 8 parts. Academic and library computing, 8 (2-9), Feb.-Oct. 1992. (A thorough introduction to Z39.50 and related protocols like ASN.1.)

3. HOLM, Liv [et al]. Bibnett2 : communication between information systems on micros and mainframes. Oslo: BRODD, 1985.

4. ISO 10162 Information and documentation - search and retrieve application. Service definition for open systems interconnection. ISO, 1993.

ISO 10163 Information and documentation - search and retrieve application. Protocol specification for open systems interconnection. ISO, 1993.

5. LYNCH, Clifford A. Using the Z39.50 Information retrieval protocol in the Internet environment. Draft RFC document dated 30.4.1994. (Electronic message sent to multiple recipients of the Z3950-IW discussion list in May 1994).
(available as a working Internet draft <URL:ftp://nic.nordu.net/internet-drafts/draft-ietf-iiir-z3950-00.txt>)

6. Nordic SR-net: final report (forthcoming in Summer, 1994)

7. Rose, Marshall T. & Cass, Dwight E.: ISO transport service on top of  the TCP. Version 3, 1987. (RFC1006). <URL:ftp://nic.funet.fi/pub/doc/rfc/all/rfc1006.txt>.

8. Skogmar, Göran. Information networking in the Nordic countries: a Swedish perspective. Journal of Information Networking, 1(2), 136-156.

9. Skogmar, Göran: Status of the Libris SR implementation. Private communication, dated 5.4.1994

10. Z39.50 MAINTENANCE AGENCY. Z39.50 register of implementors. <URL:ftp://ftp.loc.gov/pub/z3950/register.post>  

GLOSSARY

ACSE	Application Control Service Element, part of APDU  which creates and terminates communications linkages (associations) between peer applications 
APDU	Application Protocol Data Unit, unit of information passed between two peer applications
API	Application Programmer's Interface
ASN.1	Abstract Syntax Notation One (ISO 8824), syntax for SR and Z39.50 PDUs
BER	Basic Encoding Rules (ISO 8825), set of rules according to which PDUs are encoded for transmission
BIBNETT	Bibliographic Network (R&D projects)
BIBSYS	Norwegian library system for universities, regional colleges etc.
BRODD	Research, development and consultancy department of SBIH
CCL	Common Command Language (a.k.a ISO8777)
DANBIB	Danish Union Catalogue for Research and Public Libraries
GEGNIR	Icelandic Union Catalogue for Research and Public Libraries 
HP-UX	HP's version of UNIX
IFOBS	International Forum for Open Bibliographic Systems
ILL	Interlibrary loan
ISO	International Organization for Standardization
ISO2709	ISO Format for bibliographic information exchange; may be used by SR as a transfer syntax instead of ASN.1/BER 
ISODE	ISO Development Environment
LIBRIS	Swedish National Library System and Union catalogue
LINDA	Finnish Union Catalogue for the Academic Libraries
LSP	Linked Systems Project, R&D project initiated by Library of Congress 
MANDA	Finnish Union Catalogue for the Public Libraries
MARC	Machine Readable Cataloguing
NORDINFO	The Nordic Council for Scientific Information
NOSP	Nordic Union Catalogue for Periodicals
OID	Object Identifier (concept in OSI protocols)
OSI	Open Systems' Interconnection, the common name for the ISO family of data communications protocols
PICS	Protocol Implementation Conformance Statement
PROTEST	Protocol Test System
RFC	Request for Comment, working notes of the Internet community
RPN	Reverse Polish Notation
SBIH	Norwegian School of Library and Information Sciences
TCP/IP	Transmission  Control Protocol/Internet Protocol, the common name for a family of over 100 data communications protocols
TKAY	Automation Unit of Finnish Research Libraries
TRIP	Swedish free text search system
UBO	University Library of Oslo
ULTRIX	DEC's version of UNIX
USIT	University of Oslo Centre for Information Technology
VTLS	Virginia Tech Library System
ZIG	Z39.50 Implementors' Group

.