JP4852288B2 - ピアツーピア情報交換における意味相互運用性のための自己組織化方法 - Google Patents

Description

本発明は、ピアツーピアネットワークにおける情報交換の分野に関する。詳しくは、本発明は、ピアツーピアネットワークにおいて情報を交換するピアの間での意味相互運用性を促進する方法及びシステムに関連する。

情報システムは、データのコレクション及び場合によっては、何らかの概念スキーマに基づいて構造化されたメタデータの集合を含む。この明細書では、「メタデータ」という用語を広義に使用し、この用語の意味には、情報の出所に関するデータ、例えば、作者、アーチスト、作成日時、ジャンル、作成国等が含まれ、これらは、多くの場合、事前情報がなくては判定できない。更に、メタデータには、関連するコンテンツ自体を記述するデータ（予備的な知識がなくても判定することができる。）も含まれ、このようなデータとしては、例えば、以下のようなデータがある。
・楽曲に関しては、その楽曲のテンポ、ピッチ、パーカッション性（percussivity）等を記述するメタデータがある。
・映画については、その映画が主として屋内で撮影されているか、野外で撮影されているか、都市の光景を含んでいるか、自然な景観を含んでいるか等を記述するメタデータがある。
・文書については、そのキーワード（統計的解析によって判定できる）等を記述するメタデータがある。
・画像については、色ヒストグラム、画像が合成画像であるか写真であるかを示す情報、オブジェクトに由来するデータ、画像における形状検出／認識等を記述するメタデータがある。

この他にもコンテンツの種類に応じて様々なメタデータがある。

データ及びメタデータは、いずれも、いつでも新たなデータを追加し、又は削除できるという意味で、無制限（open-ended）であると言える。システムは、外部ソースから新たなメタデータにアクセスでき、例えば、ウェブサービス等として利用可能な信号処理アルゴリズムによってテンポを算出できる。

ユーザインタラクション性を実現するために、情報システムにより、ユーザは、通常、ユーザ自身が命名した範疇に基づいて、概念階層的に（taxonomically）にデータを構造化でき、これによりユーザは、これらの名称の用いてアイテムを検索することができる。情報システムの典型的な具体例を以下に示す。
・ブックマークフォルダ内に組織化されたユーザの「お気に入り」のウェブページ。この場合、データは、ウェブページに対応するＵＲＬからなり、概念階層は、ユーザがウェブページを検索するためにブラウズできる命名されたフォルダの階層である。概念階層（taxonomy）は、ユーザによるウェブページの範疇化を暗示的に定義している。
・一連の命名された階層的なプレーリストとして構成されている、ユーザによって維持される一組の音楽ファイル。
・ユーザの特定の興味に基づいて組織化された一組の画像。例えば、病理に沿って組織化された一連の医療画像、又は時代、ジャンル及び画家に沿って構成された一連の絵画。
・特定の研究テーマに沿って構成された一組の科学論文。

情報システムのオーナとも呼ばれる人間のユーザは、情報システムにデータを追加し、概念階層の形式でデータを構造化し、概念階層のノードに名称を与えることによって自らの情報システムを制御する。なお、これらの概念階層によって暗示されるユーザによる範疇化は、他のユーザ又は情報システムがアクセスできない個人の認知過程に基づいている。例えば、ユーザは、ユーザが好きな全ての曲を１つのフォルダに入れ、好きではない他の曲を別のフォルダに入れると決めることができる。この範疇化判断は、完全に主観的であり、マシンがこれを自動化又はエミュレートすることはできない。

ユーザによって作成及び維持された概念階層を、ここでは「オーナ概念階層」と呼ぶ。この概念階層で用いられる名称（単語又はフレーズであってもよい。）は、オーナ名である。概念階層は、範疇化の特定の手法（オーナによる直感的なレベルでしか知ることができない場合もある。）を含意し、これを、ユーザオントロジーと呼ぶ（図１参照）。ユーザオントロジーは、概念階層内で暗示的に含意されているが、これ以外の手法で知ることはできない。また、図１は、情報システムがある特定の概念的スキーマに基づいて組織化されたメタデータを用いる状況を示している。

ピアツーピア情報システムは、このような情報システムのコレクションからなる。各情報システムは、異なるユーザによって所有及び維持され、他の情報システムから独立して機能すると仮定される。通常、各情報システムは、ユーザが所有するコンピュータシステムに含まれ、ユーザは、コンピュータシステムにおいて実行されるアプリケーションソフトウェア（例えば、情報システムのデータ集合をブラウズするためのアプリケーションソフトウェア）に関連するインタフェースを用いて情報システムとインタラクトできる。

ピアツーピア情報システムの定義の特徴は、各ピア間で、中央サーバを介する必要なく、直接情報交換が可能であるという点である。ピアツーピア情報システムの具体例としては、例えば、現在、多くの人々によって既に用いられているナップスター（Napster）又はグヌーテラ（Gnutella）等のピアツーピア音楽ファイル共有システムがある。映画又はゲームソフトのための同様の共有ネットワークも普及している。科学的データ又は教材の分野でも、ピアツーピア共有システムのネットワークが広まりつつある。

ピアツーピア情報システムにおいては、１つの情報システムのオーナは、追加的データを得るために、他の情報システムに対して直接クエリを発する。クエリを発するピアの情報システムは、クライアントと呼ばれ、情報を提供する情報システムは、サーバと呼ばれる。具体例を以下に示す。
・ウェブユーザが、興味がある可能性があるウェブページを見つけるために、他のユーザのブックマークフォルダを問い合わせる。
・ユーザが、ユーザにとって、興味がある可能性がある楽曲を見つけるために他のユーザのプレーリストを問い合わせる。
・ユーザが、ユーザ自身の興味に関連する画像を見つけるために他のユーザの画像データベースを問い合わせる。
・研究中の研究題目の１つに関連する論文を探しているユーザが、他のユーザによって保存されている論文の組を問い合わせる。

ピアツーピア情報システムでは、如何なるノードもクライアント又はサーバとして動作することができる。なお、ユーザは、各オーナが自らのデータを組織化した概念階層を介して通信する。

ピアの間の情報交換は、サーバにデータを要求するためのクエリを発するクライアントの具体例に制限されない。ユーザは、（例えば、データを他のユーザに提供することを前提として）他のピアに対して、ユーザ自身の情報システムのデータを公表する告知を発してもよい。この場合も、ユーザは、告知を定式化する際に、ユーザ自身の概念階層を使用する。

ピアツーピア情報交換には、２つの主要な問題がある。第１の問題は、一方のピア（クライアント）の概念階層で用いられるデータ及び名称が、他のピア（サーバ）によって用いられるデータ及び名称とは通常異なり、したがって、クライアントのオーナは、クエリをどのように定式化するかがわからず、また、サーバのオーナ又はサーバ自体は、クエリがその（サーバの）概念階層に基づいて定式化されていなければ、どのように応答していいかがわからないという問題である。これは、現在動作しているピアツーピアシステムのユーザにとって、現実的な問題である。例えば、音楽ファイル共有ネットワークにおいて、ユーザは、データのタイトルやフォルダ及びサブフォルダに与えられた名称の意味を推測しなくてはならない。

第２の問題は、特に、メタデータがそれ自体無制限の場合、各情報システムにおいて、データ及びメタデータを保存するために用いられる概念的なスキーマは、互いに大きく異なる可能性があるという問題である。例えば、異なる言語の使用等の単純な不一致も問題となり得る。例えば、クライアントがメタデータ「country(Belgium)」を有し、サーバがメタデータ「pays(Belgique)」を有している場合もある。意味的な知識がなければ、情報システムは、これらの２つのメタデータをどのように互いにマッピングするかを知ることができず、したがって、クライアントは、自らのメタデータを用いて、サーバへのクエリを定式化することができない。

これらの問題は、いずれも、所謂「意味相互運用性（semantic interoperability）」問題の具体例である。

意味相互運用性の１つの解決策は、標準化である。すなわち、ピアツーピアネットワークの異なるユーザが、同じ概念階層を用いてデータを構造化すること及びデータ及びメタデータのために同じ概念的なスキーマを用いることを予め同意すればよい。これにより、概念階層のオーナ名は、ピア間の共有された通信プロトコルとして機能できる。例えば、全てのユーザが、データの組織化のためにヤフー（Yahoo）の概念階層を用い、ヤフーによって用いられている名称（他言語への翻訳を行ってもよい。）を採用することに同意すればよい。

しかしながら、このような標準化方式は、音楽ファイル共有、医療画像又は科学論文等の絶えず変化する分野における真の無制限（オープンエンド）のピアツーピアネットワークにおいては、良好に機能しない。これらの分野では、新たなトピック及び新たな種類のデータが次々と登場し、スタイルは、移行し、ユーザの興味は、様々に分岐する。また、旧式のシステムをピアツーピアネットワークに参加させる必要がある場合もある。静的なオントロジーによってこれらの全てを一度に捕捉することは困難である。

これに代えて、各ピアがそれ自身のローカルな概念階層及びそれ自身の概念的スキーマを有し、これらを包括的なオントロジー及び概念的スキーマに翻訳し、ピア間の中間言語としてこれらを用いてクエリ及び情報交換を行うこともできる。この翻訳は、できるだけ多くの概念階層の名称のセマンティクスの定義に基づいて行うことができる。例えば、ユーザが自らの音楽ファイルシステムに、ビートルズの曲のサブフォルダを有する場合、暗示された範疇のセマンティクスは、メタデータ「performed-by(TheBeatles)」を介したクエリに翻訳される。そして、このクエリは、（例えば、仲介処理による翻訳の後に）ピアのメタデータを介したクエリに用いることができる。

これは、現在、ウェブ情報システムに関して、セマンティックウェブ（Semantic Web）（「"The Semantic Web" by T. Berners-Lee and J. Hendler, Scientific American, May 2001」参照）が提唱している方式であり、より一般には、例えば、ＣＹＣ又はＷｏｒｄｎｅｔ（「"CYC, Wordnet and EDR - critiques and responses - discussion" by D. Lenat et al, Comm.of the ACM 38 (11), Nov.1995, pp. 45-48 at http://www.acm.org/pubs/articles/journals/cacm/1995-38-11/p24-lenat/p45-lenat.pdf」参照）が提唱する「普遍的な」オントロジー（"universal" ontologies）によって開発されている方式である。共通のオントロジー、これらのオントロジーを定義するためのサポートシステム、ローカルなスキーマをグローバルなスキーマにマッピングするための手法、情報検索でオントロジーを用いるメカニズム、すなわち、データに範疇をマッピングするためのメカニズムの開発には、多大な労力が払われている。しかしながら、これらの手法には、以下のように、幾つかの大きな短所があるという懐疑的な意見も多い。
・普遍的なオントロジーに依存するセマンティックウェブは、単に、意味相互運用性の問題を他のレベルに転嫁しているだけである。このレベルでは、結局、普遍的なオントロジーに基づく規格化が必要になる。現在、情報システムが用いられているは、人間の活動のあらゆる分野で、規格に関する世界的な合意が得られ、これを強要できるようになることは、想像し難い。限定された分野においてさえも、相互接続された包括的な世界が絶えず拡張しているため、これは困難である。
・人間の活動及びこれらのために構築される情報システムは、オープンシステムである。これらは、固定的に決定することはできず、常に新たなニーズに適合させなければならない。
・ピアツーピア情報システムは、分散型システムである。このシステムには、中央制御局はなく、したがって、集中的な制御は不可能である。
・多くの情報システムが既に存在しており、これらをピアツーピアネットワークに参加させることができる手法を見出さなくてはならない。

本発明者らは、意味相互運用性を実現する新たな手法を開発し、これにより、情報システムは、コンポーネントによって拡張され、ピアは、データ世界及び人間のユーザの世界とのインタラクションにおいて、自らの通信プロトコルを開発及び折衝できる。これにより、エージェントは、それぞれがローカルで解釈できる中間言語を自律的に作成する。この合意は、人間の自然言語と同様に、創発的であり、適応型であり、ローカルなものである。

本発明で用いる手法は、ロボット対ロボット及びロボット対人間の通信のための言語ゲームに関する近年の研究に由来する技術（国際公開公報ＷＯ９８／２６３６８参照）を採用したＳＡＳＩ（意味相互運用性への自己組織化方式：Self-organisation Approach to Semantic Inter-operability）に基づくものであるが、本発明の目的に適用可能にするために、これらの技術を拡張及び変更している。

本発明では、意味相互運用性は、世界と、情報システムと、人間のユーザとの間の協調の問題とみなされる。ここでは、特定の種類の「記号論的力学（semiotic dynamic）」を定義し、ピアツーピア通信で用いられるラベルと、エージェントがこれらのラベルを解釈するために用いる範疇の両方をピアツーピア情報交換の副次的効果として、整合させる。情報交換で用いられるラベル及びラベルの意味は、創発的であり、各ピアにおいてメタデータのために用いられる概念的なスキーマは、ローカルであり（他のピアによって用いられているスキーマから独立しており）、拡張可能である。

エージェントのインタラクションを介して、一種の中間言語が出現する。この中間言語は、固定されず、ピアのグループ間で、ローカルに特化することができる。各エージェントのオントロジーを定義する範疇は、純粋に、ローカルなメタデータに関して定義され、したがって、これらは一定ではない。

本発明は、ピアツーピアネットワークを介して情報を交換できる他の情報システムとの意味相互運用性を実現する、特許請求の範囲に開示する情報システムを提供する。

更に、本発明は、このような情報システムで用いられる情報交換方法を提供する。

更に、本発明は、特許請求の範囲に開示する、意味相互運用性を成長させるクライアントモード又はサーバモードで動作可能な情報システムを備えるピアツーピア情報交換ネットワークを提供する。

更に、本発明は、特許請求の範囲に開示する、情報システムの間で情報を交換するピアツーピアネットワークにおける情報交換の管理方法を提供する。

本発明の更なる特徴及び利点は、図面を参照した以下の好適な実施形態の説明により明らかとなる。

まず、本発明の好適な実施形態に基づくＳＡＳＩ方式の基礎となるメカニズムについて、図２及び３を参照して説明する。

本発明の好適な実施形態では、ピアツーピア情報交換で用いられる情報システムに、情報エージェント（information agent：ＩＡ）と呼ばれる更なるコンポーネントを設ける。このエージェントは、ピア間のインタラクションを調整する役割を果たす。情報エージェントは、多くの場合、ソフトウェアによって実現される。情報エージェントをどのように実現するかの詳細は、本発明の理解には関係せず、エージェントによって実行される機能に関する以下の説明に基づき、当業者は、様々な手法で情報エージェントを実現できる。したがって、この点に関する詳細は、ここでは説明しない。

まず、幾つかの形式的な定義について説明する。

