Digital Preservation using open standards

Our platform preserves your digital objects on your storage of choice (cloud, local disk or local file shares) using the Oxford Common File Layout (OCFL). This means your digital preservation is portable and vendor-neutral. The preserved digital objects can be understood and restored independently of our platform.

It is designed for simplicity of integration and long term sustainability of preserved content. Use the Preservation API to integrate digital preservation functionality into your workflows, and/or use the comprehensive web user interface to assemble, evaluate and preserve your content.

The Preservation API

The Preservation API provides a means of creating new digital objects, organising them in a hierarchical repository structure, and updating them to new versions as necessary. Rather than interacting directly with the underlying OCFL storage, the API’s concepts of Deposits (workspaces for assembling objects) and Import Jobs (instructions to synchronise Deposits with the repository by creating or updating preserved objects) provide powerful abstractions to build workflows with. The API can be driven by digitisation workflows or your own scripts and custom applications.

The Web User Interface

A complete out-of-the-box environment for navigating the repository, creating new digital objects and providing rich structural and technical information. The Web UI is both an asset manager and a METS editor, and can be used alongside or instead of the Preservation API.

Bring your favourite tools

We don’t want to reinvent the wheel. When you create a Deposit via the Web UI or directly via the Preservation API, it gives you a workspace on your chosen storage in which you can work on files directly. You could for example use BitCurator tooling within a Deposit for forensic analysis and file preparation, and then return to the Web UI to create an Import Job to preserve the finished object. You can also upload files and run standard tools for format identification, virus checking and metadata extraction directly from the Web UI without having to open the Deposit directly.

Fedora provides the OCFL layer

The platform uses the proven Fedora repository as a storage layer to write and manage the OCFL objects on disk or cloud storage. The Preservation API inherits Fedora’s concepts of Binaries, Containers and Archival Groups (the latter are the preserved, versioned, digital objects) but goes no further, keeping the API simple for maximum flexibility and integration potential. We deliberately avoid any use of the repository itself for modelling objects.

Bring your own modelling

Any structural meaning to the arrangement of binaries and containers in an Archival Group is unknown to the Preservation API. The answer to the question “how would I model a book” is that it’s up to you. You might choose to model in METS, or any other format that gets stored in the digital object; the METS file is just one of the stored binaries. If you use the Web UI, or our supplied WorkspaceManager library in your own applications, you can create METS conforming to our particular profile without having to edit XML directly. The API can read a wide variety of third party METS and use them for integrity checking and presenting a visual representation of a preserved object in the Web UI.

Open source, flexible cost models

The product is fully open source. Digirati provides ongoing tailored support services and product governance to ensure reliable ongoing operation of your preservation infrastructure and long term product sustainability. With a flexible lean architectural approach, and without proprietary licensing, this software can be configured to meet different overall cost points and support arrangements to accommodate specific preservation requirements and budgetary constraints.

Integration with IIIF Cloud Services

The diagram below shows how Preservation sits with other systems at Leeds University Libraries:

In this example a customised bridge links the objects in digital preservation to IIIF Cloud services: the IIIF Builder process. At its very simplest this process uses a IIIF Manifest template and echoes the sequence of content resources in a METS file into that IIIF Manifest, providing IIIF Image API endpoints, transcoded AV and file access as appropriate.

In most scenarios, IIIF Builder is customised to add specific descriptive metadata and other information to the Manifests. It can also be customised to translate access control information from a METS file into the IIIF Authorization Flow API in IIIF Cloud Services by integrating with your identity provider.