JP2004362563A - 非構造化情報管理および自動テキスト分析を実行するためのシステム、方法、およびコンピュータ・プログラム記録媒体 - Google Patents

Abstract

【課題】 非構造化情報管理システム（ＵＩＭＳ）用のシステム・アーキテクチャ、コンポーネント、および検索技法を開示することにある。
【解決手段】 ＵＩＭＳは、情報ソースの幅広いアレイに関する非構造化情報の効果的な管理および交換のためのミドルウェアとして提供することができる。このアーキテクチャは一般に、検索エンジンと、データ記憶域と、パイプライン化した文書アノテータを含む分析エンジンと、様々なアダプタとを含む。この検索技法は２レベル検索技法を利用する。検索照会は、それぞれが関連重み値を有する複数の検索部分式からなる検索演算子を含む。検索エンジンは、しきい重み値合計を超える重み値合計を有する１つまたは複数の文書を返す。検索演算子は、加重ＡＮＤ（ＷＡＮＤ）として機能するブール述部として実現される。
【選択図】 図１

Description

本発明は一般に情報管理システムに関し、より詳細には、自動テキスト分析および情報検索を含む非構造化情報管理システムを実現するためのシステム、方法、およびコンピュータ・プログラムに関する。

現代社会のテキスト・データの量は絶えず増大し続けている。その理由は様々であるが、重要な推進力の１つはパーソナル・コンピュータ・システムおよびデータベースが広範囲に配備されたことと、電子メールの量が絶えず増加していることである。その結果、様々な形式および表明での文書データの作成、拡散、および必要な記憶域が広く行き渡っている。

全般的な傾向は肯定的であるが、社会中に知識が拡散することは一般に有益な目標と見なされるので、文書データの量がその文書データを読み取り、同化し、カテゴリ化する関係者または関係組織の能力をはるかに上回る可能性があるという問題が発生する。

テキスト・データは、現在、文書データの大部分を表現しうるものであり、本特許出願に関連して主に述べられているが、その一方で文書はますますテキストとイメージ（ビデオ・クリップなどの動的または静的なもの）の両方を含む文書の形式あるいはテキストとオーディオの両方を含む文書の形式などのマルチメディア形式で作成され配布されている。

テキストベースの文書データの量の増加に応じて、この増加する文書データのコーパスを管理するための何らかの効率の良い手段を開発しなければならないことが明らかになった。この分野の努力は、非構造化情報管理と呼ぶことができ、（主に）テキストベースの情報における知識の記憶、アクセス、検索、ナビゲート、発見に必要なツールと方法の両方を包含するものと見なすことができる。

たとえば、ビジネスの手法は進化し続けているので、効率よく徹底的な方法で非構造化情報を処理する必要性が増大している。このような情報の例としては、記録された自然言語ダイアログ、マルチリンガル・ダイアログ、テキスト変換、科学資料などを含む。

David E. JohnsonおよびThomas Hampp-Bahnmuellerによる「Architecture of a Framework for Information Extraction from NaturalLanguage Documents」という名称の米国特許第６５５３３８５Ｂ２号には、アプリケーションに依存せず、高度の再利用性を提供する、自然言語文書からの情報抽出のためのフレームワークが記載されている。このフレームワークは、構文解析および分類などの種々の自然言語／機械学習技法を統合するものである。このフレームワークのアーキテクチャは、容易に使用されるアクセス層内に統合される。このフレームワークは、一般的な情報抽出、自然言語文書の分類／カテゴリ化、自動電子データ伝送（たとえば、電子メールおよびファクシミリ）処理および経路指定、ならびに構文解析を実行する。このフレームワーク内では、情報抽出を求める要求は情報エクストラクタ（extractors）に渡される。このフレームワークは、アプリケーション・データの前処理および後処理と、エクストラクタの制御の両方に対応することができる。また、このフレームワークは、アプリケーションがそのデータについて取るべき必要なアクションを提案することもできる。容易な統合および拡張という目標を達成するために、このフレームワークは、統合（外部）アプリケーション・プログラム・インターフェース（ＡＰＩ）およびエクストラクタ（内部）ＡＰＩを提供する。

米国特許第６５５３３８５Ｂ２号 米国仮出願第６０／４７４８７７号

検索、索引付け、カテゴリ化、データおよびテキスト・マイニングを含むがこれらに制限されない目的のために様々なソースからの様々なフォーマットの文書データから所望の情報を抽出するために、その文書データを効率よくしかも包括的に処理する能力が必要である。

これらの教示の現在好ましい実施形態により、上記その他の問題が克服され、その他の利点が実現される。

本明細書には非構造化情報管理（Unstructured Information Management：ＵＩＭ）システムが開示される。ＵＩＭの重要な態様としては、ＵＩＭアーキテクチャ（ＵＩＭＡ）と、そのコンポーネントと、ＵＩＭＡによって実現される方法を含む。ＵＩＭＡは、様々なソースからの文書情報を効果的かつ適時に処理するためのメカニズムを提供する。ＵＩＭＡの特定の利点の１つは、非構造化情報を同質化し処理する能力である。

ＵＩＭＡの一態様は、ＵＩＭＡがモジュール方式であり、１つのコンピュータ上に局在化するかまたは２つ以上のコンピュータに分散することができ、さらに当面の非構造化情報管理タスクに適合させるためにそのサブコンポーネントを複製したり最適化したりすることができることである。

ＵＩＭＡは、情報集中型である他のアプリケーションと効果的に統合することができる。薬品を発見するための生命科学アプリケーションとＵＩＭＡが統合されるという非制限的な例の１つが提供される。

ＵＩＭＡの諸態様は、無制限に、セマンティック検索エンジン（Semantic Search Engine）と、文書ストア（Document Store）と、テキスト分析エンジン（TextAnalysis Engine：ＴＡＥ）と、構造化知識ソース・アダプタ（Structured Knowledge Source Adapters）と、集合処理マネージャ（Collection Processing Manager）と、集合分析エンジン（Collection Analysis Engine）とを含む。好ましい実施形態では、ＵＩＭＡは、関連知識を作成するために構造化情報と非構造化情報の両方を受け取るように動作する。ＴＡＥには、共通分析システム（common analysis system）（ＣＡＳ）と、アノテータ（annotator）と、コントローラが含まれる。

また、ＵＩＭＡの一部として、２レベル検索プロセス（two-level retrieval process）を使用する効率の良い照会評価プロセッサ（query evaluation processor）も開示されている。

データ単位（data unit）の集合を記憶するためのデータ記憶域と、そのデータ記憶域に結合され、前記データ記憶域からの少なくとも１つのデータ単位を検索するための照会に応答する検索エンジンとを含み、記憶データを処理するためのデータ処理システムが開示されている。この照会は、それぞれが関連重み値（associated weight value）を有する複数の検索部分式（search sub-expressions）からなる検索演算子を含み、検索エンジンは、しきい重み値合計（threshold weight value sum）を超える重み値合計を有するデータ単位を返す。好ましい一実施形態では、データ単位は文書を含む。

より具体的には、この照会は、加重ＡＮＤ（Weighted AND：ＷＡＮＤ）として機能するブール述部（Boolean predicate）を含む。ＷＡＮＤは、引き数として、ブール変数Ｘ₁、Ｘ₂、・・・、Ｘ_kのリストと、関連の正の重みｗ₁、ｗ₂、・・・、ｗ_kのリストと、しきい値θとを取り、

である場合に、

は真になる。
式中、ｘ_iはＸ_iの標識変数（indicator variable）であり、Ｘ_iが真であればｘ_i＝１であり、そうでなければｘ_i＝０である。

このＷＡＮＤは、

および

を介して（ＡＮＤ）関数または（ＯＲ）関数のうちの１つを実現するために使用することができる。

また、文書データを処理するための方法と、コンピュータ可読媒体上で実施され、少なくとも１つのアプリケーションと協力してテキスト・インテリジェンス・システム（text intelligence system）の動作を指示するためのプログラム・コードを含むコンピュータ・プログラム記録媒体も開示されている。このコンピュータ・プログラム記録媒体は、データ単位の集合を記憶するためのコンピュータ・プログラム・セグメントと、少なくとも１つの記憶データ単位を検索するための照会に応答する検索エンジンを実現するコンピュータ・プログラム・セグメントとを含む。この照会は、それぞれが関連重み値を有する複数の検索部分式からなる検索演算子を含み、前記検索エンジンは、しきい重み値合計を超える重み値合計を有するデータ単位を返す。

これらの教示の上記その他の態様は、添付図面に関連して読んだときに以下に示す好ましい実施形態の詳細な説明でより明らかになる。

本明細書には非構造化情報管理アーキテクチャ（ＵＩＭＡ）が開示されている。以下の説明は一般に次のように構成されている。
Ｉ．はじめに
ＩＩ．アーキテクチャの機能概要
文書レベル分析
集合レベル分析
セマンティック検索アクセス
構造知識アクセス
ＩＩＩ．アーキテクチャ・コンポーネントの概要
検索エンジン
文書ストア
分析エンジン
ＩＶ．システム・インターフェース
Ｖ．２レベル検索
ＶＩ．例示的な実施形態および考慮事項

Ｉ．はじめに
本明細書に開示されているＵＩＭＡは、好ましくは構造化情報と非構造化情報の組み合わせに関する検索と分析を統合するアプリケーションを開発するためのハードウェアとソフトウェアの組み合わせとして実施される。「構造化情報」は、その意図された意味があいまいではなく、そのデータの構造またはフォーマットで明示的に表現される情報として本明細書で定義する。適切な例の１つはデータベース・テーブルである。「非構造化情報」は、その意図された意味がその形式によって暗示されるにすぎない情報として本明細書で定義する。非構造化情報の適切な例の１つは自然言語で書かれた文書である。

エンドユーザ機能を実現するためにＵＩＭＡコンポーネントを使用するソフトウェア・プログラムは、一般に、アプリケーション、アプリケーション・プログラム、またはソフトウェア・アプリケーションなどの総称で呼ぶ。例示的なアプリケーションの１つは、図３５〜３６に関して後述する生命科学アプリケーションである。

その一実施形態が図１に示されているＵＩＭＡのハイレベル・アーキテクチャは、ＵＩＭアプリケーションを実現するために協働する大まかなコンポーネントの役割、インターフェース、および通信を定義する。これらのコンポーネントは、テキスト・データやイメージ・データを含む文書などの非構造化ソース・アーティファクト（artifacts）を分析し、構造化ソースを統合してアクセスし、発見したセマンティック・コンテンツに基づいてアーティファクトを記憶し、索引付けし、検索することができるコンポーネントを含む。

図１は、ＵＩＭＡ１００の例示した非制限的な実施形態が、セマンティック検索エンジン１１０と、文書ストア１２０と、少なくとも１つのテキスト分析エンジン（ＴＡＥ）１３０と、少なくとも１つの構造化知識ソース・アダプタ１４０と、集合処理マネージャ１５０と、少なくとも１つの集合分析エンジン１６０と、アプリケーション・ロジック（Application logic）１７０とを含むことを示している。好ましい実施形態では、ＵＩＭＡ１００は、関連知識１９５を生成するために構造化情報１８０と非構造化情報の両方を受け取るように動作する。非構造化情報は、文書の集合１９０であると見なすことができ、テキスト、グラフィックス、静的および動的イメージ、オーディオ、ならびにそれらの様々な組み合わせの形にすることができる。ＵＩＭＡ１００が採取する文書の所与の１つは文書１９０Ａという。

図１に示すＵＩＭＡ１００の諸態様は図２にさらに示されており、同図では、テキスト分析エンジン１３０のコンポーネント部分にすることができるプリミティブ分析エンジン（Primitive Analysis Engine）（ＰＡＥ）２００が例示されている。ＰＡＥ２００には、共通分析システム（ＣＡＳ）２１０と、アノテータ２２０と、コントローラ２３０が含まれている。ＴＡＥ１３０の第２の実施形態は図３に示されており、同図では、アグリゲート分析エンジン（Aggregate Analysis Engine）（ＡＡＥ）３００が２つまたはそれ以上のコンポーネント分析エンジン２２１、２２２、２２３ならびにＣＡＳ２１０から構成され、ＰＡＥ２００と同じ外部インターフェースを実現する。さらにアグリゲート分析エンジン３００には、コントローラ２３０と、分析シーケンサ（analysis sequencer）３１０と、分析構造ブローカ（analysis structure broker）３２０が含まれている。これらの特徴については、より徹底的に後述することになり、したがって、ここでは紹介のみとする。

ＩＩ．アーキテクチャの機能概要
上記は一実施形態にすぎず、紹介にすぎないことに留意されたい。したがって、図１、図２、および図３に開示したＵＩＭＡ１００のコンポーネントの諸態様は様々になる可能性がある。たとえば、ＴＡＥ１３０は、音声またはビデオなどのテキスト以外のデータの分析用の適切なエンジンを含むことができる。

ＵＩＭＡ１００の実施形態は、音声、オーディオ、およびビデオに限定されず様々な非構造化アーティファクトに及ぶが、本明細書の記述は一般に、テキスト・データの形の人間の言語技術に関わるＵＩＭＡ１００の実現例を対象とする。さらに、本明細書で述べるように、文書１９０Ａとして処理するための非構造化情報の諸要素としては、テキスト文書全体、テキスト文書フラグメント、または複数文書さえも含むことができる。したがって、本明細書内の教示は、ＵＩＭＡ１００の諸態様の例証にすぎないものと見なすべきである。

すなわち、ＵＩＭＡ１００は、様々な構造を有する様々な実施形態で実現することができる。たとえば、１つの大型システムとしてまたは複数の小型分散システムとしてＵＩＭＡ１００を実現することは有利であると見なすことができる。このような実現例は、実現例のスケールならびにその他の要因などの要因に応じて様々になる可能性がある。

次に、ＵＩＭＡ１００の機能の諸態様の概要を示す。この諸態様は分析機能とアクセス機能の両方を含む。分析機能は２つのクラス、すなわち、文書レベル分析と集合レベル分析に分割される。アクセス機能はセマンティック検索アクセスと構造化知識アクセスに分割される。それぞれの機能については以下に紹介する。

ＩＩ．Ａ．文書レベル分析
文書レベル分析は、テキスト分析エンジン（ＴＡＥ）１３０というコンポーネント処理要素によって実行される。これらは、汎用分析エンジンの拡張機能であり、テキスト用に専門化されている。ＴＡＥ１３０の諸態様は、２０００年にＣｕｎｎｉｎｇｈａｍ他によってＧＡＴＥアーキテクチャとして開示された処理リソース（Processing Resources）に類似しているものと見なすこともできる。ＵＩＭＡ１００では、ＴＡＥ１３０は好ましくは、サブコンポーネント・エンジンまたはコンポーネント・エンジンから構成可能な再帰的構造であり、各エンジンはアプリケーションの分析のそれぞれ異なる段階を実行する。

テキスト分析エンジン１３０の例としては、言語変換プログラムと、文書要約プログラム（document summarizers）と、文書分類プログラム（document classifiers）と、名前付きエンティティ検出プログラム（named entity detectors）とを含む。各ＴＡＥ１３０は、他の点では文書テキスト１９０Ａ内で未確認または暗黙の特定の概念（または「セマンティック・エンティティ」）を発見するために設けられている。

ＴＡＥ１３０は文書１９０Ａを入力し、分析を生成する。元の文書１９０Ａとそれに対応する分析は、その後、共通分析システム（ＣＡＳ）２１０という共通構造で表現される。一般に、ＣＡＳ２１０は、少なくとも１つの文書１９０Ａに関する情報のモデリング、作成、および検索を容易にするデータ構造である（たとえば、図１３を参照）。ＣＡＳ２１０は局在化される場合もあれば、分散される場合もある。さらに、ＵＩＭＡ１００は複数のＣＡＳシステムの調整をサポートする。

ＵＩＭＡ１００で使用するように、また一般に、注釈（annotation）は元の文書１９０Ａ内の一領域に何らかのメタデータを関連付けるものである。たとえば、文書１９０Ａがテキスト文書である場合、注釈は、スパンの開始位置と終了位置を直接または間接的に示すことにより、文書１９０Ａ内のテキストのスパンにメタデータ（たとえば、ラベル）を関連付ける。ＣＡＳ２１０内の注釈は孤立しており、その注釈が文書そのものとは別個に維持されていることを意味する。孤立注釈（Stand-off annotations）は一般に、インライン文書マークアップ（inline document markup）よりフレキシブルなものと見なされている。しかし、ＵＩＭＡ１００では、注釈は、所与の文書１９０ＡについてＣＡＳ２１０に記憶された唯一のタイプの情報である必要はない。ＣＡＳ２１０は、元の文書１９０Ａの何らかのサブコンポーネントに明示的にリンクされているかどうかにかかわらず、文書１９０Ａの分析に関連するいずれかのクラスのメタデータ要素を表現するために使用することができる。また、ＣＡＳ２１０により、イメージ、ビデオ、またはその他の非テキスト様式の分析に有用なように、このリンケージの複数定義が可能になる。一般に、各文書１９０Ａに１つのＣＡＳ２１０が関連付けられることになる。

文書レベル分析の一例は図４に示されている。この例示的なワークフロー４００では、注釈パイプラインは、言語ＩＤ（language identifier）４１０と、トークナイザ（tokenizer）４２０と、センテンス分離アノテータ（sentence separation annotator）４３０と、品詞（ＰＯＳ）タガー（part-of-speech tagger）４４０と、名前付きエンティティ認識アノテータ４５０と、パーサ４６０と、テンプレート・フィリング・アノテータ（template filling annotator）４７０とを含む複数の結合したアノテータを含む。図４に開示した例示的なアノテータおよびステップに加えてまたはそれらの代わりに使用可能な他の非制限的な関係は図６〜８に示されている。図９および図１０は、ワークフロー生成（図９）およびワークフロー検証（図１０）の諸態様を表現する流れ図を示している。様々なアノテータ４１０〜４７０のうちの少なくとも一部は図４〜５に示すものとは異なる順序で現れる可能性があり、たとえば、状況によってはトークナイザ４２０が言語ＩＤ４１０より先行する可能性があることに留意されたい。

しかし、すべてのアノテータ４１０〜４７０を図４に示すように直列に結合したパイプラインとして配置する必要はない。たとえば、図５は、日付アノテータ（Dates annotator）４１５が言語ＩＤおよび他のアノテータと並列に配置され、日付アノテータ４１５の出力がＣＡＳ２１０に直接戻される場合の一例を示している。この実施形態は、漢字などの言語で書かれた文書１９０Ａを採取する際に、その文書がラテン文字を使用して書かれた日付を含むときに有用である可能性がある。任意の数の並列アノテータ経路を設けることができ、並列経路当たり多数のアノテータを設けることができる（たとえば、日付アノテータ４１５の次に直列に結合した時間アノテータ（Time annotator）が続いてもよい）。さらに、所与の並列アノテータ経路の出力は、直接ＣＡＳ２１０に戻す必要はないが、他のアノテータ経路にフィードバックすることもできる。

