知识图谱本体层理解及利用Protégé进行知识图谱本体层(Schema)的构建

2020/10/22 knowledge graph knowledge graph construction 共 7307 字,约 21 分钟

知识图谱基本概念

知识图谱是以图结构来存储数据及其关联关系的,用于以符号主义(Symbolism)的形式描述物理世界中的概念及其关联关系,其基本组成单位是<实体,关系,实体>三元组,和实体及其相关属性的属性值对,实体之间通过关系相互联结,构成网状的知识结构。

知识图谱、体系和结构

说到知识图谱,很容易混淆的一些概念是知识、知识体系、语义网和语义网络。下面我根据自己的理解作简单的陈述。

  • 知识图谱:一般在知识图谱的领域,认为一例知识是一个<实体,关系,实体>或者<实体,属性,属性值>三元组,而这些三元组组成的集合被称为知识图谱
  • 知识体系:一般是指用于描述我们所要构建的知识图谱所在领域的知识,这种描述是一种概括和抽象,通常用概念,概念属性以及概念之间的关系来描述。知识图谱的Schema一般是知识体系的一种表达。

知识结构的概念也经常出现,我认为可以用知识体系来代替,但也可以理解成知识图谱是一个特定领域的知识结构。我认为,知识结构表示知识图谱的结构的意思更为合理。

语义网络和语义网&链接数据

下面介绍语义网络,语义网和链接数据,以及它们之间的异同。

语义网络

由Quillian于上世纪60年代提出的知识表达模式,其用相互连接的节点和边来表示知识。节点表示对象、概念,边表示节点之间的关系。作为初代的关联关系网络,具有以下的一些缺点。

  1. 节点和边的值没有标准,用户需要自拟;
  2. 多源数据因为没有标准,融合难;
  3. 无法区分概念节点和对象节点。
  4. 无法对节点和边的标签进行定义。

简而言之,语义网络可以比较容易地让我们理解语义和语义关系。但是由于其缺少规范性和缺少节点的划分所以存在不少的问题。因此,W3C提出一系列技术栈对这些问题进行解决,其中OWL和RDF是最先出现的。

  • RDF的提出解决了语义网络的缺点1和缺点2,在节点和边的取值上做了约束,制定了统一标准,为多源数据的融合提供了便利。另外,RDF对is-a关系进行了定义,即,rdf:type(是rdf标准中的一个词汇,之后的文章会介绍)。因此,不管在哪个语义网络中,表达is-a关系,我们都用rdf:type,在语法上形成了统一。

  • 定义Class和Object(也称作Instance, Entity)。W3C制定的另外两个标准RDFS/OWL解决了这个问题,这个就是属于语义网的范畴。

语义网

语义网正是为了使得网络上的数据变得机器可读而提出的一个通用框架。语义网是一个更官方的名称,也用于指代其相关的技术标准。为了解决语义网络的缺点,在语义网技术栈中,RDFS和OWL是RDF更上一层的技术,主要是为了解决语义网络的缺点3和缺点4,其提供了schema层的描述。这里只需要知道,通过RDFS或者OWL中的预定义词汇,我们可以形式化地声明一个类:

哺乳动物 rdf:type rdfs:Class
哺乳动物 rdf:type owl:Class

语义网络指Semantic Network,语义网指Semantic Web。语义网和链接数据是万维网之父Tim Berners Lee分别在1998年和2006提出的。相对于语义网络,语义网和链接数据倾向于描述万维网中资源、数据之间的关系。

链接数据

链接数据起初是用于定义如何利用语义网技术在网上发布数据,其强调在不同的数据集间创建链接。通常用来展示当前开放知识图谱的规则、涉及的领域以及知识图谱之间的链接关系。例如wikidatadbpedia的关联关系一般认为构成链接数据。

THE 知识图谱

从语义网的脉络来定义知识图谱,知识图谱是由本体作为Schema层,和RDF数据模型兼容的结构化数据集。

本体

