Scope and methodology issues

  The aim of this report is to provide an overview of the present state of development of integrated library systems (ILS) at the time of writing and to identify, describe and evaluate significant trends in the industry in relation to their context within the overall development of library services[1]. <>The development of integrated library systems needs to be considered in the context of trends, strategies and technical issues within the overall information environment. These include, for instance, electronic library developments within particular sectors, metadata initiatives, and organisational issues such as the convergence or integration of libraries with knowledge management or computing services. For the library, the fundamental challenge is integration, and in particular designing ways of navigating the wide range of resources using cross-searching and linking tools. Libraries’ decisions about what to automate and why depend closely on the overall direction of their mission and service policies.

A major problem for the non-computer scientist is the sheer pace of development of Web-related technologies and the welter of activity that has taken place over the last few years in establishing technical standards. To maintain even an approximate grasp of what is happening one is dependent on the non-specialist computing press and on interpretative efforts of a few experts providing commentaries for the library world. Some of the more recent technological developments (e.g. XML query languages, the “semantic web”) have only recently begun to reach the library automation literature. The fundamental technologies used in library systems are generally well documented, but the manner in which they are applied to specific systems is often unclear. <> 

.A survey of this nature cannot attempt to examine all aspects of library systems. I have chosen to focus in particular on:

1)    developments in Web technologies and standards, and their implications for integrated library systems

2)    overall software industry developments

3)    enhancements in functionality and information access from the user’s perspective.

  Thus I do not consider developments in technical services (acquisitions, interlending or cataloguing) functionality as such; also I do not cover issues, such as reference linking and authentication, that relate specifically to e-book or e-journal management. This means the omission of OpenURL, EDI, and the implementation of interlending protocols. While attempting to discuss the implications of technical developments, I have excluded discussion of complex proprietary networking standards.

 Integrated library systems: general overview

  What is an “integrated library system”? Saffady (2000) offers the following definition: “an interrelated group of computer programs that automates multiple library operations”. Cibbarelli (1999) refers to the provision of integrated online access to the library catalogue and to cataloguing, circulation, acquisitions and serials management functions. As an overall framework, it is useful to have in mind Borgman’s (1997) identification of three stages of library automation. These are as follows:

1)    improving the efficiency of internal operations, through improving internal work flow and sharing catalogue data

2)    providing access to local library resources, through the provision of OPACs and through retrospective conversion of card catalogues

3)    providing access to resources outside the library.

  The next stage, according to Borgman, involves a) enhanced facilities for identifying, locating and obtaining documents; b) bibliographic data exchange, and c) integrating local collections with other types of information resources. She suggests that library systems development has now reached this further stage, where the dominant theme is that of: <> 

     4)    ensuring the interoperability of systems<> with an related tendency towards modularisation and fragmentation. <> 

In relation to this fourth stage, other writers have speculated that the integrated library system is essentially a product of the 1970s/1980s and may cease to exist as such in the twenty-first century. Healy (1998) and Evans (1998) question the need for libraries to continue investing in specialised library management systems, suggesting that more generic Web-based information retrieval systems may provide a better means of integrating library content.). It is suggested (e.g. by Rhyno (2001) that the advent of Web services may spell the end of the integrated library system as we have known it, leaving instead a “library applications framework” (LAF) (see the discussion of Web services, below). This is more a matter of system architecture, however, than of functionality; it is difficult to see how the functionality of today’s integrated library systems in respect of the automation of library processes and resource sharing could readily be superseded.

Most of the developments discussed below relate to these stages 3) and 4).

Bilal (1998) estimated that the library automation industry worldwide was worth US $498 million. According to Barry (2001b) this figure had shrunk in 2000 to US $440 million. While it rose in 2001 to an estimated $530 million (Breeding 2002c), it is still too small to have an independent impact on computer industry trends; it needs to capitalise on what is being developed and led elsewhere. The Web has driven libraries towards huge investments in networking and new systems (Kisly 1998). A large proportion of vendors’ efforts over the last few years have been taken up with the migration of existing systems to keep pace with wider developments in computing standards (such as new operating systems, client/server architecture, the explosive growth of the Web and new Web technologies) and also in dealing with year 2000 issues.

  <>There are two basic types of system (Saffady 2000): those intended for larger academic or public libraries, and those intended for smaller libraries, such as school or special libraries. The division, however, is not absolute.

It is now typical for ILS vendors to provide systems that:

• use multi-tiered client/server architecture and TCP/IP networking protocols
• have Web-based OPACs
• employ graphical interfaces for library maintenance functions (sometimes a Web interface is available throughout a system)
• support UNICODE, hence the use of non-Western characters
• have an object-oriented architecture
• are built on industry-standard relational database management systems (RDBMS)
• are Z39.50 compliant (client and server)
• support the ILL protocol (ISO 10160/61)
• are EDI compatible

  <>There is in addition a trend in modern library systems towards a modular architecture based on software components and well-defined application programming interfaces (APIs); this allows much faster upgrading of software. This is relevant to the open source software movement, discussed below. One would expect that adoption of such industry standards would have facilitated the inter-operation of modules from different library systems; however, this has not happened in practice.[2] What is of significance, however, is the emergence of complex cooperative information environments using library portals based on “web services” (Cox and Yeates 2002a). Web services are discussed in more detail below.

 <>There has been a move to standardise on two main operating systems: Unix and Windows NT/2000. In a bid to broaden their market to smaller libraries (NT/2000 being considerably less demanding in terms of hardware requirements and hence considerably cheaper), vendors have frequently developed NT/2000 versions of existing Unix-based systems. At the desktop, Windows 9x/NT/2000 dominates, but the emergence of Java, Citrix MetaFrame, and Linux technologies offers some competition and variety (Evans 2000).

<>  <>The movement towards client/server from mainframe- or minicomputer-based systems began in the mid-1990s. The gain from client/server architecture is increased speed of operation, and less need for high-powered client PCs. Vendors generally aim nowadays to provide systems that are true client/server, as distinct from adding application-specific client/server components to mainframe- or minicomputer-based products.  Client/server systems separate the user interface and the application program from the data repository. Within client/server architectures there is a distinction between two-tier and three-tier, systems. In two-tier systems, the client software system has both the GUI and the application program, In three-tier systems, the user interface program still resides on the client, and the data on the data server, but a third layer, the application server, is interposed between them. The application components can be distributed over several machines. The software that connects the three components is known as middleware. Three-tier systems have numerous advantages. Database and network performance is improved, larger amounts of data may be handled, and software may be maintained more easily. Three-tier systems support so-called “thin clients” (such as Windows terminals) and permit different types of client within the same installation. (Saunders 1996, Saffady 2000).[AMC1]  <> 

