schema融合(schemabind)

知识图谱有什么用处？

“知识图谱的应用涉及到众多行业，尤其是知识密集型行业，目前关注度比较高的领域：医疗、金融、法律、电商、智能家电等。”基于信息、知识和智能形成的闭环，从信息中获取知识，基于知识开发智能应用，智能应用产生新的信息，从新的信息中再获取新的知识，不断迭代，就可以不断产生更加丰富的知识图谱，更加智能的应用。

如果说波士顿动力的翻跟头是在帮机器人锻炼筋骨，那么知识图谱的“绘制”则是在试图“创造”一个能运转的机器人大脑。

“目前，还不能做到让机器理解人的语言。”中国科学院软件所研究员、中国中文信息学会副理事长孙乐说。无论是能逗你一乐的Siri，还是会做诗的小冰，亦或是会“悬丝诊脉”的沃森，它们并不真正明白自己在做什么、为什么这么做。

让机器学会思考，要靠“谱”。这个“谱”被称为知识图谱，意在将人类世界中产生的知识，构建在机器世界中，进而形成能够支撑类脑推理的知识库。

为了在国内构建一个关于知识图谱的全新产学合作模式，知识图谱研讨会日前召开，来自高校院所的研究人员与产业团队共商打造全球化的知识图谱体系，建立世界领先的人工智能基础设施的开拓性工作。

技术原理：把文本转化成知识

“对于‘姚明是上海人’这样一个句子,存储在机器里只是一串字符。而这串字符在人脑中却是‘活’起来的。”孙乐举例说。比如说到“姚明”，人会想到他是前美职篮球员、“小巨人”、中锋等，而“上海”会让人想到东方明珠、繁华都市等含义。但对于机器来说，仅仅说“姚明是上海人”，它不能和人类一样明白其背后的含义。机器理解文本，首先就需要了解背景知识。

那如何将文本转化成知识呢？

“借助信息抽取技术，人们可以从文本中抽取知识，这也正是知识图谱构建的核心技术。”孙乐说，目前比较流行的是使用“三元组”的存储方式。三元组由两个点、一条边构成，点代表实体或者概念，边代表实体与概念之间的各种语义关系。一个点可以延伸出多个边，构成很多关系。例如姚明这个点，可以和上海构成出生地的关系，可以和美职篮构成效力关系，还可以和2.26米构成身高关系。

“如果这些关系足够完善，机器就具备了理解语言的基础。”孙乐说。那么如何让机器拥有这样的“理解力”呢？

“上世纪六十年代，人工智能先驱麻省理工学院的马文·明斯基在一个问答系统项目SIR中，使用了实体间语义关系来表示问句和答案的语义，剑桥语言研究部门的玛格丽特·玛斯特曼在1961年使用Semantic Network来建模世界知识，这些都可被看作是知识图谱的前身。”孙乐说。

随后的Wordnet、中国的知网（Hownet）也进行了人工构建知识库的工作。

“这里包括主观知识，比如社交网站上人们对某个产品的态度是喜欢还是不喜欢；场景知识，比如在某个特定场景中应该怎么做；语言知识，例如各种语言语法；常识知识，例如水、猫、狗，教人认的时候可以直接指着教，却很难让计算机明白。”孙乐解释，从这些初步的分类中就能感受到知识的海量，更别说那些高层次的科学知识了。

构建方式：从手工劳动到自动抽取

“2010年之后，维基百科开始尝试‘众包’的方式，每个人都能够贡献知识。”孙乐说，这让知识图谱的积累速度大大增加，后续百度百科、互动百科等也采取了类似的知识搜集方式，发动公众使得“积沙”这个环节的时间大大缩短、效率大大增加，无数的知识从四面八方赶来，迅速集聚，只待“成塔”。

面对如此大量的数据，或者说“文本”，知识图谱的构建工作自然不能再手工劳动，“让机器自动抽取结构化的知识，自动生成‘三元组’。”孙乐说，学术界和产业界开发出了不同的构架、体系，能够自动或半自动地从文本中生成机器可识别的知识。

孙乐的演示课件中，有一张生动的图画，一大摞文件纸吃进去，电脑马上转化为“知识”，但事实远没有那么简单。自动抽取结构化数据在不同行业还没有统一的方案。在“百度知识图谱”的介绍中这样写道：对提交至知识图谱的数据转换为遵循Schema的实体对象，并进行统一的数据清洗、对齐、融合、关联等知识计算，完成图谱的构建。“但是大家发现，基于维基百科，结构化半结构化数据挖掘出来的知识图谱还是不够，因此目前所有的工作都集中在研究如何从海量文本中抽取知识。”孙乐说，例如谷歌的Knowledge Vault，以及美国国家标准与技术研究院主办的TAC-KBP评测，也都在推进从文本中抽取知识的技术。