所与の文書１９０Ａに２つ以上のＣＡＳ２１０を関連付けることができ、すなわち、種々のＴＡＥ１３０が種々のＣＡＳ２１０を使用できることに留意されたい。一例として、あるＴＡＥ１３０はあるＣＡＳ２１０を使用して文書１９０Ａを異なる言語に変換することができ、他のＴＡＥ１３０は異なるＣＡＳ２１０を使用して同じ文書１９０の要約を提供することができる。別法として、複数のＴＡＥ１３０が同じ文書１９０Ａについて同じＣＡＳ２１０を使用することもできる。

ＣＡＳ２１０で表現される分析は、連続する分析段階を通過するにつれて強化あるいは洗練される（無関係のデータの廃棄などによる）メタデータの集合であると見なすことができる。たとえば、特定の分析段階では、ＣＡＳ２１０は深い構文解析を含む可能性がある。ＣＡＳ２１０を受け取る名前付きエンティティ検出プログラム（４５０）は、名前付きエンティティを識別するために深い構文解析を考慮することができる。名前付きエンティティは、複数の文書１９０Ａ、たとえば、米国大統領に言及する文書または１つまたは複数の事業分野の財界指導者に言及する文書１９０Ａに基づいて要約または分類を生成する分析エンジン１３０に入力することができる。

この現在好ましい実施形態では、ＣＡＳ２１０は、単一継承をサポートする階層タイプ・システムによる一般的なオブジェクトベースの文書表現を提供する。継承構造１０００の一例は図１１に示されている。図１１のタイプ・システム１０１０は、示されている非制限的な例の注釈１０２０、品詞（ＰＯＳ）１０３０、言語ＩＤ１０４０、旅行計画１０５０などの様々なサブタイプを含む。これらのタイプ（またはサブタイプ）１０２０、１０３０、１０４０、１０５０はさらに、適宜、分解することができる（たとえば、言語ＩＤサブタイプ１０４０の変形としては、さらに米国、英国、およびオーストラリアを含む英語サブタイプ１０４０Ａを含む）。一般に、タイプ・システム１０１０は、ＣＡＳ２１０を使用するテキスト文書の分析のためのデータ・モデルを提供する。

しかし、ＣＡＳ２１０は単一継承の使用に制限されず、図１２は多重継承を使用するデータ・モデリングの一例を示している。この場合の構造は継承ツリーではなく、有向非周期サイクルである。多重継承のための操作および宣言セマンティクスを指定するために、Ｃ＋＋または人工知能などにおける標準的な技法を使用することができる。

いずれの場合も（単一継承または多重継承）、アノテータの例は、たとえば、会話における語用論上の効果を分類するためにもう１組のアノテータを呼び出すために、センテンス境界およびタイプを見つけることのみに関心がある可能性がある。

単一継承をサポートする階層タイプ・システムによるオブジェクトベースの表現は、ＴＡＥ１３０同士の間ならびにＴＡＥ１３０と他のＵＩＭＡコンポーネントまたはアプリケーションとの間の分析結果の効率のよい表現、アクセス、および転送のために設計されたデータ作成メソッド、アクセス・メソッド、および直列化メソッドを含む。ＣＡＳ２１０内の諸要素には高速アクセスのために索引を付けることができる。ＣＡＳ２１０は、バイナリ用として直列化メソッドによりならびに効率と相互運用性との兼ね合いを管理するためにＸＭＬフォーマットにより、Ｃ＋＋およびＪａｖａ（Ｒ）で実現されている。ＣＡＳ２１０とＵＩＭＡ１００のコンポーネントとの関係の一例は図１３に示されている。図１３には、ＣＡＳ２１０に加えて、反復子（Iterator）１１２５と同様にタイプ・システム１１１０と索引リポジトリ１１２０が示されている。一般に、タイプ・システム１１１０は本質的にアノテータの順序ではなくワークフローに関する制約を指定するものであり、たとえば、図４では言語ＩＤアノテータ４１０は品詞（ＰＯＳ）アノテータ４４０より先行しなければならない。索引リポジトリ１１２０は、現行文書１９０Ａ内の日付および固有名詞の位置を指定することなどにより、所与の情報を文書１９０Ａ内で突き止められるようにするポインタ用の記憶域を提供する。後述する分析構造ブローカ（ＡＳＢ）３２０だけでなく、他のＵＩＭＡコンポーネント１１３０、１１４０、１１５０も示されている。

ＩＩ．Ｂ．集合レベル分析
好ましくは、文書はアプリケーション１７０によって収集され、図１に示す集合１９０などの集合に構成される。好ましくは、ＵＩＭＡ１００は、ＣＰＭ１５０の一部を形成する集合リーダ（Collection Reader）・インターフェースを含む。集合リーダの実現例は、集合要素１９０、集合メタデータ、および要素メタデータへのアクセスを可能にする。ＵＩＭＡ１００の実現例としては、集合リーダ・インターフェースと協力し、複数の集合およびその要素を管理する文書／集合／メタデータ・ストア（Document, Collection and Meta-data Store）１２０を含む。しかし、それ自体の集合を管理したいと希望するアプリケーション１７０は、集合データへのアクセスを必要とするＵＩＭＡ１００のコンポーネントに対し、集合リーダの実現例を提供することができる。

集合１９０を分析して、集合レベル分析結果を生成することができる。このような結果は、１つの集合１９０内の文書１９０Ａの全部または一部のサブセットに関して計算したアグリゲート推論を表現するものである。集合全体１９０を分析するアプリケーション１７０のコンポーネントは集合分析エンジン（ＣＡＥ）１６０である。ＣＡＥ（複数も可）１６０は通常、個々の文書１９０Ａなどの集合の要素に要素レベル分析またはより具体的には文書レベル分析を適用し、その後、アグリゲート計算を実行する際に要素分析を考慮する。

集合レベル分析結果の例としては、諸要素が所与のフィーチャ（特徴）、その変形および頻度が付いた用語集、分類法、統計カテゴライザ用のフィーチャ・ベクトル、抽出した関係（リレーション）のデータベース、トークンおよびその他の検出エンティティのマスタ索引を含む部分集合を含む。

集合分析エンジン（複数も可）１６０をサポートして、ＵＩＭＡ１０は集合処理マネージャ（ＣＰＭ）コンポーネント１５０を含む。ＣＰＭ１５０は主に、ストア１２０内の集合リーダによりアクセス可能な各文書１９０Ａに対する指定のＴＡＥ１３０の適用の管理を課せられている。集合分析エンジン１６０は、ＣＰＭ１５０への入力として、ＴＡＥ１３０および集合リーダ（図示せず）を提供することができる。ＣＰＭ１５０は、ＴＡＥ１３０を適用し、集合内の各要素１９０ごとにＣＡＳ２１０によって表現される分析を返す。このプロセスを制御するために、ＣＰＭ１５０は、障害報告、休止、および再始動を含む管理機能を提供する。

アプリケーションの集合分析エンジン１６０の要求により、ＣＰＭ１５０は、ＵＩＭアプリケーション・シナリオを代表する機能を実行するように任意選択で構成することができる。ＵＩＭアプリケーション機能の非制限的な例としては、メタデータ制約に基づいて所与の要素のみが処理されることを保証するフィルタリングと、要素レベル分析を記憶するパーシスタンスと、分析から抽出されたメタデータに基づいて指定の検索エンジン索引付けインターフェースを使用して文書に索引を付ける索引付けと、使用可能なコンピューティング・リソースを同時に使用して複数の文書を処理するためのＴＡＥ１３０の複数のインスタンスの作成および実行を管理する並列化とを含む。

ＩＩ．Ｃ．セマンティック検索アクセス
本明細書で使用する「セマンティック検索」は、文書または集合レベル分析によって発見され、注釈として表現されるセマンティック・コンテンツに基づいて文書を突き止める機能を示している。セマンティック検索をサポートするために、ＵＩＭＡ１００は検索エンジンの索引付けインターフェースと照会インターフェースとを含む。

索引付けインターフェースの一態様は、トークンの索引付けならびに注釈、特にクロスオーバ注釈のサポートである。２つまたはそれ以上の注釈は、文書の交差領域にリンクされている場合、互いにクロスオーバするものと見なされる。

照会インターフェースの他の態様は、トークンと注釈のブール組み合わせに加えて、注釈とトークンのネストされた構造を前提とする可能性のある照会のサポートである。

ＩＩ．Ｄ．構造化知識アクセス
分析エンジン１３０がそれぞれの機能を実行するときに、多様な構造化情報ソース１８０を調べることができる。再利用性を高め、統合を容易にするために、ＵＩＭＡ１００は知識ソース・アダプタ（ＫＳＡ）インターフェース１４０を含む。

ＫＳＡ１４０は、異種類の知識ソース１８０に対する均一アクセスの層を提供する。これは、データベース、辞書、知識ベース、および他の構造化ソース１８０で均一にエンコードされた知識を送達するのに必要な技術通信、表現言語、オントロジ・マッピングを管理する。この好ましい実施形態では、ＫＳＡへの基本インターフェースは、非制限的なフォーマットの一例として、ＸＭＬでエンコードされた知識交換フォーマット（ＫＩＦ）を使用して、インスタンス生成された述部として構造化知識１８０を提示する。

ＫＳＡ１４０のアーキテクチャの一態様は、ＫＳＡの登録および検索をサポートするＫＳＡメタデータおよび関連サービスを含む。これらのサービスは、名前付きオントロジの記述および登録を含む。オントロジは一般に、それが含む概念と述部によって記述される。ＫＳＡ１４０は、好ましくは自己記述性のものであり、調べた知識ソースの表示だけでなく、ＫＳＡ１４０がインスタンス生成可能な登録済みオントロジに関連する述部シグニチャも、メタデータとして含むことができる。

好ましくは、アプリケーション開発者または分析エンジン開発者は、登録済みオントロジの述部をインスタンス生成するＫＳＡ１４０を検索し見つけるために、人間がブラウズ可能なＫＳＡディレクトリ・サービスを調べることができる。このサービスは、ウェブ・サービスまたは埋込み可能なＫＳＡコンポーネント１４０にハンドルを送達することができる。

ＩＩＩ．アーキテクチャ・コンポーネントの概要
ＩＩＩ．Ａ．検索エンジン１１０
検索エンジン１１０は索引付けおよび照会処理を担当する。検索エンジン１１０は、検索アプリケーションとは区別される。検索アプリケーションは、検索エンジン１１０を使用して、たとえばページ・ランキングおよびプレゼンテーション機能を追加して基本検索アプリケーションを提供することになる。

ＵＩＭＡ１００は、テキスト分析と検索の統合を利用するアプリケーションの開発をサポートする。基本ブール検索機能の実行に加えて、これらのアプリケーションは、「スパン」および「ビュー」という２つの拡張機能を提供するために検索エンジンを必要とする可能性がある。

スパン： イベント、場所、人、薬品、パーツなどのセマンティック・エンティティはトークンのシーケンスによってテキストで表現することができ、各トークンは１つまたは複数の英数字からなるストリングにすることができる。一般に、１つのトークンは、１つの数字、英字、音節、ワード、またはワード・シーケンスにすることができる。ＴＡＥ１３０は、トークンのスパンに関する注釈を生成する。たとえば、「場所」というタイプの注釈を使用すると「１３１３ Ｍｏｃｋｉｎｇ Ｂｉｒｄ Ｌａｎｅ」というトークンのスパンに注釈を付けることができ、「人」というタイプの注釈を使用すると「Ｂｏｂ Ｓｍｉｔｈ」というトークンのスパンに注釈を付けることができる。

図１５は、様々な注釈タイプを備えたトークンのネストされたスパンを示す注釈構造の一例を示している。図１５では、たとえば、各トークンは１つのワードとして示されている。

注釈はフィーチャ（すなわち、プロパティ）を有することができる。たとえば、「場所」というタイプの注釈は「所有者」というフィーチャを有する可能性があり、その値はその場所におけるプロパティの所有者である。フィーチャの値はそれ自体のフィーチャを備えた複合タイプになる可能性があり、たとえば、ある場所の所有者は、「名前＝Ｊｏｈｎ Ｄｏｅ」および「年齢＝５０」というフィーチャを備えた「人」というタイプのオブジェクトにすることができる。

ＵＩＭＡ準拠の検索エンジン１１０は、トークンのスパンに関する注釈または「スパン」の索引付けをサポートする。現在、後述するように、これを実施可能な２つの好ましい方法が存在する。簡単に言えば、インデクサ１１０によって理解される何らかのフォーマット（たとえば、ＸＭＬ）でＣＡＳ２１０にインライン注釈を挿入することができ、またはインデクサ１１０はＣＡＳ２１０で見つかる孤立注釈を理解することができる。

インライン注釈への変換： この手法では、アプリケーション１７０は検索エンジン１１０の入力要件に対処する。たとえば、Ｊｕｒｕなどの検索エンジンは、ＸＭＬ文書に索引を付け、次に、そのＸＭＬ要素を参照する照会を処理することができる。以下の例では、その文書に索引を付けることができることについて検討する。

この例で仮にパリという都市を含むイベントについて照会が入力された場合、この文書はその照会に一致するだろう。

ＵＩＭＡ１００でＸＭＬ認識検索エンジン１１０を使用するために、アプリケーション１７０は、ＴＡＥ１３０によって生成された孤立注釈を取り、それをＸＭＬとしてインラインでエンコードする。ＣＡＳ２１０は好ましくは、このＸＭＬ表現を生成するための方法を定義する。この手法の恩恵は、どのＸＭＬ認識検索エンジン１１０でも扱えるようにすることができることである。

孤立注釈を認識している検索エンジン： この手法では、検索エンジンのインターフェースは、ある文書に関する孤立（すなわち、非インライン）注釈の概念をサポートする。したがって、ＴＡＥ１３０の出力は検索エンジン１１０に直接（またはほとんど直接）供給することができ、ＸＭＬなどの中間表現の必要性を回避する。一例として、文書フラグメントとそのトークンの位置について検討する。

上記の例ではトークン（たとえば、「Washington」、「D.」、「C.」というトークン）は図１５に示すものとは異なる位置定義を有することに留意されたい。ＵＩＭＡ１００のこの好ましい実施形態は、両方のタイプのトークン位置定義をサポートする。

検索エンジン１１０とＴＡＥ１３０がこの文書用のまったく同じ位置空間について合意に達すると想定すると、この情報はＴＡＥ１３０によって以下のように表現することができる。

しかし、ＴＡＥ１３０と検索エンジン１１０が空白のカウント方法、句読点のアドレス指定方法について合意に達しないかまたは単に位置合せされていない場合、＄Ｃｉｔｙおよび＄Ｃｏｕｎｔｒｙという注釈には適切に索引を付けることができない。

したがって、以下のように同等のＸＭＬ表現が提供される。

ＸＭＬ構文解析は一般に、上記の代案より計算上高価なものになる。好ましくは、これは、これが前処理機能のうちの最も制限的なステップではない可能性があることを考慮する非妥当性検査パーサを使用することによって軽減される。

さらにＸＭＬを考慮すると、一部の実施形態では、ＸＭＬ表現の欠点は、ＴＡＥ１３０が重複注釈を生成する可能性があることである。換言すれば、注釈は適切にネストされない。しかし、ＸＭＬは自然に重複注釈を表現しないと思われ、他のメカニズムを使用して解決策を提供することができる。

また、「ａｉｒｂａｇ」という文字のストリングについても検討する。これは、「ａｉｒ」と「ｂａｇ」とを区別するＴＡＥ１３０からの注釈に索引を付けたいとアプリケーションが希望する可能性がある複合名詞である。検索エンジン１１０がある文書について１つのトークン化のみをサポートしており、「ａｉｒｂａｇ」が単一トークンとして解釈されたが、ＴＡＥ１３０は「ａｉｒ」と「ｂａｇ」を明確に扱う異なるトークン化を使用した場合、この場合の検索エンジン１１０の最小索引付け単位が「ａｉｒｂａｇ」であったので、アプリケーション１７０は「ｂａｇ」に関する注釈とは別個に「ａｉｒ」に関する注釈に索引を付けることができないだろう。

上記の文書フラグメント例の場合、検索エンジン１１０に送られる注釈は以下のようになるだろう。

「ｃｉｔｙ」および「ｃｏｕｎｔｒｙ」という注釈は、文字オフセット（ＣＡＳ２１０内のそれぞれの内部表現である）を使用して指定されている。検索エンジン１１０が最終的にトークン番号を使用してそれらを指定することを選ぶことになる場合、アプリケーションまたは検索エンジン１１０のいずれか一方がその変換を実行することができるだろう。

一般に、トークンは単一文字である場合もあれば、複数文字の集合体である場合もあることに留意されたい。

この手法のいくつかの恩恵としては、孤立注釈モデルからインライン注釈モデルへの高価な変換およびその逆の変換を行う必要がないことを含む。また、重複注釈は問題を提起しない。

検索エンジン１１０と、ＴＡＥ１３０と、一連のアノテータ１２２０、１２２１、１２２２との関係の一実施形態は図１４に示されている。ＡＳＢ３２０と、アプリケーション１７０用のユーザ・インターフェース（ＵＩ）１７０Ａと、ＴＡＥ１３０から出力を受け取るテキスト分析（ＴＡ）リソース・リポジトリ１３０Ａも示されている。

図１６は、文書レベルおよびワード・レベルで動作する図１４の例示的なアノテータ１２２０、１２２１、１２２２の動作の表現を示している。この例では、文書レベル言語ＩＤ４１０の次にデタガー（detagger）４１５（ＨＴＭＬタグを識別するためのもの）が続き、その次にトークナイザ４２０が続き、その次にＰＯＳアノテータ４４０が続き、その次に位置ＩＤアノテータ４４５が続く。

関係（リレーション）
図１７はトークン１５１０、１５２０、１５３０とスパン１５５０、１５６０、１５７０に関する逆ファイルの表現を示しており、図１８はスパン・オカレンスの代替表現を示す図である。図１８では、オカレンス１６１０は、開始位置および終了位置１６２０または開始位置および長さ１６３０を有するものとして定義される。スパン１６５０は、少なくとも開始トークン１６６０と終了トークン１６７０を有するものとして定義され、これらのトークンはさらに位置について指定される。

図１９、図２０、および図２１は、文書内の関係を発見するためにＴＡＥ１３０によって実行される前処理ステップ内のスパンとの関係を表現する例を提示している。図１９に示す例では、「抑制する」という関係名を備えた関係引き数を含むスパンに注釈が付けられている。この例では、第１の化合物が抑制剤として識別され、第２の化合物が抑制されるものとして識別され、その関係は抑制するという関係である。このスパンの注釈は「抑制するもの」および「抑制されるもの」という引き数役割を備えた用語に対応し、このスパンに関する注釈には索引が付けられる。