定義：
本発明の好適な実施形態では、３つのタプルからなるピア情報システムＰＩを利用する。
ＰＩ＝＜ＩＳ，Ｏ，ＩＡ＞
・ＩＳ＝＜Ｄ，ＭＤ，Ｌ，Ｍ＞は、データＤの集合、メタデータＭＤの集合、名称Ｌの集合、及び列挙（enumeration）によってＤの下位集合に名称をマッピングする概念階層Ｍ：Ｌ→ρ（Ｄ）からなる情報システムである（ρ（Ｄ）は、Ｄのベキ集合であり、すなわち、Ｄの全ての下位集合の集合である）。情報システムは、同じデータについて複数の概念階層を維持することもできる。名称及び概念階層は、情報システムのユーザオントロジーを暗示的に定義する。
・Ｏは、データを追加又は削除し、データを概念階層Ｍに組織化するという意味で情報システムを管理する（人間の）オーナを表す。オーナは、自らの情報システムに利用可能なメタデータへのアクセス又はこれに関する知識を必ずしも有していなくてもよい。
・ＩＡ＝＜Ｌ’，Ｍ’＞は、ラベルＬ’の集合及びラベルＬ’をＤの下位集合にマッピングする他の概念階層Ｍ’：Ｌ’→ρ（Ｄ）を定義する情報エージェントである。情報エージェントの概念階層は、列挙によっては定義されず、（後述するように）範疇の集合に基づいて定義される。

ピアツーピア情報ネットワークＮは、ピア情報システムの集合：Ｎ＝｛ＰＩ_１，・・・，ＰＩ_ｎ｝からなる。ここで、情報システムＰＩ_ｃ（クライアントとも呼ばれる）のオーナＯ_ｃが、他のユーザＯ_ｓが所有する他のピア情報システムＰＩ_ｓ（サーバ）から、クエリによって情報を得ようとしたとする。クエリを定式化する場合、人間のユーザは、自らがデータに課したローカルの概念階層Ｍを使用する。ピア間の通信は、それらの情報エージェントによって用いられるラベルＬ’_ｉに関して行われる。

ここで検討するピアツーピア情報ネットワークは、完全に無制限（オープンエンド）なものとする。すなわち、ＰＩのオーナは、新たなデータ、新たなメタデータ、新たなラベル又はＭの変更をいつでも、導入できる。新たなピア情報システムを追加し、又はトータルのネットワークから削除することができ、どのピアが、他のどのピアと通信できるかに関する制約は、全くない。

理想的な状況では、Ｎ内の全てのＰＩについて、Ｌ_ｉ＝Ｌ’_ｉ，Ｍ_ｉ＝Ｍ’_ｉが真であり、換言すれば、情報エージェントは、オーナがセットアップしたものと同じラベル及び同じマッピングを用い、ネットワーク内の全てのピア情報システム（Ｎ内の全てのＰＩ）が同じＬ及びＭを用いる。

∀ ｉ，ｊ ＰＩ_ｉ，ＰＩ_ｊ∈Ｐ→Ｌ_ｉ＝Ｌ_ｊ且つＭ_ｉ＝Ｍ_ｊ
これらの条件が実際に成立していれば、ピアツーピア情報交換は、容易に実現できる。クライアントは、クライアントが問い合わせている種類のデータの集合をＤ_ｌとし、（ｌ，Ｄ_ｌ）∈Ｍ_ｃとして、ラベルｌ∈Ｌ_ｃを送信することによってクエリを発行する。サーバは、自らのマッピングＭ_ｓを自らのデータ集合に適用した結果得られたデータにより応答する。ラベルｌを有するクエリは、サーバｓからＤの下位集合に等しい応答Ｒを呼び出す。すなわち、（ｌ，Ｒ）∈Ｍ_ｓとして、Ｒ＝｛ｄ_ｋ，・・・，ｄ_ｋ＋ｐ｝⊂Ｄ_ｓである。ここでは、オーナ及びエージェントの概念階層が同じであり、したがって、情報エージェントは、その役割を果たす必要がない。

例えば、クライアントが、「創発的セマンティクス（emergent semantics）」に関する論文の集合ｐ_１，・・・ｐ_ｎを有している場合、すなわち、Ｍ_ｃ（’ｅｍｅｒｇｅｎｔ−ｓｅｍａｎｔｉｃｓ’）＝｛ｐ_１，・・・，ｐ_ｎ｝である場合、同じトピックに関する更なる論文を得るために、クライアントは、サーバとして機能する他のピアに、ラベル「ｅｍｅｒｇｅｎｔ−ｓｅｍａｎｔｉｃｓ」を送信する。例えば、Ｍ_ｓ（’ｅｍｅｒｇｅｎｔ−ｓｅｍａｎｔｉｃｓ’）＝｛ｑ_１，・・・，ｑ_ｍ｝の場合、各ｑ_ｊは、応答として送信するための候補となる。

現実世界では、ネットワーク（Ｎ）内のピア情報システム（ＰＩ）のオーナは、多くの場合、互いに異なる名称Ｌ及びマッピングＭを使用する（また、通常、それらの情報システムは、それぞれ異なるスキーマに基づいて組織化されたメタデータを用いる）。この結果、クライアントＰＩ_ｃによって用いられる名称及びマッピングは、サーバＰＩ_ｓによって用いられる名称及びマッピングとは、必ずしも同じにはならない。本発明の好適な実施形態では、情報エージェントによって用いられるラベル及びマッピングは、それらのオーナによって用いられる名称及びマッピングと必ずしも同じではない。換言すれば、所定のＰＩ∈Ｎについて、Ｌ_ｉ≠Ｌ’_ｉ、Ｍ_ｉ≠Ｍ’_ｉの可能性がある。

本発明の好適な実施形態では、情報エージェントによって、通信に用いられるラベルについての折衝を行うと同時に、これらのラベルに関連する範疇のセマンティクスを調整する。換言すれば、全ての情報エージェントのラベルＬ’_ｉは、各エージェントが自らのマッピングＭ’_ｉを用いて情報システムのローカルデータ集合へのマッピングを行う「共有言語」になる。なお、これは、概念階層が基礎付けられた範疇、すなわち、データを下位集合にフィルタリングするためにメタデータに適用できる範疇を用いて実現されるという意味において、情報エージェントが人間のユーザと同様の認識的な能力を有することを意味する。なお、情報エージェントは、人間のユーザと全く同じではなく、任意にメタデータを利用しなくてはならない。

サーバによる所定の応答がクライアントのオーナに関連しているとみなされる場合、通信は、成功する。実際には、システムは、常に流動的であるので、共有は、常に部分的になる。更に、ピアのサブネットワーク内で多くの「サブ言語」が現れることを予想しなければならない。各サブ言語は、ピアのサブネットワークの興味を反映する。幾つかのアプリケーションでは、これらのサブネットワークは、「委託された共同体（trusted communities）」（情報システムのオーナが選択してもよい）に対応してもよい。

例えば、クライアント情報システムのオーナがサーバに要求する要素の種類の良い実例であると考えられるデータ要素の集合Ｇ_ｃ∈Ｄ_ｃを特定することによって、オーナが、クエリを開始したとする。オーナは、完全に自らの制御の下にあるオーナ概念階層のラベルを用いることによって又は他の手法を用いてユーザの情報システムのデータ集合の実例の下位集合を明示的に指定することによって、これを実行することができる。

例えば、オーナの情報システムが（例えば、インターネットを介して）音楽ファイルを交換できるピアツーピアネットワークに接続可能な、音楽ブラウザソフトウェアをロードしたパーソナルコンピュータである場合、オーナは、ポインティングデバイス（キーボード、マウス等）を用いて選択された実例を特定し、オーナが音楽ブラウザアプリケーションで定義したプレーリストを選択することができる。アプリケーションがどのように実現されているかの詳細に応じて、オーナがプレーリストを選択すると、類似する曲の検索が、ピアツーピアネットワーク上に送出され、又は検索を送出するために、オーナによる他の明示的な操作を要求してもよい。本発明では、ユーザの情報システムとインタラクトするためにオーナが用いることができるアプリケーションソフトウェア、インタフェース及びデバイスの詳細は、オーナが（必要であれば、ユーザ自身の概念階層に基づいて）ピアツーピアネットワークを介して、検索又は交換のためにどのデータを選択しているかを示すことができる限り、如何なるものであってもよい。

Ｇ_ｃとは区別される他のデータ要素（反例（counter-examples））からなる特定のコンテキストＫ_ｃ∈Ｄ_ｃ内において、オーナのクエリは、定式化できると仮定される。最も一般的な状況では、Ｋ_ｃ＝Ｄ_ｃ＼Ｇ_ｃである。

サーバは、データ要素の集合Ｒ⊂Ｄ_ｓによって応答し、クライアントのオーナは、ユーザが関連していると考えるＦ⊆Ｒのデータ要素を示すことによってフィードバックを行い、これにより、反例又は否定的実例Ｂ＝Ｒ＼Ｆを算出することができる。そして、クライアントのオーナの希望に応じて、「良い」データＦがクライアントのデータ集合に追加される。如何なるデータ要素も関連していない場合、又はサーバが如何なるデータも提供できない場合、通信は失敗し、情報エージェントは、本発明の好適な実施形態に基づき、後に詳細に説明するように、リペア動作を実行する。

システムの総合的な性能は、サーバからクライアントへの応答が成功した回数によって測定することができる。なお、クライアントのオーナは、対象となるアイテムの選択、要求を満たしたサーバからアイテムが受信されたか否かの判断、あるアイテムを保存するか否か、及びユーザ自身のオントロジーに基づいて、アイテムをどこに保存するかに関する決定の全てにおいて、極めて重要な役割を担う。人間のユーザの役割は、本発明にとって重要であり、これは、情報交換について、オーナが直接の影響を有さない創発的言語（emergent language）方式を利用した従来の提案とは大きく異なる点である。

情報エージェントがデータを構造化するために用いる概念階層Ｍ’を実現するために、エージェントがアクセスできるデータ又はメタデータについて機能する範疇Ｃの集合を各情報エージェントが維持すると仮定する。例えば、科学的論文は、アクセス可能なメタデータとして、著者、キーワード、発行媒体及び要約を有することができ、音楽ファイルは、関連するメタデータとして、作曲者、演奏者、録音日時等を有することができる。

エージェントの範疇の集合は、通常、情報システムのスタートアップ時には、すなわち、情報エージェントが他の情報システムと通信する前には、空集合である。情報エージェントは、互いに通信しながら、自らの範疇の集合を確立する。範疇は、データ要素がその範疇に属すか否かを決定する関数として演算可能化される。エージェントによって用いられる範疇の集合は、無制限であり、時間に依存し、異なるエージェントの範疇は、必ずしも同じである必要はない。

各エージェントは、コンテキスト（例えば、反例の集合）から、トピック（例えば、ユーザによって選択された実例の集合）を差別化しようとすることによって範疇を確立する。エージェントは、コンテキストからトピックを区別できる特徴又は特徴の集合を見つけようとする。例えば、特徴（＜ジャンル（ロックンロール）＞）のように、特徴は、多くの場合、属性（例えば、メタデータの特定のアイテム、例えば、保存された音楽ファイルの「ジャンル」）と、値（例えば、「ロックンロール」）とからなる。特徴又は特徴の集合は、トピックをコンテキストから区別できる場合、「弁別的である」。

トピック及びコンテキストデータを処理し、コンテキストとトピックとを区別する「範疇」（特徴又は特徴の集合）を決定する幾つかのよく知られた手法がある。本発明の好適な実施形態では、情報エージェントは、それらの範疇を決定するために、如何なる周知の技術を用いてもよい。

情報エージェントは、データ自体及び利用可能なメタデータのいずれか又は全てを用いて、範疇を決定することができる。メタデータは、予め存在していてもよく（例えば、関連データをロードするのと同時に情報システムにロードしてもよく、情報システムがアクセス可能なカタログ又はサーバ上に保存されていてもよい）、又は関連データの解析によって（情報システム内又はシステムと通信するデバイス内で）自動的に判定してもよい。

各情報エージェントは、エージェントラベルＬ’から範疇Ｃの集合への双方向マッピングＷを維持する。また、このマッピングは、エージェントの辞書又はレキシコンとも呼ばれる。範疇及びラベルの間の各関係は、所定の強度γ⊆［０．０，１．０］を有し、これは、情報エージェントが過去にこの関係を用いて到達した成功を反映している（後により正確に定義する）。（符号化において）同じ範疇について２つ以上のラベルがある場合、又は（復号においての）同じラベルについて２つ以上の範疇がある場合、エージェントは、最も強い強度を有する関係を用いるとよい。

これらの考察は、以下のような、充実された定義の集合に反映される。
時間ｔにおけるピア情報システムａは、以下のように定義される。
ＰＩ_ａ，ｔ＝＜ＩＳ_ａ，ｔ，Ｏ，ＩＡ_ａ，ｔ＞
ここで、
・ＩＳ_ａ，ｔ＝＜Ｄ_ａ，ｔ，ＭＤ_ａ，ｔ，Ｌ_ａ，ｔ，Ｍ_ａ，ｔ＞は、データＤの集合、メタデータＭＤの集合、名称Ｌの集合、拡張された定義によってＤの下位集合に名称をマッピングするマッピングＭ：Ｌ→Ｐ（Ｄ）からなる情報システムである。
・Ｏは、情報システムの（人間の）オーナである。
・ＩＡ_ａ，ｔ＝＜Ｌ’_ａ，ｔ，Ｃ_ａ，ｔ，Ｍ’_ａ，ｔ，Ｗ_ａ，ｔ＞は、ラベルＬ’の集合、範疇の集合Ｃ：Ｐ（ＭＤ）→Ｐ（Ｄ）及びＷ＝Ｃ×Ｌ’×［０．０，１．０］を有する情報エージェントである。この範疇は、概念階層Ｍ’を実現する。

時間ｔにおけるピアツーピア情報ネットワークは、いつでも要素を追加又は削除できる集合：Ｎ_ｔ＝｛ＰＩ_ａ１，ｔ，・・・ＰＩ_ａｎ，ｔ｝として定義される。

この設計の最終的な目的は、情報交換における成功を最適化することである。本発明の好適な実施形態は、情報エージェントａが範疇集合Ｃ_ａを開発及び使用し、他のエージェントと協働して、これをラベルＬ’_ａの集合に関連付けるためのメソッドを定義する。実際の解決策は、次のような幾つかの更なる制約条件を満たさなければならない。（１）クライアントは、サーバの内部状態にアクセスできず、これを変更することもできない。（２）ピアの間のインタラクションは、純粋にローカルである。（３）各ピアがいつでも変化できるという意味において、ピアは自律的である。（４）ピアは、分散され、包括的な同期はなく、ピアは、平行して動作できる。（５）人間のオーナは、情報エージェントの内部状態を調べる必要がなく、また、これを変更することができない。

図３に、この明細書の残りの部分で詳細に説明する処理にかかわる異なるエンティティ、情報アイテム及びマッピングを要約して示す。図３において、Ｌは、情報エージェントのレキシコンを示す。

静的なシステム（Static System）
説明を明瞭にするために、まず、「静的な」システムのために情報エージェントが用いるプロトコルの詳細を示す。すなわち、ここでは、情報エージェントがピアツーピア情報交換を実現するために必要な範疇及び交換ラベルを有することを仮定する。次に、システムを「動的な」システム（すなわち、情報エージェントが適応的にそれらの範疇及びラベルを定義するシステム）にするための必要な拡張を考慮して、説明を続ける。

図４に、静的なシステムで用いられるプロトコルを示す。これは、クライアントがサーバにクエリを発する特定のピアツーピアトランザクションの間に生じる処理を示している。

