特許 5981593 消費者定義の情報アーキテクチャ用のシステム、方法およびコンピュータプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5981593

(24)【登録日】2016年8月5日

(45)【発行日】2016年8月31日

(54)【発明の名称】消費者定義の情報アーキテクチャ用のシステム、方法およびコンピュータプログラム

(51)【国際特許分類】

   G06F 17/30 20060101AFI20160818BHJP

【ＦＩ】

   G06F17/30 210D

【請求項の数】23

【全頁数】78

(21)【出願番号】特願2015-54763(P2015-54763)

(22)【出願日】2015年3月18日

(62)【分割の表示】特願2013-222881(P2013-222881)の分割

【原出願日】2007年8月31日

(65)【公開番号】特開2015-133144(P2015-133144A)

(43)【公開日】2015年7月23日

【審査請求日】2015年4月7日

(31)【優先権主張番号】11/469,258

(32)【優先日】2006年8月31日

(33)【優先権主張国】US

(31)【優先権主張番号】11/550,457

(32)【優先日】2006年10月18日

(33)【優先権主張国】US

(31)【優先権主張番号】11/625,452

(32)【優先日】2007年1月22日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】511050240

【氏名又は名称】プライマル フュージョン インコーポレイテッド

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】スウィーニー，ピーター

(72)【発明者】

【氏名】グッド，ロバート

【審査官】 小太刀 慶明

(56)【参考文献】

【文献】 米国特許第０６４４６０６１（ＵＳ，Ｂ１）

【文献】 特開２００４−１０２３９７（ＪＰ，Ａ）

【文献】 特開２００３−１０８５６９（ＪＰ，Ａ）

【文献】 特開２００３−０３０２２７（ＪＰ，Ａ）

【文献】 国際公開第２００６／０２６７０２（ＷＯ，Ａ２）

【文献】 国際公開第２００６／０５３３０６（ＷＯ，Ａ２）

【文献】 特開２００５−２７５７９４（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １７／３０

(57)【特許請求の範囲】

【請求項1】

既存の複雑なデータ構造を新たな複雑なデータ構造に変換するための、コンピュータによって実現される方法であって、
当該方法は、メモリに格納されるプログラム命令によって、
（ａ）１つ又は複数のドメインからソースデータ構造にアクセスする或いはアクセスするのを容易化するステップであって、前記ソースデータ構造は、概念の集合と該概念の間の概念関係の第１の集合とを表す少なくとも１つの既存の複雑なデータ構造を含み、前記概念の集合及び前記概念関係の第１の集合は、次元軸の第１の集合を定める、ステップ、
（ｂ）前記概念の間の概念関係の第２の集合を生成するために、前記ソースデータ構造を処理する或いは処理するのを容易化するステップであって、前記概念の集合及び前記概念関係の第２の集合は、次元軸の第２の集合を定め、前記概念関係の第２の集合は、前記少なくとも１つの既存の複雑なデータ構造中に表されない、少なくとも１つの概念関係を含む、ステップ、並びに
（ｃ）前記次元軸の第２の集合を定める前記概念の集合及び前記概念関係の第２の集合を表す新たな複雑なデータ構造を合成する或いは合成するのを容易化するステップを、
１つ又は複数のハードウェアプロセッサが遂行することを含む、
方法。

【請求項2】

請求項１に記載のコンピュータによって実現される方法であって、前記ステップ（ｂ）は、前記ソースデータ構造のファセット及び／又はファセット属性を発見するために、前記ソースデータ構造を分析する或いは分析するのを容易化することを含む、方法。

【請求項3】

請求項１に記載のコンピュータによって実現される方法であって、前記次元軸の第２の集合は、前記次元軸の第１の集合と異なり且つ／或いは前記次元軸の第１の集合よりも数値的に大きい、方法。

【請求項4】

請求項２に記載のコンピュータによって実現される方法であって、前記次元軸の第２の集合は、発見されるファセット及び／又はファセット属性を共有する概念の間の概念関係によって定められる、方法。

【請求項5】

請求項１に記載のコンピュータによって実現される方法であって、前記次元軸の第２の集合は、前記ソースデータ構造の分析を通じて発見されるファセット属性の集合と等しい必要のない属性の集合からの属性を共有する概念の間の概念関係によって定められる、方法。

【請求項6】

請求項１に記載のコンピュータによって実現される方法であって、複雑適応処理を通じて前記新たなデータ構造を変更するために、ユーザインタラクションフィードバックを前記ステップ（ｂ）に提供する或いは提供するのを容易化することを更に含む、方法。

【請求項7】

コンピュータシステムであって、
既存の複雑なデータ構造を新たな複雑なデータ構造に変換するための、プロセッサによって実行可能な命令を格納する、少なくとも１つのメモリと、
該少なくとも１つのメモリに動作的に結合させられる、少なくとも１つのハードウェアプロセッサとを含み、
該少なくとも１つのハードウェアプロセッサは、
（ａ）１つ又は複数のドメインからソースデータ構造にアクセスする或いはアクセスするのを容易化する命令を実行し、前記ソースデータ構造は、概念の集合と該概念の間の概念関係の第１の集合とを表す少なくとも１つの既存の複雑なデータ構造を含み、前記概念の集合及び前記概念関係の第１の集合は、次元軸の第１の集合を定め、
（ｂ）前記概念の間の概念関係の第２の集合を生成するために、前記ソースデータ構造を処理する或いは処理するのを容易化する命令を実行し、前記概念の集合及び前記概念関係の第２の集合は、次元軸の第２の集合を定め、前記概念関係の第２の集合は、前記少なくとも１つの既存の複雑なデータ構造中に表されない、少なくとも１つの概念関係を含み、
（ｃ）前記次元軸の第２の集合を定める前記概念の集合と前記概念関係の第２の集合とを表す新たな複雑なデータ構造を合成する或いは合成するのを容易化する命令を実行する、
コンピュータシステム。

【請求項8】

請求項７に記載のコンピュータシステムであって、前記作用（ｂ）は、前記ソースデータ構造のファセット及び／又はファセット属性を発見するために、前記ソースデータ構造を分析する或いは分析するのを容易化することを含む、コンピュータシステム。

【請求項9】

請求項７に記載のコンピュータシステムであって、前記次元軸の第２の集合は、前記次元軸の第１の集合と異なり且つ／或いは前記次元軸の第１の集合よりも数値的に大きい、コンピュータシステム。

【請求項10】

請求項８に記載のコンピュータシステムであって、前記次元軸の第２の集合は、発見されるファセット及び／又はファセット属性を共有する概念の間の概念関係によって定められる、コンピュータシステム。

【請求項11】

請求項７に記載のコンピュータシステムであって、前記次元軸の第２の集合は、前記ソースデータ構造の分析を通じて発見されるファセット属性の集合と等しい必要のない属性の集合からの属性を共有する概念の間の概念関係によって定められる、コンピュータシステム。

【請求項12】

請求項７に記載のコンピュータシステムであって、前記少なくとも１つのプロセッサは、複雑適応処理を通じて前記新たなデータ構造を変更するために、ユーザインタラクションフィードバックを前記作用（ｂ）に提供する或いは提供するのを容易化する命令を更に実行する、コンピュータシステム。

【請求項13】

請求項７に記載のコンピュータシステムであって、当該コンピュータシステムは、分散型計算環境において実行される、コンピュータシステム。

【請求項14】

請求項７に記載のコンピュータシステムであって、前記作用（ｂ）は、前記ソースデータ構造を処理する或いは処理するのを容易化するのに形態素辞書を用いることを含む、コンピュータシステム。

【請求項15】

コンピュータシステムで実行されるときに既存の複雑なデータ構造を新たな複雑なデータ構造に変換するための方法を遂行する命令を格納する、コンピュータプログラム格納媒体であって、
前記方法は、
（ａ）１つ又は複数のドメインからソースデータ構造にアクセスすること或いはアクセスするのを容易化することを含み、前記ソースデータ構造は、概念の集合と該概念の間の概念関係の第１の集合とを表す少なくとも１つの既存の複雑なデータ構造を含み、前記概念の集合及び前記概念関係の第１の集合は、次元軸の第１の集合を定め、
（ｂ）前記概念の間の概念関係の第２の集合を生成するために、前記ソースデータ構造を処理する或いは処理するのを容易化することを含み、前記概念の集合及び前記概念関係の第２の集合は、次元軸の第２の集合を定め、前記概念関係の第２の集合は、前記少なくとも１つの既存の複雑なデータ構造中に表されない、少なくとも１つの概念関係を含み、
（ｃ）前記次元軸の第２の集合を定める前記概念の集合及び前記概念関係の第２の集合を表す新たな複雑なデータ構造を合成する或いは合成するのを容易化することを含む、
コンピュータプログラム格納媒体。

【請求項16】

請求項１５に記載のコンピュータプログラム格納媒体であって、前記作用（ｂ）は、前記ソースデータ構造のファセット及び／又はファセット属性を発見するために、前記ソースデータ構造を分析する或いは分析するのを容易化することを含む、コンピュータプログラム格納媒体。

【請求項17】

請求項１５に記載のコンピュータプログラム格納媒体であって、前記次元軸の第２の集合は、前記次元軸の第１の集合と異なり且つ／或いは前記次元軸の第１の集合よりも数値的に大きいコンピュータプログラム格納媒体。

【請求項18】

請求項１６に記載のコンピュータプログラム格納媒体であって、前記次元軸の第２の集合は、発見されるファセット及び／又はファセット属性を共有する概念の間の概念関係によって定められる、コンピュータプログラム格納媒体。

【請求項19】

請求項１５に記載のコンピュータプログラム格納媒体であって、前記次元軸の第２の集合は、前記ソースデータ構造の分析を通じて発見されるファセット属性の集合と等しい必要のない属性の集合からの属性を共有する概念の間の概念関係によって定められる、コンピュータプログラム格納媒体。

【請求項20】

請求項１５に記載のコンピュータプログラム格納媒体であって、前記方法は、複雑適応処理を通じて前記新たなデータ構造を変更するために、ユーザインタラクションフィードバックを前記作用（ｂ）に提供する或いは提供するのを容易化することを更に含む、コンピュータプログラム格納媒体。

【請求項21】

請求項１５に記載のコンピュータプログラム格納媒体であって、前記少なくとも１つの既存の複雑なデータ構造は、少なくとも１つの関係データベースから引き出される、コンピュータプログラム格納媒体。

【請求項22】

請求項１５に記載のコンピュータプログラム格納媒体であって、前記作用（ｂ）は、前記ソースデータ構造を処理する或いは処理するのを容易化するのに形態素辞書を用いることを含む、コンピュータプログラム格納媒体。

【請求項23】

請求項１に記載のコンピュータによって実現される方法であって、前記ソースデータを処理すること或いは処理するのを容易化するステップは、変換エンジンで遂行される、方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、消費者定義の情報アーキテクチャ用のシステム、方法およびコンピュータプログラムに関する。さらに詳細には、本発明は、情報を分類するためのシステム、方法およびコンピュータプログラムに関する。本発明はさらに、情報の特定のドメイン用の分類構造を合成するためのシステム、方法およびコンピュータプログラムに関する。

【背景技術】

【0002】

ファセット分類は、情報が多次元品質を有し、多くの異なる方法で分類されることができるという原理に基づいている。情報ドメインのサブジェクトは、この次元数を表すためにファセットに再分割される。ドメインの属性は、ファセット階層に関連付けられる。ドメイン内の素材が次に、これらの属性に基づいて識別および分類される。

【0003】

図１は、（たとえば）ワインの分類に適用するときに、従来技術におけるファセット分類の一般的手法を示している。

【0004】

ファセット分類は、分析および合成の両方の処理を伴うため、分析合成型分類法として周知されている。ファセット分類用の体系を考案するためには、情報ドメインが分析されて、それらの基本的なファセットを決定する。分類は次に、これらのファセットの属性をドメインに適用することによって、合成（または構築）されてもよい。

【0005】

多くの研究者は、インターネット上などの情報の大量の蓄積を組織化するための理想的な方法としてファセット分類を見なしてきた。ファセット分類は、我々の急激に変化する動的情報に適用可能である。さらに、サブジェクトをファセットに再分割することによって、情報にアクセスするための複数の多様な方法を提供する。

【0006】

しかし、分類の需要に対処するためのファセット分類の可能性にもかかわらず、その導入は、遅くなっている。インターネット上の大量の情報に対して、ファセット分類を用いているドメインは、ほとんどない。それどころか、その使用は、特定の垂直的な用途（電子商取引店および図書館など）の中に区分されている。ファセット分類は依然として、一般的に、研究者、専門的な分類学者および情報アーキテクトの範疇にある。

【0007】

ファセット分類の導入に対する障壁は、その複雑さにある。ファセット分類は、きわめて労働集約的かつ知的にやりがいのある試みである。この複雑さは、情報の規模と共に増大する。規模が増大すると、次元（またはファセット）の数が、ドメインの中で増大して複雑になり、組織化をますます困難にする。

【0008】

この複雑さに対処するのを助けるために、研究者は、ファセット分類に関する規則および指針を考案している。この研究団体は、現在の予測およびデータ分析の出現よりずっと前に、数十年前に遡っている。

【0009】

つい最近になって、技術は、ファセット分類のサービスを豊富にしている。全般的に見て、この技術は、歴史的分類法および組織化原理の中で適用されている。従来の方法によって制限され、ファセット分類の完全自動化された方法を提供する試みは一般的に、挫折している。

【0010】

最新技術が示しているように、自動カテゴリ化およびファセットナビゲーションシステムは、ＥＮＤＥＣＡ（商標）である。ＥＮＤＥＣＡは、情報カテゴリ化およびアクセスシステム産業において製品の優秀さのリーダとして認識されている。［ｈｔｔｐ：／／ｗｗｗ．ｕｓａｔｏｄａｙ．ｃｏｍ／ｔｅｃｈ／ｐｒｏｄｕｃｔｓ／ｃｎｅｔ／２００７−０６−２９−ｅｎｄｅｃｅ−ｇｏｏｇｌｅ＿Ｎ．ｈｔｍ］
ＥＮＤＥＣＡの技術は、誘導ナビゲーションと、データおよび文書の次元のほか、次元の中に関係を格納するメタ関係インデックスと、を用いる。たとえば、２００６年６月１３日出願の「Ｈｉｅｒａｒｃｈｉｃａｌ
ｄａｔａ−ｄｒｉｖｅｎ ｓｅａｒｃｈ ａｎｄ ｎａｖｉｇａｔｉｏｎ
ｓｙｓｔｅｍ ａｎｄ ｍｅｔｈｏｄ
ｆｏｒ ｉｎｆｏｒｍａｔｉｏｎ ｒｅｔｒｉｅｖａｌ」、２００６年４月２５日出願の特許文献２：「Ｈｉｅｒａｒｃｈｉｃａｌ
ｄａｔａ−ｄｒｉｖｅｎ ｓｅａｒｃｈ ａｎｄ ｎａｖｉｇａｔｉｏｎ
ｓｙｓｔｅｍ ａｎｄ ｍｅｔｈｏｄ
ｆｏｒ ｉｎｆｏｒｍａｔｉｏｎ ｒｅｔｒｉｅｖａｌ」である。

【0011】

ＥＮＤＥＣＡのシステムは、タクソノミ定義および分類として企業によって定義されるカテゴリ化手法を含む。２００６年６月１３日出願の「Ｈｉｅｒａｒｃｈｉｃａｌ
ｄａｔａ−ｄｒｉｖｅｎ ｓｅａｒｃｈ ａｎｄ ｎａｖｉｇａｔｉｏｎ
ｓｙｓｔｅｍ ａｎｄ ｍｅｔｈｏｄ
ｆｏｒ ｉｎｆｏｒｍａｔｉｏｎ ｒｅｔｒｉｅｖａｌ」参照。

【0012】

自動カテゴリ化技術の現状は、最も際立って用いられており、業界通が「構造化データリポジトリ」および「マネージドコンテンツリポジトリ」と呼ぶものにとって有用である。

【0013】

自動カテゴリ化技術の現状の別の制限は、カテゴリ化の態様の認識を要求するためのヒューマンベースのフィードバックが欠如していることである。たとえば、ＥＮＤＥＣＡは、探索結果の表示および優先度を駆動するための利用人気をはじめとするファセットナビゲーション用のフィードバックループを有するが、コンテンツの意味論的定義および意味論的関係を改善するために利用に基づくフィードバックループを有していない。

【0014】

ハイブリッドカテゴリ化システムの別の主なカテゴリは、大規模なコラボレイティブカテゴリ化と表現されてもよい。この手法は、手動カテゴリ化の認識の利点を自動システムの処理能力と組み合わせようと試みている。この新興分野におけるコラボレイティブカテゴリ化システムは、種々の名前「ウェブ２．０」、「コラボレイティブカテゴリ化」、「フォクソノミ」、「ソーシャルインデクシング」、「ソーシャルタギング」、「集団的知性」などの種々の名前で呼ばれる。ＦＬＩＣＫＲ（商標）（写真共有コミュニティ）、ＤＥＬ．ＩＣＩＯ．ＵＳ（商標）（ソーシャルブックマークマネジャ）およびＷＩＫＩＰＥＤＩＡ（商標）（ウィキベースのコラボレイティブ百科事典）が、コラボレイティブカテゴリ化のこの新興カテゴリの実施例である。

【0015】

種々の割合において、これらのシステムは、広範囲で分散型コラボレーション用の枠組みを提供するための技術を用い、コラボレータがカテゴリ、概念および関係に関して決定を行なうことを可能にする。この手法に対する１つの課題は、話題の指針および分類の専門家とコンテンツに対してきわめて異なる観点およびカテゴリ化の手法を有することが多い一般人のエンドユーザの入力との間の不調和を形成することである。これらのシステムは、曖昧さおよび一貫性のなさの範囲を特定し、コラボレータの中で競合する意見を強調することによって、人々が協同的になるのを助けることができる。しかし、最終的に、コラボレイティブシステムを用いて、人々は好ましくは、それらの差異を調和させ、用語の最もとらえどころのないことに対して広く合意に達する必要がある。したがって、このプロセスは、大きなさまざまな情報ドメインにわたって拡大縮小して適用することが困難である。

【0016】

コラボレイティブカテゴリ化手法の主要な実施例は、Ｍｅｔａｗｅｂ
Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．であり、コラボレイティブカテゴリ化手法を用いてウェブおよび他の複雑な種々の情報環境にわたって探索可能なデータベースを作成することによって、広範囲で公開情報ドメインを分類することを目的としている。

【0017】

Ｍｅｔａｗｅｂ
Ｔｅｃｈｎｏｌｏｇｉｅｓは、セマンティックウェブを作成するためのその先駆的なコラボレイティブ手法に関して多くの注目を集めてきた。Ｍｅｔａｗｅｂ
Ｔｅｃｈｎｏｌｏｇｉｅｓは、米国特許商標局に２つの特許出願を申請している（２００５年４月２１日出願の「Ｋｎｏｗｌｅｄｇｅ
ｗｅｂ」、および２００３年１０月１６日出願の「Ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ
ｆｏｒ ａｕｔｈｅｎｔｉｃａｔｉｎｇ ｔｈｅ
ｃｏｎｔｅｎｔ ｏｆ ａ
ｄｉｓｔｒｉｂｕｔｅｄ ｄａｔａｂａｓｅ」）。

【0018】

Ｍｅｔａｗｅｂ
Ｔｅｃｈｎｏｌｏｇｉｅｓのコラボレイティブオントロジ構築は、そのコラボレイティブカテゴリ化のための「群集の英知」に依存している。これに関して、エンドユーザは、皆が用いることができる複数のスキーマを定義して拡大する。有名な業界ウォッチャＥｓｔｈｅｒ
Ｄｙｓｏｎによれば、「Ｍｅｔａｗｅｂの作成者は、関係がどのように指定されるかの文法を『知的に設計した』が、英知（または特定の知識）や群集の努力に左右され、特定のデータだけでなく特定のものの間の特定の種類の関係も含む実際のコンテンツを作成している。［Ｒｅｌｅａｓｅ
０．９：Ｍｅｔａｗｅｂ−Ｅｍｅｒｇｅｎｔ Ｓｔｒｕｃｔｕｒｅ ｖｓ． Ｉｎｔｅｌｌｉｇｅｎｔ
Ｄｅｓｉｇｎ、２００７年３月１１日、ｈｔｔｐ：／／ｗｗｗ．ｈｕｆｆｉｎｇｔｏｎｐｏｓｔ．ｃｏｍ／ｅｓｔｈｅｒ−ｄｙｓｏｎ／ｒｅｌｅａｓｅ−０９−
ｍｅｔ＿ｂ＿４３１６７．ｈｔｍｌ］。この手法の制限は、データベース範囲および品質が、そのユーザによって入力される意味的関連性の有るコンテンツによって制約されることにある。この手法はまた、特定のデータ要素について合意し、コンテンツ内の関係を指定し、冗長度を削減して、その結果、データベースが確定情報を含むようにする専門家および一般人の能力に左右される。

【先行技術文献】

【特許文献】

【0019】

【特許文献1】米国特許第７，０６２，４８３号

【特許文献2】米国特許第７，０３５，８６４号

【特許文献3】米国特許出願第２００５００８６１８８号

【特許文献4】米国特許出願第２００３０１９６０９４号

【発明の概要】

【発明が解決しようとする課題】

【0020】

したがって、自動ファセット分類、自動カテゴリ化および大規模コラボレイティブ分類における業界の現状に関して多くの不都合がある。この技術は、従来の方法の中で適用されるか、または従来の方法に基づいている。情報の構造に対する基本的な変更に影響を及ぼす、増強された分類方法が、必要とされる。

【0021】

ファセット分析の場合には、人間の認知の入力が一般的に必要とされる。すべての情報ドメインにわたって働くファセット分析の場合には、普遍的パターンまたは経験則がないためである。現在、人間のみが広範囲なパターン認識技能を備えている。残念なことに、構造パターン（意味的構造または構文構造など）は一般的に、分類されるべき情報の全体ドメインの中で特定される必要があり、ファセットおよび属性を特定してもよい多くの異なるパターンがある。人々は、小さな（局所的な）データ集合におけるこれらのパターンを特定するように訓練されることができるが、ドメインのサイズが増大すると、タスクは、きわめて困難となる。

【0022】

分析処理および合成処理の予測の必要性が人間の認知能力を超えると、人間の関与による制限もまた導入される。人間は、小規模で情報要素間の関係を評価するのに熟達しているが、集合体の中の全体ドメインにわたって複雑さを管理することができない。システムは、情報の全体ドメインにわたる小さな局所的な人間の入力を集合させることができる。

【0023】

ファセット分類体系は、複数の視点をよく引き合いに出される利点にすることを可能にする。残念なことに、これらの視点が複数の階層にわたって断片化されるとき、直観的に認知されない。これは、可視化、統合および全体的な視点の深刻な問題を引き起こす。構造におけるファセット（または次元）の数が増大すると、可視化は、ますます困難になる。したがって、ファセット分類体系の可視化は、「平坦」、すなわち一次元の結果集合と化し、構造は一度に１つのみのファセットにわたって誘導される。この種の単純化は、基礎を成す構造の強烈な複雑さを緩和する。

【0024】

統合された十分に記述的な階層の中で、ファセット体系の表現力および柔軟性を組み合わせる方法および技術が、必要とされる。さらに、この柔軟性は、組織化基盤としてのファセットの動的構成において、分類体系自体の基本的レベルまで最適に下方に延びる。

【0025】

一旦選択されると、ファセット自体は、静的であり、訂正することが困難である。これは、ファセット体系の展開における相当の危険性を表す。分類者は、情報ドメインの完全な知識がかけていることが多く、したがって、これらの組織化基盤の選択は、エラーを生じる傾向がある。分類の動的システムの下で、これらの危険性は、基礎を成すファセットの追加または変更を容易にすることができる能力によって低減されるであろう。分類および派生技術の従来の方法は、この基本的レベルにおいて柔軟性に欠ける。

【0026】

任意の分類システムはまた、動的環境におけるメンテナンス要件を考慮してもよい。ドメインにおける素材が変化するときには、その結果、分類が調整してもよい。メンテナンスは、ファセット分類体系の初期の展開よりさらに一層困難な難題を課すことが多い。専門用語は、出現して変化するときに更新されなければならない。ドメインにおける新たな素材は一般的に、評価されて記録されることを必要とする。ファセットおよび属性の構成は一般的に、発展しつつある構造を含むように調整されることを必要とする。全く新しい分類を支持して、既存のファセット分類が簡単に破棄されることは何度もある。

【0027】

混成システムは、分析、合成およびメンテナンスの主要段階で人間を関与させる。プロセスにおいて初期に関与するのは、人間が分類の取り組みの進行を妨げることが多い。したがって、プロセスは、依然として遅くてコストがかかる。中央制御および権限を必要としないさらに分散されたその場しのぎの態様において、人々から分類データを許容するシステムが必要とされる。これらのシステムは、暗黙のフィードバックメカニズムを支援する可能性があり、情報アクセスおよび情報消費の純粋な活動は、分類体系のメンテナンスおよび成長に関する積極的支援を提供する。

【0028】

プロセスを案内するために、混成システムは、ファセット分類の既存の普遍的な体系に基づくことが多い。しかし、これらの普遍的な体系は、情報の大量かつ高速に進化する現代世界に常に当てはまるとは限らない。個々のドメインの必要性に特殊化した専用の体系に対する需要がある。

【0029】

ファセット分類の普遍的な体系が、普遍的に適用されることができないため、情報の異なるドメインを共に接続することに対する需要もある。しかし、解決策は、ドメインを統合するための機会を提供すると同時に、個々のドメインオーナのプライパシおよびセキュリティを尊重するべきである。

【0030】

本発明者らの分類の需要の全体規模は、コラボレータの大きなグループが関与する広範囲の分散化された環境において管理されることができるシステムを必要とする。しかし、分類は、意味合いおよび曖昧さを伴う複雑な概念を扱う。これらの曖昧さおよび不一致を解消することは、集中的なネゴシエーションおよびパーソナルな不一致に関与し、さらに小さなグループにおけるコラボレーションを狂わせる。
［優先権］
本出願は、２００６年８月３１日出願の米国特許出願第１１／４６９，２５８号、２００６年１０月１８日出願の米国特許出願第１１／５５０，４５７号および２００７年１月２２日出願の米国特許出願第１１／６２５，４５２号の利益を主張する。

【課題を解決するための手段】

【0031】

本発明の第１の態様において、フィードバックエージェントからの入力に基づいて含むデータ構造を組織化および管理するための方法が、提供され、この方法は、（ａ）情報のドメインに適用可能であるファセット分類のための方法であって、（ｉ）上記のドメインのファセット分析またはドメインのファセット分析の結果の受信と、（ｉｉ）上記のドメインのファセット分類合成の適用を含む、ファセット分類の上記の方法と、（ｂ）上記のファセット分類合成から１つまたは複数の反復時に、情報を選択して返すための複雑適応方法であって、上記の返された情報に応じて、データ構造の組織化および管理を変化させる、複雑適応方法とを含む。

【0032】

本発明の別の態様において、情報のドメインのファセット分類のための方法は、（ａ）情報を分類するために、ファセット属性を含むファセットデータ集合を提供し、そのようなファセット属性は、ファセット属性用のファセット属性階層を任意に含むようにし、（ｂ）次元概念タクソノミを提供して、ファセット属性が、オブジェクトに意味を関連付ける概念に基づいて分類されることになっているドメインのオブジェクトにファセット属性が割り当てられるようにし、上記の概念は、上記のファセット属性を用いて定義される概念定義によって提示され、次元概念タクソノミにおけるオブジェクトに関連付けられる、上記の次元概念タクソノミは、ファセットデータ集合に基づいて、概念定義間の次元概念関係を表し、（ｃ）次元概念タクソノミ情報に応じてファセットデータ集合および次元概念タクソノミを変化させて、次元概念タクソノミ情報を選択して返すための複雑適応システムを提供するか、または有効にする。

