Just to be clear - #5 in the original post is slightly misstated. If a library chooses to start an order without creating a bib in inventory, then our current planning involves the FOLIO order app automatically passing basic info to the inventory app to create a brief instance/holdings record, and possibly an item record. No one will manually have to enter an inventory record to begin an order. The library may then choose to upgrade that inventory record to a more complete record or ignore it when the electronic material is activated/paid and/or the physical material is received/paid. If the library is starting with an existing inventory instance record, or an instance record imported from an external source (e…g. vendor records, OCLC, national databases, etc), then the resulting order will be linked to that inventory record.
After MM SIG last week, I checked with a number of people involved in orders, codex, and inventory, as well as the overall FOLIO architecture, to make sure that my understanding of the structure was accurate. My understanding is as follows:
- The only place I can see all the things that my library has (owns, has access to, or are on order) is the codex.
- The codex gathers search results from external KBs and local inventories. At the moment, there are no plans (that I’m aware of) to have the codex consume search results from any other FOLIO apps besides the local inventories.
- Local inventory = instance records, and eventually may include other types of thing records, such as package records or perhaps resource records like Virginia mentions. Attached to those instance records may be holdings records and item records.
- Item records are required to circulate physical things in FOLIO.
- Item records cannot link directly to instances. They connect to holdings records, which in turn connect to instance records.
- Right now, the instance records in the inventory are 1) created by loading MARC records, which are then converted to the FOLIO instance format, or 2) created manually. After MARC, the inventory will support other metadata formats, e.g. Dublin Core, EAD, BIBFRAME, etc - all of which will be converted into the consistent inventory format, and then consumable by the codex.
If there is intent to have local inventories stored in some other format or structure than what has been developed so far, that needs to be sorted ASAP, since it is foundational to so many aspects of FOLIO.
Likewise, if there is intent to have the codex consume metadata from any FOLIO app other than the inventory, then that needs to be sorted ASAP as well.
And I guess my one big outstanding question is this - if the system is automatically creating a brief inventory record for ordered materials, but those materials may eventually be cataloged in a different way, I’m not quite understanding why that is a problem. The inventory record provides an opportunity for the order to be discovered in the codex, and keeps the library from having to search multiple FOLIO apps to discern whether they have something. That inventory record can be suppressed from end user discovery, so it won’t confuse patrons. Orders can be retrieved in the orders app via PO number/other control numbers or vendor if the title of the inventory record is not helpful. If staff need to retrieve the inventory record, but the existing title of that brief auto-generated record is not helpful, then alternate titles can be added to the inventory record.
And to be clear, I’m not 100% invested in any of this being any particular structure. What I am 100% invested in is that if we intend any other sort of structure - whether that comes from the ERM work or from the SIGs or from the PC - then that has to be figured out right now, given how fundamental this is to the overall structure of FOLIO, how many apps are potentially affected, and how much development work needs to be completed in the next few months.