セマンティック Web とリンクされたデータ。 修正と追加

最近出版されたこの本の一部を一般に紹介したいと思います。

企業の存在論的モデリング: 方法とテクノロジー [テキスト]: モノグラフ / [S. V. ゴルシコフ、S. S. クラリン、O. I. ムシュタクなど。 エグゼクティブエディター S.V. ゴルシコフ]。 - エカテリンブルク: ウラル大学出版社、2019。 - 234 ページ: 病気、表。 20cm - 著者。 裏胸に記載。 と。 — 参考文献chの最後に— ISBN 978-5-7996-2580-1: 200 部。

この断片をハブレに投稿する目的は XNUMX つあります。

• 尊敬する人物の顧客でない限り、この本を手に取ることができる人はいないだろう。 SergeIndex; 確かに非売品ですね。
• 本文には修正が加えられ (以下では強調表示されていません)、また、印刷されたモノグラフの形式とあまり互換性のない追加が行われています: トピックノート (スポイラーの下) およびハイパーリンク。
• したい 質問やコメントを集める、このテキストを他の出版物に改訂された形式で含めるときにそれらを考慮するためです。
• セマンティック Web とリンクト データの支持者の多くは、自分たちの輪が非常に狭いと今でも信じています。その主な理由は、セマンティック Web とリンクト データの支持者であることがどれほど素晴らしいことであるかが一般の人々にまだ適切に説明されていないからです。 この断片の著者は、このサークルに属していますが、この意見を持っていませんが、それでも、別の試みをする義務があると考えています。

このように、

セマンティックWeb

インターネットの進化は次のように表すことができます (または、以下に示す順序で形成されたインターネットのセグメントについて話します)。

1. インターネット上の文書。 主要なテクノロジー - Gopher、FTP など
   インターネットは、ローカル リソースを交換するためのグローバル ネットワークです。
2. インターネット文書。 主要なテクノロジーは HTML と HTTP です。
   公開されるリソースの性質には、伝送媒体の特性が考慮されます。
3. インターネットデータ。 主要なテクノロジー - REST および SOAP API、XHR など
   インターネット アプリケーションの時代、リソースの消費者になるのは人々だけではありません。
4. インターネットデータ。 主要なテクノロジーは Linked Data テクノロジーです。
   この第 3 段階は、第 XNUMX のコア テクノロジの作成者であり WXNUMXC のディレクターであるバーナーズ リーによって予測されており、セマンティック Web と呼ばれています。 Linked Data テクノロジーは、Web 上のデータを機械が読み取り可能にするだけでなく、「機械が理解できる」ように設計されています。

以下の内容から、読者は第 XNUMX 段階と第 XNUMX 段階の重要な概念間の対応関係を理解するでしょう。

• URL は URI に似ています。
• HTML の類似物は RDF です。
• HTML ハイパーリンクは、RDF ドキュメント内の URI の出現に似ています。

セマンティック Web は、特定の自発的またはロビー活動による傾向よりも、インターネットの将来に対する体系的なビジョンですが、後者を考慮に入れることもできます。 たとえば、Web 2.0 と呼ばれるものの重要な特徴は、「ユーザー生成コンテンツ」であると考えられています。 特に、W3C 勧告を考慮することが求められています。Web アノテーション オントロジー「そしてそのような取り組み コールテン.

セマンティックウェブは死んだのか?

拒否した場合 非現実的な期待、セマンティックウェブの状況は、社会主義が発展した時代の共産主義の状況とほぼ同じです（そして、イリイチの条件付き命令への忠誠が守られるかどうかは、誰もが自分で決めてください）。 サーチエンジン かなり成功した Web サイトに RDFa と JSON-LD の使用を強制し、Web サイト自体が以下に説明するテクノロジに関連するテクノロジ (Google Knowledge Graph、Bing Knowledge Graph) を使用します。

