Difference between revisions of "DSpace exports"
| (46 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
[[Main Page]] > [[Development]] > [[:Category:Development documentation|Development documentation]] > DSpace exports | [[Main Page]] > [[Development]] > [[:Category:Development documentation|Development documentation]] > DSpace exports | ||
| − | This page | + | <div style="padding: 10px 10px; border: 1px solid black; background-color: #F79086;">This page is no longer being maintained and may contain inaccurate information. Please see the [https://www.archivematica.org/docs/latest/ Archivematica documentation] for up-to-date information. </div> <p> |
| − | = | + | =Analysis= |
| + | 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 [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: | |
| − | Used the following command 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> | ||
| Line 20: | Line 20: | ||
[[File:export.png|680px|thumb|center|]] | [[File:export.png|680px|thumb|center|]] | ||
| − | == | + | ==Item-level METS files== |
| − | The mets.xml file | + | === Link to object === |
| − | + | *The mets.xml file is linked to the object by the handle of the original zipped file: | |
| − | + | ||
| − | + | [[File:metsID.png|680px|thumb|center|]] | |
| − | * | + | |
| − | * | + | === 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): | |
| − | * | + | |
| + | [[File:fileSec.png|680px|thumb|center|]] | ||
| + | |||
| + | 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]]. | ||
| + | |||
| + | === OCR text === | ||
| + | |||
| + | If the AIP contains a scanned PDF file there will also be an accompanying ocr text file with a filename like ''bitstream_39476.txt''. This text is identified in fileSec of the METS file as USE=TEXT: | ||
| + | |||
| + | [[File:metsOCR.png|680px|thumb|center|]] | ||
| + | </br> | ||
| + | The OCR text file should remain in the objects directory of the AIP. | ||
| + | |||
| + | === RightsMD === | ||
| + | |||
| + | Each object also has an amdSec containing rightsMD data (populated automatically according to DSpace configuration settings): | ||
| + | |||
| + | [[File:rights.png|680px|thumb|center|]] | ||
| + | |||
| + | 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 [https://wiki.duraspace.org/display/DSPACE/DSpaceIntermediateMetadata 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 add 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. | ||
| + | |||
| + | [[File:fileSec.png|680px|thumb|center|]] | ||
| + | |||
| + | 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. | ||
[[Category:Development documentation]] | [[Category:Development documentation]] | ||
Latest revision as of 16:44, 11 February 2020
Main Page > Development > Development documentation > DSpace exports
Analysis[edit]
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[edit]
Link to object[edit]
- The mets.xml file is linked to the object by the handle of the original zipped file:
Licenses[edit]
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.
OCR text[edit]
If the AIP contains a scanned PDF file there will also be an accompanying ocr text file with a filename like bitstream_39476.txt. This text is identified in fileSec of the METS file as USE=TEXT:
The OCR text file should remain in the objects directory of the AIP.
RightsMD[edit]
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[edit]
- 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 add dmdSecs to the Archivematica METS file to link each object to its descriptive metadata in the DSpace METS files (i.e. using mdRef).
Checksums[edit]
Each object and license has an MD5 checksum recorded in the fileSec.
Archivematica should verify these checksums after transfer.
Collection-level mets files[edit]
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.