基于Sparql的存储或换句话说，TripleStore效率不如属性图存储，这是因为它无法在保持性能作为属性图的同时进行分配。
我知道这里有很多问题，例如推理和其他。将分布和推论放在一边，以至于我们只能将RDFS限制为可以通过SPARQL完全捕获的RDFS，我想知道为什么会这样吗？
更具体地说，为什么是存储问题。是什么限制了基于Sparql的存储像属性图存储那样存储数据，并且执行遍历而不是大规模联接查询。例如，sparql不能简单地翻译成Gremlin步骤吗？那里有什么限制？无法避免加入吗？
我的假设是，如果sparql可以高效地遍历，并且数据像janusGraph那样https://docs.janusgraph.org/latest/data-model.html进行存储，并且像属性图那样存储，那么性能问题将在保持诸如作为RDFS。
话虽这么说，Sparql当然不是图灵完备的，但是至少就其功能而言，它会很快并且可能会大规模地完成。我的目标不是要竞争，而是要受益于SPARQL的易用性，并使用gremlin之类的遍历语言处理真正需要的东西，例如OLAP。
是否有朝着这个方向发展的项目，Apache jena是否考虑过其中任何一个？
我看到Grakl of Grakn似乎正在使用这条路，原因如上所述，因此，是什么阻止了TripleStore社区？
答案 0 :(得分：1)
@Michael，很高兴您能加入，因为您对此深信不疑：)。我目前正在学习中。应您的要求，以下是激发我的理解的论文之一：
arxiv.org/abs/1801.02911（使用以下属性查询SPARQL： Gremlin遍历）
我引用他们
“我们对Gremlinator和 通过执行SPARQL查询来证明其有效性和适用性 在领先的图形商店顶部存储Neo4J，Sparksee和Apache TinkerGraph并将其性能与RDF商店Virtuoso进行比较， 4Store和JenaTDB。我们的评估表明 SPARQL的Gremlin同行获得的性能提升 查询，尤其是星形和复杂查询。”
但是他们解释说，事情在某种程度上取决于查询的类型。
或者作为另一个答案，它在堆栈溢出Comparison of Relational Databases and Graph Databases中也将有助于理解Set和path之间的问题。我的理解是TripleStore也可以与Set一起使用。话虽这么说，但我绝对不了解最近在TripleStore中实施的所有优化技术，并且我看到了几篇论文解释了如何大幅修剪集连接操作。
在发行上更是一种胆量。例如，对我来说，以分布式方式进行联接操作听起来非常但非常昂贵。我没有论文，而且我的研究还不够详尽。但是从我拥有的红色开始，我将不得不在Evernote中进行挖掘:)来支持它，这就是发行的根本问题。此处的自动智能分片似乎无法帮助缓解该问题。
@Michael这是一个非常但非常复杂的主题。我绝对在旅途中，这就是为什么我要帮助自己进行stackoverflow指导我的研究的原因。您可能对原因有所了解。因此，可以随意提供指针。
话虽如此，我并不是说RDF存在问题，并且Property-Graph更好。我说的是以某种方式，当涉及到图遍历时，有一些实现后端的方法可以使此过程更快。这里的数据模型不是问题，用于支持遍历的数据结构是问题。我要说的第二件事是，查询语言的选择似乎会影响“遍历”的执行方式，从而影响用于支持数据模型的数据结构。
到目前为止，这是我的理解，是的，我确实理解，还有很多其他因素在起作用，请随时列举其中一些因素来指导我的旅程。
简而言之，我的问题归结为，是否有可能让RDF存储由所谓的本机图存储支持，然后根据遍历步骤实现Sparql，而不是按照其代数进行连接设置？那样会使事情变得更快。似乎这是https://github.com/graknlabs/grakn所采用的方法，该方法主要由janusGraph支持用于存储之类的图形。尽管不是RDF，但Graql与具有RDFS ++ + Sparql的想法相同。他们声称做得更好，对此我有保留，但这不是该主题的根本问题。最重要的是，它们通过信息检索（路径遍历）和Property-Graph支持的附带存储方法来支持知识表示。让我清楚一点，我并不是说图本机存储是属性图的属性。在我看来，这是一种优化的存储方法，用于存储图结构，其中信息检索涉及（路径）遍历：https://docs.janusgraph.org/latest/data-model.html。
答案 1 :(得分：0)
首先，我很乐意看到那些引用支持您的主张，即基于RDF的系统本质上不如属性图系统高效，因为坦率地说，这是一个荒谬的主张。此外，已经分发了，我假设您的意思是横向扩展RDF存储，因此声称它们无法分发是完全错误的。
可以在基于RDF的系统之上轻松实现属性图模型和Gremlin。据我所知，这一次完成了两次，在其中一种实现中，Gremlin / Property Graph层支持推理。因此，您无需成为基于属性图的系统即可支持该模型。系统，RDF和属性图做出从存储到执行及以后的特定实现选择的原因很多，这些选择受“本机”模型（用于实现的技术）的指导，也许最重要的是，该系统的用例及其要解决的问题。
此外，尚不清楚您对基于RDF的系统的作者的建议的实际建议。您是否建议横向扩展是有益的？您是否在说要优先考虑Propety Graph模型，以便基于RDF的系统放弃并切换数据模型？您是否要对Property Graph系统进行RDFS改造？
最后，对于您提出的第一个问题，我认为您完全倒退了。属性图模型是混合图模型，将图模型和键值模型的元素混合在一起，而RDF模型是纯图（即本机）图模型。 Gremlin will be adopting the RDF model，尽管在RDF世界中被称为语法化的语法糖，但对于其他所有人来说，边缘属性却是。因此，在您的属性图模型范例正在放弃所述模型的世界中，除了您应该做更多的背景研究之外，我不确定还有什么要告诉您的。