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



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 that let them know when the relationship between the data and the associated descriptive information is temporarily broken to ensure that it can be restored.

Compliance Rating

Half Compliant

Status

In progress

Evidence Provided

As mentioned in 4.5.1, the Bagging documentation also describes the minimum descriptive metadata needed for each bags, which includes the title and the unique identifier. One can update bags as long as one has the bag name. That should be enough to meet this requirement. Currently the UI allows one to search by title, object identifier, and Bag name.

Links between data and descriptive information cannot be broken, except possible by a) some malicious hacker, or b) a complete system failure. Both scenarios are unlikely, because we 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.

In case we do lose all copies of our metadata database, 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 somewhat more in-depth description of the links between preserved materials and metadata, see Technical Documentation#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).

Relevant Documents

https://wiki.aptrust.org/Using_APTrust#Using_APTrust https://wiki.aptrust.org/Definition_of_AIP https://wiki.aptrust.org/Member_API#Object_Resource