JP5697172B2 - 情報ストリームの情報を処理する方法およびシステム - Google Patents

Description

本発明はコンピュータプログラムおよびシステムの分野に関し、より詳細には、エンティティに関係し、かつ情報ストリームに含まれる情報の管理に関する。

Ｗｅｂ検索エンジン（Ｇｏｏｇｌｅ（登録商標）、ＭＳＮ（登録商標）ｓｅａｒｃｈ、ＡｌｌＴｈｅＷｅｂ（登録商標）など）は、ユニークなインデックスから情報レコードにアクセスする方法を提供している。この目的のために、検索エンジンは新しいコンテンツを見つけるために最初にＷｅｂをクロールする。次に、コンテンツがインデックス作成される。すなわち、コンテンツが構造解析され、ストアされて高速かつ正確な情報検索を容易化する。そのあと、ユーザは結果を得るために検索エンジンに問い合わせを行い、その検索結果は一般にリストの形で提示されている。

Ｗｅｂをクロールすることは困難なタスクである。事実、Ｗｅｂクローラは大量のデータに直面し、Ｗｅｂの全コンテンツをダウンロードすることができない。さらに、Ｗｅｂのコンテンツは絶えず変更されている。このダイナミック性は、Ｗｅｂクローリングでは新しいコンテンツが追加されたかどうかを定期的にチェックしなければならず、また既知のコンテンツが更新されたかどうか、あるいは削除されたかどうかもチェックしなければならないことを意味している。そのために、Ｗｅｂクローラは、膨大な計算リソースを必要とする複数のプロセス処理を実行するだけでなく、コンテンツがフェッチされてＷｅｂクローラに送信されるときにネットワークバンド幅を消費している。

この目的のために、キャッシングシステムが開発され、上記に挙げた制約を緩和している。キャッシングシステムは以前に見た情報のバージョンをストアして、その情報が問い合わされて表示される必要があるときのレスポンスタイムを改善している。例えば、Ｗｅｂキャッシュは、ＷｅｂブラウザおよびＷｅｂプロキシサーバによって採用され、ＷｅｂページなどのＷｅｂサーバからの以前のレスポンスをストアする。Ｗｅｂキャッシュは、キャッシュに以前にストアされた情報を頻繁に再使用し、ネットワーク上を送信する必要のある情報量を低減している。さらに、キャッシングはＷｅｂのユーザの応答性を向上するのに役立っている。しかし、ＷｅｂキャッシュはＷｅｂクローラによって検索された膨大な情報量を処理するのに適していない。事実、Ｗｅｂクローラは、クローラを通るデータのコピーをストアしているが、ストアされたデータを管理する手段も、ストレージコストを低減する手段も提供していない。

特許文献１は、イベントオブジェクトとも呼ばれる、見つかったエンティティが関係するイベントに関する情報を抽出するシステムを開示している。この特許文献は、アーティクルを一度フェッチし、そのあと一回の処理のためにローカルにストアすることを教示している。各アーティクルは既存の環境モデルを使用して一度処理され、特定のシステム実装に関する特定の業界別の焦点に従って、関心のないコンテンツをフィルタリングで除去している（例えば、取り除いている）。イベント処理制御プログラムは、その環境モデルに定義されたエンティティとは無関係のフェッチしたアーティクルをフィルタリングする。その結果として、この解析システムは、検索した情報の大部分（例えば、９９％またはそれ以上）を除去してから新しいアーティクルにイベント検出エンジンを適用する。

しかし、フェッチしたアーティクルはシステムによって保存されていない。つまり、このことは、例えば、アーティクルが更新され、再処理する必要があるときそのアーティクルが再度フェッチされることを意味している。従って、システムは、同じ（または類似）
コンテンツを何度もダウンロードする必要がある。

特許文献２は、どのようにして構造化データおよび非構造化データを、複数のデータソースからキャプチャスキーマに抽出し、非構造化データを変形し解析して、それを解析スキーマにロードするかを教示している。この特許文献は、どのようにして非構造化データおよび構造化データの構造化ビューを提供し、例えば、そのデータに対して解析〈例えば、ビジネスインテリジェンス〉を実行するかを教示している。しかし、この特許文献は、どのように新しいリソースの作成をデータで管理し、新しいビジネスデータおよび既に見たビジネスデータに対するこれらの変更を管理するかの問題に取り組んでいない。

従って、簡単に上述した既存のソリューションの制約によれば、データの再処理およびストアされたデータ量を低減するために、情報セグメントをより効率的な方法で管理する改善された情報処理が要求されている。

米国特許第７，５２３，１３７号明細書 米国特許出願公開第２００７／００１１１７５号明細書

従って、本発明は、エンティティに関係する情報であって、そのエンティティが情報ストリームに含まれる情報を処理するコンピュータ実装プロセスを提供する。このエンティティはシステムのリソースディレクトリに含まれ、各リソースディレクトリはエンティティを含み、少なくとも１つの新しいエンティティの追加後に、変更されたバージョン番号で注釈を付ける。本プロセスは、
異なる情報ソースから情報ストリームを検索するステップと、
情報ストリームからの情報セグメントをリソースディレクトリのエンティティに従って処理するステップと、
前記リソースディレクトリのどのバージョンが使用され、前記情報セグメントを処理するのかを示す注釈と共に情報セグメントをストアするステップと、
前記リソースディレクトリの少なくとも１つを少なくとも１つの新しいエンティティで更新すると共に前記少なくとも１つのリソースディレクトリのバージョン番号を更新するステップと、
前記情報セグメントがその少なくとも１つのリソースディレクトリの以前バージョンで処理されたことを示す注釈を含む、ストアされた情報セグメントを再処理するステップと、
を含んでいる。

