[长]知识图谱入坑笔记

1.1.1. 实体（entity）、本体（ontology）、与模式（schema）

1.1.2. RDF（Resource Description Framework） 资源描述框架

1. 基本要素
   

   资源描述框架是干什么的？

   描述资源的！

   资源是什么？

   资源是对象！对，资源就是对象。

   所以，RDF本质上类似于面向对象编程语言中对对象的封装，也就是， 使用各种属性和对应的属性值来描述一个实体 。

   因此，一个RDF本质上包括：

   • 资源（R）。也就是对象。
   • 属性（Realtion)。描述了资源之间的关系。

   但是，光有这两点显然还是不够的，资源提供了一个个的节点，而属性提供了节点的连接，所以应该最后还有一个描述的操作，被称作声明。

   RDF中存储的就是声明。声明主要是包括了（资源，属性，值）的一个三元组。而此处的“值”，当属性为“谓词”的时候，为一个资源对象。 但是，值未必一定是实体，也可能是构成实体的“原子值”（当然这也是一种特殊的实体），原子值在绝大多数时候是字符串）。

   那么，整个知识图谱只剩下了最后一步，如何查询（寻找）这些资源或者属性？

   辨识的方式是基于URL进行的。可 以网络中的URL进行理解。所以，一个声明（一个三元组）本质上就是存储了三个URL的列表。

   一般而言，URL按类型还可以继续分为：

   1. IRI（international Resource Identifies），类似于一般意义上的index；
   2. blank nodes，空白；
   3. literals。原子值中最大的一种。
2. 声明也是一种对象，图也是一种资源
   

   刚才说过，一个实体可以有多个属性，这样不同的实体就可以彼此连接起来，形成一张巨大而稀疏的图，这和知识图谱具有了结构上的一致。 一般而言，这张图是有向的，从主体（subject）借助关系（谓词，predicate）指向客体（object）。这样的图往往只适合用三元组 进行表达，而非邻接矩阵等东西。因为两个节点之间可以有1000条边。

   一般而言，在知识图谱中，资源用圆圈表示，谓词用方框表示.

   那么，对于这样的一个图——也就是一个声明的集合——一个三元组的集合，能否把它也看做一个实体呢？

   首先，单个的一个声明是可以看作一个实体的，它有三个属性（主体、谓词、客体）。 一张图其实也可以看作一个实体，这里就有了一些meta的味道。

3. RDF常用语法
   
   1. Turtle .ttl文件
      

      下图展示了一个基本的三元组：

      <http://www.semanticwebprimer.org/ontology/apartments.ttl#BaronWayBuilding>
      <http://dbpedia.org/ontology/location>
      <http://dbpedia.org/resource/Amsterdam>.
      

      可以看出：

      1. 每一行都是URL。
      2. 最后以句号结束。

      下面展示一个带原子值的：

      <http://www.semanticwebprimer.org/ontology/apartments.ttl#BaronWayAppartment>
      <http://www.semanticwebprimer.org/ontology/apartments.ttl#hasNumberOfBedrooms>
      "3"^^<http://www.w3.org/2001/XMLSchema#integer>.
      

      可以发现，原子值被放在了双引号内，后面有URL展示其数据类型。

      在此基础上，主要诞生了以下语法：

      1. 缩写。类似于C++中的明明空间的概念，可以用一个简段的符号把上面例子中的重复部分做映射，使用命名空间的方式进行定义；
      2. 省略主体。如果主体相同，声明之间可以用分号隔开，省略主语；
      3. 省略主体和为词。如果主体和谓词相同，声明之间可以用逗号隔开，省略主体和谓词；
      4. 为声明或图定义URL。使用大括号获得一个声明集合的对象化。

      详情可以参考这篇笔记： 知乎-语义网络基础笔记1

   2. XML语言
      

      例子如下：

      <?xml version="1.0" encoding="utf-8"?>
      <rdf:RDF xmlns:dbpedia-owl="http://dbpedia.org/ontology/"
          xmlns:dbpedia="http://dbpedia.org/resource/"
          xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
          xmlns:swp="http://www.semanticwebprimer.org/ontology/apartments.ttl#">
      <rdf:Description
      rdf:about="http://www.semanticwebprimer.org/ontology/apartments.ttl#BaronWayAppartment">
          <swp:hasNumberOfBedrooms
          rdf:datatype="http:www.w3.org/2001/XMLSchema#integer">
              3
          <swp:hasNumberOfBedrooms>
      </rdf:Description>
      

