知识图谱综述（三）

知识图谱综述（三）

论文原文链接

这部分为数据图（页码4）部分，主要包括了：

• 图结构数据模型的介绍：有向边标签图（多关系图）、异构体、属性图、图数据集、其他图数据模型、图存储；
• 查询（语言）：图模式、复杂的图模式、导航图模式、其他特性。

下文的每一小点即论文中的一个段落。

• 任何KG的建立都要事先将数据抽象成图模型，本章选取一些在实际中常用的图结构数据模型来表示数据图。然后，我们在图查询语言的基础上，讨论了此类数据图的查询原语。

  ---

一、图结构数据模型

• 撇开图表不谈，先假设我们所呈现示例中的旅游董事会尚未决定如何对有关景点、活动、服务等的相关数据进行建模。首先董事会会先使用一个表格结构来表示所需的数据，尤其是关系型数据库。尽管他们不知道真正需要捕获哪些数据，但他们起初设计了一个关系模式。

• 他们设计的活动表格有五列，其中下划线表示表的主键，以唯一标识重复活动的发生（同样的活动可能反复举行）：

  活动（活动名称，活动地点，活动类型，开始时间，结束时间）

• 但是，他们采用这种方法会遇到以下问题：

  • 活动可能有多个名字，如用不同的语言；
  • 活动地点可能有多个；
  • 他们甚至还不知道未来活动的开始和结束时间；
  • 活动有多种类型；
  • ……

• 随着数据变得多样化，问题被逐步得到解决，他们为活动生成内部标识符并调整它们的关系模式：

  活动名称（id, name），活动开始时间（id, start），活动结束时间（id, end），活动地点（id, venue），活动类型（id, type）

• 使用上述模式，该组织现在对活动进行建模时可以使用0-n个活动名称、活动地点和活动类型，以及使用0–1标明活动是否有开始日期和活动结束日期（不需要在表格上使用关系空值/空白单元格，id=0，则start/end=null；id=1，则start/end=某个时间点）。

• 在此过程中，董事会为了与新数据进行同步，必须多次改变该模式，并且每次改变都要对数据进行昂贵的重构、重新载入数据、重新索引数据（此处我们仅考虑一张表）。董事会在关系模型上苦苦挣扎，因为他们不知道哪些数据应该被建模，以及将使用哪些数据源。

• 然而，当董事会实现了后一种关系模式后，他们可以在不进行更多更改的情况下整合更多的数据资源：对多重性的最小假设（如1对1,1对n等），该模式为集成不完整和多样化的数据提供了很大的灵活性。

• 事实上，董事会最后得到的模式本质上是对实体之间的一系列二元关系进行建模，这实际上就可以看作是对图进行建模。如果从一开始就采用图数据模型，董事会就可以摒弃之前所考虑的模式，并且可以随时定义任意实体对之间的任何（二元）关系。

• 下面开始介绍实际应用中常用的图数据模型。

1. 有向带标签边图（又：多关系图）

   • 由一些$节点$（例如圣地亚哥、阿里卡、EID16、2018-03-22 12:00）和一些节点之间带标签的$有向边$（例如“圣卢西亚–城市–>圣地亚哥”）组成；

   • 在KG中，“节点”表示“实体”，“边”表示这些实体之间的（二元）关系。下图提供了一个多关系图的例子，旅游董事会将一些相关活动的数据建模为多关系图。图1中的数据包括：活动名称、活动类型、活动开始和结束时间、以及活动地点。

   • 我们使用双向边来更加简洁地描述两种方向的边，例如图1中的“比尼亚德尔马<–巴士–>阿里卡”。此外，虽然一些命名约定推荐包含动词的更完整边标签，如has venue或is valid from，但是在本论文中，为了便于演示，将省略这些标签中的“has”和“is”动词，而只使用venue或valid from。

   • 向这样的多关系图中添加新信息通常包括添加新的节点和边（除了之后提到的一些例外情况）。表述不完整的信息只需要省略某个边，例如图1中还没有定义Food Truck festival的开始和结束时间。

• 以下是多关系图的形式化定义（附录B中将进行更加细致的描述）：
  

• 相比于标准的关系模型（模式必须预先定义，并且每一步都要遵循），这种将数据建模成图的方法可以更加灵活地整合新数据源。尽管其他结构化数据模型，比如树结构（XML、JSON等）也同样灵活，但是图不需要分层组织数据（比如“活动地点”是父节点、孩子节点还是兄弟节点类型呢？）。图还可以使用$环$进行表示和查询（比如图1中圣地亚哥、阿里卡和比尼亚德尔马之间路径上的有向环）。

