Closed regineheberlein closed 1 year ago
Some initial thoughts that are no-gos:
The "Language of Description" field is only available on the Resource (=collection) level.
User-defined fields are not available on ao records.
Currently unused fields that already export, like the General Note field, are a possibility, but not a good one: they would require patterned data entry for the label (like "language note") by humans to distinguish it from other uses of the same note type, hence there is a large risk for data variance down the road.
Better options:
The best option is probably to use an unused field that doesn't currently export and include it in the Princeton exporter. That ensures that there are no usage collisions. Processors then only have to enter the language code, which cuts down on the risk for data variance.
One such field seems to be the "repository processing note", which is on the ao but not yet included in the EAD export. We could have the exporter grab it and map it to something like <c/@xml:lang>
.
We'd probably still want to validate the language codes though, since they wouldn't be entered from a controlled value list?
The alternative is to have a dedicated plug-in that makes a language field with a controlled value list available on the ao (and that we then map to the Princeton exporter).
If we want to go with the repository processing note: it's at the top level of the ao record, like here, where I've entered "it":
"lock_version"=>2,
"position"=>0,
"publish"=>true,
"ref_id"=>"C0920_c001",
"title"=>"From Francesco [Riccardi]",
"display_string"=>"From Francesco [Riccardi], 1595 April 20",
"restrictions_apply"=>false,
"repository_processing_note"=>"it",
"created_by"=>"admin",
"last_modified_by"=>"heberlei",
"create_time"=>"2021-01-24T02:16:49Z",
"system_mtime"=>"2023-03-31T13:40:49Z",
"user_mtime"=>"2023-03-31T13:40:49Z",
"suppressed"=>false,
"is_slug_auto"=>false,
"level"=>"file",
"jsonmodel_type"=>"archival_object",
[...]
I've submitted a ticket to Lyrasis so they can hopefully support this in a future version, FWIW: https://archivesspace.atlassian.net/jira/software/c/projects/ANW/issues/ANW-1720
There is also a related-sounding ticket here: https://archivesspace.atlassian.net/browse/ANW-957
ASpace tickets are prioritized, among other things, according to community need, so feel free to comment on either or both of these tickets to throw your support behind them and clarify some issues, working towards spec'ing out the work.
DSSG approved a proposal to start having bilingual finding aids for non-English collections. This means the collection-level description (resource) as well as the series-level description (ao) may be in a language different from lower-level description. Does ArchivesSpace allow specifying the language on the ao to support indexing of the different languages for different entities?