NASIG | North American Serials Interest Group

Publications

NASIGuide: Serial Holdings

Automated Holdings and the Purposes of Coding

The heart of local serial holdings automation, called "automated serials control," is the integration of acquisitions functions - prediction and receipt of serial issues - with online display of any issues and volumes held by the library. In addition, this same data may in some systems be used in other processes, including management of physical volumes for binding, inventory, circulation, preservation, etc.

Beyond local needs, holdings data contributes to "universal" serials control in the form of information to facilitate bibliographic identification, publication pattern data, and tracking what was issued under what titles. To support this control, holdings systems accommodate remote searching, union listing, and information sharing.

In the national standards, the wider communication functions become primary. The standard for holdings automation is the MARC21 Format for Holdings Data. The Format can be used for bibliographic items of any type, but its utility for serials is most widely recognized. This Format is the collaborative product of a resource-sharing experiment. In the early 1980s, eight Association of Southeastern Research Libraries (ASERL) libraries joined together to create standards for sharing holdings data by computer, and were eventually encouraged to develop a new MARC Format. Of the pioneer MFHD-compliant systems, only one or two big ones still survive. Over time, however, MFHD has slowly gained acceptance in a new generation of systems. As the century begins, the major online integrated library systems (ILS) have implemented "MARC holdings" for their customers.

In addition, MFHD is the vehicle for a national project, called the CONSER Publication Patterns and Holdings Project, to develop a "universal" holdings record for as many serial titles as possible (beginning with current publications). For the purposes of that project, a wide group of libraries, vendors, and utilities are studying, and experimenting with the Format. Its website is http://lcweb.loc.gov/acq/conser/patthold.html.

Basic MARC compliance involves the ability to communicate, export, and import data in the format. Most systems that have implemented the MFHD can accomplish these functions. In local system functionality, they are still uneven. The Format emphasizes the basic functionality. It suggests and designs data elements for further local functionality, but does not prescribe how it is to be done. Some suggested functionality:

  • Predictive check-in on the basis of embedded patterns. Patterns, linked to the captions of the enumeration/chronology, analyze each publication's frequency and sequence of issues, to predict the next expected issues and to perform check-in and claiming.

  • Full ranges of display options for summary and detailed holdings that can be compressed and expanded. With holdings compression and expansion, a library might be able to display a holdings statement in various ways: by itemizing each issue on the basis of the checked-in data, by compressing the entire data into a single free-text note, or a range of options in between. However, their choices would not preclude other ways to view the data. A library might want to be able to provide more than one view on command, in greater or lesser detail. In the vision of the Format, manipulation of the data should be flexible enough to accommodate all display needs from that of the local query to the Z39.50-based remote search or union list entry.

  • Management of physical pieces for such purposes as circulation and inventory at the option of the library. Such functions as binding and spine labeling can use check-in data and automatically compress it, perhaps to volume-level data able to function in physical piece management. Some of the newest parts of the Format - the item fields - aid in this processing. However, not all of this "local" data is considered adaptable for the MFHD. Some of the data remains in a local item record, with either a linked or a separate structure.

As library automation vendors gain experience with the MARC Format for Holdings Data, they have provided increasing portions of this functionality. Some functions, such as compression and expansion, have barely begun to appear. In existing implementations, variances remain wide. They range from user interface (what the inputter sees while coding) to basic structural issues (for instance, whether item records - the records which carry data on library processes such as circulation and inventory - are dependent on and linked to the MFHD data, or entirely separate). No library has yet enjoyed a "complete MARC Format for Holdings Data implementation" in the sense of a complete range of possible functionality plus the capability to display any and all holdings optimally for all users. However, many may have systems that do one or more of those things in a superior manner.

For these reasons, users will inevitably see things in the Guide that cannot be used in their own system. Nonetheless, it helps to be aware of the purposes of the Format and its coding, the features of the best (or future best) systems, and the limitations which may make the Format less useful than it could be. Coding will improve, conversation with system vendors and utilities will be more satisfactory, systems will add features, and the library user will benefit from clearer information.

If you are using MFHD now, whatever the implementation, it is important to keep your coding and data entry conforming to the standard. The next version of the system you are using now may correct the very problem you are trying to "work around," and you may find that what you did to make the data "look right" has now turned it into garbage.

There are always temptations to bend the rules. If you must, have a way to deal with the workaround before it comes time to migrate again. This means documenting, tracking the records involved, and having a way to correct them quickly if necessary.

The Guide notes conversion and migration issues to a greater degree than previous documentation on holdings, and tries to provide this information even at the individual code level. In general, whatever the source of holdings information to be migrated, the more information that can be distinguished by coding it, delimiting it, or marking it, the better. Investigate what can be done automatically within your present system in order to get your data better identified and ready for a smooth transition to MFHD.