MARC Holdings Records RFC

MARC Holdings Records RFC

Status:	Several iterations done, feature-complete
Sponsored by:
Developed by:	Ere Maijala / The National Library of Finland
Expected for:	2019-02-21
Bug number:	Bug 20447
Work in progress repository:
Description:	Proposal to add optional support for MARC holdings records

Motivation

Much of what's listed in the old holdings RFC applies here too. The following is adapted to this RFC.

Libraries need a way to:

• Organize multiple items together so that it’s clear that items are related to each other.
• Summarize the holdings from a group of items together, including expressing the gaps where items are missing from a set
• Display holdings information when there are no items
• Retain the holdings information when converting data from an ILS that has holdings records

At the same time holdings records must remain optional, as not all libraries need them and there is always some overhead in managing them. Additionally, it would be difficult to convert existing databases from two-tier to three-tier automatically.

Holdings records add a lot of value for serial and multi-part records, but are not as critical for single-part monographic records. It’s important not to add overhead to the process for monographic cataloging.

While some of the functionality of separate holdings can be achieved by adding the holdings fields to a bibliographic record, it becomes complicated e.g. when there are multiple holdings and additional information related each one of them as there's no standard method of grouping the fields together. See "Separate and Embedded Holdings Information" at https://www.loc.gov/marc/holdings/hdintro.html for more information.

Proposed Changes

The proposal is to add a new optional tier using MARC holdings records (https://www.loc.gov/marc/holdings/). Database changes to existing tables would be minimal, and current workflows could remain unchanged.

Using the MARC holdings format is proposed because it's already used in ILS's and allows flexibility that would not be possible with a fixed set of fields. Much of the current behavior in Koha would be compatible and it would also be possible to create simplified templates for holdings if deemed necessary (similar to the handling of item records and how the item fields are mapped to MARC fields).

Database:

• Add holdings and holdings_metadata tables. These are a lot like biblio* tables. Table structure takes bug 20271 into account.
• Add a link field (holding_id) to the items table
• Add holdings framework as an authoritative framework for holdings records
• Add 'holdings' as an authorized value category
• Add preference for controlling holdings

Staff UI:

• Add a new setting that defines whether holdings are enabled. If not, nothing in the UI changes.
• In catalogue/detail.pl:
  • Rename current "Holdings" tab to "Items"
  • Add a new Holdings tab that lists holdings and allows one to edit/delete/add them
• Use the normal cataloguing UI for holdings records
• Display holdings in search results above items
• Add a new field to item editor for selecting the holdings record attached to the item
• Display holdings record attached to an item in item lists and details views

Staff UI further on pending other enhancements:

• Add support for using the Advanced Editor for holdings too. To work well this will require improvements to the framework and record type support of the Advanced Editor (to be handled separately, e.g. bug 16424).

OPAC:

• Display holdings in search results in availability
• Display holdings in the Holdings tab of record view

Other:

• Add a new default framework HLD that contains holdings fields.
• Import/export tools for holdings records
• REST API support
• Indexing enhancements?
• Obsoletes bug 2797
• Adding framework type to the biblio_framework table to distinguish between different uses (biblio, acquisitions, holdings) was considered, but it can be done separately if deemed necessary.
• When exposing records with OAI-PMH, allow embedding basic location information from holdings alongside item information

Status

Patches for a feature-complete implementation available in Bug 20447.

Comments

• Database changes: maybe better to use holding_id or similar to fit with the unified terminology we are implementing for the REST API.
  • Ere: Thanks, will to.
• Staff UI: Can you explain/rephrase the following a bit more? (Display a holdings record selection dropdown in item editor, Display selected holdings record in item list)
  • Ere: Done, hopefully it's more informative now.
• Other: Why is this needed? (Add a setting that allows one to select another framework as the default) I would add a framework type or similar to separate holdings frameworks from others. If we'd assume only one holdings framework was needed ever, we could also hardcode it. But I could imagine people wanting different frameworks for serials and monographs at some point.
  • Ere: Framework type is a good idea to avoid duplication of tables and code while keeping the frameworks separate. I'll add that.
• Will it be possible to use the Advanced Editor for editing too?
  • Ere: It should be, but the Advanced Editor is not currently wired to handle that properly. I have some enhancements in the pipeline, but I think it's better to address them separately.
• What will be the structure of holdings?
  • Ere: Proposed table structure added.
• New Koha-to-MARC-Mappings for holdings?
  • Ere: I don't see a need, but can be added if necessary.
  • Update: Ere: The framework now includes several mappings used in the OPAC display.

--Kfischer 10:29, 1 April 2018 (EDT)

--Emaijala 04:05, 3 April 2018 (EDT) Emaijala 11:19, 5 April 2018 (EDT)