JP5937601B2 - 動的構造化文書コーパスの構造化探索 - Google Patents

Description

種々の技法が、スピーチから構造化文書を生成するために存在する。こうした技法の例は、「Ａｕｔｏｍａｔｅｄ Ｅｘｔｒａｃｔｉｏｎ ｏｆ Ｓｅｍａｎｔｉｃ Ｃｏｎｔｅｎｔ ａｎｄ Ｇｅｎｅｒａｔｉｏｎ ｏｆ ａ Ｓｔｒｕｃｔｕｒｅｄ Ｄｏｃｕｍｅｎｔ Ｆｒｏｍ Ｓｐｅｅｃｈ」という名称の２００９年９月１日に発行された米国特許第７，５８４，１０３号、および、「Ｖｅｒｉｆｉｃａｔｉｏｎ ｏｆ Ｅｘｔｒａｃｔｅｄ Ｄａｔａ」という名称の２０１０年５月１１日に発行された米国特許第７，７１６，０４０号に開示され、これらの特許は共に、ペンシルベニア州ピッツバーグのＭｕｌｔｉｍｏｄａｌ Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．に譲渡されている。同様に、Ｍｕｌｔｉｍｏｄａｌ Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．から入手可能な製品ＡｎｙＭｏｄａｌＣＤＳ Ｓｐｅｅｃｈ Ｕｎｄｅｒｓｔａｎｄｉｎｇは、スピーチから構造化文書を生成するために使用されることができる。

たとえば、医師が患者訪問の報告書を口述する場合、医師のスピーチは、単に口述される報告書の逐語的トランスクリプトにトランスクライブされるのではなく、代わりに、トランスクライブされるスピーチを表すテキストが、その中でスピーチによって表される概念に対応するセクション、サブセクション、パラグラフ、および他の構造に編成される構造化文書にトランスクライブされることができる。こうした概念は、たとえば、ＨＬ７ ＣＤＡ文書フォーマットまたは他のフォーマットによって定義されるようなＸＭＬタグを使用してテキストをマークアップすることによって構造化文書で表されることができる。

セクション、サブセクション、および他の概念は、「ＣｕｒｒｅｎｔＭｅｄｉｃａｔｉｏｎ（カレントメディケーション）」、「Ｆｉｎｄｉｎｇｓ（所見）」、および「Ｄｉｓｃｈａｒｇｅ Ｉｎｓｔｒｕｃｔｉｏｎｓ（退院指導）」などの概念の語義的分類（ｓｅｍａｎｔｉｃ ｃｌａｓｓ）を示すコードを使用して、文書内でアノテートされることができる。さらに、トランスクライブされるテキストは、テキストで述べられるメディケーションについての「ＲｘＮｏｒｍ」コード、患者の問題を記述するｐｏｓｔ−ｃｏｏｒｄｉｎａｔｅｄ ＳＮＯＭＥＤ ＣＴ用語、またはアレルギー（ａｌｌｅｒｇｙ）に関連するアレルゲン（ａｌｌｅｒｇｅｎ）、重篤度（ｓｅｖｅｒｉｔｙ）、および有害反応（ａｄｖｅｒｓｅ ｒｅａｃｔｉｏｎ）に関する情報を使用してアレルギーを記述する複雑なデータ構造などの、テキストの意味をコンピューヤ処理可能形態で表すコードによってアノテートされることができる。

さらに、構造化文書は、文書（「Ｄｉｓｃｈａｒｇｅ Ｓｕｍｍａｒｙ（退院サマリー）」または「Ｐｒｏｇｒｅｓｓ Ｎｏｔｅ（進行メモ）」など）およびコンテキスト情報（たとえば、文書の対象である患者に関する情報、文書を口述した内科医に関する情報）のタイプを示すヘッダ情報でアノテートされることができる。

スピーチから構造化文書を生成するためのこれらのまた他の技法は、先に参照した２つの米国特許第７，５８４，１０３号および第７，７１６，０４０号に、より詳細に記載される。先に示したように、こうした構造化文書は、テキストおよびテキストに関連するコーディング（ＸＭＬタグなど）を含む。コーディングは、対応するテキストによって表される概念を、コンピュータ処理可能形態でエンコードする。

関連情報をできる限り迅速に、容易に、また正確に見出すようにこうした構造化文書を探索できることが望ましい。

こうした探索を実施するためのいくつかの技法が存在するが、構造化文書を、特にこうした構造化文書が経時的に増大し変化する構造化文書の動的コーパスの一部であるときに、探索するための改良型技法についての必要性が存在する。

システムは、テキストとテキストのアノテーションの両方を含む構造化文書を含む文書コーパスを含む。システムはまた、構造化文書の構造化探索を実施するように適合されている探索エンジンを含む。新しいタイプのアノテーションがシステムに追加されると、探索エンジンは、新しいタイプのアノテーションについての構造化探索を実施することが可能になるように自動的に更新される。たとえば、新しいタイプのアノテーションを生成するように適合された新しい自然言語処理（ＮＬＰ）コンポーネントがシステムに追加される場合、システムは、新しいタイプのアノテーションの定義を含むようにクエリ言語を自動的に更新する。探索エンジンは、その後すぐに、新しいタイプのアノテーションを参照する構造化クエリを処理することが可能であるとすることができる。

本発明の一実施形態による文書コーパス内で構造化文書の構造化探索を実施するためのシステムのデータフロー図を示す。 図１のシステムを生成するプロセスの中間ステップを示すデータフロー図を示す。 図１のシステムを生成するプロセスの中間ステップを示すデータフロー図を示す。 図１のシステムを生成するプロセスの中間ステップを示すデータフロー図を示す。 図１のシステムを生成するプロセスの中間ステップを示すデータフロー図を示す。 文書コーパス内で文書内の新しいタイプのアノテーションについての構造化探索を実施することが可能になるように自動的に適合するために、図１および図２Ａ〜２Ｄのシステムによって実施される方法のフローチャートである。

本発明のいくつかの実施形態によって実施される１つの機能は、構造化文書に関して構造化探索を実行することである。上述したように、「Ｓｔｒｕｃｔｕｒｅｄ ｄｏｃｕｍｅｎｔ（構造化文書）」は、テキストおよび／または他のコンテキストが、コーディングによってアノテートされた文書であり、コーディングは、コーディングに対応するコンテキストの（語義的なおよび／または文法的な）意味を示す。

「ｓｔｒｕｃｔｕｒｅｄ ｓｅａｒｃｈ（構造化探索）」は、文書構造に対して特定の参照を行うクエリを実行する探索である。こうしたクエリは、「ｓｔｒｕｃｔｕｒｅｄ ｑｕｅｒｙ（構造化クエリ）」である。たとえば、特定の構造化文書コーパス内の構造化文書が、患者のアレルギーに関する情報を記憶するために、タイプ＜ａｌｌｅｒｇｙ＞のアノテーションを使用すると仮定する。この場合、ペニシリンアレルギーを有する全ての患者を識別するために定式化され、かつ、「＜ａｌｌｅｒｇｙ＞＝ｐｅｎｉｃｉｌｌｉｎ」などの構文を使用して定式化されるクエリは、構造化クエリである。その理由は、クエリが、文書構造、すなわち＜ａｌｌｅｒｇｙ＞アノテーションに対して特定の参照を行うからである。こうしたクエリを実行する探索は、構造化クエリである。こうした探索を実施する探索エンジンは、テキスト「ｐｅｎｉｃｉｌｌｉｎ」について（または、ペニシリンを表す他のトークンについて）文書コーパスにおいて＜ａｌｌｅｒｇｙ＞アノテーションだけを探索することができる。

対照的に、＜ｐｅｎｉｃｉｌｌｉｎ ａｌｌｅｒｇｙ＞などのクエリは、平易なテキスト「ｐｅｎｉｃｉｌｌｉｎ ａｌｌｅｒｇ」だけからなるため、非構造化クエリである。こうしたクエリは、文書構造を全く参照しない。結果として、こうした非構造化探索は、構造化探索に比べて正確さに欠ける結果を生じる可能性がある。その理由は、非構造化探索が、
・テキスト「ｐｅｎｉｃｉｌｌｉｎ ａｌｌｅｒｇｙ」に遭遇することに応答して、患者が、目下、ペニシリンアレルギーを持っていないことをこうしたテキストがたとえ示さない（たとえば、患者の母親がペニシリンアレルギーを持っていたことをテキストが示す場合がある）ときでも偽陽性を生成し、また、
・患者が、目下、ペニシリンアレルギーを持っていることを、「ｐｅｎｉｃｉｌｌｉｎ ａｌｌｅｒｇｙ」（たとえば、「ＰＮ ａｌｌｅｒｇｙ」）以外のテキストが示すことを認めることに失敗することによって、偽陰性を生成する場合があるからである。

したがって、構造化探索は、非構造化探索比べより関連性のある結果を生成しうるため有利である。しかし、構造化クエリは、長々しく、生成するのに時間がかかる。その理由は、構造化クエリが、見出されるコンテンツ（たとえば、テキスト）だけでなく、こうしたコンテンツがその中で見出される特定のタイプ（複数可）のアノテーション（複数可）をも参照しなければならないからである。したがって、人間オペレータが特定の文書コーパスにわたって実行するためのこうしたクエリを生成するために、人間オペレータは、文書コーパス内で探索するために、どのタイプのアノテーションが利用可能であるかを知らなければならない。特に、アノテーションタイプの数が非常に大きい場合、また、たとえば新しい文書が文書コーパス内に以前には存在しないタイプを含む結果として、アノテーションタイプの数が経時的に増大する場合、人間オペレータがこれを行うことは難しい可能性がある。

さらに、システムが構造化クエリを実行するために、探索される文書コーパスは、まず、構造化形態になるようにアノテートされなければならない。これは、こうしたアノテーションを実施するために設計および構築コンポーネントを必要とする。結果として、構造化クエリの１つの欠点は、構造化クエリがこうしたコンテンツに関して実施されうる前に、非構造化コンテンツを構造化コンテンツに変換するときの先行投資が必要とされることである。対照的に、非構造化クエリを実行することは、非構造化コンテンツに関して実施されうるため、こうした先行投資を全く必要としない。

