多模型RDF存储与Graph数据库

Question

我已经阅读了关于SO的问题：Graph DBs vs. Document DBs vs. Triplestores。

我知道使用OWL / RDFS语义数据有很多优点，因为它们很紧凑，而且只是边缘的集合。我要尝试一个三重存储（像Jena），但对某些我无法在其上执行的图形算法（如最短路径和称重边缘）保持警惕。

自从我开始构建类似谷歌知识库的东西以来，我遇到了混合或多模型数据存储（RDF商店+图形数据库），如Blazegraph，亚马逊海王星，谷歌凯利（不是实际的谷歌产品）， Virtuoso，Grakn等。

这让我想知道为什么我不能将所有的RDF数据导出到一个简单的图形数据库中？像Neo4j或OrientDB一样？毕竟，RDF数据仍然是图形。为什么Knowledge Graphs的创建者坚持使用混合存储？为什么不使用普通的旧图形数据库呢？如果您认为答案是优化，那么为什么不使用超图数据库呢？混合数据库上的哪些操作在图表数据库中不可用？让我从blog逐字引用：

组织和管理复杂，高度互联的数据作为所谓的知识图的新兴范例构成了知识和数据表示挑战的独特组合。基于知识图的应用程序需要在语义丰富但结构良好且受约束的图形数据上高效运行。虽然关系建模技术和图形数据库是解决某些特定问题的有用工具，但它们无法为整个任务提供全面的技术和概念基础架构。

事实上，Sail实际上在图形数据库（如OrientDB）之上提供了一个RDF层。这不会进一步降低混合数据库的吸引力吗？当RDF数据本身就是一个图形时，我不明白在图形数据库上构建RDF实现的意义吗？

Answer 1

以下是基于以下内容的tabulated comparison of Database Management Systems链接：

1. 身份标识
2. 实体关系类型（关系）建模
3. 实体关系类型（关系）结构（N元组，3元组等）
4. 实体关系类型（关系）表示结构的符号
5. 数据定义和操作语言支持
6. 推理和推理语言
7. 相关的开放标准

由于使用此特定平台对表格的降价支持，我无法将表格放在此处。