Page Comparison

...

LDR 01690cam a2200373 i 4500
001 1235903375
003 OCoLC
005 20210826141608.5
008 210127s2021\\\\ctu\\\\\\\\\\\000\p\eng\\
010 \\$a 2021003582
040 \\$aDLC$beng$erda$cDLC$dOCLCO$dBDX$dYDX$dOCLCF$dUKMGB$dYDX
020 \\$a9780819580436$qhardcover
020 \\$a0819580430$qhardcover
020 \\$a9780819580429$qtrade paperback
020 \\$a0819580422$qtrade paperback
020 \\$z9780819580443$qelectronic book
035 \\$a(OCoLC)1235903375
042 \\$apcc
050 00$aPS3602.R34288$bB58 2021
082 00$a811/.6$223
100 1\$aBrady, Andrea,$d1974-$eauthor.
245 14$aThe blue split compartments /$cAndrea Brady.
264 \1$aMiddletown, Connecticut :$bWesleyan University Press,$c[2021]
300 \\$a92 pages ;$c23 cm.
336 \\$atext$btxt$2rdacontent
337 \\$aunmediated$bn$2rdamedia
338 \\$avolume$bnc$2rdacarrier
490 1\$aWesleyan poetry
520 \\$a"Combining the history of drone warfare and the consequences of "everywhere war" with personal memory and reflections on the myths and mechanics of prosthetic violence, voyeurism, masculinity, and desire, these poems put their operator in the heads-up display to imagine what happens when targets look back"--$cProvided by publisher.
655 \7$aPoetry.$2fast$0(OCoLC)fst01423828
655 \7$aPoetry.$2lcgft
776 08$iOnline version:$aBrady, Andrea, 1974-$tThe blue split compartments$bFirst.$dMiddletown : Wesleyan University Press, 2021.$z9780819580443$w(DLC) 2021003583
830 \0$aWesleyan poetry.
980 \\$a40030682796$bPOE2$cGen$dJRL$eYBP$g509509$h994720$i210830$j14.36$lPaper$m15.95$q1

Links

...

Match profile updates for Inventory records
Match profile data elements for Inventory records (add POL/VRN, plus do some housekeeping on existing match data elements that are not used?)
See the ones in red - should we keep them?
Decision: Leave them for now and fix as they are tested, if they do not work as expected

What Backend stories are needed?

Analyze MARC-MARC matching for 0xx and 9xx fields (based on the MARC query work previously done)

...

Update UI matching screen to include options for POL and VRNs for each Inventory record type
Consider removing non-viable match data elements?

SME Questions:

Question

Status

Conclusion

Comments

Can we limit to 0xx and 9xx fields?

Status

subtle	true
colour	Green
title	resolved

Probably OK

Devs need to confirm if MARC-MARC matching capabilities can be expanded, e.g. 924$a to 924$a

Any different considerations if the match-from and/or match-to field is repeatable?

Status

subtle	true
colour	Green
title	resolved

so long as matches to single instance, holdings, or item, should be able to update

From: If copies ordered at the same time, but on separate POLs (for different acq units or locations)

To: Instance linked to multiple orders, Holdings linked to multiple orders

Is an item ever linked to multiple orders? A-M asking on Acq channel

Needs to try each of the froms (if multiples)

Needs to try each of the tos (if multiples)

Confirm appropriate test cases for E-to-E automated tests

Status

subtle	true
colour	Green
title	resolved

See use cases above

Test 1: POL, Instance source = FOLIO, update all record types

Test 2: POL, Instance source = MARC, update all record types

Test 3: VRN, Instance source = FOLIO, update all record types

Test 4: VRN, Instance source = MARC, update all record types

Do we need to break out vendor ref number types, like we do for Identifiers?

Status

subtle	true
colour	Green
title	resolved

For now, do not break out the different vendor ref number types; if use case arises in the future, consider breaking out, similar to how the Instance identifiers are broken out

Can we remove some unused match data elements?

Status

subtle	true
colour	Green
title	resolved

Leave for now; as users test more of the match elements in the future, correct or amend on a case-by-case basis, Besides, that enlarges the scope of this feature

Match on POLs with which statuses?

Status

colour	Yellow
title	in discussion

Per Christie, would want to be able to choose the POL status for successful matches

Per Raegan, this is not a scenario that comes up for them

Open = OK to match

Pending = DO NOT MATCH

Closed = Maybe sometimes

If multiple are matched (like the same VRN in Law and Main order, leading to the same Instance, but different holdings and items), stop if multiple matches. Or maybe use location as a submatch to get to the right holdings/item

A-M to talk with Devs on Friday - would it be more complexity to take status into account when matching?

Maybe have 4 matching options

POL with status = Open

