JP2018147437A - データ収集システム、データ収集方法、およびプログラム - Google Patents

Abstract

【課題】データ収集の効率向上を図ることができるデータ収集システム、データ収集方法、およびプログラムを提供すること。
【解決手段】本発明の一態様は、ネットワークを介してアクセス可能な装置に格納されたデータを参照するための参照情報を選出する選出部と、前記選出部により選出された前記参照情報が記憶される記憶部と、前記記憶部に記憶された前記参照情報を用いて、前記選出部の動作とは非同期に、前記ネットワークを介してアクセス可能な装置からデータを収集する収集部と、を備えるデータ収集システムである。
【選択図】図２

Description

本発明は、データ収集システム、データ収集方法、およびプログラムに関する。

従来、ウェブからデータ（文章や画像など）を収集し、収集したデータを自動的にデータベース化するクローラが知られている（特許文献１参照）。クローラは、ウェブページ中のリンクを辿って、様々なドメインのウェブページからデータを収集する。クローラによって収集されたデータは、ウェブ情報データベースに蓄積される。

特開２０１２−６８７３４号公報

ところで、検索サイトなどのさらなる利便性向上のため、より多くのデータを効率的に収集することが期待されている。ただし、大規模分散環境では、一般的なクローラは、前処理、データ収集、後処理が順に実行されるため、前処理や後処理が実行されている間のリソースの利用効率が低く、データ収集の効率が高くない場合がある。

本発明は、このような事情を考慮してなされたものであり、データ収集の効率向上を図ることができるデータ収集システム、データ収集方法、およびプログラムを提供することを目的の一つとする。

本発明の一態様は、ネットワークを介してアクセス可能な装置に格納されたデータを参照するための参照情報を選出する選出部と、前記選出部により選出された前記参照情報が記憶される記憶部と、前記記憶部に記憶された前記参照情報を用いて、前記選出部の動作とは非同期に、前記ネットワークを介してアクセス可能な装置からデータを収集する収集部と、を備えるデータ収集システムである。

本発明の一態様によれば、データ収集の効率向上を図ることができる。

第１の実施形態のクロールサーバ１０の使用環境を示す図である。 第１の実施形態のクロールサーバ１０の構成を示すブロック図である。 第１の実施形態のＵＲＬ管理テーブルＴ１（初期状態）の内容の一例を示す図である。 第１の実施形態のデータ収集部２００の構成を示すブロック図である。 第１の実施形態の対応テーブルＴ２の内容の一例を示す図である。 第１の実施形態のリンク構造情報Ｔ３の内容の一例を示す図である。 第１の実施形態のＵＲＬ管理テーブルＴ１（ステータスが更新された状態）の内容の一例を示す図である。 第１の実施形態の知識源解析部７００の構成を示すブロック図である。 第１の実施形態の第１対応テーブルＴ４の内容の一例を示す図である。 第１の実施形態の第２対応テーブルＴ５の内容の一例を示す図である。 第１の実施形態のＵＲＬ管理テーブルＴ１（スコアが更新された状態）の内容の一例を示す図である。 第１の実施形態のクロール処理を示すフローチャートである。 第１の実施形態のクロールサーバ１０の作用を説明するための図である。 第２の実施形態の知識源解析部７００Ａの構成を示すブロック図である。 第３の実施形態のＵＲＬ選出部１００によるＵＲＬの選出動作を説明するための図である。 第３の実施形態のスコア比率に応じたＵＲＬ数を決定するための対応テーブルＴ６の内容の一例を示す図である。

以下、図面を参照して、データ収集システム、データ収集方法、およびプログラムの実施形態について説明する。本実施形態では、データ収集システムがクロールサーバであるものとして説明する。クロールサーバとは、インターネットなどのネットワークを介してアクセス可能な複数の装置からデータを自動的に収集するサーバである。クロールサーバは、１つのプロセッサによって実現されてもよく、複数のプロセッサが分散処理することで実現されてもよい。更に、本実施形態のクロールサーバは、ユーザの目的に応じて知識源（有用な情報を含んだウェブ上のテキストデータ、画像データなど）を優先的に収集するクロールサーバであってよい。以下、実施形態について説明する。

＜第１の実施形態＞
図１は、第１の実施形態のクロールサーバ１０の使用環境を示す図である。クロールサーバ１０は、画像データおよびＨＴＭＬ（HyperText Markup Language）データの少なくとも一方を含むページデータを、ネットワークＮＷを介してアクセス可能な複数の外部サーバＳ１（複数の外部装置）から収集する。ページデータは、外部サーバＳ１に格納されており、ブラウザによって閲覧可能なページ単位のデータである。ただし、ページデータは、ブラウザに限らず、アプリケーションプログラムによって再生されるデータでもよい。ネットワークＮＷは、インターネットやＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）などを含む。

図１に示すように、クロールサーバ１０は、例えば、ＵＲＬ（Uniform Resource Locator）選出部１００と、データ収集部２００と、ＨＴＭＬ解析部３００と、コンテンツ書き込み部４００と、ＵＲＬステータス更新部５００と、目的受付部６００と、知識源解析部７００と、スコア更新部８００と、記憶部９００とを備える。

ＵＲＬ選出部１００、データ収集部２００、ＨＴＭＬ解析部３００、コンテンツ書き込み部４００、ＵＲＬステータス更新部５００、目的受付部６００、知識源解析部７００、およびスコア更新部８００（以下、これらを区別しない場合はそれぞれを「コンポーネントＣ」と称する）は、クロールサーバ１０のプロセッサがプログラムを実行することで実現される機能部（以下、「ソフトウェア機能部」と称する）でもよいし、ＬＳＩ（Large Scale Integration）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）などのハードウェアによって実現されてもよいし、ソフトウェア機能部とハードウェアとが協働することで実現されてもよい。プログラムは、例えば、バックグラウンドで自律動作するデーモン（daemon）プログラムである。

本実施形態のクロールサーバ１０は、前処理（例えばＵＲＬの選出）、データ収集（フェッチ）、および後処理（例えば取得されたデータの解析）を並行して非同期に実行することで、データ収集が一定時間以上に亘って継続的に行われる常時クロールを実現する。これを実現するため、本実施形態のクロールサーバ１０では、上述した各コンポーネントＣが、それぞれ互いに独立した１つのコンポートネントとして動作する。例えば、コンポーネントＣは、自身の起動、動作、停止のスケジュール、および動作速度を自ら決定可能である。

記憶部９００は、例えば、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ、またはこれらのうち複数が組み合わされたハイブリッド型記憶装置などにより実現される。記憶部９００は、ＮＡＳ（NetworkAttached Storage）や外部のストレージサーバなど、クロールサーバ１０のプロセッサがアクセス可能な外部装置により実現されてもよい。

記憶部９００には、ＵＲＬ選出データ９１０、ＨＴＭＬデータ９２０、画像データ９３０、フェッチ結果データ９４０、テキストデータ９５０、第１解析データ９６０、第２解析データ９７０、スコアデータ９８０などのデータと、ＵＲＬ管理データベースＤＢ１と、コンテンツ保存用データベースＤＢ２とが格納される。ただし、上記各データの名称は、互いの区別のために便宜上用いられたものであり、データの内容を限定するものではない。また各データは、テーブルやリストなどと称されてもよい。

