[Archivesspace_Users_Group] [archivesspace] Request for community input: ANW-380

Fri Jun 15 10:28:37 EDT 2018

I'm a bit wary of making major changes to the date model, as it'll require
prescriptive policy changes for data entry.  Providing only one date
expression field allows for a degree of flexibility with semantically
meaningful dates; for example, "1950s" is a perfectly valid date expression
that wouldn't separate well into begin/end expressions.  It's also not
immediately clear how range dates like "Spring 1950" or "Early 1950" will
work in this format - archives would either need to develop rules for data
entry around these date forms, or forbid them entirely.

When developing timetwister/timewalk, my goal was to be as permissive as
possible regarding date forms, and not to make assumptions/prescriptions
about metadata rules.  This results in occasional ambiguity (e.g. "circa
1950-1960" isn't clear which dates are approximated) and minor inaccuracy
(e.g. "Spring 1950" parses to 1950-03-20/1950-06-21, which is overly
broad), but there will always be a degree of that in archival description.
My concern with the proposed date model is that it takes the opposite
approach by strictly defining date forms, even when appropriate archival
practice may not call for that level of precision.

Regarding migration - our date metadata is about as sterling as one can
reasonably expect (thanks Trevor), with ~99.99% of our dates
machine-readable and parsed, and even then I anticipate migration issues
when moving to the new date model.

One possible compromise solution would be implementing EDTF in the
Begin/End Date Standardized field, as per Seth Shaw's suggestion.  This
would allow for very precise dates when necessary (e.g. "1950~/1960",
"18xx/1920~") but without prescribing descriptive policy on archives that
don't want/need that level of accuracy.  Exporters could pull from this
field to generate structured dates and bypass the expression when
appropriate (or just don't use an expression for highly precise dates).
This would require replacing the date picker with a validated text field,
and changes to exporters / maybe the PUI, but it would be much less
disruptive than a data model modification.

Thanks,
--Alex

On Fri, Jun 15, 2018 at 4:40 AM, Chris Fitzpatrick <chrisfitzpat at gmail.com>
wrote:

>
> Hi,
>
> I think these make sense, but I also think there's a lot of "migration and
> cleanup fatigue" around archivesspace. The database schema changes quite
> frequently, which often adds a lot of work to folks doing the metadata
> management.
>
> In addition, these kinds of changes require a lot of work on the
> development side, much of which isn't really anticipated before the
> database changes roll out. . Modifications to the database schema require
> changes to the staff UI views and  forms and javascript, and ditto for the
> public UI, then the indexer and the solr schema, the backend models and
> api, the exporters, importers, the converters..oh and we usually forget
> about things like the RDE, reports, AT/Archon migration apps, various
> background jobs, and all the changes to the test suite...and then there's
> everyone's plugins, themes, and integrations that have to be updated.
>
> It sounds like this is a concern for EAD exports, so should this just be
> handled in the EAD exporter? Either the standard exporter could have logic
> added to handle the use case, or a specialized exporter could be developed
> to format the data the way that's required ( if there's too much variance
> across everyone's data to correctly map it to the desired output ).
> It might be too complicated, but it might be worth exploring that option
> before making more database changes.
>
> best,chris.
>
>
>
>
>
> On Thu, Jun 14, 2018 at 8:49 PM, Cory Nimer <cory_nimer at byu.edu> wrote:
>
>> Colleagues,
>>
>>
>>
>> The Development Prioritization Team is seeking community input on a
>> feature request for revisions to the Date subrecord in ArchivesSpace
>> (ANW-380; https://archivesspace.atlassian.net/browse/ANW-380). The Date
>> subrecord is used in multiple ArchivesSpace modules, including those for
>> Accession, Resource, and Digital Object records. Changes to the Date
>> subrecord to support the EAC-CPF <dateRange> model were previously included
>> in the Agents revision project specifications (ANW-429;
>> https://archivesspace.atlassian.net/browse/ANW-429), and the new model
>> would support either EAD2002/EAD3 <unitdate> or EAD3 <unitdatestructured>
>> exports.
>>
>>
>>
>> The primary change planned is the separation of begin and end date
>> expressions in the application. For example, currently a single date
>> expression is used with separate normalized begin and end date entries for
>> date spans:
>>
>>
>>
>> *Date subrecord*
>>
>> Date Expression: circa 1950-1960
>>
>> …
>>
>> Begin: 1950
>>
>> End: 1960
>>
>> Certainty: Approximate
>>
>>
>>
>> The revised model would include a separate date expression field entry
>> for each part of the date span:
>>
>>
>>
>> *Date subrecord*
>>
>> Begin Date Expression: circa 1950
>>
>> …
>>
>> Begin Date Standardized: 1950
>>
>>
>>
>> End Date Expression: 1960
>>
>> …
>>
>> End Date Standardized: 1960
>>
>> …
>>
>> Certainty: Approximate
>>
>>
>>
>> The concern has been raised that institutions may not have sufficiently
>> consistent data entry practices to allow a single migration script to parse
>> existing Date Expression values into separate Begin and End date expression
>> fields. One proposed path has been to move the entire existing Date
>> Expression value to the new Begin Date Expression, while moving the
>> normalized dates to their appropriate standardized value fields. This would
>> appear as:
>>
>>
>>
>> *Date subrecord*
>>
>> Begin Date Expression: circa 1950-1960
>>
>> …
>>
>> Begin Date Standardized: 1950
>>
>>
>>
>> End Date Expression:
>>
>> …
>>
>> End Date Standardized: 1960
>>
>> …
>>
>> Certainty: Approximate
>>
>>
>>
>> The Development Prioritization Team would like to obtain feedback from
>> the community regarding preferences for migrating existing Date subrecord
>> content, or other concerns. Comments may be submitted through JIRA on the
>> ticket for ANW-380 (https://archivesspace.atlassian.net/browse/ANW-380).
>>
>>
>>
>> Sincerely,
>>
>>
>>
>> Cory Nimer
>>
>> University Archivist
>>
>> Brigham Young University
>>
>> 801-422-6091
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ArchivesSpace" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to archivesspace+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> chris fitzpatrick
> http://cfitz.github.io/
>
> --
> You received this message because you are subscribed to the Google Groups
> "ArchivesSpace" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to archivesspace+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
Alexander Duryee
Metadata Archivist
New York Public Library
(917)-229-9590
alexanderduryee at nypl.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180615/4d4f4088/attachment.html>