Skip to main content

Metadata Standards

A metadata standard is a common language of description. A catalog serves its records so that another portal, a search engine or a program can understand them. Your own set of fields is understood only by those who have read your instructions.

The main conclusion of this chapter: take the language the recipient already reads, and often two languages at once. A federation reads its country's DCAT profile, a search engine reads schema.org markup on the page, DOI registration reads the DataCite schema. These languages describe the same dataset and do not replace one another. A draft of the next version and "JSON loosely based on DCAT" are no good for exchange.

How a platform serves the file and which profile it enables by default is in the chapter on export. Which fields to fill in so that the dataset can be used is in the chapter on metadata completeness. Here: which language for which catalog, and how to recognise it from a file.

Describing a dataset versus structuring data​

Standards around data come in two kinds, and they are often confused.

A metadata standard describes a dataset from the outside: what it is, who the publisher is, what period it covers, where to download it, on what terms. A catalog, an aggregator or a search engine reads it. DCAT, DataCite, ISO 19115 and schema.org are metadata standards.

A data standard describes what is inside the file: which columns or fields, what they mean, how values are encoded. A program that processes the data itself reads it. OCDS for procurement, GTFS for timetables and Darwin Core for species observations are data standards. They are covered in the chapter on what is published.

A catalog always needs the first kind when someone outside harvests its descriptions. It needs the second when the sector has one: a procurement dataset in OCDS is immediately understood by contract analysis programs, while a home-grown CSV about contracts has to be parsed anew by everyone. In DCAT, the link between a record and a file standard is recorded with the dct:conformsTo property. A column dictionary is a separate task, covered in the section on the data dictionary.

Some standards do both jobs. SDMX describes both the indicator and the structure of the series. DDI describes both the survey and its variables. Croissant describes both a machine learning dataset and its files with fields. STAC describes both an image collection and individual files.

If you do not know the right standard, look it up in a standards directory: FAIRsharing for science, the Data Standards Directory for government data, the data.gov list for the US.

Four layers that get mixed up​

When people say "we support DCAT", four different things get mixed up. Until they are separated, you cannot tell whether a dump will pass validation.

LayerWhich question it answersExample
Vocabularywhat a field meansDCAT, schema.org, DataCite, ISO 19115
Profilewhich fields are mandatory and which list a value comes fromDCAT-AP, DCAT-US, GeoDCAT-AP
Controlled vocabularywhich exact value may be writtendata theme, licences, language codes
Serialisation and protocolin which file the answer arrives and how to ask for itJSON-LD, Turtle, XML; OAI-PMH, CSW

The vocabulary sets the meaning. DCAT says that a catalog has datasets, a dataset has distributions, and a distribution has a link to a file. A profile narrows the vocabulary for a country or sector: it keeps the needed fields, marks them mandatory or recommended and ties them to controlled vocabularies. DCAT-AP and DCAT-US are profiles of the same DCAT, not two different languages. A national profile, such as the Italian DCAT-AP_IT or the Swiss DCAT-AP-CH, sits on top of DCAT-AP and adds its own fields.

A serialisation is a file. The same DCAT description can be served as Turtle text, XML or JSON-LD. For a person there is no difference; for a program there is: it asks for the right form with an Accept header or takes an address with the right extension. A protocol is a way to query a catalog: OAI-PMH, CSW, OGC API Records. A single CSW can answer with both an ISO 19115 record and a DCAT description, if the software supports it. More on ways of serving in the chapter on export.

The practical consequence follows. A portal can honestly serve DCAT and still fail the validator of the profile a harvester expects. On 13 October 2026 the data.gov.gr dump was in the DCAT-AP 3 profile, and the DCAT-AP 3.0.1 validator found two errors: the file format was written as the word "CSV" rather than as a link to a controlled vocabulary, and the checksum had no algorithm specified. The analysis is in the chapter on export.

What to take as the basis​