本身是个哲学名词,在1998年对本体进行了比较完善的定义:本体是共享概念模型的明确的形式化规范说明。这个定义体现了本体的四层含义:概念模型、明确、形式化、共享。

  • 概念模型:通过抽象出客观世界中一些现象的相关概念而得到的模型。
  • 明确:所使用地概念及使用这些概念的约束都有明确的定义。
  • 形式化:本体可通过各种形式化语言对其进行描述,最终是计算机可读、可操作的。
  • 共享:本体中体现的是公认的知识,反映的是相关领域中公认的概念集。本体的目标是通过确定该领域内共同认可的词汇,达到对该领域知识的共同理解。

要构建本体,本体库需要有以下5个基本的建模元语:

  1. 类或概念:从语义上将,它表示的是对象的集合,其定义一般采用框架结构,包括概念的名称,与其他概念之间的关系的集合,以及用自然语言对概念的描述。
  2. 关系:在领域中概念之间的相互作用,形式上定义为n维笛卡尔积的子集。在语义上关系对应于对象元组的集合。
  3. 函数:一类特殊的关系,该关系的前n-1个元素可以唯一决定第n个元素。
  4. 公理:代表永真断言,如概念乙属于概念甲的范畴。
  5. 实例:代表元素,从语义上讲实例表示的就是对象。

综合来看知识图谱由本体结合具体知识实例,我们需要有:

  1. 用IRI唯一表示的节点都是某个类的实例。
  2. 每一条边都表示一个关系。
  3. 关系又可以是实体的属性。根据是实体与实体的关系还是实体与字面量的关系分为对象属性(Object Property)和数据属性(Data Property)。

Schema @ 知识体系

所谓的知识体系,其实就是描述我们所要构建的知识图谱所在领域的知识,这种描述是一种概括和抽象,通常用概念,概念属性以及概念之间的关系来描述。

如何确定Schema的信息

  • 构建域:域(domain)的概念是之于所有类型之上,对于域的定义应该尽量的抽象,不应该具体,同时域与域之间应尽量做到相互独立,不交叉。例如,省份就不应该是一个域的概念,在思考是否应该把一个概念当做域时,需要考虑到该概念是否能够继续向上抽象,例如:省份;城市;国家;县等等,他们同属于地理位置域。在明确域的概念时,应该定义好域的边界,这样比较容易区分不同域之间的区域划分。

  • 确定域的类型:类型(type)至于schema,需要知道schema的核心需求是什么,为了满足这些核心需求,我们需要创造出哪些概念。在NBA领域,用户主要关心球队、所属联盟、教练、球员等等。针对不同的需求,需要在域下面构建不同的类型来满足用户的需求。

  • 确定属性:设计本体(property)思考的角度以用户需求为出发点,以数据统计为证据。比如在构建完篮球领域中的球队类型后,该类型集合了所有的球队实体,站在用户角度触发,用户会关注球队的哪些关系等。

具体可以参考这篇文章

知识体系构建方法-人工

目前来看,基本高质量的知识体系都只能通过人工构建。一般如下几个步骤构成:

  1. 确定领域,限定知识体系的知识范围。确定领域,了解业务场景,思考知识体系能够解决哪些业务问题,是第一件要做的事情。
  2. 罗列概念、属性以及关系,根据确定的领域,罗列出来在知识图谱中可能出现的概念、属性以及关系列表。实际上这是一个和业务高度相关的工作,要罗列出来这份列表,需要对知识图谱要解决哪些问题、如何使用这个知识图谱有明确的认识。
  3. 确定知识体系结构,当罗列出来了所有的概念、属性以及关系列表之后,需要对概念进行层次结构的分类。确定分类层级通常由两种方法:自顶向下和自底向上。自顶向下就是从最抽象的概念开始,逐层扩展添加各层概念。自底向上则是相反的过程。
  4. 定义属性及关系,定义好了概念之间的层次关系之后,就需要定义概念的属性以及概念之间的关系了。做到这一步,知识体系就基本构建完成了。
  5. 定义约束,概念的属性会有一些约束条件,需要定义好。例如,人的性别只能是“男”或者“女”,年龄应该是0-200之间的数值。

