| Round II and Round III documents Round II + PO Response Worksheet Round IV - Post MVP | Harry Kaplanian Magda Zacharska | Exports for Discovery - include marc records with holdings and items in a format for Vufind and EDS - - needed for filters in discovery and indexing
- export item call #, item location, as part of the marc record
- call # browse, limit by location, location browse
- in Exports Subgroup - has use case for exporting marc bib record with holdings and items in 9xx field. Will not be delivered in Q1 2020. Marc bib records from Inventory will be done for Q1, not mapping for hol/items
- OAI-PMH gets data from Source Record Storage which only holds bib records so far. No OAI-PMH connection to Inventory.
- no way to attach discovery layer to FOLIO that includes holdings and item information currently
- Once holdings is in SRS, we'd be covered (items?). Or code is written to pull holdings and items from Inventory.
- If you create a record that's only in Inventory, would the record be included in the export from SRS?
- UUID used to check if record exists in SRS, if no SRS record, will generate bib record (lives in memory) for the export from Inventory. Performance concern
- Scheduling jobs - Q2
- will be able to export file, want to export records added since last export - get UUIDs through inventory search, save in separate file, UUIDs will be used to generate export file.
- Currently there's no plan for caching generated holdings and items records for data export/OAI-PMH
- Realistically need all three - bib/hol/items to be able to be exported
- OAI-PMH and record exports do similar tasks. Internally, they have the same dependency - being able to pull the record types to build the record with hol/items.
- Is there a priority between OAI-PMH and data export?
- Tom - need to be able to do exports to other entities than discovery layer
- Tod - data export provides broader benefit. Needs to be export profiles. Hope that OAI-PMH won't require a separate profile - use ones that are being created for data exports. Export profiles Q2.
- Harry - drastically more limited with OAI-PMH - no user interface. Focusing on data export - offers most flexibility.
Exports for Discovery - include "suppress" from discovery indicator for marc and inventory records (includes holdings and items) - Harry - suppress from discovery means record shouldn't be exported, should have an option to include or exclude suppressed records
- Tod - should be option that local site can toggle for any export (including OAI-PMH)
- Kelly - record needs to have that indicator included if it exists
- Ann-Marie -AFAIK, there's not a MARC field for suppressed. We have a non-MARC field where we're storing in SRS, but assuming that for export, it would need to be mapped into some sort of 9xx field.
In SRS, we'll be storing the suppressed flag for MARC holdings, but not for items - Tod -At Chicago, we certainly have cases where we mark items as staff-only (i.e. suppress from public view).
Ann-Marie - And the bib suppress flag is not yet being honored by OAI-PMH, but there's a story for that. Hi Tod - yes, I understand, but there's no MARC format for items. If you wanted to output it in MARC, you would need to output it (along with the item UUID, HRID, or barcode) in a MARC Bib or MARC Holdings 9xx field.
- This issue needs more discussion
Exports for Discovery - Include effective call number/effective location/effective item type - all from item record - Ann-Marie - Good example of effective call number would be most volumes are shelved in regular, but an accompanying atlas has an Oversize designation as a part of a call number. If it's effective call number, the business logic will use the location call number unless it is overridden at the item level with a different call number. The piece info (copy 1, volume 3, etc - would also be coming from the item record and hopefully being added to the base call number to create the item's specific call number). Charlotte is more up on these exact details.
Exports for Discovery - Include inventory records that are not in SRS - Magda - Will not save exported records to SRS
- Ann-Marie -If created on the fly for export, do we have a story for saving them as MARC bibs in Inventory? Maybe we need to add as post-MVP?
Exports for Discovery - Including Holdings information from 856 - URL and display text - Magda - Q2 - will be part of mapping profile in Q2
- There is a plan that holdings and items can be exported as separate files from bib records
Ann-Marie - If created on the fly for export, do we have a story for saving them as MARC bibs in Inventory? Maybe we need to add as post-MVP? For row 5, can we make it clear whether you're talking about 856 in a MARC Bib or a MARC Holdings? Change the matching?
Ability to find and edit single marc records and save to SRS - Harry - significant discussion on how this will get done
- can use Postman to run a query and save from the screen
- Looking for alternative workflow since
- will have UUID of the record with the record identifier - can get this data through Inventory Search or Postman Search - can feed UUID to export and get the record (in Q1). Could do whole thing with Postman now.
- Using Postman, you'll get JSON have to convert to MARC
- Kelly - need to be able to get the record back in as well.
Ability to match on predefined fields in marc record and replace with an imported record - Harry/Ann-Marie - matching is being worked-on for Q1
Academic libraries can really only go live during the summer break or winter break. Getting something in Q2 is not going to be early enough for those going live in the summer. Need to have alternative workflows in place until Q2 release can be put in production.
Confirmation that this Round II document is what these libraries need for go-live How did discovery work for Chalmers? - Theo developed a script for discovery. Script likely did not copy holdings and items, dealt more with ID conflicts between union catalog and local catalog. Does it make sense for FIG to take a look at requirements as they exist or as they develop? - yes - interested in mechanics of the on-the-fly record creation. Mappings will be discussed in upcoming Data Export - Thursday at 2;00 Eastern - URL in FIG Slack Channel.
We need to be carefull about 999 field - ok to use so long as it is not using indicator $ff
Round III - How do we distinguish Round III from MVP? Harry's high-level roadmap kind of assumed Round III would be MVP. - Duke and A&M haven't added to the Round III list yet.
- Is MVP still a useful construct? Is it time for new terminology?
- MVP was a target, suggests keeping it for a while.
- There are items on the Round III list that are not MVP (batch and global updates)
- MVP should still be Q4 2020
- Ann-Marie -are things like "format and print spine labels" on one of the rounds, or already handled?
- Call round 3 MVP; start Round IV list that is not MVP
- If we're going to continue to use MVP term, tack it to a specific round of implementers
- MVP was negotioation aiming at summer 2020 - which met reality and didn't happen. What did we eliminate that we really do need? If Q4 has all the MVP features - when would implement? Winter break 20-21? Summer 2021?
- Leaning toward leaving the date out of this - releases won't be put in production until later than they're released.
- Looking for lowest common denominators for go-live
Karen - concerned about breaking into Round III and Round IV already Ann Marie - Me too (about splitting round 3). Is there a way to have a subset of round 3 that would allow libraries to go live, and then a next round 4 batch for the next set of libraries? Or maybe it's hard to figure that now, and we figure it when we get closer to round 3
|