这一讲的主题是：一些高级的知识图谱是什么样的。三位讲者分别从他们各自带领的团队构建出来的高质量的知识图谱实例出发，从中我们可以认识到一些大佬们构建的优秀的知识图谱产品有哪些特点和优势，从中对我们自己构建知识图谱也可以得到一定的启发。

1 Diffbot 知识图谱

第一位讲者是来自Diffbot公司的CEO，他们公司的目标就是建立世界上第一个全面的人类知识图谱，并且他们认为实现这一目标唯一有效的方法就是全自动化构建知识图谱。

讲者团队构建的知识图谱名为Diffbot，所有数据都来源于公网并采用爬虫技术得到这些数据，这个知识图谱的规模大到包括超过100亿实体和高达惊人的1万亿事实。并且，这个知识图谱由于是自动化构建的，支持动态更新，每月可以自动增加1.5亿的实体。知识图谱中实体类型最多的是：人、组织、地点、产品、时间、文章等等，从这些经过排序后的实体可以发现在生活中人们最关心的事情是什么。构建Diffbot需要大约2000个CPU核，可见一般人也搞不起来这么大规模的知识图谱。

接下来，讲者为我们介绍了如何利用机器学习技术来构建Diffbot知识图谱，在整个构建pipeline中用到了50/60种机器学习算法，这里，主要讲解流程中的几个关键组件，包括：

Page type classification：用机器学习种的分类算法，对网络爬取种的每个页面进行分类，比如对图中的页面将其分类为人、产品、事件等类型，精度达到97%，高于人工分类的精度。

Visual extraction：讲者介绍他们是第一个在知识图谱构件中考虑了视觉信息抽取，比如在图片中找到和商品相关的哪些视觉信息，比如从商标中能知道品牌是什么甚至包括价格，并且也可以辅助进行页面分类，精度在92%-97%之间。

Natural language understanding：对于页面中的文本等文字信息采用NLP技术来抽取信息，并能够理解文本中编码的事实是什么，因为事实才是知识图谱的核心。讲者展示了一个demo，可以自动从一个页面中抽取出其中包含的所有属性和对应的事实知识，其中肯定需要命名实体识别和关系抽取等机器学习技术，让我不禁联想到前段时间非常火热的Magi，这两个系统感觉都能自动化从文本数据中进行知识抽取，只是讲者介绍的这个Diffbot系统还能够抽取视觉信息。

Diffbot和Wikidata和Freebase相比，不仅能够找到实体，还能够用不同颜色来表示实体类型，此外，还能给出抽取出的事实和主题类型之间的关联，比如一名主题类型为教授的实体，其关联的事实包含在哪些学校任教，担任了哪些学术会议的主席等，这些能够对分类提供更多有效的证据。

Record linking：由于多个页面可能指向的同一个实体，因此需要用自动化的方法将大规模的对象进行链接，以此来实现数据融合。

在知识图谱应用方面，例如对网页中抽取出的知识表示如果售卖的nike鞋的价格低于市场零售价，那这个很可能就是仿制品。此外，还可以实现语义搜索的功能，与google不同的是，这个搜索引擎更能关注和问题相关的人类知识。

2 模块化本体工程

第二位讲者来自堪萨斯州立大学数据语义实验室的博士生（同样是博士生，人这真是大佬啊），他为大家介绍如何开发高度可重用的知识图谱，其中核心内容就是如何建立模块化的本体工程。

通过给出图中这个简单的知识图谱的例子，从这个知识图谱中我们可以提取出很多信息，包括“有学生”，“接受教育”，“生日”等，这是一个实例知识图谱，这个知识图谱很难重用到即使是相同领域的其它应用中。

从实例知识图谱可以扩展为表示schema的本体图谱，这里，每一个实体都用其类型来表示，但是在实例知识图谱中的18,171这个数字到底表示什么是无法确定的，因此如何去纠正这种情况就是研究的重点。

我们来看看一个好的知识图谱本体应该具有哪些特点：

首先，好的知识图谱本体模型应该是可以通过增加一个结点，将更多的结点连接到这一结点，并结合上下文信息来得到更多语义信息。

总结起来，一个好的知识图谱本体模型应该具有的特点是：

便于更新：当实例发生变化或有新的实例添加进来，本体模型都是可用的，这样可以减少维护成本。
人类可读文档：包括可读的术语，关系，标签等用来表示本体。
严格的定义：经过严格定义后的本体模型能够减少歧义性。

形式逻辑可以很好的表达人类概念的严格定义，并能精确地应用知识图谱。根据W3C标准的OWL格式，使用一种称为描述逻辑的高级语言对模式进行编码，在描述中，逻辑被称为公理，公理集被称为本体。

使用模块化的本体建模最大的优势是可以对动态更新的知识图谱快速自适应地建立本体模型，具有高度适应性和可重用性。

一个可高度重用的知识图谱本体模型应该是：实际应用驱动的、从模式中创造模块，整个本体模型的基本组成部分就是模块。

模块化本体工程用到几个概念：

模式图：一种图形化的表示来说明本体中类型之间的关系。其中包括几个组件：黄色框表示主要的实体类型，蓝色框表示还包括其它隐含的复杂关系的实体类型，箭头表示属性/关系，Agent是用来表示在不同的时间范围内指向不同的本体。Open arrow（图中没说明，讲者也没多解释）表示子类型关系。

系统公理化：通过检查结点-边-结点这种三元组结构的模式图，我们可以给出一个可推理的公理。这里给出的17种常见的公理是在知识图谱内部经常使用的，用这种模式图可以表示这17种公理。

来源于软件工程的设计模式，本体设计模式中，Agent和TemporalExtent都表示隐含的复杂性，因为它们在不同时间范围指向不同的本体。

构建本体模块的方法分为8个步骤：

1. 定义用例或者用例的范围，因为无法建模所有类型的对象，因此需要尽可能了解更多的细节。

2. 建立能力问题让用户和我们正在开发的知识图谱有更好的交互。

3. 从数据和用例中抽取关键的概念。

4. 从模式模板中初始化这些关键的概念，然后根据需求来构造模块。

5. 用17个公理来增加结点-边-结点的公理。

6. 集成模块并增加涉及多个模块的公理。

7. 检查是否能够反映所有的实体并对本体模块进行改进。检查公理是否在集成所有的模块之后仍然是正确的。

8. 构造OWL。

3 利用规则的知识图谱推理

第三位讲者是来自蒙特利尔大学的一名女教授，主要讲授利用逻辑规则的推理。

对于图中的知识图谱，我们可以得到一组事实，其中，有的是一元谓词有的是二元谓词。逻辑规则可以表达复杂的本体结构，并且可以用本体描述的逻辑规则来推理出可能发生的事实或者发现知识图谱存在的冲突。

当有一个知识图谱，并且事先定义了4个逻辑规则，用这几个逻辑规则就可以推理出一些新的事实。

当给定一个query时，不仅需要考虑已有的事实，还应该考虑利用规则推理出的新的事实。

接下来，主要讨论知识图谱的问答系统，给定一个知识图谱和一组用于问答的逻辑规则，我们想要的答案很可能不仅出现在已有的知识图谱中，也有可能是在推理出的事实中找到答案。通过规则，我们可以更精确的使用合取查询，这种使用方法让我们看到目前很多KBQA系统都只使用了知识图谱中已有的事实，但是这对很多实际的KBQA任务是低效的，因为确实存在很多问题的答案无法直接从知识图谱中取得，因此，针对query通过推理得到新的事实并得到答案对应实际的KBQA系统是更为有效的方式。