なお、ピア間のトランザクションを示すために用いる各図においては、左側は、クライアント側の動作を示し、右側は、サーバ側の動作を示す。これらの図の中央には、クライアントとサーバとの間で交換されるアイテムを示している。

なお、図４に示す「静的システム」のトランザクションでは、クライアントのオーナは、自ら、初期のターゲット集合Ｇ_ｃ及びコンテキストＫ_ｃを選択し、応答Ｒのどの下位集合が関連しているかを判定し、及びユーザ自身の情報システムの部分としてこれを保存するべきであるかを決定する。

図４に示すインタラクションを実現するためには、範疇化（クライアントステップ２）、フィルタリング（サーバステップ２）、符号化（クライアントステップ３）、復号（サーバステップ１）といった４つの機能の定義が必要である。

本発明は、例えば、科学論文、お勧めのウェブサイト、映画、画像、音楽等に関連するクエリ（又はオファー）を始めとするピア間での異なる種類の情報交換に適用可能である。特定のクエリに関する包括的なコンテキストは、例えば、クライアントとサーバの間の以前のインタラクションに基づいて、ピアツーピアネットワーク（例えば、音楽ファイル交換専用のネットワークであってもよい）自体の性質に基づいて等、暗示的に判定してもよく、或いは、例えば、クエリの統語構造に基づいて明示的に判定してもよい。

クライアントのクエリの特定のコンテキストＫ_ｃは、先のインタラクションによって暗示的に判定してもよく、可能なオブジェクトの総合的な集合：Ｋ_ｃ＝Ｄ_ｃに等しいデフォルトとしてもよい。同様にサーバがＫ_ｓを処理するコンテキストは、先のインタラクションによって暗示的に判定してもよく、サーバのデータ要素の総合的な集合：Ｋ_ｓ＝Ｄ_ｓに等しいデフォルトとしてもよい。また、クライアントは、ターゲット集合（良い実例：good examples）と共にコンテキストを特定するデータ（悪い実例：bad examples）を送信してもよい。コンテキスト判定のためのメソッドは、特定のアプリケーション及びユーザの情報システムとユーザのインタラクションの履歴に依存する。

なお、クライアントがサーバに実例及び／又は反例を送る場合、如何なる周知の手法で実例／反例を送信してもよい。例えば、オンラインカタログにおいて、実例／反例を特定するコードを送信してもよく、実例／反例に対応するＭＰ３ファイルを送信する等してもよい。

範疇化及びフィルタリング
ピアツーピア情報交換の自己組織化では、各情報エージェントがデータの集合Ｇのメンバを他の集合Ｋから区別することができる必要がある。データ集合は、いつでも変化できるので、この区別に用いられる範疇の集合も、これに応じて適応化する必要がある。

実例のターゲット集合をＧとし、Ｇの要素と区別する必要があるコンテキストをＫとする。更に、ｃ_ｉ∈Ｃを、データ要素ｄが与えられると、ｃ_ｉによって定義される範疇にｄが属するか否かに基づいて１又は０を返す関数として定義する。ｃ_ｉが真となる集合Ｓ内の要素のパーセンテージφ（Ｓ，ｃ_ｉ）は、以下のように表される。

所定のＧ及びＫについて、範疇ｃ_ｉの弁別的な成功ｄｉｓｃは、以下のように定義することができる。
ｄｉｓｃ（Ｇ，Ｋ，ｃ_ｉ）＝φ（Ｇ，ｃ_ｉ）−φ（Ｋ，ｃ_ｉ）
範疇ｃ_ｉ∈Ｃ_ａ，ｔは、以下のように、弁別的な成功に基づいて降順に並べ替えることができる。
［＜ｃ_１，ｐ_１＞，・・・，＜ｃ_ｍ，ｐ_ｍ＞］
ここで、ｃ_ｉ∈Ｃ且つｐ_ｉ＝ｄｉｓｃ（Ｔ，Ｇ，ｃ_ｉ）且つｐ_ｉ，ｐ_ｉ＋１→ｐ_ｉ≧ｐ_ｉ＋１である。

明らかに、ｃ_ｉがＫの要素からＧの要素を良く区別する程、ｄｉｓｃ（Ｇ，Ｋ，ｃ_ｉ）が大きくなり、したがって、上のシーケンスの第１の要素は、最も弁別的な範疇に対応する。したがって、所定の範疇の集合Ｃについて、コンテキストＫから選択されたトピックＧを分類する関数は、以下のように表すことができる。
ｃａｔｅｇｏｒｉｚｅ（Ｃ，Ｇ，Ｋ）＝ｆｉｒｓｔ（［＜ｃ_１，ｐ_１＞，・・・，（ｃ_ｍ，ｐ_ｍ＞］）

複数の範疇ｃ_ｉ，・・・，ｃ_ｎが最大の弁別的能力を有する場合、すなわち、ｐ_ｉ＝・・・＝ｐ_ｎ且つｐ_ｉ，・・・，ｐ_ｎ＞ｐ_ｊの場合、情報エージェントは、更なる発見的手法を用いてＧのための範疇を選択してもよい。例えば、情報エージェントは、他のエージェントとの先の交換において用いて、最も成功した範疇を選択しても良い。（例えば、閾値レベルθ_ｄｉｓｃに比べて）最も良い範疇ｃ_ｉの弁別能力が不十分である場合（すなわち、ｐ_ｉ＜θ_ｄｉｓｃである場合）、エージェントは、既存の範疇を再利用することに優先して、新たな範疇の作成を試みる。

範疇は、どの要素がそれを満たすかを選択するためのフィルタとして用いることができる。
ｆｉｌｔｅｒ（Ｄ，ｃ）＝｛ｄ_ｉ｜ｄ_ｉ∈Ｄ且つｃ（ｄ_ｉ）＝１｝

１つの情報エージェントの範疇は、他のエージェントの範疇とは、完全に異なることがあり、エージェントにとって完全にローカルなものであると仮定される。情報システムのオーナは、情報エージェントの範疇を直接見ることはできず、情報エージェントの範疇は、実際、オーナがデータに課した概念階層とは大きく異なることもある。エージェントによって用いられている名称を人間のオーナが変更できないようにシステムを設計することが望ましい。これは、中間言語の成長に有害である可能性がある人間の干渉を避け、更に、中間言語を（使用不能になるように）操作しようとするハッカーによる悪意の侵入の危険を避けるためにも重要である。

範疇は、如何なる種類のデータ、メタデータ又は範疇を算出するために利用可能な追加的リソースを利用してもよい。また、範疇は、０又は１を返すのではなく、よりファジーであってもよく、フィルタ関数において、更に低い閾値を用いてもよい。当業者は、範疇化器を実現するための、及び新たな範疇を構築するための多くの異なる手法を想到できる。本発明は、範疇化器を実現し又は新たな範疇を構築するための特定の手法には制限されない。

また、単一の範疇に代えて、（範疇の数を最小化し、メタデータとして必要な属性の数を低減する）複合的な範疇を用いることを想到することも容易である。

符号化及び復号
次の問題は、エージェントが範疇をラベル：Ｗ＝Ｃ×Ｌ’×［０．０，１．０］に関連付けることができると仮定して、ピアツーピア交換のために用いるラベルをエージェントがどのように符号化し、復号するかという問題である。

範疇ｃを表現する必要があると仮定すると、エージェントは、以下のように、ｃとラベルｌとの間の関係の強度γに基づいて、可能なラベルのリストを順序集合として構築することができる。
ｌａｂｅｌｓ（ｃ，Ｗ）＝［＜ｌ_１，γ_１＞，・・・，＜ｌ_ｎ，γ_ｎ＞］
ここで、＜ｃ，ｌ_ｉ，γ_ｉ＞∈Ｗ且つγ_ｉ≧γ_ｉ＋１である。

符号化されたラベルは、この順序集合の第１のエントリである。
ｃｏｄｅ（ｃ，Ｗ）＝ｆｉｒｓｔ（ｌａｂｅｌｓ（ｃ，Ｗ））
逆に、ラベルｌが与えられたとすると、情報エージェントは、以下のように、ｌと範疇ｃとの間の関係の強度γに基づいて、可能な範疇のリストを順序集合として構築することができる。
ｃａｔ_ｓ（ｌ，Ｗ）＝（［＜ｃ_１，γ_１＞，・・・，＜ｃ_ｎ，γ_ｎ＞］）
ここで、＜ｃ_ｉ，ｌ，γ_ｉ＞∈Ｗ且つγ_ｉ≧γ_ｉ＋１である。
復号された範疇は、この順序集合の第１のエントリである：
ｄｅｃｏｄｅ（ｌ，Ｗ）＝ｆｉｒｓｔ（ｃａｔ_ｓ（ｌ，Ｗ））
この処理は、範疇の結合（すなわち、集合）の符号化又は復号に容易に拡張することができる。

レキシコンＷは、範疇の集合を単語に関連付けることができる。符号化では、弁別から生じた範疇の集合をカバーする最小数の単語を検索し、復号では、各単語に関連している最小数の範疇を再構築する必要がある。

動的なシステム（Dynamic System）
以下、クライアント及びサーバエージェントが、通信における失敗に対処するために、及び将来の成功率を高めるようにそれらの内部状態を適応化するためにそれらのインベントリ（inventories）（Ｌ’，Ｗ，Ｃ）を変更するメカニズムについて説明する。

本発明の好適な実施形態において実現される１つの主要な発想は、人間のコミュニケーションにおいて対象を指す場合と同様に、情報交換における失敗を修正する手法としてデータ要素の実例を用いるという点である。

サーバが特定のラベルを知らない場合、クライアントは、クライアントのクエリに対応する実例（及び、反例）をサーバに示すことができる。クライアント及びサーバによって交換される実例及び反例の数は、特に制限されない。より多くの実例／反例が提供される程、意図する範疇の性質に関するより正確な指示が得られることは明らかである。但し、実例／反例の数を増やすと、クライアントとサーバとの間の通信が占める帯域幅が広くなり、処理時間も長くなる。本発明の好適な実施形態では、送信に望ましい数より、利用可能な実例／反例の数が多い場合、これらの利用可能な実例／反例から、実際に送信する実例／反例を選択する。この選択では、実例データだけではなく、反例データも選択することが望ましい。

サーバは、クエリに応答してサーバが送信したデータがクエリに関連しており、したがって、そのラベル及び範疇をクライアントのラベル及び範疇に揃えることができるか否かに関するフィードバックを得る。

ここで、以下のように、考慮する必要がある５種類の状況がある。
・インタラクション成功：この場合、エージェントが用いる範疇及び規則の補強（re-enforcement）（ラベル／範疇の関係の意味で）をトリガするべきである。
・クライアント側での失敗：この場合、新たな範疇及びこの範疇のための新たなラベルの作成をトリガするべきである。
・サーバ側での失敗：この場合、サーバ又はクライアントによる新たなラベルの採用及び可能性として新たな範疇の作成をトリガするべきである。
・部分的な成功：これは、サーバがラベルを復号できたが、サーバによって返された結果は、クライアントのオーナにとって、部分的に無関係だとみなされた場合である。

インタラクション成功
インタラクションが完全に成功した場合、クライアントによって特定された「関連集合」Ｆは、空集合ではなく、Ｒに等しく、換言すれば、クライアントは、良い実例だけを受け取り、この事実をサーバに知らせる。これは、クライアントによって用いられた、ｃａｔ_ｃと命名されたラベルｌが、サーバによるこのラベル（ｃａｔ_ｓ）の解釈及びユーザの意図の両方に互換性があったことを意味する。この場合、クライアント及びサーバの両方が、それぞれ、ラベルから範疇へのマッピングを更新し、これにより、範疇ｃａｔ_ｃ及び範疇ｃａｔ_ｃのためのラベルｌの使用が将来的に補強される。これは、使用されたラベルと使用された範疇との間で、量Δ_ｉｎｃにより関係性（結合の「強度」）を高め、競合する関係を低めることによって実現される。競合する関係とは、同じ範疇について他のラベルを用いる関係又は過去に他の範疇を同じラベルに関連付けた関係であり、同じ範疇について他のラベルを用いる関係は、Δ_{ｎ−ｉｎｈ}によって弱められ、過去に他の範疇を同じラベルに関連付けた関係は、Δ_{ｏ−ｉｎｈ}によって弱められる。定式化すれば、以下のようになる。
１．クライアント更新ＣｌｉｅｎｔＵｐｄａｔｅ（Ｗ_ｃ，ｔ ，ｌ，ｃａｔ_ｃ）は、以下のように定義される。

２．サーバ更新ＳｅｒｖｅｒＵｐｄａｔｅ（Ｗ_ｓ，ｔ ，ｌ，ｃａｔ_ｓ）は、以下のように定義される。

そして、Δ_{ｏ−ｉｎｈ}＜０且つΔ_{ｎ−ｉｎｈ}＜０である場合、これを側方抑制（lateral inhibition）と呼ぶ。

クライアント側での失敗
次に、クライアントがＫ_ｃからＧ_ｃを区別する範疇を有していない（クライアントステップ２が失敗する）状況について検討する。この場合、クライアントは、以下の２つのステップを実行する。
・クライアントが、Ｋ_ｃの要素からＧ_ｃの要素を区別する新たな範疇ｃａｔ_ｎを構築する。
・クライアントは、新たなラベルσ（十分長いアルファベットのランダムな文字列）を作成し、強度の初期値をγ_ｉｎｉｔとして、σとｃａｔ_ｎとの間の新たな関係によって、Ｗを拡張する。
これ以降、クライアント及びサーバの間のインタラクションは、σを新たなラベルとして送信して、これまでと同様に継続することができる。

ここで、他のエージェントが、このランダムな文字列を他の範疇のために既に用いている場合に重要な問題が生じる。この問題（１つのラベルが異なる意味を有する同音異義問題と呼ばれる）は、本発明の好適な実施形態に基づくシステムのダイナミクスによって対処されるが、分散型の手法でシンボルを生成しても、一意的なシンボルを保証する、例えば、リーチ（Leach）他による「ＵＵＩＤ ＵＲＮネームスペース（A UUID URN Namespace）（The Internet Engineering Task Force, Internet drafts, http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-03.txt）」に開示されている「ユニバーサル固有識別子（universally unique identifiers：ＵＵＩＤ）」等の技術を用いることによって、この問題を最小化することができる。

サーバ側での失敗
次に、サーバがＷ_ｓにおいて定義されているラベルｌを有さず、このラベルがクライアントによって送信された（サーバステップ１が失敗する）状況について検討する。この場合に、本発明の好適な実施形態に基づいて実行される処理を図５に示す。

この場合、サーバは、クライアントに失敗を知らせる。そして、サーバは、クライアントが探しているものの実例としてＧ_ｃ（及び可能であればＫ_ｃ）を受け取り、以下のようなステップを実行する。
・サーバＩＡは、範疇ｃａｔ_ｓによってコンテキストＫ_ｃから区別できる範疇として、Ｇ_ｃを範疇化する。これに失敗した場合、サーバＩＡは、新たな範疇（更にｃａｔ_ｓと呼ぶ。）を作成し、範疇レパートリにこれを追加する。
・サーバＩＡは、ｃａｔ_ｓ及びラベルｌの関係及び初期強度γ_ｉｎｉｔを用いてＷ_ｓを拡張する。
そして、サーバは、これまでと同様の処理を継続する。