記憶部９００に格納されたＵＲＬ選出データ９１０、ＨＴＭＬデータ９２０、画像データ９３０、フェッチ結果データ９４０、テキストデータ９５０、第１解析データ９６０、第２解析データ９７０、およびスコアデータ９８０は、２つのコンポーネントＣの間で受け渡されるデータである。上記各データが格納される記憶部９００の領域は、例えばＲＡＭによって実現されるが、これに限定されない。

図２は、本実施形態のクロールサーバ１０の構成を、処理の流れに即して示すブロック図である。以下、各コンポーネントＣの具体的な処理について説明する。なお以下では、クロールサーバ１０の処理の流れに沿って各コンポーネントＣの処理を順に説明するが、各コンポーネントＣの動作は互いに並行して実行される。

まず、ＵＲＬ管理データベースＤＢ１について説明する。ＵＲＬ管理データベースＤＢ１には、クロールサーバ１０がクロールを開始するための基礎となる複数のＵＲＬが外部から入力される。ＵＲＬは、外部サーバＳ１に格納されたデータを参照するための参照情報の一例である。ＵＲＬ管理データベースＤＢ１は、入力された複数のＵＲＬを、ＵＲＬ管理テーブルＴ１の一部として記憶する。

図３は、本実施形態のＵＲＬ管理テーブルＴ１（初期状態）の内容の一例を示す図である。図３に示すように、ＵＲＬ管理テーブルＴ１は、複数のＵＲＬと、各ＵＲＬに対応するステータス、第１スコア、および第２スコアとが互いに対応付けられたテーブルである。「ステータス」は、ＵＲＬに対応するページデータの取得状況を示す情報である。「第１スコア」および「第２スコア」は、ユーザの目的毎に付与されるデータ収集の優先度（重要度）を示す指標である。図３に示すように、初期状態のＵＲＬ管理テーブルＴ１には、クロールを開始するための基礎となる複数のＵＲＬが格納されている。また、初期状態のＵＲＬ管理テーブルＴ１では、全てのＵＲＬに関して、ステータスは「未取得」、第１スコアおよび第２スコアは「未付与」となっている。

次に、ＵＲＬ選出部１００について説明する。ＵＲＬ選出部１００は、ＵＲＬ管理テーブルＴ１に格納された複数のＵＲＬのなかから、データ収集部２００によるデータ収集に用いられるＵＲＬを選出する。例えば、ＵＲＬ選出部１００は、データ収集の優先度を考慮して、複数のＵＲＬのなかから優先的にデータを収集するＵＲＬを選出する。なおこの機能については、詳しく後述する。初期状態におけるＵＲＬ選出部１００は、ＵＲＬ管理テーブルＴ１に格納された複数のＵＲＬのなかで所定のフォーマットを満たしていないＵＲＬを選出せず、所定のフォーマットを満たす全てのＵＲＬをデータ収集対象のＵＲＬとして選出する。「所定のフォーマットを満たす」とは、アクセスのために最低限必要な情報が揃っていることである。図３に示す例では、ＵＲＬ“http;//host5/example/1.htm”は、“http”と“//”の間が“：（コロン）”ではなく、“；（セミコロン）”になっているため、所定のフォーマットを満たしていないＵＲＬの一例となる。なお、所定のフォーマットを満たしていないＵＲＬの別の例としては、スキーマ（“http://”など）が抜けている場合などである。ＵＲＬ選出部１００は、選出したＵＲＬをＵＲＬ選出データ９１０に登録する。例えば、ＵＲＬ選出部１００は、新しくＵＲＬを選出する毎に、選出したＵＲＬをＵＲＬ選出データ９１０に登録する。

次に、データ収集部２００について説明する。データ収集部２００は、ＵＲＬ選出データ９１０に登録されたＵＲＬを用いて、複数の外部サーバＳ１からデータを収集する。すなわち、データ収集部２００は、ＵＲＬ選出データ９１０から取得されたＵＲＬを参照することで、参照されたＵＲＬに対応するウェブページの格納先にアクセスし、ページデータを収集する。収集されるページデータには、ＨＴＭＬデータおよび画像データが含まれる。

詳しく述べると、本実施形態のデータ収集部２００は、ＵＲＬ選出データ９１０に登録されたＵＲＬを取得するための要求を、記憶部９００を制御する不図示のコントローラに送信することで、ＵＲＬ選出データ９１０に登録されたＵＲＬを自らのタイミングで取得する。そして、データ収集部２００は、取得されたＵＲＬに基づいて外部サーバＳ１からデータを収集する。これにより、データ収集部２００は、ＵＲＬ選出部１００がＵＲＬを選出する動作とは非同期で、外部サーバＳ１からデータを収集する。例えば、データ収集部２００は、ＵＲＬ選出部１００によって選出された多数のＵＲＬがＵＲＬ選出データ９１０に登録されている場合、ＵＲＬ選出データ９１０に登録された全てのＵＲＬを一度に取得することはせず、ＵＲＬ選出データ９１０に登録された一部のＵＲＬのみを一度に取得してもよい。例えば、データ収集部２００は、ＵＲＬ選出部１００が１つのＵＲＬを選出してＵＲＬ選出データ９１０に登録する周期よりも遅い周期で、１つのＵＲＬに対応するページデータを収集してもよい。データ収集部２００は、ＵＲＬ選出データ９１０を利用することで、ＵＲＬ選出部１００がＵＲＬを選出する動作と並行して動作する。

次に、本実施形態のデータ収集部２００の所定条件下での動作例を２つ説明する。本実施形態のデータ収集部２００は、１つ目の動作例として、所定の場合に、データ収集に関する動作を抑制する。例えば、データ収集部２００は、所定の場合に、データ収集部２００の動作を停止する。「所定の場合」とは、例えば、時刻が一日のなかで特定の時間帯に含まれる場合である。特定の時間帯は、例えば、ネットワークＮＷに対するアクセスの混み具合のピーク時間（１１：３０−１３：３０、２０：３０−００：３０）である。ただし、「所定の場合」は、上記例に限らず、例えば特定サーバに対してアクセスが集中している場合でもよい。また、「動作を抑制する」とは、動作を停止すること限らず、データを収集する時間間隔（フェッチ間隔）を所定間隔よりも大きく開けることなども含む。ここで、上述したＵＲＬ選出部１００は、データ収集部２００が動作を抑制している間にも、ＵＲＬを選出する動作を行って選出されたＵＲＬをＵＲＬ選出データ９１０に登録してもよい。

本実施形態のデータ収集部２００は、２つ目の動作例として、同一の外部サーバＳ１からデータを収集する動作が所定以上連続しないように、データの収集タイミングを分散させる。

図４は、上記２つ目の動作例を実現するためのデータ収集部２００の構成を示すブロック図である。図４に示すように、データ収集部２００は、例えば、ＩＰアドレス取得部２１０、テーブル生成部２２０、およびフェッチ部２３０を有する。

ＩＰアドレス取得部２１０は、ＵＲＬ選出データ９１０から取得されたＵＲＬに対応するＩＰアドレスを、ＤＮＳ（Domain Name System）サーバから取得する。詳しく述べると、ＩＰアドレス取得部２１０は、ＵＲＬ選出データ９１０から取得されたＵＲＬからホスト名を抽出し、抽出されたホスト名をＤＮＳサーバＳ２に送信する。例えば、ＵＲＬが“http://host1/news/1.html”の場合、ホスト名は“host1”である。

