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

Current Work Plan

2021-2022 Metadata Sub-team Work Plan

Online Forum Page

TAC-MD @ AS Online Forum 2022

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

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).
Call number-type information (subfields k h i m) is concatenated with underscores and imported into the AS identifier field.  We propose adding at least subfield j to the list above.  Is there anything else that should be done in terms of call numbers?

 

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

Check for new tickets.

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:

  • Minutes: We reviewed why we reversed this ticket; I had to leave the meeting before a final conclusion on whether to remove the detailed reporting of what fields were mapped

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

2021-2022 Metadata Sub-team Work Plan

 

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

@Valerie Addonizio Public facing document to Jessica by the 16th

Long term Action Items (by or at end of term)

@Elizabeth RokeContact Mark about the EAD4 questions and invite him to a future meeting
@Elizabeth Roke and @Valerie Addonizio Alert Christine to the updated version of the MARC importer mapping + inquire about how they might want the new tickets delivered (and good suggestion from Kevin to include the DACS mapping element in the ticket creation). Also inquire about keeping an older version of the mapping for posterity.
@Elizabeth Roke and @Valerie Addonizio Contact Christine about publishing the https://archivesspace.atlassian.net/wiki/spaces/AC/pages/3003252776
and our stance on being included upstream in decisions that effect external standards
@Valerie Addonizio Put RiC review in the notes in our retrospective. Essentially we know we absolutely must render a verdict on this, but we decline to do so on a draft. We have doubts about the stated aspirations (transmission standard, descriptive standard, one ring to rule them all). We want to be included in the decision of how ASpace reacts, and not just the recipients of said decision.
@Valerie Addonizio Put our statement about being included upstream in the notes in our retrospective