• 多关系图的标准数据模型是RDF（资源描述框架），它由W3C所推荐。RDF模型定义了不同类型的节点，包括：

  • IRIs（国际化资源标识符），它可以对web上的实体进行全方位识别；
  • 字面量（literal）则能够表示字符串（带或不带语言标签）和其他数据类型的值（整型、日期等）；
  • 空节点是还未分配标识符的匿名节点，比如可以在RDF中使用空白节点，而不是创建像EID15、EID16这样的内部标识符。（我们将在3.2节讨论标识符时，进一步讨论不同类型的节点）

2. 异构图（Heterogeneous graphs）

   • 异构图（又：异构信息网络）的每个节点和边都分配了一种类型。因此，异构图类似于del图（边标签与边类型相对应），但异构图中节点的$类型$ 构成了图模型本身的一部分，而不是像del图中的类型那样被表示为一种特殊的关系，如图2所示。

• 如果某个边是在相同类型的两个节点之间，那么该边（如borders）是同质的（homogeneous），否则该边（如capital）是异构的（heterogeneous）。异构图的一个好处是：它们允许根据节点的类型进行划分，例如为了实现某种机器学习任务。反之，异构图通常只支持节点和类型间一种一对一的关系，即一个节点只会和一种类型相关联（该情况不会出现于del图中，例如图1中Santiago是0类型的，而EID15具有多种类型）

• 异构图的形式化定义：

3. 属性图（property graph，PG）

   • 属性图可以灵活地建模更加复杂的关系。整合输入的数据后，它们将提供“哪些公司提供哪些航班的票价信息”，从而让旅游董事会更好地了解城市间的可以利用的线路（例如国际航班）。在多关系图中，我们无法说明提供某条航线的公司，如边“圣地亚哥–航班–>阿里卡”。但是我们可以添加一个新节点（LA380、LA381）来表示航班，并将它与始发地、目的地、公司和交通类型相关联，如下图3所示。

• 然而，将属性图运用于图1中的所有路径上需要对图进行大改。另一种办法可以将不同公司的航班放在不同的已命名的图中，但是如果已经使用命名图来追踪图中的始发地点（？），那么这将变得很麻烦。

• 因此，属性图的提出是为了将数据建模为图的时候提供额外的灵活性。属性图允许一些“属性-值”对和一个标签同时与节点和边相关联（即PG中每个节点或边拥有一个标签（节点名）和一些属性（值））。如下图4是一个简单的PG例子，它与图3相似。

• 上图，我们使用边上的“属性-值”对来对公司进行建模（在PG的实际应用中，属性可能会有多个值，例如可表示为一个数组。但这样的情形并不影响图的表现力，也不影响我们的讨论）。关系的类型被赋予标签“flight”。我们进一步使用节点标签来表示两个节点的类型，并使用“属性-值”对来表示它们的纬度和经度。

• PG最常用于目前流行的图数据库中，如Neo4j。在图模型的选择上，最重要的是PG可以在不丢失任何信息的情况下与多关系图（MG）进行相互转换。如上图4。总之，MG提供了一个更小的模型，而PG提供了一个更加灵活的模型。通常来说，相比于其他实际因素（比如不同模型的可实现性），模型的选择是次要的。

• 下面是PG的形式化定义：

4. 图数据集

   • 即使多个MG可以通过它们的并集进行结合，但通常要求对多个图进行管理而不单是管理一个巨大的图。例如，管理多个来自不同数据源的图可能是有好处的，这使得对同源数据的更新或细化成为可能，从而可以进一步区分不可信来源和更可信来源。一个图集由一些已命名图和一个默认图组成，每个已命名图是由一个图ID和一个图共同配对组成的。默认图是没有ID的图，即如果没有指定图ID，则该图将被默认引用。如下图5所示，活动和路线被分别被存储在两张已命名图中，默认图管理已命名图的元数据。（图数据集的形式化定义见附录B.7）

• 图的名字可以作为一个图上的节点。此外，节点和边可以在多张图上重复，不同图中的相同节点通常指的是相同的实体，从而使得在合并图的时候可以很容易整合实体上的数据。尽管该例子是一个MG的数据集，但这个概念可以直接推广到其他类型的图。

• 图数据集的一个常见应用是管理和查询被链接的数据，这些数据由被散播在网络中的RDF图上相互链接的文档组成。当处理web数据时，追踪数据来源变得尤为重要。我们将在3.2节中讨论被链接的数据，并在3.3节中讨论其出处。

• 图数据集的形式化定义：
  