【0033】

本発明のさらに他の態様において、情報のドメインのファセット分類のための方法はさらに、ファセット分類合成を行なって、ファセット属性と、任意にファセット属性階層と、を含むファセットデータ集合に基づいて定義される概念定義によって表される概念の集合に関連させることを含み、上記のファセット分類合成は、概念定義間の次元概念関係を表すことを含み、２つの概念定義は、２つの概念定義のそれぞれのファセット属性間のファセットデータ集合に存在する明確な関係および暗黙の関係のうちのいずれか少なくとも１つを調べることによって、特定の次元概念関係に関連付けられるように決定される。

【0034】

本発明のさらに別の態様において、ソースデータ構造による情報のドメインから選択される入力情報のファセット分析を行なうためのコンピュータシステムが、提供され、コンピュータシステムは、（ａ）パターン増加および統計的分析を用いて、入力情報におけるファセット属性関係のパターンを特定するために、入力情報のファセット属性と、任意にファセット属性階層を導出するように動作可能である。

【0035】

本発明の別の態様において、ユーザが次元概念関係を操作することを可能にするためのコンピュータシステムが、提供され、コンピュータシステムは、（ａ）プロセッサと、（ｂ）プロセッサとのデータ通信におけるコンピュータ可読媒体と、を含み、コンピュータ可読媒体は、その上に、プロセッサによって実行可能な命令および特定の次元概念関係に関連付けられるように決定される複数のデータ要素と、を含み、（ｃ）外部エンティティをプロセッサとインターフェイスを取ることを可能にするように構成される入力ユーティリティと、（ｄ）少なくとも選択されたデータ要素の可視表現を提供するように動作するディスプレイと、（ｅ）外部エンティティがデータ要素および特定の次元概念関係を改訂可能にするエディタと、を含む。

【0036】

本発明のさらに別の態様において、フィードバックエージェントからの入力に基づくことを含むデータ構造を組織化および管理するためのシステムが、提供され、（ａ）システムは、次元概念タクソノミ情報に応じて、ファセットデータ集合および次元概念タクソノミを変化させるために、次元概念タクソノミ情報を選択して返すための複雑適応システムを含むか、または連結され、（ｂ）システムは、ファセット、ファセット属性および任意にファセット属性階層を含むファセットデータ集合を処理して、情報を分類するように動作可能であり、（ｃ）システムはさらに、次元概念タクソノミを定義するように動作可能であり、オブジェクトに意味を関連付ける概念に基づいて分類されることになっているドメインのオブジェクトにファセット属性が割り当てられるようにし、上記の概念は、上記のファセット属性を用いて定義される概念定義によって提示され、次元概念タクソノミにおけるオブジェクトに関連付けられる、上記の次元概念タクソノミは、ファセットデータ集合に基づいて、概念定義間の次元概念関係を表す。

【0037】

本発明は、図面を参照してよりよく理解されるであろう。本願明細書に含まれる図では、三角形の形状が、比較的簡単なデータ構造を表すために用いられており、ピラミッド形状が、より高次の次元を具体化する比較的複雑なデータ構造を表すために用いられていることに留意されたい。三角形およびピラミッド型の種々のサイズは、圧縮および展開の変換を表すが、圧縮または変換の正確な規模を少しも示しているわけではなく、または圧縮または変換の正確な規模を制限しているわけでもない。

【0038】

明細書に組み込まれ、その一部を構成する添付図面は、種々の実施例のシステム、方法などを示しており、本発明の態様の種々の事例の実施形態を示している。図に示された要素の境界（たとえば、ボックス、ボックスのグループまたは他の形状）は、境界の一例を表すことは十分に認識されよう。当業者は、１つの要素が複数の要素として設計されてもよく、または複数の要素が１つの要素として設計されてもよいことは認識されよう。別の要素の内部構成要素として示される要素は、外部構成要素として実装されてもよく、その逆であってもよい。さらに要素は、等倍で描かれていない可能性がある。

【図面の簡単な説明】

【0039】

【図1】従来技術のファセット分類の方法を示す概略図である。

【図2】ドメインに関する次元概念タクソノミを作成するために、データ構造変換を示すオペレーションの概観を示す。

【図3】図２のオペレーションに関して有用な知識表現モデルを示す。

【図4】図２のオペレーションの概観をさらに詳細に示す。

【図5】入力データを抽出する方法を示す。

【図6】ソース構造分析方法を示す。

【図7】予備概念−キーワード定義を抽出するプロセスを示す。

【図8】形態素を抽出する方法を示す。

【図9】概念関係から潜在的形態素を予測するプロセスを示す。

【図10】概念関係から潜在的形態素を予測するプロセスを示す。

【図11A】潜在的形態素関係の集合から形態素関係の複数階層を組み立てるプロセスを示す。

【図11B】潜在的形態素関係の集合から形態素関係の複数階層を組み立てるプロセスを示す。

【図12】潜在的形態素関係の集合から形態素関係の複数階層を組み立てるプロセスを示す。

【図13】潜在的形態素関係の集合から形態素関係の複数階層を組み立てるプロセスを示す。

【図14A】属性の方法を用いた厳格な階層への形態素複数階層の並べ替えを示す。

【図14B】属性の方法を用いた厳格な階層への形態素複数階層の並べ替えを示す。

【図15】属性の方法を用いた厳格な階層への形態素複数階層の並べ替えを示す。

【図16A】形態素階層およびキーワード階層からのサンプル断片を示す。

【図16B】形態素階層およびキーワード階層からのサンプル断片を示す。

【図17】次元概念タクソノミを構成するために用いるための出力データを準備する方法を示す。

【図18】オペレーションが要素構成要素から次元概念を生成する態様を示す。

【図19】次元概念タクソノミを生成するために、どのようにオペレーションが次元概念関係を組み合わせるかを示す。

【図20】どのようにファセット出力データが、次元概念タクソノミを構成するために用いられるかを示す。

【図21】どのようにファセット出力データが、次元概念タクソノミを構成するために用いられるかを示す。

【図22】どのようにファセット出力データが、次元概念タクソノミを構成するために用いられるかを示す。

【図23】局所的なドメイン集合用に構築される次元概念タクソノミを示す。

【図24】動的合成のモードを示す。

【図25】動的合成用の候補集合の集合方法を示す。

【図26】次元概念タクソノミ内のコンテンツコンテナを編集するユーザインタラクションのプロセスを示す。

【図27】複雑適応システムにおけるユーザインタラクションの集合およびフィードバックループを示す。

【図28】パーソナライズ化のオペレーションを示す。

【図29】機械に基づく複雑適応システムのオペレーションを示す。

【図30】実施形態によるオペレーションを実行するためのシステムに関する予測環境およびアーキテクチャ構成要素を示す。

【図31】一実施形態における簡略化されたデータスキーマを示す。

【図32】データ構造変換のオペレーションを実行するために、一実施形態によるシステム概要を示す。

【図33】一実施形態において用いられるファセットデータ構造と、これらの構造を支援する多層アーキテクチャと、を示す。

【図34】ブラウザに基づくユーザインターフェイスにおける次元概念タクソノミの図を示す。

【図35】動的合成のモードを容易にするためのブラウザに基づくユーザインターフェイスを示す。

【図36】アウトライナに基づくユーザインターフェイスにおけるユーザインタラクション用の環境を示す。

【図37】本発明によるファセット分類情報の態様の操作を可能にするコンピュータシステムの代表的な実装を示す。

【発明を実施するための形態】

【0040】

［システムオペレーション］
詳細な説明は、本発明のいくつかの態様の１つまたは複数の実施形態を詳述する。

【0041】

詳細な説明は、以下に記載される見出しおよび小見出しに分割される。
（１）「本発明の一般的な説明」−情報分類の技法を一般的に記載され、そのような技法に関する本発明も含み、さらに、本発明の目的および利点のいくつかを一般的に記載する。
（２）「システムオペレーション」−本発明を実行する際に含まれるステップを一般的に記載する。小節「オペレーションの概要」は、システムを含む構成要素のいくつかを一般的に記載する。小節「ファセット分析の方法」は、本発明のファセット分析構成要素を一般的に記載する。小節「ファセット分類合成の方法」は、本発明の静的合成構成要素および動的合成構成要素の両方を含む本発明のファセット合成構成要素を一般的に記載する。小節「複雑適応フィードバックメカニズム」は、種々のユーザインタラクションに対する本発明の応答を一般的に記載する。
（３）「実装」−本発明によって動作可能に構成される代表的な実施形態を一般的に記載する。小節「システムアーキテクチャ構成要素」は、本発明の可能な実施形態を一般的に記載する。小節「データモデルおよびスキーマ」は、データが本発明によって変換される方法を一般的に記載する。小節「次元変換システム」は、本発明のわずか一つの可能な実施形態で生じるように、本発明のシステムのオペレーションを一般的に記載する。以下の小節、すなわち「多層データ構造」、「分散型予測環境」、「ＸＭＬスキーマおよびクライアント側の変換」、「ユーザインターフェイス」は、本発明の代表的な実装について言及する。
［本発明の一般的な説明］
従来技術における制限および欠点を踏まえて、本願明細書に記載する難題および問題に対処するために、情報アーキテクチャの構成的かつコラボレイティブシステムの特定の要件を特定することができる。したがって、本発明の複数の目的および利点は、以下の点に要約される。これらの目的または利点は、限定的であり、本発明のいくつかの態様およびその考えられる利点および長所を示すためだけに作用する。

【0042】

本発明の一態様において、本発明のシステムは、最適な情報構造を構成する基礎的なレベルで動作する。既存のカテゴリ化、探索および可視化の解決策の大多数が、不備のある構造的基盤に対する寄せ集めであり、したがって、本質的に制限される。本発明のシステムは、複雑な情報構造に関する存在論的な分類枠組みであるが、実装に対する実際の経路を提供する。今日、情報の展望を支配する従来技術の単純で平坦な構造とは対照的に、本発明のシステムは、その一態様において、複雑な構造を支援する。

【0043】

本発明のシステムは、関連情報のための最も馴染みのある堅牢なモデルとして、概念階層を支援する。（「複数階層」なる語は、次元性および概念階層の中心的な要件を組み合わせる構造モデルを記載する。）しかし、本発明のシステムは、その一態様において、概念階層、タクソノミおよびオントロジ構成を困らせるパーソナルとコラボレイティブとのネゴシエーションを緩和する。本発明のシステムはまた、異なる情報ドメインからの階層を連結するための信頼性の高いメカニズムを提供するものとする。

【0044】

本発明のシステムは、その一態様において、次元空間内の種々の交差点で、構造的な完全性を提供する。これは、ノードとノード間の連結および接続との両方において現れる情報間隙の問題を排除することによって対処されてもよい。

【0045】

本発明のシステムは、その一態様において、文脈の不可欠な認知構成要素を提供するために人間を関与させる。機械は、発見およびコラボレーションのための有用なツールを提供するが、機械は、複雑な知識を「理解する」ために必要な人工知能を備えていない。したがって、本発明のシステムは、その一態様において、人間にとって馴染みがあって利用しやすい態様で、人間と関わる。

【0046】

本発明のシステムは、巨大な情報ドメインにおける次元構造および概念ポリアーキの著しい複雑さを管理し、概念記述および関係におけるコラボレータ間の合意を仲立ちさせるために、機械を関与させる。

【0047】

本発明のシステムは、その一態様において、コラボレーションにおける専門技術を持たない一般人に対応する。専門家のアーキテクトの不足および問題の範囲は、解決策に対する普遍的に利用できることを要求する。本発明は、技術的な利点を妥協することなく、次元構造の複雑さから人々を保護してもよい。

【0048】

本発明のシステムは、巨大な分散型並列処理を支援するように動作可能である（「人手が多ければ仕事は楽になる」）。情報の展望のサイズおよび複雑さは一般的に、現在、実際には不変であるように見える処理に物理的制限を課す。巨大かつ分散型の並列性は、多くの場合には、これらの制限に挑むことが好ましい。

【0049】

本発明のシステムは、その一態様において、無限の情報および知識の物理的制限を回避することができる合成オペレーションを支援するように動作可能である。本発明のシステムは、その一態様において、事実上無制限の数のデータ接続に関する可能性を符号化する能力を情報の消費者によって要求されるまで、それらのデータ接続を実際に生成することを必要とすることなく提供する。さらに、本発明のシステムは、その一態様において、消費者の規定した関心および視点に適合するデータ接続のみが存在するように、合成の種々のモードを提供してもよい。

【0050】

本発明のシステムは、その一態様において、情報の展望のダイナミズムを支援して包含する。本発明のシステムは、ある時点におけるような情報の静的スナップショットではなく、情報と共に適合して発展することができる構造を提供する。

【0051】

本発明のシステムは、コスト効率が高い。探索コストは、情報過多および情報の不規則な広がりに対する解決策を求めようとする多大な動機を提供するが、組織的プロジェクトは、自由裁量権を有しているわけではない。より構造化されたインターネットに対する障害は、既存の技術および方法を用いて、それを組織化する法外なコストである。これらの組織化コストは、金銭面だけではなく、人間の観点およびコンピュータ処理限界にもかかわる。

【0052】

本発明のシステムは、その一態様において、明確かつプライベートかつきわめてパーソナライズ化された知識リポジトリを維持するための機会を有するシステムのドメインオーナおよびエンドユーザを提供すると同時に、集団的知性および集中型知識資産の長所を共有する。

【0053】

本発明は、その一態様において、構造的関係、テキストおよびマルチメディアなどのディジタル媒体、メッセージングおよび電子メール、商業、人間の双方向性およびコラボレーションの多くの形態をはじめとする複数の情報形態を管理し、ウェブサイトおよびソフトウェアクライアントを含む種々の媒体にわたって構造的情報を出力するための、分散型システムをエンドユーザに提供することができる方法およびシステムを提供する。

【0054】

さらなる目的および利点は、次の説明および図面を考慮すれば明白となるであろう。
［システムオペレーション］
［オペレーションの概要］
図２、図３、図１８、図１９、図３２、図３３および図４は、ドメインに関する次元概念タクソノミを作成するなどの複雑な次元情報構造を構成して管理するためのオペレーションおよびシステムの概要を提供する。特に、図２、図３、図１８、図１９、図３２、図３３および図４は、そのようなオペレーションに有用な知識表現モデルのほか、一定の次元データ構造および構成を示している。複雑適応システムおよびファセット分類の増強方法をはじめとするデータ構造変換の方法がまた示されている。この説明は、具体的に言えば、知識表現に適用したときのような複雑な次元構造の簡単な概要から始める。
［複雑な次元構造における知識表現］
情報および知識を表すために用いられてもよい抽象化の累進的なレベルがある。「次元」の表記は、複雑さの程度を表現するために用いられることが多い。簡単なリスト（購入リストまたは友人のリスト）は、一次元のアレイとして記載されてもよい。表およびスプレッドシート、すなわち二次元のアレイは、簡単なリストより手が込んでいる。直交座標は、三次元空間などにおける情報を表示してもよい。

【0055】

構造内の各次元は、含まれる情報に関する組織化基盤を確立してもよい。したがって、次元性は、情報構造に関する複雑さの規模を確立してもよい。複雑な構造は、これらの基盤の多くを関与させる可能性があり、ｎ次元構造として特定されることが多い。

【0056】

次元自体の技術的属性が構造間に多種多様性を提供してもよいことに留意することもまた、重要である。たとえば、次元は、変数として存在する可能性があり、したがって、構造は、多変量空間を確立する。モデルのこれらのタイプの下で、ノードは、各次元によって表される変数内の特定の値またはデータ点をとってもよい。あるいは、ノードは、離散変数というよりもむしろ、あまり厳密ではなく、情報用のコンテナを提供するだけに過ぎない場合もある。ノード間の距離は、厳密二量子化というよりもむしろ、相対的であってもよい。技術的属性のこれらのタイプを変化させることによって、関連付けられる構造は、組織化の厳密さと記述の柔軟性との間である程度のバランスに達してもよい。

【0057】

情報構造の中には、すべての交差点においてノードを含んでもよいものもあれば、いくつかの次元の間で、交差点の不完全で欠落したノードがある場合もある。これは、情報構造が手動で構成される場合に、特に関連してくる。構造の複雑さが、人間のアーキテクトの認知能力を超える場合には、情報構造におけるエラーおよび間隙が結果として生じてもよい。

【0058】

一例として、人々が、ワールドワイドウェブなどのネットワーク構造におけるハイパーリンクを作成する場合に、提供するリンクが、所与のドメインの中で稀にしか、大局的でない。ドメインにおけるリンクに関して適切な対象が存在するが、そのリンクが存在しない場合には、これは、情報構造における間隙であると言うことができる。あるいは、情報構造が情報のカテゴリを提供するが、その情報が現在存在しない場合には、構造における間隙でもあってもよい。

【0059】

構造の完全性は、情報構造における間隙によって部分的に記載されてもよい。関係を管理するために基本的な分類システムまたは明確なオントロジがない限り、構造は、ノードのおよび次元の数が増大すると劣化し始める可能性がある。情報間隙は、この劣化の一つの指標である。

【0060】

複雑な構造は、単純な構造よりはるかに多くの情報保持性能を有する。床面を追加することが建物の容積を増大するように、次元を追加することは、構造に含まれてもよい情報の量を増大させる。多次元を支援することなく、情報過多が性能を超えると、負荷を受けて構造は最終的に崩壊する。

【0061】

複雑な次元構造の別の顕著な特徴は、それらの利用しやすさである。平坦な構造は、情報が増大すると、小さな建物からなる郊外地が都市の不規則な広がりを生じるように、不規則に広がる。

【0062】

明らかに、複雑な構造の次元性は、情報過多および情報の不規則な広がりに対する強制的な改善を指摘する。それらに固有の利点によって急速に増大することが期待されるであろう。残念なことに、これはそうではなかった。複雑な構造の採用、特に最も必要とされる一般市民の中では、慎重を期して遅くなっていた。

【0063】

複雑な構造の採用が制限される理由は、明白である、すなわち、それらに固有の複雑さである。これらの明白で基本的かつ構造的な問題に関わらず、複雑な構造を作成して管理するほど十分に堅牢であるが、さらに大量市場導入のために十分に簡単である解決策を依然として提案されなければならない。
［システム方法の概要］
［分析および圧縮］
図２は、分類の主題である情報のコーパスを含むドメイン２００用の次元概念タクソノミ２１０を構築するためのオペレーションを示す。ドメイン２００は、分析および圧縮２０４のプロセスに入力するために、ドメイン２００から導出されるソース構造スキーマおよびソースデータエンティティの集合から構成されるソースデータ構造２０２によって表現されてもよい。分析および圧縮２０４のプロセスは、要素構成要素の集合から構成される要素データ構造である形態素辞書２０６を導出して、新たなファセット分類体系のための基盤を提供してもよい。

【0064】

ドメイン２００における情報は、仮想オブジェクトまたは物理オブジェクト、プロセスおよびそのような情報間の関係に関わってもよい。一例として、本願明細書に記載されるオペレーションは、ウェブページを通じてアクセス可能なコンテンツの分類を対象にしてもよい。ドメイン２００の別の実施形態は、文書リポジトリ、音楽用の推奨システム、ソフトウェアコードリポジトリ、ワークフローおよびビジネスプロセスのモデルなどを含んでもよい。

【0065】

形態素辞書２０６内の要素構成要素は、情報と、集合体の中で、情報保持性能を提供する情報関係と、の基本的構築ブロックの最小集合であってもよく、これを用いて、ソースデータ構造２０２を分類する。

【0066】

［合成および展開］
形態素辞書２０６は、合成および展開２０８の方法に対する入力であってもよい。合成および展開オペレーションは、ソースデータ構造２０２を第３のデータ構造に変換してもよく、この第３のデータ構造は、本願明細書では次元概念タクソノミ２１０と呼ばれる。「タクソノミ」なる語は、カテゴリを階層ツリーに組織化して、カテゴリを文書または他のディジタルコンテンツなどの関連オブジェクトと関連付ける構造を指す。次元概念タクソノミ２１０は、ソースデータ構造２０２から導出された複雑な次元構造において、ドメイン２００からソースデータエンティティをカテゴリ化してもよい。したがって、ソースデータエンティティ（オブジェクト）は、多くの異なる組織化基盤にわたって関わってもよく、多くの異なる視点からソースデータエンティティ（オブジェクト）を見つけることを可能にする。

【0067】

［複雑適応システム］
分類システムおよびオペレーションは、動的環境における変化に適合することが好都合である。一実施形態において、この要件は、複雑適応システム２１２を通じて満たされる。フィードバックループは、次元概念タクソノミ２１０によるユーザインタラクションに通じて、ソースデータ構造２０２に戻るように確立されてもよい。変換のプロセス（２０４および２０８）は、繰り返されてもよく、結果として生じる構造２０６および２１０は、時間を経て精練されてもよい。

【0068】

一実施形態において、複雑適応システム２１２は、出力構造（すなわち、次元概念タクソノミ２１０）を用いるエンドユーザのインタラクションを管理して、分類プロセスにおける人間の認知能力を活かしてもよい。

【0069】

本願明細書に記載されるオペレーションは、比較的簡単なソースデータ構造をより複雑な次元構造に変換しようとして、ソースデータオブジェクトが種々の方法で組織化してアクセスされることができるようにする。情報システムの多くのタイプは、それらの基本的なデータ構造の次元性および複雑さを拡張することによって増強されてもよい。より高い解像度が画像の品質を高めるように、より高い次元性は、データ構造の解像度および特異性を向上してもよい。この増大した次元性は、今度は、データ構造のユーティリティを増強してもよい。増強されたユーティリティは、改善され、より柔軟性のあるコンテンツ発見（たとえば、探索を通じて）、情報検索における改善およびコンテンツの集合を通じて、実現されてもよい。

【0070】

変換は、複雑なシステムによって達成されてもよいため、次元性の増大は、必ずしも線形または予測可能ではない。変換はまた、ソースデータ構造に含まれる情報量に部分的に左右されてもよい。

【0071】

膨大なインターネット規模にシステムを実装するために、キーの差異は、次元情報構造がノードおよび接続の指数関数的に増大する集合に関する可能性を、必要とされるまでそれらの接続を実際に構築する膨大なコストを負担することなく、最適に提供することである。

【0072】

［次元知識表現モデル］
図３は、知識表現エンティティ、関係、図２のオペレーションに用いられてもよい変換の方法を含む知識表現モデルの実施形態を示す。知識表現モデルのさらなる仕様およびその変換方法は、図３、図１８、図１９、図３３および図４を参照して以下の説明に記載される。

【0073】

本発明の一実施形態における知識表現エンティティは、コンテンツノードの集合３０２、コンテンツコンテナの集合３０４、概念の集合３０６（図を簡単にするために、一つの概念のみが、図３には提示されている）、キーワードの集合３０８および形態素の集合３１０である。

【0074】

分類対象のドメインのオブジェクトは、コンテンツノード３０２として周知である。コンテンツノードは、分類に適用可能である任意のオブジェクトから構成されてもよい。たとえば、コンテンツノード３０２は、ファイル、文書、（注釈のような）文書片、画像または文字の格納された文字列であってもよい。コンテンツノード３０２は、物理オブジェクトまたは仮想オブジェクトを参照してもよい。

【0075】

コンテンツノード３０２は、コンテンツコンテナの集合３０４に含まれてもよい。コンテンツコンテナ３０４は、アドレス指定可能な（または位置の特定可能な）情報を提供してもよく、この情報によって、コンテンツノード３０２を検索することができる。たとえば、ＵＲＬによってアドレス指定可能なウェブページのコンテンツコンテナ３０４は、テキストおよび画像の形態で多くのコンテンツノード３０２を含んでもよい。コンテンツコンテナ３０４は、１つまたは複数のコンテンツノード３０２を含んでもよい。

【0076】

概念３０６は、コンテンツノード３０２に関連付けられ、いくつかの意味（コンテンツノード３０２の説明、目的、用途または意図）を抽象化してもよい。個々のコンテンツノード３０２は、多くの概念３０６を割り当てられてもよい。個々の概念３０６は、多くのコンテンツノード３０２にわたって共有されてもよい。

【0077】

概念３０６は、抽象化の合成レベルに関してそれらの関係を通じて、他のエンティティに定義されてもよく、構造的には他のさらに基本的な知識表現エンティティ（たとえば、キーワード３０８および形態素３１０）に関して定義されてもよい。そのような構造は、概念定義として本願明細書において周知である。

【0078】

形態素３１０は、システムによって周知のドメインにわたって現れる最小の意味的知識表現エンティティ（すなわち、形態素辞書２０６を構成するように分析されている）を表す。１つの形態素３１０は、多くのキーワード３０８に関連付けられてもよい。１つのキーワード３０８は、１つまたは複数の形態素３１０から構成されてもよい。

【0079】

さらに、本願明細書との関連において、「形態素」なる語の意味と言語学の分野におけるその従来の定義との間には差異がある。言語学において、形態素は、「言語の意味的最小単位」である。本願明細書との関連において、形態素は、「システムによって周知の任意のドメインにおいて現れる最小の意味的知識表現エンティティ」を指す。

【0080】

キーワード３０８は、形態素３１０の集合（またはグループ）を含む。１つのキーワード３０８は、多くの概念３０６に関連付けられてもよい。１つの概念３０６は、１つまたは複数のキーワード３０８から構成されてもよい。したがって、キーワード３０８は、概念３０６と形態素３１０との間のデータ構造のさらなる段階を表してもよい。キーワード３０８は、ユーザにとって認識可能であるような知識表現の最低のレベルとして「原子概念」を容易にする。

【0081】

概念３０６は、コンテンツノード３０２から抽象化されてもよいため、概念シグネチャ３０５は、概念ノード３０２の中の概念３０６を特定するために用いられてもよい。概念シグネチャ３０５は、コンテンツノード３０２のそれらの特徴であり、コンテンツに存在する組織化テーマを代表している。

【0082】

本発明の一実施形態において、要素構成要素と同様に、コンテンツノード３０２は、最小の形態になる傾向がある。コンテンツコンテナ３０４は、実際と同数のコンテンツノード３０２まで削減されてもよい。本発明における分類のきわめて優れたモードと組み合わせるときに、これらの要素コンテンツノード３０２は、コンテンツ集合およびフィルタリングに関するオプションを拡張してもよい。したがって、コンテンツノード３０２は、次元概念タクソノミにおける任意の次元に沿って再組織化および再組み合わせされてもよい。

【0083】

コンテンツノード３０２の特殊なカテゴリ、すなわち、ラベル（分類業界では「ターム」と呼ばれることが多い）は、各知識表現エンティティにつなげられてもよい。コンテンツノード３０２と同様に、ラベルは、知識表現モデルにおいて記述するそれぞれのエンティティから抽象化されてもよい。したがって、図３において、ラベルの以下のタイプ、すなわち、コンテンツコンテナ３０４を記述するためのコンテンツコンテナラベル３０４ａ、コンテンツノード３０２を記述するためのコンテンツノードラベル３０２ａ、概念３０６を記述するための概念ラベル３０６ａ、キーワードの集合３０８を記述するためのキーワードラベルの集合３０８ａおよび形態素３１０を記述するための形態素ラベルの集合３１０ａが、特定される。

【0084】

図１８において、形態素３１０のサンプルが、提示されている。形態素３１０は、ソースデータから導出された要素構成要素の中であってもよい。要素構成要素の他の集合は、形態素関係の集合から構成されてもよい。形態素が概念定義の要素構築ブロックを表し、概念から導出されるように、形態素関係は、概念間の関係の要素構築ブロックを表し、そのような概念関係から導出される。形態素関係は、以下でさらに詳細に説明され、図９〜図１０に示される。