このプロセスを記述する流れ図は図２０に示されている。図２０の第１のステップ１８１０は、関係テキストを発見すること、すなわち、ある関係が表現されている文書内のテキスト範囲を発見することを伴う。第２のステップ１８２０は、引き数テキストを発見する、すなわち、各引き数が表現されている文書内のテキスト範囲を発見する。各関係および引き数ごとに、ステップ１８３０でスパンが決定され、ステップ１８４０で引き数スパンに順序が付けられ、ステップ１８５０で関係スパンと、その引き数スパンのそれぞれについて注釈が作成される。ステップ１８５５でラベルが割り当てられて索引に追加され、ステップ１８６０で指定の順序で引き数注釈を関係注釈にリンクすることにより、関係が作成される。

図２１はスパン索引との関係を図解している。図２１の注釈索引１９１０は、各文書１９０Ａが開始位置と終了位置によって線引きされたスパン１９５０を含む場合に、文書ＩＤ１９４０を含む関係引き数１９３０に関する関係索引１９２０を組み込んでいる。

位置および検索
一般に、１組のトークン位置は単調である。しかし、上記の説明に基づいて、１組のトークン位置は連続的または非連続的のうちの一方にすることができ、１つのトークンまたは１組のトークンに対して少なくとも２つの注釈が及ぶことができる。

注釈タイプは、任意のセマンティック・タイプまたはメタ値にすることができる。したがって、検索エンジン１１０は、注釈と、トークンと、注釈に関するトークンのうちの少なくとも１つを含む照会に対して応答することができる。

関係データ構造は、引き数の順に順序付けられた引き数からなる少なくとも１つの関係を含むことができ、１つの関係はそれぞれの注釈によって表現される。検索エンジン１１０は、データ・ストア１２０を検索するための特定の関係を含む照会に応答して、その特定の関係を有する少なくとも１つの文書を返すことができる。検索エンジン１１０はさらに、特定の関係にある少なくとも１つの引き数を返すことができる。検索エンジン１１０はさらに、複数の順序付き引き数を返すことができる。少なくとも１つの引き数は、注釈にリンクされた引き数注釈を含むことができる。また、検索エンジン１１０は、その照会によって明示的に指定されない照会に応答して少なくとも１つの引き数を返すこともできる。注釈は関係ＩＤを含むことができ、その関係ＩＤは少なくとも１つの引き数から構成することができる。その関係ＩＤを含む１つの引き数は、例として、少なくとも１つの他の注釈と、１つのトークンと、１つのストリングと、１つのレコードと、１つのメタ値と、１つのカテゴリと、１つの関係と、少なくとも２つのトークン間の１つの関係と、少なくとも２つの注釈間の１つの関係とを含むことができる。この関係ＩＤは論理述部も含むことができる。

同様に、それぞれの注釈によって表現された関係データ構造（１つの関係名と、引き数の順に順序付けられた複数の引き数とを含む）は、検索エンジン１１０の照会として現れる可能性がある。このような照会は、データ・ストア１２０を検索するための関係構造（またはその一部）を指定して、その指定された関係を有する少なくとも１つの文書を返す。検索エンジン１１０はさらに、指定された関係にある１つまたは複数の引き数を返すことができる。検索エンジン１１０が１つまたは複数の順序付き引き数を返す場合、各引き数は、その注釈にリンクされた引き数注釈を含むことができる。照会に応答して、検索エンジン１１０は、その照会によって明示的に指定されない少なくとも１つの引き数も返すことができることに留意されたい。

１つの関係の注釈は１つの関係ＩＤ、たとえば、論理述部を含むことができる。このような注釈は、１つまたは複数の引き数を取り込む可能性もある。１つの引き数は、例として、少なくとも１つの他の注釈と、１つのトークンと、１つのストリングと、１つのレコードと、１つのメタ値と、１つのカテゴリと、１つの関係と、少なくとも２つのトークン間の１つの関係と、少なくとも２つの注釈間の１つの関係とを含むことができる。

ビュー
異なるＴＡＥ１３０が同じ文書（複数も可）の種々のトークン化を生成できることを確認すると、ＵＩＭＡ準拠の検索エンジン１１０は、好ましくは、同じ文書についての種々のトークン化または種々の索引付けユニット・セットをサポートする。このような種々のトークン化の結果、１つの文書について異なる「ビュー」が発生する可能性がある。文書１９０Ａの種々のトークン化に基づくかまたはそれから導出されたビューの一例は図２２に示されており、同図では、第１の代替表現２０１０および第２の代替表現２０２０の結果、ビュー２０５０、２０６０、２０７０、２０８０として示す複数のビューが得られる可能性がある。

一般に、ビューはある文書１９０Ａとトークン化との関連付けである。したがって、ビューは、文書１９０ＡのＩＤとトークン化の結果とを対にすることによって表現することができる。したがって、異なるビューは文書１９０Ａの異なるトークン化を表現することが分かる。図２３を参照すると、たとえば、単語を語幹と接尾部に分割することにより、ＴＡＥ３がトークン・セット２のトークン化を拡張し、この結果、新しいビュー（ビュー３）が得られる。

図２４は、単一ソース文書の種々のトークン化から発生する種々の文書ビューに関する検索式２１１０、２１２０、２１３０とともにブール演算子２１００を使用するビューによる検索の諸態様を例示している。

ＴＡＥ１３０の動作は好ましくは、ＴＡＥ１３０によって生成されたコンテンツの関連性に関してアプリケーション１７によって行われた既存のビューまたは決定を前提としていない。ＵＩＭＡ１００は、ＴＡＥ１３０が配備されるアプリケーション１７０とは無関係にＴＡＥ１３０を開発できることを保証する。したがって、好ましくは、ビューを作成することはアプリケーション１７０の責任である。好ましくは、２つのＴＡＥ１３０が同じ文書１９０Ａ上で実行され、異なるトークン化に基づく結果を生成する場合、これらの結果はその文書の単一ビューにマージされない。したがって、アプリケーション１７０は別個のビューとして検索エンジン１１０に各ＴＡＥ１３０の結果を提供する。

現在好ましい一実施形態では、検索エンジン１１０は、２つのレベルのうちの少なくとも一方のビューを同化するように構成される。第１のレベルは「浅い理解（Shallow Understanding）」レベルであり、その場合、検索エンジン１１０は１つの文書１９０Ａの複数のビューを、最終的に同じ文書テキストを指し示すという点でのみ関連する完全に別個のエンティティとして扱う。理想的には、このような検索エンジン１１０は、その文書の複数のビューが１つの照会に一致した場合でも、その結果リストで１回だけ文書１９０Ａを報告することになるだろう。第２のレベルは「深い理解（Deeper Understanding）」レベルであり、その場合、照会が文書１９０Ａに関する複数のビューに及ぶように検索エンジン１１０はビューを認識している。たとえば、「ＸおよびＹ」という照会において、用語Ｘがある文書のビュー１に現れ、用語Ｙが同じ文書のビュー２に現れる場合、検索エンジン１１０によって文書１９０Ａが返されることになるだろう。検索エンジン１１０の「浅い理解」の実施形態で同じ照会が同じ文書を返すわけではないことに留意されたい。

ＵＩＭＡ１００のフィーチャは、従来のＸＭＬ表現に対する大幅な改良を可能にする重複注釈を提供する能力である。「クロスオーバ・スパン」ともいうことができる重複注釈の一例は「IBM data warehousing products」というフレーズであり、「IBM data」、「datawarehousing」、「warehousing products」というすべての連続ワード対には「二重名詞」（double noun）注釈を付加することができる。このタイプのラベルを付加することは、たとえば、「storingdata created by IBM」対「IBM productfor storing data」の読み方を区別するために非常に有用である。

前述の通り、好ましくは、トークンを記憶するための少なくとも１つの逆ファイル・システム（図１７を参照）と、それぞれのビューごとにその注釈と、それぞれの注釈のオカレンスを含むリストと、それぞれの注釈のリストされた各オカレンスごとに、所与のトークン位置に対して少なくとも１つの注釈が及ぶことができる複数のトークン位置からなるセットとを記憶するための少なくとも１つの逆ファイル・システム（図１５を参照）が存在する。

明らかなように、逆ファイル・システムは、少なくとも個々のファイルにいかに索引付けし、アクセスするかという点において従来のファイル・システムとは異なっている。従来のファイル・システムでは単に個々のファイルそれぞれをリストするだけである可能性があり、逆ファイル・システムでは、トークンなどの何らかのコンテンツまたはメタデータが存在し、そのコンテンツまたはメタデータを含む１つまたは複数のファイルに何らかの方法で関連付けられている。たとえば、従来のファイル・システムでは、ファイルを検索するための索引としてのファイル名から始まる可能性があり、逆ファイル・システムでは、何らかのコンテンツまたはメタデータから始まって、そのコンテンツまたはメタデータを含む１つまたは複数のファイルを検索する可能性がある（すなわち、ファイルには、ファイル名とは対照的にコンテンツによって索引が付けられる）。

セマンティック検索エンジン１１０は、第１の述部が第１のビューに関係し、第２の述部が第２のビューに関係する少なくとも２つの述部の論理的組み合わせを含み、その述部の論理的組み合わせを満足する少なくとも１つの文書を返す照会に応答することができる。

本発明のこの好ましい実施形態では、このトークン化は、例として、プレーン・テキスト文書、文書の言語変換、文書の要約、マークアップされた文書のプレーン・テキスト変形、ＨＴＭＬ文書のプレーン・テキスト変形、あるいはテキストとイメージ、テキストとグラフィカル・パターン、テキストとオーディオ、テキストとイメージとオーディオ、またはイメージとオーディオなどの様々なマルチメディア・オブジェクトを含むものなどのマルチメディア文書のうちの少なくとも１つに対応し、それから導出される。トークン化は、種々のデータ・タイプを有するオブジェクトに基づくことができる。また、トークン化は、ある文書のｎグラム・トークン化から導出することもできる。たとえば、図４０は文書テキストのトリグラム・トークン化の一例を示している。

ＵＩＭＡ１００は、ある文書の複数ビューを作成するためにＴＡＥ１３０の複数インスタンスを必要としないことに留意されたい。その代わりに、１つのＴＡＥ１３０を使用して１つのビューを作成することができ、次に、１つまたは複数の異なるアノテータ（図２、図３、図４、および図５を参照）を選択すること、あるいはアノテータを再配置することによって再構成することができ、その文書をもう一度処理してその文書の他のビューを作成することができる。

ＩＩＩ．Ｂ．文書ストア
ストア（または文書ストア）１２０は、文書および文書メタデータ用の主たる記憶メカニズムである。好ましくは（制限する意図ではなく）、ストア１２０はウェブ・ファウンテン（ＷＦ）モデルを使用し、文書メタデータを文書に関連するキー値対として記憶しアクセスできるようにする単純ＡＰＩを想定する。

データ・ストア１２０内の文書１９０Ａは好ましくは、データ・ストア１２０内の文書の特定の順序付けに関して逆ファイルとして表現される。

アプリケーションがテキスト分析エンジン１３０（分析構造）の最終結果または中間結果が存続することを要求する場合、その分析構造は好ましくは、ストア１２０内のメタデータとして文書１９０Ａに関連するキー値構造に記憶される。他の形式も使用することができるが、この分析構造は、共通分析システム（ＣＡＳ）２１０コンポーネントによって解釈可能なＢＬＯＢとしてバイナリ形式で表現することができる。一部の実施形態では、検索エンジンの索引用の記憶メカニズムが文書ストア１２０になっている。

ＩＩＩ．Ｃ．分析エンジン
このセクションでは、ＴＡＥ１３０の諸態様の概要を示し、次にＴＡＥ１３０用の他の動作原理について検討する。

前述の通り、図２は分析エンジン２００としてＴＡＥ１３０を提示しており、同図では分析エンジン２００のフレームワークの図が示されている。ＵＩＭＡ１００は分析エンジン２００用のインターフェースを指定し、おおざっぱに言えば、それは「ＣＡＳイン」および「ＣＡＳアウト」である。フィルタリング機能、管理機能、および自己記述性機能に使用する動作は他にもあるが、このメイン・インターフェースはＣＡＳ２１０を入力として受け取り、ＣＡＳ２１０を出力として提供する。

以前にも紹介した図３はＴＡＥ１３０をアグリゲート分析エンジン３００として提示しており、同図ではアグリゲート分析エンジン３００のフレームワークの図が示されている。ランタイムでは、構成要素テキスト分析エンジン２２１、２２２、２２３を実行する順序がアグリゲート分析エンジン３００に与えられる。分析構造ブローカ３２０は、各テキスト分析エンジン２２１、２２２、２２３が指定のシーケンスに応じてＣＡＳ２１０にアクセスできることを保証する。

好ましくは、図２に示すインターフェースを実現するどのプログラムも、ＵＩＭＡ１００の実現例で分析エンジン・コンポーネントとして使用することができる。しかし、ＵＩＭＡ１００の一部として、分析エンジン２００は、多種多様なシステム・ミドルウェア・プラットフォーム上でのブリミティブ分析エンジン２００およびアグリゲート分析エンジン３００の作成、構成、およびフレキシブルな配備をサポートするフレームワークを含むことができる。次に、ＴＡＥ１３０の諸態様についてより詳細に述べる。

テキスト分析エンジン（ＴＡＥ）１３０は、テキスト状態のセマンティック・コンテンツを発見し表現することを担当するコンポーネントである。ＴＡＥ１３０には、以下の例示的な活動、すなわち、文書内のテキスト・セグメントによって表現される構文エンティティおよびセマンティック・エンティティ（たとえば、センテンス、タイトル、パラグラフ、人、場所、イベント、時間、生物学的エンティティ、関係、化学的エンティティなど）を発見することと、テキスト状態の関係を発見することと、文書の要約を生成することと、文書を異なる言語に変換することと、分類法で文書を分類することを課すことができる。

好ましくは、ＴＡＥ１３０は、文書１９０Ａを入力として取り、文書のテキストから推論されたセマンティック情報を表現する分析構造を生成する。また、ＴＡＥ１３０は、文書と、それが動作の結果として修正する初期分析構造から開始することもできる。

ＴＡＥ１３０は通常、アノテータ２２０（互いに交換できるように「マイナ」（miner）ということもできる）の集合を調整することによって実現される。アノテータ２２０は、新しいセマンティック・コンテンツを発見して記録するために元の文書１９０Ａあるいは前の分析結果を使用する明確な責任を有するコンポーネントである。アノテータ２２０は、好ましくはパイプライン・アーキテクチャ（たとえば、図４、図１４、および図１６を参照）として構成されるが、そのように構成する必要はなく、そのそれぞれは文書１９０Ａおよびパイプライン内の前のアノテータ２２０の結果について操作する。このタイプの配置については図１４に紹介されている。文書内の位置を識別するために使用する一連のアノテータ２２０の他の例は図１６に現れている。しかし、前記した通り、図５に示すようにアノテータ２２０の並列配置も提供することができる。

ハイレベルには、ＴＡＥ１３０が生テキストのセマンティック・コンテンツの発見を担当するコンポーネントであるものとして検討する。ＴＡＥ１３０は、たとえば、場所、イベント、人、あるいは他の同様のタイプの情報を表現するコーパス内のセマンティック・エンティティを発見するために、アプリケーションの前処理フェーズで使用することができる。照会時にアプリケーション１７０は、その照会を分析して、特定の位置で所与の時期に発生した何らかのイベントに関係する情報をその照会がシークしていることを判断することができる。好ましくは、アプリケーション１７０は次に、所与の位置および時間を加えたイベントを含む文書を送達するために検索エンジン１１０に照会する。この照会を効率よく実行するために、アプリケーション１７０は、前処理フェーズで発見されたセマンティック・エンティティ（特に、この場合はイベント）が検索エンジン１１０で索引が付けられることを期待する。

アノテータ２２０は制御または通信の依存関係なしに開発されることが好ましく、さもなければ、アノテータ２２０は２つ以上のアプリケーション１７０によって理解し再利用することが困難になる可能性がある。

ＴＡＥ１３０は、アノテータ・ロジックの絶縁を可能にする。したがって、ＴＡＥ１３０は、アノテータ２２０が構成され配備されているコンテナと見なすことができる。好ましくは、アノテータ２２０間の制御の流れおよび通信を調整することと、テキスト分析リソース（たとえば、辞書）への均一インターフェースをアノテータ２２０に提供することと、アノテータ２２０の集合の複合機能性にアクセスするためにアプリケーション１７０用の単一インターフェースを公開することはＴＡＥ１３０の役割である。

ＴＡＥ１３０は機能インターフェースを指定する。すなわち、ＴＡＥ１３０は、文書１９０Ａ（および任意選択で初期分析構造）を入力として受け入れ、その文書から推論されたセマンティック・コンテンツを表現する分析構造を生成する。ＴＡＥ１３０自体は、この機能性への技術インターフェースを指定しない。ＴＡＥ１３０へのアクセスは、様々な手段によって提供することができる。

ＴＡＥ１３０はアプリケーション１７０内に直接含める（同じ場所に配置する）ことができるが、ＴＡＥ１３０は分散サービス（たとえば、ウェブ・サービス）として配備することもできる。ＴＡＥサービスは、ＴＡＥ１３０をラップし、ＴＡＥ１３０への技術インターフェースを公開する。配備されたＴＡＥサービスは、文書を処理するための要求を聞き取り、その文書をＴＡＥ１３０に渡し、ＴＡＥ１３０が生成した分析構造を入手し、その分析構造を呼出し側に返す。

好ましくは、ＵＩＭＡ１００は、いくつかの共通分散オブジェクト技術およびプロトコル（たとえば、ＳＯＡＰ、ＭＱＳｅｒｉｅｓ、ＷｅｂＳｐｈｅｒｅ、Ｍａｉｌ）用のＴＡＥサービス実現例を提供する。また、ＵＩＭＡ１００は好ましくは、クライアントが必要なサービスを突き止めることができるように、ＴＡＥサービスを登録するための命名サービスも提供する。

一般に、プリミティブ２００とアグリゲート３００という２つのタイプのＴＡＥ１３０が存在する。プリミティブＴＡＥ２００は１つのアノテータ２２０用のコンテナである。これは、制御および通信の詳細からアノテータ２２０を絶縁し、テキスト分析リソースへの均一インターフェースをアノテータ２２０に提供する。アグリゲートＴＡＥ３００は、プリミティブ２００またはアグリゲートＴＡＥ３００のいずれかになる可能性のある１つまたは複数の他のＴＡＥに自分の作業を委任する。アグリゲートＴＡＥ３００は、構成要素ＴＡＥ２２１、２２２、２２３間の通信を管理するために分析構造ブローカ（ＡＳＢ）３２０を使用する。

共通分析システム２１０
共通分析システム（ＣＡＳ）２１０は、分析構造にアクセスして修正するためにすべてのアノテータ２２０が使用する共通機能として提供される。したがって、ＣＡＳ２１０は、アノテータ２２０間の調整を可能にし、種々のアプリケーション１７０および種々のタイプのアーキテクチャ（たとえば、疎結合対密結合）内でのアノテータ２２０の再利用を容易にする。もう一度、図１６を参照すると、ＣＡＳ２１０は、図１３に示すタイプ・システム１１１０を介して様々なアノテータ４１０〜４４５の動作、すなわち、ワークフローを抑制するものと見なすことができる。