また、本プロセスは、
リソースディレクトリに追加された新しいエンティティであって、前記リソースディレクトリは前記追加された新しいエンティティの追加と共に一度変更された前記リソースディレクトリに付けられたバージョン番号を示す注釈を含むものであって、再処理するステップは、ストアされた情報セグメントを前記リソースエンティティに追加された新しいエンティティに従って再処理することさらに含んでいるものと、
各処理された情報セグメントと各エンティティとに割り当てられたユニークＩＤを含み、
各新しいエンティティに割り当てられたユニークＩＤは前記新しいエンティティを明らかにした処理されたセグメントのＩＤと同じであり、
情報ストリームから情報セグメントを処理するステップにおいて、新しいエンティティはユーザによって明らかにされるか、または入力されて、対応するリソースディレクトリ内に追加され、
処理された情報セグメントはデータ構造であり、
処理された情報セグメントはタイプ、オプションのユニバーサルリソースＩＤ、および制約なしメタデータのセットを含み、各メタデータはキーと値のペアを含み、
情報ストリームからの処理された情報セグメントは選択した情報ソースに従ってストアされ、
ストリームから情報セグメントを処理するステップに先立って、検索した情報ストリームをマッパキュー内に割り当てるステップであって、そのマッパキューは情報ストリームの情報ソースに従って選択されて、ｍａｐ−レデュースメカニズムによって処理されるものを含み、
情報ストリームから情報セグメントを処理するステップのあと、
処理された情報ストリームをレデューサキュー内に割り当てるステップであって、そのレデューサキューは情報ストリームの情報ソースに従って選択されるものと、
各既存エンティティについて、情報ストリームから情報セグメントを処理するステップの結果得られる情報でエンティティのプロファイルを強化するステップと、
各明らかにされたエンティティについて、新しいエンティティの新プロファイルを作成し、情報ストリームから情報セグメントを処理するステップの結果得られる情報でエンティティのプロファイルを強化するステップと、を含み、
既存エンティティのプロファイルまたは新しいエンティティの新プロファイルはタイプおよび事前定義のメタデータのセットを含み、各メタデータはキーと値のペアを含み、
既存エンティティのプロファイルおよび新しいエンティティの新プロファイルはプロファイルリポジトリ内にストアされ、
エンティティの完成したプロファイルをインデクシングエンジンに送信し、
情報ストリームから情報セグメントを処理するステップにおいて、情報セグメントの１つにおいて特定されたユニバーサルリソースロケータと、情報セグメントの前記１つに割り当てられたユニークＩＤとの間のマッピングはシステムによってハッシュディレクトリ内に登録されることを含んでいる。

さらに、本発明は、コンピュータ可読媒体上にストアされていて、エンティティであって、情報ストリーム内に含まれたエンティティに関する情報を処理するコンピュータプログラムであって、そのエンティティはシステムのリソースディレクトリ内に含まれ、各リソースディレクトリはエンティティを含み、少なくとも１つの新しいエンティティの追加と共に変更されたバージョン番号で注釈が付けられ、本プロセスのステップをコンピュータに実行させるコード手段を含んでいるコンピュータプログラムを提供している。

さらに、本発明は、エンティティであって、情報ストリーム内に含まれているエンティティに関する情報を処理する装置であって、そのエンティティはシステムのリソースディレクトリ内に含まれ、各リソースディレクトリはエンティティを含み、少なくとも１つの新しいエンティティの追加と共に変更されたバージョン番号で注釈が付けられていて、本プロセスのステップを実現する手段を含む装置に関する。

以下には、本発明および本発明を具現化するシステムによるプロセスが、非限定的な例を示し、添付図面を参照して説明されている。なお、添付図面において、

情報ストリームとインデクシングエンジンの間に挿入されたコンソリデーションボックスを示す図である。 本発明によるコンソリデーションボックスの実施形態を示す図である。 本発明を実施するのに適したハードウェアおよびソフトウェア環境を示す概略図である。

本発明は、情報ストリーム内に含まれるエンティティに関係する情報を処理するコンピュータ実装プロセスに関する。エンティティはタイプ付きデータであり、そこではタイプ付きデータは、値のセット、他のタイプ付きデータへのリンクおよび可能な場合は、これらの値に対する操作をさらに含む場合がある。例えば、タイプ付きデータはクライアント名、都市、製品名、感情的価値(sentiment value)、支払い方法とすることができる。これらのエンティティはシステムのリソースディレクトリにストアされる。各リソースディレクトリはエンティティを含み、少なくとも１つの新しいエンティティの追加と共に変更されたバージョン番号で注釈が付けられる。バージョン番号は増分的に異なるデータのバージョンを記録するために使用されることがあり、そのバージョン番号は、例えば、システムにストアされたデータの新しさを示す。

本プロセスは、異なる情報ソースから情報ストリームを検索するステップを含む。次に、情報セグメントが前記リソースディレクトリのエンティティに従って情報ストリームから処理される。一般的に、既存リソースディレクトリのエンティティに見つかったエンティティに関する情報が抽出される。そのあと、情報セグメントは、前記リソースディレクトリのどのバージョンが前記情報セグメントの処理のために使用されたのかを示す注釈と共にストアされる。新しいエンティティが処理されたセグメントに見つかった場合には、前記リソースディレクトリの少なくとも１つを少なくとも１つの新しいエンティティで更新し、さらに前記少なくとも１つのリソースディレクトリのバージョン番号を更新するステップがそのあとに続く。一般的に、新しいエンティティは情報ストリームの中に見つけられる。そのあと、本プロセスはストアされた情報セグメントを再処理し、その情報セグメントは、前記少なくとも１つの更新されたリソースディレクトリの以前バージョンで前記情報セグメントが処理されたことを示す注釈を含む。有利な点は、開示したテクノロジによると、どの情報ソースが再処理される必要があるかを特定することによってストアする情報ストリームが少なくなることである。さらに、ストアされた情報セグメントのサブセットだけが再処理されるので、処理時間が改善される。

図１は、本発明のプロセスの実施形態を示す図である。情報ストリーム１０と従来のインデクシングエンジン１１との間にコンソリデーションボックス１２が挿入され、本発明のプロセスを実行する。コンソリデーションボックスは、１つまたは２つ以上の入力情報ソースからのエンティティに関するデータを変形し、統合するのを可能にするコンピュータシステムである。

