2022-04-28 Metadata meeting notes

Participants

  • @Elizabeth Roke

  • @Valerie Addonizio

  • @Kevin Schlottmann

  • @Jared Campbell

  • @Regine Heberlein

Minutes

  • @Valerie Addonizio

Current Work Plan

Previous Agendas

Discussion Topics

Time

Item

Notes

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:

  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:

Minutes: Each addressed in Action Items and this work is complete for now.

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?

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?

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.

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.

Minutes (polished):

In conversation about the origins and fate of the Tiers of Support we came to the conclusion that the Tiers may serve a purpose in recording our internal decisions making (i.e. what, based on the community as it stands, gets prioritized over something else), but decided that its role as a public-facing position document was limited. Instead, we discussed the bigger difficulty in all our work related to standards, and that is the lack of a an ASpace data model for us to compare other standards' models to. We positioned a hypothetical task – whether undertaken by this group, informed by this group, or working wholly separate from this group – of deriving and documenting the ArchivesSpace data model.

The rough minutes from the meeting were:

  • There are no content models associated with these, so can you really support them?

  • The Tiers of Support matters when we decide to support something but something else. Useful in terms of resource allocation.

  • What does support mean? Supporting a model just means what can we import.

  • We don’t need to international representation to be inclusive where it doesn’t conflict with the demonstrated needs of our US-based customers. We could say our first point of departure is always ISAD(G).

  • We make a suggestion on a taskforce to study these problems. Can our data model handle other content models? This isn’t a metadata thing, it’s a data modeling thing.

  • Data modeling perspective: what is a thing, what are its properties, reduces the noise, entity modeling where we can define and compare

  • Maybe a task force that can work on a graphic representation of the data model.

10 minutes

ANW-547

@Regine Heberlein

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? Support at both Resource and AO level

  3. This from me: Should this really be two string fields, or one controlled value list (id source/label) and one string field (id)? Agreed on a controlled value, but editable by the user.

  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? Yes seachrable

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.

Minutes:

Sounds good for the interface, and @Valerie Addonizio can do a mock-up of what ti would look like.

This sounds like three tickets: the interface, EAD exports, EAD imports. Less confident about how to do the export.

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

Minutes: We expect Jared’s notes in the next meeting.

 

New/Ongoing ticket review

Check for new tickets.

Revisiting:

 

Kevin’s drafted ticket

Done:

 

Review Work Plan Items

5 min

Next steps/homework

 

Action Items

@Kevin Schlottmann Extent:
@Kevin Schlottmann Importer reporting ticket
@Kevin Schlottmann 852 $j:
@Valerie Addonizio Mock up what would look like in the interface
@Elizabeth Roke Spec for final work on MARC importer, see minutes above

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