部分的な成功
部分的な成功とは、クライアントのクエリに対するサーバの応答が、サーバ（のオーナ）によって、一部無関係であるとみなされた場合を意味する。得点（すなわち、サーバの応答の「適切さ」の度合いの尺度）は、単に、オーナが適切であるとみなした要素のパーセンテージによって算出できる。失敗とは、この「適切さ」の得点が、ある閾値レベルθ_ｆａｉｌを下回ったことを意味する。

この問題には、次のような２つの原因がある。（１）クライアントによって送信されたラベルに関連している範疇が、サーバによって同じラベルに関連付けられている範疇とは異なる。又は（２）クライアントによって用いられている範疇が、ユーザが意図する区別を反映する程精密ではない。ケース（１）とケース（２）とを区別するために、クライアントエージェントは、クエリを定式化するために用いられた範疇が適切であったか否かすなわち、ｃａｔ_ｃは、Ｋ_ｃ∪ＢからＧ_ｃ∪Ｆを区別する良好な弁別的記述であるか否かを確認できる。この確認の結果が否定的である場合、これは、ｃａｔ_ｃがクライアントのオーナの意志を良好に反映していないことを意味し、すなわち、ケース（２）を適用できる。

ケース（１）に対処するためには、クライアント及びサーバは、（将来における交換が可能又は有益になるように）それぞれの範疇及びラベルを調整する必要がある。この場合、クライアント側及びサーバ側の両方からの動作が必要である。まず、以下のように、失敗した通信においてクライアント及びサーバが用いたラベルの強度を低減する。
・クライアントＩＡがｃａｔ_ｃと、Ｗ_ｃのｌとの間の関係の強度を減数Δ_ｄｅｃにより低減する。これにより、この関係が将来、この特定のラベルで符号化される可能性が低減される。
・サーバＩＡがｃａｔ_ｓと、Ｗ_ｓのｌとの間の関係の強度を減数Δ_ｄｅｃにより低減する。これにより、ｌが将来、この関係によって復号される可能性が低減される。

ケース（２）の場合、クライアント（詳しくは、クライアントの情報エージェント）は、まず、受け取ったデータの関連性に関するオーナの評価に基づいて、これまで使用した範疇より優れた、最良の範疇を見出すことを試みる必要がある。これは、ＩＡがＫ_ｃ∪Ｂ（悪い実例）からＧ_ｃ∪Ｆ（良い実例）を区別する弁別的範疇を見出さなくてはならないことを意味する。

そして、Ｇ_ｃの代わりにＧ_ｃ：∪Ｆ及びＫ_ｃの代わりにＫ_ｃ：∪Ｂを用いて、ケース（２）（クライアント側での失敗）と同様のインタラクションが行われ、クライアントは、新たな範疇及びこの範疇に関連する新たなラベルを作成する。この新たなラベルは、場合によっては、興味Ｇ_ｃ∪Ｆのオブジェクトの他の実例と共に、サーバに送信される。これにより、サーバは、この範疇の自らのバージョンを構築することができ、したがって、ラベルのセマンティクスを構築することができる。そして、サーバは、応答として、新たな実例をクライアントに送ることができる。

クライアントが第１のトランザクションで用いたものより優れた最良の範疇を見出せなかった場合、クライアントＩＡは、対象となるオブジェクトＧ_ｃ∪Ｆ及びＫ_ｃ∪Ｂの実例及び反例を送ることができ、これによりサーバは、弁別的範疇を見出すこと及びこの範疇とラベルｌとの間で関係性を追加することによって、既に送信されているラベルｌの正しい意味を理解しようとする。このケースは、先に説明したケース（３）（サーバ側での失敗）と同じである。

パラメータ
以下、エージェントの適応型メカニズムにおいて、あるメインパラメータによって取ることができる値の具体例を示す。ここに列挙する値は、システムの大規模な検査において、適切な性能をもたらすと経験的に判明した値である。ここでは、各情報エージェントが、できる限り（すなわち、特定の範疇のためのレキシコン内で使用可能な「最良の」単語を用いて）クエリに応じようとするものであるとの仮定に基づいて、良好なシステム性能が実現された。

パラメータ値の具体例：
・γ_ｉｎｉｔは、新たな関係をエージェントのレキシコンＬに入力する初期の強度である。γ_ｉｎｉｔ＝０．５。
・Δ_ｉｎｃは、成功した場合に用いられた関係におけるγの増分である。Δ_ｉｎｃ＝０．１。
・Δ_{ｎ−ｉｎｈ}は、成功した場合における、同じ名称（且つ異なる範疇）を有する関係の変化（減分）である。Δ_{ｎ−ｉｎｈ}＝−０．２。
・Δ_{ｏ−ｉｎｈ}は、成功した場合における同じ範疇（且つ異なる名称）にリンクされた関係の変化（減分）である。Δ_{ｏ−ｉｎｈ}＝−０．１。
・Δ_ｄｅｃは、失敗の場合に用いられた関係の変化（減分）である。Δ_ｄｅｃ＝−０．１。
・θ_ｄｉｓｃは、範疇化において用いられた閾値である。θ_ｄｉｓｃ＝０．５。
・θ_ｆａｉｌは、交換の失敗（サーバによって提供された結果が不十分）を知らせるために用いられる閾値である。θ_ｆａｉｌ＝０．５。

これらのパラメータの正確な値には、ある程度の余裕を設けてもよい。これらの全てを０（γ_ｉｎｉｔを許容する）としてもよいが、この場合、それまでにエージェントによって作成された全てのラベルは、エージェントの全ての母集団に伝播し、これを収束させることはできない。これらのパラメータをゼロにしない場合、Δ_ｉｎｃ＞０、Δ_{ｎ−ｉｎｈ}＜０、Δ_{ｏ−ｉｎｈ}＜０とすることは明らかである。また、Δ_ｄｅｃ＜０にしなければ、成功しなかった関係の強度が高くなるので、Δ_ｄｅｃ＜０とする必要がある。

「同義性（synonymy）」とは、同じ範疇が異なるエージェント（又は、同じエージェントの場合すらある。）について異なるラベルを有することを意味し、分散型システムでは、異なるエージェントが異なるラベルを作成するために、この状況は自然に生じる。システムのダイナミクスにより、使用と成功との間のフィードバックループのために、同義語がシステムから次第に減っていくことが保証される。ラベルが特定の範疇の命名に成功する程、そのラベルをその範疇にリンクする強度が強くなり、将来の通信で同じラベルが用いられる可能性が高まる。側方抑制（Δ_{ｎ−ｉｎｈ}≠０）がこれを保証する。

「同音異義性（homonymy）」は、同じラベルが異なる範疇に関連付けられることを意味する。これは、次のような２つの状況で生じる。（１）エージェントが、あるラベルについて、偶然同じ新たな文字列を構築した。又は（２）サーバエージェントが、クライアントによって用いられた範疇とは異なる範疇を推測したが、これにも関わらず、交換が成功した。発明者らによる実験により、本発明の好適な実施形態に基づくプロトコルによって生成された記号論的力学（semiotic dynamics）は、特に、Δ_{ｏ−ｉｎｈ}＜０の場合に、同音異義性を処理するのに十分であることが明らかとなった。なお、先に述べたように、ケース（１）は、ＵＵＩＤ技術等、一意的なラベルを仮想的に保証する方式を用いることによって回避することができる。

本発明の好適な実施形態では、ラベルと範疇との間の関係性の強度を低減する幅は、ラベルと範疇との間の関係性の強度を増加させる幅と等しくするか、これより大きくする。

図６において、「採用」は、全てのモデルパラメータがゼロであり、全ての可能なラベルが伝播される（全てのエージェントが他のエージェントによって用いられている全てのラベルを知ったときに極限に達する。）ことを意味し、「補強」は、Δ_ｉｎｃが正である（この場合０．１である）ことを示し、「側方抑制」は、Δ_{ｎ−ｉｎｈ}及びΔ_{ｏ−ｉｎｈ}が負である（この場合、それぞれ−０．２及び−０．１である）ことを示し、「減衰」は、Δ_ｄｅｃが負である（この場合、−０．１である）ことを示す。減衰は、最適より僅かに劣る結果を生じるように見えるが、同音異義性に対処するために必要である。

本発明の好適な実施形態として示す情報交換方法により、ピアツーピアネットワーク内のピアの情報エージェントは、互いに揃えられた、意味的に基礎付けられた範疇及びラベルを作成することができる。ピアの範疇／ラベルは、徐々に収束すると考えられる。但し、ピアの間の交換の全てのシーケンスが最適解に収束するわけではく、ネットワークは、「極小（local minimum）」で行き詰まることもある。本発明の好適な実施形態で用いられる側方抑制処理は、この状況を回避するためのものである。

以下、本発明の具体的な応用例の実例を説明する。第１の実例は、音楽ファイルの共有に関連し、第２の実例は、ドキュメント交換に関連し、第３の実例は、製品情報の共有に関連する。これらの応用例は、本発明が現実的にどのように作用し、この方式が如何に汎用性を有するかを詳細に示している。実際に、ここで提案するメカニズムは、如何なるピアツーピア情報交換システムにも用いることができる。

具体的応用例１：音楽ファイルの共有
この実例は、ピア間で音楽（曲）を交換するピアツーピアネットワークに関係する。ここでは、第１、第２、第３の情報システム間で行われるインタラクションについて検討する。第１の情報システムは、第１のユーザであるオーナ０に属し、情報エージェントであるエージェント０を有する。第２及び第３の情報システムは、それぞれ第２のユーザであるオーナ１及び第３のユーザであるオーナ２に属し、それぞれ情報エージェントであるエージェント１及び情報エージェントであるエージェント２を有する。以下、これらの３つの情報システムの間の一連の４つのクエリについて説明する。

本発明の好適な実施形態では、ピアに関連する異なる情報システムが、それぞれ異なる概念的スキーマに基づいて組織化されたメタデータを使用する場合であっても、ピア間で情報を交換することができる。但し、説明を簡潔にするために、３つの情報システムの全てが音楽ファイルを保存し（又は音楽ファイルにアクセスでき）、これらが、音楽ファイルを記述する同じ種類のメタデータを使用する（このメタデータは、全ての情報システムついて、同じ概念的スキーマに基づいて組織化されている。）と仮定する。この実例では、メタデータは、以下の概念的スキーマに基づいて組織化される。
・アーチスト：アーチスト名（ビートルズ、ローリングストーンズ、ディープパープル、マドンナ、マイケルジャクソン又はエルビスプレスリー）
・ジャンル：曲のジャンル（ロックンロール、ロック又はポップス）
・テンポ：曲のテンポ（遅い、中間又は速い）
以下の表１は、この実例における３個の情報システムに亘って用いられるデータ及び関連するメタデータの概要を示している。

３つの情報システムの各オーナは、それぞれのデータ（曲）を、曲タイトルのリストを含むプレーリストに組織化する。情報システムには、音楽ファイル自体を保存しても良く、これに代えて、情報システムは、単に、音楽ファイルにアクセスすることによって、例えば、再生するように選択されると、情報システムのオーナがダウンロードにより、記録媒体から読み出すことにより、又はネットワークを介してアクセスすることによって、曲を特定するための何らかの目印のみを保存してもよい。

以下の表２、表３及び表４は、それぞれ、交換処理が行われる前の、オーナ０、オーナ１及びオーナ２のプレーリストを示している。

なお、表２〜表４に示すように、オーナのプレーリストは、異なる曲についてのメタデータを示していない。音楽ブラウザアプリケーション又はこれに類するアプリケーションのユーザには、メタデータが表示されないことが多い。但し、ユーザにメタデータを表示するか否かにかかわらず、このメタデータは、情報システム内で入手可能であり（又は、例えば、オーディオフィンガプリンティングによって、曲のＭＰ３バージョンをオンラインサービスに送信し、このオンラインサービスからこの曲のメタデータを受け取ること等によって、メタデータにアクセスでき）、情報エージェントは、このメタデータを使用することができる。

これらのピア間のインタラクションの開始時には、いずれのエージェントも、如何なるラベル又は範疇も定義していない。

クエリ１：範疇作成及び通信成功の具体例
オーナ１が、自らの「ビートルズ」プレーリストのために、オーナ０から更なる曲を得ようとする第１のインタラクションについて検討する。実際には、オーナ０は、何らかのインタフェース、例えば、音楽ブラウザプログラムのグラフィカルユーザインタフェースによって、情報システムとインタラクトすることによって、このプレーリストに更なる曲を得たいとの希望を表現する。オーナ０は、新たな曲が得られるであろうピアを明示的に特定してもよく、特定しなくてもよい。

オーナ０が、「ビートルズ」プレーリストのために更なる曲を得たいことを示すと、第１の情報システムに関連するエージェント（エージェント０）は、類似する曲の検索を行う。オーナ０は、プレーリスト「ストーンズ」を選択していないので、この要求のコンテキストは、「ストーンズ」ではなく「ビートルズ」を希望するということである。この結果、オーナ０のエージェントは、この要求を「ストーンズの曲ではなく、更なるビートルズの曲を見つける」と解釈する。この要求のための実例として用いられる曲は、「Across The Universe」、「Blackbird」、「Eleanor Rigby」、「Helter Skelter」、「I Feel Fine」、「Norwegian Wood」及び「You Know My Name」である。

また、この要求のための反例として用いられる曲は、「Let's Spend the Night Together」及び「Ruby Tuesday」である。

オーナ０の要求を実現するために、システムによって実行されるステップは、以下の通りである。

ステップ１：エージェント０−範疇化
エージェント０が、オーナ０による選択に合致する範疇を見出そうとする。エージェント０は、範疇を有していないので、このステップは、失敗する。

ステップ２：エージェント０−範疇作成
エージェント０は、新たな範疇、範疇０を導入する。オーナ０の選択について説明するために、範疇０は、特徴アーチスト（ビートルズ）によって定義される。すなわち、この特徴は、属性（アーチスト）及び値（ビートルズ）からなるタプルであるとみなすことができる。エージェント０がこの範疇において、他の曲を検索しようとする場合、エージェント０は、他の情報システムと通信する際にこの範疇を指示するための単語又はラベルを必要とする。エージェント０は、ラベル「ｆａｆａｆａ」を導入し、０．５のデフォルトの強度でこのラベルを範疇０に割り当てる。これは、以下のように表現することもできる。
（範疇０＜アーチスト（ビートルズ）＞，「ｆａｆａｆａ」，０．５）
エージェント０は、ラベル「ｆａｆａｆａ」を用いて、オーナ０の検索要求を符号化する。

この特定のラベル「ｆａｆａｆａ」の選択には、如何なる特定の技術的根拠もなく、これは、単に、所定の集合（又は「アルファベット」）から選択された文字のシーケンスである。但し、幾つかのアプリケーションでは、上述したユニバーサル固有識別子（ＵＵＩＤ）からラベルを導出することが有益である場合もある。ＵＵＩＤからラベルを得る場合、これらのラベルの殆どは、集中的な調整を行わなくても一意的であることが保証され、このため、これは同音異義語の出現頻度を低減できる。

ステップ３：エージェント０−クエリ
エージェント０は、ピアツーピアネットワークを介して、エージェント１にコンタクトし、ラベル「ｆａｆａｆａ」に適合する曲を要求する。「ｆａｆａｆａ」を送信するための通信の詳細な性質及び統語構造は、例えば、Ｐ２Ｐネットワークの特徴に適合するように、必要に応じて適応化することができる。