さらに、構造化クエリの生成は、エラーを受ける。人間オペレータは、たとえば、「＜ａｌｌｅｒｇｙ＞＝ｐｅｎｉｃｉｌｌｉｎ」の代わりに誤って「＜ｉｒｒｉｔａｎｔ（刺激物）＞＝ｐｅｎｉｃｉｌｌｉｎ」についてクエリを定式化する場合がある。こうしたクエリを実行しようと試みることは、任意のマッチング文書を見出すためにエラーまたは失敗をもたらす場合がある。

いくつかの既存のシステムは、ユーザが構造化クエリを定式化するのを支援する。たとえば、いくつかのシステムは、目下のカーソルロケーションのクエリに挿入されることができる許容される用語（アノテーションタイプの名前など）のドロップダウンリストをユーザに提供するクエリ定式化ユーザインタフェースを含む。たとえば、こうしたユーザインタフェースは、「＜ａｌｌｅｒｇｙ＞」、「＜ｃｕｒｒｅｎｔｍｅｄｉｃａｔｉｏｎ＞」、および「＜ｐｒｏｇｎｏｓｉｓ（予後）＞」などのアノテーションタイプの選択を含むドロップダウンリストをユーザに提供することができる。同様に、他のクエリ定式化ユーザインタフェースは、ユーザが目下タイプしている用語を完結させるために許容される用語をユーザにプロンプト表示する「ａｕｔｏ−ｃｏｍｐｌｅｔｅ（オートコンプリート）」機能を提供する。たとえば、ユーザが、「＜ａｌｌ」をタイプする場合、システムは、用語「＜ａｌｌｅｒｇｙ＞」および「＜ａｌｌｅｒｇｅｎ＞」をユーザにプロンプト表示することができ、ユーザは、その中から選択して、クエリ内の目下の用語を完結させることができる。

ユーザにこうした支援を提供するために、いずれのこうしたクエリ定式化ユーザインタフェースも、探索される文書コーパス内に存在し、したがって、クエリ内に含まれることを許容されるアノテーションタイプのセットの知識を持たなければならない。クエリ言語は、アノテーションタイプのセットの定義を含むことができ、クエリ定式化ユーザインタフェースは、クエリ言語、したがってクエリ言語内のアノテーションタイプの知識によってプログラムされることができる。クエリ定式化ユーザインタフェースに新しいアノテーションタイプを認識する能力を提供することは、したがって、クエリ言語が更新されることを必要とする場合がある。文書コーパス内の全てのアノテーションについての、完全で正確で最新の知識を含むように、クエリ言語を更新すること、または、その他の方法でクエリ定式化ユーザインタフェースを更新することは、特に探索される文書コーパスが経時的に増大し変化する場合、また、文書コーパス内での探索について利用可能なアノテーションの数およびタイプが増大し変化する場合、難しい作業である可能性がある。

クエリ定式化ユーザインタフェースは、クエリ言語の知識によってハードコードされる、またはその他の方法でプログラムされることができる。結果として、クエリ定式化ユーザインタフェースは、「＜ａｌｌｅｒｇｙ＞」、「＜ａｌｌｅｒｇｅｎ＞」、および「＜ｓｅｖｅｒｉｔｙ（重篤度）＞」などのアノテーションに対して特定の参照を行う構造化クエリを人間オペレータが定式化するのを支援することが可能であるとすることができる。

さらに、特定の探索エンジンが、特定の文書コーパスを探索するときに使用するに配備されると仮定する。こうした配備の前に、探索エンジンは、アノテーションタイプのセットの定義を含むクエリ言語の知識を有するように探索エンジンをプログラムすることなどによって、文書コーパス内でアノテーションタイプのセットの知識によってハードコードされることができる。クエリ言語は、特定のオントロジー内でコードの互いの関係の定義を含むことができる。たとえば、クエリ言語は、「＜ａｌｌｅｒｇｙ＞」タイプのアノテーションが、「＜ａｌｌｅｒｇｅｎ＞」および「＜ｓｅｖｅｒｉｔｙ＞」などのサブアノテーション（サブコード）を有することを示すことができる。結果として、クエリ言語の知識を有する探索エンジンは、「＜ａｌｌｅｒｇｙ＞」、「＜ａｌｌｅｒｇｅｎ＞」、および「＜ｓｅｖｅｒｉｔｙ＞」などのアノテーションタイプに対して参照を行う構造化クエリを実行することが可能であるとすることができる。

しかし、こうしたシステムは、新しいアノテーションタイプ（すなわち、探索エンジンおよび／またはクエリ定式化ユーザインタフェース内に以前にハードコードされていないアノテーションタイプ）が導入されると、困難に直面する。こうした新しいアノテーションタイプは、たとえば、新しいアノテーションタイプを含む新しい構造化文書を文書コーパスに追加することによって、または、新しい非構造化文書を文書コーパスに追加し、次に、自然言語処理（ＮＬＰ）を新しい文書に適用し、それにより、新しいタイプを有する１つまたは複数のアノテーションを含むアノテーションを新しい文書に追加することによって導入されることができる。

こうしたシステムでは、探索エンジンは、新しいアノテーションタイプに対して参照を行う構造化クエリを処理することが可能である場合がある。その理由は、探索エンジンによって使用されるクエリ言語が新しいアノテーションタイプの定義を含まないからである。同様に、システムのクエリ定式化ユーザインタフェースは、新しいアノテーションタイプをユーザにプロンプト表示することが可能でない場合がある。その理由は、クエリ定式化ユーザインタフェースによって使用されるクエリ言語が新しいアノテーションタイプの知識を持たないからである。

通常、既存のシステムにおいてこれらの問題に対処するために、システム管理者または他の人間ユーザが、クエリ言語を手動で更新する、またはその他の方法で、追加されたアノテーションタイプの知識によって探索エンジンおよび／またはクエリ定式化ユーザインタフェースを更新することが必要である。こうした手動による更新を必要とすることは、長々しく、時間がかかり、エラーを起こし易い。こうした更新が正確に実施されるときでさえ、文書コーパスに対する新しいアノテーションタイプの追加と、新しいアノテーションタイプを反映するようにクエリ言語が更新されるとき、したがって探索エンジンおよびクエリ定式化ユーザインタフェースが新しいアノテーションタイプの知識を得るときとの間に、ある程度の固有の遅延が存在し、それにより、システムのユーザがシステムを最適利用できない期間が生じる。

文書コーパス内のコーディングは、前もって予測できない仕方で経時的に変化する場合がある。たとえば、（１）文書コーパスのユーザのニーズは、たとえば、規制の変化、処置レジメンに対する修正、および新しい調査研究のニーズの結果として経時的に進化する場合があり、（２）オントロジーは、用語を追加または洗練し、古い用語を軽視し、軽視される用語を新しい用語に置換えることによって経時的に進化する場合があり、（３）自然言語処理（ＮＬＰ）アルゴリズムは、経時的に進化する場合があり、結果として、テキスト内のコーディングの精度を改善するために、文書コーパス内で以前にエンコードされた文書を再処理し、それにより再コード（再アノテーション化）することが可能とすることができる。したがって、文書が経時的にできる限り有用のままであることを保証するために、先に挙げた変化に応答して、経時的に文書内でマークアップを修正する能力を有することが必要である。しかし、既存のシステムは、こうしたマークアップ修正に応答して、自分の探索エンジンおよびクエリ定式化ユーザインタフェースを自動的に更新することが可能でない。

本発明の実施形態は、探索エンジン、クエリ定式化ユーザインタフェース、および構造化探索システムの他のコンポーネントが、文書コーパスに追加されたアノテーションタイプの知識によって即座にかつ自動的に更新されることを可能にすることによって、既存の構造化探索システムのこれらのまた他の欠点に対処する。

本発明の特定の実施形態を述べる前に、構造化探索を一般に実行するプロセスが、まず、より詳細に述べられる。文書コーパスに関して構造化探索を実施するプロセスは、２つの高位ステップ、すなわち、
（１）選択（たとえば、ペニシリンに対してアレルギー性があり、かつ、３０歳と４０歳との間である、文書コーパス内で表される全ての患者を見出すこと）、および、
（２）予測（たとえば、こうしたそれぞれの患者について、患者のカレントメディケーションを論じる、患者についての文書（複数可）の部分（複数可）を取出すこと）
を含む。

選択クエリは、以下の形態の任意の形態など、種々の形態の任意の形態を、個々にまたは互いに組合せることができる。以下の形態とは、
・フリーフォームテキスト探索、
・文書（たとえば、「Ｐｅｎｉｃｉｌｌｉｎ ｉｎ Ａｌｌｅｒｇｙ Ｓｅｃｔｉｏｎ（アレルギーセクション内のペニシリン）」）内のある概念（たとえば、セクション）に制限されたフリーフォームテキスト探索、
・コーディング（アノテーション）探索、たとえば、
−オントロジーからの特定のコードの存在または非存在についての探索、
−コードの一般化の存在についての探索（たとえば、コード「Ｎｅｏｐｌａｓｍ（新生物）」についての探索は、タイプ「Ｎｅｏｐｌａｓｍ」のコードと、オントロジーで表現されるＩＳＡ関係によって「Ｎｅｏｐｌａｓｍ」コードに関連するオントロジー内の任意のコードの両方にマッチングすることができる）、
−所与の範囲（たとえば、否定、極性（たとえば、「ｐｏｓｓｉｂｌｅ（たぶん）」および「ｌｉｋｅｌｙ（おそらく）」）、時間、または対象の範囲）内のコード（またはコードの一般化）についての探索、
−コンプレックスアノテーションについての探索であって、マッチングされる値（複数可）だけでなく、その値（複数可）に対してマッチングされる複雑なアノテーション内のコンポーネント（複数可）（サブコード（複数可））をもクエリが指定する、探索。たとえば、「ａｌｌｅｒｇｙ」コンプレックスアノテーションでは、クエリは、「ａｌｌｅｒｇｙ」アノテーションの「ａｌｌｅｒｇｅｎ」フィールド（アブアノテーション）内の「ｐｅｎｉｃｉｌｌｉｎ」についての探索を指定するであろう。
・ヘッダ（たとえば、患者名、患者年齢、処置する内科医（複数可）、文書タイプ、文章表題）内のコンテキスト情報に関して実施されるコンテキスト情報探索、たとえば、
−範囲探索（たとえば、訪問日時、患者年齢）、
−フリーフォームテキスト探索（たとえば、患者名、文書表題）、
−コーデッド情報（たとえば、文書タイプ、受診の理由）についての探索であって、クエリ用語を拡張するために、オントロジーを使用することによって一般化されることができる、探索。たとえば、「ｎｏｔｅ（メモ）」タイプの文書についての探索は、タイプ「ｎｏｔｅ」の文書と、そのタイプが「ｎｏｔｅ」のサブタイプである文書の両方についての探索に一般化されることができる。
である。

