【发布时间】：2019-02-10 20:38:10
【问题描述】：
我已阅读关于 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 数据仍然是一个图。 为什么知识图谱的创建者坚持使用混合存储？为什么不只使用普通的旧图数据库？ 如果您认为答案是优化，那么为什么不只使用超图数据库呢？ 混合数据库上的哪些操作在图形数据库上不可用？让我逐字引用blog：
将复杂、高度互连的数据组织和管理为所谓的知识图谱的新兴范式提出了知识和数据表示挑战的特殊组合。基于知识图的应用程序需要在语义丰富但结构良好且受约束的图数据上高效运行。 虽然关系建模技术和图形数据库是解决某些特定问题的有用工具，但它们无法为整个任务提供全面的技术和概念基础架构。
事实上，Sail 实际上在图形数据库（如 OrientDB）之上提供了一个 RDF 层。这不会进一步降低混合数据库的吸引力吗？当 RDF 数据本身就是一个图形时，我不明白在图形数据库上构建 RDF 实现的意义吗？
【问题讨论】：
-
“为什么我不能将所有的 RDF 数据导出到一个简单的图形数据库中？” - 嗯，你可以。谁说不可能？但是请告诉我，哪个原生图形数据库支持 SPARQL，即 RDF 数据事实上的查询语言？哪个图形数据库可能支持一些基于规则的推理？很明显，SPARQL 是有限的 w.r.t。图形操作，如遍历等。它不是为它设计的。
标签： rdf graph-databases owl multi-model-database knowledge-graph