4. DCAT：数据目录词汇表归纳总结

数据目录，说白了就是管理数据的数据。你有一堆数据集，哪个是哪个？谁创建的？什么格式？怎么下载？DCAT 就是给这个问题定的一套标准词汇表。它是 W3C 推荐的，专门用来描述数据目录里的数据集、数据服务和数据分发。

我最早接触 DCAT 是帮一个政府部门做开放数据平台。当时他们 Excel 里记了 200 多个数据集，连字段含义都不统一。后来用 DCAT 一建模，所有目录立刻能互操作。嗯，今天我们就把它拆开看。

DCAT 核心类关系图 dcat:Catalog dcat:Dataset dcat:Distribution dcat:DataService foaf:Agent dcat:dataset dcat:distribution dcat:service dct:publisher 图例： 目录 数据集 分发

4.1 核心类，就这几个

DCAT 的类不多，但每个都很关键。我整理了下面的表格，方便你对照。

类 前缀 描述 我常用来表示
Catalog dcat:Catalog 数据目录本身，是一组数据集的集合 一个开放数据门户、一个内部数据资产清单
Dataset dcat:Dataset 一个数据集，可以是表、文件集合、API 的产出 某个 CSV 文件、某个数据库表
Distribution dcat:Distribution 数据集的具体表现形式（文件、API 端点等） 一份 JSON 文件、一个可下载的 ZIP
DataService dcat:DataService 提供数据访问的服务（API、SPARQL 端点等） 一个 REST API、一个 OGC WMS
Agent foaf:Agent 参与者（人、组织）——DCAT 复用了 FOAF 数据提供方、数据发布者

我的习惯：实际建模时，我会把 Catalog 看作项目根节点，Dataset 是项目里的每个数据产品，Distribution 是产品的不同包装方式。DataService 单独拿出来，因为它不是数据本身，而是获取数据的管道。

4.2 关键属性，一个都不能少

每个类都有推荐属性。下面列出最常用的，记住这些基本就能应付 80% 的场景。

dcat:Catalog

  • dct:title — 目录名称
  • dct:description — 目录描述
  • dct:publisher — 发布者（指向 foaf:Agent）
  • dcat:dataset — 包含的数据集列表（指向 dcat:Dataset）

dcat:Dataset

  • dct:title / dct:description
  • dct:issued — 发布日期
  • dct:modified — 最后修改日期
  • dcat:distribution — 指向分发实例
  • dct:theme — 主题分类（比如医学、交通）

dcat:Distribution

  • dcat:downloadURL — 直接下载链接
  • dcat:accessURL — 访问链接（可能是一个预览页）
  • dct:mediaType — 媒体类型（如 text/csv）
  • dcat:byteSize — 文件大小（字节）

重点提醒：dcat:downloadURL 和 dcat:accessURL 的区别很容易搞混。downloadURL 是直接能拿到数据的链接，accessURL 是提供访问的入口（可能还需要参数）。我见过有人把 GitHub 仓库主页当成 downloadURL，结果别人拿不到数据。

4.3 实战：一段 Turtle 描述

光看理论没意思，我们来写一段真实的 DCAT 描述。假设有一个空气质量数据集。

@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://data.example.org/catalog/airquality> a dcat:Catalog ;
    dct:title "北京市空气质量数据目录"@zh ;
    dct:publisher <http://data.example.org/org/bj-env> ;
    dcat:dataset <http://data.example.org/dataset/pm25> , <http://data.example.org/dataset/pm10> .

<http://data.example.org/dataset/pm25> a dcat:Dataset ;
    dct:title "PM2.5 小时浓度数据"@zh ;
    dct:description "2024年北京市各监测站 PM2.5 小时浓度"@zh ;
    dct:issued "2024-01-01"^^xsd:date ;
    dct:modified "2024-12-31"^^xsd:date ;
    dcat:distribution <http://data.example.org/dist/pm25-csv> .

<http://data.example.org/dist/pm25-csv> a dcat:Distribution ;
    dcat:downloadURL <http://data.example.org/files/pm25-2024.csv> ;
    dct:mediaType "text/csv" ;
    dcat:byteSize "12583320"^^xsd:decimal ;
    dct:format "CSV" .

<http://data.example.org/org/bj-env> a foaf:Organization ;
    foaf:name "北京市生态环境局"@zh .

这段代码你拿去可以直接跑在 Apache Jena 或者任何 RDF 解析器里。我刚开始用 DCAT 时，总喜欢把 Distribution 写得特别复杂，后来发现只要 downloadURL 和 mediaType 填对，大部分工具都能自动处理。

4.4 避坑指南

我曾经踩过的坑，你大概率也会遇到

  • Dataset vs Distribution 分不清：Dataset 是逻辑概念，Distribution 是物理实现。同一个数据集可以有 CSV、JSON、XML 三个 Distribution。你想想看，如果把格式信息直接写在 Dataset 上，那多个格式怎么办？
  • 忘掉 dct:publisher：数据来源是谁？很多目录只写数据集标题，没写发布者。一旦数据有问题，没人追责。别忘了关联一个 foaf:Agent。
  • 时间格式不统一：DCAT 推荐用 xsd:date 或 xsd:dateTime。我见过有人用 "2024/01/01"，RDF 解析直接报错。直接用 "2024-01-01"^^xsd:date 最保险。
  • 过度使用 dcat:keyword：关键词是自由文本，没法做精确查询。如果要做分类，老实遵守 dct:theme 引一个受控词表。

4.5 什么时候该用 DCAT？

说句实在话，不是所有元数据场景都需要 DCAT。我的判断标准就一条：

  • 需要跨组织交换数据目录？用 DCAT。它是 W3C 标准，兼容性最好。
  • 只是内部数据库文档？可以考虑更简单的 Dublin Core 或自己建模型。
  • 需要描述数据服务接口？DCAT 的 DataService 类加上 OpenAPI 描述就够了。
  • 想做数据资产目录？DCAT + 企业扩展（比如 dcat:Catalog dcat:Resource 可以自定义属性）基本够用。

一个小技巧：先用 DCAT 的核心模型建一个原型，花不了半天。给业务方看 demo，确认后再扩展。我就这么干过，避免了后期推翻重来。

DCAT 其实不复杂，核心就是 Catalog → Dataset → Distribution 三层结构。把它理解成“书架 → 书 → 书的封面/格式”，就很好记。记住那几个属性，写几条 Turtle，你就能上手了。

← 上一章 📖 返回目录 下一章 →