Difference between revisions of "Improvements/Dspace AIPs"
(Created page with "== Synopsis == Using DSpace as an AIP storage location is available in the 0.10.0 release of the Storage Service. The current implementation: - AIPs are delivered by the Sto...") |
|||
Line 3: | Line 3: | ||
Using DSpace as an AIP storage location is available in the 0.10.0 release of the Storage Service. The current implementation: | Using DSpace as an AIP storage location is available in the 0.10.0 release of the Storage Service. The current implementation: | ||
− | - AIPs are delivered by the Storage Service to DSpace as split: one zip file for the objects directory, and one for the metadata directory which contains all the bag artifacts and any metadata and submission documentation included in the AIP. This allows the metadata, etc., to be restricted from access in DSpace. | + | - AIPs are delivered by the Storage Service to DSpace via SWORD as split AIPs: one zip file for the objects directory, and one for the metadata directory which contains all the bag artifacts and any metadata and submission documentation included in the AIP. This allows the metadata, etc., to be restricted from access in DSpace, which is done using a setting in the SS Space. |
- The Storage Service does not know the final location of the AIP, and therefore it cannot be retrieved either through the Storage Service or the Archivematica dashboard. | - The Storage Service does not know the final location of the AIP, and therefore it cannot be retrieved either through the Storage Service or the Archivematica dashboard. | ||
- The pointer file does not contain information about the location of the AIP or the fact that it has been split. | - The pointer file does not contain information about the location of the AIP or the fact that it has been split. | ||
Line 15: | Line 15: | ||
These are proposed fixes to the current implementation, in order of relative importance (suggestions are welcome!) | These are proposed fixes to the current implementation, in order of relative importance (suggestions are welcome!) | ||
− | 1. | + | 1. Update the Packages tab in the Storage Service to show the full DSpace handle (including URL) under Current Location. Currently it shows a location which was used temporarily before the AIP was stored in DSpace. Ideally the Dashboard would also be updated so that if you attempt to download the AIP, you are sent to the correct DSpace URL instead. |
+ | |||
+ | OR | ||
+ | |||
+ | 2. Ability to download the AIP from the Storage Service and the Dashboard. This means the Storage Service needs to "stitch" the AIP back together after getting the two packages from DSpace. | ||
+ | |||
+ | 3. The DSpace handle for the item (AIP) should be stored in the pointer file as the mets:FLocat. Currently, the DSpace handle for the collection is used: | ||
+ | |||
+ | <pre> | ||
+ | |||
+ | <mets:FLocat OTHERLOCTYPE="SYSTEM" LOCTYPE="OTHER" xlink:href="http:/dspace5x.archivematica.org:8080/swordv2/collection/123456789/57/http:/dspace5x.archivematica.org:8080/swordv2/statement/113.atom"/> | ||
+ | |||
+ | </pre> | ||
+ | |||
+ | 4. The pointer file should have a premis:Event for splitting the AIP, similar to [[LOCKSS_Integration|LOCKSS integration]]- see [[LOCKSS_Integration#Package_split.2C_local_copy_deleted|Package split, local copy deleted]]. | ||
+ | |||
+ | == Other improvements == | ||
+ | |||
+ | There are other improvements to consider for the future as well: | ||
+ | |||
+ | - ability to choose DSpace target collection or community for storage without needing to create/edit the Storage Service space. | ||
+ | - support for different compression types (currently hardcoded to 7zip, will change to zip in 1.7 release) |
Revision as of 15:02, 7 February 2017
Synopsis
Using DSpace as an AIP storage location is available in the 0.10.0 release of the Storage Service. The current implementation:
- AIPs are delivered by the Storage Service to DSpace via SWORD as split AIPs: one zip file for the objects directory, and one for the metadata directory which contains all the bag artifacts and any metadata and submission documentation included in the AIP. This allows the metadata, etc., to be restricted from access in DSpace, which is done using a setting in the SS Space. - The Storage Service does not know the final location of the AIP, and therefore it cannot be retrieved either through the Storage Service or the Archivematica dashboard. - The pointer file does not contain information about the location of the AIP or the fact that it has been split.
User story
As an archivist, I require my digital preservation system to know a., the location of my AIPs, and b., all preservation events that pertain to my AIPs.
Suggested fixes
These are proposed fixes to the current implementation, in order of relative importance (suggestions are welcome!)
1. Update the Packages tab in the Storage Service to show the full DSpace handle (including URL) under Current Location. Currently it shows a location which was used temporarily before the AIP was stored in DSpace. Ideally the Dashboard would also be updated so that if you attempt to download the AIP, you are sent to the correct DSpace URL instead.
OR
2. Ability to download the AIP from the Storage Service and the Dashboard. This means the Storage Service needs to "stitch" the AIP back together after getting the two packages from DSpace.
3. The DSpace handle for the item (AIP) should be stored in the pointer file as the mets:FLocat. Currently, the DSpace handle for the collection is used:
<mets:FLocat OTHERLOCTYPE="SYSTEM" LOCTYPE="OTHER" xlink:href="http:/dspace5x.archivematica.org:8080/swordv2/collection/123456789/57/http:/dspace5x.archivematica.org:8080/swordv2/statement/113.atom"/>
4. The pointer file should have a premis:Event for splitting the AIP, similar to LOCKSS integration- see Package split, local copy deleted.
Other improvements
There are other improvements to consider for the future as well:
- ability to choose DSpace target collection or community for storage without needing to create/edit the Storage Service space. - support for different compression types (currently hardcoded to 7zip, will change to zip in 1.7 release)