Dublin Core

Origin: the 1995 Dublin, Ohio workshop

Dublin Core takes its name from Dublin, Ohio, not the Irish capital. In October 1994, participants from SoftQuad, OCLC, and NCSA (the National Center for Supercomputing Applications), meeting at the 2nd International World Wide Web Conference in Chicago, discussed how hard it already was to find resources on the young Web. That conversation led directly to the OCLC/NCSA Metadata Workshop, held March 1–3, 1995 at OCLC’s headquarters in Dublin, Ohio. Fifty-two invited participants — librarians, archivists, humanities scholars, geographers, and standards specialists from the Internet, Z39.50, and SGML communities — set out to identify a small, cross-domain set of metadata elements simple enough for a non-cataloger to apply to any electronic resource, in contrast to the much larger, discipline-specific schemas (MARC, EAD, TEI headers) already in use in specialist communities. The 15-element set they converged on, refined through several follow-on workshops over the next few years, became the Dublin Core Metadata Element Set (DCMES).

The fifteen core elements

Dublin Core Metadata Element Set, Version 1.1 defines fifteen elements, each optional and repeatable, with no required order:

• Title — the name given to the resource
• Creator — the entity primarily responsible for making the resource
• Subject — the topic of the resource
• Description — an account of the resource (abstract, summary, table of contents)
• Publisher — the entity responsible for making the resource available
• Contributor — an entity responsible for making a secondary contribution
• Date — a point or period of time associated with an event in the resource’s lifecycle
• Type — the nature or genre of the resource
• Format — the file format, physical medium, or dimensions of the resource
• Identifier — an unambiguous reference to the resource within a given context
• Source — a related resource from which the described resource is derived
• Language — the language of the resource
• Relation — a related resource
• Coverage — the spatial or temporal topic, spatial applicability, or jurisdiction of the resource
• Rights — information about rights held in and over the resource

DCMI describes these fifteen as “core” specifically because they are broad and generic — usable across a wide range of resource types — rather than tuned to any one domain. This is the origin of “core metadata” as a general term of art in resource description; see CASRAI’s Core metadata entry for how that broader concept plays out for research datasets specifically, including DataCite’s six mandatory properties as the applied, DOI-registration version of the same idea.

Simple Dublin Core vs. Qualified Dublin Core

Simple Dublin Core is the fifteen unqualified elements used exactly as defined above — one flat, cross-domain vocabulary, each element usable on its own with no sub-structure. It is what most people mean when they say “a Dublin Core record.”

Qualified Dublin Core is the same fifteen elements plus DCMI Metadata Terms — a larger vocabulary, published under the http://purl.org/dc/terms/ (dcterms:) namespace, that adds two kinds of qualifiers on top of the base elements:

• Element refinements narrow an element’s meaning without changing it — for example dcterms:created and dcterms:issued both refine the generic dc:date to a specific point in the resource’s lifecycle.
• Encoding schemes specify a controlled vocabulary or notation for an element’s value — for example dcterms:W3CDTF constrains a date to ISO 8601 format, and the DCMI Type Vocabulary constrains dc:type to a fixed list (Text, Dataset, Image, Software, and so on).

Qualification is governed by the Dumb-Down Principle: a client that doesn’t understand a given qualifier must be able to safely discard it and still get a valid, if less precise, unqualified Dublin Core value. Qualifiers make description more expressive; they are never allowed to change what the unqualified element means. In practice, the dcterms: namespace has become DCMI’s recommended vocabulary generally — including for the fifteen legacy elements themselves, which now have dcterms: equivalents with formal RDF value ranges — while the original http://purl.org/dc/elements/1.1/ namespace remains supported indefinitely for backward compatibility.

Governance: the Dublin Core Metadata Initiative (DCMI)

The workshop series formalized into the Dublin Core Metadata Initiative (DCMI), which today is constituted as a project of the Association for Information Science and Technology (ASIS&T), a U.S. 501(c)(3) nonprofit. DCMI is governed through a Governing Board (organizational oversight and direction), a Usage Board (reviews and maintains the specifications and the term vocabulary itself), and a Directorate (day-to-day operations). DCMI describes its own role as pursuing de facto standardization — building consensus and open, freely reusable specifications — while remaining open to further formal (de jure) standardization through bodies like ISO and NISO, provided it doesn’t restrict open access to the vocabulary.

