The AIPs must be stored. The individual components of an AIP may be stored separately, for example details of Provenance may be stored in a database while Context may be provided by published documents and the Content Data Object may be stored in a separate repository.

Asset base

Issue WP/Project/Tools/Services Asset Evidence

Selection of storage systems

APARSEN WP23: Storage solutions

[Download not found] and [Download not found]

SCIDIP-ES Storage service

Test results and user feedback

AIPs that remain accessible to this day and have been held in digital repositories for 10+ years

Records held in Digital Archives like those at the TNA, although we note that these records may not be proper AIPs.

Design of system to be able to cope with the required scale

APARSEN WP27: Scalability

[Download not found] Survey results

Different dimensions of scalability


[Download not found] Survey results

Storage and managed control of AIPs


Cloud based Preservation as a Service capability including passive storage at 99.999% availability performance

[Download not found]

Demonstrated access to AIPs held in partner test environments, and/or other digital preservation systems, repositories and test environments.

Storage of context


Context model

Data storage and long-term archiving for earth observation data


[Download not found] and ESA’s G-POD storage elements and Multi-Mission Facility Infrastructure



Most implementations do not share a common design e.g. implementation of the interfaces implied by OAIS. If the AIP interfaces are not provided then it may be difficult to use effectively in the transfer of information plus PDI from one repository to another.

Store not only digital objects, but also the complete workflow / process that generated the object, including its context (technical, legal etc.) and all relevant information.

Systems which are more generally available which include capabilities such as the following:


  • Intelligent caching over large on-line archives
  • Optimization of data circulation for caching purposes: data granularity, network configuration, seeding strategy;
  • Caching strategies based on use-patterns, trying to “guess” which data will be requested next.


  • Preservation strategies, like the periodic migration of digital products to new information technology.
  • Encapsulation by self-describing items in the OAIS model

Modular design, open architecture and streamlined interfaces to permit an easier substitution of one or more of its elements