<div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>Thanks,</div><div>--Alex<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 15, 2018 at 4:40 AM, Chris Fitzpatrick <span dir="ltr"><<a href="mailto:chrisfitzpat@gmail.com" target="_blank">chrisfitzpat@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><br></div>Hi,<br><br></div>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. <br><br></div>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. <br><br></div>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 ). <br></div><div>It might be too complicated, but it might be worth exploring that option before making more database changes. <br></div><br></div>best,chris. <br><div><div><div><div><div><div><br><br><br><br></div></div></div></div></div></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Jun 14, 2018 at 8:49 PM, Cory Nimer <span dir="ltr"><<a href="mailto:cory_nimer@byu.edu" target="_blank">cory_nimer@byu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="#0563C1" vlink="#954F72" lang="EN-US">
<div class="m_8472856386980062195m_-4552382162173062068WordSection1">
<p class="MsoNormal">Colleagues,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The Development Prioritization Team is seeking community input on a feature request for revisions to the Date subrecord in ArchivesSpace (ANW-380;
<a href="https://archivesspace.atlassian.net/browse/ANW-380" target="_blank">https://archivesspace.atlassia<wbr>n.net/browse/ANW-380</a>). 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;
<a href="https://archivesspace.atlassian.net/browse/ANW-429" target="_blank">https://archivesspace.atlassia<wbr>n.net/browse/ANW-429</a>), and the new model would support either EAD2002/EAD3 <unitdate> or EAD3 <unitdatestructured> exports.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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:
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:.5in"><u>Date subrecord<u></u><u></u></u></p>
<p class="MsoNormal" style="margin-left:.5in">Date Expression: circa 1950-1960<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">…<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">Begin: 1950<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">End: 1960<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">Certainty: Approximate<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The revised model would include a separate date expression field entry for each part of the date span:
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:.5in"><u>Date subrecord<u></u><u></u></u></p>
<p class="MsoNormal" style="margin-left:.5in">Begin Date Expression: circa 1950<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">…<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">Begin Date Standardized: 1950<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:.5in">End Date Expression: 1960<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">…<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">End Date Standardized: 1960<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">…<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">Certainty: Approximate<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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:
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:.5in"><u>Date subrecord<u></u><u></u></u></p>
<p class="MsoNormal" style="margin-left:.5in">Begin Date Expression: circa 1950-1960<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">…<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">Begin Date Standardized: 1950<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:.5in">End Date Expression: <u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">…<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">End Date Standardized: 1960<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">…<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">Certainty: Approximate<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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
(<a href="https://archivesspace.atlassian.net/browse/ANW-380" target="_blank">https://archivesspace.atlassi<wbr>an.net/browse/ANW-380</a>).
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Sincerely,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Cory Nimer<u></u><u></u></p>
<p class="MsoNormal">University Archivist<u></u><u></u></p>
<p class="MsoNormal">Brigham Young University<u></u><u></u></p>
<p class="MsoNormal">801-422-6091<span class="m_8472856386980062195HOEnZb"><font color="#888888"><u></u><u></u></font></span></p><span class="m_8472856386980062195HOEnZb"><font color="#888888">
</font></span></div><span class="m_8472856386980062195HOEnZb"><font color="#888888">
</font></span></div><span class="m_8472856386980062195HOEnZb"><font color="#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "ArchivesSpace" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:archivesspace+unsubscribe@googlegroups.com" target="_blank">archivesspace+unsubscribe@goog<wbr>legroups.com</a>.<br>
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/op<wbr>tout</a>.<br>
</font></span></blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_8472856386980062195gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>chris fitzpatrick<br></div><a href="http://cfitz.github.io/" target="_blank">http://cfitz.github.io/</a><br></div></div>
</font></span></div><div class="HOEnZb"><div class="h5">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "ArchivesSpace" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:archivesspace+unsubscribe@googlegroups.com" target="_blank">archivesspace+unsubscribe@<wbr>googlegroups.com</a>.<br>
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/<wbr>optout</a>.<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Alexander Duryee<div>Metadata Archivist</div><div>New York Public Library</div><div>(917)-229-9590</div><div><a href="mailto:alexanderduryee@nypl.org" target="_blank">alexanderduryee@nypl.org</a></div></div></div></div></div>
</div>