在权威的“知识库自动构建国际评测”中，从文本中抽取知识被分解为实体发现、关系抽取、事件抽取、情感抽取等4部分。在美国NIST组织的TAC-KBP中文评测中，中科院软件所—搜狗联合团队获得综合性能指标第3名，事件抽取单项指标第1名的好成绩。

“我国在这一领域可以和国际水平比肩。”孙乐介绍，中科院软件所提出了基于Co-Bootstrapping的实体获取算法，基于多源知识监督的关系抽取算法等，大幅度降低了文本知识抽取工具构建模型的成本，并提升了性能。

终极目标：将人类知识全部结构化

《圣经·旧约》记载，人类联合起来兴建希望能通往天堂的高塔——“巴别塔”，而今，创造AI的人类正在建造这样一座“巴别塔”，帮助人工智能企及人类智能。

自动的做法让知识量开始形成规模，达到了能够支持实际应用的量级。“但是这种转化，还远远未达到人类的知识水平。”孙乐说，何况人类的知识一直在增加、更新，一直在动态变化，理解也应该与时俱进地体现在机器“脑”中。

“因此知识图谱不会是一个静止的状态，而是要形成一个循环，这也是美国卡耐基梅隆大学等地方提出来的Never Ending Learning（学无止境）的概念。”孙乐说。

资料显示，目前谷歌知识图谱中记载了超过35亿事实；Freebase中记载了4000多万实体，上万个属性关系，24亿多个事实；百度百科记录词条数1000万个，百度搜索中应用了联想搜索功能。

“在医学领域、人物关系等特定领域，也有专门的知识图谱。”孙乐介绍，Kinships描述人物之间的亲属关系，104个实体，26种关系，10800个事实；UMLS在医学领域描述了医学概念之间的联系，135个实体，49种关系，6800个事实。

“这是一幅充满美好前景的宏伟蓝图。”孙乐说，知识图谱的最终目标是将人类的知识全部形式化、结构化，并用于构建基于知识的自然语言理解系统。

尽管令业内满意的“真正理解语言的系统”还远未出现，目前的“巴别塔”还只是在基础层面，但相关的应用已经显示出广阔的前景。例如，在百度百科输入“冷冻电镜”，右竖条的关联将出现“施一公”，输入“撒币”，将直接在搜索项中出现“王思聪”等相关项。其中蕴含着机器对人类意图的理解。

schema integration什么意思

schema integration

模式集成

integration[英][??nt??gre??n][美][??nt??ɡre??n]

n.结合; 整合; 一体化; （不同肤色、种族、宗教信仰等的人的）混合;

易混淆单词：Integration

例句:

1.

This is inevitable as development is increasing communication and integration.

发展对交流和融合的促进作用使之成为必然。

知识图谱：方法、实践与应用笔记-第5章 知识图谱融合

知识图谱包含描述抽象知识的本体层和描述具体事实的实例层。本体层用于描述特定领域中的抽象概念、属性、公理；实例层用于描述具体实体对象、实体间关系，包含大量的事实和数据。

知识融合是解决知识图谱异构问题的有效途径。知识融合建立异构本体或异构实例之间的联系，从而使异构的知识图谱能相互沟通，实现它们之间的互操作。

（1）语法不匹配

方法：尽量将不同的语言转化为同样的语法格式

（2）逻辑表示不匹配

方法：例如，通过定义从语言L1逻辑表示到语言L2的逻辑表示的转换规则

（3）原语的语义不匹配

注意：采用不同语言的本体交互时，需要注意它们的原语表达意义的差异

（4）语言表达能力不匹配

方法：需要将表达能力弱的语言向表达能力强的语言转换；但是如果表达能力强的语言并不完全兼容表达能力弱的语言，这样的转换可能会造成信息的损失。

（1）概念化不匹配

由于对同样的建模领域进行抽象的方式不同造成的。每个人对schema的理解不同，抽象出来的Schema不同。

a. 概念范围的不匹配

概念差异以及人的主观差异。

b. 模型覆盖的不匹配

模型的广度（领域范围）、模型的粒度（详细程度）、本体建模的观点（从什么角度来描述领域内的知识）

（2）解释不匹配

对概念化说明方式不同造成的。

a. 模型风格的不匹配

i. 范例不匹配。相同的概念会有不同的表示；使用不同的上层本体

ii. 概念描述不匹配。？？本体的构建不同

b. 建模术语上的不匹配

i. 同义术语（自然语言）。carautomobile

ii. 同形异义术语。conductor(指挥家；半导体)

iii. 编码格式。eg:日期(dd/mm/yyyy;mm-dd-yy)