CatalogWhat to serve outwardsWhat to rely onWhom this does not cover
Open data portalthe country's profile and schema.org on the pageDCAT-AP 3.0.1 in the EU; DCAT-US 3.0 in the US; in Russia, the "passport" from methodological recommendations 4.0a search engine does not read DCAT alone, a harvester does not read page markup alone
GeoportalISO 19115; for an open data portal, GeoDCAT-AP as wellISO 19115, in the EU INSPIRE and GeoDCAT-AP 3.1.0; image files: STACa layer record does not replace a description of files, STAC does not replace the country's infrastructure
Research repositoryDataCite for DOIs, Dublin Core over OAI-PMH, schema.org on the pageDataCite 4.7; to transfer a folder of files, RO-Cratea DOI is not registered with a DCAT record
Indicator catalogSDMX for partners; StatDCAT-AP if tables must reach an open data portalSDMX 3.1, in practice often still 2.1; tables in the browser: JSON-statSDMX does not make a dataset findable in Google Dataset Search
Microdata catalogDDI per survey and schema.org on the pageDDI Codebook 2.5; the new 2.6 since 15 April 2026DDI does not replace access conditions or DOIs
ML cataloga card for people and Croissant for programsCroissant 1.1 of 29 January 2026; platforms in 2026 still serve 1.0Croissant does not describe an indicator and does not replace a licence
Vocabulary registrySKOS; for data elements, ISO/IEC 11179SKOS; ISO/IEC 11179-3:2023a glossary does not replace a dataset catalog

Two languages at once is normal work, not a fallback. A catalog's internal form can be richer than the profile: your own editorial fields stay with you. What goes outwards is the profile the harvester named.

DCAT and profiles​

DCAT is the W3C vocabulary for data catalogs. The first recommendation came out on 16 January 2014, the second on 4 February 2020, the third on 22 August 2024. Version 3 describes a catalog, a dataset, a distribution, a data service, a dataset series and a catalog record. It introduced series of separately published datasets and version properties, including a file checksum. How these parts look on a live record is analysed in the chapter on catalog anatomy.

DCAT itself declares almost nothing mandatory. Obligation appears in the profile. That is why "we have DCAT" does not tell you whether data.europa.eu or data.gov will accept the file.

ProfileFor whomStatus as of October 2026
DCAT-AP 3.0.1European portals and data.europa.eua SEMIC recommendation of 27 October 2025. The 3.0.2 draft of 17 June 2026 has not yet become a recommendation
National profiles on top of DCAT-APa single country's portalfollow the version the national harvester checks. Examples: DCAT-AP_IT and DCAT-AP-CH
DCAT-US 3.0US federal agencies, the data.json filepublished 1 May 2026. data.gov continues to harvest version 1.1 while agencies migrate
DCAT-AP HVDhigh-value datasets in the EUrelease 3.0.0, October 2024, on top of DCAT-AP
GeoDCAT-AP 3.1.0translating an ISO 19115 record into DCATa SEMIC recommendation of 16 February 2026, aligned with DCAT-AP 3.0.1
StatDCAT-APstatistical tables on an open data portalthe current version is 1.0.1 (2019). Version 3.0.0 has been a working draft since 10 June 2026
HealthDCAT-APhealth data catalogs for the EHDSa European Commission draft; release 7, May 2026. The number has already shifted within the same year, so take the latest release
mobilityDCAT-AP 3.0.0national access points for transport dataa NAPCORE recommendation on top of DCAT-AP 3.0.0, not yet on top of 3.0.1

A sector profile is not run as a second catalog. It is produced by translating the description the sector already uses. That is what GeoDCAT-AP is for: the geoportal keeps an ISO 19115 record, and the open data portal reads it as DCAT. Likewise, StatDCAT-AP exists so that a statistical office's tables appear among open data without replacing SDMX.

In DCAT-AP 3.0.1 the mandatory dataset fields are the title and description, while the licence lives on the distribution and is not named as mandatory. For people, the licence, update date and period matter more than this minimum. The full table of mandatory and recommended fields is in the chapter on metadata completeness.