It is frequently stated (e.g. by Breeding 2000a, 2001, Beaumont 1998) that integrated library systems are now “mature”, that is, have all basic functions and modules, and that the differences between them now lie in additional functionality and additional products that lie beyond the hitherto conventional boundaries of library automation. In practice, however, one encounters variations in emphasis in the stated development strategies of vendors and in the strengths of their respective systems, as exemplified by the following: <> 

Mikromarc: flexibility

Adlib: emphasis on the convergence of museums, archives and libraries

Autolib: use of XML

Fretwell Downing: interface consistency for technical services staff, flexibility, economy

Surpass: online bookshop-like OPAC features

EOSi: state of the art retrieval engine

Libero (Esprit): non-modular, robust, cheap

  <>According to Akeroyd (1998) “during [the last few years] new systems have tended not to provide hugely significant levels of innovation, except perhaps in terms of pure technology”. However, within the systems currently being demonstrated there do appear to be some significant new innovations in basic functionality, such as:

• the use of computer integrated telephony to provide automatic renewals, reminders and reservations: I-tiva (TalkingTech), Telecirc (epixtech)
• the use of radio-frequency ID (RFID) technology to permit easy stock checking and remote issues (3M, GemPlus)
• the facility to access OPACs via mobile devices : Innovative (AirPAC) (Breeding 2002a, Allen 2001)
• integration with virtual learning environments: Endeavor (VLEs) (Hamilton 2002, Cox and Yeates (2002a)

  <>and also other new features, such, eg.

• reading list management : Sentient[3]
• e-journal administration: Innovative, Endeavor/Serials Solutions
<>It is also likely that library systems will make use the emerging voice processing technologies (Phillips, 2001a, 2001b; Dendrinos, 2002) and of the identification systems (iris- or fingerprint-based) that are currently under development for self-service banking. A fingerprint-based system (MicroLibrarian) was displayed at the 2001 Library and Information Show.

<>  <>Another emerging major trend is that of integration of electronic content into library systems via partnerships between content creators or providers and library system vendors: Sirsi with Ebrary (Evans 2002), Talis with TDnet, Endeavor with LexisNexis, etc. Library portals are discussed in more detail below. <> 

It is typical for library staff, rather than vendors, to be at the forefront of library systems technology (see below, under “Open systems software movement”). Some vendors, such as ExLibris, support major research and development efforts. However, many innovations come from research projects or from large academic libraries that have substantial systems departments, and are subsequently incorporated by vendors into new software releases (Barry et al. 2001).  For instance, the reference linking system SFX was originally a research project at the University of Ghent (van de Sompel 2001), while the Talis Web OPAC started life as an experimental project at Loughborough University (Hulme 1996), and OLIB is explicitly based upon the OKAPI experimental OPAC research (McKiernan 2000). 

Although there are widely differing views as to how it should be done (e.g. Rhyno 1997a, Lease Morgan 1995, Baruth 2000) there appears to be a clear consensus among commentators that library technology in the 21^st century needs to 1) facilitate access to a hybrid information environment and  2) integrate library services with the Web. Akeroyd (1998) has suggested that the electronic publishing revolution will require more fundamental development work on integrated library systems; that it will be desirable to:

1)    provide full support for hybrid libraries (i.e. integrate multiple systems both of bibliographic and full text information)

2)    simplify and control access to resources and provide management information on their use

3)    collect, archive and manage access to diverse digital objects

4)    personalise resources

<>  and perhaps also to: 

5)    move to open source software

6)    integrate the library system with knowledge management systems

  <>He suggests that recent hybrid library projects provide indications of their possible future shape. There appears to be remarkably little cross-over at present, however, between digital or hybrid library initiatives and commercial library systems. Of the eLib hybrid library initiatives in the UK,[AMC2]  only the AGORA and BUILDER projects involved commercial vendors (Fretwell Downing, Talis) to any significant degree.[4] Mackenzie Smith, of the Harvard University Libraries Digital Initiative, has opined that, in her experience, system vendors appear to have little understanding of leading-edge digital library developments; also that, in any case, many experimental digital library systems are too specific to their institutional context to be patent of commercial exploitation.[5]5 The issue is that of the scope of the integrated library system within a hybrid or digital information environment. According to McKenna, however (1998), “library management system suppliers now see their new generation systems as the hub of the electronic library...They are, of course, essential tools, but are only one of a myriad of electronic resources”. <> 

It is clear that many system vendors are broadening the scope of their systems, providing powerful metasearching facilities, extended cataloguing functionality (e.g. the means to define a range of custom media types and to use metadata schemes other than MARC, such as Dublin Core, RDF and OAI) and providing additional products, such as customisable library portals, virtual reference services, reference linking systems, and enhanced content. The market is evidently volatile. <> 

The Library and Information Technology Association (LITA) “Top Tech Trends” web pages[6] provide a useful barometer of expert opinion over the last few years on overall trends in library automation. Among the trends identified by the LITA and other commentators are the following:

      1)    the impact of computer industry developments and standards (technical and metadata), in particular Z39.50, XML, Java, and Web services

2)    the use of customisation and personalisation technologies; the emergence of partnerships between integrated library system vendors and digital content providers

3)    integration of many aspects of information service provision; between libraries, museums and archives (particular regarding the development of digital collections); between library and computing services in universities; between special libraries and other corporate information systems within their host organisations

4)    a move to enhance the scope and content of the library OPAC; to use it as a tool for integrating access to information resources; the requirement to support resource sharing and document delivery functions

5)    the open source software movement

6)    the advent of the Application Service Provider model for outsourcing of services

7)    the move to wireless applications

  <>Other than 7), these are the developments that I choose specifically to discuss.

 

<>Web technologies and metadata standards

I move on now to describe and discuss in detail some of the more recent innovations in technology and standards for the World Wide Web that are affecting, or are likely to affect, the development of library systems. Web technology has moved well beyond the use solely of HTML for markup and the URL system for identifying resources. Again, I cannot be exhaustive, but choose to focus on three inter-related technologies, Z39.50, XML (including Web services) and Java, which appear to be of major significance for the development of Web-based library systems.<>

 a) Z39.50