ステップ４：エージェント１−復号
エージェント１は、そのレキシコンにラベルを有しておらず、したがって、エージェント１は、受信したラベル「ｆａｆａｆａ」に範疇を割り当てることができない（エージェント１は、「ｆａｆａｆａ」を復号することができない）。エージェント１は、エージェント０に失敗信号を送信する。

ステップ５：エージェント０−送信
ここで、エージェント０は、オーナ０の選択に対応する実例及び反例のリストをエージェント１に送る。これは、「ｆａｆａｆａ」が、エージェント０によってどのように用いられているかを示す。

サーバは、例えば、あるカタログ（例えば、オンラインカタログ）内で曲を特定する曲ＩＤコードを通信することによって、何らかの一般的に知られた規則に基づいて曲のタイトルを特定することによって、曲に対応するＭＰ３ファイルを送信することによって等、周知の如何なる手法で実例及び反例を「特定」してもよい。サーバに対して実例及び反例を特定するためにどのような方式を用いた場合であっても、サーバの情報エージェント（ここでは、エージェント１）は、自らの概念的スキーマに基づいて、これらの実例／反例のためのメタデータを検索し又は検索しようとする（メタデータは、例えば、オンラインサービスの助けを借りる等、周知の如何なる手法を用いて検索してもよい）。

ステップ６：エージェント１−範疇作成
エージェント１は、実例及び反例の集合を処理し、実例について記述し、及び反例から実例を区別する弁別的特徴（又は特徴の集合）を見つけようとする。この具体例では、エージェント１は、弁別的特徴、すなわちアーチスト（ビートルズ）を見つける。エージェント１は、ここでは、範疇１と呼ぶ、この弁別的特徴に対応する新たな範疇を作成し、０．５のデフォルトの強度でラベル「ｆａｆａｆａ」を範疇１に割り当てる。
（範疇１（＜アーチスト（ビートルズ）＞），「ｆａｆａｆａ」，０．５）
なお、実際には、エージェント１は、エージェント０によって用いられた概念スキーマとは異なる概念的スキーマに基づいて組織化されたメタデータを用いてもよい。したがって、エージェント１が反例から実例を区別する弁別的特徴の集合を見つけた場合でも、この弁別的特徴の集合は、反例から同じ実例を区別するためにエージェント０によって用いられた弁別的特徴の集合とは異なることも多い。換言すれば、エージェント０及びエージェント１がこれらの範疇によって同じ実例の集合を記述することを試みる場合であっても、エージェント１の範疇１に対応する弁別的特徴の集合は、エージェント０の範疇０に対応する弁別的特徴の集合とは異なることがある。

ステップ７：エージェント０−クエリ
エージェント０は、再び、ラベル「ｆａｆａｆａ」に適合する曲について、エージェント１に問い合わせる。この要求は、明示的に行ってもよく、エージェント０がエージェント１に実例及び反例の集合を送信したという事実に基づいて、暗示的に行ってもよい。

ステップ８：エージェント１−復号
エージェント１は、ラベル「ｆａｆａｆａ」に割り当てられている範疇のリストをチェックし、この場合、（この時点では）リストは、範疇１のみを含む。換言すればリストは、（範疇１（＜アーチスト（ビートルズ）＞），「ｆａｆａｆａ」，０．５）である。

ステップ９：エージェント１−フィルタリング
エージェント１は、第２の情報システムによって、特徴アーチスト（ビートルズ）によって記述された曲を選択するために適する関数として範疇１を演算可能にする。換言すれば、エージェント１は、範疇１を用いて、関連するデータ集合をフィルタリングする。これにより得られる曲は、「And I Love Her」、「I'm Down」及び「Twist and Shout」である。

ステップ１０：エージェント１−提供
エージェント１は、ステップ９の結果として得られたデータをエージェント０に送信する。多くの場合、送信されるデータは、検索された曲を一意的に特定する何らかのデータであり、このデータは、例えば、（タイトルが一意的であれば）曲のタイトル、あるカタログ又はデータベースにおける曲のＩＤ（例えば、http://www.muscibrainz.orgにおいてアクセス可能なＭｕｓｉｃＢｒａｉｎｚデータベースにおけるＩＤ）又は曲ファイル自体であってもよい。

ステップ１１：エージェント０−選択
エージェント０は、エージェント１から受信した応答をオーナ０に知らせる。通常、オーナ０には、（第２の情報システムから）エージェント１によって提供された曲のリストが表示される。オーナ０のクエリに対応して提供されたデータは、オーナ０の希望を満たしている場合もあれば、満たしていない場合もある。そこで、本発明の好適な実施形態では、エージェント０は、オーナ０から、クエリの結果の評価を引き出す。エージェント０は、検索結果の評価を明示的に要求してもよく、又は（ユーザのクエリへの応答を示す情報がオーナ０に提示された事実に基づいて）検索結果の評価を暗示的に要求してもよい。

この具体例では、エージェント１によって提供された全ての結果がオーナ０の検索要求に適合し、したがって、全てが「正」の結果であるとみなされる。これらの「良い」結果は、いずれもオーナ０のデータベースに存在せず、したがって、オーナ０は、ユーザのデータベースにこれらを追加することを選択し、すなわち、オーナ０の「ビートルズ」プレーリストが更新される。

ステップ１２：エージェント０−クライアント更新
クエリは、成功し、結果の１００％がオーナ０によって選択された。この結果、エージェント０は、ラベル「ｆａｆａｆａ」と範疇０との間の関係性の強度を０．１によってインクリメントする。これにより、エージェント０は、範疇０に関する以下のデータを保有する（又は、これにアクセスできる）ことになった。
（範疇０（＜アーチスト（ビートルズ）＞），「ｆａｆａｆａ」，０．６）
ステップ１３：エージェント０−フィードバック
本発明の好適な実施形態では、エージェント０は、オーナ０に提供された結果が、どの程度満足できるものであったかを示すフィードバックをエージェント１に提供する。このフィードバックは、如何なる形式で行ってもよい。なお、本発明の好適な実施形態では、このフィードバックは、提供された曲のどれが「良かったか」（すなわち、オーナ０を満足させたか）及び提供された曲のどれが「悪かったか」（すなわち、ユーザの検索基準を満たしていないとオーナ０がみなしたか）をエージェント１に対して示す形式で行われる。この具体例では、エージェント０は、提供された曲の全てが「良かったこと」を示すフィードバックを送信する。オーナ０が、どの検索結果が満足できるものであったかを第１の情報システムに示すための如何なる入力も行わなければ、このフィードバックを提供できないことは明らかである。

ステップ１４：エージェント１−サーバ更新
第１及び第２の情報システムの間の交換が完全に成功したことを示すフィードバックをサーバが受け取ると、エージェント１は、ラベル「ｆａｆａｆａ」と範疇１との間の関係性の強度を０．１インクリメントする。これにより、エージェント１は、範疇１に関する以下のデータを保有する（又は、これにアクセスできる）ことになった。
（範疇１（＜アーチスト（ビートルズ）＞），「ｆａｆａｆａ」，０．６）
クエリ１の結果、第１及び第２の情報システムは、変化した。具体的には、第１の情報システムのデータベース及びプレーリストは、変化した。またエージェント０と、エージェント１の辞書が確立された。以下の表５は、オーナ０のクエリ１の結果のプレーリストを示している。表６及び表７は、それぞれ、クエリ１の結果のエージェント０及びエージェント１の辞書を示している。

クエリ２：クライアントにおける失敗の具体例
第２のインタラクションでは、オーナ１は、更なる「６０年代」の曲をオーナ０に要求する。オーナ１は、自らの「６０年代」プレーリストを選択し、自らの情報エージェント（エージェント１）に対して、類似する曲を検索するよう求める。エージェント１は、この要求を、「７０年代及び８０年代ではなく、更なる６０年代の曲を見つける」と解釈する。

このクエリのための実例として用いられる曲は、「And I Love Her」、「I'm Down」、「Paint It Black」及び「Twist and Shout」である。

また、このクエリのための反例として用いられる曲は、「Let's Spend the Night Together」、「Smoke on the Water」、「Billie Jean」及び「Borderline」である。

システムによって実行されるステップは、以下の通りである。

ステップ１：エージェント１−範疇化
エージェント１が、オーナ１による選択に合致する範疇を見出そうとする。範疇１（＜アーチスト（ビートルズ）＞）の適合得点は、０．７５であり、これは、閾値である０．５を上回る。このため、エージェント１は、オーナ１の曲の選択を記述するために、範疇１を選択する。

ステップ２：エージェント１−符号化
エージェント１に関する限り、範疇１は、１つのラベル「ｆａｆａｆａ」のみに割り当てられる。このため、エージェント１は、「ｆａｆａｆａ」を用いて、エージェント１がオーナ１の検索要求に適合するとみなす範疇を符号化する。

ステップ３：エージェント１−クエリ
エージェント１は、エージェント０にコンタクトし、ラベル「ｆａｆａｆａ」に適合する曲を要求する。

ステップ４：エージェント０−復号
エージェント０に関する限り、ラベル「ｆａｆａｆａ」は、１つの範疇、範疇０（＜アーチスト（ビートルズ）＞）だけに割り当てられる。したがって、エージェント０は、このクエリについて、範疇０を使用する。

ステップ５：エージェント０−フィルタリング
エージェント０は、第１の情報システムによって、特徴アーチスト（ビートルズ）によって記述された曲を選択するために適する関数として範疇０を演算可能にする。換言すれば、エージェント０は、範疇０＜アーチスト（ビートルズ）＞を用いて、オーナ０のデータをフィルタリングする。これにより得られる曲は、「Across the Universe」、「Blackbird」、「Eleanor Rigby」、「Helter Skelter」、「I Feel Fine」、「Norwegian Wood」、「You Know My Name」、「And I Love Her」、「I'm Down」及び「Twist and Shout」である。

ステップ６：エージェント０−提供
エージェント０は、ステップ５の結果として得られたデータをエージェント１に送信する。

ステップ７：エージェント１−選択
エージェント１は、エージェント０から受信した応答をオーナ１に知らせ、オーナ１は、提供された曲のどれが「良いか」（すなわち、自らの個人的な検索基準を満たしているか）を選択する。この具体例では、オーナ１は、「I Feel Fine」、「And I Love Her」、「I'm Down」及び「Twist and Shout」を選択する。この結果、「Across the Universe」、「Blackbird」、「Eleanor Rigby」、「Helter Skelter」、「Norwegian Wood」及び「You Know My Name」は、オーナ１の要求（「６０年代」）に対する適切な結果ではないとみなされることになる。

サーバによって供給された曲のうち、「I Feel Fine」のみがクライアントにとって新しい（すなわち、クライアントのデータ集合に含まれていなかった）曲である。この場合、オーナ１は、「I Feel Fine」をデータベースに加えるよう選択し、「６０年代」プレーリストにこのタイトルを含ませる。

ステップ８：エージェント１−（クライアントにおける失敗）
オーナ１によって決定された「良い」結果のパーセンテージは、４０％である。この得点は、所定の閾値（ここでは５０％）を下回っているので、クライアントとサーバの間の通信は、失敗したとみなされる。エージェント１は、エージェント１がオーナ１の要求を誤解したためにこの失敗が生じたのか、エージェント０がエージェント１のクエリを誤って復号したためにこの失敗が生じたのかを判定することを試みる。エージェント１は、以下のようにして、この判定を行う。

エージェント１は、オーナ１の要求に関連する「良い」実例の２つの集合及び反例の２つの集合情報を有している。これらの実例／反例の１番目の集合は、オーナ１の初期の要求に由来し、２番目の集合は、サーバから受け取った結果に対するオーナ１の選択に由来する。エージェント１は、利用可能な実例及び反例の全てを用いて、これまで用いた範疇より、オーナ１の要求に良好に適合する既存の範疇又は新たな範疇を自らが有しているか否かを検査する。

実例（「And I Love Her」、「I'm Down」、「Paint It Black」、「I Feel Fine」及び「Twist and Shout」）及び反例（「Across the Universe」、「Blackbird」、「Eleanor Rigby」、「Helter Skelter」、「Norwegian Wood」、「You Know My name」、「Let's Spend the Night Together」、「Smoke on the Water」、「Billie Jean」及び「Borderline」）に基づき、エージェント１は、自らが先に用いた範疇（範疇１）に関連する弁別的特徴の集合は、反例から実例を区別するための最良の特徴の集合ではなかったことを見出す。換言すれば、エージェント１は、オーナ１の要求を誤解していた。

ステップ９：エージェント１−範疇作成
エージェント１は、訂正処理を行い、弁別的特徴ジャンル（ロックンロール）を定義した新たな範疇である範疇２を導入し、この範疇２を０．５のデフォルトの強度で新たなラベル「ｆｅｆａｆａ」に割り当てる。すなわち、範疇２は、（範疇２（＜ジャンル（ロックンロール）＞），「ｆｅｆａｆａ」，０．５）となる。

ステップ１０：エージェント１−送信
エージェント１は、実例及び反例の両方の集合（すなわち、Ｇ_ｃ∪Ｆ及びＫ_ｃ∪Ｂ）と共に、新たなラベル「ｆｅｆａｆａ」をエージェント０に送信する。これにより、エージェント０には、コミュニケーションの失敗があったことが暗示的に知らされる。これに代えて又はこれに加えて、エージェント１は、コミュニケーションの失敗が生じたことを示す明示的な信号をエージェント０に送信してもよい。実例の及び反例の集合の両方をエージェント０に提供することによって、エージェント０は、以後の範疇化ステップ（後述するステップ１２）に利用可能な最大限の情報を得る。

ステップ１１：エージェント０−範疇化
そして、エージェント０は、実例及び反例の集合を受け取り、これらの実例及び反例の集合に適合する既存の範疇を見つけようとする。既存の範疇である範疇０（＜アーチスト（ビートルズ）＞）を実例及び反例の集合に適用すると、「潜在的な弁別」の得点は、０．２となる。これは、所定の閾値レベルである０．５を下回る。したがって、エージェント０は、より良好に反例から実例を区別する新たな範疇を導入する必要がある。

ステップ１２：エージェント０−範疇作成
実例及び反例を処理することによってエージェント０は、反例から実例を十分に区別する弁別的特徴（ジャンル（ロックンロール））があることを見出す。エージェント０は、対応する新たな範疇である範疇３を作成し、最も新しく受信したラベル「ｆｅｆａｆａ」（実例及び反例を指定する。）にこれを割り当てる。関係性の強度の値は、初期値である０．５となる。したがって、（範疇３（＜ジャンル（ロックンロール）＞），「ｆｅｆａｆａ」，０．５）となる。

クエリ２の結果、第１及び第２の情報システムは、再び変化した。具体的には、第２の情報システムのデータベース及びプレーリストが変化した。またエージェント０及びエージェント１の辞書が成長した。以下の表８は、クエリ２の結果のオーナ１の「６０年代」プレーリストを示している。表９及び表１０は、それぞれ、クエリ２の結果のエージェント０及びエージェント１の辞書を示している。