一般論として、著者は何がさらなる蔓延を妨げているのかを言うことはできませんが、個人的な経験に基づいて話すことはできます。 それほど広範囲には及ばないものの、南西部の攻撃状況には「すぐに」解決できる問題があります。 結果として、これらの課題に直面している人々は、解決策を提供できる人々に対して強制する手段を持たない一方で、後者が独自に解決策を提供することは彼らのビジネスモデルに矛盾します。 そのため、私たちは HTML の解析を続け、さまざまな API をつなぎ合わせます。

しかし、Linked Data テクノロジーは主流の Web を超えて広がりました。 実際、この本はこれらのアプリケーションに特化しています。 現在、Linked Data コミュニティは、ガートナーによる次のようなトレンドの記録 (または宣言) のおかげで、これらのテクノロジーがさらに普及すると期待しています。 ナレッジグラフ и データ ファブリック。 私は、これらの概念の「自転車」実装が成功するのではなく、以下で説明する W3C 標準に関連した実装が成功すると信じたいと思います。

リンクされたデータ

Berners-Lee は、Linked Data を「正しく行われた」セマンティック Web、つまり最終目標の達成を可能にする一連のアプローチとテクノロジであると定義しました。 Linked Data の基本原則 バーナーズ・リー 選び出された 次の。

原則1。 URI を使用してエンティティに名前を付ける。

URI は、エントリのローカル文字列識別子ではなく、グローバル エンティティ識別子です。 その後、この原則は Google Knowledge Graph のスローガン「文字列ではなく物'。

原則2。 HTTP スキームで URI を使用して、逆参照できるようにします。

URI を参照することにより、その記号表現の背後にある記号内容を取得できるはずです (演算子 " の名前との類推はここで明らかです)。*「C); より正確には、HTTP ヘッダーの値に応じて、これを意味する表現を取得します。 Accept:。 おそらく、AR/VR 時代の到来により、リソース自体を取得できるようになるでしょうが、今のところ、おそらく、それは SPARQL クエリの実行結果である RDF ドキュメントになるでしょう。 DESCRIBE.

原則3。 特に URI を参照解除する場合は、W3C 標準 (主に RDF(S) と SPARQL) を使用します。

Linked Data テクノロジー スタックのこれらの個々の「レイヤー」は、別名「レイヤー」とも呼ばれます。 セマンティック Web レイヤー ケーキについては後述する。

原則4。 エンティティを記述する際の他の URI への参照の使用。

RDF を使用すると、リソースを自然言語で口頭で説明することに制限できますが、XNUMX 番目の原則ではこれを行わないように求められています。 最初の原則が普遍的に守られている場合、リソースを記述するときに、「外部」リソースを含む他のリソースを参照することが可能になります。これが、データがリンクされていると呼ばれる理由です。 実際、RDFS ボキャブラリで指定された URI を使用することはほぼ避けられません。

RDF

RDF (リソース記述フレームワーク) は、相互に関連するエンティティを記述するための形式主義です。

トリプレットと呼ばれる「主語-述語-目的語」タイプのステートメントは、エンティティとその関係について作成されます。 最も単純なケースでは、主語、述語、目的語はすべて URI です。 同じ URI が、異なるトリプレットの異なる位置に存在する可能性があります。つまり、主語、述語、目的語になります。 したがって、トリプレットは RDF グラフと呼ばれる一種のグラフを形成します。

サブジェクトとオブジェクトは URI だけでなく、いわゆる 空のノード、オブジェクトも可能です リテラル。 リテラルは、文字列表現と型指示で構成されるプリミティブ型のインスタンスです。

リテラルの記述例 (Turtle 構文の場合、詳細は以下で説明します): "5.0"^^xsd:float и "five"^^xsd:string。 型付きリテラル rdf:langString 言語タグを装備することもできます。Turtle では次のように記述されます。 "five"@en и "пять"@ru.

空のノードはグローバル識別子のない「匿名」リソースですが、それについてはステートメントを作成できます。 存在変数の一種。

したがって (実際、これが RDF の要点です):

• subject は URI または空のノードです。
• 述語は URI であり、
• object は、URI、空のノード、またはリテラルです。

述語を空のノードにできないのはなぜですか?

考えられる理由は、トリプレットを非公式に理解し、一次述語論理の言語に翻訳したいという欲求です。 s p o みたいな どこ - 述語、 и - 定数。 この理解の痕跡は文書の中にあります。LBase: セマンティック Web の言語のセマンティクス」、これは W3C ワーキング グループのメモのステータスを持っています。 このように理解すると、トリプレットは、 s p []どこ [] - 空のノードは次のように変換されます。 どこ - 変数ですが、どのように翻訳するか s [] o? W3C 勧告ステータスを含む文書」RDF 1.1 セマンティクス」は別の変換方法を提供しますが、述語が空のノードである可能性はまだ考慮されていません。

しかし、マヌ・スポルニ 許可された.

RDF は抽象モデルです。 RDF はさまざまな構文で記述する (シリアル化する) ことができます。 RDF/XML, カメ (人間が判読できる範囲で最も可読性が高い)、 JSON-LD, HDT （バイナリ）。

同じ RDF をさまざまな方法で RDF/XML にシリアル化できるため、たとえば、XSD を使用して結果の XML を検証したり、XPath を使用してデータを抽出しようとしたりすることは意味がありません。 同様に、JSON-LD は、JavaScript のドットと角括弧の表記法を使用して RDF を操作したいという平均的な Javascript 開発者の欲求を満たす可能性は低いです (ただし、JSON-LD は、メカニズムを提供することでその方向に進んでいます) フレーミング).