1.1.3. RDFS ——RDF Schema

1. 与RDF的区别
   

   如果说RDF是在对对象进行的操作的话，那么RDFS就是在对类进行操作。这就是二者的区别。

   可以简单用下图作为区别式的理解：

   

2. 基本语法
   

   现以这篇笔记为例展示其基本语法。

   @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
   @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
   @prefix : <http://www.kg.com/ontology/> .
   
   ### 这里我们用词汇rdfs:Class定义了“人”和“地点”这两个类。
   :Person rdf:type rdfs:Class.
   :Place rdf:type rdfs:Class.
   
   ### rdfs当中不区分数据属性和对象属性，词汇rdf:Property定义了属性，即RDF的“边”。
   :chineseName rdf:type rdf:Property;
   	rdfs:domain :Person;
   	rdfs:range xsd:string .
   
   :career rdf:type rdf:Property;
   	rdfs:domain :Person;
   	rdfs:range xsd:string .
   
   :fullName rdf:type rdf:Property;
   	rdfs:domain :Person;
   	rdfs:range xsd:string .
   
   :birthDate rdf:type rdf:Property;
   	rdfs:domain :Person;
   	rdfs:range xsd:date .
   
   :height rdf:type rdf:Property;
   	rdfs:domain :Person;
   	rdfs:range xsd:int .
   
   :weight rdf:type rdf:Property;
   	rdfs:domain :Person;
   	rdfs:range xsd:int .
   
   :nationality rdf:type rdf:Property;
   	rdfs:domain :Person;
   	rdfs:range xsd:string .
   
   :hasBirthPlace rdf:type rdf:Property;
   	rdfs:domain :Person;
   	rdfs:range :Place .
   
   :address rdf:type rdf:Property;
   	rdfs:domain :Place;
   	rdfs:range xsd:string .
   
   :coordinate rdf:type rdf:Property;
   	rdfs:domain :Place;
   	rdfs:range xsd:string .
   

   上面我们定义了person和place两个东西——用三元组定义的。我们在定义他们的时候，他们同样也是实体，但在我们使用他们时，他们成了类。

   简单列举一下可能用到的一些约定：

   • 核心类：
     • rdfs：Resource，所有资源的类；
     • rdfs:Class,所有类的类
     • rdfs:domain, 属于哪个类
     • rdfs:range, 类型
     • rdfs:Literal，所有文字(字符串)的类。
     • rdf:Property，所有属性的类。
     • rdf:Statement，所有具体化声明的类。
   • 核心属性：
     • rdf:type，将一个资源关联到它的类。该资源被声明为该类的一个实例。
     • rdfs:subClassOf，将一个类关联到它的超类。一个类的所有实例都是它的超类的实例。注意，一个类可能是多个类的子类。
     • rdfs:subPropertyOf，将一个属性关联到它超属性中的一个。
     • rdf:subject，讲一个具体化声明关联到它的主语。
     • rdf:predicate，将一个具体化声明关联到它的谓语。
     • rdf:object，讲一个具体化属性关联到它的宾语。

   个人观点：随着实体的复杂，一个实体可以属于无数个类，或者说，大量的有限多个类。跨领域很重要。所谓的层次结构，并不天然适合描述 实体。实体是复杂的，一个层次结构仅仅是一个角度上的投影。

   另外，谈论到这里，可以挖掘到过去的一些符号主义的影子。什么叫符号？ Place 和 Person就是符号。因为他们本质上不过是string， 却同时有类的值和实体的类两种特征。

   下图可以更明白地区分两种层次：

   

   参考链接：

   知乎-语义网络基础笔记1

   lalal

   现在可以呈上一个架构图，看看我们到底走了多远：

   

1.1.4. OWL Ontology of Web Language

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix : <http://www.kg.com/ontology/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

### 这里我们用词汇owl:Class定义了“人”和“地点”这两个类。
:Person rdf:type owl:Class.
:Place rdf:type owl:Class.

