Planning for Import of MARC Bibs to create/update multiple holdings and items

This feature does not have any development work; it is ALL planning

Planning and story-writing during Orchid so that work can be done in UXPROD-2741 Poppy

This feature allows for multiple holdings and/or items to be created or edited based on data supplied in a single MARC record

Purpose: To update multiple holdings and items on the same instance, from the same imported MARC record

Important for

• 5 Colleges Consortium
• Spokane Public
• Chicago
• MARMOT Consortium

As a staff person working with data import
I want to update multiple holdings and their associated items when importing a single MARC record
So that I can use all of the holdings/items data on the MARC record properly

Scenarios

1. Scenario 1
   • Given a MARC record with multiple holdings and item data in it
   • When importing to update holdings and items
   • Then update all relevant holdings on the same instance and update all relevant items on the appropriate holdings
   • Include any holdings and items data in the same MARC field, different subfields
   • If multiple item records are to be updated on the same holdings, repeat the holdings data in repeated MARC fields, with each item's data in a separate MARC field. Item data/subfields for multiple item records cannot be included in the same MARC field
   • See example MARC record below
2. Scenario 2
   • Ensure this story passes Accessibility testing
3. Scenario 3
   • Ensure automated testing coverage for this new code is 80% plus and confirm with screenshot

See attached MARC file; test load to update instance, holdings, and item to ensure the logic is working correctly.

Matching notes:

• Match for holdings could be based on
  • Holdings HRID/UUID
  • Instance HRID/UUID plus secondary match on Holdings HRID/UUID or Location code
• Match for item could be based on
  • Item HRID, UUID, or barcode
  • Holdings HRID/UUID plus secondary match on Item copy number

Sample record with multiple holdings/item data:

=LDR 01262nam a2200301Ia 4500
=001 ocm54341618\
=003 OCoLC
=005 20070103101904.0
=008 010330s1798\\\\enkaf\\\\\\\\\000\0\eng\d
=035
$a(Sirsi) a551407
=035
$a(Sirsi) o54341618
=049
$aDRUM
=040
$aCUD$beng$cCUD$dDRU$dMvI
=090
$aBS2095$b.S33 1798
=130 0\$aBible.$pNew Testament$lEnglish.$sScarlett.$f1798.
=245 12$aA translation of the New Testament from the original Greek /$chumbly attempted by Nathaniel Scarlett, assisted by men of piety & literature ; with notes.
=260
$aLondon :$bPrinted by T. Gillet; and sold by Nathaniel Scarlett, No. 349, near Exeter 'Change, Strand; also F. & C. Rivington, St. Paul's Church Yard,$c1798.
=300
$axi, 483, vi p., [1] folded leaf of plates :$bill. ;$c19 cm.
=500
$aEngraved t.p.
=500
$aIncludes Observations on some terms used in this translation: vi p. at end.
=510 3\$aDarlow-Moule-Herbert 1433
=700 1\$aScarlett, Nathaniel,$d1753-1802.
=740 02$aObservations on some terms used in this translation.
=945
$a34678234678246423786427$b1$hKU/CC/DI/M <===== $a = item barcode, $b = copy number, $h = holdings permanent location
=945
$a34678234678246423786428$b2$hKU/CC/DI/M
=945
$a34678234678246423786429$b1$hKU/CC/DI/A

If this record were updating holdings and items, it would do so as follows:

• Update 1 instance, with the data in the main part of the MARC bib record
• Update 2 holdings, 1 for permanent location KU/CC.DI/M and 1 for permanent location KU/CC/DI/A, using holdings mapping data from 945$h and the defaults in the holdings mapping profile
• Update 3 item records, 2 linked to the holdings for KU/CC/DI/M and 1 linked to the holdings for KU/CC/DI/A, using item mapping data from 945$a, 945$b, and the defaults in the item mapping profile

NOTE: These 9xx fields and subfields are just examples. Real fields/subfields would be mapped in the field mapping profile. The key is that related holdings and item data must be in the same field, different subfields, and that item data for different items must be in separate MARC fields, not concatenated in the same MARC field.

Steps:

• MappingManager should return JSON value - backend
• extend mapping profile schema with param "entityPerValue" (for items and holdings) backend/UI
• add a possibility to link item and holding in mapping profile for item (holding location: 945$h) backend/UI
• Change Mapper interface to read "entityPerValue" fields call reader for n times per entity - backend
• update all handlers for support list of holdings and items in the context