選択クエリは、たとえば、構造化クエリ、非構造化クエリ、または、構造化クエリと非構造化クエリの組合せ（本明細書で「ｍｉｘｅｄ ｑｕｅｒｙ（混合クエリ）」と呼ばれる）とすることができる。

クエリの予測は、クエリの結果として、どの情報（たとえば、選択によって識別された文書セットの一部または集合体）が返送されるかを決定する。予測は、たとえば、以下のものの任意の１つまたは複数が、クエリの結果として返送されることを指定することができる。以下のものとは、
・選択用語（たとえば、「ＣｕｒｒｅｎｔＭｅｄｉｃａｔｉｏｎ」セクション）によって識別される、各マッチング文書のあるセクション、
・各マッチング文書内のあるタイプのコーディング（たとえば、タイプ「＜ａｌｌｅｒｇｙ＞」のコーディング）、
・各マッチング文書についてのコンテキスト情報（たとえば、患者名、患者年齢、処置する内科医）、
・全てのマッチング文書のセットからの集約情報（たとえば、全てのマッチのカウント、マッチのファセット）
である。

本発明の実施形態による、構造化文書のある特徴および構造化文書を生成するためのある技法を一般的に述べたが、本発明の実施形態による、構造化文書を探索するためのある技法がここで述べられる。

本発明の一実施形態では、図１に示すように、システム１００は、複数の構造化文書１０４ａ〜１０４ｎ（本明細書で、総称的に文書コーパス１０４と呼ばれる）を含むコンテンツストア１０２を含む。ここで、ｎは任意の数字とすることができる。コンテンツストア１０２はまた、構造化文書１０４ａ〜１０４ｎおよびユーザ情報１０８によって使用されるオントロジー１０６などの、文書コーパス１０４に関連するデータを含む。コンテンツストア１０２内の文書１０４ａ〜１０４ｎは、たとえば、ＸＭＬフォーマットで表されることができる。文書１０４ａ〜１０４ｎはそれぞれ、テキストおよび対応するマークアップ（本明細書で「アノテーション（ａｎｎｏｔａｔｉｏｎ）」または「コーディング（ｃｏｄｉｎｇ）」とも呼ばれる）を含むことができる。より具体的には、文書１０４ａは、テキスト１１４ａおよび対応するマークアップ１１６ａを含み、文書１０４ｂは、テキスト１１４ｂおよび対応するマークアップ１１６ｂを含み、文書１０４ｎは、テキスト１１４ｎおよび対応するマークアップ１１６ｎを含む。

システム１００はまた、自然言語処理（ＮＬＰ）フレームワーク１１０を含み、ＮＬＰフレームワーク１１０は、非構造化または半構造化データ（平易なテキスト文書など）をアノテート（エンコード）し、それにより、コンテンツストア１０２に追加されることができる構造化文書を生成するために使用されることができる。たとえば、既存の構造化文書１０４ａ〜１０４ｂ内のマークアップ１１６ａ〜１１６ｎは、構造化文書１０４ａ〜１０４ｎを生成するために、以前にＮＬＰ処理フレームワーク１１０によって生成され、非構造化文書に追加されている場合がある。ＮＬＰフレームワークは、文書内のセクションを認識すること、それらのセクションを離散的セクションとしてマークアップすること、オントロジー１０６（ＳＮＯＭＥＤ ＣＴなど）に対して一般的な用語マッチングを実施すること、オントロジー１０６からのコードを使用してマッチングされた任意の用語をママークアップすることなど、ＮＬＰフレームワークが所有する文書に関して任意の種類のマークアップを実施することができる。

より一般的には、ＮＬＰ処理フレームワーク１１０は、先に参照した先に参照した２つの米国特許第７，５８４，１０３号および第７，７１６，０４０号に開示される任意の種類の概念を認識し、こうした認識された概念を表すアノテーションによって文書（構造化文書１０４ａ〜１０４ｎなど）を相応してマークアップすることができる。こうした概念は、種々の方法のうちの任意の方法でエンコードされることができる。たとえば、ある概念は、単一値としてエンコードされることができる。たとえば「Ｓｙｓｔｏｌｉｃ Ｂｌｏｏｄ Ｐｒｅｓｓｕｒｅ Ｍｅａｓｕｒｅｍｅｎｔ（収縮期血圧測定）」概念は、特定の患者の収縮期血圧測定を表す単一数字を使用してエンコードされることができる。

しかし、概念は、複数の値を使用して表されることができる点で複雑であるとすることができる。たとえば、概念「Ｓｙｓｔｏｌｉｃ Ｂｌｏｏｄ Ｐｒｅｓｓｕｒｅ Ｍｅａｓｕｒｅｍｅｎｔ」は、患者の血圧を測定するために使用されたデバイスに関する情報および患者の血圧が測定されたときの患者の状態（たとえば、患者が立った状態で、寝た状態で、身体運動後に、または安静時などに測定が行われたかどうか）に関する情報をさらに含むことができる。

別の例として、「ＳｍｏｋｉｎｇＳｔａｔｕｓ（喫煙状態）」概念は、（１）患者の喫煙状態（たとえば、目下の喫煙者、過去の喫煙者、または非喫煙者）、（２）どれほどを患者が目下喫煙しているか（たとえば、パック／日単位で測定される）、および（３）過去の喫煙者について、患者がいつ喫煙を辞めたかを表す値を含むフィールド（本明細書で「ｓｕｂ−ａｎｎｏｔａｔｉｏｎ（サブアノテーション）」および「ｓｕｂ−ｃｏｄｅ（サブコード）」とも呼ばれる）を使用してエンコードされることができる。

先に述べたようい、こうした概念は、テキストおよびテキストのマークアップ（たとえば、ＸＭＬタグ）の組合せを使用して文書内で表されることができる。一般に、特定のテキストに対応するマークアップは、特定のテキストによって表される（語義的および／または文法的）概念を指定する。

システム１００はまた、複数のアノテーションタイプの定義１６２ａ〜１６２ｎを含むクエリ言語定義１６０を含む。図１に４つの定義１６２ａ〜１６２ｄが示されるが、クエリ言語定義１６０は、任意の数のアノテーションタイプ定義を含むことができる。一般に、アノテーションタイプ定義１６２ａ〜１６２ｄはそれぞれ、コーディング内のアノテーションタイプを表すシンボル（シンボル＜ａｌｌｅｒｇｙ＞など）、アノテーションタイプの許容されるサブアノテーションタイプ、およびアノテーションタイプのインスタンス内で使用するための許容される値などの、特定の対応するアノテーションのタイプの関連特性を定義する。各アノテーション定義は、特定の概念をエンコードするためのアノテーションのタイプを定義することができ、異なるタイプのアノテーションは、異なる概念をエンコードすることができる。クエリ言語定義１６０は、対応するクエリ言語の他の態様を定義することができ、アノテーション定義１６２ａ〜１６２ｎだけが、例示を容易にするために図１に示される。

システス１００はまた、文書コーパス１０４に関して構造化探索を実施するための探索エンジン１２０、および、ユーザ１７０が処理される構造化クエリを探索エンジン１２０によって定式化するのを支援するためのクエリ定式化ユーザインタフェース１５０を含む。より具体的には、ユーザ１７０は、部分的なまたは完全なクエリを表すテキスト入力、用語のドロップダウンリストから１つまたは複数の用語を選択するマウス入力、あるいはその任意の組合せなどのクエリ定式化入力１５２をクエリ定式化ユーザインタフェース１５０に提供する。クエリ定式化ユーザインタフェース１５０は、クエリ定式化入力１５２に基づいて構造化クエリ１５４を生成し、構造化クエリ１５４を探索エンジン１２０に提供する。探索エンジン１２０は、クエリ１５４を処理することによって文書コーパス１０４の構造化探索を実施し、もしあれば探索結果１２２をユーザ１７０に返送する。

ＮＬＰ処理フレームワーク１１０、探索エンジン１２０、およびクエリ定式化ユーザインタフェース１５０などのシステム１００のコンポーネントは、文書コーパス１０４ならびに文書コーパス１０４が含むテキスト１１４ａ〜１１４ｎおよびアノテーション１１６ａ〜１１６ｎに直接作用する、または、テキスト１１４ａ〜１１４ｎおよびアノテーション１１６ａ〜１１６ｎの中間文書モデル（図示せず）を通して作用することができる。たとえば、これらのコンポーネント１１０、１２０、および１５０の任意の１つまたは複数は、ＪａｖａＢｅａｎｓなどのデータオブジェクトを使用して文書１１４ａ〜１１４ｎ内の概念を表すことができる。異なるオブジェクトクラスが、各概念（アノテーション）タイプについて定義されることができ、各データオブジェクトは、特定のオブジェクトクラスのインスタンスとすることができる。各クラスは、データオブジェクト内に記憶された値にアクセスするための自分自身の方法のセットを定義することができる。たとえば、「ＳｍｏｋｉｎｇＳｔａｔｕｓ」アノテーションタイプに対応する「ＳｍｏｋｉｎｇＳｔａｔｕｓ」クラスは、ｇｅｔＳｔａｔｕｓ（）、ｇｅｔＰａｃｋｓＰｅｒＤａｙ（）、およびｇｅｔＤａｔｅＳｔｏｐｐｅｄＳｍｏｋｉｎｇ（）などの方法を定義することができる。