【0085】

ラベルは、人間にとって認識可能である知識表現エンティティを提供する。一実施形態において、各ラベルは、ソースドメインの固有の語彙から導出される。言い換えれば、各データ要素に割り当てられるラベルは、ドメインに提示される言語およびタームから引き出される。

【0086】

概念、キーワードおよび形態素抽出は、以下に記載され、図７〜図８に示される。概念シグネチャおよびコンテンツノードおよびラベル抽出は、入力データ抽出（図５）を参照して、さらに詳細に以下に説明される。

【0087】

本発明の一実施形態は、エンティティおよびそれらの関係の両方にわたって、多層知識表現モデルを用いる。これは、図１（従来技術）に示されているように、従来のファセット分類における概念−原子概念の２層モデルおよびそれらの平坦な（１層）関係構造とは区別する。

【0088】

オペレーションおよびシステムの一定の態様が、１つの知識表現モデルを参照して記載されるが、当業者は、他のモデルが用いられてもよく、したがって、オペレーションおよびシステムを適合させることを認識されよう。たとえば、概念は、より高次の知識表現エンティティ（考えを含む概念の収集としての「ミーム」など）を作成するために、共に組み合わせられてもよい。代表モデルの構造はまた、縮小されてもよい。たとえば、キーワード抽象化層は、概念が形態素３１０に関してのみ定義されるように除去されてもよい。
［システム変換方法の概要］
図４は、図２に導入される変換オペレーション８００の一実施形態の広汎な概要を示す。
［入力データ抽出］
オペレーション８００は、分類対象のドメイン２００のドメインオーナによる手動の特定から始まってもよい。ソースデータ構造２０２は、ドメイン訓練集合８０２から定義されてもよい。訓練集合８０２は、より大きなドメイン２００の代表的な部分集合であってもよく、代わりとして用いられてもよい。すなわち、訓練集合は、全体ドメイン２００またはその代表的な一部に関するソースデータ構造２０２を含んでもよい。訓練集合は、当業界では公知である。

【0089】

入力データの集合は、ドメイン訓練集合８０２から抽出されてもよい（８０４）。入力データは、要素構成要素を発見して抽出するために分析されてもよい。（このプロセスは、以下でさらに詳細に説明され、図５に示される。）
［ドメインファセット分析およびデータ圧縮］
本実施形態において、上記で紹介され、図３３において説明される分析エンジン２０４ａは、図４の括弧によって示されるように、方法８０６〜８１４によって境界を定められてもよい。入力データは、分析されて処理され（８０６）、ソース構造分析結果の集合を提供してもよい。ソース構造分析結果は、ソースデータ構造２０２の構造特性に関する情報を提供してもよい。このプロセスは、以下でさらに詳細に説明され、図６に示される。

【0090】

予備概念定義の集合が生成されてもよい（８０８）。（このプロセスは、以下でさらに詳細に説明され、図７に示される。）予備概念定義は、キーワード３０８の集合として構造的に表されてもよい。

【0091】

形態素３１０は、予備概念定義においてキーワード３０８から抽出され（８１０）、したがって、抽象化の別のレベルに概念定義の構造を拡張してもよい。（このプロセスは、以下でさらに詳細に説明され、図８に示される。）
形態素階層４０２を構成するプロセスを始めるために、潜在的形態素関係の集合が、予測されてもよい（８１２）。潜在的形態素関係は、入力データにおける概念関係の分析から導出されてもよい。

【0092】

形態素構造分析結果は、潜在的形態素関係に適用され、形態素階層を作成するために用いられる関係を特定してもよい。

【0093】

形態素階層に包含するように選択される形態素関係は、組み立てられ（８１４）、形態素階層４０２を形成してもよい。（このプロセスは、以下でさらに詳細に説明され、図９〜図１５に示される。）
［次元構造合成およびデータ展開］
本実施形態において、上記で紹介され、図３２において説明される構築エンジン２０８ａは、図４の括弧によって示されるように、方法８１８〜８２０によって境界を定められてもよい。ファセット分類の増強方法は、複雑な次元構造２１０ａおよび次元概念タクソノミ２１０を合成するために用いられてもよい。（このプロセスは、以下でさらに詳細に説明され、図２０〜図２２に示される。）
新たな次元構造用の出力データ２１０ａが、準備される（８１８）。出力データは、ドメイン用の分類体系の構造表現である。出力データは、次元概念タクソノミ２１０を作成するためにファセットデータとして用いられてもよい。上記に記載されるように、出力データは、コンテンツノード３０２およびキーワード階層７１０に関連付けられる概念定義７０８を含んでもよい。具体的に言えば、キーワード３０８が、概念定義の形態素３１０に関して定義される場合には、ファセットデータは、概念定義におけるキーワード３０８およびキーワード階層７１０の構造から構成されてもよい。（このプロセスは、以下でさらに詳細に説明され、図１７に示される）
次元概念関係の集合（集合体では複数階層を形成する）が、構成されてもよい（８２０）。次元概念関係は、次元概念タクソノミ２１０における概念関係を表す。次元概念関係は、ファセット分類の増強方法の組織化原理に基づいて、予測されてもよい。次元概念関係は、統合されてもよく、（概念定義において符号化されるような）概念３０６のカテゴリ化の中で次元概念タクソノミ２１０を形成してもよい。（このプロセスは、以下でさらに詳細に説明され、図２０〜図２２に示される。）
合成オペレーションの種々のモードが、ファセット分類の増強方法に関して考えられる。一実施形態において、「範囲制限型」ファセット分類合成オペレーションのシステムが、開示され、概念関係が分析エンジン方法によって完全に処理されなかったか、または全く処理されなかったドメインから合成される。別の実施形態において、「動的」ファセット分類合成のシステムが、開示され、次元概念階層が、情報のエンドユーザに関して提供される合成パラメータに直接的に基づいて、略実時間で処理される。（合成オペレーションのモードは、以下でさらに詳細に説明される。）
［複雑適応システムおよびユーザインタラクション］
本実施形態において、上記で紹介され、図２において説明される複雑適応システム２１２のオペレーションは、図４の括弧によって示されるように、概念タクソノミ２１０に関連して方法２１２ａ、２１２ｂおよび８０４によって境界が定められてもよい。

【0094】

説明されているように、次元概念タクソノミ２１０は、プレゼンテーション層６０８を通じてユーザに表現してもよい。一実施形態において、プレゼンテーション層６０８は、ウェブサイトである。（プレゼンテーション層は、以下でさらに詳細に説明され、図２３〜図２７および図３４〜図３６に示される。）プレゼンテーション層６０８を介して、ドメイン２００におけるコンテンツノード３０２は、各コンテンツノード３０２に関連付けられる概念定義の中でカテゴリ化されたものとして提示されてもよい。

【0095】

このプレゼンテーション層６０８は、次元概念タクソノミ情報として、ユーザインタラクションの集合２１２ａを収集するための環境を提供してもよい。ユーザインタラクション２１２ａは、種々の方法から構成されてもよく、エンドユーザおよびドメインオーナは、次元概念タクソノミ２１０と対話してもよい。ユーザインタラクション２１２ａは、入力データを抽出するためのステップ８０４を通じたフィードバックループを介して、分析エンジンに連結されて、複雑適応システムを可能にしてもよい。（このプロセスは、以下でさらに詳細に説明され、図２７で示される。）
一実施形態において、リソースが有効になるときには、明確なフィードバックループに戻るユーザインタラクション２１２ａは、処理のために待ち行列に入れられてもよい。したがって、暗黙のフィードバックループが、提供されてもよい。暗黙のフィードバックループは、ファセット分類の増強方法の組織化原理の部分集合に基づいて、暗黙の概念関係２１２ｂを予測してもよい。暗黙のフィードバックループを通じて、次元概念タクソノミ２１０とのユーザインタラクション２１２ａは、略実時間で処理されてもよい。
複雑適応システム２１２を通じて、次元概念タクソノミ２１０を導出する分類体系は、連続的に磨かれ、拡張されてもよい。
［ファセット分析の方法］
［入力データを抽出する］
図５は、本発明の１つの特定の態様において、図４を参照して簡単に説明したように、入力データを抽出する（８０４）および一定の予備ステップを抽出するためのオペレーションを含んでもよいオペレーション（９００）を示す。
［構造マーカを特定する］
構造マーカは、入力データが訓練集合から抽出される可能性がある場所を示すために、訓練集合８０２の中で特定されてもよい（９０２）。構造マーカは、ソース構造スキーマを含んでもよい。構造マーカは、コンテンツコンテナ３０４に現れてもよく、これに限定されるわけではないが、文書のタイトル、コンテンツに関連付けられる記述メタタグ、ハイパーリンク、データベースにおける表の間の関係またはコンテンツコンテナに存在するキーワード３０８の普及率を含んでもよい。マーカは、ドメインオーナまたはその他のものによって特定されてもよい。

【0096】

オペレーション９００は、ドメインにわたって適用するデフォルトの構造マーカを用いて設定されてもよい。たとえば、ウェブページのＵＲＬは、コンテンツノード３０２用の共通の構造マーカであってもよい。したがって、オペレーション９０２は、ソース構造スキーマにおける領域において任意の明確な参照がない場合に適用されるであろう多数のデフォルト構造パターンを用いて設定されてもよい。

【0097】

構造マーカは、入力データの位置を明確に特定してもよく、または入力データ用の代わりとしての位置を特定してもよい。たとえば、コンテンツノード３０２間の関係は、概念関係用の代わりの構造マーカとして用いられてもよい。

【0098】

一実施形態において、構造マーカは、ソース構造スキーマに関する論理的推測を生成するために組み合わせられてもよい。概念関係が、ソース構造スキーマにおいて明確でない場合には、コンテンツノード３０２に関連付けられる概念シグネチャおよびコンテンツノード関係の集合などの構造マーカから推測されてもよい。たとえば、概念シグネチャは、さらに説明されるように定義対象の概念の代わりとしてマッピングされる文書のタイトルであってもよい。コンテンツノード関係は、ウェブページを接続するハイパーリンクなどのコンテンツノード３０２間の構造的連結から導出されてもよい。

【0099】

コンテンツノード３０２への概念シグネチャの接続および他のコンテンツノード３０２へのコンテンツノード３０２の接続が、交差する概念の中の概念関係を推測してもよい。これらの関係は、さらなる（明確な）入力データを形成してもよい。
当業者にとって周知であるように、構造マーカを特定するための多くの異なる方法がある。
［システム入力スキーマへのソース構造スキーマをマッピングする］
ソース構造スキーマは、入力スキーマ９０４にマッピングされてもよい。一実施形態において、入力スキーマは、概念シグネチャの集合９０６、概念関係の集合９０８および概念ノードの集合３０２から構成されてもよい。

【0100】

このスキーマ設計は、変換プロセスを代表しており、限定することを意図しているわけではない。入力オペレーションは、きわめて単純な構造に適応するようにするために、システム入力スキーマにおけるあらゆるデータ要素にわたってソース入力データを必要としない。

【0101】

システム入力スキーマはまた、システムデータ変換スキーマにおけるあらゆる要素にマッピングするために拡張されてもよい。システムデータ変換スキーマは、変換プロセスにおいて現れるあらゆるデータエンティティに対応してもよい。すなわち、システム入力スキーマは、システムにおけるあらゆるデータエンティティにマッピングするように拡張されてもよい。言い換えれば、ソース構造スキーマは、システム入力スキーマの部分集合から構成されてもよい。

【0102】

さらに、ドメインオーナは、きわめて複雑な構造からソースデータスキーマをマッピングしてもよい。一例として、関係データベースの表および属性は、抽象化の種々のレベルで、ファセット階層としてモデル化され、システムデータ変換スキーマの多層構造にマッピングされてもよい。

【0103】

また、分析エンジン２０４ａおよび構築エンジン２０８ａのオペレーションは、データ構造変換エンジンを提供し、かなり新しいユーティリティは、複雑なデータ構造のあるタイプ（関係データベースにモデル化されるデータ構造）を複雑なデータ構造の別のタイプ（本願明細書に記載される方法およびシステムによって作成される複雑な次元構造）に変換する際に達成されてもよい。製品カタログは、複雑なデータ構造から複雑なデータ構造への変換のこのタイプから恩恵を受ける複雑なデータ構造の実施例を提供する。実施例のデータ変換スキーマにおけるさらなる情報は、以下で提供され、図３０に示される。

【0104】

［入力データを抽出する］
入力データマップは、そのソース構造スキーマを入力スキーマにマッピングするために、訓練集合に対して適用され、入力データ８０４を抽出してもよい。本発明の一実施形態は、ＸＳＬＴを用いてデータマップを符号化し、当業界は周知であるように、ソースのＸＭＬファイルからデータを抽出するために用いられる。

【0105】

抽出方法論は、ソース構造スキーマのパラメータおよび構造マーカの位置をはじめとする多くの要因によって変化する。たとえば、文書タイトル、キーワードに基づくメタタグまたはデータベースキーフィールドと同様に、概念シグネチャが正確である場合には、シグネチャは、概念ラベルを表すために直接的に用いられてもよい。文書自体におけるキーワードの普及率などのさらに複雑なシグネチャの場合には、共通のテキストマイニング方法論が、用いられてもよい。簡単な方法論は、文書において最も優勢なキーワードの簡単な計数におけるキーワードの抽出に基づく。当業者によって周知であるような情報抽出およびテキストマイニングの広汎な分野の中には、その他の多くの抽出方法論がある。

【0106】

一旦抽出されると、入力データは、分析エンジン２０４ａに連結される１つまたは複数の格納手段に格納されてもよい。便宜上、本願明細書に含まれる図および説明は、格納手段としてデータストア９１０を参照するが、他の格納を用いてもよい。

【0107】

たとえば、予測環境がホスト環境である場合には、ドメインデータストア７０６が特に用いられてもよい。

【0108】

システム入力データは、構成要素集合に分割され、変換エンジンにおける次のプロセスに渡されてもよい。

【0109】

概念関係は、ソース構造分析結果Ａに関する入力であり、以下に記載され、図６に示される。

【0110】

概念シグネチャは、予備概念定義Ｂを抽出するために処理されてもよく、以下に記載され、図７に示される。

【0111】

コンテンツノードは、システム出力データＣとして処理されてもよく、以下に記載され、図１７に示される。

【0112】

上述したように、ソースデータ構造からの入力データの抽出は、入力データを抽出するために採用される可能性がある多くの実施形態のうちの一つである。分析エンジン２０４ａに対する他の主な入力チャネルは、一実施形態において、複雑適応システムを含むフィードバックループである。したがって、ユーザインタラクション２１２ａは、さらなる入力データを提供するために戻される（Ｏ）。入力データのこのチャネルおよび複雑適応システムを含むフィードバックループの詳細は、以下に記載され、図２７に示される。
ソースデータ構造を処理する。

【0113】

図６は、本発明の１つの特定の態様において、ソース構造分析結果を抽出するためにソースデータ構造の処理を示す。ソース構造分析結果は、ソースデータ構造のトポロジに関するデータを提供してもよい。ソースデータのトポロジは、その形状を記述するソースデータ構造の技術特性の集合（構造に含まれるノードの数およびソースデータ構造におけるノード間の関係の分散パターンなどの特性）を指す。

【0114】

この分析方法の主要な目的は、概念３０６が（訓練集合８０２における他の概念３０６に関して）どの程度、一般的または特異であるかを測定することである。これを考慮すると、概念の相対的な一般性または特異性の尺度は、「一般性」と呼ばれる。一実施形態において分析されるソースデータ特性は、以下に記載される。分析および特性に関する仕様は、ソースデータ構造によって変化する。

【0115】

概念関係９０８は、分析のために組み立てられてもよい。概念３０６の間での円環的関係１００２が、特定され（非階層関係の存在を示す）、解明されてもよい。

【0116】

非階層としてシステムによって特定されるすべての概念関係は、集合１００４から取り除かれてもよい。取り除かれる概念関係は、次の処理に関与させるのではなく、異なる変換規則に基づく処理に利用されてもよい。

【0117】

取り除かれていなかった概念関係は、階層関係として処理されてもよい。システムは、これらの概念関係１００６を間接関係の拡張された集合に整理されるすべての階層概念関係の入力概念階層１００８に組み立てられてもよい。入力概念階層１００８を組み立てられることは、集合体におけるノードに整理し、関係の他の集合から推測される可能性がある任意の冗長な関係を除去することに関与してもよい。エンティティが、２つ以上の直接の親を有してもよい場合には、入力概念階層１００８は、複数階層構造を含んでもよい。

【0118】

一旦、組み立てられると、入力概念階層１００８は、以下のステップに記載するように、概念関係集合における概念３０６の一般性を測定するための構造を含んでもよく、変換プロセスにおける他の方法にとって有用であってもよい。入力概念階層１００８における概念関係は、以下に記載され、図９〜図１０に示されるように、潜在的形態素関係Ｄを予測するために用いられてもよい。入力概念階層における概念関係もまた、以下に記載され、図１７に示されるように、システムＥに関する出力データを処理するために用いられてもよい。

【0119】

入力概念階層の分析は、各概念１０１０の一般性の尺度に進んでもよい。また、一般性は、任意の所与のノードが、階層１００８における他のノードに対してどのように一般的または特異性であるかを指す。各概念３０６は、入力概念階層１００８におけるその位置に基づいて、一般性測定値を評価してもよい。

【0120】

予測は、概念３０６と交差するツリーにおける各ルートから各概念３０８用の加重平均分離度から構成されてもよい。加重平均分離度は、ルートノードにおける概念３０６からの各概念３０６の距離を指す。明白にルートノードである概念３０６は、１つの一般性尺度を割り当てる。より多くの特定の概念３０６に関する一般性測定値が増大し、ルートノードにある最も一般的な概念３０６からのそれらの増大した分離度を反映する。当業者は、一般性のその他の多くの尺度が可能であることを認識されよう。

【0121】

各概念３０６に関する一般性測定値は、（たとえば、データストア９１０における）概念一般性インデックス１０１２に格納されてもよい。概念一般性インデックス１０１２は、以下に記載され、図１２〜図１３に示されるように、形態素Ｆに関する一般性測定値の集合を推測するために用いられてもよい。

【0122】

一実施形態において記載される方法は、階層−タイプ関係に適用されてもよく、親−子関係としても周知である。親−子関係は、支援することができる関係のタイプにおいてさまざまな多様性を網羅している。その例としては、全体−部分、属−種、タイプ−事例およびクラス−サブクラスなどが挙げられる。言い換えれば、階層タイプ関係を支援することによって、本発明は、分類タスクの膨大な範囲に適用する。
［予備概念定義を処理する］
図７は、予備概念定義を生成するためのキーワード抽出の方法を示す。このプロセスの主要な目的は、キーワード３０８に関して概念３０６の構造定義を生成することである。この段階で、一実施形態において、概念定義は、後の段階で訂正を受けるため、「予備」として記載されてもよい。

【0123】

当業者は、概念３０６の構造表現としてキーワード３０８を抽出する目的を対象にしてもよい多くの方法および技術があることを認識されよう。
一実施形態において、キーワード抽出に適用される抽象化のレベルは、制限されてもよい。これらの制限は、以下の品質を用いてキーワードを導出するように設計されてもよい。（概念が訓練集合の他の領域において現れる場合には）キーワードは、直接関係集合の中のワードの独立性に応じて、原子概念を用いて定義される（に基づいて抽出される）。

【0124】

概念シグネチャ９０６および概念関係９０８は、分析のために集められてもよい。一実施形態において、このプロセスは、テキストエンティティの抽出に基づく。したがって、続く説明において、概念シグネチャ９０６は、概念３０６に割り当てられる概念ラベルに直接的にマッピングすると仮定されてもよい。

【0125】

ラベルが、概念シグネチャ９０６において特定されるため、テキスト文字列の関連部分が、抽出されて、概念ラベル３０６ａとして用いられてもよい。次の方法において、キーワード３０８および形態素３１０が、概念３０６において特定されるため、キーワード３０８ａおよび形態素３１０ａ用のラベルは、概念３０６ａの関連部分から抽出されてもよい。

【0126】

これらのドメイン特定ラベルは最終的には、出力データに書かれてもよい。オペレーション８００が、既に分析されて分類されているデータ構造を変換中である場合には、エンティティラベルが、ソースデータ構造において直接的に利用可能であってもよい。

【0127】

概念シグネチャと概念ラベル抽出との間のこの接合は、画像、マルチメディアおよび物理オブジェクトの分類などのコンテンツノード３０２のさまざまなタイプに向けられる幅広い種類のエンティティ抽出ツール用の統合点を表していることに留意されたい。

【0128】

キーワードデリネータの集合が、概念ラベルにおいて特定されてもよい。予備キーワード範囲１１０２は、キーワード３０８の共通の構造デリネータ（挿入語句、引用符および句読点など）に基づいて、概念ラベル３０６ａから構文解析されてもよい。全体のワードが次に、また共通のワードデリネータ（空間および文法記号など）を用いて、予備キーワード範囲１１０４から構文解析されてもよい。テキストエンティティ構文解析に対するこれらのパターンに基づく対処法は、当業界では公知である。

【0129】

予備キーワード範囲１１０２から構文解析されたワードは、キーワード抽出プロセスにおける次の段階のための入力の１つの集合を含んでもよい。入力の他の集合は、直接的概念関係集合１１０６であってもよい。直接的概念関係集合１１０６は、概念関係９０８の集合から導出されてもよい。直接的概念関係集合１１０６は、各概念３０６に関するすべての直接的な関係（すべての直接の親およびすべての直接の子）から構成されてもよい。

【0130】

これらの入力は、予備キーワード範囲１１０８におけるワードの独立性を確認するために用いられる。直接的関係集合１１０６内の１つのワードの独立性は、キーワード３０８に関するデリネータを含んでもよい。キーワード範囲が正確に描写された後、導出されたキーワード３０８のすべての部分が妥当であるかを確認するための検査が行なわれてもよい。具体的に言えば、キーワード３０８として正確に描写される概念ラベル３０６ａのすべての区分が、ワード独立性検査を合格することが最適である。

【0131】

一実施形態において、ワード独立性に関する検査は、ワードステム（またはワードルート）整合の方法に基づいてもよく、以下においては「ステミング」と呼ばれる。当業界では公知のステミングの方法は多くある。図８に示される以下の形態素抽出の方法において記載するように、ステミングは、分類のためのきわめて優れた基準を提供する。

【0132】

予備キーワード範囲におけるワードの独立性に基づいて、潜在的なキーワードデリネータ１１１０のさらなる集合が、特定されてもよい。簡単に言えば、あるワードが、１つの概念ラベル３０６ａにおいて他のワードと共に現れ、関連する概念ラベル３０６ａにおいてそれらの同ワードが存在しない場合には、そのワードは、キーワードを正確に描写してもよい。

【0133】

しかし、概念ラベル３０６ａがこれらのキーワードデリネータに基づいてキーワードラベル３０８ａに構文解析される前に、候補のキーワードラベルが、検証されてもよい（１１１２）。全候補のキーワードラベルが一般的に、上記に記載されるワード独立性検査に合格することが必要とされる。この検査は、キーワード抽出プロセスが抽象化の対象レベル、すなわち原子概念を超えて概念３０６を細分化しないようにする。

【0134】

一旦、キーワードラベルの予備集合が生成されると、システムは、集合体においてすべての予備キーワードラベルを調べてもよい。この意図は、複合キーワードを特定することである（１１１４）。複合キーワードは、１つの概念ラベル３０６ａの中で２つ以上の有効なキーワードラベルとして現れてもよい。この検査は、概念−キーワード抽象化の範囲として、原子概念の目的に直接的に基づいていてもよい。

【0135】

一実施形態において、複合キーワードの集合を訓練集合８０２によって支援されるキーワード３０８の最も基本的な集合に徹底的に分割するために、反復が用いられてもよい。
整合キーワードが、デリネータの位置を特定するために用いられる場合には、複合キーワードが依然として、キーワードラベルの進化する集合の中にあるのであれば、潜在的キーワードデリネータ１１１０のさらなる集合が、生成されてもよい。また、正確に描写されるキーワード範囲は、有効なキーワードとして検査され、キーワードが抽出され、複合キーワードをこれ以上見つけることができなくなるまで、プロセスが繰り返される。

【0136】

圧密化の最終的な方法過程は、全体ドメインにわたってキーワードラベルの曖昧さを排除するために用いられてもよい。曖昧さの解消は、当業界では公知の要件であり、それに対する多くの対処法がある。一般的に、曖昧さの解消は、エンティティが同一のラベルを共有する場合に生じる曖昧さを解明するために用いられる。

【0137】

一実施形態において、曖昧さの解消方法は、キーワードを同一のラベルを共有する１つの構造エンティティに圧密化することによって提供されてもよい。具体的に言えば、キーワードが、ラベルおよび交差型直接的概念関係集合を共有する場合には、キーワードラベルを圧密化し、１つのキーワードエンティティにキーワードラベルを関連付けるための基準であってもよい。

【0138】

あるいは、曖昧さの解消のこの方法は、緩和されてもよい。具体的に言えば、交差型直接的概念関係集合の判定基準を除去することによって、ドメインにおけるすべての共有キーワードラベルが、同一のキーワードエンティティに圧密化してもよい。これは、ドメインが比較的小さいか、またはその主題にかなり集中されている場合に、有効な手法である。あるいは、曖昧さの解消のこの方法に用いられる概念関係集合は、直接的概念関係および間接的概念関係のより広い連係によって変更されてもよい。曖昧さの解消のさまざまな方法が、当業界では周知である。

【0139】

キーワード抽出のこの方法の結果は、キーワードの集合１１１８であってもよく、「原子概念」のレベルに抽象化されてもよい。キーワードは、概念３０６に関連付けられ（１１２０）、これにより、予備概念定義７０８ａとして導出された。これらの予備概念定義７０８ａは、それらの構造に形態素エンティティ、抽象化のより深くてより多い基本的レベルを含むように後に拡張されてもよい。これらの予備概念定義は、以下に記載するように、入力データにおける概念関係によって示されるキーワードおよび形態素の暗黙の属性に活用するようにさらに拡張されてもよい。

【0140】

このプロセスから導出されるエンティティ７０８ａは、本開示に記載された変換エンジンにおける次のプロセスに渡されてもよい。予備概念定義７０８ａは、以下に記載され、図８に示される形態素抽出プロセスＧへの入力および以下に記載され、図１７に示される出力データプロセスＨへの出力である。

【0141】

［形態素を抽出する］
従来のファセット分類において、ファセットに関する属性は一般的に、人間の認知を用いて特定され、他の概念に関連付けられることができる概念に制限されてもよい。その結果、属性が任意のより深い文脈がない概念を構成することから、属性は、原子概念と考えられてもよい。

【0142】

本願明細書に記載される方法は、概念およびそれらの関係の要素（形態素）の最小の属性を特定するために、大きなデータ集合にわたって統計的ツールを用いてもよい。抽象化のこのレベルで、属性の多くは、概念として人間の分類学者にとって認識可能ではないであろう。

【0143】

図８は、予備概念定義７０８ａを拡張するために、形態素３１０が、構文解析されてキーワード３０８に関連付けられてもよい方法を示す。形態素抽出の方法は、上述し、図７に示した予備概念定義を生成する方法から続いてもよい。

【0144】

一実施形態において、形態素抽出の方法は、キーワード抽出の方法と共通の要素を有してもよいことに留意されたい。本願明細書において、これらの方法が重なっている場合には、形態素抽出のこの説明に対してさらに大雑把に取り扱う。

【0145】

キーワードのプール１１１８および直接的概念関係の集合１１０６は、この方法への入力であってもよい。

