---
title: "DCAT (RDF Data Catalog) (dataset.dcat)"
description: "Dataset discovery, the W3C way."
canonical: "https://geordy.ai/formats/dcat"
---
# DCAT (RDF Data Catalog)

**Dataset discovery, the W3C way.**

RDF-based catalog vocabulary for datasets - endpoints, distributions, licenses. AI agents use this when looking for structured data assets, not articles.

DCAT (Data Catalog Vocabulary) is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web, enabling AI systems to discover and understand datasets. W3C-standardized, it provides a standard way to describe datasets and data services, making them discoverable and accessible across different catalogs and systems.

## At a glance

- File: `dataset.dcat`
- First released: 2014
- Created by: Government Linked Data Working Group (W3C)
- Specification: https://www.w3.org/TR/vocab-dcat-3/
- Read by: GPTBot, ClaudeBot, PerplexityBot, LLM crawlers accessing semantic metadata

## Why it matters for AI

DCAT is the W3C-standard RDF vocabulary that data portals use to describe datasets, distributions, and data services in a machine-readable, interoperable way. Because crawlers, federated catalogs, and AI agents resolve DCAT terms to stable W3C URIs, a DCAT-described dataset is far more discoverable and contextualizable than one described only in HTML prose.

## Example

```
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dct: <http://purl.org/dc/terms/> .

<https://geordy.ai/dataset/ai-crawl-analytics>
  a dcat:Dataset ;
  dct:title "AI Bot Crawl Analytics" ;
  dct:publisher <https://geordy.ai> ;
  dcat:keyword "GPTBot", "ClaudeBot", "AI crawling" .
```

## Benefits

- W3C standard with established adoption
- Rich semantic metadata support
- Federated data discovery capabilities

## Limitations

- Complex RDF syntax requires technical expertise
- Overkill for simple datasets
- Semantic web concepts learning curve

## Best practices

- Type top-level resources explicitly as dcat:Catalog, dcat:Dataset, dcat:DataService, and dcat:Distribution, and link Distributions to Datasets via dcat:distribution.
- Reuse standard vocabularies alongside DCAT: dcterms: for title/description/issued/modified/publisher, foaf:Agent for publishers, and skos:Concept (with dcat:theme) for subject classification.
- Always provide dcat:downloadURL or dcat:accessURL plus dcterms:format / dcat:mediaType on every Distribution so machines can fetch and parse the data.
- Publish DCAT alongside (not instead of) human HTML, ideally as Turtle/JSON-LD with content negotiation, and keep dataset URIs stable and dereferenceable.

## Pitfalls

- Confusing dcat:accessURL (a landing/API URL) with dcat:downloadURL (a direct file URL) - using only accessURL on bulk files breaks automated harvesting.
- Omitting dcterms:publisher, dcterms:license, or dcterms:modified, which makes the record unusable for trust, attribution, and freshness checks.
- Inventing custom subclasses or properties instead of reusing DCAT/DCAT-AP terms, which breaks federation with portals such as the EU Data Portal.

## Use cases

- **Open data publishing**
- **Research datasets**
- **Government / enterprise federated discovery**

## Adopters

- data.europa.eu (https://data.europa.eu/en)
- data.gov (https://catalog.data.gov/dataset)
- data.gov.uk (https://data.gov.uk/)
- DCAT-AP (SEMIC) (https://semiceu.github.io/DCAT-AP/)
- CKAN (https://github.com/ckan/ckanext-dcat)
---

Source: https://geordy.ai/formats/dcat
This is a machine-readable markdown version of that page, generated by Geordy.