しかし、オブジェクトクラスおよびデータオブジェクトの使用は、本発明の要件ではない。したがって、以下の説明は、オブジェクトクラスおよびデータオブジェクトを使用することなく、文書コーパス１０４内のテキスト１１４ａ〜１１４ｎおよびアノテーション１１６ａ〜１１６ｎの直接の処理を述べることになる。しかし、当業者は、オブジェクトクラスおよびデータオブジェクトを使用し、他の方法で同じ機能を実施するために、本明細書で述べる技法を修正する方法を理解するであろう。

ＮＬＰ処理フレームワーク１１０、探索エンジン１２０、およびクエリ定式化ユーザインタフェース１５０などのシステム１００のコンポーネントは、クエリ言語定義１６０にアクセスすることができる。結果として、探索エンジン１２０は、クエリ言語定義１６０に対するそのアクセスの結果として、特定の時点においてクエリ言語定義１６０内のアノテーション定義１６２ａ〜１６２ｄの目下のセットによって定義されるアノテーションタイプを参照する構造化クエリを処理することによって構造化探索を実施することが可能とすることができる。逆に、探索エンジン１２０は、特定の時点においてクエリ言語定義１６０内のアノテーション定義１６２ａ〜１６２ｄの目下のセットによって定義されないアノテーションタイプを参照する構造化クエリを処理することによって構造化探索を実施することが可能でないとすることができる。たとえば、図１の場合に、構造化クエリが、クエリ言語定義１６０内のアノテーションタイプ定義１６２ａ〜１６２ｄの任意の定義によって定義されないアノテーションタイプを参照する場合、探索エンジン１２０は、こうしたクエリを正しく実行するためにエラーまたは失敗を信号送信することができる。

同様に、クエリ定式化ユーザインタフェース１５０は、クエリ言語定義１６０に対するそのアクセスの結果として、特定の時点においてクエリ言語定義１６０内のアノテーション定義１６２ａ〜１６２ｄの目下のセットによって定義されるアノテーションタイプを参照する構造化クエリを定式化するときの支援をユーザに提供することが可能とすることができる。たとえば、クエリ定式化ユーザインタフェースは、クエリ言語定義１６０によって定義されるアノテーションタイプ１６２ａ〜１６２ｄを表すラベルのドロップダウンリストをユーザに提供すること、および／または、クエリ言語定義１６０によって定義されるアノテーションタイプ１６２ａ〜１６２ｄを表すラベルのオートコンプリーションを提供することが可能とすることができる。

逆に、クエリ定式化ユーザインタフェース１５０は、特定の時点においてクエリ言語定義１６０内のアノテーション定義１６２ａ〜１６２ｄの目下のセットによって定義されないアノテーションタイプを参照する構造化クエリを定式化するときの支援をユーザに提供することが可能でないとすることができる。たとえば、クエリ定式化ユーザインタフェース１５０によって提供されるドロップダウンリストは、クエリ言語定義１６０が生成されて以来または最後に更新されて以来文書コーパス１０４に追加されたアノテーションのタイプを表すラベルなどの、特定の時点においてクエリ言語定義１６０内のアノテーション定義１６２ａ〜１６２ｄの目下のセットによって定義されないアノテーションタイプを表すラベルを含まない場合がある。同様に、クエリ定式化ユーザインタフェース１５０は、特定の時点においてクエリ言語定義１６０内のアノテーション定義１６２ａ〜１６２ｄの目下のセットによって定義されないアノテーションタイプを表すラベルをオートコンプリートすることが可能でないとすることができる。

本発明の実施形態による、これらの問題を克服するために使用されることができる技法の例がここで述べられる。図１のシステム１００の例とすることができるが、図１に示すシステム１００より時期が早い、図２に示すシステム２００ａを考える。特に、図２では、ＮＬＰ処理フレームワーク１１０は、コンテンツが特定のタイプのアノテーションでマークアップされるべきであることを認識し、また、そのタイプのアノテーションのインスタンスを生成し、文書コーパス１０４内の文書内に挿入するための単一ＮＬＰ処理コンポーネント１１２ａだけを含む。例のために、ＮＬＰ処理コンポーネント１１２ａは、患者の収縮期血圧を表すコンテンツをアノテートするためにタイプ「ＳｙｓｔｏｌｉｃＢｌｏｏｄＰｒｅｓｓｕｒｅ」のアノテーションを認識し生成すると仮定する。

同様に、図２Ａにおいて、文書コーパス１０４は、テキスト１１４ａおよび対応するアノテーション１１６ａを含む単一文書１０４ａだけを含む。例のために、テキスト１１４ａは、患者の収縮期血圧を表すテキストを含み、また、こうしたテキストは、対応するアノテーション１１６ａ内のタイプ「ＳｙｓｔｏｌｉｃＢｌｏｏｄＰｒｅｓｓｕｒｅ（収縮期血圧）」のアノテーションによってアノテート（マークアップ）される。このアノテーションは、文書１０４ａを走査し、患者の収縮期血圧を表すテキストを文書１０４ａが含んでいたことを認識することに応答してＮＬＰ処理コンポーネント１１２ａによって生成されている場合がある。

図２のクエリ言語定義１６０は、単一アノテーション定義１６２ａだけを含む。例のために、アノテーション定義１６２ａがアノテーションタイプ「ＳｙｓｔｏｌｉｃＢｌｏｏｄＰｒｅｓｓｕｒｅ」を定義すると仮定する。したがって、クエリ定式化ユーザインタフェース１５０は、「ＳｙｓｔｏｌｉｃＢｌｏｏｄＰｒｅｓｓｕｒｅ」などの、アノテーションタイプを参照する構造化クエリをユーザが定式化するのを支援することが可能であり、探索エンジン１２０は、こうした構造化クエリを処理することによって構造化探索を実施することが可能である。

したがって、図２Ａに示す時点で、探索エンジン１２０は、「ＳｙｓｔｏｌｉｃＢｌｏｏｄＰｒｅｓｓｕｒｅ」アノテーションタイプ以外のアノテーションタイプを参照する構造化クエリを処理することによって構造化探索を実施することが可能でないとすることができる。たとえば、「ＳｍｏｋｉｎｇＳｔａｔｕｓ」アノテーションタイプを参照するクエリを処理することによって構造化探索を実施するために探索エンジン１２０を使用しようとするユーザによる試みは、探索エンジン１２０に、こうしたクエリを正しく実行するためにエラーまたは失敗を信号送信するようにさせる。同様に、図２Ａに示す時点で、クエリ定式化ユーザインタフェース１５０は、「ＳｍｏｋｉｎｇＳｔａｔｕｓ」アノテーションタイプなどの、「ＳｙｓｔｏｌｉｃＢｌｏｏｄＰｒｅｓｓｕｒｅ」アノテーションタイプ以外のアノテーションタイプを参照する構造化クエリを定式化するときの支援をユーザに提供することが可能でない場合がある。

ここで、図１のシステム１００の例とすることができるが、図１に示すシステム１００より時期が早く、かつ、図２に示すシステム２００ａより時期が遅い、図２Ｂに示すシステム２００ｂを考える。さらに、本発明の一実施形態において図２Ｂのシステム２００ｂによって実施される方法３００のフローチャートを示す。

特に、図２Ｂにて、新しい文書１０４ｂが、文書コーパス１０４に追加された（図３、ステップ３０２）。新しい文書１０４ｂは、患者の喫煙状態を表すテキスト１１４ｂを含む。図２Ｂに示す特定の例では、文書１０４ｂは、平易なテキスト文書であり、したがって、テキスト１１４ｂのアノテーションを全く含まない。

図２Ｂにて、新しいＮＬＰ処理コンポーネント１１２ｂが、ＮＬＰ処理フレームワーク１１０に追加された（図３、ステップ３０４）。ＮＬＰ処理コンポーネント１１２ｂは、（１）患者の喫煙状態を表すテキストを認識すること、および、（２）こうしたテキストをアノテートするために、「ＳｍｏｋｉｎｇＳｔａｔｕｓ」アノテーションタイプのインスタンスを生成し、文書に挿入することが可能である。

ＮＬＰ処理フレームワーク１１０は、新しいＮＬＰ処理コンポーネント１１２ｂを使用して、患者の喫煙状態を表す新しい文書内のテキストを認識することができる（図３、ステップ３０６）。簡潔にするために、新しい文書１０４ｂのテキスト１１４ｂ内のまさに１つの節が患者の喫煙状態を表すと仮定する。この場合、ＮＬＰ処理コンポーネント１１２ｂは、こうしたテキストを認識し、「ＳｍｏｋｉｎｇＳｔａｔｕｓ」アノテーションタイプのインスタンスであるアノテーションを生成し（図３、ステップ３０８）、アノテーション１１６ｂとして文書１０４ｂ内にアノテーションを挿入することができる（図３、ステップ３１０）。文書１０４ｂ内にアノテーション１１６ｂを挿入することは、テキスト１１４ｂとアノテーション１１６ｂが、その後互いに相関するように、アノテーション１１６ｂを対応するテキスト１１４ｂに関連付けることを含むことができる。その結果は、図２Ｃのシステム２００ｃによって示される。

ＮＬＰ処理フレームワーク１１０は、たとえば、文書コーパス１０４に対する新しい文書１０４ｂの追加に応答して、新しい文書１０４ｂに対して目下のＮＬＰ処理コンポーネント１１２ａ〜１１２ｄの全てを適用することによってステップ３０６〜３１０を実施することができる。

あるいは、たとえば、ＮＬＰ処理フレームワーク１１０は、文書コーパス１０４内の文書１０４ａ〜１０４ｂの全てに対して新しいＮＬＰ処理コンポーネント１１２ｂだけを適用することによってステップ３０６〜３１０を実施することができる。この場合、患者の喫煙状態を表す既存の文書１０４ａ内の任意のテキストはまた、タイプ「ＳｍｏｋｉｎｇＳｔａｔｕｓ」のアノテーションでアノテートされることになる。ＮＬＰ処理フレームワーク１１０は、文書コーパス１０４内のアノテーションができる限り最新になることを保証するために、文書コーパス１０４内の文書の全てに対してＮＬＰ処理フレームワーク１１０内のＮＬＰ処理コンポーネントの全てを定期的に（たとえば、１時間ごとに、毎日、毎週）適用することができる。