コンソリデーションボックス１２は、異なる情報ソースから情報ストリーム１０を検索する。一般的に、情報ストリーム１０は、Ｗｅｂとも呼ばれるＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂによって提供される。しかし、情報ストリーム１０は、イントラネットやエクストラネットのようなプライベートネットワークによって提供されることもある。ところで、どの情報ソースも、その発生源に関係なく本発明を実行するために使用されることがある。情報ストリーム１０はエンティティに関係する情報セグメントを提供する。エンティティはタイプ付きデータであり、この場合、タイプ付きデータは値のセット、他のデータタイプとの関係のセット、および可能ならば、これらの値に対する操作を含むことができる。例えば、タイプ付きデータはクライアント名、都市、製品名、感情的価値、支払い方法とすることができる。情報セグメントは、リソースディレクトリにストアされたエンティティに従って情報ストリームから処理される。リソースディレクトリはエンティティを含み、バージョン番号で注釈が付けられる。そのあと、情報セグメントは、エンティティに関するプロファイルを継続的および増分的に構築するコンソリデーションボックス上にキャッシュ（１３）される。一般的に、プロファイルはプロファイルリポジトリ上にストアされ、コンソリデーションボックス１２によって生成される出力データである。プロファイルはエンティティに関係するデータの集まりである。一般的に、プロファイルはタイプおよび事前定義したメタデータのセットを含むデータ構造であり、メタデータのセットは互いにキーと値のペアで構成されている。一部のメタデータはオプションとすることができる。定義により、オプションのメタデータのキーと値のペアのうちの値部分は空とすることができる。他のメタデータは、データ構造をプロファイルと見なすために、
その存在を必須とすることができる。従って、あるエンティティのプロファイルが完成したとき、すなわち、すべての必要データが統合されたとき、そのプロファイルは、プロファイルのデータのインデックスを作成するインデクシングエンジン１１に送られる。

実際には、コンソリデーションボックス１２はＤＳＳ（Decision Support System：意思決定支援システム）の一部とすることができる。ＤＳＳは特定クラスのコンピュータ化情報システムであり、このシステムは、ビジネスおよび組織の意思決定アクティビティをサポートし、意思決定者が生データ、ドキュメント、個人知識および／またはビジネスモデルから有用な情報をコンパイルして問題を特定して解決し、意思決定を行なうおとを支援することを目的としている。

次に、図２は本発明のプロセスを実行するシステムの実施形態、すなわち、コンソリデーションボックスを示す図である。

コンソリデーションボックス１２はコネクタ２６、２７を介して外部世界に接続されている。コネクタは情報ストリームのソースにアクセスし、異なる情報ソースから情報ストリームを検索する。実際には、コネクタはデータソース（ファイルシステム、Ｗｅｂページ、データベース、Ｅメール）に接続すると共に、そのソースからタイプ付きデータ（例えば、送信者名、Ｅメール本文テキストなどを指定するＸＭＬ）を抽出するコンピュータモジュールである。非限定的な例として、コネクタは、レストランに関するＷｅｂサイトの与えられたリストを継続的にクロールし、情報ストリームから、すなわち、レストランを記述したＷｅｂページから情報セグメントを抽出することが可能である。

これらのコネクタを使用すると、システムのユーザはどの情報ストリームがインデックス生成されるエンティティに関する情報セグメントを提供する可能性があるかを決定することができる。この決定はストリームの発生源に応じて行なわれることがある。発生源は、サーバの地理的ロケーション、そのＩＰアドレス、そのサービス（ＨＴＴＰ、ＦＴＰなど）などの情報ストリームのソースの技術的考慮に基づいて判断されることがある。また、発生源はストリームソースのタイプ、例えば、Ｗｅｂサイト、フォーラム、Ｗｅｂサイトにおけるコメント、ブログポストなどに基づいて判断されることもある。理解されるように、有利な点は選択した情報ソースに従って情報ストリームを選択することである。従って、データ量が激減することがあるので（Ｗｅｂ全体をクロールするのではなく）、コンソリデーションボックス１２の計算リソースが保持される。有利な点は、インデックス作成されるエンティティがまだシステムに知られていない場合でも決定を行なうことができることである。これが有利であるのは、ある与えられたエンティティが見つかれば、そのエンティティに関する情報が失われることがないとユーザが予測できることである。

コネクタはストリームから情報セグメントを抽出する。情報セグメントはコンソリデーションボックスによって処理された入力データである。各情報セグメントはデータ構造である。実際には、情報セグメントのデータ構造はタイプ、オプションのＵＲＩおよび制約なしメタデータのセットを含み、各メタデータは互いにキーと値のペアから構成される。情報ストリームからの情報セグメントは、検索されると、リソースディレクトリのカレントバージョンに従って処理される。

コンソリデーションボックスに入力された情報セグメントの処理が開始されとき、ユニークＩＤが各処理される情報セグメントに割り当てられることがある。これに付随して、システム内の各エンティティにＩＤが割り当てられることもある。一般的に、処理された情報セグメントに見つかった各新しいエンティティについて、両方のＩＤは同じである。従って、情報セグメント内のメタデータ部分を処理するマスタ参照ＩＤジェネレータ(master reference identifier generator)によってマスタ参照ＩＤが割り当てられる。例えば、エンティティの１つがレストランに関するものであれば、このＩＤジェネレータはレストランの名前とそのアドレスを含むメタデータを受け取って、エンティティレストランのレストランマスタ参照ＩＤを生成することができる。より一般的には、ある与えられたタイプの各情報セグメントが特定のＩＤジェネレータにマッピングされる。(エンティティ)マスタ参照ＩＤは、あるエンティティに関する複数の情報セグメントをそのエンティティに関する単一のプロファイルにリンクさせる。情報セグメントがＵＲＩを含む場合、そのＵＲＩと生成された(エンティティ)マスタ参照ＩＤとの間のマッピングがＤＩＨ(Document Identifier Hashtable／ドキュメント識別子ハッシュテーブル)に登録される。

