retrieve activated / deactivate package/title+package
- link license info (hotlink) ?
- associate package/title+package to an agreement (hotlink)
- display instances
- display holdings
- display items
- display containers (local packages UXPROD-1105, UIIN-155)
- Ebook packages - relationship to individual title records (UXPROD-151)
- Check for duplicative EBooks. Clustering of records. Prioritize the view of the record with the richest bibliographic record in the display (UXPROD-139)
-provide metadata updates for selected titles in KB
- hotlink to more detailed info in eHoldings app
- process needed to periodically refresh the record against the source (Knowledge base)
MARC Batch Loader (Import) app
-brief instance records
- brief container records
- display
- record management
process needed to periodically refresh the record against the source
General comments:
The idea is, that we do a diagram for each of the apps in the dataflow/interaction between ‘crossrmapps’. These diagrams will be similar modeled, as the diagram Khalilah started out with:
- eHoldings: https://docs.google.com/presentation/d/1MbcUHphAdV30WQg5ZLZK1Ohmu7cIkr8p_E74QmejJEw/edit#slide=id.p
And here my version for
- Inventory: https://docs.google.com/presentation/d/1_BD5AhPKLXwkMdIj0DtTfKanEnm1tyj3os20oQS9hgM/edit#slide=id.p
Later to be added:
- Acquisitions:
- ERM:
V1: Order app -> Inventory
Mandatory connection to Inventory from Acquisitions (email from Ann/Marie Breaux, 9/18/2018)::
Orders will be created in acquisitions in a couple ways. There may be an external feed (MARC file, API, call from ERM) that tells Acquisitions to create an order (and link to a vendor and fund). Or someone may create an order directly in Acquisitions. In either case, a record may already exist in Inventory or not. If a record already exists, the order will be linked to it. If a record does not already exist, a record will be created. The Inventory record will usually be an Instance, but sometimes a Container (Package). For Physical and eContent, a stub holdings will also be created. For Physical content, a stub item record (or more, depending on the quantity ordered) will also be created. Then when the material is received, the instance may be updated to a more-complete cataloging record, and the holdings/items may be updated with things like URL, barcode, call number, etc.
Every order will need to be represented by an Instance or Container in Inventory. For eContent, the library may choose to suppress the Inventory record from patron discovery and only surface the ERM/eHoldings info, but it will definitely be there. When we first started designing acquisitions, there was no ERM. The order needs to be tied to some sort of record. Since the eHoldings records that you see in Codex are transitory records, there was no way to link the order to an eHoldings record. So we settled on some sort of representation in Inventory. Also, many libraries (at least in the US) opt to load or create MARC records for their eContent, so that they have more complete cataloging info to display to patrons. If they do that, there will have to be an Instance in Inventory to surface the MARC record.
V1: eHoldings -> Inventory
Orders and ERM apps should call mod-kb for applicable package and/or title+package Orders and ERM should have the ability to activate a package and/or title+package in mod-kb All three apps should not have hard dependencies. IOW - assume customers may not use all three apps.
V1: eHoldings <-> Inventory
V1: ERM <-> Inventory (email from Ian Ibbotson, 9/12/2018):
For ERM users who want to do ERM-First selection (To borrow a term from the paper that owen has written) and activation via eHoldings we will use the eHoldings?
For ERM users who want to do Holdings first selection, they will also be using eHoldings, so can use that route?
That leaves ERM users who want to do ERM-First selection using an external KB (Using the term external in preference to commercial).
This will be the default use case for the initial German libraries - where they have an external(to FOLIO) discovery service and expect ERM to provide a feed of items. I think we have this well in hand, the only real gap being the enrichment of discovery records with rich catalog records. Your diagram makes it look like catalog records will be loaded into mod-inventory rather than what I thought was going to be a marc storage component - is that correct?
So - as is, I don't think this blocks us in any way, but I'm also not sure it offers us any services or affordances that will help us. I'm pretty confident it is possible to implement the endpoints mod inventory will describe.