ＤＮＳサーバＳ２は、ドメインネームシステムに登録された情報を検索し、ＩＰアドレス取得部２１０から受信したホスト名に対応するＩＰアドレスを取得する。ＤＮＳサーバＳ２は、取得したＩＰアドレスをＩＰアドレス取得部２１０に送信する。ＩＰアドレス取得部２１０は、ＵＲＬ選出データ９１０から取得されたＵＲＬと、ＤＮＳサーバＳ２から受信したＩＰアドレスとを、テーブル生成部２２０に出力する。

テーブル生成部２２０は、ＵＲＬに含まれるホスト名と、ＩＰアドレス取得部２１０によって取得されたＩＰアドレスとを対応付けた対応テーブルＴ２を生成する。対応テーブルＴ２は、ＵＲＬに対応するＩＰアドレスを取得するために、フェッチ部２３０によって用いられるテーブルである。

図５は、本実施形態の対応テーブルＴ２の内容の一例を示す図である。図５に示すように、対応テーブルＴ２は、ホスト名とＩＰアドレスとが対応付けられたテーブルである。図５に示される例では、ホスト名“host1”および“host2”にはＩＰアドレス“192.0.2.1”が対応付けられており、ホスト名“host3”にはＩＰアドレス“192.0.2.2”が対応付けられている。

フェッチ部２３０は、データ収集に用いられるＵＲＬを参照することで、ウェブページの格納先にアクセスし、ページデータを収集する。本実施形態のフェッチ部２３０は、同一のＩＰアドレスに対応するＵＲＬの一群に含まれるＵＲＬを用いてデータを収集する動作が所定以上連続しないように、データの収集タイミングを分散させる。

詳しく述べると、例えば、フェッチ部２３０は、テーブル生成部２２０によって生成された対応テーブルＴ２を参照することで、ＵＲＬ選出データ９１０から取得された複数のＵＲＬを、ＵＲＬが対応するＩＰアドレス毎にグループ化する。そして、フェッチ部２３０は、同一グループに含まれるＵＲＬを用いてデータを収集する動作が所定以上連続しないように、その動作のタイミング（データの収集タイミング）を分散させる。「データ収集のタイミングを分散させる」とは、例えば、同一グループに含まれるＵＲＬを用いてデータを収集する時間間隔（フェッチ間隔）を、所定間隔よりも大きく開けることをいう。また、「データ収集のタイミングを分散させる」とは、同一グループに含まれるＵＲＬを用いたデータの収集が所定回数または所定時間以上継続した場合に、一定間隔、その同一グループに含まれるＵＲＬを用いたデータの収集を行わないことを意味してもよい。例えば、フェッチ部２３０は、同一のＩＰアドレスに対応するグループに含まれる複数のＵＲＬを用いてデータを収集する動作を行う間に、別のＩＰアドレスに対応するグループに含まれるＵＲＬを用いてデータを収集する動作を挟む。

なお、フェッチ部２３０は、上記処理に代えて、ＵＲＬの一部が互いに共通するＵＲＬの一群（例えばホスト名が共通の一群）に含まれるＵＲＬを用いてデータを収集する動作が所定以上連続しないように、その動作のタイミングを分散させてもよい。すなわち、ＵＲＬのグループ化は、ＩＰアドレス毎のグループ化に限らない。例えば、フェッチ部２３０は、ＵＲＬ選出データ９１０から取得された複数のＵＲＬを、ＵＲＬの一部が互いに共通するＵＲＬ毎（例えばホスト名が共通するＵＲＬ毎）にグループ化し、同一のグループに含まれるＵＲＬを用いてデータを収集する動作が所定以上連続しないように、その動作のタイミングを分散させてもよい。

データ収集部２００は、データ収集部２００によるデータの収集結果を、ＨＴＭＬデータ９２０、画像データ９３０、およびフェッチ結果データ９４０に登録する。例えば、データ収集部２００は、ＵＲＬ選出データ９１０から取得されたＵＲＬと、そのＵＲＬを用いて収集されたＨＴＭＬデータとを対応付けて、ＨＴＭＬデータ９２０に登録する。データ収集部２００は、ＵＲＬ選出データ９１０から取得されたＵＲＬと、そのＵＲＬを用いて収集された画像データとを対応付けて、画像データ９３０に登録する。データ収集部２００は、ＵＲＬ選出データ９１０から取得されたＵＲＬと、そのＵＲＬを用いて行われたデータ収集の成否（フェッチ結果）とを対応付けて、フェッチ結果データ９４０に登録する。データ収集の成否は、例えば、ＨＴＴＰステータスコードでもよいし、成否のみを示す情報でもよい。

次に、ＨＴＭＬ解析部３００について説明する。ＨＴＭＬ解析部３００は、データ収集部２００によってＨＴＭＬデータ９２０に登録されたＵＲＬおよびＨＴＭＬデータを、ＨＴＭＬデータ９２０から取得する。ＨＴＭＬ解析部３００は、ＨＴＭＬデータ９２０から取得されたＨＴＭＬデータを解析する。例えば、ＨＴＭＬ解析部３００は、ＨＴＭＬデータ９２０から取得されたＨＴＭＬデータから、ヘッダ部分を除くテキストデータを抽出し、抽出したテキストデータと対応するＵＲＬをテキストデータ９５０に登録する。

また、ＨＴＭＬ解析部３００は、ＨＴＭＬデータ９２０から取得されたＨＴＭＬデータのなかに、新しいＵＲＬが含まれていないかを検出する。「新しいＵＲＬ」とは、ＵＲＬ管理データベースＤＢ１のＵＲＬ管理テーブルＴ１に未登録のＵＲＬである。ＨＴＭＬ解析部３００は、ＵＲＬ管理テーブルＴ１を参照することで、ＨＴＭＬデータ９２０から取得されたＨＴＭＬデータに含まれるＵＲＬが新しいＵＲＬであるか否かを判定する。ＨＴＭＬ解析部３００は、ＨＴＭＬデータ９２０から取得されたＨＴＭＬデータのなかに新しいＵＲＬが含まれる場合、そのＵＲＬを抽出し、抽出したＵＲＬを新しく発見されたＵＲＬとしてフェッチ結果データ９４０に登録する。

さらに、ＨＴＭＬ解析部３００は、ＨＴＭＬデータ９２０から取得されたＵＲＬと、そのＵＲＬに対応するＨＴＭＬデータに含まれた「新しいＵＲＬ」とに基づき、リンク構造情報Ｔ３を生成する。「リンク構造情報」は、あるウェブページのＵＲＬ（リンク元）と、そのウェブページのなかに含まれるＵＲＬ（リンク先）との対応関係を示すテーブルである。

