SKOS简单知识组织系统参考

1. 引言

1.1. 背景和动机

SKOS是一个汇聚不同领域知识、技术和实践的数据共享标准。

在图书馆学情报学领域，一项悠久而突出的传统是致力于开发用于组织大规模收藏(如图书、博物馆文物等)的工具。这些工具就是通常所指的“知识组织系 统(knowledge organization systems， KOS)”，有时也被称为“受控结构化词表”。一些类似但有别于传统的新事物逐渐出现，每一个都有支持的实践团体和一系列约定的标准。知识组织系统的不同 类型，包括叙词表、通用分类表、标题表和专业分类表，已经得到广泛的认可并应用于现代和传统信息系统。尽管可以用一些属性笼统地区分出不同的类型，但在实 践当中很难在叙词表和分类表之间做出明确区分(参见: [BS8723-3])。SKOS的重要之处在于，除了各自独有的特征之外，每种KOS类型都有许多共同点，通常以类似的方式使用[SKOS-UCR]。然而目前还不存在一种被广泛采用的标准，用于表征作为数据资源的这类知识组织系统，在计算机系统之间进行数据交换。

W3C语义网活动[SW]激发了跨越数据库系统、形式逻辑和万维网边界的集成化研究和技术开发新领域。这项工作负责制定语义网基础标准。资源描述框架(Resource Description Framework，RDF)为Web提供了一个通用的数据抽象和语法 [RDF-PRIMER]。RDF词汇描述语言RDFS和网络本体语言OWL为Web数据提供了一套通用数据建模(Schema)语言[RDFS][OWL-GUIDE]。SPARQL查询语言和协议为Web数据交互提供了一套标准[SPARQL]。

这些技术正为不同的应用软件所采用，由于许多现实应用软件需要一套通用框架用作不同来源数据的发布、共享、交换和集成(联合)。关联不同来源数据的能力促使着许多项目的研究团体寻求能够挖掘之前处于孤立来源的数据之间的隐含价值。

语义网的一个目标是期望更好地组织网络上大量的非结构化信息(人类可读的)，提供发现和共享信息的新路线。RDFS和OWL之前被定义为知识表示语言，提供适合于计算的表示方法，为已经存在于Web上的信息补充和提供结构[RDF-PRIMER][OWL-GUIDE]。 然而，在大规模信息上实际应用这些技术，需要依赖于详尽的特定领域知识地图的构造，以及大规模对信息资源进行精确描述(注解或编目)，往往其中的许多工作 都无法自动完成。来自于图书馆学情报学领域关于信息与知识组织方面的经验积累和最佳实践明显地可以补充和适用于语义网的这个目标，许多已有的知识组织系统 已经在开发和使用，例如美国国会标题表[LCSH]，联合国食品与农业组织的AGROVOC叙词表[AGROVOC]。

SKOS的目标是在知识组织系统设计与应用当中架起包括图书馆学情报学在内的不同实践团体之间的桥梁。SKOS旨在通过将已有知识组织模型转换到语义网技术环境下，提供已有知识组织系统导入RDF的一条低成本迁移路线，提供这些团体与语义网之间的联系。

展望未来，SKOS将会在非结构化信息开发和分析、大规模非正式和社会媒介信息的组织以及知识形式化表示之间占据一席之地。通过把图书馆学情报学领 域在知识组织方面积累的经验和专业理论以方便、恰当、可转化的方式融入语义网技术环境，以这种方式与已有语义网技术的形成互补，特别在诸如OWL这样的知 识表示形式化系统中。我们希望SKOS能够催生更多新的、有价值的应用，同时将研发的技术和实践两方面提升到一个集成化的新路线。

1.2. SKOS 概述

简单知识组织系统是知识组织系统(例如叙词表、通用分类表、标题表和专业分类表等)的一个通用数据模型。知识组织系统使用SKOS可以表示为机器可读数据，用于计算机应用软件之间的数据交换和以机器可读的格式实现网络发布。

本技术规范里将SKOS数据模型正式定义为一个OWL Full Ontology[OWL-SEMANTICS]。SKOS数据被表示为RDF三元组 [RDF-CONCEPTS]，能够使用任一种RDF语法进行编码(例如RDF/XML[RDF-XML]或Turtle[TURTLE])。更多SKOS、RDF与OWL的关系，参见下一子节。

SKOS数据模型将知识组织系统视为由概念集合组成的概念体系（Concept Scheme）。SKOS概念体系和SKOS概念用URIs来辨识，使得任何人在任何上下文环境中可以一致地引用它们，将它们作为万维网的一部分。更多识别和描述SKOS概念有关内容，参见第三节 skos:Concept类；有关概念体系，参见第四节 概念体系 。

SKOS概念可以使用任意数量的词汇字符(例如“romantic love”或“れんあい”)，任意指定自然语言(例如英语或日语平假名拼法)作为其标签。指定语言的标签中的一个可以作为该语种的首选标签，其他作为可选标签。标签也可以是“隐藏的”，这对通过文本索引查询的知识组织系统有帮助。更多SKOS词汇标签属性有关内容，参见第五节 词汇标签。

SKOS概念可以被赋予一个或多个标记，这些文字代码在特定概念体系中用来唯一识别概念。URIs更适合于计算机系统识别SKOS概念，标记则提供与其他已有标记的系统之间的桥梁，例如图书馆目录中已经存在的分类号。更多标记有关内容，参见第六节 标记。

SKOS概念拥有各种类型的文档说明。SKOS数据模型提供一组基础文档属性集，支持范围注释、定义和编辑注释等。这组基础文档属性集并不打算穷尽所有的注释类型，而是提供一个可供第三方扩展的框架，以支持更多类型的注释。更多注释相关内容，参见第七节 文档属性。

SKOS概念通过语义关系属性与其他SKOS概念关联起来。SKOS数据模型提供SKOS概念间的等级和相关链接。重申一下，SKOS数据模型的任何部分都可以通过第三方扩展以支持更加具体的需求。更多关联SKOS概念相关内容，参见第八节 语义关系。

SKOS概念可以组成带有标签和/或有序的集合。SKOS数据模型的这一特征试图为叙词表的节点标签提供支持，适用于当一组概念的排序是有意义的或提供一些有用信息的情况。更多集合相关内容，参见第九节 概念集合。

SKOS概念在不同概念体系之间可以形成映射。SKOS数据模型提供四种基础映射链接：等级式、相关式、近似等价和完全等价。更多映射相关内容，参见第十节 映射属性。

最后， 附录 B SKOS标签扩展(SKOS-XL)定义了一个可选扩展。

1.3. SKOS、RDF 与OWL

SKOS数据模型的元素是类和属性，数据模型的结构和完整性由概念和属性的逻辑特征，以及它们之间的依存关系决定。这可能是SKOS最有用但也是比较含糊的一个方面，在更多高级应用中，SKOS与OWL一样也能够表达和交换一个领域的知识。然而，SKOS不是一种形式化知识表示语言。

为了理解这种区别，“知识”通过由一组公理和事实集合表征的形式本体外显出来。叙词表和分类表则完全不同，它们不断言任何公理和事实。它们通过自然语言或 其他非正式方式识别和描述不同的想法或含义的集合，这些想法或含义有时为方便起见被称为“概念”。这些概念能够被组织成各类结构，最常见的是等级体系和相 关网络。这些结构不具备任何形式化语义，不能被有效地解释为关于世界的形式化公理或事实。确实它们也从未想过要那样去做，它们仅仅是为了提供一个方便和直 观的主题领域地图，用于帮助组织和发现事物，例如某一领域相关的文档。