### owl区分数据属性和对象属性（对象属性表示实体和实体之间的关系）。词汇owl:DatatypeProperty定义了数据属性，owl:ObjectProperty定义了对象属性。
:chineseName rdf:type owl:DatatypeProperty;
	rdfs:domain :Person;
	rdfs:range xsd:string .

:career rdf:type owl:DatatypeProperty;
	rdfs:domain :Person;
	rdfs:range xsd:string .

:fullName rdf:type owl:DatatypeProperty;
	rdfs:domain :Person;
	rdfs:range xsd:string .

:birthDate rdf:type owl:DatatypeProperty;
	rdfs:domain :Person;
	rdfs:range xsd:date .

:height rdf:type owl:DatatypeProperty;
	rdfs:domain :Person;
	rdfs:range xsd:int .

:weight rdf:type owl:DatatypeProperty;
	rdfs:domain :Person;
	rdfs:range xsd:int .

:nationality rdf:type owl:DatatypeProperty;
	rdfs:domain :Person;
	rdfs:range xsd:string .

:hasBirthPlace rdf:type owl:ObjectProperty;
	rdfs:domain :Person;
	rdfs:range :Place .

:address rdf:type owl:DatatypeProperty;
	rdfs:domain :Place;
	rdfs:range xsd:string .

:coordinate rdf:type owl:DatatypeProperty;
	rdfs:domain :Place;
	rdfs:range xsd:string .

1. OWL的推理与知识图谱补全
   

   OWL的优势在于推理。主要包括以下推理：

   1. 基于谓词逻辑的推理。 暂略，有时间专门写笔记填坑。
   2. 知识图谱补全。主要是根据关系之间的关系。比如，如果A是B的爸爸，那么B肯定是A的儿女。
   3. 本体映射。主要应用在知识图谱融合。比如，判断两个类是否是同一个，两个实体是否是同一个，连个属性是否是同一个等等。

   所有的基于规则的推理，大约都是可以应用在这种三元组上的。

1.1.5. SPARQL： RDF的Query Language

SELECT * WHERE {
  ?s ?p ?o
}

SELECT ?n WHERE {
  ?s rdf:type :Person.
  ?s :personName '周星驰'.
  ?s :hasActedIn ?o.
  ?o :movieTitle ?n
}

1.2.1. DBpedia

1.2.2. Yago

1.2.3. wikidata

>>> from wikidata.client import Client
>>> client = Client()  # doctest: +SKIP
>>> entity = client.get('Q20145', load=True)
>>> entity
<wikidata.entity.Entity Q20145 'IU'>
>>> entity.description
m'South Korean singer and actress'
>>> image_prop = client.get('P18')
>>> image = entity[image_prop]
>>> image
<wikidata.commonsmedia.File 'File:KBS "The Producers" press conference, 11 May 2015 10.jpg'>
>>> image.image_resolution
(820, 1122)
>>> image.image_url
'https://upload.wikimedia.org/wikipedia/commons/6/60/KBS_%22The_Producers%22_press_conference%2C_11_May_2015_10.jpg'

1.2.4. ConceptNet

1.2.5. Microsoft Concept Graph

1.2.6. 特定的中文知识图谱

1. Zhishi.me
   

   下载地址： http://openkg1.oss-cn-beijing.aliyuncs.com/470c372e-9b16-4076-9101-5696fa4f810d/zhishime-ttl.zip

   论文地址： http://iswc2011.semanticweb.org/fileadmin/iswc/Papers/In-Use/70320209.pdf

   Zhishi.me 是第一份构建中文链接数据的工作， 与 DBpedia 类似，Zhishi.me 首先指定固定的抽取规则对百度百科、互动百科和中文维基百科中的实体信息进行抽取， 包括 abstract、infobox、category 等信息； 然后对源自不同百科的实体进行对齐，从而完成数据集的链接。 目前 Zhishi.me 中拥有约 1000 万个实体与一亿两千万个 RDF 三元组，所有数据可以通过在线 SPARQL Endpoint 查询得到。

2. Zhishi.schema
   

   Zhishi.schema 是一个大规模的中文模式（Schema）知识库，其本质是一个语义网络， 其中包含三种概念间的关系，即equal、related与subClassOf关系。 Zhishi.schema抽取自社交站点的分类目录(Category Taxonomy)及标签云（Tag Cloud）， 目前拥有约40万的中文概念与150万RDF三元组，正确率约为84%，并支持数据集的完全下载。

