Section VII. Digital Library Technology/Functionality Overview
This section provides an overview of current digital library architectures and approaches. Similarities and differences are noted in an attempt to provide a context for the ORM's recommended best practices.
Current Digital Libraries
There are a variety of differently architected digital libraries. While not comprehensive, the list below details a broad range of these DLs, for the purpose of making it easier to identify the similarities and differences that the various architectures encompass.
Harvard's Digital Library Initiatives
Harvard was an early implementer of a complete digital library system. In 2000, Harvard initiated on a five year project to build what they called a "first-generation digital library infrastructure". (Flecker, 2000)
FIGURE 1 - Harvard's first general digital library infrastructure architecture
As can be seen in figure 1 above, Harvard's architecture is divided into three areas: Collections, Common Services, and Access. Collections are repositories of digital resources from a variety of content sources, which are delivered through various user interface tools. Flecker organizes Collections into Repositories, Delivery Services, and Content Sources. Flecker has proposed the institutional repository concept as viewed within the context of a greater digital library effort. He differentiates between the repository and other content sources mainly in the fact that the repositories are more centrally controlled / managed collections of resources, while content sources in general are collections that will come from many different internal and external sources. Delivery services are specialized applications which allow for the use of different format types.
In Flecker's model, Common Services are "a small set of core services used by many other components of the infrastructure". (Flecker, 2000) In this architecture, there are two common services - naming and access management. Naming can be equated to persistent resolution, in that Flecker states that "Unlike URLs, names do not point to the location of the named object. Instead, at the point of use a name invokes a 'resolution service' that returns the current location of the named item" (Flecker 2000). Such services currently exist - for example, the Handle system, OpenURL resolvers, and the DOI system. Access Management has two primary functions - those of authentication and of profiling (i.e. authorization).
Finally, Access Infrastructure is organized into the subcategories of catalogs, multi-catalog access, collection web sites, and portal. Harvard has a number of online library catalogs, which need to be pulled together in a "multi-catalog support" tool. Basically, this is a tool which will allow searching capability across the various catalogs, whether it be through a federated approach or a harvested approach. Collection Web Sites seem a bit out of place in this category; they basically detail a managed display approach, not necessarily an access issue. Finally, the Portal concept is viewed as a tool to enhance and assist users in navigating the richer and more complex information environment as it grows to include more and more diverse sources of information.
DSpace
DSpace describes itself as a system to support institutional repositories. Functionally, it allows institutions to "capture and describe digital works using a submission workflow module, distribute an institution's digital works over the web through a search and retrieval system, and preserve digital works over the long term." (http://dspace.org/technology/system-docs/introduction.html
)
Figure 2 - DSpace System Architecture
The DSpace architecture is structured in three layers. These are the storage layer, the business logic layer, and the application layer. The storage layer handles both the primary resource storage as well as the metadata storage and organization. The Business Logic Layer handles both internal workflow of the DSpace system as well as provides APIs for hooking into the DSpace functionality and content. The Application layer provides end-user and end-system functionality, such as the user interface, OAI-PMH server, etc.
The DSpace layers are hierarchical in nature - each layer only invokes the layer below it. DSpace allows abstracts the functionality of the storage and business logic layers by providing APIs for each of these layers; the Application layer does not have a specified API, but it does provide end-user and end-system interoperability through both a human usable interface and through the use of simple protocols to facilitate sytem-to-system functionality.
Open Digital Libraries
The concept of Open Digital Libraries (ODL) derives from the work of Ed Fox and Hussein Suleman, and extends the concept of the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH). An example of an open digital library architecture is as follows:
Figure 3 - Example Open Digital Library Architecture
Once again, we have a number of similiar architectural layers, this time linked through an OAI/ODL protocol. A number of disperate collections are brought together into a union catalog of resources via the OAI/ODL protocol (which in this case is more akin to basic OAI-PMH), and then additional functionality with the union catalog is achieved by access through the OAI/ODL protocol. This additional functionality extends on the harvesting functionality of the OAI-PMH, and adds capabilities such as Unionizing metadata from multiple sources, filtering metadata from non-OAI-conforming data sources, searching, browsing, and alerting of newly added resources.
ETANA-DL
ETANA-DL is a digital library for ancient Near Eastern studies with two archaeological components: DigBase (DB) - a repository and an archive for archaeological data from the Near East and beyond, and DigKit (DK) - a compatible field tool for collecting and recording archaeological data during archaeological surveys and excavations. ETANA-DL is supported by an Open Digital Library-based architecture.
Working References:
