multiple $bs in items from marc_export can confuse external systems
Bug #2004587 reported by
Rogan Hamby
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned |
Bug Description
In this great age of discovery layers really caring about where an item lives the multiple subfield bs created in the holdings when marc is exported is confusing. One is currently for the call number owning library and one for the circ library of the item self. Non-discovery layers may care too but the discovery layers very much care.
This is up for discussion how to best handle it but the options appear to me to be
a) break the call number owning library into a different subfield. Potential issue is that this could be disruptive to some exports if both $bs are in use by someone.
b) provide an option to suppress the owning library
tags: | added: cat-importexport cataloging |
Changed in evergreen: | |
importance: | Low → Medium |
status: | New → Confirmed |
Changed in evergreen: | |
assignee: | nobody → Jason Stephenson (jstephenson) |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
One way to do it to preserve backwards compatibility would be to have marc_export (and Supercat) add the owning library and circulating library to new, additional subfields while still retaining the two 852 $b.
The tradeoff would be the result permitting fewer items to be embedded in the MARC record before running into the ISO 2709 limit.
Alternatively: add command-=line options to marc_export (easy) and library settings for Supercat output to tune this, though the more options we add, the more that going to the effort of creating item record MARC embedding templates would be desirable.