1.2 知识图谱相关技术与方法

知识图谱相关研究在自然语言处理、深度学习等技术的推动下已经迈进成熟化和实例化，形成两条基本的技术路径：一是语义网领域的语义知识图谱，二是数据库领域的广义知识图谱。接下来将以此分类为依据对知识图谱数据模型、查询语言、构建技术、存储管理方案等进行分析介绍。

1.2.1 知识图谱构建技术流程

知识图谱的构建过程实际上是从大量关系复杂、类型繁多、结构多变的数据中获取计算机可读知识的过程，是数据融合与链接的纽带。从逻辑层次上看，知识图谱分为模式层和数据层，数据层由一系列以三元组为表现形式的事实组成，模式层（也称概念层）则是作为数据层的“上层建筑”，通过积累沉淀的知识集合——本体库来规范数据层的事实表达。因此，知识图谱的核心是建立本体模型和实体数据库，按照二者构建顺序可将知识图谱构建方法分为“自顶向下型”和“自底向上型”两种。“自顶向下型”是指在定义好本体和数据规范的前提下再抽取数据，这种模式适用于存在可量化的行业逻辑的领域，如医疗、法律、金融等。“自底向上型”则是先抽取实体数据，选择置信度高的实体数据加入知识库再逐层抽象出本体模型，常应用于数据量庞大但行业逻辑难以直接展现的领域，如Bing Satori、Google知识图谱。对于新兴领域，通常采用两者结合的方式建模。从数据模型上看，知识图谱分为RDF图和属性图，如前所述，前者通常是指语义网领域提出的基于RDF三元组存储的语义知识图谱，侧重知识的发布和链接；属性图则主要指数据库领域发展出的基于属性图数据库的广义知识图谱，侧重知识的计算与挖掘。

总的来说，不管是哪种数据模型的知识图谱，构建全程都以本体模型为规范或约束条件。经过广泛的调研和分析总结得出：知识图谱构建主要技术架构如图1-1所示，包含广义知识图谱及语义知识图谱构建的全过程。其中，广义知识图谱构建流程中，知识建模在知识融合之后，即采用自底向上的方式；而知识建模前置在知识抽取过程的为语义知识图谱构建，即采用自顶向下的方式，通常这种情形下的知识建模多依赖已有领域数据模型及专家智慧。

1.广义知识图谱的构建

广义知识图谱的构建从数据源开始，包括知识抽取、知识融合、知识加工等步骤，其语料来源通常为非结构化的文本数据、半结构化的网页或表格，以及生产系统中的结构化数据。作为图谱构建最核心的环节，知识抽取包含命名实体识别（Named Entity Recognition, NER）（也称实体抽取）、关系抽取（Relationship Extraction, RE）和属性抽取三个要素，其中属性抽取相对易操作，通常采用Python爬虫在百科类网站爬取，因此实体抽取和关系抽取成为知识抽取环节的重点研究内容。针对不同的数据类型，知识抽取技术也有所不同，其中，面向结构化数据的知识抽取方法有直接映射、R2RML等；面向非结构化数据的知识抽取方法有基于规则、基于统计模型如隐马尔可夫模型（Hidden Markov Model, HMM） ^[6] 、最大熵（Maximum Entropy, MaxEnt）模型 ^[7] 和条件随机场（Conditional Random Field, CRF） ^[8，9] 等，以及基于深度学习的方法如循环神经网络（Recurrent Neural Network, RNN） ^[10] 、卷积神经网络（Convolutional Neural Network, CNN） ^[11] 、引入注意力机制（Attention Mechanism） ^[12，13] 的神经网络等。目前使用最广泛的是Google公司于2018年提出的语言预训练模型BERT（Bidirectional Encoder Representation from Transformers）——双向Transformer的Encoder ^[14] 、国内百度PaddlePaddle开源的中文知识增强的语义表示模型ERNIE（Enhanced Representation through Knowledge Integration），这些模型均需结合文本语料标注工具如BRAT、YEDDA等进行大量的语料标注，实体抽取准确率超过80%。知识融合过程是将抽取后的知识通过统一的术语融合成知识库，包括知识消歧、实体对齐、实体链接等，这一阶段的主要任务是数据层的融合，常用的方式有DBpedia Mapping的属性映射方法、zhishi.me的离线融合方式等。知识加工过程则是针对知识融合过程中产生的新关系组合或通过知识推理形成的新知识形态进行质量评估，抽象出本体模型并不断更新和扩充，最终形成完整形态的知识图谱。

