What’s Wrong with MARC? (NISO BIBFRAME Roadmap Meeting, Part 2)

Librarians have been talking about what’s wrong with MARC for so long, at this point it seems like you shouldn’t even have to ask. It was 11 years ago that Roy Tennant published his now infamous article, MARC Must Die in Library Journal. But MARC is far from dead. At the NISO BIBFRAME Roadmap Meeting, Karen Coyle said that not only should MARC die, but that we need to take an active role in killing it. I don’t disagree, but I think we should spend some quality time talking about what it is, exactly, that makes MARC so wretched. It does, after all, still have its defenders.

Todd Carpenter pointed out at the beginning of the two-day meeting that people will not move away from our legacy systems, away from MARC, unless its successor is demonstrably cheaper and more efficient. So we need to be very explicit about what makes our existing systems expensive and inefficient.

Most of the complaints about MARC that I’ve heard center around a few key problems: It’s not particularly interoperable, it’s not easily extensible, and it doesn’t offer enough granularity in the data elements. Even with the amazing shared cataloging infrastructure we’ve created over the last 50-plus years, our data couldn’t honestly be considered easy to share. It doesn’t play well with other, non-library systems, and therefore, our metadata remains isolated. Our systems infrastructure is dominated by a few giant gorilla corporations because working with our data isn’t something that many programmers can or want to do. There aren’t a lot of people coming up with new, better systems that work with MARC.

But I think, other than the interoperability and granularity issues that have been identified, one of the biggest problems with MARC is that it is difficult. It’s difficult to learn, and difficult to use. Cataloging is expensive because MARC is hard, and the systems that use it are complicated. Cataloging is costly, and libraries could achieve a great deal of cost savings by implementing easier to use data structures. Sometimes I think cataloging is the third rail of library discussions, but I’m going jump right on it: It is not the library’s responsibility to employ catalogers. It is the library’s responsibility to make our resources easy for our users to find, and if we can do that faster and cheaper, we have an obligation to do so.

The other unspoken truth of library metadata is that, because of the difficulty of MARC, our metadata is riddled with errors. We talk a lot about the quality metadata that libraries create, but if you spend any time working with large sets of MARC records, you realize pretty quickly how untrue that really is. MARC offers way too many opportunities for human error. It’s complexity practically guarantees that all but the very best catalogers are going to make mistakes (and even the best will make a few). Our metadata is a mess. Every cataloging librarian I have talked to has admitted that. If we can come up with a data model, and systems that implement it, that cut out some of those opportunities for human error, we should.

I think we cling too tenaciously to our complicated, obscure practices because they make us feel important. We like to think about the richness of our metadata, without thinking about what that richness is being used for, and why we need it. I’m not saying we don’t. I’m not saying we should throw it all away, and just start downloading our metadata from Amazon. But I do think that, as we examine what we have done, we should think long and hard about every element, and determine whether it’s truly useful to our users. And then we should look at every piece that remains, and try to find the redundancies, the dependencies, the pieces that make MARC so complicated, and take a big, giant hatchet to those places.

Simpler, less complex metadata means that our metadata will be more interoperable, more flexible, less expensive to create, and of more use to our users. If we’re not starting there, we’re not making any changes that are significant enough to be worth it.