ＣＡＳ２１０は主に、データ・モデリング機能、データ作成機能、およびデータ検索機能に備えるものである。データ・モデリングは、好ましくは、図１１（図６も参照）に示したように複数タイプのツリー階層を定義する。これらのタイプはフィーチャ（図７）という属性またはプロパティを有する。好ましい実施形態では、整数（ｉｎｔ）、浮動小数点（ｆｌｏａｔ）、および文字列（ｓｔｒｉｎｇ）など、少数の組込み（定義済み）タイプが存在する。このデータ・モデルは、アノテータ記述子で定義され、他のアノテータと共用される。データ・モデリング例は図２５に示されている。示されている例示的なデータ・モデル２２００は、トップ２２１０と、注釈２２２０と、Ｉｎｔ２２３０と、ＰＯＳ２２４０と、トークン２２５０と、センテンス２２６０と、前置詞２２７０と、名詞２２８０と、その他の追加タイプ２２９０とを含む、複数タイプのアセンブリを含んでいる。このデータ・モデル２２００は、図１１に開示された例示的な単一継承構造などの継承構造と、図８に開示された例示的なコンポーネント・リストなどのコンポーネント・リストとの組み合わせと見なすことができる。

ＣＡＳ２１０のデータ構造は「フィーチャ構造」という場合もある。フィーチャ構造を作成するために、そのタイプを指定しなければならない（図６を参照）。注釈（およびその他のフィーチャ構造）は索引に記憶される。フィーチャ構造は索引に関する反復子（複数も可）１１２５を介してアクセスすることができる（再び図１３を参照できる）。

図３７および図３８は、ＣＡＳ２１０の動作を説明するために有用な例示的な疑似コードを示している。この疑似コードは、動詞タイプのフィーチャ構造を作成し、それをＣＡＳ２１０の索引に挿入するときのタイプ・システムとフィーチャ構造の使い方を示している。

ＣＡＳ２１０は、抽象データ・タイプとして表現的オブジェクトベースのデータ構造を実現するメソッドの集合（たとえば、Ｊａｖａ（Ｒ）またはＣ＋＋ではクラスとして実現される）と見なすことができる。好ましくは、ＣＡＳ２１０の設計は、主として、ＴＡＥ１３０のフィーチャ／プロパティ構造に基づくものであり、この構造は、ユーザ定義オブジェクトと、フレキシビリティのためのプロパティおよび値と、効率のための静的タイプ階層と、１つまたは複数の反復子１１２５（図１３を参照）の使用により記憶データにアクセスするためのメソッドとを提供する。

ＣＡＳ２１０により実現された抽象データ・モデルは、他のフィーチャの中でも、プラットフォーム独立性（すなわち、タイプ・システムはプログラミング言語とは無関係に宣言的に定義される）と、パフォーマンス上の利点（たとえば、共通データ・モデルにより種々のプログラミング言語で書かれたアノテータ２１０を結合する場合）と、アノテータ２１０に関する入出力指定によるフロー構成（サービス・モデルとしてのアノテータ（ＴＡＥ）のサポートだけでなく、タイプ・チェックおよびエラー検出を可能にする宣言指定を含む）と、セマンティック索引付け、探索、および検索による第三世代検索プロシージャのサポート（すなわち、セマンティック・タイプはキーワード・ベースではなく、宣言型である）をＵＩＭＡ１００に提供する。

ＣＡＳ２１０は、効率よく分析構造を構築し検索するための機能をアノテータ２２０に提供する。この分析構造は主に、元の文書１９０Ａのテキストのサブシーケンスを記述したメタデータから構成されるデータ構造である。分析構造内の例示的なタイプのメタデータは注釈である。注釈は、それ自体のプロパティを備えたオブジェクトであり、テキスト・シーケンスに注釈を付けるために使用する。任意の数の注釈タイプが存在する。たとえば、注釈は、文書の構造（たとえば、ワード、センテンス、パラグラフなど）内のそれぞれの役割に関してテキスト・シーケンスにラベルを付けるか、またはそれぞれの文法上の役割（たとえば、名詞、名詞句、動詞、形容詞など）に関してテキスト・シーケンスを記述することができる。本質的に、注釈の数または適用については何も制限はない。その他の例としては、固有名詞、位置、軍事標的、時間、イベント、機器、条件、時間条件、関係、生物学的関係、家族関係、あるいは、意義または関心のあるその他の項目として識別するために、テキスト・セグメントに注釈を付けることを含む。

通常、アノテータ２２０の一機能は、それを認識するためにアノテータが設計された注釈セットの新しいインスタンスを発見し、他のアノテータ２２０による追加処理への入力のためにその注釈を分析構造に追加するために、テキストならびに既存の分析構造を分析することである。たとえば、図１９に関連して前述した抑制するという特定の関係は、このタイプの関係を識別するために具体的に設計されたアノテータ２２０によって（この場合は「may reduce the effectiveness of」というフレーズがそのフレーズの前後の２つの化合物名の間の抑制関係を暗示することを認識することによって）発見することができる。この特定のアノテータ２２０が抑制として認識可能な同様の性質の他のフレーズとしては、「reduces the effect of」（図２７を参照）と「suppresses the operation of」が考えられる。

注釈に加え、ＣＡＳ２１０は、元の文書テキストならびにアノテータ２２０によって生成可能な関連文書（たとえば、元の文書の変換あるいは要約）を記憶することができる。好ましくは、ＣＡＳ２１０は、ＸＭＬなどの確立したフォーマットで分析構造の種々の態様（たとえば、１組の注釈セット）のエクスポートを容易にする拡張機能を含む。

簡単に言えば、ＴＡＥ記述はＴＡＥ１３０を記述するオブジェクトである。好ましい実施形態では、ＴＡＥ記述子は、ＴＡＥ記述を表現するＸＭＬ文書である。ＴＡＥ記述は、ＴＡＥを開始して使用するために必要なすべての情報を含んでいる。しかし、ＴＡＥ記述は、それ自体ではＴＡＥ１３０をどのように配備するか（たとえば、それが密結合になるかまたは疎結合になるか）を指定しない。

ＴＡＥ記述は、異なる状態の完全度をもって存在することができる。たとえば、ＴＡＥ１３０の開発者は、構成パラメータを定義するが、構成パラメータのいずれも設定しないＴＡＥ記述を提供することができる。その場合、アプリケーション開発者は、そのＴＡＥ記述を取り出して、そのパラメータの値をプログラムによって割り当てる。

共通分析システム２１０（ＣＡＳ）の詳細について説明する。ＣＡＳ２１０は、ＴＡＥ１３０の一部分であって、テキストの注釈を定義して記憶する部分である。ＣＡＳ ＡＰＩは、注釈を作成してアクセスするために、アプリケーションとアノテータ２２０の両方が使用するものである。ＣＡＳ ＡＰＩは、好ましくは、少なくとも３通りの明確なインターフェースを含む。タイプ・システムは、新しいタイプの作成を制御し、タイプ間の関係（継承）およびタイプとフィーチャとの関係に関する情報を提供する。タイプ定義の非制限的な一例は図６に示されている。構造アクセス・インターフェースは、新しい構造の作成と、値のアクセスおよび設定とを処理する。構造照会インターフェースは、既存の構造の検索を扱う。次に、ＣＡＳ２１０のサブコンポーネントに関する詳細を示す。

タイプ・システムは、オブジェクト指向プログラミングにおけるクラス階層と同様に、システムにとって既知のエンティティの分類を提供する。タイプはクラスに対応し、フィーチャはメンバ変数に対応する。好ましくは、タイプ・システム・インターフェースは、新しいタイプ（型）に名前を提供し、それを付加すべき階層内の場所を指定することにより新しいタイプを追加することと、新しいフィーチャに名前を提供し、そのフィーチャを付加すべきタイプならびに値タイプを示すことにより新しいフィーチャを追加することと、「どのタイプ（複数も可）がこのタイプから継承するか」など、既存のタイプおよびフィーチャとそれらの関係を照会することという機能性を提供する。

好ましくは、タイプ・システムは少数の組込みタイプを提供する。前述の通り、基本タイプはｉｎｔと、ｆｌｏａｔと、ｓｔｒｉｎｇである。Ｊａｖａ（Ｒ）の実現例では、これらはそれぞれＪａｖａ（Ｒ）のｉｎｔタイプ、ｆｌｏａｔタイプ、ｓｔｒｉｎｇタイプに対応する。注釈および基本データ・タイプのアレイもサポートされる。この組込みタイプは、構造アクセス・インターフェースにおける特殊ＡＰＩサポートを有する。

構造アクセス・インターフェースは、新しい構造の作成ならびに既存の構造の値のアクセスと設定を可能にする。好ましくは、これは、所与のタイプの新しい構造の作成と、所与の構造上のフィーチャの値の取得および設定と、組込みタイプに関するメソッドのアクセスに備えるものである。図７を参照すると、同図では、ドメインに関する例示的なフィーチャ定義が示され、各フィーチャは所定の範囲を有している。

一部の実施形態では、フィーチャ構造に関するソート済み索引の作成および維持には、フィーチャ構造に関するコミット操作が必要になる場合がある。コミット時にシステムはフィーチャ構造に対する変更を適切な索引に伝搬する。

構造照会インターフェースは、所与の条件を満たす構造のリスト（反復）を可能にする。このインターフェースは、ＴＡＥ１３０が生成した結果にアクセスするために、アノテータ２２０ならびにアプリケーション１７０によって使用することができる。好ましくは、このインターフェースは直観的であり、種々のアプリケーション１７０でのＴＡＥ１３０の再利用を容易にする。

ＣＡＳ２１０内の構造に関する反復を構築するために種々の技法が存在する。第一に、フィルタリングされた反復において、フィーチャ構造に関する制約またはフィルタが構築される。好ましくは、これらは、不等式制約によってｉｎｔ値およびｆｌｏａｔ値を抑制し、等式によってｓｔｒｉｎｇ値を抑制し、構造のタイプを抑制し、経路の下に基本制約を埋め込み、制約とブール演算子ＡＮＤ、ＯＲ、およびＮＯＴとを組み合わせる。

反復内のすべての要素がその制約を満たす場合、新しい反復子１１２５を使用することができる。注釈については特殊ケースの反復子１１２５が存在する可能性があり、その場合、何らかのタイプ（たとえば、センテンス）の注釈について反復し、その反復内の各要素について埋込み注釈のスパンに含まれる他のタイプ（たとえば、トークン）のすべての注釈をリストすることが好ましい。埋込み構造反復子はフィルタリングされた反復子によって構築することができる。この目的のために特殊ＡＰＩを設けることは、便利であるとともに、最適化実現例を可能にする。

図３８は、ＣＡＳ２１０ベースのデータ・アクセスのための疑似コードの一例であり、トークンに関する反復の使用を示している。

一般に、ＴＡＥ１３０の基礎設計では、コンポーネントの再利用を奨励して可能にし、システムおよび配備の詳細からアルゴリズム開発者を絶縁する明確な開発役割をサポートし、下位レベルのシステム・ミドルウェアＡＰＩを絶縁することによってフレキシブルな様々な配備オプションをサポートする３つの基本原理を認識している。次に、この３つの原理の実現例の諸態様について述べる。

コンポーネントの再利用の奨励および可能化
コンポーネントの再利用を奨励し可能にすることは、所望の効率を達成し、クロスグループ・コラボレーションに備えるものである。ＴＡＥ１３０用のフレームワークの３つの特性がこの目標に対処する。これらの特性は、再帰的構造（recursive structure）と、データ主導（data-driven）と、自己記述性（self-descriptive）である。それぞれについて説明する。

再帰的構造： 図２に示すように、プリミティブ分析エンジン２００はアノテータ２２０とＣＡＳ２１０から構成される。アノテータ２２０は、分析ロジック（たとえば、トークン化、文法構文解析、エンティティ検出）を実現するオブジェクトである。アノテータ２２０は、ＣＡＳ２１０から元の文書のコンテンツとメタデータを読み取る。次にアノテータ２２０は、新しいメタデータを計算し、それをＣＡＳ２１０に書き込む。ネストされたプログラミング・モデルと同様に、アグリゲート分析エンジン３００は、それぞれの内部構造を絶縁しながら、コンポーネントを互いに組み合わせて再利用できることを保証する再帰的構造の一例である。

データ主導： 好ましくは、分析エンジン２００の処理モデルは厳密にデータ主導型である。この好ましい実施形態では、これにより、アノテータ２２０の分析ロジックは、それと組み合わせることができる特定の分析エンジン（複数も可）２００またはアノテータ２２０を埋め込むことができる制御シーケンスではなく、入力のコンテンツのみを前提とすることができることが示される。これは、アノテータの入力要件を満たしている限り、分析エンジン２００が種々のアグリゲート構造および種々の制御環境で正常に再利用可能であることを保証する。

図３の分析シーケンサ３１０は、ＣＡＳ２１０へのアクセス権を受け取るために次の分析エンジン２２１、２２２、２２３を動的に決定することを担当するフレームワーク内のコンポーネントである。分析シーケンサ３１０は分析構造ブローカ３２０とは別個のものであり、その責任は、それが何であれ、またそれがどこに位置していても、テキスト分析エンジン２２１、２２２、２２３のうちの適切なものにＣＡＳ２１０を送達することである。分析シーケンサ３１０の制御ロジックは好ましくは、アノテータ２２０に埋め込まれた分析ロジックから分離しており、ＣＡＳ２１０の転送を保証あるいは最適化することに関連する分析構造ブローカ３２０の関心事から分離している。この機能性の分離により、種々の分析シーケンサ３１０のプラグ・アンド・プレイが可能になる。分析シーケンサ３１０により、宣言的に指定した静的フローに関する単純な反復が計画アルゴリズムを複雑にすることができる。分析シーケンサ３１０の実施形態は、分析エンジン２２１、２２２、２２３間の線形フローに制限することができるが、しかし、より高度なアプリケーションでは、動的かつ適応順序付けを実現することができる。したがって、とりわけ、どの程度の制御指定を宣言表現内に配置するかと、このような高度な要件に関して分析シーケンサ３１０内でどの程度実現するかはアプリケーションに依存する。

自己記述性： 分析エンジン２２１、２２２、２２３がアグリゲートを形成するために容易に構成でき、種々の制御シーケンスで再利用できることを保証することは、技術的再利用性を保証するために好ましいことである。しかし、これは、広範囲の開発者コミュニティ内での再利用を可能にし検証するために十分ではない可能性がある。再利用を促進するために、分析エンジン２００の開発者は、それぞれの機能に関してどの分析エンジン２２１、２２２、２２３が使用可能であるかを発見できるようになっている。

好ましくは、各分析エンジン２００のデータ・モデルはＸＭＬで宣言され、ランタイム時にＣＡＳ２１０内で動的に認識される。ＵＩＭＡ１００では、分析エンジン２２１、２２２、２２３はこの宣言データ・モデルに関するそれぞれの入力要件および出力指定を公開し、分析エンジン・ディレクトリ・サービスで分析エンジン２２１、２２２、２２３を登録するためにこの情報を使用する。このサービスは好ましくは、アプリケーション開発者がその要求を満たす分析エンジンをブラウズあるいは検索できるようにする人間向きインターフェースを含む。

明確な開発役割のサポート
ＵＩＭＡ１００では、様々な開発役割が識別され、考慮されている。種々の開発者スキル・セットをサポートする複数の独立インターフェース・セットが含まれている。

たとえば、マルチリンガル機械翻訳を専攻する言語技術研究者は、高度に訓練されたソフトウェア・エンジニアではなく、フレキシブルでスケーラブルな配備に必要なシステム技術に熟練していない可能性がある。ＵＩＭＡ１００の一態様は、堅固でスケーラブルなシステム・アーキテクチャにおけるそれぞれの作業の効率的配備に備えるものである。

もう１つの例として、種々のコンポーネントを組み合わせて調整する方法に関するアイディアを持っている研究者自身はアルゴリズム開発者またはシステム・エンジニアではない可能性があり、依然として既存のコンポーネントを組み合わせることによるアイディアを迅速に作成し検証する必要がある。さらに、分散され、使用可能性の高いサービスとして、またはアグリゲート・システム内の連結オブジェクトとして分析エンジン２２１、２２２、２２３を配備することは、さらに他のスキルを必要とする。

したがって、所与の開発役割が識別されている。このため、ＵＩＭＡ１００は、上記のように種々のスキル・セットをサポートする複数の独立インターフェース・セットを使用することができる。次にこれらについて検討する。

アノテータ開発者： アノテータ開発者の役割は、統計的言語認識プログラムからルールベースの名前付きエンティティ検出プログラム、さらに文書分類プログラムに及ぶコア・アルゴリズムの開発に集中している。

このフレームワークの設計は、相互運用性、リカバリ、遠隔通信、分散配備などのようなアグリゲート・システム挙動またはシステム問題に対処するためのコードをアノテータ開発者が開発する必要がないことを保証する。その代わりに、このフレームワークは、アルゴリズム・ロジックおよび結果の論理表現に集中するという目標に備えるものである。

この目標は、分析エンジン２００のフレームワークを使用することと、アノテータ開発者に対し３つのインターフェース、すなわち、アノテータ・インターフェースと、アノテータ・コンテキスト・インターフェースと、ＣＡＳインターフェースのみを理解することを要求することにより、達成される。好ましくは、アノテータ開発者は、アノテータ・インターフェースを実現するステップと、入力を読み取り、結果を書き込むためのＣＡＳインターフェースと、リソースにアクセスするためのアノテータ・コンテキスト・インターフェースとを使用して分析アルゴリムをエンコードするステップと、分析エンジン記述子を作成するステップと、分析エンジン・ファクトリを呼び出すステップを実行する。

このフレームワークに分析アルゴリズムを埋め込むために、アノテータ開発者はアノテータ・インターフェースを実現する。好ましくは、このインターフェースは単純なものであり、初期設定のためのメソッドと文書を分析するためのメソッドという２つのメソッドのみの実現を必要とする。

アノテータ開発者が入力データにアクセスし、分析結果を登録するのは、ＣＡＳ２１０のみによって行われる。前記した通り、ＣＡＳ２１０は、前に実行された分析エンジン２２１、２２２、２２３によって提供されるメタデータを加えた元の文書（分析の主題）を含むことができる。このメタデータは、元の文書の諸要素に関する注釈を含むことができる。分析エンジン２２０へのＣＡＳ２１０の入力は、メモリ内に常駐し、遠隔で管理し、他のコンポーネントによって共用することができる。

好ましくは、アノテータが調べる必要がある辞書などのすべての外部リソースは、アノテータ・コンテキスト・インターフェースを介してアクセスされる。したがって、データの正確な物理的表明は、リソース・データをキャッシュするかどうかおよびそれをキャッシュする方法に関する決定のように、デプロイヤ（deployer）によって決定することができる。