语言层的不匹配可以进行语言之间的转换；模型层的不匹配，可以根据匹配类型的不同选择正确的算法。

（1）基于单本体的集成

不同本体集成一个大本体，但是这种方法对于其中的每个本体来说时过于庞大的，且推理和查询的时候效率低。

（2）基于全局本体-局部本体的集成

抽取共同知识构建全局本体，同时各个系统可以拥有自己的本体，称为局部本体（是剔除了共有知识吗？？不是）。需要建立局部本体和全局本体之间的映射。局部本体侧重于特定的知识，全局本体保证不同系统间异构的部分能进行交互。

（1）映射的对象角度

明确映射应该建立在异构本体的哪些成分之间。

从映射对象来看，可将本体映射分为概念之间的映射和关系之间的映射，其中概念之间的映射是最基本的映射。

（2）映射的功能角度

明确建立具有何种功能的本体映射。11种

（3）映射的复杂角度

明确什么形式的映射是简单的，什么是复杂的。

如何发现异构本体间的映射？

本体映射过程：

（1）导入待映射的本体

（2）发现映射。

（3）表示映射。

发现映射方法：

(1)? 基于术语和结构的本体映射

(2) 基于实例的本体映射

(3) 综合方法

知识图谱基础（三）-schema的构建

在前面一篇文章《知识图谱基础（二）-知识表达系统》中介绍了知识图谱的基础知识表达系统，什么是entity，什么是relation，什么是domain，什么是type等等。本篇文章主要从应用角度来聊一聊如何构建schema以及shcema构建中需要考虑的问题。以下所讲的schema构建主要是基于common sense进行构建的，弱关系图谱构建会在应用中讲到。

简单来说，一个知识图谱的schema就是相当于一个领域内的数据模型，包含了这个领域里面有意义的概念类型以及这些类型的属性。任何一个域的schema主要由类型（type）和属性（property）来表达。图1是plantdata内的创投schema，主要是为了发掘一级市场的投资和融资构建的schema。该schema主要是去定义需求，哪些数据对创投有用，才往上构建，例如：人物都有身高 体重，但是这些数据对创投来说意义不大，在schema中就不用构建了。关注创投的人会关注这些基金与人物投资了哪些公司，投资的公司所属行业，投资的公司属于哪一类企业，在该schema中就需要详细构建。

1.如何构建域（domain）

域（domain）的概念是凌驾于所有类型之上，对于域的定义应该尽量的抽象，不应该具体，同时域与域之间应尽量做到相互独立，不交叉。例如，省份就不应该是一个域的概念，在思考是否应该把一个概念当做域时，需要考虑到该概念是否能够继续向上抽象，例如：省份；城市；国家；县等等，他们同属于地理位置域。在明确域的概念时，应该定义好域的边界，这样比较容易区分不同域之间的区域划分。

2.如何确定一个域的类型（type）

这里需要产品经理去思考，构建这个schema的核心需求是什么，到底需要解决用户什么问题。为了满足这些核心需求，我们需要创造出哪些概念？

举个例子，在汽车领域，用户主要关心什么问题，例如：汽车的品牌、车系、发动机。

在NBA领域，用户主要关心球队、所属联盟、教练、球员等等。

针对不同的需求，需要在域下面构建不同的类型来满足用户的需求。

3.如何确定属性（property）

思考的角度如下：

1.以用户需求为出发点

2.以数据统计为证据

比如在构建完足球领域中的球队类型后，该类型集合了所有的球队实体，站在用户角度触发，用户会关注球队的哪些关系？

图2是我简单的针对足球领域构建的一个图谱，上面包含了梅西（球队的球员）， 埃内斯托·巴尔韦德 （球队的教练），西甲（球队的所属联赛），其中梅西、西甲、埃内斯托.巴尔韦德又分属于不同的类型：足球球员，足球联赛，足球教练，这些所有的类型构成了足球域。

从上图的common sense配合图查询和自然语言处理技术已经可以支持基础的问答了，例如，梅西是哪个球队的？埃内斯托巴尔韦德是哪些球员的教练？西甲有哪些球队在踢球？等等

schema的应用是产品经理需要重点考虑的内容，因为产品需求决定了schema应该怎么构建，构建的是否完备。而产品的具体应用则主导了schema的整体构建方式，如果不仔细考虑产品应用的话，最惨的情况可能构建了很久的schema会因为一个逻辑坑而彻底报废掉，由于知识图谱又是一个牵一发而动全身的工程，根据实际经验来说，如果图谱构建和应用有部分脱节，可能修改图谱schema比重新构建图谱schema的成本还要高。所以，首先确认好具体的应用场景对于一个schema构建的成功与否是至关重要的。

