2022-03-31 Metadata meeting notes

5 mins

Intro

Five minutes on the timer to read the agenda

AS Online Forum Recap and Feedback

The chat log from the forum is below; recording is here.

Open

I gave it a read and re-watched the video can report the following:

On compliance versus interchangeability

• Accounting for people who said both, roughly 10 votes for compliance/14 for interchangeability

• 2 mentions of ISAD(G) and 1 mention of RAD

• “You need compliance in order to exchange the data”

• “I think it will ever be impossible to formally state AS is compliant to any standard, rather that its data model is informed by a variety of archival and library description and it 'supports compliance and interchange' with a variety of standards.”

• Summary from Greg in the video: “Not all standards compliance encourages interoperability; might be the opposite”

On Elizabeth’s MARC topic

• Beyond mappings, there are some concepts wholly missing (Main Entry in MARC does not have a clear equivalent in DACS [Kate argues choosing the creator for a collection name is a Main Entry]) which make mapping difficult

• “59X would be one that may be problematic to leave out? We have a tricky catalog and end up using 59Xs a lot”

• “I can see adding an additional job/config setting that allows you to list the excluded fields to import. So all real mappings would import and everything not in the excluded list would map to a note.” Conversation went on to agree with this, but switch it to an include list instead.

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?

On Kevin’s MARC topic

• Examples given: 300 ## $a 6 $f linear feet $a (677 $f items) and 300 ## $a 5 $f linear feet $a (16 $f boxes)

• “We have used the Container Summary and sometimes the note Physical Description as 'fallback' fields for holding that data, rather than drop it during migration”

• Main Entry should probably be in our retrospective for next term

• Kevin’s idea is a good one: Imports that can’t parse extents should just fail

Minutes from Discussion:

• Container Summary and Physical Description are good fallbacks, but extent is still a required field in ASpace. This requirement is the kicker and why we ended up with 1 linear feet

• Due to this, and having received only two data data examples in our call for feedback, we revert to one of our original ideas, which is to propose that the job fail but with much better logging to explain why and explicitly state that only one pattern is supported.

MARC importer documentation and progress

Next steps?

• Tabled until we can meet with @Elizabeth Roke

Tiers of Support

Next steps?

• Minutes from Discussion:

• Feedback was along two lines, and so we see two paths forward:

  • Conflating descriptive standards with data interchange standards: Address in tiers if possible? Revisit for discussion.

  • US-centric: Ultimately we see a conflict between the aspirations that ArchivesSpace reflect international needs and the reality on the ground. Of approximately 100 attendees, only two self-identified as using standards that are not DACS/EAD. If we broadened our scope, we would come up against either/or, we will probably default to DACS. We suggest reaching out to Christine to see how this can be addressed at higher levels in the ArchivesSpace organization, and perhaps in the short-term as a more practical step, special recruitment for an ad hoc group on non-US-centric standards. Ultimately that group might merge with this one, but there is not enough bandwidth for both the existing and backlog of work for this team and the aspiration to reach an broader audience, especially if there are no representatives of that work currently serving on TAC.

Guest! Kate Bowers will be joining us at 12:30

Kevin suggested we add Kate Bowers to this meeting to discuss the following:

I’m writing because I just learned that AS is deprecating the dates area of a name in agent records.  I don’t remember hearing about this at all, but then, well, there’s a lot going on in the world and I could have missed a big discussion. I’d like to know more, but I’m not sure where to look.  Was there a lot of discussion? This decision implications chiefly for MARC bibliographic export and MARC authority import.

I do a lot of checking on new name records because we have a multi-repository instance of ArchivesSpace. I was noticing a user in another archives who was putting dates into “dates of existence” instead of “dates” portion of the name. I  wrote to the user about this. They said it was a conscious decision because “dates” is being deprecated in AS. Indeed, the “help” text in AS if you scroll over the label “dates” in form of name says this field is deprecated.

For my money, in person agent records:

MARC authority 100 $$c = “dates” in form of name

MARC authority 046 $$f and $$g = exist dates

In bib records, there will be no way of knowing, during MARC bibliographic export, whether or not the “dates of existence” should be exported in X00 $$d. You’ll end up with split headings in the MARC catalog unless you fix everything by hand.

• Kate joined us to express concern over this change

• Due to a misunderstanding of what version she was on (she said 3.0.2, I heard 3.2.0) the conversation was a good one, but in error. We expressed that we wish to be more proactively involved in such changes and confusion over why this went unnoticed.

• Then, realizing the mistake on version number, a cascade of understanding followed: we realized that change was mentioned on the listserv, and since it was part of the Agents work for 3.0, we were invited to participate in that a few years ago and declined due to commitments, so we would have known had we participated.

• @Valerie Addonizio Will reach out to Kate to explain the change and why we had no role in it and go from there

  • I will also nominate Kate for TAC

EAD Mapping reorganization

Opening the floor to @Regine Heberlein to show us her continuing work and invite comments.

• Regine has finished the work of integrating comments from the prior spreadsheet and invites us to view it here: AS_EAD mapping.xlsx

• Filtering on the first tab should be all we need to help us manage the information

• Propose that some time be spent on this in each meeting moving forward where we can identify what we’d like to focus on in the time between meetings

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?

New/Ongoing ticket review

Check for new tickets.

Revisiting:

ANW-943: Ability to export an Accession record as MARC recordAwaiting More Information

and:

In a prior meeting we reviewed ANW-547: As an archivist, I would like to associate multiple identifiers with resources/objects and export it in EADAwaiting More Information and we had the following comments. Another review of this ticket is a low priority (at this time) given the items above.

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

Review Work Plan Items

2021-2022 Metadata Sub-team Work Plan

5 min

Next steps/homework