知识图谱是近几年来一个蛮热的词，被认为是“认知智能领域核心技术之一”，“人工智能四大领域之一”等等。甚至有了不谈知识图谱不足以号称新技术的趋势。
这么重要的一个东东，它到底是什么呢？我们今天就来认识一下——
Google的Knowledge Graph（知识图谱）
“知识图谱”对应的英文是“Knowledge Graph”（简写KG），它最初的走红要归功于Google。
2012年Google提出了一项名为Knowledge Graph技术，在当时语境下指Google搜索引擎所使用的一种知识库，这个知识库中的信息来自多种源头。
KG这一知识库的应用对于Google搜索引擎的助力十分明显，它至今仍然在为用户的搜索提供服务。
如果你用Google搜索某个关键字，除了能在结果页面的主要部分看到若干和搜索词相关的网页链接外，还能够在页面右侧看到一个方框，里面有很多和你搜索的内容相关的其他内容。
比如下面这个例子，当我们用Google搜索“哥白尼”的时候，显示结果如下：
右侧信息框内，除了哥白尼自身的情况，还列出了一些书籍和人物。
这些书和人都没有出现在我们的搜索词里，但是又都和我们搜索的哥白尼有所关联——其中有些书是哥白尼写的；有些书是写哥白尼的；有的人是哥白尼思想的继承者；有的和他研究共同的领域……
它们在很大程度上帮助我们了解了哥白尼，甚至于比直接介绍哥白尼的文章更有启发性。这些“周边”信息，就是Google的知识图谱（KG）提供的。
从这个例子里，我们可以直观感受到：KG提供的是和搜索词有关系，但又不完全“一致”的信息。
这就是原本意义上的KG——Google发明并使用的一种专门的信息管理和检索的技术。
但后来，这个专有名词发生了变化，逐渐变成了一个通用名词，用来代指一个研究/应用领域。于是也就有了我们现在所说的知识图谱。
什么是知识图谱
通用名词
如今，作为通用名词的“知识图谱”没有一个严格的学术定义。
有些时候，“知识图谱”被用来表达和“本体论”（Ontology）大致相同的含义；另一些时候，“知识图谱”专指以图结构存储信息的知识库。
不过，在计算机领域，它最常见的解释是：知识图谱表示了一系列相互联系的实体 ，这些实体可以是现实世界中的任意人、事、物、状态或概念。
目前在研究或实践知识图谱技术时，基本上采用它的常见解释。
从计算机工程的角度来看待知识图谱，那么我们可以暂且将其理解为一种以图（Graph）结构表达实体及其之间关系的数据组织形式。
顶点和边
所谓图（Graph）是一种由对象集合组成的数据结构，对象之间存在着若干具有某种联系的“对象对（pair）”。
这些对象被抽象为顶点（vertice），也可以叫节点（node），每对关联对象之间的联系被抽象为边（edge），也可以叫做弧（arc）。
下图是一个图结构的示意图：
“以图结构来表达实体及其之间的关系”——就是将实体抽象为图中的顶点，而将其之间的关联抽象为边。
实体的属性
实体表达的是客观世界的事物，而客观事物都是具备各式各样的特征的。也恰恰是这些特征的差异使得每个个体得以区别于群体中的其他个体。
当我们在知识图谱中表达各个实体的时候，同样要表达它们各自的特征，于是就有了“属性（attribute/property）”这个概念。
知识图谱中的每个实体，都具备若干（0~n）个属性，每个属性则至少具备两个字段（field）：属性名和属性值。每个属性都表达了所属实体在某个方面的特征状态。
例如：一张表示研究机构内部人员和项目的知识图谱，其中某一个实体具备三个属性，它们分别是：
- 属性名：Type；属性值：Person
- 属性名：Name；属性值：J. Lehmann
- 属性名：Title；属性值：Prof. Dr.
有了这三个属性，我们就不难看出，这个实体表示的是机构中一位名叫J. Lehmann的教授。
而另一个实体同样具有这三个属性，它们对应的值分别是：Person，A. Fischer, Dr.。我们可知：这个实体表示的是一位名叫A. Fischer的博士生。
知识图谱的表达
图形化表达
【展示属性 vs 不展示属性】
我们经常可以见到直接表示为示意图形式的知识图谱，比如下面这个：
知识图谱-实例-1
这种表达方式的好处显而易见：有什么实体，实体有什么属性，实体之间的关系是什么，都一目了然。
当然，鉴于很多时候实体的属性会比较多，所以大多数情况下我们在绘制这类示意图的时候，并不把属性直接展现在图中，而是仅展示实体和关联两部分。例如下图：
知识图谱-实例-2
【边的方向性】
这里要强调一下边的方向性：图结构中的边可以有方向，也可以无方向。
边有方向的图叫做有向图（Directed Graph），反之叫做无向图（Undirected Graph）。
那么，知识图谱中的边有没有方向呢？一般是有方向的。
大多数情况下，现实世界的两个事物之间如果存在某种关联，这个关联往往不是对等的，而是有一个主体和一个客体，关联是主体施加给客体的。
比如：在某个知识图谱中，达芬奇是一个实体，《蒙娜丽莎》油画是另一个实体。它们之间存在关联——达芬奇绘制了《蒙娜丽莎》。这种“绘制”关系只能是单向的，从达芬奇到《蒙》，而不是反过来：
知识图谱-实例-3
当然，现实中也存在那种“互为XX”的关系。比如人际关系中常见的“朋友”，如果两个人是朋友，那么也就是说他们互相是对方的朋友，“朋友”这种关联在两个实体之间是对等的。
遇到这种情况，我们可以在两个人物实体之间建立两个被标志为“朋友”的关联，也就是两个顶点之间存在两条方向相反的边。
在实际绘制的时候可以将两条边merge为一条双向边，但其含义仍然是两条边（如下图）：
知识图谱-实例-4
文字表达
【顶点记录和边记录】
用示意图表达知识图谱固然直观，但是毕竟时常信息不全（不显示属性）。另外，这种方法用于十几个到几十个顶点的小图谱还好，如果是成千上万的顶点，非把人看晕了不可。
最靠谱的，还是文字表达。
用文字如何表达知识图谱呢？其实没有一定之规，只要能将实体、属性、关联清晰地展示出来即可。
因为属性原本就是从属于实体的，因此，我们可以分“顶点”和“边”两个部分来表达知识图谱：
- 顶点部分由若干条实体记录构成，每条记录对应一个实体。 实体记录内容包括：实体id及其所包含的属性列表。
- 边部分由若干条边记录构成，每条记录对应某两个实体之间的一种关联。 边记录内容包括：头实体id，尾实体id和关系类型。
注【1】：之所以每个实体要有一个id，是因为我们需要唯一key来标识每个实体，id就是这个key，在一个知识图谱里，每一个实体的id都是全局唯一的。
注【2】：之所以边记录要区分头实体和尾实体，是对应前面讲过的关联的方向性。头实体对应主体，尾实体对应客体。
【记录的格式】
具体每条记录以什么样的数据格式呈现，也完全可以自己定义。
最直接的，我们可以用json格式来表达实体和边。
例如知识图谱-实例-1的文字表示就可以是如下这样：
顶点记录：
代码语言：javascript复制[
{
"entity_id": "entity_Lehmann",
"properties": [
{
"property_name": "Type",
"property_value": "Person"
},{
"property_name": "Name",
"property_value": "J. Lehmann"
},{
"property_name": "Title",
"property_value": "Prof. Dr."
}]
}, {
"entity_id": "entity_Fischer",
"properties": [
{
"property_name": "Type",
"property_value": "Person"
},{
"property_name": "Name",
"property_value": "A. Fischer"
},{
"property_name": "Title",
"property_value": "Dr."
}]
}
... ...
]边记录：
代码语言：javascript复制[
{
"relationType": "work with",
"head_entity_id": "entity_Lehmann",
"tail_entity_id": "entity_Fischer"
},{
"relationType": "work with",
"head_entity_id": "entity_Fischer",
"tail_entity_id": "entity_Lehmann"
}
......
]上面只是一种最简单的表达，根据需要给实体或者边记录添加其他字段，是完全可以的。
还有，如果我不想用json格式，就要把顶点和边都存储在XML文件中行不行呢？当然可以！
具体的数据格式、文件格式、字段定义……都不重要，关键是能够展示实体、属性和关联就好，并满足应用的需要就好！
构建一个知识图谱
我们已经知道了知识图谱是什么，以及用图像和文字怎么描绘它，那是不是我们就可以构建自己的知识图谱了？理论上是可以的。
一个知识图谱能够存在，关键在于：它有哪些顶点，有哪些边，以及它们分别表达和何种含义。
只要有了顶点和边，就能构成一张图（Graph），而只要顶点表达的是实体，边表达的是实体间关联，这张图就可以被叫做知识图谱。
如前所述，知识图谱中的实体（也就是顶点），可以是这个世界上的万事万物，可虚可实，具体是什么，全看图谱的创建者如何定义。
同理，实体间的关联也是如此——一般情况下，任意两个实体之间，可以有任意的关系/联系，一张生成后的知识图谱里哪些具体的顶点之间有哪些具体的边，全看创建者的规定。
换言之，只要我们头脑中有一些事物，了解这些事物的特征，并且知道它们之间是如何相互作用或联系的，我们就可以构建出自己的知识图谱！
最简单的构建办法：直接画出来就好了。
COVID-19 知识图谱
新冠疫情
2020年初，新冠疫情来临，COVID-19病毒横行一时，整个国家乃至整个世界都被带入到“抗疫”的节奏之中。
作为普通人，每个人都必须在短时间内学习许多医学、社会学、卫生保健等涉及到多个专业的知识来保护自己——对于大家的学习能力还真是不小的挑战呢。
好在，这些知识看似纷乱繁杂，其实却是相互关联、环环相扣的。而知识图谱恰恰具备将这种关联厘清和展示的功能，非常适合用于描述知识点及其间的关系。
COVID-19知识图谱（草图）
如果我们能够构建一个以COVID-19为核心的知识图谱，围绕病毒展开，揭示病毒的感染机理、导致疾病、预防方式、治疗手段等，那不是对我们了解防疫工作很有价值嘛——我向生物学专家和渊老师分享了这一想法。
清华生物博士和渊老师
和渊，清华大学生物专业理学博士。 现任教于中国人民大学附属中学，高级教师，北京市海淀区学科带头人。 中国青少年科技辅导员协会高级辅导员，中国教育科学研究院STEM课题主持人。
和渊老师非常支持，然后用了不到半小时时间，绘制了下面这幅图：
和渊老师手绘COVID-19知识图谱草图
这里需要说明一下，和老师的专业是生物学，对计算机科学并不熟悉，原本也不了解”知识图谱“。
笔者也只是在请和老师绘制上述图谱之前口头介绍了一下知识图谱是什么，当时所说内容还没有本文章前面内容多呢。
即使如此，和老师还是迅速画出了上图。这是因为这张图原本就在和老师脑子里——那些作为顶点的概念和作为边的关联，原本就是和老师所掌握的知识，如今不过是用这样一种形式呈现出来了而已！
反过来，如果一个人头脑空空，原本也没有任何信息想要表达，那再怎么学知识图谱的定义、表示方式也还是构建不出图谱来。
说白了，知识图谱是一种表达思想的方式，而其所传达的内容才是关键。
COVID-19知识图谱及数据
基于i）上面手绘图，ii）和老师追加的手绘图修正意见，以及iii）下一步应用该图谱的考虑，笔者做了一些修改——将2019-nCov改成了COVID-19，增加了一些新的实体，对少量原有实体和关系做了删节和重构。
于是有了下面这个COVID-19知识图谱：
COVID-19知识图谱
图中只展示了实体和关联，当然每个实体都是有属性的。
除了上面的示意图，我们还有对应的json格式的顶点和边的数据（如下，其中实体的属性数据也是和渊老师根据2020年2月底时的信息整理的）。
顶点（实体）记录：
代码语言：javascript复制[{
"entity_id": "vertex_2019ncov",
"properties": [{
"property_name": "名称",
"property_value": "COVID-19"
},
{
"property_name": "别名",
"property_value": "新型冠状病毒"
},
{
"property_name": "增殖过程",
"property_value": "1. RNA复制；2. 转录翻译"
},
{
"property_name": "侵染对象",
"property_value": "粘膜细胞ACE"
}
]
}, {
"entity_id": "vertex_coronapneu",
"properties": [{
"property_name": "名称",
"property_value": "新型冠状病毒肺炎"
},
{
"property_name": "别名",
"property_value": "新冠肺"
},
{
"property_name": "死亡率",
"property_value": 0.02
}
]
}
......
]边（关联）记录：
代码语言：javascript复制[
{
"relationType": "导致",
"head_entity_id": "vertex_2019ncov",
"tail_entity_id": "vertex_coronapneu"
}
......
]COVID-19 知识图谱的用途
COVID-19知识图谱已经被构建出来了。那么，它又有什么用呢？用处有很多。
比如，我们可以以其为知识库，创建一款具备疫情知识的智能问答机器人（chatbot），该机器人根据COVID-19知识图谱中的内容回答用户用自然语言提出的问题。
智能问答机器人是一个软件/程序，它如何从图谱中获取某一条知识？要想“听懂”用户的问题，只有知识图谱就够了吗？是不是还需要其他一些模块和功能？除了直接回答问题外，还有什么办法能够帮助人类用户了解更多的新冠知识？……
这些问题，等我们的下一篇文章再来做解答吧。