Standardization status: ISO, ANSI/NISO, and IETF

Dublin Core is unusual among metadata vocabularies in having been formally standardized by three separate bodies, each maintaining its own version lineage:

• IETF: originally published as RFC 2413 (1998), superseded by RFC 5013 (2007), “The Dublin Core Metadata Element Set.”
• ANSI/NISO: first published as Z39.85-2001, revised as Z39.85-2007, and currently ANSI/NISO Z39.85-2012, “The Dublin Core Metadata Element Set.”
• ISO: first published as ISO 15836:2003, revised as ISO 15836:2009, then split into two parts — ISO 15836-1:2017 (Part 1: Core elements, which cancels and replaces the 2009 edition) and ISO 15836-2:2019 (Part 2: DCMI Properties and classes, extending the fifteen core elements with roughly forty additional properties and twenty classes drawn from DCMI Metadata Terms).

All three tracks describe the same fifteen-element core; the ISO Part 2 and current DCMI Metadata Terms specification (a DCMI Recommendation, last revised 2020-01-20) are what formally standardize the broader Qualified Dublin Core vocabulary beyond the original fifteen.

Worked examples

• A university institutional repository record for a working paper carries dc:title (“the paper’s title”), dc:creator (author name), dc:date (deposit date), dc:type (“Text”), dc:format (“application/pdf”), dc:identifier (a handle or DOI), dc:subject (keywords), and dc:rights (a licence statement) — a Simple Dublin Core record, and the exact element set most OAI-PMH repositories are required to expose for harvesting, since OAI-PMH’s oai_dc format is Simple Dublin Core by definition.
• The same repository, using Qualified Dublin Core, could refine that record with dcterms:dateAccepted and dcterms:dateSubmitted instead of one generic dc:date, and constrain dc:language’s value using the ISO 639 encoding scheme — adding precision a harvester that only understands Simple Dublin Core can still safely read as plain, unqualified dates and a plain language string.

Counter-example

A catalog record that stores similar information — an author field, an upload date, a free-text description — under ad hoc, locally invented field names (author_name, upload_ts, blurb) with no mapping to the Dublin Core element set or namespace is not a Dublin Core record, even though the underlying information is comparable. Nor is a full MARC bibliographic record or an EAD finding aid Dublin Core on its own — both are richer, library/archives-specific schemas that predate or sit alongside Dublin Core; a MARC record only becomes Dublin Core once it is deliberately crosswalked (mapped field-by-field) down to the fifteen-element set, which is itself a common, lossy step when aggregating heterogeneous catalogs for cross-repository search.

Related CASRAI content

For the general concept of a minimal, discoverability-enabling field set (of which Dublin Core is the classic example), see Core metadata. For the applied, DOI-registration version of the same idea for research datasets, see DataCite metadata schema. For the harvesting protocol that made oai_dc (Simple Dublin Core) a de facto interoperability baseline across repositories, see OAI-PMH. For discipline-specific schemas built on the same “core plus extension” pattern, see Darwin Core (biodiversity occurrence records), Ecological Metadata Language (EML), and MODS (a richer library schema that, unlike Dublin Core, retains structured sub-elements). For the decision framework on choosing between a general schema like Dublin Core and a richer discipline-specific one, see the guide How to Choose a Metadata Schema for a Dataset. This term sits within CASRAI’s Research Data Management (RDM) cluster.

References

• Dublin Core Metadata Initiative, “DCMI History” (dublincore.org/about/history/) and “About DCMI” (dublincore.org/about/).
• Dublin Core Metadata Initiative, “Dublin Core™ Metadata Element Set, Version 1.1: Reference Description” (dublincore.org/specifications/dublin-core/dces/).
• Dublin Core Metadata Initiative, “DCMI Metadata Terms”, 2020-01-20, DCMI Recommendation (dublincore.org/specifications/dublin-core/dcmi-terms/).
• IETF RFC 5013, “The Dublin Core Metadata Element Set” (2007), superseding RFC 2413 (1998).
• ANSI/NISO Z39.85-2012, “The Dublin Core Metadata Element Set” (niso.org).
• ISO 15836-1:2017, “Information and documentation — The Dublin Core metadata element set — Part 1: Core elements,” and ISO 15836-2:2019, Part 2: DCMI Properties and classes (iso.org).