JP2017138958A - テーマ型Ｗｅｂコーパス - Google Patents

Abstract

【課題】あるテーマについてのＷｅｂコーパスを構築するための方法、システム、およびプログラムを提供する。
【解決手段】サーチエンジンのインデックスを記憶するサーバが、テーマに対応しかつ少なくとも１つのキーワードの論理和からなる構造化クエリを、クライアントから受信し、インデックス中においてクエリに合致するすべてのページのＵＲＬからなるグループを決定する。サーバが、クライアントに、グループにおけるＵＲＬをストリームとして送信することによりテーマ型Ｗｅｂコーパスの構築を改善する。
【選択図】図３

Description

本発明は、Ｗｅｂクローリング用のコンピュータプログラムおよびシステムの分野に関し、より具体的には、あるテーマについてのＷｅｂコーパスを構築するための方法、システム、およびプログラムに関する。

Ｗｅｂをクロールして、例えば、任意の種類のドキュメントのコーパス（ドキュメントがＷｅｂから取得されることから、一般に「Ｗｅｂコーパス」と呼ばれる）を構築する目的で、多数のシステムおよびプログラムが市場に提供されている。コーパスは、後に検索、分析、および／または、その他任意の用途に利用できる。通常利用可能な技術では、あるテーマに関連するコーパス（すなわち「テーマ型Ｗｅｂコーパス」）などの特化型Ｗｅｂコーパスは、構築することができないか、あるいは適合率（ｐｒｅｃｉｓｉｏｎ）および／または再現率（ｒｅｃａｌｌ）が不十分となる。

標準的なＷｅｂクローリング（図１に示す。ここでは時系列が上から下に表されている。例えばＴａｕｂｅｓ，Ｇａｒｙ−Ｉｎｄｅｘｉｎｇ ｔｈｅ ｉｎｔｅｒｎｅｔ？Ｓｃｉｅｎｃｅ ２６９．５２２９，１９９５に記載）では、シードＵＲＬ（ｓｅｅｄ ＵＲＬｓ）から開始して、これらのＵＲＬのページをダウンロードし、各ページを解析して、訪れるべきＵＲＬをさらに収集する。この方法は、テーマ型コーパスの収集には不十分である。なぜなら、トピック外のページから、おそらく複数のリンクの後に、トピックについてのページ（テーマに関するページ）へリンクしているかもしれないからである。極端な方法の１つは、トピック外のページからのリンクはフォローしないことである。この方法では、再現率（当初Ｗｅｂ中に存在したトピックについてのページの総数に対する、最終的に構築されたコーパス内におけるトピックについてのページの数）が低くなる。別の極端な方法は、Ｗｅｂ全体をクロールすることをその本質とする。この方法では適合率（クロールしたページの総数に対する、構築したコーパス内におけるトピックについてのページの数。クロールしたページがコーパスに含まれるか否か）が非常に低くなる。

集中的Ｗｅｂクローリング（ｆｏｃｕｓｅｄ Ｗｅｂ ｃｒａｗｌｉｎｇ）（図２に示す。ここでは時系列が上から下に表されている。例えばＮｏｖａｋ，Ｂｌａｚ−Ａ ｓｕｒｖｅｙ ｏｆ ｆｏｃｕｓｅｄ Ｗｅｂ ｃｒａｗｌｉｎｇ ａｌｇｏｒｉｔｈｍｓ−Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＳＩＫＤＤ ５５５８，２００４に記載）は、同様の方法を維持しつつ、標準的なＷｅｂクローリングの欠点を改善するために発明されたものである。集中的クローラは、最終的にトピックについてのページにリンクする別のページにリンクする可能性のあるＷｅｂページに対しスコアを付与することをその本質とする追加のステップを用いる。この方法では、概して、上述した極端な方法の妥協点を見出すことが期待されている。しかし、この方法も、適合率および再現率が十分ではない。この方法は、Ｗｅｂ全体をクロールする際に適合率を改善するだけである。なぜなら、クロールされるトピック外のページの数を減らすからである。また、トピック外のページで停止する際の再現率を改善する。なぜなら、それらのうちいくつかのページが最終的にトピックについてのページにリンクすることを高い推定確率で許容するからである。

こうした背景において、テーマ型Ｗｅｂコーパスを効率的に構築する解決策の改良、すなわち、計算コスト、適合率、および再現率が妥当な解決策が依然として求められている。

サーチエンジンのインデックスを記憶するサーバによって実行される、コンピュータに実装された方法であって、テーマに関連するＷｅｂコーパスのページのＵＲＬをクライアントに送信する方法が提供される。当該方法は、テーマに対応し、かつ少なくとも１つのキーワードの論理和からなる構造化クエリを、クライアントから受信するステップを含む。当該方法は、インデックス中において、クエリに合致するすべてのページのＵＲＬからなるグループを決定するステップも含む。前記決定は、前記インデックスから前記クエリの論理和における前記キーワードを読み出し、それによって前記インデックスから少なくとも一組のＵＲＬを取得するステップと、次いで、前記取得した少なくとも一組のＵＲＬに対して、前記クエリの論理和に対応する集合演算のスキームを実行し、それによってＵＲＬのグループを導き出す。また、当該方法は、前記クライアントに前記グループにおける前記ＵＲＬをストリームとして送信するステップを含む。

一例では、前記クライアントに前記グループにおける前記ＵＲＬをストリームとして送信するステップは、前記クライアントとのネットワーク接続（例えばＨＴＴＰ接続）を確立するステップと、前記ネットワーク接続上で前記グループにおける前記ＵＲＬをストリーミングするステップと、次いで、前記ネットワーク接続を終了するステップとを含んでいてもよい。

さらには、テーマに関連するＷｅｂコーパスを構築するための、コンピュータに実装された方法が提供される。この方法は、クライアントが、前記テーマに対応し、かつ少なくとも１つのキーワードの論理和からなる構造化クエリをサーチエンジンのインデックスを記憶するサーバに送信するステップと、次いで、前記サーバが、前記構造化クエリに基づき、サーバにより実行される、送信のための上述の方法に従って、クライアントに、前記ＷｅｂコーパスのページのＵＲＬをストリームとして送信するステップとを含む。