2.语义知识图谱的构建

语义知识图谱本质上是RDF三元组图数据，是图书情报和数字人文领域的主流形式，其数据来源可归纳为关系型数据、非关系型数据及文件三类，尤其对于垂直领域，知识大多来源于关系型数据库。关系型数据库作为传统的企业数据业务系统，在效率方面存在一定优势，但欠缺语义且系统间互操作性弱，随着数据网络的快速发展，将关系型数据转化为RDF图数据（RDB-to-RDF）或者OWL本体的研究实践不断涌现并形成了一系列相关的标准和应用工具，这一方式既可以确保以前开发应用的可持续性，也可以充分利用RDB系统的可扩展性、ACID属性和安全性等优良特性 ^[15] 。RDB-to-RDF实现思路主要有基于转换引擎、本体工程、通用映射语言三种 ^[16] ：基于转换引擎的方法是通过SPARQL查询触发处理引擎进行数据转换 ^[17] ；本体工程的方法是指从关系型数据及其模式中抽象出本体的概念和关系 ^[18] ，一般需要结合转换引擎和映射语言使用；通用映射语言的方法则是指在已有本体模型的前提下通过描述语言直接映射，该方法的应用场景最为广泛，是目前最为典型和主流的方式。W3C推荐了两种RDB-to-RDF映射语言用于定义RDB转换为RDF的规则，包括URI的生成、RDF类和属性的定义、空节点的处理、数据间关联关系的表达等。一种是直接映射，即将RDB表结构和数据直接转化为RDF图，并支持通过SPARQL查询或RDF图API访问数据；另一种是R2RML——自定义的映射语言，可以在RDF数据模型下查看关系型数据并灵活定制视图。

此外，除了关系型数据库，还有大量数据资源以结构化或半结构化文件格式存在，如CSV、Excel、XML、JSON等，基于此类数据的语义知识图谱构建也有一定的研究成果。本节针对部分重要且在领域广泛使用的工具或系统进行调研分析，其特性对比如表1-2所示。调查结果显示，针对不同的数据类型及应用场景，目前的语义知识图谱生成工具/系统提供在线编辑、单机版等若干服务形态。然而，大多需要编写自定义脚本或编程来执行数据转换，且支持的数据源和存储方式有所限制，随着数据规模的扩大和处理任务的复杂化，实践中将面临效率等各方面的挑战，如数据管理员定义了若干周期性的数据处理任务，使用时必须配置不同的调度脚本或者使用外部工具以确保任务执行，则工具配置和任务维护将消耗大量人力和时间。

UnifiedViews ^[19] 是一个开源的抽取-转换-加载（Extraction-Transformation-Loading, ETL）框架，允许用户定义、执行、监控、调试、调度和共享RDF数据处理任务，简化了关联数据发布过程的创建和维护。图1-2展示了UnifiedViews总体架构，它提供了一个图形用户界面，数据处理任务在UnifiedViews中被表示为数据处理管道（Pipeline）。每个Pipeline都由一个或多个数据处理单元（Data Processing Unit, DPU）和这些单元之间的数据流组成，每个DPU都封装处理数据的特定业务逻辑，并且可以产生对应的输出。在不同的Pipeline中可以对DPU进行不同的配置。数据单元是DPU使用或生成数据的容器。UnifiedViews支持三种类型的数据单元：RDF数据单元，处理RDF图；文件数据单元，处理文件和文件夹；关系数据单元，处理关系数据库中的表。UnifiedViews有四种类型的DPU：Extractor是不定义任何输入数据单元的DPU，它的输入数据是依据DPU的业务逻辑从外部来源获取的，如Extractor可以从远程SPARQL端点查询数据，或从特定的URL集下载文件；Transformer是将输入转换为输出的DPU，它定义了输入和输出数据单元，如将表格数据转换为RDF数据或执行SPARQL查询；Loader是定义输入数据单元但不定义任何输出数据单元的DPU，其输出数据不由UnifiedViews维护，而由外部存储库进行存储；Quality Assessor是评估输入数据的质量并生成质量评估报告作为输出的DPU。此外，用户可以创建和部署自定义的DPU以满足所需功能要求。