Z39.50 is a communications standard which describes the rules and procedures for communicating between two computer systems for searching and retrieving information from databases (Lunau 2000). It is a “broker architecture” which offers client-based services that interact with external servers through a standard protocol (Pearce 2000). It enables a remote source to be searched using the interface of the local client, obviating the need to master a variety of search interfaces and facilitating the integration of bibliographic resources.

  <>It was originally proposed in 1984; the current version (version 3) was adopted in 1995. It uses the client/server model. Originally it was conceived with an OSI framework, however, most implementations now run over TCP/IP (Kunze and Rodgers 1996). It is a stateful, session-oriented protocol. In Z39.50, the system initiating the association is termed the origin, while the system that is searched is termed the target. The basic record syntax used is MARC, but other syntaxes can be used, e.g. SUTRS, OPAC (for OPAC displays), GRS-1, and Summary). Significantly, Z39.50 treats XML as an additional record syntax (Jørgensen 2000); it is considered likely that XML will replace GRS-1 and SUTRS in future (Gardner 2000). A number of different configurations of a system are possible (Evans 2001a).

A Z39.50 session consists of a number of stages or facilities, which in turn incorporate a series of messages: (2001a). Broadly, these divide into core facilities and the so-called extended services. These are included in version 3, and provide the ability, for instance, to order material for interlibrary loan, to save searches for re-use, to download searches, to retrieve catalogue records, and to update databases. This potentially allows many library processes to become “open”. The explain feature allows the user to query remote databases about available services, and to configure dynamically search and retrieval. It defines a database structure, a search methodology and a retrieval mechanism that a Z39.50 server can use to provide information to clients about the databases which it offers and the content of those databases. Local administrators decide which attributes and attribute values (see below) should be available for the Z39.50 client.

<>For interchange of bibliographic data the standard defines the Bib-1 attribute set, which covers the six types of attribute that can be used to form a query: use, relation, position, structure, truncation, and completeness. In version 3, the query structure can perform Boolean searches using the operators AND/OR/NOT. Sometimes use of the proximity operator PROX is possible, and also restriction of the search to a particular field, e.g. author. Although the standard itself defines only the interaction between one client and one server, many vendors have implemented the ability to broadcast requests simultaneously to several Z servers (Lynch 1997). 

It can readily be seen that the potential implications for library services and systems of such a standard are profound. Z39.50 tools allow the searching and downloading of bibliographic records in MARC format, which has implications for the sourcing of catalogue records. Z39.50 also permits the development of user-mediated document supply and SDI services (Evans 2001a). Z39.50 OPACs allow the extension of bibliographic access to other Z39.50-enabled systems, hence the growth of interest in the development of virtual union catalogues, which are considerably cheaper and easier to maintain than physical union catalogues. There have been a number of virtual union catalogue projects: the University of California Union Catalog (Coyle 2000), the Canadian Virtual Union Catalog (vCuc) (Lunau and Turner 1997), the Z Texas Project (Moen 1998), and the RIDING, M25links, and CAIRNS “clumps” projects in the UK (Cousins 1999). Typically, however, a variety of problems arise with Z39.50 searching (Pinfield 1998, 2001; Stubley 1999; Ridley 1999; Agnew 2001):

1)    the number of attributes supported by all targets tends to be small; this leads to difficulties constructing effective search statements

2)    institutions adopt varying practices when mapping data to the bib-1 attribute set

3)    serial holdings are catalogued differently in different vendors’ systems

4)    searches are slow

5)    the results are confusing to the end-user; the search generates varying levels of detail among bibliographic, archival and subject gateway records

6)    databases have implemented different indexes and may search an inappropriate index such as a name index for an author search request

7)    large result sets are caused by a server not allowing a precise search, and treating all searches as keyword searches

8)    there is currently no agreed method for the provision of location, holdings and circulation information in response to a query

<>      9)    scalability is an issue: searching of more than 5-7 institutions at a time can result in network bottlenecks due to the client/server communications overhead. 

Version 3 of Z39.50 is in fact very general in scope and incorporates a large number of options; arguably too many (Lynch 1997). The original intention of those drafting it was that particular user communities should define profiles specifying how Z39.50 was to be used in their applications and what type of data is to have access provided to it, e.g.:

1)    what Z39.50 functionality must be supported

2)    what minimum search attribute and attribute combinations are required

3)    what record syntaxes need to be supported

4)    how security and access issues are to be handled

<>     5)    minimum and maximum lengths for various data elements     (Needleman 2000)
 

The Bath Profile[7] is dominant among the profiles so far devised by the library community. It is designed to solve some of the problems of Z39.50 implementation: it identifies features of the standard that are required to support effective use of Z30.50 software for a range of library functions. It defines a core set of author, author + title, and subject search and retrieval specifications across a variety of library databases, as well as more complex searches. Its functionality and specifications are intended to be incorporated into more detailed regional specifications. Problem 8) above is the subject of the ZIG Holdings Schema[8] (Stubley 1999).

As Pearce (2000) observes, the library catalogue is not necessarily a single Z39.50 target, since most library systems support a logical data model consisting of at least three separate targets: a bibliographic database, an authority database and a holdings database. There are plans for the Bath Profile to include a functional area for thesauri in a future version.

<>Currently it is being implemented by SIRSI; one may anticipate that conformity with the Bath Profile will increasingly become an issue for vendors. (Lunau 2000, Miller 1999). Explain is currently implemented within Z’mbol, a metadata indexing system developed by Fretwell-Downing. 

The development of the Web provided a boost to Z39.50, since it provided a forms-based interface for Z39.50 searches (Casale 1996). Most library system vendors have implemented Z39.50 and have added features, such as the ability to execute multiple simultaneous searches. This is done either via a local Z39.50 client or (more frequently nowadays) via a combined Z39.50 client and web browser, which offers access to Z39.50 via the browser interface, performing an interconversion between Z39.50 and HTTP (Turner 1998).

If libraries have a Z39.50 server, their holdings are searchable from external Z39.50 clients. (Z39.50 software cannot be customised to interact with a library’s own integrated system; it sits waiting for search requests from outside users (Nickerson 1998)).

<>Web OPAC software is technologically very complex, as it must incorporate ways of overcoming the inherent statelessness of the TCP/IP protocol (Rhyno 1997b). Web OPACs can usually be configured to search any number of vendors’ systems. The use of Z39.50 Extended Services in Web OPACs has been variable to date. Web OPAC features provided by a vendor may or may not use them, which can lead to interoperability problems. Hinnebusch (1997) suggests that take-up of Z39.50-enabled document supply facilities has been limited owing to its administrative complexity. 

Z39.50 in its classic form is unlikely to be taken up widely outside the library and information field; it is unpopular with the wider Web community on account of its complexity, use of connection-based sessions, use of binary encoding, and direct transmission via TCP/IP, while other Web standards duplicate aspects of its functionality. (LeVan 2002).  It has not been implemented by major browser or relational database management system vendors, but has shown steady growth and evolution within the sphere of library applications, and has a large installed base in existing systems. It is still the only effective means of enabling simultaneous queries upon distributed heterogeneous databases. It is reasonable, therefore, to anticipate for it a continuing importance in library systems within the near future (Needleman 2000; Moen 2001).