知识体系构建方法-自动

知识体系的自动构建,在面对结构化知识和非结构化知识时所采用的策略时不同的。

  • 结构化知识的知识体系构建:面对结构化的知识,知识体系构建的任务其实就是提炼出来结构化语料中蕴含的概念以及概念之间的关系。结构化数据通常存储在关系型数据库中,上述任务通常就变成了分析数据表中的字段内容、主键以及外键之间的关系。

  • 非结构化知识的知识体系构建:面对非结构化的知识,要自动化构建知识体系是一件难度非常大的事情。首先,要基于语料进行领域内概念的抽取。然后,基于上述过程抽取到的概念进行概念体系的构建以及概念属性关系的抽取。

知识体系(Schema)赋予知识图谱明确的语义信息,即概念的分类,概念的属性以及概念之间的关系等。通常,这些概念是后续知识抽取的前提,也是知识图谱进行知识推理的基础。虽然,知识体系个构建分为自动化和人工构建两种,目前比较有效的手段还是人工构建。

Schema优化与验证

Schema的构建原则有:

  1. 规范性:概念定义明确,客观,概念命名符合领域标准。
  2. 完全性:定义是完整的,完全能表达所描述术语的含义。
  3. 一致性:由概念定义的实例、约束得出的推论与概念本身的语义不会产生矛盾。
  4. 较大单调可扩展性:添加子概念时,不需要修改己有父概念的内容。
  5. 最小承诺:尽可能少的约束。
  6. 语义区分性:高层级别(meta-concept)语义区分度大,兄弟概念间的语义差别应尽可能小。

判断领域 Schema 是否优良的标准,在于能够广泛的建立领域内个场景、业务单元下数据的关联,并兼顾与领域外数据融合;减少数据冗余并为长路径推理提供的逻辑基础。领域 schema 在构建初期,是一个基于业务实际不断优化迭代的过程,直到 schema 的完全结构确定下来不再修改(可以继承),则可以基于此将领域知识结构化了。

对于知识图谱的Schema,分架构上的schema,和基于架构上的schema进行业务梳理的实例化,第一点是技术选型底层设计息息相关,第二点是基于第一点进行的业务数据构建。可以说一个是系统Schema,一个是业务Schema。

Protégé

Protégé是一个免费的开源本体编辑器和用于构建智能系统的框架,有利于我们构建知识图谱的本体层(Schema)。Protégé在生物医学,电子商务和组织建模等各个领域都有构建基于知识的解决方案的案例。简而言之,Protégé是一个规范化的本体信息管理软件。 Protégé

Protégé的安装部署

Protégé的下载地址是:PRODUCTS FOR Protégé根据自己的平台选择安装,下面仅对Windows版本的安装进行介绍。或者参考ProtégéWiki。这里提供Windows版本的下载链接

安装JAVA

Protégé依赖于JAVA的运行环境,因此需要安装JRE(JAVA Running Environment)

可以参考廖雪峰的官方网站对JAVA编程的指导。

安装Protégé

通过下载Windows版本的ZIP包,实际上是一个绿色安装的版本,解压到本地就可以直接双击Protege.exe进行使用了。

下面依照沉积岩的知识体系使用Protégé进行知识图谱Schema层的构建。这里也附上官方文档

构建实例–以沉积岩的知识体系为例

