ユーザー情報スペースの編成と最適化

毎日、仕事やその他の機能を実行する現代人は、大量の情報を分析し、必要なデータを見つけるというタスクに直面しています。 時間が経つにつれて、ドキュメントの形でユーザーデータの蓄積。 これらのドキュメントは、ユーザー情報スペースになります。 新しいドキュメントごとに、このスペースをより鋭く整理する問題がますます発生します：時間とともに、階層的に配置されたファイルを含む2つから3つのフォルダーから、膨大なドキュメントの山が得られます。これは、線形関係を持つ階層形式に導くことは非常に困難です。 ユーザーの情報スペースを具体化し、分類し、視覚化するという課題に直面しています。


用語を定義してみましょう。この記事のフレームワークにおけるユーザーの情報空間は、特定のディレクトリ階層内のファイルシステム上で配布されるテキスト（非表形式およびグラフィック）ドキュメント（ファイル）のセットとして理解されます。 わかりやすくするために、情報空間のドキュメントが経済学などの1つのサブジェクトエリアに属するための条件の説明も簡略化します。 テキストファイルは、経済的な記事、科学論文、教科書、および経済的なテキスト情報を提示する他の形式を表すことができます。

情報スペースの形成の初期段階では、ユーザーはそのサイズが小さいためにナビゲートするのが非常に簡単であり、その結果、要素間の構造と関係がかなり明確になります。 時間の経過と、ユーザーが公式、科学、および日常の機能を実行するにつれて、情報スペースのパワーが増大し、ノード（ファイル）間の個々のリンクの重みが減少し、ナビゲートがより困難になります。 これにより、必要な情報を検索する時間が長くなり、情報スペースのフレームワーク内でのユーザーのアクティビティの品質と生産性が低下します。
原則として、これはテキスト情報の量の増加だけでなく、ユーザーによる知覚速度の低さも原因です。 配列全体で適切なフラグメントを見つけることも困難です：ユーザーは、適切な検索結果を得るために検索クエリを正しく構成する必要があります。たとえば、サブジェクト領域でのユーザーの知識が低い、または類似の定式化で異なる​​ことを説明する同義語または事実の存在が原因で問題が発生することがあります また、オペレーティングシステムによるドキュメントの全文検索の使用は、検索結果のパーソナライズと関連性を提供しません。これは、ユーザーの速度とユーザーの情報スペースの組織の質にも悪影響を及ぼします。
標準検索と情報スペースの編成の上記の欠点から、ユーザーの情報アクティビティを最適化するために必要なことは次のとおりです。

• サブジェクト領域をカテゴリまたは「ゾーン」に分割します
• サブジェクトエリアのキーノードを選択する
• 対象領域を視覚化して、人間の知覚を加速します
• サブジェクト領域の各要素内のノードを識別します（オントロジーの形成）
• ドメインのノード内のオブジェクトのプロパティとそれらの関係（オントロジーの形成の完了）を決定する
• サブジェクトエリアのノード間の接続と相互作用を決定する（ノードのセマンティックネットワークのコンパイル-オントロジー）
• サブジェクト領域の視覚化と機能の説明のレベルを関連付けます（タグカード、オントロジー、セマンティックネットワークの重なり）
• ユーザーと対話するプロセスでの反復学習に基づいて、主題領域とそのプレゼンテーションの関連性をパーソナライズする機能を実装します。

上記を実装するには、3つのテクノロジーを使用することをお勧めします。これらは、マップまたはタグクラウド、オントロジー、セマンティックネットワークです。 個別に、それらのいずれも、情報スペースの組織における既存のすべての欠点の除去に寄与しませんが、その部分を最適化し、その結果、ユーザーの情報活動の改善に役立ちます。

タグのマップ（クラウド）は、サブジェクト領域の最高レベルの詳細を表します。これは、サブジェクト領域の一種のGUI（グラフィックユーザーインターフェイス）です。 この場合、タグマップ（クラウド）の古典的な記述から多少の逸脱があります：タグは単なるテキストラベルよりも少し多く使用されます-この場合、タグはオブジェクトの名前になります。これは、サブジェクトエリアの1つからいくつかのオントロジーの結合です。 古典的な「クラウド」から「マップ」への逸脱は、主題エリアがゾーンに分割されているためです（国が政治マップ上のエリアでどのように分割されているか）。 この区分は、ユーザーのサブジェクトエリアのオントロジー（ファクト、ドキュメント）間の必要なデータの視覚的知覚の速度と検索の直感性を高めるために導入されました。 タグマップはトップレベルであり、その形成には、オントロジーとセマンティックネットワークの2つのレベルのデータが使用されます。

