DCAT-AP: EU Data Portal Metadata Profile

What DCAT-AP Is

DCAT-AP (the DCAT Application Profile for data portals in Europe) is a metadata specification that defines how public-sector and research data catalogs across the European Union describe their datasets so that catalogs built by different countries, agencies, and institutions can be harvested and searched together. It is maintained by the SEMIC action (Semantic Interoperability Community) within the European Commission’s Interoperable Europe initiative, and it underpins data.europa.eu, the EU’s central open-data portal, which harvests national and regional catalogs across member states using DCAT-AP as the common exchange format.

For a research administrator or data steward working with a European research-data portal, an institutional open-data platform, or a repository that needs to be discoverable through data.europa.eu or a national equivalent, DCAT-AP is the metadata contract that determines whether a catalog’s records will actually be harvested correctly. CASRAI’s DCAT dictionary entry covers the base W3C vocabulary; this guide covers the EU application profile built on top of it, including the two extensions research-adjacent portals most often encounter: GeoDCAT-AP for geospatial data and StatDCAT-AP for statistical data.

How DCAT-AP Relates to W3C DCAT

An “application profile” in this context is a constrained, more specific version of a general vocabulary: it takes the W3C DCAT Recommendation and narrows it down to a specific, interoperable subset for a specific use case, in this instance cross-border European public-sector data exchange. DCAT-AP does not invent new terms so much as it specifies, for a subset of DCAT’s classes and properties, exactly which ones are mandatory, which are recommended, and which are optional for conformant European data portals, along with additional usage notes, controlled vocabularies, and cardinality constraints that base DCAT leaves open.

DCAT-AP has tracked each major W3C DCAT revision: it originally aligned with DCAT (2014), then DCAT2 (2020), and the current DCAT-AP release aligns with DCAT3 (2024), including DCAT3’s dcat:DatasetSeries class for grouping related, evolving datasets. As of this guide, the current stable release is DCAT-AP 3.0.1, published 27 October 2025 as a bugfix release over 3.0.0 — version numbers and release dates are worth re-checking against the official SEMIC release page before citing them in a compliance document, since the specification is actively maintained and periodically revised.

Structure: Mandatory, Recommended, and Optional Classes

DCAT-AP publishes its conformance requirements as a machine-readable UML model and SHACL shapes, alongside the human-readable specification, so that catalog operators and tooling vendors can validate a given catalog description against the profile automatically. At a structural level, the profile centers on four core classes:

Catalogue (dcat:Catalog) — the catalog itself, the top-level container that lists the datasets and data services it holds.
Dataset (dcat:Dataset) — a collection of data, described at the conceptual level: what it is, who published it, what it’s about, under what conditions it can be accessed or reused.
Distribution (dcat:Distribution) — a specific, accessible representation of a dataset: a downloadable CSV, an API endpoint, a bulk download in a particular format. One dataset commonly has several distributions.
Agent — the organizations and individuals associated with a catalog or dataset, most importantly as publisher and as contact point.

Within these classes, the specification’s conformance tables mark a core set of properties as mandatory for a catalog to be considered DCAT-AP-conformant — broadly, enough to identify what a dataset is (title, description), who is responsible for it (publisher, contact point), and under what terms it can be accessed (access rights). A larger set of properties is marked recommended (theme/category, keywords, temporal and spatial coverage, issued and modified dates, license) because they materially improve discoverability and reuse even though a catalog can technically conform without them, and a further set is optional for information that applies only to some datasets (provenance notes, sampling methodology, frequency of update, and so on). Because the exact mandatory/recommended/optional (MRO) designation for any individual property can shift between minor releases, an institution implementing a DCAT-AP feed should validate against the current release’s own SHACL shapes or conformance table rather than working from a cached summary — including this one.

GeoDCAT-AP: The Geospatial Extension

GeoDCAT-AP extends DCAT-AP to describe geospatial datasets and services in a way that is interoperable with the EU’s INSPIRE directive and the ISO 19115/19119 geographic-metadata standards that INSPIRE geoportals already use. In practice, GeoDCAT-AP is the bridge that lets a national geospatial data infrastructure — built around INSPIRE and ISO metadata — also be harvested by a general-purpose open-data portal built around DCAT-AP, without maintaining two entirely separate metadata records for the same dataset. It reuses DCAT-AP’s core classes and adds geospatial-specific properties (spatial resolution, coordinate reference system, geographic bounding box, and INSPIRE-specific classification metadata) needed to satisfy INSPIRE’s own metadata regulation. It is also maintained under the SEMIC action alongside DCAT-AP itself.

For research data portals, GeoDCAT-AP is most relevant where a dataset carries a genuine geospatial component — environmental monitoring data, geological surveys, spatial epidemiology, remote-sensing outputs — and the depositing institution or national repository is also subject to INSPIRE reporting obligations.

StatDCAT-AP: The Statistical Extension