図６は、本実施形態のリンク構造情報Ｔ３の内容の一例を示す図である。図６に示すように、リンク構造情報Ｔ３は、リンク元のＵＲＬとリンク先のＵＲＬとが対応付けられたテーブルである。図に示される例では、ＵＲＬ“http://host1/news/1.htm”を用いて収集されたＨＴＭＬデータから新しくＵＲＬ“http://host11/news/1.htm”が抽出された場合の例である。この例では、リンク構造情報Ｔ３において、ＵＲＬ“http://host1/news/1.htm”と、ＵＲＬ“http://host11/news/1.htm”とが対応付けられている。ＨＴＭＬ解析部３００は、ＨＴＭＬデータ９２０から取得されたＨＴＭＬデータのフルデータ（ＲＡＷデータ）およびリンク構造情報Ｔ３を、対応するＵＲＬと対応付けて第１解析データ９６０に登録する。

次に、コンテンツ書き込み部４００について説明する。コンテンツ書き込み部４００は、データ収集部２００によって画像データ９３０に登録されたＵＲＬおよび画像データを、画像データ９３０から取得する。また、コンテンツ書き込み部４００は、ＨＴＭＬ解析部３００によってテキストデータ９５０に登録されたＵＲＬおよびテキストデータを、テキストデータ９５０から取得する。さらに、コンテンツ書き込み部４００は、後述する知識源解析部７００によって第２解析データ９７０に登録された解析結果を、第２解析データ９７０から取得する。そして、コンテンツ書き込み部４００は、これら取得した情報をコンテンツ保存用データベースＤＢ２に書き込む。これにより、データ収集部２００によって収集されたデータは、ＵＲＬと対応付けられた状態で、コンテンツ保存用データベースＤＢ２に蓄積される。

次に、ＵＲＬステータス更新部５００について説明する。ＵＲＬステータス更新部５００は、ＨＴＭＬ解析部３００によってフェッチ結果データ９４０に登録されたＵＲＬおよびデータ収集の成否を示す情報を、フェッチ結果データ９４０から取得する。また、ＵＲＬステータス更新部５００は、ＨＴＭＬ解析部３００によってフェッチ結果データ９４０に登録された「新しいＵＲＬ」を、フェッチ結果データ９４０から取得する。ＵＲＬステータス更新部５００は、フェッチ結果データ９４０から取得されたこれら情報に基づき、ＵＲＬ管理データベースＤＢ１のＵＲＬ管理テーブルＴ１を更新する。

図７は、ＵＲＬステータス更新部５００によって更新されたＵＲＬ管理テーブルＴ１の内容の一例を示す図である。図７に示すように、ＵＲＬステータス更新部５００は、フェッチ結果データ９４０から取得された情報に基づき、各ＵＲＬのステータスを更新する。例えば、ＵＲＬステータス更新部５００は、データ収集部２００によるデータの収集が成功したＵＲＬのステータスを「取得済」に更新する。また、ＵＲＬステータス更新部５００は、データ収集部２００によるデータの収集が失敗したＵＲＬのステータスを「取得失敗」に更新する。

また、ＵＲＬステータス更新部５００は、ＨＴＭＬ解析部３００により新しく抽出されたＵＲＬがある場合、新しく抽出されたＵＲＬをＵＲＬ管理テーブルＴ１に追加する。ＵＲＬステータス更新部５００は、新しく追加されたＵＲＬのステータスを「未取得」にする。図７に示す例では、新しく抽出されたＵＲＬ“http://host11/news/1.htm”がＵＲＬ管理テーブルＴ１に追加され、そのステータスが「未取得」に設定される。

次に、目的受付部６００について説明する。目的受付部６００は、データの収集に関するユーザの目的を受け付ける。例えば、目的受付部６００は、データの収集に関するユーザの目的が入力または選択されるインターフェースである。目的受付部６００は、例えば、データの収集に関するユーザの複数の目的を受け付け可能である。以下では、データの収集に関するユーザの目的として、種類が異なる２つの目的（第１目的、第２目的）が入力される場合を例に取り上げて説明する。

第１目的は、例えば、「特定のタグが含まれるウェブページを優先して収集したい」といった目的である。「特定のタグ」は、例えば、ＯＧＰ（Open Graph Protocol）タグのようなコンテンツの内容を示すテキストを含むタグである。ＯＧＰタグは、リンク先を示すＵＲＬ、リンク先のコンテンツの言語、リンク先のウェブサイトの名前、リンク先のコンテンツのタイトル、リンク先のコンテンツに関する画像データのＵＲＬ、リンク先のコンテンツの概要を示すテキストデータなどがひと纏まりになった情報である。ＯＧＰタグは、「コンテンツの内容を示す特定の情報」の一例であり、且つ、「ユーザの目的に対応する特定の情報」の一例である。

第２目的は、例えば、「コンテンツの内容を示す特定の語句が含まれるウェブページを優先して収集したい」といった目的である。「特定の語句」は、例えば、ウェブページのメインテキストに含まれる語句であって、コンテンツの内容を示すものとして予め登録された特徴語である。また、「特定の語句」は、ウェブページのメタタグに含まれる語句であって、コンテンツの内容を示すものとして予め登録された語句でもよい。これら特定の語句も「コンテンツの内容を示す特定の情報」の一例であり、且つ、「ユーザの目的に対応する特定の情報」の一例である。

ただし、第１目的および第２目的は、上記例に限定されず、適宜設定可能である。データの収集に関するユーザの目的は、１つでもよく、３つ以上でもよい。また、「特定のタグ」や「特定の語句」も上記例には限定されない。「特定のタグ」や「特定の語句」は、それぞれ１つに限らず、複数設定されてもよい。目的受付部６００は、目的受付部６００によって受け付けられたユーザの目的を知識源解析部７００に出力する。

次に、知識源解析部７００について説明する。知識源解析部７００は、ＨＴＭＬ解析部３００によって第１解析データ９６０に登録されたＵＲＬ、ＨＴＭＬデータおよびリンク構造情報Ｔ３を、第１解析データ９６０から取得する。また、知識源解析部７００は、目的受付部６００により受け付けられたユーザの目的を目的受付部６００から受け取る。知識源解析部７００は、目的受付部６００から受け取ったユーザの目的に基づき、第１解析データ９６０から取得されたデータを解析する。例えば、知識源解析部７００は、ユーザの目的が複数ある場合、ユーザの目的毎にデータを解析する。

知識源解析部７００は、解析されたデータの内容に基づき、そのデータに対応するＵＲＬまたはそのＵＲＬに基づいて得られる所属情報または関連リンク情報に、データ収集の優先度を示す指標を付与する。「所属情報」は、例えば、ＵＲＬの一部を構成して複数のＵＲＬの群を特定する情報（例えば、ドメインや、ドメインの下位に設定されるグループなどを特定する情報）である。また、「関連リンク情報」は、例えば、ＨＴＭＬ解析部３００によって新しく抽出されたＵＲＬである。知識源解析部７００は、「優先度付与部」の一例である。

なお以下では、説明の便宜上、所属情報の一例としてドメインに優先度が付与される例を取り上げて説明する。このため、以下の説明における「ドメイン」とは、「ＵＲＬの一部を構成して複数のＵＲＬの群を特定する情報」または「ＵＲＬが所属するグループを示す情報」などと読み替えられてもよい。

ここで、知識源解析部７００は、解析されたデータにユーザの目的に対応する特定の情報が含まれる場合に、付与する優先度を高くする。例えば、知識源解析部７００は、解析されたデータにコンテンツの内容を示す特定の情報が含まれる場合に、付与する優先度を高くする。