好ましい一実施形態では、アノテータ開発者は、入力要件、出力仕様、および外部リソースの依存関係を識別するＸＭＬ記述子を完成する。アノテータ・オブジェクトおよび記述子が与えられると、このフレームワークの分析エンジン・ファクトリは完全な分析エンジン２２０を返す。

分析エンジン・アセンブラについて説明する。分析エンジン・アセンブラは、コンポーネント分析エンジンの宣言調整によりアグリゲート分析エンジンを作成する。設計目標は、アセンブラがコードを作成せずにアグリゲート・エンジンを構築できるようにすることである。

分析エンジン・アセンブラは、その機能に関して使用可能なエンジンを考慮し、フロー制約を宣言的に記述する。これらの制約は、選択したコンポーネント・エンジンのＩＤとともに、アグリゲート・エンジンのＸＭＬ記述子に収集される。このアセンブラはフレームワークの分析エンジン・ファクトリ・オブジェクトにこの記述子を入力し、アグリゲート分析エンジンが作成されて返される。

分析エンジン・デプロイヤについて説明する。分析エンジン・デプロイヤは、分析エンジンとそれが必要とするリソースを特定のハードウェアおよびシステム・ミドルウェア上にどのように配備するかを決定する。ＵＩＭＡ１００は好ましくは、コンポーネントをどのように配備するかに関してそれ自体の指定を提供せず、特定のタイプのミドルウェアまたはミドルウェア製品の使用を義務づけることもない。その代わりに、ＵＩＭＡ１００は、その要求を満たすミドルウェアを選択するためのフレキシビリティをデプロイヤに提供する。

下位レベルのシステム・ミドルウェアの絶縁
人間言語技術（Human Language Technologies：ＨＬＴ）アプリケーションは、様々な要件を他のタイプのアプリケーションと共用することができる。たとえば、このアプリケーションはスケーラビリティ、セキュリティ、およびトランザクションを必要とする可能性がある。アプリケーション・サーバなどの既存のミドルウェアはこれらの要求のうちの多くを満たすことができる。これに対して、ＨＬＴアプリケーションは、デスクトップ・コンピュータまたはＰＤＡ上に配備できるように小さいフットプリントを持つ必要がある場合もあれば、それ自体のミドルウェアを使用する他のアプリケーション内に埋込み可能である必要がある場合もある。

ＵＩＭＡ１００の設計目標の１つは、任意のタイプのミドルウェア上での分析エンジン２２１、２２２、２２３の配備をサポートし、これらの関心事からアノテータ開発者および分析エンジン・アセンブラを絶縁することである。これは、サービス・ラッパ（Service Wrappers）および分析構造ブローカ３２０の使用によって行われる。分析エンジン・インターフェースは、入力および出力がＣＡＳ２１０を介して行われることを指定するが、ＣＡＳ２１０がコンポーネント分析エンジン間でどのように転送されるかを指定するわけではない。サービス・ラッパは特定の配備に必要なＣＡＳの直列化および非直列化を実現する。アグリゲート分析エンジン３００内では、種々のサービス・ラッパを使用してコンポーネントを配備することができる。分析構造ブローカ３２０は、これらのコンポーネントがどのように配備されるかにかかわらず、これらのコンポーネント間でＣＡＳ２１０を転送するコンポーネントである。

ＣＡＳ２１０は、疎結合または密結合のいずれかであると見なすことができる。疎結合のＣＡＳ２１０は、２つ以上のメモリ上に分散される１つのタイプ・システムを表現するものであり、たとえば、ＵＩＭＡ１００のネットワーク化アプリケーション内で検出することができる。この場合、アノテータ４１０〜４７０などのアノテータは２つ以上のメモリ内で機能する。密結合のＣＡＳ２１０は、１つのメモリ（または１台のマシン）内に位置する１つの定義済みタイプ・システムを表現するものであり、その場合、アノテータ４１０〜４７０などのアノテータは同じメモリを共用する。

新しいタイプのミドルウェアをサポートするために、好ましくは新しいサービス・ラッパと分析構造ブローカ３２０の拡張機能が開発され、フレームワークにプラグインされる。分析エンジン２００自体は決して修正する必要はない。

たとえば、ウェブ・サービスとメッセージ・キューイング・インフラストラクチャ両方の上にあるサービス・ラッパおよび分析構造ブローカ３２０が実現されている。各実現例は、配備シナリオの詳細に関する種々の態様およびフィーチャを伴う。一般に、ウェブ・サービスは、ＸＭＬメッセージを交換することによって通信するアプリケーションを含む。

一般に、ＵＩＭＡ１００は、ユーザ・インターフェース（ＵＩ）をアプリケーション固有のコンポーネントとして扱う。アプリケーションがどのように入力を受け入れ、結果を通信し、ユーザとダイアログするかは、アプリケーション１７０によって決定される。

ＩＶ．システム・インターフェース
次に、ＵＩＭＡ１００の最上位レベルのコンポーネント間の様々なインターフェースについて説明する。図２６は図１と同様の図を示しているが、図２６はＵＩＭＡ１００のインターフェースの諸態様をさらに含み、これらはひとまとめにしてテキスト・インテリジェンス・システム１０８として示されている。アプリケーション１７０と検索エンジン１１０との間のインターフェース１１５の諸態様のより詳細な様子は図２７に示されている。他のインターフェースと、そのインターフェースによって運搬されるデータ・フローも示されている。たとえば、アプリケーション１７０と文書ストア１２０との間のインターフェース１２５と、アプリケーション１７０とＴＡＥ１３０との間のインターフェース１３５と、アプリケーション１７０と知識アクセス（構造化情報）１８０との間のインターフェース１８５と、アプリケーション１７０と、知識ディレクトリ・サービス１０６およびテキスト分析ディレクトリ・サービス１０７を含むディレクトリ・サービス１０５との間のインターフェース１７５が存在する。

インターフェース１１５の記述を助けるために、いくつかの条件を提示する。たとえば、ビューは複数のトークン化をサポートし、スパンは１つのビュー内の範囲に注釈を付けるために使用する。スパンベースの照会の一例は、「タイトル」フィールドが「抑制する」という関係を含んでいる文書を見つけるための照会を含む。例示的な結果は、「Ibuprofen reduces the effects of aspirin on vascular dilation」を含む文書１９０Ａになるだろう。好ましい実施形態では、スパンベースの照会を定義するために様々な照会言語を使用することができる。好ましくは、アプリケーション１７０は、前処理およびランタイム（または照会時間）中に検索エンジン１１０を使用することができる。

前処理中にアプリケーション１７０は、テキスト・インテリジェンス・システム１０８を介してインターフェース１２５により文書ソース１２０から文書を検索し、その文書をインターフェース１３５によりＴＡＥ１３０のうちの１つまたは複数に渡すことができる。ＴＡＥ１３０は、元のテキストや他のアグリゲート構造（たとえば、候補用語集項目、要約、またはカテゴリ化）内のトークンのスパンについて注釈の形の分析構造として結果を返す。この結果により、アプリケーション１７０は、発見したエンティティが照会時間中に容易にアクセス可能になるように、そのエンティティの全部または一部を検索エンジン１１０用の索引に追加することを選択することができる。

検索エンジン１１０はビューを識別するための手段をインターフェース１１５を介してアプリケーション１７０に提供し、アプリケーション１７０はインターフェース１１５を介して索引付けのために指定のフォーマットでエンティティを検索エンジン１１０に渡す。テキスト分析と検索の強力な統合をサポートするために、ＵＩＭＡ１００は、検索エンジン１１０がスパンに関する注釈に索引を付ける能力を提供することを期待する。たとえば、「＄ＵＳ Ｐｒｅｓｉｄｅｎｔ」というセマンティック・エンティティを検討すると、検索エンジン１１０の索引付けインターフェースによりアプリケーション１７０は「Ｊｏｈｎ Ｑｕｉｎｃｙ Ａｄａｍｓ」などのトークンのスパンに関して「＄ＵＳ Ｐｒｅｓｉｄｅｎｔ」というセマンティック・エンティティに索引を付けることができる。

照会時にはアプリケーション１７０は、ブール照会を指定するために検索エンジン１１０の照会インターフェース１１５を使用する。テキスト分析と検索の強力な統合をサポートするために、ＵＩＭＡ１００は、検索エンジン１１０がスパンに関する照会言語を提供することを期待し、このインターフェースによりアプリケーション１７０は照会を実行することができる。たとえば、照会は、タイトル（注釈付きスパン）が米国大統領（注釈付きスパン）を含むすべての文書をシークするかまたは文書の要約（注釈付きスパン）が「抑制する」という関係（注釈付きスパン）を含み、その関係が「ｉｎ ｖｉｔｒｏ」というテキストを含む修飾子（注釈付きスパン）を含むすべての文書をシークすることができる。

ＴＡＥ１３０と検索エンジン１１０との間のインターフェース１３５に移行すると、好ましくは、ＴＡＥ１３０にはアプリケーション１７０によって１つまたは複数の文書が供給される。好ましくは、ＴＡＥ１３０は文書を突き止めるために検索エンジン１１０を使用しない。ＴＡＥ１３０は、アプリケーション１７０が索引を付けるためにシークする可能性のある注釈を生成するが、ＴＡＥ１３０は何に索引を付けるかを決定せず、アプリケーション１７０の索引付け機能に対して直接通信することもない。

好ましくは、アプリケーション１７０とＴＡＥ１３０との関係は、どちらも相手の状態に影響を及ぼさないようなものになっている。アプリケーション１７０は、好ましくは、ＴＡＥ１３０を呼び出すために結果全体の状態を管理するためのプログラミング・モデルおよび演算子を含む。共用／更新可能状態は好ましくは、ＴＡＥ１３０によって直接ではなく、ＵＩＭインフラストラクチャによって管理される。たとえば、適切なルールの１つは、「ＴＡＥとアプリケーションの間には共用グローバル変数は一切存在しない」ということになる可能性がある。

Ｖ．２レベル検索
好ましくは、ＵＩＭＡ１００は、２レベル評価プロセスまたはモデルを使用する検索技法によって支援される。このプロセスについて例示的に説明するが、このプロセスは本明細書において本発明を制限するものと解釈すべきではない。

一部の実施形態では、この評価モデルは、あらゆる索引語が１つのポスティング・リストに関連付けられている従来の逆索引を想定している。このリストは、索引語を含む集合内の各文書ごとに１つの項目を含む。この項目は、その文書固有の正のＩＤであるＤＩＤだけでなく、文書内の用語のオカレンスの回数、オカレンスのオフセットなど、適用可能なスコアリング・モデルが必要とするその他の情報を含んでいる。好ましくは、ポスティング・リストは、文書ＩＤの増加順に順序が付けられている。

プログラミングの観点から見ると、このような逆索引に関する複合照会をサポートするために、オブジェクト指向手法を使用することが好ましいと思われる。この手法を使用して、そのポスティング・リストについて順次反復することができる基本反復子１１２５オブジェクト（「ストリーム・リーダ」オブジェクト）に各索引語が関連付けられる。そのうえ、反復子１１２５は、ポスティング・リスト内の所与の項目にスキップすることができる。特に、この反復子は、それに関してＤＩＤ＞ｉｄになる最初のポスティング要素を返すｎｅｘｔ（ｉｄ）というメソッドを提供する。このような文書がまったくない場合、用語反復子１１２５は、索引内のすべての既存ＤＩＤより大きいＩＤであるＬａｓｔＩＤを備えた特殊ポスティング要素を返す。

ブール演算子およびその他の演算子（または述部）は、基本反復子１１２５から構築された複合反復子１１２５に関連付けられる。たとえば、演算子Ａ（ＯＲ）Ｂの場合のｎｅｘｔメソッドは以下の関係で定義される。

（ＷＡＮＤ）演算子：
本明細書に開示されている２レベル手法では、Ｗｅａｋ（ＡＮＤ）またはＷｅｉｇｈｔｅｄ（ＡＮＤ）を表し、便宜上、ＷＡＮＤとして参照されるブール述部を使用する。ＷＡＮＤは、引き数として、ブール変数Ｘ₁、Ｘ₂、・・・、Ｘ_kのリストと、関連する正の（positive）重みｗ₁、ｗ₂、・・・、ｗ_kのリストと、しきい値θとを取る。定義によれば、

である場合に、(WAND)(X₁, w₁, ...X_k,w_k, θ)は真になる。ここで式中のｘ_iはＸ_iの標識変数であり、Ｘ_iが真であればｘ_i＝１であり、そうでなければｘ_i＝０である。

このＷＡＮＤは、

および

を介して（ＡＮＤ）および（ＯＲ）を実現するために使用できることが認識できる。

（ＷＡＮＤ）を表現するために他の規則を使用することができ、たとえば、しきい値は最初の引き数として現れる可能性があることに留意されたい。

したがって、しきい値を変化させることにより、（ＷＡＮＤ）は実質的に（ＯＲ）関数から実質的に（ＡＮＤ）関数に移ることができる。ｘ_ｉが任意の単調増加関数となってしきい値より大きくなることを要求するか、または特に任意の単調ブール公式が真になることを要求することにより（１）の条件を置換することにより、（ＷＡＮＤ）を一般化することができることに留意されたい。

図２８はＷＡＮＤしきい値とパターンの関係を示しており、最後のパターンに重み２５３０が割り当てられるまで、所与のパターンに重み２５１０が割り当てられ、第２のパターンに所望の重み２５２０が割り当てられる。しきい重み２５５０を生成するために、割当て２５１０、２５２０、２５３０がひとまとめにして使用される。ＷＡＮＤ技法２８００の使い方の要約は図３１に提示されている。図３１では、第１のステップは、初期設定すること２８１０と、次にパターンの加重合計を評価すること２８２０と、その合計がしきい値より大きいかどうかを判定すること２８３０とを含む。その合計がしきい値以下である場合、ステップ２８８０でポインタが進められ、ステップ２８２０でもう一度、パターンの加重合計が評価される。その合計がしきい値より大きい場合、このメソッドはステップ２８４０で詳細な評価を実行し、ステップ２８５０でその値がヒープ（後述するように、上位ｎ個の結果を追跡するためにサイズｎのヒープ）内の最小値より大きいかどうかの判定を実行する。大きくない場合、制御はステップ２８８０に戻され、そうではない場合、ステップ２８６０で結果がヒープに挿入され、ステップ２８７０でしきい値あるいは重みが修正され、制御がステップ２８８０に戻される。

一般に、（ＷＡＮＤ）は複数文書について反復する。何らかの点でＷＡＮＤはプロシージャ呼出しと見なすことができるが、適切なメソッドおよび状態を備えたＷＦ反復子のサブクラスであるとも見なさなければならない。このため、（ＷＡＮＤ）は現行文書ならびにその他の属性を表現する「カーソル」を有する。

図２８に示すように、ＷＡＮＤへの引き数はパターンと重みである。パターンｐａｔ１、ｐａｔ２、・・・は、反復子１１２５として実現されたＷＦによってサポートされる典型的なパターンである。好ましくは、各パターンは、反復中に必ずしも同じにならない可能性のある関連の正の重みｗを有する。また、しきい重みｗ０も存在する。

動作時に、ＷＡＮＤ（ｗ０，ｐａｔ１，ｗ１，ｐａｔ２，ｗ２，．．．）は、一致したパターンに関する重みの合計がｗ０より大きくなるように、ｐａｔ１、ｐａｔ２、・・・に十分一致する次の文書（現行カーソルに関して）を返す。

より一般的に、ｐａｔ１、ｐａｔ２、・・・のそれぞれは、文書のコンテンツのブール関数を表現する。その場合、動作時に、ＷＡＮＤ（ｗ０，ｐａｔ１，ｗ１，ｐａｔ２，ｗ２，．．．）は、一致したパターンに関する重みの合計がｗ０より大きくなるように、ｐａｔ１、ｐａｔ２、・・・を十分満足する次の文書（現行カーソルに関して）を返す。

上記の記述に基づいて、ｐａｔ＿ｉが文書１９０Ａのコンテンツの任意のブール関数を表現する場合、返された文書は、満足した関数ｐａｔ１、ｐａｔ２、・・・に関する重みの合計がｗ０より大きくなるように、ｐａｔ１、ｐａｔ２、・・・を十分満足することが分かる。

重みの合計は必ずしもその文書のスコアではない。好ましくは、重みの合計は単純にプルーニング（pruning）・メカニズムとして使用する。実際の文書スコアは、すべての正規化要因とその他の同様の属性を考慮に入れて、ランキング・ルーチンによって計算される。好ましくは、合計の使用は任意であり、その代わりにどの増加関数を使用することもできる。

プルーニング重みとスコアが同じであると想定しながら、以下の例について検討する。

照会が<cat dog fight>であると想定する。

上位１００個の文書が所望されている。何らかの時点でスコア＞＝３０である１００個の文書が存在する場合、WAND(30, <cat>, 3, <dog>, 2, <fights>, 4, LA(<cat>, <dog>), 10,LA(<cat>, <fights>), 14, LA(<dog>, <fights>), 12)であり、ＬＡ（Ｘ，Ｙ）がＸ ＮＥＡＲ Ｙを実現する呼出しが行われる。

実現に関しては、（ＷＡＮＤ）の使用はＡＮＤの実現例に多少似ている。一部の実施形態では、「ジッピング」（zipping）のルールは以下のようになる可能性がある。

完全ＷＡＮＤ反復子１１２５は、現行一致を表現するＣＵＲ＿ＤＯＣというカーソルを有する。ＣＵＲ＿ＤＯＣを進めることが望ましい。

各パターンｐａｔ＿ｉは、それがＣＵＲ＿ＤＯＣを上回る位置で一致する場所を表現する関連のｎｅｘｔ＿ｄｏｃ＿ｉを有する。

ｎｅｘｔ＿ｄｏｃ＿ｉ＿１＜＝ｎｅｘｔ＿ｄｏｃ＿ｉ＿２＜＝ｎｅｘｔ＿ｄｏｃ＿ｉ＿３＜＝・・・になるように、すべてのｎｅｘｔ＿ｄｏｃ＿ｉをソートする。

ｋは、ｗ＿ｉ＿１＋ｗ＿ｉ＿２＋・・・＋ｗ＿ｉ＿ｋ＞ｗ＿０になるような最小索引とする。その場合、ＣＵＲ＿ＤＯＣをｎｅｘｔ＿ｄｏｃ＿ｉ＿ｋに進め、他のすべてのカーソルをＣＵＲ＿ＤＯＣ以上の位置に進めることが可能であると主張する。次に、ＣＵＲ＿ＤＯＣにある十分な重みが使用可能である場合、ＣＵＲ＿ＤＯＣが返される。そうではない場合、もう一度、これらの位置がソートされる。

この動作を理解するために、パターンｐａｔ＿ｉがｎｅｘｔ＿ｄｏｃ＿ｉの後ろのあらゆる単一文書に一致すると想定する。この楽観的想定でも、ｎｅｘｔ＿ｄｏｃ＿ｉ＿ｋより前のいかなる文書も十分な重みを持っていない。

