My colleague Roy Tennant has eloquently argued that "MARC Must Die". Certainly much of what he says is true, but it's been almost 13 years since that column and MARC, while weakening, still seems to be hanging on. I think there is actually more going on here than simply legacy software that won't go away, so I'd like to offer my less eloquent defense of MARC.
First what I'm defending here is underlying MARC Communications format (ANSI Z39.2/ISO 2709), or at least the XML/JSON equivalents, not full MARC-21 or other variants with their baggage of rules. Those rules and their encoding could also use some defense (after all they were all established after extensive debate) but that is a different essay.
What I like about MARC is its relative lack of predetermined structure beyond indicators, fields and subfields and conventions about using 3 digit numerics for tags, and a-z, 0-9 for subfield indicators. Admittedly, you are restricted with the two level field/subfield, but an amazing amount of bibliographic stuff fits (and anything can be shoved) into such a structure. The 5 digit length field is a serious limitation, but overcome with the translation to XML/JSON. I watched a video by Donald Knuth recently about "Constraint Based Composition" where he talks about constraints on form fostering creativity. Maybe MARC format's constraints may be just the sort of structure that makes metadata somewhat manageable, while still retaining some flexibility.
Contrast this to a MODS/MADS record. Here everything is laid out, with rules to make sure you don't modify the structure. When we started xA, a small authority file to feed into and control VIAF, MADS seemed a better fit for the rather simple authority records we expected to create than a full-blown MARC-21 authorities record. What I didn't realize was that bringing up a simple editor for MARC is a day or two's work (see mS, also known as the MARC Sandbox). A full MADS editor would be substantially more work. In fact xA's simple take on MADS was substantially more work. Which was OK, until we decided to change something. No longer was it just a matter of sticking in a new text field (and possibly modifying a table to allow it), but interface issues need to be faced, and changes made in the record display and editing forms.
All of a sudden, the slightly more work for a possibly friendlier form, turned very unfriendly for someone (me) trying not to spend any more time on the infrastructure than absolutely necessary. In mS you can actually cut and paste from a MARC display in other MARC tools and things 'just work'. Plus there is the familiarity with MARC which makes many people (at least where I work!) very comfortable. The ability to easily add fields and subfields to accommodate new needs appears to be much more important than a pretty interface. In fact, we attempted to extend xA to handle the needs of some Syriac scholars, but failed because of the amount of effort involved. What did they use instead? A very complex Excel spreadsheet! I've seen any number of attempts to fit bibliographic information into spreadsheets, and they do not work nearly as well as MARC.
The first version of the mS form was actually MARC, but with tags, indicators, subfields neatly separated into their own boxes. It turned out that the simple text field we are now using was both easier to work with (e.g. cut/paste) and substantially easier to get working smoothly.
I admit that using MARC seems quite retro. MARC is an old format that has held up surprising well, but is showing its age. Using it is a bit like using Emacs or Vi to create software. They are very 'close to the metal' and that's just what lots of people want.
--Th
Comments