多模型RDF存储与图数据库

Question

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

我知道使用OWL / RDFS处理语义数据有很多优势，因为它们很紧凑并且只是边缘的集合。我本来要尝试使用Triplestore（例如Jena），但对某些我无法在其上执行的图形算法（例如最短路径和加权边缘）保持警惕。

自从我开始构建Google知识库之类的东西以来，我就遇到过混合或多模型数据存储区（RDF存储区+ Graph DB），例如Blazegraph，Amazon Neptune，Google Cayley（不是真正的Google）产品），Virtuoso，Grakn等。

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

  

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

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

Answer 1

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

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

由于无法使用此特定平台对表格进行降价支持，因此无法在此处内嵌表格。