一例において、クライアントとサーバが関与するこの方法は、前記クライアントが、前記サーバからストリームとして受信したＵＲＬを、ローカルに保存するステップをさらに含む。一例において、クライアントとサーバが関与するこの方法は、前記クライアントが、前記サーバから受信したＵＲＬのページをクロールするステップ、または、前記サーバから受信したＵＲＬをＷｅｂクローラに送信するステップをさらに含む。

さらには、クライアントによって実行される、テーマに関連するＷｅｂコーパスを構築するための、コンピュータに実装された方法であって、前記テーマに対応し、かつ少なくとも１つのキーワードの論理和からなる構造化クエリをサーバに送信するステップと、次いで、前記サーバから前記ＷｅｂコーパスのページのＵＲＬをストリームとして受信するステップとを含む方法が提供される。

一例では、クライアントにより実行されるこの方法は、前記サーバからストリームとして受信したＵＲＬを、ローカルに保存するステップをさらに含む。

さらには、このような方法のいずれか、またはその組み合わせを実行するための命令を含むコンピュータプログラムが提供される。

さらには、前記コンピュータプログラムを記録したコンピュータ読み取り可能な媒体が提供される。

さらには、前記コンピュータプログラムを記録したメモリに接続されたプロセッサを備えるシステムが提供される。

以下、非限定的な例として、本発明の実施の形態を添付の図面を参照しつつ説明する。
先行技術のクローリング技術における時系列を示す。 先行技術のクローリング技術における時系列を示す。 本方法の一例のフローチャートを示す。 サーバクライアントネットワークの一例を示す。 システムの一例を示す。 Ｗｅｂコーパスを構築するための方法の時系列の一例を示す。

図３のフローチャートは、クライアントサーバシステムによって実行される、コンピュータに実装された方法であって、あるテーマに関連するＷｅｂコーパスを構築するための方法の一例を示す。本例の方法は、クライアントが、サーチエンジンのインデックスを記憶するサーバに対し、構造化クエリを送信するステップ（Ｓ１０）を含む。構造化クエリは、テーマに対応し、かつ、少なくとも１つのキーワードの論理和からなる。次に、当該方法は、サーバが、構造化クエリに基づいて、ＷｅｂコーパスのページのＵＲＬをストリームとしてクライアントに送信するステップ（Ｓ２０）を含む。送信（Ｓ２０）は、サーバがクライアントから構造化クエリを受信（Ｓ２２）すると、インデックス内において当該クエリに合致するすべてのページのＵＲＬからなるグループ（すなわち、「グループ」という用語は単に集合を指す）を決定するステップ（Ｓ２４）を含む。決定（Ｓ２４）は、インデックスからクエリの論理和のキーワードを読み出し（Ｓ２４２）（すなわち、キーワードをインデックスのエントリと比較し）、それによりインデックスから少なくとも一組のＵＲＬを取得し（すなわち、サーチエンジンで、それ自体公知である緩和能力（ｒｅｌａｘａｔｉｏｎ ｃａｐａｂｉｌｉｔｉｅｓ）が用いられていれば、それに応じて、エントリがキーワードに完全に合致するか、あるいはほぼ合致する、インデックスのデータを出力し）、その後、取得したＵＲＬの集合に対して、クエリの論理和に対応する、（少なくとも１つの）集合演算のスキームを実行し（Ｓ２４４）、これにより、ＵＲＬのグループ（すなわち、返されるべきクエリの「結果」）を導き出す。また、送信（Ｓ２０）は、クライアントに、グループにおけるＵＲＬをストリームとして送信するステップ（Ｓ２６）も含む。送信（Ｓ２６）は、クライアントとのＨＴＴＰ接続を確立するステップ（Ｓ２６２）を含む（なお、確立（Ｓ２６２）は、そうした接続を開始するステップに対応する可能性があるが、必ずしもそうとは限らない。なぜなら、ＨＴＴＰ接続は、それ以前に初めて開始されている可能性があり（例えば、送信（Ｓ１０）以前）、その場合、確立（Ｓ２６２）は、そうした接続の回復／継続に対応するからである）。送信（Ｓ２６）は、グループにおけるＵＲＬをＨＴＴＰ接続上で（すなわち、ＨＴＴＰ接続を介して）ストリーミングするステップ（Ｓ２６４）も含む。そして、本例における送信（Ｓ２６）は、ＨＴＴＰ接続を終了するステップ（Ｓ２６６）を含む。本例における方法は、クライアントが、サーバからストリームとして受信したＵＲＬを、ローカル（例えばＵＲＬを受信したクライアントと同じマシーンの、例えば永続性を有するメモリ上）に記憶するステップ（Ｓ３０）をさらに含む。そして本方法は、クライアントが、サーバから受信したＵＲＬのページをクロールするステップ（Ｓ４０）をさらに含む（例えば、クライアントと同じマシーン、あるいは他のマシーンによる。このような場合、本方法は、サーバから受信したＵＲＬをＷｅｂクローラに送信するステップを含むことができる）。

このような方法は、テーマ型Ｗｅｂコーパスの構築を改善する。