ほとんどの構文には、長い URI を短縮する方法が用意されています。 たとえば、広告 @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> Turtle では、代わりに次のように書くことができます。 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ちょうど rdf:type.

RDFS

RDFS (RDF スキーマ) - 基本的なモデリング語彙。プロパティ、クラス、および次のようなプロパティの概念を導入します。 rdf:type, rdfs:subClassOf, rdfs:domain и rdfs:range。 たとえば、RDFS ディクショナリを使用すると、次の有効な式を作成できます。

rdf:type         rdf:type         rdf:Property .
rdf:Property     rdf:type         rdfs:Class .
rdfs:Class       rdfs:subClassOf  rdfs:Resource .
rdfs:subClassOf  rdfs:domain      rdfs:Class .
rdfs:domain      rdfs:domain      rdf:Property .
rdfs:domain      rdfs:range       rdfs:Class .
rdfs:label       rdfs:range       rdfs:Literal .

RDFS は記述とモデリングの語彙ですが、制約言語ではありません (ただし、公式の仕様と 葉っぱ そのような使用の可能性があります）。 「スキーマ」という言葉は、「XML スキーマ」という表現と同じ意味で理解すべきではありません。 例えば、 :author rdfs:range foaf:Person という意味です rdf:type すべてのプロパティ値 :author - foaf:Person, しかし、これは事前に言うべきだという意味ではありません。

SPARQL

SPARQL (SPARQL プロトコルおよび RDF クエリ言語) - RDF データをクエリするための言語。 単純なケースでは、SPARQL クエリは、クエリ対象のグラフのトリプレットが照合されるサンプルのセットです。 パターンには、主語、述語、および目的語の位置に変数を含めることができます。

クエリは、サンプルに代入すると、クエリされた RDF グラフのサブグラフ (そのトリプレットのサブセット) が得られるような変数値を返します。 トリプレットの異なるサンプル内の同じ名前の変数は、同じ値を持つ必要があります。

たとえば、上記の XNUMX つの RDFS 公理のセットを考慮すると、次のクエリは次の値を返します。 rdfs:domain и rdfs:range 価値観として ?s и ?p したがって：

SELECT * WHERE {
 ?s ?p rdfs:Class .
 ?p ?p rdf:Property .
}

SPARQL は宣言型であり、グラフ トラバーサルを記述するための言語ではないことに注意してください (ただし、一部の RDF リポジトリではクエリ実行プランを調整する方法が提供されています)。 したがって、最短パスの検索などの一部の標準グラフ問題は、SPARQL では解決できません。 プロパティパス (ただし、繰り返しになりますが、個々の RDF リポジトリは、これらの問題を解決するための特別な拡張機能を提供しています)。

SPARQL は世界のオープン性の前提を共有せず、「失敗としての否定」アプローチに従います。 可能 などのデザイン FILTER NOT EXISTS {…}。 データ分散を考慮した仕組み フェデレーションクエリ.

SPARQL アクセス ポイント (SPARQL クエリを処理できる RDF ストレージ) には、第 XNUMX 段階から直接類似するものはありません (この段落の冒頭を参照)。 これは、HTML ページが生成された内容に基づいてデータベースにたとえることができますが、外部からアクセスできます。 SPARQL アクセス ポイントは、第 XNUMX 段階の API アクセス ポイントに似ていますが、主に XNUMX つの違いがあります。 第一に、複数の「アトミック」クエリを XNUMX つに結合することが可能であり (これが GraphQL の重要な特性と考えられています)、第二に、そのような API は完全に自己文書化されています (これが HATEOAS が達成しようとしたことです)。

論争的な発言

RDF は Web 上でデータを公開する方法であるため、RDF ストレージはドキュメント DBMS と見なす必要があります。 確かに、RDF はツリーではなくグラフであるため、グラフベースであることも判明しました。 それがまったくうまくいったのは驚くべきことです。 空のノードを実装する賢い人がいるとは誰が想像したでしょうか。 コッドがここにいます うまくいかなかった.

RDF データへのアクセスを整理するための、あまり機能が充実していない方法もあります。次に例を示します。 リンクされたデータフラグメント (LDF)と リンクドデータプラットフォーム （自民党）。

OWL

OWL (Web オントロジー言語) - 知識を表現するための形式主義、記述ロジックの構文バージョン (以下では、OWL 2と言う方が正確です。OWLの最初のバージョンは、OWL XNUMXに基づいていました。 ).

OWLの記述ロジックの概念はクラスに対応し、ロールはプロパティに対応し、個人は以前の名前を保持します。 公理は公理とも呼ばれます。

たとえば、いわゆる マンチェスター構文 OWL表記の場合、すでに知られている公理 次のように書かれます:

Class: Human
Class: Parent
   EquivalentClass: Human and (inverse hasParent) some Human
ObjectProperty: hasParent

OWLを記述するための構文は他にもあります。 関数構文、公式仕様で使用されており、 OWL/XML。 さらに、OWL はシリアル化できます。 RDF構文を抽象化する さらに、特定の構文のいずれかで。

OWLはRDFと二重の関係にあります。 一方で、RDFS を拡張した一種の辞書と考えることもできます。 一方、RDF は単なるシリアル化形式であるため、RDF はより強力な形式主義です。 すべての基本的な OWL 構造が単一の RDF トリプレットを使用して記述できるわけではありません。

OWL構造体のどのサブセットの使用が許可されているかに応じて、それらはいわゆる OWLプロファイル。 標準化されており最も有名なのはOWL EL、OWL RL、OWL QLです。 プロファイルの選択は、一般的な問題の計算の複雑さに影響します。 以下に対応するOWLコンストラクトの完全なセット 、OWL DLと呼ばれます。 場合によっては、意味論的および計算上の制限なしに、RDF に固有の完全な自由で OWL 構造を使用できる OWL Full についても話します。 。 たとえば、何かはクラスとプロパティの両方になる可能性があります。 OWL Fullは未定。

OWLで結果を付加するための重要な原則は、オープンワールドの仮定を採用することです。 OWA）および一意の名前の推定の拒否（一意の名前の仮定、 ONE）。 以下では、これらの原則がどこにつながるかを見て、いくつかのOWL構造を紹介します。

オントロジーに次のフラグメント (マンチェスター構文) が含まれるようにします。

Class: manyChildren
   EquivalentTo: Human that hasChild min 3
Individual: John
   Types: Human
   Facts: hasChild Alice, hasChild Bob, hasChild Carol

ジョンにはたくさんの子供がいると言われていることから、そうなるのでしょうか？ UNA を拒否すると、アリスとボブは同一人物である可能性が高いため、推論エンジンはこの質問に否定的に答えることになります。 以下のことを行うには、次の公理を追加する必要があります。

DifferentIndividuals: Alice, Bob, Carol, John

ここで、オントロジーのフラグメントが次の形式を持つとします (ジョンには多くの子供がいると宣言されていますが、子供は XNUMX 人しかいません)。

Class: manyChildren
   EquivalentTo: Human that hasChild min 3
Individual: John
   Types: Human, manyChildren
   Facts: hasChild Alice, hasChild Bob
DifferentIndividuals: Alice, Bob, Carol, John

このオントロジーは矛盾しますか (無効なデータの証拠として解釈される可能性があります)? OWA を受け入れると、推論エンジンは否定的な応答をします。つまり、別の「どこか」 (別のオントロジー内) では、キャロルもジョンの子供であると言えるかもしれません。

この可能性を排除するために、ジョンに関する新しい事実を追加しましょう。

Individual: John
   Facts: hasChild Alice, hasChild Bob, not hasChild Carol

他の子供の出現を除外するために、「子供がいる」というプロパティのすべての値が人々であり、そのうちの XNUMX つだけがあるとします。

ObjectProperty: hasChild
   Domain: Human
   Сharacteristics: Irreflexive
Class: Human
EquivalentTo: { Alice, Bill, Carol, John }

オントロジーは矛盾するようになり、推論エンジンは必ずそれを報告します。 最後の公理により、ある意味で世界が「閉じられた」ことになり、ジョンが自分の子供である可能性がどのように排除されているかに注目します。

企業データのリンク

Linked Data の一連のアプローチとテクノロジーは、もともと Web 上でデータを公開することを目的としていました。 企業内部環境でこれらを使用するには、多くの困難に直面します。

たとえば、閉鎖的な企業環境では、OWA の採用と UNA の拒否に基づく OWL の演繹力 (Web のオープンで分散された性質による決定) は弱すぎます。 そしてここで、次のような解決策が考えられます。

• OWLにセマンティクスを与え、OWAの放棄とUNAの採用、対応する出力エンジンの実装を意味します。 - この道に沿って です スタードッグ RDF ストレージ。
• OWLの演繹機能を放棄し、ルールエンジンを優先します。 — スタードッグのサポート スワール; Jena と GraphDB のオファー 自分の 言語 ルール
• OWLの演繹的機能の拒否、モデリングのためのRDFSに近いXNUMXつまたは別のサブセットの使用。 - これについては以下を参照してください。

もう XNUMX つの問題は、企業がデータ品質の問題と Linked Data スタック内のデータ検証ツールの欠如に大きな焦点を当てている可能性があることです。 ここでの出力は次のとおりです。

• この場合も、適切な推論エンジンが利用可能な場合は、閉じた世界のセマンティクスと一意の名前を持つ OWL 構造の検証に使用します。
• 使用 シャクル、Semantic Web Layer Cake レイヤーのリストが修正された後に標準化されました (ただし、ルール エンジンとしても使用できます)、または シュエクス.
• 最終的にはすべてが SPARQL クエリで行われることを理解し、それらを使用して独自の単純なデータ検証メカニズムを作成します。

しかし、たとえ演繹機能や検証ツールを完全に拒否したとしても、リンクト データ スタックは、オープンで分散された Web と状況が似ているタスク、つまりデータ統合タスクにおいて競争力を失います。

通常の企業情報システムではどうでしょうか?

これは可能ですが、対応するテクノロジがどのような問題を解決する必要があるかを正確に認識しておく必要があります。 ここでは、この技術スタックが従来の IT の観点からどのように見えるかを示すために、開発参加者の典型的な反応を説明します。 象のたとえ話を少し思い出します。

• ビジネスアナリスト: RDF は、直接保存された論理モデルのようなものです。
• システムアナリスト: RDF は次のようなものです EAV大量のインデックスと便利なクエリ言語を備えているだけです。
• 開発者: そうですね、これはすべてリッチ モデルとロー コードの概念の精神に基づいています。 読む 最近これについて。
• プロジェクトリーダー：はい、同じです スタックを折りたたむ!

実践によると、スタックは、MDM (マスター データ管理) や DWH (データ ウェアハウス) クラス システムを構築する場合など、データの分散と異質性に関連するタスクで最もよく使用されます。 このような問題はどの業界にも存在します。

業界固有のアプリケーションに関して言えば、Linked Data テクノロジーは現在、次の業界で最も人気があります。

• 生物医学技術 (その人気は分野の複雑さに関係していると思われる);

現在

「Boiling Point」は最近、「National Medical Knowledge Base」協会が主催するカンファレンスを主催しました。オントロジーの結合。 理論から実践へ'。

• 複雑な製品の生産と運営 (大規模な機械工学、石油とガスの生産。ほとんどの場合、標準的な製品について話します) ISO 15926);