タグカードを使用すると、特定のユーザーの検索結果の関連性を確認できます。 これを行うには、タグによってユーザーの情報スペースを介したナビゲーションの履歴を記録するメカニズム、いわゆる「知識ルート」を使用することをお勧めします。 この「ルート」は、時間の経過とともに募集および修正されます。新しい検索のたびに、ユーザーはタグマップ内を移動することで、ノード間の関係を設定します。 そして、次回、ユーザーがサイトにアクセスすると、彼が代表するオントロジーに加えて、ユーザーにはオントロジー、つまり彼に関連するノードも与えられます。 この手法を使用して検索結果を整理することにより、ユーザーの情報スペースをパーソナライズできます。システムによって収集された好みに応じて、ユーザーに必要なオプションが提供されます。

標準のタグクラウドを使用する場合、1つの重要な欠点が明らかになりました：新しいデータソースと古いデータソース（追加日まで）がマップ上で同じようにマークされます-これにより、ユーザーが追加日までに開くノードを事前に知ることができません。 「新規」プロパティをタグに追加することをお勧めします。これは、所定の相対時間スケール（パレット）に応じた色の視覚表示です。 たとえば、24時間以内に追加されたノードを記述するタグの場合は白色が、1週間以内に追加されたタグの場合は黄色などが適用されます。 このプロパティを追加すると、ユーザーの情報スペースをより適切に整理し、ユーザーによる必要な情報の受信を促進することもできます。

オントロジーは、データの粒度の最低レベルを表します。 各ユーザーファイルは個別のオントロジーと見なされます。 初期データは、ディレクトリ構造のファイルシステムに配布されたファイルの形式のテキストドキュメントであるため、情報空間の機能構造のコンパイルを簡素化するために、このような規則が採用されています。 このシステムのフレームワーク内のオントロジーの場合、ドメインノードの正式な明示的な記述が取得されます。 これは、ノードではなくサブジェクト領域全体を記述するという点で、オントロジーの古典的な定義からわずかに逸脱しています。これは、ユーザーの情報空間のパーソナライズの度合いを高めるために行われました。 主題分野「経済学」には既製のオントロジーがいくつかあります。それらはすべて異なる規模をカバーし、詳細度が異なりますが、特定のユーザー向けに「調整」されていません。
そのため、システムは「1回限り」ではありません。主題分野の特定の一般的な辞書またはシソーラスを基礎として、主題分野「経済」の概念のすべての概念と特性、およびそれらの間のいくつかの基本的なつながりと関係を説明します。 このようなクラス、スロット、およびオントロジーファセットの中央リポジトリを使用すると、システムのクライアント/サーバーアーキテクチャを使用できます。これには、スタンドアロンバージョンに比べて次のような利点があります。

• フォールトトレランス（オントロジーオブジェクトは、データバックアップシステムを備えたサーバーに保存されます）
• スケーラビリティ（新しいユーザーを十分に迅速にシステムに接続することが可能になります）
• 計算能力の最適な使用
• ユーザーグループの力による開発（オントロジーは1人ではなく数人によって補充および最適化され、開発が大幅に加速され、比較的短時間で大容量のオントロジーが増加します。また、設計およびサポートツールとの重複および同義語を検索できるため、冗長性が回避されますオントロジー）

クライアント/サーバーアーキテクチャを使用する場合、サーバーはドメインクラス、そのスロット、ファセット、および基本的な関係を格納します。 クライアント側では、クラスとインスタンス間の関係を指定（パーソナライズ）するクラスインスタンスが保存されます。 したがって、ユーザー側のシステムは、既製のオントロジーとサーバーに格納された要素を使用して独自のパーソナライズされたオントロジーを構築し、そのアクティビティの結果をサーバーに送信することで、更新と進化を保証できます。

前述のように、各ファイルは個別のオントロジーとして受け入れられ、サーバーオントロジーとの関係は「含む」タイプになります。 「なぜこのようなオントロジーアーキテクチャを使用するのでしょうか。1つの大きなオントロジーを作成して、その中で動作するのはなぜですか？」 説明は次のとおりです。多くのオントロジーを使用すると、システム、クライアントサーバーアーキテクチャの条件の下での情報スペースをパーソナライズできますが、同時に、オントロジー比較メカニズムのおかげで、オントロジー間の関係の分析はそれらの数によってまったく妨げられません。

