AIP re-ingest

Main Page > Requirements > AIP re-ingest

This page is no longer being maintained and may contain inaccurate information. Please see the Archivematica documentation for up-to-date information.

This page documents requirements for retrieving an Archivematica AIP from archival storage and re-ingesting it for further processing.

Use cases

• Updating DC metadata (version 1.5)
• Updating rights metadata (version 1.5)
• Adding new DC metadata files (version 1.5)
• Adding new submission documentation (unsponsored)
• Adding new digital objects (unsponsored)
• Deleting original digital objects (unsponsored)
• Redoing format identification/validation/characterization (version 1.6)
• Redoing metadata extraction (version 1.6)
• Redoing preservation normalization (version 1.6)
• Generating new DIP (version 1.5)
• Running OCR on re-ingest (version 1.6)
• Rerunning other micro-services (Examine Contents, Transfer Structure Report) (unsponsored)
• Extracting packages and then deleting the packages (unsponsored)
• Sending AIP to backlog and re-arranging/selecting from contents (unsponsored)

Full re-ingest

To be supported in version 1.6. Sends an AIP to the beginning of transfer to run all micro-services on AIP, and re-normalize for preservation and access if desired.

Metadata re-ingest

Supported in version 1.5. Sends an AIP to the beginning of ingest to allow user to update metadata.

Partial re-ingest

Supported in version 1.5. Sends an AIP to the beginning of ingest to allow user to update metadata and normalize for access.

New micro-services

New micro-services for all workflows

• Retrieve AIP from archival storage
• Place AIP in active transfers for processing
• Extract AIP contents and run BagIt checks
• Add approve AIP re-ingest micro-service
• Re-use existing file UUIDs
• Identify new metadata files
• Validate schemas in new metadata files
• Update METS file
• Replace AIP

METS versioning

• Versioning will be captured via METS file updates.
• METS file updates will be handled through <status>, <created> and <groupID> attributes in the various METS sections. See for example Element <dmdSec> at http://www.loc.gov/standards/mets/docs/mets.v1-9.html.
• This means that there will always only be one AIP METS file, but it will contain both superseded and current metadata and versioning information for all updates.

dmdSec

• The first dmdSec created will be marked as status="original", and updated/revised dmdSecs will be marked as status="updated". The timestamp (created="[date/time]") is also updated.

amdSec

techMD

• After re-ingest, the original techMD will contain the PREMIS:Object metadata and the status="superseded."
• The next techMD will be status="current" and contain the PREMIS:Object metadata generated on re-ingest, as well as all PREMIS events from each ingest and re-ingest. This shows the complete set of actions taken upon the objects since they came into the repository.
• The timestamp (created="[date/time]") is also updated.

rightsMD

• After re-ingest, the original rightsMD will have the status="superseded" and the revised rightsMD will have the status="current".
• The timestamp (created="[date/time]") is also updated.
• Altering either the rights statement or the act(s) will result in a new rightsMD.

fileSec

The fileSec does not indicate its status, but should reflect the files in the AIP currently. For example, if normalization is not performed on the first ingest, but is performed on reingest, the fileSec in the reingested AIP will include preservation derivatives.