<>The question arises as to the future of Z39.50 in an XML-dominated era within the context of the Web (see the discussion of XML and its significance). Z39.50 is comparable to XML in that it provides an abstract framework for talking about data models completely independently of the physical software and underlying architecture. It goes further, however, than XML in that it specifies not only a logical representation of a document, but how it may be searched (Hammer 2000). Jørgensen (2000) points out a number of synergies between Z39.50, XML and RDF: Z39.50 can support XML as a transfer syntax, it can support XML-based query languages, and can search and retrieve RDF structures, while Extended Service transactions can be handled by the Simple Object Access Protocol (SOAP)[9]. 

In recent years a number of development projects have sought to redevelop Z39.50 as a Web service. The Z39.50 Implementors Group (ZIG) is sponsoring the development of Z39.50 in this way via its Search and Retrieve on the Web (SRW) initiative, formerly known as ZNG. This work uses a version of Z39.50 encoded in XML and sent via HTTP and SOAP. The details of the system architecture are described by Jørgensen (2001). It has the advantage that the Open Archives Initiative community is already committed to the use of services running over HTTP; also SRW is considerably simpler than “classic” Z39.50 (ZING 2002; NISO 2002). Another project is that of Corfield et al. (2002) on the JAFER (Java Access For Electronic Resources) ToolKit, which is developing a simplified XML-based API above the Z39.50 protocol for both Z39.50 clients and servers. The ToolKit has been used to build a number of Web applications based on XSLT, and also some experimental Web services.

 b) XML

  <>EXtensible Markup Language, XML, is rapidly establishing itself as an industry-wide format for data and document exchange, being the de facto standard for representation of information content optimised for Web delivery in variable formats (Miller 2000, Marco 2001, Banerjee 2002). Every serious Web technology is now expected to define its relationship to XML (Rhyno 2002).  Virtually all major software developers have now integrated support for XML into their products[10]. The overarching issue for libraries, as we have seen, is that of resource integration across a distributed information environment (see above – Powell and Lyon 2002, Brygfjeld 2001). XML is a language or format capable of representing complex structures in non-proprietary and self-explanatory ways. It appears to have the potential of facilitating such integration, through the possibilities it affords for metasearching across different document types and metadata formats, and as a vehicle for systems interoperability (via Web services?).The potential applications of XML within library systems have drawn considerable interest from the beginning, yet it is apparent that this widespread interest has not lead to clear directions about what the role of XML should be (cf. Carvalho and Cordeiro 2002).

It appears that this complex issue has three main aspects: the extent to which XML is being used as a format for core library metadata standards and employed within data exchange technologies; the penetration of XML standards within e-book publishing (one may assume that library systems vendors will introduce support for such standards once they have stabilised); and the “pure” technology issues: of data storage and manipulation, and use of the so-called Web services within library systems.

I aim to provide here:

a)    An overview of XML fundamentals

b)    A summary of metadata issues, especially use of MARC

      XML

c)  a summary of the issues concerning data storage, database technologies, and Web services

<>The data exchange issue has already been covered under Z39.50 and EDI.  <>a) XML was introduced in 1996 and endorsed by the World Wide Web Consortium in 1998. XML, like HTML, is a derivative of Standard Generalised Markup Language (SGML). XML provides a customisable, structural markup of a document, unlike HTML, which provides a presentation format rather than a structure. It is a meta-language for defining an unlimited number of specific markup languages, each of which may contain an unlimited number of tags (hence extensible); its elements are defined by the user. In XML, content is separated entirely from presentation; the presentation of XML content needs to be specified by style sheets. 

XML was designed for a number of specific purposes:

• to enable international media-independent electronic publishing
• to allow for the definition of platform-independent protocols for data exchange
• to deliver information to user agents in a manner that allows for automatic processing post-receipt, and to reduce the costs of the processing
• to permit choice of display format by means of style-sheet control
•  to facilitate the production of metadata
  (W3C XML Activity Statement, quoted by Fichter and Cervone 2000)

<>The XML syntax has three main building blocks. XML documents contain a hierarchy of named elements, the structure of which can be conceived of as an inverted tree with the actual data values occupying the “leaves”. Container elements contain text and/or other elements. Named attributes of an element can be specified in its “start” tag. Entities permit components of a document to be named and stored separately. A Document Type Definition (DTD) can be set up to declare each of the permitted elements, attributes, entities and their inter-relationships. (Brandt 2001). A DTD expresses the hierarchy and granularity of data, allowable attribute values, and whether elements are optional, repeatable, etc. Such DTDs form templates for the logical structure of associated XML documents. An XML document that conforms to a DTD is said to be valid. A DTD can be established by the user, or the document can refer to an existing DTD. The notion of an XML namespace has been established to address the issue of potential name clashes of XML elements, whereby a machine-readable definition of the element set for a document (e.g. a resource list) is given at a fictitious URL or URI (Uniform Resource Identifier) (Kelly 2000). Since a DTD defines a single namespace, a suite of DTDs can be defined to permit elements from different DTDs to occur in one document. 

At a more fundamental level (e.g. across a particular industry sector), it is possible to define XML schemata or specialised derivative markup languages, which define within the overall XML Schema framework, using a separate XML document, the particular tags and attributes used for applications within that industry, (van der Vlist 2000).  This has been done, e.g. for voice recognition (VoxML) multimedia (Synchronised Multimedia Integration Language – SMIL) and wireless access (Wireless Markup Language –WML). A draft of XML Schema was released by the W3C as a Proposed Recommendation on March 21^st 2001.[11] While much more powerful that a DTD, XML Schema has only limited support within currently available software.

<>XML by itself models and delivers structured data without any reference to documents. The display and linking of XML data is defined by several related technologies and standards (the proliferation of which is fairly described by Peek (2000) as “alphabet soup”!): 

XSL

In a manner analogous to the use of Cascading Style Sheets with HTML, the appearance of XML documents is controlled by eXtensible Style Language (XSL). This separation of form from content is a powerful feature of XML; XML data can be displayed in many different formats using different style sheets, hence it can be used to customise user interfaces. XSL may also be used to perform calculations. XML can be converted to HTML using a variety of methods at either client or server side. A further development, XSL Transformations (XSLT), enables one XML document to be transformed into another according to an XSL style sheet, so, for instance, XSLT can convert an XML document into HTML, or reformat it for display within the screen of a WAP mobile ‘phone. XHTML, which is effectively replacing versions of HTML according to the W3C’s recommendations, is a representation of HTML in XML (Kelly 2001).