Data spaces publish their catalog in DCAT and record usage conditions in ODRL: who may take the data and for what. The description remains ordinary DCAT even when the file itself is closed. How exchange works is in the chapter on other catalog types.

A passport instead of DCAT​

In Russia, open data descriptions are defined not by DCAT but by methodological recommendations version 4.0. They were approved by minutes No. 49pr of the presidium of the Government Commission on Digital Development of 12 December 2024. The unit of description is the dataset "passport": identifier, title, description, owner, responsible person and their contacts, a link to the file, format, publication, modification and currency dates, keywords, links to data versions and structures.

The machine-readable passport for parsing someone else's site is one file for the whole list: meta.csv, meta.xml or meta.json. The CSV requirements name four columns: property, title, value and format. The version of the recommendations is recorded in the standardversion field. The data file and the structure file sit next to the passport. On government websites built on Gosweb, each dataset has three CSVs: the passport, the structure and the data. How such sections work is in the chapter on open data portals.

The sample in the same section has fallen behind the requirements. The reference meta.csv contains only the property and value columns and links to the old address of standard 3.0, http://opendata.gosmonitor.ru/standard/3.0, although the cover says version 4.0. Separately, in the section on RDFa, the recommendations advise marking up HTML with the schema.org or Dublin Core vocabulary. Page markup and the passport are not brought together into one profile in the document.

The practical conclusion. The passport is read by the Russian portal and its page parser. data.europa.eu, data.gov and Google Dataset Search do not read it. If datasets only need to be found inside that system, the passport is enough. If someone else must find them, schema.org on the page is added to the passport, along with the DCAT profile a specific harvester has named.

The other languages​

schema.org/Dataset is markup in a dataset's HTML page, usually as a JSON-LD block. Search engines read it. Google asks for a name and a description of 50 to 5,000 characters, and calls the licence, author, period and territory recommended. Markup describes one dataset at a time and does not replace a file of the whole catalog. A page that a script draws in the browser is often empty for a robot. How to check this is in the chapter on discoverability.

ISO 19115 describes spatial data: extent, coordinate system, quality, constraints. A record is written to a file per ISO 19139 or ISO 19115-3: in XML this shows in the gmd: and mdb: prefixes. INSPIRE says how a European public authority must serve such a record. Satellite images and other spatial files are described by STAC: a collection has thousands of files, each with its own date and territory. More in the chapter on geoportals.

Dublin Core is a short set of fields: title, creator, date, subject, rights. Research repositories serve it over OAI-PMH, and almost every archive understands it. DataCite is more detailed and is needed to register a DOI. The current schema is 4.7 of 3 March 2026. The identifier, creator, title, publisher, year and resource type are mandatory. A licence is optional in the schema: its absence does not prevent getting a DOI, but it does prevent a person from knowing whether the files can be used. How the DOI itself works is in the chapter on identifiers.

DDI describes a survey: the questionnaire, the sample, the variables, the files. SDMX describes an indicator, its dimensions and the series. Both are needed within their sector. Outwards, to an open data portal and to a search engine, a translation is made from them anyway: StatDCAT-AP and schema.org. The analysis is in the chapters on microdata and on indicators.

Croissant describes a machine learning dataset on top of schema.org: files, fields, a split into training and test parts. Version 1.1 of 29 January 2026 added provenance using the PROV-O model, usage conditions (DUO and ODRL) and links to external vocabularies. In a file the version shows as dct:conformsTo with the value http://mlcommons.org/croissant/1.1. Platforms in 2026 still serve 1.0. A card for people is a separate text alongside. More in the chapter on ML catalogs.

SKOS describes a vocabulary: a concept has an address, labels, a code and "broader/narrower" links. ISO/IEC 11179 describes a data element in a registry: a definition, permitted values, an owner. These are the languages of metadata catalogs, not dataset portals. The analysis is in the chapter on metadata catalogs.

