Open Data Manual › Practical guides › Metadata Standards for Open Data

Metadata Standards for Open Data

By Open Data Manual editors · Published 4 November 2026 · Editorial standard

Metadata is the description that lets people, and software, find a dataset and decide whether to use it. The manual's chapter Make data discoverable explains why catalogues matter; this guide covers the standards that make catalogue records consistent, so that one portal can read another's records and search engines can index them.

Why use a standard at all

A dataset page with a free-text description can be read by a person, but a portal that wants to aggregate thousands of datasets from hundreds of publishers needs the same fields, with the same meaning, in every record. Standards provide that: an agreed list of properties (title, licence, publisher and so on), agreed value types, and in most cases a machine-readable encoding. The payoff is that a dataset described once can appear in a local portal, a national catalogue, a regional aggregator and a search engine without being re-entered.

DCAT: the W3C Data Catalog Vocabulary

DCAT is the W3C vocabulary for describing data catalogues and the datasets in them. Its history:

• DCAT (version 1), a W3C Recommendation from January 2014, produced by the Government Linked Data Working Group;
• DCAT 2, a Recommendation dated 4 February 2020, from the Dataset Exchange Working Group;
• DCAT 3, a Recommendation dated 22 August 2024, which supersedes DCAT 2 without making it obsolete.

The core classes are easy to grasp:

Class	What it describes
dcat:Catalog	A curated collection of metadata about datasets and services (a portal)
dcat:Dataset	A collection of data published by one agent or community
dcat:Distribution	One accessible form of a dataset, such as a CSV download
dcat:DataService	An API or other service providing access to data
dcat:DatasetSeries	A group of related datasets published separately (for example, annual releases)
dcat:CatalogRecord	The catalogue's own record about an entry

DCAT reuses existing vocabularies rather than inventing everything: titles, descriptions, licences and dates come from Dublin Core Terms (dct:title, dct:license, dct:modified), and contact details from vCard. The distinction between a dataset and its distributions is the single most useful idea in DCAT: the same data released as CSV, JSON and an API is one dataset with three distributions, not three datasets.

Application profiles: DCAT-AP and DCAT-US

DCAT is deliberately broad. Application profiles narrow it for a community by choosing which properties are mandatory, which code lists to use and how to encode values.

DCAT-AP (Europe)

DCAT-AP is the application profile for data portals in Europe, maintained under the European Commission's SEMIC programme. National portals in EU member states typically use DCAT-AP or a national extension of it, which is what allows the official EU portal, data.europa.eu, to harvest their records.

DCAT-US (United States)

US federal agencies publish a catalogue file named data.json on their websites, and Data.gov harvests those files. The schema is DCAT-US. In version 1.1, the dataset fields that are always required are title, description, keyword, modified, publisher, contactPoint, identifier and accessLevel, with bureauCode and programCode required for federal agencies. Others, including license, spatial, temporal and distribution, are required where applicable.

DCAT-US 3.0 is a JSON Schema implementation of W3C DCAT 3. It requires fewer fields at schema level (for datasets: title, description, contact point and identifier), with modified moving from required to recommended. Data.gov continues to harvest version 1.1 files while agencies migrate.

Dublin Core

The DCMI Metadata Terms, maintained by the Dublin Core Metadata Initiative, are the general-purpose vocabulary behind much of DCAT. The original fifteen elements (title, creator, subject, description, publisher, contributor, date, type, format, identifier, source, language, relation, coverage, rights) are also published as ISO 15836. On their own they are often too loose for data catalogues, which is why DCAT adds dataset-specific structure on top.

schema.org Dataset for search engines

Search engines read schema.org markup embedded in web pages. Google's Dataset structured data documentation explains which properties it uses for Dataset Search, including name, description, license, creator, distribution (with contentUrl and encodingFormat), temporalCoverage and spatialCoverage. Many catalogue platforms generate this markup automatically from their DCAT records.

Describing the contents: CSV on the Web

DCAT describes a dataset from the outside: what it is, who published it, where to get it. It says little about the columns inside a file. For tabular data, W3C's CSV on the Web Recommendations (December 2015) define a JSON metadata file that declares column names, data types, units and keys. Our guide to CSV vs JSON explains how that file sits alongside the CSV.

A practical minimum record

Whatever standard your portal uses, these fields cover most of what users and aggregators need:

Field	DCAT property	Tip
Title	dct:title	Plain words a searcher would use, not an internal code
Description	dct:description	What, where, when, how collected, known limitations
Keywords / themes	dcat:keyword, dcat:theme	Use the portal's theme list where one exists
Publisher	dct:publisher	The organisation, not an individual
Contact point	dcat:contactPoint	A shared mailbox that outlives staff changes
Identifier	dct:identifier	Stable and unique; FAIR principle F1
Licence	dct:license	A URL, e.g. CC BY 4.0 or CC0
Last modified	dct:modified	ISO 8601 date
Update frequency	dct:accrualPeriodicity	From a controlled list (daily, monthly, annual...)
Coverage	dct:spatial, dct:temporal	Area and period the data covers
Distribution	dcat:downloadURL, dcat:mediaType	One per format; a working direct link

Common mistakes

• Licence missing or written as prose. Aggregators cannot interpret "free to use, please credit us". Use a licence URL; see our guides to CC0 and CC BY 4.0.
• Every file catalogued as a separate dataset. Monthly files of the same series belong in one dataset (or a dataset series) with several distributions.
• Stale modification dates. If modified is set once and never updated, users cannot tell whether the data is current.
• Broken download links. Check distributions automatically and fix or remove dead ones.

Good metadata is also the core of the FAIR data principles: several of the fifteen principles are about nothing else.

Frequently asked questions

What is the main metadata standard for open data catalogues?

The W3C Data Catalog Vocabulary (DCAT). DCAT 3 became a W3C Recommendation on 22 August 2024, following DCAT 2 (February 2020) and the original version (January 2014). National profiles such as DCAT-US and DCAT-AP are built on it.

What is DCAT-US?

The metadata schema used by US federal agencies to describe datasets in their data.json catalogues, which Data.gov harvests. Version 1.1 is in wide use; version 3.0 is a JSON Schema implementation of W3C DCAT 3.

Which metadata fields matter most?

At minimum: title, description, keywords, publisher, contact point, identifier, licence, date last modified, update frequency, and a download or access URL with its format.

How do I make datasets appear in Google Dataset Search?

Add schema.org Dataset structured data to the dataset's web page, or publish through a catalogue that does so. Google documents the supported properties in its Dataset structured data guidelines.

More practical guides

• CSV vs JSON
• FAIR data principles
• The CC0 license
• CC BY 4.0 for data
• Open Database License (ODbL)
• Database rights