莫方教程网

专业程序员编程教程与实战案例分享

知识图谱开发(一)-本体模型构建_知识图谱实体类型

近阶段有一个知识图谱的项目,这部分内容了解不太多,所以参考了前同事的项目,去图书馆借了七八本书,再下载一堆论文,经过一两个星期的调研,最后决定以蚂蚁集团+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包文件替换。这部分内容与建模关系不大,属于项目部署实施相关内容,不在本文中展开详述。

控制面板
您好,欢迎到访网站!
  查看权限
网站分类
最新留言