The IDS is a fairly recent construct: Directors' meetings started in 1994, as KDH (Konferenz der Deutschschweizer Hochschulbibliotheken). In 1996 it became clear that all members had to find a new library management system, and it was decided to evaluate together, with the aim of close cooperation on various levels and beyond simply using the same technology. In 1997 the collective decision was taken to adopt Aleph - this was a first proof of cooperative synergy: it was possible to conduct an in-depth evaluation within year by pooling the IT-specialists of the 7 libraries. At the same time, we decided to adopt US-MARC as a basic underlying format and adopt new cataloguing rules on the basis of AACR2. In 1998, the contract with ExLibris was signed, and the implementation process started. Autumn 1999 saw the switch to production with the new LMS in all 7 libraries, another major proof of cooperative synergy: it took us only one year to convert several old databases (using four different LMSs!) to one new system with a common set of parameters and look-alike OPACs for all libraries, based on one MARC format.

The year 2002 saw the laborious migration to version 14 of Aleph 500; in 2003, we implemented SFX; in 2004 the Shared User File (SUF) was ready; in 2005 we migrated to version 16, and 2006 will probably see the implementation of MetaLib in several libraries as well as a portal for the whole of the IDS.

The aims we want to reach with the IDS are twofold: first we want to make use of as much potential synergy for technical services as possible. For this, technology is not an aim in itself! We tried (and try again and again) to find organizational structures and means that allow us to cooperate while maintaining the fierce independence dictated by political and cultural tradition as well as by very limited financial means. Thus, the central coordinating resources are quite weak: we have only 2.3 posts that are financed centrally, and we do not have central IT structures. If a server, e.g. for MetaLib or indeed for the shared user file, is necessary, it is usually set up and run by one member, and all members pay their share. As far as the cataloguing goes, we aimed for a common and unified set or rules for cataloguing based on a widespread standard and changed as little as possible; it should allow for easy copy cataloguing from other IDS libraries but also from external sources. The result is the KIDS, the cataloguing rules of the IDS. We also wanted to keep open the possibility of a union catalogue, but realized that the initial input, for both finances and human resources, as well as the amount of coordination necessary to maintain it, were far above what we were prepared and able to invest. We do have a coordination group for these cataloguing rules, but it helps to keep a common ground and to prevent too much individualism in each library rather than control strict adherence to some pure ideology. It was also important to us to keep integration of interested smaller libraries of higher education institutions into one of the local networks as easy as possible - all members of the IDS are of course at the centre of their own local networks of libraries. We still have a few visions for further developments: one is a unified subject catalogue, or at least a common project for enriching and evolving subject cataloguing. Another vision reaches for better collaboration in collection management, for storage as well as for acquisitions, but they are still in a state of being thought about and toyed with rather than forcefully and purposefully pursued.

The second important aim we want to achieve with the IDS is user-service-driven: we want to make searching the holdings of the participating libraries as easy as possible, and we want to facilitate the use of the participating libraries as much as possible. Easy searching prompted the unified look and functioning of all 7 OPACs, and led to the implementation of a one stop search facility over several or all IDS catalogues at the beginning of our cooperation. It also helped to bring unified linking and portal technology to the network: SFX was working in 2003, MetaLib is working in two libraries at the moment and about to be rolled out in others as well as for the whole IDS. And we have attempted to make the use of all participating libraries easier by:

• creating one library card for all seven libraries: one side is identical for all IDS libraries; it contains a barcode in a common format with a letter as prefix that defines the library; the other side can be designed according to the needs of each library - it just has to contain the sentence "Each library applies its own circulation conditions" in German and French;
• unifying the circulation conditions and charges for the large, central libraries;
• making ordering from other IDS libraries easy;
• delivering books and other media to the user's home address or to another library.

The main character: the shared user file (suf)

What, then, were the reasons for going further? We lacked a few features we really wanted, above all a true one-time registration for all seven libraries. While our card was valid for all IDS libraries, it was still necessary to register in each library separately. We wanted, in other words, to enable patrons who are already registered at any one IDS library to log in and order at any other IDS library immediately - in the library or on the web; and to guarantee that their orders be processed without further identification.

If we could achieve a one-time registration, we would also need a feature that would replicate changes in patron data to all IDS libraries used by the patron, but we wanted to keep the lending process and control over it easy. We therefore decided that control over circulation should stay with the lending library. That meant two things:

1. the issuing library gets a set of the user’s data from a central database and stores it in its own circulation module;
2. contact between user and library is limited to the lending library and the user - regardless of the library that serves as point of delivery or drop.

In short: The loan of documents should be booked and controlled by the issuing library without the need to retype the patron data - i.e. comfort without loss of local control!

This was achieved by setting up a stand-alone server that contains a separate Oracle instance and a separate Aleph installation (see Figure 2).

Figure-2: The Shared Users Database USR01 and its connection to the other library servers.

It effects the following procedures:

