Versions Compared

Key

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

Participants

...

Time

Item

Notes

2 mins

Intro

Some text lifted directly from emails, below:

10 minutes

Ticket updates

Kevin Schlottmann

  1. Give our final conclusion on this ticket:

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

  2. Create a ticket for Mapping of 852 call number import

  3. And we still had an open agenda item for creating an AS importer log. However, here are my minutes on that topic, since I had to leave early in the middle of discussion:

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 (Draft is in Agenda, linked here):

·        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

Direct follow ups:

  • Is that the list of work items you were expecting? Did I miss anything?

  • Did the group reach a conclusion on the above, in red?

15 minutes

MARC importer documentation and progress

Elizabeth Roke Next and final steps?

The tickets for 300 and 852 actually tie this work up well. 264, 583, and 584. Totally feasible to finish the spreadsheet this term.

Minutes from Discussion:

  • The goal was to reduce the amount of code to be maintained, so the community feedback for an include list does not support that goal.

  • Afterthought: Maybe there is room for compromise where we do the include list, but also comment in the code and in the mappings that this support is essentially frozen and will not be improved or changed. That may allow for a middle ground?

  • Compromise to the compromise: Pull all the 2xx’s out that do not meet core guidelines, except the 5xx’s, and fir the 5xx’s, for everything 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.

Direct questions to address in the next meeting:

  1. What do you think of the include list idea? See the minutes linked above. What do you think of the compromise idea about freezing code? I am confident we could put notes directly in the code if we decided on that.

  2. Where are we on finishing the MARC importer, and specifically, what decisions do we need settled before we’re confident to call it done? What do you think you think we can accomplish this term versus next?

10 minutes

Tiers of Support

Valerie Addonizio Next and final steps?
I have re-drafted the Tiers of Support to address two sets of concerns, but I do not see a good path forward.

10 minutes

ANW-547

Regine Heberlein

Jira Legacy
serverSystem JIRA
serverId36c489e2-4fb0-353a-985b-64038401be2f
keyANW-547
You commented on having a need, which helps us frame our response. I am in favor of supporting this functionality, so I want to get started on the practical needs for the developers. That will consist of:

  1. A mock but valid EAD sample. What would you like this to look like in EAD? Feel free to mock up a few different scenarios at the Resource and Component level.

  2. Do you want to support this at both the Resource level and the component level? Only one? Hesitations or reservations?

  3. This from me: Should this really be two string fields, or one controlled value list (id source/label) and one string field (id)?

  4. Here are some questions already in the ticket that I am just repeating in one place: when does the component unique id take precedence, should they be searchable?

I’d like you to focus exclusively on resources/components and not on Agents. The original writer of the ticket was talking about resources/components and then it was a commenter that opened the discussion to Agents. I’d like to separate out the Agents question and focus back on just the resource and component level.

10 minutes

Updated EAD Mapping

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

Revisiting:

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

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

5 min

Next steps/homework

...