将嵌入叙词表和分类表里的“知识”在任何形式中外显，需要将叙词表和分类表“再工程”(re-engineered)为一个形式本体。 换句话说，不得不做一些工作将叙词表和分类表的结构和知识内容转换为一组形式化公理和事实的集合。转换的工作需要智力投入，非常费时，因此也是昂贵的。从 叙词表使用中可以获益良多，照原样(非正式的)使用叙词表可将其作为一个主题领域内导航的便利结构。照原样使用叙词表不需要任何再工程，因此也花费更少。 另外，一些SKOS没有被设计用来表征领域的逻辑视图。在实践中，把这样的KOS转化为一个形式化逻辑表征结构往往不再满足原始意图。

OWL提供强有力的数据建模语言。因此我们能够使用OWL照原样为叙词表和分类表构建数据模型。这正是SKOS擅长之处。采用这种方式，叙词表和分类表的 概念在SKOS数据模型中被建模为个体，叙词表和分类表中包含概念的非正式描述和它们之间的链接被建模为关于这些个体的事实，而不是类或属性公理。注意， 这些是关于叙词表和分类表本身的事实，例如“概念X有首选标签‘Y’，作为叙词表Z的一部分”，不是关于世界在一个特定主题领域安置方式的事实，同样可以表达为一个形式本体。

SKOS数据被表达为RDF三元组。以下RDF图(如1.7.3节中讨论的[TURTLE])表达了叙词表的一些事实。

<A> rdf:type skos:Concept ;
  skos:prefLabel "love"@en ;
  skos:altLabel "adoration"@en ;
  skos:broader <B> ;
  skos:inScheme <S> .

<B> rdf:type skos:Concept ;
  skos:prefLabel "emotion"@en ;
  skos:altLabel "feeling"@en ;
  skos:topConceptOf <S> .

<S> rdf:type skos:ConceptScheme ;
  dct:title "My First Thesaurus" ;
  skos:hasTopConcept <B> .

这一点对理解SKOS数据模型的形式化定义和如何在软件系统里实现非常重要。另外，对SKOS更高级的应用，特别是SKOS与OWL组合起来作为复合形式化/半形式化设计的使用也很重要。

从用户角度看，形式化知识组织系统与非形式化或半形式化知识组织系统之间的区分自然地变得很模糊。换句话说，以下RDF图中个体<A>和<B>是个体(skos:Concept的实例)，<C>和<D>是类(owl:Class的实例)，这些问题和用户不太相关。

<A> rdf:type skos:Concept ;
  skos:prefLabel "love"@en ;
  skos:broader <B> .

<B> rdf:type skos:Concept ;
  skos:prefLabel "emotion"@en .

<C> rdf:type owl:Class ;
  rdfs:label "mammals"@en ;
  rdfs:subClassOf <D> .

<D> rdf:type owl:Class ;
  rdfs:label "animals"@en .

但是，支持SKOS数据模型的信息系统需要注意这种区分。

附录 C SKOS与SKOS-XL命名空间文档描述了SKOS的RDF Schema与SKOS标签扩展(SKOS-XL)。注意，由于一些约束不能在Schema中被完全顾及到，RDF/XML文档提供了规范子集。

1.4. 一致性与完整性

RDF和OWL Full语义之下，一个RDF图的形式意义(解释)是真值(truth value)[RDF-SEMANTICS][OWL-SEMANTICS]，也就是一个RDF图可以被解释为真或假。

通常RDF图如果不为真，那意味着不一致。换句话说，RDF图如果包含矛盾，那就是不一致。

单独使用RDF和RDFS词汇，事实上不可能做出一个矛盾声明。使用OWL词汇时，存在许多方法声明一个矛盾，例如，请看下面的RDF图。

<Dog> rdf:type owl:Class .
<Cat> rdf:type owl:Class .
<Dog> owl:disjointWith <Cat> .
<dogcat> rdf:type <Dog> ， <Cat> .

这个图表明<Dog>和<Cat>都是类，而且它们是不相交的，也就是说它们没有共同的成员。这与<dogcat>同时具有<Dog>和<Cat>类型的声明相矛盾。不存在OWL Full解释满足这个图，因此这个图不符合OWL Full。

当采用OWL Full作为知识表示语言，不一致的观念是有用的，因为它揭示了本体中用作断言的公理与事实之间的矛盾。通过解决这些不一致，我们学到更多领域知识，形成一个更好的模型，得出有趣和有效的推理。

当OWL Full用作一种数据建模(Schema)语言时，不一致性的观念也很有用，不过是以不同的方式。在这里我们没有关注人类知识本身的逻辑一致性。我们仅是 对形式化定义一个数据模型感兴趣，因此我们能够确定一些给定数据是否适合既定数据模型。如果数据不符合数据模型，那么数据就不适合。

这里，我们不关注给定数据是否对应真实世界，也就是他们在绝对意义上是否为真或假。由于一个特定类型应用的互操作依赖于遵循一个通用数据模型的数据，我们仅仅关注数据是否适合数据模型。

另一种方式是通过完整性表达这个观点。完整性条件是数据模型形式化定义中的声明，用于确定给定数据是否符合数据模型。例如，<Dog>与<Cat>是不相交类的声明可以视为数据模型的一个完整性条件。有了这一条，下面的数据就不一致。

<dogcat> rdf:type <Dog> ， <Cat> .

本文档中SKOS数据模型的定义包含有限数目的一组声明，作为完整性条件。通过定义数据不符合SKOS数据模型情况，将这些完整性条件纳入其中，以提升互操作。通过工具检查给定数据的一些或所有完整性条件是否满足，从而判定数据是否符合SKOS数据模型。

这些完整性条件是SKOS数据模型中类与属性的形式化定义的一部分。由于这些条件用于不同的目的，所以与其他形式化定义分别列出。完整性条件主要用于确定给定数据是否符合SKOS数据模型。SKOS数据模型定义中的所有其他声明仅用于支持逻辑推理。(参见下一子节)

完整性条件以尽可能独立于实现的策略定义在SKOS数据模型中。这是由于发现SKOS数据模型不一致的过程存在几种不同的实现方式。采用OWL推理机可以 发现不一致。除此之外，搜索数据中的特定模式或采用复合策略(如：采用RDFS或OWL推理机实现推理，然后在推断图中搜索模式)也可以找到一些不一致。

SKOS数据模型的完整性条件比想象中要少一些，特别是用于数据库系统的封闭世界。参见下一子节，注意第三节到第十节的注释。

1.5. 推理、相依性与开放世界假设

该文档把SKOS数据模型定义为一个OWL Full ontology。还存在其他定义SKOS数据模型的方法，比如实体关系模型或UML模型。虽然OWL Full作为一种数据建模语言与其他建模方式从表面上看有许多相似之处，但存在一个重要的本质区别。

RDF和OWL Full被设计用于广泛的分布式数据系统(如Web)。当这样的系统变得越来越庞大，了解系统所有数据的存放位置变得既不实际也不可能。因此，通常不能假定该系统的数据是完整。如果一些数据丢失了，那么一般来说，可以假定数据可能存在于系统的其他位置。这个假设大致上讲就是开放世界假设(open world assumption)[OWL-GUIDE]。

实践中这意味着对于被定义为OWL Full ontology的一个数据模型，一些定义可能会带有反直觉的意义，由于从丢失数据的中得不出结论，删除一些数据不会导致其他数据不一致。为了说明这一点，例如第八节skos:semanticRelation的定义。skos:semanticRelation属性的定义域与值域为skos:Concept。这些定义域与值域的定义为推理提供许可。请看下面的RDF图：

<A> skos:semanticRelation <B>.

在这一示例中，上面的RDF图推导出下面的RDF图。

<A> rdf:type skos:Concept .
<B> rdf:type skos:Concept .

因此我们不必明确地声明<A>和<B>是skos:Concpet的实例，因为这样的声明可以从skos:semanticRelation定义之中推导出来。