特に、クロール（Ｓ４０）は、グループにおけるＵＲＬのページ（テーマに対応する構造化クエリと合致するすべてのページのＵＲＬからなるグループ）に対して実行されるため、本方法の、テーマに関する適合率と再現率は比較的高い。実際、当該分野で公知のように、テーマ型Ｗｅｂコーパスは、特定のテーマ／トピックに関連する、（例えば任意の種類の）Ｗｅｂドキュメント／ページの集合である。また、それ自体公知であるように、サーチエンジンインデックス（例えば転置インデックス）は、接続されたサーチエンジンに入力された構造化クエリ（構造化クエリとは、そうした技術において古典的であるように、例えば、サーチエンジンによって提供される所定の文法および／または構文規則があれば、それに応じて、すなわち、それに準拠して記載された少なくとも１つのキーワードの論理和である）を介して、容易に（すなわち、直接的かつ比較的高速に）取得することが可能な、整理されたデータ集合である（あるいは少なくともそれを含む）。図３の方法は、こうした背景を、テーマ型コーパスの構築／作成に生かしている。なぜなら、これは、テーマに対応する構造化クエリを介して行われるからである（すなわち、サーチエンジンおよびそのインデックスが与えられたとき、構造化クエリの結果は、テーマ内のドキュメント、例えば、少なくとも実質的に全てのそのようなドキュメントである）。その目的のために、構造化クエリは、構築するＷｅｂコーパスの仕様（例えば、想定しているテーマについての記述）が与えられれば、例えば、ユーザおよび／またはユーザのチームによって、図３の方法に対して、任意の手法で事前に設計することができる。なお、構造化クエリを設計するための特定の手法は、本議論の範疇には含まれない（ただし、一例が、アルゴリズムのステップ１および２において後ほど示されている）。ある意味で、テーマ型Ｗｅｂコーパスは、このような文脈において、Ｓ３０で記憶した（したがってＳ４０でクロール対象となった可能性のある）ＵＲＬに対応し、ゆえに構造化クエリの結果（これは、図３の方法の観点からは、任意の方法で予め定義されたものとみることができる）に対応する、ページ／ドキュメントのコーパスとして定義可能であるに過ぎない。そのため、クローリング（Ｓ４０）は、グループにおけるＵＲＬ（Ｓ２６で送信したもの）であって、それ自体少なくとも大部分（すべてでない場合）がテーマに関連するページを示しているＵＲＬのうち、少なくとも大部分（例えば、１００％でない場合、クロール対象ページの９０％超）に対して（順次、あるいはパラレルクローリングを用いて）実行可能であるため、「集中的」であると認定できる。

当該ＵＲＬがＳ２６４においてサーバからクライアントに送信されるため、この方法では、必ずしもサーバに、全てのＵＲＬを記憶すること、および／または、最終的な集中的クローリングを実行することを課さない。一例として、本方法では、サーバが、グループを（少なくとも送信（Ｓ１０）後、すなわちＳ２０内に）永続的に記憶することは除外する。「グループを記憶する」とは、記憶された情報が、グループにおけるＵＲＬだけでなく、それらＵＲＬの形成する情報、あるいは、グループの一部である情報をも含むことを意味する。言い換えれば、サーバでは、グループは、例えば送信（Ｓ２６）の前に、せいぜい揮発性メモリに記録されるか、あるいはグループとしては記憶しないことさえある（例えば、単にグループにおけるＵＲＬが、例えば揮発性メモリに記録され、記録されるときにストリーム化される）。いずれの場合も、グループが不揮発性メモリに（グループとして）記憶されることはおそらくない。一方、Ｓ３０では、クライアントはＵＲＬを、特にグループとして記憶し、かつ／または、不揮発性（すなわち永続的）メモリに記憶する可能性がある。本方法は、同様に、サーバが当該ＵＲＬの集中的クローリングを実行することを除外できる（これもまた少なくとも送信（Ｓ１０）の後、すなわちＳ２０内に行われる。なぜならサーバは、本方法以前、例えば、サーチエンジンを構築する際に、当該ＵＲＬをクロール済みかもしれないからである。しかしこの場合は、非集中的クローリングである）。一方、Ｓ４０では、クライアントは、集中的クローリングを行う（なお、クライアントは、想定されるアプリケーションに応じて、関連する情報、例えばＵＲＬのグループを、そのような集中的クローリングを行うことが可能なサードパーティに対し、同等な方法で送信するか、あるいは、そのような集中的クローリングを行うことが可能なサーバに後で返すこともでき、図３の方法は、このような態様の一例に過ぎない）。

クエリの結果（すなわち、クエリに合致するすべてのページのＵＲＬからなるインデックス内のグループ）を決定するステップ（Ｓ２４）が、インデックスからクエリの論理和におけるキーワードを読み出すステップ（Ｓ２４２）と、それによりインデックス（すなわち読み出し（Ｓ２４２）の出力）から少なくとも一組のＵＲＬを取得し、そして取得した少なくとも一組のＵＲＬに対して、クエリの論理和に対応する集合演算のスキームを実行（Ｓ２４４）し、それによりＵＲＬのグループ（すなわちスキームＳ２４４の出力）を導き出すことからなる（すなわち、正確には、例えば当該ＵＲＬに対し、後にも組み合わせにおいても、ランキングを追加することがない）ため、図３の方法は、サーバ側から見ると、比較的高速に行われる。実際、それ自体サーチエンジンの分野で公知であるように、サーチエンジンインデックスは、常に、ある形式のＳ２４２およびＳ２４４を実施し、これらは古典的な手法で実行することが可能であり、広範にわたって詳述する必要はない。しかしながら、古典的なサーチエンジンでは、構造化クエリを送信したクライアントに対して結果を返す前に、さらに、結果をランキングする。このようなランキングには時間がかかり、またハードウェアリソースも消費する（ドキュメントがＲＡＭ等を含む一時的なメモリに記憶されるとき、ランキングアルゴリズムがアクセスする）が、本方法では、後のクローリング（Ｓ４０）を介してテーマ型Ｗｅｂコーパスを構築するという目的にはランキングは不必要であると素早く判断する。したがって、Ｓ２４は、Ｓ２４２において、クエリの異なるキーワード（例えば、各キーワード）に合致する、（例えばすべての）（ＵＲＬの）集合についてのインデックスから抽出を行うこと（なお、通常そうであるように、インデックスがいくつかの別個のサーバに格納されている場合、当業者には知られているように、同じキーワードに対して異なる集合が相応に取得される）と、Ｓ２４２において、集合演算の最終的なスキーム（すなわち、集合を入力とする数学的演算）を構造化クエリに従って実行することに限定される（論理和からスキームを導き出す手法は古典的であり、当該分野ではそれ自体公知であるため、ここでは詳述しない）。さらに、古典的なサーチエンジンは、ランキングを実行するがために、通常、Ｓ２４２を完全には実施しない。実際、古典的には、クエリは必ずしもすべてのＵＲＬに対して実行される必要はないとされる。まず、たいていの場合において最初の結果ページを取り込むのには十分な小さなサブインデックスに対して、実行する。実際、ランキングには、コンテンツの人気および質を含む、クエリには依存しないいくつかのパラメータが考慮され、たいていのクエリにおいて、コンテンツのうちのいちばん人気が高い、あるいは質が高いページで、最初の結果ページを埋めることができる。例えば、ユーザは、まず最高ランクの結果の第一ページを受信し、次に、より低いランクの結果についてページごとに要求することが可能で、ユーザがさらなる結果を求めると、サーチエンジンインデックスは、集合を計算し集合演算を実行する。一方、図３の方法では、Ｓ２４２が、候補となるすべての集合および／またはＵＲＬが決定されるまで、連続的に／途切れることなく実行されてもよく、これにより、この方法では、ユーザが、例えばさらなる結果を要求するために演算と対話するのとは独立して、途切れることなく、Ｓ２４でクエリのすべての結果を決定する。