以下の所見を示すことができる。
１．正規のＡＮＤ（Ｘ，Ｙ，Ｚ）はＷＡＮＤ（３，Ｘ，１，Ｙ，１，Ｚ，１）とまったく同じである。２つの反復子１１２５は、まったく同じジャンプを行って、まったく同じ位置のリストにより内部でジッピングすることになる。
２．正規のＯＲ（Ｘ，Ｙ，Ｚ）はＷＡＮＤ（１，Ｘ，１，Ｙ，１，Ｚ，１）とまったく同じである。２つの反復子は、まったく同じジャンプを行って、まったく同じ位置のリストにより内部でジッピングすることになる。
３．あらゆる文書が一致しなければならないという表現であるフィルタ式Ｆを使用する場合、これはＷＡＮＤ（ｌａｒｇｅ＿ｎｕｍｂｅｒ＋ｔｈｒｅｓｈｏｌｄ，Ｆ，ｌａｒｇｅ＿ｎｕｍｂｅｒ，ｐａｔ１，ｗ１，．．．）として実現することができる。

実際のスコアは単なる合計ではないので、プルーニング式を設定するために様々な技法を使用することができる。これらの技法は好ましくは、正規化に加えてＴＦを考慮に入れる。

スコアリング
文書の最終スコアは、その照会に対する文書のテキスト類似性に基づくテキスト・スコアを含む。この最終スコアには、ウェブ・ページの接続性、科学資料の引用カウント、Ｅコマース品目の目録などの他の照会独立（照会非依存）要因を含むが、解説を簡単にするために、このような照会独立要因はまったくないと想定する。さらに、付加的スコアリング・モデルが存在すると想定する。すなわち、各文書のテキスト・スコアは、その文書に属するすべての照会用語の寄与率（contribution）を合計することによって決定される。したがって、照会ｑに関する文書ｄのテキスト・スコアは以下のようになる。

たとえば、ｔｆ×ｉｄｆというスコアリング・モデルの場合、α_tは照会に含まれる用語ｔのオカレンスの回数（発生数）に索引内のｔの逆文書頻度（inverse document frequency）（ｉｄｆ）を掛けた関数であり、ｗ（ｔ，ｄ）はｄ内のｔの用語頻度（term frequency）（ｔｆ）を文書の長さ｜ｄ｜で割った関数である。加えて、各用語は、以下のように、いずれかの文書スコアに対するその最大寄与率の上界ＵＢ_tに関連付けられていると想定する。

したがって、ある文書内に現れるすべての照会用語の上界を合計することにより、その文書の照会依存スコアの上界を以下のように決定することができる。

照会用語は、単純用語、すなわちそれに関する静的ポスティング・リストが索引に記憶される用語、または複合用語、すなわちそれに関するポスティング・リストが照会評価中に動的に作成されるフレーズなどの用語にすることができることに留意されたい。このモデルは単純用語と複合用語とを区別せず、各用語は上界を提供し、実現のために各用語はポスティング反復子１１２５を提供する。これらの条件が与えられると、予備スコアリングは各文書ｄごとに以下のような評価を伴う。

式中、Ｘ_iは文書ｄ内の照会用語ｉの存在に関する標識変数であり、しきい値θは以下に説明するアルゴリズムの間に変化する。（ＷＡＮＤ）が真であると評価された場合、文書ｄは完全評価を受ける。しきい値θは好ましくは、それまでに見つかった上位ｎ個の結果のうちの最小スコアｍに基づいて、アルゴリズムによって動的に設定される。ｎは要求した文書の数である。

しきい値が大きくなるほど、スキップされる文書が増加し、したがって、完全スコアが計算される文書は少なくなる。寄与率の上界が正確である場合、ある文書の最終スコアがその予備上界程度になることは容易に分かる。したがって、θ＝ｍであるＷＡＮＤによってスキップされるすべての文書は、同じ付加的スコアリング・モデルを使用する他の代替方式による上位スコアリング文書セット内に入らないだろう。

しかし、後で説明するように、（ａ）事例によっては、各用語の寄与率について近似上界のみが使用可能になる可能性があり、（ｂ）そのスコアは照会独立要因を含む可能性があり、（ｃ）実行される完全評価を少なくするために、しきい値を大きくすることが好ましい可能性がある。したがって、実際には、θ＝Ｆ＊ｍと設定することが好ましく、Ｆはその集合について正のエラーと負のエラーのバランスを取るために選択したしきい係数（threshold factor）である。これを効率よく実現するために、照会用語に関連する反復子の上に（ＷＡＮＤ）反復子を配置することが好ましい。これについては以下に詳述する。

一般に、上記の手法は付加的スコアリングに制限されず、（ＷＡＮＤ）の定義内の任意の単調関数を使用することができる。すなわち、唯一の制約事項は、好ましくは照会用語の存在によって文書の全スコアが減少されないことである。これは、すべての典型的な情報検索（ＩＲ）システムに該当する。

ＷＡＮＤ反復子の実現
（ＷＡＮＤ）述部は、完全評価のための候補文書を反復して見つけるために使用することができる。ＷＡＮＤ反復子は、この述部を満足する文書を素早く見つけることができるプロシージャを提供する。

好ましくは、ＷＡＮＤ反復子は、図２９の疑似コードに示されているｉｎｉｔ（）関数を呼び出すことによって初期設定される。このメソッドは、照会用語のアレイを入力として受け取り、考慮すべき現行文書（ｃｕｒＤｏｃ）をゼロに設定する。また、このメソッドは、ポスティング・リスト内の最初のポスティング要素になるように現行ポスティングｐｏｓｔｉｎｇ［ｔ］も初期設定する。図２９のｉｎｉｔ（）関数を呼び出した後、このアルゴリズムは、完全評価のための次の候補を取得するためにＷＡＮＤのｎｅｘｔ（）メソッドを繰り返し呼び出す。ｎｅｘｔ（）関数は、しきい値θを入力として取り、その近似スコアがθより大きい次の文書を返す。その近似スコアがしきい値より小さい文書はスキップされる。図３０は、ｎｅｘｔ（）関数を実現するための非制限的な疑似コードを示している。

ＷＡＮＤ反復子はその実行中に以下のように２つのインバリアント（invariants）を維持する。
１．ＤＩＤ＜ｃｕｒＤｏｃであるすべての文書はすでに候補と見なされている。
２．どの用語ｔについても、ｔを含み、ＤＩＤ＜ｐｏｓｔｉｎｇ［ｔ］．ＤＩＤである文書はすでに候補と見なされている。

ｉｎｉｔ（）関数はこれらのインバリアントを確立することに留意されたい。ＷＡＮＤ反復子は、それが返すべき候補文書を見つけるまで、個々の用語反復子を繰り返し進める。これは、すべての反復子を一斉に次の文書に進め、ＤＩＤの順に候補文書のスコアを近似し、しきい値と比較することにより、単純素朴に実行しうる。しかし、このメソッドは非常に効率が悪いと思われ、いくつかのディスクＩ／Ｏと関連の計算を必要とするだろう。本明細書に開示されているアルゴリズムは、ｎｅｘｔ（）演算の数と近似評価の数を最小限にするように最適化される。これは、まずその現行ポスティングのＤＩＤの増加順に照会用語をソートすることにより実施される。次に、このメソッドは、ピボット用語、すなわち、その順序内で、それを含みそれより先行するすべての用語の上界の累積合計が所与のしきい値を超えるような最初の用語を計算する（図３０の行５およびその次を参照）。ピボットＤＩＤは、候補になる可能性のある最小ＤＩＤである。このような用語がまったくない場合（すべての用語上界の合計がしきい値未満であることを意味する）、反復子は停止し、ＮｏＭｏｒｅＤｏｃｓという定数を返す。

ピボット位置の意義を理解するために、ｉｎｉｔ（）後のｎｅｘｔ（）の最初の呼出しについて検討する。すべての用語がその現行ポスティングに続くすべての文書内に存在する場合でも、ピボット文書より先行する文書はいずれも、それがしきい値を超えるようになるのに十分な総寄与率を持っていない。ピボット変数は、ピボット用語の現行ポスティングに対応するＤＩＤに設定される。このピボットが、最後に考慮した文書（ｃｕｒＤｏｃ）のＤＩＤ以下である場合、ＷＡＮＤはピボット用語より先行する用語を選び出し、ｃｕｒＤｏｃを越して反復子を進めるが、その理由は、ｃｕｒＤｏｃより先行するすべての文書が（インバリアント１によって）すでに考慮されており、したがって、次にシステムはより大きいＤＩＤを備えた文書を考慮しなければならないことである。これによりインバリアント２が保持されることに留意されたい。ピボットがｃｕｒＤｏｃより大きい場合、ピボット文書に対する寄与率の合計がしきい値より大きいかどうかの判定が行われる。２通りのケースがある。すなわち、ピボット用語より先行するすべての用語の現行ポスティングＤＩＤがピボット文書に等しい場合、ピボット文書はしきい値より大きい累積上界を備えた１組の照会用語を含み、このため、ｎｅｘｔ（）はｃｕｒＤｏｃをそのピボットに設定し、完全評価のための候補としてこの文書を返す。そうではない場合、ピボット文書は先行するすべての用語を含む場合もあれば含まない場合もあり、すなわち、十分な寄与率を有する場合もあれば有していない場合もあり、ＷＡＮＤはこれらの用語のうちの１つを選択し、ピボット位置以上の位置までその反復子を進める。

ｎｅｘｔ（）関数は、ｃｕｒＤｏｃ以下のＤＩＤを備えたすべての文書がすでに候補として考慮されているというインバリアント（インバリアント１）を維持することに留意されたい。定義によるピボット用語はＤＩＤ順序内でその累積上界がしきい値を超える最初の用語であるので、そのＤＩＤがピボットのＤＩＤより小さい他の文書が有効な候補になることは不可能である。このため、ピボットのＤＩＤより小さいＤＩＤを備えたすべての文書は、ピボット用語より先行する用語のみを含むことができ、したがって、そのスコアに関する上界は厳密にしきい値未満になる。ｃｕｒＤｏｃは成功の場合、すなわち、その順序内で最初にある新しい有効候補を見つけた場合に、ピボット文書まで進められるだけなので、ｎｅｘｔ（）はそのインバリアントを維持することになる。

好ましくは、ｎｅｘｔ（）関数は、ｓｏｒｔ（）、ｆｉｎｄＰｉｖｏｔＴｅｒｍ（）、ｐｉｃｋＴｅｒｍ（）という３つの関連関数を呼び出す。ｓｏｒｔ（）関数は、その現行ＤＩＤの非減少順に用語をソートする。ｓｏｒｔ（）に対する連続呼出しの間に１つの用語だけがその反復子を進めるので、いずれの段階でも用語を完全にソートする必要はないことに留意されたい。このため、適切なデータ構造を使用することにより、ソートした順序は１つの用語のみの位置を修正することによって維持される。第２の関数であるｆｉｎｄＰｉｖｏｔＴｅｒｍ（）は、ソートした順序内で、それより先行しそれを含むすべての用語の累積上界が所与のしきい値を超える最初の用語を返す。第３の関数であるｐｉｃｋＴｅｒｍ（）は、１組の用語を入力として受け取り、その反復子が進められる用語を選択する。最適選択戦略は、最大予想スキップを生成することになる用語を選択する。用語反復子をできるだけ進めると、考慮すべき文書の数が削減され、このため、検索すべきポスティングの数も削減される。この方針は完全に評価される１組の文書に対し何も影響を及ぼさないことに留意することができる。そのスコア上界がしきい値より大きい文書は、いずれの戦略でも評価されることになる。したがって、ｐｉｃｋＴｅｒｍ（）方針が良好であればパフォーマンスが改善される可能性があるが、それは精度に影響を及ぼすものである。一実施形態のｐｉｃｋＴｅｒｍ（）は、最も稀な用語が最大スキップを生成することになると想定して、最大逆文書頻度を備えた用語を選択する。他のｐｉｃｋＴｅｒｍ（）方針も使用することができる。

これについては、K. Beyer、R. Lyle、S. Rajagopalan、およびE. Shekitaにより本出願と同一日付で「Pivot Join: A runtime operatorfor text search」という名称で出願され、本願譲受人に譲渡された米国仮出願第６０／４７４８７７号に関係がある。たとえば、単調ブール公式は、前述の通り、明示的ではない可能性があるが、単調ブラック・ボックス評価によって示される可能性がある。

ＷＡＮＤしきい値の設定
ユーザが所与の照会について上位ｎ個のスコアリング文書を検索したいと希望すると想定する。このアルゴリズムは、上位ｎ個の結果を追跡するためにサイズｎのヒープを維持する。ＷＡＮＤ反復子のｉｎｉｔ（）関数を呼び出した後、このアルゴリズムは新しい候補文書を検索するためにｎｅｘｔ（）関数を呼び出す。ＷＡＮＤ反復子によって新しい候補が返されると、この文書はシステムのスコアリング・モデルを使用して完全に評価され、その結果、この文書に関する精密なスコアが生成される。このヒープが一杯ではない場合、候補文書はこのヒープに挿入される。このヒープが一杯であって、新しいスコアがヒープ内の最小スコアより大きい場合、新しい文書はヒープ内に挿入され、最小スコアを備えた文書を置換する。

ＷＡＮＤ反復子に渡されるしきい値は、現在ヒープ内にあるすべての文書の最小スコアに基づいて設定される。このしきい値は、候補と見なされる文書であって完全評価ステップに渡される文書について超えなければならない下界を決定することを想起されたい。

初期しきい値は照会タイプに基づいて設定される。たとえば、ＯＲ照会またはフリーテキスト照会の場合、初期しきい値はゼロに設定される。照会用語のうちの少なくとも１つを含むいずれかの文書の近似スコアは、このしきい値を超えるものと思われ、したがって、候補として返されることになるだろう。このヒープが一杯であり、より現実的なしきい値が設定されると、高いスコアをもたらすために十分な数の用語を有する文書のみが完全に評価される。ＡＮＤ照会の場合、初期しきい値はすべての用語上界の合計に設定することができる。すべての照会用語を含む文書のみが、候補文書と見なされるために十分な高さの近似スコアを有することになるだろう。

初期しきい値は、必須用語（「＋」が前に付いているもの）に対処するためにも使用することができる。このような用語の上界は、他のすべての用語の上界の合計よりかなり大きい何らかの巨大な値Ｈに設定することができる。初期しきい値をＨに設定することにより、必須用語を含む文書のみが候補として返されることになる。照会がｋ個の必須用語を含む場合、初期しきい値はｋ・Ｈに設定される。

そのうえ、完全評価のための候補文書の選択の点でより便宜的なものにすることにより評価プロセスを迅速化するために、このしきい値を使用することができる。この場合、しきい値は好ましくはヒープ内の最小スコアより大きい値に設定される。しきい値を増加することにより、アルゴリズムは、近似ステップ中に文書を動的にプルーニングし、したがって、完全に評価する全般的候補文書をより少なくすることができるが、可能性はより高くなる。動的プルーニングの代価はいくつかの高スコアリング文書を見落とす危険性であり、したがって、結果は正確なものであることが保証されない。しかし、多くの場合、これは非常に効果的な技法である可能性がある。たとえば、所与の照会時に費やされる最大時間を左右するシステムは、時間制限を超えそうなときにしきい値を増加することができ、その結果、より大きいスキップを施行して、最終結果リストを作成する可能性が高い文書のみを完全に評価する。実験結果は、動的プルーニングが効率ならびにこの技法を使用する照会評価の有効性にどのように影響を及ぼすかを示している。

用語上界の計算
ＷＡＮＤ反復子では、各照会用語ｔがいずれかの文書スコアに対するその寄与率に関する上界ＵＢ_tに関連付けられることを要求している。文書スコアに関する上界は、その文書が含むすべての用語の上界を合計することによって計算されることを想起されたい。したがって、その用語上界が正確である場合、すなわち、∀t, UB_t > α_tmax_d w(t,d)である場合、ある文書のスコアに関する上界も正確であり、すなわち、その最終スコアより大きくなる。この場合、アルゴリズムがいずれかの段階でのしきい値をこれまでに見られた最小文書スコアに設定すると想定すると、この２レベル・プロセスが正しいランキングおよび正確な文書スコアを返すことが保証される。

単純用語について真の上界を見つけることは簡単なことである。このような用語は、索引に明示的に記憶されるポスティング・リストに直接関連付けられる。上界を見つけるために、まず、その用語のポスティング・リストを詳しく検討し、各項目ごとに、この項目に対応する文書のスコアに対するこの用語の寄与率を計算する。次に、上界はすべてのポスティング要素に関する最大寄与率に設定される。この上界は、その用語のプロパティの１つとして索引に記憶される。

しかし、偽の正のエラーを回避するために、単純用語の場合でも、上界推定に対し特別な注意を払わなければならないということになる。さらに、フレーズまたは近接対などの複合照会用語の場合、用語上界は好ましくは、そのポスティング・リストが照会評価中に動的に作成されてから推定される。

以下の説明では、複合用語に関する上界を推定するための方式だけでなく、単純用語の上界推定のための代替方法について説明する。単純用語の場合、用語ｔに関する上界は、UB_t = C・α_tになるように近似値が取られる。α_tは用語ｉｄｆと照会内の用語頻度によって決定されることを想起されたい。Ｃ＞１は、すべての用語に均一に使用される定数である。この推定では、文書のスコアに対する特定の用語の寄与率に通常影響を及ぼす他の要因を無視する。このような要因としては、文書内の用語頻度、オカレンスのコンテキスト（たとえば、文書タイトル内）、文書の長さなどを含む。

この推定の恩恵はその簡潔さである。その代償は、候補文書の計算した上界がその文書の真のスコアより小さくなる可能性があり、その結果、偽の負のエラーが発生することである。上位スコアリング文書は予備評価ステップに合格しない可能性があり、したがって、完全に評価されないので、このようなエラーの結果、正しくない最終ランキングが得られる可能性がある。しかし、偽の負のエラーは、ヒープが一杯であって、しきい値が高い値に設定された場合にのみ発生する可能性があることに留意されたい。

パラメータＣは、偽の正のエラーと偽の負のエラーとのバランスを取るために、文書の所与の集合について微調整することができる。Ｃが大きくなるほど、予想される偽の正のエラーが多くなり、したがって、システム効率が低下する。Ｃを減少させると、その結果、より多くの偽の負のエラーが生成され、したがって、システムの有効性が低下する。実験データは、システム有効性が損なわれる前にＣを比較的小さい値に設定できることを示している。

複合用語に関する上界の推定
前述の通り、照会用語に関する上界は、その逆文書頻度（ｉｄｆ）に基づいて推定される。単純用語のｉｄｆは、そのポスティング・リストの長さから容易に決定することができる。そのように索引に明示的に記憶されない複合用語のｉｄｆは好ましくは、そのポスティング・リストが照会評価中に動的に作成されてから推定される。次に、２通りのタイプの複合用語のｉｄｆを推定するためのプロシージャについて説明する。このプロシージャは、他のタイプの複合用語に拡張することができる。

