[Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace

[Ron Van den Branden]

Hi all,

This is my first message to this group; apologies if this has been addressed 
before (tried my best researching the list archive at 
https://www.mail-archive.com/archivesspace_users_group@lyralists.lyrasis.org/). 
At my institution, we’re preparing a migration of data from a previous archival 
description system to ArchivesSpace. The previous system allowed for structured 
links between archival descriptions within the system. For example, resource A 
could point to resource B within the same system by means of a system 
identifier, which the system would resolve to a full link in the PUI. This is 
functioning in a similar way as Agents Links or Related Accessions sections in 
ArchivesSpace; only with a different record type (resources / archival objects 
instead of agents, resp. accessions).

Please correct me if I’m wrong, but I don’t see an immediate equivalent 
mechanism in ArchivesSpace. This raises some questions:

  *   Am I overlooking the obvious, and does ArchivesSpace provide a structured 
mechanism to point from a Resource / Archival Object to another Resource / 
Archival Object?
  *   If not, I do see the External Documents section as a close fit, with the 
semantic drawback that these linked resources are not really external but 
rather internal. More substantially, though, External Documents only allows for 
a literal URL, which is less elegant, more error-prone, and less sustainable 
than the dynamically generated links provided via Agent Links or Related 
Accessions.
  *   If not, is this something that’s on a development roadmap, or have others 
implemented this as a plug-in?

Many thanks for your thoughts!

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<http://www.letterenhuis.be/> | 
instagram<https://www.instagram.com/letterenhuis/> | 
facebook<https://www.facebook.com/Letterenhuis>

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

Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace

[Ron Van den Branden]

Thanks for that pointer, Cory! I’m probably a tad late at that party to give my 
support, though it seems like a useful idea (from a user perspective).

Best,

Ron

Van: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 Namens Cory Nimer
Verzonden: woensdag 25 mei 2022 17:15
Aan: Archivesspace Users Group 
Onderwerp: Re: [Archivesspace_Users_Group] linking to related Resources / 
Archival Objects in ArchivesSpace

Ron,

I would agree that it would be preferable to have a more EAD3-friendly 
configuration for related materials notes, at least in order to reduce/remove 
the need for mixed content within these notes. I don't know if there is 
widespread interest in moving implementing something more like the Agents 
module's Sources subrecord or the Metadata Rights Declarations with their 
fields for recording a descriptive note and a URL separately. It looks like the 
project has already rejected the idea of being allowing linking between 
different records within the database, though (ANW-763; 
https://archivesspace.atlassian.net/browse/ANW-763).

Best,

Cory Nimer
University Archivist
Brigham Young University

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of Ron Van den Branden
Sent: Wednesday, May 25, 2022 10:05 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] linking to related Resources / 
Archival Objects in ArchivesSpace

Hi Corey,

Many thanks for your helpful reply! In our current data, these structured links 
are indeed connected to a field that maps to  in 
ArchivesSpace, so that’s indeed the destination we had in mind.

Your example for embedding ArchivesSpace-internal links via the ArchivesSpace 
ID for a @href attribute was really helpful and finally made me get it working 
in the test instance, great! That’s a useful mechanism, though I fully agree 
the manual input process is brittle, even with the (limited) “mixed content” 
completion help. In order to make the most semantic sense, as you exemplified 
with the  example, our colleagues and volunteers describing the 
archives would have to be knowledgeable of XML syntax rules, and the suitable 
EAD structures for the information they’d want to enter. Yet, even if a new 
structured resource-to-resource link field would be too far off the 
implementation horizon, perhaps a general improvement for adding such internal 
cross-links in text fields in a more guided way could be of interest. I’ll 
think about it!

Finally, your data audit remark sounds intriguing and -considering the amount 
of data cleanup this data migration project has confronted us with- a vital 
part of best practice. Would you mind elaborating on that, or pointing me to 
any available documentation?

Best,

Ron

Van: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 Namens Corey Schmidt
Verzonden: woensdag 25 mei 2022 14:57
Aan: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Onderwerp: Re: [Archivesspace_Users_Group] linking to related Resources / 
Archival Objects in ArchivesSpace

Hey Ron,

Glad to see you reaching out! I’m not sure if others have emailed you regarding 
this, so I’ll put in my 2 cents worth.

  *   From what I understand, there is no mechanism within ArchivesSpace that 
provides a structured “Agents/Related Accessions” type link from one resource 
to another, nor one archival object to another.
  *   Have you considered using the “Related Materials” note 
(<https://www.loc.gov/ead/tglib/elements/relatedmaterial.html>)?
 The advantage with this is the note is made specifically for related materials 
either within the repository or without and you don’t need a full URL, just the 
ArchivesSpace ID if you’re using the PUI, like so: Related Collection title. The 
problem with this is you have to enter the info by hand, which is error prone 
(we’ve scheduled a yearly “data audit” to help us catch errors like these).
  *   I don’t know of any institution that has developed a 
plugin<https://github.com/archivesspace/awesome-archivesspace>, nor is this on 
the roadmap I think. Nevertheless, you can submit a JIRA 
ticket<https://archivesspace.atlassian.net/jira/software/c/projects/ANW/issues/ANW-1334>
 for this feature (how to do that linked 
here<https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/19202060/How+to+Request+a+New+Feature>)
 – explaining how you want it to work with as much detail as possible. The 
Development Priority Team will then determine if the ArchivesSpace development 
team or community can/should prioritize it in future releases. The more 
attention a 

Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace

[Ron Van den Branden]

Whoa, thanks for sharing both your code and those pointers, Corey! That’s study 
stuff for when the dust’ll have settle a bit.

I’ll present the current option for internal linking in ArchivesSpace to our 
colleagues and IT partner; if this leads to structured suggestions for 
improvement, it would be great if that could result in a Jira ticket. Many 
thanks in advance for your support.

Best,

Ron


Van: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 Namens Corey Schmidt
Verzonden: woensdag 25 mei 2022 17:29
Aan: Archivesspace Users Group 
Onderwerp: Re: [Archivesspace_Users_Group] linking to related Resources / 
Archival Objects in ArchivesSpace

Ron,

My pleasure! I’m glad the example helped get you going for your test instance. 
Thanks for the follow-up Cory. It’s a shame that functionality was rejected, 
but understandable.

As you pointed out Ron, it’s still a brittle process, not helped by the fact 
that it’s sometimes difficult to ask colleagues/volunteers to familiarize 
themselves with XML syntax and EAD tags and attributes. If after considering 
improvements for internal cross-links you want to post a ticket and need/want 
help, just let me know! I’m happy to make suggestions and give a +1.

Sure, after migrating to ArchivesSpace, we compiled a bunch of tests we did for 
checking our data. I wrote a python 
script<https://github.com/uga-libraries/aspace_scripts/blob/master/ASpace_Data_Audit.py>
 to do the tests, create a spreadsheet with the results, email those results to 
our users, and I worked with our sysadmin to make a cron job to run the script 
once a year. It checks:

  *   controlled vocabularies for non-permitted terms
  *   resources/items with Component Unique IDs (we don’t use them)
  *   containers with no barcodes or indicators
  *   archival objects with multiple containers or digital objects
  *   archival objects falsely labeled as “collection” level
  *   EAD-IDs (we make these in our EAD.xml exporter)
  *   duplicate subjects and agents
  *   archival objects on the same level but have different labels (i.e. a file 
and series on the same level together)
  *   XML errors
  *   URL errors

With a little programming knowledge, you could modify this script or make one 
yourself. There’s also a number YouTube videos on data cleanup in 
ArchivesSpace: ArchivesSpace Data Cleanup Webinar: Tips, Tricks, and 
Tools<https://www.youtube.com/watch?v=SnZErWH0XmU>, How to Make Technology Work 
for You In an ArchivesSpace Data Cleanup 
Project<https://www.youtube.com/watch?v=PTuROXsEjqo>, Someday is Here! 
ArchivesSpace Projects for Working from 
Home<https://www.youtube.com/watch?v=LupV331hg8E>.

Corey

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of Cory Nimer
Sent: Wednesday, May 25, 2022 11:15 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] linking to related Resources / 
Archival Objects in ArchivesSpace

[EXTERNAL SENDER - PROCEED CAUTIOUSLY]
Ron,

I would agree that it would be preferable to have a more EAD3-friendly 
configuration for related materials notes, at least in order to reduce/remove 
the need for mixed content within these notes. I don't know if there is 
widespread interest in moving implementing something more like the Agents 
module's Sources subrecord or the Metadata Rights Declarations with their 
fields for recording a descriptive note and a URL separately. It looks like the 
project has already rejected the idea of being allowing linking between 
different records within the database, though (ANW-763; 
https://archivesspace.atlassian.net/browse/ANW-763).

Best,

Cory Nimer
University Archivist
Brigham Young University

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of Ron Van den Branden
Sent: Wednesday, May 25, 2022 10:05 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] linking to related Resources / 
Archival Objects in ArchivesSpace

Hi Corey,

Many thanks for your helpful reply! In our current data, these structured links 
are indeed connected to a field that maps to  in 
ArchivesSpace, so that’s indeed the destination we had in mind.

Your example for embedding ArchivesSpace-internal links via the ArchivesSpace 
ID for a @href attribute was really helpful and finally made me get it working 
in the test instance, great! That’s a useful mechanism, though I fully agree 
the manual input process is brittle, even with the (limited) “mixed content” 
completion help. In order to make the most semantic sense, as you e

Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace

[Ron Van den Branden]

Hi Corey,

Many thanks for your helpful reply! In our current data, these structured links 
are indeed connected to a field that maps to  in 
ArchivesSpace, so that’s indeed the destination we had in mind.

Your example for embedding ArchivesSpace-internal links via the ArchivesSpace 
ID for a @href attribute was really helpful and finally made me get it working 
in the test instance, great! That’s a useful mechanism, though I fully agree 
the manual input process is brittle, even with the (limited) “mixed content” 
completion help. In order to make the most semantic sense, as you exemplified 
with the  example, our colleagues and volunteers describing the 
archives would have to be knowledgeable of XML syntax rules, and the suitable 
EAD structures for the information they’d want to enter. Yet, even if a new 
structured resource-to-resource link field would be too far off the 
implementation horizon, perhaps a general improvement for adding such internal 
cross-links in text fields in a more guided way could be of interest. I’ll 
think about it!

Finally, your data audit remark sounds intriguing and -considering the amount 
of data cleanup this data migration project has confronted us with- a vital 
part of best practice. Would you mind elaborating on that, or pointing me to 
any available documentation?

Best,

Ron

Van: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 Namens Corey Schmidt
Verzonden: woensdag 25 mei 2022 14:57
Aan: Archivesspace Users Group 
Onderwerp: Re: [Archivesspace_Users_Group] linking to related Resources / 
Archival Objects in ArchivesSpace

Hey Ron,

Glad to see you reaching out! I’m not sure if others have emailed you regarding 
this, so I’ll put in my 2 cents worth.

  *   From what I understand, there is no mechanism within ArchivesSpace that 
provides a structured “Agents/Related Accessions” type link from one resource 
to another, nor one archival object to another.
  *   Have you considered using the “Related Materials” note 
(<https://www.loc.gov/ead/tglib/elements/relatedmaterial.html>)?
 The advantage with this is the note is made specifically for related materials 
either within the repository or without and you don’t need a full URL, just the 
ArchivesSpace ID if you’re using the PUI, like so: Related Collection title. The 
problem with this is you have to enter the info by hand, which is error prone 
(we’ve scheduled a yearly “data audit” to help us catch errors like these).
  *   I don’t know of any institution that has developed a 
plugin<https://github.com/archivesspace/awesome-archivesspace>, nor is this on 
the roadmap I think. Nevertheless, you can submit a JIRA 
ticket<https://archivesspace.atlassian.net/jira/software/c/projects/ANW/issues/ANW-1334>
 for this feature (how to do that linked 
here<https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/19202060/How+to+Request+a+New+Feature>)
 – explaining how you want it to work with as much detail as possible. The 
Development Priority Team will then determine if the ArchivesSpace development 
team or community can/should prioritize it in future releases. The more 
attention a ticket gets (comments, clarifications, etc.) the more likely it is 
to be implemented (great YouTube video here about the 
process<https://www.youtube.com/watch?v=jlquifRXwmA>).

I hope this is helpful, but if you’d like to talk more about it, feel free to 
email me: corey.schm...@uga.edu<mailto:corey.schm...@uga.edu>. To everyone on 
the listserv, please feel free to correct any of this info if it’s 
incorrect/misleading.

Sincerely,

Corey
Corey Schmidt
Special Collections Libraries | Project Management Librarian/Archivist
300 S Hull St | Athens, GA 30605
corey.schm...@uga.edu<mailto:corey.schm...@uga.edu>
From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of Ron Van den Branden
Sent: Wednesday, May 18, 2022 3:45 PM
To: 
archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] linking to related Resources / Archival 
Objects in ArchivesSpace

[EXTERNAL SENDER - PROCEED CAUTIOUSLY]
Hi all,

This is my first message to this group; apologies if this has been addressed 
before (tried my best researching the list archive at 
https://www.mail-archive.com/archivesspace_users_group@lyralists.lyrasis.org/). 
At my institution, we’re preparing a migration of data from a previous archival 
description system to ArchivesSpace. The previous system allowed for structured 
links between archival descriptions within the system. For example, resource A 
could point to resource B within the same system by means of a system 
identifier, which the system would resolve to a full link in the PUI. This is 
functioning in a similar way as Agents 

[Archivesspace_Users_Group] different date models for Agents vs Accessions, Resources, Archival Objects?

[Ron Van den Branden]

Hi,

I'm wondering why different date models exist for different record types in 
ArchivesSpace:


  *   Accessions + Resources/Archival Objects:
 *   Date Certainty: general certainty qualifier: "Approximate", 
"Inferred", "Questionable"
  *   Agents:
 *   Date Certainty: general certainty qualifier: "Approximate", 
"Inferred", "Questionable"
 *   Standardized Date Type: specific qualifier for both Begin and End 
date: "Standard", "Not Before", "Not After"

The extra field Standardized Date Type is occurring consistently for all date 
fields in the Agents module.

This raises some questions:


  *   What's the motivation for this difference? Is it standards-based, and 
does EAC-CPF allow for more detail than EAD? Or is is because the Agents module 
has been reworked more recently?
  *   In the latter case, is any harmonization foreseen for the date fields in 
Accessions and Resources/Archival Objects? If so, is there a time frame?

Many thanks for your thoughts!

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<http://www.letterenhuis.be/> | 
instagram<https://www.instagram.com/letterenhuis/> | 
facebook<https://www.facebook.com/Letterenhuis>

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

Re: [Archivesspace_Users_Group] how to encode open-ended date ranges?

[Ron Van den Branden]

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 
 Namens James E. Cross
Verzonden: donderdag 13 oktober 2022 16:56
Aan: Archivesspace Users Group 
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/

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto: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.
2022-10-08

  *   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 | function

[Archivesspace_Users_Group] how to encode open-ended date ranges?

[Ron Van den Branden]

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),
 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.
2022-10-08

  *   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<http://www.letterenhuis.be/> | 
instagram<https://www.instagram.com/letterenhuis/> | 
facebook<https://www.facebook.com/Letterenhuis>

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

Re: [Archivesspace_Users_Group] how to encode open-ended date ranges?

[Ron Van den Branden]

Hi Kate,

I realize my analysis might have been biased by a data-oriented view on our 
current data, which contains quite a number of archival objects with only a 
start date, and some with only an end date. I’ve asked my colleagues, and 
open-ended dates are indeed uncommon for resources, accessions, archival, or 
digital objects: they’ll be mostly ranges with a known start and end date.

How to interpret these single dates in our data is probably a matter of 
internal interpretation on our end, but still: what is the intended/preferred 
notation in ArchivesSpace? If the creation time span for a subseries is 
determined as e.g. 1969, how should this be encoded:

  *   Single date
 *   Begin date = 1969
  *   Inclusive date
 *   Begin date = 1969
 *   End date = 1969
?

Best,

Ron

Van: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 Namens Bowers, Kate A.
Verzonden: donderdag 13 oktober 2022 16:57
Aan: Archivesspace Users Group 
Onderwerp: Re: [Archivesspace_Users_Group] how to encode open-ended date ranges?

Can you explain the case for open-ended dates for resources, accessions, 
archival, or digital objects?

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto: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.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchive.com_archivesspace-5Fusers-5Fgroup-40lyralists.lyrasis.org_msg05341.html=DwMGaQ=WO-RGvefibhHBZq3fL85hQ=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY=hwhUWCl8DmiVBAr8KCWWuvqIpF5qGU38NpEyKdpmIIC_b1sDZ08xKIYeni9Jn1Sz=cH9UvNvbKkbEcG88o6pqGcf3-0l_7L5sIV0c3bplsR8=>),
 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.
2022-10-08

  *   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 

Re: [Archivesspace_Users_Group] different date models for Agents vs Accessions, Resources, Archival Objects?

[Ron Van den Branden]

Hi Christine,

Many thanks for your helpful response, and pointers to those interesting issues!

Best,

Ron

Van: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 Namens Christine Di 
Bella
Verzonden: woensdag 5 oktober 2022 18:30
Aan: Archivesspace Users Group 
Onderwerp: Re: [Archivesspace_Users_Group] different date models for Agents vs 
Accessions, Resources, Archival Objects?

Hello Ron,

The divergence of the two date models within ArchivesSpace did come about with 
the work on the Agents module. While the plan is to eventually move other 
record types for which it makes sense to the same model (there are some related 
requests at https://archivesspace.atlassian.net/browse/ANW-1475 and 
https://archivesspace.atlassian.net/browse/ANW-380), because dates are so 
complex and because the agents work was underway already, we treated the work 
on dates associated with agents as a first step. The motivation for the change 
was specific to the EAC-CPF standard, though it has broader applicability with 
EAD as well.

I don’t have a specific timeframe for moving other dates in the application to 
this model right now. One of our thoughts in staging this date transition was 
that we wanted to get feedback on the agents dates piece before taking the even 
larger step of moving the other record types (and migrating the associated 
data) to that model. We haven’t received much feedback on the agents yet, 
possibly because a lot of people haven’t upgraded to a 3.x version yet or 
possibly because the new date model meets their needs just fine. We are 
currently reviewing prioritized projects against capacity in light of staffing 
changes and I intend to share more information and an updated roadmap soon.

I hope that helps. If you have other questions, or if anyone here has 
background or feedback specific to the agents date model, we’d be glad to have 
them.

Christine

Christine Di Bella
ArchivesSpace Program Manager
christine.dibe...@lyrasis.org<mailto:christine.dibe...@lyrasis.org>
800.999.8558 x2905
678-235-2905

[ASpaceOrgHomeMedium]



From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of Ron Van den Branden
Sent: Wednesday, October 5, 2022 9:56 AM
To: 
archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] different date models for Agents vs 
Accessions, Resources, Archival Objects?

Hi,

I'm wondering why different date models exist for different record types in 
ArchivesSpace:


  *   Accessions + Resources/Archival Objects:

 *   Date Certainty: general certainty qualifier: "Approximate", 
"Inferred", "Questionable"

  *   Agents:

 *   Date Certainty: general certainty qualifier: "Approximate", 
"Inferred", "Questionable"
 *   Standardized Date Type: specific qualifier for both Begin and End 
date: "Standard", "Not Before", "Not After"

The extra field Standardized Date Type is occurring consistently for all date 
fields in the Agents module.

This raises some questions:


  *   What's the motivation for this difference? Is it standards-based, and 
does EAC-CPF allow for more detail than EAD? Or is is because the Agents module 
has been reworked more recently?
  *   In the latter case, is any harmonization foreseen for the date fields in 
Accessions and Resources/Archival Objects? If so, is there a time frame?

Many thanks for your thoughts!

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<http://www.letterenhuis.be/> | 
instagram<https://www.instagram.com/letterenhuis/> | 
facebook<https://www.facebook.com/Letterenhuis>

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

Re: [Archivesspace_Users_Group] [External] Collection CSV export

[Ron Van den Branden]

Hi all,

This looks like a very interesting piece of functionality. I'm still intrigued 
by Paul's question:

Regarding being in the core code, I see a 
Github page for it but I 
can't see it mentioned in any of the release notes recently, or any information 
in the import/export 
section
 of the documentation, or in Jira. Can anybody confirm if this is the case or 
is planned?

When checking the official ArchivesSpace code tree in Github, I don't find any 
traces of bulk_update files. Does anyone know more about the status or plans?

Best,

Ron


From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Paul 
Sutherland 
Sent: 25 May 2023 23:18
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] [External] Collection CSV export


WAARSCHUWING: DIT IS EEN EXTERNE MAIL

Deze mail komt van buiten onze organisatie. Kijk eerst of je het mailadres en 
de afzender herkent en/of vertrouwt. Doe dat voor je bijlagen opent of links 
aanklikt. Zo houden we onze organisatie veiliger voor phishing.

Hi Sarit,
Thank you for pointing me to this. We've got it installed and it looks like it 
works smoothly for our purposes right now.
Best,
Paul

On Tue, May 16, 2023 at 9:08 AM Paul Sutherland 
mailto:psutherl...@amphilsoc.org>> wrote:
Hi Sarit,

Thank you - I hadn't noticed this plugin. This sounds like it might be what 
we're looking for.

Regarding being in the core code, I see a 
Github page for it but I 
can't see it mentioned in any of the release notes recently, or any information 
in the import/export 
section
 of the documentation, or in Jira. Can anybody confirm if this is the case or 
is planned?

Best,
Paul


On Thu, May 11, 2023 at 5:46 PM Hand, Sarit mailto:sh...@ap.org>> 
wrote:

Hi Paul,



Right off the cuff I would suggest looking at the bulk updater which is now 
part of the core code in the newest version (I believe).  It was a plugin. You 
can granularly select which records to export into a CVS/excel spreadsheet 
including many of the sub-records.



Hope that is useful.



Cheers,



[cid:188249a8fd84cff311]



Sarit Hand

Digital Archivist
AP Corporate Archives

200 Liberty Street

New York, NY 10281

T 212.621.7035



sh...@ap.org
ap.org

[cid:188249a8fd85b16b22]





From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of Paul Sutherland
Sent: Thursday, May 11, 2023 5:04 PM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Collection CSV export



[EXTERNAL]

Hi all,



I'm looking for a way to export a CSV of all the Archival Objects under a 
specific Resource (collection). The goal would be to generate a CSV of every 
child archival object (through all levels of hierarchy*), including all fields 
that have been filled for each archival object. Essentially the opposite of the 
CSV import function.



Specific use cases include making folder labels, producing reports on 
collections' objects, transforming the data for other purposes, running large 
granular searches, etc.



I've looked around plugins and custom reports and nothing appears to match this 
exactly. I wanted to reach out to the community here to see if anyone has 
created such a tool.



There are a couple of ways I can see this being implemented:

  *   a button on the Resource level for Download CSV, under Export

[cid:188249a8fd9692e333]

  *   a version of Report. Report lets you produce a CSV of every archival 
object in the repository but it's limited to 5 results and doesn't let you 
narrow down by parent, as far as I can see.

Thank you for your help,

Paul



(*it could also be all immediate children of a specific archival object rather 
than only the resource level, though this doesn't interact as apparently neatly 
with the rest of the interface).

--

Paul Sutherland (he/his)
Archivist of Indigenous Materials
Center for Native American and Indigenous Research

Library & Museum
American Philosophical Society
105 S. 5th Street, 2nd Floor
Philadelphia, PA 19406

Lenapehoking

215-440-3408