SKOS数据模型中，大部分定义的声明不是完整性条件，而是数据模型不同元素之间逻辑依存的声明，在开放世界假设之下这为一些简单推理提供许可。为说明这一点，第七节的声明中skos:broader和skos:narrower是一对互逆属性。这条声明的含义是

<A> skos:narrower <B> .

推导出

<B> skos:broader <A> .

这两张RDF图本身都符合SKOS数据模型。

知识组织系统(例如叙词表和分类表)适用于各种情况，一个独立的知识组织系统可以用于不同的信息系统。将SKOS数据模型定义为一个OWL Full ontology，语义网可以用来作为发布、交换、共享和关联数据(包括这些知识组织系统)的媒介。出于这个原因，以及OWL Full作为数据建模语言的表达性、使用叙词表、分类表等的可能性，与形式本体一样，OWL Full被用作定义SKOS数据模型。开放世界假设成为SKOS数据模型的基本前提，应该在阅读该文档时牢记。

参见[RDF-PRIMER]和[OWL-GUIDE]。

1.7. 如何阅读

该文档正式定义SKOS数据模型为一个OWL Full ontology。SKOS数据模型的元素是OWL类和属性，这些类和属性拥有统一资源标识符URI，方便在Web中明确使用。URI集合属于SKOS词汇。

第二节包含完整的SKOS词汇。第三节到第十节正式定义SKOS数据模型。为方便起见，数据模型的定义被分成若干节：

• 序言— 介绍该节主要思想。
• 词汇— 定义SKOS词汇的URI。
• 类与属性定义— URI对应类与属性之间的逻辑特征与相依性的正式定义。
• 完整性条件— 给出存在的完整性条件。
• 示例— 给出一些典型例子，符合和不符合SKOS数据模型的数据。
• 注释— 给出进一步的说明和讨论。

1.7.1. 形式化定义

大部分类与属性的定义与完整性条件在该文档中被声明为RDF三元组，使用RDF、RDFS和OWL词汇。但是还有一小部分不是，这是由于OWL Full表达性的局限或一些类缺少标准的URI。为改进文档的整体可读性，没有采用混合RDF三元组和其他标记形式，形式化定义和完整性条件全部用散文体 声明。

这种散文体风格一般是依照[RDFS]中的使用风格，对具备RDF和OWL知识的读者应该是清晰的。

例如" ex:Person是owl:Class的一个实例"等价于

ex:Person rdf:type owl:Class .

" ex:hasParent和ex:hasMother是owl:ObjectProperty的实例" 等价于

ex:hasParent rdf:type owl:ObjectProperty .
ex:hasMother rdf:type owl:ObjectProperty .

" ex:hasMother是ex:hasParent的子属性" 等价于

ex:hasMother rdfs:subPropertyOf ex:hasParent .

" ex:Person的rdfs:range值域是ex:hasParent类 "等价于

ex:hasParent rdfs:range ex:Person .

SKOS数据模型的某些形式方面不能使用RDF、RDF或OWL词汇声明为RDF三元组，那么解释RDF词汇时，为读者提供如何将这些声明转化为形式条件的 RDF和OWL语义的基本理解应该是清晰的。例如第五节，“一个资源的每个语种有且仅有一个skos:prefLabel值”等价于任一资源x，集合{ y | <x，y> is in IEXT(I(skos:prefLabel)) }中不存在两个成员共享一个语种标识，这里I和IEXT在[RDF-SEMANTICS]中定义为功能。

1.7.2. URI简写

完整的URIs采用等宽字体，用尖括号括起来，例如<http://example.org/ns/example>。相对URIs采用相同的方式，与基础URI<http://example.org/ns/>对应，例如，<example>和<http://example.org/ns/example>是同一URI。

URI也使用缩写形式。缩写URI采用等宽字体，不带尖括号。缩写表如下所示：

例如， skos:Concept是<http://www.w3.org/2004/02/skos/core#Concept>的简写。

1.7.3. 示例

下面的RDF图示例采用简洁RDF三元组语言(Turtle)[TURTLE]。所有的示例假定它们之前包括以下前缀和URI基准指令：

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@base <http://example.org/ns/> .

因此，如下示例：

等价于下面的Turtle文件

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@base <http://example.org/ns/> .
    
<MyConcept> rdf:type skos:Concept .

等价于下面的RDF/XML文件[RDF-XML]

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" 
    xmlns:skos="http://www.w3.org/2004/02/skos/core#"
    xmlns:owl="http://www.w3.org/2002/07/owl#"
    xml:base="http://example.org/ns/">
    
    <skos:Concept rdf:about="MyConcept"/>
    
</rdf:RDF>

等价于下面的N-TRIPLES文件[NTRIPLES]

<http://example.org/ns/MyConcept> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2004/02/skos/core#Concept> .

注意Turtle中“;”和“，”字符用来缩写同一主体或谓词的多个三元组。一些示例中“(...)”语法用来表示一个RDF集合。

1.8. 适应性

这份技术规范不定义正式的适应性说明。

如果RDF图与SKOS数据模型放在一起会导致逻辑矛盾，那么RDF图不符合SKOS数据模型。

URIs用于识别skos:Concept、skos:ConceptScheme、skos:Collection或skosxl:Label资源，并不要求通过Web解引用(dereferencing)这些URI的具体行为[WEBARCH]，但是强烈推荐SKOS数据发布者遵守[COOLURIS]和[RECIPES]。

2. SKOS命名空间与词汇

SKOS的命名空间URI是：

• http://www.w3.org/2004/02/skos/core#

SKOS词汇是一组URIs集合，下表左侧栏所示：

所有SKOS词汇的URIs在SKOS命名空间URI后面附加一个本地名称(例如“prefLabel”)。

参见附录 B的SKOS概览和快速浏览面板。

3. skos:Concept类

3.1. 序言

skos:Concept是SKOS概念类。

一个SKOS概念可以被视为一个观念或想法；一个思维单元。然而一个思维单元的组成是主观的，这个定义是建议性的，而非限制性的。

SKOS概念在描述知识组织系统的概念结构或知识结构，以及提到KOS中具体想法和意义时非常有用。

注意，由于SKOS被设计为表征半形式化KOS的工具，例如叙词表和分类表，这类KOS的形式化定义具有一定的灵活性。

参见[SKOS-PRIMER]中更多有关识别和描述SKOS概念的示例。

3.2. 词汇

3.3. 类与属性定义

3.4. 示例

下图声明<MyConcept>是一个SKOS概念，也就是skos:Concept的一个实例。

3.5. 注释

3.5.1. SKOS概念、OWL类与OWL属性

除了skos:Concept是owl:Class的实例这一断言之外，本技术规范对其他有关SKOS概念与OWL类之间的形式关系不做补充声明。不做任何声明的决定，允许应用软件结合使用SKOS与OWL，自由开发不同设计模式。

下图示例，<MyConcept>是skos:Concept的一个实例，也是owl:Class的一个实例。

这个示例符合SKOS数据模型。

与之类似的，本技术规范对SKOS概念与OWL属性之间的形式关系不做任何声明。

如下图示例，<MyConcept>是skos:Concept的一个实例，也是owl:ObjectProperty的一个实例。

这个示例符合SKOS数据模型。

4. 概念体系

4.1. 序言

SKOS概念体系可以视为一个或多个SKOS概念的集合体。概念间的语义关系也视为概念体系的一部分。这个定义是建议性的而非限制性的。以下声明的形式化数据模型具有一定灵活性。

概念体系在处理未知来源数据，以及处理描述两个或多个不同知识组织系统的数据时非常有用。

参见[SKOS-PRIMER]更多有关识别和描述概念体系的示例。