現在

ここでも、その理由は対象分野の複雑さです。たとえば、石油・ガス産業について言えば、上流段階では、単純な会計処理にいくつかの CAD 機能が必要になります。

2008 年には、シェブロンが主催する代表的なインスタレーション イベントが開催されました。 会議.

ISO 15926 は結局のところ、石油・ガス業界にとっては少々負担が大きいように思えました (そしておそらく機械工学においてより大きな応用が見出されています)。 完全に夢中になったのは Statoil (Equinor) だけで、ノルウェーでは全体が 生態系。 他の人は自分のことをやろうとしています。 たとえば、噂によると、国内エネルギー省は、明らかに次のような「燃料・エネルギー複合体の概念的存在論的モデル」を作成するつもりだという。 電力業界のために作られた.

• 金融機関 (XBRL でさえ、SDMX と RDF データ キューブ オントロジーの一種のハイブリッドと考えることができます)。

現在

今年の初めに、LinkedIn は、テレビ シリーズ「不可抗力」で著者が知っている金融業界のほぼすべての巨人からの求人情報を積極的にスパム送信しました。ゴールドマン サックス、JP モルガン チェースおよび/またはモルガン スタンレー、ウェルズ ファーゴ、 SWIFT/Visa/Mastercard、Bank of America、Citigroup、FRB、Deutsche Bank...おそらく誰もが送金できる相手を探していたでしょう。 ナレッジグラフカンファレンス。 かなりの数の人が、金融機関がすべてを奪ったことを発見しました。 初日の朝.

