Museum Collection Data Export and Open Standards

Why data ownership matters more than it sounds

Most small museums never think about leaving a catalog system until something forces the question: a volunteer who built the database moves away, a subscription lapses, a board decides to change tools. At that point the museum finds out whether it ever really owned its records.

Your catalog is the record of what you hold, who gave it, what condition it is in, and what stories go with it. That information took years of volunteer hours to collect. It should outlive any one piece of software, any one volunteer, and any one budget cycle. The practical test is simple: could you, this afternoon, hand your whole catalog to someone else in a form they can open?

Start with a plain-spreadsheet export

The most dependable format for catalog data is the humble CSV file: one row per object, one column per field. Any spreadsheet program opens it, any future system can import it, and it will still be readable in thirty years. It is not glamorous, but it is the lifeboat.

In MuseumBuild, Objects → Export gives a full CSV of every real field. The same idea applies to contacts, since the museum's relationships with donors and lenders are part of its history too. Whatever system you use, ask the same question: does the export contain every field, or only a summary?

• Export the whole catalog, not a filtered view, so nothing is quietly left behind.
• Open the file yourself and look at a few records you know well.
• Check that dates, numbers and descriptions came through intact, including numbers with dots or dashes in them.
• Save the file somewhere that is not the same computer or account as the system itself.

Build a simple backup rhythm

An export you made once, three years ago, is a souvenir rather than a backup. Pick a rhythm that matches how fast your catalog changes. A museum cataloging every week might export monthly; a family collection that changes a few times a year might export every quarter and after any big cataloging push.

Write the habit down in your collections procedures, give it to a named role rather than a named person, and keep dated copies so you can see how the catalog grew. Store at least two copies in two places, and have a second person confirm they know where they are. A backup that only one volunteer can find is a single point of failure.

Permanent numbers make your data portable

Data you can carry is data whose identifiers stay stable. Museum object numbers are meant to be permanent and never reused, because the number is what ties the physical object, its tag, its paperwork and its record together. If numbers get reshuffled in a move, every old label and every old document stops pointing at the right thing.

MuseumBuild numbers objects cataloged from an accession in the three-part year.accession.item style, and those numbers are permanent and never reused. When you bring in an existing catalog, the Import screen keeps your existing object numbers, so your old labels and paper files still match. If you are weighing a numbering scheme, the guide on accession numbers explains the reasoning in detail.

Open standards: what OAI-PMH and IIIF mean for a small museum

Open standards are shared, published ways of describing and sharing collections, so that your records are not trapped in one vendor's format. Two are worth knowing by name. The first is OAI-PMH, a long-established method that lets a collection be harvested, meaning that another service can collect its public records automatically. The second is IIIF, a common way of delivering images so that scholarly image viewers around the world can open them.

In MuseumBuild, every museum is an OAI-PMH repository, which is what the Digital Public Library of America's service hubs harvest, and it speaks IIIF so images open in scholarly viewers. These apply to published objects only, and you will find them under Connected Collections. There is no export step to run for them.

For a small museum the point is not to become a technologist. It is that when your public collection speaks open standards, it can be found and used by researchers and aggregators without you rebuilding anything, and it is not tied to one product's pages.

Public data and private data are different jobs

Keeping your data your own also means controlling what leaves the building. Publishing is a deliberate act. New museums start private by default, and Publish copies only the name, description and photos to the public page. Donor details, values and exact locations are never published. Withdraw removes an object from the public page instantly.

Because the open-standards connection covers published objects only, your private working records stay private. Your export is the other direction: the full CSV is for your own safekeeping and moving, while publishing is for the public. Keep those two ideas separate when you explain data policy to your board.

Leaving a system: a calm checklist

Whether you are leaving MuseumBuild or arriving from somewhere else, the steps are the same. Do them before you cancel, not after.

On the MuseumBuild side, you keep access to export your data if you cancel, and nothing is held hostage. Moving in works the same way in reverse: export your existing catalog to CSV, drop it into the Import screen, check how each column maps before anything is created, and everything comes in private until you choose to publish. Plan on an afternoon rather than a project.

• Export the full catalog and the contact list, and date the files.
• Spot-check twenty records across different parts of the collection.
• Confirm object numbers survived exactly as written.
• Record where files are stored and who can open them.
• Keep your photographs in your own files too, wherever they live today.
• Only then cancel or switch, and keep the old export as a permanent archive.

Common questions

Related

• Import your records
• How museum accession numbers work
• Put your museum collection online
• Security
• All guides