XML query languages

<>A variety of XML query languages have been proposed; in the library systems literature one can find references to XQL, XSL Patterns, and XQuery.  XQuery is the most likely candidate to emerge as a W3C standard: XQuery 1.0,  which relates closely to XPath (see below), is the subject of a W3C Working Group.[12] 

Xlink, Xpointer and XPath

XLink provides hyperlinking functionality considerably greater than that of HTML. It includes links that lead users to multiple destinations, (so that, e.g. a hyperlink to an author’s name could yield a list of multiple options, such as secondary sources, bibliographical information, further links, portraits etc.) bi-directional links, and links with special actions. With XLink it is possible to set up external link databases to facilitate the maintenance of hyperlinks.  These extended links are of two sorts, inline and out-of-line. In the latter, the links between documents are not stored in the documents themselves, but in a separate linking document. XML also provides HTML-like simple links, bi-directional links, and links with special actions (Kim and Choi 2000, Miller 2000). XPointer addresses the limitations inherent in HTML for processing pointers into documents. Using XPointer it is possible to link to any portion of an XML document, even if the author has not provided an internal anchor. It uses another XML technology, XPath, to specify locations with the document and to provide a means of querying the document (Evans 2002).

<>XML documents may of course be created using text editors, but specialised XML editors are required for producing them in quantity; again, several are now available. XML is supported by the most recent versions of Web browsers[13].
To validate XML documents and provide access to their content, an XML parser is required. A variety of academic and free parsers is available, mostly coded in Java. In addition, several commercial companies have started offering updated versions of these, or have built their own. There are two main standard application programming interfaces (APIs) specifying how an application may access an XML document once it is in a parser: the tree-based Document Object Model (DOM) and the event-based, less memory-intensive Simple API for XML (SAX). DOM reproduces an XML document’s data hierarchy in a programming language’s native object format, providing programmers with an easy and familiar way of working with the data in the document. The DOM API loads the entire document into memory, favouring repetitive operations performed on short documents. For lengthy documents, SAX is a better choice. Unlike DOM, however, it cannot make backward or multiple passes through the data. (Yager 2000). 

b)  Since the 1960s the main metadata format used within the library community for print-based materials, has been MARC. A huge amount of bibliographic data is extant in MARC formats. With the advent of XML and other Web metadata standards, the issue for libraries obviously thus arises of the prospects for MARC in an integrated information environment. A great deal of work has been carried out in relation to XML and MARC. Approaches and perspectives have varied: the issue is bound up with a complex debate, which is beyond the scope of this article, concerning the suitability of MARC as a bibliographic format for cataloguing Web resources, and the desirability of its replacement with an XML-based alternative.[14] Some efforts (e.g. those of Miller and his team at the Lane Medical Library) have focused on replacing MARC content with an XML schema for bibliographic records (Miller 2000, 2002).  Several teams and agencies (e.g. Miller 2000, Logos Research Systems) have developed methods and tools for conversion of MARC to XML at the structural level.  The other main emphasis has been on XML implementations of MARC. In the spring of 2002 the Library of Congress announced an official specification for representing MARC data in an XML environment, MARC XML. It seems reasonable to suppose that, while MARC implementation efforts and experiments will continue, the library community is unlikely to abandon MARC within the foreseeable future (Johnson 2001).

XML has already been widely adopted as the language of other metadata standards within the library and information community. For instance,

i) XML is itself the syntax for the Resource Description Framework (RDF). RDF is the central component of W3C “semantic web” activity (Medeiros 2000) and a major application for digital libraries (Kelly 2000, Bray 2001). It is not itself a metadata scheme, but a system for encoding metadata schemes within a standardised framework; it provides a standard way of describing element names, their content and their relationships (ODL 2001).

<>ii) The Open Archives Initiative[15] is a protocol that enhances access to e-print archives as a means of improving access to scholarly communication; within the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH), XML is used both for protocol requests and for delivering metadata, Dublin Core[16] based metadata in XML being the main metadata format that it uses (Kent 2002).  

This is far from being a complete list. Other library-related metadata standards using XML are summarised by Rhyno (2002a) and by ODL (2001).

<>c) There is an obvious issue for software developers as to how XML-based documents and data may be stored and managed. Two main approaches are possible: the relational database (RDBMS) using XML extensions or middleware, and the “native” XML database.[17] In both these types of database, the tools to manage the XML documents conform to XML-related data models: XPath, DOM, and sometimes XQuery, Relational databases store large XML documents as Binary Large Objects (BLOBs) or Character Large Objects (CLOBs), using an XML parser to manipulate the XML as it is moved in or out of the BLOB or CLOB (Trippe 2002). They use SQL for querying, and a variety of mapping tools and technologies for mapping the XML data to the relational fields and back again. They may have built-in extensions for transferring data between XML documents and themselves (in which case they are referred to as XML-enabled databases) or may employ third-party middleware for this purpose (Castor, IBM Database DOM, and Breeze are products that are readily available). This can be processing-intensive and relatively slow, losing the performance advantage of a relational database system; it also has the disadvantage that depending on the type of mapping employed, it may not always be possible to retrieve documents in the form in which they were input (“round-tripping”). All the major relational database players have moved to strengthen XML support (the use of XML query languages and the more stable standards) within their products: Oracle (Oracle 8i and 9i), IBM  (DB2) and Microsoft (SQL Server using SQLXML) are some of the market leaders (Mable 2002). 

 “Native” XML databases, such as Ipedo (Ipedo Inc.), eXcelon’s XIS, and Tamino (Software AG) may use any physical storage model. By definition, they store and retrieve documents according to an XML-derived hierarchical data model, generally as indexed text or some variant of the DOM mapped to an existing data store. (Content management systems, incidentally, use such “native” XML databases for storage, but have additional functionality such as editors, workflow control, and version control built in.) XML-enabled relational databases, however, conventionally break down the XML hierarchy into sets of relational tables (Mable 2002, Bourret 2002).

The relative merits of these different types of database depends very much on how the application makes use of the XML document. The terms data-centric and document-centric (Bourret 2002) are used to describe the primary function that an XML document provides for an application. A data-centric XML document is one:

<>

1)    which is designed primarily as a vehicle for data transport

2)    which is intended to be processed by an application, is accessed and manipulated at the level of individual fields

3)    which has a regular structure with specified field lengths

4)    which is fine-grained

5)    in which sibling order (i.e. of elements) is not important.