図８は、本実施形態の知識源解析部７００の構成を示すブロック図である。図８に示すように、知識源解析部７００は、例えば、タグ情報検出部７１０、語句検出部７２０、およびスコア付与部７３０を有する。

タグ情報検出部７１０は、第１解析データ９６０から取得されたＨＴＭＬデータのなかに、ユーザの第１目的として設定された特定のタグが含まれるか否かを検出する。例えば、タグ情報検出部７１０は、第１解析データ９６０から取得されたＨＴＭＬデータのなかにＯＧＰタグが含まれるか否かを検出する。例えば、タグ情報検出部７１０は、ＨＴＭＬデータのなかにＯＧＰタグが含まれることが検出された場合、ＯＧＰタグのなかから、リンク先を示すＵＲＬ、リンク先のコンテンツのタイトル、リンク先のコンテンツに関する画像データのＵＲＬ、リンク先のコンテンツの概要を示すテキストデータなどの情報を抽出する。タグ情報検出部７１０は、それら抽出した情報を互いに対応付け、知識源解析部７００による解析結果として第２解析データ９７０に登録する。また、タグ情報検出部７１０は、ＨＴＭＬデータのなかにＯＧＰタグが含まれることが検出された場合、ＯＧＰタグが含まれることを示す情報と、ＯＧＰタグを含むデータに対応するＵＲＬとを対応付けてスコア付与部７３０に出力する。

語句検出部７２０は、第１解析データ９６０から取得されたＨＴＭＬデータのなかに、ユーザの第２目的として設定された特定の語句が含まれるか否かを検出する。例えば、語句検出部７２０は、ＨＴＭＬデータに含まれるテキストデータに対して形態素解析を行い、予め登録された語句を検索することで、特定の語句が含まれるか否かを検出する。ただし、特定の語句を検出する方法は、上記例に限定されず、種々の方法を適宜採用可能である。語句検出部７２０は、検出対象の特定の語句が検出された場合、その語句とその語句を含むＨＴＭＬデータとを対応付け、知識源解析部７００による解析結果として第２解析データ９７０に登録する。また、語句検出部７２０は、検出対象の特定の語句が検出された場合、特定の語句が含まれることを示す情報と、その特定の語句を含むデータに対応するＵＲＬとを対応付けてスコア付与部７３０に出力する。

スコア付与部７３０は、タグ情報検出部７１０による検出結果と、語句検出部７２０による検出結果とに基づき、解析対象のデータに対応するＵＲＬ、またはＵＲＬに基づいて得られる所属情報または関連リンク情報に、データ収集の優先度を示すスコアを付与する。

本実施形態では、スコア付与部７３０は、タグ情報検出部７１０の検出結果に基づき、ＵＲＬ、またはＵＲＬに基づいて得られる所属情報または関連リンク情報に、ユーザの第１目的に対応する優先度として第１スコアを付与する。スコア付与部７３０は、タグ情報検出部７１０によってデータのなかに特定のタグが含まれることが検出された場合、データ収集の優先度が高くなるように第１スコアを高くする。

また、本実施形態では、スコア付与部７３０は、語句検出部７２０の検出結果に基づき、ＵＲＬ、またはＵＲＬに基づいて得られる所属情報または関連リンク情報に、ユーザの第２目的に対応する優先度として第２スコアを付与する。スコア付与部７３０は、語句検出部７２０によってデータのなかに特定の語句が含まれることが検出された場合、データ収集の優先度が高くなるように第２スコアを高くする。

図９は、スコア付与部７３０により生成される第１対応テーブルＴ４を示す図である。図９に示すように、第１対応テーブルＴ４は、データの収集に用いられたＵＲＬと、そのＵＲＬに対して付与された第１スコアおよび第２スコアとを対応付けたテーブルである。

また、スコア付与部７３０は、ＨＴＭＬ解析部３００によって新しく抽出されたＵＲＬ（関連リンク情報）に対しても第１スコアおよび第２スコアを付与する。本実施形態では、スコア付与部７３０は、第１解析データ９６０から取得されたリンク構造情報Ｔ３に基づき、新しく抽出されたＵＲＬ“http://host11/news/1.htm”に対して第１スコアおよび第２スコアを付与する。新しく抽出されたＵＲＬ“http://host11/news/1.htm”に付与される第１スコアおよび第２スコアは、例えばそのＵＲＬのリンク元であるＵＲＬ“http://host1/news/1.htm”に対して付与される第１スコアおよび第２スコアと同じに設定される。ただし、新しく抽出されたＵＲＬに付与されるスコアは、リンク元のＵＲＬに付与されるスコアと異なってもよい。スコア付与部７３０は、生成した第１対応テーブルＴ４を、スコアデータ９８０に登録する。

図１０は、スコア付与部７３０によって生成される第２対応テーブルＴ５を示す図である。図１０に示すように、第２対応テーブルＴ５は、ドメインと、そのドメインに対して付与された第１スコアおよび第２スコアとを対応付けたテーブルである。本実施形態では、例えば、スコア付与部７３０は、各ＵＲＬに対して付与された第１スコアおよび第２スコアをドメイン毎に平均することで、ドメイン毎の第１スコアおよび第２スコアを導出して付与する。スコア付与部７３０は、生成した第２対応テーブルＴ５を、スコアデータ９８０に登録する。

次に、スコア更新部８００について説明する。スコア更新部８００は、知識源解析部７００によって付与されたスコアに基づき、ＵＲＬ管理データベースＤＢ１のＵＲＬ管理テーブルＴ１を更新する。例えば、スコア更新部８００は、スコア付与部７３０によってスコアデータ９８０に登録された第１対応テーブルＴ４および第２対応テーブルＴ５を、スコアデータ９８０からを取得する。スコア更新部８００は、第１対応テーブルＴ４および第２対応テーブルＴ５に基づき、ＵＲＬ管理テーブルＴ１を更新する。

図１１は、スコア更新部８００によって更新されたＵＲＬ管理テーブルＴ１の内容の一例を示す図である。図１１に示すように、スコア更新部８００は、第１対応テーブルＴ４に基づき、各ＵＲＬに対応する第１スコアおよび第２スコアを更新する。ＵＲＬ管理テーブルＴ１は、ＵＲＬと、そのＵＲＬに対して更新された第１スコアおよび第２スコアを対応付けて管理する。

また、ＵＲＬ管理データベースＤＢ１は、ドメインと、そのドメインに対して付与された第１スコアおよび第２スコアを管理するドメイン管理テーブル（図１０に示す第２対応テーブルＴ５と略同じもの）を記憶してもよい。この場合、スコア更新部８００は、第２対応テーブルＴ５に基づき、ドメイン管理テーブルにおいて各ドメインに対応する第１スコアおよび第２スコアを更新する。

最後に、更新されたＵＲＬ管理テーブルＴ１に基づくＵＲＬ選出部１００の動作について説明する。ＵＲＬ選出部１００は、ＵＲＬ管理テーブルＴ１に格納された各ＵＲＬのステータスに基づくことで、取得済みのＵＲＬに比べて、未取得のＵＲＬを優先して、データ収集に用いるＵＲＬとして選出する。また、ＵＲＬ選出部１００は、ＵＲＬ管理テーブルＴ１を参照することで、データ収集の優先度を考慮して、複数のＵＲＬのなかから優先してデータを収集する１以上のＵＲＬを選出する。例えば、ＵＲＬ選出部１００は、有用な知識源を含む可能性が高いウェブページのＵＲＬを優先して選出する。