Packaging and combining existing standards​

Several specifications often end up on the same list as catalog standards, although they answer a different question: how to package files, or which existing standards to combine.

RO-Crate packages a study's files together with their description. Next to the data sits ro-crate-metadata.json, a JSON-LD file based on schema.org. The current recommendation is 1.3 of 22 June 2026. It is used to transfer and deposit a research object: the data, the programs, the article on how they were obtained. A national catalog is not harvested with this file. Dataverse has an RO-Crate export as a separate community exporter, not as a portal exchange format.

CDIF (Cross-Domain Interoperability Framework) is CODATA's guidance on which existing standards to combine when data crosses a discipline boundary. Version 1.0 came out in May 2024, version 1.1 in June 2026. For discovery, CDIF recommends schema.org and DCAT, not a new catalog vocabulary. Each discipline's own standards remain: DataCite, DDI, ISO 19115.

Data Package and BagIt describe a folder of files. In the first, a datapackage.json sits alongside with a list of tables and a column dictionary: this is how a dataset is published in Git. In the second, a checksum manifest: this is how an archive checks that a package is intact. OCFL sets out how a repository lays out such packages on its own disk. None of the three tells a portal harvester how to walk a catalog. On publishing as a folder, see the chapter on Git repositories; on archival packaging, the chapter on archiving.

CodeMeta works like schema.org for a dataset, but for software: authors, version, a link to the repository. It is placed next to the data if code is published too. It does not become a dataset catalog.

Controlled vocabularies​

Free text in a "theme" field does not join up across portals. "Transport", "Transportation" and "transp." are three different themes to a program. The value is taken from a shared list and written as its address or code.

For open data in Europe these are the thirteen data themes of the EU Publications Office: agriculture, economy and finance, education, energy, environment, government and public sector, health, international issues, justice, regions and cities, population and society, science and technology, transport. For geodata, the nineteen ISO 19115 topic categories: biota, boundaries, elevation, inland waters and others. You can have your own classification. Outwards it is mapped onto the shared list, as EU national portals do: their own headings inside, the data theme in DCAT-AP.

A licence is written as a link, not as the phrase "open licence". In DCAT-AP the link points to the EU Publications Office licence vocabulary. In a repository and in a CITATION.cff file the same licence is recognised by its SPDX code, e.g. CC-BY-4.0. A Russian reader will understand the words "standard terms of use", but an international catalog's program will not: there is no such code in its list. More in the chapter on licences.

The language is written as a code from the EU language vocabulary or ISO 639, and the territory as a country and region code or a link to a recognisable object such as GeoNames, not as "our region". A code survives harvesting better than a name: when moved from catalog to catalog, a city name is lost more often than an identifier. In a research description the publisher is written as an organisation identifier from the ROR registry, and the author as an ORCID identifier. Then one organisation and one person do not split into different spellings of the name.

Your own controlled vocabulary is justified if there is no shared one. Then it is published separately, each value gets a persistent address, and it is described in SKOS. A list in a form field's hint does not count as a controlled vocabulary: it cannot be referenced from another catalog.

How to choose​

SituationDecision
Descriptions are harvested by a national portal or data.europa.euthe profile and version their validator checks. A neighbouring version will not do
Datasets must be findable by searchschema.org on every dataset page, even if DCAT already exists
A DOI is neededthe DataCite schema. A DCAT record does not register a DOI
A map layer must also appear on an open data portalISO 19115 inside, GeoDCAT-AP outwards
Only your own staff see the catalogno external standard is needed
A Russian authority publishes to the federal portal and nowhere elsethe recommendations 4.0 passport
The same authority wants its datasets found from outsidekeep the passport and add schema.org; DCAT when a harvester names a profile
The discipline has its own schemakeep it inside, serve a common profile outwards
You want your own fieldsin the catalog's form, yes. In a file for someone else's harvester, only a known profile
A dozen datasets with no harvesterschema.org and one file with all descriptions. Full DCAT-AP is overkill

