[Archivesspace_Users_Group] Duplicated agent dates in migration to 3.0.1

[Cory Nimer]

Patrick,

We found the same thing in our test migration to 3.0.1. In cases where an Agent date entry included both a date expression and normalized dates, the application had split up the 2.8 date entry into two separate entries--one for the date expression (without normalized dates) and one for the normalized dates (without date expressions). Our impression was that the application was not parsing the date expression at all.

This is a significant issue for us moving forward, and we would be interested in learning more about what approaches other institutions have been considering to address this issue.

Best,

Cory Nimer
University Archivist
Brigham Young University

From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> On Behalf Of Galligan, Patrick
Sent: Monday, June 21, 2021 12:10 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Duplicated agent dates in migration to 3.0.1

Hi all,

We've noticed that in our test migration from ArchivesSpace version 2.8.0 to 3.0.1 that the agent migration was sometimes creating two separate structured dates based on whether there was an existing date expression or not in the dates of existence section.

Here is the JSON before migration:

    "dates_of_existence": [
        {
            "lock_version": 0,
            "expression": "1915-2017",
            "begin": "1915",
            "end": "2017",
            "created_by": "pgalligan",
            "last_modified_by": "pgalligan",
            "create_time": "2019-12-04T14:24:11Z",
            "system_mtime": "2019-12-04T14:24:11Z",
            "user_mtime": "2019-12-04T14:24:11Z",
            "date_type": "range",
            "label": "existence",
            "jsonmodel_type": "date"
        }
    ],


Here is the JSON post-migration:

"dates_of_existence": [
        {
            "create_time": "2021-06-16T19:12:16Z",
            "system_mtime": "2021-06-16T19:12:16Z",
            "user_mtime": "2021-06-16T19:12:16Z",
            "lock_version": 0,
            "date_label": "existence",
            "date_type_structured": "single",
            "jsonmodel_type": "structured_date_label",
            "structured_date_single": {
                "date_expression": "1915-2017",
                "create_time": "2021-06-16T19:12:16Z",
                "system_mtime": "2021-06-16T19:12:16Z",
                "user_mtime": "2021-06-16T19:12:16Z",
                "lock_version": 0,
                "date_role": "begin",
                "date_standardized_type": "standard",
                "jsonmodel_type": "structured_date_single"
            }
        },
        {
            "create_time": "2021-06-16T19:12:16Z",
            "system_mtime": "2021-06-16T19:12:16Z",
            "user_mtime": "2021-06-16T19:12:16Z",
            "lock_version": 0,
            "date_label": "existence",
            "date_type_structured": "range",
            "jsonmodel_type": "structured_date_label",
            "structured_date_range": {
                "begin_date_standardized": "1915",
                "end_date_standardized": "2017",
                "create_time": "2021-06-16T19:12:16Z",
                "system_mtime": "2021-06-16T19:12:16Z",
                "user_mtime": "2021-06-16T19:12:16Z",
                "lock_version": 0,
                "begin_date_standardized_type": "standard",
                "end_date_standardized_type": "standard",
                "jsonmodel_type": "structured_date_range"
            }
        }
    ],

It also seems to be creating a structured singular date instead of a date range. It's parsing the expression correctly into separate dates, but it's entirely unnecessary and creates and incorrect duplication.

This seems like a bug and would stop us from updating because it'd be a hassle to go in and remove these.

Is this intended behavior for this migration? There may be something I'm not understanding about MARC or EAC-CPF that makes this desirable, but it seems like a bug to me.

Thanks,
Patrick Galligan
Rockefeller Archive Center
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20210622/e94a6715/attachment.html>