5. 其他图数据模型

   • 前面的模型是实现图表示的典型例子。其他图数据模型存在可能包含单独边或嵌套图的“复杂节点”（有时也被称为“超节点”）。同样，一个“超图”的数学概念定义了连接多个集合（而不是一些节点对）的复杂边。
   • 在我们看来，一个KG可以采用任何一种基于节点和边的图数据模型：通常数据可以实现两个模型间的相互转换（如图3和图4）。本论文接下来的部分将更多讨论MG，因为其相对更简洁，但大部分讨论可以很自然地扩展到其他模型。

6. 图存储

   • 已经有一些用于存储和索引图的技术被提出，使用这些技术实现查询的高效运算（正如接下来所讨论）。MG被存储在关系型数据库中，其中要么是一种单一的三元组关系（三元表格），要么是一种针对每个属性的二元关系（垂直划分），又或是某种给定类型实体间的n元关系（属性表）。
   • 此外，还有为各种图模型开发的自定义存储技术，它们为节点、边及其相邻元素的查询提供了高效的访问技术。许多系统进一步支持将图分布在多台机器上，该技术基于目前流行的NoSQL存储或者自定义分区方案。有关更多详细信息，请参阅 Janke 和 Staab 的书籍相关章节以及 Wylot 等人在该主题上的研究综述。

二、查询语言

• 目前已经有一些实用的语言来查询图，包括用于RDF图的SPARQL查询语言，以及用于查询PG的Cypher、Gremlin和G-CORE语言。这些查询语言的基础是一些常见的原语，包括（基本的）图模式、关系运算符、路径表达式等等。现在我们依次描述这些查询图的核心特征，从图模式开始。

1. 图模式

   • 每种图的结构化查询语言核心是（基本的）图模式，它遵循与待查询数据图相同的模型（见2.1节），此外它允许变量作为术语。因此，图模式中的术语被分为常量（如阿里卡或者“活动地点”）、变量（以问好为前缀，如“?event”或者”?关系“）。

   • 然后，通过生成从图模式中变量到数据图中常量的映射，根据数据图对图模式进行计算，如此一来，在这一映射下图模式的映像(用指定的常量替换变量)就包含在了数据图中（即该数据图体现了/符合这一图模式的一切特征）。

   • 如下图6所示，我们提供了一个图模式的例子，该模式查询“Food Festival”的活动地点。右表为该图模式根据图1中所呈现的数据图产生的可能映射。在一些映射中（最后两列），多个变量映射到映射到同一个术语（右表3~4行），是否需要这样做则取决于具体应用场景。因此一些语义被提出用来计算图模式，其中最重要的是：

     • 基于同态的语义。它允许多个变量映射到同一个术语，于是图6中的所有映射都将被视为结果。
     • 基于同构的语义。它要求节点或/和边上的变量映射到唯一的术语，因此从结果中排除右表中的后三个映射。

• 不同的应用语言在计算图模式时采用不同的语义，例如SPARQL采用基于同态的语义，而Cypher在边的选取上采用基于同构的语义。

• 在后面的例子中（尤其是图8），图模式也可以形成环（他们是有向或者无向的），并且可以变量替换边标签。类似地，图模式在其他模型的上下文中（如PG），可以通过让变量在模型的任何位置对术语进行替换来定义（就是我要查什么节点或边，我就用变量替换掉PG上的那个标签，然后在前面写个?，表示我要查询这中类型的实体或关系）。在附录B.2.1中提供了MG和PG的图模式的形式化定义及其运算。

2. 复杂图模式

   • 图模式将输入的一张图转换为一张表作为结果（如图6所示）。然后，我们可以考虑使用关系代数来结合和/或转换这些表，以便从一个或多个图模式中形成更复杂的查询。回忆关系语言可知，关系代数由接受一个输入表的一元运算符和接受两个输入表的二元运算符组成。

   • 一元运算符有：投影$\pi$（输出列的子集）、选择$\sigma$（输出符合给定条件的一些行）、重命名列$\rho$。

   • 二元运算符有：并集$\cup$（将两个表的行合并为一个表）、差集$-$（删除第一张表中在第二张表内有的行）、连接$\bowtie$（用另外一张表中满足某个连接条件的行扩展第一张表中的行）。

   • 选择和连接条件运算符通常有：等式$=$、不等式$\le$、取非$\neg$、析取$\vee$等等。

   • 从以上这些操作中，我们可以进一步定义其他（语法）操作，比如交集$\cap$（输出两个表中共有的行）、反连接$▹$（又：不存在。在表1中寻找表2中无法进行连接操作的行）、左连接⟕（又：可选的。执行连接操作，但在第二张表中没有兼容表1的行的情况下保留第一个表中的行）等等。

   • 之后，图模式可以用关系代数的子集来表示（即$\pi$、$\sigma$、$\rho$、$\bowtie$）。例如，假设一个三元组关系$G(s,p,o)$表示一张图（即一个有三个列“主谓宾”$s,p,o$的表$G$），图6的查询用关系代数可表示为：

