3. Dublin Core：基本元素与用法归纳总结

Dublin Core 这东西，说白了就是一套"大家都认"的元数据标签集。1995年那会儿，OCLC 和 NCSA 在都柏林开了个会，搞出了15个核心元素。为啥它能活下来？够简单、够通用。我在项目中接手过一个跨机构的数字资源库，五个单位各自用不同的字段命名，最后全映射到 Dublin Core 才对齐。嗯，这15个元素就是元数据世界的"通用语"。

Dublin Core 核心元数据（15个元素） 📄 内容相关（Content） ⚖️ 知识产权（Intellectual Property） 📋 实例相关（Instantiation） Title（标题） Subject（主题） Description（描述） Source（来源） Language（语言） Relation（关联） Coverage（覆盖范围） Creator（创建者） Publisher（出版者） Contributor（贡献者） Rights（权利） Date（日期） Type（类型） Format（格式） Identifier（标识符） 💡 15个元素分为三大类：内容、知识产权、实例

3.1 15个元素，一张表说清楚

下面这个表列出了所有核心元素。你想想看，大多数资源用其中一半左右的字段就能描述清楚，但完整的15个能保证跨系统互操作时不丢信息。

类别元素名标签含义与用法示例
内容相关Title标题资源的名称，比如"元数据标准与规范"
Subject主题关键词或分类号，如"元数据；标准化；Dublin Core"
Description描述摘要或内容说明，纯文本就好
Source来源衍生资源的原始出处，通常用URI
Language语言遵循RFC 4646，如"zh-CN"、"en-US"
Relation关联与其他资源的关系，用URI表达
Coverage覆盖范围时空范围，如"中国；2020-2025"
知识产权Creator创建者个人或机构名称，如"张三"
Publisher出版者发布方，如"XX大学出版社"
Contributor贡献者除创建者外的其他参与方
Rights权利版权或许可声明，如"CC BY 4.0"
实例相关Date日期采用ISO 8601，如"2025-01-15"
Type类型DCMI Type Vocabulary，如"Text"、"Image"
Format格式MIME类型，如"application/pdf"
Identifier标识符唯一标识，如ISBN、DOI、URI

3.2 三类元素的要点解析

3.2.1 内容相关元素——描述资源"讲了什么"

Title 和 Subject 是最常用的两个。我建议 Title 保持与资源本身一致，不要自己乱编。Subject 用受控词表会好很多——我在项目中见过有人直接拿文章标题当关键词，检索效果一团糟。

Coverage 这个元素，很多人用错。它指的是资源所覆盖的地理或时间范围，不是"我覆盖了哪些主题"。比如一本写中国互联网发展的书，Coverage 可以是"中国；1994-2025"。

Relation 需要搭配关系类型使用，比如 "isPartOf"、"references"。纯文本写"属于XX系列"在跨系统时很难被解析。

3.2.2 知识产权相关元素——说明"谁做的、谁管的"

Creator 和 Contributor 的区别，说白了就是主要责任和次要责任。一篇文章的作者是 Creator，审稿人是 Contributor。Publisher 通常指正式发布方，个人博客可以留空。

Rights 字段我建议写具体一点。只写"Copyright"太模糊了，写成"Copyright © 2025, 张三. CC BY-NC 4.0" 既清晰又合规。

3.2.3 实例相关元素——记录"资源长什么样"

Date 用 ISO 8601 格式，别写"2025年1月15日"——机器读不懂。Type 必须从 DCMI Type Vocabulary 里选，比如 "Text"、"Dataset"、"Image"，不要自己发明。

Identifier 是资源的身价证。同一资源在不同系统里可能用不同标识符，建议优先用 URI 或 DOI，其次是 ISBN 等标准编号。

3.3 编码实践：在代码里怎么用

理论说完了，上点干货。下面三种是实际项目中最常见的编码方式。

3.3.1 HTML meta 标签嵌入

适合网页资源。直接在页面头部声明即可。
小提示：name 属性中的 "DC." 前缀是 Dublin Core 的命名约定。注意大小写，标准推荐首字母大写（如 DC.title），但实际解析器通常不区分。

3.3.2 XML / RDF 表示

适合数据交换。用 RDF 包裹，每个字段对应一个 dc: 前缀的元素。


  
    元数据标准与规范从入门到实践
    张三
    元数据, Dublin Core, 标准化
    本书系统介绍元数据标准与规范的核心概念与实践方法。
    2025-01-15
    Text
    application/pdf
    ISBN: 978-7-XXXX-XXXX-X
    zh-CN
    Copyright © 2025, 作者保留所有权利

3.3.3 JSON 表示

适合 API 和现代 Web 应用。用 @context 引入命名空间，简洁明了。

{
  "@context": {
    "dc": "http://purl.org/dc/elements/1.1/"
  },
  "@id": "http://example.org/book/001",
  "dc:title": "元数据标准与规范从入门到实践",
  "dc:creator": "张三",
  "dc:subject": ["元数据", "Dublin Core", "标准化"],
  "dc:description": "本书系统介绍元数据标准与规范的核心概念与实践方法。",
  "dc:date": "2025-01-15",
  "dc:type": "Text",
  "dc:format": "application/pdf",
  "dc:identifier": "ISBN: 978-7-XXXX-XXXX-X",
  "dc:language": "zh-CN",
  "dc:rights": "Copyright © 2025, 作者保留所有权利"
}

3.4 避坑指南

我曾经在一个数字图书馆项目里，发现标记录入了将近两千条"DC.date"字段格式五花八门：有写"2025.01.15"的，有写"2025年1月15日"的，甚至有写"15-Jan-2025"的。后来做日期范围检索时，程序直接崩溃。统一格式不是小事，必须在录入规范里写死。

还有几个常见问题，我直接列出来：

  • Identifier 用了非标准格式——尽量用 URI、DOI、ISBN，别用内部ID。
  • Type 用了自定义值——必须从 DCMI Type Vocabulary 里选，否则跨系统无法识别。
  • Language 写了"中文"而不是"zh-CN"——遵循 RFC 4646，机器只认标准代码。
  • Rights 只写了个"All Rights Reserved"——建议明确许可协议，比如 CC BY 4.0。

核心原则：Dublin Core 的价值在于"大家都用一个标准"。字段值尽量用受控词表或标准格式，少自己发明。互操作性比花哨更重要。

注意：Dublin Core 的元素都是可选且可重复的。同一元素可以出现多次，比如多个 Creator 或多个 Subject。但不要为了凑数滥用元素——空字段比错误字段更容易处理。

说到底，Dublin Core 的15个元素就是元数据界的"最小公约数"。上手不难，但用好需要一点经验积累。你在实际项目里遇到的具体场景，往往比标准文档里写的更复杂。不过别担心，掌握了这些基本元素和它们的用法套路，大部分资源的描述需求都能覆盖。

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