这里使用下图中的信息进行的使用举例

  • 新建项目,打开Protégé的主界面就是默认的一个空白新项目。
  • 修改IRI 修改自定义的IRI,设置成自己的项目,一个知识体系统一使用一个IRI。
  • 新建类,Protégé的主页面中会出现 Classes(OWL类)、Properties(属性)、Forms(表单)、Individuals(个体)、Metedata(元类)几个标签。如果没有的话,到菜单栏的 Window-Tab 下进行选择选择OWL Classes。在Asserted Hierarchy(添加阶层)中,会有所有类的超类 owl:Thing,单击Asserted Hierarchy旁边的【Create subclass】或者右击“OWL:Thing”选择“add subclass”。会出现Protégé自动定义名为Class_1的类。在对话框中,【Name】一栏输入名字“Genetic models of dolostone”等可以被认为是类的名字。
  • 新建子类,右击“Thing”,选择“add subclass”,将名字改为“CaR1”。然后建立CaR1的另一个子类“CaR2”,最后建立CaR2的子类“Dolostone”。

    综合上面两步得到:

  • 新建类之间关系,因为Dolostone和Genetic models of dolostone是不同的事物,但它们具有“形成于”的关系。下面定义这个关系。在Entities选中Object properties的状态下,右下角Description中填充Domain和Ranges。

  • 新建属性,新建一个Object Property(注意不是 DataProperty),右击“Object Properties”,选择“add sub-Properties”,输入is_part_of,然后勾选“Transitive”复选框,说明这是一个传递性属性。
  • 关联类和属性,根据下图的关系可以建立一个Carbonate rock的子类Grains,并附加限制条件。在选择Grains的状态下,右击“subClass of”,在弹出的对话框中选择is_part_of。最后选择Carbonate rock,这样就定义了类Grains,它是Carbonate rock的一部分(is_part_of)
  • 可视化,在菜单栏中 Window-Tab 下进行选择,在出现的对话框中勾选【OntoGraf】复选框,出现新的标签。点击即可看到本体的结构。

最后文件的保存格式为OWL

<?xml version="1.0"?>
<rdf:RDF xmlns="http://acekg-dde.com#"
     xml:base="http://acekg-dde.com"
     xmlns:owl="http://www.w3.org/2002/07/owl#"
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:xml="http://www.w3.org/XML/1998/namespace"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
    <owl:Ontology rdf:about="http://acekg-dde.com"/>
     <!-- 
    ///////////////////////////////////////////////////////////////////////////////////////
    //
    // Object Properties
    //
    ///////////////////////////////////////////////////////////////////////////////////////
     -->
    <!-- http://acekg-dde.com#form_in -->

    <owl:ObjectProperty rdf:about="http://acekg-dde.com#form_in">
        <rdfs:domain rdf:resource="http://acekg-dde.com#Dolostone"/>
        <rdfs:range rdf:resource="http://acekg-dde.com#Genetic_models_of_dolostone"/>
    </owl:ObjectProperty>
    <!-- 
    ///////////////////////////////////////////////////////////////////////////////////////
    //
    // Classes
    //
    ///////////////////////////////////////////////////////////////////////////////////////
     -->
    <!-- http://acekg-dde.com#CaR1 -->

    <owl:Class rdf:about="http://acekg-dde.com#CaR1"/>
    
    <!-- http://acekg-dde.com#CaR2 -->
    <owl:Class rdf:about="http://acekg-dde.com#CaR2">
        <rdfs:subClassOf rdf:resource="http://acekg-dde.com#CaR1"/>
    </owl:Class>
    <!-- http://acekg-dde.com#Dolostone -->

    <owl:Class rdf:about="http://acekg-dde.com#Dolostone">
        <rdfs:subClassOf rdf:resource="http://acekg-dde.com#CaR2"/>
    </owl:Class>
    <!-- http://acekg-dde.com#Genetic_models_of_dolostone -->

    <owl:Class rdf:about="http://acekg-dde.com#Genetic_models_of_dolostone"/>
</rdf:RDF>
<!-- Generated by the OWL API (version 4.5.9.2019-02-01T07:24:44Z) https://github.com/owlcs/owlapi -->

更多功能可以参考医学知识图谱的构建指南以及官网的关于Classes的指南

如果使用OWLVis的可视化选项,可能会有实体堆叠在左上角的问题,这里提供一个CSDN博客中的解决方案

以上就是全部的构建内容。

Protégé推理部分Coming Soon,在这推荐一个知乎专栏

文档信息

Search

    Table of Contents