rdf - 多模型 RDF 存储与图数据库

Question

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

我知道将 OWL/RDFS 用于语义数据有很多优势，因为它们很紧凑，而且它们只是边缘的集合。我打算尝试一个三元存储（如 Jena），但对我无法在其上执行的某些图形算法（如最短路径和加权边）持谨慎态度。

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

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

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

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

标签： rdfgraph-databasesowlmulti-model-databaseknowledge-graph

Answer 1

以下是基于以下内容的数据库管理系统列表比较的链接：

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

由于使用此特定平台的表的降价支持，我无法将表内联放置在这里。