また、何らかの普遍的なアルゴリズムに基づいて、それとは別の小さなオントロジーを作成すると、ユーザーの情報スペースに新しいドキュメントを追加するのがはるかに簡単になります。 その後、元のオントロジーの保存を考慮して、サーバーと比較されます。
検討中のサブジェクトエリア「経済」の例を使用すると、ユーザーファイルからサブジェクトエリアのオントロジーノードを形成するための普遍的な方法論があるという仮定で言うことができます。 一般に、オントロジーの形成はいくつかの段階で実行されます。

• オントロジーの範囲と範囲の決定

オントロジーを作成する前に、その範囲と規模を決定する必要があります。このため、いくつかの質問に答える必要があります。

• オントロジーはどの領域をカバーしますか？
• オントロジーは何に使用されますか？
• オントロジーの情報はどのような質問に答えるべきですか？

これらの質問に対する回答は、オントロジーの設計プロセス中に変更される場合がありますが、どの時点でも、モデルの規模を制限するのに役立ちます。

• 既存のオントロジーの再利用を検討する

オントロジーソースサーバーを使用または改善および拡張する可能性があるかどうかを確認する必要があります

• オントロジーの重要な用語のリスト

オントロジーの主な用語とそのプロパティのリストを作成すると便利です。

• クラスとクラス階層の定義

クラス階層を開発するためのいくつかの可能なアプローチがあります。

• トップダウン開発のプロセスは、サブジェクト領域の最も一般的な概念を定義し、その後に概念を指定することから始まります。
• ボトムアップ開発のプロセスは、最も具体的なクラスの定義である階層のリーフから始まり、これらのクラスをより一般的な概念にグループ化します。
• 統合された開発プロセスは、トップダウンアプローチとボトムアップアプローチの組み合わせです。まず、より目に見える概念を定義し、次にそれらを一般化し、それに応じて制限します。
• ただし、どちらのアプローチを選択した場合でも、オントロジークラスを定義することから始める必要があります

• クラスプロパティ（スロット）の定義

クラス自体はサブジェクト領域に関する十分な情報を提供しません。クラスを定義した後、概念の内部構造を記述する必要があります。

オントロジーでは、いくつかのタイプのオブジェクトプロパティがスロットになります。

• オブジェクトの内部プロパティ
• オブジェクトの外部プロパティ
• パーツ、オブジェクトに構造がある場合（物理パーツと抽象パーツの両方が可能）
• 他の個々の概念との関係

スロットは、このプロパティを持つことができる階層内の最も一般的なクラスに結び付けられている必要があります。

• ファセットスロットの定義

スロットには、値のタイプ、許容値、値の数（電力）、およびスロットが受け入れることができる値のその他のプロパティを記述するさまざまなファセットを含めることができます。

一般的なファセットは次のとおりです。

• スロットパワー

スロットの能力によって、スロットが持つことができる値の数が決まります。 一部のシステムでは、単位電力（1つの値のみが可能）と複数の電力（任意の数の値が可能）のみが区別されます。

• スロット値タイプ

値タイプファセットは、スロットに入力できる値タイプを示します。 最も一般的なタイプの値のリストは次のとおりです。文字列、数値、ブール型スロット、番号付きスロット、インスタンススロット（インスタンス間の関係を説明します）

• スロットドメインとその値の範囲

スロットが接続されているクラス、またはスロットがプロパティを記述するクラスは、スロットのドメインと呼ばれます。 スロットをクラスにバインドするシステムでは、スロットドメインは通常、スロットがバインドされているクラスで構成されます。 スロットドメインとスロット値の範囲を決定するための基本的なルールは互いに似ています。

スロットのドメインまたは値の範囲を定義する場合、最も一般的なクラス、またはドメインまたはスロットの値の範囲になり得るクラスをそれぞれ見つけます。

一方、あまりにも一般的なドメインと値の範囲を定義しないでください。スロットドメイン内のすべてのクラスはスロットによって記述される必要があり、スロット値の範囲内のすべてのクラスのインスタンスは潜在的なスロットプレースホルダーでなければなりません。 また、値の範囲に対してあまり一般的なクラスを選択しないでください。

• インスタンスを作成する

最後のステップは、階層内のクラスの個別のインスタンスを作成することです。 クラスの個々のインスタンスを決定するには、（1）クラスを選択し、（2）このクラスの個別のインスタンスを作成し、（3）スロットの値を入力する必要があります。

オントロジーの形成後、それらをサーバー部分と比較して、重複、相互の強化、および相互の補充などを削除する必要があります。 また、オントロジーマッピングを使用すると、ユーザーの情報スペースでの全文検索を回避できます。

