RDF リポジトリでは今何が起こっているのでしょうか?

セマンティック Web とリンクト データは宇宙空間のようなもので、そこには生命は存在しません。 多かれ少なかれ長期的にそこに行くこと…子供の頃、「宇宙飛行士になりたい」という言葉に何と答えたかは分かりません。 しかし、地球上にいる間、何が起こっているかを見ることができます。 アマチュア天文学者になること、あるいはプロになることさえはるかに簡単です。

この記事では、数か月以内の RDF ストレージの世界の最新のトレンドに焦点を当てます。 最初の段落の比喩は、カットの下にある壮大なプロモーション画像からインスピレーションを得ています。

壮大な絵

I. RDF アクセスのための GraphQL

彼らは言うGraphQL はユニバーサル データベース アクセス言語であると主張しています。 そして、GraphQL を使用して RDF にアクセスする機能はどうなるのでしょうか?

すぐに使えるこの機会は、以下によって提供されます。

• スタードッグ(ブログ, ドキュメント);
• トップクアドラント製品 (ウェビナー, ドキュメント).

リポジトリがそのような機会を提供しない場合は、適切な「リゾルバー」（リゾルバー）を作成することによって独立して実装されます。 これは、たとえばフランスのプロジェクトで行われました。 データツーリズム。 あるいは、すでに何も書かずにただ受け取ることもできます ハイパーグラフQL.

セマンティック Web とリンクト データの正統派信奉者の観点からすると、これはすべて悲しいことです。なぜなら、これは次のデータ サイロを中心に構築された統合を目的としているように見え、適切なプラットフォーム (もちろん RDF ストレージ) ではないからです。 。

GraphQL と SPARQL を比較した感想は XNUMX つあります。

• 一方で、GraphQL は SPARQL の遠い親戚のように見えます。つまり、REST によくある再選択と複数のクエリの問題を解決します。これがなければ、おそらく、SPARQL を考慮することは不可能でしょう。 クエリ言語少なくともウェブに関しては。
• 一方で、GraphQL の厳格なスキームは混乱を招きます。 したがって、その「内省性」は、RDF の完全な再帰性に比べて非常に限定されているように見えます。 また、プロパティ パスに相当するものはないため、なぜ「Graph-」なのかさえ明確ではありません。

II. MongoDB 用アダプター

前のトレンドを補完するトレンド。

• 今はスタードッグで 多分 - 特に、すべて同じ GraphQL 上で - MongoDB データの仮想 RDF グラフへの表示を構成します。
• 最近Ontotext GraphDB 許可する MongoDB Query の SPARQL フラグメントに挿入します。

より広く言えば、これらのソースに保存されている JSON を RDF として表現することを多かれ少なかれ「オンザフライ」で可能にする JSON ソースへのアダプターについて言えば、かなり長い間既存のものを思い出すこともできます。 SPARQL生成調整できるもの 例えば、Apache Jena に。

最初の XNUMX つの傾向を要約すると、RDF リポジトリは、「複数のストレージ」(多言語永続性) の条件での統合と機能に対する完全な準備が整っていることを示していると言えます。 しかし、この後者は長い間時代遅れであり、それに取って代わられることが知られています。 やってくる マルチモデリング。 RDF ストレージの世界におけるマルチモデリングについてはどうでしょうか?

要するに、無理です。 マルチモデル DBMS のトピックについては別の記事にまとめたいと思いますが、今のところ、グラフ モデル (RDF はそのバリエーションと考えることができます) に「基づいた」マルチモデル DBMS は存在しないことがわかります。 いくつかの小規模なマルチモデリング - 代替 LPG グラフ モデルの RDF ストレージによるサポート - については、で説明します。 セクション V.

Ⅲ． OLTP vs. OLAP

しかし、同じガートナーでも、 пишетマルチモデリングは主に次の要件であるということ 手術室 DBMS。 これは当然のことです。「複数のストレージ」の状況では、主な問題はトランザクション性に関連して発生します。

しかし、OLTP-OLAP スケールのどこに RDF リポジトリがあるのでしょうか? 私ならこう答えるでしょう：あそこにもここにもありません。 それらの目的を示すには、XNUMX 番目の略語が必要です。 オプションとして私が提案したいのは オリップ — オンライン知的処理。

