この記事では、指のキーポイントを説明し、RDFモデルの利点を実証しようとします。
10年以上にわたって、RDFを含むセマンティックWebの概念は議論と議論の対象となっており、今日では、その応用においてコミュニティによってますます支持されています。
ただし、多くの場合、まだ明確ではありません。
- なんでこんなこと？
- どのように作業するのですか？
- 正確に何が得られますか？
ほとんど、少なくとも短時間、有名なケーキを見ました：
多くの仕様、技術、概念があります-目さえ散らばっています...下位レベルは世界と同じくらい古く、学者はネットワークから受け取った利用可能なステートメントをどれだけ信頼できるかを評価するためにアプリケーションを教えるために上位レベルを超えて苦労しています。 通常の開発者はまだそれを心配することなく、さらに5年待つことができます。w3cのメンバーは疲れることなく真ん中の標準を磨き、RDFのように既に磨かれているものもあります。行って使用します。 主にRDFモデルを使用して、実際のアプリケーションで頻繁に遭遇するのは、それらのユーザーです。
なぜそれが必要なのか、何が必要なのか、オントロジーをどのように扱うのかを理解するのはとてもいいことですが、これは今回についてではありません。
それでは、モデルを使用して得られるものを理解してみましょう。
- 新しい事実の論理的結論
- セマンティック検索のサポート
- データモデルの柔軟性
- システム間のデータ交換が非常に簡単
正式な論理をこれまで一度も勉強したことがない場合は、事実を正式に説明しておくと、明確に定義されていない多くの新しい事実を自動的に取得できることを思い出してください...このトピックは、触れるまで特別な注意に値します。
セマンティック検索、なぜ、Googleがあるのですか？
はい、 「Habrユーザーのリスト」を入力すると、間違ったユーザーのセットだけが取得されます。 なんで？ -Googleはドキュメントのテキスト内のクエリから単語を検索し、事実ではなくドキュメントを返すためです。
そして、「hubr」リソースの「user」オブジェクトが必要であり、これらのオブジェクトの正式な説明がRDFモデルでのインデックス作成に使用できると理解した場合（たとえば、検索エンジンがインデックス付けできるようにページ上のRDFaレコードの形式で）探していたオブジェクトのセット。
多くの人が反対しています-「リンクをいくつか回って、さらに明確なクエリを作成し、それでも必要なものを見つけることができます。なぜですか？」-その答えは、今日はファイリングキャビネットを使用せず、検索バーにいくつかのキーワードを入れてそして、あなたがすぐに情報を受け取ることは言うまでもありません。 何らかの理由で、私たちは車で、そして馬で仕事に行きます-それはより便利だからです。
質問-「RDFはセマンティック検索をどのように提供するのですか？」-答え：RDFモデルは正式な説明を提供します。 正式な説明がある場合、検索エージェントは事実と知識を検索できます。
Googleは今日これを探していません-なぜ今それについてスチームバスをする必要があるのですか？ まず第一に、後述の利点を得るため、そして第二に、「遅れている」ことではありません-私たちの業界はそうです-「迅速であるか死んでいる」
他の2つの利点について詳しく説明しましょう。これらの利点は、私のように理解しやすいです。 しかし、最初に、さらにいくつかのポイントを明確にします。
RDFモデルとは何ですか？
すぐにRDFを理解する必要があります-これは抽象的で非常に単純なモデルで、少し空虚です。 いくつかの追加事項と注意事項を含む有向グラフ。 ただし、さまざまな方法で記述できます。通常、選択肢はN3、N-Triples、Turtle、RDF / XML、RDFaのいずれかであり、使用する仕様を検討する必要があります。
説明対象：RDFを使用すると、ドキュメント、ドキュメント内の個々の知識、および現実世界のオブジェクト（特定の生きている人（ここでは一部のit-peopleはsome迷に陥る）など）の両方を説明できます。
すべてはURIを使用して識別されます。 さらに、URIは通常のリンクURLのように見えますが、少し異なります。たとえば、リソース（実在の人物）を定義し、そのURIを「http://example.org/people# Vasya Pupkin」に設定できます。
はい、ユニコード以来ロシア語で書くことができますが、理解する必要があるのはURLではないことです-ブラウザに挿入して人を取得することはできません-科学はこの点に達していません。
モデルの柔軟性とシステム間でのデータ交換について、ここのどこかで理解してみましょう。
人々がどのように通信するかを見てみましょう：
彼らは特定の言語の助けを借りて、さまざまな方法で口頭で自分の考えを書き留め（公式化）、情報はさまざまなシステムを介してスピンし、口から口へと渡され、保存され、集約されます。 しかし、最終的に、それはこの言語を解釈し、考えを受け取ることができる人によって読まれます。 説明されたチェーン内で、あるノードから別のノードに形式化された思考がどの程度正確に送信されるかは、最終的には誰にも関係しません。
中国語がわからない場合でも、ある場所から別の場所にctrl-c ctrl-vを作成することを妨げることはありません。
RDFは非常によく似ています。
情報は、RDFで形式化され、反対側のエージェントによって読み取られる場合にのみ解釈される必要があります。 これらの2つの段階の間、誰でも処理して、何らかの方法で共有することができます。必ずしも意味の意味を表すわけではなく、意味を理解するためでもありません。
たとえば、RDFステートメント（triplet subject-predicate-object）
< www.example.org/index.html > < www.example.org/terms/creation-date > 1999年8月16日。
理解するために、言い換えることができます
www.example.org/index.htmlにはプロパティwww.example.org/terms/creation-dateがあり、その値は1999年8月16日です。
つまり アプリケーションを作成している場合、 www.example.org/terms/creation-dateの解釈方法をアプリケーションロジックで説明する必要があります。 すぐに注意深い読者の質問-誰もが1つのことを示す述語を作成し、統合したい各アプリケーションのアプリケーションロジックに同義語を追加する必要があるので？
答えはNOです...最初に、すでに開発され活発に使用されているほとんどのタスクに対して、可能な限り普遍的に認識されている辞書を使用すること、そして次にオントロジーに基づいて、owl：SameAs 2つのエンティティ間の関係と、必要な同義語を論理的に導き出すことができ、アプリケーションを書き換える必要はありません。 そのような目的で、外部サービスを使用できます。
したがって、n + 1システムとの統合など、不必要なジェスチャーを行うことなく、誰とでも交換することができます。 このために何かをプログラムする必要はありません。 このシステムがあなたのものから必要とするすべての概念-それは受け取り、解釈することができます。
今日の比較のために、XML、XSLT、またはAPIから取得したフィールドを使用して、あるシステムのフィールドを他のシステム（多くの場合、それぞれ）に明示的に関連付ける必要があります。
データが特定のアプリケーションのモデルから独立している可能性があることを理解するようになりました。 つまり 一連の事実はそれ自身で生きています。 追加、削除、リクエストの作成、解釈は可能ですが、それらは論理的に独立しています。
この事実には、次の重要な利点があります。 モデルの変更が容易です。
リレーショナルモデルに依存するアプリケーションで何をする必要があるか想像してみてください。 ドラマのために、データモデルを変更する必要がある場合は、起動後に既に実行する必要があることを想像してみましょう。たとえば、ユーザーオブジェクトに新しいエンティティ、住所などを関連付ける必要があります。 d。）。 データベースで何をする必要がありますか？ いくつかのラベルを正しく修正し、新しいラベルを作成し、それらの間に接続を追加し、データにアクセスする手順を変更し、Webサービスを修正すれば完了です。 そしてもちろん、ユーザーインターフェイスを変更する必要があります。
これを行うのは少し不快ですよね？
そして、インターフェースにいくつかのフィールドを追加し、新しいフィールドごとに1つの新しいステートメントを追加するアクションを実行するだけで済むとしたら、どれだけ簡単になるでしょう（より普遍的に設計されたインターフェースがある場合は、この最小値も回避できます） ？ 数行のコード...
RDFモデルを使用すると、この操作はまさにそのようになります。 結局のところ、格納されるのは、subject-predicate-objectの膨大な数のステートメントだけです。 したがって、データモデルの変更は、考えてすぐに気分を損なうものではなくなります。