Holdings Source ID (situation as of late 2022) - MODINVSTOR-983

MM-SIG working group - decided established at meeting 10/29/2022:

Product OwnerIndex Data
Product OwnerAnn-Marie Breaux (Deactivated) EBSCO

Will later loop in developers to discuss and plan the next step for implementation of proposed rework, and possible breaking change.


The Holdings source Id property has been implemented to support edit of Holdings in MFHD format in quickMARC. The solution was not implement consistent with the Instance Source ID. 

The Bulk Edit WG has asked for the Holdings Source ID data property to be implemented as a required data property, not repeatable. This implementation would be consistent with the Instance Source ID.

Right now libraries who migrated before this data property was implemented has holdings source in all kind of variations

  • data element being empty (and displayed in the UI as MARC)
  • data element being labelled with the same label as the Instance source, e.g. uChicago has records with ILL

The libraries need to run a migration script to update their records. This solves all migrated records, but the down side is, it's a very time costly migrationsscript to run and it cause down time for the libraries. 


(to be reviewed by the working group)

When a holdings is present then a holdings source is required and non-repeatable

Holdings source = MARC only if there is an underlying SRS MARC

Define other Holdings source types in Settings > Inventory > Holdings > Holdings source 

Functional requirements

(to be reviewed by the working group)

Make the Holdings Source implementation of the data element match the Instance Source

Make the Instance Source configurable in Settings and it is implemented for Holdings source

Do not relate the instance source and holdings source in any way - that is addressed in UIIN-2229

If Holdings source = MARC

  1. Lock down the controlled Inventory Holdings fields from editing in Inventory, but allow editing for the uncontrolled fields
  2. Display the quickMARC-related Action options only if Holdings Source is = MARC
  3. Allow the MARC Holdings to be edited in quickMARC

If Holdings source = FOLIO

  1. Suppress the quickMARC-related Action options
  2. Allow editing of all Inventory Holdings fields - if the Holdings source is FOLIO.

If Holdings source = any other label defined in Settings > Inventory > Holdings > Holdings Source  

  1. Suppress the quickMARC-related Action options
  2. The German Libraries would want to use the label K10plus, and protect some data element in their holdings records.

MODINVSTOR-983 - Getting issue details... STATUS

Meeting Notes: 


Consistency can either be:

  • Holdings source being aligned with Instance source
  • Instance source being aligned with Holdings source.

Clear understanding on what is the use of Instance source and Holdings source.

How are these data properties used?

A clear scope of the use of these data elements. 

We will most likely suggest a solution there will be a breaking change. But this change will most likely help all future libraries implementation of FOLIO.

The documentation of these data properties in the API are not precise, and are not consistent.

Important for users to understand the behavior. E.g. for Instance source = FOLIO here you can edit all data elements. We must also think about use of other data formats in the future; e.g. BIBFRAME and Linked Data

  • Cornell has used Borrow direct as label for Instance source.
  • GBV use K10plus
  • Chicago use ILL (ILL is the creator of the record, so it has nothing to do of the edit of this record)


Ask MM-SIG to explain their use of Instance source, and Holdings source. 

At this point we should not propose new data properties: 

Define: Source

Description: Union Catalogue, SRS-MARC, SRS-BIBFRAME

Define Format source; e.g. FOLIO, MARC, BIBFRAME, K10plus 


Define: Data source; e.g. ILL, Borrow direct. Archive space, SuDoc (question) => Statistical codes, or another property


The current situation: One data property:

MARC - this record is edited in quickMARC

K10plus - this record is edited in CBS

FOLIO - this record is edited in Inventory

Settings > Inventory

  • implemented for Holdings Source.

These data are not editable in the Edit of the Holdings record, even that the data element in the UI has a drop down arrow indicated.

Usecase from Duke.: A change of a holdings created in Inventory as FOLIO Holdings source must be changed to MARC so the edits will be changed to require the quickMARC editor (MFHD) -

It would be great if a cataloger could edit the Holdings source manually. On direction only: FOLIO → MARC, and never from MARC → FOLIO

Holdings source:

  • defining the editor
  • the value should always be set by the System

When documenting how to add or create new sources ( the ramifications on doing so should also be documented (i.e.: this property also defines what editor can be used)

Outline the situation:

Document ways to create holdings - to uncover if we have identified all issues where we can risk creating holdings records with no holdings source data:

Link to migration script - 

List current filed bug reports:

UIIN-2229 - Getting issue details... STATUS

UIIN-2223 - Getting issue details... STATUS

UIIN-2230 - Getting issue details... STATUS

Fix issue in the FOLIO Order Import Tool - Jira ticket (Index Data)

List current filed related issues:

UIIN-1232 - Getting issue details... STATUS

Action items:
  • Improve the description of the Instance source, and Holdings source data properties in the API documentation in:
    • list here ... (Jenn?)
  • Ask MM-SIG to explain their use of Instance source, and Holdings source
  • Plan next meeting: 11/11/2022 at 3 pm EST / 9 pm CET

JavaScript console in Morning Glory (created by Zak Burke (?)
-- (core) @@@@@@ &@@@@@@@@ . @@@@@@@@@@ ,/ &@@@@@@@@@@* .( *@@@@@@@@@@@( @ (@@@@,/@@@@@@@@@( ,@ *@@@@@@@@@*%@@@@@@. @ @@@@@@@@@@@& @@@@@ .@ /@@@&#(%@@ @@@@@@@@@@@@@ @@@* &*,&%@* .@@/ %@@@@@@@@@@@@@ @@ @,*&@@@@@@ @@@@@@@@@@@@@ @@@@@@@@@@@@@@@ .,(@@@@@@@@@@@@@@@@@@@@@@ * @@@@@@@@@@@@@@@@@ ,@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@, %@@@. %@@@@@@@@@@@@@@@@@@@. @@ *@@@ @@@@@@@@@@@@@@&#@@@@ @@@@@@@@@, # @@@ #@@@ @@@@@@@ @@@@@@@.&@@@@@@@@@@@/ *@@ #@@@ .@@@@ &@@( &@@@@@@@@@ @@@@@@@@@@@@@@ / @@@ *@@@/ ,@@@@(&. .@@@@@@@@@@@#.@@@@@@@@@@@@@@ /@* @@@, &@@@& %& /@@@@@@@@@@@@@%@@@@@@@@@@@@@ (@@@& ,@@@. .@@@& @@@@@@@@@@@@@%@@@@@@@@@@@ @@@@@@, @@@# ,@@@@@@@@@@ #%%( /////// .//// /// //// .//// *//// //// .//// ////////// *//////// .//// .//// ///////// //// ////. //// .//// .//// //// //// //// .//// .//// .//// .//// *//// *//// //// ,//// .//// .//// .//// ///// *//// //// //// ,//// .//// .//// .//// ////. //// *////////// .//// .//// *///////// future of libraries is open bundle.index1fc09c933aa617193af7.js:2 -- (core) Starting Stripes ...