システムのオントロジーは、サブジェクトエリアとユーザードキュメントだけでなく、ユーザーの検索クエリも表示します。 オントロジーとして各検索クエリを考慮することは、オントロジーを比較するための方法論を使用して、クエリ定式化が拡張されたときに、実際の検索結果と必要な情報の間の高レベルの対応を実現するのに役立ちます。 これは、「回答」（データシステムで利用可能）からではなく、「質問」（理解しようとする試み：ユーザーが正確に何を見つける必要があるか）から始まる、検索を扱うためのアプローチです。 このアプローチを使用すると、具体化、検索結果の精度、および拡張検索クエリの間に直接比例関係が確立されます：ユーザーが必要なものをより完全に記述するほど、オントロジーがより完全にコンパイルされ、オントロジーのマッチングメカニズムがより正確に機能し、より定性的な出力が得られます提供されます。

簡単に説明すると、オントロジーを比較する方法は次のように説明できます。

• ドメインオントロジーの用語とクエリT（O）= T（O_s）∩T（O_q）の共通部分が構築されます
• この交点が空でない場合、T（O）からの各項に対して、2つのセットT_sおよびT_qが構築されます-関係によって各オントロジーでそれに接続される項
• T（O）の各項について、集合T_sとT_qの共通部分が構築されます。
• T（O）からの項と、セットT_sとT_qの共通部分との間の関係のタイプの分析。 （すべてのオントロジー関係は、階層、同義語、その他の3つのタイプに分けられます）。
• オントロジーの類似性係数が構築されます。これは、2つのオントロジーのセマンティクスの類似性を定量的に反映したものです。 次の要因が考慮されます。両方のオントロジーで同じ用語が出現する。 2つの用語が同じ点で異なるオントロジーにあること。 2つの用語が同じタイプまたは異なる関係（たとえば、階層関係と同義語との関係）で異なるオントロジーにあるという事実。 同じ用語の間に何らかの関係（直接または間接）がありますか。

ユーザーの情報スペースの詳細の最低レベル（オントロジー）と高レベル（タグマップ）を互いに接続する必要があります。 これは、サブジェクトエリアのセマンティックネットワークを作成し、絶えず拡張することで実現できます。 セマンティックネットワークは、頂点がシステムオブジェクト（タグとオントロジー）に対応し、アークがそれらの間の関係を定義する有向グラフのように見える情報モデルとして理解されます。
セマンティックネットワークは、オントロジー間の接続の役割を果たします-ハイパーリンクのように、それらを指すファイルとタグですが、より複雑な構造で、システムの「トランスポート」になります。 サーバー側はユーザー文書の場所と構造に関する情報を必要としないため、クライアント側に保存されます。 このテクノロジーにより、タグマップ上の任意のゾーンからタグを選択したユーザーは、このタグ、オントロジーデータ、およびこのオントロジーに関連付けられたソースドキュメントファイルに関する情報を受け取ります。 そして、複雑な構造を作成する機能のおかげで、ユーザーはドキュメントファイルに加えて、このドキュメントに関連付けられたオントロジー、タグマップ上のタグと領域、結果に関連するドキュメントなどのカスタム量の周辺（資格）情報を取得できます。

上記の原則とアルゴリズムに従って動作するシステムは、十分に大きい必要があります
主要コンポーネントのクライアント/サーバーアーキテクチャのおかげで、処理能力、拡張されたスケーラビリティ、セキュリティ、および拡張と進化の可能性があります。 これにより、ユーザー情報スペースの分類、パーソナライズ、要約、および視覚化が可能になり、最終的には情報アクティビティ全体の品質に有益な影響を与え、ユーザーの情報スペースのサブジェクト領域の詳細なオントロジーを開発します。

参考文献 ：

1. Gladun A.Ya.、Nesen M.V.、Shtonda V.N. インテリジェントネットワークプラットフォームに基づくインテリジェントエージェントベースのサービス//コンピューター設備、ネットワーク、システム、2004年、第6号、p。 112-122。
2. Gladun A.Ya、Rogshinna Yu.V.、Shtonda V.N. インテリジェントネットワークにおけるWebサービスのオントロジー分析//国際会議「Knowledge-Dialogue-Solutions」2007。
3.デボラL.M.、ナタリアF.N. オントロジー開発101：最初のオントロジー作成ガイド//スタンフォードナレッジシステムズラボテクニカルレポートKSL-01-05およびスタンフォードメディカルインフォマティクステクニカルレポートSMI-2001-0880、2001年3月。
4. Kleschev A.S.、Artemyeva I.L. ドメインオントロジー間の関係。 パート1. //情報分析、問題1、C.2、2002。-C.4-9。