As an archivist, I would like to record separate date expressions for the beginning and end dates in a date range.

Description

The current version of the application only provides a single date expression field for each date subrecord. We would like to be able to record date expressions for the beginning and ending dates in an inclusive date range. We would like to be able to export this data in conformance with the EAD3 <unitdatestructured> model, and maintain compatibility with EAC-CPF.

We would also like to have existing data parsed and migrated to the new data structure.

Activity

Show:
Christine Di Bella
January 28, 2019, 7:03 PM

Just putting a note here about something to consider for the convenience part of this: https://github.com/alexduryee/timewalk

Christine Di Bella
January 28, 2019, 5:14 PM

As part of the process of working through decisions for implement the data model part of the agents specification (https://archivesspace.atlassian.net/browse/ANW-429), we're working through implications, and options, for date records. We'll definitely return to the comments here and discussion overall as part of those consideration.

Cory Nimer
September 5, 2018, 4:52 PM

Based on the feedback from received from the community, it would appear that the preferred approach for pursuing this request would be to add a second date entry option for structured dates in Resource, Archival Object, and Accession records. This option could also be included in the Digital Object and Digital Object Component records. However, based on current standards, structured dates should replace the current EAD 2002-based model used in Agent records as outlined in ANW-429, as there is no equivalent unstructured date range format in EAC-CPF.

As suggested by , some discussion is needed surrounding EDTF dates in the normalized date entry fields. EDTF is being included in the current revisions to ISO 8601 (see https://www.iso.org/standard/70907.html and https://www.iso.org/standard/70908.html), with publication expected late this year, or early 2019. This may need to be included in a separate ticket, however, as this may require modification of the EAD3 and EAC-CPF formats before implementation.

Mark Carlson
June 20, 2018, 4:05 PM

On a related note, some new standards such as RDA and EDTF have changed the way dates are formatted. We use DACS dates for collection-level dates, but we are using RDA dates for our item-level visual materials descriptions. So for instance, how would you split an RDA date expression such as "between 1940 and 1945" into two parts? Yes, we could put it in "beginning date expression", but that wouldn't really be accurate since it includes both parts of the date. It just seems like a hack to me. In an ideal world, I'd like to see a way to select the date standard you are using (much as we do with authority records) which will inform how the date is (and perhaps should be) structured.

Larry Weimer
June 19, 2018, 3:42 AM

Thanks for the clarification, Jordan.

My answer to the question would be, yes, we could live with putting the entire unstructured date expression in the structured "begin date expression" field, as long as that had no further implications, such as Jordan's PUI example or the system somehow reformatting the expression in outputs, or whatever. Nevertheless, I would much prefer Mark Carlson's approach (echoed by Angela Kroeger on the user group list) that retains the single expression, while adding the new model.

Actually, in re-reading Cory's opening comment, it seems like the idea would be for the single expression to migrate to the "begin date expression" and then repositories that wanted to would parse from that field the relevant portion into the "end date expression." If the repositories will need to parse from the single expression anyway, why not create the new data fields and have the interested repositories parse directly from the single expression field into the begin and end fields, leaving others in the unstructured field?

Larry Weimer

Assignee

Unassigned

Reporter

Cory Nimer

Affects versions

Priority

Major