Difference between revisions of "Improvements/Dspace AIPs"
| Line 7: | Line 7: | ||
- 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. | ||
| − | Starting in May 2018, the University of Edinburgh has begun to develop a new implementation for this. See https://github.com/UoEMainLibrary/archivematica-storage-service/tree/dspace_rest . This implements a new Space in the Storage Service that talks to DSpace exclusively via the DSpace REST api (no SWORD). It | + | Starting in May 2018, the University of Edinburgh has begun to develop a new implementation for this. See https://github.com/UoEMainLibrary/archivematica-storage-service/tree/dspace_rest . This implements a new Space in the Storage Service that talks to DSpace exclusively via the DSpace REST api (no SWORD). It uses the 6.x version of the DSpace REST api. |
== User story == | == User story == | ||
Latest revision as of 12:56, 25 May 2018
Synopsis[edit]
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.
Starting in May 2018, the University of Edinburgh has begun to develop a new implementation for this. See https://github.com/UoEMainLibrary/archivematica-storage-service/tree/dspace_rest . This implements a new Space in the Storage Service that talks to DSpace exclusively via the DSpace REST api (no SWORD). It uses the 6.x version of the DSpace REST api.
User story[edit]
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[edit]
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[edit]
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)