luis100
commented
2 months ago Hello,
I am not quite understanding the use cases that are meant to be supported. In my view, AIPs live independently of SIPs, but might be affected by them, such as they might be affected by other operations such as metadata enrichment, file format convertion or even redaction or destruction by retention processes. Note also that AIPs might be created by SIPs, or by operations, such when creating an AIC (and AIP relative to a collection or a case with only metadata).
Also, I am not very confortable with this level of complexity, the versioning should be an acessory level, that you could take it or leave it without much change to the overall format of the AIP.
As such, I would like to suggest the following:
- Leave the AIP layout and storing as it was
- Have versioning support nested in an optional sub-folder under the AIP (named for example as "versions"), even at the cost of redundancy
- Versions use the OCFL format, and are always expanded (i.e. no use of TAR or other containers), so it is quite clear what changes occured from previous version.
- The AIP usual folders, such as metadata and representation, will always provide the "current" version of the AIP.
- SIPs or any other "submission" might be archived in another folder (e.g. named "submissions") and have the submission datetime (in ISO 8601 with Z timezone but without ':') recorded as SIP updates tend to have the same file name. The SIP should be archived inside the AIP as it was received.
- Relationships between submissions, action and AIP versions should be described in PREMIS. As such, it should be possible for PREMIS events to refer to a specific version of an AIP as the source or outcome object.
- Versions and Submissions are optional, their use will have a significant impact in storage and processing and their use should be defined by implementation and easy to switch on and off.
Given this, I would like to suggest the following layout of an AIP with two versions, were the first version was created by a SIP and the second version is just an update of the descriptive metadata.
urn+uuid+81bd3aa2-7350-44f6-ad54-d8181858605a
├── metadata
│ ├── descriptive
│ │ └── ead.xml
│ ├── metadata.json
│ ├── other
│ │ ├── processing.log
│ │ └── state.json
│ └── preservation
│ ├── premis_202401094-230854Z_event_sipcreation.xml
│ └── premis_20240409-230854Z_event_ingest.xml
├── METS.xml
├── representations
│ └── 09502a26-f822-407c-ad0a-4d7e64052a91
│ ├── data
│ │ └── example.pdf
│ ├── metadata
│ │ └── preservation
│ │ └── premis.xml
│ └── METS.xml
└── schemas
│ ├── csip.xsd
│ ├── ead3.xsd
│ ├── IP.xsd
│ ├── mets_1_11.xsd
│ ├── premis-v2-2.xsd
│ └── xlink.xsd
└── versions
│ ├── 0=ocfl_object_1.0
│ ├── inventory.json
│ ├── inventory.json.sha512
│ ├── v00000
│ │ └── metadata/descriptive/ead.xml
│ │ (all other files in AIP originaly received from the SIP)
│ └── v00001
│ └── metadata/descriptive/ead.xml
| (descriptive metadata updated on the digital preservation archive)
└── submissions
└──2024-04-10T11-57-00Z
└── example.sip.001.zip
carlwilson
shsdev
For the versioning of AIPs the plan is to recommend the use of OCFL.
Assuming the following structure for an original submission information package
example.sip.001.tarstored as versionv00000and an AIPurn+uuid+81bd3aa2-7350-44f6-ad54-d8181858605a.tarstored as versionv00001:The
inventory.jsoncould look as follows:Note that there is an overlap of fixity information which is provided in the METS already.
The question for voting is if the container files
example.sip.001.tarfor the original SIP andurn+uuid+81bd3aa2-7350-44f6-ad54-d8181858605a.tarfor the AIP should be wrapped in a bagit container, for example:Note that this way fixity information would possibly be provided in up to four layers:
To reduce complexity and redundancy, the proposal is store the E-ARK information package as TAR files instead of wrapping them as bagit containers as shown in the example above.
The E-ARK AIP container file
urn+uuid+81bd3aa2-7350-44f6-ad54-d8181858605a.tarwould then have the following form, for example:The suggestion is:
As part of the general AIP recommendations, the proposal is to store the E-ARK information package as TAR files instead of wrapping them as bagit containers.