Dublin Core Metadata Record: Worked Example

A Dublin Core metadata record is easier to understand from a completed example than from the element list alone. This guide walks through a single, fully filled-out record — all fifteen core elements populated for one dataset — showing what each element is actually for, what a cataloger typically puts in it, and how the same information looks in Simple Dublin Core versus Qualified Dublin Core (dcterms:). For the formal definition of each element and Dublin Core’s standardization history (ISO 15836, ANSI/NISO Z39.85, IETF RFC 5013), see CASRAI’s Dublin Core dictionary entry; for choosing between Dublin Core and a richer, discipline-specific schema, see How to Choose a Metadata Schema for a Dataset.

Illustrative example, not a real dataset. The dataset, author, institution, and identifiers below are invented for teaching purposes only. They are not attributed to any real repository deposit, researcher, or institution. Use this page to understand the shape and content of a correctly filled-out record, not to find or cite an actual dataset.

The scenario

A research team has collected soil moisture sensor readings from a field site over a two-year period and is depositing the cleaned dataset in a repository that exposes metadata as Simple Dublin Core over OAI-PMH — the most common real-world situation in which a researcher or data curator will actually see a raw Dublin Core record, since oai_dc is, by definition, Simple Dublin Core.

The complete record: all fifteen elements

Each row below shows the element, an example value for the fictional dataset, and a short note on what actually belongs in that element — the fifteen elements are the same ones defined in DCMI’s Dublin Core Metadata Element Set, Version 1.1.