3. XLore
   

   XLore 是一个大型的中英文知识图谱。来自于THUNLP组。 它旨在从各种不同的中英文在线百科中抽取 RDF 三元组，并建立中英文实体间的跨语言链接。 目前，XLore 大约有 246 万个概念，44 万个属性，1600 万的实体，所有数据可以通过在线 SPARQL Endpoint 查询得到。

   项目主页在这里。数据下载主页在这里。

   除此之外，该项目还维护了一个Knowledge Embedding的开源框架，叫做OpenKE。OpenKE的主页在这里。 后续，在介绍知识图谱与预训练模型的结合方式时，会更进一步对这个框架进行分析。

4. 中文开放知识图谱平台
   

   从上面可以找到各种知识图谱相关的数据。 http://openkg.cn/home

2.1.1. 嵌入空间不同

2.1.2. 知识噪声

2.2.1. ERNIE

1. 模型输入
   

   seqence的输入比较简单，就是各token的各层次embedding（如位置、段、语义等等）在组合之后进入T-encoder模块； 知识的输入只有实体，实体的表示使用的是transE算法。

2. 知识融合
   

   ERNIE的知识融合，只是在sequence中和实体相同意义的token之间完成的。比如在上图中，bob这个名字，和实体一致，所以二者才会融合。 像wrote这种词是不会进行融合的。

   一般而言，这种寻找类似名字实体的工作，被叫做对齐（alignment）。 论文中使用的方法比较简单，即训练一个线性层+softmax进行实体对齐。

   

   在此处，作者还借助于MLM任务对实体对齐进行了进一步的训练，但是我好像不太理解这种训练的意义……

   对于那些进行了融合的词，其操作是：

   

   对于没有东西进行融合的，其操作是：

   

   注意到，一共有四个映射矩阵，外加两个偏移修正。

   σ 指的是GELU函数。

2.2.2. Know-BERT

2.2.3. KG-BART: Knowledge Graph-Augmented BART for Generative Commonsense Reasoning

1. 论文基本信息
   

   论文地址见这里，源码见这里。

   这篇论文是AAAI2021上的一篇文章，看作者有很多个大学，伊利诺伊大学芝加哥分校、华科、北航等等等等。 看题目，很容易理解这篇论文的目的：将KG和BART做了一个结合。BART是facebookAI去年（2020）发表的一篇工作，其模型结构同于 transformer，是一种encoder-decoder格式的模型（这种模式又在Google的T5上验证了其有效性），BART的出现是为了让PTMs既具有 BERT那种NLU的能力，同时也具有GPT那种NLG的能力。不过目前来看主要还是被应用在NLG相关任务上居多。

   读该论文的题目的话，另一个或许会产生的问题就是“generative Commonsense Reasoning”是什么意思。一般而言，常识推理是指让计算机 具有和人类相同的常识所能解决的那类问题对应的技术。而此处的“生成式”常识推理，则是考虑在文本生成过程中可能会用到的一些常识。

   为了验证论文模型中给出的常识推理的能力，作者全文实际上做的问题是“hard constrained NLG”。也就是，给定一个token集合，令模型 生成一段话，使得这段话里包含所有的输入集合中的token。

   下图展示了这样的一个例子：

   

   当我们给定河流，鱼，网，抓这几个词的时候，期待的结果应该是，一个渔夫在河边用网抓鱼。但是，如果缺少常识，就可能理解成“河中鱼在 抓网”这种东西。他们仍然是保持语法的，但是却显然不合常识，因为一般水平的鱼不会抓网。这篇论文就是试图解决这样的问题的。 作者解决此等问题的大致思路如下：

   1. 挖掘输入诸名词所对应的概念（concept）之间的关系。在conceptnet（也就是本文所使用的知识图谱，前面已经介绍过）中，这些实体

   之间的关系可以被检索得到，通过一个三元组进行表达。而这样的一个三元组，本质上就是一个常识。比如river和fish之间，就有两种关系， 其中一条是：fish在river里。