UnifiedViews是到目前为止在流程和功能方面最为完整和全面的RDF数据创建与转换综合解决方案，对数据兼容性较高，支持关系型数据、RDF编码格式和文件数据向RDF数据的转换，但也存在构建复杂、人工配置困难的问题。从初步试用体验来看，该工具还是较为初级的原型系统，在易用性、稳定性等方面与专业的数据ETL工具（如Kettle）相比还有较大提升空间。

1.2.2 知识图谱数据模型

从数据模型的角度来看，概念网络——知识图谱本质上是一种图数据，数据模型规范依据知识图谱的领域特征而定，主要有RDF图和属性图两种形式，两者的逻辑视图如图1-3所示。其中，属性图具备RDF图所没有的节点和边的内部结构，可以表达实体/关系的属性。

1.RDF图

RDF是2004年万维网联盟（W3C）制定的语义网中机器可理解信息表示和交换的标准数据模型，也可作为知识图谱的国际标准。作为Web上表示和发布知识图谱最主要的数据格式之一，RDF明确了描述网络信息资源及资源间语义关系的模型和语法，以三元组<subject, predicate, object>（s,p,o）即主谓宾的方式表示知识，主语表示类的实例——个体（Individual），谓语既可以是连接两个个体的关系，也可以是连接个体和数据类型的实例，宾语为相应个体或者属性值。RDF三元组集合即为图中的有向边集合，集合中每个资源具有统一资源定位符（Uniform Resource Identifier, URI）作为其唯一的id，通常情况下主语和谓语都要用HTTP URI表示，宾语可以是某种数据类型的值Literal（字面量），也可以是另一资源的HTTP URI。需要说明的是，RDF主语和宾语也可以是空节点类型，即没有URI和Literal的资源或匿名资源，RDF图对节点和边上的属性没有内置的支持。RDF图数据模型常用于学术领域的语义知识图谱构建。

RDF支持不同的书写格式，也称序列化（Serializations）方法，如RDF/XML、Notation3（N3）、Turtle、N-Triples、RDFa、JSON-LD等 ^[20] ，下面以图1-4为例进行说明。

图1-4中分别给出了“论文ja.00001的标题（title）是Learning representation by back-propagating errors，主题（subject）是Neural Networks”这一RDF三元组集的三种序列化格式。RDF/XML（.rdf）指用XML格式表示RDF数据，是树状文档和基于三元组图的混合体，表达较为冗长；N-Triples（.nt）则是指用多个三元组来表示RDF数据集，每行表示一个三元组，这种表示方式最为直观，有利于机器的解析和处理，开放领域知识图谱DBpedia及学术知识图谱SciGraph均采用这种方式发布数据；Turtle（.ttl）是目前应用最为广泛的序列化格式，数据紧凑、可读性好，使用＠prefix对RDF的URI前缀进行缩写，Turtle与N-Triples相比解析成本更高；其他格式如JSON-LD（.json）是轻量级链接数据格式，在工程应用方面更具优势。

知识图谱需要借助查询语言进行查询等应用操作，RDF图数据中常用的是W3C指定的标准查询语言——SPARQL协议与RDF查询语言（SPARQL Protocol and RDF Query Language），类似于关系数据库中的SQL查询语言，其核心处理单元是三元组模式。作为一套知识服务标准体系，SPARQL 1.1版本提供查询、更新（Update）、联邦查询（Federated Query）、查询结果格式和接口协议等服务，设计了三元组模式、子图模式、属性路径等多种查询机制，且可用于跨数据源的查询。SPARQL查询可用Q={GP, DS, SM, R}表示，其中GP是表达查询意图的图模式；DS是RDF数据集源；SM是指定结果集约束条件的解修饰符；R是查询结果，通常为结果集或RDF图。SPARQL在查询操作方面的友好特性是本书在知识图谱构建工具及存储应用方面的重要技术基础。

例如，查询scigraph图中2019年发表的主题为Neural Networks的论文的标题（？title），SPARQL查询语句语法分析如图1-5所示。除简单查询外，SPARQL还支持多字段匹配和数据属性匹配，根据需求可搭配CONCAT函数、FILTER关键字等联合使用，实现检索结果的字符串拼接、条件过滤等。

