2020-03-12 Meeting Notes

Date and Time

Thursday 03/12/20, 3pm Eastern

Zoom URL

https://lyrasis.zoom.us/j/897871318

Participants

• @Kevin Schlottmann

• @Christine Di Bella

• @Daniel Michelson

• @Dallas Pillen

• @James Griffin (Unlicensed) (Note taker)

Goals

• Work Plan

Discussion topics

Proposed MARC 520 bug report

Title: MARC importer bug - 520 not importing correctly

The MARC importer is not handling the 520 field correctly. 
For 520 fields where indicator 1 is {blank, 1, 2}, the data is imported into a general note type instead of scope and content note type.
Note that for 520 fields where indicator 1 is {3, 8}, the importer works correctly, importing in an abstract note / dropping the note entirely, respectively. 
Test record:

https://github.com/ASpace-Metadata-Standards/marc-examples/commit/890da69104a01f304e2252409ee952eb968b4260#diff-2b46b1712695c90d46fdd5e673219766

Proposed Improvements

Add import capability for 583 (mapped to Processing Information note)

Add import capability for 555 (mapped to Other Finding aids; tricky though as this is used inconsistently). Alternately, ask Lyrasis to publish how they handle custom modifications for importing 555 and 856 fields to various AS fields.

MARC 65X review

*650, 656, 657 - small issues, should adjust documentation but no AS fix needed.

MARC agent review

*100/600/700 and 110/610/710 work reasonably close to the documentation. Main issue is note respecting the source indicators. Ticket?

*130 and 630 appear to work, 730 does not. 1) Ticket to allow 730; 2) Document this (X3X not mentioned at all)

*Feature request for all agents and subjects - import $0 into an authfile URI field? Is this already underway as part of the agents module work

MARC Other Fields review

*001 is ignored; feature request to map to identifier? Either way, document.

*008 works, but not entirely intuitive as to date behavior; should be documented.

*300 - if the importer can’t parse data (numeric in $a, a known extent type in $f), it defaults to “1 linear feet”.

Document what vocab this maps to.

Also, it’s kind of a mess. Consider reviewing in toto what’s going on, and how to improve it.

Notes

(Ice Breaker Responses)

Reviewing metadata tickets

• There were some tickets which might not need to be evaluated any long

• ANW-412: VRA core for exporting digital objects

  • This is a fairly old ticket, there was disagreement about whether or not this was even desirable

  • Linked issue was closed as complete/duplicate

  • We are primarily concerned with the published mappings for the tier 1 standard

  • Christine

    • This is from the early day of the program…this can be used for linking to more robust digital object metadata

    • Most aren’t using ArchivesSpace with VRA core to provide more robust metadata for digital objects

  • Important for ASpace to always be thinking of what should be supported for core

• ANW-475

  • Lydia noticed that there is a Dublin Core mapping already

  • Is this subteam going to evaluate this mapping?

    • Christine:

      • Project was ongoing during 2017, Dublin Core map is pretty close to the end

      • It is Dublin Core and not MARC

      • We can reach out to Adrian Pruitt - it might be worth investigating, as the mapping seems to be fairly far along

  • We should then keep this ticket upon, we are unlikely to get to it this year

  • We need to prioritize this as Tier 1

• ANW-1047

  • There are inconsistencies in MARC relator exports

    • Some export as translations, and some as values

    • Not certain which should be exported

    • Christine:

      • Difference is in something in the role field vs the relator field

  • We probably want to look a bit further to RDA in order to use the translation

    • $4 is the value

    • Some systems prefer the code to the translation

  • We need to undertake research for this

    • Kevin will research this with cataloging colleagues

    • Kevin will make the comment once he has done the research

• Review Agent Mappings

  • Agent Module being developed by Lyrasis

  • Test server deployed this week to test the agent module

  • EAC-CPF exporters/importers being developed

  • MARC authority features also being implemented

    • This group would be valuable in testing and providing feedback

  • Timeline of two months

    • Exporters/importers might require more time for implementation

      • If so, this would delay the release of the Module, all features should be released simultaneously

  • How will this impact the other work?

  • Prioritization

    • What can we realistically get done?

    • MARC bib. import needs to be finished

    • EAD still needs to be finished

    • We also need to adjust exports

      • Export review process might be deprioritized for the next phase of this subteam

  • James can take the lead on testing the agent module

    • Determine what it should be rather

    • No reason to compare the existing EAC-CPF map

      • James must evaluate the new EAC-CPF map

      • Need to review EAD3

  • How do we feel on deprioritizing export work?

    • Group consensus to leave this for the phase held for next year

• MARC Import Review Process

  • How do we want to publish the findings?

    • Offer the existing spreadsheet for download?

    • Is there some other way to publish this?

  • MARC 520 fields (scope content and abstract)

    • Indicators: put into general note types, and this is an error

    • This results in scope notes being placed into 500 fields upon (re)export

    • Kevin proposed to create a bug in JIRA

  • MARC 5XX

    • 583 processing note should be handled

      • This is pretty heavily used and has a clear analogue in ArchivesSpace

    • Ability to import 555 and 856 fields

      • URLs are stored to link out to other descriptions

      • Often these link out to finding aids, but currently they are not supported in core for imports

        • Columbia required customization for these fields

      • Should we take time in order to determine the best default behavior?

        • Perhaps we should request from Lyrasis their guidelines for how they typically support this with customizations

      • This very much depends upon the infrastructure

        • For Columbia, 555/856 URLs point towards the rendered HTML

        • Maybe we don’t change the import capabilities but instead document how it has been done for other institutions

      • 555 or 856 or both?

        • Kevin has seen them used interchangeably and simultaneously

        • How often are those fields the location of the EAD

          • Post to the listserv in order to see about putting this ticket in as a feature

  • MARC 65X

    • Documentation doesn’t outline what is happening

    • The documentation just needs to be updated, the behavior is very intuitive

  • MARC 6XX/7XX

    • Support for Agents

    • 130-630 appear to work

    • 730 does not

      • This is probably just an oversight, and this is not documented at all

    • MARC 1XX field is not correctly respecting the source field

      • This is worth a bug ticket

      • Otherwise, end up with dirty agent data

      • Might not require a ticket, if it this isn’t reflected in the new Agent Map, then this behavior will define the behavior for the new Module

    • Importing existing authority data using URIs

      • This feature should be supported

      • Kevin will route that to James

  • MARC 001

    • In most ILS platforms, the bib. ID is stored there

      • Columbia uses this as the identifier, but this might be institution-specific infrastructure

      • What does ASpace currently use for the identifier?

        • It’s being ignored right now as a 24-digit hash identifier is generated

          • 852 and 090 already already checked and used, perhaps we should check 001 as well

          • https://github.com/archivesspace/archivesspace/blob/master/backend/app/converters/lib/marcxml_base_map.rb#L731-L742

        • Is this documented in the mappings?

          • This needs to be added

  • MARC 008

    • Collection level dates are imported

    • Encoded dates are imported

      • Can see why this was imported

      • If there is a history of copying and pasting, and if there is a documentation question, this can be described in the spreadsheets

  • MARC 300

    • This is quite a complex field to parse

  • How do we want to roll this out?

    • Want to avoid updates breaking the importer

• Export Review Process

  • Export review has been deprioritized in favor of EAC-CPF and MARC authorities

• Additional Items

  • Daniel also made progress with the EAD import

  •