📚 课程目录第2章元数据标准发展史

2. 元数据标准发展史：从MARC到DCAT

元数据标准不是一天建成的。我从2008年第一次接触MARC记录时，完全没想到这东西能追溯到1960年代。说白了，整个发展史就是一场“如何让数据被机器读懂”的接力赛。

今天咱们把时间线捋清楚。你会发现每个标准都是在解决前一个标准留下的坑。

2.1 MARC：图书馆的“磁带遗产”

MARC（Machine-Readable Cataloging）是元数据领域的鼻祖。1965年美国国会图书馆搞出来的，最初目的是把卡片目录变成磁带能读的格式。

你想想看，那时候连ASCII都还没完全定型。MARC用固定字段位置、三位数字标签、子字段标识符——比如 245 是题名，$a 是主要题名。

一个典型的MARC记录长这样：

LEADER 00000nam a2200385 i 4500
001   2023001234
005   20230701000000.0
008   230701s2023    nyua          001 0 eng  
020   $a9781234567890
100 1 $aSmith, John$eauthor.
245 10$aIntroduction to Metadata$cJohn Smith
260   $aNew York$bAcademic Press$c2023

我在一家老牌图书馆做系统迁移时看过几十万条MARC记录。那个 LEADER 字段的每一位都有含义——第5位是记录状态，第6位是记录类型。没文档你根本猜不出来。

核心贡献：MARC第一次把图书馆目录变成了机器可读、可交换的数据。至今仍是图书馆系统的基石。

踩过坑：我曾经接手一个MARC转XML的项目，发现字段 856（电子资源定位）在早期记录里直接写URL，后期却用 $u 子字段。混编记录特别容易解析出错。最好先做一次字段分布分析。

2.2 Dublin Core：迈出“简单通用”的一步

到了1995年，图书馆圈子之外的人也想要元数据。网页多了，大家都需要描述资源。于是都柏林核心元数据倡议（DCMI）出了个15个元素的简单集。

说白了就是：题名、创建者、主题、描述、出版者、贡献者、日期、类型、格式、标识符、来源、语言、关联、覆盖范围、权利。15个词搞定。

一个Dublin Core的RDF/XML例子：

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/">
  <rdf:Description rdf:about="http://example.org/doc/42">
    <dc:title>元数据标准入门</dc:title>
    <dc:creator>张三</dc:creator>
    <dc:date>2023-06-15</dc:date>
    <dc:type>Text</dc:type>
  </rdf:Description>
</rdf:RDF>

15个元素够用吗？其实不够。但好处是门槛极低。我见过一个高校机构库，就只用了DC的8个核心字段跑通整个流程。简单就是力量。

实用建议：如果你刚开始设计元数据方案，先按Dublin Core列一遍。15个元素覆盖了最基础的信息。之后不够再扩展，比一上来搞复杂的Schema更容易落地。

2.3 MODS：MARC的XML“瘦身版”

MARC太古老，DC又太简单。2002年美国国会图书馆推出了MODS（Metadata Object Description Schema）。它本质上是MARC的XML子集——保留主要语义，但用树结构代替了固定字段。

一个MODS片段：

<mods xmlns="http://www.loc.gov/mods/v3">
  <titleInfo>
    <title>元数据实践指南</title>
  </titleInfo>
  <name type="personal">
    <namePart>李四</namePart>
    <role>
      <roleTerm type="text">作者</roleTerm>
    </role>
  </name>
  <originInfo>
    <dateIssued>2023</dateIssued>
  </originInfo>
</mods>

对比MARC，MODS最大的好处是XML原生支持，解析工具多。我在做数字人文项目时，用XSLT把MARC转成MODS，比逐字段解析磁带格式快两个数量级。

2.4 DCAT：面向开放数据目录的W3C标准

2014年W3C发布了DCAT（Data Catalog Vocabulary）。这个标准专门用于描述数据目录本身——数据集、数据服务、分布。它是RDF/OWL词汇表，天然支持语义关联。

一个DCAT描述的简化样例：

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

<http://data.gov/catalog/1> a dcat:Catalog ;
  dct:title "开放数据平台" ;
  dcat:dataset <http://data.gov/dataset/42> .

<http://data.gov/dataset/42> a dcat:Dataset ;
  dct:title "城市公交站点数据" ;
  dcat:distribution <http://data.gov/dist/csv-bus> .

<http://data.gov/dist/csv-bus> a dcat:Distribution ;
  dcat:mediaType "text/csv" ;
  dcat:accessURL "https://data.gov/bus-stops.csv" .

DCAT把元数据从“描述单个资源”提升到“描述资源之间的关联”。政府开放数据门户几乎标配DCAT。我参与过的一个省级数据开放平台，就是用DCAT做数据目录的RDF序列化，上层直接对接SPARQL查询。

2.5 发展脉络对比

标准	出现时间	领域	核心优势	主要弱点
MARC	1965	图书馆	稳定性极高	格式陈旧、难以扩展
Dublin Core	1995	综合/Web	极简、易上手	语义粒度不足
MODS	2002	图书馆/数字人文	MARC语义+XML灵活性	仍偏向图书馆领域
DCAT	2014	开放数据/政府	语义关联、目录互操作	需要RDF基础

2.6 从发展史中学到什么

回看这五十年，元数据标准一直在“专深”和“通用”之间摇摆。没有哪个标准是银弹。

MARC：专到连子字段含义都依赖外部手册，但图书馆离不开它。
Dublin Core：通用到15个字段搞定80%场景，但遇到复杂关系得自己扩展。
MODS：专向通用的桥接方案，可惜生态不够大。
DCAT：拥抱语义网，但引入OWL后学习曲线变陡。

我的经验：选标准别追新。如果你的团队没有RDF经验，从Dublin Core开始跑通流程，再用DCAT做上层目录。我在一个项目中跳过DC直接上MODS，结果成员花了两周才搞懂嵌套关系。元数据工具链和人才储备一样重要。

这些标准不是彼此替代的关系。你会在同一个系统中看到MARC记录做底层存储、DC做检索摘要、DCAT做数据目录。理解它们的历史，其实是理解它们各自的“设计妥协”。