マスタ参照ＩＤが計算されると、本プロセスは情報セグメントをマッパキュー２０に割り当てて、そこでさらに別の処理を待機する。この割り当てを、そのセグメントのソースのタイプに従って処理することができる。実際には、割り当てるプロセスを、コンソリデーションボックス１２内部の通信を管理するマスタプログラムであるコンソリデーションボックスマネージャによって実行することができる。

マッパキュー２０は、この分野では公知であるように、ｍａｐ−レデュースメカニズム２１によって処理される。このｍａｐ−レデュースメカニズム２１は、クラスタと総称される非常に多数のコンピュータを使用して膨大なデータセットを処理するフレームワークに頼っている。情報セグメントはエンティティタイプ別プロセスにマッピングされ、このプロセスはエンティティマスタ参照ＩＤによって特定された各ＩＤに関する別のメタデータの抽出を試みる。この処理は高度並行処理であり、そこでは自然言語処理および情報抽出などの大量コンピューティング操作が情報セグメントに対して実行される。情報抽出は、非構造化または構造化データからある特定タイプのエンティティ(例えば、人々、場所、金、日付、組織、製品)を認識する自然言語処理の分野である。エンティティ認識技法では、リンク、ルールまたはこれらを組み合わせたものが使用される。エンティティはエンティティ階層でタグを付けることもできる。エンティティはコンソリデーションボックス１２のエンティティストア２５にストアされる。さらに、セグメントの処理中に情報セグメントに特定されたエンティティもエンティティストア２５にストアすることができる。

マッピングメカニズムによってリソースディレクトリのエンティティに従って情報セグメントを処理したあと、情報セグメントは専用ストア２５にストアされる。これに付随して、あるエンティティタイプにマッピングされた各情報セグメントを、そのエンティティタイプに従ってコンソリデーションボックス１２の初期構成にストア可能またはストア不能として宣言することが可能である。そのエンティティタイプがストア不能として宣言された場合は、情報セグメントはストアされない。これとは反対に、ある情報セグメントがマッピングされるときのエンティティがストア可能として構成されている場合は、その情報セグメントはそのオリジナルフォーマットでストアされるか、場合によりマッピング段階期間に生成された追加のメタデートと共にストアされるが、そのセグメントが処理されてコンソリデーションボックス内部の情報セグメントストア２２にストアされたときのリソースのバージョン番号で注釈が付けられることは確かである。事実、上記で見たように、エンティティはエンティティストア２５と呼ばれるリソースディレクトリにストアされる。リソースディレクトリはある特定タイプのエンティティに対応しており、各リソースディレクトリはバージョン番号をもっている。

情報セグメントの処理は、例えば、上述したエンティティ認識を使用して新しいエンティティを明らかにすることができる。リソースを使用して、エンティティを特定することができ、リスト、ディクショナリ、シソーラスまたはオントロジで構成されることもある。これらの新しいエンティティはエンティティストア２５にストアされる。リソースディレクトリ２５に追加された新しいエンティティは、追加された新しいエンティティの追加と共に一度変更されたリソースディレクトリに付けられたバージョン番号を示す注釈を含むことができる。これに応じて、対応するリソースディレクトリの更新が実行されるが、その更新に伴って各リソースディレクトリのそれぞれのバージョン番号が変更される。さらに、以前に見られた情報ストリーム（情報セグメントストア２２にストアされた）の一部分はこれらの新しいエンティティに関する情報を含むことができる。従って、これらがリソースディレクトリの以前バージョン番号でその情報セグメントが処理されたことを示す注釈を含むストア２２された情報セグメントが再処理される。ストアされた情報セグメントの再処理はリソースディレクトリに追加された新しいエンティティに従って実行されることもできる。当然に理解されるように、各情報セグメントの注釈に利点があるのは、情報セグメントストア２２にストアされたどのセグメントがエンティティリソースの以前バージョンで処理されたかを本プロセスが選択できるからである。同じタイプのエンティティリソースで処理されないセグメントは再処理のために選択されない。従って、この選択のお陰で、ストア２２にストアされた情報セグメントのサブセットだけが再処理され、その結果として計算リソースが保持され、処理時間が改善される。さらに、ストアしておく必要のある情報セグメントのストリームは、どの情報セグメントを再処理する必要があるかを特定することにより少なくて済むので、ストレージコストが低減される。もう１つの利点は、リソースのバージョン番号により、情報セグメントの再処理期間に、エンティティのリソースディレクトリの新バージョンに現れたエンティティに関する情報だけを抽出できることである。事実、これらのリソースディレクトリでは、各エンティティが最初に現れたリソースディレクトリのバージョン番号で各エンティティにも注釈が付けられるので、システムは、どのエンティティが新情報の抽出を必要としているかを再処理期間に認識することができる。この場合も、新しいエンティティの情報だけを抽出することにより、ストアされた情報セグメントの再処理時に処理時間が減少する。

これに付随して、情報ストリームから情報セグメントを処理する間に新しいエンティティが明らかにされることがあるが、ユーザによって入力されることもある。さらに、コンソリデーションボックス１２がインタフェースとなって、自然言語処理リソースをダイナミックに更新することもある。各リソースはバージョン番号を有している。リソースの更新がコミットされると、バージョン番号が変わるので、関係する情報セグメントの再処理が実行されることになる。

次に、マッピングメカニズムによる処理が行なわれ、情報セグメントを追加のメタデータ（もしあれば）と共にストアしたあと、処理された情報セグメントがレデューサキュー２３に追加される。各エンティティには、コンソリデーションボックス１２の構成に定義されたレデューサが関連付けられている。このレデューサは１つまたは２つ以上の情報セグメントを入力として受け取ることができるコンピュータプログラムである。

プロファイルがレデュースステージ２４で作成される。同じマスタ参照ＩＤをもつエンティティが既に存在する場合は、そのエンティティは、エンティティストア２５からローカルに、コンソリデーションボックスにフェッチされる。情報セグメントはターゲットであるエンティティごとに順次に処理される。レデュースメカニズムは、すべてのプロファイルを、ローカルにコンソリデーションボックス１２にストアされたプロファイルにストアするが、一部の必須メタデータを欠くプロファイルでさえもストアする。

