Context
FOLIO primarily has two ways to represent sets in back end APIs: enumerations and reference records (there are some exceptions, including unconstrained strings and hard coded sets).
Historically, it seems that properties used primarily as information for people (or for dynamic policies) e.g. instance status or material type, are represented as reference records and states or types that the system needs to interpret semantically as enumerations e.g. item status, order type, order workflow status.
Recently, there has been increasing interest in representing the latter as reference records as well. This document is intended to outline the considerations for such an approach.
Characteristics
| Defined by | Referred to by | Stability of values | Descriptive properties | |
|---|---|---|---|---|
| Enumerations | interface | name | Static/fixed | No |
| Reference Records | implementation | id | dynamic/can change | Yes |
Enumerations
- Are referred to by name
- Are defined by an interface
- Set is fixed for any given module version
- Clients cannot dynamically get the members of set
- Are only a name, cannot have additional properties
Reference Records
- Are referred to by name
- Are defined by the implementation
- Set may change independently of module version
- Clients can dynamically get the members of the set
- Can have additional properties beyond the name
Worked Example - Holdings Source
Behaviour
- Assigned by different processes
- If created during data import, the source should be MARC
- If created any other way, the source should be FOLIO
- Can filter instances by whether there it has holdings with that source
- Dictates whether instances can be edited
- Holdings with a MARC source cannot be edited directly
- Otherwise holdings can be edited directly
Comparison
Table describing how the behaviour is achieved, and questions / impacts of that
Worked Example - Item Status
There is an upcoming feature for the ability for item statuses to be configurable by tenant. This example won't delve much into the details beyond trying to
Impact of the characteristics
Question
Summary
Related work
The Technical Council and Sys Ops SIG have been discussing how reference records should work, e.g. should users be able to change them? and how upgrades should affect them e.g. should a change to the modules default definition of reference records overwrite changes made by a user?