2.属性图

属性图（Property Graph, PG）是图数据库领域使用最为广泛的一种图数据模型，是由节点（Vertex或Node）、边（Edge或Relationship）组成的有向图，其具备如下特性：

（1）每个节点都具有唯一的id、若干条出边和入边，以及一组属性，每个属性都是一个键值对（Key-Value Pairs），属性值可以是标量类型或数组。

（2）每条边都具有唯一的id、一个头节点、一个尾节点、一个表示联系的标签，以及一组属性值，每个属性都是一个键值对。

以图1-6所示的属性图样例为例进行说明，根据属性图的要素，software、person分别代表类为软件、人员的节点，created、knows分别代表关系为开发、认识的边，软件节点的属性包括名称和开发语言，人员节点的属性包括姓名和年龄。这个属性图描述了2个软件节点和4个人员节点的关系，如节点3的入边集合为{边9，边11，边12}，属性集合为{name=lop, lang=java}，表示节点3的软件由人员节点1、4、6开发，软件名称是lop，开发语言是java；节点4的入边集合为{边8}，出边集合为{边10，边11}，属性集合为{name=josh, age=32}，表示节点1的人员认识节点4的人员，节点4的人员姓名是josh，年龄32岁，开发了节点3和节点5的软件。

属性图上的查询语言通常是Cypher和Gremlin，其中Cypher最初是图数据库Neo4j中实现的开源声明式查询语言，提供通过可视化和逻辑方式匹配图中节点和关系的模式，支持创建、读取、更新、删除等功能，目前主流的图数据库如Memgraph、AgensGraph等均支持Cypher。

表1-3给出了RDF图和属性图的对比。

1.2.3 知识图谱存储与管理

随着知识图谱规模的日渐增长，其存储管理与查询处理也变得更加重要。知识图谱存储是指以计算机可读的数据格式对知识图谱的模式层和数据层进行物理保存，包括基本的资源、事件、关系、属性等知识。知识图谱的底层存储方案直接关乎数据查询的效率，通常需结合知识应用场景设计。

知识图谱数据集包括两个部分：显性的三元组（Explicit Triples）及隐性的三元组（Implicit Triples）。其中，显性的三元组通常以数据的形式直接给出，而隐性的三元组蕴含于各元素所附带的语义中，需要根据知识图谱的本体及规则集从显性的三元组中推理得到。按照存储结构划分，知识图谱存储有关系表和图两种形式：基于关系表存储的主要有三元组表、水平表、属性表、垂直划分和六重索引等，与知识图谱的图模型存在巨大差异，查询、维护、删改等操作成本高，难适应大规模图谱数据的建设与管理；以图形结构对数据进行存储的图存储是目前主流的知识图谱存储方式，相较于关系表存储，它在关联查询的效率上有着显著的提升，尤其在深度关联查询时表现更为优异。根据图谱数据格式，常见的图存储方案分为面向RDF的三元组数据库及面向属性图的图数据库两种。

1.面向RDF的三元组数据库

面向RDF的三元组数据库是专门为存储大规模RDF数据而开发的知识图谱管理系统，被称为Triple store或RDF store，支持声明式查询语言——SPARQL。三元组数据库是一种通用的、用于描述事物的图模型，通过统一资源标识符URI标识资源，用户可以对网络中的资源基于特定的协议进行交互操作。目前，主要的RDF三元组数据库包括Virtuoso、GraphDB、MarkLogic和BlazeGraph及源自学术界的RDF-3X（仅支持Linux的科研原型系统）和gStore。图1-7给出了DB-Engines上排名靠前的三元组数据库，其中，MarkLogic、Virtuoso、GraphDB常年稳居前列，下面将分别进行详细介绍 ^[21] 。

1）多模型数据库MarkLogic

MarkLogic是美国同名软件公司推出的多模型数据库，具备NoSQL和可信的企业数据管理功能，至今已有20年的发展历程，是集文档、语义图、地理空间和关系型模型优点于一体设计的可扩展、高性能数据库，内置的搜索引擎可为JSON、XML、文本、RDF三元组、地理空间和二进制文件（如PDF、图像、视频）提供统一的搜索和查询界面，减少标准查询构建、配置索引的时间。MarkLogic在文档、图形数据和关系型数据的存储和查询方面具备极高的灵活性且可以通过三元组在文档间建立关联。图1-8展示了MarkLogic多模型描述示例，包含三种有关Jen的事实和关系三元组的描述方式，用户可在保证数据一致性的前提下根据实际需求选择恰当的数据模型组合。

