In Part 1 of this series I looked at what has become the inevitability of change in our fundamental bibliographic metadata standard MARC. And by MARC I really mean the collection of technologies, rules, carrier formats, and what have you that could be hung off that rubric.
However, as I turn to identifying specific problems that I and other see with our present situation, I should take pains to point out that I am mostly referring to the MARC21/AACR2/ISBD formulation that has held North America in its sway for lo these many years.
Also, it became clear that I as I shared a draft with colleagues that I had enough to work with that I should break it into two parts — this first part are largely the things that I see as problems and the second part will be things that my colleague Jean Godby has identified as specific issues discovered from her voluminous and thorough work at crosswalking MARC21 to ONIX and other formats and vice versa.
So with that, let’s get started, and in no particular order:
- Needless complexity. Over the forty or so years that MARC has been around, it has accreted many fields and/or subfields. Some of these are veryinfrequentlyused and yet they remain part of the standard. This means that any software written to produce or process MARC records must accommodate fields and/or subfields that hardly anyone uses. Such complexity comes at a cost that is not always justified.
- Over-reliance on punctuation for semantic purposes. Punctuation marks are used in MARC for display purposes or for indicating different elements (that is, for enhancing granularity). For example, commas, slashes, and colons often appear to indicate separate elements and yet those marks can damage the ability to unambiguously parse the elements for purposes other than simple display.
- Lack of sufficient granularity. For example, the 100 field where a personal name is recorded relies upon the placement of a comma to delineate parts of a name. This prevents, for example, the delineation of the male and female surnames for the names of Spanish creators (order can no longer be assumed to be male-female as it might have been in the past).
- Lack of standardized statements/declarations when those would be useful. One of the most basic things a library use expects to be able to do is to identify content that is fully digital and openly available, and yet we have no way to unambiguously state this using MARC (see, for example, “MARC and the Trouble with Online”, http://www.infodocket.com/2013/03/05/slide-presentation-roy-tennant-on-marc-and-the-trouble-with-online-or-metadata-carnage-and-where-we-go-from-here/ )
- Inability to unambiguously encode important characteristics. We presently have hundreds of ways that we attempt to encode the concept that a given URL in an 856 field will lead the user to the full item online. This is because we have no unambiguous way to encode this information. Neither do we have an unambiguous way to encode the information that an item is open access. Both of these are extremely valuable aspects of our bibliographic data that users rightly expect us to be able to provide.
- Lack of easy extensibility. MARC lacks the ability of a given community (for example, archivists) to specify their own set of descriptive elements that could either be processed or ignored by consumers of MARC given their needs. Rather, even the most minor of changes must be vetted through a time-consuming process to eventually be added to a standard where every element has equal weight to every other element (see “Needless complexity” above).
- Technical marginalization. The only users of MARC are libraries, and to a much lesser degree, publishers. Meanwhile, the publishing community has created its own standard, ONIX, which will likely marginalize MARC even further in the bibliographic metadata world. MARC itself is anachronistic as a computer communication standard, since to have even the remotest chance of understanding it requires reference to documentation that identifies the purpose of – for example – every byte in the header. And yet our complete reliance on a single record format means we are ill-equipped to deal with anything else.
Those are just some of the issues that occur to me as I think about where we are now and where we need to be. I would be interested to hear your thoughts — whether for or against — in the comments below.