笔者写一套曾经用过的确认schema的流程

先将应用根据需求的强弱划分，分为基础核心需求，schema特色需求，锦上添花需求，未来扩展性需求。

基础核心需求：是经过需求分析后，构建这个schema需要完成最核心的需求，该需求优先级最高

schema特色需求：构建图谱时可能会经常遇到图谱可以实现而其他方法实现比较困难的特色需求，这类需求可能需求强度不是很高，但是由于能够实现一定的差异性，经常会有意想不到的效果。

锦上添花需求：非基础核心需求，做了更好，不做也可以接受

未来扩展性的需求：确认schema的时候要充分考虑到未来的扩展性，因为这类需求有可能会大改图谱的schema结构

在构建schema的时候，根据上述分类，需要去考虑该schema一期需要满足哪些具体的功能，将功能一一列下来，哪些功能是需要放在第二期、第三期完成的，未来的扩展性需求需要在构建的哪一块区域留下可扩展的内容。

常用的方法可以使用excel去列出一、二、三期所需要的功能点。

列出上述的功能点后，针对每一个功能点在后面备注好该功能的构建要点（注：这个非常重要），通常需求只需要将产品需求转化成一定的查询结构即可，笔者原来用的是cypher查询语法。以图2为例，我要支持某个教练教了哪些球员？转化成查询语言就是（a:足球教练）-{b:教练}-（c:球队）-{d:球员}-（e:足球球员） return e。将a变成参数，输入a即可返回所有的e，即输入埃内斯托巴尔韦德，返回就是梅西。

流程如下：query:埃内斯托巴尔韦德带了哪些球员？→语义解析→转化成上述查询，将埃内斯托巴尔韦德作为参数a代入查询→返回结果→前端包装展示

注：上面在每个功能点后面备注了构建要点，当大部分功能点的构建要点都写完的时候，需要集中查看构建要点，因为如果需求本身比较大的话，不同的需求很容易造成schema的构建冲突，正如前面所讲，schema尽量要保证少出错。这个时候由于备注了构建要点，可以全局的来审视这个schema中间有没有逻辑黑洞。常出现的问题主要是在属性的设计，以及知识融合上。

拿着上述文件去找开发，确认一下哪些是比较好实现的，一般来说做到这种程度大多数需求开发都是会接的。如果开发同学足够专业的话，他会从他的视角去给你提出他的宝贵意见。通常产品经理在思考schema这一块更倾向于思考这个schema的作用，而开发同学会思考工程实现、实现效率、运行效率、计算量等问题。

大规模构建schema的时候需要认真考虑数据源的情况，由于不同公司掌握的数据不同，所应用的对策也不同。

通常笔者会将数据源分为如下几种：

1.已经清洗好的结构化数据：这部分数据一般是公司的核心数据，或者其他公司的核心数据，构建的时候应该优先考虑这类数据。这部分数据通常只需要改变数据格式即可入图谱。

2.清洗好的结构化数据，但数据残缺：这部分数据通常需要数据挖掘，知识融合。清洗难度是由残缺比例决定的。

3.无数据：没有这部分数据，但是又需要这部分数据，通常只能去选择让BD去购买数据，或者让爬虫组去专业网站爬取，例如：企业数据可以去企查查，电影的数据可以去猫眼，产业的数据可以去产业信息网等等。

假设需要构建的图谱entity数量在千万级别，开发力量不够强大的时候，慎用纯数据挖掘方案，有条件的话笔者建议直接去买结构化数据，因为可能挖掘和知识融合在经济上的成本比直接买数据要高，而且时间周期也会很长。

个人认为，大规模构建schema最难的地方就在于挖掘数据的知识融合上，举个例子：全国有10000个叫王刚的人，爬虫从A网站挖下来5000个“王刚”，从B网站挖下来7000个“王刚”，那么这5000个王刚和那7000个王刚到底是不是一个人？在没有身份证号码的情况下如何确定哪些王刚是一个人呢？常规的做法是去挖掘出“王刚”的其他信息，例如出生年月，任职信息，籍贯等等，然后通过一定的算法进行知识融合。通常，网站的数据不一定全面，即使经过知识融合后，挖掘的数据中一定会有大量的噪音，不同的需求对噪音的承受能力是不同的，构建schema的时候需要充分考虑数据出现噪音的可能性，去评价这部分需求对噪音的承受能力。

如果知识融合完成了话，大规模构建其实就是一个导数据的过程，由于图谱数据结构的关系，一般存2张表（点、边）或者使用RDFs存储，在entity数量上千万以后，图谱的查询压力会比较大，单机查询可能会直接跪掉，开发一般会采用graphX的分布式的存储，不过由于点和边的切割方式的问题，会有一定的副作用。