MarkLogic的最大特点在于其数据集成功能敏捷且简单，无须预先定义模式（数据可以按照原本的格式存储）或依赖复杂的ETL过程。它可以在商用硬件的集群中水平扩展到数百个节点、PB级数据、数十亿个文档，每秒可处理数万笔事务，集群随着数据或访问需求的增长或收缩而水平扩展，并提供自动故障转移、复制和备份服务。MarkLogic非商用版采用注册制，MarkLogic Console界面如图1-9所示。MarkLogic支持JavaScript脚本、SPARQL Query、SPARQL Update、SQL、XQuery查询方式及文本、XML、HTML结果形式。

2）混合数据库管理系统Virtuoso

Virtuoso是语义网项目常用的一种多模型混合关系数据库管理系统（Relational Database Management System, RDBMS），支持对关系表和属性图的数据管理，是一个高性能、可扩展、安全和基于开放标准的平台。其基础源自开发了多年的传统关系数据库管理系统，因此具备较为完善的事务管理、并发控制和完整性机制。Virtuoso作为较成熟的语义数据库，在其数据库基础上可支持关联数据的发布和应用，并支持查询语言SPARQL。作为知识存储系统，Virtuoso支持客户端和服务器后台两种数据加载方式，客户端数据加载（见图1-10）适用于单个较小文件的上传加载，服务器后台批量加载则适用于多个大文件加载。

以Virtuoso服务器后台数据加载实验为例，代码如下：

基于136个文献类RDF数据文件（共计2.97亿个RDF三元组、容量40.8GB）进行数据加载测试，总耗时2小时，平均38485个三元组/秒。同时，加载DBpedia开源数据共147个文件（共计30亿个RDF三元组、容量700GB），耗时16小时，平均51574个三元组/秒。Virtuoso中SPARQL查询示例如图1-11所示，包含查询特定论文的查询界面和结果界面，从近40亿个RDF三元组中查询单个实体对象耗时18.45毫秒。

此外，Virtuoso支持HTTP URI实体解析，提供面向计算机的互操作接口，可返回多类型查询数据结果片段。

3）图形数据存储引擎GraphDB

GraphDB是基于OWL标准开发的具有高效推理、聚类和外部索引同步支持的企业RDF三元组库，同时支持属性图管理，可以链接到大型知识图谱中的文本和数据，具备支持任何类型数据（CSV、XLS、JSON、XML等）的解析与RDF转换格式和存储、SPARQL编辑器、FTS连接器、可视化等功能。还可以基于RDF数据进行语义推理，通过使用内置的基于规则的“前向链”（Forward Chaining）推理机，由显式知识推理得到导出知识并优化存储。导出的知识会在知识库更新后相应地同步更新，支持数据调和、本体可视化和高性能可扩展的聚类，可与MongoDB集成，用于大规模元数据管理、基于图嵌入的语义相似性搜索及快速灵活的全文搜索。

GraphDB分为企业版、标准版和社区免费版，其中，企业版支持分布式部署，允许查询吞吐量与集群节点的数量成比例地扩展，可与Solr、Elasticsearch集成进行全文搜索；免费版支持多个图数据库的创建管理，GraphDB的数据文件管理如图1-12所示。从版本8开始，GraphDB与RDF4j框架完全兼容。GraphDB实现了RDF4j的存储与推理层（SAIL），可以使用RDF4j的RDF模型、解析器和查询引擎直接访问GraphDB。

GraphDB支持网页客户端单个较小文件的上传加载功能，也支持网络端本地或服务器目录的批量大文件上传，并提供丰富的解析参数设置功能。加载同样的136个文献类RDF数据文件总用时约6小时，查询特定论文结果返回时长0.1秒，与Virtuoso相比，效率较低。从官方的介绍中可以看出，Virtuoso、GraphDB均是多模型混合存储数据库，同时支持RDF图和属性图数据管理，由于其SPARQL的图形遍历性较差，实际应用中多作为RDF三元组数据库使用。