Element	Example value	Note
Title	Soil Moisture Readings, Site 4, 2024–2025	A name a human would recognize the resource by — specific enough to distinguish it from other datasets in the same series.
Creator	Alvarez, Priya M.	The entity primarily responsible for making the resource — usually a person’s name in “Family, Given” form, or an organization name; repeatable for multiple creators.
Subject	soil moisture; hydrology; environmental monitoring	Topic keywords or a controlled-vocabulary term (e.g. from a thesaurus); repeatable.
Description	Hourly volumetric soil moisture readings from twelve sensors at Site 4, collected January 2024 through December 2025, with sensor calibration logs.	An abstract, summary, or table of contents — enough for someone to judge relevance without downloading the files.
Publisher	Example Research Data Repository	The entity responsible for making the resource available — typically the repository, not the researcher’s home institution.
Contributor	Osei, David T. (sensor calibration)	An entity that made a secondary contribution — distinct from a Creator; some implementations note the role in free text, as here.
Date	2026-01-15	A point or period of time associated with an event in the resource’s lifecycle — commonly the deposit or publication date; DCMI recommends the `W3CDTF`/ISO 8601 profile (`YYYY-MM-DD`).
Type	Dataset	The nature or genre of the resource — DCMI recommends drawing this from the fixed DCMI Type Vocabulary (Dataset, Text, Image, Software, and so on) rather than free text.
Format	application/zip (CSV files inside)	The file format, physical medium, or dimensions — a MIME type is the common convention for digital resources.
Identifier	https://doi.example/10.5072/example.98213	An unambiguous reference to the resource — ideally a resolvable persistent identifier such as a DOI, not just an internal database key.
Source	Derived from raw logger output archived internally as SITE4-RAW-2024-2025	A related resource the described resource is derived from — used here to point back to the unprocessed source data.
Language	en	The language of the resource (its documentation and any textual content) — DCMI recommends an ISO 639 code rather than a spelled-out language name.
Relation	Is referenced by: https://doi.example/10.5555/example-journal-article-2026	A related resource — commonly used to link a dataset to the paper that cites it, or to a prior version.
Coverage	Site 4 field station; January 2024–December 2025	Spatial or temporal scope — where and/or when the data was collected, as distinct from the Date element, which records an event in the record’s own lifecycle.
Rights	CC-BY-4.0 (https://creativecommons.org/licenses/by/4.0/)	Information about rights held in or over the resource — DCMI recommends identifying a license by a resolvable URI, not just a name.

The same record as Simple Dublin Core XML (oai_dc)

This is the format an OAI-PMH-compliant repository is required to expose for every record, since oai_dc is Simple Dublin Core by definition:

<oai_dc:dc xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"
           xmlns:dc="http://purl.org/dc/elements/1.1/">
  <dc:title>Soil Moisture Readings, Site 4, 2024-2025</dc:title>
  <dc:creator>Alvarez, Priya M.</dc:creator>
  <dc:subject>soil moisture</dc:subject>
  <dc:subject>hydrology</dc:subject>
  <dc:subject>environmental monitoring</dc:subject>
  <dc:description>Hourly volumetric soil moisture readings from twelve sensors at Site 4, collected January 2024 through December 2025, with sensor calibration logs.</dc:description>
  <dc:publisher>Example Research Data Repository</dc:publisher>
  <dc:contributor>Osei, David T.</dc:contributor>
  <dc:date>2026-01-15</dc:date>
  <dc:type>Dataset</dc:type>
  <dc:format>application/zip</dc:format>
  <dc:identifier>https://doi.example/10.5072/example.98213</dc:identifier>
  <dc:source>SITE4-RAW-2024-2025</dc:source>
  <dc:language>en</dc:language>
  <dc:relation>https://doi.example/10.5555/example-journal-article-2026</dc:relation>
  <dc:coverage>Site 4 field station; 2024-01/2025-12</dc:coverage>
  <dc:rights>CC-BY-4.0 (https://creativecommons.org/licenses/by/4.0/)</dc:rights>
</oai_dc:dc>

Simple vs. Qualified Dublin Core, and what changes in the record

Simple Dublin Core is exactly the flat, fifteen-element record above — each element used once or repeated, with no sub-structure or vocabulary constraint on the value. It is what most people mean by “a Dublin Core record,” and it is the version every OAI-PMH repository must expose.

Qualified Dublin Core adds two things on top, both defined in DCMI Metadata Terms under the http://purl.org/dc/terms/ (dcterms:) namespace: element refinements, which narrow an element’s meaning without changing it, and encoding schemes, which constrain a value to a controlled vocabulary or notation. Applied to the same record:

<dcterms:created>2024-01-01</dcterms:created>
<dcterms:issued>2026-01-15</dcterms:issued>
<dc:language xsi:type="dcterms:ISO639-2">eng</dc:language>
<dc:type xsi:type="dcterms:DCMIType">Dataset</dc:type>
<dcterms:license>https://creativecommons.org/licenses/by/4.0/</dcterms:license>

Here dcterms:created and dcterms:issued replace the single generic dc:date with two more specific dates — when the data collection period began and when the record was published — and dcterms:license replaces the free-text dc:rights value with a property built specifically to identify a license document, distinct from a general rights statement (see CASRAI’s guide on describing dataset reuse rights for why dc:rights, dc:license, and dc:accessRights are not interchangeable). This is governed by DCMI’s Dumb-Down Principle: a system that only understands Simple Dublin Core must still be able to read dcterms:created as an unqualified date and safely ignore the refinement — qualification adds precision, it never changes what the base element means.

Common mistakes when filling out a record

Putting the collection date in Coverage and the deposit date in Date, or vice versa. Date records an event in the resource’s own lifecycle (created, issued, modified); Coverage records the spatial or temporal scope of what the resource is about. A dataset collected in 2024–2025 but deposited in 2026 needs both, correctly separated.
Leaving Identifier as an internal filename or database key. A resolvable, persistent identifier (a DOI, a handle) is what actually lets the record be cited and found again outside the originating system.
Using free text for Type instead of the DCMI Type Vocabulary. “Dataset,” “Text,” “Image,” and “Software” are recognized values; an invented term like “Research output” breaks interoperability with harvesters expecting the controlled list.
Naming a license in Rights without a version or resolvable URI. “CC-BY” alone is ambiguous about which version’s terms apply — state the version and link to the actual license text, or use dcterms:license for this purpose specifically.
Skipping Relation. It is optional, but it is the field that connects a dataset to the paper that cites it or to a prior version — omitting it makes that connection invisible to anyone who only has the metadata record.

Frequently asked questions

Do all fifteen Dublin Core elements have to be filled in?

No. All fifteen elements are optional and repeatable in the Dublin Core Metadata Element Set — there is no mandatory subset in the specification itself. In practice, a repository or funder mandate will often require a working minimum (Title, Creator, Date, Identifier, Rights are the most commonly enforced) even though DCMI itself does not mandate any of them.

What does a Dublin Core record look like in JSON instead of XML?

Dublin Core is commonly expressed as XML (the format OAI-PMH requires) but the same fifteen elements can equally be expressed as flat JSON key-value pairs, or as RDF/JSON-LD using the dc: or dcterms: namespace URIs as property names — the element set itself is serialization-independent; DCMI does not mandate one encoding.

Is a Dublin Core record the same as a DataCite record?

No. They are different, though related, schemas. Dublin Core’s fifteen elements are broader and older; the DataCite Metadata Schema is purpose-built for DOI registration, with six mandatory properties (Identifier, Creator, Title, Publisher, PublicationYear, ResourceType) that map closely, but not one-to-one, onto Dublin Core equivalents. Many repositories generate both from a single deposit-time form. See CASRAI’s Core metadata entry for how the two relate.

Where would I actually see a raw Dublin Core record like this?

Most researchers never see the XML directly — the repository generates it behind a deposit form and exposes it through OAI-PMH for harvesters like BASE, CORE, and national aggregators to consume. It becomes visible if you query a repository’s OAI-PMH endpoint directly (a GetRecord or ListRecords request with metadataPrefix=oai_dc) or inspect a self-hosted institutional repository’s raw metadata export.

Related CASRAI resources

Dictionary: Dublin Core — the full standard definition, governance, and standardization history
Dictionary: Core metadata
Dictionary: OAI-PMH
Dictionary: DataCite metadata schema
Guide: How to Choose a Metadata Schema for a Dataset
Guide: How to Describe Reuse Rights and Permissions for a Shared Dataset
Guide: How to Cite a Dataset
Pillar: Research Data Management