HeadHunter では、Sberbank だけが興味深いものを見つけました。それは、「RDF のようなデータ モデルを備えた EAV ストレージ」に関するものでした。

おそらく、国内の金融機関と欧米の金融機関の対応技術に対する愛情の度合いの違いは、後者の活動の国境を越えた性質によるものと思われます。 明らかに、州境を越えた統合には、質的に異なる組織的および技術的ソリューションが必要です。

• 商用アプリケーションを使用した質問応答システム (IBM Watson、Apple Siri、Google Knowledge Graph)。

現在

ちなみに、Siri の作成者であるトーマス グルーバーは、「概念化仕様」としての (IT の意味での) オントロジーの定義そのものの著者です。 私の意見では、この定義の単語を並べ替えても意味は変わりませんが、これはおそらくその定義が存在しないことを示していると思います。

• 構造化データの公開 (より正当な理由として、これは Linked Open Data に起因すると考えられます)。

現在

Linked Data の大ファンは、ギャラリー、図書館、アーカイブ、博物館などのいわゆる GLAM です。 米国議会図書館が MARC21 の代替を推進していると言えば十分でしょう。 ゼッケンフレームどちら 書誌記述の将来のための基盤を提供する そしてもちろん RDF に基づいています。

ウィキデータは、Linked Open Data の分野で成功したプロジェクトの例としてよく引用されます。ウィキデータは、ウィキペディアの一種の機械可読バージョンであり、DBPedia とは対照的に、そのコンテンツは記事インフォボックスからのインポートによって生成されません。多かれ少なかれ手動で作成されます (その後、同じインフォボックスの情報源になります)。

