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的离线融合方式等。知识加工过程则是针对知识融合过程中产生的新关系组合或通过知识推理形成的新知识形态进行质量评估，抽象出本体模型并不断更新和扩充，最终形成完整形态的知识图谱。
图1-1 知识图谱构建主要技术架构
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所示。调查结果显示，针对不同的数据类型及应用场景，目前的语义知识图谱生成工具/系统提供在线编辑、单机版等若干服务形态。然而，大多需要编写自定义脚本或编程来执行数据转换，且支持的数据源和存储方式有所限制，随着数据规模的扩大和处理任务的复杂化，实践中将面临效率等各方面的挑战，如数据管理员定义了若干周期性的数据处理任务，使用时必须配置不同的调度脚本或者使用外部工具以确保任务执行，则工具配置和任务维护将消耗大量人力和时间。
表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以满足所需功能要求。
图1-2 UnifiedViews总体架构[19]
UnifiedViews是到目前为止在流程和功能方面最为完整和全面的RDF数据创建与转换综合解决方案，对数据兼容性较高，支持关系型数据、RDF编码格式和文件数据向RDF数据的转换，但也存在构建复杂、人工配置困难的问题。从初步试用体验来看，该工具还是较为初级的原型系统，在易用性、稳定性等方面与专业的数据ETL工具（如Kettle）相比还有较大提升空间。