したがって、ＮＬＰ処理フレームワーク１１０は、文書コーパス１０４に対して文書が全く追加されないときでも、新しいアノテーションタイプのインスタンスを生成することができる。たとえば、やはり文書コーパス１０４が文書１０４ａだけを含む図２Ａのシステムを考える。ここで、文書１０４ａは、患者の収縮期血圧を表すテキストと患者の喫煙状態を表すテキストの両方を含むと仮定する。図２ＡのＮＬＰ処理フレームワーク１１０は、文書１０４ａを処理する場合、ＮＬＰ処理コンポーネント１１２ａを使用して、文書１０４ａ内でタイプ「ＳｙｓｔｏｌｉｃＢｌｏｏｄＰｒｅｓｓｕｒｅ」のアノテーションを生成することになるが、文書１０４ａに対してタイプ「ＳｍｏｋｉｎｇＳｔａｔｕｓ」のアノテーションを生成しないことになる。その理由は、図２Ｂの「ＳｍｏｋｉｎｇＳｔａｔｕｓ」ＮＬＰ処理コンポーネント１１２ｂが、図２ＡのＮＬＰ処理フレームワーク１１０にいまだ追加されていないからである。

しかし、「ＳｍｏｋｉｎｇＳｔａｔｕｓ」ＮＬＰ処理コンポーネント１１２ｂが、図２Ｂに示すようにＮＬＰ処理フレームワーク１１０に追加され、ＮＬＰ処理フレームワーク１１０が、次に文書１０４ａの（未修正）テキスト１１４ａに「ＳｍｏｋｉｎｇＳｔａｔｕｓ」ＮＬＰ処理コンポーネント１１２ｂを適用する場合、「ＳｍｏｋｉｎｇＳｔａｔｕｓ」ＮＬＰ処理コンポーネント１１２ｂは、文書１０４ａ内で患者の喫煙状態を表すテキストを認識し、相応して文書１０４ａ内で「ＳｍｏｋｉｎｇＳｔａｔｕｓ」アノテーションを生成することになる。この例が示すように、文書コーパス１０４に対する新しい文書の追加は、新しいアノテーションタイプのインスタンスの生成について必要でない。

元の文書１０４ａが、患者の喫煙状態を表すテキストを元の文書１０４ａに追加することによって修正された場合、同様の結果が生じることになる。この場合、文書１０４ａの修正バージョンに対して新しい「ＳｍｏｋｉｎｇＳｔａｔｕｓ」ＮＬＰ処理コンポーネント１１２ｂを適用することは、ＮＬＰ処理コンポーネント１１２ｂに、修正されたテキストを認識させ、相応して「ＳｍｏｋｉｎｇＳｔａｔｕｓ」アノテーションを生成させ、文書１０４ａ内に挿入させる。これは、文書コーパス１０４に対する新しい文書の追加が、新しいアノテーションタイプのインスタンスの生成について必要でないことをさらに示す。

クエリ言語定義１６０は、新しいアノテーションタイプ（すなわち、新しいＮＬＰコンポーネント１１２ｂによって認識されるアノテーションタイプ）の定義を含むために更新される（図３、ステップ３１２）。結果として、クエリ言語定義１６０は、図２Ｄのシステム２００ｄに示すように、新しいアノテーションタイプの定義１６２ｂを含む。

こうした更新は、種々の方法で実施されることができる。たとえば、クエリ言語定義１６０は、文書コーパス１０４に対する新しいタイプのアノテーション（たとえば、アノテーション１１６ｂ）の追加に応答して更新されることができる。アノテーションのタイプがクエリ言語定義１６０内に対応するアノテーション定義を持たない場合、アノテーションは「ｎｅｗ（新しい）」タイプである。こうしたアノテーションは、たとえば、文書コーパス１０４内に現れる、そのタイプの最初のものとすることができる。クエリ言語定義１６０は、たとえば、自動的に（たとえば、自然言語処理フレームワーク１１０によって）またはシステム２００の人間ユーザによって手動で修正されることができる。

たとえば、クエリ言語定義１６０が「ＳｍｏｋｉｎｇＳｔａｔｕｓ」アノテーションタイプの定義を含まず、かつ、ＮＬＰ処理フレームワーク１１０が、文書コーパス１０４内の文書１０４ａ〜１０４ｄのうちの１つの文書に対してタイプ「ＳｍｏｋｉｎｇＳｔａｔｕｓ」のアノテーションを追加する場合、こうしたアノテーションは、「ｎｅｗ」タイプのアノテーションである。システム１００は、文書コーパス１０４に対するこうしたアノテーションの追加に応答してクエリ言語定義１６０を更新することができる。

文書コーパス１０４に対する新しいアノテーションの追加は、種々の方法のうちの任意の方法で検出されることができる。たとえば、ＮＬＰ処理フレームワーク１１０は、対応するアノテーションを文書コーパス１０４内に挿入するための新しいＮＬＰ処理コンポーネント（ＮＬＰ処理コンポーネント１１２ｂ）の最初の使用によって、新しいタイプのアノテーションが文書コーパス１０４に追加されたと判定し、こうした判定に応答して、ＮＬＰ処理フレームワーク１１０は、クエリ言語更新２０２をクエリ言語定義１６０に送出することができる（図２Ｃ）。クエリ言語更新２０２は、新しいアノテーション定義１６２ｂおよびクエリ言語定義１６０に対して新しいアノテーション定義１６２ｂを追加するための対応する命令を含むことができる。更新２０２を受信することに応答して、クエリ言語定義１６０は、（クエリ言語定義１６０がアノテーション定義１６２ｂを既に含んでいない場合）アノテーション定義１６２ｂを含むように更新されることができる。

別の例として、システム１００のＮＬＰ処理フレームワーク１１０または何らかの他のコンポーネントは、文書コーパス１０４が最後に走査されてから文書コーパス１０４内で起こらなかったタイプを有するアノテーションを識別すること、または、クエリ言語定義１６０内で定義を持たないタイプを有するアノテーションを識別することなどによって、新しいタイプのアノテーションを検出するために自然言語処理を適用することによって文書コーパス１０４を定期的に構文解析することができる。こうした新しいアノテーションタイプを検出することに応答して、クエリ言語定義１６０は、新しいアノテーションタイプの定義を含むように更新されることができる。

新しいタイプのアノテーションを有する文書がＮＬＰ処理フレームワーク１１０を使用してアノテートされている必要がないことに留意された。たとえば、ＮＬＰ処理フレームワーク１１０によって生成されない既存のアノテーションを含む文書は、文書コーパス１０４内にインポートされることができる。別の例として、文書コーパス１０４内のある文書は、手動で、または、ＮＬＰ処理フレームワーク１１０以外の何らかの他のメカニズムを使用してアノテートされることができる。こうした文書は、クエリ言語定義１６０を更新するために使用されることができる新しいタイプのアノテーションを識別するために（ＮＬＰフレームワーク１１０を使用してまたは使用せずに）走査されることができる。

新しいタイプを有するアノテーションは、ＮＬＰフレームワーク１１０内のＮＬＰ処理コンポーネント１１２ａによって認識されることが可能なタイプを持つ場合があるまたは持たない場合がある。たとえば、タイプ「ＣｕｒｒｅｎｔＭｅｄｉｃａｔｉｏｎ」の既存のアノテーションを含む新しい文書は、ＮＬＰフレームワーク１１０内のＮＬＰ処理コンポーネント１１２ａ〜１１２ｎがいずれも、（１）患者のカレントメディケーションを表すコンテンツを認識すること、または、（２）タイプ「ＣｕｒｒｅｎｔＭｅｄｉｃａｔｉｏｎ」のアノテーションを生成することが可能でなくても、文書コーパス１０４内にインポートされることができる。それでも、新しい文書内のタイプ「ＣｕｒｒｅｎｔＭｅｄｉｃａｔｉｏｎ」のアノテーションは、システム１００によって識別され、クエリ言語定義１６０の更新をトリガーするために使用されることができる。これらの例が示すように、新しいＮＬＰ処理コンポーネントが全くＮＬＰフレームワーク１１０に追加されない場合でも、新しいタイプのアノテーションが検出されることができ、対応するアノテーション定義が、クエリ言語定義１６０に追加されることができる。

さらに、既存のタイプのアノテーションに対する修正は、上述した技法と同様の技法を使用して検出されることができる。たとえば、システム１００は、文書コーパス１０４内の新しいまたは既存の文書を走査し、既存のタイプであるが、クエリ言語定義１６０内の対応するアノテーション定義において反映されないフィールド（サブコード）を含むアノテーションを検出する場合、新しく発見されたフィールドを反映するためにそのアノテーション定義を更新することができる。

さらに、新しいＮＬＰ処理コンポーネント（すなわち、クエリ言語定義１６０内の対応するアノテーション定義を持たないタイプのアノテーションを生成することが可能であるＮＬＰ処理コンポーネント）の単なる追加は、新しいＮＬＰ処理コンポーネントによって生成されることが可能なアノテーションのタイプの定義を含むために、クエリ言語定義１６０の更新をトリガーすることができる。クエリ言語定義１６０は、新しいＮＬＰ処理コンポーネントによって生成されることが可能なタイプのアノテーションが文書コーパス１０４内で起こるか否かによらず、こうした新しいＮＬＰ処理コンポーネントの追加に応答して、更新されることができる。

新しいアノテーション定義１６２ｂを含むためにクエリ言語定義１６０が更新されると、ユーザは、次に、クエリ定式化入力１５２をクエリ定式化ユーザインタフェース１５０に提供することができ（図３、ステップ３１４）、その間に、クエリ定式化ユーザインタフェース１５０は、新しいアノテーションタイプを参照する構造化クエリをユーザ１７０が定式化するのを支援することができる（図３、ステップ３１６）。