こちらもぜひチェックしてみることをお勧めします リスト Stardog Web サイトの「顧客」セクションにある Stardog RDF ストレージのユーザー。

それはともかく、Gartner では 2016 年の新興テクノロジーのハイプ サイクル 「エンタープライズ分類とオントロジー管理」は、早ければ 10 年以内に「生産性のプラトー」に達すると予想され、失望の谷への下り坂の真っ只中に置かれています。

エンタープライズデータの接続

予報、予報、予報…。

歴史的関心から、私たちが興味を持っているテクノロジーに関するさまざまな年における Gartner の予測を以下に表にしました。

年	Технология	レポート	位置	停滞期までの年数
2001	セマンティックWeb	新技術	イノベーショントリガー	5-10
2006	企業セマンティック Web	新技術	インフレ期待のピーク	5-10
2012	セマンティックWeb	ビッグデータ	インフレ期待のピーク	> 10
2015	リンクされたデータ	高度な分析とデータサイエンス	幻滅のくぼ地	5-10
2016	エンタープライズオントロジー管理	新技術	幻滅のくぼ地	> 10
2018	ナレッジグラフ	新技術	イノベーショントリガー	5-10

ただし、すでに 「ハイプサイクル...」2018 別の上昇傾向が現れました - ナレッジグラフ。 ある輪廻が起こった。ユーザーの注意と開発者の努力がグラフDBMSに切り替わり、前者の要求と後者の習慣の影響を受けて、その輪郭と位置付けが決まり始めた。以前の競合他社の。

