DCAT-AP and data catalogues: metadata that travels

DCAT, the Data Catalog Vocabulary, is the World Wide Web Consortium (W3C) standard for describing datasets and data services in a catalogue. DCAT-AP is the European application profile of it: it says which properties public data portals must fill in and which shared code lists to use. Together they let a ministry's or a city's dataset records be collected into national portals and into data.europa.eu, so people can search public data from across Europe in one place.

DCAT: the W3C standard for data catalogues

DCAT version 3 became a W3C Recommendation on 22 August 2024¹. The vocabulary was first standardised in 2014, and DCAT 2 followed as a Recommendation on 4 February 2020¹. Its purpose is to make metadata from many catalogues easy to consume and aggregate, so that datasets can be published in a decentralised way and still be found through federated search¹.

The core of DCAT is a small set of classes¹:

• Catalog: a collection of metadata records about datasets, data services or other resources;
• Dataset: a collection of data published or curated by a single agent or community;
• Distribution: an accessible form of a dataset, such as a downloadable file;
• Data service: operations available through an API (application programming interface) that give access to datasets or data processing;
• Dataset series: separately published datasets that share characteristics, added in version 3 along with properties for versioning.

The key idea, present since 2014, is the distinction between a dataset as an abstract idea and a distribution as one manifestation of it¹. A council's bus stop data is one dataset, whether it is offered as CSV (comma-separated values), JSON (JavaScript Object Notation) or a map service.

DCAT-AP: the European application profile

DCAT-AP is maintained by the SEMIC action of Interoperable Europe and "provides a minimal common basis within Europe to share Datasets and Data Services cross-border and cross-domain"². The first version was released in September 2013, and version 3.0.1, aligned with DCAT 3, has the status of a SEMIC Recommendation published on 27 October 2025². Like other application profiles, it reuses existing terms and sets which are mandatory, recommended or optional².

Those labels have precise meanings. A sender must provide mandatory properties, should provide recommended ones if the information is available and may provide optional ones, while a receiver must be able to process all three². It sets no rules on how systems are built, beyond exchanging metadata in RDF (the Resource Description Framework) or in a format that converts unambiguously into it². Sectors and countries build on it in turn: DCAT itself cites GeoDCAT-AP, a geospatial extension, and national profiles such as Italy's DCAT-AP_IT and Norway's DCAT-AP-NO¹.

What a dataset, distribution and data service record contains

Source for the table: DCAT-AP 3.0.1². Titles, descriptions and keywords must carry a language tag, and the EU's data theme vocabulary is the mandatory code list for classifying datasets by theme². Where a file can only be reached through a web page, DCAT says that page should be repeated as the distribution's access URL¹.

How catalogues federate into data.europa.eu

data.europa.eu, managed by the Publications Office of the European Union, provides access to open data from international, EU, national, regional, local and geographic data portals, and replaces the earlier EU Open Data Portal and European Data Portal³. It collects the metadata of public data published across Europe, and it publishes instructions for portals that want to be harvested³. It also says it will report errors it finds back to the owners of the source catalogues³. Each record carries what the original publisher supplied, so reusers are advised to check reuse terms with that publisher³.

A typical chain runs from a local or national body's own catalogue, through the national portal, to the European portal. Every step depends on records that keep the same identifiers and meaning, which is why DCAT-AP fixes the shared code lists, a basic condition of semantic interoperability. Under the rules on high-value datasets, publishers must also flag those datasets as high-value in their metadata⁶.

How metadata quality is checked

data.europa.eu runs a Metadata Quality Assessment (MQA) on the metadata it harvests, each time it harvests⁴. The current methodology checks datasets, distributions and data services against DCAT-AP 3: whether properties are present, whether controlled vocabularies are used, and whether selected links actually work⁴. Mandatory properties carry more weight than recommended ones, and recommended more than optional⁴.

The assessment has clear limits. It does not judge whether the data itself is correct, complete or legally reusable, only the metadata that describes it⁴. For the data, W3C's Data on the Web Best Practices asks publishers to provide metadata for both people and software, including licence, provenance, quality and version information⁵.

Common mistakes in publishing metadata

• One record per file. Publishing the CSV and the JSON as two datasets hides that they hold the same data; DCAT expects one dataset with two distributions¹.
• Dead or redirected links. In the current MQA only a successful HTTP 2xx response counts as accessible⁴.
• Licences in local wording. A 2023 assessment of data.europa.eu found different representations of the same licence, so DCAT-AP recommends the Publications Office's licence vocabulary where national law allows².
• Free-text formats. The MQA checks whether format and media type values come from the controlled vocabulary⁴.
• Stopping at the mandatory fields. The MQA assumes that mandatory fields alone are not enough for high-quality metadata⁴.
• No version or update information. Without a version number or date, reusers cannot tell which release they hold⁵.
• Duplicates. When a dataset is harvested by more than one route, DCAT points to DCAT-AP guidance on telling the authoritative record apart from copies¹.