(57)【要約】【課題】文書の管理等を向上しうるテキストを追補する方法等を提供する。【解決手段】テキストを追補する方法は、データベース内の構造化データのモデルを生成するステップであってデータベース内のリファレントに各々がオブジェクトを記述する指定語を関連付けるステップを含みリファレントの各々がオブジェクトの１個を含むかまたは参照するモデルの生成ステップと、データベースのテキストデータ内の複数の候補参照エンティティを識別するステップと、各々の候補参照エンティティについてテキストデータ内の候補参照エンティティをモデルと比較するステップを含んで類似度を計算し候補参照エンティティの参照エンティティと参照エンティティが参照する対応オブジェクトとを識別するステップと、オブジェクトから導かれた情報を用いてテキストデータを追補するステップとを含む。【選択図】図１
2008033931.tif 000002
【特許請求の範囲】
【請求項１】
テキストを追補する方法であって、
データベース内の構造化データのモデルを生成するステップであって、前記データベース内のリファレントに各々がオブジェクトを記述する指定語を関連付けるステップを含み、前記リファレントの各々がオブジェクトの１個を含むかまたは参照する、モデルの生成ステップと、
前記データベースのテキストデータ内の複数の候補参照エンティティを識別するステップと、
各々の候補参照エンティティについて、前記テキストデータ内の候補参照エンティティを前記モデルと比較するステップを含んで類似度を計算し、前記候補参照エンティティの参照エンティティと前記参照エンティティが参照する対応オブジェクトとを識別するステップと、
前記オブジェクトから導かれた情報を用いて前記テキストデータを追補するステップと、
を備える方法。
【請求項２】
前記モデルを生成するステップが、前記リファレントの各々について、前記リファレントと意味論的関係にある指定語を識別するステップを含む、請求項１に記載の方法。
【請求項３】
クエリーに応答してテキストを取得する方法であって、
クエリーを入力するステップと、
格納された構造化およびテキストデータから前記クエリーに応答する情報を取得するステップと、
を備え、
前記テキストデータは請求項１に記載の方法に従って追補されている、方法。
【請求項４】
メモリに格納されたレコードを含み、当該レコードの各々が構造化データのフィールドに配置された構造化データおよびテキストデータのフィールドのテキストデータを含むデータベースであって、構造化データの少なくとも一部のフィールドがビジネスオブジェクトを参照するリファレントを含む、データベースと、
前記テキストデータのテキストチャンクと、前記構造化データに関連付けられたビジネスモデルとの間の類似度を計算することにより、構造化データのリファレントに参照されるビジネスオブジェクトを識別する注釈を用いて前記テキストデータに注釈を付けるプロセッサと、
を備えるシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、テキストを追補する方法、クエリーに応答してテキストを取得する方法、およびシステムに係る。この例証的な実施形態は、文書の管理および利用に関するものであり、構造化された、または構造化されていない（テキスト型）データを共通の解析方式により解析可能にする情報を用いたデータの追補に関して特定の用途が見出される。
【背景技術】
【０００２】
往々にして、ビジネスデータソース（business  data  sources）は、構造化および非構造化のデータを含んでいる。構造化データはビジネスオブジェクトに関する定量的な（quantitative）情報を含んでいてよく、一方、非構造化データはこれらのビジネスオブジェクトに関連するテキスト情報を含んでもよい。構造化データの例として、定義された階層関係がデータの異なる部分間に存在するテーブル（table）が含まれる。例えば、データベースのテーブルは一般に、従来型のテーブルの列見出しに対応するフィールドを含んでいて、これらのフィールドは各列の内容と所定の関係を有する。非構造化データは自然言語（「自由テキスト」）で表わされたテキストデータであって、顧客または供給元とのやり取りから得られたテキスト、例えばそのような構造が存在しない（あっても極めて制限されている）電子メール、スキャンされＯＣＲ（自動文字認識処理）されたメール、調査アンケート、通話内容の記録、会議メモ等を含んでもよい。例えば、技術センターは多くの場合、故障／修理記録を維持しており、これらはハードウェア、製品コンポーネント、介入日付、担当した技術者、および逐語的コメントに関する両方の構造化情報を含んでいる。
【０００３】
一般に、混合データ環境の二つの部分は、分離された状態で別々に使用される。データの解析において、報告および統計解析はデータマイニング技術（data  mining  techniques）を用いた定量的（構造化）部分だけに依存し、一方、テキスト部分はキーワード検索技術を用いる従来型の情報検索エンジンにより利用される場合が多い。データの定量的部分により実際にリンクが生成されることはない。
【０００４】
データのユーザーは、各種用途のための混合データモデリングに関心を持っている。データが広範に解析／利用されない理由の一つとして、非構造化テキストがビジネスオブジェクトを参照する際に異なる表現を使用して、それらを総称的に参照することが挙げられる。
【０００５】
【非特許文献１】マイク・マイヤー（MIKE  MEYER）、“混合データモデリングの非構造化データを用いたより良好な予測（Better  Predictions  Using  Unstructured  Data  In  Mixed-Data  Modeling）”、［online］、２００４年７月、ＤＭダイレクト、インターネット＜www.dmreview.com/dmdirect/＞
【非特許文献２】ガイ・クリース（GUY  CREESE）、“デュオ・マイニング：データとテキストマイニングの結合（Duo  Mining：Combinig  Data  and  Text  Mining）”、［online］、２００４年９月、ＤＭレビュー、インターネット＜www.dmreview.com＞
【発明の開示】
【発明が解決しようとする課題】
【０００６】
例えば、顧客が自身のモデルＡＢ１００のプリンタの故障に関して、単に「私の新しいプリンタが動きません。」とだけ書いた電子メールをＡＢ社のサービス技術者に送る場合がある。当該サービス技術者は構造化されたビジネスデータのレコードからプリンタモデルを判定することができる。例えば、当該データベースは全ての技術者が担当する顧客、対応プリンタのモデル、および購入日時のリストを示すテーブルを含んでもよい。当該技術者は次いで、顧客の電子メールに返信して、その電子メールを顧客サービス要求のデータベースファイルに格納することができる。しかし、ＡＢ社は自社の各プリンタモデルに対するサービス依頼の件数のレポートを生成したいと思うかもしれない。この情報は全体として会社のデータベースに存在しているにせよ、同社は構造化および非構造化（テキスト）データの両方から自動的に情報を抽出する方法を持ち合わせていない。
【０００７】
本発明の目的は、文書の管理、利用等を向上しうる、テキストを追補する方法、クエリーに応答してテキストを取得する方法、およびシステムを提供することにある。
【課題を解決するための手段】
【０００８】
本明細書に開示した例示的な実施形態の一態様によれば、テキストを追補する方法を提供する。本方法は、データベース内の構造化データのモデルの生成を含んでいる。モデルの生成は、データベース内のリファレント（referent）に、各々がオブジェクトを記述する指定語（designating  term）を関連付けることを含み、リファレントの各々は１個のオブジェクトを含むかまたは参照する。候補参照エンティティ（candidate  referring  entity）は、データベース内のテキストデータで識別（identify）される（換言すれば、同定される）。各々の候補参照エンティティについて、テキストデータ内の候補参照エンティティをモデルと比較することを含んで類似度（similarity  measure）を計算し、候補参照エンティティの参照エンティティと参照エンティティが参照する対応オブジェクトとを識別する。テキストデータは、対応オブジェクトから導かれた情報を用いて追補（enrich）される。
【０００９】
本方法において、オブジェクトはビジネスオブジェクトを含むことができる。リファレントは、構造化データ用のフィールドの内容を含むことができる。
【００１０】
モデルの生成は、各々のリファレントについて、リファレントと意味論的関係（semantic  relationship）にある指定語の識別を含むことができる。
【００１１】
リファレントと意味論的関係にある指定語の識別は、語彙集リソース（lexical  resource）へのアクセスを含むことができる。
【００１２】
各々のリファレントに関連付けられた指定語の１個は、オブジェクトの正規化された一意の識別子（normalized  unique  identifier）を含むことができる。
【００１３】
テキストデータ内の候補参照エンティティの識別は、名詞句の識別を含むことができる。
【００１４】
候補参照エンティティの識別は、当該候補参照エンティティの正規化された形の識別を含むことができる。候補参照エンティティの識別は、（ａ）当該テキストデータに関する外部情報によるテキストデータの拡張と、（ｂ）テキストデータまたは拡張されたテキストデータ内での共参照解決（または共参照解析）（co-reference  resolution）と、の少なくとも一つを含むことができる。
【００１５】
指定語のリファレントへの関連付けは、各々のリファレントについて、それぞれが重みを有する複数の指定語とリファレントとの関連付けを含むことができる。
【００１６】
類似度の計算は、各々の指定語の重みの関数として、候補参照エンティティとリファレントとの間の類似度の計算を含むことができる。
【００１７】
類似度の計算は、文字列カーネル値（string  kernel  value）と、候補参照エンティティとモデルの指定語との間の最小編集距離と、の少なくとも一つの計算を含むことができる。
【００１８】
類似度の計算は更に、テキストデータ内の候補参照エンティティと、テーブルの同一レコードの構造化データまたは当該レコードに関連付けられた他のレコードの構造化データとの比較を含むことができる。
【００１９】
追補は、テキストデータを、識別されたリファレントが参照するオブジェクトの正規化された識別子を用いて追補することを含むことができる。
【００２０】
正規化された識別子は、名称および関連した役割または機能を含むことができる。
【００２１】
追補は、タグまたは追加的なテキストによる参照エンティティへの注釈付けを含むことができる。
【００２２】
本方法は更に、リファレントが参照するオブジェクトから導かれた情報を用いて構造化データを追補することを含むことができる。
【００２３】
別の態様によれば、システムは、メモリに格納された複数のレコードを含むデータベースを含んでいる。複数のレコードの各々は、構造化データのフィールドに配置された（arranged）構造化データと、テキストデータのフィールドのテキストデータと、を含んでいる。構造化データのフィールドの少なくとも一部は、ビジネスオブジェクトを参照するリファレントを含んでいる。プロセッサは、テキストデータのテキストチャンク（textual  chunk）と構造化データに関連付けられたビジネスモデル（business  model）との類似度を計算することにより、構造化データのリファレントに参照されるビジネスオブジェクトを識別する注釈により、テキストデータに注釈を付ける。
【００２４】
構造化および非構造化データの解析は、クエリーに応答するテキストの取得（retrieve）を含むことができる。
【００２５】
別の態様における方法は、指定語と、複数のレコードを含むデータベーステーブルのフィールド（各レコードについて当該フィールドは構造化データを含む）内のリファレントとの関連付けを含み、当該リファレントは各々ビジネスオブジェクトを含んでいるかまたは参照する。候補参照エンティティは、テキストデータの部分で識別され、テキストデータの部分はデータベーステーブルのテキストデータフィールドにあるかこれにリンクされており、これにより各々のテキストデータ部分にはテーブルの全レコードよりは少ないレコードに関連付けられている。複数の候補参照エンティティの各々について、候補参照エンティティと、データベーステーブルの同一レコードのリファレントに関連付けられた指定語との間の類似度が計算される。計算された類似度が閾値を超えた場合、レコードのテキストデータ部分は、リファレントのビジネスオブジェクトから導かれた情報を用いて追補される。
【００２６】
本方法は更に、追補されたテキストデータとクエリーに応答する構造化データとからのテキストの取得を含んでいる。
【発明を実施するための最良の形態】
【００２７】
例示的な実施形態の態様は、引き続くデータの解析を一般的な情報解析技術を用いて可能にするデータベース内の構造化および／または非構造化データを追補する方法に関する。各種の態様において、本方法は、指定語が構造化データ内のリファレント（各々のリファレントはビジネスオブジェクトを含んでいるかまたは参照する）に関連付けられたモデルを構築するステップと、データベースのテキスト部分の候補参照エンティティを識別（identify）、換言すれば同定する（オプションとして当該エンティティを拡張した後で識別する）ステップとを含んでいる。本方法は更に、候補参照エンティティとモデルとの間の類似度を計算して、参照エンティティとそれらが参照するビジネスオブジェクトとを識別するステップを含んでいる。本方法は更に、ビジネスオブジェクトから導かれた情報を用いてテキストデータを追補するステップを含んでいる。
【００２８】
本システムおよび方法は、一般に、故障／診断／修理ログデータベース、顧客電子メールのルーティング、およびデータマイニングに用途が見出せる。例示的に、本明細書では本方法をビジネスシナリオに関して記述している。しかし、本システムおよび方法が各種の分野で用途が見出せる点を理解されたい。本方法は、より完全な一義化および正規化されたテキスト情報を利用することにより、エンティティの抽出、分類、およびクラスタリングの方法の効率を向上させることができる。これにより、更なる解析目的のために、データの構造化されていない部分を、大域的且つ完全に構造化されたデータベースへより正確に再構築および統合を行なうことができる。
【００２９】
本システムを利用できる特定の状況の例として、消費者満足度調査を、調査対象である製品に関する構造化された情報へリンクすることが挙げられる。別の例として、サービスまたは販売に関する電子メールや他の通信内容を、特定顧客に販売した製品に関する情報へリンクすることが挙げられる。ここで用いる「オブジェクト」とは、ドメインに固有な概念の所定の有限集合における、関心対象である項目を構成する概念である。
【００３０】
オブジェクトは、その共通する役割または機能により分類でき、且つこれらの役割または機能は階層的に構築できるため、他のオブジェクトを含んでもよい。ビジネスドメインにおいて、オブジェクトはビジネスオブジェクトと呼ばれる。ビジネスオブジェクトは、ビジネスにおいて重要である任意の物理的または論理的なオブジェクトであってよく、例えば、特定の製品、製品の組、従業員、市場セグメントを代表する顧客の集団、販売注文、部門、組み立て部品、品目は、残高または請求書等が挙げられる。ビジネスオブジェクトは通常、抽象的または物理的なレベルで階層的なクラスに編成されている。ビジネスオブジェクトは、オブジェクト指向用語におけるクラスのメンバーまたはクラスのインスタンスに類似していよう。各ビジネスオブジェクトは、例えば、エンティティ名や、ロール（役割）または機能を表わす抽象を含んでもよい。役割は一般に人名に関連付けられており、一方、機能は製品やサービス等の無生物オブジェクトに関連付けられている。
【００３１】
データベースはテーブルを含んでおり、その中で列に対応するデータフィールドは、構造化データの内容と論理的、階層的な関係を有している。データフィールドは一般に、オブジェクトを参照し、これはビジネス環境ではビジネスオブジェクトである。データベース内のテーブルの「行」はレコードを構成する。レコードとは、データベーステーブルに格納された、１個のビジネスオブジェクト（顧客等）に関する一まとまりの関連情報である。各レコードは、他のビジネスオブジェクト、例えば購入されたプリンタ、そのサービス担当技術者等、を含むかまたは参照することができる。しかし、各レコードには、限られた数のビジネスオブジェクト（全ての可能なビジネスオブジェクトの部分集合）しか関連付けられていない。データベースにおいて各フィールドは、フィールド名および／またはフィールド記述等の、従来型テーブルの列ヘッダに対応する、フィールド情報が関連付けられていてもよい。フィールド名は、データベース内でフィールドを識別するための必須情報部分であってよく、短い文字列を含んでもよい。フィールド記述は、存在する場合、テーブルのメタデータの一部であってよい。フィールド記述は、フィールドの内容の意味に関する詳細な情報を提供するものであり、一つ以上の文であってよい。
【００３２】
以下から理解されるように、データベーステーブルを議論する際に行および列の概念は任意であり、本明細書では説明目的にのみ用いる。テーブルのセル内の構造化データは、例えば、人口統計的、地理的および／またはトランザクションの（transactional）データを含んでもよい。一般に、データベースの構造化された部分のレコードは、２個以上のオブジェクト同士の関係を定める順序付けられた構成（arrangement）を含んでいる。データベース内の典型的な構造化情報は、従業員のテーブル、製品およびその機能のテーブル等を含んでもよい。データベース内のテーブルのエンティティ関係（ＥＲ）スキーマは通常、ビジネスオブジェクトのクラス構造をコード化する。
【００３３】
いくつかのデータベースフィールドは、非構造化データまたは非構造化データへのリンクを含んでいる。具体的には、データベース内のレコードは、各々が自然言語テキストを含む1個以上のテキストフィールドを含んでもよい。あるいは、フィールドはテキストへのアクセスを提供するリンクを含んでもよい。リンクは、ジョインテーブルを介して生成することができる。このように、所与のレコードに対して、1個以上のフィールドが、対応する非構造化データへの1個以上のリンクを含んでもよい。従って、1個のレコードは構造化および非構造化データを含むことができる。異なるテーブルのレコードを識別するフィールドは外部キーと呼ばれる。
【００３４】
非構造化データは上述のようにテキストデータを含んでおり、英語等の一種類以上の自然言語で表わされた通信レポート、例えば電子メール、スキャン後にＯＣＲされたメール、調査アンケート、通話内容の記録等の形式のテキストデータ部分を含んでもよい。一般に、非構造化データは、定義された、階層的な構造を欠いている。非構造化データは、自由テキストまたは逐語的テキストと呼ばれる。非構造化データとして記述されているにものの、非構造化データを含むテキストは構造化データにリンクされており、従ってデータベースの全体的な構造内に含まれている。テーブルのフォーマットメタデータは一般に、構造化データまたは自由テキストのいずれかを含むものとし各々のフィールドを区別する。データベース内のデータはまた、本明細書に記載した技術（例えばキーワード検索）では検索不可能なデータ、例えば画像データ、音声データ、またはビデオデータ等を含んでいてよく、これらについては以下では考慮しない。
【００３５】
本明細書で用いる「リファレント（referent）」とは、データベースの構造化された部分のうちで、それ自体がビジネスオブジェクト（例えば特定のプリンタや「ジョン  ドウ」等の自然人）である部分か、ビジネスオブジェクトを（例えばコードまたは短縮形を用いて）参照する部分である。
【００３６】
本明細書で用いる「参照エンティティ（referring  entity）」とは、データベースの構造化された部分を参照するデータベースの非構造化部分における表現である。参照エンティティは、データベースの非構造化（テキスト）部分の語句（term）（単語または複数の単語）であってよく、当該テーブルの同一レコードの他のフィールドのリファレント、あるいはリンクされたテーブルの他のレコードのリファレントを参照することができる。例示的な実施形態において、参照エンティティは、参照エンティティ（またはその正規化された形式）とリファレントとの間の計算された類似度が選択された閾値を超えた場合にリファレントを参照するものと考えられる。「参照する（referring）」とは、参照エンティティとビジネスオブジェクトとが意味論的関係にあることを意味する。意味論的関係には、類義語、上位語（hypernymy）／下位語（hyponymy）および全体語（holonymy）／部分語（meronymy）を含んでもよい。これらは全て、単語の対同士の関係を指す文法的形態素である。
【００３７】
本明細書で用いる「追補（enrich）」とは一般に、オブジェクトまたはリファレントとの関連に従った情報を用いてデータベース内の自由テキスト項目（free  text  entry）に注釈を付けることを意味する。注釈は、レコード内の参照エンティティまたはレコードの領域と、ビジネスオブジェクトまたはリファレントとの間に参照関係を生成することができる。また、リファレントは、それらが参照する対応ビジネスオブジェクトに関する情報を用いて追補されることができる。本明細書で用いる追補は、テキストチャンクをその正規化された形式で代替する場合と同様に、代替を含んでもよい。
【００３８】
本明細書で用いる「語彙集（lexicon）」とは、データ構造と、プログラムと、オブジェクトと、辞書、シソーラスまたは単語の特定のデータベース等の自然言語の集合に出現し得る単語の集合を示すデバイスと、のうち一つ以上を包含している。語彙集の例として、ＷｏｒｄＮｅｔ等のオンラインサービスがあり、入力語に対して類義語、上位語／下位語および全体語／部分語の等価物を与える。
【００３９】
各オブジェクトは、正規化された一意の識別子（identifier）であってよい一意のアイデンティティ（ｏｂｊｅｃｔ＿ｉｄ）により識別できるものと仮定する。例示的な実施形態の一態様において、関心対象である参照は、ビジネスオブジェクトのドメイン固有の（ユーザー定義された）集合（例えば、顧客、製品、サービス、従業員）に属する。通常、これらのオブジェクトはｏｂｊｅｃｔ＿ｉｄにより、＜名称、役割または機能＞の対（例えば＜ジョー  シュミット、技術者＞；＜アン  ドウ、販売担当者＞；＜ＴＰＸ４３５、複写機＞）として形式化することができる。役割および機能の集合は既知であり、一般にデータベース構造と密に結合されている（例えばテーブル名または列記述として）。この密結合を利用して、半自動的にビジネスオブジェクトを定義することができる。
【００４０】
＜名称、役割または機能＞の対における名称がオブジェクトの一意の識別子であると仮定する。名称（またはエンティティ名）は、例えば、製品、人またはサービスの名称であってよい。従って、複数のｏｂｊｅｃｔ＿ｉｄが同一の役割または機能を有してもよいが、２個のｏｂｊｅｃｔ＿ｉｄにおいて役割または機能が同一であると同時にエンティティ名が同一であってはならない。通常、データベースの構造化された部分のレコードは、また多くの場合フィールド名および／またはフィールド記述も、オブジェクト＿ｉｄの名称、役割または機能を含んでいる。
【００４１】
これらの概念を例示すべく、複写機の販売またはリースを行い、それらの複写機に対する技術サービスを提供するＡＢ社が、以下のように、３個のテーブルを備えたデータベースを有すると仮定する。
【００４２】
第１テーブル（顧客）
第１フィールド：顧客Ｉｄ
第２フィールド：顧客名
第３フィールド：顧客セグメント
第４フィールド：技術者Ｉｄ
【００４３】
第２テーブル（技術者）
第１フィールド：技術者Ｉｄ
第２フィールド：技術者名
第３フィールド：技術者所属
【００４４】
第３テーブル（調査）
第１フィールド：調査Ｉｄ
第２フィールド：顧客Ｉｄ
第３フィールド：満足度スコア［１−５］
第４フィールド：顧客自由コメント（自由テキスト）
【００４５】
６個のビジネスオブジェクト、すなわち４人の顧客（ＡＣ社、ＤＥ社、ＦＲ社、およびＪ社）と２人の技術者（ナディーン  ドウおよびジョー  ウィルソン）があると仮定する。３個のテーブルは以下の情報をレコードに含んでもよい。
【００４６】
第１テーブル
１９３４６５  ＡＣ社  事務所  ９９０１２
１９３４６７  ＤＥ社  事務所  ９９０１２
１９３４０５  ＦＲ社  大      ９９０１０
１９０４６７  Ｊ社    中      ９９０１０
【００４７】
第２テーブル
３４８５４３  ドウ        マサチューセッツ支店
３４８５４４  ウィルソン  イリノイ支店
【００４８】
第３テーブル
４３５  １９３４６７  ４  「技術者のサービスと複写機の品質に大変満足している。」
４３６  １９３４０５  ２  「おたくの複写機は欠陥品だ！」
等々。
【００４９】
顧客テーブル（第１テーブル）を中心として３個のテーブルを結合することができる。これにより以下のフィールドを有する新しいテーブルが得られる。
【００５０】
新規のテーブル
第１フィールド：顧客Ｉｄ
第２フィールド：顧客名
第３フィールド：顧客セグメント
第４フィールド：技術者Ｉｄ
第５フィールド：技術者名
第６フィールド：技術者所属
第７フィールド：調査Ｉｄ
第８フィールド：満足度スコア［１−５]
第９フィールド：顧客自由コメント（自由テキスト）
【００５１】
従って、このテーブルのレコードは以下のようになる。
【００５２】
１９３４６７  ＤＥ社  事務所  ３４８５４４  ウィルソン  イリノイ支店  ４３５  ４  「技術者のサービスと複写機の品質に大変満足している。」
１９３４０５  ＦＲ社  大  ９９０１０  ドウ  マサチューセッツ支店  ４３６  ２  「おたくの複写機は欠陥品だ！」
等々。
【００５３】
この最後のテーブルは、「ビュー」すなわち仮想的なテーブルとして生成され、以下に述べる例示的な方法の出発点となり得る。このテーブルの最後のフィールドは、顧客のコメント（またはそれへのリンク）を含んでおり、このシナリオにおけるデータベースの非構造化部分である。
【００５４】
本実施形態においては、単にデータベース内の非構造化データの追補に依存するのではなく、テキストはデータベースの構造化された部分への参照を検知、解決、および正規化することにより追補される。これは、テキスト情報の追補された表現に作用することによりテキスト情報へのアクセス方法の性能を向上させる。
【００５５】
構造化データと非構造化データを整合させる際に対処すべき一つの問題として、共参照解決（co-reference  resolution）がある。この場合、共参照解決には、ビジネスオブジェクトを参照可能なテキストフィールド内の表現（参照エンティティ）を検知することと、それらをそのビジネスオブジェクトに関する正規化された情報のいくつかを用いて追補することとが含まれる。特に、参照解決（または参照解析）は、データベースの非構造化部分の参照エンティティと、データベースの構造化された部分の対応するリファレントとの間のリンクの構築に到る。テキスト部分で利用可能な参照エンティティを、データベースの構造化された部分（構造および内容）から導かれるリファレントの集合とマッチングすることができる。従って、リファレントのコンピュータ表現は会話エンティティ（discourse  entity）として機能すべく利用できる。
【００５６】
データベース構造、特に、逐語的テキスト部分がテーブルレコードの列の特定の値として格納されている事実から、データベースのテーブル同士の関係（リンク）を介して、レコードおよび潜在的に関連付けられたいくつかのレコードにおける参照問題を解決するための一方式が自動的に得られる。この問題は通常、複数の異型（variant）と単一のオブジェクトとの間の多対１マッピングに簡約される。
【００５７】
参照エンティティは、例えばｏｂｊｅｃｔ＿ｉｄ（正規化された一意の識別子）によりリンクされているデータベースの参照エンティティまたはセルを拡張することによって、対応する外部情報を用いて追補され、次いでこれを用いて一義的にビジネスオブジェクトを指すことができる。
【００５８】
テキストデータの意図した使用法に応じて、追補を単一のｏｂｊｅｃｔ＿ｉｄからより完全な記述へ、例えば、本明細書において＜＞で表わす１個以上の拡張マークアップ言語（ＸＭＬ）タグを用いる構造化された方法で、あるいはテキスト拡張を介した非構造化方法で拡張することができる。以下の例を用いて、ｏｂｊｅｃｔ＿ｉｄによりデータベースの非構造化部分の追補を説明する。
【００５９】
レコードのあるテキストフィールド内の部分的な名称（姓、名）については、追補にはこれを正しい、正規化された名称および対応する役割を用いて完成させることが含まれる。例えば、「ジョーが修理した…」という句は以下の３通りの方法のいずれによっても追補することができる。
１．ジョー＜Ｔｅｃｈ＿ｉｄ２００９４３＞が修理した…
２．ジョー（＜氏名＞ジョー  シュミット＜機能＞技術者＜地区＞ノースカロライナ、…）が修理した
３．我が社に属する技術者で、ノースカロライナで勤務しているジョーシュミット…
【００６０】
名称以外の役割または機能に言及している場合、ビジネスオブジェクトの名称を加えることにより同様に追補を実行することができる。例えば、「当社の販売担当者はピントがずれている」という句を以下のように追補することができる。
１．当社の販売担当者＜Ｒｅｐ＿ｉｄ３４８９５４３＞はピントがずれている。
２．当社の販売担当者（＜名称＞ナディーン  ドウ，＜機能＞販売担当者，＜Ｒｅｐ＿ｉｄ３４８９５４３＞）はピントがずれている。
３．ナディーン  ドウ，当社の販売担当者，Ｂ３４８拠点所属，はピントがずれている。
【００６１】
図１を参照すると、データマイニング用の例示的な装置１０の機能ブロック図は、コンピュータシステム１２とデータベース１４とを含んでいる。コンピュータシステム１２はデータベース１４を検索して、クエリーに応答するレコード１６に含まれる情報を取得したり、データに対し他の形式の解析を実行することができる。レコードは、複数のフィールド１８（図に示す実施形態では９個のフィールド）に情報を含んでいる。レコード１６は、構造化部分２０と非構造化部分２２とを含んでいる。図に示す実施形態において、最後のフィールド１８は、非構造化部分を含んでいる。所与のクエリーに応答して、部分２０，２２の一方または両方からの情報を当該クエリーに応じて取得することができる。図に示すテーブルは便宜的に、セル内に情報を含んだ規則的な格子として示すが、コンマ等の区切りにより間隔が空けられた情報をセルが含んでもよい点を理解されたい。また、フィールド情報がメタデータに組み込まれていてもよい。
【００６２】
図に示すコンピュータシステム１２はプロセッサ２４を含んでおり、プロセッサ２４は当該プロセッサ２４に接続されているメモリ２６に格納された処理命令を実行することによりコンピュータシステム１２の全般的な動作を制御する。コンピュータシステム１２はまた、ネットワークインターフェース２８およびユーザー入出力インターフェース３０を含んでいる。入出力インターフェース３０は、ユーザーに情報を表示するためのディスプレイ、テキストを入力するためのキーボードまたはタッチスクリーンや書き込み可能スクリーン等のユーザー入力装置、および／または、ユーザー入力情報およびコマンド選択をプロセッサ２４に渡すためのマウス、トラックボール等のカーソル制御機器のうちの一つ以上と通信することができる。コンピュータシステム１０の各種の構成部品は全てバス３２により接続することができる。プロセッサ２４は、クエリーに応答するテキストをデータベースから抽出する等、データベースの内容を解析する命令を実行する。コンピュータシステム１２は、デスクトップ型、ラップトップ型、パームトップ型のコンピュータ等のＰＣ、携帯情報端末（ＰＤＡ）、携帯電話、ポケットベル、またはデータベースを検索可能なその他の通信システムであってよい。
【００６３】
メモリ２６は、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、磁気ディスクもしくはテープ、光ディスク、フラッシュメモリ、またはホログラフィックメモリ等、任意の種類のコンピュータ読み取り可能な媒体を代表している。ネットワークインターフェース２８は、コンピュータを、コンピュータネットワークを介して、例えばローカルエリアネットワーク（ＬＡＮ）や広域ネットワーク（ＷＡＮ）やインターネット等を解して他の装置と通信可能にするものであり、変調器／復調器（モデム）を含むことができる。
【００６４】
データベース１４は、コンピュータシステム１２が接続されているネットワーク３４に関連付けられているもしくはインターネットを介してアクセスされるサーバ等のメモリ、および／または、コンピュータシステム１２がアクセスするメモリ２６やその他のコンピュータ読み取り可能な媒体に格納することができる。
【００６５】
図１に示すように、データベースの非構造化テキスト部分２２は、１つまたは複数のフィールド１８に（直接またはリンクを介して）格納することができる。図に示す実施形態において、最後のフィールドは、別のテーブルに格納されているかまたは情報自体を含む文書にリンクされている非構造化情報３８へのリンク３６（図に示す実施形態ではＫ１，Ｋ２等と付番）を含んでいる。非構造化情報は、情報４２（例えば図に示すＸＭＬタグにより）を用いて追補されている。例えば、参照エンティティ４０（ナディーン）は、正規化された形式のビジネスオブジェクトである本人の担当者ＩＤ番号により追補されている。
【００６６】
同様に、データベース１４の構造化部分２０もまた、情報を用いて追補されている。特に、列フィールド１８（およびオプションとしてフィールド名４７、フィールド記述等も）の個々のセル項目（cell  entry）４４，４６内のリファレントは、ＸＭＬタグ４８，５０として参照するビジネスオブジェクトの正規化された形式により追補されている。
【００６７】
データベースは、関連するデータ（テーブルや自由テキストレコード、またはその一部）の取得を可能にする解析的ツールを用いて、データベースの残りの内容の検索に加えてタグ４２，４８，５０（または他の形式の追補）を検索することにより、マイニング可能である。例えば、図１のデータベースの場合、「Ｒｅｐ＿Ｉｄ３４８５４３且つドウ」のようなクエリーにより、第２レコード１６から情報を取得することができる。追補されたデータベースの他の利用方式も考えられる。例えば、抽出、クラスタリング、カテゴリー化等の古典的なテキストマイニングアプリケーションもここで可能である。これらの古典的データマイニングツールは、データベースの構造化部分と「再構成された」非構造化部分とのユニオン（union）に適用することができる。
【００６８】
ここで図２を参照すると、図１に示すようなデータベース１４を開発する方法を簡略化した形式で示す。本方法は、非構造化データは自身が関係するレコードと既にリンクされているものと仮定する。このステップは、例えばリンクをテーブル（群）に組み込むことにより手動で実行することができる。
【００６９】
本方法はステップＳ１００から始まる。ステップＳ１０２において、ビジネスオブジェクトの集合（set）が識別される。この段階は、オフラインのモデリング段階において手動または半自動のいずれでも実行することができる。本ステップは、関心対象であるビジネスオブジェクト（または概念）の極めて簡単なオントロジーを確立することができる。例えば、データベースの構造化部分２０（図１）（および／またはセル項目４４，４６）の１個以上のテーブルのフィールド名４７を識別して、そのようなビジネスオブジェクトの集合の生成に用いることができる。一例として、図３に簡単なモデル５２を示す。このモデル５２では、データベースの構造化部分２０のテーブルの列（フィールド）ｃ1およびｃ2の列見出し（フィールド名）４７が、指定語５８の集合５４，５６を含んだリファレントモデル５３，５５としてモデル化されたものである。一般に、モデル５２は、そのような集合５４，５６を複数含んでおり、例えば指定語の少なくとも１０個または少なくとも５０個の集合を含んでいる。一般に、所与の集合はわずか１個の指定語５８しか含んでいないが、各々の集合は複数の語句、例えば約２〜１０個の語句を含んでおり、１０個を超える語句を用いる場合もある。本システムは全てのリファレントモデル５３，５５等を組み込んだ単一のビジネスモデル５２に関して記述されているが、複数のビジネスモデルもあり得る点を理解されたい。
【００７０】
ステップＳ１０４において、候補参照エンティティは、データベースの非構造化部分２２のテキスト項目の１個またはその集合内で識別される。参照エンティティ検知フェーズにおいて、テキストチャンクは、候補参照エンティティ、すなわち１個以上のビジネスオブジェクトを参照できる参照エンティティとして識別され、且つそのようにする旨が決定されたならば、続いて、参照されたビジネスオブジェクトにリンクする情報を用いてこれらのチャンクを追補する。新たなレコードがデータベースに追加されるに伴なって、本ステップは繰り返されてよい。一例として、図４に、候補参照エンティティ６０が強調表示されているデータベースのテキスト部分２２のテキスト項目Ｋ３を示す。
【００７１】
ステップＳ１０６すなわち参照解決ステップにおいて、ステップＳ１０４で識別された候補参照エンティティ６０とステップＳ１０２で識別されたモデル化ビジネスオブジェクト５４，５６との類似度が計算される。類似度は、抽象的なレベル（ビジネスオブジェクトの役割または機能等）またはインスタンス生成されたレベル（instantiated  level）（製品名や人名等）で、あるいは両者の組合せにより計算することができる。類似度の計算に基づいて、テキストチャンク（候補参照エンティティ６０）が１個以上のビジネスオブジェクトを参照する（または場合によりビジネスオブジェクトを全く参照しない）ことが決定される。上述のように、各レコードは、限られた数のビジネスオブジェクトしか包含または参照しない。また、各々のテキスト項目には、リンクを介して、単一のレコードが関連付けられているか、または比較的限られた数のレコードが関連付けられている場合がある。このことが多義性解消の前提となる。具体的には、類似度は、全てのビジネスオブジェクトではなく、候補参照エンティティが見つかったテーブルのテキスト項目と同一レコードに関連付けられたビジネスオブジェクトのモデルについて計算することができる。このように、候補参照エンティティの類似度は、モデル化されたビジネスオブジェクト全体の部分集合（subset）だけに対する類似度の計算を含んでいる。
【００７２】
ステップＳ１０８において、ビジネスオブジェクトを参照していることを計算された類似度が示すテキストチャンク６０が、参照するビジネスオブジェクト（群）に当該チャンクをリンクさせる情報４２を用いて追補される。要求する情報のレベルに応じて、これは単一のオブジェクトＩＤ、ＸＭＬタグ、またはテキスト拡張を含んでもよい。
【００７３】
ステップＳ１１０において、リファレント４４，４６は、対応するビジネスオブジェクトの正規化された形式で構成されたタグ４８，５０等の情報を用いて追補することができる。
【００７４】
ステップＳ１１２において、追補されたレコードはデータベースに格納される。本方法はステップＳ１１４で終了する。
【００７５】
これらのステップの各々を実行する例示的な方法について以下に詳述する。
【００７６】
以下に、オフラインビジネスオブジェクトモデリングについて説明する。
【００７７】
ステップＳ１０２（図２）は、関心対象であるビジネスオブジェクトの簡単化されたオントロジーを生成する。生成されるオントロジーはビジネスオブジェクトモデル５２（図３）を構成する。本モデルにおいて、構造化データベースのレコード内の各リファレントには、一意のビジネスオブジェクトｉｄと共にその役割および／または機能を記述している、ビジネスオブジェクト（またはリファレント自体がビジネスオブジェクトでない場合は当該リファレントが参照するビジネスオブジェクト）の語句の整理されたリストが関連付けられる。
【００７８】
本プロセスの第１のステップ（ステップＳ１０２Ａ）は、テーブルの選択と、参照解決の潜在的な情報源すなわちビジネスオブジェクトであり得るデータベースの構造化部分２０のフィールド１８の部分集合（subset）との選択を含むことができる。例えば、図１に示すテーブルではフィールド１〜６が選択されている。以下の説明ではリファレントとしてフィールド名４７に焦点を当てるが、セル項目４４，４６および／またはフィールド記述等、他の情報も考慮できる点を理解されたい。フィールドは、ビジネスオブジェクト（リファレント）の構造化された表現と考えることができる。列（ｃ1、ｃ2等）が選択されたならば、リファレントモデル５３，５５（図３）を各フィールド１８またはセル項目４４に関連付けることができる（ステップＳ１０２Ｂ）。このステップは、手動、自動、または半自動的に実行することができる。リファレントモデル５３，５５は、例えば、指定語５４、５６のリスト、指定語の順序付きリスト、または指定語の重み付きリスト（図３のｗｔ1、ｗｔ2等は重みを表わす）であってよい。これらの重みは、指定語がビジネスオブジェクトに関連する度合いを反映することができる。ビジネスオブジェクトを最も正確に記述する指定語に対してより大きい重みを与えてよい。
【００７９】
指定語はフィールド名４７であってよく、フィールド記述として表示してもあるいはテーブルメタデータに組み込まれていてもよい。フィールド名がコード、省略形である場合および／または自明でない場合、指定語は対応する非省略語（省略等の無い語句）であってよい。特にコード、省略形、および自明でないフィールドの場合、この初期化プロセスに人間が介入して誘導してもよい。例えば、列ｃiのフィールド名４７から始まって、いくつかの指定語を手動でそのモデルＭ（ｃj）に追加することができる。次いで語彙集を用いて、例えば、既にモデルＭ（ｃj）に含まれている語句の１個以上の類義語、下位語、上位語、部分語および全体語を考慮することにより、モデルを拡張することができる。適切な比較可能コーパスが利用できる場合、モデルの意味論的な追補は統計的文脈共起解析（statistical  contextual  co-occurrence  analysis）に基づくこともできる。その結果は、指定語（恐らくは、例えば初期のビジネスオブジェクトとの関連の度合いに応じて重み付けられる）の集合５４，５６、ビジネスオブジェクトのベクトル表現、またはより複雑な表現となろう。例えば、フィールド名「プリンタ」は、ビジネスオブジェクトＩＤ＜ＡＢ１００、プリンタ＞）によって、あるいは装置の種類に応じて以下の上位語、プリンタ、複写機、多機能装置の一つによって、拡張することができる。また、部分語、すなわちそれの構成部品の製品名、例えばＸＲフューザ、ＭＢ−Ｘプロセッサ、Ｆ１００用紙トレイ等によって拡張することができる。ＡＢ１００プリンタの製品マニュアル等で用いられている名称等の類義語もまた、モデル５２に含まれていてもよい。フィールド内の情報（例えばセル項目４４，４６）もまたこのように拡張することができる。
【００８０】
このプロセスは、データベースの構造化部分２０の選択されたフィールド名４７の各々について繰り返されてよい。この段階の終了時点で、リファレントモデル５３，５５のファミリーが生成され、その各々がデータベース内にリファレントを有するビジネスオブジェクトに関連している。
【００８１】
以下に、参照エンティティの検知について説明する。
【００８２】
データベースのテキスト部分２２のフィールド内の参照エンティティ６０の識別に際して各種の方法を用いてもよいが、これらはデータベースのテキスト部分のテキスト項目の種類に部分的に依存しよう。
【００８３】
第１のステップ（Ｓ１０４Ａ）には、テキスト項目内の特定の文の拡張が含まれていてもよい。テキスト部分におけるテキスト項目が、対応する調査の質問から識別できる暗黙の質問に対する逐語的な回答である場合が多い。従って、質問からの情報を用いて回答を拡張することができる。例えば、質問には製品名や人名が含まれていて、それをテキストフィールドの追補に用いることができる。従って、テキスト部分の拡張は、単純な連結および／または質問の再構築により実行することができる。例えば、質問を疑問文から肯定文に変え、次いで連結することができる。
【００８４】
識別における第２のステップ（Ｓ１０４Ｂ）は、候補参照エンティティとしてテキスト項目（ステップＳ１０４Ａで拡張されたような）のテキストチャンクの抽出を含んでいてもよい。パーサ（parser）を用いてテキスト項目からテキストチャンクを抽出することができる。適当なパーサとして、米国特許出願公開第２００５／０１３８５５６号および第２００３／００７４１８７号に開示されている。パーサは通常、よく知られているいくつかのステップを実行し、それにはテキスト内の単語の識別（トークン化）、単語とその形態的形式（群）（morphological  form(s)）（形容詞、名詞、動詞等）の関連付け、および名詞句、形容詞句等の語句の識別が含まれる。パーサはまた、後の段階で語彙集を参照することにより名称を付けられたエンティティを抽出することができる。上述の類義語、上位語／下位語および全体語／部分語等の意味論的等価物の識別のように各種形式の拡張を適用することができる。
【００８５】
また、ステップＳ１０４Ｃすなわち内部文書（intra-document）の標準技術において、同一参照解決（co-reference  resolution）を採用することができる。このステップは、特に、テキスト項目内の代名詞の前方照応（anaphora）および後方照応（cataphora）を解決（または解析）することにより、可能な限り多くの参照を解決（または解析）すべく実行される。例えば、パーサは、図３に示す例示的な電子メールにおける「それら」がテキスト項目内の「プリンタ」を参照することを検知できる同一参照モジュール（co-reference  module）を含むことができる。この場合、代名詞「それら」は名詞「プリンタ」への代名詞後方照応リンク６２（および拡張により、ＡＢ１００プリンタへのリンク）にタグ付けされる。同様に、代名詞「それらの」は代名詞前方照応リンク６４にタグ付けされ、この場合は名詞「プリンタ」にもタグ付けされる。
【００８６】
これらオプションの拡張および同一参照解決ステップの後、ステップＳ１０４Ｄにおいて、潜在的外部参照（potential  external  reference）を有するテキストチャンクを識別することができる。これはエンティティ抽出と称する。本ステップの一要素として、探索空間を減らすことにより後続のステップの効率を上げるために、テキストのありふれた（例えば機能語）または無関係な部分を除去しようと試みる点が挙げられる。一実施形態において、候補参照エンティティとして名詞句（ＮＰ）だけを考える。本明細書で用いる名詞句とは、少なくとも１個の名詞と名詞を説明する任意の関連した形容詞とからなる語句を含んでいる。関連付けられた形容詞が無い場合、名詞句は単に１個の名詞または名詞群で構成されることになる。このように、図１の例示的な電子メールＫ３において、以下のテキストチャンクを考えることができる。ナディーン；新機種ＡＢプリンタ、当社（ＡＣ社への代名詞後方照応リンク）；１月；それら（ＡＢプリンタへの代名詞後方照応リンク）；ＸＲ部品；ジーン；ＡＣ社。
【００８７】
一実施形態において、他の句（動詞句等）は無視される。従って、ステップＳ１０４Ｄは簡単なＮＰ抽出を含むことができる。ここでテキストレコードの内容は、一時的にメモリに格納できる名詞句の順序付きリストに簡約される。参照解決ステップをより簡便且つ確実（robust）にすべく、ＮＰの正規化（例えば見出し語化（lemmatized））された形式を追加的または代替的に格納することができる。ＮＰ抽出機能は往々にして、名詞句を認識可能になる前に何らかの形態素解析（morphological  analysis）および品詞のタグ付けを行なう必要があるため、一切の追加的処理を必要としない。このように、見出し語化されたＮＰ新機種ＡＢプリンタは追加的または代替的にリストに格納される。
【００８８】
精緻化により、更なる名詞語句を識別することができる。例えば、人名の場合、ＮＰ「ナディーン  ドウ」を与えられた場合に、識別された追加的な名詞句は「Ｎ．ドウ」、「ドウ、ナディーン」、「ドウ」等を含んでもよい。
【００８９】
識別されたＮＰが実際に以下の場合の一つに対応するものと仮定することができる。
（ａ）ＮＰは、関心対象であるどのビジネスオブジェクトをも参照しない。
（ｂ）ＮＰは、正規化された形式が同一レコードまたはリンクされたテーブルの他のレコードのあるフィールドに含まれているビジネスオブジェクトの特定のインスタンスを参照するエンティティ名（人名、製品名等）であり、例えば、役割または機能が列（フィールド）名であり、またはより正確にはこの列に関連付けられたモデルである。
（ｃ）ＮＰは、エンティティ名ではなく、（多くの場合、明確な形式の）普通名詞に基づく表現であって、役割または機能に関連しており、且つモデルにより拡張されたビジネスオブジェクト（抽象レベル）の表現に極めて類似していることが予想される。
【００９０】
本ステップの終了時点において、考慮しているテーブルの各レコードの各テキストフィールドについて（正規化または見出し語化された）候補参照エンティティのリストが一連の識別されたＮＰの形式で得られている。
【００９１】
以下に、参照解決について説明する。
【００９２】
本ステップ（ステップＳ１０６）では、各々のレコードｒ1、ｒ2のデータベースのテキスト部分２２内の各テキストフィールドについて、候補参照エンティティを、ビジネスオブジェクトのモデルまたはこれらのオブジェクトの（正規化された）インスタンスのいずれかに整合（match）させることを試みて、同一レコード（または恐らくはリンクされたテーブルの関連するレコード）のデータベースの構造化部分の関連する行のインスタンス（値）に範囲を制限する。レコードは多義性解消の範囲を定めるための前提を自動的に与えることを理解されたい。実際、１個のレコードはビジネスオブジェクトの既知且つ固定された集合を扱う。
【００９３】
より正確には、Ｌ＝｛ＮＰ1，ＮＰ2，．．．，ＮＰn｝を、レコードｒの現在のテキストフィールドに対する候補参照エンティティＮＰjのリストとする。Ｍ＝｛Ｍ1，Ｍ2，．．．，Ｍn｝を、それらのモデルＭ（ｃi）に含まれているビジネスオブジェクトＭiのリスト（抽象レベルにおける、すなわち役割、機能）とする。モデルＭ（ｃi）内の各ビジネスオブジェクトＭi（またはより厳密にはその抽象インスタンス）には、データベースの構造化部分を参照する列インデックスｃiが関連付けられている。ＮＰjはＭiと比較される（ステップＳ１０６Ａ）。ＮＰjはまた、ｖａｌ（ｒ，ｃi）すなわちレコードｒのフィールドｃiの内容（または、例えば最初のｃjセル項目がＩＤ番号である場合は、他のリンクされたテーブルの関連フィールドの内容）と比較される（ステップＳ１０６Ｂ）。このように、例えば、図１に示すテーブルにおいて、テキスト項目Ｋ１からのＮＰ「技術者」（またはその追補された形式）を、指定項目の１個として機能「技術者」を含んでいる可能性のある同一レコードの第５フィールドの内容すなわち「ウィルソン」およびモデルＭｃ5と比較する。
【００９４】
この比較は、最小編集距離と同様に、余弦類似度、文字列カーネル、またはより一般的なカーネル等の類似度を用いて実行することができる。最小編集距離すなわちレーベンシュタイン（Ｌｅｖｅｎｓｔｅｉｎ）距離は、ＮＰj等の文字列（例えば文字、数字およびスペース）を別の文字列、ここではＭj、に変換するために必要な挿入、置換、および削除の回数を計算する。文字列カーネルは、文字が完全に連なっていない場合でも、文字列同士の類似度を認識する能力を提供する。文字列カーネルに関する更なる議論は、ロディ（Ｌｏｄｈｉ）他、「文字列カーネルを用いるテキスト分類」（ニューラル情報処理システムの発展１３（ＭＩＴプレス（２００１年））、およびカンセッダ（Ｃａｎｃｅｄｄａ）他「単語シーケンスカーネル」（マシンラーニング研究ジャーナル、３：ｐｐ．１０５９〜１０８２（２００３年２月））に開示されている。
【００９５】
類似度の定義は、単純な文字列マッチングテストから、より確実な（robust）内容類似度まで、任意の適当な尺度であってよい。例えば、一実施形態において、リファレントにはモデルＭ（ｃi）において指定語（単語または多単語表現）の重み付きリストおよび以下のように計算される類似度が関連付けられている。
ｓｉｍ（ＮＰj，Ｍ（Ｃi））は、ＮＰｊから少なくともｘ％の相対編集距離にあるＭ（ｃi）の指定語の最大重みに等しい。ここに、ｘ％は例えば７０％、８０％、または９０％等である。
ｓｉｍ（ＮＰj，ｖａｌ（ｒ，ｃi））は、ｖａｌ（ｒ，ｃi）が往々にして固有名詞の連続（sequence）であるので、より複雑な類似度となる傾向があり、固有名詞の連続を参照する場合、ＮＰjは当該連続のうちの一部（例えば人の氏名の名前部分）のみ使用する。
【００９６】
ｓｉｍ（ＮＰj，Ｍ（ｃi））を計算する際、相対編集距離は、最初に２個の文字列間の古典的編集距離（具体的には、ＮＰjをＭ（ｃi）の指定語に変換するための置換、削除等の最少回数）を計算することにより決定することができる。古典的編集距離は次いで、比較したい文字列の平均長により除算されて相対的な編集距離が導かれる。
【００９７】
以下のアルゴリズムを用いて、上述の外部参照課題を解決することができる。
For  r=1…number  of  records；
For  f=1…number  of  textual  fields；
For  j=1…number  of  candidate  referring  NP  in  field  f  of  record  r；
Maxsim=0；
For  m=1…number  of  business  concepts；
Compute  s=sim(arfj,Mm)；  note  arfj  is  the  NPj  of  field  f  from  record  r  and  Mm  is  the  model  associated  with  concept  m；
If  s>Maxsim：  [  Maxsim=s；  bus_obj=  m  ；  refer_to  =  role]；
Compute  s=sim(arfj,val(r,cm))；  note  val(r,cm)  is  the  value  of  the  cell  content  (cell  row  r  and  column  cm)；
If  s>Maxsim：  [  Maxsim=s；  bus_obj  =  m  ；  refer_to  =  name]；
Endfor  m
If  Maxsim>threshold：
Link  arfj  with  <bus_obj(arfj),  refer_to(arfj)>；
ElseLeave  arfj  alone  (i.e.,  decide  that  this  NP  does  not  refer  to  a  business  object)；
End
Endfor  j
Endfor  f
Endfor  r
【００９８】
なお、上記アルゴリズムは概説すれば次の通りである。
ｒ＝１〜レコードの数；
ｆ＝１〜テキストフィールドの数；
ｊ＝１〜レコードｒのフィールドｆ内でＮＰを参照する候補の数；
Ｍａｘｓｉｍ＝０；
ｍ＝１〜ビジネス概念の数；
ｓ＝ｓｉｍ（ａrfj，Ｍm）を計算する；ａrfjがレコードｒからのフィールドｆのＮＰjであり、Ｍmは概念ｍに関連付けられたモデルであることに注意；
ｓ＞Ｍａｘｓｉｍの場合：｛Ｍａｘｓｉｍ＝ｓ；ｂｕｓ＿ｏｂｊ＝  ｍ；ｒｅｆｅｒ＿ｔｏ＝役割｝；
ｓ＝ｓｉｍ（ａrfj，ｖａｌ（ｒ，ｃm））を計算する；ｖａｌ（ｒ，ｃm）がセル内容（セル行ｒおよび列ｃm）の値であることに注意；
ｓ＞Ｍａｘｓｉｍの場合：｛Ｍａｘｓｉｍ＝ｓ；ｂｕｓ＿ｏｂｊ＝ｍ；ｒｅｆｅｒ＿ｔｏ＝ｎａｍｅ｝；
ｍについて終了
Ｍａｘｓｉｍ＞ｔｈｒｅｓｈｏｌｄの場合：
ａrfjを＜ｂｕｓ＿ｏｂｊ（ａrfj），ｒｅｆｅｒ＿ｔｏ（ａrfj）＞にリンクする；
上記以外の場合ａrfjを変えない（すなわち、このＮＰはビジネスオブジェクトを参照しないものとする）；
終了
ｊについて終了
ｆについて終了
ｒについて終了
【００９９】
本ステップの終了時点において、参照エンティティａrfjとビジネスオブジェクトｂｕｓ＿ｏｂｊ（ａrfj）との間に一群のリンクが得られている。参照エンティティは、役割／機能またはオブジェクト自体の名称のいずれかを参照すべく指定されている。これは、付随するｒｅｆｅｒ＿ｔｏ（ａrfj）値により示される。この値は「名称」または「役割」のいずれであってもよい。
【０１００】
以下に、追補について説明する。
【０１０１】
参照分析が実行されたならば、本ステップは比較的簡単である。本ステップは、先のステップ（Ｓ１０６）で参照エンティティａrfjにリンクされたビジネスオブジェクトｂｕｓ＿ｏｂｊ（ａrfj）から導くことができる情報を含むことによる、データベースのテキストフィールドへの追補を含んでいる（ステップＳ１０８）。例えば、ｃをｂｕｓ＿ｏｂｊ（ａrfj）に関連付けられた列とする。次いで、追補されたデータベースを後で利用するのに適した仕方で、参照エンティティを追加情報として＜ｖａｌ（Ｒ，ｃ），ｂｕｓ＿ｏｂｊ（ａrfj）＞にタグ付けまたは別途追補する。一般に、ｖａｌ（Ｒ，ｃ）は、インスタンス生成されたビジネスオブジェクトを指定する正規化された方法且つ一意の識別子（すなわちビジネスオブジェクト名）であってよく、一方、ｂｕｓ＿ｏｂｊ（ａrfj）は役割または機能を指定する。追補には「正規化」、すなわちテキストチャンクを正規化された（より基準的または標準化された）形式で代替することも含まれ得る点に留意されたい。標準形式は一般に、データベースの構造化部分により与えられる。正規化は、優れた検索または解析性能を得るのに役立つ。
【０１０２】
別の形式の追補として、マッチングが見出されたテーブルのフィールドへの参照によるテキスト部分への注釈付けが含まれていてもよい。
【０１０３】
一実施形態において、例えば、リンクされた別のテーブルでビジネスオブジェクトも参照されている場合、データベースのテキスト部分２２は更に追加的な情報を用いて追補される。例えば、ｖａｌ（Ｒ，ｃ）が外部キーとして機能すると共により有用且つより詳細なテーブルの主キーであるＩＤ番号以外の何物でもない場合である。
【０１０４】
既に述べたように、上記追補をどのように編成するかは、以後の処理および索引付けの仕組みに依存し得る。ＮＰの直後に位置するＸＭＬタグは一つの解であるが、生成された自然言語テキストチャンクをＮＰの周辺にまたはこれを代替して挿入し得ることも考えられる。この自然言語記述は、何らかの標準的な方法によって概念記述から導くことができ、その際にいくつかのフィールドがインスタンス生成された値が記入される。
【０１０５】
以下の非限定的な例は、顧客満足アンケートへの回答を含むテキスト部分を、顧客情報のテーブルを含む構造化データに組み込み可能にするデータベースの開発を説明するものである。
【０１０６】
本例では、顧客情報および製品に関する情報を含む構造化データがデータベースに格納されている。追補する非構造化データとして、電子メール形式、ＯＣＲされた文書等による一般的な満足度アンケートに対する顧客の回答が使用された。アーキテクチャは、ＤＢＭＳとしてＭｙＳＱＬを用いてパイソン（Ｐｙｔｈｏｎ）に実装された。本例では、４個のテーブルを用いた。そのうちの２個のテーブルが構造化された入力データ、参照解決を見出すために使用される外部情報源（以下フィラーデータ（Filler  Data）と呼ぶ）を含んでいる。別の１個のテーブルは、追補されるテキストデータ（以下フォームデータ（Form  Data）と呼ぶ）を含んでいる。本方法で生成される第４のテーブルは、フォームデータのレプリカであり、そのテキストデータが追補内容を含んでいる。
【０１０７】
第３レコード内のフォームデータは、これが未加工テキストを含んでいないが、品詞にタグ付けされた（ＰＯＳタグ付き）単語（すなわち、名詞、代名詞、形容詞、動詞等の文法機能に既にタグ付けされている単語）を含むチャンクを含む意味において前処理された。
【０１０８】
図５に、ビジネスオブジェクトのモデル化ステップ（図２のステップＳ１０２に対応）におけるステップを示す。本方法はステップＳ２００から始まる。ステップＳ２０２において、テーブルの列番号Ｎが読まれる。ループカウンタが０に設定される（ステップＳ２０４）。ループカウンタがＮより小さい間、列の名称が読まれる（ステップＳ２０６）。ステップＳ２０８において、名称が拡張される（ステップＳ１０２Ｂと同様）。このステップは図６により詳細に示して後述する。ステップＳ２１０において、拡張の結果が指定語の拡張リストに格納される。ループカウンタが加算され、テーブル内の全ての列が処理されるまでステップＳ２０６〜Ｓ２１０が繰り返される。本方法は次いでステップＳ２１２へ進み、拡張リストに格納されたリファレントモデルに追加された新たな指定語を受理するかまたは拒否するかをシステムのオペレータに尋ねる。ユーザーは、いくつかの指定語の削除を選択してもよい。残りの指定語（要素）は、追補テーブル（第４テーブル）に格納される（ステップＳ２１４）。これらのステップは、全てのリファレントモデルがユーザーにより検証されるまで繰り返される。複数のテーブルに同一の列記述が存在する場合、先に生成されたリファレントモデルを第２および後続のオカレンス用に利用することができる。
【０１０９】
全てのリファレントモデルが追補テーブルに格納されたならば、本方法はステップＳ２１６へ進み、ここで新規のループカウンタがフォームデータのフォームの数を数える。後述するように、フォームデータは次いで、図７（ステップＳ１０４に対応）に示すように拡張される。
【０１１０】
図６を参照すると、拡張ステップＳ２０８は、ステップＳ３００から始まり、ステップＳ３０２へ進んで、列のＮＡＭＥ（列記述）を読む。ステップＳ３０４において、ＮＡＭＥの類義語および下位語がＷｏｒｄＮｅｔから取得される。その結果はローカル候補語リストとして格納される（ステップＳ３０６）。ステップＳ３０８において、ローカル候補語リストを調べてそれが空であるか（すなわちＷｏｒｄＮｅｔから全く語が取得されなかった）否かを判定する。空である場合、ＮＡＭＥが自然言語によるものか否かをユーザーに尋ねる（ステップＳ３１０）。ユーザーはステップＳ３１２でＹＥＳと答えて、ユーザーが知っている追加的な用語を提供してよい。その場合、ＮＡＭＥ（および任意の追加された用語）はステップＳ３０４に返される。ユーザーがステップＳ３１２でＮｏと答えた場合、本方法はステップＳ３１４へ進み、そこでユーザーにＮＡＭＥ用の別の単語を尋ねる。例えば、ＮＡＭＥは頭字語または省略形であってよく、ユーザーは非省略語を入力する。本方法はステップＳ３０４に戻ってユーザーが追加した語（群）を処理する。ステップＳ３０８において、ローカル候補リストが１個以上の用語を含んでいる場合、ステップＳ３１６で当該リストをユーザーに提示することができる。ＮＡＭＥ自体がローカル候補リストに追加される（Ｓ３１８）。ＮＡＭＥおよび任意の新規ローカル候補が拡張リストに格納される（ステップＳ２１０（図５））。
【０１１１】
図７を参照すると、フィラーデータの拡張（ステップＳ１１６）は、ステップＳ４００から始まる。ステップＳ４１０において、フィラーデータを読んで、誰（すなわちどの顧客）がフォームデータ内にフィラーデータを生成したかを判定する。フォームデータは、データベースの非構造化部分となる。データベースに挿入すべく、フォームデータが関係する特定のレコードはこのように本ステップで識別される。ステップＳ４１２において、情報が、記入されたデータに格納される。ステップＳ４１４において、顧客により記入されたデータが読まれて、フィラーデータに格納される（Ｓ４１６）。具体的には、顧客により記入されたデータが読まれて、当該フォームからの未加工テキストが抽出される。次いでこれがデータベース内の適当なフィールドに非構造化データとして格納される。ループカウンタを用いて、フィラーデータ内のテキスト文字列を順次調べ（Ｓ４１８）、これをトークン化して（Ｓ４２０）、ＮＰ結果を単語リストに格納する（Ｓ４２２）。本例ではより複雑な拡張は実行されなかった。
【０１１２】
本例では、チャンクは入力としてＰＯＳタグ付けされている。ステップＳ４２４において、ＰＯＳタグを取り除くことができる。単語リストを精緻化して、識別された名詞句の可能な入れ替えを生成することができる（ステップＳ４２４）。チャンク内の単語のあらゆる可能な並べ替え（固有名詞のみを含むチャンクの場合）を生成することができる。また、初期チャンクから全ての可能な形容詞の組合せを除去することにより、チャンクのサブチャンクを含む文字列を構築することができる。仕上げられた単語リスト内の全ての単語をループカウンタを用いて順次調べるべく、ステップＳ４２８において、単語をフォームデータ内の語と比較する。マッチングが見つかった場合、その結果は結果リストに追加される（ステップＳ４２８）（簡便のため、類似度関数は単純なｙｅｓ／ｎｏマッチングとした）。どの語ともマッチングが見出されなかった場合（ステップＳ４３０）、その情報もまた注記される。次の単語リストを調べる（ステップＳ４３４）。全ての単語が調べられたならば、フォームのコピーは、マッチング結果に対応する追補情報と共にフォームのレプリカに格納される（ステップＳ４３６）。本方法はステップＳ４３８で終了する。
【図面の簡単な説明】
【０１１３】
【図１】構造化および非構造化（テキスト）文書を含むデータベースを検索するシステムの機能ブロック図である。
【図２】構造化および非構造化データを整合させる例示的な方法のフロー図である。
【図３】データベースの構造化部分の例示的なビジネスモデルを示す説明図である。
【図４】データベースの非構造化部分の拡張を示す説明図である。
【図５】図２のビジネスモデルを構築する例示的な方法のフロー図である。
【図６】図２のビジネスモデルを構築する例示的な方法のフロー図である。
【図７】図２のビジネスモデルを構築する例示的な方法のフロー図である。
【符号の説明】
【０１１４】
１０  データマイニング装置、１２  コンピュータシステム、１４  データベース、１６  レコード、１８  フィールド、２０  構造化部分、２２  非構造化部分、２４  プロセッサ、２６  メモリ、２８  ネットワークインターフェース、３０  入出力インターフェース、３２  バス、３４  ネットワーク、３６  リンク、３８  非構造化情報、４０  参照エンティティ、４２  情報、４４，４６  セル項目、４７  フィールド名、４８，５０  ＸＭＬタグ、５２  モデル、５３，５５  リファレントモデル、５４，５６  指定語の集合、５８  指定語、６０  候補参照エンティティ、６２  リンク、６４  代名詞前方照応リンク。
【図１】
2008033931.tif 000003
【図２】
2008033931.tif 000004
【図３】
2008033931.tif 000005
【図４】
2008033931.tif 000006
【図５】
2008033931.tif 000007
【図６】
2008033931.tif 000008
【図７】
2008033931.tif 000009