add field for rights information on use of the resource recs/finding aids themselves
I propose adding a field, perhaps titled Finding Aid Rights, into the Finding Aid Data section of Resource records in ArchivesSpace to accommodate rights information about allowable uses of the Resource records/finding aids themselves. This field could be used to declare that the description is shared under an actionable CC0 license. As noted in an SAA panel at last year’s conference, opening finding aids is beneficial to researchers in the digital humanities and is in line with the profession’s core value to promote open culture.
Michael Rush in the Society of American Archivists Technical Subcommittee on Encoded Archival Standards has proposed adding an element for this purpose into EAD3 within the new EAD3 <control> section, so this new ArchivesSpace field should eventually map to that EAD3 element in the AS EAD import and export. I plan to work on submitting a change request to DACS requesting that standard also provide guidance on such an element. Maureen Callahan will most likely work on this effort too.
At the April 6, 2021 meeting of Dev/Pri, we agreed that further detail was needed and I’ve volunteered to get it together in time for our next meeting. I’m therefore changing the status to Awaiting More Information.
I like the idea of modeling this off the convention declaration subrecord (the structure of the two EAC-CPF elements is identical) and I think we really need a new subrecord that can be consistent across all publishable data (resources, agents, subjects, digital objects, and accessions). We could then have a customizable controlled value that is pre-populated with common rights statements.
Basically, take the convention declaration subrecord as a base, rename it something like “metadata rights declaration” and change the name of the first field to something like “rights statement.”
Logic for the EAC-CPF export would be identical to the convention declaration, while the EAD export could target <publicationstmt> if only the descriptive note field is filled in, otherwise it would go to <rightsdeclaration>.
, you are right that it was not included in the specification--as I remember the element was not added until 2018 and post-dates the document. I agree that it would be good to have it added in both standards, if possible.
As you mentioned, in EAD3 there is an option for an unstructured note in the <publicationstmt> element, though I am not sure what the equivalent would be in EAC-CPF. I would still suggest reusing or otherwise modeling the element on the convention declaration subrecord, though I don’t know if it would be possible to allow configuration/population of the drop-down menu with common rights statements.
Thanks for pointing that out Cory. The EAD mapping isn’t as straightforward as I’d assumed. I see that <rightsdeclaration> is only to be used for rights information that is machine actionable and mapped to an external source, otherwise <publicationstmt> should be used.
Also, I haven’t really looked at the new agents module in detail, but it doesn’t look like it includes the <rightsdeclaration> element from EAC-CPF (https://eac.staatsbibliothek-berlin.de/schema/taglibrary/cpfTagLibrary2019_EN.html#elem-rightsDeclaration), which is also required under the upcoming release of DACS 2021. Am I just missing it?
Dev/Pri is meeting today and will discuss this ticket, but I’m starting to think it might be best to create a new ticket to cover adding both elements.
Based on the structure of the EAD3 1.1.1 <rightsdeclaration> element (https://www.loc.gov/ead/EAD3taglib/EAD3.html#elem-rightsdeclaration), should the ArchivesSpace element also include fields for abbreviation and an actionable link? The convention declaration subrecord in the ASpace 3.0 Agents module seems to have a similar structure.
The minor priority was always planned to be updated once the new element was approved. I will add it to the agenda of the April 6 meeting of Dev/Pri.