MARC is a cataloging data format designed in 1968. For context, that’s the same year we invented the computer mouse and decided bell bottoms were a good idea. We stopped wearing bell bottoms. We still use MARC.

(This is part of why your catalog search sucks, by the way.)

What MARC Actually Is

MARC stands for Machine-Readable Cataloging. It’s a way to structure library catalog data so computers can read it. In 1968, this was revolutionary. In 2025, it’s like using a rotary phone to make a Zoom call.

The format uses numerical tags to identify different pieces of information about a book. Title goes in the 245 field. Author goes in 100. Subject headings live in the 600s. There are subfields marked with dollar signs and pipes and other nonsense that made sense when punch cards were cutting-edge technology.

Why It Should Be Dead

Reason 1: Nobody Understands It

Ask a new librarian to explain what 245 $a $b $c means and watch their soul leave their body. MARC is incomprehensible to humans without specialized training. That’s a problem when you’re trying to hire people.

Reason 2: It’s Inflexible

Want to add a new type of data that wasn’t imagined in 1968? Good luck. MARC was designed for books. It handles ebooks poorly, streaming media worse, and modern data types like datasets or 3D models not at all.

Reason 3: It’s Expensive to Maintain

Every ILS vendor charges you to store MARC records. Every migration involves converting MARC. Every new cataloger needs training on MARC. The accumulated cost of maintaining a 57-year-old format is staggering.

Reason 4: Better Alternatives Exist

BIBFRAME exists. Schema.org exists. Linked data exists. We have modern, flexible, machine-readable formats that actual humans can understand. We just don’t use them.

Why It’s Still Alive

Here’s the uncomfortable truth: MARC is still here because migration is expensive and nobody wants to pay for it.

Network Effects Are Real

OCLC has millions of MARC records. Vendors build systems around MARC. Catalogers know MARC. Training materials assume MARC. Switching means breaking all of that at once. That’s terrifying.

The Devil You Know

MARC is terrible, but it’s predictable terrible. You know what 650 $a means. You know how subfields work. Moving to a new format means learning new terrible, and humans hate change more than they hate inefficiency.

Budget Reality

Migrating from MARC to BIBFRAME or linked data costs money. Lots of money. Money that could go toward staffing or collections or literally anything else. So libraries keep using MARC because the alternative is worse.

Nobody Owns the Problem

Who should fix this? OCLC? The Library of Congress? Individual libraries? Vendors? Everyone points at everyone else and nothing happens.

What Actually Needs to Happen

Stop Pretending MARC Will Die on Its Own

MARC will not die naturally. It will live forever unless someone actively kills it. Waiting for vendors to spontaneously support BIBFRAME is naive.

Pick a Standard and Commit

The problem isn’t lack of alternatives. It’s lack of consensus. BIBFRAME exists but nobody uses it seriously. Schema.org exists but libraries ignore it. Pick one. Make vendors support it. Migrate.

Make Migration Affordable

Libraries can’t afford to migrate because vendors charge obscene amounts for data conversion. Make conversion tools open source. Share migration playbooks. Stop treating data migration like a billable consulting project.

Train New Catalogers on Modern Standards

Stop teaching MARC to new library science students unless they’re specifically going into legacy systems work. Teach linked data. Teach metadata standards that will exist in 20 years.

The Actual Problem

The actual problem isn’t MARC. It’s that libraries are risk-averse, underfunded, and stuck in vendor lock-in. MARC is a symptom.

Vendors won’t support new standards until libraries demand it. Libraries won’t demand it until budgets allow for migration. Budgets won’t allow for migration until administrators understand the cost of technical debt.

It’s a cycle. And we’re all stuck in it.

What You Can Do

If you’re a cataloger: Learn BIBFRAME or linked data anyway. Future-proof yourself.

If you’re an administrator: Budget for migration. Not next year. This year.

If you’re a vendor: Support modern standards or get replaced by vendors who do.

If you’re a library school: Stop teaching MARC as the default. Teach it as legacy format maintenance.

MARC should be dead. It’s not. And that’s entirely our fault for letting institutional inertia win.

The sooner we admit that and actually do something about it, the sooner we can stop explaining to new librarians why dollar sign b is a subtitle indicator.

Demand BIBFRAME roadmaps from your vendors. Stop accepting “industry standard” as an excuse.

Frequently Asked Questions

What is MARC in libraries?

MARC (Machine-Readable Cataloging) is a data format created in 1968 to structure library catalog records so computers can read them. It uses numerical tags (245 for title, 100 for author, etc.) and subfield codes to organize information about books and other materials.

Why do libraries still use MARC?

Libraries still use MARC because migration is expensive, OCLC has millions of MARC records, vendors build systems around MARC, and catalogers know MARC. Network effects and budget constraints make switching costly, even though better alternatives exist.

What will replace MARC?

BIBFRAME (Bibliographic Framework) and linked data standards like Schema.org are designed to replace MARC. However, widespread adoption is slow due to migration costs, lack of vendor support, and organizational inertia. Libraries need to demand vendor support and budget for conversion.

Is MARC hard to learn?

Yes. MARC requires specialized training to understand field tags (245 for title, 100 for author, 650 for subjects), subfield indicators ($a, $b, $c), and arcane syntax rules. This makes hiring and training catalogers difficult and expensive.

Can I migrate from MARC to BIBFRAME?

Technically yes, but few libraries have done it successfully. Migration requires vendor support, budget for data conversion, staff retraining, and system upgrades. Most libraries wait for vendors to support modern standards instead of migrating independently. The best approach is demanding vendor roadmaps for BIBFRAME support.

Authenticity note: With the exception of images, this post was not created with the aid of any LLM product for prose or description. It is original writing by a human librarian with opinions.