GR Mulcaster
At UTAS SPARC, we have been testing Archivematica on v 1.7.2, with DIP uploads to AtoM version 2.4.0.
I thought it timely to share some results from Dublin Core date (dc.date) imports via Archivematica.
Having previously used ISAD templates as the basis for bulk uploads of Archival Descriptions to describe digital objects in AtoM (using up to about 28 fields within a .csv), we are now crosswalking our metadata destined for AtoM via Dublin Core to be piped through Archivematica, then DIP uploaded across to AtoM.
The dc.date field has been an unexpected stumbling block.
Archivematica to AtoM via DIP uploads will only accept ISO8601 – YYYY-MM-DD formats through the Dublin Core date fields.
Here is a series of different date formats that I test uploaded to AtoM as a DIP upload after first using the dc.date cell within a csv for upload using Dublin Core to Archivematica.
dc.date lodged in Archivematica | Transfer to AtoM via DIP upload | Result |
2017-2018 | 2017-02-01 | Created false data by inserting inaccurate dd-mm misinterpreting 2018 as second month, first day |
2018 | 2018-01-01 | Created false date by inserting inaccurate dd-mm |
12-31-2018 | None | Failed to create data entry |
31-12-2018 | 12-31-2018 | Inverted dd-mm-yyyy to mm-dd-yyyy |
31Dec18 | 2018-12-31 | Converted alphanumeric 00MTH00 string to yyyy-mm-dd |
31Dec2018 | 2018-12-31 | Converted alphanumeric 00MTH0000 string to yyyy-mm-dd |
December 31, 2018 2018-12-31 | 2018-12-31 | Converted alphanumeric text date to yyyy-mm-dd |
31 December 2018 | 31 - 12 – 18 | Converted alphanumeric text date to dd – mm – yy with odd spacing between numerals and hyphens |
2018-12-31 TO 2019-01-04 | 2018-12-31 | Converted to alphanumeric text date |
C2018 | None | Failed to create data entry |
Circa 2018 | None | Failed to create data entry |
2018-12-31T13:00:45 | 31- 12 - 18 13:00 | Converted the YYYY-DD-MMThh:mm:ss to 31 - 12 - 18 with extra spacebands, indicating formatting issue, with the seconds totally ignored in the UTC time format |
2018-12-31 | 2018-12-31 | Converted successfully as lodged |
Resources
ISO (2016). Data elements and interchange formats — Information interchange - Representation of dates and times — Part 1: Basic rules. Geneva, Switzerland: International Organization for Standardization. Retrieved from
ISO (2016a). Data elements and interchange formats — Information interchange - Representation of dates and times — Part 2: Extensions. Geneva, Switzerland: International Organization for Standardization. Retrieved from
Kuhn, M. (2004). A summary of the international standard date and time notation. Retrieved from https://www.cl.cam.ac.uk/~mgk25/iso-time.html
Wolf and Wicksteed (1997). Date and time formats, submitted to W3C 15 September 1997. Retrieved from https://www.w3.org/TR/NOTE-datetime
Approximate dates are essential for use in AtoM – and accurate date generation is very important when transferring bulk digital object Archival Descriptions across form Archivematica.
I chose to test the ISO8601 4.2.1 fields for uncertain/approximate dates to see if these fields have been implemented for Dublin Core transfer/ingest to Archivematica and from there to AtoM. I have charted the results, which were not encouraging. None of the questionmark, tilde or percentagesigns added to an approximate date string worked.
See the chart below.
Dc.date through Archivematica | After transfer to AtoM via DIP | Purpose | Result |
2018-12-31? | 2018-12-31 | To test the ISO8601 4.2.1 uncertain and or approximate dates using the YYYY-MM-DD? question mark | Question mark ignored, instead used the 2018-12-31 full date YYYY-MM-DD |
2018-12-31~ | 2018-12-31 | To test the ISO8601 4.2.1 uncertain and or approximate dates using the YYYY-MM-DD~ tilde mark | Tilde ignored, instead used the 2018-12-31 full date YYYY-MM-DD |
2018-12-31% | 2018-12-31 | To test the ISO8601 4.2.1 uncertain and or approximate dates using the YYYY-MM-DD% percentage sign | Percentage sign ignored, instead used the 2018-12-31 full date YYYY-MM-DD |
2018-12? | 2018-12-01 | To test the ISO8601 4.2.1 uncertain and or approximate dates using YYYY-MM? | Inserted incorrect date of 2018-12-01 ignoring imprecision of question mark |
2018-12~ | 2018-12-01 | To test the ISO8601 4.2.1 uncertain and or approximate dates using YYYY-MM with a tilde | Inserted incorrect date of 2018-12-01 again ignoring the approximate uncertain tilde |
2018-12% | 2018-12-01 | To test the ISO8601 4.2.1 uncertain and or approximate dates using YYYY-MM with a percentage sign | Inserted incorrect date of 2018-12-01, ignoring the percentage sign |
2018? | Failed | To test the ISO8601 4.2.1 uncertain and or approximate dates using only the Year, YYYY? question mark string | Failed to generate date |
2018~ | Failed | To test the ISO8601 4.2.1. uncertain/approx. dates using the YYYY~ tilde string | Again failed to generate date |
2018% | Failed | To test the ISO8601 4.2.1 uncertain approx dates using the YYYY% percentage sign | Failed to populate date field |
So at least I know what dates, can be properly transferred.
We are looking at the integrity of the metadata contained in the METS file within Archivematica to determine why these date fields go awry in transferring to AtoM.
