业务理解、图谱设计
知识抽取、知识表示、知识存储
知识众包、知识链接、知识融合
问答、推荐等等
业务理解:
有哪些可获取的业务数据?
如果需要获取数据以及人工标注,需要多大成本?
是否需要专家介入?
业务数据的特性是什么样的?
业务数据是否用一般数据库表示即可?
通过这些关系表示,能否给场景带来实际益处?
在熟悉业务的场景下,构建边界清晰、产出可用的知识图谱。
图谱设计:
现实场景中的哪些事物可以抽象为实体?
各类实体分别具有哪些属性?
实体间存在什么关系?关系有什么属性?
构建知识图谱的基础
限定了数据范围
约束了数据的操作范围
不同的图谱设计、不同的业务逻辑、不同的下游应用
几个基本设计规则
基于业务设计图谱
专家法:自上而下,总体规划;领域专家(技术+业务)
归纳法:单点切入,自下而上(针对一个单点的业务场景纵向打破,然后再基于这一套横向扩展):技术专家
混合法:一味用专家发,细节不足,一味用归纳法,高度不够,可以综合两者,比如大的方向上用专家法,小的场景下用归纳法。
参照法:标杆对照,设配调整;行业标准
几点经验:
业务+技术
不断迭代修整
小规模实践
可视化图谱全貌
验证对应用工程的支持
知识抽取
结构化数据、非结构化数据、半结构化数据
预处理、分词、词性标注、句法分析
命名实体识别、实体链接
关系抽取、事件抽取
基本的自然语言处理、机器学习、深度学习等
知识表示 SPO三元组,三元关系(subject ----Predicate ---Object)主谓宾
概念理解
资源(Resource):所有以RDF表示法来描述的东西都叫做资源,它可能是一个网站,可能是一个网页,可能只是网页中的某个部分,甚至是
不存在于网络的东西,如纸本文献、器物、人等,都以统一资源标识(URI, Uniform Resource Indentifiers)来命名。
属性(Properties):用来描述资源的特定特征或关系
陈述(Statements):一个RDF陈述,其中资源是主词(subject),属性是述词(Predicate),属性值则是受词(Object),这是一种描述的语法。
RDF图中一共有三种类型, International Resource Identifiers(IRIs), bland nodes 和Literals.下面是SPO每个部分的类型约束:
Subject可以是IRI或者blank node
Predicate是IRI
Object三种类型都可以
如何存储和传输RDF数据?
目前,RDF序列化的方式主要有:RDF/XML , N-Triples, Turtle, RDFa, JSON-LD等几种。
这种简单的表示方式存在什么缺陷?
有些知识和时空相关,也具有不确定性
例如: 奥巴马,就职,美国总统
番茄,有助于,补铁
RDF的表达能力有限,无法区分类和对象,也无法定义和描述类的关系/属性
知识存储:
关系数据库
三元组
图数据库
并非所有的实体都要放入到三元组或者图数据库中!!!
没有太多关系延伸计算、属性多、结构固定,放到一般关系数据库中即可。
可以把一些信息比如“年龄”、“家乡”放到传统的关系型数据库中,因为:
这些数据对于分析关系来说没有太大作用
访问频率低,放在知识图谱上反而影响效率
知识链接:
构建好的知识图谱,从文本中引入更多知识的时候。
Mention variations:同一个实体有不同的mention,
如何将不同称呼的关于“唐僧”的文本知识扩充至KG?
唐僧、唐三藏、金蝉子、玄奘、江流儿、长老、唐玄奘、旃(zhan)檀功德佛
Entity Ambiguity: 同一个mention对应不同的实体
如何避免将机器学习的乔丹与飞人乔丹混淆?
知识融合:
对于已构建好的知识图谱,如何如何知识?
豆瓣和百度百科中同一个人的介绍内容如何融合
扩展知识:知识图谱|知识存储
https://zhuanlan.zhihu.com/p/63378196
本章内容介绍知识图谱在存储数据过程中的知识存储。
一般情况,对知识存储没有统一的标准,目前业内存储知识的方式有三种,第一种为三元组形式的RDF存储;第二种为传统关系型数据库存储;第三种为图数据库存储;而目前比较常用的为图数据存储或者关系型数据库+图数据库存储的方式。
RDF即资源描述框架,本质上是一个数据模型;它提供了一个统一的标准,用于描述资源/实体,形式上是以(实体,关系,实体)三元组的形式进行数据的存储。
RDF存储的优点是:
同样RDF的缺点也很明显:
传统的关系型数据库存储图数据可以很好的解决单条数据查询的问题,因为传统的数据库在存储效率和查询效率上都有很大的优势,且关系型数据库是目前最成熟也应用最广的数据库。
关系型数据库的缺点: