Building a MARC Cataloger From Scratch

Status clarification, September 11, 2026. This is a design and build log. The source inspection recorded below lists SRU and other lookup sources; it reports no OCLC services and no implemented Koha or Evergreen integration. A reproducible input/output demonstration and failure-case results are not published here. Planned capabilities should be read as targets, not tested outcomes.

Catalogers have described a gap between full vendor ecosystems and the focused, standalone tools they use to edit and validate records. MarcForge is my attempt to test that gap.

A few months ago I went looking for a browser-based MARC editor with strong keyboard support and validation outside an ILS.

Here's what I found: BTCat is gone. MarcEdit is a one-person project Terry Reese has maintained for decades, and it does the job it was built for. It is a desktop application, so it does not give me browser-based access or the keyboard-driven editing surface I want, which is the specific gap I am trying to fill rather than a criticism of his work. I have not put any of this to him. OCLC Connexion does what it does well within its ecosystem, with the pricing and integration that come with that. The ILS-native editors vary in fit depending on your vendor and workflow.

What this is

The working name is MarcForge. It is a standalone cataloging experiment, not an ILS or a discovery layer. The intended workflow is to create, edit, validate, and export MARC records. The published evidence does not yet establish that the complete workflow succeeds.

The stack:

• Frontend: Next.js + React with a purpose-built MARC editor component
• Backend: Python/FastAPI
• Storage: PostgreSQL + OpenSearch
• Cache/queue: Redis
• Dual format storage: raw MARC21 binary alongside normalized MARCJSON

That last point matters. MARC21 is the exchange format. It's what your ILS imports, what OCLC expects, what Z39.50 serves. But it's a hard format to query, diff, or build UI around. MARCJSON gives you a clean JSON representation for the application layer while keeping the canonical binary for interoperability. You always have the real record. You also have a version you can actually work with.

Why standalone

This was the first real decision. Why not build cataloging directly into l/30?

l/30 has a cataloging module. It works. But a lot of catalogers don't work inside a single ILS. They work across systems: contributing to OCLC, pulling records from Z39.50 sources, editing batches for a consortium, cleaning up a migration file. The tool they need isn't married to one system's data model. It's a workbench that connects to whatever they need it to connect to.

BTCat understood this. It was standalone, it was fast, and catalogers loved it. When Baker & Taylor wound down its operations and BTCat went with it, the software disappeared and so did the philosophy: cataloging tools as their own thing rather than a feature inside something else.

The design calls for MarcForge to exchange records with L/30 and other systems through standards such as Z39.50 or SRU. Koha and Evergreen integration is planned and is not present in the inspected code.

The editor

The editor is the central hypothesis: a focused interface may make repetitive MARC work faster without hiding the record structure.

The design puts field definitions, valid indicators, and common subfield patterns beside the record. The intended result is guidance available in context rather than in a separate reference document. That interaction still needs to be tested with catalogers.

Side-by-side diff and merge handles the case where you pulled a record from OCLC, you have a local version, and they don't match. Today that means eyeballing two records and manually copying fields. MarcForge shows you exactly what changed, field by field, and lets you merge selectively. This is the workflow that eats hours in batch cataloging and the place where a focused UI can save the most time.

Macro automation covers the repetitive edits catalogers do constantly: stripping fields for a specific load profile, normalizing punctuation across a batch, adding local fields based on location codes. The plan is sandboxed Python macros with access to the record structure but restricted globals so they can't reach outside the record.

Validation runs continuously, not as a batch step after the fact. And it understands context. "Is this field repeatable" is the easy check. The real ones are "does this 245 have the right punctuation for ISBD" and "does this 1XX match an authority record" and "is this call number consistent with the classification scheme in the 050."

Authority linking

This is one of the pieces I'm most interested in getting right. When a cataloger types a name in a 100 field, MarcForge queries id.loc.gov in real-time and offers matching authority records. Accept a match and the heading is linked. Not just text-matched, but URI-linked to the Library of Congress authority file.

This is where MarcForge connects to the BIBFRAME conversation. MARC records with authority URIs are MARC records that are ready for linked data. You're not doing BIBFRAME yet, but you're building records that will translate cleanly when the time comes. Every linked heading is one less thing to reconcile during a future migration.

The authority linking also works for subjects (LCSH, LCGFT), classification numbers, and geographic names. Anywhere the Library of Congress maintains an authority file, MarcForge can connect to it. The lookup is fast because results are cached in Redis with a sensible TTL. You're not hammering id.loc.gov on every keystroke.

Multi-tenant and audit trail

MarcForge supports multiple users and organizations from the start. Role-based access control, because not everyone in a cataloging department has the same permissions and not every consortium member should see every other member's records.

