Getting Started with Dublin Core: Fifteen Fields That Make Things Findable

Here is a file on my desktop called IMG_4471.jpg. What is it? You have no idea. Neither do I, and I took it.

Metadata is data about data. In plain language, it is the information that lets something be found, understood, and cared for. A digital file without metadata is not an archive item. It is a lost object with a filename. Dublin Core is the most common way digital humanities projects give those lost objects a name, a date, and a home.

A very short history #

The name comes from Dublin, Ohio, not Ireland, which disappoints everyone who hoped for a pub story. In March 1995, OCLC and the National Center for Supercomputing Applications hosted a workshop there, and the fifty-two people in the room included librarians, archivists, and humanities scholars. So yes, humanists were in on this from day one. That workshop produced thirteen elements, two more followed, and the fifteen elements were first standardized in 1998 as IETF RFC 2413, then published as ANSI/NISO Z39.85 and ISO 15836. The NISO version calls itself, with admirable modesty, a set of "fifteen metadata elements for resource description in a cross-disciplinary information environment." That cross-disciplinary part is the point. A library, a museum, and a grad student with a spreadsheet can all speak it.

The fifteen elements #

Every element is optional and every element can repeat. Here they are in plain English, grouped by the question they answer.

What is it?

• Title. The name of the thing. If it has no title, write a descriptive one. "Hymnal page, 'A Mighty Fortress,' annotated by Ruth Johnson" beats "image 004."
• Description. What a visitor is seeing and why it matters. This is interpretation, so keep it clear and honest.
• Subject. The topic. Use words a searcher would use.
• Type. The nature or genre. The standard recommends a controlled list like the DCMI Type Vocabulary, so use words like Text, StillImage, Sound, or Dataset.
• Format. The file format, physical medium, or dimensions, such as image/jpeg or "8 x 10 in."

Who made it?

• Creator. The person or organization primarily responsible.
• Contributor. Anyone else who helped, such as a translator, an editor, or the person who scanned it.
• Publisher. Who made it available.

When and where?

• Date. A date associated with the item. Use YYYY-MM-DD when you can. If you only know a range, give a range. If you are estimating, say "circa."
• Coverage. The spatial or temporal topic, or the jurisdiction where it is relevant. This is where "Nashville, Tennessee" or "1968 to 1974" goes.

How do I find and use it?

• Identifier. A unique, unambiguous reference, such as a URL, a DOI, or your accession number.
• Language. Use a standard code like en or es.
• Rights. What people may do with it. "Copyright status unknown" is honest. "Found it on Google" is not a rights statement. It is a confession.

How does it connect?

• Source. A resource this one is derived from. The scan's source is the physical newsletter.
• Relation. Any other related resource, like the other issues in the series.

The one confusing bit: dc versus dcterms #

You will see two prefixes in the wild, dc: and dcterms:. The original fifteen live in the dc: namespace. The larger, more precise set lives in DCMI Metadata Terms under dcterms:. The names match, but the dcterms: versions have defined domains and ranges, which is a fancy way of saying computers understand them better. DCMI encourages people to use dcterms:.

In practice: if you use Omeka Classic or Omeka.net, you get the fifteen elements as fields, and you just fill them in. If you use Omeka S, Dublin Core Terms supplies 55 properties, including handy refinements like dcterms:created and dcterms:extent. Same idea, more drawers in the dresser.

How to write a good record #

Let's describe that IMG_4471.jpg. For this exercise, pretend it is a photo of a church bulletin. The congregation and details below are invented for practice.

Element	Value
Title	Easter Sunday bulletin, Grace Lutheran Church
Creator	Grace Lutheran Church
Date	1972-04-02
Description	Four-page order of worship listing hymns, readings, and a notice about the parish food pantry.
Subject	Easter; Lutheran Church; Worship programs; Food banks
Type	Text
Format	image/jpeg
Language	en
Coverage	Nashville, Tennessee
Rights	Copyright status unknown. Shared with permission of the congregation.
Source	Original paper bulletin held in the church office
Identifier	glc-1972-001

Notice four habits. Do not guess. Expand every acronym. Separate repeated subjects with a semicolon or a new field. Write for a stranger.

Also notice what subjects do. Subject terms make arguments. Older headings sometimes use harmful language for people and communities. When historical wording matters, record it with a note, and add respectful terms so that the harmful word is never the only way in.

Dublin Core outside of Omeka #

You do not need Omeka to use Dublin Core. Three easy places to practice:

1. A spreadsheet. Make one column per element and one row per item. Tools like CollectionBuilder can turn a metadata spreadsheet into a full collection website.
2. Your blog's front matter. The title, date, description, and tags at the top of this post are basically Title, Date, Description, and Subject wearing a trench coat.
3. Your HTML. You can expose metadata to machines. I wrote about this in my post on FAIR signposting and metadata JSON in Eleventy.

Why this matters for DH #

Metadata is a choice. Every field reflects a decision about what counts, who gets credit, and how someone will find this later. It is a scholarly act, not a clerical chore. Good Dublin Core is how a newsletter from 1972 reaches a researcher in 2072.

Next week we take a detour to the tildeverse, where people still build tiny websites by hand on shared computers. Until then, open a spreadsheet, pick one object you own, and write a fifteen-field record for it. Then rename that file. Please. IMG_4471.jpg deserves better.