Difference between revisions of "DSpace exports"
Line 3: | Line 3: | ||
This page analyzes the structure of a DSpace collection export from an uncustomized (i.e. out of the box) DSpace installation. See also [[Transfer and SIP creation#Workflow.28DSpace export.29| draft workflow]] for transferring and ingesting DSpace exports. | This page analyzes the structure of a DSpace collection export from an uncustomized (i.e. out of the box) DSpace installation. See also [[Transfer and SIP creation#Workflow.28DSpace export.29| draft workflow]] for transferring and ingesting DSpace exports. | ||
− | Used the following command (from DSpace [ | + | Used the following command (from DSpace [https://wiki.duraspace.org/display/DSDOC/AIP+Backup+and+Restore#AIPBackupandRestore-ExportingAIPs user documentation]) to export a two-item collection with the handle 123456789-6: |
<pre>./dspace packager -d -a -t AIP -e <user name> -i 123456789-6 calamy.zip</pre> | <pre>./dspace packager -d -a -t AIP -e <user name> -i 123456789-6 calamy.zip</pre> |
Revision as of 13:29, 23 September 2011
Main Page > Development > Development documentation > DSpace exports
This page analyzes the structure of a DSpace collection export from an uncustomized (i.e. out of the box) DSpace installation. See also draft workflow for transferring and ingesting DSpace exports.
Used the following command (from DSpace user documentation) to export a two-item collection with the handle 123456789-6:
./dspace packager -d -a -t AIP -e <user name> -i 123456789-6 calamy.zip
This results in the export of three zipped packages: one for the collection and one for each of the items:
- calamy.zip
- ITEM@123456789-7.zip
- ITEM@123456789-8.zip
The extracted contents of each zipped file are shown in this screenshot:
Item-level METS files
Link to object
- The mets.xml file is linked to the object by the handle of the original zipped file:
Licenses
The text file bitstreams in the two item-level directories are licenses. Note that they are not identified by filename as license files - Archivematica will need to recognize license files from each object's METS file (i.e. from fileSec). Here is an example of the fileSec showing the object to be preserved (bitstream_12.png) and its license file (bitstream_13):
Archivematica should move the license file to the metadata/submissionDocumentation directory; the text can be parsed to the rights entity in the PREMIS metadata. See PREMIS metadata: rights#License-based.
RightsMD
Each object also has an amdSec containing rightsMD data (populated automatically according to DSpace configuration settings):
This metadata can be added to the PREMIS rights entity in the rightsExtension field. See See PREMIS metadata: rights#From_DSpace_METS.
Descriptive metadata
- Each object has two dmdSecs: MODS and DSpace Intermediate Metadata (DIM).
- The DIM metadata is not intended for use outside of DSpace: according to the DSpace website, "[DIM] is used by XsltCrosswalk. It is called the Intermediate format because it is intended solely as an intermediate stage in XML-translation-based crosswalks. To reiterate, This is an INTERMEDIATE format, it is NOT for exporting or harvesting metadata!" However, in uncustomized DSpace all the metadata in the DIM fields are mapped to DC, so there may be no harm in referencing the DIM metadata in the Archivematica METS file.
- We should dmdSecs to the Archivematica METS file to link each object to its descriptive metadata in the DSpace METS files (i.e. using mdRef).
Checksums
Each object and license has an MD5 checksum recorded in the fileSec.
Archivematica should verify these checksums after transfer.
Collection-level mets files
The collection-level mets file contains MODS and DIM metadata for the collection; the descriptive metadata should be linked to the Archivematica mets file in the dmdSec using mdRef.