• upon a new registration, which is always done in one of the local IDS systems, an automatic, real-time replication of the basic data into USR01 is triggered;
• if a user comes to an IDS library for the first time, the circulation module automatically searches USR01 to see whether he is already registered in another IDS site; if so, it triggers a download of the data into the circulation module of the new library's system;
• updates or changes in a user's address etc. are replicated into USR01, and from there into all local circulation modules that keep this user's data already.

The data set that is kept in USR01 is a reduced set of data; it contains name, date of birth, address, phone no., and email address, in the patron-MARC-format. When a user is registered in a library for the first time, he is asked whether he agrees to have his data saved in more than one place. If he does not want to have his data sent to USR01, replication is prevented - but then he cannot make use of other libraries as easily, and he will not be able to profit from other central services (which will be outlined below). These two measures - making people aware of the fact that their data can be put on to another server, and the possibility of preventing replication - were necessary, but also sufficient to comply with data protection laws.

When the shared users database was set up and started working properly, we initiated a retroactive merging and cleaning up of duplicate user records. That means that users who were already registered in more than one IDS site and had one or several user cards already, were 'reduced' to one entry. That was an automated process if a minimum of pre-defined data fields were identical. If not, de-duplication had (and still has …) to be done manually by circulation staff.

The replication model is a technically complex one. Why did we choose it? I would like to explain that by looking at two other possibilities. First, we could have chosen to work with only one big user database, which would serve all IDS sites. It might have been easier to set up, but we would have a very large file in which it could be difficult to find a specific set of users. And if this one database was 'down', circulation for all IDS sites would be down. Furthermore it would place much stronger constraints on the strict unification of all data fields; now, the different sites still have quite a lot of freedom for specific data, and especially for tailored statistical information they need. Finally, the one thing that the replication model does not allow is an IDS-wide suspension of a user; this would have been easy to realize with one user database. Indeed, we had a few discussions about the need for a measure as harsh as that. We decided that we did not want an IDS-wide suspension that could be triggered by one site with a 'simple keystroke'. Rather, we intend to trust old-fashioned communication channels: if a user is displaying behaviour that justifies suspension beyond one library, we have to talk to the circulation people at the other libraries. On the other hand: if a user does not bring back a book in time or pay his fines immediately in one library, is that reason enough to adopt measures that are more or less automatically valid in all other libraries?

Secondly, we could have done without any central database and programmed a process of a ‘distributed real-time look-up’ that would kick in each time a user wanted to order or register without being already registered in that specific IDS library. The look-up process would have to take place in all IDS circulation modules. We realized that this was, technically speaking, quite a bit more complex than the central shared user file, and that, above all, it would create unforeseeable data traffic loads.

These models helped us decide that the shared user file was the right solution for what we were looking for, but did it bring the success we aimed for - i.e. does it work?

Does it work? Is there a happy ending?

Yes, it does. Users like it very much - the comments we hear in the libraries are very positive and the numbers prove it: the switch to production of the SUF took place in April 2004. At that moment we had some 20,000 multi-library users. A year later there were roughly 38,000 - almost a redoubling. The circulation people also very much appreciate that their work has become easier; they like the speed with which a user can be accepted, and they really like to demonstrate that speed to the users! There were a few fears, to be sure. The fear, for example, that they could lose control was soon dispelled, as local control remains firmly local; it is just some of the tedious processes that have become a lot easier. Another fear concerned much-used holdings - would they be overruled by people from outside one's own region? It has not happened up to now, so this fear, too, proved not to be justified, even though Switzerland is a small country, and the main cities, Basel, Bern, Zürich, Lucerne are about an hour's train ride apart from each other, and St. Gallen not much more - a lot of students study in one place and live in another.

Figure-3

We did have a few problems: one is that data traffic turned out to be quite heavy, and we have to make sure that the connections have powerful performance and are stable, and that the database service is really stable, too., What was more difficult, however, was the process of getting the SUF programmed and of arriving at the final stage. Though we presented ExLibris with a request and a clear concept in autumn 2000, we ran into a tedious stop-and-go project, aggravated by repeated programming troubles and changing responsibilities. In 2003 we were close to giving up, when programming and development were delegated to Germany. The pace and constancy of work on the project picked up, and after ten months of continuous progress we could finally 'go live'! The one big drawback is that the programming for the replication process is done in the proprietary 'Aleph messaging format' which makes it nearly impossible to integrate other libraries into that scheme, especially libraries that use a different library management system. And finally, we are not sure about the long view; we already notice that for ExLibris the SUF has not first priority in changes of versions…

On the whole we are quite pleased with the feature and its performance at the moment, but more than a little uncertain about the long term development. This could turn out to be very important, because we have started a few projects that are based on the shared user file as it works today.

What's on the horizon? Projects based on the suf

Of course, we do have a few ideas about how to develop or enhance the SUF. I would like to look at two wishes within the IDS and at two ideas that go beyond the IDS.