コンソリデーションボックス構成において、そのエンティティタイプについて定義された全必須メタデータをプロファイルが含む場合、レデュースメカニズム２４はコンソリデーションボックス１２の外部のインデクシングエンジン１１にそのプロファイルを送信する。

本発明による本プロセスの実施形態を例示するシナリオについて、以下で説明する。このシナリオでは、３つの情報ソースがコンソリデーションボックス１２によって処理される。すなわち、レストランＷｅｂサイト、コメントおよびブログエントリ（ブログポストとも呼ばれる）である。レストランのプロファイルは処理された情報から構築され、名前、アドレス、支払い方法、メニュー、顧客感情などのフィールドを含むことができ、これらは各レストランに関連付けられている。

２つのコネクタ２６、２７は情報ストリームソースにアクセスし、情報ストリームからの情報セグメントをコンソリデーションボックス１２の中にプッシュする。一方のコネクタはレストランの情報とコメントを複数のレストランレビューＷｅｂサイトから抽出し、これらをコンソリデーションボックス１２にプッシュする。第２のコネクタは複数のブログからブログを抽出し、これらのコンソリデーションボックス１２の中にプッシュする。

このシナリオでは、第１のコネクタは次に示す情報セグメントをコンソリデーションボックスに入力する。
<Data type=“restaurant”>
<meta name=“URI“ Value=“http://www.restaurantreviews.com/ABCRestraurant“ />
<meta name=“restaurantName“ value=“ABC Restaurant“ />
<meta name=“address“ value=“123 food street“ />
</Data>

情報セグメントはタイプ、“restaurant”、オプションのユニバーサルリソースＩＤ、“http//www.restaurantreviews.com/ABCRestraurant”および制約なしメタデータを含み、各メタデータはキーと値のペア（例えば、キー名＝“restaurantName”および値＝“ABC Restaurant”）を含む。従って、この情報セグメントはレストラン情報セグメントである。

コンソリデーションボックス１２は、このレストラン情報セグメントを処理する。“restaurant”タイプの情報セグメントに対するマスタ参照ＩＤジェネレータが計算される。コンソリデーションボックスの構成においてこのタイプ（“restaurant”）の情報セグメントに関連付けられたマスタ参照ＩＤジェネレータはレストランのアドレスと名前を解析し、正規化してエンティティ“ＡＢＣレストランと名付けたレストラン”のユニークなエンティティマスタ参照ＩＤを生成する。このエンティティマスタ参照ＩＤは新メタデータとして情報セグメントに追加される。このエンティティマスタ参照ＩＤをユニークキーとして使用して、異なるレビューＷｅｂサイトに渡って同じエンティティ“ＡＢＣレストランと名付けたレストラン”に対して収集された情報がそのエンティティの同じディレクトリに統合される。有利なことは、異なるストリートアドレスに別の“ＡＢＣレストラン”が存在する場合、ジェネレータはその別のレストランに対して異なるエンティティマスタ参照ＩＤを生成するので、エンティティ“ＡＢＣレストランと名付けたレストラン”と第２のレストランエンティティである第２のレストランとが区別されることである。

次に、情報セグメントはメタデータとしてＵＲＩを有しているので、コンソリデーションボックスマネージャはＵＲＩと以前に計算したエンティティマスタ参照ＩＤとの間のマッピングをコンソリデーションボックス１２に独自のＤＩＨに登録する。このハッシュテーブルは、ハッシュ関数を使用してエンティティマスタ参照ＩＤを関連のＵＲＩに効率的にマッピングするデータ構造である。有利なことは、ハッシュテーブルを使用すると、効率的な検索が可能になることである。

そのあと、コンソリデーションボックスマネージャはレストラン情報セグメントをマッパキュー２２内にプッシュする。情報ストリームのマッパキューへの割り当ては、情報ストリームのタイプ（または情報ソース）に従ってマッパキューが選択されるように行なわれる。この情報セグメントはタイプ“restaurant”のエンティティに関係しているので、このレストラン情報セグメントはレストランタイプの情報セグメントのマッパキューに入って送信される。マッパマネージャのプログラムはコンソリデーションボックスのマネージャによって起動され、マッパキュー内のレストラン情報セグメントがｍａｐ−レデュースメカニズム２１によって処理される。

次に、レストラン情報セグメントがマッパマネージャによって抽出され、レストランマッパに送信される。このレストランマッパはプログラムであり、（レストラン名、エンティティマスタ参照ＩＤ）ペアが既に存在するかどうかを、コンソリデーションボックスにローカルのリソースにおいて検証する。マッパプログラムによって抽出された（レストラン名、エンティティマスタ参照ＩＤ）ペアがリソースに存在しなければ、そのリソースが更新のためにプログラムされ、新情報がローカルファイルにストアされ、そのリソースが「ダーティ(dirty)」とマーク付けられる。すなわち、このことは、新情報がその後のいつかに新バージョンの構築に利用できることを意味している。

次に、レストラン情報セグメントは、ストア可能として構成されていないので、これは情報セグメントストア２２に書き出されない。

そのあと、レストラン情報セグメントがマッパ２１によってレデューサキュー２３に送信される。

レデュースステージがトリガされると、レストラン情報セグメントがレストランエンティティのレデューサによって処理される。エンティティ“ＡＢＣレストランと名付けたレストラン”のエンティティマスタ参照ＩＤについてプロファイルがまだ存在しないので、新プロファイルが作成される。この新プロファイルはタイプと事前定義メタデータのセットを含み、各メタデータはキーと値のペアを含んでいる。プロファイルはオリジナル情報セグメントからのほかに、エンティティ“ＡＢＣレストランと名付けたレストラン”のそのエンティティマスタ参照ＩＤに関係する他の情報セグメントがレデューサキューにあればその情報セグメントからも、マッパによって生成されたすべての情報を用いて強化される。