ただし、それでも:

• GraphDB と MongoDB に実装された統合メカニズムは、少なくとも重要なものではありません。 意図されました 書き込みパフォーマンスの問題を回避するため。
• スタードッグはさらに進化し、完全に進化します 書き換えます これも書き込みパフォーマンスの向上を目的としたエンジンです。

それでは、市場に新しいプレーヤーを紹介しましょう。 IBM Netezza と Amazon Redshift の作成者から - アンゾグラフ™。 それを元にした製品の広告の写真が記事の冒頭に掲載されました。 AnzoGraph は自らを GOLAP ソリューションとして位置づけています。 ウィンドウ関数を使用した SPARQL はいかがですか? —

SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE {  …  }

IV. ロックスDB

すでに上にあります リンクがありました Stardog 7 Beta の発表では、Stardog は基盤となるストレージ システムとして RocksDB (キーバリュー ストレージ、Google の LevelDB を Facebook がフォークしたもの) として使用する予定であると発表されました。 特定のトレンドについて話す価値があるのはなぜでしょうか?

まず判断するに、 ウィキペディアの記事, RocksDB に「移植」されるのは RDF リポジトリだけではありません。 ArangoDB、MongoDB、MySQL、MariaDB、Cassandra のストレージ エンジンとして RocksDB を使用するプロジェクトがあります。

次に、該当する主題のプロジェクト (つまり製品ではありません) が RocksDB 上で作成されます。

たとえば、eBay は RocksDB を次のように使用しています。 プラットフォーム あなたの「ナレッジグラフ」のために。 ちなみに、読むと面白いです： クエリ言語は自家製の形式として始まりましたが、最近では SPARQL によく似たものに移行しています。。 冗談のように、ナレッジ グラフをどれだけ作成しても、RDF が得られます。

別の例 - 数か月前に登場 ウィキデータ履歴クエリ サービス。 導入前は、ウィキデータの歴史情報にアクセスする必要がありました。 MWAPI 標準の Mediawiki API に。 純粋な SPARQL で多くのことが可能になりました。 「内部」には RocksDB もあります。 ちなみにこれをやったのはWDHQSで、Google Knowledge GraphへのFreebaseのインポートに関わった人のようです。

V. LPG のサポート

LPG グラフと RDF グラフの主な違いを思い出させてください。

LPG では、スカラー プロパティはエッジ インスタンスに接続できますが、RDF では、エッジの「タイプ」にのみ接続できます (ただし、スカラー プロパティだけでなく、通常のリンクも接続できます)。 LPG と比較した RDF のこの制限 克服 ある種のモデリング技術。 RDF と比較して LPG の制限を克服するのはより困難ですが、LPG グラフは RDF グラフよりもハラリの教科書の絵に似ているため、人々はそれを欲しがります。

明らかに、「LPG をサポートする」というタスクは XNUMX つの部分に分かれます。

1. RDF モデルに変更を加えて、その中で LPG 構造をシミュレートできるようにします。
2. RDF クエリ言語に変更を加えて、この変更されたモデル内のデータにアクセスできるようにするか、一般的な LPG クエリ言語でこのモデルをクエリする機能を実装します。

V.1. データ・モデル

ここで考えられるアプローチはいくつかあります。

V.1.1。 シングルトンプロパティ

RDF と LPG を調和させるための最も文字通りのアプローチは、おそらく次のとおりです。 シングルトンプロパティ:

• たとえば述語の代わりに :isMarriedTo 述語が使われている :isMarriedTo1, :isMarriedTo2 そして、t。D。
• これらの述語は、新しいトリプレットの主語になります。 :isMarriedTo1 :since "2013-09-13"^^xsd:date 等
• これらの述語のインスタンスと共通の述語との接続は、次の形式のトリプレットによって確立されます。 :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
• 明らかに、 rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type、しかし、単に書くべきではない理由を考えてください。 :isMarriedTo1 rdf:type :isMarriedTo.

