Sparql ベースのストア、言い換えれば TripleStore は、プロパティ グラフとしてのパフォーマンスを維持しながら分散できないことに加えて、プロパティ グラフ ストアよりも効率が悪いことが知られています。
ここには、推論など、さまざまな問題があることを理解しています。SPARQL を介して完全にキャプチャできる RDFS に限定できる配布と推論はさておき、それはなぜでしょうか?
より具体的には、ストレージが問題になる理由です。プロパティ グラフ ストアのように Sparql ベースのストアがデータを格納するように制限し、大規模な結合クエリの代わりにトラバーサルを実行しているのは何ですか。たとえば、sparql を単純に Gremlin ステップに変換することはできませんか? そこにある制限は何ですか？結合を避けることはできませんか?
私の仮定は、sparql が効率的なステップ トラバーサルで変換でき、データがプロパティ グラフのように格納されている場合、たとえば janusGraph がhttps://docs.janusgraph.org/latest/data-model.htmlを実行している場合、 RDFS などの推論を維持しながら、パフォーマンスを橋渡しします。
そうは言っても、Sparqlはもちろんチューリング完全ではありませんが、少なくともそれが行うことについては、高速で、おそらく大規模でも実行できます。私の見解では、目標は競合することではなく、SPARQL の使いやすさと、OLAP などの本当に必要なものに gremlin のようなトラバーサル言語を使用することで利益を得ることです。
その方向のプロジェクトはありますか、Apache jena はこれを検討しましたか?
Graql of Grakn は、上で説明した理由でその道を使用しているように見えますが、TripleStore コミュニティを止めているのは何ですか?