当該ＵＲＬがサーバによってストリームとして送信されるため、図３の方法では、サーバがすべての結果を（不揮発性メモリにさえも）一度に記憶する必要がなく、したがって本方法では除外されてもよく、さらには、クライアント側から見ると高速に実行できる。ストリームの概念は、コンピュータサイエンスの分野で広く知られている。ストリーミング（Ｓ２６）では、サーバがＵＲＬを、それが構造化クエリの結果であると判断するとすぐに送信することになる（これは、まずランキングを行ってからバッチでデータを送信する古典的なサーチエンジンとは対照的である）。典型的には、ストリーミング法は、セッション開始、ストリーム、およびセッション終了をその本質とする。図１の方法では、ＨＴＴＰ接続を介したこのようなストリーミング（Ｓ２６）の具体例を実施している。ＨＴＴＰ接続が特にうまく機能するが、本方法においては、他のプロトコル（たとえばＦＴＰ接続など）、さらに一般的には、任意のネットワーク接続が実施できる。

本方法は、コンピュータにより実施される。これは、方法の各ステップ（または実質的にすべてのステップ）が、少なくとも１つのコンピュータまたは同様の任意のシステム、すなわちコンピュータプログラムが記録されたメモリに結合された少なくとも１つのプロセッサを含むシステムによって実行されることを意味し、当該プログラムは、本方法を実行するための命令を含む。メモリは、データベースを記憶していてもよい。メモリは、そのような記憶に適した任意のハードウェアであり、場合により、物理的に区別可能ないくつかの部分（例えば、プログラム用に１つ、場合によりデータベース用に１つ）を含む。具体的には、本方法は、サーバシステムと通信を行うクライアントシステムにより実行され、これら２つのシステムは、場合によっては区別可能なマシーンであって、また、場合によっては、地理的に離れている可能性もある（例えば、少なくとも、異なる部屋、異なるビル、異なる都市、さらには異なる国など）。これは、クライアントおよびサーバが、典型的にはネットワーク（例えば、インターネット）を介して通信可能に結合されるように構成されたハードウェアおよび／またはソフトウェアを備えることを意味する。図４は、このようなネットワークの一例を示し、ここでは、図３の方法において、任意のクライアントがサーバと関わっていてもよい。

このように、本方法のステップは、場合によっては完全に自動的に、あるいは半自動的に実行される。例えば、本方法の少なくともいくつかのステップは、ユーザとコンピュータの対話を通じて始動されてもよい。求められるユーザとコンピュータの対話レベルは、想定される自動性のレベルに応じたものであって、ユーザの要望を実装する必要性との間でバランスをとるものとしてもよい。例えば、このレベルは、ユーザが定義し、かつ／または、あらかじめ定義するものであってもよい。例えば、本方法は、Ｓ１０の前に、ユーザまたはチームが構造化クエリを設計し、設計した構造化クエリをクライアントに入力し、その後、Ｓ１０を始動することを含む。Ｓ２０は、その後、場合により自動的に、あるいはユーザによって（例えば、予め定義された手法で、または受信（Ｓ２２）後に手作業で）提供される承認に基づいて、自動的に実行されてもよい。Ｓ３０は、自動的に、あるいは場合によりユーザの確認後、実行されてもよい。そして、Ｓ４０は、自動的に実行、あるいは必要に応じていつでも起動できるように、予め定義されていてもよい。例は後述する。

図３は、クライアントおよび／またはサーバを表現可能な、コンピュータシステムの一例を示す。この例のコンピュータは、内部通信バス１０００に接続された中央処理装置（ＣＰＵ）１０１０と、同じくバスに接続されたランダムアクセスメモリ（ＲＡＭ）１０７０とを備える。大容量記憶装置コントローラ１０２０は、ハードドライブ１０３０などの大容量記憶装置へのアクセスを管理する。コンピュータプログラムの命令及びデータを具体的に実現するのに適した大容量メモリ装置は、例として、ＥＰＲＯＭ、ＥＥＰＲＯＭ及びフラッシュメモリ装置のような半導体メモリ装置、内蔵ハードディスクやリムーバブルディスクなどの磁気ディスク、光磁気ディスク、およびＣＤ−ＲＯＭディスク１０４０を含む、全ての形式の不揮発性メモリを含む。前述のいずれも、特別に設計されたＡＳＩＣ（特定用途向け集積回路）によって補完されてもよいし、組み入れられてもよい。ネットワークアダプタ１０５０は、ネットワーク１０６０へのアクセスを管理する。本例のコンピュータは、さらに、バスに接続されたビデオランダムアクセスメモリ１１００と関連付けられたグラフィックス処理装置（ＧＰＵ）１１１０を備える。ビデオＲＡＭ１１００は、当該技術分野において、フレームバッファとしても知られる。コンピュータはまた、カーソル制御装置、キーボードなどの触覚装置１０９０を含んでいてもよい。カーソル制御装置は、ユーザがディスプレイ１０８０上の任意の所望の位置にカーソルを選択的に位置させることを可能にするために、コンピュータ内で使用される。さらに、カーソル制御デバイスは、ユーザが様々なコマンドを選択し、制御信号を入力することを可能にする。カーソル制御装置は、システムに制御信号を入力するための多数の信号生成装置を含む。典型的には、カーソル制御装置はマウスであってもよく、マウスのボタンは信号を生成するために使用される。あるいは、または追加的に、コンピュータシステムは、感知パッドおよび／または感知スクリーンを備えてもよい。

