By Roy Tennant
Note: This article was originally published in the OCLC research blog Hanging Together¹ on October 15, 2017. It is being republished here with permission from the author.
Fifteen years ago to the day I declared that “MARC Must Die” in Library Journal. It sparked a firestorm of criticism, mostly from the cataloging community, and several invitations to speak. Over the years many would misquote the title or misunderstand my point, and claim that I said “MARC is dead”. I didn’t, and there is a key difference. I simply knew that MARC remained a sacred cow in libraryland and I was intent to blow it up (how’s that for mixing metaphors?)
I wanted librarianship to wake up to the fact that our foundational standard was no longer serving us like it should.
Unfortunately, some seemed to take it as a blow directed against catalogers, not the standard that they were accustomed to working with. One AUTOCAT-L subscriber even wrote a parody of my piece titled “Why web services departments must die” (I was a web manager at the time). I wasn’t calling for catalogers to go away. I just wanted something better for them to work with.
There was also the feeling that MARC had everything we needed but that our automated systems were not doing enough with it. I agree with that to a point, but for example, how does one specify in MARC that a given URL will take someone to the openly available full-text of an item? That seems like a laughably simple thing to do and also very important, but there is no way for us to assert this unambiguously in a form that computers can easily use. Still. Metadata situations like this are completely indefensible in the world of the web.
As I re-read some of the discussion on AUTOCAT-L from back then I must admit that many of the posts were at least civil, and there were useful points brought to the debate. There were a couple people who wondered if I was a librarian (a fact easily Googled), despite having worked in libraries my entire adult life and writing a monthly column for five years in one of the most widely read professional magazines, but things like that come with the territory when you set out to be provocative. If you can’t take the heat, stay out of the kitchen. I’ve somehow always found myself in the kitchen. Starting fires, even.
I also feel a need to point out that I hadn’t come to this realization lightly, or quickly, that MARC was standing in our way more than helping. In the lead-up to that controversial assertion I had written columns like “Twenty-First Century Cataloging,” “The Art and Science of Digital Bibliography,” “The Consequences of Cataloging,” “Metadata as if Libraries Depended Upon It,” and “The Importance of Being Granular”, which all had something to say about library metadata and the challenges we faced with our existing tools. Those columns and others are collected in the book Managing the Digital Library, which I am requesting that the HathiTrust make open access (they have a form you can submit for just this purpose). [Update: They did! Here is a direct link to it.]
So what has happened over the last 15 years? For starters, no one seems to think it’s controversial anymore. The Library of Congress has not only admitted that MARC’s days are indeed numbered, they are actively working to develop a linked data replacement. I don’t by any means think that we are out of the woods of making this transition yet, and I also believe it will take many years.
The good thing is that we can finally move on from anger, denial, and hurt to a more constructive place of trying to figure out to more effectively replace it. It’s just that it has unfortunately taken half of my professional career to get here.
SEE ALSO
REFERENCES
1. Roy Tennant, "MARC Must Die” 15 Years On," Hanging Together, https://hangingtogether.org/?p=6221 (accessed May 21, 2020)
FEEDBACK AND COMMENTS
James Weinheimer (Information Specialist, Rome, Italy) - One of the problems I had with Tennant's article (and still do) is that he never really explained what he meant by MARC having to die. Did he mean 1) that it was the raw ISO-2709 format that no human can read? 2) Did he mean the numbered fields and lettered subfields, so that you would have some field labelled "titleproper" instead of 245$a? 3) Did he mean that the MARC format keeps other agencies from using library records, so our records end up isolated in their "silos"?
Concerning 1) the ISO-2709 format should have been changed long ago.
Concerning 2) almost every system I have seen has displays for the managers and inputters, and different ones for the public. The MARC fields and subfields are only computer codes and can display however someone wants (as 245 displays as "Title" to the public), so changing that never made much sense.
Concerning 3) library records have been available to the general public for over a decade at least, and in different formats (not only raw MARC but in Dublin Core, OAI-PMH, schema.org if not others) and the availability of our records has made precisely zero difference to the world of metadata. I don't see how the outrageously complex Bibframe will change anything.
So, while it's fine to get rid of MARC, I question (and still question) whether doing so will actually change anything, for the better or otherwise.
Concerning 1) the ISO-2709 format should have been changed long ago.
Concerning 2) almost every system I have seen has displays for the managers and inputters, and different ones for the public. The MARC fields and subfields are only computer codes and can display however someone wants (as 245 displays as "Title" to the public), so changing that never made much sense.
Concerning 3) library records have been available to the general public for over a decade at least, and in different formats (not only raw MARC but in Dublin Core, OAI-PMH, schema.org if not others) and the availability of our records has made precisely zero difference to the world of metadata. I don't see how the outrageously complex Bibframe will change anything.
So, while it's fine to get rid of MARC, I question (and still question) whether doing so will actually change anything, for the better or otherwise.