POL with status = Open or Closed

VRN with status = Open

VRN with status = Open or Closed

What about multiple copies?

Status

colour	Yellow
title	in discussion

It may be that we can only do 1 instance/holdings/item update until the multiples feature is developed

Right now, can only create single instance, holdings, item from an incoming MARC Bib. What happens if you're trying to updating multiple holdings or items from the same MARC Bib (if you have multiple holdings/items HRIDs) (find the feature for updating multiples from the same MARC Bib)

Write a couple tests to see what happens when trying to update more than 1 item or holdings from the same MARC Bib

Jira Legacy

server	System Jira
serverId	01505d01-b853-3c2e-90f1-ee9b165564fc
key	UXPROD-2741

Basic workflow

Matching on POL (only accounts for single Instance/Holdings/Item for now)

Data Import job profile:
1. Match POL to Instance UUID
  1. Single match: Update Instance (and Create/Update SRS MARC Bib)
  2. No match or Multiple match: STOP
2. Match POL to Holdings UUID
  1. Single match: Update Holdings
  2. No match or Multiple match: STOP
3. Match POL to Item UUID
  1. Single match: Update Item
  2. No match or Multiple match: STOP
mod-inventory hits mod-orders endpoint to find a POL's related Inventory UUIDs (only for Open, or possibly Open/Closed, not Pending POLs)
If found, follow related Action and Field mapping profiles for SRS MARC Bib create/update and Inventory record updates
1. Questions for SMEs:
  1. would the workflow sometimes be finding the instance and then creating (instead of updating) the holdings and item?
  2. would the workflow sometimes be finding the instance and holdings and then creating (instead of updating) the item?

Matching on VRN (only accounts for single Instance/Holdings/Item for now)

Data Import job profile:
1. Match VRN to Instance UUID
  1. Single match: Update Instance (and Create/Update SRS MARC Bib)
  2. No match or Multiple match: STOP
2. Match VRN to Holdings UUID
  1. Single match: Update Holdings
  2. No match or Multiple match: STOP
3. Match VRN to Item UUID
  1. Single match: Update Item
  2. No match or Multiple match: STOP
mod-inventory queries mod-orders by VRN to find related POL (only for Open, or possibly Open/Closed, not Pending POLs)
1. If only 1 POL, keep going
2. If multiple POLs, STOP
mod-inventory hits mod-orders endpoint to find a POL's related Inventory UUIDs
If found, follow related Action and Field mapping profiles for SRS MARC Bib create/update and Inventory record updates

What Backend stories are needed?

Thunderjet:
- Create API endpoint that would allow lookup by POL for related Instances, Holdings, Items
- Already have a query for using VRNs to find POLs
Folijet:
- Create match queries and matching logic for POLs and VRNs
Prokopovych:
- No dev work required
Analyze MARC-MARC matching for 0xx and 9xx fields (based on the MARC query work previously done)
- May not be needed if can use MARC-Instance matching to create/update SRS MARC Bib

What UI stories are needed?

Folijet:
- Update UI matching screen to include options for POL and VRNs for each Inventory record type

Developer Questions:

Question

Status

Conclusion

Comments

What changes are needed to the UI matching screen?

Status

subtle	true
colour	Blue
title	Open

Any different considerations if the match-from and/or match-to field is repeatable?

Status

subtle	true
colour	Blue
title	Open

Where do we pull the POL and VRN from, and how are they linked to the appropriate instances, holdings, items

Status

subtle	true
colour	Blue
title	Open

If we only wanted to match on POLs or VRNs for orders that are Open (and maybe Closed), but NOT Pending, would that be an issues? (we already use similar logic for EDIFACT invoice matching between Invoice line and POL/VRN)

Status

subtle	true
colour	Blue
title	Open

POs with Ongoing status (in receipt or payment) are included with Open

Order status is at the PO level, but POL/VRN are at the POL level. May need to hit a composite endpoint to get the number and the status.

Per Siarhei H, can use cross-index query to also find the status of a POL

E-to-E automated tests; how many, and happy path only, or negative too?

Status

subtle	true
colour	Blue
title	Open

For the 4 happy path scenarios
Possible negative scenarios
- No match (instance, holdings, item)
- Multiple matches (holdings, item; any need for instance?)

...

Version	Old Version 10	New Version 11
Changes made by	Ann-Marie Breaux	Ann-Marie Breaux
Saved on	Oct 20, 2021	Oct 22, 2021

Versions Compared

Key

Links

What Backend stories are needed?

SME Questions:

Basic workflow

Matching on POL (only accounts for single Instance/Holdings/Item for now)

Matching on VRN (only accounts for single Instance/Holdings/Item for now)

What Backend stories are needed?

What UI stories are needed?

Developer Questions: