身份与 URI 设计、命名空间

第 11 章 · 知识图谱

同一个「爱因斯坦」，你的系统用 ex:Einstein，Wikidata 用 wd:Q937，DBpedia 用 dbpedia:Albert_Einstein——若没有身份的约定，融合与对齐就无从谈起。实体的全局唯一标识在 RDF 与知识图谱中通常用 URI/IRI；设计时要考虑：用怎样的命名空间、路径如何组织、URI 是否可解析（用浏览器或程序 GET 能否拿到描述）、以及版本与持久化（URI 一旦对外发布，最好永久有效）。本章把身份、URI 设计规范、命名空间、可解析与不可解析标识符、以及版本与持久化策略讲清楚。

一、实体的全局唯一标识

知识图谱中的每个实体需要在一个全局（或至少在融合范围内）唯一的标识，以便：不同数据源指向「同一实体」时能对齐；同一实体在不同三元组中不产生歧义；链接与引用可追溯。在 RDF 与语义网中，这一标识通常采用 URI（Uniform Resource Identifier） 或 IRI（Internationalized URI，支持 Unicode）。

同一现实事物可能在不同系统中拥有不同 URI（如上述爱因斯坦的例子）。此时需要通过实体对齐（Entity Alignment）或等价声明（如 owl:sameAs）建立「这些 URI 指向同一实体」的映射，才能在做融合、查询与推理时视为一体。因此，在设计自建图谱的 URI 时，若能与已有权威源（Wikidata、DBpedia、行业标准）保持一致或建立稳定映射，会大大降低后续对齐成本。

同一实体多 URI：通过 owl:sameAs 或实体对齐建立等价

二、URI 设计规范与命名空间

URI 的通用形式为 scheme :// authority / path ? query # fragment。在知识图谱中常用 http 或 https 作为 scheme，authority 为域名（表示由谁负责该标识空间），path 用于区分类别与具体实体。

设计约定：路径尽量稳定、可读——如 /entity/Person/Einstein、/resource/Einstein；避免把易变信息（如自增 id、时间戳）作为唯一区分手段，除非有持久化保证。常用小写、无空格，用连字符或驼峰；若与已有词汇表对齐，可沿用其 path 风格。命名空间（Namespace）：把 URI 的「前缀」抽象成短前缀，便于书写与阅读。例如 http://example.org/ 对应前缀 ex:，则 ex:Einstein 展开为 http://example.org/Einstein。Turtle、SPARQL 中通过 @prefix ex: <http://example.org/> . 声明。

https://example.org/entity/Person/Einstein

URI 结构：scheme + authority + path

URI 三部分：scheme、authority、path

ex: <http://example.org/>
wd: <https://www.wikidata.org/entity/>
dbo: <http://dbpedia.org/ontology/>

常见命名空间前缀示例：ex 为示例，wd 为 Wikidata 实体，dbo 为 DBpedia 本体。

三、可解析 URI 与不可解析标识符

可解析 URI（Resolvable URI）：用 HTTP GET 请求该 URI 时，服务器返回对该资源的描述（如 200 或 303 重定向后返回 RDF）。这样，任何人或程序都能通过「访问 URI」获取该实体的元数据与关系，符合关联数据原则。实现上常用 303 See Other：请求 https://example.org/entity/Einstein 时，返回 303 重定向到 .../entity/Einstein.rdf 或 .../data/Einstein，再返回 RDF 文档。

不可解析标识符：URI 仅作为名字使用，不保证 GET 能拿到描述。许多内部图谱或仅用于融合的标识采用这种方式，减少对 Web 服务的依赖。此时仍应保证 URI 的全局唯一性与稳定性；若使用 hash URI（如 https://example.org/ns#Einstein），注意 # 后的 fragment 在 RDF 中通常与「不含 # 的 URI」视为同一资源，具体语义依序列化与工具而定。

可解析 URI

GET 该 URI → 303 或 200 → 返回 RDF/HTML 描述。支持关联数据与「点击即得」；需部署 URI 解析服务。

不可解析标识符

URI 仅作唯一 ID，不保证 HTTP 返回描述。适合内部图谱或仅做对齐；仍须保证唯一与稳定。

可解析 URI 与不可解析标识符的取舍

可解析 URI 流程：GET → 303 → 返回 RDF 描述

四、版本与持久化策略

URI 一旦被外部引用或写入数据，就应视为持久：不改变其含义（同一 URI 始终指向同一实体），否则会破坏已有链接与推理。若实体信息需要版本化，常见做法是：

内容版本化、URI 不变：同一 URI 的描述可随时间更新（如属性修正），但「这是谁」不变；适合日常修正。
版本路径或时间戳资源：若需保留历史快照，可增加「版本资源」如 .../Einstein/2024-01 或 .../version/1，主 URI 仍指向「当前」实体。
重定向：若必须更换 URI（如域名迁移），用 HTTP 301 或 308 永久重定向从旧 URI 到新 URI，并在文档中说明；新数据使用新 URI，旧链接仍可通过重定向找到。
废弃（deprecation）：不再使用的 URI 可标记为 deprecated，不删除；新数据不引用，旧数据保留以便追溯。

版本与持久化：URI 不变、重定向、废弃

一句话： 实体需要全局唯一标识，通常用 URI/IRI；多源中同一实体可有不同 URI，需通过 sameAs 或实体对齐建立等价。URI 设计注意 scheme、authority、path 的稳定与可读；命名空间用前缀缩写便于书写。可解析 URI支持 GET 返回描述（303 + RDF）；不可解析则仅作 ID。持久化要求 URI 语义不变、迁移用 301/308、废弃仅标记不删。

实践： 为自建图谱选定一个 authority（如公司域名或项目域名），约定 path 规则（如 /entity/类名/标识），在 Turtle 或 JSON-LD 中统一 @context / @prefix；若有与 Wikidata 或 DBpedia 对齐的实体，显式写出 owl:sameAs 以便融合与推理。

五、小结

实体的全局唯一标识采用 URI/IRI；同一实体在不同源可有不同 URI，需 sameAs 或对齐。URI 设计：scheme + authority + path，路径稳定可读；命名空间用前缀映射长 URI。可解析 URI：GET 返回 303/200 与 RDF；不可解析仅作 ID。版本与持久化：URI 语义不变、内容可更新；迁移用 301/308；废弃仅标记。下一章进入知识获取与构建：实体识别与抽取，从非结构化文本中识别实体。