2.面向属性图的图数据库

原生图数据库主要是以属性图的方式存储、处理、查询和展示数据，在关系遍历和路径发现等应用中性能优越，主要代表有Graph1.0时期最为流行和成熟的Neo4j。随着业界在图数据库扩展性方面的挑战逐渐凸显，JanusGraph、OrientDB等开源分布式大规模图数据库应运而生，其中OrientDB功能相对全面，支持文件、图（包括原生图）、键值对等多模型数据管理和SQL、Gremlin多种查询语言，JanusGraph则在底层数据库之上封装一层，实现图的语义，可基于第三方分布式索引库Elasticsearch、Solr和Lucene实现数据快速检索，作为图计算引擎使用。现对DB-Engines上排名靠前的图数据库（见图1-13）进行说明。

1)Neo4j

Neo4j是由Java实现的开源NoSQL图数据库，常年处于DB-Engines图数据库排名首位，是基于数学中的图论所实现的一种数据库，数据对象/实体被保存为节点，关系则被保存为链接地址的形式。Neo4j存储管理层为属性图结构中的节点、节点属性、边、边属性等均设计了存储方案，因此与其他数据库相比，它可以更加高效地存储、查询、分析和管理高度关联的图谱数据。例如，在遍历关系时，只要在Neo4j中找到起始节点、读取节点的邻接边就可以访问该节点的邻居，具有“无索引邻接”特性（Index-Free Adjacency），每个节点都可被当成邻接节点的“局部索引”，这种查询方式与“全局索引”相比更能节省时间开销。

Neo4j图作为属性图，其数据模型形式化定义为六元组PG= ，其中 是有标签的有向多重图， V 和 E 分别表示节点和边的集合，src： E → V 、tgt： E → V 、lbl： E → V 分别表示每条边都有起始节点、终止节点和标签， φ：V ∪ E →2 ^P 表示属性键值对的集合 ^[22] 。相较于面向RDF的三元组数据库，图数据库在数据关系检索方面具有更大的优势，通常以简单的Cypher语句便可实现查询功能，且执行效率更加高。Neo4j V4.1.11启动后浏览器界面如图1-14所示，具体使用将在后续章节中详细介绍。

2)JanusGraph

JanusGraph是一种面向分布式集群的开源图形数据库管理系统，可以存储千亿级节点和边的大规模图，支持高并发复杂实时图遍历和分析查询，大型图上的复杂遍历查询效率达毫秒级。JanusGraph集成第三方分布式索引库Elasticsearch、Apache Solr、Apache Lucene作为索引后端，可作为图形数据库引擎使用，支持全文检索。

3)TigerGraph

TigerGraph是一款“实时原生并行图数据库”，可在云端、本地等多终端部署，支持水平和垂直扩展，可以对集群中的图数据自动分区，具有非常强大的查询语言和算法库。相较其他图数据库，TigerGraph在多跳路径查询、批量数据加载和实时更新方面优势尽显，2跳路径查询可比其他图数据库快40～337倍，数据加载速度是其他图数据库的1.8～58倍，存储相同原始数据所需的磁盘空间更小。TigerGraph支持查询语言GSQL，该语言结合SQL风格的查询语法和Cypher风格的图导航语法，并加入过程编程和用户自定义函数。

选择合适的知识图谱存储方案是支撑知识应用的基础，实际应用场景中也不乏继续沿用基于表结构的关系型数据库的情况，对于高度结构化的数据存储差异不大，但在2跳、3跳路径查询方面较为低效。结合DB-Engines数据库排名，从存储方法、系统特征等角度对常用的图谱数据库进行比较测评，综合分析得出结果：数据规模上，稍高配置的单机系统和主流RDF三元组数据库可以支持百万级三元组的存储管理，更大规模则需要部署具备分布式存储与查询能力的数据库系统。随着三元组库和图数据库的融合发展，基于图数据库的RDF三元组管理也是很常用的方式，前提是需要根据图谱映射规则对RDF三元组进行格式转换，生成属性图的格式再进行管理。 6oQ6AV8OGFGpPFaYNAtmyPsvoMKIBBLS8xr5NAdWKFs2oL3HpJMrjSVaqzT1RU0R