コンピュータプログラムは、コンピュータによって実行可能な命令を含んでいてもよく、命令は、上記システムに方法を実行させるための手段を含む。プログラムは、システムのメモリを含む任意のデータ記憶媒体に記録可能であってもよい。プログラムは、例えば、デジタル電子回路、またはコンピュータハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実装されてもよい。プログラムは、例えばプログラマブルプロセッサによる実行のための機械読み取り可能な記憶装置に具体的に実現された製品のような装置として実装されてもよい。方法ステップは、プログラム可能なプロセッサが命令のプログラムを実行し、入力データを操作して出力を生成することによって方法の機能を実行することによって実行されてもよい。したがって、プロセッサは、データ記憶システム、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスからデータおよび命令を受信し、また、それらにデータおよび命令を送信するようにプログラム可能であってもよく、またそのように接続されていてもよい。アプリケーションプログラムは、高水準の手続き型またはオブジェクト指向のプログラミング言語で、または必要に応じてアセンブリ言語または機械語で実装されていてもよい。いずれの場合も、言語はコンパイラ型言語またはインタープリタ型言語であってもよい。プログラムは、フルインストールプログラムまたは更新プログラムであってもよい。いずれの場合も、プログラムをシステムに適用すると、本方法を実行するための指示が得られる。

「メモリ」という用語は、任意のメモリストレージ、または接続された一連のメモリストレージを指していてもよい。Ｗｅｂインデックスを構築するとは、Ｗｅｂコーパスに索引付けすることを指す。すでに述べたように、コーパスは、ドキュメントの集合である（例えば、公開Ｗｅｂ／民間企業）。サーチエンジンのインデックスは、サーチエンジンのインターフェースまたはサーチベースアプリケーション（ＳＢＡ）を使用して作成されたクエリへの応答を提供するためにドキュメントを選択しランク付けするシステムを指していてもよい。コーパスは、選択およびランキングのためにインデックスに利用可能なドキュメントの集合であってもよい。Ｗｅｂコーパスは、Ｗｅｂページ上のＵＲＬを用いて発見される、Ｗｅｂページ、さらにはＰＤＦ、画像などのドキュメントを含む、Ｗｅｂ上で最初に発見されるドキュメントのコーパスである。Ｗｅｂインデックスは、Ｗｅｂコーパスに基づくインデックスである。テーマ型インデックスは、特定のトピックに関連するクエリ専用のサーチエンジンまたはサーチベースのアプリケーションのインデックスであってもよい。これらには、すべてのプロフェッショナル（Ｂ２Ｂ）サーチエンジンとＳＢＡが含まれ、これらは少なくとも、ユーザの産業に関連するトピックに特化している。プロフェッショナルサーチエンジン、あるいはＳＢＡは、典型的には、予め定義した使用シナリオをサポートするように構築されており、このシナリオは、インデックスで予想されるクエリに、限定された範囲を設定する。コーパスはドキュメント、例えばＷｅｂページ（本方法で想定されている）の集合であり、テーマ型Ｗｅｂコーパスはテーマに関するＷｅｂインデックスのコーパス、すなわち、クエリに応答する選択に用いられるインデックスに利用可能なドキュメント（例えばＷｅｂページ）である。

例えば、特化型のサーチエンジンやＳＢＡは、テーマ、例えば、投資家が使用する金融資産に関するに情報を提供することに特化していてもよい。クエリは、典型的には、ユーザのポートフォリオに含まれる資産を含む。１つの実装法として、投資家が手動ではクエリを入力しないことが考えられる。クエリは投資家の現在の投資ポートフォリオに基づいて生成される。クエリに応答して、そのポートフォリオに対して影響が最も大きいと考えられるニュースが選択され、最も関連度の高いものから順に返される。特化型サーチエンジンやＳＢＡの開発者やユーザには、すべてのクエリがサポートされているとは限らないことが広く知られている。サーチエンジンまたはＳＢＡインターフェースに、ユーザが自由にクエリを提供できるクエリボックスが表示されている場合、ユーザは、技術的には、サポートされていないクエリを入力できる。例えば、サーチエンジンが金融資産に特化しているにもかかわらず、投資家が突然自分の祖母のことを考え、そのクエリボックスを使用して、祖母の健康状態について調べようとするかもしれない。クエリは［祖母 健康状態］のようなものかもしれない。しかし、このサーチエンジンは金融資産に特化しているため、このクエリに対して関連するページを返さないかもしれない。これはサーチエンジンの欠陥ではなく、使い方が不適切であるに過ぎない。

図３の方法は、具体的には、例えばそのような目的のためにテーマ型Ｗｅｂコーパスを構築することを可能にする。特に、本方法は、ドキュメントのフィルタリングやランキングには関与せず、それはインデックスの責務である。本方法は、サーチエンジンやＳＢＡのインターフェースにも関与しない。テーマ型Ｗｅｂコーパスを構築するとき、図３の方法では、テーマ型Ｗｅｂインデックスに関するクエリに応答して返される可能性のあるＷｅｂページの集合を、正確に収集することが可能になる。多くない：インデックスに関するクエリに応答して返されることのないページは無用であり、ストレージおよびＲＡＭの領域を不必要に占有する。少なくない：クエリに関連するＷｅｂページがコーパスに存在し、ユーザが、当該クエリに応じて受け取るようにする必要がある（そうでなければ、インデックスの再現率に影響が出る）。上記の広範な議論に示したように、図３の方法は、特別な種類のサーチエンジン（ＵＲＬストリーミング網羅的サーチエンジン。ストリーミングサーチとしても知られる）が設けられていることを除けば、サーチエンジンの助けを借りるクロールの方法と類似している。Ｗｅｂサーチエンジンは、典型的には、クエリに対して、少数のクエリ結果に関連するリンクおよびサマリーを表示するために使用される、機械読み取り可能なフォーマット（例えば、ＨＴＭＬ、ＸＭＬ、またはＪＳＯＮ）のページを用いて応答する。このように、図３の方法のようなＷｅｂサーチエンジンの助けを借りたクロールは、そのような複数のページを照会して、各ページ上のリンクを抽出し、これらのリンクをクロールすることをその本質とする。ストリーミングサーチ（Ｓ２４およびＳ２６）は、コーパスコレクションで用いられる古典的なサーチエンジンの欠点を改善する。Ｗｅｂページのランキングは行わず、結果のページを用いて応答しない。その代わりに、ＵＲＬがインデックス内で見つかった順に並んだ、ＵＲＬのストリームを用いて応答する。クローラは、これらのＵＲＬによって特定されたページを取得するため、Ｓ４０で、Ｗｅｂサイトに接触してもよい。適合率が高い：コーパスは、クエリがトピックを正確に記述しており、かつクエリに使用されるインデックスが新しい（インデックスに格納されているページと、現在Ｗｅｂ上で提供されている同じページとの間にはほとんど違いがないため、インデックスの応答が正確である）と仮定して、クエリに完全に合致するＷｅｂページから構成され得る。再現率が高い：コーパスは、クエリに使用されるインデックスが完全で新しいと仮定すると、クエリに合致するすべてのＷｅｂページで構成されている。コストが安い：不要な操作を行う必要がない。主な全体コストは、最初のインデックスを構築するコストである。同じインデックスを用いて構築したテーマ型コーパスの数が多いほど、テーマ型コーパス１つあたりのグローバルコストは安くなる。

