2022-06-23 Metadata meeting notes

2 mins

Intro

15 minutes

MARC importer documentation and progress

@Elizabeth Roke Next and final steps?

Minutes: @Elizabeth Roke proposed a compromise to the compromise: Pull all the non-core fields (2xx, 3xx, 754, 856) except the 5xx’s; for the 5xx’s, everything that is a core field gets mapped, but everything that is a 5xx just gets a mapping to a local note, like a 590. We know this a relatively big change, maybe put this in the roadmap, so that it doesn’t happen quietly . Elizabeth volunteers to write that spec, including the justification. You get a list of what was imported.

Outstanding MARC importer tickets:

(ERR)

(ERR)

(ERR)

(KS)

(ERR)

(KS)

**Suggest waiting to republish mappings until above tickets are resolved or rejected. The rest of the spreadsheet has been checked and is up-to-date. Rename versions in google docs as we go (File--version history--name current version with date).

MARC reporting functionality ticket:

(KS)

**Suggest announcing this functionality to user groups once implemented.

Have not written the spec to delete fields from the importer yet, but amended the text above. Is there a template for this? Can we socialize this idea with TAC and the user group at a future joint meeting?

Minutes:

• One idea that came up with providing a read-only link instead of a new version of the mappings; we agreed to do this now, and since the mapping has the ticket numbers in it that will help anyone looking at the mapping to understand that certain behaviors should change, and the ticket number is easily accessible for them to track

• Kevin added the great suggestion to name this version in Google Sheets, which was done in the meeting

• @Elizabeth Roke will reach out to Christine

• @Valerie Addonizio will make sure that we record our desire to bring up the retiring of MARC behaviors at the next joint UAC/TAC meeting, which will be in the fall

• If we get Kevin’s ticket, we should do an email announcement

10 minutes

Data Model idea

Please help us define this here:

Minutes from this discussion were incorporated in the document.

10 minutes

ANW-547

@Regine Heberlein

Re:   , folder for spec documents here:

Minutes:

• This was not discussed in-depth, only wanted to bring this work to the attention of those present

• However good feedback:

  • Consider renaming these “External Identifiers”

  • Consider a way to mark an identifier as primary; this may assist with exports, and remember that we’re not just talking EAD

  • Include accessions, which is Columbia’s use case for this

10 minutes

Updated EAD Mapping - This was not discussed today

I have asked @Jared Campbell to work with some sample EAD mappings between now and the end of term.

• Key here is to to prepare for the work of next term. Some thoughts:
  The makeup of this team is always a mix of those comfortable with Ruby (to a point) versus those who are not. Suggestion: keep tasks for the EAD importer split between those a traditional archivist will feel comfortable with (verdicts on whether something should be included, DACS mapping) versus people more comfortable in code (does this import?)

• What to focus on next might not be so much what to actually do in the spreadsheet as designing the next phase of work for a team with various comfort levels.

New/Ongoing ticket review

Check for new tickets. - None

and the idea of community participation.

Minutes:

• Enthusiasm on the community participation part, but, we haven’t touched the MARC Exporter yet, which means that we don’t yet have principles in place and we should talk about those before we discuss community participation.

• Once that work begins, we’ll take on the work of understanding the MARC exporter of Resource records, and then this ticket will be much easier to tackle

Review Work Plan Items

Retrospective

Recommendations:

1. Being included upstream

• Some of this feeling was generated after all the changes that came with 3.0, but we’ve moved forward on that concern forgetting that we were invited to participate and declined. So this is about aligning both our own expectations about our work and being included further upstream in changes.

• This is a good example of where things that the metadata group should weigh in on are buried in specification documents and tickets.  Note that the specification includes a request to amend the EAD and EAD3 exports

• Communicate it to Christine, the developers, but also TAC and Dev Pri.

• More about a heads up than an approval process; fundamental to needing to track changes to documentation. Even if it becomes the primary job of this group to actively document and track those changes. We need to be tagged any time anything touches an importer/exporter

2. It would help us if the name of the pull request had the ticket number; could you take us through this so that we know what's going on here?

Unresolved business from this term

• Bring up the retiring of MARC behaviors at the next joint UAC/TAC meeting, which will be in the fall

• If we get Kevin’s ticket, we should do an email announcement

RiC review

• 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.

5 min

Next steps/homework