I'd like to add, as someone previously on the Dev-Pri group, if you have interest in the feature that Benn pointed to which he submitted, clicking on Watch, and Voting for the ticket (available after logging into Jira near the upper right portion) will greatly help in getting this ticket completed.
I can see that the ticket was already passed into ready for implementation back in February and is waiting to be picked up but with more activity, a developer might pick it up faster. Regards, Edgar Edgar Garcia Senior Software Developer IT Infrastructure Northwestern University Libraries Evanston, IL ________________________________ From: archivesspace_users_group-boun...@lyralists.lyrasis.org <archivesspace_users_group-boun...@lyralists.lyrasis.org> on behalf of Benn Joseph <benn.jos...@northwestern.edu> Sent: Thursday, October 13, 2022 1:09 PM To: Archivesspace Users Group <archivesspace_users_group@lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] how to encode open-ended date ranges? We’re largely trying to avoid using date expressions too, for the same reasons—and this ticket<https://urldefense.com/v3/__https://archivesspace.atlassian.net/browse/ANW-1273__;!!Dq0X2DkFhyF93HkjWTBQKhk!WYkOLHT2VKrv8grDaKj41Y0CRoQkRla7LnwKYEaQrJ8HBuB81B7cQ6wDh-poRPhf5N4BaPuSh-AR6akjNgcdy1tTqFfJxjCgj2UlWp4$> is something we’re hoping will be approved at some point to make the normalized dates a little easier to read for users. --Benn From: archivesspace_users_group-boun...@lyralists.lyrasis.org <archivesspace_users_group-boun...@lyralists.lyrasis.org> On Behalf Of Ron Van den Branden Sent: Thursday, October 13, 2022 11:02 AM To: Archivesspace Users Group <archivesspace_users_group@lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] how to encode open-ended date ranges? Hi Jim, Thanks for your thoughts. We’re aiming at minimizing the use of date expressions as much as possible, in order to: * Reduce the workload and avoid the need to record date information twice (once as date expression, once as standardized date) * Reduce the amount of possible input error and ambiguity caused by that redundancy In other words: if registrants have to enter a date, it would seem most efficient if they could express this as just a standardized date, which is both precise and machine-processable. Also, for exchangeability, a precise standardized representation of dates would seem preferable over date expressions, wouldn’t it? Best, Ron Van: archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org> <archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>> Namens James E. Cross Verzonden: donderdag 13 oktober 2022 16:56 Aan: Archivesspace Users Group <archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>> Onderwerp: Re: [Archivesspace_Users_Group] how to encode open-ended date ranges? Another thought: use single date in both cases and let the “Date Expression” field indicate that it is open-ended, i.e. single date “1990,” date expression “1990 - ” or single date “1990,” date expression “1990 (end date)” The date expression is what the user will see in the PUI. Jim James Cross Manuscripts Archivist Special Collections and Archives Clemson University Strom Thurmond Institute Building 230 Kappa Street Clemson, SC 29634 jcr...@clemson.edu<mailto:jcr...@clemson.edu> 864.656.5182 http://library.clemson.edu/specialcollections/<https://urldefense.com/v3/__http:/library.clemson.edu/specialcollections/__;!!Dq0X2DkFhyF93HkjWTBQKhk!Vhv7kTVtnT65Ea6wvRVHjpJxPAGILvbvp5uxHvgQMY1hz876NvjNUT1ud7NpUoLSyhAbV7lvXsqNxGnMEAdcYXey5ZmTmr7OpUUB0Iiz$> From: archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org> <archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>> On Behalf Of Ron Van den Branden Sent: Thursday, October 13, 2022 10:32 AM To: archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] how to encode open-ended date ranges? Hi, We’re in the process of migrating data to ArchivesSpace, and one thing I’m still struggling with is how to encode open-ended date ranges, using standardized dates only. In other words: how to express: * the fact that only a start date is known * or the fact that only an end date is known …while still indicating this known date is the start / end of a range whose other end is not known; as opposite to expressing a precise singular/punctual date. Given the fact that ArchivesSpace currently uses 2 distinct date models for accessions, resources/archival objects and digital objects vs agents (see https://www.mail-archive.com/archivesspace_users_group@lyralists.lyrasis.org/msg05341.html<https://urldefense.com/v3/__https:/www.mail-archive.com/archivesspace_users_group@lyralists.lyrasis.org/msg05341.html__;!!PTd7Sdtyuw!QEv9HwNAtu0O8yQ0ApRp7X3OLav3cGzG6U8Z3ZWXiSBU2UtBSlOPNIlB0iboNUhLSJYzbb8_xbHNbELs8h37VQInUry3C2sr$>), I’ll outline the observations and options I’m seeing. [1] Accessions, resources, archival objects, digital objects: * “Single” date only offers a single date field, labeled “Begin” * “Inclusive” date offers both a “Begin” and “End” date field, only one of which is required Would this be a good strategy: * “singular/punctual” dates: “single” date, one value as “Begin” date * date range: “inclusive” date, start and end dates as “Begin” and “End” dates, respectively * open-ended date range: “inclusive” date, with known date as either “Begin” or “End” date ? This leads me to the question whether in practice “single” dates are used at all for anything except accession dates, creation dates of digital objects, or as dates for only the lowest-level archival objects? [2] Agents: * “Single” date only offers a single date field, which can be labeled as either “Begin” or “End” * “Inclusive” date offers both a “Begin” and “End” date field, of which “Begin” is mandatory Would this be a good strategy: * “singular/punctual” dates: “single” date, one value as either “Begin” or “End” date Note: in EAC output, the begin/end qualification is dismissed: both are exported without distinction as e.g. <date localType="existence" standardDate="2022-10-08">2022-10-08</date> * date range: “inclusive” date, start and end dates as “Begin” and “End” dates, respectively * open-ended date range: ? ==> problem if only end date is known, since begin date is mandatory In other words: how would one differentiate between, e.g.: * birth date of a living person (1990 - ) * birth date of a deceased person, whose death date is unknown (1800 - ?) * death date of a person whose birth date is unknown (? - 1950) ? The documentation in the ArchivesSpace Help Center merely documents the different fields, but I couldn’t find much guidance on how to use them in practice. The DACS, EAD, and EAC documentation is rather sparse as well regarding open-ended date ranges. Therefore, any guidance on this matter would be much appreciated! Best, Ron Ron Van den Branden | functioneel analist - applicatiebeheerder Letterenhuis Stad Antwerpen | Talentontwikkeling en Vrijetijdsbeleving | Musea en Erfgoed Minderbroedersstraat 22, 2000 Antwerpen ✉ Grote Markt 1, 2000 Antwerpen gsm +32 0485 02 80 50 | tel. +32 3 222 93 30 letterenhuis.be<https://urldefense.com/v3/__http:/www.letterenhuis.be/__;!!PTd7Sdtyuw!QEv9HwNAtu0O8yQ0ApRp7X3OLav3cGzG6U8Z3ZWXiSBU2UtBSlOPNIlB0iboNUhLSJYzbb8_xbHNbELs8h37VQInUtO9V0vc$> | instagram<https://urldefense.com/v3/__https:/www.instagram.com/letterenhuis/__;!!PTd7Sdtyuw!QEv9HwNAtu0O8yQ0ApRp7X3OLav3cGzG6U8Z3ZWXiSBU2UtBSlOPNIlB0iboNUhLSJYzbb8_xbHNbELs8h37VQInUorJZpFU$> | facebook<https://urldefense.com/v3/__https:/www.facebook.com/Letterenhuis__;!!PTd7Sdtyuw!QEv9HwNAtu0O8yQ0ApRp7X3OLav3cGzG6U8Z3ZWXiSBU2UtBSlOPNIlB0iboNUhLSJYzbb8_xbHNbELs8h37VQInUsUvzyqI$> Proclaimer Vergissen is menselijk. Dus als deze e-mail, samen met eventuele bijlagen, niet voor u bestemd is, vragen we u vriendelijk om dat te melden aan de afzender. Deze e-mail en de bijlagen zijn namelijk officiële documenten van de stad Antwerpen. Ze kunnen vertrouwelijke of persoonlijke informatie bevatten. Als stad nemen we privacy heel serieus en willen we als een goede huisvader waken over de vertrouwelijkheid van documenten. Als u dit bericht per vergissing hebt ontvangen of ergens hebt gevonden, wees dan zo eerlijk om het meteen te verwijderen en het niet verder te verspreiden of te kopiëren.
_______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