<>A document-centric document, by contrast: 

1)    is intended to be updated and edited at the document level

2)    is designed to be read by human beings

3)    has a variable structure

4)    has larger grained data

5)    is one in which sibling order matters

<>These distinctions are not absolute, as many XML documents are of “mixed” type. A hybrid library obviously incorporates a heterogeneous range, from MARC records (data-centric) to e-books and even collections of e-archives. XML databases are also much slower than relational database management systems, of working with internal data structures (McCarthy 2000, Rich 1999) although they can provide very good performance for certain types of information retrieval.  Hitherto, relational databases have been considered more appropriate for data-centric applications, whereas for document-centric applications…native XML databases, object-relational databases, and other solutions that can maintain XML documents as a more complete unit, have been preferred.[18] 

Library systems vendors so far seem to have chosen to adhere to relational database solutions, although native XML databases such as Tamino (Software AG) and Ixiasoft’s TEXTML are being used in some digital library projects

(Yeates 2002).

  <>XML is not a panacea to end all data exchange and interoperability problems. Its versatility comes at the expense of computational efficiency. A considerable expenditure is required to create XML documents and standards, while the documents themselves are verbose and slow-loading. Also, there is currently little awareness and use of it within the wider library and information community. It is, however, an important enabling technology.
 

Web services

  <>Web services (or, less confusingly, application services) have been succinctly defined as “self-contained, self-describing modular applications that can be published, located and invoked across the Web”. Web services “perform functions, which can be anything from simple requests to complicated business processes”. In other words, they are “interoperable building blocks for constructing applications” (Gardner 2001). Web services allow an application to invoke a remote process or application as if it were part of the invoking application (Jacobson 2002). The infrastructure required to support Web services may be described in terms of three roles: service provider, service requestor and service registry, and three interactions: publish, find, bind. It may be seen that Web services have the potential to provide robust interoperability between different systems (compare the discussion of library system components above, p. .). Major commercial software providers heavily support them: the two competing environments for the development of Web services are Enterprise Java Beans (Sun Microsystems) and Microsoft’s .NET.

Web services depend upon a suite of XML-based open standards:

1)    The Web Services Description Language (WSDL) which describe a service as a set of “ports” which group related interactions that are possible between the application (service requestor) and the Web service (service provider);

2)    The Simple Object Access Protocol (SOAP), a standard for XML-based information exchange between distributed applications. It is typically transmitted over HTTP. It has the advantage of working across firewalls;

3)    Universal Discovery, Description and Integration (UDDI), which is a specification for distributed registries and services.

<>Other than library portal solutions (see above, p.....) I have not been able to identify any commercially-available library systems incorporating Web services. However, there are a number of local implementations and experimental projects within the library community which are highly significant: 

1)    The work of ZiNG on Web services implementations of Z39.50 has already been discussed (above p. )

2)    The Portuguese National Library is using Web services architecture to support the Portuguese National Catalogue. The system allows record retrieval and the searching, insertion, validation and updating of records (Tennant 2002).

3)    The ALADIN digital library system of the Washington Research Library Consortium (WRLC) uses Web services to provide a network-based interface to its services, permitting more effective integration with the systems of the individual member libraries. [19]

4)    Most significant, perhaps, is the PYTHEAS experimental multi-tier open source library system or library application framework (see above….) developed by Rhyno and his team at the University of Windsor, Ontario (Rhyno 2002c). PYTHEAS uses RDF and MARC as its major metadata formats. The server is based on XML, Web services, and Enterprise Java Beans, with Exolab’s Castor XML mapping tool as middleware.

Web services are currently receiving a great deal of attention within the information technology industry as a whole. It remains to be seen whether the early expectations will be borne out.

<>

c)    Java

Java is an important enabling technology for library systems, allowing the rapid development of new functions. It relates closely to XML in that many XML tools and applications are coded in Java. It shares with it the characteristic of platform-independence. . Using XML and Java together, developers can build sophisticated, interoperable Web applications more quickly and at a lower cost.

  <>Java is a high-level programming language that was launched by Sun Microsystems in 1995, and is steadily becoming more significant in web-mediated information delivery. It has the advantage over other programming languages of being object-oriented (like C++, but simpler to learn); platform-independent, portable and secure; according to the developers, it will “write once, run anywhere, on anything, anytime, safely…” (Jones 1997). Java code is relatively easy to reuse and maintain, giving it an advantage as compared with scripting languages.

Java programs running on client PCs enhance considerably the possibilities for interactivity of Web pages. Users can run programs (applets) on remote servers from within a Web browser: they are embedded within HTML pages using the <applet>…</applet> tag and execute within the so-called Java Virtual Machine (JVM) (Rhyno 1997b), a subsystem that can be incorporated within a variety of computing environments.

<>Java programs will run on PCs using Windows 9x / NT/2000/XP, Macintoshes, and Unix workstations, using any microprocessor. Operating systems do not necessarily come with the JVM installed; it is provided either through a Java Development Kit (which includes tools for developing and running Java applications) or a Java Runtime Environment (which simply allows Java applications to run). This is the standard approach for servers running network operating systems; the primary vehicle for providing a (more limited) JVM is the Web browser (Breeding 2000b). Java is supported by recent versions of the main Web browsers. 

Java applets and applications are easily distributed via the Web, but can work offline, which facilitates system maintenance and upgrading. The network becomes the distribution vehicle for the software applications. Java code loads from the network to the client PC’s RAM: there is no need for it to install to the hard disc. Portability of applets across architectures is not perfect, however (Hickey 1997); vendors’ JVMs vary, and large applets can take some time to download. “Platform independence” has in practice generated a whole raft of semi-standards, spin-off technologies and legal difficulties.

<>The information retrieval capabilities of Java are much improved over the HTML forms/CGI approach, which can return only one page at a time and cannot deal well with large result sets. It was realised early on by library systems experts (e.g. Rhyno 1997b, McKiernan 1997, Hickey 1997, Rosenberg 1996) that Java, on account of the advances in functionality it offers, would be an excellent tool for developing OPACs and Z39.50 clients. It has the functionality to handle the complex interface between the client and the Web server, being able for instance, to support the sorting and analysing of relationships between records displayed within a browser, and the holding open of a connection to a remote library service. Using Java to create the Z39.50 client provides a standard browser interface without loss of the Z39.50 functionality.  

