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:
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 ( )
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?
In a prior meeting we reviewed 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
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
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