4.2. 词汇

4.3. 类与属性定义

4.4. 完整性条件

4.5. 示例

下图描述了拥有两个SKOS概念的概念体系，其中一个概念是该概念体系的顶层概念。

4.6. 注释

4.6.1. 封闭与开放系统

一个SKOS概念体系可以简单地对应为一个叙词表、分类表、标题表或其他知识组织系统。

在大多数信息系统中，叙词表和概念体系被视为封闭系统。尽管系统之间存在映射，当前系统里定义的概念单元不能作为其他系统的一部分。

虽然SKOS采用类似的方式，但是这不妨碍一个SKOS概念存在(或不存在)于一个或多个概念体系中。

例如，下图SKOS概念<MyConcept>存在于两个概念体系中，这符合SKOS数据模型。

这种灵活性是需要的，因为这样就允许连接两个或多个已有的概念体系来描述新的概念体系。

同时，概念体系的边界是不存在的。使用skos:inScheme来声明SKOS概念X，Y和Z存在于概念体系A中，这不意味着概念体系A仅由概念X、Y和Z组成。

因此，当SKOS用于描述概念体系时，SKOS不提供定义一个完整概念体系的途径。

4.6.2. SKOS概念体系与OWL本体

本技术规范决定不做任何声明，允许应用软件结合使用SKOS与OWL，自由开发不同的设计模式[OWL-GUIDE]。

如下图所示，<MyScheme>既是一个SKOS概念体系也是一个OWL本体，这符合SKOS数据模型。

4.6.3. 顶层概念与语义关系

skos:hasTopConcept属性通常用于连接SKOS概念体系与等级关系中最高层的SKOS概念。但是没有要求必须这样做的完整性条件。下图所示，这不是skos:hasTopConcept的严格用法，但仍然符合SKOS数据模型。

应用软件中可以拒绝这类数据，但不做强制要求。

4.6.4. 概念体系蕴含与语义关系

两个SKOS概念之间的链接不表明这两个概念包含在同一个概念体系中，如下例所示。

参见第八节

4.6.5. skos:inScheme定义域

注意，skos:inScheme属性没有声明定义域，有效的定义域可以是所有rdfs:Resource类。不做定义域声明提供一些灵活性，促使扩展SKOS定义新的资源类仍然使用skos:inScheme与skos:ConceptScheme建立连接。参见例 82。

5. 词汇标签

5.1.序言

词汇标签是一个Unicode字符串，任意指定自然语言，例如 "romantic love" 或"れんあい"，英语或日语平假名拼法。

SKOS为任何类型资源相关的词汇标签提供一些基础词汇。SKOS尤其能够区分任意给定资源的首选标签、非首选标签与隐藏标签。

首选标签和非首选标签在创建人可读知识组织系统表征时非常有用。这些标签提供了SKOS概念含义最有利的线索。

隐藏标签在用户通过文本搜索功能与知识组织系统交互时非常有用。例如用户寻找一个相关概念时输入了拼错的词语。如果拼错的查询与隐藏标签匹配，用户仍然能够找到相关概念，但隐藏标签对与用户而言是不可见的(不能鼓励继续犯错)。

词汇标签形式上是RDF普通文字(Plain Literal)[RDF-CONCEPTS]。一个RDF普通文字由Unicode字符串和可选的语种标识(符合[BCP47]语法的字符串)组合而成。

更多有关SKOS概念的标签示例，参见[SKOS-PRIMER]。特别需要注意的是，以下示例只说明了SKOS数据模型的一般特征，并没有给出不同语种标识的最佳实践。SKOS参考的目标是建立适用于不同状况的数据模型，可以根据具体情况做出用法上的改进或限定。有关标签和语种标识在应用与语言方面的用法惯例不在SKOS参考讨论范围之内。

5.2. 词汇

5.3. 类与属性定义

5.4. 完整性条件

5.5. 示例

下图是一致的，说明了两种不同语言(法语和英语)的词汇标签。

下图是一致的，说明了四种不同情况的词汇标签(日本汉字、平假名、片假名以及拉丁字符(罗马字))。

下图不符合SKOS数据模型，因为同一语种存在两个不同的首选标签。

下图不符合SKOS数据模型，因为首选标签与非首选标签冲突。

下图不符合SKOS数据模型，因为非首选标签与隐藏标签冲突。

下图不符合SKOS数据模型，因为首选标签与隐藏标签冲突。

5.6. 注释

5.6.1. SKOS词汇标签属性的定义域

注意，skos:prefLabel、skos:altLabel和skos:hiddenLabel没有声明定义域。这些属性的有效定义域是所有rdfs:Resource类。

因此，skos:prefLabel、skos:altLabel和skos:hiddenLabel可以标识所有类型的资源，这符合SKOS数据模型。

下图示例，skos:prefLabel、skos:altLabel和skos:hiddenLabel用于标识owl:Class的一个资源，这符合SKOS数据模型。

5.6.2. SKOS词汇标签属性的值域

注意，skos:prefLabel、skos:altLabel和skos:hiddenLabel的值域是RDF普通文字[RDF-CONCEPTS]。

RDF普通文字通常用于一个三元组的客体位置，谓词是skos:prefLabel、skos:altLabel或skos:hiddenLabel。如果RDF图不遵守这个用法惯例，应用软件可以拒绝这类数据，但不做强制要求，参见下面的注释。

5.6.3. 定义标签关系

一些应用软件需要标签相关的额外功能，例如允许标签的描述或定义标签之间的关系(如首字母缩写词)，这些可以通过定义标签的URIs来实现。附录 A定义的SKOS标签扩展提供这类支持。

5.6.4.无首选标签的其他可用标签

下图中，资源拥有两个非首选标签，但没有首选标签。这符合SKOS数据模型，没有其他的蕴含包括在这个数据模型中。尽管如此，许多应用软件还是需要一个首选标签词汇，以便产生一个人可读的最优化显示。

5.6.5. 标签与语种标识

[BCP47]定义了不同 的语种标识。"en"、"en-GB"和"en-US"是三种不同的语种标识，分别对应英语、英式英语与美式英语。类似的，"ja"、"ja- Hani"、"ja-Hira"、"ja-Kana"和"ja-Latn"是五种不同的语种标识，分别对应日语、日本汉字、平假名、片假名和拉丁字符(罗 马字)。

下图符合SKOS数据模型，因为"en"，"en-US" 和"en-GB"是不同的语种标识。

下图中词汇标签之间没有冲突，因为"en"和"en-GB"是不同的语种标识，因此该图符合SKOS数据模型。

正如5.1部分的陈述，这些示例仅仅说明了SKOS数据模型的一般特征，并不指明不同语种标识使用的最佳实践。有关标签和语种标识在应用与语言方面的用法惯例不在SKOS参考讨论范围之内。

建议应用软件采用SKOS概念体系提供的相关语种标识对应的标签，例如执行[BCP47]定义的查找算法。应用软件执行时不要求提供所有可能的语种变量(可能有许多)，要能够与SKOS概念体系兼容，仅提供与特定语种或语种集合不同的词汇形式标签。

6. 标记

6.1. 序言

标记是一串字符，比如“T58.5”或“303.4833”，用于在给定的概念体系范围中唯一标识一个概念。

标记与词汇标签的不同在于，标记通常不是任何自然语言中公认的单词或词序列。

本节定义了skos:notation属性。这个属性用于指定标记为一个类型文字(Typed Literal)[RDF-CONCEPTS]。

6.2.词汇

6.3. 类与属性定义

6.4. 示例

下面的示例说明带有一个标记的一个资源<http://example.com/ns/MyConcept>，其词汇形式是UNICODE字符串“303.4833”，其数据类型通过URI地址 <http://example.com/ns/MyNotationDatatype>指定。

