4.5.3 Create bi-directional linkages between each AIP and its descriptive information

From aptrust
Jump to: navigation, search


4.5.3 Create bi-directional linkages between each AIP and its descriptive information
Status Ready for review
Compliance Rating Mostly compliant
Responsible


The repository shall maintain bi-directional linkage between each AIP and its descriptive information

Supporting Text

This is necessary to ensure that all AIPs can continue to be located and retrieved.

Examples for Meeting the Requirement

Descriptive metadata; unique identifier, persistent identifier or locator associated with the AIP; documented relationship between the AIP and its metadata; system documentation and technical architecture; process workflow documentation.

Discussion

Repositories must implement procedures to establish and maintain relationships to associate descriptive information for each AIP, and should ensure that every AIP has some descriptive information associated with it and that all descriptive information must point to at least one AIP.

Evidence Provided

As mentioned in 4.5.1, the Bagging specifications also describes the minimum descriptive metadata needed for each bags, which includes the title and the unique identifier. A depositor can update bags as long as they have the bag name. Currently the UI allows search by title, object identifier, and Bag name. Also see the Definition of AIPs and Object Resource.

Links between data and descriptive information cannot be broken. Identified risks include a) a malicious hacker, or b) a complete system failure. Both scenarios are unlikely as APTrust maintain two up-to-date copies of our metadata database in Virginia and one in Oregon, along with multiple daily and weekly database backups in Virginia. Also see the Risk Management, Threats, and Mitigations page.

In the event that all copies in our metadata database are corrupted, we have attached at least the most essential metadata to the actual stored objects. We can retrieve and restore that metadata in the event of a catastrophic loss of our own metadata, though we would lose the PREMIS events. The loss of PREMIS events would mean we lose some historical/audit metadata about files, such as whether the file currently in preservation storage is an updated version of a previously ingested file, and what the checksums of previous file versions were. For a more in-depth description of the links between preserved materials and metadata, see Preservation and Storage.

In the event of the loss of the SQL database, APTrust could reconstruct the registry because of the tagged files for everything except PREMIS events (which we are encouraging institutions to record independently).