2022-03-31 Metadata meeting notes

Time	Item	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. 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 (MARC 21 Format for Bibliographic Data: 852: Location (Network Development and MARC Standards Office, Library of Congress) ) 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: https://archivesspace.atlassian.net/browse/ANW-943 and: In a prior meeting we reviewed https://archivesspace.atlassian.net/browse/ANW-547 and we had the following comments. Another review of this ticket is a low priority (at this time) given the items above. 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 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

Action Items

@Kevin Schlottmann Three MARC tickets in this agenda, and happily a path forward on the MARC 300 field

@Valerie Addonizio Follow up with Kate

@Valerie Addonizio Think about descriptive versus interoperability in the Tiers.

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.

@Elizabeth Roke and @Valerie Addonizio Contact Christine about publishing the https://archivesspace.atlassian.net/wiki/spaces/AC/pages/3003252776

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