【0146】

パターンは、形態素候補１２１２を特定するための判断基準として用いるために定義されてもよい。これらのパターンは、ステミングのためのパラメータを確立してもよく、当業界では公知であるように、全体のワードのためのパターンのほか、部分的なワード整合のためのパターンを含んでもよい。

【0147】

キーワード抽出と同様に、直接的概念関係の集合１１０６は、パターン整合のための文脈を提供してもよい。パターンは、キーワードが生じる直接的概念関係の集合の中のキーワードのプール１１１８に対して適用されてもよい（１２０４）。ステミングパターンに基づく共有ルートの集合が、特定されてもよい（１２０６）。共有ルートの集合は、各キーワード用の候補の形態素ルートの集合１２０８を含んでもよい。

【0148】

各キーワード用の候補の形態素ルートは、互いに一致するかを確認するために、比較されてもよい（１２１０）。同一のキーワードの文脈およびキーワードが生じる直接的概念関係集合の中に存在するルートは、重なるルートを有すると仮定されてもよい。さらに、それらの重なるルートの交差から導出される要素ルートは、有効な形態素を特定するために用いられるパラメータの中に依然としてあると仮定される。

【0149】

この認証検査は、潜在的形態素を特定するために、パターン整合を適用するときに現れるエラー（ステミング方法と共通の問題）を補正するための方法を提供してもよい。さらに重要なことは、認証は、過度の形態素分割を抑制してもよく、抽象化の文脈上意味のあるさらに基本的なレベルを提供してもよい。

【0150】

一実施形態において設計される形態素およびキーワードの抽出における一連の制約はまた、複雑適応システムの文脈の中で、ネガティブフィードバックメカニズムを提供してもよい。具体的に言えば、これらの制約は、複雑さの影響を減じ、分類のための集合パラメータの中でそれを管理するように作用してもよい。

【0151】

この形態素認証プロセスを通じて、任意の一致しない候補の形態素ルートは、キーワード集合から除去されてもよい（１２１２）。形態素候補を特定するためのパターン整合のプロセスは、すべての一致しない候補が除去されるまで、繰り返されてもよい。

【0152】

一致する形態素候補の集合は、キーワードに関連付けられる形態素を導出するために用いられてもよい。キーワード抽出方法と同様に、デリネータは、形態素を抽出するために用いられてもよい（１２１４）。潜在的なルートのグループを調べることによって、１つまたは複数の形態素デリネータは、各キーワードに関して特定されてもよい。

【0153】

形態素は、各キーワードラベル内のデリネータの位置に基づいて抽出されてもよい（８１０）。さらに重大なことは、キーワードに対する構造定義を提供するために、１つまたは複数の形態素エンティティを導出するプロセスである。キーワード定義は、形態素をそこから導出されたキーワードに関係させる（またはマッピングする）ことによって構成されてもよい（１２１６）。これらのキーワード定義は、ドメインデータストア７０６に格納されてもよい。

【0154】

抽出された形態素は、形態素のタイプ（たとえば、自由、拘束、屈折、派生など）に基づいてカテゴリ化されてもよい（１２１８）。構成プロセスの後期の段階において、概念を構築するための規則は、関与させられる形態素のタイプと、これらの形態素が他の形態素に拘束されるかどうかに基づいて、変化してもよい。

【0155】

一旦、タイプが決定されると、抽出された形態素は、ドメインにおけるすべての形態素のプールを含んでもよい（１２２０）。これらのエンティティは、システムの形態素辞書２０６に格納されてもよい。

【0156】

各形態素ラベルの常置の目録は、形態素構文解析の未来の過程を知らせるために用いられる用に維持されてもよい。（さらなる情報に関しては、図３３に示される上記のデータ構造変換の概要を参照されたい。）
このプロセスから導出される形態素は、以下に記載され、図９〜図１０に示されるように、形態素関係Ｉを処理するために、変換エンジンにおける次のプロセスに渡されてもよい。

【0157】

当業者は、形態素から構成されるキーワード定義を発見して抽出するために用いられ手もよい多くのアルゴリズムがあることを認識されよう。
形態素関係を予測する
形態素は、システムの多層ファセットデータ構造を固定する要素構成要素の１つの集合を提供してもよい。他の要素構成要素は、形態素関係であってもよい。上記で説明し、図３、図１８〜図１９に示されるように、形態素関係は、次元概念関係を作成するための有力な基準を提供する。

【0158】

しかし、課題点は、分類データで存在する曖昧さの雑音において真に形態素の形態素関係を特定する中にある。本発明の多層構造は、この課題点に対する一つの対処法を提供する。抽象化の複数のレベルにわたって関係を認証することによって、曖昧さは、連続的に削減される。

【0159】

以下の節は、形態素関係の発見を扱う。具体的に言えば、本発明のこの特定の態様において、パターン増強の方法は、雑音を剥ぎ取って要素構成要素の統計的特定を増強するために用いられる。
［潜在的形態素関係の概要］
図９は、潜在的形態素関係が訓練集合において概念関係から推測される方法を示す。
潜在的形態素関係は、すべての概念関係の集合体において、個々の潜在的形態素関係の普及率を調べるために予測されてもよい。この調査に基づき、統計的検査は、形態素関係が現れる概念関係のすべてとの関連において当てはまる高尤度を有する候補の形態素関係を特定するために適用されてもよい。

【0160】

本発明のシステムの一実施形態において、潜在的形態素関係は、関連概念における形態素間に存在する可能性がある関係のすべての並べ替えとして構成されてもよく、関係の親−子方向性が維持される。

【0161】

図９において実施例において、入力概念階層１００８の一部は、２つの概念間の関係を示す。親概念およびそれに関係する子概念は、形態素｛Ａ，Ｂ｝および｛Ｃ，Ｄ｝をそれぞれ含んでもよい。

【0162】

また、概念は、１つまたは複数の形態素に関して定義（一実施形態において、キーワードによってグループ化）されてもよい。その結果、２つの概念間の任意の関係は、概念を定義する形態素間の少なくとも１つの（２つ以上であることも多い）関係を示唆する。

【0163】

この実施例において、潜在的形態素関係を予測するプロセスが示されている。４つの潜在的形態素関係８１２ａは、１つの概念関係から推測されてもよい。概念関係によって確立された親−子方向性を維持し、任意の反復を認めないために、導出される可能性がある４つの潜在的形態素関係、Ａ．Ｃ、Ａ．Ｄ、Ｂ．Ｃ、Ｂ．Ｄがある。

【0164】

一般的に、親概念は、ｘ形態素を含み、子概念がｙ形態素を含む場合には、ｘ×ｙの潜在的形態素関係がある。潜在的形態素関係の数は、親概念および子概念における形態素の数の積である。

【0165】

一実施形態において、形態素関係を予測するこの簡素な例証は、生成される統計的指標を改良するために精製されてもよい。これらの改訂（すなわち、形態素の配置）は、図１０に示される潜在的形態素関係予測の方法の説明において、以下で述べられる。

【0166】

潜在的形態素関係を特定する基本的な方法のこれらの改訂は、潜在的形態素関係の数を削減するように機能してもよい。この削減は、今度は、雑音の量を低減する可能性があり、したがって、形態素関係を特定するパターンを増大し、形態素関係の統計的特定の信頼性をさらに高める。

【0167】

また、当業者は、概念関係の所与の集合から潜在的形態素関係を導出するために用いられてもよい多くのアルゴリズムがあることを認識されよう。
潜在的形態素関係の予測方法
図１０は、潜在的形態素関係を予測するプロセスの一実施形態をより詳細に示す。

【0168】

この意図は、潜在的形態素関係の集合を生成することであり、この潜在的形態素関係の集合は、本質的に真に形態素である尤度（すなわち、潜在的形態素関係が提示するあらゆる文脈に当てはまる）を評価するために後に分析されてもよい。

【0169】

潜在的形態素関係を予測する本方法は、上記に記載され、図６に示されるソース構造分析結果Ｄの方法から続く。

【0170】

方法はまた、上記に記載され、図８に示される形態素抽出Ｉの方法から拡張する。

【0171】

潜在的形態素関係を決定するこの方法への入力は、ドメイン１２２０と、ドメインから概念関係の認証された集合を含む入力概念階層１００８と、から抽出される形態素のプールであってもよい。

【0172】

各概念関係ペア内の形態素は、推測されることができる潜在的形態素関係の数を削減するために、整列されてもよい（１４０４）。具体的に言えば、２つのデータ要素が整列される場合には、これらの要素は、同一の概念関係ペアにおける任意の他の要素と組み合わせることができない。整列を通じて、候補の形態素関係の数を削減してもよい。

【0173】

一実施形態において、軸は、共有形態素に基づいて整列されてもよく、共有形態素に結合されるすべての形態素を含んでもよい。たとえば、１つの概念が「カナダにおける政治（Ｐｏｌｉｔｉｃｓ
ｉｎ Ｃａｎａｄａ）」であり、別の概念が「国際政治（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｐｏｌｉｔｉｃｓ）」である場合には、キーワード「政治（Ｐｏｌｉｔｉｃｓ）」における共有形態素が、整列のための基準として用いられてもよい。

【0174】

軸はまた、形態素辞書内の既存の形態素関係に基づいて、整列されてもよい。具体的に言えば、任意の所与の潜在的形態素関係が、形態素関係の集合を用いて直接的または間接的のいずれかで構成される形態素辞書における形態素関係によって表されてもよい場合には、潜在的形態素関係は、この基準で整列されてもよい。

【0175】

外部辞書（図１０には図示せず）はまた、潜在的形態素関係の配置を指示するために用いられてもよい。ＷＯＲＤＮＥＴ（商標）は、配置に適用されてもよい辞書である。外部辞書内に含まれる種々の情報は、方向に関する基準として用いられてもよい。一実施形態に基づいて、キーワードは、最初に言語の一部によってグループ化されてもよい。潜在的形態素関係は、これらの文法的グループ化の中でのみ組み合わせるために抑制される。言い換えれば、配置は、外部辞書によって指向されるように、言語の文法部分に基づいてもよい。外部辞書から推測されてもよい直接的形態素関係もまた、配置のための基準として用いられてもよい。

【0176】

潜在的形態素関係は、配置される集合に関与していない形態素のすべての組み合わせとして予測されてもよい（８１２）。この予測は、上記に記載され、図９に示される。

【0177】

潜在的形態素関係の結果として生じる集合１４０６は、ドメインデータストア９１０に保持されてもよい。ここで、潜在的形態素関係の目録は、訓練集合に現れて、分析の次の段階を通じて取り除かれるため、追跡されてもよい。

【0178】

このプロセスから導出される潜在的形態素関係は、以下に記載され、図１１〜図１３に示されるように、取り除く形態素関係の組み立てＪのためのプロセスに渡されてもよい。

【0179】

［潜在的形態素関係を取り除く］
上記に記載され、図９〜図１０に示される方法を通じて生成された潜在的形態素関係のプールは、候補の形態素関係の集合になるまで取り除かれてもよい。

【0180】

潜在的形態素関係は、訓練集合における全体的な普及率の評価に基づいて取り除かれてもよい。広く普及しているそのような潜在的形態素関係は、真に形態素である（すなわち、あらゆる文脈における関係を保持する）より高い尤度を有する。

【0181】

さらに、形態素関係は、さらに一般的な（より広範な）関連形態素に関して、それらの関係において明白であると仮定されてもよい。この曖昧さに関する構造マーカは、複数階層であってもよい。形態素関係は、より少数の属性を具体化してもよく、関連形態素に関するより明確な基準を提供してもよい。したがって、潜在的形態素関係もまた、複数階層に現れるため、取り除かれてもよい。

【0182】

形態素関係の階層は、これもまた階層である形態素関係ペアの集合から構成されてもよい。したがって、潜在的形態素関係のプールは、集合体において分析されて、階層のこの仮定と矛盾する関係を特定してもよい。

【0183】

この取り除きプロセスを切り抜けて残る候補の形態素関係が、形態素階層に組み立てられてもよい。候補の形態素関係は、親−子ペアリングであるのに対して、形態素階層は、親−子関係の複数の生成に拡張されてもよい。

【0184】

図１１Ａおよび図１１Ｂは、潜在的形態素関係と候補の形態素関係の取り除かれた集合との間の差を示す。

【0185】

図１１Ａにおいて、階層である４つの潜在的形態素関係ペア（親−子）がある。これらの関係のうち、最初の３つは、ドメインにおいて比較的普及しているが、第４の関係は、比較的稀である。したがって、第４のペアは、潜在的形態素関係の集合から取り除かれる。

【0186】

潜在的形態素関係の集合１４０６における最初の３つの関係ペアはまた、階層の仮定と一致する。しかし、双方向の第５の関係１５０２は、この仮定と矛盾する。関係Ｄ．Ｃの方向は、関係Ｃ．Ｄと矛盾する。この形態素ペアは、連想関係を通じて関係付けられたものとして再度タイプ分けされ、候補の形態素関係の集合１５０４から除去される。図１１Ｂは、候補の形態素関係の取り除かれた集合を示す。
［形態素関係を組み立てる］
［形態素関係を統合する］
図１２は、全体的な形態素複数階層への候補の形態素関係の圧密化を示す。すべての候補の形態素関係ペアは、１つの集合体集合に組み込まれ、（以下にさらに詳細に記載するような）論理的に一致する世代ツリーに接続してもよい。

【0187】

このデータ構造は、より一般的な形態素（複数の親）と２つ以上の直接的な関係に関与させる唯一の形態素を結果として生じてもよいため、「複数階層」として記載されてもよい。この複数階層は、プロセスの後の段階で、厳格な階層（１つの親のみ）に変換されてもよい。

【0188】

矛盾する取り除くプロセス切り抜けて残る潜在的形態素関係（上記に記載され、図１１Ｂに示される）は、候補の形態素関係の集合１５０４に収集されてもよい。候補の形態素関係の集合は、全体的な形態素複数階層１６０２に統合されてもよい。

【0189】

一実施形態において、全体的な複数階層を構成するプロセスにおける制約は、１）複数階層における候補の形態素関係の集合は、集合体において論理的に一致することと、２）複数階層は、論理的に一致する構造を作成するために必要な複数階層関係の最小数を用いることであってもよい。

【0190】

再帰的順序付けアルゴリズムは、ツリーを組み立てて、矛盾および提案された解決策を強調するために用いられてもよい。以下の実施例に適用された推測は、このアルゴリズムの論理を示す。

【0191】

関係階層＃１に基づき、Ａは、Ｃより優れている（すなわち、一般的である）。階層＃２に基づき、Ｂは、Ｃより優れている。階層＃３に基づき、Ａは、Ｄより優れている。４つの形態素は、Ｃより優れているＡおよびＢとＤより優れているＡと論理的に組み合わせられることができる。

【0192】

２つ以上の論理的な順序付けが、可能である場合には、概念一般性インデックス１０１２が、曖昧さを解明するために用いられてもよい。（概念一般性インデックスは、上記に記載され、図６に示されるソース構造分析結果の方法を通じて作成される。）このインデックスは、形態素が比較的に、他の形態素より一般的であるか、または特異であるかどうかを評価するために形態素を（ルートノードからの分離度に関して測定される一般性と）比較するために用いられてもよい。

【0193】

実施例において、ＡおよびＢの両方が、候補の形態素関係の集合に基づいて、局所的に一致する最上位のノードである。ＡおよびＢはまた、Ｃの両親である。したがって、関係の複数階層集合は、Ｃで生成されてもよい。関係の複数階層集合と矛盾するサンプル集合における情報がないため、関係は、有効であると仮定されてもよい。処理は、後の段階において複数階層を解明するために続いてもよい。
ＡおよびＢが、間接的な関係を通じて、代わりにノードに関連付けられることを示される新たなデータが提示される場合には、システムは、複数階層を直ちに解明し、同一のツリー内にＡおよびＢを順序付けしてもよい。ＡおよびＢの優先度は、一般性インデックスを通じて決定されてもよい。ここでは、Ａは、Ｂより低い一般性ランキングを有する。したがって、結果として生じる複数階層１６０２においてより高い（より一般的な）位置が与えられる。
［形態素複数階層の組み立て］
図１３は、形態素複数階層が、候補の形態素関係から組み立てられることができる方法を示す。

【0194】

形態素階層は、集合体において、候補の形態素関係ペアを分析することによって組み立てられてもよい。入力概念階層における場合のように、目的は、関係の個々のペアを１つにまとめられた全体に圧密化することである。

【0195】

形態素関係組み立ての方法は、上記に記載され、図９〜図１０に示したように、潜在的形態素関係Ｊを予測する方法から続いてもよい。

【0196】

潜在的形態素関係の集合１４０６は、この方法に対する入力であってもよい。候補の形態素関係は、形態素を含む概念関係の分析に基づいてソートされてもよい（１７０２）。概念関係は、各概念関係ペア（最低対最高）における形態素の集合計数に基づいてソートされてもよい。

【0197】

概念関係ペアに関与する形態素の数が減少すると、形態素関係は、尤度において増大する可能性がある（任意の所与の形態素関係候補に関する確率は、ペアにおける潜在的な候補の数によって因子が決まる）。したがって、一実施形態において、オペレーションは、より低い形態素計数を有する概念関係の分析を優先してもよい。ペアにおける形態素の数が低いと、真に形態素の形態素関係を求める機会を増大する可能性がある。

【0198】

形態素関係の統計的に関連する境界を定義するためのパラメータは、集合１７０４であってもよい。これらのパラメータは、集合体において形態素関係の普及率に基づいてもよい。目的は、ドメインにおいてきわめてよく普及しているドメインを特定することである。形態素関係におけるこれらの制約はまた、複雑適応システムのネガティブフィードバックメカニズムに寄与する可能性がある。集合体における関係集合の分析１７０６は、各関係の全体普及率を決定するために行われてもよい。この分析は、システムアドミニストレータによって制御される感度パラメータ内で行われる統計的ツールと組み合わせられてもよい。正確なパラメータは、各ドメインに対して調整されてもよく、ドメインオーナおよびシステムアドミニストレータによって変更されてもよい。

【0199】

概念関係分析と同様に、円環的関係１７０８は、階層関係の仮定を否定するために構造マーカとして用いられてもよい。潜在的形態素関係は、普及率および階層のフィルタに合格しない場合には取り除かれてもよい（１７１０）。

【0200】

潜在的形態素関係の取り除かれた集合は、候補の形態素関係の集合１５０４を含んでもよい。形態素の一般性１０１０ａは、概念一般性インデックス１０１２において具体化されるように、ソース構造概念の一般性から推測されてもよい。

【0201】

形態素の最小数を具体化する概念は、各形態素の一般性の代わりとして用いられてもよい。この仮定の基準を示すために、概念は、唯一の形態素から構成されると仮定する。概念と概念を含む１つの形態素との間で高い関連度が与えられると、形態素の一般性は、概念の一般性ときわめて相関がある可能性が高い。

【0202】

この推測は、一実施形態において、形態素の一般性の予測に向けられる。具体的に言えば、システムは、集合体において形態素の最小数を具体化する概念の集合を集めてもよい。すなわち、システムは、集合におけるすべての形態素を表す概念の集合を選択してもよい。

【0203】

概念一般性インデックス１０１２は、次元概念関係に優先順位を付けるために用いられてもよく、ドメインデータストア７０６に格納されてもよい（図示せず）。

【0204】

形態素階層は、上記に記載され、図１２に示される方法を用いて、全体の複数階層構造１７１２に組み立てられてもよい。これは、集合体においてノードを順序付けすることと、間接的な関係の他の集合から推測される可能性がある任意の冗長な関係を除去することと、に関与してもよい。作成された概念一般性インデックスは、最も一般的なものから最も特異なものまで、形態素を順序付けするために用いられてもよい。

【0205】

当業者は、当業界は周知であるように、階層形態素関係の収集物を複数階層に統合するために用いられてもよい多くのアルゴリズムがあることを認識されよう。
［形態素階層を組み立てる］
図１４〜図１６は、形態素階層への形態素複数階層の変換を示す。
［形態素複数階層属性］
図１４Ａ〜図１４Ｂは、形態素属性および例示的結果のプロセスを示す。これに関連する属性は、ファセット分類が順序付けされ、データ要素に割り当てられる態様を指す。オペレーションが、エンティティ抽出（キーワードおよび形態素抽出など）に制約を付けるように、形態素階層は、明確な制約を用いて形態素関係上に構築されてもよい。

【0206】

形態素を階層に連結する形態素関係は、定義によって、形態素である。形態素エンティティは、基本的であり、かつ明白である。形態素は一般的に、１つの親のみに関連付けられることが必要である。形態素関係の集合（形態素階層）において、形態素は、１つのみの位置に存在してもよい。

【0207】

１つの知識表現モデルにおけるこれらの定義に基づき、形態素は、形態素データのファセット階層の中の属性として提示されてもよい。したがって、知識表現モデルは、ファセットデータおよびファセット分類の多層の増強方法を提供してもよい。

【0208】

以前の方法において、候補の形態素関係の集合は、形態素複数階層の集合１８０２を提示してもよい。したがって、属性は、知識表現モデルにおけるこれらの矛盾を比較検討して、解を求めるために用いられてもよい（１８０４）。

【0209】

一実施形態において、属性の方法は、階層の形態素要件と矛盾しない階層における各形態素に関する場所を求めることに関与してもよい。

【0210】

複数階層における形態素は、元のツリーの中の新たな位置に上がってもよく、または完全に新たなツリーに移動してもよい。属性のこのプロセスは、ファセット階層における最上位のルートの形態素ノードを最終的に定義してもよい。したがって、形態素階層におけるルートの形態素ノードは、形態素ファセットとして定義されてもよく、各形態素が、形態素ファセット属性ツリーの中に含まれてもよい。

【0211】

以下の説明は、属性の概念を用いて複数の親を除去するための方法を示す。

【0212】

また、矛盾に関する構造マーカは、形態素複数階層１８０２に表れている複数の親の存在であってもよい。矛盾を除去するために、複数の親を有する形態素は、共有する親の祖先の属性として再検討されてもよい。

【0213】

属性クラスは、再組織化される形態素によって元々共有される親のグループ化を維持し、それらの親から別個の属性クラスにおける形態素を保持するために作成されてもよい。（固有の祖先がない場合には、方法は、新たな形態素ファセットとして、形態素を階層のルートレベルに進める。）
関係は、ルートノードからリーフノードに属性クラスに再組織化されてもよい。複数の親は、最初に唯一の親が特定することができるような属性に再組織化されてもよい。すなわち、形態素関係のトップダウン探査は、解の集合１８０４を求めることができるような属性を提供する。

【0214】

一般的に、２つの形態素が、少なくとも１つの親を共有する場合には、それらの形態素は、その共有する親との関連において兄弟（連想関係）である。兄弟の子ノードは、単一の属性クラスの下でグループ化されてもよい。（子ノードは、１つの親を共有することだけが必要であり、すべての親を共有する必要はないことに留意されたい。）形態素が、少なくとも１つの親を共有しない場合には、形態素は、共有した祖先の個々の属性としてグループ化されてもよい。

【0215】

選択肢の間で選択するために、ソース関係の関連度が、比較検討されてもよい。関係関連度の尺度は、ソース構造分析結果の説明において、上記で紹介され、図６に示された。

【0216】

トップダウンから始まり、変換ステップは、以下のように細分化されてもよい。
１．兄弟グループ｛Ｂ，Ｃ，Ｄ，Ｆ，Ｈ｝は、１つの親Ａを共有する。各個々のノードは、複数の親がいるかどうかを確かめるために検査される。この場合には、これらのノードには複数の親がおらず、したがって、これらの関係を再組織化する必要はない。
２．形態素Ｅは、複数の親を有する。Ｅの最も近い１つの親の祖先は、Ａである。Ｅは、Ａの属性として再組織化される必要がある。
３．Ｅの親｛Ｂ，Ｃ，Ｄ，Ｆ，Ｈ｝は、属性クラスＡ１の下でグループ化される。Ｅは次に、Ａの属性としてＡ１の兄弟になる。
４．形態素Ｇもまた、複数の親を有する。ステップ（２〜３）の場合と同様に、Ｇは、Ａの属性として再組織化される必要がある。さらに、ＥおよびＧは、少なくとも１つの親を共有するため、１つの属性クラスＡ２の下でグループ化されることができる。
５．形態素Ｊは、唯一の親Ｈを有する。この親−子関係は、再組織化される必要はない。
６．形態素Ｋは、複数の親ＥおよびＧを有する。ＥおよびＧの単独の祖先は、ここではＡ２である。Ｋは、Ａ２の属性として再組織化される必要がある
７．Ｋの親｛Ｅ，Ｇ｝は、属性クラスＡ２−１の下でグループ化される。Ｋは次に、Ａ２の属性として、Ａ２−１の兄弟となる。

【0217】

最終結果が、形態素階層であり、本発明の知識表現モデルによって定義される真に形態素の属性および形態素関係の仮定に適合する。
形態素階層の再組織化
図１５は、一実施形態において、属性の方法を提供することができる再帰アルゴリズムを提示する。この形態素階層の再組織化の中核論理は、上記に記載され、図１４Ａおよび１４Ｂに示された属性の方法であってもよい。

【0218】

この方法に関する入力は、上記に記載され、図１１〜図１３に示されるように、形態素複数階層Ｋであってもよい。本方法に対する入力は、形態素複数階層１６０２であってもよい。関係は、ルートノードからリーフノードまでソートされる（１９０２）。形態素複数階層における各形態素は、複数の親に関して検査されてもよい。本願明細書において、分析の焦点である形態素は、能動形態素として周知である。

【0219】

任意の複数の親が存在する場合には、能動形態素に関する複数の親の集合が、以下では形態素属性クラスと呼ばれる集合にグループ化されてもよい（１９０６）。形態素属性クラスは、再組織化されるツリーにおける形態素が、どのように順序付けされるべきかを指示するために用いられてもよい。

【0220】

各形態素属性クラスに関して、複数の親を有していない固有の祖先の位置を特定してもよい（１９０８）。祖先は、属性クラスのみ（形態素によって共有される親のグループ）に一意に関連付けられてもよい。

【0221】

祖先が存在する場合には、システムは、形態素属性クラスにおけるすべての形態素を含む１つまたは複数の仮想属性を作成してもよい（１９１０）。ツリーにおけるこのノードは、任意の形態素に直接的に関連付けられず、したがって、任意の概念定義に関与しないために、「仮想属性」と呼ばれる。それは、仮想属性であって、実在属性ではない。

【0222】

祖先が存在し、１つまたは複数の属性が作成される場合には、能動形態素は、祖先に直接的に関連するか、または形態素属性クラスにおける他の形態素と共にグループ化されるかのいずれかで、祖先の属性として再組織化されてもよい（１９１２）。

【0223】

固有の祖先が存在しない場合には、形態素は、ツリーにおけるルートノード（ファセット）として再位置決めされてもよい（１９１４）。

【0224】

システムはまた、アドにミストレータが、形態素関係のプールおよび結果として生じる形態素階層を手動で変更して、自動的に生成される結果を精製または置換することができるようにしてもよい（１９１６）。

【0225】

このプロセスの最終結果は、形態素階層４０２であってもよく、要素形態素の階層整列を含む。システムのデータ構造の要素構成要素の１つである形態素階層は、エンティティを抽象化の増大する複雑なレベルにカテゴリ化して配置するために用いられてもよい。

【0226】

形態素階層における形態素関係は、形態素辞書２０６に記入されてもよい。形態素ラベルは、システムに格納されたラベルの普及率に基づき、形態素に割り当てられてもよい。システムにおいて最も普及している形態素ラベルは、その形態素に関する１つの代表的なラベルとして用いられてもよい。

【0227】

この方法の出力は、以下に記載され、図１７に示されるように、システム出力データＬとして処理されてもよい。