Java permits the running of animation, video and sound internally within a browser; it provides for pop-through windows and for the integration of different types of tools and documents within the Web environment. It also offers the possibility of annotating documents, of linking composite documents, and of customisation (Chu 1996, Jones 1997, McKiernan 1997). The Java Database Connectivity (JDBC) interface is a significant technology, comparable to Microsoft’ ASP. It allows programs written in Java to access any ANSI SQL-2 standard database; it presents a means of dynamically generating HTML pages; and it allows applications to present the same interface to all databases on all platforms.

<>Running programs over the internet obviously creates security issues. Java was designed in such a way that the applets must operate within a strictly defined environment called the sandbox, they are restricted from reading from or writing to the local hard disc, from gaining access to the operating system, data files, and hardware, and from opening connections to servers other than the one from which they originated. Hence it is a) difficult to save retrieved items and b) impossible to connect to several Z39.50 servers at once. However, there are ways of overcoming these limitations: email can generally be used to send results to users; also the host server can be set up to act as a bridge to other Z39.50 servers.

Sun Microsystems made a deliberate pitch for the library systems market at an early stage (Chu 1996, Pasquinelli 1997); it was perceived that its platform independence could effectively extend the life of legacy library computer systems. However, it has made a presence in library automation only slowly (Breeding 1997). While the trend towards its use is not overwhelming, there are now a number of major products using Java in one or more of their components. TLC has a cataloguing system, CATNOW!, and a Java-based circulation systems and OPAC, Library*Solution. Innovative’s Millenium system incorporates several Java modules, while CyberTools, BiblioMondo, and epixtech have Java OPACs. The new Java 2 Enterprise Edition (J2EE) is claimed to have transformed a streamlined, thin programming language into a complete computing platform, of which the language is just one component. It has recently started to be implemented within integrated library systems, for instance Talis’ new library portal, TalisPrism.

 

The user interface: content integration 

1)    OPAC developments

<>As stated above, Web OPACs have become almost universal and de rigueur in present day library systems. Web OPACs generally offer a wide range of search options. They may incorporate information retrieval techniques such as word stemming, truncation, weighted searching, use of fuzzy match search logic, natural language processing; they may provide enriched subject access, or enhanced content. They may (e.g. Fretwell-Downing’s OLIB) provide automatic spelling correction of common terms. They frequently provide the ability for a reader to save searches via email. Self-service features, such as reader-initiated reservations, renewals, equipment bookings, and document ordering, are common; the trend is towards “borrower empowerment” (Saffady 2000). The interfaces may incorporate extensive search limiting or browsing features. The vendor may offer access to the catalogues of other libraries via a Z39.50 client; such access may be an important component of resource sharing and hybrid library initiatives, as well as enriching the content of the OPAC itself . (Beheshti 1997). It is common now also for OPACs to be able to display book jacket images, tables, of contents, abstracts and reviews. (Breeding 2002c). Babu and O’Brien (2000) provide a detailed overview of currently available Web OPAC functionality. 

Two developments appear to underlie these trends:

1)    Steve Coffman’s well-publicised piece “Building Earth’s largest library…” (Coffman 1999), which made a appeal for library catalogues to become more like online bookshops in terms of the content offered to the reader, offering features, such as self-service issue and return, pictures of book jackets, access to reviews, the ability to compile book lists, and recommendations for similar titles based on previous purchasing decisions (see also Block, 2001)

<>2)    A considerable body of evidence from research conducted in the early 1990s that OPAC searching benefits considerably from the addition of information to enrich the bibliographic record, such as tables of contents (reviewed by Matthews 1997). 

Surpass’s OPAC is perhaps the most obviously “Amazon-ised” of those currently available. Surpass offers the facility for a reader to look at book jackets and reviews, to submit their own reviews, and to create a ‘book bag’, which may be used later to generate a reading list. The enhanced content is syndicated from a content provider. Another notable product is SIRSI’s iBistro, which includes enhanced OPAC content.

Web OPACs have obvious major advantages that:

1)    the user is offered access via the browser, integrating the OPAC with other information sources

2)    using the USMARC field 856 it is possible to include URLs within the bibliographic database, creating live links to digital objects, or enabling the association of print and digital sources within a bibliographic record

3)    they are highly customisable; search types can be defined, and special interfaces, e.g. for children or disabled users, can be provided

4)    cross references, and links to full text sources, can be provided via hyperlinks

5)    the basic navigation conventions of the search interface, while sometimes questionable in themselves (Ridley 2000) are familiar to the reader.

<>However, they have the disadvantage of requiring relatively high Internet bandwidth to run at an acceptable speed, owing to their inherent slowness. Where enhanced content is provided, this is an additional expense for the system vendor, and is not always relevant or useful for special libraries (Gordon 2001). 

Some features specified as desirable by researchers, which have been implemented in experimental OPACs, e.g. automatic query expansion (Fieldhouse and Hancock-Beaulieu 1994), the ability to read selected contents (Lease Morgan 1998) and the use of VRML as an aid to navigation (Rhyno 1997a), have not to my knowledge yet been implemented in any commercial systems.[20]  Some commentators have described the enhancements in functionality provided by Web interfaces to OPACs as “cosmetic” and failing to address more fundamental problems of OPAC searching (e.g. Ortiz-Repiso and Moscoso 1999).

2) Portals, customisation, and personalisation

<>There is a broader trend of offering user interfaces to library collections and services in the form of Web portals, often incorporating personalisation technologies (e.g. Balas 2001, Anon. 2001). There have been several well-known experimental projects using personalised interfaces14. More recently, vendors have begun to provide products which not only provide a Web interface to the catalogue, but enable librarians to build portals which effectively act as hybrid library interfaces, since they offer integrated access to a variety of information services: local or remotely hosted, print-based or digital, bibliographic or full-text. Portals are “systems which gather a variety of useful information resources into a single ‘one-stop’ web page, helping the user to avoid infoglut, or feeling lost on the Web” (Looney and Lyman 2000). They may include a variety of services such as e-mail updating, chat areas, online payment facilities, and reference access via videoconferencing. Underlying this development, again, are several trends: 

1)    A body of recent studies of information seeking behaviour which suggests that searchers, particular in younger age groups, are becoming reluctant to make use of library catalogues, finding them slow and irrelevant, and prefer Web search engines as their search tool of first resort (e.g. Leibovich 2000, Davidson 1999, Tennant 2001, Jackson 2002)

2)    The success and influence of commercial portals such as MyNetscape, MyYahoo, etc. in terms of enhanced visibility, accessibility, and interaction with users;

3)    The competition to libraries presented by commercial information portals such as WebFeat, Ebrary and Questia (Davidson 1999);

4)    The results of focus group studies among groups of students, which suggested that they are often confused by the plethora of choices facing them (Lease Morgan 1999).

