动态本体 - sunyongdi/nlp-code-examples GitHub Wiki
动态本体构建
以数据为驱动的动态本体构造方法,其中包括基础知识构造和知识传播两个阶段
- 第一阶段:在第一阶段,采用自顶向下结合领域知识的法律领域本体构造方法,数据模式从最顶层概念构造,加入时空特征,逐步向下细化,形成结构良好的分类学层次
- 在第二阶段,为应对法律知识的变化性,通过定义传播特征,把知识源的变化传播给动态本体体系
动态本体
- 数据源的动态性
- 通过定制不同的schema适应各种的不同来源的数据格式,例如不同数据库中的数据结构各不相同,可以通过针对不同的数据结构定制不同的schema,最为知识的数据源
- 本体层动态性
- 为了节省服务器开销,新的schema在基于旧的结构基础上形成增量schema,通过触发增量脚本形成增量本体。与原始数据结构不同的数据保存在增量本体中保存到知识库中。增量本体更新原始本体层形成新的本体层
- 实例层动态性
- 新的数据源的数据包含两个部分:其中一部分可能是可原始数据结构相同的可以直接通过原始本体更新到本体库,另一部份数据通过增量本体更新到知识库
数据存储
1. 本体schema
1.1 图谱管理表
graphManage | 记录图谱的信息 | 注释 |
---|---|---|
gid | 主键id | |
graphName | 图谱名称 | |
remark | 图谱简介 | |
concept_count | 概念的数量 | |
concept_re_count | 概念关系的数量 | |
entity_count | 实体数量 | |
entity_re_count | 实体关系数量 | |
isdelete | 逻辑删除 |
1.2 概念管理表
conceptManage表 | 概念表管理 | ||
---|---|---|---|
cid | 主键id | ||
conceptName | 概念名 | ||
remark | 简介 | ||
entity_table_name | 表名 | entity + "_" + cid | |
isdelete | 逻辑删除 |
1.3 schema管理表
schemaManage表 | 图谱结构schema | ||
---|---|---|---|
sid | 主键id | ||
gid | 图谱id | ||
relationName | 关系名称 | ||
remark | 关系简介 | ||
source | 头概念id | ||
target | 尾概念id | ||
triplet_table_name | 表名 | triplet + "_" + sid | |
isdelete | 逻辑删除 |
1.4 实体表
entity_1表 | 信访人 | ||
---|---|---|---|
e_id | 主键id | ||
name | 名称 | 必填;es索引 | |
neo_id | 图数据库id | ||
parent | 记录上下位 | ||
isdelete | 逻辑删除 |
1.5 三元组表
triplet_1表 | 三元组 | ||
---|---|---|---|
t_id | 主键id | ||
from | 头节点id | ||
sid | 关系id | ||
to | 尾节点id | ||
neo_id | 图数据库id | ||
isdelete | 逻辑删除 |
缺点
- 将单个概念实例成一张数据表,其中的属性作为表的字段,导致定本体层只可以添加和删除概念无法修改概念(修改表结构)
- 属性作为数据表的字段导致创建属性的时候就需要添加英文字段作为属性字段,要想添加中文属性需要在描述中添加(两次操作比较繁琐)
- 单个实体无法添加多个概念(人,当事人、执法人 概念的实例都可能是同一个人(但是在我们知识库中是三张表中的实例))
优点
- 采用mysql 保存schema 可以避免图数据库不稳定的缺点,传统的图数据不稳定,容易崩溃,数据丢失。使用关系数据库可以避免这个问题。
- 可以采用mysql 作为数据的管理,和知识库的构建的中间价。最后通过D2R的方式快速生成三元组供查询使用。图数据库采用Neo4j
D2R
每个概念为一张表