一般的なＷｅｂサーチエンジンは、典型的には、サーチバーとサーチ結果のリストを提供する。特化型サーチエンジンおよびＳＢＡは、典型的には、高度なナビゲーションとグラフも提供する。ナビゲーションオプションには、カテゴリ別に資産をブラウズすることが含まれる。例えば、トップレベルのカテゴリには、「株式」、「デリバティブ」、「通貨」、「原料」などがある。「株式」をクリックすると、最近のニュースで見つかった株式のリストがユーザのポートフォリオから展開されてもよい。株式をクリックすると、ニュースがフィルタリングされ、選択した株式に関連するニュースのみが表示されてもよい。グラフには、今日のニュースで最も引用されている資産が高いバーで表される、日毎のトップ資産の棒グラフが含まれていてもよい。これらのナビゲーションオプションとグラフは、すべてのドキュメントにおけるすべての資産を検出することによって表示される。ドキュメント内に資産への参照がある場合、インデックスはそれをＲＡＭに記憶してもよい。なぜなら、ＲＡＭはディスクよりもはるかに応答性が高く、ナビゲーションオプションとグラフを表示するには、これらの参照を素早く反復する必要があるためである。これらの参照はファセットと呼ばれる。ナビゲーションおよびグラフに使用されるファセットはＲＡＭ領域を占有し、それはインデックス内のドキュメントの数とともに増加する。ＲＡＭ領域は高価であり、しばしば特化型サーチエンジンやＳＢＡのハードウェアインフラのボトルネックになる。インターフェースが豊富であるほど、各ドキュメントからより多くのファセットが抽出される可能性が高くなり、コーパス内のドキュメントごとにより多くのＲＡＭ領域を割り当てる必要がある。特化型サーチエンジンやＳＢＡでは、ユーザの典型的な関心事が分かっているため、トピックに関連している可能性のあるナビゲーションオプションやグラフなどを含む、豊富なインターフェースを提供することができる。結果として、より多くのファセットが必要とされ、コーパスのサイズにより多くの注意を払わなければならなくなる。コーパスには、不要なドキュメントが含まれていないほうがよい。結果として、特化型サーチエンジンまたはＳＢＡのインターフェースを介したクエリに応答するインデックスに必要なすべてのドキュメントのみを含むコーパスを提供する手法が真に求められている。そして、図３の方法がそのような必要に応えている。

図３の例に応じた、テーマ型Ｗｅｂコーパスを構築する方法の一例について、図６を参照して説明する。図６は以下に述べる時系列を（上から下に）示している。

テーマ型インデックスによってサポートされる、考えられるすべてのクエリの集合Ｑが与えられると、このインデックスのための理想的なテーマ型コーパスＣは、クエリｑ＝ＯＲ（ｑ’，ｆｏｒ ｑ’ ｉｎ Ｑ）に合致するドキュメントの集合となる：インデック
スにサポートされているすべてのクエリの論理和。テーマ型コーパスは、Ｑのクエリの結果（すなわち、そのようなすべてのドキュメントであり、それ以上ではない）に現れ得るすべてのドキュメントからなる。以下のアルゴリズムは、図３の方法を用いてどのようにＣを構築するかを説明したものである。
０． 空のリストＬを作成する
１． インデックスにサポートされるべきクエリｑ’を収集する。これは、想定されるユ
ーザへのインタビューや、サーチエンジンやＳＢＡの仕様に基づいて行うことができる。
２． １で見つかったクエリを選言標準形ｄで記載する。ｑ’は、ブール式であるため、
ｄが存在し、一意である。
３． ｄにおける各連言節ｃについて、仮にｃがＬの要素を含んでいなければ（ｃ中のその式を、その項の連言節で置換する。例えば、［ａ］がＬに含まれる場合、［’ａ ｂ
ｃ’ ＡＮＤ ｄ］は取り除かれる）：
３．１ 置換後のｃもサポートされるようにｃの項の代理を探す。（例えば、株式市場における会社コードを、その他のすべての会社コードで置き換える。代理の数が多い場合、典型的には、このステップはスクリプト化する必要がある。）
３．２ 可能な代理のすべての組み合わせを用いて、連言節ｃ１・・・ｃｎを生成する。
３．３ 本発明によるシステムでクエリｃ１・・・ｃｎのそれぞれを実行し、その結果をコーパスに加える。
３．４ Ｌ中のｃ１・・・ｃｎを記憶する。
４． （ａ）サポートされるクエリがそれ以上みつからなくなるまで、あるいは（ｂ）サポートされ３．０を満たすようなクエリがそれ以上みつからなくなるまで１から繰り返す。
理論的には、項の数が有限であることを理由にこの方法は終了する。実際には、ＡＮＤがない、またはＡＮＤの数が少ないクエリを使用して開始すると、４．ｂですぐに停止する。本方法では有用なページのみが収集される。クローリングに基づく方法では、ページを収集する前に有用かどうかを知ることができないため、有用ではないページも収集される。先行技術のクローリング（集中クローリングを含む）は、本方法に比べて適合率が低い。例では、本方法の適合率は１００％である。本方法の再現率は、参照Ｗｅｂインデックスのサイズによってのみ制限される。仮に参照ＷｅｂインデックスがすべてのＷｅｂページを含むなら、本方法の再現率は、１００％となり得る。実際には、参照Ｗｅｂインデックスは網羅的ではない。実装時には、本方法は、３２０億ページのＷｅｂインデックスを使用できる。参照インデックスに欠けたページがあると、方法における再現率が低下する。参照Ｗｅｂインデックスを構築するのにコストがかかるため、本方法は、参照Ｗｅｂインデックスがすでに利用可能な場合、または複数のテーマ型インデックスが参照Ｗｅｂインデックスに基づいて構築される場合、特に費用対効果が高くなる。クローリングは、Ｗｅｂサイトサーバの遅延を招く。各ステップにおいて、クローラは、クロールする新しいページのＵＲＬを収集するためにＷｅｂページをロードする必要がある。本方法では、典型的には、各クエリに応答して一度に大量のＷｅｂページを収集する。