現在、ほぼすべてのグラフ DBMS は、企業の「ナレッジ グラフ」 (「リンクされたデータ」は「接続されたデータ」に置き換えられることもあります) を構築するのに適したプラットフォームであると宣言していますが、そのような主張はどの程度正当化されるのでしょうか?

グラフ データベースは依然としてセマンティックであり、グラフ DBMS 内のデータは依然として同じデータ サイロです。 URI の代わりに文字列識別子を使用すると、XNUMX つのグラフ DBMS を統合するタスクが依然として統合タスクになりますが、XNUMX つの RDF ストアの統合は、多くの場合、単純に XNUMX つの RDF グラフをマージすることになります。 アセマンシティのもう XNUMX つの側面は、LPG グラフ モデルの非再帰性であり、これにより、同じプラットフォームを使用してメタデータを管理することが困難になります。

最後に、グラフ DBMS には推論エンジンやルール エンジンがありません。 このようなエンジンの結果はクエリを複雑にすることで再現できますが、これは SQL でも可能です。

ただし、主要な RDF ストレージ システムは、LPG モデルを問題なくサポートしています。 最も確実なアプローチは、Blazegraph で一度提案されたアプローチであると考えられています。それは、RDF と LPG を組み合わせた RDF* モデルです。

もっと

LPG モデルの RDF ストレージ サポートの詳細については、Habré に関する以前の記事を参照してください。 「RDFストレージで今何が起こっているのか」。 いつかナレッジ グラフとデータ ファブリックについて別の記事が書けることを願っています。 最後のセクションは、わかりやすいように、急いで書かれたものですが、XNUMX か月経っても、これらの概念についてすべてがそれほど明確になっているわけではありません。

文学

1. Halpin, H.、Monnin, A. (編) (2014)。 哲学工学: ウェブの哲学に向けて
2. Allemang, D.、Hendler, J. (2011) 働く存在論者のためのセマンティック Web (第 2 版)
3. Staab, S.、Studer, R. (編) (2009) オントロジーに関するハンドブック (第 2 版)
4. ウッド、D. (編)。 (2011) 企業データのリンク
5. Keet, M. (2018) オントロジー エンジニアリングの概要

出所： habr.com