クエリ定式化ユーザインタフェース１５０は、種々の形態の任意の形態をとることができる。たとえば、クエリ定式化ユーザインタフェース１５０は、ユーザ１７０がそれを通してクエリ１５４をタイプすることができるテキストベースユーザインタフェースを含むことができる。別の例として、ユーザインタフェース１５０は、グラフィカルユーザインタフェースを含むことができ、グラフィカルユーザインタフェースを通して、ユーザ１７０は、キーワード（「ＧＥＴ」および「ＦＯＲ」など）、アノテーションタイプおとびフィールドの名前（「ＳｍｏｋｉｎｇＳｔａｔｕｓ」および「ｐａｃｋｓＰｅｒＤａｙ（パック／日）」など）、およびブール代数コネクタ（「ＡＮＤ」および「ＯＲ」など）を選択して、クエリ１５４を形成することができる。

先に述べたように、クエリ定式化ユーザインタフェース１５０は、クエリ言語定義１６０にアクセスすることができ、したがって、新しいアノテーションタイプの定義１６２ｂがクエリ言語定義１６０にたった今追加された場合であっても、新しいアノテーションタイプの名前をユーザにプロンプト表示する、またはその他の方法で、新しいアノテーションタイプに関連する支援を提供することができる。換言すれば、クエリ定式化ユーザインタフェース１５０は、単にクエリ言語定義１６０に対するアノテーション定義１６２ｂの追加に応答して、また、システム１００またはシステム１００の任意のコンポーネントをポーズする、リコンパイルする、リローンチする、リブートする、またはその他の方法で再構成する必要なしで、新しいタイプのアノテーションを参照する構造化クエリをユーザ１７０が定式化するのを支援することが自動的に可能になる。

たとえば、クエリ定式化ユーザインタフェース１５０は、目下のカーソルロケーションでクエリに挿入されることができる許容される用語（アノテーションタイプの名前など）のドロップダウンリストをユーザ１７０に提供することができる。このリストは、新しいアノテーションタイプの名前または他の識別子（たとえば、「ＳｍｏｋｉｎｇＳｔａｔｕｓ」）を含むことができる。ユーザ１７０は、こうした名前または識別子を選択し、それにより、クエリ定式化ユーザインタフェース１５０に、新しいアノテーションタイプを参照する用語を構造化クエリ１５４に追加させることができる。クエリ定式化ユーザインタフェース１５０は、アノテーションタイプ１６２ａ〜１６２ｄによって定義されるアノテーションのタイプに関する情報をクエリ言語定義１６０から得ることによってドロップダウンリスト１５０を生成することができる。

別の例として、クエリ定式化ユーザインタフェースは、構造化クエリ１５４を定式化するプロセスにおいてユーザ１７０によって目下タイプされる用語を完結させるために、許容される用語をユーザ１７０にプロンプト表示することができる「ａｕｔｏｃｏｍｐｌｅｔｅ」機能を含むことができる。こうした許容される用語は、新しく追加されたアノテーションタイプの名前または他の識別子を含むことができる。たとえば、構造化クエリ１５４をタイプするプロセスにおいて、ユーザ１７０は、「Ｓｍｏｋ」をタイプし、クエリ定式化ユーザインタフェース１５０は、「Ｓｍｏｋ」の許容されるコンプリーションとして「ＳｍｏｋｉｎｇＳｔａｔｕｓ」を提供することができる。ユーザ１７０は、次に、「ＳｍｏｋｉｎｇＳｔａｔｕｓ」を選択し、それにより、クエリ定式化ユーザインタフェース１５０に、構造化クエリ１５４に用語「ＳｍｏｋｉｎｇＳｔａｔｕｓ」を追加させることができる。ユーザ１７０は、所望に応じて、他の用語を構造化クエリ１５４に追加することができる。

クエリ定式化ユーザインタフェース１５０は、結果として得られる構造化クエリ１５４を探索エンジン１２０に提供することができ、探索エンジン１２０は、構造化クエリ１５４に基づいて文書コーパス１０４に関して構造化探索を実施することができ、それにより、探索結果１２２を生成することができる（図３、ステップ３１８）。探索エンジン１２０は、探索結果１２２をユーザ１７０に提供することができる（図３、ステップ３２０）。

先に述べたように、探索エンジン１２０は、クエリ言語定義１６０にアクセスすることができ、したがって、その定義１６２ｂがクエリ言語定義１６０にたった今追加されたアノテーションの新しいタイプを構造化クエリ１５４が参照する場合であっても、構造化クエリ１５４を処理することができる。換言すれば、探索エンジン１２０は、単にクエリ言語定義１６０に対するアノテーション定義１６２ｂの追加に応答して、また、システム１００またはシステム１００の任意のコンポーネントをポーズする、リコンパイルする、リローンチする、リブートする、またはその他の方法で再構成する必要なしで、新しいタイプのアノテーションを参照する構造化クエリを処理することが自動的に可能になる。

構造化探索を実施するプロセス（図３、ステップ３１８）は、２つのステップ、すなわち選択および予測を含むことができる。選択および予測（図示せず）を実施する探索エンジン１２０のサブコンポーネントは、クエリ言語定義１６０にアクセスすることができ、したがって、その定義１６２ｂがクエリ言語定義１６０にたった今追加されたアノテーションのタイプを参照するクエリ用語を使用して、選択および予測をそれぞれ実施することができる。

たとえば、「．ＳｍｏｋｉｎｇＳｔａｔｕｓ．ｐａｃｋｓＰｅｒＤａｙ＞２ ＡＮＤ ．ＳｍｏｋｉｎｇＳｔａｔｕｓ．ｓｔａｔｕｓ＝ＡＣＴＩＶＥ」などのクエリを考える。探索エンジン１２０の選択コンポーネントは、文書コーパス１０４によって記載される患者から、１日当たり２パックより多くを目下喫煙している全ての患者を選択することによって、こうしたクエリを処理することができる。

別の例として、クエリ「ＧＥＴ ＳｍｏｋｉｎｇＳｔａｔｕｓ ＦＯＲ．ｆｉｎｄｉｎｇ．ｃｏｄｅ ｉｓＡ＜Ｎｅｏｐｌａｓｍ＞」を考える。このクエリは、選択要求（「ＦＯＲ．ｆｉｎｄｉｎｇ．ｃｏｄｅ ｉｓＡ＜Ｎｅｏｐｌａｓｍ＞」）および予測要求（「ＧＥＴ ＳｍｏｋｉｎｇＳｔａｔｕｓ」）を含む。探索エンジン１２０の選択コンポーネントは、任意の種類の新生物の臨床所見の論議を含む、文書コーパス１０４内の全ての文書を見出すために選択要求を処置することによって、また、選択要求からもたらされた、文書コーパス１０４内に記載される患者の喫煙状態を返送するために予測要求を処理することによって、こうしたクエリを処理することができる。

したがって、一般に、クエリ言語定義１６０によって定義されるクエリ言語を使用して形成されることができるクエリは、経時的に、自動的に、文書コーパス１０４内に含まれるアノテーションの経時的な変化に応答して増大し変化することができる。

先の説明が明確にするように、本発明の実施形態は種々の利点を有する。たとえば、本明細書で開示される技法は、非常に特異的な構造化クエリが高い信頼性を持って処理されることを可能にする。その理由は、探索可能なアノテーションタイプのセットが文書コーパス１０４内の構造化コンテンツに直接対応しており、また、処理されるクエリが、単に平易なテキストではなく、こうしたアノテーションタイプを特に参照することができるからである。これは、構造化クエリが、文書コーパス１０４内のコンテンツの語義的および／または文法的意味を考慮することを可能にし、それにより、偽陽性と偽陰性の両方を減少させる。

本発明の実施形態の別の利点は、本発明の実施形態が、動的に拡張可能である文書を探索するために使用されるクエリ言語を使用可能にすることである。こうした拡張は、文書コーパス１０４内の対応する探索可能な構造化文書１０４ａ〜１０４ｎの変化に応答して自動的に行われることができる。結果として、こうした拡張を行うためのさらなる努力は、エンドユーザまたはシステム管理者の部分に関して全く必要とされない。さらに、こうした自動的でかつ動的な拡張の結果として、ユーザが文書１０４ａ〜１０４ｎの最新の（ｍｏｓｔ ｃｕｒｒｅｎｔ）状態を反映することがいつの時点でも常に可能であり、探索エンジン１２０がこうしたクエリを処理することがいつの時点でも常に可能である。これは、考えられる最大の表現力を有するクエリがいつでも実施されることを可能にし、それにより、ユーザが、必要とする情報を迅速にかつ正確に見出すことができる可能性を高める。

既存の構造化クエリシステムの１つの欠点は、非構造化コンテンツをアノテートして、そのコンテンツを構造化コンテンツに変換するコンポーネントを、そのコンテンツに関して構造化クエリを実施することが可能になる前に生成するよう、こうしたシステムの設計者にシステムが要求することである。既存の構造化クエリシステムの関連する欠点は、こうしたシステムのクエリ言語定義を手動で構成して、クエリ言語定義が新しい種類の構造化コンテンツに関して構造化探索を実施することが可能になるようにさせることが必要であることである。さらに上述したように、非構造化クエリシステムの対応する利点は、システムがこうした先行投資を必要としないこと、および、非構造化クエリが、こうしたコンテンツをアノテートすることなく、いずれの非構造化コンテンツ上でも実行されうることである。しかし、非構造化クエリシステムの欠点は、システムが、構造化クエリを実施できず、したがって、構造化クエリシステムの精度および深度を有する探索結果を得ることができないことである。

本発明の実施形態は、構造化クエリシステムと非構造化クエリシステムの両方の利点を含むシステムを提供することによってこれらの問題に対処する。特に、本発明の実施形態は、非構造化コンテンツが、構造化クエリを使用して、しかし、システムを手動で構成して、システムがこうした構造化クエリを実施することが可能になるようにさせることをシステムの設計者または管理者に要求することなく、クエリされることを可能にする。代わりに、本発明の実施形態は、非構造化コンテンツを自動的にアノテートして、そのコンテンツを構造化コンテンツに変換すると共に、新しくアノテートされたコンテンツに関して構造化クエリをシステムが実施できるように、システムのクエリ言語定義を自動的に更新することができる。結果として、システムのユーザは、新しいコンテンツが最小の努力でシステムに追加されるため、新しいコンテンツに関して構造化クエリを実施できる。