Every change to every record is tracked. Full audit history: who changed what, when, and what the record looked like before. This is good practice, and it's something catalogers have asked for. When you're trying to figure out why 200 records lost their 856 fields last Tuesday, "check the audit log" should be a real answer.

ILS integration

The plan is to connect to the systems catalogers already use:

• Z39.50/SRU for searching and retrieving records from any compliant source
• Koha via its REST API for direct record push/pull
• Evergreen via its APIs

The integration would be read-write where the target system supports it. Search a Z39.50 source, pull a record into your workspace, edit it, push it back to your ILS. That's the core loop, and proving that it works cleanly is what Phase 0 is about.

Where this actually landed, as of September 2026. The shipped tool queries the Library of Congress and the Biblioteca Nacional de España over SRU, plus Open Library and Google Books. There is no Koha or Evergreen integration in the code yet, and there is no OCLC integration at all: the project's README now states that "no OCLC services, APIs, or generated vocabularies are used anywhere in the pipeline," which is a deliberate design choice rather than a gap. An earlier version of this section listed OCLC among the Z39.50 sources and described all three integrations in the present tense. Corrected September 10, 2026.

Where this stands

Phase 0. I'm calling it a spike because that's what it is. I'm proving the core loop works before I build out the full feature set.

The core loop: search a source, retrieve a record, display it in the editor, edit it, validate it, export it. Every link in that chain touches a different technical problem. The MARC21 parser has to handle the real-world records that exist, not the spec-perfect records that don't. The editor has to render variable-length fields with proper subfield display. The validator has to know the difference between an error and a cataloging choice.

The first concrete target for Phase 0: round-tripping a MARC21 record through the MARCJSON representation and back without any data loss. That sounds simple but it isn't. Real-world MARC records from different ILS exports have inconsistencies the parser has to handle gracefully. Getting that right before building the editor on top of it is the right order.

The first version of the editor will be wrong, and I know that going in. The field ordering will annoy someone. The keyboard shortcuts will conflict with something. The validation will flag things that are fine and miss things that aren't. That's the point of building in public. The feedback loop starts before the architecture calcifies.

The BIBFRAME bridge

The short version of the MARC-to-BIBFRAME transition: the Library of Congress has been cataloging in BIBFRAME production since 2024, and the rest of the supply chain will follow on its own timeline.

MarcForge is a MARC tool. It's not pretending to be a BIBFRAME editor. But the design decisions, authority linking via URIs, clean JSON representation of records, separation of intellectual content from carrier information, are all decisions that make the eventual bridge easier to build.

When the time comes to add BIBFRAME output, records whose headings are URI-linked will translate more cleanly than records that store headings as flat text. Good MARC is the best preparation for good BIBFRAME, and MarcForge is designed to produce good MARC.

Why open source

Same reasoning as l/30. AGPL-licensed, because cataloging tools shouldn't require a license fee and shouldn't disappear when a company changes direction.

BTCat disappeared because it was a commercial product tied to a commercial company. When the company's business model changed, the tool went with it. Companies make business decisions, and an open-source alternative gives catalogers something that doesn't depend on any one company's roadmap.

An open-source cataloging tool that works well is infrastructure. Building on MarcEdit's legacy, with a bus factor greater than one and a web-native architecture that distributes the maintenance load beyond a single developer's shoulders.

What I'm looking for

I spent years on the vendor side of library technology. I know what catalogers ask for in support tickets, in feature requests, in the workarounds they build when the software doesn't do what they need. That's useful context, but it's not the same as watching someone use the thing I built.

If you are a cataloger, I would like to know which parts of the proposed core loop match your work and which do not. That feedback is evidence the project needs before its interface hardens.

The source is public. The Phase 0 goal described here is a MARC21/MARCJSON round trip; publishing code does not establish that the workflow has passed a reproducible validation.

Sources

• MarcForge source, AGPL-3.0. The source list read from src/marcforge/sources/ on September 10, 2026: Library of Congress SRU (lx2.loc.gov:210/lcdb), Biblioteca Nacional de España SRU, Open Library, Google Books, and id.loc.gov for authority lookups.
• MarcForge README, on OCLC: "No OCLC services, APIs, or generated vocabularies are used anywhere in the pipeline."
• Library of Congress, BIBFRAME Update Forum, January 2025, for BIBFRAME production at LC: the introduction deck records "2024 — BIBFRAME production (BFProd)" following pilots in 2014 and 2016, and the training deck puts over 300 cataloging staff in the directorate with BFProd training targeted for completion March 31, 2025.

Disclosure: L/30 and MetisLib are mine. Both are open source, neither takes real patron data, and neither is sold to anyone.