知识图谱人物本体模型设计方法

来源:用户上传      作者:

　　摘要：人物本体在众多领域知识图谱中具有重要的作用，但目前人物本体设计较为简单，难以通用。本文通过人物相关案例构建小型的本体模型，分析其中存在的多元关系问题，结合多元关系的定义介绍多元关系的表示方法。对于在多元关系设计中存在不同设计方案，提出通过将本体模型部分映射为关系数据库，利用关系数据库N泛式原则优化多元关系设计。利用现有的本体模型基础上设计领域本体模型，在兼顾领域问题的同时保证扩展性和通用性，并基于Wikidata中的Human类设计，给出了本文中的人物本体泛式，专门针对地理位置和时间本体进行了优化设计。
　　关键词：本体模型;多元關系;领域图谱;知识图谱
　　0引言
　　知识是数据中有规律的信息和信息上下文的集合，知识的上下文表示信息之间的关系，知识具有经验性。为了让计算机可以存储和计算知识，上世纪五十年代学者提出的一种可以在计算机硬件中的存储和表示知识形式一语义网络（Semantic Network）。
　　语义网使用w3C制定的资源描述框架RDF（Resource Description Framework）作为知识表示的数据模型，在RDF中知识使用SPO二元组（Subject，Predicate，Object）的形式存储。目前比较知名的开放RDF知识数据库有DBpedia、Freebase等。RDF在发布之初定义了常用的Predlcate关系，通过固定的IRI表示，统一的IRI定义可以实现不同知识之间的共享。但RDF定义中可以表示的知识有限：RDF预定义的Predicate关系中没有区分概念和实体，也无法定义概念的属性和概念之间的关系，RDF仅能表示Subject和Object之间的关系，没有泛化和抽象的表达能力。为了提高知识表达范围，在RDF的基础上提出了RDFS（Resource DescriptionFramework Schema），在知识数据存储之前需要定义知识的概念和关系等，对知识概念和关系的定义成为本体模型（Ontology Model）。随后在RDFS的基础上，根据定义中的实际需求扩展了OwL（webOntologyLanguage）本体语法以及随后的OWL2，其中OwL相比于RDFS增加了数值属性和对象属性的不同定义。弥补了RDFS的定义中无法区分实体的属性以及实体之间的关系问题。OWL2在OWL基础上增加了角色链。双关等特性定义，规范了表达技巧。目前OWL2已经成为本体建模的推荐标准，国际万维网组织WWW（world Wildweb）负责本体描述语言的标准制定。
　　1 相关研究介绍
　　主流知识图谱大致可以分为通用知识图谱UKG和领域知识图谱DKG。UKG是面向全领域信息构建知识表示和关联关系，强调的是广度，而DKG是面向特定的垂直领域构建知识关系，对于数据有更严格的前置数据模式和准确度要求，强调的是深度。DKG在金融量化交易、学者信息搜索智能教育、历史研究、生物医学等垂直领域有广泛的应用。构建UKG和DKG时，两者之间的主要区别在于UKG一般使用“自底向上”的方法构建知识库，而DKG使用“自顶向下”的方法。UKG的“自底向上”方法体现在利用开放式关系抽取（Open Information Extraction，OIE），通过语法结构分析文本中的实体和关系构建二元组，构建DKG的“自顶向下”方法需要在设计之初首先确定待解决的领域问题，通过本体建模的方法明确问题的范围、包含的实体以及实体的属性和关系，并且根据领域内的规律构建推理规则。DKG与UKG之间相辅相成，DKG可以从UKG中获取通用性的知识。而DKG本身就是UKG在具体领域的丰富和延展。为了通用性，DKG在设计时需要考虑与UKG的兼容性。
　　近年来为了实现知识计算和共享，DKG的研究逐渐增多。文献[11]中介绍了目前自动构建本体模型的主要方法，通过自动识别实体，语法分析获取实体之间概念上的层级关系，文中指出目前自动构建方法主要针对层次关系（is-a关系）的构建，而对于应用中的领域本体模型。大量非层次关系更为重要。因此自动构建的方法只能在领域实体和概念的发现过程中有所帮助。
　　从目前本体模型的研究可以发现：
　　（1）自动化构建本体模型的方法主要应用于UKG中的层级关系，在DKG中大量的非层级关系仍无有效地自动化构建方法，以领域专家人工构建为主。
　　（2）DKG在各行各业中逐渐产生重要的作用，相比DKG指导工业应用和生产的价值更高。
　　（3）目前没有健全的DKG本体模型的构建思路和方法。ODP的设计理念可以提高领域模型的设计规范，但仍处于工业探索阶段，仍需要大量的领域专家构建不同的DKG积累量变，逐步到质变的过程。
　　（4）公开的ODP中关于人物、机构、事件的ODP研究较少，目前定义最完善的人物本体是Wikidata的Human定义，多元关系定义依赖于传统的百科词典的词条转化，为了保证兼容性，定义冗余程度高，表意区分度不明显。
　　本文主要研究人物本体应该如何在满足本体要求的情况下，精简概括地建模，并提出包含多元关系的人物、机构、事件相关的ODP，供构建领域知识图谱中与人物相关的本体模型参考。
　　2 人物本体建模案例分析
　　本体模型案例：“HA在2010年7月从OB学校计算机专业研究生毕业，HA的本科就读于OB校信息安全专业，2010年8月HA进入OD公司工作，刚人职就非常有热情。工作积极主动，在2012年12月的“年度公司综合竞赛”中获得第一名的成绩，很快在2013年4月升职为项目负责人，独立带领团队。2015年5月OD公司改组。HA离开OD公司进入OE公司担任大数据分析组项目负责人，并工作至今。HA的感情生活并不像事业那样如意，2011年12月HA与HF结束三年的爱情长跑步人婚姻，但是因为种种原因，在2014年4月协议离婚，在2015年进入新公司后。遇到HG让HA再一次激起了爱情的火花，2016年3月，HG与HA组成新的家庭，并在2017年10月喜得千金。 　　在例子中首先可以明确确定4个主要类别：Human人物类别、Organization机构类别、Event事件类别、Position职位类别，在Human与Organization关系中，还存在Position的职位属性，为了在知识库中进一步表示职位属性，需要综合考虑三个类别之间的关系。Postion属于Organization的组成属性，公司中一定会包含各种不同的职位从CEO、CTO到普通雇员、HR等。因此使用“hasPosition”属性关联Organization和Position。Human和Postion之间也可以通过类似“hasPosition”的方式关联。但是这样会产生歧义，如图1所示。由于RDF表示的知識中是没有时序性的，因此“ed。corn/human/1”通过“hasPosition"只能表示“ed。corn/human/1”曾经担任过“ed。com/pos/1”和“ed。com/pos/2”，但无法知道是在“ed。com/org/1”和“ed。com/org/2”公司中分别担任哪些职务。Human和Postion之间的关联需要第3个实体Organization才能确定，这种涉及到多个不同实体之间的关联的关系属性称为多元关系（N-ary）。
　　OWL通过SPO二元组表示的知识只能表达二元关系，但在真实数据中存在大量的多元关系（N-ary Relation），一个具体的多元关系CRn被定义为一种特殊的本体类，通过定义CRn的类关系确定多元关系中共现的不同本体类。对应前文中确定的Human、Organization、Position之间的关系，可以抽象为同一个Employee类表示多元关系，如图2所示。Employee继承自N-ary Relation表明是一个关系类，而不是对应的实体类。
　　图2的定义中虽然实现了3个之间多元关系。但是进一步详细分析会发现对于一个Employee关系，Human和Organization是固定的，而Position并不是唯一的，因一个人在一个公司可以担任多个职位。当增加时间属性时，问题会更加明显。一个Employee关系包含人职时间和离职时间，而对Position也需要描述具体职位的当选时间和离开时间。如果按照图2的定义。则需要在此基础上增加4个时间属性，如图3所示。从例中得知，HA在OB公司从员工升职为项目负责人。因此需要创建2个Employee关系的实体，分别描述当员工时的信息和担任项目负责人时的信息，这2个实体中“workStartTime”和“workEndTime”重复出现，属于冗余的知识信息，在本体建模中需要避免冗余性的出现。
　　为了更好的解释图2和图3中本体建模的问题，本文提出将本体模型部分映射到关系型数据库表的方法，利用数据库设计的3NT原则指出设计的不规范性，并将数据库设计的泛式原则转化为多元关系的定义准则。本体模型映射到关系型数据库的步骤如下。
　　（1）包含多元关系类的所有类分别转化为一张表，以类名作为表名。
　　（2）所有类的数值属性转化为表的字段，表的键值对应本体中属于该类别的实体IRI。
　　（3）非多元关系类的关系属性独立生成一张关系表，表包含双键值，分别对应关系属性的Domain和Range类的实体IRI：
　　（4）多元关系类表的键值是多元关系的关系属性中所有Range对应类的IRI。
　　通过转化可以得到多元关系转化的关系型数据库，ER图如图4（a）所示，多元关系表中的“workStartTime”和“workEndTime”属性只依赖于Human和Organization键值，而不依赖于Position键值，违反数据库定义中第二范式原则“非主属性完全依赖于主关键字”，本例Employee表是多键值表，存在属性依赖于部分主键，而不是整体键值，因此需要进行修改。根据关系型数据库的修改规范，将只依赖于部分主键的属性独立成表，创建新的键值，原表中使用新表的键值代替原来的部分主键，如图4（b）所示。得到转化的ER图后，根据从关系型数据库转化到本体模型的算法，可以转化为本体模型，再经过修改增加相应的属性描述。
　　3 复用现有本体模型
　　人物摘要本体模式，是为了给具体的领域知识图谱设计者提供基本概念的设计思路和复用泛式。本节介绍基于Wikidata的基础概念，结合前文中介绍的多元关系设计，给出本文中设计的人物摘要本体ODP，方便其它领域知识图谱参考。图5是本文中涉及的人物摘要本体模型。主要的实体类和关系类。涉及的对象包括表示人物的Human类，表示机构的Organization类以及表示事件的Event类。为了领域知识图谱可以直接兼容Wikidata中现有数据，顶层继承关系承袭自Wikidata的schema，ObJect、SubJect、Agent、Individual、TemporalEntity借鉴自Wikidata中的抽象概念，Subject表示具有独特意识或独特个人经历的人，或与其它实体存在关系的实体;Object描述与Subject相反的概念，表示物体不具有独立意识：Agent表示能够执行行动的个人和可识别实体，可以在事件中担任行为的发起方：Individual指人或特定物体：TemporalEntity表示可以在一段时间内包含的内容，或者状态的变化。Wikidata中构建了大量较为完善的抽象层概念，可以在此基础上通过多继承的方式丰富领域内实体的概念，便于实现逻辑上的推理和定理的描述。核心实体类包括Organization、Human、Award、Event，分别表示机构、人物、荣誉和事件，可以根据具体的领域问题方便增加社交网络属性信息，通过集成Relation类扩展网络中账号之间的关系。图中省略了地理位置和时间的定义，在存在基于时间和地理位置查询索引时，可以增加相关的实体设计。在通过扩展实体时，如果实体不具有主动意识，可以通过继承ObJect类进行定义，如增加作品实体的定义，可以适用于学者论文、明星作品等不同领域的知识表示。对于可以作为事件主动者的实体。可以继承自Agent类。新增多元关系时，可以参考已有的多元关系。
　　4 结束语
　　本文中介绍了目前本体模型设计的基本语法结构和设计思路。并给出了通过二元关系表示多元关系的方法，通过例子分析了不同情况中多元关系的设计思路。其次针对多元关系设计中可能存在的冗余问题，本文提出本体模型到ER图的映射算法，通过数据库设计N泛式的规则又换多元关系设计。最后以Wikidata为主要模板。给出了人物摘要本体ODP，便于在具体应用中知识图谱的设计参考。
转载注明来源:https://www.xzbu.com/8/view-15125551.htm