クエリ３−範疇作成及びクライアントにおける失敗の具体例
第３のインタラクションでは、オーナ２は、更なる「パーティ用音楽」をオーナ０に求める。オーナ２は、ユーザのプレーリスト「パーティ用音楽」を選択し、自らのエージェント（エージェント２）に類似する曲を検索させる。オーナ２は、１つのプレーリストしか有していないので、この要求に関する反例は存在しない。実例として用いられる曲の集合は、「I'm Down」及び「Twist an Shout」である。

この要求に応じるためにシステムによって実行されるステップは、以下の通りである。

ステップ１：エージェント２−範疇化
エージェント２は、オーナ２の選択に適合する範疇を見つけようとする。エージェント２は、まだ、如何なる範疇も有していないのでこのステップは失敗する。

ステップ２：エージェント２−範疇作成
エージェント２は、オーナ２の選択を記述する新たな範疇である範疇４を導入する。範疇４は、特徴アーチスト（ビートルズ）によって定義される。エージェント２は、ラベル「ｆｉｆａｆａ」を導入し、０．５のデフォルトの強度でこれを範疇４に割り当て、（範疇４（＜アーチスト（ビートルズ）＞），「ｆｉｆａｆａ」，０．５）を生成する。

ステップ３：エージェント２−クエリ
エージェント２は、記述「ｆｉｆａｆａ」に適合する曲をエージェント０に問い合わせる（すなわち、エージェント２は、クエリ「ｆｉｆａｆａ」をエージェント０に送る）。

ステップ４：エージェント０−復号
エージェント０は、レキシコン内にラベル「ｆｉｆａｆａ」を有していない。したがって、エージェント０は、エージェント２に失敗を知らせる。

なお、本発明は、失敗をエージェントの間で通知する手法を限定するものではない。また、失敗の種類を明示的に示す異なる種類の失敗信号を用いてもよく或いは、特定の失敗信号が生成されたコンテキストから失敗の性質を推論してもよい。

ステップ５：エージェント２−送信
エージェント２は、「ｆｉｆａｆａ」がどのように用いられているかを示す実例（及び適切であれば反例）のリストをエージェント０に送る。

ステップ６：エージェント０−範疇化
エージェント０は、実例及び反例の集合に適合する（既存の又は新たな）範疇を見つけようとする。エージェント０は、既存の範疇である範疇０（＜アーチスト（ビートルズ）＞）の「弁別」の得点が閾値０．５を上回る１．０であることを見出す。

ステップ７：エージェント０−ラベル結合
エージェント０は、デフォルトの強度０．５で範疇０（＜アーチスト（ビートルズ）＞）にラベル「ｆｉｆａｆａ」を割り当てる。したがって、エージェント０は、現在、範疇０に割り当てられた２つのラベル、すなわち「ｆａｆａｆａ」及び「ｆｉｆａｆａ」を有する。

ステップ８：エージェント２−クエリ
エージェント２は、再び、記述「ｆｉｆａｆａ」に適合する曲についてエージェント０に問い合わせる。ここでも、この要求は、明示的に行ってもよく、エージェント２が実例／反例のリストをエージェント０に送信した事実から推論してもよい。

ステップ９：エージェント０−復号
エージェント０に関する限り、１つの範疇（範疇０）すなわち、範疇０（＜アーチスト（ビートルズ）＞）のみがラベル「ｆｉｆａｆａ」に割り当てられる。

ステップ１０：エージェント０−フィルタリング
エージェント０は、データ集合をフィルタリングするために範疇０を用いる。これにより得られる曲は、「Across the Universe」、「Blackbird」、「Eleanor Rigby」、「Helter Skelter」、「I Feel Fine」、「Norwegian Wood」、「You Know My Name」、「And I Love her」、「I'm Down」及び「Twist and Shout」である。

ステップ１１：エージェント０−提供
エージェント０は、ステップ１０によって得られたデータをエージェント２に送信する。

ステップ１２：エージェント２−選択
エージェント２は、オーナ２に対し、エージェント０から受け取った結果を評価するよう求める。オーナ２は、正の結果として、「I Feel Fine」、「Helter Skelter」、「I'm Down」及び「Twist and Shout」を選択する。他の曲（「Across the Universe」、「Blackbird」、「Eleanor Rigby」、「Norwegian Wood」、「You Know My Name」及び「And I Love Her」）は、良い結果として選択されない。

受け取った「良い」結果のうち、「I Feel Fine」及び「Helter Skelter」は、オーナ２のデータ集合内にない。これらの２つの曲は、オーナ２のデータベースに追加され、オーナ２の「パーティ用音楽」プレーリストは、追加された曲のタイトルを含むように更新される。

ステップ１３：エージェント２−クライアントにおける失敗
オーナ２によって決定された良い結果のパーセンテージは、４０％である。この得点は、閾値５０％を下回り、これは、コミュニケーションの失敗を意味する。

エージェント２は、自らがオーナ２の要求を誤解したか、又はエージェント０が要求を誤って復号したかを検査する。クエリ２のステップ８におけるエージェント１と同様に、エージェント２は、良い実例の２つの集合及び反例の２つの集合情報を有している。エージェント２は、全ての利用可能な実例及び反例を用いて、これまでに用いた範疇より、オーナ２の要求に良好に適合する既存の範疇又は新たな範疇があるか否かを確認する。

実例（「I Feel Fine」、「I'm Down」、「Helter Skelter」及び「Twist and Shout」）と、反例（「Across the Universe」、「Blackbird」、「Eleanor Rigby」、「Norwegian Wood」、「You Know My Name」及び「And I Love Her」）とに基づき、エージェント２は、自らが先に用いた範疇（範疇４）に関連する弁別的特徴の集合は、反例から実例を区別するための最良の特徴の集合ではなかったことを見出す。換言すれば、エージェント２は、オーナ２の要求を誤解していた。

エージェント２は、訂正処理を行い、弁別的特徴テンポ（速い）を定義した新たな範疇である、範疇５を導入し、この範疇５を０．５のデフォルトの強度で新たなラベル「ｆｏｆａｆａ」に割り当てる。すなわち、範疇５は、（範疇５（＜テンポ（Ｆａｓｔｌ）＞），「ｆｏｆａｆａ」，０．５）となる。

ステップ１４：エージェント２−送信
エージェント２は、実例及び反例のリストと共に、ラベル「ｆｏｆａｆａ」をエージェント０に送信する。

ステップ１５：エージェント０−範疇化
エージェント０は、実例及び反例の集合に適合する範疇を見つけようとする。範疇０（＜アーチスト（ビートルズ）＞）の得点は、閾値０．５を下回る０．０である。範疇３（＜ジャンル（ロックンロール）＞）の得点は、閾値を上回る０．５８である。

ステップ１６：エージェント０−ラベル結合
エージェント０は、ラベル「ｆｏｆａｆａ」を範疇３に割り当てる。すなわち、（範疇３（＜ジャンル（ロックンロール）＞），「ｆｏｆａｆａ」，０．５）である。

この具体例では、クエリ３は、上述したステップ１６の実行により終了する。換言すれば、エージェント２が新たなラベル（「ｆｏｆａｆａ」）及び実例をエージェント０に提供した後に、エージェント０は、自らの範疇の１つに新たなラベルを割り当てる。

なお、システムの詳細な実現例に応じて、この時点で、ラベル「ｆｏｆａｆａ」を用いた第２の検索が有効に実行されるように、エージェント０とエージェント２との間のインタラクションを拡張してもよい。より包括的に言えば、システムの実現例によっては、初期のクエリ応答の間に、又は同じユーザクエリの処理における後の交換で、新たなラベル及び／又は範疇が作成されたか否かに応じて、クライアントとサーバとの間で任意の数のステップにより、インタラクションを拡張してもよい。このような拡張トランザクションにおいても、以下の原始関数が用いられる。
・ｑｕｅｒｙ（ｌａｂｅｌ）：クライアントが、特定のラベルを用いてクエリを実行するようサーバに要求する。
・ｒｅｓｕｌｔｓ（ｌａｂｅｌ，ｄａｔａｓｅｔ）：サーバが、クライアントによって送られたラベルを用いた、クエリに対するサーバの結果であるｄａｔａ（”ｄａｔａｓｅｔ”）の集合をクライアントに返す。
・ｔｒａｎｓｍｉｔ（ｌａｂｅｌ，ｅｘａｍｐｌｅｓ，ｃｏｕｎｔｅｒ−ｅｘａｍｐｌｅｓ）：クライアントが、ラベルがどのように用いられているかを示すために、実例及び反例の集合をサーバに送信する。
・ｓｅｒｖｅｒｕｐｄａｔｅ（（ｌａｂｅｌ，｛ｆａｉｌｕｒｅ ｏｒ ｓｕｃｃｅｓｓ｝）：クライアントが、サーバによって提供された結果に対するユーザの評価に応じて、失敗又は成功をサーバに示す。

上の４つの原始関数を用いて、拡張されたクエリをどのように生成するかは、当業者にとって明らかであり、したがって、この点については詳細には説明しない。

クエリ３の結果、第１及び第３の情報システムが変化した。具体的には、第２の情報システムのデータベース及びプレーリストが変化した。また、エージェント０及びエージェント２の辞書が成長した。以下の表１１は、クエリ３の結果のオーナ２のプレーリストを示している。表１２及び表１３は、それぞれ、クエリ３の結果のエージェント０及びエージェント２の辞書を示している。

これまでの説明では、３つの情報システムのデータ集合が変化する原因は、ピアツーピア交換だけであった。しかしながら、異なる情報システムのオーナは、自らの情報システムを自由に変更できる（如何なるデータを保存するか、及びそのデータを記述するためにどのような概念階層を用いるかを変更でき、例えば、プレーリストを変更してもよい。）
例えば、クエリ３の後に（且つクエリ４の前に）、第１及び第３の情報システムのオーナは、それらの情報システムに変更を加えたとする。具体的には、以下のような変更が加えられたとする。

オーナ０が曲「Love Me Tender」、「Don't Be Cruel」及び「Suspicious Minds」を含む「エルビス」と呼ばれる新たなプレーリストを作成する。

オーナ２が、自らのプレーリスト「パーティ用音楽」に２つの新たな曲「Billie Jean」及び「Borderline」を追加する。

これらの変更が加えられた後のオーナ０及びオーナ２のプレーリストを表１４及び表１５に示す。

クエリ４−サーバにおける失敗の具体例
第４のインタラクションでは、オーナ２が、更なる「パーティ用音楽」をオーナ０に求める。オーナ２は、プレーリスト「パーティ用音楽」を選択し、自らのエージェント（エージェント２）に対し、類似する曲を検索するよう求める。オーナ２は、１つのプレーリストしか有していないので、ここでも、この要求のための反例は存在しない。

実例として用いられる曲の集合は、「I'm Down」、「Twist and Shout」、「I Feel Fine」、「Helter Skelter」、「Borderline」及び「Billie Jean」である。

この要求に応じるためにシステムによって実行されるステップは、以下の通りである。

ステップ１：エージェント２−範疇化
エージェント２は、オーナ２の選択に適合する範疇を見つけようとする。範疇５（＜テンポ（速い）＞）は、全ての実例をカバーし、１．０の得点を生成する。

ステップ２：エージェント２−符号化
エージェント２に関する限り、範疇５は、０．５の強度で１つのラベル「ｆｏｆａｆａ」のみに割り当てられる。

ステップ３：エージェント２−クエリ
エージェント２は、「ｆｏｆａｆａ」によって記述された範疇の曲を要求するために、ラベル「ｆｏｆａｆａ」をエージェント０に送信する。

ステップ４：エージェント０−復号
エージェント０は、範疇３（＜ジャンル（ロックンロール）＞）として「ｆｏｆａｆａ」を復号する。

ステップ５：エージェント０−フィルタリング
エージェント０は、データ集合をフィルタリングするために範疇３を用いる。これにより得られる曲は、「I Feel Fine」、「And I Love Her」、「I'm Down」、「Twist and Shout」、「Love Me Tender」、「Don't Be Cruel」及び「Suspicious Minds」である。

ステップ６：エージェント０−提供
エージェント０は、上のステップ５で得られた結果をエージェント０に送信する。

ステップ７：エージェント２−選択
エージェント２は、サーバから受け取った結果を評価することをオーナ２に求める。オーナ２は、正の結果として、「I Feel Fine」、「I'm Down」及び「Twist and Shout」を選択する。他の曲（「And I Love her」、「Love Me Tender」、「Don't Be Cruel」及び「Suspicious Minds」）は、良い結果として選択されない。

正の検索結果の全ては、既に、オーナ２のデータベースにある曲に対応しており、したがって、データベースには、新たな曲は追加されない。但し、エージェント２とエージェント０とにとって、それらの範疇／ラベルの整合性を高める目的で、通信を継続することは有益である。

ステップ８：エージェント２−サーバにおける失敗
オーナ２によって判断された良い結果のパーセンテージは、４２％である。この値は、閾値５０％を下回り、これは、コミュニケーションの失敗を示す。エージェント０及びエージェント２の両方は、「ｆｏｆａｆａ」と、それぞれ範疇３及び範疇５との間の関係性の強度を０．１減少させる。

エージェント２は、自らがオーナ２の要求を誤解したか、或いは、エージェント０がクエリを誤って復号したかを検査する。エージェント２は、良い実例の２つの集合及び反例の２つの集合を結合する。全ての実例のリストは、「I Feel Fine」、「I'm Down」、「Twist and Shout」、「Helter Skelter」、「Borderline」及び「Billie Jean」である。全ての反例のリストは、「And I Love Her」、「Love Me Tender」、「Don't Be Cruel」及び「Suspicious Minds」である。エージェント２は、利用可能な実例及び反例の全てを用いて、これまで用いた範疇より、オーナ２の要求に良好に適合する既存の範疇又は新たな範疇が存在するか否かを検査する。ここで、エージェント２は、既に用いている範疇（すなわち、範疇５＜テンポ（速い））により１．０の得点が得られることを見出す。このため、エージェント２は、オーナ２の要求を誤解していないとの結論を得る。したがって、この場合、エージェント０が復号を誤ったと推定する。

ステップ９：エージェント２−送信
エージェント２は、実例及び反例のリストをエージェント０に送信することによって、「ｆｏｆａｆａ」が何を意味するかをエージェント０に示す。

ステップ１０：エージェント０−範疇化
エージェント０は、エージェント２から受け取った実例及び反例の集合に適合する既存の範疇を見つけようとする。範疇０（＜アーチスト（ビートルズ）＞）は、０．４２の得点を生成し、範疇３（＜ジャンル（ロックンロール）＞）は、０．０の得点を生成し、これらはいずれも、閾値である０．５を下回る。

ステップ１１：エージェント０−範疇作成
エージェント０は、反例から例を十分に区別する新たな範疇を作成する。この新たな範疇は、範疇６（＜テンポ（速い）＞）である。エージェント０は、デフォルトの強度０．５でラベル「ｆｏｆａｆａ」を範疇６に割り当てる。

この第４のクエリに関する処理が終わると、第１及び第３の情報システムの辞書は、再び変化する。クエリ４の結果のエージェント０及びエージェント２の辞書をそれぞれ表１６及び表１７に示す。

