2022-03-09 Metadata meeting notes
Microsoft Teams meeting
Click here to join the meeting
Participants
@Elizabeth Roke
@Valerie Addonizio
@Kevin Schlottmann
@Jared Campbell
@Regine Heberlein - regrets
Minutes
@Valerie Addonizio
Quick links
Google drive space: https://drive.google.com/drive/u/1/folders/1RQftm8w4XkNISQHVbtjr6sNY4_iyyXMV
Test records: ArchivesSpace Metadata Standards Sub-Team
Published import/export AS standard: Migration Tools and Data Mapping - ArchivesSpace
The MARC importer: Spreadsheet | Code
EAD 2002 importer: Spreadsheet | Code
Holding pen for ideas: 2022 Online Forum Ideas and Questions
Current Work Plan
2021-2022 Metadata Sub-team Work Plan
Online Forum Page
Previous Agendas
2021-08-19 Metadata meeting notes
2021-09-16 Metadata meeting notes
2021-10-20 Metadata meeting notes
2021-11-11 Metadata meeting notes
2021-12-09 Metadata meeting notes
2022-01-27 and 2022-02-03 Metadata meeting notes
Discussion Topics
Time | Item | Notes |
---|---|---|
5 mins | Intro |
|
| AS Online Forum: March 21-22, 2022 | Updates on preparations for the online forum is our main agenda item! Please add public-facing presentation notes to TAC-MD @ AS Online Forum 2022 @Kevin Schlottmann Examples of extents that will parse well versus extents that will not? @Elizabeth Roke The date on the read-only view of the mapping says June 15, 2021
|
| EAC as Tier 1 | @Valerie Addonizio Raising the issue of EAC one last time for https://archivesspace.atlassian.net/l/c/17RXGJP7 and once this is decided, it’s going public. Here? @Elizabeth Roke Feedback on this statement paragraph stating what we hope our role to be moving forward: that TAC-MD should be consulted in any change that includes an external standard: “Metadata Standards expects to contribute in a proactive role concerning the implementation or support of external standards in ArchivesSpace, meaning that the subteam should be tagged on any tickets and included in any discussion or final decisions about whether, how, and to what degree to support an external standard in ArchivesSpace, including changing the mapping for either importing or exporting those standards.” |
| MARC importer documentation and progress | @Elizabeth Roke Progress and updates? @Valerie Addonizio FYI I made some updates to the mapping re: 090, 099, and 852 based on the Workplan; I made those changes before Elizabeth created the read-only copy, so that should be good |
| Draft a ticket for this? (bumped from online forum discussion) | @Kevin Schlottmann Issue 2: Mapping of 852 call number import (https://www.loc.gov/marc/bibliographic/bd852.html ) Note that repository information is not considered, as it is, appropriately, set at the AS Repository Level (organization, address). |
| Updates from last time | There are new matches in your subscription to changes in archivesspace/archivesspace to files that match backend/app/converters/lib/marcxml_bib_base_map.rb! Here's what changed:
|
| New/Ongoing ticket review | Revisiting: https://archivesspace.atlassian.net/browse/ANW-943 and: In a prior meeting we reviewed https://archivesspace.atlassian.net/browse/ANW-547 and we had the following comments. Another review of this ticket is a low priority (at this time) given the items above. This was particularly difficult. There is a lot in here, would be better broken up into multiple user stories. Reading this as the ability to emulate the repeatable unitid with a type attribute in EAD. Better argument at the archival object level because there are some ways to work around this in Resources with the use of plugins. Different use case of managing agents because there are different authority records, but ArchivesSpace should be the database of record. Hesitance about prioritizing giving intellectual records multiple identifiers. No solid conclusion today, will continue to revisit. |
| Kevin’s drafted ticket | Kevin sent us a draft of a ticket requesting that the AS importer code confirm the elements that were handled by an ingest process, allowing users an assessment of what was not handled. Here is his draft, below:
As a user, I would like all importers to generate a report of every element from a source record that is handled. I would like this functionality for all imported record types (MARC, EAD, EAC-CPF, csv). For example, if I'm importing a MARCXML record with a 245 field, subfield a, I would like an indication that the field was handled by the importer. If possible, noting *where* it was imported would be desirable as well. For example, 245$a -> Title. This idea came up in the Metadata Standards subgroup as we were reflecting on all the data that the importers silently skip. Metadata Standards plans to propose that the importers handle fewer elements (so it is easier to document and maintain), meaning the importance of this functionality will increase. We would also like whatever report is generated to encourage the user to check the report against the source record, to identify any skipped fields. If this is something that could be addressed, Metadata Standards would be happy to provide more specific examples and input. |
| Review Work Plan Items | |
| EAD Mapping reorganization | Purely optional: Opening the floor to @Regine Heberlein to show us her continuing work and invite comments. |
5 min | Next steps/homework |
|
Action Items
Long term Action Items (by or at end of term)