Appearance
If your records are simple, web-facing and need to be harvested widely, choose Dublin Core. If they describe library or archival objects that need multiple titles, typed names, genre and hierarchy, choose MODS. The honest answer for most digitisation projects is both: keep MODS as the detailed master record and derive a Dublin Core view for exchange. The decision hinges on how much descriptive nuance your sources carry and who consumes the metadata downstream.
What actually differs between Dublin Core and MODS?
Dublin Core is fifteen flat elements (title, creator, subject, date, and so on) with no nesting. MODS is an XML schema of around twenty top-level elements, each with structured sub-elements and attributes that let you say what kind of title, what role a name plays, and where an item sits in a hierarchy.
| Concern | Dublin Core | MODS |
|---|---|---|
| Structure | 15 flat elements | ~20 elements, deeply nested |
| Name roles | Single string | name + role/roleTerm (author, engraver) |
| Multiple titles | One title | titleInfo typed alternative/translated/uniform |
| Hierarchy | None | relatedItem type="host" |
| Typical use | Harvesting, exchange | Digital library cataloguing |
| Verbosity | Minimal | Moderate |
When should you pick Dublin Core?
Pick Dublin Core when interoperability beats precision. It is the lingua franca of metadata harvesting: OAI-PMH requires simple DC (oai_dc), Europeana and the DPLA both ingest it, and almost every tool reads it. A minimal DC record fits in a few lines:
xml
<oai_dc:dc xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:title>Map of the Parish of St Botolph, 1782</dc:title>
<dc:creator>Hodskinson, Joseph</dc:creator>
<dc:date>1782</dc:date>
<dc:type>Image</dc:type>
<dc:rights>Public Domain Mark 1.0</dc:rights>
</oai_dc:dc>The pitfall: DC's flatness is lossy. "Hodskinson, Joseph (surveyor)" and "Faden, William (publisher)" both collapse into bare dc:creator strings with no role distinction.
When should you pick MODS instead?
Pick MODS when one item carries description that DC cannot hold without losing meaning — typed names, multiple titles, structured dates, host-item relationships. A surveyor and a publisher become separable:
xml
<mods xmlns="http://www.loc.gov/mods/v3" version="3.7">
<titleInfo><title>Map of the Parish of St Botolph</title></titleInfo>
<name type="personal">
<namePart>Hodskinson, Joseph</namePart>
<role><roleTerm type="text" authority="marcrelator">Surveyor</roleTerm></role>
</name>
<originInfo><dateIssued encoding="w3cdtf">1782</dateIssued></originInfo>
<genre authority="aat">maps</genre>
</mods>MODS keeps provenance and roles intact, which matters when researchers query who engraved versus who surveyed a plate.
Can you use both at once?
Yes — this is the recommended default. Author rich MODS records, then generate oai_dc on the fly with the Library of Congress MODS-to-DC stylesheet:
bash
xsltproc MODS3-7_DC_XSLT1-0.xsl record-mods.xml > record-dc.xmlExpose both as separate metadataPrefix values in your OAI-PMH endpoint. Harvesters that only understand DC take the simple view; richer aggregators take MODS. You author once and lose nothing.
What are the common pitfalls?
- Starting flat and regretting it. If you author DC first and later need roles or hierarchy, there is nothing in the record to upgrade from — you re-catalogue. Author rich, derive simple.
- Putting MARC habits into DC. DC has no relator codes; do not stuff them into
dc:creator. - Ignoring
dcterms. Qualified DC (dcterms:created,dcterms:isPartOf) recovers some lost nuance without jumping to MODS. - Forgetting validation. MODS has an XSD; validate against
mods-3-7.xsdbefore ingest or malformed records will break your repository indexer.
Key Takeaways
- Dublin Core = 15 flat elements, maximum interoperability, lossy for complex objects.
- MODS = nested XML, typed names, multiple titles, hierarchy — ideal for digital library cataloguing.
- For OAI-PMH you always need a DC view; MODS can be a second harvest format.
- The default for digitisation projects is author MODS, derive DC via XSLT.
- Qualified Dublin Core (
dcterms) is a useful middle ground before committing to MODS. - Validate MODS against its XSD; never trust unschema'd records into a repository.
- Author rich first: you can always simplify, you cannot un-flatten.
Frequently Asked Questions
Is Dublin Core or MODS better for a digital archive?
MODS is better when you need rich descriptive detail (multiple titles, name roles, hierarchical genres) and your records feed a catalogue. Dublin Core is better when you need broad interoperability and harvesting via OAI-PMH with the least friction.
Can I use both Dublin Core and MODS together?
Yes, and many repositories do. Keep MODS as your richer source-of-truth record and generate a simple Dublin Core view from it with an XSLT crosswalk for harvesting and exchange.
Does Dublin Core support hierarchy and complex names?
No. Dublin Core is a flat set of 15 elements with no nesting, no role qualifiers and no controlled sub-fields, so complex personal names and multi-part titles flatten into a single string.
Is MODS still maintained?
Yes. MODS is maintained by the Library of Congress; MODS 3.7 was released in 2018 and it remains the standard mid-weight descriptive schema between simple Dublin Core and full MARC.
Which should I choose for OAI-PMH harvesting?
OAI-PMH mandates simple Dublin Core (oai_dc) as the baseline format, so you always need a DC view. You can additionally expose MODS as a second metadataPrefix for harvesters that want richer data.