【0228】

複数階層を厳密な階層に変換するための別の手法が、用いられてもよい。１つの親は、複数の親の立場を除去するために、複数の比較検討因子のいずれかに基づいて選択されてもよい。簡単な解では、複数の親関係は、消去されてもよい。

【0229】

図１６Ａは、組み立てられた形態素階層からのサンプルツリーの断片を示す。ツリーにおける各ノード（たとえば、２００２ａ）は、形態素階層における形態素を表してもよい。フォルダアイコンは、下に入れ子になっている関連形態素に対する親である形態素を示すために用いられる（形態素関係）。各ノードの隣の文字列（たとえば、２００２ｂ）は、関連付けられる形態素ラベル（多くの場合には、部分ワード）である。
［ファセット分類合成の方法］
ここでは、ファセット分類の増強方法に基づき、次元概念タクソノミ２１０を構築（または合成）するプロセスを始める。この分類は、概念定義の集合に関する形態素階層の調査を通じて、次元概念関係を生成してもよい（さらに具体的に言えば、形態素に関して定義され、０以上の形態素が、形態素階層の中の形態素属性となる）。

【0230】

本発明のファセット分類の方法は、データ抽象化の多階層に適用されてもよい。このように、ドメイン特有の境界を維持すると同時に、多数のドメインが、分類のために同一の要素構成要素を共有してもよい。
［ファセットデータ集合を処理する］
以下のポイントは、ファセット分類データ構造を合成するために用いるための分析オペレーションから出力データを準備する一態様において関与されるステップをまとめている（以下にさらに記載される）。

【0231】

分類対象の各ドメインの場合には、データ構造は、ドメイン特有のキーワード階層およびドメイン特有の概念定義の集合として出力されてもよい（さらに具体的に言えば、ドメイン特有のキーワードに関して定義され、０以上のドメイン特有のキーワードが、ドメイン特有のキーワード階層の中のキーワード属性となる）。

【0232】

上記に記載されるドメイン特有のファセットデータは、ドメインにわたって共有される要素構成要素から導出されてもよい。予備概念定義は、訂正され、重大なことに、新たな情報によって拡張されてもよい。これは、形態素階層における情報を訓練集合における元の概念関係と比較することによって達成される。

【0233】

具体的に言えば、合成オペレーションは、ドメインオーナ提供される明確な定義だけの分析に基づくだけではなく、集合体におけるすべての概念および概念関係の分析を通じても、コンテンツノードに概念定義を割り当ててもよい。「明確な」属性の予備定義が、割り当てられてもよく、コンテンツノードと交差する概念関係によって「示唆される」属性のはるかに豊富な集合によって後に補足される。

【0234】

候補の形態素関係は、すべての形態素階層に組み立てられてもよく、ファセット分類に関するデータカーネルとして用いられてもよい。各ドメインに関する別個のファセット階層は、各ドメインにおけるキーワードおよびそれらの形態素の固有の交差点から作成されてもよい。このデータ構造は、ドメインの境界に制限される形態素階層の表現であってもよい。

【0235】

ファセット階層は、ドメイン（キーワードのその固有の集合）のボキャブラリにおいて表現されてもよく、またドメインに因子が決まる形態素関係のみを含んでもよい。各ドメインに関するファセット分類は、そのドメインに関する概念定義の集合およびファセット階層として出力されてもよい。

【0236】

したがって、一実施形態において、ドメイン特有のファセット階層は、集中型の形態素階層から推測されてもよい。ドメイン特有のファセット階層は、より小さなドメインに関するファセットのより豊富な集合を提供してもよい。ドメイン特有のファセット階層は、より小さなドメインに現れるエラーを補正することができる多数のドメインの共有される経験を構築してもよく、ドメインの処理がより高速になるように促進してもよい。

【0237】

別の実施形態において、システムは、上記に記載され、図１４〜図１５に示される方法に、直接的に基づいて、ドメインに関する固有のファセット階層を作成してもよい。この実施形態において、属性階層の組み立てのプロセスは、各ドメインから抽出されるドメイン特有のキーワードに直接的に適用されてもよい。

【0238】

さらに別の実施形態において、合成オペレーションは、分類の他の従来の手段から収集されるデータに基づいてもよい。分類のそのような手段は、従来のファセット分類合成の場合に準備されたファセットデータと、形式上の概念分析の場合のように、属性集合を厳格に用いて定義される概念と、を含んでもよい。これらをはじめとする他の相補的分類方法は、当業者には公知である。

【0239】

図１６Ａおよび図１６Ｂは、（上記に記載されるように）組み立てられた形態素階層２００２からのツリー断片および一実施形態において導出されたようなドメイン特有のキーワード階層２００４からのツリー断片を示す。キーワード階層２００４に関するツリー断片において、関連付けられるキーワードラベルを表す各ノードに隣接する文字列（たとえば、２００４ｂ）は、ドメインにおいて現れるように完全なワードであることに留意されたい。さらに、キーワード階層２００４に関するツリー断片は、形態素階層２００２に関するツリー断片の部分集合であってもよく、キーワード階層が導出されるドメインに関連するそれらのノードのみを含むように縮小される。

【0240】

図１７は、ファセット分類の増強方法に関する出力データを調整するオペレーションを示す。
出力データは、ドメインに関する改訂された概念定義およびキーワード階層から構成されてもよい。キーワード階層は、形態素階層に基づいてもよい。

【0241】

このプロセスに対する入力は、分類対象のコンテンツノード３０２の集合、入力概念階層１００８、形態素階層４０２および予備概念定義７０８ａであってもよい。これらの入力の生成または他の方法による獲得のためのそれぞれのオペレーションＣ、Ｅ、ＬおよびＨは、上記に記載される。

【0242】

第１の概念定義７０８ａおよび入力概念関係内の形態素属性の交差は、第１の概念定義７０８ａから第２の概念定義７０８ｂに訂正するために用いられてもよい（２１０２）。具体的に言えば、ソースデータにおける概念関係は、形態素階層から推測されることができない場合には、概念定義は、概念関係によって「示唆される」属性を提供するために拡張されてもよい。結果は、改訂された概念定義７０８ｂの集合である。

【0243】

ドメインに加わっているすべての形態素の集合から形態素階層における関連形態素関係の集合が、特定されてもよい（２１０６）。

【0244】

形態素階層の低減されたドメイン特有のバージョンにおける形態素は、ドメインからのキーワードを用いてラベル付けされてもよい（２１０８）。各形態素に関して、その形態素を最大回数用いるシグネチャキーワードが、選択されてもよい。各キーワードに関して最も普及しているキーワードラベルが、割り当てられてもよい。個々のキーワードは、ファセット階層における１回の発生に制限されてもよい。一旦、キーワードが、シグネチャキーワードとして用いられると、キーワードは、他の形態素の代わりとして利用不可能となってもよい。

【0245】

形態素階層は、ドメインに関係している形態素のみを含む形態素関係の集合に圧密化されてもよく、キーワード階層２１１２は、圧密化された形態素階層から推測される（２１１０）。

【0246】

ファセット分類を表す出力データ２１０ａは、訂正された概念定義７０８ｂ、キーワード階層２１１２およびコンテンツノード３０２から構成されてもよい。出力データは、ドメインデータストア７０６に転送されてもよい。

【0247】

入力概念階層における概念関係はまた、ドメインデータストア７０６における出力データに直接的に影響を及ぼしてもよい。具体的に言えば、入力概念階層は、オペレーションの合成部分から推測される関係に優先順位を付けるために用いられてもよい。ソースデータから直接的に引き出された概念関係のプールは、推測される次元概念関係とは対照的に、「明確な」データを表してもよい。入力概念階層において（直接的にまたは間接的に）明確である推測された関係は、ソースデータに現れなかった関係より上の優先順位を付けられてもよい。すなわち、明確な関係は、プロセスから推測されるさらなる関係よりも重大であるように思われる場合がある。

【0248】

出力データは、今度は、次元概念タクソノミＭをレンダリングするために複雑な次元データ構造として利用可能であってもよい。
［ファセット分類の方法を適用する］
ファセット分類の増強方法の組織化原理は、最初に上記で紹介された図３、図１８〜図１９に示され、以下でさらに詳細に説明され、図２０〜図２２に示され、その方法を通じて、要素構成要素が、複雑な次元構造を作成するために合成されることができる。

【0249】

ファセット分類のこの増強方法は、ファセット分類体系の柔軟性の長所と、複雑な概念の単一（非断片化された）階層を通じて提供されるような単純化、可視化および全体的な視点の長所と結び付ける。

【0250】

ファセット階層を単純な（単一の）階層と対比することは、これらの長所を明らかにする。単純な階層は、直観的に認識され、視覚化されやすい。階層は、同時に多くの組織化基礎（またはファセット）を統合することが多く、関連属性のすべてのさらに全体的な視点を提供する。属性は、ファセット境界にわたって連結され、同時にナビゲートされてもよい。属性を断片化するのではなく、属性を統合することによって、はるかに経済的で、堅牢な説明の枠組みを提示する。

【0251】

当業者は、その他の多くのより単純な従来の分類方法もまた、以下で概略を述べるように、本発明の種々の構成要素およびオペレーションのモードから恩恵を受ける可能性があることを認識されよう。公式の概念分析などのファセット分類の集合に基づく分類構築の従来のプロセスは、本願明細書に記載されるシステムから恩恵を受けるであろう２つの別の分類方法を示す。
［次元概念合成］
図１８を参照すると、概念定義を含む形態素３１０が、形態素階層４０２に関連付けられてもよい。形態素階層４０２は、冗長な形態素関係を取り除いた形態素辞書２０６において既知の形態素関係のすべての集合体集合であってもよい。形態素関係は、他の形態素関係の集合を用いて（すなわち、間接的な関係を通じて）局所的に構成されることができる場合には、冗長であるとみなされてもよい。

【0252】

個々の形態素３１０ａおよび３１０ｂは、特有の概念３０６ｂを定義するために、キーワードにおいてグループ化されてもよい。したがって、これらの形態素３１０ａおよび３１０ｂは、（キーワードグループ化を介して）概念３０６ｂと、形態素階層４０２における他の形態素３１０と、に関連付けられてもよいことに留意されたい。

【0253】

これらの相互接続を通じて、形態素階層４０２は、概念関係の新たでかつ拡張的な集合を作成するために用いられてもよい。具体的に言えば、形態素関係を通じて関連付けられる形態素３１０を含む任意の２つの概念３０６は、それ自体が、関連概念であってもよい。

【0254】

概念定義の中の形態素の同時発生は、概念関係の階層を作成するための基準として用いられてもよい。概念３０６ｂにおける交差線４０６ａおよび４０６ｂ(図１８)は、概念３０６ｂを他の関連概念（図示せず）に接続する次元軸を表す。それぞれが、軸を定義する形態素（またはファセット属性）の集合によってフィルタリングされる概念関係の別個の階層を表す次元軸の集合は、複雑な次元構造の構造的基礎であってもよい。構成方法の簡略化された概要は、図１９に続く。
［次元概念タクソノミ］
図１９は、次元軸の交差に基づき、次元概念タクソノミ２１０を定義するための複雑な次元構造の構成を示す。

【0255】

４つの概念３０６ｃ、３０６ｄ、３０６ｅおよび３０６ｆの集合は、それぞれ、形態素３１０ｃ、３１０ｄおよび３１０ｅによって定義される概念３０６ｃ、３０６ｄおよび３０６ｅと、形態素３１０ｃ、３１０ｄおよび３１０ｅの集合によって定義される概念３０６ｆと、で示されてもよい。形態素３１０ｃ、３１０ｄおよび３１０ｅの交差点によって、概念３０６ｃ、３０６ｄ、３０６ｅおよび３０６ｆが、概念関係を共有してもよい。合成オペレーション（以下に記載される）は、概念定義において形態素３１０ｃ、３１０ｄおよび３１０ｅに基づいて、概念関係の明らかに異なる階層として次元軸４０６ｃ、４０６ｄおよび４０６ｅを作成してもよい。

【0256】

次元概念関係を合成するこのオペレーションは、ドメイン２００におけるコンテンツノード３０２のすべてまたは一部に対して処理されてもよい（処理オペレーションの範囲制限および動的モードは、以下に記載され、図２２〜図２３に示される）。したがって、コンテンツノード３０２は、次元概念タクソノミ２１０として完全に再設計される複雑な次元構造にカテゴリ化されてもよい。

【0257】

上記に記載されるように、１つのコンテンツコンテナまたはコンテンツノード（ウェブページなど）が、２つ上の概念に割り当てられてもよい。したがって、１つのコンテンツコンテナまたはコンテンツノードは、次元概念タクソノミにおける多くの離散した階層に常駐してもよい。

【0258】

また、形態素関係を通じて関連する形態素３１０を含む任意の２つの概念３０６はそれ自体が、関連概念であってもよい。一実施形態において、明確な形態素関係および暗黙の形態素関係の両方が、ドメインの文脈上の検討と組み合わせて、次元概念タクソノミにおける複雑な次元関係を推測してもよい。

【0259】

概念定義は、ファセット属性として形態素を用いて記載されてもよい。上記に記載されるように、ファセット属性（形態素）が、辞書において明確である（「登録されている」または「周知である」）か、または暗黙である（「登録されていない」または「未知である」）かは問題としなくてもよい。次元概念タクソノミにおけるその意味を保持するために、概念定義に関連付けられるわかりやすく有効な説明であるべきである。有効な概念定義は、次元概念タクソノミにおけるコンテンツノードの意味を説明するために、生の素材を提供してもよい。このように、ドメインにおけるオブジェクトは、訓練集合の一部として前に分析されたかどうかに関係なく、次元概念タクソノミにおいて分類されてもよい。当業界では公知であるように、分類対象のオブジェクトに概念定義を割り当てることを可能にする多くの方法および技術がある。

【0260】

本発明の一実施形態において、（上記に記載される）知識表現モデルの構造的エンティティの対話は、以下のように、形態素、形態素関係、概念定義、コンテンツノードおよび概念関係間の論理的連結を確立してもよい。

【0261】

能動コンテンツノード内の概念が、他のコンテンツノード（以下では「関連ノード」）におけるファセット属性と同一の系統のファセット属性（以下では、形態素）を含む場合には、関係は、能動ノードと関連ノードとの間に存在してもよい。言い換えれば、各概念は、コンテンツノードにおいて存在するように、それらの形態素間の関係によって推測される関係をすべて受け継いでもよい。

【0262】

ファセット階層から直接的に推測される次元概念関係は、本願明細書では明確な関係と呼ばれる。分類対象のコンテンツノードに割り当てられる概念定義の中のファセット属性の交差集合から推測される次元概念関係は、本願明細書では暗黙の関係と呼ばれる。
合成（構築）規則
概念間の明確な関係は、それらの概念定義における属性間の関係を調べることによって予測されてもよい。概念定義は、分類されるコンテンツノードにおける属性（以下では、「能動ノード」）に対して、ファセット階層（以下では、同一の「系統」の）において直接的にまたは間接的に関わる属性を含む場合には、関与させる属性によって表される次元軸に沿って、概念間に明確な関係が存在してもよい。

【0263】

限定する制約（以下に記載される）を条件として、暗黙の関係は、それらの概念定義における属性の部分集合を共有する任意の概念の間で、推測されてもよい。属性の交差集合は、親−子関係を確立する。

【0264】

軸は、ファセット属性集合に関して定義されてもよい。一実施形態において、軸は、ファセット階層におけるファセット（ルートノード）の集合によって定義されてもよい。これらの属性集合は次に、次元概念関係の圧密化された階層に概念をフィルタリングするために用いられてもよい。あるいは、属性の任意の集合は、複雑な次元構造から導出される同的に構成された（カスタム）階層に関して、次元軸の基準として用いられてもよい。

【0265】

明確な関係および／または暗黙の関係が、親概念定義におけるすべての軸に関して引き出されてもよい場合には、次元概念関係が存在する。したがって、次元概念関係は、属性によって定義されるすべての次元にわたって、構造的に完全なままである。
優先度および方向性
ファセット階層（形態素関係によって表現されるように）は、コンテンツノードの優先順位を付けるために用いられてもよい。具体的に言えば、各コンテンツノードは、ファセット階層において高々１つの位置に現れる属性を具体化してもよい。階層における属性の優先度は、ノードの優先度を決定してもよい。

【0266】

概念関係内の優先度は、最初に、問題になっている集合の中の任意の登録形態素の全体の優先度を調べることによって、決定されてもよい。最上位の登録形態素は、集合に関する優先度を確立してもよい。

【0267】

たとえば、第１の集合が、優先度数｛３，３７，３０３｝を有する３つの登録形態素を含み、第２の集合は、優先度｛５，４９０｝を有する２つの登録形態素を含み、第３の集合は、優先度｛５，２９６，１００２｝を有する３つの登録形態素を含む場合には、集合は、｛３，３７，３０３｝、｛５，２９６，１００２｝、｛５，４９０｝に順序付けられてもよい。第１の順序付けされた集合は、その集合において含まれる優先度３を有する形態素の上位の全体的なランキングに基づいて、優先順位を付けてもよい。後者の２つの集合は、いずれも｛５｝の最上位の形態素優先度を有してもよい。したがって、各集合における次の最高の形態素の優先度は、優先度｛２９６｝を有する形態素を含む集合が、より高い優先順位を付けた集合であるべきであることを明らかにするために調べられてもよい。

【0268】

概念関係におけるコンテンツノードが、登録形態素によって差別化されない場合には、システムは、優先順位付けの基準として暗黙の形態素の数を用いてもよい。最小数の形態素を有する集合は、階層においてより高い優先度であると仮定されてもよい。コンテンツノードが、同一の明確な形態素および同数の未登録の暗黙の形態素を含む場合には、コンテンツノードは、互いと同等であると見なされてもよい。コンテンツノードが、同等であるときには、優先度は、これらのコンテンツノードのそれぞれがシステムによって発見される順序によって確立されてもよい。

【0269】

図２０は、暗黙の関係の構成および結果として生じる階層におけるノードの優先度の決定の一実施形態の構成の簡単な例証を提供する。

【0270】

この実施例において、形態素「ビジネス」２２０１は、形態素辞書に登録される。ユーザインタラクションを通じて、コンテンツノードが、この形態素に加えて新たな形態素「モデル」２２０２を含む概念定義を用いて構成されると仮定すると、それは、形態素辞書では認識されない。

【0271】

上記の実施例を続けると、形態素「ビジネス」は、最高の優先度２２０３を有する。集合「ビジネス，モデル」は、「ビジネス」の示唆された子２２０４である。「広告」２２０５などのこの集合に加えられる任意のさらなる形態素は、階層におけるさらなる層２２０６を作成することになる。

【0272】

任意の形態素は、システムにおいて明確であるかまたは示唆されたかに関係なく、概念階層（または軸）に関する基準として用いられてもよい。上記の実施例を続けると、暗黙の形態素「広告」２２０７は、この形態素に基づき、階層の親２２０８である。集合「ビジネス，モデル，広告」２２０５は、この階層における子２２０９である。「広告」を含む任意のさらなる集合はまた、この階層の構成員であろう。実施例において、集合「広告，方法」２２１０もまた、広告２２１１に対する子である。形態素「ビジネス」が登録されているため、集合「ビジネス，モデル，広告」は、暗黙の形態素のみを含む集合「広告，方法」に比べて、広告階層においてより高い優先度が与えられる。

【0273】

ノードの優先順位付けの別の実施例は、「シグネチャ」ノードに関する。これらは、それらの関連付けられる概念に最もよく記述する（または意味を与える）コンテンツノードとして、定義される。たとえば、ドメインオーナは、その概念に関するシグネチャ識別子として特定の概念に写真を関連付けてもよい。このように、シグネチャノードは、優先順位を付けられてもよい。

【0274】

シグネチャノードを実装するための多くの手法がある。たとえば、コンテンツノードの特殊なクラスとしてのラベルは、１つの手法である。特殊な属性は、シグネチャノードに割り当てられてもよく、その属性は、ファセット階層において最高の優先度を与えられてもよい。または、フィールドが、コンテンツノードの表において用いられ、この属性を規定してもよい。

【0275】

ファセット階層に基づく優先順位付けは、アルファベット順、数値順および年代順のソーティングなどの自動的な基礎によって補足されてもよい。従来のファセット分類において、優先順位付けおよびソーティングは、表記および引用順の問題である。システムは通常、優先順位付けおよびソーティングの属性の動的再順序付けを提供する。したがって、これらのオペレーションのさらなる説明は、ここでは行わない。
［軸定義および構造的完全性］
システムの一実施形態において、次元概念タクソノミを構築するための別の規則は、次元軸の構造的完全性に関する。概念定義（軸定義）としての各形態素（属性）集合は、次元軸を確立してもよい。これらの形態素から推測される次元概念関係は、親ノードによって決定されるように、すべての次元にわたって構造的に完全なままでなければならない。言い換えれば、親概念と交差するすべての次元はまた、ノードの子概念のすべてと交差しなければならない。以下の実施例が、説明する。

【0276】

概念定義｛Ａ，Ｂ，Ｃ｝を有する能動コンテンツノードを考える。

【0277】

Ａ、Ｂ、Ｃが、概念定義における３つの形態素であり、形態素Ｅ、Ｆ、Ｇがそれぞれ、形態素階層におけるＡ、Ｂ、Ｃの子たちである場合には、
｛Ａ，Ｂ，Ｃ｝は、形態素ＡおよびＢおよびＣを用いて記述される概念定義を指す。

【0278】

｛Ａ，＊｝は、Ａの暗黙の子であるノードを確立するために、明確な形態素Ａおよび暗黙の形態素｛＊｝の組み合わせを指す。

【0279】

｛Ａ｜Ｂ｝は、形態素｛Ａ｝または｛Ｂ｝のいずれかを指す。

【0280】

この実施例において、能動ノードにおける３つの形態素Ａ、Ｂ、Ｃは、次元概念階層における３つの次元（または交差軸）を確立するために用いられてもよい。このノードの子であるための任意の他のコンテンツノードに関して、候補は、３つの軸すべてに対する子たちでなければならない。以下の表記は、本発明の一実施形態によって定義されるように、明確な関係および暗黙の関係の解集合である：
｛Ａ｜Ｅ｜Ａ，＊｜Ｅ，＊），（Ｂ｜Ｆ｜Ｂ，＊｜Ｆ，＊），（Ｃ｜Ｇ｜Ｃ，＊｜Ｇ，＊）｝、
式中、第１の次元の形態素は、ＡまたはＥまたはＡの暗黙の形態素またはＥの暗黙の形態素である、
式中、第２の次元の形態素は、ＢまたはＦまたはＢの暗黙の形態素またはＦの暗黙の形態素である、
式中、第３の次元の形態素は、ＣまたはＧまたはＣの暗黙の形態素またはＧの暗黙の形態素である。

【0281】

処理の範囲は、次元軸の概念定義を抑制することによって、さらに制限されてもよい。個々の軸（以下では「能動軸」）は、親ノードから形態素の部分集合を参照することによって確立されてもよく、したがって、能動ノードにリンクしてもよい親（祖先）の集合を抑制する。効果的に、能動軸に関連付けられる概念定義は、能動ノードから能動軸の概念定義によって定義される階層に常駐するそれらのコンテンツノードだけに拡張する複数階層を抑制する仮想の親ノードを確立してもよい。

【0282】

以下の例は、概念定義｛Ａ，Ｂ，Ｃ｝に関する上記で紹介された例を用いたこの制約を示す。この実施例において、導出された次元概念関係は、概念定義｛Ａ，Ｂ｝を有する能動軸に抑制される。この制約の下で、能動ノードに対する潜在的な親（祖先）の集合は、集合
｛（Ａ，Ｂ）｜Ａ｜Ｂ｝に制限される。言い換えれば、整合する概念定義は、ＡまたはＢの組み合わせを含むだけであり、Ｃを含まない（また、この実施例において、形態素階層においてＡまたはＢに対する親はないと仮定する）。

【0283】

したがって、明確な関係および暗黙の関係の組み合わせは、概念間の階層関係を構築するための規則を確立してもよい。

【0284】

当業界は周知であるように、フィルタリング機能および順序付け機能のこれらのタイプを最適化するための多くの手法がある。これらには、インデックスおよびキャッシュなどのデータ管理ツールが含まれる。これらの改良点は、当業界では公知であり、本願明細書ではさらに説明しない。
［合成オペレーションのモード］
本発明のファセット分類の方法の場合には、合成オペレーションの種々のモードが、可能である。合成は、異なるドメインの個々の要件およびエンドユーザの要件に適合するように変化させてもよい。以下に記載するように、これらのモードは、以下のように定義されてもよい。
［静的合成対動的合成］
一実施形態において、「静的」ファセット分類合成は、提供され、この「静的」ファセット分類合成において、次元概念階層を定義する軸が、予め定義されてもよい。結果として生じる次元概念タクソノミが次に、静的構造としてアクセスされてもよい。

【0285】

ファセット分類合成の静的モードの利点は、ドメインオーナが次元概念タクソノミを正確な仕様に整理してもよいことである。したがって、これらの静的構造の中に含まれる情報にアクセスして消費するエンドユーザは、ドメインオーナの組織化する知識から恩恵を受けることができる。したがって、静的合成は、たとえば、情報のエンドユーザが、ドメインの中に含まれる情報の知識をほとんど持たない場合に、特に有用である。

【0286】

別の実施形態において、「動的」ファセット分類合成のシステムが、提供され、この「動的」ファセット分類合成のシステムにおいて、次元概念階層が、情報のエンドユーザに提供される合成パラメータに直接的に基づいて、略実時間で処理されてもよい。オペレーションのこの動的モードは、情報構造の徐々に増加し、純粋に「必要に応じた」組み立てを容易にする。

【0287】

動的処理は、情報の途方もない節約および格納の長所を提供し、エンドユーザ構造を予め作成して格納する必要性を取り除くことができる。さらに重要なことは、動的処理は、エンドユーザがそれらの要件に対する出力を正確に調整することを可能にし、パーソナライズ化の長所を提供してもよい。（合成オペレーションのモードは、以下でさらに詳細に説明される。）
さらに別の実施形態は、上記で紹介された静的合成のモードおよび動的合成のモードを組み合わせる。合成のこの混成モードの下で、ドメインオーナは、軸定義の選択を提供し、次元概念タクソノミに関する静的「大域的」構造を提供してもよい。その大域的構造の中で、動的合成は次に、個々のエンドユーザが彼らの必要に対して構造をさらに調整することができるようにするために用いられてもよい。したがって、この混成モードは、静的合成および動的合成の両方の長所を組み合わせている。
［概念階層およびコンテンツノードにおける制限］
ドメインおよびファセット階層のサイズが増大すると、推測されることができる次元概念関係の数が、急増する可能性がある。制限が、生成される関係の数に設けられてもよい。

【0288】

制限は、結果として生じる出力階層における関係概念または関連コンテンツノードの最大数を設定するために、ユーザによって入力されてもよい。たとえば、アドミニストレータが、合成オペレーションを設定して、システムが、１０の密接に関係する概念を階層に組み立てた後、処理を停止してもよい。
［抽象化レベルを変更する］
知識表現モデルおよび分析オペレーションの説明において、上記に記載されるように、概念定義を含む属性は、抽象化レベルを変更するために定義されてもよい。本願明細書に記載される一実施形態は、概念、キーワードおよび形態素の抽象化レベルでエンティティを提供する。合成において用いられる概念定義の属性における抽象化レベルの変更は、合成オペレーションの著しく異なる出力に影響を及ぼしてもよい。

【0289】

