AIP Updates based on BagIt

Background

In my previous blog post, I outlined how to implement AIP updates using the BagIt (RFC 8493) ‘fetch.txt’ file.

Another option would be to link directly to the preceding AIPs. This would allow for the retrofitting of a genuine AIP update mechanism in Archivematica, as it would only require implementing a resolver for the URLs listed in the ‘fetch.txt’.

Alternative

I have illustrated the internal structure below:

AIPv1/                                      AIPv2/
  |                                           |
  +-- bag-info.txt                            +-- bag-info.txt
  |                                           |
  +-- bagit.txt                               +-- bagit.txt
  |                                           |
  +-- data/                                   +-- data/
  |     |                   fetch             |     |
  |      `-- datei1  ............             |     `-- datei2
  |                             :             |
  +-- manifest-md5.txt          ............. +-- fetch.txt
  |                                           |
  `-- tagmanifest-md5.txt                     +-- manifest-md5.txt
                                              |
                                              `--tagmanifest-md5.txt

The corresponding ‘fetch.txt’:

am://AIPv1/data/datei1 83722 data/datei1

The internal resolver of the archival information system should resolve the URL am://AIPV1/data/datei1. The resulting AIP version 2 will than reconstructed to:

AIPv2/
  |
  +-- bag-info.txt
  |
  +-- bagit.txt
  |
  +-- data/
  |     |
  |     +-- datei1
  |     |
  |     `-- datei2
  |
  +-- manifest-md5.txt
  |
  `-- tagmanifest-md5.txt

Discussion

Compared to the version in the previous blog post, this version also has a disadvantage.

None of the subsequent versions of the AIPs stand alone as AIPs. In other words, if the URL cannot be resolved, these AIPs are broken.

This can be addressed by limiting the number of AIP updates that use the BagIt ‘fetch.txt’ mechanism, or by determining this number on an individual basis depending on the risk.

I would recommend using the resolver only internally within the Archival Information System and not exposing it externally.

Since the files to be fetched—along with their checksums—must be recorded in the manifest files, the fetching process is well-secured. If errors occur within the AIS, an attempt can be made to access the n-th copy of the referenced AIP. Should the fetch fail due to a broken URL, the entire storage can, in a worst-case scenario, be searched using the checksum.