そのあと、新たに変更されたプロファイルがプロファイルリポジトリ、すなわち、プロファイルストア２９にストアされる。ストアされたプロファイルが必要とするすべてのメタデータを含む場合、すなわち、プロファイルのすべての必須フィールドが満たされていれば、そのプロファイルはコンソリデーションボックスの外部の従来のインデックスエンジン１１によるインデックス作成のために送信される。

第２のコネクタは次に挙げたブログポスト情報セグメントを入力し、それをコンソリデーションボックスに送信する。
<Data type=“blogpost”
<meta name=“URI”value=http://www.foodblog.com/entries/1“ />
<meta name=“text“ value=“Today we tried ABC Restaurant, and it was
Fabulous.“/>
</Data>

コンソリデーションボックスは、“ブログポスト“タイプの情報セグメントに対するコンソリデーションボックス構成の中で関連付けられたマスタ参照ＩＤジェネレータプログラムにタイプ“ブログポスト“のこの情報セグメントを最初に送信することによってその情報セグメントを処理する（例えば、情報ストリームのソースはブログである）。このマスタ参照ＩＤジェネレータプログラムはドキュメントの単純な特徴(fingerprint)をそのマスタ参照ＩＤとして生成する。従って、この情報セグメントはブログポスト情報セグメントである。

次に、ブログポスト情報セグメントはＵＲＩをもっているので、ＤＩＨ内のエントリが追加され、ブログポスト情報セグメントのＵＲＩをそのエンティティマスタ参照ＩＤにマッピングすることになる。

そのあと、コンソリデーションボックス１２のマネージャはブログポスト情報セグメントを、マッピングのためのキュー２０に挿入する。

そのあと、マップマネージャプログラムがコンソリデーションボックスのマネージャによって起動されるのでブログポスト情報セグメントが“ブログポスト”タイプの情報セグメントのために専用されるマッパ２１によって処理される。この“ブログポスト”マッパはレストラン名を含むリソースとマッチさせる自然言語処理を実行する。“ブログポスト”マッパ２１がブログポストに既知のレストラン名を見つけると、レストランエンティティマスタ参照ＩＤをもつノートがブログポスト情報セグメントに追加される。このケースでは、“レストラン名”のリソースディレクトリがエンティティ“ＡＢＣレストランと名付けたレストラン”の“ＡＢＣレストラン”名でまだ更新されていないので、これまではどの名前もマッチしていない。

次に、“ブログポスト”タイプの情報セグメントはコンソリデーションボックスの構成の中でストア可能として宣言されているので、このブログポスト情報セグメントは、リソースディレクトリのどのバージョンが処理の過程で使用されたかを示すために注釈が付けられて情報セグメントストア２２にストアされる。このケースでは、レストラン名リソースのカレントバージョンはバージョン０である。

そのあと、ブログポスト情報セグメントがマッパ２１によってレデューサキューに送られる。

そのあと、レデュースステージがコンソリデーションボックスマネージャによって起動され、新ブログポストプロファイルがブログポストレデューサによって作成される。この目的のために、ブログポスト情報セグメントのメタデータが新しく作成されたプロファイルにコピーされるが、これはそのブログポスト情報セグメントのマスタ参照ＩＤにはまだプロファイルが存在しないためである。

そのあと、コンソリデーションボックス内部のプロファイルストア２９にブログポストプロファイルがストアされる。さらに、すべての必須メタデータがプロファイルに存在していれば、レデューサは、従来の外部インデクサ１１によってインデックス生成されるためにコンソリデーションボックスの外部のプロファイルも送信する。

レストラン名リソースのカレントバージョンはバージョン０である。ある時点で、コンソリデーションボックスマネージャは、レストラン名リソースの新バージョンを構築することを決定する。これに付随して、外部イベントが、例えば、ユーザの決定を受けてリソースの更新をトリガすることもある。リソースのこの新バージョン、すなわち、バージョン１では、エンティティ“ＡＢＣレストランと名付けたレストラン”のレストラン名“ＡＢＣレストラン”およびそのエンティティマスタ参照ＩＤがレストラン名のリソースディレクトリに現れる。見つかったすべての新しい（レストラン名、エンティティマスタ参照ＩＤ）ペアを統合することによって、レストラン名のリソースディレクトリの新バージョンが構築されると、コンソリデーションボックスマネージャは情報ストア２２のローカルセグメントにストアされたすべての情報セグメントを調べて、このリソースの以前バージョンを使用する情報セグメントがあれば、そのセグメントを「ダーティ」にする。これらのデータが新リソースで再処理される必要があるのは、リソースの以前バージョンで見つからなかった情報、例えば、以前に未知のレストランに関する情報を含むことがあるからである。本プロセスは、情報セグメントストア２２にストアされたどのセグメントがリソースの以前バージョンを使用して処理されたのかを選択することができる。従って、ストア２２にストアされた情報セグメントのサブセットだけが再処理され、その結果として、計算リソースと処理時間が保持されている。さらに、どの情報ソースが再処理される必要があるかを特定することにより、ストアする必要のある情報セグメントストリームが少なくなるのでストレージコストが低減されている。さらに、注釈が付いた情報セグメントがローカル情報セグメントストア２２にストアされるので、リソースが更新されるとき外部情報ソースから情報をリフレッシュする必要がない。これにより、ネットワークバンド幅の消費が大幅に減少している。

そのあと、コンソリデーションボックスマネージャは“Reprocess obsolete Business Data”プログラムを起動し、ブログポスト情報セグメントを、マッピングのためにキュー２０に挿入することによってすべての“ダーティ”情報セグメントをコンソリデーションプロセスに再入させる。

今回は、マッパは、ブログポスト情報セグメントのテキストの中のエンティティ“ＡＢＣレストランと名付けたレストラン”のレストラン名“ＡＢＣレストラン”をマッチさせ、“ＡＢＣレストラン”エンティティのマスタ参照ＩＤをもつノートをブログポスト情報セグメントに追加する。

そのあと、ブログポスト・レデューサとレストラン・レデューサにおいてレデュースするブログポスト情報セグメントがキューに置かれる。このブログポストレデューサはブログポストのマスタ参照ＩＤを使用してローカルプロファイルストア２９を探索し、そのブログポストに対応する以前に構築されたプロファイルを見つけ、そのあとレストランのマスタ参照ＩＤをその既存ブログポストプロファイルに追加する。