具体的に言えば、属性が、ドメインの中で、より基本的な形態素エンティティとなる傾向があるために、これらの属性を用いて定義される複雑な概念の間で、より多くの接続が、可能であってもよい。したがって、これらの形態素に関して属性を定義することは、結果として生じる合成出力を組織化するために、より大きな接続およびより多様な手法を提供してもよい。

【0290】

逆に言えば、属性が、キーワードまたは複雑な概念などのより抽象的で複雑なエンティティとなる傾向があるために、結果として生じる合成構造は、さらに正確で、一般的により少数の接続を有するが、より高い全体的な品質を有してもよい。したがって、合成オペレーションにおいて抽象化レベルを変化させることは、アドミニストレータ、ドメインオーナまたはエンドユーザが、個々の要件に基づいて情報を調整することを可能にしてもよい。
［ドメイン処理の範囲］
一実施形態において、次元概念タクソノミの完全な表示が、生成される前に、ドメインにおけるすべてのコンテンツノードが、調べられて比較されてもよい。言い換えれば、システムは、任意の推測が、これらの関連ノード間の直接的階層関係に関して行われることができる前に、関わる可能性があるドメインにおけるすべてのコンテンツノードを発見してもよい。

【0291】

ドメインにおけるすべてのコンテンツノードの完全な調査の長所は、ドメインの中の情報の網羅的な探査および発見を提供してもよいことである。高精度要件および再現率要件に関して、合成のこのモードは、適切である可能性がある。それは、比較的小さく、明確に境界を定められたドメインの場合は、好ましいことが多い。

【0292】

別の実施形態において、全体ドメインを分析する代わりに、ドメインの局所領域が、ユーザの能動的焦点に基づいて、分析されてもよい。この局所的な分析は、素材が、訓練集合の一部として以前に分析されたかどうかに関係なく、素材に適用されてもよい。パラメータは、処理時間（待ち時間）と分析の深さのバランスを取るために、アドミニストレータによって設定されてもよい。

【0293】

訓練集合の一部として分析されなかった素材に関して、システムは、訓練集合素材から導出された強化されたファセット分類体系の下で素材を分類するために、局所的な分析のオペレーションを用いてもよい。

【0294】

以下にさらに詳細に記載するように、ドメインから素材の局所部分集合を分類するオペレーションがまた、新たなドメインを分類するために用いられてもよいことに留意されたい。言い換えれば、１つのドメインから訓練集合は、新たなドメインから素材を分類するために、構成体系に関する基準として用いられ、したがって、マルチドメイン分類環境を支援してもよい。

【0295】

図２１は、合成の種々のモードをさらに詳細に示す。本発明の範囲を制限することなく、これらの例は、種々のモードを通じて提供される広範囲の合成オプションを実証する。この合成の柔軟性の長所は、ドメインの膨大なアレイおよびユーザの要件に適合するシステムを提供することである。
［静的（プレインデックス）合成］
図２１は、本発明の方法を示し、その一実施形態において、ファセット分類の増強方法に関する出力データは、次元概念タクソノミ２１０を作成し、ドメインを再組織化してもよい。出力データが、生成されてもよい（Ｍ）（上記に記載され、図１７に示される）。この方法に関する入力は、訂正された概念定義２１０４、キーワード階層２１１２およびドメインからのコンテンツノード３０２であってもよい。

【0296】

各概念定義７０８ｂは、キーワード階層２１１２におけるキーワードにマッピングされてもよい（２３０２）。概念に関する新たな次元概念関係は、上記に記載され、図３、図１８〜図２０に示されるように、ファセット分類の増強方法の規則によって生成されてもよい（８２０）。

【0297】

情報構造のアドミニストレータは、自動的に生成される次元概念タクソノミ構成の結果を手動で調整することが好ましい場合がある（２３０４）。オペレーションは、手動介入のこれらのタイプを支援してもよいが、完全に自動化されたオペレーションの場合にはユーザインタラクションを必要としない。

【0298】

分析２３０６は、結果として生じる次元概念タクソノミのパラメータを評価するために用いられてもよい。また、統計的パラメータは、次元概念タクソノミに関する倍率としてアドミニストレータによって設定されてもよい（２３０８）。統計的パラメータはまた、処理の範囲を削減することによって、複雑適応システムにおけるネガティブフィードバックとして複雑さを制限し、したがって、組み込まれる階層の数を減少してもよい。

【0299】

次元概念タクソノミ２１０は、以下に記載され、図２７に示されるように、ユーザインタラクションに関して利用可能であってもよい（Ｎ）。
［ドメイン部分集合（範囲制限型）合成］
図２２は、ドメインからコンテンツノードの選択および次元概念階層へのそれらのコンテンツノードの順序付けを示す。能動ノードに対するドメインの抑制された表示が、行なわれてもよい（２４０２）。全体ドメインを処理するのではなく、オペレーションは、能動ノードのすぐ近接する（２４０４）すべてのコンテンツノード（たとえば、２４０６）の直接的な調査を行なってもよい。
［再帰的概念階層の組み立て］
一実施形態において、関連コンテンツノードのこの差別化されていないグループを特定の構造グループに再分割するために、再帰アルゴリズムが有用であってもよい。「候補集合」は、能動概念定義に関わる概念の集合および関連付けられるコンテンツノードをそれらがどのように関わっているかの正確さを問わずに、記述する。グループは、親および子たち（階層関係）および兄弟（関連関係）として、能動概念またはコンテンツノードに対して記述されてもよい。これらのグループによって記述された構造関係は、当業界では公知である。これらの近接概念および関連付けられるコンテンツノードは次に、基本的な形態素関係および関与する形態素に基づいて、能動概念に対する階層関係に順序付けされてもよい。

【0300】

図２２において、この階層は、コンテンツノードの候補集合２４０４の中のコンテンツノード（たとえば、２４０６）間の関係の部分集合として示される。階層ツリー２４０８において、能動ノード２４０２に直接的に関わるそれらのコンテンツノード（直接的な子たち）は、候補集合２４０４の中の任意の他の親を有してもよい。候補集合における残りのコンテンツノードは、間接的な子たち（子孫）として階層においてより深く位置決めされてもよい。
［１つのドメイン分類体系を第２のドメインに適用する］
図２３は、ファセット分類体系を展開するために用いられた訓練集合の一部ではなかったドメインからの素材の局所部分集合を分類するオペレーションを示す。

【0301】

ドメイン２００から、ドメイン素材の局所部分集合２４０４ａは、処理のために選択されてもよい。素材は、ドメインオーナによって確立された選択判断基準に基づいて選択されてもよい（２５０２）。選択は、局所的な領域に関する基準である能動ノードに対して行なわれてもよい（２５０４）。選択プロセスは、局所部分集合の境界を記述する探索タームのリストなどの局所部分集合のパラメータを生成してもよい（２５０６）。

【0302】

局所集合に関する多くの潜在的な選択判断基準がある。一実施形態において、素材は、関連素材の集合を返すために、能動ノードに関連付けられる概念定義を全文情報検索（探索）構成要素に渡すことによって選択されてもよい。そのような全文情報検索ツールは、当業界では公知である。別の実施形態において、関連キーワードの集合を導出するために、拡張された探索クエリは、キーワード階層を調べることによって、能動ノードにおける概念定義から導出されてもよい。これらの関連キーワードは今度は、探索クエリを拡張して、能動ノードの概念定義に関するタームを含むようにするために用いられてもよい。

【0303】

選択プロセスから導出されるドメインの局所部分集合２４０４ａは、分類対象の候補コンテンツノードを含んでもよい。局所部分集合における各候補コンテンツノードに関して、概念シグネチャが、抽出されてもよい（２５０８）。概念シグネチャは、ドメインオーナによって特定されてもよく、ドメイン特有のキーワード階層２１１２にキーワード２３０２をマッピングするために用いられ、各候補コンテンツノードに関する概念定義を提供してもよい。また、構築構成要素は、概念シグネチャから導出されるすべてのキーワードが、（キーワード階層に登録されたものとして）システムにとって周知である必要はない。

【0304】

概念階層は、上記に記載される暗黙の関係および明確な関係の構築規則を用いて、候補コンテンツノードに関して予測されてもよい（８２０）。最終結果は、局所概念タクソノミ２１０ｃであってもよく、ドメインの局所部分集合からのコンテンツノードが、訓練集合からのそのドメインに関して導出される構成的体系の下で組織化される。分類をさらに改良するために、局所概念タクソノミは次に、ユーザインタラクション用の環境として利用可能であってもよい。
［動的（実時間）合成］
本発明の別の実施形態は、合成の動的モードを用い、実時間でユーザの好みを合成オペレーションに組み込む。図２４〜図２５および以下の説明は、動的合成のこのモードの中で、オペレーションにさらに詳細を提供する。

【0305】

図２４において、動的合成のモードの一実施形態が、広範な概観において示されている。動的合成プロセスは、オペレーションの要求応答モデルに従ってもよい。動的合成オペレーションは、ユーザ要求によって起動される（２４０２）。ユーザは、自分たちの要件（たとえば、自分たちの関心ドメイン、能動概念定義によって符号化されるような自分たちの関心話題、軸定義によって符号化されるような話題における自分たちの視点および制限合成パラメータの集合によって抑制されるような自分たちの関心の範囲）を指定してもよい。図２４において、これらのユーザパラメータは、内側のより多くの要素属性（４つの点）２４０４から構成される能動概念定義として概略的に簡略した形（ボックス）で表される。

【0306】

ユーザからこの動的入力を用いて、システムは次に、概念の関連付けられる階層（出力概念階層）２４０６を返してもよい。この出力概念階層は次に、ユーザによるさらなる探査の焦点であってもよく、または合成オペレーションのさらに別の段階へのブリッジとして働くことができる。

【0307】

この要求を処理するために、能動概念定義に関連付けられる属性集合は、合成される概念階層に関する候補集合２４１０として用いられる指定されたドメイン２４０８内から概念の集合の位置を特定するための基準であってもよい。それらの概念を能動概念定義に関連させるための「誘導」方法２４１２は、以下に記載される。誘導は、動的に分類され、関連概念の階層を構成するための参照として用いられてもよい。

【0308】

動的合成のモードの主要なステップおよび構成要素におけるさらなる詳細が、次に提供される。
［ユーザ起動合成要求］
動的合成オペレーションは、ユーザ要求によって起動される（３５０２）。動的合成プロセスを起動するために、ユーザは、ドメイン、能動概念定義および軸定義を提供してもよい。ユーザはまた、以下に説明される他の入力合成パラメータを介して、概念階層のサイズおよび形状を抑制してもよい。ユーザインターフェイスシステムの実装の説明において以下に記載するように、ユーザ入力のこのタイプを獲得するための多くの技術的手段がある。
［動的合成入力および合成パラメータ］
したがって、合成の動的モードに対する入力は、ユーザ特有の合成パラメータおよびドメイン特有のファセットデータ集合から構成されてもよい。これらの入力は、綿密に磨かれたフィールドに合成オペレーションを抑制してもよく、またはユーザの正確な要件の支配下に領域を置いてもよい。ドメイン特有のファセットデータ集合に関する詳細は、上記で提供される。
［実時間合成パラメータ］
上述のように、動的合成の一実施形態は、能動ドメイン、能動概念定義および能動軸定義のユーザ入力を提供してもよい。さらに、ユーザは、分離度を規定するパラメータと、概念およびコンテンツノードに関して合成オペレーションの出力を制限するパラメータと、をさらに提供することによって、自分たちの要件を記述してもよい。

【0309】

分離度パラメータは、能動概念定義から出力概念階層における関連概念定義に、最大数の直接的階層ステップを指定する。

【0310】

たとえば、ファセット分類の増強方法の構築規則に基づいて、代表的な能動属性集合｛Ａ，Ｂ，Ｃ｝と仮定すると、以下の属性集合が、除去される１つの分離度となる。

【0311】

｛Ａ，Ｂ，Ｃ，？｝：１つのさらなる要素を有するすべての上位集合、式中、？は１つの他の属性を表す
｛Ａ，Ｂ｝、｛Ａ，Ｃ｝、｛Ｂ，Ｃ｝：暗黙の属性関係に基づくすべての部分集合
Ａ→Ｄが明確な属性関係と仮定されると、｛Ｄ，Ｂ，Ｃ｝
［待ち時間］
待ち時間は、エンドユーザによって操作されてもよい合成の別のパラメータである。一つの実装において、「天井」応答時間は、合成オペレーションが、ユーザの合成要求と構築エンジン応答との間の最大時間まで制限されるように、システムに適用され、その要求を満たすように出力されてもよい。この待ち時間制御の別の実施形態は、エンドユーザが、要求応答時間を増減し、個々の情報のアクセス要件および発見要件に合致するように性能を調整することを可能にする。
［動的合成に関する候補集合］
動的合成に関する候補集合の組み立ての一実施形態が、図２５に示される。

【0312】

動的合成において、能動概念の属性集合は、明確に関係する祖先および子孫属性集合を求めるために、属性階層に対して調べられてもよい。これらの調査に関するより多くの情報が、合成（構築）規則の説明の下で、上記に提供される。また、全体ドメインは、動的合成のこの実時間モードの下で、完全に調べる必要はない。システムのみが、候補集合によって定義されるように、ドメインの部分集合を調べる。候補集合は、以下のように求められる。

【0313】

部分集合である属性集合または能動属性集合における属性集合の明確な祖先である要素を有する属性集合またはその両方が、考慮されてもよい。（これらは、潜在的な祖先概念を表す。）これらの関連属性集合２５０２ａ，２５０２ｂおよび２５０２ｃのそれぞれの中で、各属性は、整合概念定義のそれ自身の集合を有してもよい。所与の能動概念定義属性集合に関するこれらの概念集合２５０４ａ、２５０４ｂおよび２５０４ｃの交差集合は、その属性集合の整合概念を含んでもよい（整合概念は、黒点と示され、非整合概念は、白点として示される）。

【0314】

個別に、類似のプロセスが、上位集合であってもよい関連属性集合または能動属性集合の関連属性集合の明確な子孫である要素を有する関連属性集合またはその両方を用いて行われ、候補の子孫概念を表す。ここでもまた、関連属性集合に関する概念集合の交差集合は、その属性集合の整合概念を含んでもよい。

【0315】

関連属性集合のすべてからの交差集合の結合は、候補集合であってもよい。関連属性集合は、指定された軸定義に抑制されてもよい。それらの数もまた、指定された最大制限および分離度距離の対象であってもよい。
［概念階層の組み立てに関する誘導］
動的合成の実時間モードの下で、待ち時間は、主要な制限因子であってもよい。具体的に言えば、比較的小さな候補集合であっても完全に処理する時間はほとんどない。上述のように、概念階層合成の再帰方法を用いた合成の静的手段は、より大きなドメインに関して導入される可能性がある待ち時間のために、この動的環境に置き違えることが多い。

【0316】

したがって、動的合成の一実施形態は、実時間で概念階層を動的に組み立てるために、誘導の方法を用いる。誘導は、候補の概念が能動概念にどのように関連するかを記述するオペレーションの集合である。

【0317】

上記で紹介された性能および待ち時間削減という長所に加えて、誘導は、概念合成の新規な長所、すなわち、以下で説明する「仮想概念」として新たな概念定義の推測を導入する。これらの仮想概念は、たとえ、それらの新たな概念がコンテンツノードにまだ関連付けられていないとしても、新たな概念を推測することによって、システムの発見という長所を著しく拡張する。これらの誘導はまた、ユーザ設定可能なクラスタリングメカニズムとして、強力なソーティングおよびフィルタリング手段を提供する。

【0318】

候補集合は、能動概念の属性集合に関する属性集合から求められてもよい。明確に関する要素は、ファセットデータ集合における属性階層から求められてもよい。暗黙の関連属性集合は、集合交差点（すなわち、それらの属性集合の部分集合および上位集合）によって示唆されてもよい。ドメイン中で、暗黙の子孫属性を求めるために用いられるさらなる属性は、システムにとって周知であってもよく、周知でなくてもよい。

【0319】

能動属性集合は、候補集合における概念に関連付けられる属性集合のそれぞれとペアであってもよい。各ペアに関して、能動属性集合をそのペアになった集合に変換する集合オペレーションの順序が、導出されてもよい。

【0320】

関連属性集合を求めようとするプロセスにおいて、属性集合で行なわれてもよい４つの誘導オペレーションがある。オペレーションタイプは、表１に示されているように簡潔にすることができる。

【0321】

【表1】

すべての属性関係の方向性は、潜在的な概念関係のペアの中で一致しなければならないことに留意されたい。属性集合のペアは、それらの要素の間で祖先関係または子孫関係を有してもよいが、両方の関係を有するわけではない。

【0322】

プロセスの合成は、祖先オペレーション（ｐ，ｄ）または子孫オペレーション（ｃ，ａ）の両方ではなく、いずれかを適用することだけによって、この方向性を維持して、概念間の関係を確立する。これは、その属性のすべてを無関係の概念に対応する属性に置き換えることを防ぐ。

【0323】

たとえば、属性｛Ａ，Ｂ，Ｃ｝を有する能動概念および属性｛Ｄ，Ｂ，Ｇ，Ｆ｝を有する候補概念を仮定すると、その３つの属性に対応する能動概念の定義を通りぬける３つの軸がある。関係が概念間に存在するかどうかを決定するために、最初に、ＡからＤまでの明確な関係およびＣからＧまでの別の関係などの明確な関係を用いることが可能である。（これらは、両方ともｃオペレーションであり、属性を子属性に置き換える。）最後に、子孫属性（すなわち、Ｆ）を追加する暗黙のａオペレーションを用いることは、候補の子孫の属性に適合する能動概念の属性集合を結果として生じる。したがって、候補は、能動概念の子孫であると言うことができる。

【0324】

説明するために、能動集合および候補属性集合をペアにするとき、属性の３つの潜在的なグループがある。

【0325】

候補集合のみに関連付けられるグループ（「候補専用の」属性）
候補集合および能動集合に関連付けられるグループ（「両方の」属性）
能動集合のみに関連付けられるグループ（「能動専用の」属性）
能動集合を候補集合に変換することにより、「能動専用の」属性を消去する必要がある場合には、候補集合は、能動集合の祖先である。

【0326】

能動集合が候補集合と同一である場合には、候補集合は、能動集合の兄弟である。

【0327】

能動集合を候補集合に変換することにより、「候補専用の」属性を追加する必要がある場合には、候補集合は、能動集合の子孫である。

【0328】

２つの元の集合が既に、共通の属性を有しているかどうかに関係なく、「能動専用の」属性の消去および「候補専用の」属性の追加の両方を行なうことによって、能動集合を候補集合に変換することは、有効ではない。そのようなペアは、関連していないと思われる。これに対する唯一の例外は、「専用の」集合における属性が、属性階層に関係している場合である。そのような場合には、以下の２つのオペレーションのうちの１つを行うことができる。

【0329】

能動集合属性をその親属性（能動集合の祖先である候補集合を有する）に置き換える
能動集合属性をその子属性（能動集合の子孫である候補集合を有する）に置き換える
このとき、結果として生じる属性は、「両方の」集合の構成員である。

【0330】

所与のレベルで、兄弟が提示される順序が、重要である場合がある。ユーザにとって重要である確立がさらに高いそれらの概念は、より高い優先度を有するべきである。

【0331】

候補集合における各概念は、それを能動概念に接続する固有の誘導シリーズを有してもよい。誘導がソートされ、合成によって対処される順序は、結果階層における概念の順序付けに影響を及ぼす。階層における候補概念の優先度は、表２に基づいて決定される。

【0332】

【表2】

［応答］
ユーザの要求において指定される要件に応じて、アプリケーションは、ドメイン内のオブジェクトに関連付けられる概念から構築され、能動概念に関し、軸に沿った概念階層を返してもよい。ユーザは、指定される能動概念に関する概念を求めるためのこの概念階層を指してもよい。

【0333】

誘導は、階層結果集合に構築されてもよい。その階層における各ノードは、その概念定義として属性集合を有する概念を表す。階層における各エッジは、１つの誘導オペレーションを表す。
［仮想概念］
場合によっては、概念階層ノードにおける属性集合は、整合概念を有していない。仮想概念は、これを示すためのプレースホルダとして用いられてもよい。

【0334】

たとえば、
明確な関係Ａ→Ｄであり、
明確な関係Ｄ→Ｆであり、
｛Ｄ，Ｂ，Ｃ｝属性集合を有する概念がない場合には、
属性集合｛Ａ，Ｂ，Ｃ｝を仮定すると、
｛Ｆ，Ｂ，Ｃ｝は、｛Ａ，Ｂ，Ｃ｝から１つの分離度を有する候補集合であってもよい。｛Ｄ，Ｂ，Ｃ｝属性集合が、対応する概念を持たない場合には、階層におけるこのノードに仮想概念がある。

【0335】

能動ドメイン内から動的合成プロセスは、能動概念に関する概念の階層を分離して返してもよい。関係概念は、指定された軸に沿って指示されない限り、能動概念からの祖先（より広範囲な）方向および子孫（より特異的）方向の両方に分岐してもよい。

【0336】

次元概念タクソノミ２１０を導出するデータ構造は、多くの目的のために、多くの手法で表されてもよいことに留意されたい。続く説明において、エンドユーザインタラクションの目的が示されている。しかし、これらの構造はまた、たとえば、別の情報検索またはデータマイニングツール（図示せず）への入力として、他のデータ操作技術のサービスにおいて用いられてもよい。
［複雑適応フィードバックメカニズム］
図２７は、複雑適応システムにおいてユーザインタラクションを処理するための方法を示す。この方法は、上記に記載される次元概念タクソノミプロセスＮを構築する。ユーザインタラクションは、システムに対するフィードバックの集合を確立してもよい。複雑な次元構造に対する改良の適応プロセスは、エンドユーザによって起動されるフィードバックを通じて達成されてもよい。

【0337】

図３７は、１つまたは複数の次元概念タクソノミ４０１０の形でファセット分類情報の態様の操作を可能にするコンピュータシステム４０００の考えられる実装を示す。システム４０００は、実装を実行するためのコンピュータプログラム、ソフトウェアまたはファームウェア４０８０を収容するディスクドライブまたは他の形態のコンピュータメモリなどのコンピュータ可読媒体４０２０のほか、概念定義４０９０などの次元概念タクソノミの態様、階層データ４１００、コンテンツノード４１１０、コンテンツノード４１２０に対応する定義または次元概念タクソノミ４０１０の態様の分類４１３０またはそれらのうちの１つを含んでもよい。システム４０００はまた、プロセッサ４０３０、キーボードまたはマウスなどのユーザインターフェイス４０４０およびディスプレイ４０５０を含んでもよい。この実装において、コンピュータプロセッサ４０３０は、コンピュータ可読媒体４０２０にアクセスし、ソースデータから生成された次元概念タクソノミ４０１０の少なくとも一部を検索し、ディスプレイ４０５０上にタクソノミ４０１０の一部を提示してもよい。プロセッサ４０３０はまた、次元概念タクソノミ４０１０の態様のユーザ操作を反映して、インターフェイス４０４０（任意にユーザインターフェイス）を介して、外部エンティティ（ユーザまたは機械）から入力してもよい。プロセッサ４０３０は、第１の次元概念タクソノミ４０１０において見られる多数の潜在的な関係の任意の１つの受信された外部エンティティ操作を第２の次元概念タクソノミに組み込んでもよい。外部エンティティ操作は、たとえば、データの第１の次元概念タクソノミ４０１０に対する改変または追加、概念定義、階層データの編集、概念に関連付けられる他のコンテンツノードに対する概念に関連付けられるコンテンツノードの位置の変更、コンテンツノードの主題を記述する定義の変更またはファセット分類に対する他の改変の形であってもよい。第２の次元概念タクソノミは、第１の次元概念タクソノミ４０１０を全体的に置き換えてもよく、第１の次元概念タクソノミ４０１０のそばにまたは第１の次元概念タクソノミ４０１０から離れて完全に存在してもよく、第１の次元タクソノミ４０１０に対する例外表として常駐するなどしてもよい。さらに、第２の次元概念タクソノミに対する利用しやすさは、外部エンティティ、たとえば、ドメインオーナおよびアドミニストレータ、加入者、特定の遠隔コンピュータデバイスなどの一定のクラスに制限されてもよい。

【0338】

ディスプレイ４０５０は、インターフェイス４０４０に応答することができるプロセッサ制御型ディスプレイウィンドウまたはエディタ４０７０の形で次元概念タクソノミ４０１０の態様を提示してもよい。エディタ４０７０はまた、ウェブページの形をとってもよく、コンテンツノードと、次元概念タクソノミ４０１０またはその改変物から導出されるファセット分類を提示してもよい。エディタによって示されるコンテンツノードおよびファセット分類は、外部エンティティによって選択される能動ノードに対応してもよく、たとえば、ツリー断片の形をとってもよい。エディタ４０７０はまた、外部エンティティが、次元概念タクソノミ４０１０の態様を操作してもよいか、または新たな要素、関係およびコンテンツを導入してもよい編集機能性を提示してもよい。編集機能性はまた、外部エンティティがノードのコンテンツに関連付けられる１つまたは複数の形態素グループを改変することを可能にするレビューインターフェイスのほか、ノードのコンテンツと一致することを可能にする次元概念タクソノミにおけるノードの位置を含んでもよい。

【0339】

したがって、以下のように、複雑適応プロセスの方法をまとめてもよい。

【0340】

ユーザインタラクション２１２ａ用の環境として次元概念タクソノミを提供する。一旦、次元概念タクソノミ２１０が、ユーザに提示されると、既存のデータの訂正のための環境のほか、新たなデータ用のソース（次元概念タクソノミ情報）となってもよい。入力データ８０４ａは、既存のデータに対する編集およびユーザによる新たなデータの入力から構成される。入力データ８０４ａはまた、動的ドメインに対する分類を展開して適合する。

【0341】

ユーザインタラクションは、システムへのフィードバックを含んでもよい。次元概念タクソノミ情報におけるデータ要素の固有の識別子は、集中システムに格納される形態素要素に基づいて、表記システムを用いて一意に特定されてもよい。したがって、システムによって生成される次元概念タクソノミにおける各データ要素は、集中型（共有型）形態素辞書に戻るように統合されることができる手法において特定されてもよい。

【0342】

したがって、ユーザがそれらの要素を操作するとき、関連形態素要素における不確かな影響が、追跡されてもよい。これらの変更は、システムにおける新たな明確なデータを反映し、システムによって自動的に生成された推測データのいずれかを改善してもよい。言い換えれば、システムによって元々推測されたことが、エンドユーザの明確なインタラクションによって補強または却下されてもよい。

【0343】

ユーザインタラクションは、新たなデータソースおよび既知のデータソースに対する訂正の両方を含んでもよい。既知の要素に対する操作は、形態素の素性に戻るように変形されてもよい。システムによって認識されない任意のデータ要素は、新たなデータを表してもよい。しかし、変更がシステムによって作成される既存の次元概念タクソノミとの関連において行なわれるため、この新たなデータは、既知のデータとの関連において配置されてもよい。したがって、ユーザによって追加される任意の新たなデータ要素は、既知の要素との関連において提供されてもよい。既知の要素と未知の要素との間の関係は、ユーザのインタラクションから推測されることができる次元概念タクソノミ情報の量を著しく拡大する可能性がある。

【0344】

システムにおける「ショートカット」フィードバック２１２ｃは、エンドユーザに関する実時間インタラクティブ環境を提供してもよい。ユーザによって起動されるタクソノミおよびコンテナ編集２９０２は、システムにおいて待ち行列に入れられ、システムリソースが、利用可能になったときに、正式に処理されてもよい。しかし、ユーザは、次元概念タクソノミに対する自分たちの変更に対して実時間フィードバックを必要とする（好む）場合がある。システムの正式なフィードバックを通じた変更を処理するために必要な時間は、ユーザに対するこの実時間フィードバックを遅延させる可能性がある。その結果、システムの一実施形態は、ショートカットフィードバックを提供する。