Within the IDS, the next step we would like to reach is to have one single login. Today, if you search across all IDS catalogues and find books in several libraries that you want to order, you have to log on to each library separately. A single login would mean that a user could do with one login only, which would grant him access to the password-protected services of all the libraries he is entitled to use.

Similarly, we would like to introduce a unified display of a user's various accounts. If a user today wants to check his accounts in each of the libraries he uses, he not only has to log on to each library, but he also has to open each account separately. Wouldn't it be nice if his account showed him all the data from the different libraries in one session?

Beyond the IDS we are trying to work out a way of expanding the SUF scheme: we would also like to integrate the IDS partner institutions, like the local library network in Aarau (KB AG) or in Chur (KB GR) etc. (see ill. 1). The expansion would enlarge the potential number of users, but we do not think that it would create problems, e.g. depleted holdings. On the other hand it would allow us to include these partner institutions in projects that are based on the SUF (see Figure 4).

Taking these considerations yet a step further: it might be possible to expand the SUF to encompass the libraries of the Réseau Romand, the network in the French speaking part of Switzerland, and the SLB (Schweizerischen Landesbibliothek), the Swiss National Library. The Conference of Swiss University Libraries that unites the IDS, the Réseau Romand and the National Library has wanted to help facilitate access for users from the various universities for quite some time, and the SUF seemed like an interesting way to achieve that aim, [1] all the more so because the SUF does not prevent differentiated user privileges. However, the main problem is that the programming of the SUF is done in a proprietary format that is very difficult and expensive to adapt to the integration of another LMS. We have not yet started work on this problem; above all, perspectives for the future of the SUF within ExLibris would have to be very clear.

But while the SUF in itself has been quite a success within the IDS libraries and for their users, it turned out to be an ideal basis for another service that has proved to be very attractive: the IDS-wide pick-up service. It was introduced in January 2005 with 4 participating libraries (Basel, Bern, Lucerne, and the Zentralbibliothek in Zürich); in April 2006, a 5th library will join the scheme (St. Gallen). It allows a user to order a book directly from the catalogue of each participating library and to determine the place of its delivery. Having finished with the book, he can give it back in any of the participating libraries (see Figure 4).

Figure-4: A screenshot showing the possibility of ordering a book from one of the pick-up libraries and determining the place of delivery.

On the side of the libraries, only the issuing library is involved, as it controls its lending to the user directly, not through an intermediary library, but one might ask whether this is really special. It is, we think, and perhaps a look at traditional ILL can highlight the differences:

• From the user's point of view the pick-up service is less hassle, more comfort – he can order directly through the catalogue from any of the participating libraries, he can fix the place where he wants to have it brought and he can give it back wherever he pleases! Finally, no ILL process matches the speed of delivery: we guarantee 48 hours, though it usually reaches the user within 24 hours, yet it is still cheaper than an ILL loan. (Yes, we do have to charge the users for an ILL loan or a pick-up delivery.)
• From the library's point of view the pick-up makes quite a few things easier: there is no double circulation control, as only the lending library is in direct contact with the borrower. The only two things that a non-involved library has to do is, first, to keep the book at the ready for a user that ordered his book delivered to it, and, secondly, if it serves as the place of return, it has to book it back into a transfer account to make sure that the user is not charged wrongly. Furthermore, the library just puts the books ordered or brought back into a transport box - no packaging, no stamps, no queuing at the post office, etc.

This project, the IDS-wide pick-up, was only possible because of the basis of the SUF. Both projects have found wide acceptance, among the users as well as among the libraries, and we will try very hard to keep these levels of user services, even if the original support cannot be guaranteed. Finally, both projects are fine examples for cooperation: once you start the process, ideas for taking it further will come automatically, and it is hard to stop…

Acknowledgement

I would like to thank Oliver Thiele, now responsible for information within the user services at the Zentralbibliothek in Zürich, at the time of the realization of the SUF coordinator for the IDS. His information led me to understand the deeper issues of the project (but of course any errors would still be mine).

Web sites referred to in the text

AACR - Anglo-American cataloguing rules. http://www.aacr2.org/

Aleph integrated library system. http://www.exlibrisgroup.com/aleph.htm

BibliOpass. http://www.bibliopass.ch/

IDS - Informationsverbund Deutschschweiz. http://www.zb3.unizh.ch/ids/

KIDS. http://www.zb3.unizh.ch/ids/KIDS/A0-KIDSInh.pdf

KUB - Konferenz der Universitätsbibliotheken der Schweiz. http://www.kub-cbu.ch/

MetaLib library portal. http://www.exlibrisgroup.com/metalib.htm

RERO - REseau ROmand, Réseau des Bibliothèques de Suisse Occidentale. http://www.rero.ch/

SFX link server. http://www.exlibrisgroup.com/metalib.htm

SLB - Schweizerischen Landesbibliothek. http://www.snl.admin.ch/slb/

Notes