上述した一連の４つのクエリに関する処理が終了すると、３つの情報システムは、それぞれのレキシコンを確立し、これを用いて、他の情報システムと情報を交換できるようになる。なお、エージェントの間の通信の初期の段階では、同音異義語（例えば、２つの異なる範疇であるジャンル（ロックンロール）及びテンポ（速い）のために用いられる「ｆｏｆａｆａ」）、及び同義語（例えば、ジャンル（ロックンロール）のための「ｆｅｆａｆａ」、「ｆｏｆａｆａ」）の存在により、問題が生じることがある。これらの情報システムの間のインタラクションの数が増えるに従い、ラベルと範疇の意味の間の整合性が高まる。

具体的応用例２：ドキュメントの交換
ワールドワイドウェブ上で利用可能なドキュメントの数が増加している。例えば、科学の分野では、現在、多くの研究者が自らのウェブサイトを運営し、自らの論文をｐｓ（ポストスクリプト）フォーマット又はｐｄｆ（アドビ・アクロバット：Adobe Acrobat）フォーマットで公表している。これらのデータは交換される。また特定の主題を専門とするサイトも、個々の制作者によって公開されている。学術雑誌は、通常、購読予約（subscription）を介してのみアクセス可能なウェブサイトを有する（但し、大学図書館は、大学全体の購読予約の方式を採用している場合も多い）。また、ウェブを介してのみ利用可能な電子ジャーナルの数も増加している。更に、論文の発行を追跡する幾つかのサイトもある（例えば、Ｃｉｔｅｓｅｅｒ、http://citeseer.ist.psu.edu/）。

この明細書に開示する技術は、この種の分野に好適に応用することができる。無制限なデータの集合（ドキュメント自体）が存在し、及びメタデータが存在するが、これらは、多くの場合、サイト固有の形式を有する。例えば、ジャーナル又は引用サイト（citation site）は、少なくとも、作者、発行日、キーワード、要約等の情報を含む。通常、作者又は対象のサイトは、データを組織化し、又は更なるキーワードを提供するが、これらの組織化の手法は、他のサイトの手法とは大きく異なる（例えば、異なる発行者は、それぞれのコレクションのために、異なる組織化法及びメタデータを用いている）。サイトは、多くの場合、特に、ソースサイトが一時的なものであり、論文が消されてしまうこともあるので、ソースとは異なる形式で論文のコピーを保存する。このため、ユーザは、他者にとってのサーバとなることができる。例えば、Ｃｉｔｅｓｅｅｒは、それ自身の論文のバージョンを異なるフォーマットでキャッシングし、データを得たパスに関する情報を提供する（これは、論文を最初に公開したサイトではない場合もある）。

この分野に本発明を適用する場合、これらの各サイトは、ピアツーピアネットワークにおけるピアとみなすことができ、各サイトに属する情報エージェント間で中間言語が形成される。なお、包括的で普遍的な中間言語の存在は期待されず、科学の特定の分野（例えば、マシンビジョン、ナノエレクトロニクス等）に固有の、特定の副次的な中間言語がエージェント間に出現すると考えられる。これらの中間言語は、データを交換するユーザの実際のニーズ及びその分野の意味構造に応じて適応化される。

なお、重要な点は、各ユーザが範疇の構造をサポートするために、データを組織化し、又は十分なメタデータを有しているという点である。範疇化器がこれらのメタデータにどのようにアクセスするかに関する特定のインプリメンテーションは、各ピアにローカルの問題である。ピアが使用できるメタデータは、情報検索の様々な標準的な手法を用いて得ることができる。

具体的応用例３：製品情報の共有
共有される情報は、ウェブコンテンツに制限されず、例えば、一般的な製品情報等の他の分野にも拡張できる。産業界におけるＲＦＩＤ規格（無線ＩＣタグ：Radio Frequency Identification）の採用により、消費者及び企業は、あらゆる製品に関する情報を得ることができる。ＲＦＩＤは、適切なリーダによって読み取ることができるデジタル信号を放つ小さな電子ラベルである。電子製品コード（Electronic Product Code：ＥＰＣ）は、インターネットドメイン名を決定する際のドメインネームシステムと同様に、一意的な識別をあらゆる製品に提供する命名法によって、ＲＦＩＤ規格を補足する。自動ＩＤは、物理的マークアップ言語（Physical Markup Language：ＰＭＬ）を用いて、ＥＰＣをマシンにより読取可能な製品の物理的プロパティの記述に変換することによりデータベースを提供することによってＥＰＣを更に拡張する（"PML Core Specification 1.0", Christian Floerkemeier, Dipan Anarkat, Ted Osinski, Mark Harrison, Auto-ID Center, University of St.Gallen, Insititute of Technology Management, http://www.autoidlabs.org.uk/whitepapers/STG-AUTOID-WH005.pdf）。自動ＩＤプロジェクトは、メタデータを製品の物理的性質に制限している。但し、今後は、食品の成分、電気製品の安全度等、製品に関するより多くのメタデータが利用可能になることが予想される、
人々は、製品のリストを日々取り扱い、閲覧している。例えば、消費者は、買物リストに商品を列挙し、雑誌は、注目の新製品を毎週選択し、シェフは、材料のリストによってレシピを発行し、小売業者は、そのカタログを発行し、消費者団体は、独自の基準に基づいて、商品を格付けする。製品／商品及び消費者の両方が電子機器を備えるようになり、人々の間での製品情報の交換は、一時的な分散型の環境で行われるようになった。例えば、ショッピングセンターでは、これらの情報システム間の相互運用性が実現でき、このような状況にも本発明は好適に適用できる。

本発明を用いて、新たなアプリケーションを導入できる。例えば、買物客は、複数の商品を選択し、他の買物客に、類似するアイテムのリストを尋ねる。同様の興味を有するユーザ間には、徐々に中間言語が発達し、これが情報交換に有効になる。この場合も、包括的で普遍的な中間言語は確立されず、特定の共同体で利用可能なニーズ、興味及びメタデータに順応した多くのローカル言語が生じる。

以上、本発明の好適な実施形態の詳細な特徴を用いて本発明を説明したが、本発明は、上述の実施形態の特殊性に制限されないことは当業者にとって明らかである。更に、上述した好適な実施形態は、特許請求の範囲で定義される本発明の範囲から逸脱することなく、様々に修正し及び適応化することができる。

例えば、上述したピア間のクエリ応答トランザクションでは、サーバは、クライアントの要求に適合すると考えられる全てのデータをクライアントに送信している。しかしながら、この場合、１つのデータアイテムのみを返信してもよく、より包括的には、サーバがクライアントの問合わせに適合すると考えるデータの完全な集合より少ない数のデータアイテムを返信してもよい。

更に、上述した具体的応用例では、クライアントのオーナがクエリに対する応答を受け取った場合、オーナは、クエリに関連している結果（存在すれば）を選択し、自らの情報システムに選択した項目を加えるか否かを決定することができる。実際には、オーナは、オーナ側で更なる操作を行うことなく、選択された結果を自動的にオーナの情報システムに追加することを好む場合もあり、このような構成としてもよい。

更に、（一方がクライアントとして機能し、他方がサーバとして機能する）２つの情報システムの間の一対一の交換に関して本発明の好適な実施形態を説明したが、実際には、クライアントは、特定のアドレスを指定することなく、ピアツーピアネットワークに同報通信的にメッセージを送出してもよい。換言すれば本発明は、クライアントがネットワーク内の実質的に全てのメンバに（又は、例えば、委託されたピアの共同体等の予め定義された下位集合に）クエリを送出する場合も包含する。クライアント（及び／又はネットワーク内の制御要素）は、周知のアルゴリズムを用いて、現在のクエリの以後の処理において、どのピア（又は複数のピア）をサーバとみなすかを決定してもよい。また、本発明は、第１の情報システムが特定のサーバに対してクエリを発する場合も包含することは明らかである。

更に、ピアツーピアネットワークにおける情報システム間の情報交換において意味相互運用性を促進する上述した技術は、１つの情報システムのオーナが他の情報システムに対しデータの要求（クエリ）を行う場合を想定している。しかしながら、これらの技術は、例えば、１人の情報システムのオーナが他の情報システムのオーナに対し、自らの情報システムに保有するデータに関する告知（オファー）を行う等の他の状況に容易に適応化することができる。

利用可能なデータの「告知」にかかわる情報交換では、告知を受け取った情報システムのオーナは、告知を行った情報システムにデータを要求することによって、告知に応じることができる。この場合、情報システムのオーナが告知を受け取り、データを要求でき、告知を行った情報システムによって提供された結果に対して選択を行うことができる。したがって、この場合、「告知側」がサーバであり、告知を受け取る情報システムがクライアントである。ピア間における「告知」型のトランザクションでは、上述と同様の符号化、復号、範疇化及びフィルタリング処理を用いることができる。

上述した好適な実施形態では、最初に、クライアントからサーバにラベルを含むクエリを発し、ラベルによって指定された範疇の実例は、後に送信しているが、初期のクエリの送信において、ラベルに実例及び／又は反例データを含ませてもよい（但し、これは、クライアント及びサーバが、いずれも使用されているラベルを既に理解している場合には、非効率な処理である）。

従来の情報システムにおけるデータの構造化及びオーナが定義した概念階層を示す図である。 本発明の好適な実施形態の情報システムに関連するエージェントの概念階層を示す図である。 本発明の好適な実施形態に基づくピアツーピア交換に関する異なる情報アイテム及びマッピングを示す図である。 第１のピアツーピア交換を説明する図である。 第２のピアツーピア交換を説明する図である。 異なるパラメータが情報システム間の共通のレキシコンの成長にどのように影響するかを示すグラフ図である。

Claims (17)

1. データアイテムの第１のコレクションにアクセスするアクセス手段と、
   
   情報システムのユーザが上記第１のコレクション内のデータアイテムである実例を１つ以上特定した実例の集合に対応するデータアイテムのクラスであって、リモートの情報システムから検索することを望んだデータアイテムのクラスを定義できるようにする検索要求手段と、
   上記検索要求手段に応答し、ユーザの要求をリモートの情報システムに送信するための初期のクエリを準備する情報エージェントであって、ユーザによって特定された上記実例の集合に含まれる各実例の共通の特徴を判定し、判定された共通の特徴に基づいて、ユーザによって特定された上記実例の集合にデータアイテムのカテゴリを自動的に割り当てる分類器と、上記分類器によって割り当てられた上記カテゴリと関連する１以上のラベルを含むラベルの集合の中から上記ラベルを選択する符号器とを備え、上記初期のクエリに、上記符号器により選択された上記ラベルを含ませることにより、検索が望まれたデータアイテムの上記カテゴリを指定する情報エージェントと、
   上記情報エージェントによって準備された初期のクエリを出力する出力手段と、
   上記出力手段によるクエリの出力に対応して、リモートの情報システムによって検索されたデータアイテムを特定する情報を受け取る入力手段と、
   上記ユーザに対し、上記リモートの情報システムによって検索されたデータアイテムを特定する上記情報を表示する表示手段と、
   上記ユーザが、上記クエリに対応して上記リモートの情報システムによって検索されたデータアイテムからユーザにより定義された上記クラスに合致するデータアイテムの選択を行うことができる選択手段とを備え、
   上記情報エージェントは、
   上記分類器により割り当てられた上記カテゴリと、ラベルと、上記ラベル及び上記分類器により割り当てられた上記カテゴリの間の関係性の強度とが対応付けられて一覧とされたリストを記憶手段に記憶させ、
   上記ラベル及び上記分類器により割り当てられた上記カテゴリの間の関係性の強度に基づいて、ユーザによって特定された上記実例の集合に上記分類器が割り当てたカテゴリと最も強い関係性を有するラベルを判定し、
   上記分類器により割り当てられた上記カテゴリと最も強い関係性を有するラベルを上記初期のクエリに含め、
   上記選択手段に応答し、上記ユーザの選択に基づいて、上記ラベルと上記分類器により割り当てられた上記カテゴリとの間の関係性の強度を変更し、
   上記初期クエリに対応して上記リモートの情報システムによって検索されたデータアイテムがユーザにより定義された上記クラスと合致することを、上記ユーザによるデータアイテムの選択が示している場合、上記分類器により割り当てられたデータアイテムの上記カテゴリと関連するラベルの集合のうち、上記初期のクエリで用いられたラベル以外のラベルと、上記分類器により割り当てられたデータアイテムの上記カテゴリとの間の関係性の強度に比べて、上記初期のクエリに含まれるラベルと、上記分類器によって割り当てられたデータアイテムの上記カテゴリとの間の関係性の強度を高め、
   上記初期クエリに対応して上記リモートの情報システムによって検索されたデータアイテムがユーザにより定義された上記クラスと合致しないことを、上記ユーザによるデータアイテムの選択が示している場合、上記分類器により割り当てられたデータアイテムの上記カテゴリと関連するラベルの集合のうち、上記初期のクエリで用いられたラベル以外のラベルと、上記分類器により割り当てられたデータアイテムの上記カテゴリとの間の関係性の強度に比べて、上記初期のクエリに含まれるラベルと、上記分類器によって割り当てられたデータアイテムの上記カテゴリとの間の関係性の強度を低める
   ことを特徴とする情報システム。
2. 上記情報エージェントは、
   上記検索されたデータアイテムから上記ユーザによって選択されたデータアイテムの数が、所定の閾値より多いか少ないかを判定し、
   上記選択されたデータアイテムの数が所定の閾値より多い場合、初期のクエリで用いられたラベル以外のラベルと、上記分類器により割り当てられた上記カテゴリとの間の関係性の強度に比べて、初期のクエリで用いられたラベルと、上記分類器により割り当てられた上記カテゴリとの間の関係性の強度を高める
   ことを特徴とする請求項１記載の情報システム。
3. 上記情報エージェントは、
   上記検索されたデータアイテムから上記ユーザによって選択されたデータアイテムの数が、所定の閾値より多いか少ないかを判定し、
   上記選択されたデータアイテムの数が所定の閾値より少ない場合、初期のクエリで用いられたラベルと、上記分類器により割り当てられた上記カテゴリとの間の関係性の強度を低める
   ことを特徴とする請求項１又は２記載の情報システム。
4. ユーザが上記第１のコレクションのデータアイテムを分類可能なデータ構造を定義できるようにする構造化手段をさらに備え、
   上記データ構造のノードは、ユーザによる任意の分類に基づいてラベルが付され、
   上記検索要求手段は、上記ユーザによる任意の分類により、上記検索が望まれたデータアイテムのクラスを特定できるようにする
   ことを特徴とする請求項１乃至３いずれか１項記載の情報システム。
5. 上記情報エージェントによって上記記憶手段に記憶されるリスト内の各カテゴリは、弁別的特徴の集合によって定義され、
   上記分類器は、上記ユーザによって特定された実例の集合に含まれる各実例の共通の特徴と、上記情報エージェントによって上記記憶手段に記憶されるリスト内のカテゴリの弁別的特徴集合とを比較することにより、上記ユーザが特定したデータアイテムの集合を割り当てるカテゴリを決定する
   ことを特徴とする請求項１乃至４いずれか１項記載の情報システム。
6. 
   上記選択手段に応答し、上記ユーザの選択を特定する信号をリモートの情報システムに出力するフィードバック手段を備える
   請求項１乃至５いずれか１項記載の情報システム。