【0345】

このショートカットフィードバックは、その時間に存在するときに、ドメインデータストア７０６に対するユーザ編集を処理することによって始めてもよい。ユーザの変更が、ドメインデータストアに現在存在しない次元概念タクソノミ情報を含んでもよいため、システムは、変更の影響を見積もるプロセスを用いなければならない。

【0346】

暗黙の関係２１２ｂを作成するための規則（上記に記載される）は、完全な処理の短期的な代わりとして、新たなデータに適用されてもよい。この手法は、ユーザが、新たなデータをすぐに挿入して対話することを可能にする。

【0347】

システムの正式のプロセスを通じて予測される次元概念関係とは対照的に、この見積もりプロセスは、既知の形態素の集合において、システムに対して未知の形態素の存在を用い、集合における既知の形態素の次元概念関係を適任として調整してもよい。これらの調整された関係は、上記でさらに詳細に述べた「暗黙の関係」２１６として記述される。

【0348】

新たなデータ要素に関して、短期的な概念定義は、（上記に記載される）暗黙の関係に基づいて割り当てられ、インタラクションの実時間処理を容易にしてもよい。ドメインに関する次の完全な処理サイクルの終了時に、短期的な暗黙の概念定義は、システムによって考案される完全な概念定義と置き換えられてもよい。

【0349】

当業者は、システムにおける既知の形態素の関係への未知の形態素の影響を見積もるために用いられてもよい多くのアルゴリズムがあることを認識されよう。
［ユーザインタラクションを提供する］
次元概念タクソノミは、ユーザインタラクションのための環境を提供する。本発明の一実施形態において、２つの主なユーザインターフェイスが提供されてもよい。ナビゲーション「ビューア」インターフェイスは、ファセット分類をブラウジングするために設けられてもよい。このインターフェイスは、「ファセットナビゲーション」として周知のクラスであってもよい。他のインターフェイスは、「アウトライナ」として周知であってもよく、エンドユーザが、関係構造、概念定義およびコンテンツノードの割り当てを変更することを可能にしてもよい。

【0350】

ファセットナビゲーションインターフェイスおよびアウトライナインターフェイスの一般的な特徴は、当業界では公知である。以下で本願明細書に記載される新規な態様は、特に複雑適応システム２１２に関するときには、当業者には明白であろう。
［概念タクソノミを表示する］
次元概念タクソノミは、プレゼンテーション層を通じて表現されてもよい。一実施形態において、プレゼンテーション層は、ウェブサイトである。ウェブサイトは、次元概念タクソノミの表示の集合をレンダリングするウェブページから構成されてもよい。表示は、能動ノードの範囲内に次元文脈タクソノミの一部（たとえば、１つまたは複数の軸によってフィルタリングされる複数階層の部分集合）である。これに関連する能動ノードは、エンドユーザまたはドメインオーナによって現在焦点が合わせられている次元概念タクソノミ内のノードである。一実施形態において、「ツリー解析」は、これらの関係を表すために用いられる。

【0351】

ユーザは、それらの探索および情報検索の一般的な領域に直接的に移動するように、システムにテキストクエリを提供してもよい。表示は、当業界では公知であるように、各概念と交差するファセットおよび属性によってフィルタリングおよびソートされてもよい。

【0352】

コンテンツノードは、各概念によってカテゴリ化されてもよい。すなわち、任意の所与の能動概念に関して、ユーザによってフィルタリングされるような概念の属性に適合するすべてのコンテンツノードが提示されてもよい。

【0353】

各表示の「解像度」は、各ノード付近で変更してもよい。これは、表示された関係の広さおよび調査の徹底度を指す。表示の解像度の問題はまた、分析されるドメイン部分のサイズおよび選択との関連において考慮されてもよい。また、分析の深さと処理にかかる時間（待ち時間）の量との間には、兼ね合いがある。プレゼンテーション層は、能動ノードの位置に基づいて、分析されるドメインの一部を選択するように動作してもよい。表示の解像度およびパラメータは、アドミニストレータによって設定される。

【0354】

一実施形態において、次元概念タクソノミの表示のインタラクション、（上述のように）動的合成のモードの作動は、本発明の複雑適応システムに関するフィードバックを生成してもよい。これらの条件下で、表示のインタラクションを通じて生成される暗黙のフィードバックは、エンドユーザの視点から本質的に見えないことになる。言い換えれば、エンドユーザは、次元概念タクソノミを表示する単なるインタラクションによってシステムに関する有益なフィードバックを作成することになる。

【0355】

この見えないユーザ生成フィードバックには多くの長所がある。エンドユーザは、（以下に詳細に説明されるように）次元概念タクソノミに対する直接的な編集を必要とされる努力に費やさなくて済む。さらに、動的合成のこのモードの下で、ユーザによって要求される次元概念階層のみが、次の分析オペレーションに関するフィードバックとして返される次元概念タクソノミを含むため、エンドユーザによって実際に要求される情報のみに抑制されたフィードバックのより狭い集合は、システムによって生成されるフィードバックデータの品質を改善する効果がある。
［概念タクソノミを編集する］
プレゼンテーション層は、次元構造を抜き出して、人間のインタラクションに必要な簡略された表示（次元概念タクソノミにおける関連ページへのリンクを含むウェブページなど）にする。したがって、プレゼンテーション層はまた、導出される情報構造に関する編集環境をかねてもよい。一実施形態において、ユーザは、構造を直ちに編集するために、プレゼンテーション層内から編集モードに切り換えることができる。

【0356】

アウトライナは、階層データを操作するためのユーザ用の手段を提供する。アウトライナはまた、ユーザが、構造における各概念に関連付けられるコンテンツノードを操作することを可能にする。

【0357】

ユーザインタラクションは、次元概念タクソノミにおけるノードに割り当てられる文脈および／または概念を改変してもよい。文脈は、構造における他のノードに対するノードの位置（すなわち、構造を確立する次元概念関係）を指す。概念定義は、形態素の収集として表現されるノードのコンテンツまたは主題を記述する。

【0358】

ユーザは、一実施形態において、レビュープロセスが提示され、ユーザが、そのようなユーザの編集のパラメータを確認することができるようにしてもよい。以下の次元概念タクソノミ情報、１）ノードのコンテンツ、２）コンテンツに関連付けられる形態素グループ（キーワードとして表現される）および３）タクソノミ構造におけるノードの位置は、このレビューに関して、ユーザに公開されてもよい。ユーザは、後者の２つ（形態素および相対的な位置決め）のパラメータを改変して、第１のパラメータ（そのノードにおけるコンテンツ）と情報を一致させてもよい。

【0359】

したがって、本発明の一実施形態におけるインタラクションは、２つの広範なタイプ、ａ）コンテナ編集およびｂ）タクソノミ編集のいくつかの組み合わせとしてまとめられてもよい。

【0360】

コンテナ編集は、次元概念タクソノミ内に分類されるコンテンツノードに対するコンテンツコンテナ（ＵＲＬアドレスなど）の割り当てに対する変更である。コンテナ編集はまた、次元概念タクソノミ内のコンテンツノードの記述に対する変更である。

【0361】

タクソノミ編集は、次元概念タクソノミにおけるノードの位置に対する文脈の変更である。これらの変更は、構造への新たなノードの追加および既存のノードの再位置決めを含む。この次元概念タクソノミ情報は、ユーザインタラクションによって影響される概念に関連付けられる形態素関係に対する変更としてシステムにフィードバックされてもよい。

【0362】

タクソノミ編集を用いて、タクソノミにおける概念間に新しい関係を作成してもよい。これらの概念関係は、ユーザインタラクションを通じて構成されてもよい。これらの概念は、形態素に基づいているため、新たな概念関係は、形態素関係の新たな集合に関連付けられてもよい。この次元概念タクソノミ情報は、これらの示唆された形態素関係を再予測するために、システムにフィードバックされてもよい。

【0363】

ユーザインタラクションはまた、キーワードおよび形態素などの抽象化のさらに要素的なレベルで提供されてもよい。

【0364】

図２６は、コンテナ編集のプロセスの一実施形態を示す。コンテナ編集は、概念定義と、各コンテンツノードを記述する基本的な形態素と、に対する変更である。これらの変更を用いて、ユーザは、コンテンツノードの基本的な概念定義を改変してもよい。その際には、これらのコンテンツノードで概念定義にマッピングされる形態素を改変してもよい。

【0365】

ユーザインタラクションは、キーワードの収集として表現されるコンテンツノードに割り当てられる概念定義を構成してもよい。この構成において、ユーザは、システムの形態素辞書およびドメインデータストアと対話してもよい。ここで作成される任意の新たなキーワードは、上記に記載されるように、システムの形態素抽出プロセスに送られてもよい。

【0366】

この実施例において、文書２８０１は、能動コンテナである。ユーザインターフェイスにおいて、コンテンツを記述するキーワードの集合２８０２は、文書と共にユーザに提示されてもよい。（実施例を簡単にするために、次元概念タクソノミにおけるこのノードの相対的な位置は、ここでは示さない。）
実施例において、ユーザがコンテンツをレビューするときに、ユーザは、ページに関連付けられるキーワードが最適でないことを決定してもよい。新たなキーワードは、ユーザによって選択され、ページをロードする集合２８０３を置き換えてもよい。ユーザは、文書に関連付けられる新たな概念定義として、キーワードのリスト２８０４を更新してもよい。

【0367】

これらの変更は次に、ドメインデータストア７０６に渡されてもよい。データストアは、システムに登録されたすべてのキーワードを特定するために、探索されてもよい。

【0368】

この実施例において、リストは、「犬」を除くユーザによって特定されるすべてのキーワードを含む。その結果、「犬」は、システムに登録される明確なキーワードを修飾する暗黙のキーワードとして処理される。

【0369】

暗黙のキーワードは、ドメインが、集中型変換エンジンによってレビューされるときに、全部分析されてもよい。暗黙のキーワードは次に、明確なキーワード（既存のキーワードまたは新たなキーワードのいずれかとして）置き換えられ、１つまたは複数の形態素に関連付けられてもよい。
パーソナライズ化
図２８は、パーソナライズ化の特徴を提供する本発明の別の実施形態を示し、次元概念タクソノミのパーソナライズ化バージョンは、ドメインの個々のユーザのそれぞれに関して維持されてもよい。

【0370】

パーソナライズ化の一実施形態は、各個々のユーザに関するパーソナライズ化概念タクソノミ２１０ｆと共に、共同概念タクソノミ２１０ｅをパーソナライズ化するための手段を提供する。最初にエンドユーザがシステムと対話するときに、各エンドユーザは、共同概念タクソノミ２１０ｅに関与している最中であってもよい。続くインタラクションは、タクソノミ２１０ｆのユーザのパーソナライズ化表示に関与してもよい。

【0371】

データ構造は、各エンドユーザの好みを表すユーザインタラクション２１２ａに応じて、データ構造の固有な表現を照合することによって「パーソナライズ化」される。編集の結果は、ユーザインタラクションからパーソナライズ化データとして格納されてもよい（３００４）。一実施形態において、これらの編集は、共同概念タクソノミ２１０ｅに対する「例外」として格納される。パーソナル概念タクソノミ２１０ｆが処理されるとき、システムは、ユーザの例外表に見られる任意の変更を代用してもよい。

【0372】

示される要素は、システムの複雑適応プロセスにおけるコラボレータを特定してもよい。各ユーザを固有の識別子に関連付けて、それらのインタラクションを格納するための手段を提供する。

【0373】

別の実施形態において、システムは、プレゼンテーション層を通じて、次元概念タクソノミ２１０ｅと対話する各ユーザに固有の識別子を割り当ててもよい。これらの識別子は、形態素と見なされてもよい。あらゆるユーザは、大域的に一固有の識別子（ＧＵＩＤ）を割り当ててもよく、すべてのコンピュータおよびネットワークにわたって用いられることができる１２８ビット整数（１６バイト）であることが好ましい。ユーザＧＵＩＤは、システムにおける形態素として存在する。

【0374】

システムにおける任意の他の形態素のように、ユーザ識別子は、形態素階層（明確な形態素）に登録されてもよく、システムに対して未知（暗黙の形態素）であってもよい。

【0375】

２つのタイプの識別子の間の差異は、当業界では公知の用語において、登録済みビジタおよび無記名のビジタとの間の差異に類似している。識別子を生成し、識別子（または「トラッカ」）をユーザと関連付けるために用いられてもよい種々の手法もまた、当業界では公知であり、本願明細書において説明しない。

【0376】

ユーザが、（たとえば、コンテンツコンテナを編集することによって）システムと対話するとき、システムは、概念定義を記述する形態素の集合にそのユーザの識別子を追加してもよい。システムはまた、システムが支援するインタラクティビティの種々のタイプに関連付けられる１つまたは複数の形態素を追加してもよい。たとえば、ユーザ「ボブ」は、地理参照を含むように概念定義「レコーディング、スタジオ」に関してコンテナを編集したいと思っている。したがって、システムは、ボブに特有のそのコンテナに関して以下の概念定義のレコード｛ボブ、ワシントン、（レコーディング、スタジオ）｝を作成してもよい。

【0377】

この次元概念タクソノミ情報を用いて、システムは、上記に記載されるファセット分類の増強方法において、明確な関係および暗黙の関係の予測の同一の規則を適用することによって、ユーザボブに特有の態様のコンテナを提供することができる。コンテナは、ボブに関するパーソナルウェブページに現れてもよい。彼のパーソナル概念タクソノミにおいて、ページは、ワシントンにおけるリソースに関わっていることになる。

【0378】

次元概念タクソノミ情報はまた、他のユーザに対しても大域的に利用可能であってもよく、ネガティブフィードバックメカニズムとしてアドミニストレータによって確立される統計的分析およびハードルレートを対象としてもよい。たとえば、十分なユーザが、レコーディングスタジオに関してワシントンの位置を特定する場合には、最終的には、有効な関係としてすべてのユーザに提示されることになる。

【0379】

コンテンツコンテナに関連付けられる概念定義に対する修飾のこのタイプは、次元性の新たな層をユーザインタラクティビティの種々の送を表す次元概念タクソノミに本質的に追加する。このタイプは、情報およびコンテンツの他の形態に適用される既存の構成的プロセスを用いて、パーソナライズ化用汎用メカニズムを提供する。

【0380】

当業界では公知であるように、パーソナライズ化およびカスタマイズ化されたプレゼンテーション層を追加するために利用可能な多くの技術およびアーキテクチャがある。本願明細書において説明される方法は、コラボレータを組織化するために、システムの中核構造論理を利用する。この方法は、正に情報要素の別のタイプとして、ユーザインタラクションを本質的に取り扱い、システムの柔軟性および拡張性を示す。しかし、この方法は、システムにカスタマイズ化およびパーソナライズ化を追加するための種々の方法において、本発明の範囲を制限しない。
［機械に基づく複雑適応システム］
図２９は、複雑適応システムを提供するための機械に基づく手段を提供する別の実施形態を示し、次元概念タクソノミ２１０を含む次元概念関係が、システム入力データ８０４ｂとして変換エンジンプロセスに直接的に戻るように返される（３１０２）。

【0381】

これに関して、本発明は、本開示において記載するように、データ構造を作成して管理するエンドユーザの能力を提供することに留意されたい。本発明の一定の態様において、エンドユーザは、本願明細書において説明するように、データ構造の作成および管理をさらに通知するフィードバックを提供する。このフィードバックは、エンドユーザによってのみだけでなく、たとえば、エンドユーザからフィードバックを収集するコンピュータなどの機械または、全く人間が関与することのないコンピュータなどの機械によってさえも提供されてもよい。これに関連して、エンドユーザまたは機械の役割は、本開示において「フィードバックエージェント」として呼ばれる。本開示において提供される複数の実施例は、例証のためにエンドユーザを指すこともまた留意すべきであるが、これらの場合のすべてではないが、多くの場合には、コンピュータなどの機械は、エンドユーザの役割に取って代わることが可能であることを理解すべきである。この小見出しは、そのような実装を示す。したがって、本開示は、「エンドユーザ」に対する言及は、すべての場合ではないが多くの場合には、「フィードバックエージェント」を指すように読むべきである。
ソースデータ構造から導出される元の概念関係とシステム構築エンジンのプロセスから生じる次元概念関係との間には、重要な差異があることに留意されたい。前者の関係は、ソースデータ構造において明確であり、後者の関係は、形態素辞書内の要素構成要素に対して適用される構成方法から導出（または生じる）。したがって、ユーザインタラクションに基づく複雑適応システムのように、機械に基づく手法は、要素構成物からの（複雑な）次元概念関係の合成を通じて、システムオペレーション８００に変型を導入し、次に、ソース構造分析結果の構成要素におけるその変型から選択するための手段を提供してもよい。

【0382】

オペレーションのこの機械に基づくモードの下で、複雑適応システムに関する選択要件は、ソース構造分析結果構成要素（上記に記載され、図６に示される）によって担われてもよい。具体的に言えば、次元概念関係は、円環的関係の特定１００２と、これらの円環的関係を解明するために用いられてもよい種々のモードおよびパラメータと、に基づいて選択されてもよい。当業界では公知であるように、機械に基づく複雑適応システムを提供するために、多くの別の手段、選択判断基準および分析ツールがある。

【0383】

円環的関係の存在を通じて集合体において特定される階層の仮定に反する次元概念関係は、データ集合から取り除かれてもよい（１００４）。この取り除かれたデータ集合は、入力概念タクソノミ１００８に再組み立てされてもよく（１００６）、これにより、オペレーション８００は、分析エンジンの残りのオペレーションを通じて要素構成物の新たな集合を導出してもよい。

【0384】

機械に基づく複雑適応システムのこのタイプは、図４および図２７に関して上記に記載されるユーザインタラクションに基づくシステム２１２などの他の複雑適応システムと連動して用いられてもよい。たとえば、図３０の機械に基づく複雑適応システムは、プロセスの複数回の反復を通じて、次元概念タクソノミを精製するために用いられてもよい。その後で、結果として生じる次元概念タクソノミは、さらなる精製および進化のために、ユーザに基づく複雑適応システムにおいて、ユーザに導入されてもよい。
［実装］
システムアーキテクチャのこの説明を通じて強調されたように、データストアをはじめとして本発明の多くの実施形態を設計するための方法および技術においてさまざまな変動性がある。本発明の多くの用途は、当業界では公知であるアーキテクチャ技術の多くの形を通じて、明らかとなり、変化させられてもよい。
［システムアーキテクチャ構成要素］
［計算環境］
図３０は、本発明に関する計算環境の一実施形態を示す。
一実施形態において、本発明は、４層アーキテクチャの下で動作するコンピュータソフトウェアプログラムとして実装されてもよい。サーバアプリケーションソフトウェアおよびデータベースは、集中型コンピュータおよび分散型非集中型システムの両方で実行されてもよい。インターネットは、集中型サーバおよび種々の計算デバイスと、計算デバイスと対話する分散型システムとの間で通信を行なうために、ネットワークとして用いられてもよい。

【0385】

計算環境のこのタイプを確立するための変動性および方法は、当業界では公知である。したがって、計算環境のさらなる説明は、本願明細書には入れない。すべての適用可能な環境に共通であることは、ユーザが、インターネットまたは会社のイントラネットなどのパブリックネットワークまたはプライベートネットワークに自分のコンピュータまたは計算デバイスを通じてアクセスし、それにより、本発明を具体化するコンピュータソフトウェアにアクセスすることである。
［サービス層］
各層は、サービスを提供する責任があってもよい。層１（３２０２）および層２（３２０４）は、集中型処理のモデルの下で動作する。層３（３２０６）および層４（３２０８）は、分散型（非集中型）処理のモデルの下で動作する。

【0386】

この４層モデルは、ドメインを分析するためにシステムが用いる共有された集中型データからプライベートドメインデータの非集中化を実現する。共有データとプライベートデータとの間のこの描写は、以下で説明され、図３３に示される。

【0387】

第１の層で、集中型データストアは、システムによって管理される種々のデータソースおよびコンテンツソースを表す。一実施形態において、データベースサーバ３２１０は、データサービスと、データにアクセスして、データを維持する手段と、を提供してもよい。

【0388】

分散型コンテンツは、ここでは「データベース」内に収容されるものとして記載されているが、データは、複数のリンクされた物理位置またはデータソースに格納されてもよい。

【0389】

メタデータはまた、非集中型であり、システムデータベースから外部に格納されてもよい。たとえば、メタデータを含むＨＴＭＬコード断片は、システムによって作用されてもよい。外部スキーマからの要素は、本システムのスキーマにおいて用いられる要素にマッピングされてもよい。メタデータを提示するための他の形式は、当業界では公知である。したがって、情報の展望は、豊富な分散型コンテンツソースと、非集中型手法において情報を管理するためのエンドユーザ用の手段と、を提供してもよい。

【0390】

複数のリンクされた物理的な位置またはデータソースにわたってデータを管理するための技術および方法は、当業界では公知であり、本願明細書においてさらに徹底的に説明されない。

【0391】

ＸＭＬデータフィードおよびアプリケーションプログラミングインターフェイス（ＡＰＩ）３２１２は、データストア３２１０をアプリケーションサーバ３２１４に接続するために用いられてもよい。

【0392】

また、当業者は、ＸＭＬが広範囲の所有権およびオープンスキーマに従ってもよいことを理解される。さまざまなデータ交換技術は、種々の分散型コンテンツ形式をシステムに組み込むためのインフラストラクチャを提供する。一実施形態において用いられるコネクタのこの説明およびすべての以下の説明は、本発明の範囲を限定するわけではない。

【0393】

第２の層３２０４で、集中型サーバ３２１４に常駐するアプリケーションは、本発明に関する中核プログラミング論理を含んでもよい。アプリケーションサーバは、データベースサーバへの接続性に加えて、本発明の方法の種々の態様の実装のための処理規則を提供してもよい。このプログラミング論理は、上記で詳細に記載され、図４〜図１７および図２０〜図２３に示される。

【0394】

一実施形態において、アプリケーションサーバによって処理される構造情報は、ＸＭＬ３２１６として出力されてもよい。ＸＭＬは、外部データストアおよびウェブサイトをアプリケーションサーバと接続するために用いられてもよい。

【0395】

また、ＸＭＬ３２１６は、最適化および精製の進行中のプロセスにおけるさらなる処理のために、アプリケーションサーバに戻るようにこのインタラクティビティを通信するために用いられてもよい。

【0396】

第３の層で、分散型データストア３２１８は、ドメインデータを格納するために用いられてもよい。一実施形態において、このデータは、ウェブサーバでＸＭＬファイルの形で格納されてもよい。外部データベースなどのドメインデータを格納する多くの別のモードがある。分散型データストアは、出力データをエンドユーザの提示デバイスに分散するために用いられてもよい。

【0397】

一実施形態において、出力データは、ＸＭＬデータフィードとして分配され、ＸＳＬ変換ファイル（ＸＳＬＴ）３２２０を用いてレンダリングされてもよい。これらの技術は、第４の層で、プレゼンテーション層を通じて、出力データをレンダリングしてもよい。

【0398】

プレゼンテーション層は、任意の非集中型ウェブサイト、クライアントソフトウェアまたは人間または機械によって利用されてもよい形でタクソノミを提示する他の媒体であってもよい。プレゼンテーション層は、タクソノミの表面的な明示と、エンドユーザがタクソノミと対話する環境を表してもよい。一実施形態において、データは、ウェブサイトとしてレンダリングされ、ブラウザに表示されてもよい。

【0399】

この構造化情報は、ユーザコラボレーションおよび入力用のプラットフォームを提供してもよい。当業者は、ＸＭＬおよびＸＳＬＴが、多様な範囲の計算プラットフォームおよび媒体にわたって、情報をレンダリングするために用いられてもよいことを認識されよう。この柔軟性により、システムは、広範囲の情報処理タスクの中でのプロセスとして用いられることが可能である。

【0400】

たとえば、形態素は、データフィードにおいてキーワードを用いて表現されてもよい。データフィードにおいて形態素参照を含むことによって、システムは、特定の形態素識別子に応じて、プレゼンテーション層におけるさらなる処理を提供してもよい。この柔軟性の適用は、パーソナライズ化の説明において上記に記載される（図２８）。

【0401】

ウェブに基づく形および制御を用いて（３２２４）、ユーザは、システムにおいて情報を追加して修飾してもよい。この入力は次に、ＸＭＬデータフィード３２２６および３２１６として分散型データストアを介して集中型処理システムに返されてもよい。

【0402】

その上、ＲＳＳなどのオープンＸＭＬ形式はまた、システムへの入力として、インターネットから組み込まれてもよい。

【0403】

構造情報に対する修飾は、アプリケーションサーバ３２１４によって処理されてもよい。この処理からの共有形態素データは、ＸＭＬおよびＡＰＩコネクタ３２１２を介して返され、集中型データストア３２１０に格納されてもよい。

【0404】

システムアーキテクチャの広範囲なフィールドの中で、公知である多くの潜在的な設計、モードおよび製品がある。これらとしては、システムアーキテクチャの集中型モデル、非集中型モデルおよびオープンアクセスモデルが挙げられる。本発明によって網羅されるこれらの実装の技術的な操作および種々の代替物については、本願明細書においてさらに説明しない。
［データモデルおよびスキーマ］
図３１は、本発明の一実施形態におけるシステム内の中核データ構造の簡略化された概要を提供する。この簡略化されたスキーマは、データがシステムのアプリケーションプログラミング論理を通じて変換されてもよい態様を示す。このスキーマはまた、形態素データがどのように分解されて格納されることができるかも示す。

【0405】

システムのデータアーキテクチャは、ドメイン特有のエンティティを処理するための一時的なデータストアを提供すると同時に、形態素辞書を集中させるように設計された。

【0406】

ドメインデータは、システムを通って貫流してもよく、システムに格納されなくてもよいことに留意されたい。ドメインエンティティにマッピングされる表は、一時的なデータストアであってもよく、次に出力データおよびドメインに関するデータストアに変換される。ドメインデータストアは、他の集中型資産と共に格納されてもよく、またはドメインオーナによって維持されるストレージリソースに分散されてもよい。

【0407】

一実施形態において、アプリケーションおよびデータベースサーバ（上記に記載され、図３０に示される）は、データを最初に操作してもよい。データは、システムにおけるデータ抽象化の３つの広汎な領域の中で組織化されてもよい。

【0408】

エンティティ抽象化層３３０２は、エンティティがシステムにおける知識表現の主な構築ブロックである場所である。エンティティは、形態素３３０４、キーワード３３０６、概念３３０８、コンテンツノード３３１０およびコンテンツコンテナ３３１２（ＵＲＬによって表される）から構成されてもよい。

【0409】

抽象化の関係層３３１４は、エンティティ定義が、システムにおいて用いられる種々のエンティティ間の関係によって表される場所である。エンティティ関係は、形態素関係３３１６、概念関係３３１８、キーワード−形態素関係３３２０、概念−キーワード関係３３２２、ノード−概念関係３３２４およびノード−コンテンツコンテナ（ＵＲＬ）関係３３２６から構成されてもよい。

【0410】

ラベル抽象化層３３２８は、エンティティを記述するために用いられる語が、エンティティ自体の構造定義から分離される場所である。ラベル３３３０は、形態素ラベル３３３２、キーワードラベル３３３４、概念ラベル３３３６およびノードラベル３３３８から構成されてもよい。ラベルは、種々のエンティティにわたって共有されてもよい。あるいは、ラベルは、エンティティタイプによって区分されてもよい。

【0411】

