知识图谱概论（一）

本文主要是对Knowledge Graphs所涉及的知识进行翻译和记录

本节概述图数据模型以及用于查询和验证它们的语言。

1. 图结构

此节主要介绍一些流行的图结构模型、用于图查询和验证的图语言以及图中上下文的表示。

1.1 模型（Models）

1.1.1 有向边标记图（Directed Edge-labelled Graphs）

简称del图，也被叫做多关系图（multi-relational graph）。

在知识图谱中，节点代表实体，比如Fig.1中的Santiago等；边表示实体之间的二元关系，如Fig.1中的Santa Lucia–$city$–>Santiago。

1.1.2 异构图（Heterogeneous Graphs）

异构图与del图类似的是，其边标签和边类型是对应的；不同的是，节点作为异构图本身的一部分，而不是表示为一种特殊关系，如Fig.2所示。

Fig.2中：
同构边（homogeneous）：边位于两个相同类型的节点，如$borders$
异构边（heterogeneous）：边位于两个不同类型的节点，如$capital$

异构图允许通过类型划分节点，并通常假定类型和节点是一对一的关系。
del图中通常则不同，比如Fig.1中零类型的节点Santiago和多类型的节点EID15。

1.1.3 属性图（Property Graphs）

属性图允许一组属性值对或者一个标签与节点和边相连。

例如，考虑对提供航班的航空公司进行建模。在del图中，我们不能直接给像Santiago–$flight$–>Arica这样的边进行公司的注释，但是我们可以添加一个表示航班的新节点，并将其与源、目的地、公司和模式连接起来，如Fig.3(a)所示。将此模式应用于大型图可能需要进行重大更改。相反，Fig.3(b)举例说明了一个具有类似数据的属性图，其中边缘上的属性值对表示公司，节点上的属性值对表示纬度和经度，节点/边标签表示节点/缘的类型。虽然尚未标准化，但属性图已用于流行的图形数据库，如Neo4j。虽然更复杂的模型在如何将数据编码为属性图方面提供了更大的灵活性(例如，使用属性图，我们可以继续将飞行建模为Fig.3(b)中的边)，可能导致更直观的表示，但这些额外的细节同样需要更复杂的查询语言、形式语义和归纳技术，而不是更简单的图模型，如del图或异构图。

1.1.4 图数据集（Graph Dataset）

图数据集允许管理多个图，并由一组命名图（named graph）和一个默认图（default graph）组成。每个命名图由图ID和图本身组成。默认图是一个没有ID的图，并且如果没有指定图形ID，则引用默认图。

Fig.4提供了一个示例，其中Events和Routes存储在两个命名图中，默认图管理关于命名图的元数据。虽然示例使用del图，但图数据集可以推广到其他类型的图。图数据集对于管理和查询来自多个数据源的数据非常有用，其中每个数据源都可以作为一个单独的图进行管理，允许根据需要查询、更新、删除单个图等。

1.2 查询（Querying）

许多用于查询图的语言已经被提出，包括用于RDF图的SPARQL、Cypher 、Gremlin 查询语言。用于查询属性图的 G-CORE。现在我们来描述一些作为这些语言基础的常见原语。

1.2.1 图模式（Graph Patterns）

图模式（基本图模式）是一种与被查询的数据图类似的图，但它也可能包含变量。因此，图模式中的术语被分为常量(如Fig1.中的Arica或$venue$)和变量(我们用问号作为前缀，如?event或?rel)。

通过生成从图模式的变量到数据图中的常量的映射，根据数据图对图模式进行评估，这样在映射下的图模式的图像(用分配的常量替换变量)就包含在数据图中。

Fig.5显示了一个查找美食节场地的图模式，以及该图模式根据Fig.1的数据图生成的映射。在Fig.5表中显示的后两种映射中，多个变量被映射到相同的术语，这取决于其应用，可能需要也可能不需要。

因此，已经提出了许多用于评估图模式的语义，其中最重要的是：

• 基于同态的语义（homomorphism-based semantics），它允许将多个变量映射相同的术语，这样Fig.5中所示的所有映射都将被视为结果(SPARQL采用了这种语义)。
• 基于同构的语义（isomorphism-based semantics），它要求节点和（或）边上的变量映射唯一的术语，从而从结果中排除Fig.5中的后三种映射(Cypher对边变量采用了这种语义)。

1.2.2 复杂图模式（Complex Graph Patterns）