其中，$\bowtie$为自然连接（在两张表中的同名列间检查相等性，此处连接操作是在主语列$s$上进行的 ）。查询结果是一张表，其中每个变量是一列：$ev,vn1,vn2$。但是，并非所有在$G$上使用$\pi$、$\sigma$、$\rho$、$\bowtie$的查询都可以表示为图模式；例如，我们无法在图模式中选择投影哪些变量，而是必须投影所有未固定为常量的变量。

• SPARQL和Cypher等图查询语言允许在图模式的结果上完全使用关系运算符，从而引发复杂图模式。下图 7 呈现了一个复杂图模式的示例，其中投影变量以粗体显示，选择特定变量呈现在最终结果中。在术语的表现力上，具有这种（不受限制的）形式进行投影的图模式等同于在图上进行连接查询。

• 在图 8 中，我们给出了另一个复杂图模式的示例，用于查找不在圣地亚哥举行的美食节或饮料节，可选地返回其开始日期和名称（如果有）。这样的查询——允许在图模式上充分使用关系运算符——等同于在图上进行一阶查询（first-order queries）。在附录 B.2.2 中，我们形式化了复杂图模式及其在数据图上的运算。

• 复杂图模式会产生重复结果；例如，图7中的第一个结果出现了两次，这是因为在一个结果中 ?city1 与 Arica 匹配，?city2 与 Viña del Mar 相匹配，在另一种结果里两者恰好相反。查询语言提供两种语义：bag 语义根据底层映射的多样性保留重复项，而 set 语义（通常使用 DISTINCT 关键字）从结果中删除重复项。

3. 导航图模式

   • 区分图查询语言的一个关键特征是其能够在查询中包含路径表达式。一个路径表达式$r$是一个正则表达式，它能够匹配两个节点间任意长度的路径，表示为一个正则路径查询$(x,r,y)$，其中$x$和$y$可以是变量或常量（或者甚至是同一个术语）。基本的路径表达式中$r$是一个常量（一个边标签）。

   • 此外，如果$r$是一个路径表达式，那么$r^{-}$（逆向查询）和$r^{\ast }$（可莱尼星Kleene star：0个或更多个）也是路径表达式。一些作者区分两路正则路径查询和正则路径查询，只有前者支持逆向查询。最后，$r_1$和$r_2$如果是路径表达式，那么$r_1|r_2$（析取）和$r_1\cdot r_2$（连接）也是正则表达式。

   • 之后，正则路径表达式在一些不同的语义下被计算。例如，根据图1计算的$(Arica,bus\ast ,?city)$可能匹配下图9中的路径。实际上，由于存在环，因此可能匹配到无限数量的路径。由于这个原因，通常使用受限制的语义，只返回最短路径，或者没有重复节点或边的路径（如在Cypher中。将变量映射到路径需要特殊处理，Cypher返回一个编码为路径的字符串，这样一来某些函数可被使用，如$length(\cdot )$；另一方面，G-CORE支持返回路径，并且支持其他运算符，包括投影为图，应用成本函数等）。除了返回路径外，另外一种选择是返回匹配的路径中所连接的（有限）节点对的集合（SQPARQL 1.1中是这样）。

• 然后，为了表达导航图模式，我们在图模式中使用正则路径查询。下图10说明了一个查询，它搜索举办美食节的城市，要求从阿里卡坐公共汽车或飞机出发可到达（递归地）的城市。

• 此外，当正则路径查询和图模式与操作符（如投影、选择、并集、差集和可选）相结合时，则称为复杂导航图模式。附录 B.2.3 提供了（复杂）导航图模式的定义及其运算。

4. 其他特性

   • 到目前为止，我们已经讨论了形成任何图查询语言的实践和理论基础所具有的特征。然而，特殊的图查询语言可以支持其他实际特性，例如聚合（group by，count等）、更复杂的过滤器和数据类型操作符（从一个日期中提取的年份范围查询）、用于通过Web远程查询托管图的联邦、用于更新图的语言、语义蕴涵机制的支持。
   • 对于更多的信息，我们参考了多种查询语言的文档和Angles的综述。