Neo4j与知识图谱 —— Part 3
笔记列表
- Neo4j与知识图谱 —— Part 1 ：废话、安装与设计思路
- Neo4j与知识图谱 —— Part 2 ：Cypher基础
- Neo4j与知识图谱 —— Part 3 ：建立数据基础
- Neo4j与知识图谱 —— Part 4 ：初步应用模式
(1) 基础与框架
框架我在最开始其实已经说明了一部分，就是知识图谱结构框架。这个框架的好处，我自己感觉有三个：
- 便于扩展：无论音视频数据的范围如何扩展，都可以转换到这个框架内；
- 维护简单：对于新增加数据的维护，只要在原始范畴内，就可以直接进行数据加工与处理了；
- 符合习惯：比较符合大多数人对于音视频的理解和抽象。
另一方面，就是数据来源上的基础。我其实还是很鸡贼的，因为有太多公司和组织提供了非常优秀的开源知识图谱。同时，公司对于自己手里的音视频内容也是有对应的编目数据的，虽然这个音视频数据十分十分不靠谱，但好歹有一个基础。这里真的超级感谢 OwnThink 所提供的知识图谱（不过，我个人还是要吐槽一下这个开源的知识图谱，声称有14亿节点但很多都算不上是个节点）。
所有这些基础，就构成了我这次工作的基本。
最后，就是对于图数据与一般数据的讨论，这也是我近期工作时关于这个问题的一些思考。为什么需要图表达而非关系数据表达？这其实很好理解，因为关系表达是基于再抽象的，图表达是直观的。对于两者间关系，需要单独创建一个关系表进行存储，对应于图的形式。所以很多时候，似乎使用关系型数据库就足够表达这个意义了，不过，这是在没有抽象的时候，我们单纯的理解图的关系，似乎所有关系都可以加入到一个关系表中。从另一个角度看，关系的抽象或者节点的抽象，都可以这么处理，于是按照关系数据的方式，也仅需要2个表格进行处理，这在实际计算中就有点搞笑了。
从另一个角度想，关系可以当作一个映射，节点就是不同的集合，两个集合之间的关系，就是构建这两个集合之间的映射。例如恋爱关系，就是自身到自身的映射。所以，从函数抽象的角度讲，关系也是可以进行分类从而进一步抽象。于是，我这里设计关系的时候，就是这样做的，尽可能降低关系的数量，使用子集定义更细节的关系属性。同理，节点的定义就是对集合的抽象，之所以没有把人与公司这两类节点做合并，也是出于使用方便的角度，因为大多数时候，公司这个实体在音视频的垂直领域中所占分量具有很强的独立特性，例如持有某一版权等。所以单独取出公司类节点，可以降低一部分数据处理上的复杂程度。由此，图数据的含义就完全不同意关系数据库的定义与延展，我期待的也就是图数据库虽能体现的更好的抽象能力，而非单纯的记录功能。
最后的最后，数据的另一种组织模式是mangoDB代表的文件型存储组织。其实这也可以做成像图数据库一样的模式，只是不直观。那么，使用图数据库其实更多还是偏向于其所提供的便利，而非因为独特。
(2) 数据与数据清洗
剩下的核心内容就是整合外来数据和自有数据。这个有两个有趣的方式：
- 基于正则匹配对外来数据和内部数据进行整合，对外来数据直接删减；
- 分别整理两个知识图谱（内部、外部），对两个图谱之间相近或完全相同的元素建立关联，最后再核对新建关系的准确性。
我最终使用的方案，还是从简单的角度来做的选择，就是正则匹配的方案。
匹配节点本身的内容，同时，对匹配节点的其他关联内容进行比较后决定是否需要合并到内部数据形成的图谱上。这一过程可以穷举所有可能性，只是略显繁杂而已。在这过程中，考虑过使用神经网络的方式来减少匹配规则的定义，但是，在生成训练数据时，就几乎在穷举所有可能性，结果就略显多此一举了。
至此，整个神经网络，就算粗具形态。后面就要考虑怎么用了。