Skip to main content
OCLC Support

MARC 21 Format for Holdings Data (MFHD)

The MARC 21 Format for Holdings Data (MFHD) was originally developed by the SOLINET consortium in the Southeastern U.S. so libraries in the consortium could report their holdings data to a centralized database. It became an official MARC format in 1986.

It is one of five official MARC 21 formats (the other four are Bibliographic, Authority, Classification, and Community Information). As such, it has many of the familiar features and functions that all MARC 21 formats share. These include:

  • The four record components. The Leader, Directory, Variable Control Fields, and Variable Data Fields.
  • A combination of codes and free-text data. The codes are typically fixed-length and are used for computer search & retrieval. The free-text data is typically variable length and is used for staff & patron displays.
  • The variable data fields are composed of tags, indicators, and subfields.
  • Tag blocks precisely define the content of the data within the field.

Many of the codes and fields within a MFHD record are identical to the codes used by the other MARC 21 formats. The definition and content of the 020 tag (the ISBN) in the MFHD is identical to the 020 tag in the related MARC 21 Bibliographic record, for example.

MARC 21 Holdings are also a set of unique features that set it apart from other MARC 21 formats. These include:

  • Publication Patterns
  • Compression and expansion
  • Paired tags
  • Coded and textual holdings

Publication patterns

Serial issues that are published on a regular basis can easily be predicted by humans. The publication patterns in the MFHD are a series of codes that allow the computer to replicate this human ability to predict the next issue of publication for checkin purposes. The patterns can be used, as well, to predict other aspects of the serial's lifecycle: when an issue needs to be claimed with the publisher or vendor, when a volume is ready to be bound, or how it should display in the OPAC.

The MFHD can also accommodate changes in patterns in publication. When the publisher changes the publication cycle for the serial, the library staff close out the first pattern in the MFHD and then create a new pattern.

As an example, a serial that is published quarterly in the months of January, April, July, and October, where the issue numbers increment indefinitely, and the month is not printed on the issue, would have as its pattern:

          853 $u 4 $v c $w q $x01

If the last issue checked in is volume 4 number 16, 2007 (published in October), the system would combine this information with the pattern in the 853 and predict that the next issue to be checked in will be volume 5 number 17, 2008 (published in January).

Compression and expansion

Compression of holdings means that, if a pattern is present, the computer uses an algorithm to compress all the single issues recorded individually in the MFHD (i.e., an ANSI/NISO Level 4 statement) into a brief, single holdings statement (i.e., an ANSI/NISO Level 3 statement). As an example:

          v.1:no.1           becomes           v.1-v.4

Expansion is the exact opposite of compression. That is, a single holdings statement (ANSI/NISO level 3) is "blown up" to include all levels of the serials hierarchy (ANSI/NISO level 4), listed in an itemized fashion. Thus:

          v.1-v.4             becomes          v.1:no.1

This manipulation can be used in a variety of scenarios. A detailed holdings statement becomes compressed for OPAC displays or for exporting the MFHD to a different system, for example. It is also good for reporting output. At its most sophisticated, compression and expansion also takes into account gaps in the library's holdings or the publisher's history of publication.

Paired tags

Within the variable fields, the set of fields that are used to record enumeration and chronology work in pairs. The 853 tag, for example, is paired with the 863 tag. Although the data is stored in separate but paired fields, it is combined in OPAC displays. To carry the previous example to its logical conclusion, the paired tags and their data:

          853 $a v. $b no.           would display in the OPAC as:           v.1:no.1
          863 $a 1 $b 1

Coded and textual holdings

The holdings data can be recorded in either coded or free-text form. The individual MFHD record can either be all coded, all free-text, or a combination of the two in order to enable the library to record its full range of holdings for a title. Both categories of holdings readily display in an OPAC.

Typically, the coded holdings are used for all current activities (checkin, claiming, binding, etc.) and the textual holdings are used retrospectively to record bound volumes already on the shelf. Textual holdings are also commonly used when a library reports its holdings to a union list.

Serial holdings can also be recorded for three different categories: the volumes & issues (technically called the basic bibliographic unit), supplements, and indexes. This allows the library to fully, accurately, and completely record the full range of its serial holdings.

The paired tags, combined with the fields used for coded and textual holdings, result in the following matrix of MFHD tags expressing the full set of relationships:

Field Basic Bibliographic Unit Supplementary Material Indexes
Caption & Pattern 853 854 855
Enumeration & Chronology 863 864 865
Textual Holdings 866 867 868
Item Information 876 877 878


Separate vs. embedded holdings

The MARC 21 formats give libraries two options to record their holdings data:

  • A separate holdings record linked to the bibliographic record
  • Embed the holdings data in the bibliographic record

Typically, if the library has chosen to embed its holdings data, the data consists of only the data elements needed to locate the item within the library (the locations data Data Area). The holdings record, in this case, may not be Z39.71 compliant.

If the library has chosen to record its holdings separately, and link to the bibliographic record, then it can record more data elements, more holdings locations, and the fact that they hold multiple copies of the item. The holdings record, in this case, is Z39.71 compliant. The "separate but linked" approach also allows the library to implement the multiple options allowed by the Z39.71 standard when dealing with multiple formats.

MFHD and Z39.71

When the two holdings standards for display and communication are combined, a complete electronic holdings record results. Taking the Level 4 holdings record listed in Table 1, and combining it with MFHD, the resulting holdings record would look approximately like:

          005      20020221
          008           5        8       1
          022      0040-781x
          852      $a T@W
          853 10$a v. $b no. $i (year) $j (month) $k (day)
          863 41$a 1 $b 1 $i 1923 $j 01 $k 24
          ...         (other 863 repeats)
          863 41$a 56 $b 52 $i 1979 $j 12 $k 29

Only the Z39.71 data elements have been included in this record example for the purposes of clarity.

The MARC 21 Holdings record does not itself contain the Z39.71 punctuation. However, the indicator values in the 853 and 863 tags indicate the holdings record is Z39.71 compliant. Most ILSs use this information to then generate the Z39.71 punctuation in the OPAC displays:


Another point to note about the relationship between Z39.71 and MFHD is that the MARC 21 Holdings format supplements Z39.71 in the sense that it defines additional data elements that are not part of the Z39.71 standard. A partial list of these supplementary data elements might include:

          Method of acquisition                       Intent to cancel the subscription
          Language of the item                        ISBN, ISSN, etc.
          Reproduction note                             Reproduction policy
          Interlibrary Loan policy                     Action note

These data elements are officially out of the scope of Z39.71 but may be required to be present in the holdings record by an ILS or a bibliographic utility.

  • Was this article helpful?