Difference between revisions of "TRIM exports"
Jump to navigation
Jump to search
Line 92: | Line 92: | ||
|'''n/a''' | |'''n/a''' | ||
|AtoM adds a Name field linked to the Date(s) of creation field | |AtoM adds a Name field linked to the Date(s) of creation field | ||
+ | |- | ||
+ | |<DateModified> | ||
+ | |<dc.date> | ||
+ | |<unitdate> | ||
+ | |'''Date(s) of creation''' | ||
+ | |Date range based on earliest and latest DateModified in document metadata | ||
+ | |- | ||
+ | |n/a | ||
+ | |<dcterms.extent> | ||
+ | |<physdesc> and subelement <extent> | ||
+ | |'''Physical description''' | ||
+ | |Count of documents in the SIP plus fixed text | ||
+ | |- | ||
+ | |<Notes> | ||
+ | |n/a | ||
+ | |<note> | ||
+ | |'''General note''' | ||
+ | | | ||
+ | |- | ||
+ | |<RecordNumber> | ||
+ | |<dc.identifier> | ||
+ | |<unitid> | ||
+ | |'''n/a''' | ||
+ | |AtoM adds an identifier field to archival descriptions | ||
+ | |- | ||
+ | |} | ||
+ | |||
+ | </br> | ||
+ | |||
+ | '''Sample container description''' | ||
+ | |||
+ | </br> | ||
+ | |||
+ | {| border="1" cellpadding="10" cellspacing="0" width="100%" | ||
+ | |- | ||
+ | !'''TRIM''' | ||
+ | !'''RAD''' | ||
+ | !'''Comments''' | ||
+ | |- | ||
+ | |<Information Management - IT Business Applications - Application Development and Upgrade Project Case Files - PCI Compliance> | ||
+ | |PCI Compliance | ||
+ | | | ||
+ | |- | ||
+ | |Doe, Jane | ||
+ | |Doe, Jane | ||
+ | | | ||
|- | |- | ||
|<DateModified> | |<DateModified> | ||
Line 157: | Line 203: | ||
|- | |- | ||
|} | |} | ||
+ | |||
+ | </br> | ||
===amdSecs=== | ===amdSecs=== |
Revision as of 16:50, 17 October 2012
Main Page > Development > Development documentation > TRIM exports
This page documents ingest of TRIM exports based on requirements for VanDocs ingest at City of Vancouver Archives.
TRIM export contents
A TRIM export consists of
- 1 or more containers
- A manifest of the transfer (manifest.txt)
- XML schema documentation for all xml files in the transfer (container, location and document xml metadata)
- Location metadata (Location.xml)
- Container metadata (ContainerMetadata.xml)
- Document metadata (eg DOC_2012_000100_Metadata.xml)
- Documents (eg DOC_2012_000100.docx)
Processing a TRIM export
Parsing contents to the SIP
- Each container becomes a single transfer OR each transfer is broken into one SIP per container
- manifest.txt is copied to metadata/submissionDocumentation/
- Location.xml is copied to metadata/
- All schema documentation is copied to metadata/
- The relevant ContainerMetadata.xml is copied to metadata/
- The relevant document metadata files are copied to metadata/
- All documents are copied to objects/
Verifying manifest
The contents of the transfer must be verified against the manifest.txt file during the "Verify transfer compliance" micro-service.
Verifying checksums
Each document metadata file contains an md5 checksum for the document:
These checksums must be verified during the "Verify transfer checksums" micro-service.
The AIP METS file
dmdSecs
- Each container will have one dmdSec consisting of Dublin Core metadata derived from the TRIM export metadata
- Each file will have one dmdSec consisting of Dublin Core metadata derived from the TRIM export metadata
Container metadata mapping
TRIM element | DC element | EAD element | RAD element | Comments |
---|---|---|---|---|
<TitleFreeTextPart> | <dc.title> | <unittitle> | Title proper | Remove structured part from TitleFreeTextPart |
<Creator>? | <dc.creator> | <origination> | n/a | AtoM adds a Name field linked to the Date(s) of creation field |
<DateModified> | <dc.date> | <unitdate> | Date(s) of creation | Date range based on earliest and latest DateModified in document metadata |
n/a | <dcterms.extent> | <physdesc> and subelement <extent> | Physical description | Count of documents in the SIP plus fixed text |
<Notes> | n/a | <note> | General note | |
<RecordNumber> | <dc.identifier> | <unitid> | n/a | AtoM adds an identifier field to archival descriptions |
Sample container description
TRIM | RAD | Comments | ||
---|---|---|---|---|
<Information Management - IT Business Applications - Application Development and Upgrade Project Case Files - PCI Compliance> | PCI Compliance | |||
Doe, Jane | Doe, Jane | |||
<DateModified> | <dc.date> | <unitdate> | Date(s) of creation | Date range based on earliest and latest DateModified in document metadata |
n/a | <dcterms.extent> | <physdesc> and subelement <extent> | Physical description | Count of documents in the SIP plus fixed text |
<Notes> | n/a | <note> | General note | |
<RecordNumber> | <dc.identifier> | <unitid> | n/a | AtoM adds an identifier field to archival descriptions |
File metadata mapping
TRIM element | DC element | EAD element | RAD element | Comments |
---|---|---|---|---|
<TitleFreeTextPart> | <dc.title> | <unittitle> | Title proper | |
<DateModified> | <dc.date> | <unitdate> | Date(s) of creation | |
<Notes> | n/a | <note> | General note | |
<RecordNumber> | <dc.identifier> | <unitid> | n/a | AtoM adds an identifier field to archival descriptions |
amdSecs
- Each container will have an amdSec consisting of:
- A rightsMD with an xpointer reference to the AccessControl element in metadata/ContainerMetadata.xml
- A digiprovMD with an xlink reference to metadata/ContainerMetadata.xml
- A digiprovMD with an xlink reference to metadata/Location.xml
- Each file will have an amdSec consisting of:
- A rightsMD with an xpointer reference to the AccessControl element in the relevant document metadata xml file
- A digiprovMD with an xlink reference to the the relevant document metadata xml file
- A techMD and digiprovMDs generated by Archivematica during processing
fileSec and structMaps
- Each METS file will have two structMaps, the Archivematica default structMap and a logical structMap for hierarchically arranging the container into a file and its child items
- The container and file div TYPE elements will map to the RAD Level of description field in AtoM
- The structMap contains the links between containers and files and their relevant dmdSecs
- The structMap also contains the link between the container and its amdSec
- The files are linked to their amdSecs in the fileSec