<>Thus, personalised portal interfaces are perceived primarily as a solution to the problem of information overload (Tennant 1999). Their other aims are to provide traditional library services via a Web interface, to provide an organised context for information (Stevens 1998), and to “brand” the library (Lease Morgan 1999). They enable readers to set up personal information systems (Lakos and Gray 2000). For librarians, they are a way of countering Web-induced marginalisation of the library already referred to, and also of enhancing the usability of Web-based services. 

Among recently-developed commercial portal products for libraries are SIRSI’s iBistro, ExLibris’s MetaLib, OCLC’s WebExpress, Esprit’s XDirectory, MuseGlobal, and Fretwell-Downing’s ZPORTAL. SIRSI’s system provides a Web interface which is designed specifically to market the library and its resources, i.e. to place them at the forefront of the reader’s awareness. Its interface is explicitly “search engine-like” in its design and terminology. iBistro provides access to a selection of MARC-catalogued Web sites maintained by SIRSI; enhanced OPAC content (reviews, tables of contents, synopses); alerting to new accessions based on a stored customer profile; integration with content providers (NorthernLight, SiteSource); and Z39.50 enabled searching across other library catalogues. Within the library systems market generally, it is observable that content providers are entering the arena (Barry 2000b;. cf. above, p.5).

The integration of local as well as remote content can be an important function for academic and special libraries (Cornford 2001). Cibbarelli (1999) states that it is desirable to “have the online library system function as the document management system, or at least to interface with the [organisation’s] document management system”. According to Tim Twine of EOSi 15, it is now very difficult to sell library systems to corporate libraries that do not offer some measure of this sort of integration, both at the systems and at the user interface level. Interesting products of this kind are on offer from the Esprit Soutron Partnership; its NOTEbookS system interfaces with Lotus Notes, while the Inmagic product portfolio includes intranet tools as well as library systems. It is advantageous for academic library portals to be able to interface with VLEs (Virtual Learning Environments).

<>It remains to be seen how useful the personalisation features of commercial portal products will prove in practice. Neilsen (1998) is critical in general of personalisation systems which are not directly under the user’s control, or which do not allow the user to select what is of interest at a specific time. Lease Morgan (2001) observes that customisation of library interfaces can be a double-edged sword; while it assists librarians in being more proactive on the part of their readers, privacy is a serious issue, as is the time involved in system maintenance.  Moreover, Ghaphery and Ream (2000) found that only a small percentage of the registered users of MyLibrary (an experimental library portal) seemed to find it useful as an enduring access point for their research, and that the system was of much less use for occasional library users than for regular ones. For a detailed discussion of library portal solutions, the reader is referred to the recent report by Cox and Yeates (2002b) 

The open source software movement

Open source software is software whose source code is made freely available for inspection, modification and incorporation in other software, as distinct from being a closely guarded trade secret of software companies (Schlumpf 1999). The licences typically specify that applications and source code are free to use, modify and distribute, so long as these modifications, uses and redistributions are similarly licensed. (Chudnov 1999).

<>In the last few years it has entered the mainstream software market, with the widespread adoption of packages such as Linux (operating system), mySQL (relational database), PHP, Perl, Python (scripting and programming languages), Apache Web Server, and the Zope content management system. Its effects are beginning to be felt in the library automation marketplace as open source projects develop within the library community.

 <>It is claimed by its advocates that the open source approach has the advantage of giving libraries direct control over the technology they use; systems librarians can have a direct role in developing the software and can focus on functional enhancements which are of local value but which would not be viable commercially for a mainstream vendor. These can then be shared with the library community, compensating for the relatively small size of the library systems market (Mickey 2001). Development of open source products is generally rapid and more responsive to users compared with that of commercial software. The open source system has the advantage of promoting software quality and reliability through peer review. Where adequate technical resources exist, it has the advantage of relatively low cost. 

A number of experimental library systems are in existence: Avanti, OSDLS/Pytheas, Koha, FSLP and Open Book. Schlumpf (1999) believes that these have the potential to compete seriously with commercial systems. However, these are relatively small-scale projects, and it is unlikely that there could ever exist a group of potential software developers sufficiently large and well resourced to make them viable (Breeding 2002b). It is more likely that libraries will develop more specialised open source applications which are interoperable with, but additional to, commercial systems; successful examples to date include Prospero (an email ILL tool), Jake (a reference tool for medical journals), SWISH-E (a web indexing tool), Free Reserves (course reserve and management software) and XMLMARC (a utility for converting MARC records to XML (Mickey 2001).

<>One noteworthy recent development is epixtech’s decision to offer open source licensing for its software to implement the NISO Circulation Interchange Protocol (NCIP).16 OCLC also appears interested in open source projects. It remains to be seen whether other vendors will follow this sort of approach.
 

Application service providers

<>ASPs are internet-based services that allow one to rent software or services on a per-use or subscription basis. The software and data sits on the ASP’s server and is accessed via a simple Web connection, available to anyone within the customer organisation (Dzurinko 2000). In the library context, a library ASP hosts a library’s database at a central location, manages the system application software, and provides hardware and software support for the application. The library’s PC acts as a thin client, i.e. provides access to the system software via a web browser through the library’s firewall. Data content and integrity remain under the control of the library; hardware and software maintenance and support lies with the vendor. Initial system purchase price is paid over the period stated in the library-vendor contract. 

The ASP concept is still relatively new to the library systems market, and to date only a few vendors (CASPR, epixtech, Innovative Interfaces, library.com and SIMA) are marketing such systems.

<>Such systems are likely to offer considerable advantages, particularly where local IT support or library systems expertise is limited, and where there are no extensive requirements for customisation. Migration to an ASP-based system is reported to be very rapid compared with conventional migration (Dzurinko 2000). A high speed Internet connection is essential, and the terms and conditions of the contract need to be specified in considerable detail. Security is also an issue; a secure ASP has considerable security advantages over a locally hosted system, whereas an insecure one is a considerable liability (Stein 2001). 

(Inconclusive) conclusion

It should have become evident in the course of this report that the library systems market, and developments in library systems, are:

1)    driven by internet trends and by the software industry rather than by the library and information community

2)    subject to global economic imperatives (US dominance, globalisation, fragmentation)

  <>The industry is highly competitive, which tends in general to benefit customers as long as profit margins, and hence the ability to invest in research and development, can be maintained.  <>

The available products are mature in terms of basic functionality, but the industry has entered a volatile, confusing and yet interesting phase; the major developments in library technology now appear to be taking place in areas which are outside the scope of integrated library systems as conventionally understood.

Catherine Ebenezer

8/12/02

SIMA http://www.simainc.com/