[Archivesspace_Users_Group] Duplicated agent dates in migration to 3.0.1

[Christine Di Bella]

Patrick and Cory,

Thank you for surfacing this issue. We've looked into this more and I'd like to work with you to determine the desired outcome for migration of these dates. I'll reach out to you directly. If anyone else reading these messages has a strong interest in or suggestions for the migration of this information, would you please comment here or reach out to me to participate in these discussions?

In the meantime, I would suggest that people who have both structured dates and date expressions on Agents in their pre-3.0 ArchivesSpace hold off on migrating for now. These kinds of dates would typically be in your Dates of Existence sub-records. If pre-3.0 you have been using only the Dates field in a Name Form, or if you only use structured dates, the issue mentioned here is less likely to be pertinent to you.

Thanks for your help,
Christine

Christine Di Bella
ArchivesSpace Program Manager
christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>
800.999.8558 x2905
678-235-2905


[ASpaceOrgHomeMedium]



From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> On Behalf Of Cory Nimer
Sent: Tuesday, June 22, 2021 10:59 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Duplicated agent dates in migration to 3.0.1

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<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto: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<mailto: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/4ccacaf9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 13904 bytes
Desc: image001.jpg
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20210622/4ccacaf9/attachment.jpg>