StatDCAT-AP extends DCAT-AP for describing statistical datasets, adding properties relevant to official statistics that plain DCAT-AP does not capture well: methodology, unit of measure, statistical classification, update frequency tied to a release calendar, and links back to the underlying survey or register the statistics were derived from. It is aimed primarily at national statistical institutes and Eurostat-aligned data portals, but is relevant to any research data portal that catalogs official or survey-derived statistical outputs alongside primary research data.

StatDCAT-AP is currently in active revision toward a version 3.0. Per the SEMIC support centre’s published event schedule, StatDCAT-AP working-group sessions were held on 12 February, 10 March, and 16 April 2026 to review the revision’s scope and iterate on issues raised in prior sessions ahead of a 3.0.0 release, and a draft specification has been circulated for public review since. Because a specification actively under public review can still change before final publication, treat any StatDCAT-AP 3.0-specific property or class name as provisional until the finalized release is published on the SEMIC/Joinup release pages — check the SEMICeu/StatDCAT-AP repository or the Interoperable Europe portal for the current status before citing specifics in an implementation.

Where Research Data Portals Encounter DCAT-AP

A European research institution is likely to meet DCAT-AP in one of a few concrete ways:

National open-data and research portals that harvest into data.europa.eu generally require dataset metadata to be exposed as valid DCAT-AP (or the local national profile layered on top of it, since several member states publish their own further-constrained national application profile of DCAT-AP).
EOSC-connected infrastructure: catalogs feeding into the EOSC Federation are expected to expose DCAT-AP-compatible metadata so that resources can be discovered consistently across the federation, alongside DataCite and other metadata schemas used at the resource-registration level.
Repository software such as CKAN and several DSpace/institutional-repository configurations ship DCAT-AP export plugins, letting an institutional repository generate a conformant feed without hand-authoring RDF.
Geospatial and statistical data offices that need their holdings represented in both a domain-specific system (an INSPIRE geoportal, a national statistics catalog) and a general open-data portal typically rely on GeoDCAT-AP or StatDCAT-AP specifically to avoid double metadata maintenance.

DCAT-AP conformance is generally a technical/metadata-layer requirement rather than a legal one in itself, but it is frequently referenced as an implementation detail within broader open-data policy (for example, national transpositions of the EU’s Open Data Directive) and within specific funder or national research-infrastructure metadata mandates, so “is DCAT-AP required here” is usually a question of which portal or funder policy a given dataset needs to satisfy, not a blanket EU-wide legal mandate on every research dataset.

DCAT-AP and Other Metadata Standards

DCAT-AP is a catalog-and-discovery-layer standard, not a full replacement for dataset-level description standards a repository already uses. It typically sits alongside, rather than instead of, standards like Dublin Core (a simpler, widely reused core element set), the DataCite metadata schema (used for DOI registration metadata), and repository certification frameworks like CoreTrustSeal, which assess a repository’s trustworthiness rather than its catalog syntax. See CASRAI’s guide on how to choose a metadata schema for a dataset for how these layers fit together, and the FAIR Data Principles entry for the broader findability/interoperability framework DCAT-AP conformance supports in practice.

Frequently Asked Questions

Is DCAT-AP the same as DCAT?

No. DCAT is the general-purpose W3C vocabulary; DCAT-AP is a European application profile built on top of it that narrows DCAT down to a specific, more tightly specified subset (with additional mandatory/recommended/optional rules and controlled vocabularies) for cross-border public-sector data exchange in the EU.

Do I need DCAT-AP if my repository already uses Dublin Core or the DataCite schema?

Possibly, depending on where the dataset needs to be discoverable. Dublin Core and DataCite metadata describe a dataset at the resource level; DCAT-AP describes how a catalog exposes its holdings for cross-catalog harvesting. A repository can maintain DataCite metadata for DOI registration and separately expose a DCAT-AP feed (often auto-generated by repository software) so the same dataset is both citable and harvestable into data.europa.eu or a national portal.

What is the difference between GeoDCAT-AP and StatDCAT-AP?

GeoDCAT-AP extends DCAT-AP for geospatial datasets, aligning it with the INSPIRE directive and ISO 19115/19119 geographic metadata standards. StatDCAT-AP extends DCAT-AP for statistical datasets, adding properties for methodology, statistical classification, and release-calendar-driven update frequency, aimed primarily at national statistical institutes and Eurostat-aligned portals.

Is DCAT-AP conformance legally required?

Not as a single, blanket EU-wide legal mandate on all research data. DCAT-AP conformance is typically a technical requirement imposed by a specific portal (to be harvested into data.europa.eu, for instance) or referenced within a national transposition of open-data policy or a specific funder/infrastructure mandate. Whether it applies to a given dataset depends on which portal or policy that dataset needs to satisfy.

Where can I find the current DCAT-AP specification?

The authoritative source is the SEMIC-maintained release page at semiceu.github.io/DCAT-AP, with the underlying issue tracker and machine-readable artifacts (UML model, SHACL shapes) on the SEMICeu GitHub organization. Always check there for the current version before implementing, since the profile is actively maintained.