This paper surveys the cataloging literature to collect problems that have been identified with the MARC 21 format. The problems are sorted into (1) problems that are not the fault of MARC 21; (2) problems that perhaps are not problems at all; (3) problems that are connected with the current shared cataloging environment; and 4) other problems with MARC 21 and vendor implementation of it. The author makes recommendations to deal with the true MARC 21 problems that remain after this analysis.
A number of writers in our field have suggested recently that it is time to move our cataloging data out of the MARC 21 format and into something else, perhaps XML. (1) XML (Extensible Markup Language) is a subset of SGML (Standard Generalized Markup Language) in which tags are unlimited and not redefined. Even quite knowledgeable MARC 21 leaders recognize that MARC 21 has a much smaller installed base than does XML and that, at some rime in the future, we may have to plan for a migration of our data into something like XML or one of its successors in order to have access to a broader marketplace of software and hardware solutions to the problem of bibliographic control. (2) In fact, the Network Development and MARC Standards Office at the Library of Congress has made it quite easy for any institution that wants to switch their MARC records to XML to do so today by providing both a full MARC 21 XML schema and an abbreviated "MARC XML lite," known as the Metadata Object Description Schema (MODS). (3) There is also evidence that the world at large is turning to examine the issues and problems that for the past several hundred years have occupied only librarians. (4) Given this situation, now is a good time to consider whether a future transition might provide the opportunity for beneficial changes to be effected in our shared cataloging environment and in out methods of tagging and coding cataloging data for the purposes of sharing it.
The purpose of this paper is to explore the various problems that the writers have associated with the MARC 21 format. There are actually four categories of problems.
In the first category are problems that are hOt actually the fault of MARC 21, but rather lie with the cataloging rules and practices that provide content for the MARC 21 data structure standard, such as the Anglo-American Cataloguing Rules 2nd ed., revised, (AACR2R) and Library of Congress Subject Headings (LCSH). Such problems will be identified but not discussed extensively, as the need for change in cataloging principles and the rules based on them is much too broad a subject to be covered here. One exception to this approach is made for problems associated with multiple versions and FRBR (Functional Requirements for Bibliographic Records), on the grounds that MARC 21, the cataloging rules, and the shared cataloging environment are so entwined in their effect on possible solutions that they cannot be separated from each other.
In the second category are problems that perhaps are not really problems at all, but rather solutions to problems that are imperfectly understood by many writers.
In the third category are problems that are due to the shared cataloging environment that MARC 21 was designed to support. Simply changing MARC 21 without also changing the context in which it operates cannot solve these problems. Here we must deal to a certain extent with possible changes in the cataloging rules.
Finally, in the fourth category are some known problems that are either caused or partially caused by MARC 21 and that perhaps could be solved in the process of migrating our data to some new data structure standard in the future. These latter problems I have referred to as a MARC 21 shopping list. It is possible that a number of these latter problems would be better solved in vendor software implementation than in the MARC 21 format itself. In these cases, it is hoped that this paper will stimulate discussion in the vendor community about better ways to use existing MARC 21 data to provide better user service. …