SKOS 的 Concept、ConceptScheme、Collection、broader、related、exactMatch 和 closeMatch 有什么区别？

快速对照

Concept：可被标注和关联的概念资源

skos:Concept 是 SKOS 词表的基本单位。它通常用 IRI 标识，再配合 prefLabel、altLabel、hiddenLabel、定义、注释和语义关系描述。例如，“分布式系统”可以是一个 Concept，它有中文首选标签、英文首选标签、别名和定义。

Concept 不是标签字符串。两个概念可以偶然拥有相同文字，却因语境不同而保持不同 IRI；同一个概念也可以有多语言标签和多个同义词。应用应以 IRI 作为身份键，不能用首选标签直接去重。

Concept 也不自动等于 owl:Class。SKOS 概念用于索引、浏览和知识组织，OWL 类用于描述个体集合及形式逻辑约束。某个资源在 RDF 中可以同时被声明为 SKOS Concept 与 OWL Class，但这是项目主动采用的“元建模”选择，需要明确推理和治理后果，不能从 SKOS 类型自行推断。

ConceptScheme：概念体系与治理边界

skos:ConceptScheme 表示一个受管理的概念体系，例如企业主题词表、图书分类方案或产品分类法。Concept 通过 skos:inScheme 指向所属体系。一个 Concept 可以属于多个 ConceptScheme，因此 inScheme 不是只能出现一次的封闭容器关系。

ConceptScheme 可有标题、发布者、版本和许可等元数据。它是治理与发布边界，不代表体系中的最高概念。最高概念应通过 skos:hasTopConcept 从 Scheme 指向 Concept，或用其逆属性 skos:topConceptOf 从 Concept 指向 Scheme。topConceptOf 也意味着该概念 inScheme。

W3C SKOS 数据模型将 Concept 与 ConceptScheme 视为不同类别。不要为了表示“动物”是动物分类体系的顶级词，就把同一个 IRI 同时作为 ConceptScheme 和 Concept；应给体系与词条各自稳定 IRI。

Collection：面向分组，不进入概念层级

skos:Collection 用于把若干 Concept 或嵌套 Collection 聚合在一起，常见用途包括导航分组、编辑批次、主题阵列或按某个非层级特征展示一组词。成员通过 skos:member 连接。

Collection 不是 Concept，所以不能用 broader 或 narrower 把它插入概念层级。假设词表把“按颜色分类”作为一个展示分组，其中包含“红色”“蓝色”，这个分组本身未必是可用于标引文档的主题词。把它建成 Concept 会让检索和推理误以为它具有独立概念语义。

Collection 成员关系也不等同于 inScheme。一个概念被某 Collection 收录，不会仅凭该事实自动得出它属于某 ConceptScheme。发布流程应分别维护体系归属和集合成员，并用 SHACL 或其他验证规则检查项目自己的约束。

OrderedCollection：成员顺序是数据的一部分

skos:OrderedCollection 是带顺序的 Collection，通过 skos:memberList 连接一个 RDF List。它适合星期、流程阶段或必须按编辑顺序展示的词组。普通 Collection 的 skos:member 没有顺序语义，RDF 三元组的序列化先后也不可靠。

成员列表顺序仍不是 broader/narrower 层级。第一项不自动是其他项的上位概念，相邻项也没有语义关系。若成员之间同时存在层级或关联，必须另写对应 SKOS 关系。

broader 与 narrower：直接层级关系

skos:broader 表示主语 Concept 有一个语义范围更广的 Concept；skos:narrower 是其逆属性。例如“关系数据库” broader “数据库”，“数据库” narrower “关系数据库”。只声明一侧时，符合 SKOS 推理的系统可以得出另一侧。

关键点是 broader 和 narrower 本身不是传递属性。如果 A broader B，B broader C，不能按该属性直接断言 A broader C。SKOS 提供 broaderTransitive 和 narrowerTransitive 作为传递超属性，用于查询完整祖先或后代闭包。

这个区分保留了直接层级边与传递路径。界面展示下一层时查询 broader/narrower，面包屑或所有祖先查询可使用 Transitive 关系或属性路径。如果把所有祖先都物化为普通 broader，就无法分辨直接父节点与远祖。

broader 不是 rdfs:subClassOf

rdfs:subClassOf 声明一个类的所有实例也是另一个类的实例，具有形式化的类包含语义。skos:broader 只表示知识组织系统中的层级关联，可能对应类属、整体—部分、实例关系或特定领域的编排规则，并不保证统一逻辑解释。

例如博物馆词表可能把一位画家放在某艺术流派下用于导航，这不一定是在声明该人物是某 OWL 类的子类。需要本体推理时，应单独建立 OWL 模型，再明确它与 SKOS 概念的映射，而不是直接替换属性。

related：对称的非层级关联

skos:related 表示两个 Concept 之间存在有意义但非层级的关联，例如“网络安全”与“密码学”。它是对称属性：A related B 可以推出 B related A。

SKOS 的一致性条件要求 related 与 broaderTransitive 不应同时描述同一对概念。若 A 是 B 的上位或传递上位概念，又把二者标成 related，会混淆层级与关联导航。数据导入时应检查直接和间接层级闭包，再验证 related 冲突。

related 不传递。A related B 且 B related C，不意味着 A related C。若搜索系统做关系扩展，应给每一跳设置权重和上限，不能把整个关联网络当成等价簇。

