[Archivesspace_Users_Group] normalized begin/end date display in PUI

Fri Apr 23 11:21:12 EDT 2021

Kevin - the timewalk plugin (https://github.com/alexduryee/timewalk) will
do exactly that.  I don't recall the exact source for parsing certainty (
https://github.com/alexduryee/timetwister/blob/master/lib/timetwister/utilities.rb#L18-L42),
but I based it on MODS, DCRM, and discussions with archivists/catalogers.

Benn - I'd argue that DACS-compliant Expressions are hardly bad data, but
I'm somewhat biased :)  Transforming Begin/End into clean Expressions is a
really good idea, although my primary concerns would be the number of
places that dates can appear (PUI and its PDF, SUI and its PDF,
EAD/MARC/OAI, etc.), and compressing a variety of ranges (e.g. "April 5 -
May 15, 1973" versus "1973 April 5 - May 15").  I'm sure with enough
examples of common formats and their compression, it should be achievable.

Thanks,
--Alex

On Fri, Apr 16, 2021 at 2:02 PM Benn Joseph <benn.joseph at northwestern.edu>
wrote:

> Hi everyone,
>
> Thanks for your feedback! I did create and submit a new feature request
> for changing to more human-readable dates in the PUI (basically just
> replacing the month in ISO 8601 with the spelled out English equivalent),
> which is now ANW-1273
> <https://archivesspace.atlassian.net/browse/ANW-1273>.
>
>
>
> Mark, thanks for this background info—I’m also going to submit a linked
> request for compressing the date displays in the way you describe, which is
> a great idea but seems like it might need a separate ticket. Maybe a third
> step would be a customizable display as Dan mentions below.
>
>
>
> Kevin, what you’re describing is exactly what brought this up for us
> initially. I had proposed to folks here that maybe one way to get good
> human-readable dates in the PUI would be to enter them (consistently) as
> date expressions and then have Timewalk or Timetwister normalize them for
> us. But that seemed to be living a bit on the edge, and as a member of the
> team described it: “we shouldn’t be entering bad data on purpose and hoping
> that ASpace will magically fix it for us”. I like to think I received a lot
> of tough love that day 😊
>
>
>
> Thanks,
>
> --Benn
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> *On Behalf Of *Clair,
> Kevin
> *Sent:* Wednesday, April 14, 2021 10:58 AM
> *To:* Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] normalized begin/end date
> display in PUI
>
>
>
> Hello,
>
>
>
> +1 to all of this. Our current use case seems to go the other way -- at
> Penn State the tendency is to have processing archivists provide
> human-readable date expressions, and that we would like to generate
> machine-readable begin and end dates based on that.
>
>
>
> I'm wondering how uncertain dates would figure into this. In both of the
> ArchivesSpace instances I'm familiar with there are a lot of "circa"s and
> "approximately"s, with varying ideas on how to encode them as begin and end
> dates.
>
>
>
> thanks!  -k
> ------------------------------
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of
> Custer, Mark <mark.custer at yale.edu>
> *Sent:* Wednesday, April 14, 2021 10:01 AM
> *To:* Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] normalized begin/end date
> display in PUI
>
>
>
> Benn,
>
>
>
> Yes, this is a great feature request!
>
>
>
> It was discussed as part of the PUI enhancement phase for 2.1, but never
> got added due to the additional work required (e.g., month names would also
> need to be added to the YML files for translation purposes).  It was also
> hoped that there might already be an adoptable codebase that would handle
> the logic of taking ISO-8601 (and, eventually, EDTF dates, which I think
> are now somewhat part of the newest release of ISO-8601) and transform
> those to human-readable values so that this would not have to be created
> from scratch for ArchivesSpace (maybe
> https://github.com/duke-libraries/edtf-humanize
> <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fduke-libraries*2Fedtf-humanize&data=04*7C01*7Ckmc35*40psu.edu*7Cb55e1f010f9447f0577b08d8ff4dcec6*7C7cf48d453ddb4389a9c1c115526eb52e*7C0*7C0*7C637540056959006870*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=VmJoTsOdvmcTh8hEJ3TV2bmlkn2hiQjvT7Yyv6wmXS4*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUl!!Dq0X2DkFhyF93HkjWTBQKhk!Fkq1I6E7XyinQKdUlen_4U4aO06pHrKfTJlMjvezF7IEWVXc05m_BOif_eFzWKKLXuLtj4Qc$> fits
> the bill now... at least it already has translation values, e.g.
> https://github.com/duke-libraries/edtf-humanize/blob/develop/config/locales/fr.edtf.yml#L6
> <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fduke-libraries*2Fedtf-humanize*2Fblob*2Fdevelop*2Fconfig*2Flocales*2Ffr.edtf.yml*23L6&data=04*7C01*7Ckmc35*40psu.edu*7Cb55e1f010f9447f0577b08d8ff4dcec6*7C7cf48d453ddb4389a9c1c115526eb52e*7C0*7C0*7C637540056959016861*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=vStOxOH7hU*2FBaCG*2FbO37UOogXkSLF2l*2B05f7if1obfg*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!Dq0X2DkFhyF93HkjWTBQKhk!Fkq1I6E7XyinQKdUlen_4U4aO06pHrKfTJlMjvezF7IEWVXc05m_BOif_eFzWKKLXreZ1EKB$>).
>
>
>
>
> Also, in the example that you provided below, the ideal English language
> output might be something like:  "1935 March 19-23", without repeating the
> year and month values. So, the auto-populated date displays should also be
> compressed when necessary.
>
>
>
> Mark
>
>
> ------------------------------
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Dan
> Michelson <dmichelson at smith.edu>
> *Sent:* Wednesday, April 14, 2021 6:21 AM
> *To:* Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] normalized begin/end date
> display in PUI
>
>
>
> Hi Benn,
>
>
>
> I think that's a great idea!  Ideally, we'd have a way for the format to
> be customizable (e.g., day month year for European institutions, month day,
> year for US institutions), but removing the ambiguity is more important.
>
>
>
> Dan
>
>
>
> On Tue, Apr 13, 2021 at 5:38 PM Benn Joseph <benn.joseph at northwestern.edu>
> wrote:
>
> Hi everyone,
>
> For processing projects at our institution, we’ve pretty much reached the
> point of normalizing the use of the Harvard spreadsheet ingest module in
> ASpace, which is great! One result of doing this is that we now favor
> ingesting normalized begin/end dates almost exclusively, if possible, in
> order to make searching dates easier in the ASpace PUI (meaning we
> typically do not include a date expression unless it’s something that
> cannot be conveyed in the begin/end fields).
>
>
>
> But, is anyone else bugged by the way these dates display in the PUI?
> Here’s an example from something we have currently in process:
>
>
>
>
>
> It isn’t terrible, but it’s also not the easiest to read. In addition,
> DACS seems to discourage the use of ISO 8601 for the end user:
>
>
>
> *2.4.14.* For descriptions of a single item, record exact dates in a
> consistent and unambiguous fashion, preferably expressed as year-month-day,
> i.e. 1906 March 17 (it also says “Expression of dates as all numerals is
> discouraged due to the differing conventions in the order of information”,
> and what we have here is all numerals).
>
>
>
> We could certainly add a more human-readable date expression to each of
> these archival objects, but the sentiment here is that if we have good
> data, ASpace should be able to take ‘1935-03-19’ and display ‘1935 March
> 19’ (or whatever we like) to a user pretty easily without us having to do
> any extra work. But, before I file an enhancement request, what do others
> think about this?
>
>
>
> Thanks,
>
> --Benn
>
>
>
> *Benn Joseph*
>
> Head, Collections Services
>
> McCormick Library of Special Collections & University Archives
>
> Northwestern University Libraries
>
> Northwestern University
>
> www.library.northwestern.edu
> <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?url=http*3A*2F*2Fwww.library.northwestern.edu*2F&data=04*7C01*7Ckmc35*40psu.edu*7Cb55e1f010f9447f0577b08d8ff4dcec6*7C7cf48d453ddb4389a9c1c115526eb52e*7C0*7C0*7C637540056959016861*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=L7Tt4rwjB8bJzecSTeQ26i5BNsOboQr71k2Xdh*2F6Ip8*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUl!!Dq0X2DkFhyF93HkjWTBQKhk!Fkq1I6E7XyinQKdUlen_4U4aO06pHrKfTJlMjvezF7IEWVXc05m_BOif_eFzWKKLXq7eFDMI$>
>
> benn.joseph at northwestern.edu <benn.joseph at northwestern.edu%0d>
>
> 847.467.6581
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
> <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?url=http*3A*2F*2Flyralists.lyrasis.org*2Fmailman*2Flistinfo*2Farchivesspace_users_group&data=04*7C01*7Ckmc35*40psu.edu*7Cb55e1f010f9447f0577b08d8ff4dcec6*7C7cf48d453ddb4389a9c1c115526eb52e*7C0*7C0*7C637540056959026855*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=c6lYvrhlXffiD37JlteoS9TW0Ix2PJVg5J1PxP7m4YQ*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!Dq0X2DkFhyF93HkjWTBQKhk!Fkq1I6E7XyinQKdUlen_4U4aO06pHrKfTJlMjvezF7IEWVXc05m_BOif_eFzWKKLXscSzYRR$>
>
>
>
> --
>
> Dan Michelson
>
> Project Manager Archivist
>
> Smith College Special Collections
>
>
>
> Due to COVID-19, Special Collections is offering limited, remote reference
> and digitization services and ongoing consultations for faculty, students,
> and other researchers. Smith course support is our primary responsibility
> at this time. All other requests and inquiries will be responded to as we
> are able.
>
>
> For information about Smith College’s response to Covid-19, please visit
> the Smith College Libraries
> <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?url=http*3A*2F*2Fbit.ly*2FSCLcovid-19&data=04*7C01*7Ckmc35*40psu.edu*7Cb55e1f010f9447f0577b08d8ff4dcec6*7C7cf48d453ddb4389a9c1c115526eb52e*7C0*7C0*7C637540056959036854*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=kXOc2OY9A56mfl7YfXO0JVFSEy3I7c9Sb1TXgroKYPs*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSU!!Dq0X2DkFhyF93HkjWTBQKhk!Fkq1I6E7XyinQKdUlen_4U4aO06pHrKfTJlMjvezF7IEWVXc05m_BOif_eFzWKKLXsXnOUo7$>
> and Smith College
> <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.smith.edu*2Fstudent-life*2Fhealth-wellness*2Fcoronavirus&data=04*7C01*7Ckmc35*40psu.edu*7Cb55e1f010f9447f0577b08d8ff4dcec6*7C7cf48d453ddb4389a9c1c115526eb52e*7C0*7C0*7C637540056959036854*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=WQ6qZVQLh7oyqAgwAmK4djVg24bNxKdhTroFR*2BNwwCs*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!Dq0X2DkFhyF93HkjWTBQKhk!Fkq1I6E7XyinQKdUlen_4U4aO06pHrKfTJlMjvezF7IEWVXc05m_BOif_eFzWKKLXhgt2EWm$>
> websites. For information about library services during this time,
> information is available on our website.
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>

-- 
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/20210423/4767a28c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 11705 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20210423/4767a28c/attachment.jpg>