图模式将输入图转换为结果表(如Fig.5所示)。复杂图模式允许使用关系代数对一个或多个图模式的表结果进行转换，如SQL等查询语言所支持的那样。图形查询语言如SPARQL和Cypher支持复杂图模式。

其中的运算符包括：

• 如投影($\pi$，又称SELECT)，
• 选择(σ，又称WHERE或FILTER)，
• 并集(∪，又称UNION)，
• 差(−，又称EXCEPT)，
• 内连接($\bowtie$，又称NATURAL JOIN)，
• 左外连接(`$\bowtie$，(也就是LEFT OUTER JOIN 或 OPTIONAL)
• 反连接($▹$，也称NOT EXISTS)等等。

Fig.6显示了一个复杂图模式，查找不在圣地亚哥举行的美食节或饮料节，并可选择返回它们的名称和开始日期(如果有的话)。我们用粗体表示投影变量。复杂图模式使用关系运算符(∪，$▹$，`$\bowtie$)组合了五种基本图模式(Q1，…，Q5)的映射表，生成所示的结果。

复杂图模式会产生重复的结果；例如，如果我们在Fig.5中只投影变量?ev，那么EID16(单独)作为结果出现四次。
查询语言通常提供两种语义：包语义（bag semantics）根据底层映射的多重性保留重复项，而集合语义（set semantics又名DISTINCT）从结果中删除重复项。

1.2.3 导航图模式（Navigational Graph Patterns）

路径表达式 $r$是一个正则表达式，可用于正则路径查询$(x,r,y)$，其中$x$和$y$可以是变量或常量，以匹配任意长度的路径，基本路径表达式中 $r$ 是一个常量(一个边标签)。

然后可以在许多不同的语义下计算常规路径查询。例如，根据Fig.1的图计算(Arica, bus*，?city)可能匹配以下路径:

1. Arica
2. Arica–$bus$–>Vina del Mar
3. Arica–$bus$–>Vina del Mar–$bus$–>Arica
4. …

事实上，由于存在循环，因此可能有无限多条路径匹配。由于这个原因，通常应用限制语义，只返回最短路径，或者没有重复节点或边的路径(如Cypher的情况)而不是返回路径，另一种选择是返回由匹配路径连接的(有限)节点对集合（比如SPARQL 1.1）。

然后可以在图模式中使用常规路径查询来表示导航图模式，Fig.7演示了从非洲乘公共汽车或飞机(可递归进行)可到达的城市中搜索美食节的查询。将规则路径查询与复杂图模式相结合，产生了复杂的导航图模式，SPARQL 1.1支持这种模式。

1.3 验证有效性（Validation）

虽然图为各种大规模的不完整数据提供了灵活的表示，但我们可能希望验证我们的数据图遵循特定的结构，或者在某种意义上是“完整的”。例如，在Fig.1中，我们可能希望确保所有事件至少具有名称、地点、开始和结束日期，以便使用数据的应用程序清楚所需要提供的最少信息。促进这种验证的一种机制是使用形状图（Shapes Graphs）。

1.3.1 形状图（Shapes Graphs）

形状针对数据图中的一组节点，并指定对这些节点的约束。可以使用查询等方式手动指定形状的目标。一组相互关联的形状组成形状图。

形状图可以被描述为类似UML的类图，Fig.8展示了一个基于Fig.1的形状图的例子，定义了四个相互关联的形状的约束。每个形状(用Place、Event等方框表示)都与一组约束相关联。当且仅当节点满足该形状上定义的所有约束时，节点才符合该形状。

在每个形状框内，可以对符合节点与边标签（例如，$name$、$start$等）相关联的节点的数量（例如，[1…$\ast$]表示一对多，[1…1]精确地表示1等）和类型（例如，string、dateTime等）施加约束。
另一种选择是对符合特定形状的节点数量进行约束，该特定形状的节点可以与边标签相关联(从而在形状之间生成边)；例如:Event –$venue,\mathrm{1..}\ast$–> Venue 表示符合Event的节点必须链接到至少一个带有边标签$venue$的符合Venue形状的节点。形状可以继承父形状（用$\Delta$表示）的约束，如形状Venue和City的父形状为Place。

形状的布尔组合可以使用连接（AND）、析取（OR）和否定（NOT）来定义；例如，我们可以说$venue$的所有值都应该符合Venue AND(NOT City)，明确数据中的venue不应该直接作为city被给出。