フレーズ
フレーズは、通常、引用符で囲まれた照会用語のシーケンス、たとえば、「John Quincy Adams」である。文書は、フレーズ照会に現れるのと同じ順序でフレーズ内のすべての用語を含む場合にのみ、この照会を満足する。動的フレーズ評価をサポートするために、個々の用語のポスティングが文書内の用語のオフセットも含むことに留意されたい。そのうえ、フレーズ評価は、索引にストップワードを記憶することを必要とする。

各フレーズごとに反復子がＷＡＮＤの外部に構築される。ＷＡＮＤの内部では、フレーズは通常、稀なものなので、フレーズは「出現必須（must appear）」用語として扱われ、すなわち、照会フレーズを含む文書のみが検索される。この方法は、そのｉｄｆにかかわらず、その上界を巨大な値Ｈに設定することによって必須用語を処理することに想起されたい。加えて、しきい値もＨに初期設定される。したがって、そのフレーズを含む候補文書のみが詳細な評価ステップに合格することになる。

字句類似性
字句類似性（Lexical affinity：ＬＡ）は、小さいサイズのウィンドウ内で互いにきわめて接近して見つかった用語である。ＬＡ用語のポスティング反復子は、両方のＬＡ用語のポスティング反復子を入力として受け取り、きわめて接近して両方の用語を含む文書のみを返す。ＬＡ（ｔ₁，ｔ₂）の文書頻度を推定するために、ＬＡのポスティング・リストがその個々の用語のポスティング・リストのサブシーケンスであるという事実が利用される。これまでに詳しく検討したその用語の部分ポスティング・リスト内でのＬＡの出現の回数がカウントされ、ポスティング・リスト全体に外挿される。

より具体的には、ＬＡの文書頻度はdf₀(LA) = min(df(t₁),df(t₂))に初期設定され、追加のｋ個の文書を詳しく検討した後で繰り返し更新される。ｐ（ｔ₁）は用語ｔ_iのポスティング・リストであり、ｐ’（ｔ_i）はこれまでに詳しく検討したその部分ポスティング・リストであるとする。＃（ＬＡ｜ｐ’（ｔ_i））はｐ’（ｔ_i）内のＬＡを含む文書の数であるとする。ｔ_iのポスティング・リスト全体でＬＡを含む文書の数は以下の外挿によって推定することができる。

段階ｎにおけるＬＡの文書頻度の更新ルールは以下のようになる。

収束速度は用語ポスティング・リストの長さによって決まる。ＬＡの文書頻度推定は数回程度の反復の後で素早く収束することが分かっている。

結果
以下に示すのは、現在好ましい２レベル照会評価プロセスを評価するために実行された実験から得られた結果の説明である。これらの実験にはＪａｖａ（Ｒ）検索エンジンを使用した。１６９万ページのＨＴＭＬページからなる１０ＧＢのデータを含む文書の集合に索引を付けた。短い照会と長い照会の両方を実現した。この照会は集合内のトピックから構築した。短い照会の構築のためのトピック・タイトル（照会当たり平均２．４６ワード）を使用し、タイトルは長い照会の構築のためのトピック説明（照会当たり平均７．０ワード）と連結した。加えて、結果セットのサイズ（ヒープ・サイズ）を変数として使用した。ヒープが大きくなるほど、結果セットを入手するために必要な評価の数が増加する。

また、独立パラメータＣ、すなわち、文書スコア上界を入手するために照会用語上界の合計に掛ける定数も変化させた。ＷＡＮＤ反復子に渡されるしきい値パラメータと文書のスコア上界とを比較することを想起することができる。その上界が所与のしきい値より大きい場合のみ、文書が完全に評価される。したがって、Ｃはパフォーマンスと精度との兼ね合いを左右し、Ｃが小さいほど、精度の低下という犠牲を払って、完全に評価される文書の数が少なくなり、逆の場合も同様である。実際的な理由で、Ｃを変化させる代わりにＣを特定の値に固定する場合もあり、真のしきい値に掛けるしきい係数Ｆの値を変化させて、ＷＡＮＤ反復子に渡すことができる。係数ＣはＦに反比例し、したがって、Ｆを変化させることはＣを変化させることと等価であり、反対の効果が得られる。すなわち、Ｆの値が大きい場合、その結果、完全評価の数が減少し、精度の損失が予想される。Ｆをゼロに設定すると、ＷＡＮＤに渡されるしきい値はいつでもゼロになり、したがって、照会用語のうちの少なくとも１つを含むすべての文書は候補と見なされ、完全に評価される。Ｆを無限値に設定すると、このアルゴリズムは、ヒープが一杯になるまで（θ＝０である間）文書を完全に評価することになるだけである。その場合、θ・Ｆがすべての照会用語上界の合計より大きくなるので、文書の残りはしきい値を超えない。

しきい係数の値を変化させると、以下のパラメータを測定することができる。（ａ）照会当たりの完全評価の平均数。これは、検索パフォーマンスに影響を及ぼす主要パラメータである。明らかに、完全評価が増えるほど、システムの速度は遅くなる。（ｂ）１０の精度で測定した検索精度（Ｐ＠１０）および平均精度（ＭＡＰ）。（ｃ）偽の負のエラーがまったくない実行（基本実行）から得られた検索結果セットと、負のエラーを伴う実行（切り詰めた実行）から得られた結果セットとの差。完全エバリュエータが一般的であり、これが最終スコアを割り当てるので、文書が両方の実行において同一スコアを受け取ることに留意することができ、このため、基本セットＢおよび切り詰めたセットＰ内の共通文書の相対順序が維持される。したがって、各実行がｋ個の文書を返す場合、切り詰めた実行によって返される最上位ｊ個の文書は、何らかのｊがｋ以下である場合に基本セットに入り、同じ相対順序になることになる。

２つの結果セット間の差は２通りの方法で測定した。まず、以下の公式によって与えられる相対差を使用して、その差を測定した。

第２に、すべての文書が等しく重要であるわけではないので、ＭＲＲ（平均逆数ランク）加重を使用して２つの結果セット間の差を測定した。基本セットＢ内で、その順序内の位置ｉにあるが、切り詰めたセットＰのメンバではない文書は、ＭＲＲ距離に１／ｉを与える。この考え方は、切り詰めたセット内の欠落文書が順序内のその位置に反比例する距離に寄与するということである。ＭＲＲ距離は、セット全体のＭＲＲ重みによって正規化される。したがって、以下のようになる。

有効性および効率
第１の実験では、しきい値パラメータＦの関数として完全評価の数を測定した。Ｆをゼロに設定すると、少なくとも１つの照会用語を含むすべての文書を返す。次に、返された候補文書のセットをすべて完全に評価する。この技法を使用して基本実行を確立したが、その場合、平均して、長い照会当たり３３５５００個の文書を評価し、短い照会当たり１３５０００個の文書を評価することを条件とする。図３２は、長い照会と短い照会について、ヒープ・サイズが１００および１０００の場合のしきい係数Ｆの関数として完全評価の数を示している。図３２は、すべての実行について、Ｆが増加するにつれて、評価の数が必要な文書の数（ヒープ・サイズ）に素早く収束することを示している。そのうえ、Ｆの関数としての平均照会時間を測定し、これが完全評価の数に高度に相関することを示した（すべての実行について相関は０．９８より高い）。たとえば、長い照会で、ヒープ・サイズが１００で、Ｆ＝０の場合、基本実行の照会当たりの平均時間は８．４１秒である。この時間は、Ｆ値が大きい場合に０．４秒まで減少する。基本実行はプルーニングがまったく行われていない極端なケースであることに留意されたい。しきい値は実際には、何らかの負のエラーが発生する前に高い値に設定することができる。これらの実験に基づいて、しきい値が約０．８である場合、その結果、完全評価の数が大幅に切り詰められ、結果リストに対する影響はまったくないことが分かる。

図３３は、ＭＲＲ距離測定によって測定したのと同じ実行について、切り詰めた結果と基本結果との差を示している。Ｆの値が小さい場合、偽の負のエラーはまったくないので、その距離はゼロになる。Ｆを増加すると、偽の負のエラーの数が増加し、そのため、距離が増加する。

図３４は、ヒープ・サイズが１０００である短い照会および長い照会についてＰ＠１０およびＭＡＰによって測定したのと同じ実行の精度を示している。プルーニングが増すにつれて（予想通り）ＭＡＰが減少するが、Ｐ＠１０は、非常に大幅なプルーニングの後でのみ、短い照会について適度に減少する。長い照会の場合、Ｐ＠１０の変化は取るに足らないものである。たとえば、Ｆ＝６．０である場合、完全評価の数が１７００未満であり（初めにヒープを満たすために必要な１０００回の評価よりわずか７００回だけ多い）、ＭＲＲが約０．５である間、長い照会と短い照会のいずれについてもＰ＠１０はまったく影響を受けない。

積極的なプルーニングの場合でも上位結果セット内の精度が高い理由は、高いしきい値によって本質的にＷＡＮＤ関数がＡＮＤのようになり、すべての照会用語を含む文書のみを返すことによって説明される。その場合、これらの文書は完全に評価され、高いスコアを受け取る可能性が最も高い。スコアは２レベル・プロセスの影響を受けず、これらの文書はまったく関連のあるものであり、いずれの場合も高いスコアを受け取るので、Ｐ＠１０は影響を受けない。これに対して、同じく再呼出しを考慮に入れるＭＡＰは、多くのミスにより有害な影響を受ける。

したがって、すべての照会用語を含む文書のみを明示的に評価することにより、システムは上位結果セットにおいて高精度を達成できると想定することができる。すべての照会用語上界の合計に等しいしきい値をそれに渡すことにより、このような文書のみを返すよう、ＷＡＮＤに容易に指示することができる（便宜上、ＡｌｌＴｅｒｍｓプロシージャという）。この手法はＰ＠１０に関して真価を示すが、多くの照会について考慮される文書が少なすぎるので、再呼出しおよびしたがってＭＡＰが減少する。修正した戦略（ＴｗｏＰａｓｓプロシージャという）は、第１の「積極的な」パスが十分な数の結果を返さない場合、用語ポスティングに関して第２のパスの使用を可能にする。具体的には、しきい値はまず、すべての用語上界の合計に設定され、累積文書の数が必要な結果の数より少ない場合、しきい値は文書のコーパス内で少なくとも１回発現するすべての照会用語の最大上界まで削減されて、それに設定され、評価プロセスが再呼出しされる。

表１は、ＡｌｌＴｅｒｍｓおよびＴｗｏＰａｓｓの実行と比較して、いくつかの異なるしきい係数を使用するＷＡＮＤの結果を示している。Ｆ＝０の場合、ＷＡＮＤは照会用語のうちの少なくとも１つを含むすべての文書を返す。この実行の場合、偽の負のエラーはまったくないので、精度は最大になる。Ｆ＝１．０の場合、完全評価の数は、長い照会については２０だけ、短い照会については１０だけ減少し、依然としていかなる偽の負のエラーもなく、そのため、精度の低下もまったくない。Ｆ＝２．０の場合、評価の数は、精度の低下という犠牲を払って４だけさらに減少する。

ＡｌｌＴｅｒｍｓは短い照会と長い照会のいずれについてもＷＡＮＤに比較して大幅にＰ＠１０を改善するが、ＭＡＰは大幅に低下することが分かる。上位結果の精度のみに関心があるシステムの場合、再呼出しを無視すると、ＡｌｌＴｅｒｍｓ戦略は合理的かつ効果的な選択である。ＴｗｏＰａｓｓの実行は、Ｐ＠１０およびＭＡＰのいずれについても著しい結果を達成する。第２のパスについては実行時間の点でわずかな犠牲が発生するが、用語ポスティングは依然として第１のパスからメイン・メモリにキャッシュされる可能性が高いので、ほとんど場合、その犠牲は取るに足らないものである。いずれの場合も、このような結果は、この方法全般および特にＷＡＮＤ反復子の多様性およびフレキシビリティを立証する。しきい値を変化させることにより、この演算子の「強さ」はＯＲからＡＮＤへ制御することができる。

上記の記述は、一度に１つの文書の手法と、第１段階のプルーニングにＷＡＮＤ演算子を使用する２レベル照会評価方法とを使用して、効率の実質的な増加をもたらすことができ、精度および再呼出しの損失がまったくないことを実証している。さらに、ある程度のわずかな精度の損失を許容できる場合、この増加はさらに増すことができる。

上記のように、好ましくは文書内の用語のオカレンスに関して少なくとも１つの反復子が設けられ、好ましくはどの文書が特定のプロパティを満足するかを示すための少なくとも１つの反復子が存在する。ＷＡＮＤは、ブール述部Ｘ＿１、Ｘ＿２、・・・をそれぞれ満足する文書について少なくとも１つの反復子を使用し、ＷＡＮＤ演算子は、どの文書がＷＡＮＤ述部を満足するかを示すための反復子を作成する。

ＷＡＮＤ演算子は、ＷＡＮＤ述部を満足しないことがまだ分かっていない第１の可能な文書を表現する現行文書変数を維持し、ＷＡＮＤ述部が現行文書変数で満足されない場合に複数の反復子のうちのどの反復子を進めるかを示すために何らかのプロシージャを使用することができる。

ＶＩ．例示的な実施形態および考慮事項
図３５〜３７はＵＩＭＡ１００の例示的な一実施形態の例証を示しており、薬品発見のための生命科学アプリケーション１７０に関連して示されている。この非制限的な例では、それによってＵＩＭＡ１００が動作可能な多くのコンポーネントおよびインターフェースのうちの一部を示している。

例示した実施形態には、アプリケーション１７０に固有のリソース（たとえば、ＭＥＤＬＩＮＥ、ＵＭＬＳ、バイオメディカル・データ／テストベッド）を含む言語リソース３２００コンポーネントが存在する。複数のアプリケーション・サポート・コンポーネント３２２０と同様に、様々な関連ローダ・ユーティリティ３２１０も設けられている。

ＵＩＭＡ１００は、コア・テキスト分析アノテータおよび後処理アナライザ・アノテータ２２０を含むように備えがなされ、それらのうちの一部は、ＭＥＤＴＡＫＭＩセマンティック・アナライザおよびバイオリレーション・アナライザなどの例示的な生命科学アプリケーション１７０に固有のものである。このコア・テキスト分析機能は、ＪＴａｌｅｎｔテキスト・アナライザＴＡＥ１３０を使って作業する。テキスト・データ・ストア１２０は、ＤＢ２（ＴＭ）と、ＤＢ２（ＴＭ）ローダおよびアクセス・モジュールによって実現することができる。テキスト検索エンジン１１０は、Ｊａｖａ（Ｒ）で書かれたフルテキスト検索ライブラリであるＪＵＲＵに基づくものにすることができる。

図３５〜３７を考慮すると理解できるように、諸問題を解決する（またはアプリケーションを構築する）ためにコンポーネントをどのように調整するかは、ＵＩＭＡ１００の重要な一態様である。１組のコンポーネントを定義することに加え、ＵＩＭＡ１００は好ましくは、効果的なアプリケーションを構築するためにこれらのコンポーネントについて可能な統合を決定する１組の制約を含む。

文書ストア１２０は、文書および文書メタデータをディスク上に記憶して管理できるようにするインターフェースを備えたコンポーネントと見なすことができる。たとえば、一実施形態では、回復性またはＴＡＥ結果への後処理アクセスのために、ＴＡＥ１３０が文書メタデータをストア１２０に書き込むべきかどうかの判定をメイン・アプリケーション・ロジックが担当することを指図する制約はアーキテクチャ上の制御制約である。とりわけ、アプリケーションの全体的なパフォーマンスに対する影響は相当なものになる可能性があるので、この制約は、ＴＡＥ１３０がアプリケーションの知らぬ間にデータをストアに書き込むことを任意に決定しないことを保証するためのものである。ＵＩＭＡ１００は、そのアプリケーションの全体的な動作要件（たとえば、パフォーマンスと回復性との兼ね合い）に関してアプリケーション開発者が最もよく知らされ、したがって、それを制御しなければならないことを示唆する。次にこれにより、ＴＡＥ１３０がその中間結果をストア１２０に書き込むというその要件をアプリケーション１７０が通信できるようにするために、ＴＡＥのインターフェースを拡張することが必要になる可能性がある。

他の実施形態では、注釈（アノテータまたはＴＡＥ）シーケンスを自動的に生成するためのソフトウェア・コンポーネントおよびユーザ要件をモデル化することができる。この手法は、コンポーネントのインターフェースレベルの詳細を知ることからユーザを絶縁し、アプリケーションの機能性要件のみに集中する可能性がある。そのうえ、自動順序付けは、既存のコンポーネントから新しいアプリケーションを費用効果的に構築する方法を決定する際にユーザを支援することができ、さらに、すでに構築したアプリケーションを維持する際に援助することもできる。

自動順序付けは、実行中の注釈フローの制御およびリカバリにおいて何らかの役割を有する。具体的には、フロー実行プログラムは、障害に関する詳細を備えたシーケンサを要請し、依然として新しい不測の状況においてフローを完了することができる代替シーケンスを要求することができる。再順序付けにより、アプリケーションは、ＵＩＭの分散配備の急変であるランタイム・エラーにとって透過的なものになることができる。

コンポーネント間通信方法の選択の基礎となる関心事の一部は、フレキシビリティ、パフォーマンス、スケーラビリティ、規格の準拠である。したがって、その技術インターフェースの説明の一部として、ＵＩＭＡ１００は好ましくはコンポーネントの対話のための通信方法を識別する。ＵＩＭＡ１００は、このアーキテクチャの様々な部分で必要な既存の分散コンピューティング技術のアプリケーションを活用することになる予定である。

一般に、ＵＩＭＡ１００は、複数のコンポーネントが別々のマシン上の別個のアドレス空間内および種々の動作環境に存在し、サービス指向方法を介して通信することができる疎結合（すなわち、分散）アーキテクチャをサポートする。この手法は、フレキシビリティおよびスケーラビリティのために好ましいものである。しかし、密結合アーキテクチャも本発明の範囲内で適切なものであり、ＵＩＭＡ１００は密結合システム・アーキテクチャ・モデルもサポートする。

たとえば、様々なコンポーネントは、高レベルのパフォーマンスを保証するために密結合通信を必要とする可能性がある。一例はＴＡＥ１３０であり、その場合、アノテータ２２０は通常、文書ストリームを処理するときに直列で機能する。

分析構造は、ＴＡＥ１３０の動作の間中、頻繁にアクセスされ更新される。次のアノテータへの高速アクセス、更新、および伝送は、高速応答時間を必要とする埋込みテキスト分析アプリケーションの場合またはユーザが結果を待っている照会時間に分析が行われる場合、特に重大なものになるだろう。このような条件では、高く予測可能なパフォーマンス・レベルを達成するために、メモリ内分析構造によるアノテータ２２０間の密結合通信を使用することができる。