本実施形態では、ＵＲＬ選出部１００は、例えばＵＲＬ管理テーブルＴ１においてステータスが「未取得」のＵＲＬのなかで、ＵＲＬ毎に付与されたスコア（例えば第１スコアおよび第２スコアの一方または両方）に基づいて、複数のＵＲＬのなかから優先してデータを収集するＵＲＬを選出する。例えば、ＵＲＬ選出部１００は、ＵＲＬ毎に付与された第１スコアおよび第２スコアの組み合わせに基づいて、複数のＵＲＬのなかから優先してデータを収集するＵＲＬを選出する。例えば、ＵＲＬ選出部１００は、複数のＵＲＬのなかから、付与されたスコアが最も高いＵＲＬから順に選出する。なおこれに代えて、ＵＲＬ選出部１００は、複数のＵＲＬのなかで、付与されたスコアが一定の閾値よりも高いＵＲＬを順に選出してもよい。

また、ＵＲＬ選出部１００は、例えばＵＲＬ管理テーブルＴ１においてステータスが「未取得」のＵＲＬについて、そのＵＲＬが属すドメイン毎に付与されたスコア（例えば第１スコアおよび第２スコアの一方または両方）に基づいて、複数のＵＲＬのなかから優先してデータを収集するＵＲＬを選出してもよい。例えば、ＵＲＬ選出部１００は、そのＵＲＬが属するドメイン毎に付与された第１スコアおよび第２スコアの組み合わせに基づいて、複数のＵＲＬのなかから優先してデータを収集するＵＲＬを選出してもよい。例えば、ＵＲＬ選出部１００は、付与されたスコアが最も高いドメインに属するＵＲＬを優先的に選出する。なおこれに代えて、ＵＲＬ選出部１００は、付与されたスコアが一定の閾値よりも高いドメインに属するＵＲＬを順に選出してもよい。

図１２は、本実施形態のクロール処理を示すフローチャートである。本フローチャートによる処理は、クロールサーバ１０によって実行される。なお、本フローチャートは、１つのＵＲＬに関するクロール処理の流れを示す。

まず、ＵＲＬ選出部１００は、ＵＲＬ管理テーブルＴ１に格納された複数のＵＲＬのなかから、データを収集するのに用いるＵＲＬを選出する（Ｓ１０）。データ収集部２００は、ＵＲＬ選出部１００により選出されたＵＲＬを用いてウェブページの格納先にアクセスし、ページデータを収集する（Ｓ１１）。次に、ＨＴＭＬ解析部３００は、データ収集部２００により収集されたデータを解析する（Ｓ１２）。これにより、データに含まれるリンク構造情報Ｔ３などが得られる。

ＵＲＬステータス更新部５００は、各ＵＲＬに対するデータ収集の成否や、ＨＴＭＬ解析部３００により得られたリンク構造情報Ｔ３などに基づき、ＵＲＬ管理テーブルＴ１を更新する（Ｓ１３）。知識源解析部７００は、ＨＴＭＬ解析部３００から送られたＨＴＭＬデータを解析し、ＵＲＬなどに対してユーザの目的毎に応じたスコアを付与する（Ｓ１４）。スコア更新部８００は、知識源解析部７００により付与されたスコアに基づき、ＵＲＬ管理テーブルＴ１を更新する（Ｓ１５）。コンテンツ書き込み部４００は、収集されたデータをコンテンツ保存用データベースＤＢ２に書き込む（Ｓ１６）。なお、Ｓ１３、Ｓ１４、Ｓ１５、およびＳ１６の処理は、上記順序とは異なる順序で行われてもよく、互いに同じタイミングで行われてもよい。

図１３は、本実施形態のクロールサーバ１０の作用を説明するための図である。図１３中の（ａ）は、比較例として、前処理、データ収集、後処理が順に実行されるバッチ処理によりクロールが行われる例を示す。図１３中の（ａ）に示すように、このようなクローラでは、前処理や後処理が実行されている間のリソースの利用効率が低く、データ収集の効率が高くない場合がある。

一方で、図１３中の（ｂ）は、本実施形態のクロールサーバ１０によりクロールが行われる例を示す。本実施形態のクロールサーバ１０によれば、リアルタイム処理による常時クロールが実現される。これにより、ネットワーク帯域を効率的に使用することができる。また本実施形態では、データ収集部２００は、収集対象となるＵＲＬがＵＲＬ選出データ９１０に新しく登録されると、そのＵＲＬを用いたクロールをすぐに行うことができる。これにより、重要度が高いＵＲＬが新しく発見された場合、そのＵＲＬを用いてデータを迅速に収集することができる。

以上のような構成のクロールサーバ１０によれば、データ収集の効率向上を図ることができる。すなわち、本実施形態のクロールサーバ１０は、ＵＲＬ選出部１００の動作とは非同期に、外部サーバＳ１からデータを収集するデータ収集部２００を備える。このような構成によれば、ＵＲＬ選出部１００がＵＲＬを選出する動作と並行してデータ収集部２００がデータを収集することができる。このため、リソースを効率的に利用することができ、データ収集の効率向上を図ることができる。

ここで、上流のコンポーネントＣの処理速度が下流のコンポーネントＣの処理速度を上回る場合、下流のコンポーネントＣでデータがあふれ、一部の処理に不具合が生じることがある。例えば、データ収集の処理は、ＵＲＬ選出の処理などに比べて負荷が大きい。このため、ＵＲＬ選出の処理とデータ収集の処理とが単に並列に実行されると、データ収集の処理に不具合が生じる可能性がある。

そこで、本実施形態のクロールサーバ１０は、ＵＲＬ選出部１００により選出されたＵＲＬが登録されるＵＲＬ選出データ９１０を備える。そして、データ収集部２００は、ＵＲＬ選出データ９１０に登録されたＵＲＬを用いて、ＵＲＬ選出部１００の動作とは非同期に外部サーバＳ１からデータを収集する。このような構成によれば、ＵＲＬ選出部１００から送られたＵＲＬがデータ収集部２００であふれることを抑制することができ、データ収集の処理に不具合が生じる可能性が低下させることができる。これにより、不具合発生を抑制しつつ、データ収集の効率向上を図ることができるクロールサーバ１０を提供することができる。

本実施形態では、データ収集部２００は、時刻が一日のなかで特定の時間帯に含まれる場合に、動作を抑制する。このような構成によれば、ネットワーク帯域に大きな負荷を与えることを避けることができる。

本実施形態では、ＵＲＬ選出部１００は、データ収集部２００が動作を抑制している間にも、ＵＲＬを選出する動作を行って選出されたＵＲＬをＵＲＬ選出データ９１０に登録する。このような構成によれば、所定の場合にデータ収集部２００の動作が抑制される場合であっても、リソースの利用効率を高めることができる。これにより、データ収集のさらなる効率向上を図ることができる。