「LPG サポート」のタスクは、ここでは RDFS レベルで解決されます。 このような決定には、関連する政策に含める必要があります。 стандарт。 結果の添付をサポートする RDF リポジトリにはいくつかの変更が必要になる可能性がありますが、現時点では、Singleton Property は単なる別のモデリング手法と考えることができます。

V.1.2。 具体化は正しく行われる

あまり単純ではないアプローチは、プロパティ インスタンスがトリプレットによって完全にインスタンス化されるという認識から生まれます。 トリプレットについて説明できることにより、プロパティ インスタンスについても説明できます。

これらのアプローチの中で最も確実なものは、 RDF*別名RDR、 生まれる ブレイズグラフの内部で。 それは最初からです 選出 私自身とAnzoGraphのために。 アプローチの確実性は、その枠組み内で次のことが行われるという事実によって決まります。 提供された 対応する変化 RDFセマンティクス。 ただし、ポイントは非常にシンプルです。 RDF Turtle シリアル化では、次のようなものを記述できるようになりました。

<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .

V.1.3。 他のアプローチ

形式的な意味論を気にする必要はありませんが、トリプレットにはいくつかの識別子 (もちろん URI) があり、これらの URI を使用して新しいトリプレットを構成すると単純に考えてください。 残っているのは、SPARQL でこれらの URI へのアクセスを許可することだけです。 それで 到着 スタードッグ。

アレグログラフで 行こう 中間的な方法で。 Allegrograph の三つ組の識別子は次のとおりであることが知られています。 がある, が、トリプル属性が実装されると突出しません。 しかし、形式意味論さえもはるかに遠いところにあります。 特に、トリプレット属性は URI ではなく、これらの属性の値もリテラルのみにすることができます。 LPG 支持者はまさに望んでいたものを手に入れることができます。 特別に考案された NQX 形式では、上記の RDF* の例と同様の例は次のようになります。

:bob :marriedTo :alice {"since" : "2013-09-13"}

V.2. クエリ言語

モデル レベルで何らかの方法で LPG をサポートしたら、そのようなモデルでデータをクエリできるようにする必要があります。

• Blazegraph による RDF* クエリのサポート スパークル* и グレムリン。 SPARQL* クエリは次のようになります。

 SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }

• アンゾグラフもサポート スパークル* そしてサポートする予定です Cypher、Neo4j のクエリ言語。
• Stardog は独自のメンテナンスを行っています 拡張 スパークルと また グレムリン。 次のようなものを使用して、SPARQL でトリプレットの URI と「メタ情報」を取得できます。

SELECT * {
    BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
    ?id :since ?since
}

• Allegrograph は独自のサポートもサポートしています 拡張 スパークル:

 SELECT * { ("since" ?since)  franz:attributesNameValue  ( :bob :marriedTo ?wife ) }

ちなみに、GraphDB は一時 LPG をサポートせずに Tinkerpop/Gremlin をサポートしていましたが、バージョン 8.0 または 8.1 で停止しました。

VI. ライセンスの厳格化

「選択したトリプルストア」セットと「オープンソース トリプルストア」セットの交差部分に最近追加されたものはありません。 新しいオープンソースの RDF ストアは日常使用には決して適しておらず、私が使用したい新しいトリプル ストア (たとえば、AnzoGraph) のソース コードはクローズされています。 むしろ、削減について話すことができます...

もちろん、以前はオープンソースが閉鎖的だったわけではありませんが、一部のオープンソース リポジトリは徐々に選択に値しないと考えられています。 私の意見では、オープンソース版がある Virtuoso はバグに満ちています。 Blazegraph は AWS に買収され、Amazon Neptune の基礎を形成しました。 今のところ、少なくともあと XNUMX 回のリリースがあるかどうかは不明です。 残るはジェナだけ…

オープンソースがそれほど重要ではないが、ただ試してみたい場合は、すべてが以前ほどバラ色ではなくなります。 例えば：

• スタードッグ 止まる 無料版を配布します（ただし、通常版の試用期間はXNUMX倍になります）。
• в グラフDBクラウドでは、これまで無料の基本プランを選択できていたところ、新規ユーザー登録が停止されています。

一般に、宇宙は一般の IT 素人にとってはますますアクセスできなくなり、その開発は多くの企業によって行われるようになってきています。

出所： habr.com