問題タブ [property-graph]

私は最近、GraphScale を使用して neo4j の LPG ストアで OWL のような推論を取得する方法を説明する記事を読みました。しかし、そもそもLPGグラフでOWLのようなルールを定義する方法については非常に不明確です。説明してもらえますか？
私は基本的に、ML モデルで最終的に使用するナレッジ グラフを作成しようとしています。現在、LPG ストアとトリプル ストアを評価していますが、どの種類のデータ モデリングとデータ ストアを使用すればよいかわかりません。洗練された OWL ルールを使用しないと、何を失うでしょうか?

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 コミュニティを止めているのは何ですか?

会社で使用されるすべての単語の略語を含むデータベースを作成したいと考えています。

(RDF のように) 同じプロパティーに対してさまざまな数のプロパティーを定義できますか? 異なるデータ型を使用することは可能ですか?

たとえば、次のようにします。