2. 结合前的模型
   
   1. 预训练模型
      

      BART, 包含encoder和decoder两个部分.

   2. 知识图谱及其表示的提取方法
      

      所使用的知识图谱是conceptNet, 前面已经有过介绍.

      关于提取知识图谱中实体和关系对应的embedding的方法, 此处使用的是transE. transE用来为知识图谱中的实体和边学习一个向量表示. 其基本思路可如下图表示:

      即: 默认实体和边的表示之中存在这样一种关系:头部+关系=尾部. 基于这种思路所定义的损失函数为:

      

      从中可以看出,同一种relation, 找到对应三元组的一个正例和一个反例, 之后使用对比训练的方式进行就好了.

      后续还会有一些工作, 将实体和关系置于两个空间, 而后使用一个矩阵做projection(也就是空间的对齐), 此处不再赘述.

3. 结合方式及具体相关细节
   
   1. 概览
      

      二者总体的结合方式可由下图表示:

      

      从中可以看出, 在bart的encoder和decoder处都具有知识图谱的融合, 二者的轻微区别是:

      1. 对于G^R, 主要是用来进行概念推理(reasoning)的,因此与encoder进行结合,帮助对词义的更好理解.

      因此,G^R中的三元组,头部与尾部的实体都是在输入中存在的word, 其表示为(V_i^R, r_{ij}^R, V_j^R);

      1. 对于G^E, 主要是用来进行文本生成的,因此与deocder进行结合,进行概念扩展(expanding).

      因此, G^E中的三元组,头部的实体来自于输入(或与输入实体的邻居实体中),尾部的实体则是与之相关的一些修饰词. 换句话说,扩展知识图谱的输入,是那些由输入实体集合对应的邻居实体集合构成的并集中的实体们维护的三元组. 当一个输入实体对应很多个邻居实体时,通常采用word-embedding对应的similairity score选取topk个.

   2. encoder部分结合细节
      

      

      对于和知识图谱的结合,论文阐述的比较复杂. 现一一剖析之. 上图所展示的知识图谱增强的思路是这样的: 对于输入x(x是token序列,相当于word(subword)级别),需要先通过一个变换转化到concept级别,这之后才能同知识图谱代表的 知识进行融合. 而融合之后的结果,常常也需要再进行一个反过程,才能变成输入x的一个更新之后的结果. 上述过程就是x->SCI->MGAT(融合)->CSD->x'.

      下面分别依照此对各个层次进行介绍.

      1. SCI
         

         使用的是一维卷积+池化层.

      2. [重点]融合部分 Multi-head Graph Attention
         

         融合部分使用的是GAT里的策略, 如下图所示.

         

         其对应的基本操作包括:

         1. 对推理图谱对应的实体们使用W_e进行映射得到W_eV^R;
         2. 对预训练模型的表示序列e^w(维度是k*d_w, k是concept的个数,d_w是embedding的长度)和知识图谱的映射后的表示进行拼接;
         3. 将拼接后的结果, 在原知识图谱的结构上, 使用GAT的加和型注意力机制进行特征更新.
      3. CSD: Concept 2 subword
         

         先使用上采样进行序列扩充, 之后使用反卷积(Deconv1D)进行扩充处理,之后再使用两层全连接做线性变换,最后接上GeLU和LayerNorm.

   3. decoder部分结合细节
      

      

      decoder部分的知识图谱和前面的推理图谱,除了内容上的不一致之外, 在结构上也有其自身的特点. 由于G^E的构建是始于输入中所带有的word的,所以其图的结构本质上是一个树,也就是层次结构. 因此,在进行融合之前,当我们使用TransE获取了该图谱的浅显表示之后,首先进行的是特征提取. 同样地基于GAT, 其基本步骤如下:

      • 对整张知识图谱使用GAT进行特征提取,公式如下所示:

      

      • 只对出现的那部分word对应的实体进行特征更新, 公式如下所示:

      

      将得到的表示,也就是V^{R''},作为自注意力机制中QKV三件套里的K和V的输入(K常常等于V,在其他论文里同样如此);

      

      当然,也包括正常的注意力机制(AT^{TX}).

      把二者拼接在一起,使用一个线性变化,就可以得到最终的输出.

      

      在上述整个过程中,预训练模型部分的输入是y,输出是y^o.

2.3.1. K-Adapter

2.3.2. K-BERT