7. 上記情報エージェントは、上記リモートの情報システムによって上記クエリに対応するデータアイテムが検索できなかったことをリモートの情報システムから受け取った情報が示している場合、又はユーザが上記選択手段を操作して選択した検索されたデータアイテムの数が所定の閾値より少ない場合に、上記ユーザが特定した実例の集合を特定するデータをリモートの情報システムに出力する
   ことを特徴とする請求項１乃至６いずれか１項記載の情報システム。
8. 上記情報エージェントは、
   上記検索されたデータアイテムから上記ユーザによって選択されたデータアイテムの数が、所定の閾値より多いか少ないかを判定し、
   上記選択された数が閾値を下回る場合、上記分類器は、上記検索要求手段に特定された上記実例の集合に含まれる各実例と、上記リモートの情報システムによって検索されたデータアイテムからユーザによって選択されたデータアイテムとの共通の特徴を判定し、判定された共通の特徴に基づいて、上記実例の集合及びユーザによって選択されたデータアイテムに適用可能な改訂されたカテゴリを決定し、
   上記改訂されたカテゴリが上記初期のクエリにおいてラベルが付された上記分類器により割り当てられたカテゴリとは異なる場合、上記ラベル及びカテゴリの間の関係性の強度に基づいて、上記改訂されたカテゴリに対する最も強い関係性を有するラベルである改訂されたラベルを判定し、上記改定されたラベルを含む上記初期のクエリへの補足情報を準備し、リモートの情報システムに出力する
   ことを特徴とする請求項１乃至７いずれか１項記載の情報システム。
9. データアイテムの第２のコレクションにアクセスするアクセス手段と、
   リモートの情報システムから、ラベルを含み、上記第２のコレクションからデータアイテムの検索を要求する初期のクエリを受け取る入力手段と、
   カテゴリと、ラベルと、上記ラベル及び上記カテゴリの間の関係性の強度とが対応付けられて一覧とされたリストを記憶する記憶手段と、
   上記受信した初期のクエリを処理し、上記リストに基づいて、受信したクエリに含まれるラベルに関連する１以上のデータアイテムのカテゴリを含むカテゴリの集合を判定し、上記カテゴリの集合内に含まれるデータアイテムのカテゴリの中から上記第２のコレクションからの検索のためのデータアイテムの初期のカテゴリを判定する復号手段を有し、上記判定された初期のカテゴリに属する上記第２のコレクション内のデータアイテムを特定する初期応答を準備する情報エージェントと、
   上記初期応答を上記リモートの情報システムに出力する出力手段とを備え、
   上記復号手段は、受信された上記初期のクエリに含まれるラベルと関連する１以上のデータアイテムのカテゴリを含むカテゴリの集合の中から、ラベル及びカテゴリの間の関係性の強度に基づいて、上記初期のクエリによって受け取ったラベルに最も強い関係性を有するカテゴリを選択することによって、検索のための上記データアイテムの初期のカテゴリを判定し、
   
   上記情報エージェントは、
   上記リモートの情報システムから受信した、上記リモートの情報システムのユーザによる、上記初期応答で特定されたデータアイテムからの選択を示すフィードバックに応答して、上記ラベルとカテゴリとの間の関係性の強度を変更し、
   上記初期応答内のデータが上記リモートの情報システムのユーザによって定義されたデータアイテムのクラスに合致することを、上記リモートの情報システムから受信されたフィードバックが示している場合、上記初期のクエリに含まれるラベルと、上記復号手段により選択されたデータアイテムの上記カテゴリ以外の、上記カテゴリの集合内の上記カテゴリとの間の関係性の強度に比べて、上記ラベルと、上記復号手段により選択されたデータアイテムの上記カテゴリとの間の関係性の強度を強め、
   上記初期応答内のデータが上記リモートの情報システムのユーザによって定義されたデータアイテムのクラスに合致しないことを、上記リモートの情報システムから受信されたフィードバックが示している場合、上記初期のクエリに含まれるラベルと、上記復号手段により選択されたデータアイテムの上記カテゴリ以外の、上記カテゴリの集合内の上記カテゴリとの間の関係性の強度に比べて、上記ラベルと、上記復号手段により選択されたデータアイテムの上記カテゴリとの間の関係性の強度を低める
   ことを特徴とする情報システム。
10. 上記情報エージェントは、上記リモートの情報システムから受信したフィードバックにおいて、上記検索されたデータアイテムから上記ユーザによって選択されたデータアイテムの数が、所定の閾値より多いか少ないかを判定し、
    上記選択されたデータアイテムの数が所定の閾値より多い場合、受信した上記初期のクエリに含まれるラベルと、上記復号手段によって選択された上記初期のカテゴリ以外のカテゴリとの間の関係性の強度に比べて、上記受信した初期のクエリに含まれるラベルと、上記復号手段によって選択された上記初期のカテゴリとの間の関係性の強度を高める
    ことを特徴とする請求項９記載の情報システム。
11. 上記情報エージェントは、上記リモートの情報システムから受信したフィードバックにおいて、上記検索されたデータアイテムから上記ユーザによって選択されたデータアイテムの数が、所定の閾値より高いか低いかを判定し、
    上記選択されたデータアイテムの数が所定の閾値より少ない場合、上記受信した初期のクエリに含まれるラベルと、上記復号手段によって判定された上記初期のカテゴリとの間の関係性の強度を低める
    ことを特徴とする請求項９又は１０記載の情報システム。
12. 上記記憶手段に記憶されるリスト内の各カテゴリは、弁別的特徴の集合によって定義され、上記情報エージェントは、上記データアイテムの特徴と、上記判定された初期のカテゴリの弁別的特徴の集合とを比較することによって、上記第２のコレクションにおいて、検索のためのデータアイテムを特定する
    ことを特徴とする請求項９乃至１１いずれか１項記載の情報システム。
13. 上記情報エージェントによって記憶手段に記憶されるリスト内の各カテゴリは、弁別的特徴の集合によって定義され、
    上記情報エージェントは、上記リモートの情報システムから受け取った、上記リモートの情報システムのユーザが検索を望んだデータアイテムのクラスの実例を構成するデータアイテムの集合を特定する各実例の共通の特徴を判定し、判定された共通の特徴に基づいて、検索のためのデータアイテムの優位のカテゴリを特定する分類器を備え、該分類器は、上記実例の共通の特徴と、上記情報エージェントによって記憶手段に記憶されているリスト内のカテゴリの弁別的特徴集合とを比較することによって、検索のための優位のカテゴリを特定する
    ことを特徴とする請求項９乃至１２いずれか１項記載の情報システム。
14. 上記分類器は、上記情報エージェントによって記憶手段に記憶されているリスト内のカテゴリの特徴の集合のいずれも、実例であるデータアイテムに関して弁別的でない場合、上記実例であるデータアイテムの弁別的特徴の集合を判定し、該弁別的特徴の集合に対応する新たなカテゴリを上記リストに追加する
    ことを特徴とする請求項１３記載の情報システム。
15. クライアントモード又はサーバモードで動作可能な複数のピアである情報システムを含むピアツーピア情報交換ネットワークにおいて、各情報システムは、上記クライアントモードでは、請求項１乃至８いずれか１項記載の情報システムとして動作し、上記サーバモードでは、請求項９乃至１４いずれか１項記載の情報システムとして動作する
    ピアツーピア情報交換ネットワークシステム。
    
16. 
    データアイテムの第１のコレクションにアクセスするアクセス手段と、
    
    情報システムのユーザが上記第１のコレクション内のデータアイテムである実例を１つ以上特定した実例の集合に対応する上記データアイテムのクラスであって、リモートの情報システムから検索することを望んだデータアイテムのクラスを定義できるようにする特定手段と、
    上記特定手段に応答し、リモートの情報システムに送信するためのデータアイテムの初期のメッセージを準備する情報エージェントであって、ユーザによって特定された上記実例の集合に含まれる各実例の共通の特徴を判定し、判定された共通の特徴に基づいて、ユーザによって特定された上記実例の集合にデータアイテムのカテゴリを自動的に割り当てる分類器と、上記分類器によって割り当てられた上記カテゴリと関連する１以上のラベルを含むラベルの集合の中から上記ラベルを選択する符号器とを備え、上記初期のメッセージに上記符号器により選択された上記ラベルを含ませることにより、検索が望まれたデータアイテムの上記カテゴリを指定する情報エージェントと、
    
    上記情報エージェントによって準備された初期のメッセージを出力する出力手段と、
    上記出力手段による上記メッセージの出力に対応して、リモートの情報システムによって検索されたデータアイテムを特定する情報を受け取る入力手段と、
    上記ユーザに対し、上記リモートの情報システムによって検索されたデータアイテムを特定する上記情報を表示する表示手段と、
    上記ユーザが、上記メッセージに対応して上記リモートの情報システムによって検索されたデータアイテムからユーザにより定義された上記クラスに合致するデータアイテムの選択を行うことができる選択手段とを備え、
    上記情報エージェントは、
    
    上記分類器により割り当てられたカテゴリと、ラベルと、該ラベル及び上記分類器により割り当てられたカテゴリの間の関係性の強度とが対応付けられて一覧とされたリストを記憶手段に記憶させ、
    上記ラベル及び上記分類器により割り当てられた上記カテゴリの間の関係性の強度に基づいて、ユーザによって特定された上記実例の集合に上記分類器が割り当てたカテゴリと最も強い関係性を有するラベルを判定し、
    上記分類器により割り当てられた上記カテゴリと最も強い関係性を有するラベルを上記初期のメッセージに含め、
    上記選択手段に応答し、上記ユーザの選択に基づいて、上記ラベルと上記分類器により割り当てられた上記カテゴリとの間の関係性の強度を変更し、
    上記初期メッセージに対応して上記リモートの情報システムによって検索されたデータアイテムがユーザにより定義された上記クラスと合致することを、上記ユーザによるデータアイテムの選択が示している場合、上記分類器により割り当てられたデータアイテムの上記カテゴリと関連するラベルの集合のうち、上記初期のメッセージで用いられたラベル以外のラベルと、上記分類器により割り当てられたデータアイテムの上記カテゴリとの間の関係性の強度に比べて、上記初期のメッセージに含まれるラベルと、上記分類器によって割り当てられたデータアイテムの上記カテゴリとの間の関係性の強度を高め、
    上記初期メッセージに対応して上記リモートの情報システムによって検索されたデータアイテムがユーザにより定義された上記クラスと合致しないことを、上記ユーザによるデータアイテムの選択が示している場合、上記分類器により割り当てられたデータアイテムの上記カテゴリと関連するラベルの集合のうち、上記初期のメッセージで用いられたラベル以外のラベルと、上記分類器により割り当てられたデータアイテムの上記カテゴリとの間の関係性の強度に比べて、上記初期のメッセージに含まれるラベルと、上記分類器によって割り当てられたデータアイテムの上記カテゴリとの間の関係性の強度を低める
    ことを特徴とする情報システム。
    
17. データアイテムのコレクションと、ユーザがリモートピアから検索するためのデータアイテムのクラスを指示するための指示手段と、ユーザがリモートピアによって検索されたデータアイテムに対する選択を行う選択手段とを有し、クライアントモード又はサーバモードで動作可能な複数のピア情報システムを含むピアツーピアネットワークにおける情報交換の管理方法において、
    上記各ピア情報システムの情報エージェントが、カテゴリと、ラベルと、該ラベル及びカテゴリの間の関係性の強度とが対応付けられて一覧とされたリストを記憶手段に記憶するステップを有し、
    
    上記クライアントモードにおいてクエリを定式化する場合、上記情報エージェントは、上記指示手段のユーザ操作によりコレクション内のデータアイテムである実例が１つ以上特定された実例の集合であって、ユーザが検索を望んだデータアイテムのクラスに対応する実例の集合を表す実例データを解析して、上記実例の集合に含まれる各実例の共通の特徴を判定し、判定された共通の特徴に基づいて、クエリのためのクライアント側のカテゴリを判定し、上記クライアント側のカテゴリと関連する１以上のラベルを含むラベルの集合の中から、上記ラベルと上記カテゴリとの間の関係性の強度に基づいて、上記カテゴリに最も強い関係性を有するラベルを判定し、リモートピアに出力する上記クエリに、上記判定されたクライアント側のカテゴリに最も強い関係性を有するラベルを含め、
    上記サーバモードにおいてクエリに応じる場合、上記情報エージェントは、該クエリによって受信したラベルを復号し、上記リストに基づいて、受信した上記ラベルと関連する１以上のカテゴリを含むカテゴリの集合を判定し、上記ラベルと上記カテゴリとの間の関係性の強度に基づいて、検索のためのデータアイテムのカテゴリとして、受信した上記ラベルと最も強い関係性を有するサーバ側のカテゴリを判定し、
    
    上記情報エージェントは、上記リスト内のラベル及びカテゴリの間の関係性の強度を変更することによって、上記選択手段のユーザ操作による、リモートのピアで検索されたデータアイテムのユーザの選択に応答し、
    上記情報エージェントは、
    上記クライアントモードにおいてクエリを定式化する場合、上記リモートピアによって検索されたデータアイテムがユーザにより定義された上記クラスの分類と合致することを、上記ユーザによるデータアイテムの選択が示しているとき、上記判定されたクライアント側のカテゴリと関連するラベルのうち、上記リモートピアに出力されたクエリに含まれるラベル以外のラベルと、上記判定されたクライアント側のカテゴリとの間の関係性の強度に比べて、上記リモートピアに出力されたクエリに含まれる上記選択されたラベルと、上記判定されたクライアント側のカテゴリとの間の関係性の強度を高め、
    上記クライアントモードにおいてクエリを定式化する場合、上記リモートピアによって検索されたデータアイテムがユーザにより定義された上記クラスの分類と合致しないことを、上記ユーザによるデータアイテムの選択が示しているとき、上記判定されたクライアント側のカテゴリと関連するラベルのうち、上記リモートピアに出力されたクエリに含まれるラベル以外のラベルと、上記判定されたクライアント側のカテゴリとの間の関係性の強度に比べて、上記リモートピアに出力されたクエリに含まれる上記選択されたラベルと、上記判定されたクライアント側のカテゴリとの間の関係性の強度を低め、
    上記サーバモードにおいて動作する場合、上記サーバモードにおいて生成された応答が上記受信されたクエリと合致することを、上記ユーザによるデータアイテムの選択が示しているとき、上記リモートピアから受信されたクエリに含まれるラベルと、受信されたクエリに含まれるラベルに関連するサーバ側のカテゴリのうち、上記判定されたカテゴリ以外のカテゴリとの間の関係性の強度に比べて、上記リモートピアから受信されたクエリに含まれるラベルと、上記判定されたサーバ側のカテゴリとの間の関係性の強度を高め、
    上記サーバモードにおいて動作する場合、上記サーバモードにおいて生成された応答が上記受信されたクエリと合致しないことを、上記ユーザによるデータアイテムの選択が示しているとき、上記リモートピアから受信されたクエリに含まれるラベルと、受信されたクエリに含まれるラベルに関連するサーバ側のカテゴリのうち、上記判定されたカテゴリ以外のカテゴリとの間の関係性の強度に比べて、上記リモートピアから受信されたクエリに含まれるラベルと、上記判定されたサーバ側のカテゴリとの間の関係性の強度を低める
    情報交換の管理方法。

Images