Spike:
| Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | MODDATAIMP-729 |
|---|
|
Features:
| Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | UXPROD-3729 |
|---|
|
| Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | UXPROD-2741 |
|---|
|
Summary
When libraries purchase multiple copies or volumes of a title, they often need to create or update multiple Inventory holdings and item records based on the import of a single MARC Bibliographic record. If the MARC Bib has been exported from FOLIO, then it likely has necessary matchpoints for identifying and updating the proper holdings and item records (e.g. HRIDs, UUIDs, barcode numbers). If the updates are received from an external source, the incoming records are not likely to include HRIDs or UUIDs, and the existing item records, which may have been created at point of order, may not include barcode numbers. For these records, the matching and updating may need to rely on secondary matchpoints such as location.
...
| Num | Status | Question | Answer | Notes |
|---|
| 1 | | Status |
|---|
| subtle | true |
|---|
| colour | Green |
|---|
| title | Closed |
|---|
|
| Is it OK to require that all data for a particular item or holdings has to be in the same MARC field, different subfields, and consistent for each holdings/item being created/updated? (see 945 field in below example) | Yes |
|
| 2 | | Status |
|---|
| subtle | true |
|---|
| colour | BlueGreen |
|---|
| title | in processClosed |
|---|
|
| Is it OK to require that data used to find an existing holdings/item, or to identify which holdings an item should be created on is in the same MARC field/different subfield as the create/update data? | Yes for the holdings/item. If first match is to an Instance-level HRID or POL and possibly submatch to Instance status, would that need to be in the same MARC field as the holdings/item data, or not necessary since Instance would be a completely separate match profile? |
|
| 3 | | Status |
|---|
| subtle | true |
|---|
| colour | Green |
|---|
| title | Closed |
|---|
|
| Is it OK to require that no other non-item/holdings data use that same MARC field? e.g. if 945 is being used for holdings/item data, don't include another 945 field with miscellaneous non-holdings/item notes or codes | Yes |
|
| 4 | | Status |
|---|
| subtle | true |
|---|
| colour | Green |
|---|
| title | closed |
|---|
|
| Call numbers: If create/update includes call numbers that will vary from one holdings/item to another, is it OK to require that data to be in the MARC field along with the other create/update data? (e.g. LC versus accession numbers, or LC versus storage numbers) | Yes |
|
| 5 | | Status |
|---|
| subtle | true |
|---|
| colour | Green |
|---|
| title | closed |
|---|
|
| Call numbers: If create/update includes call numbers that will NOT vary from one holdings/item to another, the existing field mapping (e.g. 050, or 050/090 cascade, or 092, etc) will work fine. | Yes |
|
| 6 | | Status |
|---|
| subtle | true |
|---|
| colour | BlueGreen |
|---|
| title | in processClosed |
|---|
|
| What should show in the import logs?
Summary versus details
First iteration: maybe just multiple and no links to individual holdings/items?
What happens with the hotlinks?For the individual holdings and items, include something to differentiate ones created/updated within the same instance (decided to use Permanent location for holdings, and HRID for items) | See brief discussion in DI Subgroup Notes. To be continued |
|
| 7 | | Status |
|---|
| subtle | true |
|---|
| colour | YellowGreen |
|---|
| title | OpenClosed |
|---|
|
| Confirm matchpoints for MARC records exported from FOLIO vs records sent by external sources; see above table | Others besides ones in above table: URLs (holdings. items), accession numbers (items) |
|
| 8 | | Status |
|---|
| |
|---|
| subtle | true |
|---|
| colour | YellowBlue |
|---|
| title | Openreview |
|---|
|
| If nothing differentiates 2 existing items on the same holdings, would there need to be an option to "update" all of the items with the incoming data, and then the system just updates all the items in the sequence that they are linked to the holdings record. If it can't update all (maybe data only provided for 2 of the 3 items linked to a holdings), would FOLIO need to display a warning? |
|
|
SAMPLE RECORD (not exported from FOLIO)
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
050 $aBS2095$b.S33 1798
090 $aBS2095$b.S33 1798a
092 $b200$bSCARL$b1798
130 0\ $aBible.$pNew Testament$lEnglish.$sScarlett.$f1798245 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$a34678234678246423786427$hKU/CC/DI/M <===== $a = item barcode, $b = copy number, $h = holdings permanent location
945 $a34678234678246423786428$b2$hKU$a346782346$b2$hKU/CC/DI/M
945 $a34678234678246423786429$b1$hKU/CC/DI/A
...
- 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
Holdings and Item Fields: Map from incoming MARC, default in Field mapping profile, or Both?
| Holdings field | Map from incoming MARC? | Default in field mapping profile? | Notes |
|---|
| 1 | Suppress from discovery |
|
|
|
| 2 | Former Holdings ID |
|
|
|
| 3 | Holdings type |
|
|
|
| 4 | Statistical code |
|
|
|
| 5 | Administrative note |
|
|
|
| 6 | Permanent location |
|
|
|
| 7 | Temporary location |
|
|
|
| 8 | Shelving title |
|
|
|
| 9 | Copy number |
|
|
|
| 10 | Call number type |
|
|
|
| 11 | Call number prefix |
|
|
|
| 12 | Call number |
|
|
|
| 13 | Call number suffix |
|
|
|
| 14 | Number of items |
|
|
|
| 15 | Holdings statement |
|
|
|
| 16 | Holdings statement public note |
|
|
|
| 17 | Holdings statement staff note |
|
|
|
| 18 | Holdings stm supplements |
|
|
|
| 19 | Holdings stm supplements public note |
|
|
|
| 20 | Holdings stm supplements staff note |
|
|
|
| 21 | Holdings stm indexes |
|
|
|
| 22 | Holdings stm indexes public note |
|
|
|
| 23 | Holdings stm indexes staff note |
|
|
|
| 24 | ILL policy |
|
|
|
| 25 | Digitization policy |
|
|
|
| 26 | Retention policy |
|
|
|
| 27 | Holdings note: type |
|
|
|
| 28 | Holdings note: text |
|
|
|
| 29 | Holdings note: staff only checkbox |
|
|
|
| 30 | E-access: relationship |
|
|
|
| 31 | E-access: URI |
|
|
|
| 32 | E-access: link text |
|
|
|
| 33 | E-access: materials specified |
|
|
|
| 34 | E-access: URL public note |
|
|
|
| 35 | Acquisition method |
|
|
|
| 36 | Order format |
|
|
|
| 37 | Receipt status |
|
|
|
| 38 | Receiving history: public display checkbox |
|
|
|
| 39 | Receiving history: enumeration |
|
|
|
| 40 | Receiving history: chronology |
|
|
|
| Item field | Map from incoming MARC? | Default in field mapping profile? | Notes |
|---|
| 1 | Suppress from discovery |
|
|
|
| 2 | Barcode |
|
|
|
| 3 | Accession number |
|
|
|
| 4 | Item identifier |
|
|
|
| 5 | Former identifier |
|
|
|
| 6 | Statistical code |
|
|
|
| 7 | Administrative note |
|
|
|
| 8 | Material type |
|
|
|
| 9 | Copy number |
|
|
|
| 10 | Call number type |
|
|
|
| 11 | Call number prefix |
|
|
|
| 12 | Call number |
|
|
|
| 13 | Call number suffix |
|
|
|
| 14 | Number of pieces |
|
|
|
| 15 | Description of pieces |
|
|
|
| 16 | Enumeration |
|
|
|
| 17 | Chronology |
|
|
|
| 18 | Volume |
|
|
|
| 19 | Year, caption |
|
|
|
| 20 | Number of missing pieces |
|
|
|
| 21 | Missing pieces |
|
|
|
| 22 | Missing pieces date |
|
|
|
| 23 | Item damaged status |
|
|
|
| 24 | Item damaged date |
|
|
|
| 25 | Note type |
|
|
|
| 26 | Note text |
|
|
|
| 27 | Note staff only checkbox |
|
|
|
| 28 | Permanent loan type |
|
|
|
| 29 | Temporary loan type |
|
|
|
| 30 | Status |
|
|
|
| 31 | CICO note type |
|
|
|
| 32 | CICO note text |
|
|
|
| 33 | CICO note staff only checkbox |
|
|
|
| 34 | Item permanent location |
|
|
|
| 35 | Item temporary location |
|
|
|
| 36 | E-access: relationship |
|
|
|
| 37 | E-access: URI |
|
|
|
| 38 | E-access: link text |
|
|
|
| 39 | E-access: materials specified |
|
|
|
| 40 | E-access: URL public note |
|
|
|
| 41 | Bound with holdings HRID |
|
|
|