6.5. 注释

6.5.1.标记、类型文字和数据类型

类型文字是一个带有数据类型URI[RDF-CONCEPTS]的UNICODE字符串。

类型文字通常用于指定数值，如：整数、浮点数和日期。XML Schema规范[XML-SCHEMA]中预定义了许多数据类型，如：xs:integer、xs:float和xs:date。

在其他情况下，可以定义新的数据类型，这些通常被称为“用户定义的数据类型”[SWBP-DATATYPES]。

通常，skos:notation属性仅用在三元组客体位置上，数据类型URI表示对应特定标记系统或分类代码系统的一个用户定义的数据类型。

很多情况下，为特定标记系统指定一个数据类型URI就足够了，通过一个描述标记构成和允许使用哪种词汇形式的文档来非正式地定义数据类型。但要注意的是，也可以通过XML Schema语言更正式地至少定义一个数据类型的词汇空间，参见[SWBP-DATATYPES]第二节。用户应该意识到应用软件可能支持不同的数据类型。然而，如[OWL-REFERENCE]6.3节中所论述的，应用软件起码应该平等看待词法相同的文字。

6.5.2. 多个标记

skos:notation属性的基数（cardinality）没有限制，一个概念可以有0、1或多个标记。

当一个概念有多个标记，这些标记可能来自相同或不同的标记系统。标记来自不同系统的情况下，可以用不同的数据类型表示。一个概念对应一个标记系统中多个标记的情况是不常见的(也就是带有相同数据类型的URI)。

6.5.3. 概念体系中的唯一标记

通常，同一概念体系中的两个概念不会拥有相同的标记。如果有，标记不可能唯一指向一个概念（也就是，标记含义将不清楚）。

6.5.4. 标记和首选标签

对同时使用skos:notation和skos:prefLabel没有限制。在下例中，相同的字符串既作为标记的词汇形式，又作为首选标签的词汇形式。

类型文字由一串字符和一个数据类型URI组成。通常，skos:notation仅在三元组的客体位置上使用类型文字。

普通文字由一个字符串和一个语种标识组成。通常，skos:prefLabel、skos:altLabel和skos:hiddenLabel仅在三元组的客体位置上使用普通文字。

没有一个RDF文字同时带有一个语种标识和一个数据类型URI。换句话说，一个类型文字不会带有语种标识，一个普通文字不会带有数据类型URI。

6.5.5. skos:notation的定义域

注意，skos:notation没有声明定义域，有效的定义域是所有资源rdfs:Resource的类。因此，任何资源类型使用skos:notation都符合SKOS数据模型。

7. 文档属性 (注释属性)

7.1. 序言

注释用于提供与SKOS概念相关的信息。注释信息属性不存在固有约束，举例来说，注释信息可以是纯文本、超文本或图像，可以是一个定义、关于概念范围的信息、编辑信息或其他信息类型。

本节中正式定义了SKOS中7个与概念注释有关的属性。更多有关SKOS文档属性的推荐用法，参见[SKOS-PRIMER]。

这7个属性不试图涵盖所有的情况，但在大多数情况下是有用的，并且提供了定义更多特定注释类型的一组扩展点。更多有关SKOS扩展最佳实践的推荐信息，参见[SKOS-PRIMER]。

[SKOS-PRIMER]中推荐了3种不同的SKOS文档属性使用模式：“文档作为一个RDF文字”、“文档作为一个相关资源描述”和“文档作为一个文档参考”。本节定义的数据模型适用于这三种设计模式。

7.2. 词汇

7.3. 类与属性定义

7.4. 示例

下图给出“文档作为RDF文字”模式的一个示例。

下图给出“文档作为一个文档参考”模式的一个示例。

7.5. 注释

7.5.1. SKOS文档属性的定义域

注意，SKOS文档属性没有声明定义域，这些属性的有效定义域是所有资源rdfs:Resource的类。因此，使用SKOS文档属性提供任何资源类型的信息都符合SKOS数据模型。

下图的示例中，skos:definition用来为owl:Class类型的一个资源提供纯文本定义——这符合SKOS数据模型。

7.5.2. SKOS文档属性的值域

注意，SKOS文档属性没有声明值域，因此这些属性的有效值域是所有资源rdfs:Resource的类。在RDF和OWL Full语义中，每种事物都是一个资源，包括RDF普通文字。

8. 语义关系

8.1. 序言

SKOS语义关系是SKOS概念之间的连接，这是相关概念含义之间内在的链接。

SKOS区分两种基本的语义关系类型：等级关系和相关关系。两个概念之间的等级连接表示其中一个概念比另一个概念（“狭窄”）在某方面更概括（“宽泛”）。两个概念之间的相关连接表示两个概念内在“有关”，但是其中任何一个概念不以任何方式比另一个概念更概括。

属性skos:broader和skos:narrower用于断言两个SKOS概念之间的直接等级关系。一个三元组<A> skos:broader <B>断言了<B>（三元组的客体）是<A>（三元组的主体）的上位概念。同样地，一个三元组<C> skos:narrower <D>断言了<D>（三元组的客体）是<C>（三元组的主体）的下位概念。

通常，skos:broader和skos:narrower仅用于断言两个SKOS概念之间的直接（邻接的）等级关系。这提供了以便捷可靠的方式访问任何给定概念的直接上位和下位链接的应用。注意，为了支持这个用法惯例，skos:broader和skos:narrower没有被声明为传递性属性。

一些应用软件需要同时利用概念之间的直接和间接等级链接，例如通过查询扩展提高查全率。为达到这一目的，提供了skos:broaderTransitive和skos:narrowerTransitive属性。一个三元组<A>skos:broaderTransitive<B>表示一个直接或间接等级链接，<B>是<A>的一个宽泛的“祖先”（ancestor）。相似地，一个三元组<C> skos:narrowerTransitive <D>表示一个直接或间接的等级链接，<D>是<C>的一个窄义的“后代”（descendant）。

通常， skos:broaderTransitive和skos:narrowerTransitive属性不用作断言。相反地，这些属性用于推断等级关系的传递闭包(transitive closure)，那么它们可用于访问概念间的直接或间接等级链接。

skos:related属性用于断言两个SKOS概念之间的相关链接。

更多声明等级链接和相关链接的示例，参见[SKOS-PRIMER]。

8.2. 词汇

8.3. 类与属性定义

8.4. 完整性条件

注意，由于skos:related是对称性属性，skos:broaderTransitive和skos:narrowerTransitive互逆，因此skos:related和 skos:narrowerTransitive不相交。

8.5.示例

下图断言了<A>和<B>之间的一个直接等级链接（<B>是<A>的上位概念），<A>和<C>之间的一个相关链接，这符合SKOS数据模型

下图不符合SKOS数据模型，因为相关链接和等级链接中存在冲突。

下图不符合SKOS数据模型，因为相关链接和等级链接中存在冲突。

在上例中，冲突不易察觉。根据上面的类和属性定义进行推理时，冲突才变得明显，如下图所示：

下图不符合SKOS数据模型，也是因为根据上面的类和属性定义进行推理时，相关链接和等级链接中存在冲突。

8.6. 注释

8.6.1.子属性关系

下图表非正式地说明了SKOS语义关系属性之间的子属性关系。

skos:semanticRelation
 |
 +— skos:related
 |
 +— skos:broaderTransitive
 |    |
 |    +— skos:broader
 |
 +— skos:narrowerTransitive
      |
      +— skos:narrower

8.6.2.SKOS语义关系属性的定义域和值域

注意，skos:semanticRelation的定义域和值域是skos:Concept类。因为skos:broader、skos:narrower和skos:related都是skos:semanticRelation的子属性，上面例 26的图中推导出<A>、<B>和<C>都是skos:Concept的实例。