レストランレデューサはこの同じブログポスト情報セグメントをレデュースして、エンティティ“ＡＢＣレストランと名付けたレストラン”のプロファイルをフェッチし、そのエンティティに関係するブログポストの数を増加するか、または感情解析メタデータがマッパによってブログポスト情報セグメントに追加されていれば感情解析を計算する。

最後に、ブログポストとレストランのプロファイルの両方がプロファイルストアにストアされ、これらのプロファイルがそれぞれの必須のメタデータセットを含む場合、外部インデクサ１１に送出される。

このシナリオで処理された第３タイプの情報ソースはレストラン・コメントである。異なるコネクタからであり、自然言語処理技法を必要とするブログポストとは異なり、コメントはそのページに直接にリンクしたレストランまたはページとして同じＷｅｂページ上で抽出される。

レストランコネクタは次に挙げた情報セグメント（タイプ“コメント”の）をコンソリデーションボックスにプッシュする。
<Data type=“comment”
<meta name=“URI”
Value=http://www.restauratreviews/ABCRestaurant/comments />
<meta name=“restaurant URI”
Value=http://www.restaurantreviews.com/ABCRestaurant />
<meta name=“text”value=“This is the best restaurant.”/>
</Data>

コンソリデーションボックスマネージャは、コメント情報セグメントに関連付けられたマスタ参照ＩＤジェネレータに情報セグメントのコメントに送信する。コメントには複雑な解決ルールがないので、ドキュメントの単純な特徴がコメントマスタ参照ＩＤとして割り当てられる。

次に、コメント情報セグメントはＵＲＩを含むので、ＤＩＨ内のエントリが追加され、コメントＵＲＩをそのコメントマスタ参照ＩＤにマッピングする。

そのあと、コメント情報セグメントが処理され、コンソリデーションボックスマネージャによってマッピングキュー２０に送られる。コンソリデーションボックスマネージャがマッピングメカニズムを起動すると、コメント情報セグメントがコメントマッパによって処理される。このコメントマッパはＤＨＩ内を単純に調べて、レストランＵＲＩをレストランマスタ参照ＩＤに分解し、対応するレストランマスタ参照ＩＤをコメント情報セグメント内に新メタデータとして追加する。

そのあと、コメント情報セグメントはコンソリデーションボックス構成においてストア不能として定義されるので、コメント情報セグメントはローカル情報セグメントストア２２にストアされない。

次に、マッパは増補されたコメント情報セグメントをレデューサキューに入れる。レデュースステージがコンソリデーションボックスマネージャによって起動されると、コメント情報セグメントがコメントレデューサとレストランレデューサの両方によって処理される。レストランレデューサはプロファイルストア２９から“ＡＢＣレストラン”をフェッチし、そのレストランに関係するコメントの数を増やすか、または感情解析を計算し、更新したレストランプロファイルをプロファイルストア２９に戻してストアする。コメントレデューサは新コメントプロファイルを作成し、コメント情報セグメントのメタデータをコメント情報セグメントのプロファイルにコピーする。

最後に、すべての必須メタデータが存在していれば、コメントのプロファイルがプロファイルストア２９にストアされ、最終的にインデックスエンジン１１に送られる。

以上から理解されるように、上述した方法は、システムによって定義される可能性のあるどの構成においてもどの情報ストリームにも適用可能である。本発明は、デジタル電子回路に実現されることも、コンピュータハードウエア、ファームウエア、ソフトウェアまたはこれらを組み合わせたもので実現されることもある。本発明の装置は、プログラマブルプロセッサによる実行のためにマシン可読ストレージデバイスに有形に具現化されたコンピュータプログラム製品で実現されることもあり、本発明の方法ステップは、入力データに操作を及ぼして出力を生成することにより本発明の機能を実行するために命令からなるプログラムを実行するプログラマブルプロセッサによって実行されることもある。

本発明の利点として、本発明はプログラマブルシステム上で実行可能である１つまたは２つ以上のコンピュータプルグラムで実現されることがあり、そのプログラマブルシステムとしては、データストレージシステム、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスとの間でデータおよび命令を受信し、送信するように結合された少なくとも１つのプログラマブルプロセッサがある。アプリケーションプログラムは高水準手続き型またはオブジェクト指向プログラミング言語で実現されることも、必要ならばアセンブリまたはマシン言語で実現されることもあり、いずれの場合も、その言語はコンパイル型または解釈型言語とすることができる。

図５はコンピュータシステムス、例えば、コンソリデーションボックスを示す図である。コンソリデーションボックスは内部通信バス（ＢＵＳ）)１００に接続された中央処理ユニット（ＣＰＵ）、ＢＵＳにも接続されたランダムアクセスメモリ（ＲＡＭ）１０５を備えている。マスストレージデバイスコントローラは、ハードドライブ１０３のようなマスメモリデバイスへのアクセスを管理する。コンピュータプログラム命令およびデータを有形に具現化するのに適したマスメモリデバイスとしては、あらゆる形体の不揮発性メモリがあり、その中には、例を挙げると、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの半導体メモリデバイス、およびフラッシュメモリデバイス、磁気ディスク（内部ハードディスクや取り外し可能ディスクなど）、光磁気ディスクおよびＣＰ−ＲＯＭディスク１０４がある。上記に挙げたもののいずれも、特殊設計のＡＳＩＣ(application-specific integrated circuit／特定用途向け集積回路)によって補強されることも、そこに組み込まれることもある。ネットワークアダプタ１０７はネットワーク１０８へのアクセスを管理する。コンソリデーションボックスはディスプレイ１０６と触覚デバイスを含んでいることがある。この方法によると、ユーザは、例えば、自然言語処理リソースを変更するために、コンピュータシステムとのやりとりが可能になる。