例示的な特徴を実現する図３の方法の一例について以下に説明する。

本例の第一のステップで、ユーザがクエリを選択してもよい。例えば、ユーザは、最終的にＯｂａｍａについてのＷｅｂドキュメントを取得することを目標とし、そのために「Ｏｂａｍａ」というクエリを選択する。クエリは、より複雑なものになる可能性がある。例えば、「Ｏｂａｍａ ａｎｄ ‘Ｐｒｅｓｉｄｅｎｔｉａｌ ｒａｃｅ’ ａｎｄ −Ｍｉｃｈｅｌｌｅ」では、オバマおよび大統領選挙に関連し、ミシェル・オバマには関連しないドキュメントが対象となる。ユーザは、設定インターフェースに提示されたテキストフィールドにクエリを挿入することができる。ユーザは、それが一度限りのクエリであるか、それとも定期的に行うべきかを選択することもできる。後者の場合には、ユーザは、クエリがどの程度の間隔で実行されるべきかを選択する。ユーザは、取得すべきドキュメントの数の上限を選択することもできる。合致するドキュメントの総数は、数億のオーダーになる可能性があり、ユーザは、典型的には、クエリに基づいて収集されるドキュメントの数を数百万に制限する。ソートのステップが含まれていない場合、これらの数百万のドキュメントは、すべての合致するドキュメントの中からランダムに収集されてもよい。より正確には、クエリに合致するドキュメントで、インデックスにおいて最初に見つかったものであってもよい。クエリは、ユーザが管理インターフェース上の「実行」ボタンを押すかクリックしたとき、またはスケジュールされた時間が経過したときに実行されてもよい。クエリは、その後、Ｓ１０でインデックスに送られ、ＨＴＴＰ（またはＨＴＴＰＳ）リクエストを介して実行される。リクエストは、典型的には、顧客のサーバ（テーマ型コーパスが収集されるべき場所）から始まる外部ネットワークを通って、典型的には遠隔サービスのサーバ上に位置するストリーミングインデックスまで進む。そこにおいてＳ２２でクエリが受信される。

ストリーミングインデックスは、典型的には、以下の２つのステップを用いてクエリを解決する。第一のステップＳ２４２において、ルックアップテーブル／転置リスト／辞書と呼ばれる構造体においてクエリのキーワードを検索する。この構造体は、これらのキーワードを含むドキュメントの識別子を指し示す、ソート済みキーワードリストのセットである。キーワードは、検索が早くなるようにソートされている。この構造内において一意の識別子を付けるために、別のプロセスで、Ｗｅｂ文書はクロールされ、格納され、インデックス化されている。クローリングとは、それぞれのＷｅｂサイトサーバから、Ｗｅｂドキュメントを、（ドキュメントのＵＲＬを含むこれらのサーバにＨＴＴＰクエリを発行することによって）収集することを意味する。記憶とは、ローカルキャッシュにコピーすることを意味する（ドキュメントを複数回要求するのを避けるため）。インデックス化では、ドキュメントから単語を抽出し（それらを選択し、予め正規化してもよい）、また、転置リストにおける、結果として得られた単語それぞれの前に、ドキュメントのＩＤを追加する（必要であれば転置リストに単語を追加してもよい）。第二のステップＳ２４４において、インデックスはクエリの論理式を解釈し、第一のステップで見つかったドキュメントに対して集合演算を適用する。例えば、「Ｏｂａｍａ」を含むドキュメントの集合と「Ｐｒｅｓｉｄｅｎｔｉａｌ ｒａｃｅ」を含むドキュメントの集合との交わりから「Ｍｉｃｈｅｌｌｅ」を含む文書の集合を除いた集合を返す。これらの演算は、典型的には、標準的なサーチエンジンによって実行される演算である。標準的なサーチエンジンでは、このステップの後に、関連性が最も高いものから低いものへと、順にドキュメントをランクづけする他のステップが続く。図３の方法では、これらのステップは実施しない。

実際には、上述の２つのステップは、順には実行されない。たとえば、「Ｏｂａｍａ」を含むドキュメントからなる部分集合を最初にリスト化し、Ｏｂａｍａを含む別のドキュメントの集合を処理する前に、「Ｐｒｅｓｉｄｅｎｔｉａｌ ｒａｃｅ」と「Ｍｉｃｈｅｌｌｅ」も含まれているかどうかに基づいてフィルタリングすることができる。一般に、結果は、ドキュメントが見つかった分散ストレージサーバに対応するバッチによって処理され、それらを処理する処理サーバ上で利用可能なＲＡＭに応じてさらに分類してもよい。さらに、転置リストの階層があってもよく、階層内の最初のリストは、より関連性の高い結果をもたらす傾向があるため、最初に検索される。最上層の転置リストは、典型的には、タイトルなど、Ｗｅｂページの特別な位置にあるキーワード、または他のＷｅｂページ上に見つかったリンクで、当該Ｗｅｂページを指し示すリンクにあるキーワードのみを記憶する。これらの内部構造およびインデックスのパフォーマンスを最適化するためのアルゴリズムは、すべて、クエリに合致するドキュメントが取得される順序に影響を与える可能性がある。