疎結合システムに関するもう１つの考慮事項は開発パラダイムである。この場合も、それぞれが独自に進化し、それぞれが分析構造に関して固有の前提条件を備えた多くのアノテータ２２０を含む可能性のあるＴＡＥ１３０について検討する。理想的には、ＵＩＭＡ１００は、開発者がコンポーネント通信方法とは無関係に作業し、必須の開発または配備環境に対して理想的に適した種々のコンテナ内にアノテータを配置することができるようなアノテータ２２０の開発をサポートする。

ＵＩＭＡ１００のコンポーネントが疎結合変形で通信するかまたは密結合変形で通信するかにかかわらず、その制御独立性は別個かつ重要な問題である。理想的には、ＵＩＭＡインターフェースは、コンポーネント・ロジックが外部制御パターンに基づくことを禁止するものでなければならない。この主義の含意は、非同期制御環境で障害なしに動作するようにコンポーネントが作成されることである。ＵＩＭＡは、それが埋め込まれる可能性のあるアプリケーション１７０の特定のフローにかかわらず動作しなければならない。

他の表現をすると、ＵＩＭＡ１００は好ましくはデータ主導型である。コンポーネントは、入力データが所与の前提条件を満足しないという理由で入力を処理し損なう可能性があるが、そのコンポーネントは特定のプロセス・フローに依存してはならない。また、データ主導の焦点により一般に、ＵＩＭＡ１００の実現のための高度に分散されたエージェントベースの手法も可能になる。

上記の説明に基づいて、ＵＩＭＡ１００は、少なくとも１つの文書ストア１２０に結合された少なくとも１つの文書ストア・インターフェース１２５を含むアプリケーション・インターフェースを含むモジュラ・テキスト・インテリジェンス・システムを提供することが分かる。文書ストア・インターフェース１２５は、少なくとも１つのデータベース指定と、少なくとも１つのデータ・ソースを受け取り、少なくとも１つのデータベース照会コマンドを提供する。ＵＩＭＡ１００は、少なくとも１つのテキスト分析エンジン１３０に結合された少なくとも１つの分析エンジン・インターフェース１３５をさらに提供する。分析エンジン・インターフェース１３５は、少なくとも１つの文書セットの少なくとも１つの文書セット指定を受け取り、テキスト分析エンジンの分析結果を提供する。アプリケーション・インターフェースにより、アプリケーション１７０は、少なくとも１つの文書ストア１２０にデータを取り込む方法を指定し、少なくとも１つの文書セットを選択するため、ならびに少なくとも１つのテキスト分析エンジン１３０による選択した文書セットの処理を指定するためのアプリケーション・ロジックを指定する。また、少なくとも１つのユーザ・インターフェースだけでなく、分析結果の処理も指定される。アプリケーション指定は、少なくとも１つのテキスト分析エンジンによる使用のための共通抽象データ・フォーマットの指定を含む少なくとも１つのパラメータを設定することによって行われる。また、少なくとも１つの検索エンジン１１０の少なくとも１つの検索エンジンＩＤおよび少なくとも１つの検索エンジン指定を受け取るための少なくとも１つの検索エンジン・インターフェース１１５も含まれている。検索エンジン・インターフェース１１５は、少なくとも１つの検索エンジン照会結果をさらに受け取る。

当業者は、本明細書の教示が例証にすぎず、したがって、本発明を制限するものと見なすべきではないことを認識することになる。すなわち、前述の通り、ＵＩＭＡ１００は様々な情報ソースとともに使用することができ、その多くについてはここで説明しない。たとえば、文書は静的または動的いずれかのテキストとイメージをともに含むことができ、アノテータはテキストとイメージ・データの両方に備えることができる。

したがって、上記の説明は、例示的かつ非制限的な例として、本発明を実施するために本発明者が現在企図している最良の方法および装置に関する完全かつ有益な説明を提供していることが分かるはずである。しかし、様々な修正および適応は、添付図面および特許請求の範囲に関連して読んだときに、上記の説明を考慮して関連技術の当業者には明白になる可能性がある。しかし、本発明の教示のこのような修正はいずれも、依然として本発明の範囲内にあるだろう。さらに、本明細書に記載した方法および装置には所与の程度の特異性が設けられているが、本発明は、ユーザの要求に応じて、それ以上またはそれ以下の特異性でも実現することができるだろう。さらに、本発明の特徴の一部は、それに対応して他の特徴を使用せずに有利に使用することができるだろう。このため、本発明は特許請求の範囲によって定義されるので、上記の説明は、本発明の制限ではなく、本発明の原理の例証にすぎないものと見なすべきである。

本明細書に開示されている非構造化情報管理システムのアーキテクチャの概要を提示するブロック図である。 プリミティブ分析エンジンの諸態様を提示するブロック図である。 アグリゲート分析エンジンの諸態様を提示するブロック図である。 共通分析システム（ＣＡＳ）内のワークフローの一例を示す流れ図であり、テキスト分析エンジンの一部を形成する複数の直列に結合したアノテータの一例として見ることもできる図である。 結合されたアノテータの代替実施形態の一例を示す図であり、少なくとも２つの並列アノテータ経路が存在する図である。 例示的なタイプ定義の表である。 例示的なフィーチャ定義の表である。 例示的なコンポーネント・リストを示す表である。 ワークフロー生成を示す流れ図である。 ワークフロー検証を示す流れ図である。 単一継承ツリー内の関係の一例を示す図である。 多重継承を使用するデータ・モデリング例を示す図である。 共通分析システムの諸態様の概要を提供するブロック図である。 テキスト分析エンジンの追加の関係を示すブロック図である。 例示的な注釈構造の図解描写である。 アノテータの動作を示すブロック図である。 トークンとスパンとの関係を示すブロック図であり、逆ファイル・システムの一例を示す図である。 スパン・オカレンスの代替表現を提供するブロック図である。 前処理段階のスパンとの関係を例示する図である。 テキスト内の関係を発見するための前処理を記述する流れ図である。 注釈索引と、関係索引と、スパンと、引き数との関係の諸態様を提示するブロック図である。 ある文書の代替表現のビューとそれに対応するトークン化の一例を提示するブロック図である。 ある文書の種々のトークン化による複数のビューの導出を示す図である。 ビューを使用する検索の諸態様を示す関係図である。 データ・モデルの諸態様を示す関係図である。 コンポーネント間のインターフェースの諸態様を示すブロック図である。 前処理およびランタイムの諸態様を提供するブロック図である。 パターンとしきい重みとの関係を示す流れ図である。 ＷＡＮＤ反復子のｉｎｉｔ（）メソッド用の疑似コードの一例を示す図である。 ＷＡＮＤ反復子のｎｅｘｔ（）メソッド用の疑似コードの一例を示す図である。 ＷＡＮＤプロセスの流れを要約する流れ図である。 ＷＡＮＤプロセスに関する効率結果を示すグラフである。 ＷＡＮＤプロセスに関する効率結果を示すグラフである。 ＷＡＮＤプロセスに関する効率結果を示すグラフである。 生命科学アプリケーションに関連して非構造化情報管理システムを示すブロック図である。 生命科学アプリケーションに関連して非構造化情報管理システムを示すブロック図である。 共通分析システム（ＣＡＳ）の動作を説明するために有用なデータを作成するための例示的な疑似コードを示す図である。 共通分析システム（ＣＡＳ）の動作を説明するために有用なデータを作成するための例示的な疑似コードを示す図である。 ＣＡＳベースのデータ・アクセス用の疑似コードの一例を示す図であり、トークンに関する反復の使用を示す図である。 文書テキストのｎグラム（トリグラム）トークン化の一例を示す図である。

符号の説明

１００ 非構造化情報管理アーキテクチャ
１１０ セマンティック検索エンジン
１２０ 文書／集合／メタデータ・ストア
１３０ テキスト分析エンジン（ＴＡＥ）
１４０ 構造化知識ソース・アダプタ
１５０ 集合処理マネージャ（ＣＰＭ）
１６０ 集合分析エンジン
１７０ アプリケーション・ロジック
１８０ 構造化情報
１９０ 文書の集合（非構造化情報）
１９０Ａ 文書
１９５ 関連知識

Claims (32)

1. 記憶データを処理するためのデータ処理システムにおいて、
   データ単位の集合を記憶するためのデータ記憶域と、
   前記データ記憶域に結合され、前記データ記憶域からの少なくとも１つのデータ単位を検索するための照会に応答する検索エンジンとを含み、
   前記照会がそれぞれが関連重み値を有する複数の検索部分式からなる検索演算子を含み、前記検索エンジンがしきい重み値合計を超える重み値合計を有するデータ単位を返す、データ処理システム。
2. 前記データ単位が文書である、請求項１に記載のデータ処理システム。
3. 前記重み値およびしきい重み値のうちの少なくとも１つが検索中に可変である、請求項１に記載のデータ処理システム。
4. 前記検索演算子が加重ＡＮＤ関数を含み、前記しきい重み値を変化させることにより、前記加重ＡＮＤ関数の演算が実質的な論理ＯＲ関数から実質的な論理ＡＮＤ関数に変化する、請求項１に記載のデータ処理システム。
5. 前記データ処理システムが、文書データのトークン化から導出された注釈と、それぞれの注釈のオカレンスを含むリストと、それぞれの注釈のリストされた各オカレンスごとに、前記それぞれの注釈が及ぶ複数のトークン位置を含むセットとを記憶するための逆ファイル・システムを含む、請求項２に記載のデータ処理システム。
6. 記憶文書データを処理するためのデータ処理システムにおいて、
   文書データの集合を記憶するためのデータ記憶域と、
   前記データ記憶域に結合され、前記データ記憶域からの少なくとも１つの文書を検索するための照会に応答する検索エンジンとを含み、
   前記照会が加重ＡＮＤ（ＷＡＮＤ）として機能するブール述部を含み、前記ＷＡＮＤが、引き数として、ブール変数Ｘ₁、Ｘ₂、・・・、Ｘ_kのリストと、関連する正の重みｗ₁、ｗ₂、・・・、ｗ_kのリストと、しきい値θとを取り、
   

   

   である場合に、
   

   

   が真になる（式中、ｘ_iはＸ_iの標識変数であり、Ｘ_iが真であればｘ_i＝１であり、そうでなければｘ_i＝０である）、データ処理システム。
7. 前記ＷＡＮＤが、
   

   

   および
   

   

   を介して（ＡＮＤ）関数または（ＯＲ）関数のうちの１つを実現するために使用される、請求項６に記載のデータ処理システム。
8. ｘ_ｉが任意の単調増加関数となって前記しきい値より大きくなることを要求することにより、前記ＷＡＮＤが一般化される、請求項７に記載のデータ処理システム。
9. 任意の単調ブール公式が真になることを要求することにより、前記ＷＡＮＤが一般化される、請求項７に記載のデータ処理システム。
10. しきい重みをｗ０、ＷＡＮＤへの引き数となるパターンをｐａｔ＿ｉとするとき、ＷＡＮＤ（ｗ０，ｐａｔ１，ｗ１，ｐａｔ２，ｗ２，．．．）を含む照会が、一致したパターンｐａｔ１、ｐａｔ２、・・・に関する重みの合計がｗ０より大きくなるように、ｐａｔ１、ｐａｔ２、・・・に十分一致する少なくとも１つの文書を返す、請求項６に記載のデータ処理システム。
11. 照会に含まれる各用語が、以下のように、いずれかの文書スコアに対するその最大寄与率の上界ＵＢ_tに関連付けられ、
    

    

    ある文書内に現れるすべての照会用語の前記上界を合計して、前記文書の照会依存スコアの上界を以下のように決定し、
    

    

    
    予備スコアリングが各文書ｄごとに以下のような評価を伴う（ただし、Ｘ_iは文書ｄ内の照会用語ｉの存在に関する標識変数であり、前記しきい値θはそれまでに前記検索エンジンによって見つかった上位ｎ個の結果のうちの最小スコアｍに基づいて演算中に変更され、ｎは要求した文書の数である）、
    

    

    請求項６に記載のデータ処理システム。
12. 前記単調ブール公式が明示的に示されないが、ブラック・ボックス計算によって示される、請求項９に記載のデータ処理システム。
13. 前記ｐａｔ＿ｉが前記文書のコンテンツの任意のブール関数を表現し、返された文書は、関数ｐａｔ１、ｐａｔ２、・・・に関する重みの合計がｗ０より大きくなるように、ｐａｔ１、ｐａｔ２、・・・を十分満足する、請求項１０に記載のデータ処理システム。
14. 前記データ記憶域内の前記文書が、前記データ記憶域内の前記文書の特定の順序付けに関して逆ファイルとして表現される、請求項６に記載のデータ処理システム。
15. 文書内の用語のオカレンスに関する少なくとも１つの反復子をさらに含む、請求項６に記載のデータ処理システム。
16. どの文書が特定のプロパティを満足するかを示すための少なくとも１つの反復子をさらに含む、請求項６に記載のデータ処理システム。
17. 前記ＷＡＮＤが、前記ブール述部Ｘ＿１、Ｘ＿２、・・・をそれぞれ満足する文書について少なくとも１つの反復子を使用し、ＷＡＮＤ演算子が、どの文書が前記ＷＡＮＤ述部を満足するかを示すための反復子を作成する、請求項６に記載のデータ処理システム。
18. 前記ＷＡＮＤ演算子が、前記ＷＡＮＤ述部を満足しないことがまだ分かっていない第１の可能な文書を表現する現行文書変数を維持し、前記ＷＡＮＤ述部が現行文書変数で満足されない場合に複数の反復子のうちのどの反復子を進めるかをプロシージャが示す、請求項１７に記載のデータ処理システム。
19. コンピュータ可読媒体上で実施され、少なくとも１つのアプリケーションと協力してテキスト・インテリジェンス・システムの動作を指示するためのプログラム・コードを含むコンピュータ・プログラム記録媒体において、
    データ単位の集合を記憶するためのコンピュータ・プログラム・セグメントと、
    少なくとも１つの記憶データ単位を検索するための照会に応答する検索エンジンを実現するコンピュータ・プログラム・セグメントとを含み、
    前記照会がそれぞれが関連重み値を有する複数の検索部分式からなる検索演算子を含み、前記検索エンジンがしきい重み値合計を超える重み値合計を有するデータ単位を返す、コンピュータ・プログラム記録媒体。
20. 前記データ単位が文書である、請求項１９に記載のコンピュータ・プログラム記録媒体。
21. 前記重み値およびしきい重み値のうちの少なくとも１つが検索中に可変である、請求項１９に記載のコンピュータ・プログラム記録媒体。
22. 前記検索演算子が加重ＡＮＤ関数を含み、前記しきい重み値を変化させることにより、前記加重ＡＮＤ関数の演算が実質的な論理ＯＲ関数から実質的な論理ＡＮＤ関数に変化する、請求項１９に記載のコンピュータ・プログラム記録媒体。
23. 文書データのトークン化から導出された注釈と、それぞれの注釈のオカレンスを含むリストと、それぞれの注釈のリストされた各オカレンスごとに、前記それぞれの注釈が及ぶ複数のトークン位置を含むセットとを記憶するための逆ファイル・システムを実現するためのコンピュータ・プログラム・セグメントをさらに含む、請求項１９に記載のコンピュータ・プログラム記録媒体。
24. 前記照会が加重ＡＮＤ（ＷＡＮＤ）として機能するブール述部を含み、前記ＷＡＮＤが、引き数として、ブール変数Ｘ₁、Ｘ₂、・・・、Ｘ_kのリストと、関連する正の重みｗ₁、ｗ₂、・・・、ｗ_kのリストと、しきい値θとを取り、
    

    

    である場合に、
    

    

    が真になる（ただし、ｘ_iはＸ_iの標識変数であり、Ｘ_iが真であればｘ_i＝１であり、そうでなければｘ_i＝０である）、請求項１９に記載のコンピュータ・プログラム記録媒体。
25. 前記ＷＡＮＤが、
    

    

    および
    

    

    を介して（ＡＮＤ）関数または（ＯＲ）関数のうちの１つを実現するために使用される、請求項２４に記載のコンピュータ・プログラム記録媒体。
26. ｘ_ｉが任意の単調増加関数が前記しきい値より大きくなることを要求することにより、前記ＷＡＮＤが一般化される、請求項２４に記載のコンピュータ・プログラム記録媒体。
27. 任意の単調ブール公式が真になることを要求することにより、前記ＷＡＮＤが一般化される、請求項２４に記載のコンピュータ・プログラム記録媒体。
28. しきい重みをｗ０、ＷＡＮＤへの引き数となるパターンをｐａｔ＿ｉとするとき、ＷＡＮＤ（ｗ０，ｐａｔ１，ｗ１，ｐａｔ２，ｗ２，．．．）を含む照会が、一致したパターンｐａｔ１、ｐａｔ２、・・・に関する重みの合計がｗ０より大きくなるように、ｐａｔ１、ｐａｔ２、・・・に十分一致する少なくとも１つの文書データ単位を返す、請求項２４に記載のコンピュータ・プログラム記録媒体。
29. 前記ｐａｔ＿ｉが前記文書のコンテンツの任意のブール関数を表現し、返された文書データ単位は、関数ｐａｔ１、ｐａｔ２、・・・に関する重みの合計がｗ０より大きくなるように、ｐａｔ１、ｐａｔ２、・・・を十分満足する、請求項２８に記載のコンピュータ・プログラム記録媒体。
30. 照会に含まれる各用語が、以下のように、いずれかの文書データ単位のスコアに対するその最大寄与率の上界ＵＢ_tに関連付けられており、
    

    

    ある文書データ単位内に現れるすべての照会用語の前記上界を合計して、前記文書の照会依存スコアの上界を以下のように決定し、
    

    

    
    予備スコアリングが各文書ｄごとに以下のような評価を伴う（ただし、Ｘ_iは文書データ単位ｄ内の照会用語ｉの存在に関する標識変数であり、前記しきい値θはそれまでに前記検索エンジンによって見つかった上位ｎ個の結果のうちの最小スコアｍに基づいて演算中に変更され、ｎは要求した文書の数である）、
    

    

    請求項２４に記載のコンピュータ・プログラム記録媒体。
31. 文書データを処理するための方法において、
    照会を受け取るステップと、
    データ記憶域から少なくとも１つの文書を検索するために前記照会に応答するステップとを含み、
    前記照会が加重ＡＮＤ（ＷＡＮＤ）として機能するブール述部を含み、前記ＷＡＮＤが、引き数として、ブール変数Ｘ₁、Ｘ₂、・・・、Ｘ_kのリストと、関連する正の重みｗ₁、ｗ₂、・・・、ｗ_kのリストと、しきい値θとを取り、
    

    

    である場合に、
    

    

    が真になる（ただし、ｘ_iはＸ_iの標識変数であり、Ｘ_iが真であればｘ_i＝１であり、そうでなければｘ_i＝０である）、方法。
32. 前記ＷＡＮＤが、
    

    

    および
    

    

    を介して（ＡＮＤ）関数または（ＯＲ）関数のうちの１つを実現するために使用される、請求項３１に記載の方法。

Images