本実施形態では、データ収集部２００は、同一のＩＰアドレスに対応する複数のＵＲＬを用いてデータを収集する動作が所定以上連続しないようにデータの収集タイミングを分散させる。また、データ収集部２００は、ＵＲＬの一部が互いに共通する複数のＵＲＬを用いてデータを収集する動作が所定以上連続しないようにデータの収集タイミングを分散させる。これらのような構成によれば、特定のサーバに集中して大きな負荷を与えることを避けることができる。

本実施形態では、知識源解析部７００は、データ収集部２００により収集されたデータの内容に基づき、ＵＲＬまたはＵＲＬに基づいて得られる情報に、データ収集の優先度を付与する。そして、ＵＲＬ選出部１００は、知識源解析部７００により付与された優先度に基づき、複数のＵＲＬのなかからデータ収集に優先して用いるＵＲＬを選出する。このような構成によれば、データ収集の重要度が高いデータをより迅速に収集することができる。これにより、データ収集のさらなる効率向上を図ることができる。

本実施形態では、前記ＵＲＬに基づいて得られる情報は、ＵＲＬの一部を構成して複数のＵＲＬのグループを特定する情報である。すなわち、本実施形態では、ドメインやドメインの下位に設定されるカテゴリに対して、データ収集の優先度を付与することができる。このような構成によれば、データ収集の観点で重要なウェブページが発見された場合、そのウェブページが属するドメインやドメインの下位に設定されるカテゴリに対して高い優先度を付与し、そのドメインなどに属してデータが未取得のＵＲＬを次のデータ収集に用いるＵＲＬとして優先的に選出することができる。これにより、データ収集のさらなる効率向上を図ることができる。

本実施形態では、前記ＵＲＬに基づいて得られる情報は、データ収集部２００により収集されたデータから新しく抽出されたＵＲＬである。すなわち、本実施形態では、新しく抽出されたＵＲＬに対して、データ収集の優先度を付与することができる。このような構成によれば、データ収集の観点で重要なウェブページが発見された場合、そのウェブページに含まれるＵＲＬに対して高い優先度を付与し、その新しく抽出されたＵＲＬを次のデータ収集に用いるＵＲＬとして優先的に選出することができる。これにより、データ収集のさらなる効率向上を図ることができる。

本実施形態では、知識源解析部７００は、データ収集部２００により収集されたデータのなかに目的受付部６００により受け付けられたユーザの目的に対応する特定の情報が含まれる場合に、優先度を高くする。このような構成によれば、ユーザの目的に応じたデータの収集をより効率的に行うことができる。

本実施形態では、知識源解析部７００は、データ収集部２００により収集されたデータのなかにデータの内容を示す特定の情報が含まれる場合に、優先度を高くする。このような構成によれば、例えば知識源にフォーカスしたデータの収集をより効率的に行うことができる。

本実施形態では、前記特定の情報は、ＯＧＰ（Open Graph Protocol）タグである。このような構成によれば、コンテンツのタイトル、コンテンツに関する画像データ、コンテンツの概要を示すテキストデータなどの情報を１纏まりとして抽出することができる。これにより、知識源にフォーカスしたデータの収集をさらに効率的に行うことができる。

＜第２の実施形態＞
次に、第２の実施形態について説明する。本実施形態は、ドメインやウェブページの性質に合わせたデータの再収集（再フェッチ）が行われる点で、第１の実施形態とは異なる。「データの再収集」とは、過去にすでに一度データが取得されたウェブページから、再びデータを収集することを意味する。なお、以下に説明する以外の構成は、第１の実施形態の構成と同様である。

図１４は、本実施形態の知識源解析部７００Ａの構成を示すブロック図である。図１４に示すように、本実施形態の知識源解析部７００Ａは、更新頻度推定部７４０を有する。更新頻度推定部７４０は、第１解析データ９６０から取得されるＨＴＭＬデータの内容に基づき、そのＨＴＭＬデータが存在したウェブページの更新頻度を推定する。例えば、更新頻度推定部７４０は、ウェブページの更新頻度に関する特定の語句がＨＴＭＬデータのなかに含まれないか検出する。

ここで、例えば、ウェブページは、ドメインやページの性質によって、更新頻度が異なる。例えば、ニュースサイトは頻繁に更新されるが、古い事柄に関する解説サイトはほとんど更新されない。また、ニュースサイトのなかでも、トップページは頻繁に更新されるが、個々の記事ページは基本的に更新されない。

そこで、更新頻度推定部７４０は、例えば、ＨＴＭＬデータのなかに、ニュースサイトであることを示す特定の語句（例えば“article”）や、トップページであることを示す特定の語句（例えば、“top page”）などが含まれていないか検出する。そして、更新頻度推定部７４０は、これらの特定の語句がＨＴＭＬデータに含まれる場合に、そのウェブページの更新頻度が高いものと推定する。なお、ウェブページの更新頻度を推定する方法は、上記例に限られない。例えば、同じウェブページから所定の周期で再収集したＨＴＭＬデータを、ハッシュ関数を用いて比較する方法や、その他の解析手法を用いる方法で更新頻度が推定されてもよい。

更新頻度推定部７４０は、ＵＲＬ管理データベースＤＢ１のＵＲＬ管理テーブルＴ１において、各ＵＲＬに対して推定された更新頻度に関する情報を追加する。また本実施形態では、ＵＲＬ管理テーブルＴ１は、各ＵＲＬを用いて最後にデータが収集された日時を、各ＵＲＬと対応付けて記憶する。例えば、各ＵＲＬを用いて最後にデータが収集された日時は、ＵＲＬステータス更新部５００によって登録される。

そして、ＵＲＬ選出部１００は、ＵＲＬ管理テーブルＴ１を参照することで、更新頻度推定部７４０により推定された更新頻度に基づき、データを再収集するＵＲＬを選出する。例えば、ＵＲＬ選出部１００は、更新頻度が高いウェブページであるほど、データを再収集する時間間隔を小さくする。

このような構成によれば、ドメインやウェブページの性質に合わせたデータの再収集を行うことができる。これにより、更新頻度が高いウェブページから、より多くのデータ、および新しいデータを収集することができる。これにより、データ収集のさらなる効率向上を図ることができる。

＜第３の実施形態＞
次に、第３の実施形態について説明する。本実施形態は、ドメイン毎やドメインの下位に設定されるグループ毎に、クロールするＵＲＬ数が割り当てられる点で、第１の実施形態とは異なる。なお、以下に説明する以外の構成は、第１の実施形態の構成と同様である。

図１５は、本実施形態のＵＲＬ選出部１００によるＵＲＬの選出動作を説明するための図である。本実施形態のＵＲＬ選出部１００は、選出するＵＲＬの総数をドメイン毎に割り当て、各ドメインに属するＵＲＬを各ドメインに割り当てられた数だけ選出する。また、本実施形態のＵＲＬ選出部１００は、各ドメインに割り当てられたＵＲＬの数を、さらにドメインの下位に設定されるグループ毎に割り当て、各グループに属するＵＲＬを各グループに割り当てられた数だけ選出する。

詳しく述べると、本実施形態のＵＲＬ選出部１００は、ドメイン毎のスコア比率に応じてドメイン毎に割り振るＵＲＬの数を決定するための対応テーブルＴ６を有する。「スコア比率」とは、全てのドメインのスコアを合計した値に対する各ドメインのスコアの比率を意味する。例えば、全てのドメインのスコアを合計した値が１３０であり、ドメイン“host1”のスコアが１００の場合、ドメイン“host1”のスコア比率は、０．７７になる。