本発明の実施形態の別の利点は、本発明の実施形態が、混合コンテンツデータセット、すなわち非構造化コンテンツ（たとえば、物語テキスト）と構造化テキスト（たとえば、離散的事実）の両方を含むデータセットの進化的かつ動的な理解を生じるために使用されることができることがでる。非構造化コンテンツがアノテートされるため、非構造化コンテンツの意味のより深い理解が得られ、アノテーションの形態で記録される。システム内の（新しくアノテートされたコンテンツを含む）混合コンテンツに関して構造化クエリをシステムが実施することを可能にするためにシステムのクエリ言語を動的に更新することは、混合コンテンツから情報がより容易に抽出されることを可能にする。こうした情報は、その後、コンテンツをさらにアノテートするために使用されることができる。結果として、本発明の実施形態は、システムのコンテンツのより深い理解が経時的に得られる正フィードバックループを可能にする。

特定の実施形態によって本発明が上述されたが、先の実施形態は、単に例証として提供され、本発明の範囲を限定または規定しないことが理解される。限定はしないが以下を含む種々の他の実施形態もまた特許請求の範囲内にある。たとえば、本明細書で述べる要素およびコンポーネントはさらに、さらなるコンポーネントに分割されることができる、または、共に結合されて、同じ機能を実施するためのより少数のコンポーネントを形成することができる。

上述したように、構造化文書は、テキストおよび／またはコンテンツが、アノテーションによってマークアップされる文書である。こうしたアノテーションは、ＸＭＬタグの形態などで、構造化文書自体内にあるとすることができる。あるいは、たとえば、アノテーションは、文書の外部にあるとすることができるが、その意味がアノテーションによって示されるコンテンツにリンクされるまたはその他の方法で関連付けられることができる。ＸＭＬが、本発明の種々の実施形態の説明に関連して使用されるが、これらは、例に過ぎず、本発明の制限を構成しない。アノテーションは、ＸＭＬ以外の表現を使用して表されることができる。

先に述べたいくつかの例では、構造化文書は、スピーチをトランスクライブすることによって生成される。しかし、これは、本発明の制限ではない。むしろ、本発明の実施形態に関連して使用される構造化文書は、スピーチをトランスクライブすることによってだけでなく、任意の方法で生成されることができる。たとえば、構造化文書は、文書内のテキストによって表される概念（たとえば、セクション）をエンコードするコーディング（アノテーション）によって既存の平易なテキスト文書をマークアップすることによる本発明の実施形態に従って生成されることができる。

本明細書で述べるいくつかの例では、アノテートされる「ｔｅｘｔ（テキスト）」が参照されるが、テキストは、本発明の実施形態を適用することができるある種類のコンテンツの例として単に提供され、本発明の制限を構成しない。むしろ、文書内の「ｔｅｘｔ」に対する本明細書におけるいずれの参照も、オーディオ、ビデオ、および／または他のコンテンツに同様に当てはまる。同様に、本明細書で述べるいくつかの例は、「ｄｏｃｕｍｅｎｔ（文書）」の使用を含むが、本明細書で使用される用語「ｄｏｃｕｍｅｎｔ」は、テキストを含む、または、テキストを含むだけである文書に限定されない。むしろ、本明細書で使用される用語「ｄｏｃｕｍｅｎｔ」は、任意の種類のコンテンツを含む、コンピュータ可読媒体上に有形に記憶された任意のデータ構造当てはまる。

クエリ言語定義１６０は、システム１００の他のコンポーネントと別個であるとして図１および図２Ａ〜２Ｄに示されるが、これは、本発明の要件ではない。たとえば、クエリ言語定義１６０は、自然言語処理フレームワーク１１０、探索エンジン１２０、およびクエリ定式化ユーザインタフェース１５０の１つまたは複数に統合されることができる。結果として、クエリ言語定義１６０を修正することは、探索エンジン１２０を修正して、修正型探索エンジンを生成することができ、かつ／または、クエリ定式化ユーザインタフェース１５０を修正して、修正型クエリ定式化ユーザインタフェースを生成することができる。クエリ言語定義１６０の異なる表現が、ＮＬＰ処理フレームワーク１１０、探索エンジン１２０、およびクエリ定式化ユーザインタフェース１５０によって使用されることができる。さらに、クエリ言語定義１６０ａ〜１６０ｄは、任意の方法でアノテーション定義１６２ａ〜１６２ｄを表すことができる。

ＮＬＰ処理コンポーネント１１２ａ〜１１２ｎは、図１および図２Ａ〜２ＤのＮＬＰ処理フレームワークに含まれるものとして示されるが、これは、本発明の制限ではない。代わりに、たとえば、ＮＬＰ処理コンポーネント１１２ａ〜１１２ｎは、ＮＬＰ処理フレームワーク１１０の外部にあるとすることができ、その場合、ＮＬＰ処理コンポーネント１１２ａ〜１１２ｎは、自然言語処理を文書コーパス１０４に適用するときにどのＮＬＰ処理コンポーネント１１２ａ〜１１２ｎを使用すべきかをＮＬＰ処理フレームワーク１１０がわかるように、ＮＬＰ処理フレームワーク１１０によって登録されることができる。

クエリ定式化ユーザインタフェース１５０はオプションである。さらに、たとえクエリ定式化ユーザインタフェース１５０が使用される場合でも、クエリ定式化ユーザインタフェース１５０は、探索エンジン１２０と同じシステムの一部である必要はない。構造化クエリ１５４は、クエリ定式化ユーザインタフェース１５０を使用することなく生成されることができる。たとえば、構造化クエリ１５４は、ユーザ１７０によってではなく、ソフトウェアによって自動的に生成されることができる。

上述した技法は、たとえば、ハードウェア、コンピュータ可読媒体上に有形に記憶されたソフトウェア、ファームウェア、またはその任意の組合せで実装されることができる。上述した技法は、プロセッサを含むプログラム可能なコンピュータ上で実行される１つまたは複数のコンピュータプログラム、プロセッサによって読出し可能な記憶媒体（たとえば、揮発性および不揮発性メモリおよび／または記憶要素）、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスで実装されることができる。プログラムコードは、入力デバイスを使用して入力される入力に適用されて、述べた機能を実施し、出力を生成することができる。出力は、１つまたは複数の出力デバイスに提供されることができる。

添付特許請求の範囲内の各コンピュータプログラムは、アセンブリ言語、機械言語、高位手続き型プログラミング言語、またはオブジェクト指向プログラミング言語などの任意のプログラミング言語で実装されることができる。プログラミング言語は、たとえば、コンパイル済みまたはインタープリト済みプログラミング言語とすることができる。

こうした各コンピュータプログラムは、コンピュータプロセッサが実行するために、機械可読記憶デバイスで有形に具現化されるコンピュータプログラム製品で実装されることができる。本発明の方法ステップは、コンピュータ可読媒体上に有形に具現化されるプログラムを実行するコンピュータプロセッサによって実施されて、入力に作用し、出力を生成することによって本発明の機能を実施することができる。適したプロセッサは、例として、汎用マイクロプロセッサと専用プロセッサの両方含む。一般に、プロセッサは、読出し専用をメモリおよび／またはランダムアクセスメモリから命令およびデータを受信する。コンピュータプログラム命令を有形に具現化するのに適した記憶デバイスは、たとえば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、およびフラッシュメモリデバイスを含む、半導体メモリデバイスなどの不揮発性メモリ、内部ハードディスクおよび取外し可能なディスクなどの磁気ディスク、光磁気ディスク、およびＣＤ−ＲＯＭの全ての形態を含む。上記の全ては、特別に設計されたＡＳＩＣ（特定用途向け集積回路）またはＦＰＧＡ（フィールドプログラマブルゲートアレイ）によって補完される、または、それに組込まれることができる。コンピュータは、一般に、内部ディスク（図示せず）または取外し可能なディスクなどの記憶媒体からプログラムおよびデータを受信することもできる。これらの要素はまた、従来のデスクトップまたはワークステーションならびに本明細書で述べる方法を実装するコンピュータプログラムを実行するのに適した他のコンピュータにおいて見出されることになり、それらの要素は、任意のデジタルプリントエンジンまたはマーキングエンジン、ディスプレイモニタ、あるいは、紙、フィルム、ディスプレイスクリーン、または他の出力媒体上にカラーまたはグレースケールピクセルを生成することが可能な他のラスター出力デバイスと共に使用されることができる。

Claims (28)

1. 少なくとも１つの非一時的なコンピュータ可読媒体上に有形に記憶されたコンピュータプログラム命令を実行する少なくとも１つのコンピュータプロセッサによって実施される方法であって、
   システムであって、
   文書コーパス内で第１のタイプのアノテーションを生成するために前記文書コーパス内のテキストを構文解析するように適合された第１の自然言語処理コンポーネントと、
   第２のタイプのアノテーションを生成し、前記第２のタイプのアノテーションを前記文書コーパスに追加するために前記文書コーパス内のテキストを構文解析するように適合された第２の自然言語処理コンポーネントと、
   第２のタイプのアノテーションではなく、前記第１のタイプのアノテーションの構造化探索を実施するように適合された探索コンポーネントと
   を備える、システムと共に使用するためのものであり、
   （Ａ）前記文書コーパス内で前記第２のタイプの第１のアノテーションを識別すること、
   （Ｂ）前記第２のタイプのアノテーションの構造化探索を前記探索コンポーネントが実施することを可能にするように、前記探索コンポーネントを修正することであって、それにより、修正探索コンポーネントを生成する、修正すること、
   （Ｃ）前記第２のタイプのアノテーションを参照する用語を含むクエリを受信すること、および、
   （Ｄ）前記クエリを使用して前記文書コーパスに関する探索を実施するために前記修正探索コンポーネントを使用することを含み、
   前記（Ａ）は、
   （Ａ１）前記文書コーパス内で前記第２のタイプの第１のアノテーションを生成するために第２のタイプの前記アノテーションに対応する概念を表す文書コーパス内のテキストを認識することと、
   （Ａ２）前記認識されたテキストを前記第２のタイプの前記第１のアノテーションに関連づけること
   を含む方法。
