我第一次把正经业务数据映射到都柏林核心元数据Dublin Core简称 DC的时候是在给一个机构知识库定资源描述规范。老实说当时我对RDF的了解仅限于“三元组”三个字脑子里想的还是“数据库里加几个字段”的事。等真正动手用 RDF 把这份元数据落到代码里我才发现都柏林核心这个看上去人畜无害的标准一旦扔进语义网的体系里每走一步都是选择同一个字段到底用旧词汇还是新词汇、作者应该写成普通文字还是独立 URI、多个作者之间要用什么容器表达……这些问题要是不提前弄清楚数据一旦发布出去后面做知识图谱、跨库互操作、数据融合每一项都会变成灾难。这篇文章我就把自己这几年跟 RDF 和都柏林核心打交道的思路、代码和踩过的坑从头到尾整理一遍。不管你是刚开始接触语义网的库馆从业者还是在做开放数据平台、学术知识图谱的工程师后面这些内容应该都能直接拿来当参考。1. 都柏林核心的初心给网络资源一张统一的“档案卡”1.1 一场都柏林聚会诞生的 15 个词1995 年在美国俄亥俄州都柏林市OCLC 和 NCSA 召集了一批图书馆员、计算机学者和网络研究者讨论一个当年很现实的问题互联网上的资源越来越多但没有任何一套足够简单的元数据标准能让资源创建者自己动手去描述网页、文档、图片、数据集。图书馆用的 MARC 编目格式功能虽然强大但那是专业编目员的工具让普通网页作者去填 MARC 字段显然不现实。于是“都柏林核心”这套词汇诞生了。它的设计目标你可以用三句话概括第一资源作者本人就能完成描述不依赖专业编目人员第二不针对某一种特定资源类型书、论文、图片、数据集都能用第三字段数量压到最少最初就是 15 个元素。这套“极简”思想放在 2024 年看依然很超前。它实际上是在提醒所有做数据治理的人元数据不是字段越多越好而是要让不同系统之间能用一个共同语言对话。DC 承担的就是这个“公共语言”的角色。1.2 15 个元素到底在描述什么很多教程喜欢把 15 个元素列成一个表就完了但我更愿意把它们按“描述什么”分个组这样更容易记也更容易在实际中判断该用哪个字段。分组元素实际用途资源本身的识别Title、Description、Identifier给资源起名、写简介、挂唯一标识ISBN、DOI、URI责任主体Creator、Publisher、Contributor主要作者、发布者、次要贡献者内容特征Subject、Type、Language、Coverage主题分类、资源类型、语言、时空覆盖范围生命周期与格式Date、Format关键日期创建、发布、修正、文件格式或媒体类型关联与权利Source、Relation、Rights资源来源、与其他资源的关系、版权和许可信息这里有一个初学者容易忽略的点DC 并不是某个具体业务模型而是一层“互操作层”。它的作用是让来自不同系统的数据经过映射后彼此能对齐。比如一个机构库里的“创建者”另一个系统里叫“著者”在 DC 层面都映射成creator不同系统之间就能对上了。1.3 标准化路径从研讨会到 ISO都柏林核心的标准化速度在元数据领域算是相当快的1998 年成为 RFC 24132003 年成为 ISO 15836后面又陆续更新到 ISO 15836:2009 和 ISO 15836-2:2019。DCMIDublin Core Metadata Initiative一直维护着这套词汇并且发布正式的 RDF 词表文件。正是这份 RDF 词表文件让“DC”和“RDF”这两个词绑定在了一起。它不是简单地把 15 个字段贴到网上而是给出了每个属性的 URI、定义、取值范围、与其他属性的继承关系让机器可以解析和处理。这也是这篇文章标题“RDF 都柏林核心”真正的含义把一套人可读的元数据词汇放到机器可读的语义网框架里。2. 三元组视角下的 DC从字段表到语义网的跃迁2.1 键值对与三元组之间隔着一整个世界如果你只是把 DC 当“字段表”用它长这样title 红楼梦 creator 曹雪芹 publisher 人民文学出版社这种表达方式直观但有一个致命局限所有信息都是孤立的字符串机器没法知道这个title是“哪本书的标题”也没法把“曹雪芹”链接到另一个数据集中关于曹雪芹的其他信息。你能做的只是原样存下来。但用 RDF 表达同一个信息情况完全不同prefix dc: http://purl.org/dc/elements/1.1/ . https://example.org/book/9787020024759 dc:title 红楼梦 ; dc:creator 曹雪芹 ; dc:publisher 人民文学出版社 .这里出现了三个元素一个用尖括号包裹的 URI 主语一个dc:title这样的谓词以及一个带语言的字面量宾语。RDF 把所有东西都放进了“主语-谓词-宾语”的三元组里主谓宾都可以是 URI。这意味着什么意味着任何一条描述都能被一个全局唯一的地址引用。书有书的 URI人有人的 URI出版社也有出版社的 URI。数据之间不再是孤岛而是通过 URI 连成了一张网。这个过程有点像搬家之前你住在一个没有门牌号的村子找人全靠问RDF 给每一块信息都钉上了门牌号你要找什么人、什么资源循着地址就能到。2.2 命名空间DC 在 RDF 世界里的正式住址DC 在 RDF 里有两个最常用的命名空间几乎所有写 RDF DC 的人都会用到http://purl.org/dc/elements/1.1/ # 简称 dc: http://purl.org/dc/terms/ # 简称 dcterms:在 Turtle 里通常这样声明prefix dc: http://purl.org/dc/elements/1.1/ . prefix dcterms: http://purl.org/dc/terms/ .命名空间的 URI 非常容易写错这里是重灾区结尾的斜杠/不能丢。http://purl.org/dc/elements/1.1/和http://purl.org/dc/elements/1.1在 RDF 里是两个完全不同的 URI。一旦你写少了斜杠SPARQL 查询时怎么都匹配不到数据还找不出原因。这种问题我后面会专门写一节。2.3 DC 属性在 RDF 中的“身份证明”rdf:Property很多人以为 DC 在 RDF 里就是一个“标签名”其实 DCMI 发布词表时做了更严谨的事情把每个 DC 元素都声明为rdf:Property。这意味着 DC 属性是经过了 RDF/RDFS 语义体系认证的“一等公民”可以被推理机使用。举个例子DCMI 在 RDF 词表文件里声明了这样一个关系dcterms:creator rdfs:subPropertyOf dc:creator .dcterms:creator是dc:creator的子属性。如果你用dcterms:creator描述了一条资源哪怕下游系统只认识dc:creator推理机也能推导出这条资源也具有dc:creator属性。反过来则不行因为反过来不是必然成立。这就是 RDF 化 DC 和“XML 里套几个title标签”的本质区别。它不是一个方便阅读的序列化格式而是一套可以让机器自动推导、自动关联的语义模型。3. dc 与 dcterms两套命名空间的历史与选型3.1 为什么会有两套长得差不多的 DC 前缀每个刚接触 RDF DC 的人都会问同一个问题dc:和dcterms:到底什么区别为什么不能只用一套这背后有一段历史。早期的 DC 就是 15 个元素被称为“简单 DC”Simple DC。后来大家发现 15 个元素不够描述复杂资源比如一个标题还有副标题、交替标题一个日期有创建日期、发布日期、修改日期。于是 DCMI 引入了“限定词”Qualifier机制形成了“限定 DC”Qualified DC做法是在元素后面加修饰符比如dc.title.alternative。这个方案在当时能用但有两个明显缺陷第一限定词和基础元素之间的关系不够规范第二限定 DC 的表示方式在 RDF 里很别扭。于是 2008 年前后DCMI 推出了正式的 “DCMI Metadata Terms” 词表也就是dcterms。这个新词表把所有原来用限定词表达的内容全部提升为独立的一级属性每个属性都有自己的 URI。比如dcterms:alternative、dcterms:issued、dcterms:modified以及更精确的dcterms:creator、dcterms:title等。到了 2012 年DCMI 明确宣布 Simple DC 的 15 个元素不再处于活跃维护状态。这句话很容易被误读不是说这 15 个词“废了”而是说它们在语义上已经冻结DCMI 不再扩展它们推荐的新项目统一使用dcterms词表。3.2 现代项目该怎么选存量数据怎么处理根据我这个实践者的视角选型建议就几句话全新项目、要做关联数据/知识图谱的直接用dcterms:不要犹豫存量数据如果已经用dc:先保留通过映射到dcterms:来逐步切换不要在同一个 RDF 图里对同一资源同时使用dc:title和dcterms:title两套描述除非你有意利用rdfs:subPropertyOf的推理语义。否则数据消费者读取时会困惑到底该信哪个属性涉及特定领域时先用 DC 覆盖通用描述再用 VRA Core、MODS、EBUCore 这类领域词表做深度描述DC 和其他词表不是竞争关系是分层配合关系。我给一个具体的对比。假设描述一本书用老牌dc:写法是这样prefix dc: http://purl.org/dc/elements/1.1/ . https://example.org/book/9787020024759 dc:title 红楼梦zh ; dc:creator 曹雪芹 ; dc:publisher 人民文学出版社 ; dc:identifier 9787020024759 ; dc:date 1996 ; dc:language zh .用dcterms:的现代写法可以表达得更精确也更适合 RDFprefix dcterms: http://purl.org/dc/terms/ . prefix xsd: http://www.w3.org/2001/XMLSchema# . prefix dcmitype: http://purl.org/dc/dcmitype/ . https://example.org/book/9787020024759 a dcmitype:Text ; dcterms:title 红楼梦zh ; dcterms:creator https://example.org/person/cao-xueqin ; dcterms:publisher 人民文学出版社 ; dcterms:issued 1996-12^^xsd:gYearMonth ; dcterms:isbn 9787020024759 ; dcterms:language zh .注意dcterms:creator这里我写的是带尖括号的 URI而不是字符串“曹雪芹”。这种写法的语义是这本书的创建者是https://example.org/person/cao-xueqin这个资源。接着可以对这个人物资源本身再做进一步描述知识图谱就是这样一层一层长出来的。3.3 什么时候可以用老的 dc“dc 已冻结”不等于“见了 dc 就要打死”。现实里有大量系统还在输出dc:命名空间的数据比如 OAI-PMH 的oai_dc格式、DSpace 的早期配置、不少地方政府的开放数据平台。这些数据的存在就是事实新一代系统在消费这些数据时需要在导入阶段做一次映射——把dc:属性翻译成dcterms:或领域本体。我遇到过一个实际案例一批老数据里dc:date存的是“1996 年”这种自由文本映射到新系统后必须统一转换为xsd:gYear否则 SPARQL 里的时间范围查询根本没法写。4. RDF DC 的落地姿势三组代码演示前面讲了概念这一章来点能直接改改用的代码。我准备三个场景一本书、一篇论文、一个知识图谱节点难度依次递进。4.1 场景一用最小 DC 描述一本书这个最适合刚上手的人。先把命名空间声明好然后用主语URI 谓词 宾语 .这种结构把书的基本信息写出来prefix dcterms: http://purl.org/dc/terms/ . prefix xsd: http://www.w3.org/2001/XMLSchema# . prefix dcmitype: http://purl.org/dc/dcmitype/ . https://example.org/book/9787020024759 a dcmitype:Text ; dcterms:title 红楼梦zh ; dcterms:creator 曹雪芹 ; dcterms:publisher 人民文学出版社 ; dcterms:issued 1996-12^^xsd:gYearMonth ; dcterms:language zh ; dcterms:subject 章回小说, 中国古典文学, 清代 .这里有几个 Turtle 语法点你需要熟悉因为所有 RDF DC 代码都会用到分号;表示下一条三元组继续使用上面的主语逗号,表示多个宾语共享同一个主语和谓词比如dcterms:subject后面跟了三个字符串a是rdf:type的简写作用是指定资源的类型中文字符串后面加zh表示这个字面量是中文语言标签。这段数据的核心思想是书这个 URI 是一个资源它的所有描述都是围绕着这个资源展开的。从最开始就建立“资源有 URI”的意识会对你后续做数据互联有巨大帮助。4.2 场景二用 dcterms 描述一篇论文和它的许可信息论文相比书的描述要复杂一些因为它涉及作者列表、发表时间、引用关系、许可证等信息。看下面这段prefix dcterms: http://purl.org/dc/terms/ . prefix xsd: http://www.w3.org/2001/XMLSchema# . prefix dcmitype: http://purl.org/dc/dcmitype/ . prefix foaf: http://xmlns.com/foaf/0.1/ . https://example.org/publications/rdf-dc-practice a dcmitype:Text ; dcterms:title RDF都柏林核心实践笔记zh ; dcterms:creator https://example.org/person/alice ; dcterms:contributor https://example.org/person/bob ; dcterms:created 2024-06-15^^xsd:date ; dcterms:language zh ; dcterms:license https://creativecommons.org/licenses/by/4.0/ ; dcterms:subject 语义网, 知识图谱, 元数据 ; dcterms:relation https://example.org/dataset/checklist .注意这里dcterms:creator用的是一组 URI。有了 URI我们可以继续描述这个作者https://example.org/person/alice a foaf:Person ; foaf:name Aliceen ; foaf:mbox mailto:aliceexample.org ; dcterms:affiliation https://example.org/org/library .这样论文、作者、机构、数据集、许可证就都通过 URI 链接起来了。任何一条数据从孤立字符串变成了网络中的一个节点。这也是知识图谱和“用字段表管理元数据”之间最大的不同。4.3 场景三把一个数据库记录升级成知识图谱节点这是我认为最有代表性的一段代码。假设你有一个关系型数据库表里面存着一批地方志文献字段为“书名、作者名、作者生日、朝代、分类”。传统映射是这样作者名存字符串。升级后我们用 RDF DC FOAF 把它改写成这样prefix dcterms: http://purl.org/dc/terms/ . prefix dcmitype: http://purl.org/dc/dcmitype/ . prefix xsd: http://www.w3.org/2001/XMLSchema# . prefix foaf: http://xmlns.com/foaf/0.1/ . prefix skos: http://www.w3.org/2004/02/skos/core# . https://example.org/gazetteer/1789 a dcmitype:Text ; dcterms:title XX府志zh ; dcterms:creator https://example.org/person/zj-1780 ; dcterms:created 1789^^xsd:gYear ; dcterms:subject https://example.org/concepts/local-history ; dcterms:coverage XX府 . https://example.org/person/zj-1780 a foaf:Person ; foaf:name 张某zh ; dcterms:temporal 1720s .这段代码的进阶点有三个第一dcterms:subject从普通字符串变成了一个概念 URI可以接 SKOS 受控词表。它的好处是以后所有标引“地方史”这个主题的文献都指向同一个 URI跨库聚合和统计变得容易。第二dcterms:creator指向了一个人 URI而不是字符串“张某”。这样同一个作者名下所有著作都可以通过 SPARQL 一条命令查出来不用做字符串匹配。第三dcterms:coverage用来表达时空范围这是地方志类资源非常关键的字段。写到这里我要特别提醒字面量和资源实体没有绝对的对错。如果你的系统不需要跨库链接字符串完全够用。但如果你未来要做知识图谱、做实体消歧从一开始就把重要的实体挂上 URI后面可以省掉大把迁移时间。做这个决策时你需要权衡成本维护一组 URI 意味着你得管理实体的生命周期、去重、合并。小规模项目直接用字符串起步并不丢人。5. 藏在真实系统里的 RDF DCDSpace、DCAT 与 OAI-PMH5.1 机构库里的 DCDSpace 的元数据模型很多高校机构库用的 DSpace底层元数据模型就是 DC支持dc.contributor.author、dc.date.accessioned这些带修饰符的变体。DSpace 的配置里有一个dc注册表每个字段带一个修饰符所以你会看到dc.title、dc.title.alternative、dc.contributor.advisor这类写法。DSpace 这套设计的历史价值在于它证明了“DC 修饰符”可以在没有 RDF 的情况下实现复杂描述。但当 DSpace 需要通过 OAI-PMH 对外提供元数据时还是会把所有修饰符降级映射回标准 DC 元素再以oai_dc格式输出。这是 DC 作为互操作层的经典案例内部可以用扩展形式对外交换时回到公共语言。5.2 开放数据目录里的 DCDCAT 本体大量复用 dcterms如果你搞过政府开放数据平台大概率见过 W3C 的 DCATData Catalog Vocabulary。DCAT 定义了dcat:Dataset、dcat:Distribution、dcat:Catalog这些核心类但它的很多描述属性直接沿用了 dcterms。比如一个数据集的标题、简介、发布时间、修改时间在 DCAT 里对应的就是dcterms:title、dcterms:description、dcterms:issued、dcterms:modified。当你用 SPARQL 查询某个数据目录时跑出来的一大批dcterms:属性其实就是 RDF 化的 DC 在真实系统中“服役”。这也是为什么我前文反复强调要认真理解 DC 词汇表DC 并没有因为老了而过时它已经渗透进新标准里成为基础设施级的存在。5.3 学术资源交换里的 DCOAI-PMH 为什么强制要求 oai_dcOAI-PMH开放存档倡议-元数据收割协议是学术资源跨库互操作的老牌协议。它规定每个数据提供方必须支持oai_dc这一元数据前缀意思是所有记录都要能输出成标准 DC 格式。从纯 RDF 角度看OAI-PMH 的 XML 输出里没有 URI 化三元组那么灵活但它遵循的是同样的思想把各系统的异构字段映射到一套公共词汇上。收割端拿到oai_dc后可以再把数据转成 RDF供 SPARQL 端点或知识图谱使用。我做过一次类似的管道从多个 DSpace 实例通过 OAI-PMH 拉到oai_dcXML解析后映射为 Turtle加载进 Jena Fuseki然后用 SPARQL 做跨库检索。整个链路里 DC 作为交换标准让本来异质的系统能对齐字段这条思路放今天依然有效。5.4 网页嵌入从 DC 的 meta 标签到 schema.org 的 JSON-LD早期网站习惯在 HTML 头部写meta nameDC.title content...来输出 DC 元数据。现在更常见的做法是用 JSON-LD 嵌入 schema.org 词汇比如这样{ context: https://schema.org, type: Book, name: 红楼梦, author: { type: Person, name: 曹雪芹 }, publisher: { type: Organization, name: 人民文学出版社 } }schema.org 在设计时明显吸收了 DC 的字段思维然后做了更细粒度、面向搜索和电商场景的扩展。对于新型网页应用直接用 JSON-LD 更合适但这不代表 DC 没用了——它是理解整个演进脉络的基础。你只有先理解creator、publisher、identifier这些概念是从哪来的才能在看 schema.org 的文档时快速理解它哪些地方是在原有框架上做细化。6. 我在这几年 RDF DC 实操中踩过的坑与工具清单6.1 命名空间的大小写和结尾斜杠第一个坑也是最高频的坑URI 的大小写和结尾斜杠。http://purl.org/dc/elements/1.1/结尾有斜杠dcterms的http://purl.org/dc/terms/结尾也有斜杠。这两个前缀的大小写是固定的elements不能写成Elementsterms也不能写成Terms。我见过有人从网上抄来代码时把dc:声明写成了http://purl.org/dc/elements/1.1少一个斜杠结果整批数据存进去后 SPARQL 怎么都查不到。因为每一个dc:title的完整 URI 都是错的虽然显示时带着dc:前缀看起来没问题但机器不认。排查起来也麻烦因为很多编辑器会把错误的dc:前缀仍然高亮成正常颜色。我的建议是每次写完 RDF 文件先用解析器校验一遍别依赖肉眼检查前缀。6.2 字面量还是资源这个决定要趁早定我在第 4 章讲过字面量和资源的权衡。这里补充一个实际踩坑的教训我曾经在一个项目里前半年把作者全部用字符串存储后半年决定改成 URI结果要做一次全量数据迁移还要处理同名作者的消歧问题工作量翻了好几倍。所以在做元数据应用纲要的阶段就要把这层关系定义清楚哪些属性允许字面量哪些属性必须使用受控词表或 URI。对于 DC 标准词汇来说我通常这样定dcterms:title、dcterms:description、dcterms:publisher允许字面量dcterms:creator、dcterms:contributor、dcterms:subject、dcterms:license、dcterms:relation尽量使用 URIdcterms:type建议使用 DCMI Type Vocabularyhttp://purl.org/dc/dcmitype/dcterms:language使用语言标签zh或标准代码 URI不要自由填写“中文”“English”这种不一致的写法。6.3 语言标签千万别写错中文的语言标签是zh不是cn。繁体内容可以用zh-Hant简体用zh-Hans。如果一条文本没有语言标签RDF 解析器不会报错但数据消费者无法确定这是哪种语言。多语言内容特别容易乱我的经验是所有人类可读的标题和描述无论什么语言都显式加语言标签。6.4 日期字段不要存“看似能看懂”的字符串dcterms:date和它的一批子属性dcterms:created、dcterms:issued、dcterms:modified、dcterms:available在 RDF 里应该用 W3C 的日期时间类型来标注年份1789^^xsd:gYear年月1996-12^^xsd:gYearMonth完整日期2024-06-15^^xsd:date如果不加数据类型SPARQL 里做时间范围比较时会很痛苦。字符串比较和日期比较是两回事你没法用 SPARQL 直接问“1996 年之后出版的书有哪些”除非所有数据都带正确的xsd类型。6.5 空白节点bnode能不用就不用RDF 里有一种没有 URI 的临时节点叫空白节点Turtle 里写作[]或_:a。比如可以这样写作者的临时个人信息https://example.org/book/1 dcterms:creator [ a foaf:Person ; foaf:name 曹雪芹 ] .这在语法上没问题但空白节点没有全局身份外部数据无法引用它也没法从另一个数据集给它补充信息。如果你做的是关联数据、知识图谱尽量给重要实体分配持久 URI。只有一些纯结构性的辅助信息比如一个聚合容器才适合用空白节点其他情况都建议用真实 URI。6.6 好用的工具链我日常处理 RDF DC 文件最常用的工具就这几个rapper命令行 RDF 解析器主要用来校验语法。命令是rapper -c yourfile.ttl如果文件有语法错误它会直接报错。适合在 CI 流程里挂一道检查。riotApache Jena 的命令行工具也能校验和转换。如果你用 Java 生态Jena 全家桶几乎绕不开。Python rdflib适合写脚本做批量映射、清洗、加载。比如把一份 CSV 转成 DC 描述用 rdflib 几十行就能搞定。Jena Fuseki本地起一个 SPARQL 查询服务方便调试查询语句。DCMI 官方词表建议下载一份 DCMI Metadata Terms 的 RDF 文件存到本地遇到不确定的属性定义直接查。我简单写一个用 rdflib 读取并校验 Turtle 文件的示例from rdflib import Graph g Graph() g.parse(resource.ttl, formatturtle) print(f三元组数量: {len(g)}) query PREFIX dcterms: http://purl.org/dc/terms/ SELECT ?title WHERE { ?s dcterms:title ?title . } LIMIT 10 for row in g.query(query): print(row.title)6.7 老数据迁移用脚本代替手工改如果你手头有一批历史数据全是dc:旧命名空间开头的属性想迁移到dcterms:千万不要手工一行一行改。写个 Python 映射脚本把http://purl.org/dc/elements/1.1/下的属性映射到http://purl.org/dc/terms/下即可。但在替换之前务必在副本数据上跑一遍检查有没有属性名冲突或者特殊字符问题。发布时建议保留新旧两套视图一段时间方便下游系统缓冲切换。写在最后我的一点实践体会如果让我用一个词概括 RDF 和都柏林核心的关系我会选“基础设施”。DC 提供了词汇RDF 提供了语法两者结合的产物不是什么高深的黑科技而是无数数字图书馆、开放数据平台、知识图谱项目背后默默运转的地基。在我实际做项目的习惯里起步阶段会先定义一份“元数据应用纲要”把每个 DC 字段允许的值类型写清楚然后写三个样例数据分别覆盖最简单场景、最常见场景、最复杂场景全部通过 rapper 和 rdflib 校验后再大规模生成数据。这个流程看着笨但能省下后期大量返工时间。最后分享一个小技巧靠谱地表示“中文资源”这件事别只看字段名要看语言标签和数据类型是否一致。同一份 RDF 数据如果一百条记录的日期有三种写法、主题字段既有一级词又有二级词那这套数据未来一定会在某个你没有预料到的地方拖你后腿。做元数据的人一定要有“后人会怎么查询我的数据”的自觉。