[Archivesspace_small_archives_users_group] Metadata Standards Subteam ArchivesSpace Online Forum presentation - call for feedback

[Jessica Crouch]

[Posted on behalf of the Metadata Standards subteam of the Technical Advisory Council]



Dear ArchivesSpace community,


The Metadata Standards subgroup of the Technical Advisory Committee will be presenting<https://archivesspace.atlassian.net/wiki/spaces/AC/pages/3033006097/TAC-MD+AS+Online+Forum+2022> at the ArchivesSpace Online Forum<https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/3036282881/ArchivesSpace+Online+Forum+2022> on Tuesday, March 22 at 9am EST.


During our discussion we will talk about how we prioritize support for various standards<https://archivesspace.atlassian.net/wiki/spaces/AC/pages/3003252776/Draft+of+Tiers+of+Support> and share news about our ongoing work on the MARC importer and the current MARC import mappings<https://docs.google.com/spreadsheets/d/17zhNYoR2kYxfsm5bXBwoJN9YcRY_eSR3fIPKCUz4m0Q/edit#gid=1527709562>.


We are also looking for community feedback on a specific metadata question, below. Please consider providing feedback beforehand by email to kws2126 at columbia.edu<mailto:kws2126 at columbia.edu>. Sample MARC records would be welcome! You may also offer your thoughts during the session.


Issue: Improving the MARC 300 field<https://www.loc.gov/marc/bibliographic/bd300.html> import behavior


Do you have MARC records for your archival holdings? Then you probably have 300 fields. The MARC 300 “Physical Description” field contains extent information critical for archival control of material, like 34 linear feet, or 12 boxes (10 cubic feet).


The current AS MARC importer<https://github.com/archivesspace/archivesspace/blob/master/backend/app/converters/lib/marcxml_bib_base_map.rb#L868> only parses the 300 field according to one very specific pattern, and otherwise defaults to “1 linear feet.” This means that anyone doing bulk import of MARC records may be silently wiping out their archivist-supplied extents without realizing it. A recent ticket<https://archivesspace.atlassian.net/browse/ANW-1260> also noted that 300$f fields are ignored entirely.


What we would like from the community is how your 300 fields are structured, and how you would want 300 fields parsed on import. Sample data will help us make recommendations on what should be happening. For example, this is a common construction (from LC) that is NOT handled by the MARC importer:

300 ǂa 5 ǂf boxes ǂa (3 ǂf linear ft.)


A discussion based on that sample might be: Should this pattern be supported? How should this be parsed?  How should all of that punctuation be handled?


The Metadata Standards subgroup will take what it learns and develop a specification for the desired behavior, but we need to hear from you.


Best,

Jessica

Jessica Dowd Crouch
Community Engagement Coordinator for ArchivesSpace
jessica.crouch at lyrasis.org<mailto:jessica.crouch at lyrasis.org>





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_small_archives_users_group/attachments/20220223/cf6ca438/attachment.html>