semanticRelation 与 mappingRelation：内部关系和跨体系映射

skos:semanticRelation 是概念间语义关系的总属性，broader、narrower 和 related 都是其子属性。skos:mappingRelation 则是为跨 ConceptScheme 映射设计的总属性，具体包括 broadMatch、narrowMatch、relatedMatch、closeMatch 和 exactMatch。

映射属性与普通语义属性存在对应：broadMatch 是 broader 的子属性，narrowMatch 是 narrower 的子属性，relatedMatch 是 related 的子属性。这样通用 SKOS 查询仍能看到它们的基础语义，同时应用可识别“这是外部体系映射”并采用不同治理策略。

规范将 mapping properties 用于不同 Concept Schemes 之间，但不能仅靠属性名替代体系归属验证。数据管道应确保映射两端的 Concept、Scheme 和版本明确，并记录映射来源、审核状态与时间。

exactMatch：高置信度且可传递的映射

skos:exactMatch 表示两个不同 Concept Scheme 中的概念在足够广泛的应用范围内可以互换。它是对称属性，也是传递属性，并且是 closeMatch 的子属性。因此 A exactMatch B、B exactMatch C 可以推出 A exactMatch C，同时任一 exactMatch 也属于 closeMatch。

正因为会传递，exactMatch 必须谨慎使用。两两看似接近的映射串联后可能把不同版本、粒度或司法语境的概念合并成过大的等价簇。发布前应测试传递闭包，检查是否出现意外跨域连接。

exactMatch 仍不是 owl:sameAs。owl:sameAs 声明两个 IRI 指向同一个个体，所有属性可在逻辑上相互传播；SKOS exactMatch 是概念映射关系，刻意比严格身份等价弱。把它升级为 sameAs 会把标签、体系归属、维护元数据和其他关系全部合并，通常过强。

closeMatch：足够接近，但禁止多跳扩散

skos:closeMatch 表示两个概念足够相似，可以在某些检索或对齐场景中替代，但并不保证广泛互换。它是对称的，但不是传递的。A closeMatch B、B closeMatch C 时，不应自动推断 A closeMatch C。

这正适合粒度略有差别、定义边界不完全一致或只在特定业务中近似对应的概念。应用可以在查询时将 closeMatch 作为候选扩展，却应保留来源体系和置信度，不应把整条链折叠成一个 ID。

如果项目需要带置信分数、审核人、适用场景或有效期的映射，单个 RDF Property 不够。可把映射提升为独立资源或使用 RDF-star/专门映射模型记录元数据，同时保留标准 SKOS 边供互操作。

broadMatch、narrowMatch 与 relatedMatch

broadMatch 表示目标概念在另一个体系中更宽泛，narrowMatch 表示目标更具体，两者互为逆属性。方向必须从主语读起：A broadMatch B 意味着 B 比 A 更广，不是“A 是 B 的上位词”。命名容易造成反读，导入代码应配合例子测试。

relatedMatch 表示跨体系的非层级关联，是对称属性。它与 related 一样不应被当成等价。面向搜索扩展时，broadMatch、narrowMatch 和 relatedMatch 应采用不同召回权重，否则查询扩大与缩小会失去方向。

标签约束与概念身份

每个 Concept 可用 skos:prefLabel 表示首选标签、altLabel 表示替代标签、hiddenLabel 表示主要供搜索匹配而不展示的隐藏标签。对同一个资源，每种语言最多一个 prefLabel；这三个标签属性彼此不应对同一个字面值重复使用。

标签不是映射依据。两个词表都叫“Java”，可能分别指编程语言、岛屿或咖啡。自动映射至少要比较定义、上位词、适用范围、语言、体系元数据和示例，再由规则或人工审核决定 exactMatch、closeMatch 或无映射。

一个完整 Turtle 示例

这个示例同时保留体系、顶级概念、直接层级、非层级关联、跨体系映射和展示顺序，没有把 Collection 成员误写成概念父子关系。

验证规则建议

SKOS 自带一定的形式语义与一致性条件，但不会替项目自动保证一棵干净树。生产验证通常还应补充：IRI 必须稳定；每种语言最多一个 prefLabel；Concept 必须至少属于一个指定 Scheme；顶级概念必须在该 Scheme；层级不得形成项目禁止的环；related 不得与传递层级冲突；Mapping 两端必须来自不同 Scheme；exactMatch 闭包不得跨入黑名单体系；OrderedCollection 的 RDF List 必须完整且无循环。

这些约束适合用 SHACL 实现，但应区分 W3C SKOS 规范本身的完整性条件与项目自定义业务规则。把业务偏好声称为“SKOS 标准要求”会降低数据交换兼容性。

常见误区

• 用 Collection 作为层级中的父节点
• Collection 用于分组，不是 Concept。需要可浏览上位词时创建 Concept，再按需另建 Collection。
• 把 broader 声明成传递属性
• 这会丢失直接层级与祖先关系的区别。完整闭包应查询 broaderTransitive。
• 把 related 当成弱 broader
• related 是对称、非层级关系，没有上下方向。层级不确定时应先治理数据，而不是用 related 模糊替代。
• 所有相同标签都使用 exactMatch
• 同形词可能语义完全不同。exactMatch 会传递，错误映射的影响会沿网络扩散。
• 用 owl:sameAs 替代 exactMatch
• sameAs 是严格身份等价，会传播全部事实；跨词表概念对齐通常应使用 SKOS Mapping 属性。