この簡略化されたスキーマは、一実施形態において用いられるデータベーススキーマを全く制限しないことに留意されたい。システム性能、格納および最適化の問題は、著しく顕著である。当業者は、本願明細書に記載される設計要素を反映するデータベースシステムを設計するための多くの手法があることを知見している。したがって、本発明における実施形態として用いられてもよい種々の方法、技術および設計は、本願明細書においてさらに説明しない。
［次元変換システム］
図３２は、上記に記載され、本願明細書において以下にさらに記載されるデータ構造変換のオペレーションを実行するための一実施形態によるシステム概要を示す。

【0412】

上記で紹介される変換の３つの広範なプロセスは、一実施形態において現れるように、さらに詳細な語で再表示されてもよい。１）複雑な次元構造において要素構成要素に関して定義されるように、その構造のファセットを発見するためのドメイン２００の分析および圧縮、２）ファセット分類の増強方法によって提供される次元概念タクソノミ２１０へのドメインの複雑な次元構造の合成および展開、３）時間の経過と共に、構造を改良する複雑適応システム（たとえば、２０６および２１０）を可能にするためのファセットナビゲーションおよび編集環境を通じた次元概念タクソノミ２１０内のユーザインタラクションの管理である。
［要素構成要素の分析］
一実施形態において、分散型計算環境６００が、概略的に示される。集中型処理６０１用の１つの計算システムは、データ構造用の変換エンジン６０２として動作してもよい。変換エンジンは、その入力として、１つまたは複数のドメイン２００からのソースデータ構造２０２を受け取る。変換エンジン６０２は、分析エンジン２０４ａ、形態素辞書２０６および構築エンジン２０８ａから構成されてもよい。これらのシステム構成要素は、上記で紹介され、図２に示される分析および合成の機能性を提供してもよい。

【0413】

１つのきわめて特異な実施形態において、複雑な次元構造は、インターネット６０６にわたって、非集中型処理用の１つまたは複数の第２の計算システム（たとえば、６０３）にウェブサービス（またはＡＰＩまたは他の分散チャネル）を介して分散されてもよいＸＭＬファイル６０４に符号化されてもよい。分散および非集中化のこのモードおよび／または他のモードを通じて、広範囲の開発者および発行者が、変換エンジン６０２を用いて、複雑な次元構造を作成してもよい。アプリケーションには、ウェブサイト、知識ベース、電子商取引ストア、探索サービス、クライアントソフトウェア、管理情報システム、分析結果などが含まれる。

【0414】

集中型処理および非集中型処理のこれらの説明は、処理のこれらのモードを提供するために用いられてもよい種々の集中型物理システムおよび分散型物理システムと混同すべきではないことをここでは留意されたい。ここで、「集中型処理」は、変換プロセスのための共有データ、パブリックデータおよび／または収集データおよびサービスを指す。「非集中型処理」は、ドメイン特有のデータおよびサービスを指す。当業界では公知であるように、集中型処理および非集中型処理のこの混合を実現するために実装されてもよい多数の物理的システムおよびアーキテクチャがある。
［強化されたファセット分類を通じた合成］
ＸＭＬファイル６０４に基礎として利用可能であってもよい。一実施形態において、ファセット分類の増強方法は、ドメインにおける素材を再組織化するために用いられてもよく、ＸＭＬファイル６０４において具体化された複雑な次元構造を用いて第２の計算システム６０３で次元概念タクソノミ２１０を導出してもよい。通常、システム６０３のような第２の計算環境は、次元概念タクソノミ２１０によって再組織化されるために、ドメインにおいても責任があるドメインオーナによって維持されてもよい。システムによって用いられる多層データ構造に関する詳細な情報は、以下で提供され、図３３に示される。

【0415】

システム６０３の一実施形態において、次元概念タクソノミ２１０に関するプレゼンテーション層６０８またはグラフィカルユーザインターフェイス（ＧＵＩ）が提供されてもよい。ブラウザ、ウェブに基づく形およびソフトウェア構成要素などのクライアント側ツール６１０は、ドメインエンドユーザおよびドメインオーナ／アドミニストレータが、次元概念タクソノミ２１０と対話することを可能にしてもよい。
［ユーザインタラクションを介した複雑適応処理］
次元概念タクソノミ２１０は、個々のエンドユーザおよびドメインオーナのそれぞれによって調整されて境界を定められてもよい。これらのユーザインタラクションは、第２の計算システム（たとえば、６０３）によって利用され、人間の認知および分類システムに対するさらなる処理リソースを提供する。
たとえば、ＸＭＬ２１２ａにおいて符号化されるユーザインタラクションを具体化する次元タクソノミ情報は、ウェブサービスまたは他の手段を介して分散することによってなど変化エンジン６０２に返されてもよい。これにより、データ構造（たとえば、２０６および２１０）が、時間の経過と共に進化して改善することを可能にする。

【0416】

第２のシステム６０３から変換エンジン６０２へのフィードバックは、処理の複雑適応システムを確立する。エンドユーザおよびドメインオーナは、次元概念タクソノミ２１０を通じて抽象化の高いレベルで対話し、ユーザインタラクションは、次元概念タクソノミ情報の根底にある要素構成物（たとえば、形態素および形態素関係）に変形されてもよい。要素構成要素にエンドユーザおよびドメインオーナのインタラクションを結合し、それらを変換エンジン６０２を返すように供給することによって、システムは、集合体におけるインタラクションを評価することができてもよい。

【0417】

このメカニズムを用いて、コラボレイティブ分類において歴史的に生じる曖昧さおよび矛盾を除去してもよい。したがって、コラボレイティブ分類に対するこの手法は、他のそのようなシステムを用いて生じる可能性がある概念レベルにおけるパーソナルネゴシエーションおよびコラボレイティブネゴシエーションを回避しようとする。

【0418】

ユーザインタラクションはまた、ユーザがインタラクションを通じてコンテンツノード３０２および分類データ（次元概念タクソノミ情報）に寄与し、分類の全体品質を強化し、利用可能な処理リソースを増大することによって、利用可能なソースデータ２０２を拡張する。
［多層データ構造］
図３３は、各ソースデータ構造２０２から採取される要素構成物が、抽象化および次元性の連続的レベルを通じて組み合わせられ、各ドメイン２００に関する次元概念タクソノミ２１０を作成する手段を示す。この図はまた、各ドメイン２００において具体化される非集中型プライベートデータ（７０８、７１０および３０２）と、集中型システムが各ドメインに関して生成される分類体系を知らせるために用いる共有要素構成物（形態素辞書）２０６との間の描写を示す。
［要素構成要素］
形態素３１０および形態素関係の要素構成要素は、集中型データとして形態素辞書２０６に格納されてもよい。集中型データは、（たとえば、変換エンジンシステム６０１を介して）分散型計算環境６００にわたって集中され、ドメインの分類に役立つドメインオーナおよびエンドユーザのすべてに利用可能であってもよい。集中型データは、要素（形態素）であり、概念３０６および概念関係によって表される任意の特定の知識およびプライベートな知識の文脈から切り離されるため、第２の非集中型計算システム６０３の中で共有されてもよい。システム６０１は、各ドメインに含まれる固有の情報を含むこれらの要素構成物に固有の表現および組み合わせを永久に格納する必要はない。

【0419】

形態素辞書２０６は、形態素属性７０２の表の集合において、各形態素３１０の属性を格納してもよい。形態素属性７０２は、（以下にさらに記載するように）変換エンジン６０２の分析プロセスによって用いられる構造的パラメータおよび静的データを参照してもよい。形態素関係は、集合体において形態素階層４０２の中に順序付けされてもよい。
［次元ファセット出力データ］
ドメインデータストア７０６は、ソースデータ構造２０２から変換エンジンシステム６０１によって導出されるドメイン特有のデータ（複雑な次元構造２１０ａ）を形態素辞書２０６を用いて格納されてもよい。ドメイン特有のデータの一実施形態は、ＸＭＬの形で格納されてもよい。

【0420】

各ドメインデータストア７０６におけるＸＭＬに基づく複雑な次元構造２１０ａは、ドメイン特有のキーワード階層７１０、コンテンツノードの集合３０２および概念定義の集合７０８から構成されてもよい。キーワード階層７１０は、キーワード関係の階層集合から構成されてもよい。ＸＭＬ出力はそれ自体は、ファセットデータとして符号化されてもよい。ファセットデータは、その構造のファセットとしてソースデータ構造２０２の次元性と、ファセットの属性に関してソースデータ構造２０２のコンテンツノード３０２と、を表す。この手法により、ドメイン特有のリソース（たとえば、システム６０３）が、複雑な次元構造２１０ａを次元概念タクソノミ２１０などの抽象化のより高いレベルに処理することを可能にする。

【0421】

複雑な次元構造２１０ａは、コンテンツノード３０２間の関係を管理するために、組織化基準として用いられてもよい。組織化原理の新たな集合は次に、分類のための要素構成要素に適用されてもよい。組織化原理は、以下に詳述し、図２０〜図２２に示すように、ファセット分類の増強方法を含んでもよい。

【0422】

ファセット分類の増強方法は、複雑な次元構造２１０ａに適用されてもよい。他のより簡単な分類方法もまた、適用されてもよく、他のデータ構造（簡単であるか、複雑であるかに関係なく）は、所望に応じて複雑な次元構造２１０ａから作成されてもよい。一実施形態において、ファセット分類を明確に表す出力スキーマが、用いられてもよい。他の出力スキーマが、用いられてもよい。各ドメインに関して作成されるファセット分類は、種々のデータモデルを用いて表されてもよい。利用可能な分類の方法は、分類されるデータ構造のタイプに密接に関連付けられる。したがって、分類に関するこれらの別の実施形態は、上述の次元性の別の実施形態に直接的にリンクされてもよい。

【0423】

ドメインデータストア７０６に含まれるデータエンティティ（たとえば、７０８、７１０）は、形態素辞書２０６に格納される要素構成物に対する参照を含む。このように、各ドメイン２００に関する次元概念タクソノミ２１０は、変更に適合するようにために、その作成の後で再分析されることができる。ドメインオーナが、自分たちの分類を更新したいときには、ドメイン特有のデータは、処理のために分析エンジン２０４ａに再ロードされてもよい。ドメイン２００は、実時間で（たとえば、ＸＭＬ２１２ａを介してエンドユーザインタラクションを通じて）または（待ち行列の）定期的な更新を通じて分析されてもよい。
［共有データ対プライベートデータ］
次元知識表現モデルの利点は、ドメインを複雑な次元構造２１０ａに処理するために、システムによって用いられるプライベートドメインデータおよび共有データの明確な分離である。データ分離は、ホスト型アプリケーションサービスプロバイダ（ＡＳＰ）処理モデル、上記に記載されるようなユーティリティ計算環境を活用する機会またはサービス型ソフトウェア（ＳａａＳ）アプリケーション配信モデルなどの分散型計算の長所を提供する。これらのモデルの下で、第三者が、ドメインオーナに変換エンジンを提案してもよい。したがって、ドメインオーナは、モデルのこれらのタイプが提供する規模の利益を十分に活用することができる。

【0424】

ドメインオーナのドメイン特有のデータは、他のドメインオーナの共有データ（すなわち、形態素辞書２０６）およびプライベートデータから分離可能であるため、種々の格納モデル（たとえば、ＡＳＰを介して）の下で確実にホスト化されることができる。あるいは、ドメイン特有のデータは、ドメインオーナによってホスト化され、共有データから物理的に除去されてもよい。

【0425】

この分散型知識表現モデルの下で、ドメインオーナは、集中型知識変換サービスの経済的な利点および特殊化の両方からの恩恵のほか、集中型分類データの「衆知」からの恩恵を受ける可能性がある。しかし、これらの集中型サービスおよびデータ資産から分離される必要なドメイン特有のデータを保つことによって、ドメインオーナは、固有の知識を妥協する必要なく、ユーザの全体的な共同の共有知識（たとえば、形態素辞書）を構築してもよい。

【0426】

企業設置内の知識保管庫およびイントラネットは、プライベート知識ドメインとの関連の中で共有収集知識のこの適用の実施例を提供する。現在、会社は、収集知識の経済的利益と競争上の利点に関してプライベート知識を維持する必要性のオープンコラボレーションとの間で、厳しい妥協点に直面している。本願明細書に記載されるシステムにより、閉鎖的な情報ドメインのこのタイプが、それでもなお本願明細書に記載される集中型知識表現および変換サービスからのほか、本願明細書に記載される形態素辞書の場合のような共同データ資産の恩恵を受けると同時に、合成された知識およびドメイン特有のデータ資産をプライベートに維持することが可能となる。
［分散型計算環境］
一実施形態において、構築エンジンは、オープンソースプラットフォームで実行するソフトウェアアプリケーションとして分散されてもよい。１つのそのようなオープンソースプラットフォームは、ＬＩＮＵＸ（登録商標）、ＡＰＡＣＨＥ（商標）、ＭｙＳＱＬ（商標）およびＰｅｒｌ、ＰＨＰ、Ｐｙｔｈｏｎなどを含んでもよいプログラミング言語からなる技術の「ＬＡＭＰ」スタックである。そのようなアプリケーションを通じて、構築エンジンの合成規則のマルチプルコピーが、ドメインオーナの分散型物理システムで直接的に読み出されてもよい。このモデルの下で、（構築エンジンの各コピーは、同一の命令で提供されるため、）集中型処理規則を実行する分散型物理システムを有する。

【0427】

この手法を用いて、各ドメインに関する複雑な次元構造を合成するスケーリングコストは、各ドメインオーナのリソースにわたって分散される。類似の方式において、構築エンジンは、軽量のクライアント側アプリケーションとして分散され、それらのアプリケーションのエンドユーザの必要に応じて複雑な次元構造を合成してもよい。

【0428】

これらの非集中型システムをドメインオーナおよびエンドユーザのシステム上で直接実行する機会に加えて、ＡＭＡＺＯＮ
ＷＥＢ ＳＥＲＶＩＣＥ（商標）（ＡＷＳ）などのユーティリティ予測プラットフォームが、集中型構築エンジン規則用の経済的な分散メカニズムを提供する。（構築エンジンの仮想インスタンスを実行する直接費は、ドメインオーナの異機種環境にわたる構築エンジンを分散して支援する間接費を埋め合わせるより大きい可能性がある。）構築エンジンの物理的分散コピーより、仮想構築エンジンアプリケーションは、ユーティリティ計算環境の中で提供されることが可能である。

【0429】

たとえば、ＡＷＳの中で、構築エンジン用の画像が作成され、ＡＷＳ
Ｅｌａｓｔｉｃ Ｃｏｍｐｕｔｅ Ｃｌｏｕｄサービス（ＥＣ２）の仮想環境にアップロードされてもよい。ＥＣ２は、１つまたは複数の仮想サーバ環境を提供してもよい。ＡＷＳ「画像」は、本質的に仮想サーバのディスク画像である。「インスタンス」は、そのディスク画像に基づく動作仮想サーバである。仮想サーバで実行中の構築エンジンの新たなインスタンスは、ドメインを処理し、必要に応じて、ユーザの活動に適合させるようにセットアップされる。

【0430】

この非集中型環境（ならびにその他の多くの環境）において、ドメイン特有のデータおよび構築エンジンは、切り離されてもよい。ＡＷＳの中で、ＥＣ２は、処理のために用いられてもよく、Ｓｉｍｐｌｅ
Ｓｔｏｒａｇｅ Ｓｅｒｖｉｃｅ（Ｓ３）は、データ格納のために用いられてもよく、Ｓｉｍｐｌｅ
Ｑｕｅｕｅ Ｓｅｒｖｉｃｅ（ＳＱＳ）は、ＥＣ２、Ｓ３および上記で紹介され、および以下でさらに詳細に説明される分析および複雑適応フィードバックの他の集中型サービスにわたるメッセージングを連係するために用いられてもよい。

【0431】

ＡＷＳ
Ｓ３サービスは、ドメインに関する次元複雑な構造を符号化するファセットデータ集合の格納および分配のために用いられてもよい。これらのドメイン特有のファセットデータ集合は、構築エンジン規則を処理している複数の仮想サーバの間で共有されてもよい。

【0432】

合成される概念関係は、この非集中型環境に格納されてもよい。構築要求は、合成されて、エンドユーザシステムおよびＳ３の両方に並列に送信されてもよい。その後で、前に要求されたパラメータに整合する合成要求は、Ｓ３における概念関係のキャッシュから満たされてもよく、または、更新が必要である場合に、構築エンジンによって直接的に生成されてもよい。同程度に重要なことは、合成された関係は、上記に記載されるように、集中型分析エンジンにおける次の分析サイクル用のフィードバックとして利用可能であってもよい。

【0433】

当業者は、分散型計算の領域において、ここで作成されてもよい多くのアーキテクチャの改善および進歩があることを認識されよう。複数の仮想機械にわたる並列化およびドメインおよびユーザ活動にわたる負荷バランスは、改善のこのタイプの実施例である。
ＸＭＬスキーマおよびクライアント側の変換
ファセット出力データは、ＸＭＬとして符号化され、ＸＳＬＴとしてレンダリングされてもよい。ファセット出力は、多くの異なる手法で再組織化されて表されてもよい（たとえば、公開されたＸＦＭＬスキーマを指す）。階層を表すための別の出力が、利用可能である。
ＸＳＬ変換コード（ＸＳＬＴ）が、プレゼンテーション層を提示するために、一実施形態において用いられる。システムによって管理されるすべての情報要素（システムを通じて向けられる場合には分散型コンテンツを含む）は、ＸＳＬＴによってレンダリングされてもよい。

【0434】

クライアント側処理は、データフィードをシステムのプレゼンテーション層に接続するための一実施形態のプロセスである。コネクタのこれらのタイプは、アプリケーションサーバから構造情報を用いる種々の媒体に情報を出力するために用いられてもよい。アプリケーションサーバからのＸＭＬデータは、ウェブページにおける表示のためにＸＳＬＴを通じて処理されてもよい。

【0435】

当業者は、ＸＭＬ技術および類似の表示技術が、本発明のサービスにおいて提供する現在および未来の機能性を認識されよう。基本的な発行およびデータ表示に加えて、ＸＳＬＴおよび類似の技術が、さまざまなプログラマティック環境を提供してもよい。システムによって作成される構造などの複雑な情報構造は、データモデルにそっくりの実用的な情報を提供してもよい。ソフトウェアプログラムおよびエージェントは、プレゼンテーション層上で情報に作用し、巧妙なインタラクティビティおよび自動化を提供してもよい。したがって、システムの中核構造利点によって提供される本発明の範囲は、簡単な発行をはるかに越えて拡張されてもよい。

【0436】

当業者はまた、これらのＸＭＬ位置およびＸＳＬＴ位置を設計することを可能にする可変性を認識されよう。たとえば、ファイルは、エンドユーザのコンピュータ上に局所的に格納されてもよく、ウェブサービスを用いて生成されてもよい。ＡＳＰコード（または類似の技術）は、分散型プレゼンテーション層（第３者による発行者またはソフトウェアクライアントのウェブページなど）上に本発明のシステムによって管理される情報を挿入するために用いられてもよい。

【0437】

別の実施例として、システムからの中核構造情報を含むＸＭＬデータフィードは、システムが組織化する分散型コンテンツと組み合わせてもよい。当業者は、データのこれらの２つのタイプを分離データフィードに分離するための機会を認識されよう。

【0438】

これらの表示ファイルおよびデータフィードを格納して分配するためのこれらの設計機会および他の設計機会は、当業界では公知であり、したがって、本願明細書においてさらに説明しない。
［ユーザインターフェイス］
以下の節は、上述のシステムオペレーション用の種々のユーザインターフェイスに関する実装の詳細を提供する。これらのオペレーションは、次元概念タクソノミの表示、動的合成のモードにおける合成パラメータの提供および次元概念タクソノミの編集である。当業者は、上述のシステムオペレーションのサービスにおいて実装してもよい潜在的なユーザインターフェイスの多様性を認識されよう。したがって、ユーザインターフェイス実装の例証および説明は、本発明の範囲を全く制限しない。
［次元概念タクソノミビューア］
図３４は、エンドユーザの表示およびブラウジング用の次元概念タクソノミ表示ＵＩの主要構成要素の説明的なスクリーンキャプチャを提供する。

【0439】

コンテンツコンテナ２６００は、次元概念タクソノミ用のプレゼンテーション層を形成する構造リンクおよび概念定義に加えて、ドメインにおけるコンテンツの種々のタイプを保持してもよい。１つまたは複数の概念定義は、コンテナにおけるコンテンツノードに関連付けられてもよい。システムは、本願明細書に記載するように、次元概念関係を予測するために用いられるＵＲＩおよび概念定義に加えて、システムに登録される情報要素の任意のタイプを管理することができてもよい。

【0440】

一実施形態において、従来の直線的な（または平坦な）情報構造に通常関連付けられるユーザインターフェイスデバイスは、複雑な次元構造における次元性を表すために組み合わせられるか、積み重ねられてもよい。

【0441】

ナビゲーションバー、ディレクトリツリー２６０４およびブレッドクラムパス２６０２などを組み合わせ型の従来のウェブＵＩデバイスは、情報アーキテクチャにおける種々のノードにおける次元交差点を示すために用いられてもよい。能動コンテンツノード２６０６と交差する各次元軸（または階層）は、別個の階層として表されてもよく、各交差軸に１つの階層が表される。

【0442】

構造関係は、ドメインにおいて能動コンテンツコンテナから関連コンテンツコンテナまでポインタ（またはリンク）によって定義されてもよい。これは、次元概念タクソノミによって指示されるように、能動コンテナと関連コンテナとの間の複数の構造リンクを提供してもよい。構造リンクは、概念の全文脈提示、能動軸においてキーワードのみを表示する概念のフィルタリングされた提示、コンテンツノードラベルの提示などをはじめとする種々の方式で提示されてもよい。

【0443】

構造リンクは、１つまたは複数の関係タイプ（たとえば、親、子または兄弟）の中のコンテンツノードの優先順位を付けされたグループ化に組織化された次元概念タクソノミの中で、コンテンツノードに関する文脈２６０８を提供してもよい。

【0444】

ＸＳＬＴは、ウェブサイトにおけるナビゲーションパスとして構造情報を提示するために用いられてもよく、ユーザが能動コンテナに関するコンテナに構造階層を誘導することを可能にする。ウェブサイトにおけるナビゲーションデバイスとして構造情報の提示のこのタイプは、システムの最も基本的なアプリケーションの中にあってもよい。

【0445】

これらのナビゲーションの慣例および他のナビゲーションの慣例は、当業界では公知である。
［動的合成ユーザインターフェイス］
（上記したような）動的合成オペレーションを提供するためのユーザインターフェイスを組み込むユーザインターフェイス制御が、図３５に示される。

【0446】

ユーザインターフェイスは、ユーザが指定してもよいユーザインターフェイス制御、すなわち、能動概念定義３６０２、能動軸定義３６０４および能動ドメイン３６０６を含んでもよい。能動概念定義および能動軸定義を指定するための制御は、キーワードとして概念定義を規定し、編集オペレーションおよびテキストに基づく探索（図示せず）を起動するためのリンク（図示）を含んでもよい。

【0447】

一実施形態において、ユーザは、既存の概念階層３６０８の中に配置される概念定義の集合から能動概念定義を選択してもよい。能動概念定義のこの選択は、前に実行された静的合成オペレーションに基づき、次元概念タクソノミ用の大域的ナビゲーション構造を提供してもよい。

【0448】

別の実施形態において、能動概念定義を指定するために、ユーザは、テキストボックス（図示せず）にクエリを入力してもよい。クエリは、ドメインに関連付けられるエンティティラベルの集合に対して処理されてもよい。入力しているときに、ドメインにおける概念、キーワードおよび形態素の他のエンティティに関連付けられるラベルとの文字列比較に基づいて、提案のリストが提案されてもよい。（抽出方法論は、さらに詳細に上述される。）これらのツールを用いて、ユーザは、ドメイン特有のラベルの顧客の語彙に基づいて、提供される提案から概念定義を選択することができてもよい。

【0449】

軸定義は、能動概念定義の１つまたは複数の属性のリストまたは（合成オペレーションの説明の下で上記に記載されるように）ユーザが組み立てたいと考える属性の任意の組み合わせを用いて指定されてもよい。動的合成オペレーションのために用いられる候補集合内からの属性の分析に基づく「タグクラウド」３６１０は、潜在的な軸定義の概観を提供するための１つの手段であってもよい。たとえば、候補集合において最も普及しているキーワードの計数は、提示用のキーワードの部分集合の選択のほか、全体的なキーワード計数に基づくキーワードラベルのフォントサイズの変更のための基準として用いられてもよい。

【0450】

この実装において、ユーザは、スクリーンの上部にわたって位置決めされるタブの集合から選択することによって、能動ドメインを選択してもよい。

【0451】

処理の範囲および結果として生じる合成出力を制御するために、上記に記載されるように、合成パラメータを定義するための制御は、スライダ３６１０としての分離度およびリンク３６１２として返される概念の数における制限を含んでもよい。（この実施形態において、表示されるコンテンツノードの数における制限は、返される概念における制限に結合される。あるいは、概念およびコンテンツノードにおける制限は、提示においてさらなる柔軟性を提供するために分離されてもよい。）仮想概念を表示するかまたは隠すことができる手段は、チェックボックストグル制御３６１４として示される。
［次元概念タクソノミアウトライナ］
次元概念タクソノミの表示は、上記に記載されるユーザインターフェイスを通じてユーザに提示されてもよい。例証のために、分類を検討した後、ユーザは、分類を再組織化したいと仮定する。システムの視点から、これらのインタラクションは、複雑適応システム内の明確なユーザフィードバックを生成することになる。

【0452】

図３６は、一実施形態におけるこれらのインタラクションを提供することができるアウトライナユーザインターフェイスを示す。この図は、構造２７０４におけるノード２７０２の位置を変更し、各ノード２７０６でコンテナおよび概念定義割り当てを編集するためのデバイスを示す。

【0453】

一実施形態において、クライアント側制御を用いて、ユーザは、次元概念タクソノミを再組織化するために、階層においてノードを移動することができてもよい。その際、ユーザは、ノード間に新たな親−子関係を確立してもよい。

【0454】

ノードの位置が編集されるため、基本的な形態素間の関係の新たな集合を関連させてもよい。これは今度は、推測される次元概念関係の新たな集合を決定するための再予測を必要としてもよい。これらの変更は、概念関係によって推測される新たな形態素関係を予測するために、待ち行列に入れられてもよい。
変更は、ユーザのパーソナライズ化需要のための共有次元概念タクソノミ（以下では共同概念タクソノミ）に対する例外として格納されてもよい（パーソナライズ化に関するさらなる詳細については、以下を参照のこと）。

【0455】

当業者は、多次元情報構造を提示し、エンドユーザにインタラクティビティを提供するために用いられてもよい多くの方法および技術があることを認識されよう。たとえば、多変量形態は、ユーザが多くの異なる次元に沿って同時に情報アーキテクチャを照会することを可能にするために用いられてもよい。「ピボットテーブル」などの技術は、他のパラメータが変更されている間、情報構造における１つの次元（または可変）定数を保持するために用いられてもよい。ＡｃｔｉｖｅＸおよびＡｊａｘに基づく構成要素などのソフトウェア構成要素は、ウェブページに埋め込まれ、基本的な構造を有するインタラクティビティを提供してもよい。可視化技術は、データの三次元表示を提供してもよい。これらの変形および他の変形は、当業者には明白であり、本発明の範囲を制限するわけではない。

【0456】

本発明は、多くの形態をとることができることと、そのような形態は、請求項に記載されたように本発明の範囲内にあることは当業者によって認識されよう。したがって、添付の特許請求の範囲の精神および範囲は、本願明細書に含まれる特定のバージョンの説明に限定されるべきではない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11A】

【図11B】

【図12】

【図13】

【図14A】

【図14B】

【図15】

【図16A】

【図16B】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】