8.6.3. skos:related的对称性

skos:related是对称性属性。这种情况的推导如下示例所示：

注意，尽管skos:related是对称性属性，但这个条件对skos:related的子属性没有任何约束（也就是，skos:related的子属性可以是对称的、不对称的或反对称的，这仍符合SKOS数据模型）。

为了说明这点，下例声明了两个非对称的新属性作为skos:related的子属性，这符合SKOS数据模型，也说明了其中一些蕴含关系。

更多SKOS扩展的最佳实践推荐，参见[SKOS-PRIMER]。

8.6.4. skos:related和传递性

注意，skos:related不是传递性属性。因此，SKOS模型不支持下例所示的推导。

8.6.5. skos:related和自反性

注意，本技术规范既没有规定skos:related是自反性属性，也没有规定其是非自反性属性。

由于skos:related没有定义成非自反性属性，下图符合SKOS数据模型。

但是，对于许多KOS应用来说，X skos:relatedX的声明是一个潜在的问题。情况是这样的，应用软件可能希望在处理SKOS数据之前检索这些声明，但是应用软件如何处理这些声明不在本技术规范中定义，应用软件之间也会有所不同。

8.6.6. skos:broader和传递性

注意，skos:broader不是传递性属性。同样地，skos:narrower也不是传递性属性。因此，SKOS数据模型不支持下例所示的推理。

但是，skos:broader是skos:broaderTransitive的子属性，skos:broaderTransitive是传递性属性。同样的，skos:narrower是skos:narrowerTransitive的子属性，skos:narrowerTransitive是传递性属性。因此，SKOS数据模型支持下例的推导。

特别注意，通常，skos:broader和skos:narrower仅用作断言两个SKOS概念之间直接的（也就是邻接的）等级关系。通常，skos:broaderTransitive和skos:narrowerTransitive不用作断言，而是仅用于作推理。

这种模式允许保存直接的（也就是邻接的）等级链接信息，这对很多任务来说是必须的（例如，建立一个知识组织系统不同类型的可视化表示），同时也提供了方便查询这些等级链接的传递闭包（包括直接和间接链接）的机制，另外对其他一些任务很有用（例如，查询扩展算法）。

也要注意传递属性的子属性没必要是传递性的。

参见下面关于其他路径的注释。

8.6.7. skos:broader和自反性

注意，本技术规范没有规定skos:broader关系的自反性特征。既没有规定skos:broader是自反性属性，也没有规定它是非自反性属性。因此，对任何图和资源<A>，三元组：

可以存在，也可以不存在。这种保守的态度允许SKOS用于把skos:broader定义成具有自反性的知识组织系统（例如，一个被推理的OWL子类等级的直接翻译），或者把skos:broader视为具有非自反性的知识组织系统（为了适合于大部分叙词表或分类表）。

同样的，也没有关于skos:narrower具有自反性或非自反性的断言。

但是，对于知识组织系统的许多应用来说，X skos:broaderX或Y skos:narrowerY的声明形式存在一个潜在的问题。具体情况中，一个应用软件可能希望在处理SKOS数据之前检索这些声明，但是本技术规范中没有定义应用软件应该如何处理这种声明，应用软件之间可能会有所不同。

8.6.8. 等级关系的循环（skos:broader的传递性和自反性）

在下图中，声明了等级关系中的一个循环。注意该图符合SKOS数据模型，也就是，不需要skos:broaderTransitive具有非自反性的条件。

但是，对使用知识组织系统的许多应用来说，等级关系中的循环存在潜在的问题。计算skos:broaderTransitive传递闭包，查找X skos:broaderTransitive X声明形式是发现等级关系中存在循环的一个便利策略。本技术规范中没有定义应用软件应该如何处理这种声明，应用软件之间可能会有所不同。

8.6.9. 等级关系中的其它路径

在下图中，从A到C的等级关系有两个可选的路径。

在下图中，从A到D的等级关系有两个可选的路径。

这是复合等级式(poly-hierarchical)知识组织系统中自然产生的一种模式。

上面的两个图都符合SKOS数据模型，也就是说，不需要这样的条件：在具有等级关系的两个节点之间仅存在一条路径。

8.6.10. skos:related和skos:broaderTransitive的不相交性

本技术规范认为等级关系和相关关系在本质上是不同的。因此，等级关系和相关关系之间存在冲突就不符合SKOS数据模型。上面的示例说明了冲突发生的一些情况。

这遵守叙词表标准[ISO2788][BS8723-2]对等级关系和相关关系的通常定义，支持许多现有知识组织系统的常见应用。

注意，本技术规范采取更加严格的立场，不仅直接的（也就是紧接的）等级关系和相关关系之间不相交，相关关系也必须与间接的等级关系不相交。这种约束通过skos:related和skos:broaderTransitive是不相交属性的完整性条件断言正式获得。

9. 概念集合

9.1. 序言

SKOS概念集合用于为SKOS概念组贴标签和排序。

集合对以下情况很有用：当一组概念共享某些属性时，很方便就能在一个通用标签下把这些概念归成一类，或者以某种有意义的顺序排列一些概念的情况。

9.2. 词汇

9.3. 类与属性定义

9.4. 完整性条件

9.5. 示例

下图说明了一个拥有3个成员的SKOS集合。

下图说明了一个拥有3个成员的SKOS有序集合。注意这里使用了Turtle语法 (...)，表示为一个RDF集合（列表）。

9.6. 注释

9.6.1. 从有序集合中推导集合

S36声明了skos:memberList和skos:member属性之间的逻辑关系。这种关系意味着一个集合可以从一个有序集合中推导出来。下例加以说明。

注意，SKOS没有提供任何方式来明确声明一个集合是无序的。

9.6.2. skos:memberList（成员列表）的完整性

注意，skos:memberList是一个功能性属性，也就是，它只能有一个值，包含多个成员列表的有序集合是没有意义的。不幸的是，如果不能明确地声明两个列表是不同的对象，就无法利用这个条件作为一个完整性条件。换句话说，尽管下图符合SKOS数据模型，但推导毫无意义(带有两个第一元素和一个叉状尾巴(forked tail)的列表)。

但是，如[RDF-SEMANTICS]中第3.3.3节规定的，RDF的语义扩展可以为RDF集合词汇(rdf:first， rdf:rest， rdf:nil)的使用提供附加的句法结构完整性限制，从而避免出现上图中的情况。

9.6.3. 嵌套集合

在下例中，一个集合被嵌套在另一个集合中。

该例符合SKOS数据模型，因为skos:member的值域是skos:Concept和skos:Collection的并集（union）。

9.6.4. SKOS概念、概念集合和语义关系

在SKOS数据模型中，skos:Concept和skos:Collection是不相交的类。SKOS语义关系属性的定义域和值域是skos:Concept。因此，如果任何SKOS语义关系属性（例如，skos:narrower）用于链向或链自一个集合，那么此表不符合SKOS数据模型。

下例说明了不符合SKOS数据模型的这种情况。

同样，下图也不符合SKOS数据模型。

同样，下图也不符合SKOS数据模型。

但是，下图符合SKOS数据模型。

这表示，对那些使用节点标签（node labels）来系统化显示的叙词表或其他知识组织系统来说，需要认真考虑合适的SKOS表征。此外，以系统化显示的节点标签，并不总能仅用SKOS表征 来完全重建。以系统化显示，完全表征一个叙词表或其他知识组织系统的所有信息，包括版面和外观的细节，不在SKOS处理范围之内。

10. 映射属性

10.1. 序言

SKOS映射关系属性包括skos:closeMatch、skos:exactMatch、skos:broadMatch、skos:narrowMatch和skos:relatedMatch。这些属性用于声明不同概念体系中SKOS概念之间的映射链接，这些链接是相关概念含义中所固有的。