ドキュメントを取得する間、インデックスは、クエリによって開始されたＨＴＴＰ接続を用いてクエリに応答し（これによりＳ２６２は、この例では、Ｓ１０の後に実行される）、ドキュメントのＵＲＬが取得されると、それらをストリーミング（Ｓ２６４）する（ドキュメント自体ではない）。接続を開始しクエリを発行したクライアント上のプロセスは、ストリーミングインデックスからＵＲＬを受け取る。好ましい実施形態では、このクライアントプロセスはＵＲＬをクローラに送信する。クローラは、典型的には同じシステム上で実行される別のプロセスであってもよい。クローラは、Ｓ４０において、これらのＵＲＬに対応するドキュメントをそれぞれのＷｅｂサイトから取得することを担当する。別の実施形態では、ＵＲＬを受け取るプロセスは、Ｓ３０においてそれらをローカルに（例えば、ディスク上に）記憶し、クローラは、それらをローカルストレージから読み出してＳ４０を実行する。

古典的には、クローラは、取得した各ＵＲＬを使用してＨＴＴＰリクエストを発行することによって動作する。リクエストは、ＵＲＬをＩＰアドレスに変換するネームサーバや、宛先ＩＰアドレスに従ってパケットを送信するルータを含む、インターネットインフラを使用して、Ｗｅｂサイトのサーバに送られる。各Ｗｅｂサイトサーバは、リクエストで指定されたＵＲＬに対応するドキュメントを用いて応答する（または応答しない）。一例では、クローラは、複数のＷｅｂサイトに対して、これらのＷｅｂサイトの負荷の限界を守りつつ、並行してドキュメントを要求する手順を実施する。典型的には、２．５秒以内に複数のページを同じＷｅｂサイトから要求することはしない。クローラは、典型的には、並行して実行されるプロセスの集合であり、それぞれがＷｅｂサイトの部分集合を担当する。例えば、あるプロセスは、名前が「Ａ」などで始まるＷｅｂサイトの照会を担当する。一例では、コーパスがドキュメントのインデックスを構築するのに役立ち、クローラは次に、２つのことを行うことができる。（１）受信したドキュメントをローカルキャッシュに記憶する。ローカルキャッシュは単なるローカルストレージであって、ここでは、ドキュメントがそれぞれのＵＲＬで識別され、ＵＲＬで検索できる。（２）ドキュメントを受け取ると、ドキュメントを処理しインデックス化する別のプロセスに、それらをプッシュする。

Claims (12)

1. サーチエンジンのインデックスを記憶するサーバによって実行される、テーマに関連するＷｅｂコーパスのページのＵＲＬをクライアントに送信するための、コンピュータに実装された方法であって、
   前記テーマに対応し、かつ少なくとも１つのキーワードの論理和からなる構造化クエリを、前記クライアントから受信するステップと、
   前記インデックス中において、前記クエリに合致するすべてのページのＵＲＬからなるグループを決定するステップであって、
   前記インデックスから前記クエリの論理和における前記キーワードを読み出し、それによって前記インデックスから少なくとも一組のＵＲＬを取得するステップと、次いで、
   前記取得した少なくとも一組のＵＲＬに対して、前記クエリの論理和に対応する集合演算のスキームを実行し、それによってＵＲＬのグループを導き出す本質ステップと、
   前記クライアントに、前記グループにおける前記ＵＲＬをストリームとして送信するステップと
   を含むコンピュータに実装された方法。
2. 前記クライアントに前記グループにおける前記ＵＲＬをストリームとして送信するステップが、
   前記クライアントとのネットワーク接続を確立するステップと、
   前記ネットワーク接続上で前記グループにおける前記ＵＲＬをストリーミングするステップと、次いで、
   前記ネットワーク接続を終了するステップと
   を含む、請求項１に記載のコンピュータに実装された方法。
3. 前記ネットワーク接続がＨＴＴＰ接続である
   請求項２に記載のコンピュータに実装された方法。
4. テーマに関連するＷｅｂコーパスを構築するための、コンピュータに実装された方法であって、
   クライアントが、前記テーマに対応し、かつ少なくとも１つのキーワードの論理和からなる構造化クエリをサーチエンジンのインデックスを記憶するサーバに送信するステップと、次いで、
   前記サーバが、前記構造化クエリに基づき、請求項１、２、または３の方法に従って、前記ＷｅｂコーパスのページのＵＲＬをストリームとして前記クライアントに送信するステップと
   を含むコンピュータに実装された方法。
5. 前記クライアントが、前記サーバからストリームとして受信したＵＲＬを、ローカルに保存するステップをさらに含む
   請求項４に記載のコンピュータに実装された方法。
6. 前記クライアントが、前記サーバから受信したＵＲＬのページをクロールすること、または、前記サーバから受信したＵＲＬをＷｅｂクローラに送信するステップをさらに含む
   請求項４または５に記載のコンピュータに実装された方法。
7. クライアントによって実行される、テーマに関連するＷｅｂコーパスを構築するための、コンピュータに実装された方法であって、
   前記テーマに対応し、かつ少なくとも１つのキーワードの論理和からなる構造化クエリをサーバに送信するステップと、次いで、
   前記サーバから前記ＷｅｂコーパスのページのＵＲＬをストリームとして受信するステップと
   を含むコンピュータに実装された方法。
8. 前記サーバからストリームとして受信したＵＲＬを、ローカルに保存するステップをさらに含む
   請求項７に記載のコンピュータに実装された方法。
9. 前記サーバから受信したＵＲＬのページをクロールすること、または、前記サーバから受信したＵＲＬをＷｅｂクローラに送信するステップをさらに含む
   請求項７または８に記載のコンピュータに実装された方法。
10. 請求項１〜９のいずれかに記載の方法を実行するための命令を含むコンピュータプログラム。
11. 請求項１０に記載のコンピュータプログラムを記録したコンピュータ読み取り可能な媒体。
12. 請求項１０に記載のコンピュータプログラムを記録したメモリに接続されたプロセッサを備えるシステム。

Images