18.104.22.168 Definition of each AIP
|22.214.171.124 Definition of each AIP|
|Status||Ready for review|
|Compliance Rating||Fully compliant|
The repository shall have a definition of each AIP that is adequate for longterm preservation, enabling the identification and parsing of all the required components within that AIP
This is necessary in order to explicitly show that the AIPs are fit for their intended purpose, that each component of an AIP has been adequately conceived and executed and the plans for the maintenance of each AIP are in place. (See 4.3, Preservation Planning, below.)
Examples for Meeting the Requirement
Demonstration of the use of the definitions to extract Content Information and PDI (Provenance, Access Rights, Context, Reference, and Fixity Information) from AIPs. It should be noted that the Provenance of a digital object, for example, may be extended over time to reflect additional preservation actions.
Documentation should identify each class of AIP and describe how each is implemented within the repository. Implementations may, for example, involve some combination of files, databases, and/or documents. Documentation shall relate the AIP component’s contents to the related preservation needs of the repository, with enough detail for the repository’s providers and consumers to be confident that the significant properties of AIPs will be preserved. Documentation should clearly show that AIP components such as Representation Information and Provenance can be managed and kept up to date. The repository should clearly identify when new versions of AIPs need to be created in order to keep them fit for purpose. The external dependencies of the AIP should also be recorded. Definitions should exist for each AIP, or class of AIP if there are many instances of the same type. Repositories that store a wide variety of object types may need a specific definition for each AIP they hold, but it is expected that most repositories will establish class descriptions that apply to many AIPs. It must be possible to determine which definition applies to which AIP. It may also be necessary for the definitions to say something about the semantics or intended use of the AIPs if this could affect long-term preservation decisions. For example, two repositories might both preserve only digital still images, both using multi-image TIFF files as their preservation format. Repository 1 consists entirely of real-world photographic images intended for viewing by people and has a single definition covering all of its AIPs. (The definition may refer to a local or external definition of the TIFF format.) Repository 2 contains some images, such as medical x-rays, that are intended for computer analysis rather than viewing by the human eye, and other images that are like those in Repository 1. Repository 2 should perhaps define two classes of AIPs, even though it only uses one storage format for both. A future preservation action may depend on the intended use of the image— an action that changes the bit-depth of the image in a way that is not perceivable to the human eye may be satisfactory for real-world photographs but not for medical images, for example. An AIP contains these key components: the primary data object to be preserved, its supporting Representation Information (format and meaning of the format elements), and the various categories of Preservation Description Information (PDI) that also need to be associated with the primary data object: Fixity, Provenance, Context, and Reference. There should be a definition of how these categories of information are linked.