以上、本発明の好適実施形態について説明してきた。当然に理解されるように、本発明の精神および範囲から逸脱することなく種々の変更が行なわれることもある。従って、他の実施形態は特許請求の範囲内に属している。例えば、本発明のプロセスはインデックスエンジンによって実行されることがある。

Claims (15)

1. タイプ付きデータであるエンティティに関する情報を処理するコンピュータが実行するプロセスであって、前記エンティティは情報ストリームに含まれ、前記エンティティはシステムのリソースディレクトリにストアされ、各リソースディレクトリはエンティティを含み、および少なくとも１つの新しいエンティティの追加と共に変更されるバージョン番号で注釈が付けられている、前記プロセスは、
   異なる情報ソースから情報ストリームを検索するステップと、
   情報ストリームからの情報セグメントを、前記リソースディレクトリのエンティティに従って処理するステップと、
   前記情報セグメントを、前記リソースディレクトリのどのバージョンが前記情報セグメントを処理するために使用されたのかを示す注釈と共にストアするステップと、
   前記リソースディレクトリの少なくとも１つを、少なくとも１つの新しいエンティティを用いて更新し、前記少なくとも１つのリソースディレクトリのバージョン番号を更新するステップと、
   前記情報セグメントが少なくとも１つのリソースディレクトリの以前のバージョンで処理されたことを示す注釈を含む、前記ストアされた情報セグメントを再処理するステップと
   を含むことを特徴とするプロセス。
2. リソースディレクトリに追加された新しいエンティティは、前記リソースディレクトリに付与されたバージョン番号が、前記追加された新しいエンティティの追加と共に一度変更されたことを示す注釈を含み、再処理するステップは、前記ストアされた情報セグメントを、前記リソースディレクトリに追加された新しいエンティティに従って再処理することをさらに含むことを特徴とする請求項１に記載のプロセス。
3. 各処理された情報セグメントと各エンティティとにユニークな識別子が割り当てられることを特徴とする請求項１乃至２のいずれか１つに記載のプロセス。
4. 各新しいエンティティに割り当てられた前記識別子は、前記各新しいエンティティを明らかにした前記処理されたセグメントの識別子と同じであることを特徴とする請求項３に記載のプロセス。
5. 前記情報ストリームからの情報セグメントを処理するステップにおいて、新しいエンティティはユーザによって明らかにされるか、または入力され、対応する前記リソースディレクトリ内に追加されることを特徴とする請求項１乃至４のいずれか１つに記載のプロセス。
6. 前記処理された情報セグメントはデータ構造であることを特徴とする請求項１乃至５のいずれか１つに記載のプロセス。
7. 前記処理された情報セグメントは、タイプ、オプションのユニバーサルリソース識別子、および制約なしメタデータのセットを含み、各メタデータはキーと値のペアを含むことを特徴とする請求項１乃至６のいずれか１つに記載のプロセス。
8. 前記情報ストリームからの前記処理された情報セグメントは、選択した情報ソースに従ってストアされることを特徴とする請求項１乃至７のいずれか１つに記載のプロセス。
9. 前記ストリームから前記情報セグメントを処理するステップに先立って、
   前記検索した情報ストリームを、マッパキュー内に割り当てるステップであって、前記マッパキューは、前記情報ストリームの前記情報ソースに従って選択され、かつｍａｐ−レデュースメカニズムによって処理されるステップをさらに含むことを特徴とする請求項１乃至８のいずれか１つに記載のプロセス。
10. 前記情報ストリームから情報セグメントを処理するステップのあとに、
    前記処理された情報ストリームを、レデューサキュー内に割り当てるステップであって、前記レデューサキューは、前記情報ストリームの前記情報ソースに従って選択されるステップと、
    各既存エンティティに対して、前記情報ストリームからの情報セグメントを処理する前記ステップの結果得られる情報を用いて、前記エンティティのプロファイルを強化するステップと、
    各明らかにされた新しいエンティティに対して、前記新しいエンティティの新プロファイルを作成し、かつ前記情報ストリームからの情報セグメントを処理する前記ステップの結果得られる情報を用いて、前記プロファイルを強化するステップと
    をさらに含み、
    前記エンティティのプロファイルまたは前記新しいエンティティの新しいプロファイルは、タイプおよび、事前定義メタデータのセットを含み、各メタデータはキーと値のペアを含むことを特徴とする請求項５乃至９のいずれか１つに記載のプロセス。
11. 前記既存エンティティのプロファイルおよび前記新しいエンティティの新しいプロファイルは、プロファイルリポジトリにストアされることを特徴とする請求項１０に記載のプロセス。
12. エンティティの完成したプロファイルを、インデクシングエンジンに送信するステップをさらに含むことを特徴とする請求項１０乃至１１のいずれか１つに記載のプロセス。
13. 前記情報ストリームから前記情報セグメントを処理するステップにおいて、前記情報セグメントの１つにおいて特定されたユニバーサルリソースロケータと、前記情報セグメントの前記１つに割り当てられたユニークな識別子との間のマッピングが、前記システムによってハッシュディレクトリ内に登録されることを特徴とする請求項３乃至１２のいずれか１つに記載のプロセス。
14. コンピュータ可読媒体上にストアされ、タイプ付きデータであるエンティティに関する情報を処理するコンピュータプログラムであって、前記エンティティは情報ストリーム内に含まれ、前記エンティティは、システムのリソースディレクトリ内にストアされ、各リソースディレクトリはエンティティを含み、および少なくとも１つの新しいエンティティの追加と共に変更されるバージョン番号で注釈が付けられ、請求項１乃至１３のいずれか１つに記載のプロセスのステップをコンピュータに実行させるコード手段を含むことを特徴とするコンピュータプログラム。
15. タイプ付きデータであるエンティティに関係する情報を処理する装置であって、前記エンティティは情報ストリーム内に含まれ、前記エンティティは、システムのリソースディレクトリ内にストアされ、各リソースディレクトリはエンティティを含み、および少なくとも１つの新しいエンティティの追加と共に変更されるバージョン番号で注釈が付けられ、請求項１乃至１３のいずれか１つに記載のプロセスのステップを実行する手段を含むことを特徴とする装置。

Images