What Is MODS and Why Should You Care?

At some point in your metadata journey, especially if you’ve wrangled with Dublin Core or EAD, you may have stumbled across MODS and thought, “That looks nice, but where does it fit?” If you’ve ever tried to make sense of this XML-based schema that promises to be more detailed than Dublin Core but less complicated than MARC, you are not alone.

MODS stands for Metadata Object Description Schema. It was released by the Library of Congress in 2002 as a middle ground between lightweight general-purpose schemas and heavy-duty library standards. It was designed to be more structured than Dublin Core and more readable than MARC. Unlike MARC, which uses numeric tags, MODS uses human-readable XML tags like <titleInfo>, <name>, and <subject>, making it easier to understand and implement. It is flexible enough for libraries, archives, and museums, and it can be used to describe everything from digitized photographs to bibliographic records.

Why MODS Was Created

The early 2000s were a turning point for metadata. Dublin Core had just emerged. EAD and ISAD(G) were gaining traction. Institutions needed better ways to describe and share their digital and analog collections. MODS came into that moment offering a more nuanced approach to description than Dublin Core without the overwhelming complexity of MARC. It supports semantic encoding and was built to be both human-friendly and machine-readable.

MODS is particularly useful for digital content. It can be used to describe single digital objects, born-digital files, or even collections. It is based in XML, so it can be embedded into digital systems or uploaded via spreadsheets. In systems like Preservica and Islandora, MODS is often one of the built-in metadata options.

The Metadata Stack

To understand MODS, it helps to separate three related concepts:

• A metadata schema is the structure you use to describe a resource. MODS is a schema.

• A content standard tells you how to write the information that goes into those fields. DACS is a content standard. So is RDA or AACR2.

• A controlled vocabulary provides the actual terms you use, such as the Library of Congress Subject Headings or the Art and Architecture Thesaurus.

All three of these work together when you describe a collection. MODS gives you the fields. DACS tells you how to fill them in. A controlled vocabulary tells you which words to use.

What MODS Offers

MODS includes 20 top-level elements. These are the big categories of information, like title, creator, date, or format. All but one of them are repeatable, and many of them allow for subelements or attributes to get even more specific. The fields can appear in any order. That means you do not have to follow the strict structure you see in MARC with numbered fields.

Some of the most commonly used MODS fields include:

• titleInfo: Where you record or supply the title.

• name: Used for any personal or corporate creator or contributor, with options to define roles like author, illustrator, or editor.

• typeOfResource: What kind of object it is, like text, image, or object.

• genre: The style or content category, like fiction, animation, or biography.

• originInfo: Where and when it was created or published, including digitization details.

• language: What language is used, including the script if needed.

• physicalDescription: Physical characteristics like size, format, or reformatting notes.

• abstract: A summary of the resource’s content.

• tableOfContents: Used for books, recordings, or anything with a defined structure.

• targetAudience: Intended user group, such as children or specialists.

• note: A flexible field for any other information that does not fit elsewhere.

• subject: Topics, places, people, or time periods covered by the resource.

• classification: Call numbers or codes from formal systems like Dewey or LCSH.

• relatedItem: Links to other collections, items, or records that are connected.

• identifier: Unique codes like accession or catalog numbers. Repeatable if the item is tracked in more than one system.

• location: Where the resource is held physically or digitally.

• accessCondition: How the resource can be accessed or used.

• part: A way to describe a portion of a larger resource, like a chapter or journal issue.

• extension: A field for local or custom data that does not fit into existing fields.

• recordInfo: Administrative details about the metadata record itself, such as who created it or when.

Should You Use MODS?

MODS is not required and is not the right fit for every institution. If you already use Dublin Core and it does what you need, you can stick with it. If you are happy with your MARC records, keep them. But if you need a little more structure and flexibility, especially for digital objects or complex collections, MODS can offer that.

You do not need to implement MODS retroactively. Start using it where it makes sense, and if you decide to adopt it formally, write a local content guide. That way, everyone at your institution has clear guidance on how to use the fields and what values to include. Include examples that are specific to your collection, and specify what standards and vocabularies you expect users to follow. A good local guide makes it easier for student workers, volunteers, and new staff to create consistent records.

Is Anyone Using MODS?

The honest answer is that MODS is not the dominant schema in most institutions. Many people are experimenting with it. Some institutions use it because their systems are built around it. Others adopt it for specific digital projects or because it works better for certain types of records. You might see it in aggregation platforms like the Digital Public Library of America, where MODS can offer more specific encoding than Dublin Core. But it is not replacing other schemas; it is just another tool to consider.

Like every metadata tool, MODS only works if it meets your needs. If it helps you describe your stuff more clearly or manage your records more easily, then it is worth exploring.