skos:broadMatch和skos:narrowMatch属性用于声明两个概念之间的等级映射链接。

skos:relatedMatch属性用于声明两个概念之间的相关映射链接。

skos:closeMatch属性用于链接两个十分相似的概念，这两个概念可在一些信息检索应用中相互替换。为了避免跨多个概念体系映射时出现“合成错误”的可能，skos:closeMatch不被声明为一个传递性属性。

skos:exactMatch属性用于链接两个概念，表明在广泛的信息检索应用中，概念在很大程度上可以交替使用。skos:exactMatch是一个传递性属性，是skos:closeMatch的子属性。

10.2. 词汇

10.3. 类与属性定义

10.4. 完整性条件

注意，因为skos:exactMatch是对称性属性，skos:broadMatch和skos:narrowMatch互逆，因此skos:exactMatch与skos:narrowMatch不相交。

10.5. 示例

下图断言了<A>和 <B>之间的一个完全等价映射链。

下图断言了<A>和<B>间的一个近似等价映射链接。

下图断言了<A>和<B>之间的一个等级映射链接（<B>是<A>)的上位映射概念），以及<A>和<C>之间的一个相关映射链接。

下图不符合SKOS数据模型，因为在完全等价和等级映射链接之间存在一个冲突。

下图不符合SKOS数据模型，因为在完全等价和相关映射链接之间存在一个冲突。

10.6. 注释

10.6.1. 映射属性、语义关系属性和概念体系

通常，SKOS映射属性仅用于链接不同概念体系的概念。但是，使用SKOS语义关系属性（skos:broader、skos:narrower、skos:related）链接不同概念体系的概念也符合SKOS数据模型（见第8节）。

映射属性skos:broadMatch、skos:narrowMatch和skos:relatedMatch在下面情况中十分有用：已知数据的出处，要立即区分一个概念体系中的内部链接和不同概念体系间的映射链接。

但是，使用SKOS映射关系属性不能代替RDF图的细致管理，也不能代替数据起源机制(provenance mechanisms)的使用。

这种设计的合理性在于，很难在一个概念体系中的内部链接和不同概念体系间的映射链接之间做出绝对的区分。在一个开放环境中，不同人可能以不同的方式 把概念组织重新组织成概念体系。某个人认为两个概念体系间的映射链接在另一个人那里可能认为仅是一个概念体系内部的链接。本技术规范允许这两种观点共存， 这（有望）提高在网络上重用SKOS数据的灵活性和创新性。

因此，SKOS语义关系属性和SKOS映射关系属性之间存在密切联系。skos:broadMatch是skos:broader的子属性，skos:narrowMatch是skos:narrower的子属性，skos:relatedMatch是skos:related的子属性。子属性关系的完整集如下所示：

skos:semanticRelation
 |
 +- skos:related
 |   |
 |   +- skos:relatedMatch
 |
 +- skos:broaderTransitive
 |   |
 |   +- skos:broader
 |       |
 |       +- skos:broadMatch
 |
 +- skos:narrowerTransitive
 |   |
 |   +- skos:narrower
 |       |
 |       +- skos:narrowMatch
 |
 +- skos:mappingRelation
     |
     +- skos:closeMatch
     |   |
     |   +- skos:exactMatch
     |
     +- skos:relatedMatch
     |
     +- skos:broadMatch
     |
     +- skos:narrowMatch 

下例说明了从子属性树和skos:semanticRelation的定义域与值域推导出一些结论。

注意，因为不同的人可能以不同的方式把概念重新组织成概念体系，一个图可能会断言相同概念体系中概念间的映射链接，在SKOS数据模型中没有正式的完整性条件来验证该图不符合SKOS数据模型，例如下图就符合SKOS数据模型。但是，在实践中希望该图仅用于合并来自不同来源的两个或多个图的情形。

10.6.2. 等级映射和相关映射链接之间的冲突

下例说明了等级映射和相关映射链接之间的“冲突”，这不符合SKOS数据模型（这是因为前面所示的子属性关系和第8节中定义的SKOS语义关系属性的数据模型）。

10.6.3. 映射属性和传递性

唯一被声明具有传递性的SKOS映射属性是skos:exactMatch。下图是一个推导示例：

所有其他的SKOS映射属性都是非传递性的。因此，下例所示的推导不被SKOS数据模型支持。

10.6.4. 映射属性和自反性

SKOS映射属性既不具有自反性，也不具有非自反性。

因为skos:exactMatch、skos:broadMatch和skos:relatedMatch都不具有自反性，下图符合SKOS数据模型。

参见第8节SKOS语义关系属性的自反性。

10.6.5. skos:broadMatch的循环和其他路径

不存在阻止一个等级映射链接图中出现循环或其他路径的正式完整性条件。

下图有两个关于skos:broadMatch的循环，该图符合SKOS数据模型。

下图包含两个关于skos:broadMatch的其他路径。该图符合SKOS数据模型。

可参见第8节关于skos:broader所涉及的循环和其他路径。

10.6.6. skos:exactMatch和skos:closeMatch的循环

由于上面的推导（来自S42、S44和S45的组合），应用软件必须能够处理skos:exactMatch和skos:closeMatch中的循环。

10.6.7. skos:exactMatch的子属性链

在SKOS数据模型中没有关于skos:exactMatch或skos:closeMatch属性的子属性链公理。因此不支持如下所示的推导。

附录 A. SKOS属性与类

附录 B. SKOS标签扩展（SKOS-XL）

附录B定义了SKOS的一个可选扩展——SKOS标签扩展（SKOS-XL）。该扩展提供识别、描述和链接词汇条目的额外支持。

词汇条目定义为skosxl:Label，每个实例是单一的RDF普通文字形式。即使采用同样的文本形式，它们也不一定是同一资源。

定义了三个标签属性，skosxl:prefLabel、skosxl:altLabel和skosxl:hiddenLabel。这些属性使用skosxl:Label的实例给SKOS概念打上标签，可以与SKOS中的skos:prefLabel、skos:altLabel和skos:hiddenLabel属性形成类比。

SKOS数据模型也提供skosxl:labelRelation属性。该属性用于断言skosxl:Label实例之间的直接链接，主要意图是作为一个扩展点，根据具体链接类型细化。虽然示例中提供了一些演示，但具体的skosxl:labelRelation内建类型并未提供。

B.1. SKOS-XL命名空间与词汇

The SKOS-XL的命名空间URI是：

• http://www.w3.org/2008/05/skos-xl#

skosxl:前缀是SKOS-XL命名空间URI的简写。

SKOS-XL词汇由下表左侧列给出的一组URIs组成。

这里的“SKOS-XL词汇”包括SKOS词汇与SKOS-XL词汇两者。

“XL数据模型”仅是指附录B中定义的类和属性。SKOS+XL数据模型包括第3-10节定义的数据模型和此处的XL数据模型。

B.2. skosxl:Label类

B.2.1. 序言

skosxl:Label是词汇条目的具体类。

skosxl:Label实例是一个资源，可以用URI来命名。

skosxl:Label实例是单一的文本形式。这个文本形式一个RDF普通文字，即UNICODE字符串和可选的语种标识[RDF-CONCEPTS]。skosxl:literalForm属性用于skosxl:Label的文本形式。

即使skosxl:Label的两个实例拥有相同的文本形式，它们也不一定是同一资源。

B.2.2. 类与属性定义

B.2.3. 示例

以下示例描述了skosxl:Label的URI是<http://example.com/ns/A>，文本形式是英语的“love”。

以下四个示例都不符合XL数据模型，因为skosxl:Label用两个不同的文本形式进行描述。

B.2.4. 注释

B.2.4.1. 识别与蕴含

