FOLIO Inventory: a working definition

MM SIG has drafted the following and requests feedback from the FOLIO community. Our aim is a better shared understanding of what the Inventory app is, what it isn’t, and how it interacts with other apps. This document (which can also be viewed here: (https://docs.google.com/document/d/16C83Yy61GVm9dYs7aRKj9Z0on-vEuBcfXiCjuo_jALo/edit) is a work in progress. Please help us make it better.

FOLIO Inventory comprises four record types: Instance, Holdings, Item, and Local Package [name pending].

What it is:
Inventory is the FOLIO app where bibliographic information from a variety sources can be presented in a uniform, abstracted form for management of the collection regardless of the format or content rules used to describe a resource.
Inventory is the place in FOLIO to manage Instance, Holdings & Item records.

Instance records may be derived from full bibliographic records (in MARC or other formats) and are intended to provide enough information for library staff to identify & select records in order to perform work on associated holdings and items. Instance records can also be in the native FOLIO format when full bibliographic description is not required.

Holdings records provide information needed, such as location, call number, and volumes owned, for staff to locate and manage library holdings. Holdings records may describe library holdings that are physical, electronic, or other formats. Holdings records are created and edited in Inventory.

An Item record provides the information needed to identify and track a single item or piece, such as barcode, availability, and material type. Item records are created and edited in Inventory.

Local Package records hold multiple Instance, Holdings, and/or Item records and serve as virtual containers.

What it is not:
Instance records are not full descriptive catalog records. Instance record editing is not the equivalent of full MARC (or other metadata format) editing; source record editing occurs outside of Inventory. FOLIO Inventory interface is intended for staff discovery, not user-facing discovery.

Related apps:
Records in Inventory interact with MARCcat, Circulation, Acquisitions, ERM, eHoldings, Codex Search, and Reporting.

Related documents:
Inventory and MARCcat - https://docs.google.com/document/d/1b_DVh1CGaUQmFu6kMp4R44WUKMpMQ8fP5RVhaEv4eFk/edit

This definition causes me some discomfort… Most notably “Inventory is THE place in FOLIO to manage instance, Holdings and Item records”. In ERM we certainly need to manage instance records. I understand that one of the reasons that Items ended up physically close in the architecture was the requirements for circulation. I think we have exactly the same issues in ERM, except that our relationship with instances needs to be against split coverage statements, provision on multiple platforms and relationships with licenses. There are techncal reasons the bounded context for ERM needs it’s instance records close by.

This description seems to turn inventory into a keystone component which is the hub of a FOLIO system. I wonder how it fares when evaluated against the architectural norms proposed for FOLIO - of small apps working together. In the UK FOLIO days we discussed CIDOC-CRM and Institutional Repositories. Given this model of Inventory, will the descriptive metadata and the location metadata need to be extended to encompass all those material types also? Does that not create a really brittle hub that is prone to breaking every time we want to add some new kind of manged material type?

This to me feels like the fundamental crunch point / elephant in the room with Inventory that we still have’t really grappled with. Is inventory really just a monolith sitting at the centre of FOLIO, or does it do 1 job well and we have separate apps (Unified by codex, perhaps) for different contexts.

I’d also suggest that whilst the Package proposal lists use cases, it currently doesn’t make the case for why those use cases need to be in inventory, only that they need to be somewhere. As someone who contributed pretty significantly to “Vinces codex model” I don’t think when we were describing the tipp/package construct from gokb I necessarily felt this was automatically an analogous to other bundling use cases.

I suspect that a reason for much of this confusion is the need to feed descriptive records into discovery and the fact that in the past we have done this by mashing records into our catalog. I don’t see that FOLIO has to be bound by that convention, and in ERM discussions we certainly discussed the idea that ERM would be the place to manage instance information for electronic items.

Since in the BIBFRAME world instances for electronic and physical would be separate anyway this surely should not be an issue.

A related issue for me then is where are the Works?

Hope you can find something useful in all that rambling!

Ian

My grasp of the basic folio concepts is still rather limited and the more I read the more questions pop up:

• Order App: Will it be possible to attach a purchase order and an invoice line directly to an object in ERM (agreement, subscription, single instance/TIPP)? Or do you need a holding/item from inventory to create a purchase order and an invoice line?
• One typical use case is to determine whether the library has access to a certain book or journal (no matter electronic or printed), e.g. when a patron requests the purchase of a book and the acquisition team has to find out whether the book is part of the 150.000 titles licenced in an EBSCO ebook subscription package. The EBSCO package is of course managed in the ERM app. Where do you look to locate the title?
  ** Inventory?
  ** Codex?
  ** ERM?
  ** Or is there a Federated search?
• To my understanding ERM will use only a very limited subset of bibliographic data (like in KBART) to manage holdings. For discovery by patrons these data will be too skimpy. Is there a concept to enrich the basic holding data from ERM by descriptive metadata when exporting (“publishing”) them for discovery? For non-ERM data the data flow diagram in Folio inventory: a working definition features an export app. Where do You get the corresponding bibliographic records for ERM-TIPPs? MARCCat app or Codex or inventory?

As far as I currently understand it:

Order App: Will it be possible to attach a purchase order and an invoice line directly to an object in ERM (agreement, subscription, single instance/TIPP)? Or do you need a holding/item from inventory to create a purchase order and an invoice line?

You will be able to attach a Purchase Order Line directly to an object (specifically an Agreement Line) in ERM.

Is there a concept to enrich the basic holding data from ERM by descriptive metadata when exporting (“publishing”) them for discovery?

This is still something for discussion in the ERM work - my current view is that there might be lots of different models for this. In some cases the descriptive metadata will be handled elsewhere, in other cases in might be in Folio. I don’t think we have fully got to the bottom of what this means for ERM and Inventory yet, and I think that we will have to get ERM functionality more fully specified and developed before we can be clear on how this will work for ERM

Where do you look to locate the title?
** Inventory?
** Codex?
** ERM?
** Or is there a Federated search?

I think there could be more than one answer here - it’s ok for multiple routes to work.
I don’t feel like I have all the answers here, although as I understand it Codex is a federated search - so certainly that seems like one option.

I agree with several of Ian’s points, particularly the question of whether inventory is seen as a the hub of FOLIO and whether things like packages need to live in inventory or just somewhere. For me, this ties back to the fundamental need to move away from the bibliographic record as the central point of management for FOLIO.

We need to manage hierarchical relationships, like the package/title (or tipp) construct, which is being represented in E-Holdings, and the agreement concept from ERM. Plus we need to manage things that are simply not bibliographic like memberships, platform fees, etc. Bib records are of course still a key part of what we need, but I think it’s reductionist to base the whole system around them – it will essentially recreate the problems of the old ILS.

Inventory absolutely makes sense as the main storage area for bibliographic information, as long as we acknowledge that bibliographic information is not all we need.

Thanks to everyone who has given us feedback so far. Speaking for myself (not the MM SIG), it is a constant excercise to decouple my thinking from the environment I work in, e.g., MARC bibliographic records within the constraints of a particular ILS. And it is so important not to fall into recreating existing systems that do not meet our needs.

Some of us from several SIGs have had productive discussions recently around Package records in Inventory and their relationship to Package records in other apps (ERM and eHoldings). If you’re interested in this, all of our documents and meeting minutes can be found here: https://wiki.folio.org/display/MM/Local+Package+Record+Subgroup