[Reading View] | [Source View]
The wide adoption of digital repository software by cultural heritage organizations has led to significant increases in effective management and access to digital assets. While these software systems may provide some digital preservation features, the digital materials and their associated metadata managed by such systems need to be preserved in a way that ensures they will persist over time. This project addresses this need by developing a specification for an integration model that will allow libraries and archives to seamlessly deposit system content into distributed digital preservation systems (DDPs) such as Chronopolis, APTrust, and LOCKSS. This project is funded by the Andrew W. Mellon Foundation.
More information about the project can be found on the project wiki, including a list of the members of the OTM project team.
The One To Many (OTM) Specification defines two APIs to support communication between digital content repository systems (Repository) and distributed digital preservation systems (DDPs). These two APIs work in tandem to allow content captured in Repository systems to be copied to DDP systems for preservation. The APIs are the OTM Gateway API (Gateway) for the Repository and the OTM Bridge API (Bridge) for the DDP. The Gateway and the Bridge APIs handle intermediary communication between the Repository and DDP and allow each system to operate without any knowledge of the internal workings of the other system. Each API is designed to facilitate deployment either as part of, or as an extension to, the Repository (in the case of the Gateway) or the DDP (in the case of the Bridge), or as a stand-alone application. They each provide an HTTP-based approach for authentication, communication, and data transfer.
- OTM Preservation Workflow - An overview of the entire preservation process (start here!)
- OTM Gateway API Specification - The preservation Gateway functions as an aggregating cache for preservation requests originating with a repository and destined for a DDP via the OTM Bridge
- OTM Bridge API Specification - The Bridge provides a consistent interface for systems (including repositories) to integrate with DDP platforms; the Bridge also serves as a staging point for content being transferred into or out of a DDP
- OTM Audit Events - A listing of preservation events that occur as part of the workflow that may be captured by the DDP and made available through the Bridge
- OTM Hyrax Workflow - An example content workflow designed to support the OTM use cases in Hyrax (Samvera) repository systems
These specifications were created as part of the One to Many grant, funded by the Andrew W. Mellon Foundation. The goals and scope of this grant are described in One to Many Project Overview and Goals.
These specifications aim to provide the structure and interaction patterns necessary to meet the One to Many User Stories. The team sought to define the APIs with enough specificity to allow future implementation efforts to succeed in delivering systems that satisfy those user stories, while leaving flexibility for software developers to adjust to needs that may arise in the development phase. Future versions of these specifications are expected as an outcome of any effort to implement them.
In order for a Repository system to make use of an application which has been developed to implement the Gateway API Specification, the following requirements would need to be in place:
- The Gateway application must be deployed and made available to the Repository
- The Repository must support the addition of preservation targets (DDPs)
- The Repository must support the selection of content for preservation storage
- The Repository should support the selection of content for restore
- The Repository should display details about object preservation status
In order for a Distributed Digital Preservation system to make use of an application which has been developed to implement the Bridge API Specification, the following requirements would need to be in place:
- The DDP must deploy and run the Bridge application
- The DDP must provide the Bridge application access to a staging storage location that is also available to the DDP
- The DDP must implement tooling to interact with the Bridge application API
- The DDP must support at least minimal versioning capability (ingesting, restoring, and deleting named filegroup versions)
- In order for a Gateway to communicate with a Bridge an account with associated access credentials must first be created in the Bridge by the Bridge administrator and those credentials communicated to the Gateway administrator. Creating accounts is accomplished via the Add Account endpoint.
- There will be a one-to-one relationship between a Bridge account and a single Gateway application
- The method of application authentication and authorization may vary by API implementation
This document is licensed under a Creative Commons Attribution 4.0 License