如上声明中每个skosxl:Label实例有且仅有一个文本形式。换句话说，这是skosxl:Label扩展映射到RDF普通文字的功能。这个功能通过skosxl:literalForm属性扩展定义。注意该功能的两个事实。

首先，这个功能不是单射的(injective)。换句话说，不存在skosxl:Label实例到RDF普通文字一对一的映射（实际上是多对一）。这意味着拥有相同文本形式的skosxl:Label两个实例也不一定是同一个体。因此，XL数据模型不支持以下的示例。

其次，这个功能不是满射的(surjective)。换句话说，对于给定普通文字1，可能不存在带有文本形式1的skosxl:Label的任何实例。

B.2.4.2. 概念体系成员

SKOS概念体系中skosxl:Label的实例成员采用skos:inScheme属性声明。

B.3. 首选、非首选和隐藏标签

B.3.1. 序言

skosxl:prefLabel、skosxl:altLabel和skosxl:hiddenLabel三个属性分别用于一个资源的首选、非首选和隐藏标签，这些标签是skosxl:Label的实例，可以与SKOS词汇中的相同名称词汇类比。以下定义的两个属性集之间存在逻辑依存关系。

B.3.2. 类与属性定义

B.3.3.示例

以下示例展示了三种标签属性的用法，符合SKOS+XL数据模型。

B.3.4. 注释

B.3.4.1. SKOS词汇标签转化（Dumbing-Down）

子属性链公理S55、S56 和S57支持XL标签通过推理的方式转化为SKOS词汇标签，如下例所示。

B.3.4.2. SKOS+XL标签完整性

在第五节中，SKOS基础标签属性定义了两个完整性条件。首先，skos:prefLabel、skos:altLabel和skos:hiddenLabel属性两两不相交。其次，一个资源的每个语种有且仅有一个skos:prefLabel。由于以上定义的子属性链公理，以下四个示例，符合XL数据模型，但不符合SKOS+XL数据模型。

B.4. skosxl:Labels链接

B.4.1. 序言

这部分定义了表征skosxl:Label实例间二元链接的一种模式。

注意，这部分定义的词汇不能直接使用，只是作为一个扩展点，根据具体标签应用场景再做细化。

B.4.2. 类与属性定义

B.4.3. 示例

以下示例说明了skosxl:Label类的两个实例之间的链接。

B.4.4.注释

B.4.4.1.模式限定

如上提到的，skosxl:labelRelationskosxl:labelRelation属性提供一个扩展点，根据具体标签应用场景做细化。

下面的示例中，第三方限定了skos:labelRelation属性用来表达首字母缩写词，例如"FAO"是“Food and Agriculture Organization”的缩写词。

注意，对称性属性的子属性不一定是对称的。

B.5. SKOS-XL Schema概览

SKOS-XL词汇概览如下表所示。

附录 C. SKOS和SKOS-XL命名空间文档

根据万维网架构第一卷[WEBARCH]，命名空间文档是机器与人可用的包含有关命名空间术语信息的信息资源。

SKOS词汇是通过命名空间URIhttp://www.w3.org/2004/02/skos/core#识别的概念资源。SKOS词汇的规范定义可以在SKOS参考中找到。

以下的命名空间文档提供SKOS词汇表征的其他方式：

C.1. SKOS命名空间文档 — HTML版本(规范的)

SKOS命名空间文档的HTML版本[SKOS-HTML]总结了SKOS词汇，通过命名空间URIhttp://www.w3.org/2004/02/skos/core#的内容协商机制，采用“词表发布最佳实践”[RECIPES]的方案3。客户端请求HTML或XHTML时，HTTP请求的头部包含相应的“Accept”。除此之外，SKOS命名空间文档的HTML版本可以直接通过URI：http://www.w3.org/TR/skos-reference/skos.html访问。

SKOS命名空间文档的HTML版本复制了附录A. SKOS属性与类。

C.2. SKOS命名空间文档 — RDF/XML版本 (规范的)

SKOS命名空间文档的RDF/XML版本[SKOS-RDF]以RDF元组（尽可能）表示了SKOS词汇和数据模型。通过内容协商机制，采用词表发布最佳实践的方案3[RECIPES]。客户端请求RDF/XML时，HTTP请求的头部包含相应的“Accept”。除此之外，RDF Schema通过URI：http://www.w3.org/TR/skos-reference/skos.rdf直接访问或下载。

用RDF三元组表示SKOS数据模型的所有声明是不能的，因此RDF Schema只是SKOS参考的一个规范子集。RDF Schema定义为OWL Full ontology[OWL-SEMANTICS][OWL-REFERENCE]。SKOS词汇定义为这个本体的实例。

C.3. SKOS RDF Schema - OWL 1 DL子集（有益的）

为方便工具与应用在OWL DL约束下使用， SKOS RDF Schema(OWL 1 DL子集)[SKOS-RDF-OWL1-DL]提供一个修正的、有益的Schema来符合OWL DL约束。注意，这个Schema里删除了违反OWL DL约束的公理元组，另外也做了一些精简。

SKOS OWL 1 DL子集通过URI：http://www.w3.org/TR/skos-reference/skos-owl1-dl.rdf直接访问。

C.4. SKOS-XL命名空间文档 — HTML版本 (规范的)

SKOS-XL命名空间文档的HTML版本[SKOS-XL-HTML]，总结了SKOS词汇，通过命名空间URI http://www.w3.org/2008/05/skos-xl#的内容协商机制，采用“词表发布最佳实践”[RECIPES]的方案3。客户端请求HTML或XHTML时，HTTP请求的头部包含相应的“Accept”。除此之外，SKOS-XL命名空间文档的HTML版本可以直接通过URI：http://www.w3.org/TR/skos-reference/skos-xl.html访问。

SKOS-XL命名空间文档的HTML版本复制了附录B SKOS-XL Schema概览。

C.5. SKOS-XL命名空间文档 — RDF/XML版本 (规范的)

RDF Schema文档通过URI http://www.w3.org/2008/05/skos-xl#以RDF三元组（尽可能）表示了SKOS词汇和数据模型。通过内容协商机制，采用“词表发布最佳实践”的方案3[RECIPES]。客户端请求RDF/XML时，HTTP请求的头部包含相应的“Accept”。除此之外，RDF Schema通过URI：http://www.w3.org/TR/skos-reference/skos-xl.rdf直接访问或下载。

附录 D. SKOS命名空间：历史注释

SKOS Schema采用命名空间http://www.w3.org/2004/02/skos/core#定义SKOS词汇。这个命名空间曾用于定义SKOS Schema，作为这份推荐的起点。鉴于此，之前版本的机器可读的SKOS Schema中的元素已经从当前版本中删除。SKOS Schema中的一些类的元素定义和语义已经发生改变。

保留现有的SKOS命名空间是为了避免与已经采用SKOS编码的KOS发生冲突。用户应该意识到skos:broader和skos:narrower语义的变化可能对SKOS应用产生影响。

已删除的元素在SKOS Schema中没有明确的反对公理表示。SKOS Schema的历史版本在SKOS网站"版本历史"页面上。当前版本中被删除的元素如下：

• skos:symbol
• skos:prefSymbol
• skos:altSymbol
• skos:CollectableProperty
• skos:subject
• skos:isSubjectOf
• skos:primarySubject
• skos:isPrimarySubjectOf
• skos:subjectIndicator

关于skos:broader和skos:narrower，词汇元素的语义已经发生改变，这两个属性不再声明为传递性的，因此以下的推导不成立。

skos:broaderTransitive是skos:broader的传递性父属性，它允许跨越skos:broader关系的传递性闭包查询。类似的，skos:narrowerTransitive允许跨越skos:narrower关系的传递性闭包查询。