In brief, this is what a justification looks like using the decision record template. The record on which CKAN extension to enable is already in the chapter on export. Here the fork is different: the national passport or "an international standard".

  • Context. A ministry publishes about two hundred datasets. The federal portal and Gosweb sites expect a passport under recommendations 4.0. Staff ask to "do it like in Europe, in DCAT". There is no specific harvester that would name a DCAT-AP version. It would be good to see the datasets in dataset search.
  • Options. Replace the passport with DCAT-AP. Keep only the passport. Keep the passport for the Russian portal, mark up pages with schema.org and not write a home-grown JSON.
  • Criteria. Who actually harvests the descriptions, whether the dataset gets into search, how much it costs to maintain two descriptions of one dataset.
  • Decision. Keep the passport. Add schema.org to the dataset page. Enable DCAT-AP when a specific harvester names a profile version. Do not make a home-grown "almost DCAT" format.
  • Why. The Russian portal reads the passport. A search engine reads the page markup. Nobody would validate DCAT-AP without a harvester, and a home-grown JSON would have to be explained separately to every new recipient. Both descriptions come from one record: the second is not typed by hand.
  • When to review. If the federal portal starts harvesting DCAT, if a dataset has to get into data.europa.eu or a sector aggregator, or if DCAT-AP 3.0.2 becomes a recommendation and the draft stops being accepted.

How to recognise a standard from a file​

The commands for checking that a dump opens and passes a validator are collected in the chapter on export. Here: how to tell from the contents which language you are looking at. Look at the start of the file, not at the name of the "download metadata" button.

What is visible in the fileWhich standard it is
property and value columns, a standardversion fieldthe passport from the Russian methodological recommendations
conformsTo with the address of DCAT-AP, DCAT-US or another profile versiona DCAT profile; the number in the address matters more than the word "DCAT" in the instructions
@type with the value Dataset and the schema.org vocabulary in @contextschema.org markup. If conformsTo points to mlcommons.org/croissant, it is Croissant
A ro-crate-metadata.json fileRO-Crate
XML with a gmd: or mdb: prefixan ISO 19139 or ISO 19115-3 record
The datacite.org/schema/kernel-4 namespacethe DataCite schema
datapackage.json next to tablesData Package, a dictionary of files, not a portal catalog

Then two checks. First: the version in the file matches the one the harvester named. DCAT-AP 2 where 3.0.1 is expected, and DCAT-US 1.1 where 3.0 is already accepted, are different profiles. Second: the field values come from a controlled vocabulary. To a validator, the word "CSV" in the format field and a file type address from the vocabulary are not equal, as the data.gov.gr dump showed.

Where people usually go wrong​

Calling your own JSON a standard. The fields resemble DCAT, the names are your own, there are no controlled vocabularies. Every harvester parses such a file separately, and it fails at the first profile check.

Enabling the dump and assuming the profile is right. An extension's or a cloud service's default profile is often older than the one the country expects. It is switched on in settings. On data.gov.gr the profile was enabled, and two fields still failed the validator.

Taking a draft as the current version. As of October 2026 the drafts are DCAT-AP 3.0.2, StatDCAT-AP 3.0.0 and HealthDCAT-AP. They are read to understand where the profile is heading. For exchange, serve the version that has recommendation status and that the harvester's validator accepts.

Free text instead of a code. A theme, licence, language and territory written as phrases do not join up with someone else's catalog. A mandatory field filled with a placeholder formally passes and is empty in meaning.

Covering all tasks with one standard. DCAT does not register DOIs, DataCite does not feed data.europa.eu, the passport does not get into dataset search, Croissant does not describe an indicator. Each recipient gets its own language from the same record.

Confusing a dataset description with a file's structure. You cannot publish procurement "in DCAT": DCAT describes the record, OCDS describes the contracts themselves. The record then says, via dct:conformsTo, that the file conforms to OCDS.

Sources​