Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Microsoft Teams meeting

...

Minutes

...

2021-2022 Metadata Sub-team Work Plan

Online Forum Page

https://archivesspace.atlassian.net/wiki/spaces/AC/pages/3033006097

...

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 https://archivesspace.atlassian.net/wiki/spaces/AC/pages/3033006097

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:

Jira Legacy
serverSystem JIRA
serverId36c489e2-4fb0-353a-985b-64038401be2f
keyANW-943

and:

In a prior meeting we reviewed

Jira Legacy
serverSystem JIRA
serverId36c489e2-4fb0-353a-985b-64038401be2f
keyANW-547
and we had the following comments. Another review of this ticket is a low priority (at this time) given the items above.

Expand
titleClick for notes from last discussion

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

Expand
titleClick for Draft

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

...