近阶段有一个知识图谱的项目，这部分内容了解不太多，所以参考了前同事的项目，去图书馆借了七八本书，再下载一堆论文，经过一两个星期的调研，最后决定以蚂蚁集团+OpenKG的开源框架OpenSPG为基础，进行某垂直行业的知识图谱模块开发。项目刚进入本体模型构建阶段，在参考传统知识模型本体构建的基础上，遵循OpenSPG的建模最佳实践进行本体模型构建，刚好整理一篇文档，作为这一阶段设计开发工作的小结。
一、传统知识图谱中的本体模型
1、本体模型概念
1993年，GRUBER为本体下了一个被业内广泛认可的定义，即“本体是概念模型的明确规范说明”。
而NECHES等人对本体给出了更具实践性的定义：“给出构成有关领域词汇的基本术语和关系，并运用这些术语和关系组成规定这些词汇外延的法则”。其中“领域”是指本体所描述的特定领域，如项目涉及的垂直领域；“术语”是指特定领域中的重要概念，如领域中的生产过程、生产对象、生产设备、生产技术等；“关系” 是指基本术语之问的关系，可理解为类的层次结构，如术语“生产设备”中包含了“制氧器”、“投喂器”，“制氧器”具有“制氧”这一用途属性；词汇外延法则是指对本体的约束，包括值约束、不相交描述、属性约束等。
本体属于知识图谱中的模式层，决定了知识图谱的数据模型，其结构可以理解为知识图谱的框架。
所谓的模式层，是知识图谱的常用逻辑结构分层，一般分为数据层和模式层，数据层由一系列事实构成，一般基于图数据库以三元组的形式进行存储。模式层建立在数据层之上，通常采用本体（Ontology）进行规范。
本体一般的构成要素主要有：类、属性、关系。
- 类class，对客观存在进行抽象，即得到概念，使用自然语言对概念进行描述，并使用框架结构进行定义，形成类，如公司、书籍等；
- 属性property，描述概念自身的特性，如公司的名称、法人，书籍的书名、作者等；
- 关系relation，表明不同本体之间的各种关系，最基本的关系有四种：part-of，部分与整体的关系；kind-of，某概念是另一概念的一个种类；instance-of，表明某概念是另一个概念在现实中的一种具体存在，一个实例；attribute-of，表示某概念是另一个概念的一个属性。
另外，对应于类的具象化，或者说每个类的个体，叫做实例，举例如：“公司”是类，“中国移动”就是“公司”的实例，基本上可以对应于面向对象概念中的“类”和“对象”。
2、本体模型构建步骤
（1）构建模式选择
知识图谱的构建一般分为自顶向下（top-down）和自底向上（down-top）两种模式。
自顶向下是指先设计本体和模式层，再将结构化数据事实加入到知识库里。自底向上是指采用数据驱动方式，从公开数据集中选择一些置信度较高的信息加入到知识库中，构建知识图谱的模式层。
自底向上的方法一般用来建立通用领域知识图谱，例如Google的KnowledgeVault。
如果对于垂直领域的本体，即使是包含了成千上万个通用和高级概念的大型本体，仍然不足以表达特定领域的概念和层次关系，所以垂直领域的知识图谱一般采用自顶向下的构建模式 更合适，即先进行进行本体建模，完成模式层的构建。
下图是知识图谱构建的一般流程。
（2）参考构建步骤
骨架法，包含五步：先确定构建本体的目的，再进行概念、关系与属性等知识获取，之后进行知识处理，本体评估以及本体存储。
七步法，具体步骤有：首先确定本体的专业领域和范畴；考虑重用本体；列出相关的重要术语；定义类和类的层次结构；定义类的继承；最后创建实例。
六韬法，其中关联本体定义的有：对事物的分类，理清场景中需要处理哪些类型的事物；对事物类别的命名，要充分考虑命名的语义、外延和颗粒度；抽象出合适的特征，以属性来描述多维特征；如无必要，勿增实体；按照业务发展不断进行演化。
（3）典型本体描述语言和工具
最主要的标准包括资源描述框架RDF和网络本体语言OWL。
RDF全称为Resource Description Framework，由W3C发布和管理，将知识表示为“主语-谓语-宾语（SPO）的三元组集合，类似于有向图，图中有节点和边，节点对应实体，边对应关系或者属性，所谓的关系是指实体之间、实体与属性之间的关系。
因为源自W3C，所以URI也少不了，即每个资源都有唯一对应的资源标识符，通常由域名+路径名+资源名构成。
因为RDF层级少、元素少，无法清晰、体系地描述复杂的知识，于是就有了RDF Schema（RFD模式语言），它在RDF的基础上定义了类Class、属性Property以及关系Relation来描述资源，并定义了域Domain和值域Range来约束资源。
RDFS的语义表达能力有所提升，但在类与类之间只能声明子类关系，无法声明互斥类、多个类、属性等价等关系。
OWL（Ontology Web Language）网络本体语言是对RDFS关于描述资源词汇的扩展，添加了额外的预定义词汇来描述资源，可以声明资源的等价性，属性的传递性、互斥性、函数性、对称性等。
从下图的层级关系可以发现，OWL构建在语义层，包含了构建本体所需的很多原语，有助于实现本体图上的推理算法。
3、本体模型的不足
项目最初就先找到了RDF和OWL，也试用过Protege工具，但在学习和选型过程中发现两个较大的落地实践问题：
（1）本体建模从设计之初，在一个框架下，既包含对语义类别的建模，也包括实体对象的建模，将概念设计、分类设计、实现设计等过程用相同的模型进行展现，对于设计人员、开发人员、维护人员都不太友好，在使用过程中需要多次切换思考维度，理解、设计、开发、维护的复杂度大大增加，更适宜作为研究而不是实践。
（2）除了（1）中提到的问题外，因为知识图谱在工程实践中的标准化程度不够，设计、开发、维护都缺少可参照的实施规范，如果要在项目中自行制定并遵循，对开发团队的要求会过高。
正是考虑到以上情况，经过技术比较和选型，选择了OpenSPG，因为它在传统知识图谱的基础上，结合蚂蚁集团的实际应用场景，与国内重点高校联合进行了优化，对本体模型进行了调整，也提供了项目落地的最佳实践指导，虽然在设计和开发过程中会有更多的约束，但从降低开发难度、提升开发效率方面能得到更多的保证。
二、OpenSPG项目中的本体模型构建
1、本体概念的调整
OpenSPG吸收了关于本体的概念，但有进行了很大的调整，将本体进行了拆分，按照“概念”、“实体”、“事件”进行了分类，还有一种类型“标准”，我倒认为并不算一种分类，只是值域类型的扩充，如将字符串延伸出邮箱、身份证号码等。
正如上面所分析的，原来本体的含义太宽泛，真正落实到工程开发中太容易混淆，恰当的分类及相关约束更有助于设计、开发、运营、维护人员达成共识并提升效率。
（1）实体类型EntityType
定义了具有共同数据结构（特征）的一类实例的集合，是一种多元要素的复合节点类型，通常用来描述客观世界中的一个具体事物，如公司、学校、书籍等。
实体类型由属性和关系组成，属性的值域可以是文本、整数、浮点数等，也可以是概念、实体等高级类型。实体类型的默认属性为id、name，description，无须额外定义系统会自动生成。
注：不过从开源文档上没有看到description的自动生成，存疑中。
在自己定义实体属性时，属性名称不能与默认属性名称相同，否则schema提交时会报错。
（2）事件类型EventType
事件类型是在实体类型的基础上，加入主体、客体、时间、空间这四类要素，是对动态行为的建模，可描述不同空间、时间区间上事物的状态，如政策事件、行业事件、用户行为事件等。其中主体要素是必须具备的，其余要素可选。
（3）概念类型ConceptType
概念是对一类具有共同特征的实体的抽象化描述，通常用于描述实体/事件类型的分类。概念的默认包含属性name（必填）、alias、stdId（标准Id），不允许再创建其他属性。
（4）标准类型StandardType
是系统内置的用于描述属性类型的特殊定义，通过正则约束对属性进行标准化。简单类比就是语言中的扩展类型定义，如手机号、邮箱、身份证号码等。
2、建模最佳实践的七条原则
原则1：复杂多元结构用实体类型或事件类型
原则2：扁平化的分类标签用概念类型
原则3：实体/事件多类型使用动态分类原则
原则4：概念类型不继承
原则5：关系的指向遵守由动到静原则，反之被禁止
原则6：概念类型之间只允许系统指定的7大类语义关系
原则7：属性尽量标准化
经过团队讨论学习，我们认为真正属于最佳实践的是第三条和第七条，因为这两条涉及具体主体定义/设计时的策略，而其他原则本质上都是定义的说明和延伸，即更多的是约束，而不是指导。
为了快速开发MVP，我们建立了项目本体建模的最佳实践准则如下：
（1）概念类型的层级暂定三级或三级以内，以更好地控制实体数量；
（2）实体类型的继承层级暂定三级或三级以内，减少实体设计的复杂度；
（3）事件类型本期先控制在政策发布、行业新闻、市场价格、病虫害、生产环节等五类事件，后续再按需添加。
（4）实体/事件多类型使用动态分类原则（原则3）
（5）属性尽量标准化（原则7）
3、建模工具和实操
之前整理了一篇关于OpenSPG本地搭建的文章，在Github上也提过一个关于前端页面的Issue，遗憾地发现，前端可视化部分还没有开源，只能用公司现有的前后端框架与OpenSPG进行整合了。
具体策略如下：
（1）本体建模由架构师直接使用Visual Code即IDE直接编辑，参考sample项目（经济、供应链、医药等）中的schema范例，来编写本项目所在垂直业务领域的本体模型，包括概念、实体、属性、关系等内容，内部评审通过后，使用knext正式提交到服务器。
（2）将OpenSPG的可视化前端以界面整合的方式，集成到公司现有前端框架，以iframe形式直接调出OpenSPG页面，可以使用可视化方式进行本体模型的查看，不提供修改功能。
（3）在后端代码层面，将开源组件中的通用组件如MySQL、ElasticSearch与公司现有版本组件进行合并，同步双方的数据库表结构和内容，必要时修改服务器配置信息并进行对应的JAR包文件替换。这部分内容与建模关系不大，属于项目部署实施相关内容，不在本文中展开详述。