One of the major themes that I've observed in the recent era of the library involves the demand for more openness in all aspects of the technology infrastructure. Libraries often articulate frustration at automation systems that fail to offer adequate access to the data and functionality of their automation systems. Libraries increasingly resist rigidly closed automation products that do not provide flexible access to the data and provide ways to connect to other products. Today's library automation environment favors systems that can deliver, in one way or another, products that break away from closed, proprietary systems to allow libraries more liberal access to their data. Open source software has caught on in a big way within the library automation arena, but we'll see that this is not the only approach possible as libraries seek options to gain more access and control over their data and other aspects of their technology environment.
The need to protect a library's investment in its data provides one of the key drivers for increased openness. The data that describes the collections and reflects the operations of the library represents one of a library's most important assets. The value of the cumulative investment of library personnel to create a database that accurately reflects its collection probably outweighs the value of the software used to produce and maintain that data. Likewise, data endures longer than any given software product. In the course of a library's automation history, it will likely migrate through multiple automation systems, yet the data created should pass intact from one to the next.
An interest in interoperability with other software products and information systems also fuels demand for openness. Libraries increasingly expect to do more with their data than simply use it within a single automation product. A typical library technology environment includes multiple interrelated systems, many of which need to access data and functionality from others. In order for multiple systems to communicate with each other and work together efficiently, library automation products need to embody a high level of interoperability.
What's Wrong With Closed Systems?
A software product, such as an ILS, comes delivered with interfaces needed for the full operation of the system. Through these supplied interfaces, the library can carry out its daily activities, constantly updating a variety of databases in a well -controll ed manner. Most products will also provide utilities that allow the library to produce reports on most aspects of the underlying data.
A closed system comes supplied with interfaces that allow library personnel to operate all aspects of the system, often including reports and utilities for viewing, printing, and exporting data. Yet, having to operate within the interfaces, reports, and utilities provided with the system may not provide the level of flexibility needed by many libraries. A closed, proprietary system limits the ways the library can access the underlying data. The library remains dependent on the creators of the software to extend the functionality of the system and to access or manipulate its data in ways not supported in the delivered interfaces.
What Constitutes Openness?
A fully open system allows the library to access any aspect of its data and extend its functionality without the intervention of the company or organization that created the system. Products that embrace openness allow the library to work with the system in ways not originally anticipated by its creator. Open systems reduce barriers. An open system gives the library more control over its own data and makes it less dependent on any given company.
Openness is all about giving libraries access to their software and their data. Open systems aim to help the library gain access to its data above and beyond the means provided by the original developer. It involves libraries having greater ownership of their data and less vulnerability to any given company or software developer. Increased openness results in products that are less isolated and self-contained and that can easily connect with other systems.
Support for Standards Results in Openness
Within the library automation arena, the requirement for the support of national and international standards results in at least a minimal level of openness. Libraries have a long history of developing standards and protocols that provide access to major categories of library data and functionality. Provided that libraries insist that any library automation software comply with any relevant standards, they gain some of the benefits of an open system. Standards such as MARC 21, Z39.59, NCIP, and OAI-PMH provide some examples of how standards have engendered more open library automation systems.
The evolving family of MARC (M Achine -Readable Cataloging) standards has been established for many years to ensure that bibliographic, authority, and holdings records can be transported out of one system and into another. The Z39.50 protocol provides a standard approach for search and retrieval for information systems and has been very effective as the basis for library applications such as federated search among information resources, virtual union catalogs for library consortia, search and selection of MARC records from bibliographic services or peer libraries, and other scenarios.
NCIP (NISO Circulation Interchange Protocol), and its predecessor SIP, provides a standard framework that addresses data and functionality involved in circulation transactions, including patron and item records.
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) specifies an approach for the mass extraction of records from an information resource. This protocol has become especially relevant for the new genre of discovery interfaces that usually involve transferring all of the records from the ILS to a new search platform.
It's important to remember the great benefits that have been achieved through the development of library standards and in the efforts developers have invested in implementing them. These standards provide both interoperability and data protection. An ILS that can import and export MARC records, for example, should ensure that a library can migrate to a new system with at least its bibliographic database, even if the incumbent vendor is unable or unwilling to assist in the process.
Unfortunately, similar standards do not exist for many of the other categories managed within a library automation system. Even when employing a system that implements all the relevant standards, libraries find that they still face many limitations. Another step in the direction of openness involves the support for APIs with more comprehensive scope regarding data and system services.
The API Approach to Openness
Application Programming Interfaces, or APIs, provide a powerful means of access to the data and functionality of a library automation product, depending on the comprehensiveness of data and functionality addressed. An API allows programmers to access the functionality of a software product. It also allows an organization to work beyond the user interfaces and utilities provided by the products developer and write its own programs that interact with its data and services.
Technically, an API is a layer of software that responds to other computers, using pre-established protocols and commands, to perform specific tasks. APIs operate within the realm of computer- to-computer interactions and are not something that the end users of the system would see. An API allows a programmer to write scripts to extend the functionality of the system or to extract data in ways not specifically created by the original system developer.
The usefulness of an API depends on the level of comprehensiveness at which it addresses the data and services of the system and the quality of its documentation. The more that the original software creator opens up the system by providing APIs to all aspects of the system, the more power the library gains to use its system in any way that it might need.
An API as part of an ILS is a powerful tool and must be used with great care. Some companies have been reluctant to provide an API, especially to the extent that it allows data modification, since they don't want to be responsible for problems caused by an errant script that creates a system problem or data corruption. In today's environment, which highly values openness, the provision of APIs has become an important competitive factor and is seeing much wider deployment.
In today's environment, web services stand as the preferred technology for implementing APIs. Web services have been widely adopted throughout the information technology industry as the standard approach for computer-to-computer communications. Web services employ XML data structures to convey requests and responses within a computer application or with a remote system to perform specific tasks.
Web services find increasing adoption within the library automation industry. A growing number of library automation vendors have articulated strategies that involve the use of APIs, implemented as web services, to extend the functionality of their systems. Examples include Ex Libri s' "open-platform program" (see Smart Libraries Newsletter, August 2008), the Encore API announced by Innovative Interfaces in October 2008, the Jangle framework sponsored by Talis (see http://code.google.eom/p/jangle), and in the web services implemented in V-smart from Infor. SirsiDynix was one of the pioneers in this area, with its API available for Unicorn since 1995 (see Library Systems Newsletter, 15:11, November 1995). The Unicorn API predates web services and is available in a proprietary language.
Each of these approaches to an API for library automation varies in the level of comprehensiveness of functionality addressed and in the progress made toward its implementation. Yet these demonstrate the efforts that developers of closed-source ILS products have made in providing a more open approach to their customers.
Open Source Software
One of the major trends in the library automation arena over the last few years involves a tidal wave of interest in open source ILS products. Hundreds if not thousands of libraries have adopted an open source ILS. This movement toward open source ILS has been motivated largely by libraries wanting to be less vulnerable to the actions or inaction of any given company as the industry continues to consolidate. It also reflects the interest of libraries in playing a stronger role in shaping and extending the software upon which they rely for their daily operations and strategic initiatives.
Open source software, by its very definition, embraces the concepts of openness, at least from the perspective of giving libraries full access to the technical underpinnings of the ILS. Open source ILS software gives libraries access to the source code, which in effect provides a complete blueprint of its data and functionality. With an open source ILS, any library with a capable programmer can inspect and modify the source code. This provides the ability to fully understand how the system works internally, to fix any errors encountered, to access any of the underlying data, and to extend the functionality of the system.
Whether an open source ILS delivers on openness in the form of robust support for library standards and in the implementation of web services and other APIs varies from one product to another. The ability for an ILS to interoperate with other applications in the library's environment depends much more on the standards it embraces, the library- specific protocols it offers, and the extent to which it supports web services. Access to the source code offers many benefits but does not in itself make a system more interoperable with other library or nonlibrary applications.
Conclusion
Throughout the history of library automation, I have seen a steady advancement toward more open systems. The first generation of library automation products was entirely proprietary. They ran on hardware platforms and operating systems created by one company that were completely incompatible with those from competing companies. Geac, for example, created the GLIS to run on its own line of mainframe computers, but it used a programming language specific to these computers as well as a proprietary database. The next phase of library automation ran on operating systems such as UNIX using programming languages and databases that that could be easily ported to multiple hardware platforms. The 1990s saw increased implementation of ILS products on more standard database environments such as Oracle - environments that allow libraries full access to the underlying data and some interoperability with other business applications in the organization that shared this database platform.
In the early days of library automation, when proprietary systems dominated, the need for standards was paramount since other means of interoperability and data exchange weren't possible. Today's focus on APIs, web services, and open source systems makes possible a level of openness far beyond what was feasible in earlier times. In today's world where libraries face incredible challenges to be ever more interconnected within their broader organizations, in cooperative arrangements with other libraries, and with their users, we need to constantly work toward higher levels of openness.