1.3.2 一致性（Conformance）

在前方形状的定义中已经说明，如果节点满足形状的所有约束，则该节点符合形状。

节点对形状的一致性可能取决于其他节点对其他形状的一致性。
例如，节点EID15不仅根据其本地属性符合形状Event，而且还根据Santa Lucía符合形状Venue, Santiago符合形状City。一致性依赖关系也可能是递归的，其中Santiago与City的一致性要求它符合形状Place，而Place又要求Viña del Mar和Arica符合形状Place，等等。相反，EID16不符合形状Event，因为它没有形状图所需的$start$和$end$属性。

当且仅当每个形状目标的每个节点都符合该形状时，图对于形状图(及其目标)是有效的。
例如，如果形状Event以EID15和EID16为目标，则Fig.1的图相对于Fig.8的形状图将无效(EID16不符合形状Event)，而如果形状Event仅以EID15为目标，并且没有定义其他目标，则图有效。

1.4 上下文（Context）

1.4.1 直接表示（Direct Representation）

表示上下文的第一种方法是将其视为与其他数据没有区别的数据。
例如，Fig.1中EID15事件的日期可以看作是直接表示时间上下文的一种特殊形式。另外，已经提出了许多规范，以更标准的方式直接表示上下文，包括用于时间上下文的时间本体，用于出处的PROV数据模型，等等。

1.4.2 具体化（Reification）

通常，我们可能希望直接定义边本身的上下文。Reification允许在图中描述边本身。
例如：假设从1956年起，Santiago–$flight$–>Arica这条航线是有效的。

Fig.9给出了时间上下文建模的三种具体化形式:RDF具体化（RDF reification）、n元关系（n-ary relations）、单例属性（singleton properties）。与直接表示不同，e 被视为表示图中的边，而不是一趟航班。虽然n元关系和单例属性更为简洁，且n元关系与路径表达式更兼容，但具体化的最佳选择可能取决于所选择的系统。文献中也提出了其他形式的物化，例如NdFluents。

1.4.3 高元表示（Higher-arity Representation）

我们还可以使用高元表示(它扩展了图模型)来编码上下文。

再次以 Santiago–$flight$–>Arica 为例。Fig.10说明了时间上下文的三个高元表示。

首先，我们可以使用一个已命名的del图(Fig.10(a))来包含边，然后在图名上定义时间上下文。
其次，我们可以使用属性图(图10(b))，其中时间上下文被定义为边上的属性。
第三，我们可以使用RDF*(图10($c$)): RDF的扩展，允许将边定义为节点。

这三种方法中最灵活的是命名图表示，我们可以通过将多个边放置在一个命名图中来一次将上下文分配给多个边。例如，向图10(a)的命名图添加更多1956年有效的边。
最不灵活的选项是RDF*，它没有边ID，不能捕获边上不同组的上下文值。例如，我们可以在 Chile–$president$–>M. Bachelet 的边上添加四个值，说明其有效期为2006年至2010年，有效期为2014年至2018年，但我们不能对值进行配对。

1.4.4 注释（Annotations）

前面介绍的方法关注的是如何表示上下文，而注释则允许定义上下文，从而实现对数据的自动上下文感知处理。

一些注释为特定的上下文域建模，另一些注释是域独立的。

介绍域独立的注释：Annotated RDF允许建模表示为半环（semi-rings）的各种形式的上下文:由域值(例如，时间间隔、模糊值等)组成的代数结构和组合域值的两个主要操作符:meet和join(不同于关系代数的join)。

Fig.11给出了一个示例，其中G用整数(1-365)注释，表示一年中的天数。我们使用区间表示法，使{[150,152]}表示集合{150,151,152}。

查询（query） Q询问从 Santiago 到有事件的城市的航班，并返回每个答案的时间有效性。

为了得到这些答案，我们首先应用meet操作符(这里定义为集合交集)来计算航班和城市边匹配的注释。
例如，在{[150,152]}和{[1,120]，[220,365]}上对Punta Arenas应用meet会得到空时间间隔{}，因此可以从结果中省略它。然而，对于Arica，我们找到了两个非空交叉点:EID16的{[123,125]}和EID17的{[276,279]}。
假设我们关注的是城市，而不是事件。因此我们使用join操作符组合这两个针对Arica的注释，返回其中任何一个结果都为真的注释。在我们的场景中，我们将join定义为集合的并集，给出{[123,125]，[276,279]}的答案。