図１６は、本実施形態のスコア比率に応じてＵＲＬ数を決定するための対応テーブルＴ６の内容の一例を示す図である。図１６に示すように、対応テーブルＴ６において、各スコア比率に応じてドメイン毎に割り当てるＵＲＬ数の配分比率は、予め設定されている。本実施形態では、一例として、ドメイン“host1”のスコアが１００であり、ドメイン“host99”のスコアが５であるとする。この場合、ＵＲＬ選出部１００は、対応テーブルＴ６に格納された配分比率に基づき、ドメイン“host1”から選出するＵＲＬ数を５０とし、ドメイン“host99”から選出するＵＲＬ数を１とする。

同様に、本実施形態のＵＲＬ選出部１００は、ドメインの下位に設定されるグループ（図１５中では「サービス」と表記する）毎のスコア比率に応じてグループ毎に割り振るＵＲＬの数を決定する。本実施形態では、一例として、グループ“host1 news”のスコアが８０であり、グループ“host1 shop”のスコアが２０であるとする。この場合、ＵＲＬ選出部１００は、対応テーブルＴ６と同様に設定された配分比率のテーブルに基づき、ドメイン“host1”に割り当てられたＵＲＬの数である５０を、グループ“host1 news”から選出するＵＲＬの数を４０とし、グループ“host1 shop”から選出するＵＲＬの数を１０として配分する。

そして、本実施形態のＵＲＬ選出部１００は、各グループに割り当てられたＵＲＬの数のなかで、各ＵＲＬのスコアに応じてデータを優先して収集するＵＲＬを選出する。

ここで、ドメインや、ドメインの下位に設定されるグループのカテゴリ（サービスの種類）により、クロールする価値が異なる場合がある。例えば、ポータルサイトのニュースサービスやショッピングサービスは、より積極的にクロールする価値がある。

そこで、本実施形態では、ドメイン毎やドメインの下位に設定されるグループ毎に、クロールするＵＲＬの数が割り当てられる。このような構成によれば、価値の高いドメイン（知識源が多く含まれるドメイン）からのデータ収集をより優先して行うことができる。

以上、いくつかの実施形態について説明した。ただし、実施形態の構成は、上記例に限定されない。例えば、各コンポーネントＣは、同じ装置（同じハードウェア）に存在してもよく、別の装置（別のハードウェア）に存在してもよい。ＩＰアドレス取得部２１０およびテーブル生成部２２０は、データ収集部２００に代えて、ＵＲＬ選出部１００に設けられてもよい。この場合、ＵＲＬ選出部１００は、複数のＵＲＬをＵＲＬが対応するＩＰアドレス毎にグループ化し、同一ＩＰアドレスに対応するＵＲＬが所定以上集中しないようにＵＲＬを選出してもよい。別の観点で見ると、複数のＵＲＬをＵＲＬが対応するＩＰアドレス毎（または、ＵＲＬの一部が互いに共通するＵＲＬ毎）にグループ化する処理は、データ収集部２００の代わりに、ＵＲＬ選出部１００によって事前に行われてもよい。

以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

１０…クロールサーバ（データ収集システム）、１００…ＵＲＬ選出部（選出部）、２００…データ収集部（収集部）、６００…目的受付部（受付部）、７００，７００Ａ…知識源解析部（優先度付与部）、７４０…更新頻度推定部（推定部）、９００…記憶部

Claims (15)

1. ネットワークを介してアクセス可能な装置に格納されたデータを参照するための参照情報を選出する選出部と、
   前記選出部により選出された前記参照情報が記憶される記憶部と、
   前記記憶部に記憶された前記参照情報を用いて、前記選出部の動作とは非同期に、前記ネットワークを介してアクセス可能な装置からデータを収集する収集部と、
   を備えるデータ収集システム。
2. 前記選出部と前記収集部の動作は、並行して実行される
   請求項１記載のデータ収集システム。
3. 前記収集部は、所定の場合に動作を抑制し、
   前記選出部は、前記収集部が動作を抑制している間にも、前記参照情報を選出する動作を行って選出された前記参照情報を前記記憶部に記憶させる
   請求項１または２に記載のデータ収集システム。
4. 前記所定の場合は、時刻が一日のなかで特定の時間帯に含まれる場合である
   請求項３記載のデータ収集システム。
5. 前記収集部は、同一のＩＰアドレスに対応する複数の前記参照情報を用いたデータの収集タイミングを分散させる
   請求項１から４のうちいずれか一項に記載のデータ収集システム。
6. 前記収集部は、前記参照情報の一部が互いに共通する複数の前記参照情報を用いたデータの収集タイミングを分散させる
   請求項１から４のうちいずれか一項に記載のデータ収集システム。
7. 前記収集部により収集されたデータの内容に基づき、前記データに対応する前記参照情報または前記参照情報に基づいて得られる情報に、データ収集の優先度を付与する優先度付与部を更に備え、
   前記選出部は、前記優先度付与部により付与された前記優先度に基づき、複数の参照情報のなかからデータ収集に優先して用いる参照情報を選出する
   請求項１から６のうちいずれか一項に記載のデータ収集システム。
8. 前記参照情報に基づいて得られる情報は、前記参照情報の一部を構成して複数の参照情報の群を特定する情報である
   請求項７記載のデータ収集システム。
9. 前記参照情報に基づいて得られる情報は、前記収集部により収集されたデータから新しく抽出された参照情報である
   請求項７記載のデータ収集システム。
10. データ収集に関するユーザの目的を受け付ける受付部を更に備え、
    前記優先度付与部は、前記収集部により収集されたデータに前記受付部により受け付けられたユーザの目的に対応する特定の情報が含まれる場合に、前記優先度を高くする
    請求項７から９のうちいずれか一項に記載のデータ収集システム。
11. 前記優先度付与部は、前記収集部により収集されたデータにコンテンツの内容を示す特定の情報が含まれる場合に、前記優先度を高くする
    請求項７から１０のうちいずれか一項に記載のデータ収集システム。
12. 前記特定の情報は、ＯＧＰ（Open Graph Protocol）タグである
    請求項１１記載のデータ収集システム。
13. 前記収集部により収集されるデータが存在したウェブページの更新頻度を推定する推定部を更に備え、
    前記選出部は、前記推定部により推定された前記更新頻度に基づき、データを再収集する参照情報を選出する
    請求項１から１２のうちいずれか一項に記載のデータ収集システム。
14. コンピュータが、
    ネットワークを介してアクセス可能な装置に格納されたデータを参照するための参照情報を選出し、
    前記選出された参照情報を記憶部に記憶し、
    前記記憶部に記憶された前記参照情報を用いて、前記参照情報を選出する動作とは非同期に、前記ネットワークを介してアクセス可能な装置からデータを収集する、
    データ収集方法。
15. コンピュータに、
    ネットワークを介してアクセス可能な装置に格納されたデータを参照するための参照情報を選出させる処理と、
    前記選出された参照情報を記憶部に記憶させる処理と、
    前記記憶部に記憶された前記参照情報を用いて、前記参照情報を選出させる処理とは非同期に、前記ネットワークを介してアクセス可能な装置からデータを収集させる処理と、
    を実行させるプログラム。

Images