2. （Ａ）は、前記文書コーパスに対する前記第１のアノテーションの追加を検出することを含む請求項１に記載の方法。
3. （Ａ）の前に、前記文書コーパスは、前記第２のタイプのいずれのアノテーションも含まず、
   （Ｂ）は、前記文書コーパスに対する前記第２のタイプの前記第１のアノテーションの追加の検出に応答して前記探索コンポーネントを修正することを含む請求項２に記載の方法。
4. （Ｆ）（Ａ）の前に、前記第２のタイプのアノテーションを生成するためにテキストを構文解析するように適合された前記第２の自然言語処理コンポーネントを前記システムに追加することをさらに含み、
   （Ｂ）は、前記システムに対する前記第２の自然言語処理コンポーネントの追加に応答して前記探索コンポーネントを修正することを含む請求項３に記載の方法。
5. （Ｂ）は、前記少なくとも１つのコンピュータプロセッサによって自動的に実施される請求項１に記載の方法。
6. （Ｂ）は、人間ユーザによって手動で実施される請求項１に記載の方法。
7. 前記探索コンポーネントは、前記第１のタイプのアノテーションの構造化探索、テキストの非構造化探索、ならびに、テキストと前記第１のタイプのアノテーションの混合探索を実施するように適合される請求項１に記載の方法。
8. （Ｂ）は、前記第２のタイプのアノテーションの定義を含むように、前記第１のタイプのアノテーションの定義を含むクエリ言語定義を修正することを含む請求項１に記載の方法。
9. 前記システムは、クエリ定式化ユーザインタフェースであって、前記クエリをユーザが定式化するのを支援するように適合された、クエリ定式化ユーザインタフェースをさらに含み、
   （Ｅ）前記クエリ定式化ユーザインタフェースを自動的に修正することであって、それにより、前記クエリ定式化ユーザインタフェースが、前記第２のアノテーションを参照する用語を含むように前記クエリを前記ユーザが定式化するのを支援することを可能にする、修正することをさらに含む請求項１に記載の方法。
10. （Ｂ）は、前記第２のタイプのアノテーションの定義を含むように、前記第１のタイプのアノテーションの定義を含むクエリ言語定義を修正することを含む請求項９に記載の方法。
11. 前記文書コーパスは、前記第２のタイプの複数のアノテーションを含み、（Ｄ）は、
    （Ｄ）（１）前記第２のアノテーションを参照するクエリの用語を使用して前記文書コーパス内で前記第２のタイプのアノテーションに関する選択を実施するために前記探索コンポーネントを使用することを含む請求項１に記載の方法。
12. コンピュータプログラム命令が有形に記憶されている非一時的なコンピュータ可読媒体であって、前記コンピュータプログラム命令は、システムと共に使用するための方法を実施するために少なくとも１つのコンピュータプロセッサによって実行可能であり、前記システムは、
    文書コーパス内で第１のタイプのアノテーションを生成するために前記文書コーパス内のテキストを構文解析するように適合された第１の自然言語処理コンポーネントと、
    第２のタイプのアノテーションを生成し、前記第２のタイプのアノテーションを前記文書コーパスに追加するために前記文書コーパス内のテキストを構文解析するように適合された第２の自然言語処理コンポーネントと、
    第２のタイプのアノテーションではなく、前記第１のタイプのアノテーションの構造化探索を実施するように適合された探索コンポーネントと
    を備え、
    前記方法は、
    （Ａ）前記文書コーパス内で前記第２のタイプの第１のアノテーションを識別すること、
    （Ｂ）前記第２のタイプのアノテーションの構造化探索を前記探索コンポーネントが実施することを可能にするように、前記探索コンポーネントを修正することであって、それにより、修正探索コンポーネントを生成する、修正すること、
    （Ｃ）前記第２のタイプのアノテーションを参照する用語を含むクエリを受信すること、および、
    （Ｄ）前記クエリを使用して前記文書コーパスに関する探索を実施するために前記修正探索コンポーネントを使用することを含み、
    前記（Ａ）は、
    （Ａ１）前記文書コーパス内で前記第２のタイプの第１のアノテーションを生成するために第２のタイプの前記アノテーションに対応する概念を表す文書コーパス内のテキストを認識することと、
    （Ａ２）前記認識されたテキストを前記第２のタイプの前記第１のアノテーションに関連づけること
    を含むコンピュータ可読媒体。
13. （Ａ）は、前記文書コーパスに対する前記第１のアノテーションの追加を検出することを含む請求項１２に記載のコンピュータ可読媒体。
14. （Ａ）の前に、前記文書コーパスは、前記第２のタイプのいずれのアノテーションも含まず、
    （Ｂ）は、前記文書コーパスに対する前記第２のタイプの前記第１のアノテーションの追加の検出に応答して前記探索コンポーネントを修正することを含む請求項１３に記載のコンピュータ可読媒体。
15. （Ｆ）（Ａ）の前に、前記第２のタイプのアノテーションを生成するためにテキストを構文解析するように適合された前記第２の自然言語処理コンポーネントを前記システムに追加することをさらに含み、
    （Ｂ）は、前記システムに対する前記第２の自然言語処理コンポーネントの追加に応答して前記探索コンポーネントを修正することを含む請求項１４に記載のコンピュータ可読媒体。
16. （Ｂ）は、前記少なくとも１つのコンピュータプロセッサによって自動的に実施される請求項１２に記載のコンピュータ可読媒体。
17. （Ｂ）は、人間ユーザによって手動で実施される請求項１２に記載のコンピュータ可読媒体。
18. 前記探索コンポーネントは、前記第１のタイプのアノテーションの構造化探索、テキストの非構造化探索、ならびに、テキストと前記第１のタイプのアノテーションの混合探索を実施するように適合される請求項１２に記載のコンピュータ可読媒体。
19. （Ｂ）は、前記第２のタイプのアノテーションの定義を含むように、前記第１のタイプのアノテーションの定義を含むクエリ言語定義を修正することを含む請求項１２に記載のコンピュータ可読媒体。
20. 前記システムは、クエリ定式化ユーザインタフェースであって、前記クエリをユーザが定式化するのを支援するように適合された、クエリ定式化ユーザインタフェースをさらに含み、
    （Ｆ）前記クエリ定式化ユーザインタフェースを自動的に修正することであって、それにより、前記クエリ定式化ユーザインタフェースが、前記第２のアノテーションを参照する用語を含むように前記クエリを前記ユーザが定式化するのを支援することを可能にする、修正することをさらに含む請求項１２に記載のコンピュータ可読媒体。
21. （Ｂ）は、前記第２のタイプのアノテーションの定義を含むように、前記第１のタイプのアノテーションの定義を含むクエリ言語定義を修正することを含む請求項２０に記載のコンピュータ可読媒体。
22. 前記文書コーパスは、前記第２のタイプの複数のアノテーションを含み、（Ｄ）は、
    （Ｄ）（１）前記第２のアノテーションを参照するクエリの用語を使用して前記文書コーパス内で前記第２のタイプのアノテーションに関する選択を実施するために前記探索コンポーネントを使用することを含む請求項１２に記載のコンピュータ可読媒体。
23. 少なくとも１つの非一時的なコンピュータ可読媒体上に有形に記憶されたコンピュータプログラム命令を実行する少なくとも１つのコンピュータプロセッサによって実施される方法であって、
    システムであって、
    文書コーパス内で第１のタイプのアノテーションを生成するために前記文書コーパス内のテキストを構文解析するように適合された第１の自然言語処理コンポーネントと、
    第２のタイプのアノテーションではなく、前記第１のタイプのアノテーションの構造化探索を実施するように適合された探索コンポーネントと
    を備える、システムと共に使用するためのものであり、
    （Ａ）前記第２のタイプのアノテーションを生成するためにテキストを構文解析するように適合された第２の自然言語処理コンポーネントの前記システムに対する追加を検出すること、
    （Ｂ）前記第２のタイプのアノテーションの構造化探索を前記探索コンポーネントが実施することを可能にするように、前記検出に応答して前記探索コンポーネントを修正することであって、それにより、修正探索コンポーネントを生成する、修正すること、
    （Ｃ）前記第２のタイプのアノテーションを参照する用語を含むクエリを受信すること、および、
    （Ｄ）前記クエリを使用し前記文書コーパスに関する探索を実施するために前記修正探索コンポーネントを使用することを含む方法。
24. 前記文書コーパスは、（Ｂ）が実施される時間に、前記第２のタイプのいずれのアノテーションも含まない請求項２３に記載の方法。
25. （Ａ）は、前記システムに対して前記第２の自然言語処理コンポーネントを追加することを含む請求項２３に記載の方法。
26. コンピュータプログラム命令が有形に記憶されている非一時的なコンピュータ可読媒体であって、前記コンピュータプログラム命令は、システムと共に使用するための方法を実施するために少なくとも１つのコンピュータプロセッサによって実行可能であり、前記システムは、
    文書コーパス内で第１のタイプのアノテーションを生成するために前記文書コーパス内のテキストを構文解析するように適合された第１の自然言語処理コンポーネントと、
    第２のタイプのアノテーションではなく、前記第１のタイプのアノテーションの構造化探索を実施するように適合された探索コンポーネントと
    を備え、
    前記方法は、
    （Ａ）前記第２のタイプのアノテーションを生成するためにテキストを構文解析するように適合された第２の自然言語処理コンポーネントの前記システムに対する追加を検出すること、
    （Ｂ）前記第２のタイプのアノテーションの構造化探索を前記探索コンポーネントが実施することを可能にするように、前記検出に応答して前記探索コンポーネントを修正することであって、それにより、修正探索コンポーネントを生成する、修正すること、
    （Ｃ）前記第２のタイプのアノテーションを参照する用語を含むクエリを受信すること、および、
    （Ｄ）前記クエリを使用して文書コーパスに関する探索を実施するために前記修正探索コンポーネントを使用することを含むコンピュータ可読媒体。
27. 前記文書コーパスは、（Ｂ）が実施される時間に、前記第２のタイプのいずれのアノテーションも含まない請求項２６に記載のコンピュータ可読媒体。
28. （Ａ）は、前記システムに対して前記第２の自然言語処理コンポーネントを追加することを含む請求項２６に記載のコンピュータ可読媒体。
    

Images