Microsoft Teams meeting
Click here to join the meeting
Participants
Minutes
...
Discussion Topics
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. View file |
---|
name | Online forum discussion chat_abridged.txt |
---|
|
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? |
| Tiers of Support | Next steps? |
| 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
|
| EAD Mapping reorganization | Opening the floor to Regine Heberlein to show us her continuing work and invite comments. |
| 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: Jira Legacy |
---|
server | System JIRA |
---|
serverId | 36c489e2-4fb0-353a-985b-64038401be2f |
---|
key | ANW-943 |
---|
|
and: In a prior meeting we reviewed Jira Legacy |
---|
server | System JIRA |
---|
serverId | 36c489e2-4fb0-353a-985b-64038401be2f |
---|
key | ANW-547 |
---|
| and we had the following comments. Another review of this ticket is a low priority (at this time) given the items above. Expand |
---|
title | Click for notes from last discussion |
---|
| 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: Expand |
---|
| 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)
...