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

Fri Jun 15 11:30:31 EDT 2018

If I may chime in.  It would help if AS would allow something like  
February 30, any year as the unknown date. I found that the ladies of  
old would place this date on their tombstones.

Br Raphael
Quoting Alexander Duryee <alexanderduryee at nypl.org>:

> 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