以下、本発明の実施形態を説明するが、本発明の実施形態は、以下の実施形態に限定されるものではない。なお、以下の実施形態では、文書を対象とした情報検索を実行する文書検索システムを一例として説明する。
図1は、第1の実施形態による文書検索システム100を示す概略図である。図1に示す文書検索システム100は、検索要求を送信するクライアント・コンピュータ(以下、単にクライアントとして参照する。)160a,bと、クライアント160から受信した上記検索要求を処理するWebアプリケーション・サーバ(以下、Webサーバとして参照する。)120と、文書検索のためのインデックスを記憶するデータベース110aを管理し、文書検索エンジンとして機能するデータベース・サーバ(以下、DBサーバとして参照する。)110とを含んで構成されている。上記DBサーバ110、Webサーバ120およびクライアント160は、イーサネット(登録商標)およびTCP/IPプロトコルによるローカル・エリア・ネットワーク(以下、LANとして参照する。)などのネットワーク170を介して、相互に接続されている。上記ネットワーク170の構成は、特に限定されるものではなく、クライアント160とWebサーバ120との間には、インターネットなどの公衆ネットワークを含んでいてもよい。
本実施形態の文書検索システム100は、文書検索に加え、新たに要求された検索条件に関連する過去の検索条件(以下、関連検索条件として参照する。)を抽出して、クライアント160に提示するよう構成されており、上記DBサーバ110は、関連検索条件を抽出するために、さらに、システムに対し過去に要求された検索の履歴をデータベース110a上に蓄積している。クライアント160は、Webサーバ120に対し、文書検索とともに上記関連検索条件の抽出を要求する。Webサーバ120は、クライアント160から受信した検索要求に応答して、文書検索エンジンとしてのDBサーバ110に照会するとともに、上記関連検索条件の抽出の要求に応答して、DBサーバ110が蓄積する検索履歴を利用した関連検索条件の抽出処理を実行し、検索結果および抽出結果をクライアント160へ返信する。
上記DBサーバ110は、より具体的には、DB2(登録商標)、Oracle(登録商標)、MySQL(登録商標)、PostgreSQL(登録商標)などのデータベース管理システム(Database Management System)を実装しており、関係データベース、オブジェクト関係データベースまたはオブジェクト・データベースなどとして構成されるデータベース110aを管理している。DBサーバ110は、検索履歴、文書検索のためのインデックスの他、後述する関連検索条件の抽出処理に用いる状態遷移グラフを構成する構成データを格納している。
クライアント160は、ブラウザ・ソフトウェアを実装しており、Webサーバ120から送信されるHTML、XHTML、XMLなどの構造化文書を使用して、文書検索および関連検索条件の抽出の指示、および結果表示を行うためのグラフィカル・ユーザ・インタフェース(以下、GUIとして参照する。)を提供している。本実施形態で使用することができるブラウザ・ソフトウェアとしては、これまで知られたいかなるものでも使用することができ、例えば、Internet Explorer(登録商標)、Netscape Navigator(登録商標)、Firefox(登録商標)、Mosaic(登録商標)、Opera(登録商標)などの適切なブラウザ・ソフトウェアを挙げることができる。
Webサーバ120は、IIS(Internet Information Service:登録商標)、APache(登録商標)などのWebサーバ・ソフトウェアおよび、PHP、Java(登録商標)Servlet、JSPなどの適切なWebアプリケーションを実装しており、HTTP(HyperText Transfer Protocol)に従ったトランザクションを処理している。本実施形態のWebサーバ120は、クライアント160から送信される検索条件を受信し、検索結果、および該検索条件に関連する関連検索条件の抽出結果をクライアント160上に表示させるための応答データを返信する。また、Webサーバ120は、JDBC、ODBC(Open Database Connectivity)などのAPI(Application Programming Interface)を含んで構成され、データベース110aに接続して、検索履歴の取得、状態遷移グラフの構成テーブルの取得および格納、およびクライアントから要求された検索の照会を行っている。
以下、第1の実施形態の文書検索システム100で用いられるWebサーバ120の構成について、詳細を説明する。図2は、第1の実施形態によるWebサーバ120のハードウェア構成を示す図である。Webサーバ120は、マイクロプロセッサ・ユニット(MPU)12と、BIOS(Basic Input Output System)を格納する不揮発性メモリ14と、MPU12によるプログラム処理を可能とする実行記憶空間を提供するRAMなどのメモリ16とを含んで構成されている。起動時にMPU12は、不揮発性メモリ14からBIOSを読み出して、システム診断を行なうとともに入出力装置26の管理を行っている。
MPU12は、内部バス22を介して記憶制御用インタフェース18に接続され、ハードディスク20が、MPU12からの入出力要求に応答してデータの書込または読み出しを実行する。記憶制御用インタフェース18としては、IDE(Integrated Device Electronics)、ATA(AT Attachment)、シリアルATA、UltraATAなどの規格により、ハードディスク20の入出力を管理するインタフェースを使用することもできる。MPU12は、内部バス22を介してUSB、IEEE1164などのシリアルまたはパラレル・インタフェース24を制御して、キーボード、マウス、プリンタなどの入出力装置26と通信して、ユーザからの入力を受け取る。
Webサーバ120は、さらにVRAM28とグラフィック・チップ30とを含んでおり、MPU12からの指令に応答してビデオ信号を処理し、ディスプレイ装置32へと表示させている。また、MPU12は、内部バス22を介してネットワークI/F(NIC;Network Interface Card)34と通信し、Webサーバ120を、ネットワーク170を通して、DBサーバ110およびクライアント160と通信させている。
Webサーバ120は、不揮発性メモリ14やハードディスク20、その他、NV−RAM(図示せず)やSDカード(図示せず)などの記憶装置に格納されたプログラム(図示せず)を読み出し、メモリ16のメモリ領域に展開することにより、適切なオペレーティング・システム(OS)のもとで、後述する各機能手段および各処理を実現している。上記OSとしては、Windows(登録商標)、UNIX(登録商標)またはAIXまたはLINUX(登録商標)など、如何なるアーキテクチャを有するOSを採用することができる。なお、本実施形態のDBサーバ110およびクライアント160も、図1に示すハードウェア構成と同様の構成とすることができる。
以下、文書検索システム100の機能構成について説明する。図3は、第1の実施形態による文書検索システム100の機能ブロックを示し、図3には、DBサーバ110の機能ブロック、Webサーバ120の機能ブロック、およびクライアント160の機能ブロックが示されている。
図3に示すクライアント160は、検索条件の入力を受け付ける検索条件入力部164を含んで構成されている。クライアント160とWebサーバ120との間のメッセージ交換は、クッキーなどによってセッション管理されている。検索条件が入力され、GUIを介した検索指示を受けると、検索条件入力部164は、入力された検索条件を含む検索要求をWebサーバ120へ送信する。
ここで、図4を参照して、検索要求のために用いられるGUI画面について説明する。図4は、クライアントのディスプレイ上に表示されるGUI画面を示す。図4(A)に示すGUI画面300は、第1の実施形態の文書検索システム100において検索要求を発行するためのGUIを提供し、検索条件を入力するためのテキスト・ボックス302と、検索要求を指示するための検索ボタン304とを含んで構成される。検索者は、GUI画面300を用いて、検索条件の入力および検索要求を指示することができる。
再び図3を参照すると、DBサーバ110は、検索履歴を格納する検索履歴格納部114と、文書検索のための全文テキスト検索インデックスを格納するインデックス・データベース116とを含んで構成される。Webサーバ120は、検索履歴の記録処理を実行する検索履歴記録部122と、要求された検索条件による照会処理を行う照会処理部144と、照会結果を得て要求に対する検索結果を含む応答データを生成する検索結果応答部146とを含んで構成される。
上記照会処理部144は、クライアント160から受信した検索条件を、SQLなどのデータベース言語に変換してインデックス・データベース116に照会し、検索結果応答部146は、照会結果として検索条件に該当する文書(以下、検索文書として参照する。)の書誌情報およびハイパーリンク情報から構成される文書リストを取得する。照会結果を取得した検索結果応答部146は、検索要求に対する検索結果の応答データを生成して、クライアント160へ返信する。また、検索結果応答部146は、後述する状態遷移グラフのノード間の重み付けを計算するために、検索文書のリストを検索履歴記録部122へ報告することができる。報告を受けた検索履歴記録部122は、検索条件入力部164から送信された検索要求に含まれる検索条件と、報告された該検索条件による検索結果に含まれる検索文書とを相互に関連付けて検索履歴格納部114へ記録する。
クライアント160は、さらに、受信した応答データに従って画面表示する結果表示部166と、検索結果中の検索文書へのハイパーリンク情報に従って文書へアクセスし表示するための文書表示部168とを含んで構成される。上記結果表示部166は、GUIを介して検索者からの検索文書の参照の指示を受けて、文書表示部168を呼び出す。呼び出された文書表示部168は、指定された文書へアクセスするとともに、当該検索文書が参照された旨の報告をWebサーバ120へ送信する。報告を受けて検索履歴記録部122は、当該検索条件に対し、さらに参照済みの検索文書(以下、参照文書として参照する。)をさらに関連付けて記録する。
つまり、参照された検索文書は、単に検索にヒットしただけではなく、検索者により有為な文書であるとして参照された関連性の高い文書(以下、関連文書として参照する。)であるとして履歴中に記録されることとなる。本実施形態では、参照された参照文書を関連文書として登録するものとして説明するが、他の実施形態では、適合性フィードバックにより、検索者から選択された文書に含まれる単語を用いて拡張した検索条件による二次検索結果に含まれるものを、関連性の高い関連文書として記録することもできる。その場合は、検索結果表示部166は、検索文書のリストとともに適合文書として登録するためのボタンなどのGUIを表示させ、検索者からGUIを介して登録の指示があった文書が検索履歴記録部122に報告され、指示された適合文書を用いて拡張された二次検索結果に含まれる文書が関連文書として記録されることとなる。
ここで、図5を参照して検索履歴の詳細について説明する。図5は、検索履歴のデータ構造を示す。図5(A)に示す検索履歴テーブル200は、第1の実施形態の文書検索システム100において用いられ、検索条件を識別する検索条件IDが入力されるフィールド200aと、検索条件の内容が入力されるフィールド200bとを含んで構成され、検索者から要求された検索条件に関する情報が時系列的にエントリされてゆく。また、検索履歴テーブル200は、検索結果としてヒットした検索文書の文書IDのセットが入力されるフィールド200cと、検索結果から参照された関連文書の文書IDのセットが入力されるフィールド200dとを含んで構成され、検索条件と、関連文書の集合と、検索文書の集合とをさらに関連付けている。
再び図3を参照すると、本実施形態のWebサーバ120は、さらに、蓄積した上記検索履歴を利用して検索条件に関連性の高い関連検索条件を抽出するために、グラフ・テーブル編成部124と、グラフ構築部126と、グラフ管理部128とを含んで構成され、後述するランダム・ウォーク・ウィズ・リスタート(Random-walk with Restart;以下、RWRとして参照する。)方式により要求された新規検索条件と過去の検索条件との間の関連度の算出に用いるための状態遷移グラフを構成し、管理している。本実施形態のグラフ・テーブル編成部124、グラフ構築部126およびグラフ管理部128は、統合的に状態遷移グラフを構成する構成手段として機能する。本実施形態のDBサーバ110は、グラフ・テーブル格納部112をさらに含んで構成され、グラフ・テーブル格納部112は、状態遷移グラフを構成するためのテーブル・セットを格納している。
グラフ・テーブル編成部124は、時系列データとして構成される検索履歴を検索履歴格納部114から読み出して、状態遷移グラフを構成するためのテーブル・セットを作成して、グラフ・テーブル格納部112へ格納する。このテーブル・セットは、検索条件毎に履歴情報が整理されて構成される検索条件ノード・テーブルと、関連文書毎に整理されて構成される関連文書ノード・テーブルとを含んで構成される。状態遷移グラフの各ノードは、検索条件IDおよび文書IDにより識別される。
グラフ・テーブル編成部124は、同一検索者から短期間に頻発して要求された検索要求などの異常な履歴エントリや、内容が同一の重複する履歴エントリなど、不要なエントリを適宜除去して、状態遷移グラフに追加するべき履歴エントリを取捨選択しつつ、上記テーブル・セットを作成する。Webサーバ120は、更新要求部134を含んで構成され、更新要求部134は、予め設定された間隔やスケジュールなどに従って、グラフ・テーブル編成部124に対して上記テーブル・セットの再構成を指令し、検索履歴の経時的な状態変化をテーブル・セットに反映させている。
Webサーバ120は、さらにスタートアップ処理を行うサーバ起動部132を含んで構成され、サーバ起動部132は、起動時にグラフ構築部126を呼び出す。グラフ構築部126は、グラフ・テーブル格納部112からテーブル・セットを読み出して、状態遷移グラフを構築する。この状態遷移グラフは、検索条件のノードと関連文書のノードとを含んで構成され、さらに、接続されるノード間の関係性を表す重み値を含んで構成される。状態遷移グラフは、より具体的には、各ノード間の重み値からなる隣接行列によって表現される。構築された状態遷移グラフは、グラフ管理部128へと渡され、グラフ管理部128は、渡された状態遷移グラフをメモリ16が提供するグラフ記憶部130に記憶させる。
ここで、図6を参照して、状態遷移グラフの構築処理の詳細について説明する。図6は、第1の実施形態によるWebサーバ120が実行する状態遷移グラフ構築処理を示すフローチャートである。図6に示す処理は、例えば、Webサーバ120の起動時にサーバ起動部132から呼び出されて、ステップS100から開始される。ステップS101では、グラフ構築部126は、グラフ・テーブル格納部112への接続を確立する。ステップS102では、グラフ構築部126は、検索条件ノード・テーブルおよび関連文書ノード・テーブルを読み出して、検索条件ノードqiのセットおよび関連文書ノードvdiのセットからなる状態遷移グラフを構成する。ステップS102では、より具体的には、検索条件ノードqiおよび関連文書ノードvdiからなるノード・セットを行および列とした隣接行列が準備される。
ステップS103では、グラフ構築部126は、各検索条件ノード間のリンク(qi→qj)の重み値を計算する。このリンク(qi→qj)の重みは、検索条件間の関係性を表し、例えば、対応する検索結果に含まれる検索文書の重複度、対応する関連文書の重複度、および検索条件の内容自体に含まれる単語の類似度、またはこれらの少なくとも1つを用いて算出することができる。上記検索文書の重複度ObjFeedSim(qi,qj)は、例えば、検索条件ノードqiに対応する上位Kの検索文書の集合topK(qi)と、検索条件ノードqjに対応する上位Kの検索文書の集合topK(qj)とを用いて、下記式、
により算出することができる。上記関連文書の重複度SubFeedSim(q
i,q
j)も同様に、検索条件ノードq
iに対応する関連文書の集合visDocs(q
i)と、検索条件ノードq
jに対応する関連文書の集合visDocs(q
j)とを用いて、下記式、
により算出することができる。上記単語の類似度ContSim(q
i,q
j)は、検索条件ノードq
iの内容に含まれる単語の重みW
sと、検索条件ノードq
jの内容に含まれる単語の重みW
tと、検索条件ノードq
iおよび検索条件ノードq
jの両方に含まれる単語の重みW
uとを用いて、下記式、
により算出することができる。ここで、単語の重みW
u,W
s,W
tは、tf/idf(Term Frequency inverse Document Frequency)法により求められた単語の重要度を表している。上記検索文書の重複度ObjFeedSim(q
i,q
j)、関連文書の重複度SubFeedSim(q
i,q
j)、単語の類似度ContSim(q
i,q
j)を用いるリンクの重み値の具体的な算出方法は、特に限定されるものではないが、これらの値に係数をかけて算出した値を用いることができる。また、同一検索条件ノード間のリンク(q
i→q
j;i=j)の重み値は、「0」に設定することができる。
ステップS104では、グラフ構築部126は、検索条件ノードと関連文書ノードとの間のリンク(qi→vdj)の重み値を計算する。このリンク(qi→vdj)の重み値は、各検索条件と関連文書間の関係性を表し、例えば、各検索条件の検索結果から参照された関連文書と該検索条件との間の値を「1」に設定し、参照関係に無い関連文書と検索条件との間の値を「0」に設定することができる。他の実施形態では、参照関係のある関連文書および検索条件において、検索結果における関連文書のランキングスコアを適宜規格化した値を当該重み値として採用してもよい。
ステップS105では、上記検索条件ノード間のリンク(qi→qj)の重み値、および検索条件ノードおよび関連文書ノード間のリンク(qi→vdj)の重み値を用い、リンク(vdi→qj)の重み値がリンク(qi→vdj)と同一であるものとして、また関連文書ノード間のリンク(vdi→vdj)の重み値が「0」であるものとして、準備された隣接行列の成分にこれら重み値を入力して、状態遷移グラフを表現する隣接行列を生成し、グラフ記憶部130へ格納し、ステップS106で処理を終了させる。
上述したように、本実施形態のWebサーバ120は、新たに要求された検索条件に関連する関連検索条件を抽出するために、要求された検索条件と、該検索条件による検索結果に含まれる検索文書と、参照あるいは指定された関連文書とを対応付けて検索履歴として記録し、この検索条件に対応するノード、および関連文書に対応するノードからなる状態遷移グラフを予め構成しておく。新たな検索要求があった場合には、Webサーバ120は、以下説明するように、この状態遷移グラフを用いて関連検索条件の抽出処理を実行する。
再び図3を参照すると、本実施形態のWebサーバ120は、さらに、規格化処理部138と、RWR計算部140と、関連条件抽出部142とを含んで構成され、RWR方式を適用して、蓄積した上記検索履歴を利用した関連検索条件の抽出処理を実行する。上記グラフ管理部128は、クライアント160から検索要求を受信すると、関連検索条件を抽出するために、この新たな検索条件のノードを状態遷移グラフに追加して新規検索要求に適合させて更新し、この更新済みの状態遷移グラフの隣接行列を規格化処理部138へと渡す。
図7は、第1の実施形態による隣接行列のデータ構造を示す図である。図7に示す隣接行列は、検索条件ノードおよび関連文書ノードを、行および列に配したデータ構造となっており、リンク(qi→qj)の重み値、リンク(qi→vdj)の重み値、リンク(vdi→qj)の重み値、リンク(vdi→vdj)の重み値(=0)を成分として構成されている。また、最後の行および列には、新たに要求された新規検索条件に対応する行ベクトルおよび列ベクトルがそれぞれ追加されている。図7に示す実施形態では、新規検索条件ノードと、過去の検索条件ノードとのリンク(qnew→qj;qi→qnew)の重み値が「0」であり、一方、新規検索条件ノードと履歴に含まれる関連文書ノードとのリンク(qnew→vdj;vdi→qnew)には、ある重み値が与えられている。リンク(qnew→vdj;vdi→qnew)の重み値は、例えば、検索履歴に含まれる関連文書の中から新規検索条件にて全文検索した場合に得られるランキングスコアを利用することができ、また所定の閾値以下のスコアを有する関連文書との重み値を「0」に設定することもできる。
再び図3を参照すると、規格化処理部138は、隣接行列の各行の総和を1となるよう規格化し、規格化済みの隣接行列をRWR計算部140へ渡す。RWR計算部140は、規格化済みの隣接行列にRWR方式を適用して、新たに要求された検索条件と、過去の検索条件との間の関連度を計算する。RWR方式では、隣接行列Aに対し、リスタート・ベクトルVを繰り返し適用して、得られる定常状態のベクトルUSSを求める。このベクトルUSSには、新規検索条件ノードqnewと、過去の各検索条件ノードqiとの関連度を成分として含まれることとなる。
以下、図8および図9を参照して、RWR方式による関連度計算処理の詳細について説明する。図8は、第1の実施形態による隣接行列A、リスタート・ベクトルV、および定常状態のベクトルUssを模式的に例示している。リスタート・ベクトルVは、新規検索条件に対応する成分が1である他、他の成分が0であるベクトルである。また隣接行列Aの行および列には、検索条件ノードqiに対応する検索条件Qi、および関連文書ノードvdiに対応する関連文書Viが示されている。図9は、第1の実施形態のWebサーバ120が実行するRWR方式による関連度計算処理を示すフローチャートである。図9に示す処理は、規格化処理部138から規格化済みの隣接行列Aを渡されて、ステップS200から開始される。
ステップS201では、RWR計算部140は、まず、初期値のベクトルU0としてリスタート・ベクトルVを与える。ステップS202では、RWR計算部140は、所与の定数c、隣接行列A、リスタート・ベクトルV、次のベクトルUi+1、および現在のベクトルUiを用いて表される下記式、
に従って、現在の現在のベクトルU
iから次のベクトルU
i+1を算出する。ステップS203では、ベクトルU
iとベクトルU
i+1との差のノルム(=|U
i+1−U
i|)、より具体的には距離を算出し、ノルムが所定の閾値以下となり、収束したか否かを判定する。
ステップS203で、収束していないと判定された場合(NO)には、ステップS204へ処理を進める。ステップS204では、イタレーションの回数iが、所定の打ち切り限度を越えたか否かを判定する。ステップS204で、未だ打ち切り限度を越えていないと判定された場合(NO)には、ステップS205へ処理を進めて、iを加算し、ステップS202へと再びループさせる。
一方、ステップS203で、収束したと判定された場合(YES)には、ステップS206へ処理を進めて、処理を終了させる。同様に、ステップS204で、打ち切り限度を超えたと判定された場合(YES)には、ステップS206へ処理を進めて、処理を終了させる。ステップS204の判定によって、所定回数以上のイタレーションが行われても充分に収束しない場合にでも処理を終了させることができる。そして、ステップS203またはS204からループを出たとき、最後に算出されたベクトルUi+1が、定常状態のベクトルUSSとして与えられる。図8に示すように、ベクトルUSSは、新規検索条件Qnewに対する、検索履歴中の過去の検索条件Qiおよび過去の関連文書Viの関連度を成分として含んでいる。
再び図3を参照すると、RWR計算部140は、得られた定常状態のベクトルUSSを関連条件抽出部142へ渡す。関連条件抽出部142は、得られたベクトルUSSの成分である関連度に従って、検索条件Qiをソーティングし、関連度が上位の関連検索条件のリスト(以下、関連検索条件リストとして参照する。)を、その内容および関連度とともに照会処理部144を経由して検索結果応答部146へ渡す。
関連検索条件リストを得て検索結果応答部146は、取得した文書リストを含む照会結果に従って当該検索要求に対する検索結果の応答データを生成する際に、関連条件抽出部142から取得した関連検索条件の表示および該関連検索条件による検索要求を指令するハイパーリンク情報を検索結果の応答データに含める。そして、検索要求に対する検索結果と関連検索条件の抽出結果との両方を含む応答データがクライアント160へ返信されることとなる。なお、本実施形態では、関連検索条件による検索要求を指令するハイパーリンク情報を応答データに含める構成として説明したが、他の実施形態では、関連検索条件による照会を実際に実施し、この検索結果をも応答データに含める構成を採用することもできる。
図10は、第1の実施形態においてWebサーバ120より返信された応答データに従ってクライアント160のディスプレイ上に表示されるGUI画面を示す。図10に示すGUI画面310は、図4(A)に示したGUI画面300で入力された検索条件を示すテキスト312と、検索履歴から抽出された過去の関連検索条件を示すテキスト314と、上記検索条件の検索結果に含まれる上位検索文書をサマリとともに一覧表示するテキスト316と、GUI画面300に戻るためのボタン318とを含んで構成される。テキスト314の各関連検索条件には、ハイパーリンクが付されており、該ハイパーリンクをクリックすることにより、関連検索条件を条件とした検索要求が容易に行えるように構成されている。図10に示す例では、GUI画面310には、オリジナルの検索条件として「電子図書館」が表示され、「電子図書館 マイライブラリ」「専門分野 文献検索」など、過去の関連する複数の検索条件が提示されている。なお、上記クリックに替えてリターンキーの押下など、別の動作により関連検索条件を条件とした検索要求が行えるよう構成することができることは、言うまでもない。
上述したように、上記第1の実施形態の文書検索システム100における関連検索条件の抽出処理により、検索条件に含まれる単語自体の類似性のみならず、各検索条件と関連文書との対応付けから辿られる検索条件間の間接的な関係性が活用されて関連検索条件が抽出されることとなる。したがって、共通の単語を含まないような検索条件であっても、間接的な関係性が高いものであれば関連検索条件として抽出される可能性があり、過去の検索履歴をより有効に活用できるものと言える。また、第1の実施形態では、一度検索条件を入力することにより、当該検索条件による検索結果と当該検索条件に関係性の高い関連検索条件の抽出結果との両方が得られるため、検索履歴からの検索条件を抽出するための条件の別途入力が不要とされ、高いユーザ利便性が提供される。
また、検索結果から参照された文書を関連文書として履歴に記録するよう構成可能であるため、検索者が検索文書について登録の要否を判断し明示的に指定する手間を省くことが可能であり、ユーザ利便性高く関連度の精度を高めることができる。また、適合性フィードバックにより対話的に指定された関連文書を記録する他の実施形態でも、検索者に特別の心理的負担をかけることなく、容易に関連文書の登録を行うことが可能とされる。
しかしながら、第1の実施形態の隣接行列では、新規検索条件ノードと履歴中の関連文書ノードとのリンク(qnew→vdj;vdi→qnew)には、ある重み値が与えられている一方で、新規検索条件ノードと、過去の検索条件ノードとのリンク(qnew→qj;qi→qnew)の重み値は、「0」に設定されていた。そのため、新規検索条件と過去の検索条件とが、例え共通の単語を多く含んでいた場合でも、RWR法による計算結果として得られる両者の関連度が低く計算され、この過去の検索条件が表示されない、または下位になってしまう蓋然性がある。以下、RWR法の最終的な計算結果において、入力した検索条件と共通の単語をより多く含む過去の検索条件との間の関連度が高くなるよう構成される、第2の実施形態の文書検索システム100について説明する。
第2の実施形態による文書検索システムは、隣接行列のデータ構造以外の構成は、第1の実施形態の文書検索システムと同一であるため、説明の便宜上、隣接行列以外の構成についての説明は割愛する。図11は、第2の実施形態における隣接行列のデータ構造を示す図である。図12は、第2の実施形態による隣接行列A、リスタート・ベクトルV、および定常状態のベクトルUssを模式的に例示する図である。図11および図12に示す隣接行列は、第1の実施形態と同様に、検索条件ノードおよび関連文書ノードを行および列に配したデータ構造となっており、最後の行および列には、新規検索条件に対応する行ベクトルおよび列ベクトルがそれぞれ追加されている。第2の実施形態のデータ構造では、新規検索条件ノードと履歴中の関連文書ノードとのリンク(qnew→vdj;vdi→qnew)に加えて、新規検索条件ノードと、過去の検索条件ノードとのリンク(qnew→qj;qi→qnew)の重み値が与えられている。リンク(qnew→qj;qi→qnew)の重み値は、過去の検索条件間のリンク(qi→qj)と同様に、例えば、上記式(3)のqiをqnewに読み替えて表現されるような検索文書の含有する単語の類似度ContSim(qnew,qj)を用いて算出することができる。
図11に示す第2の実施形態の隣接行列のデータ構造を用いた関連条件の抽出処理により、検索者の検索目的に応じて自然なランク付けの関連検索条件の抽出結果を提示することが可能となる。例えば、新規検索条件として「電子図書館」が入力された場合、関連する過去の検索条件が、含有する単語の類似度の高い順、図10に示す例では、「電子図書館 マイライブラリ」、「図書館評価」、「電子ジャーナル」、「専門分野 文献検索」、「図書館ポータル 利用状況」といった順に表示されることとなり、「電子図書館」をそのまま含む「電子図書館 マイライブラリ」が上位に表示されることとなる。つまり、利用者の最大の関心対象である「電子図書館」をそのまま含む検索条件が上位にランクされるようになる。
以下、検索者に関する情報を含む検索履歴を活用して関連検索条件を抽出する第3の実施形態による文書検索システムについて説明する。第3の実施形態の文書検索システムの概略構成および各装置のハードウェア構成は、第1の実施形態の文書検索システムと同一であるため、説明は割愛する。
図13は、第3の実施形態による文書検索システム100の機能ブロックを示す。図13に示す文書検索システム100は、クライアント160のログイン手続部162と、Webサーバ120の新規ユーザ判定部150、検索条件ノード付加部152およびユーザ・ノード付加部154からなる機能構成148を、図3と相違する部分として含んで構成されている。なお、図13に示す機能部のうち、図3に示したものと同様の機能を有するものについては、同一符号を付し、詳細な説明は省略する。
ログイン手続部162は、ユーザ名およびパスワードの入力を求めてシステムに対しログイン手続処理を実行する。クライアント160とWebサーバ120との間のメッセージ交換は、クッキーなどによってセッション管理されており、第3の実施形態のWebサーバ120は、検索者であるユーザを識別可能とされている。なお、第3の実施形態では、パスワードを伴わないゲストユーザのログインを許可するよう構成することもできる。検索条件が入力され、GUIを介した検索指示を受けると、検索条件入力部164は、入力された検索条件と、ユーザを識別する情報とを含む検索要求をWebサーバ120へ送信する。
ここで、図4を参照して、第3の実施形態において検索要求のために用いられるGUI画面について説明する。図4(B)に示すGUI画面330は、第3の実施形態の文書検索システムにおける検索要求を発行するためのGUIを提供し、ログイン手続後に表示され、検索条件を入力するためのテキスト・ボックス332と、検索要求を指示するための検索ボタン334と、ログアウトするためのログアウト・ボタン336とを含んで構成される。
再び図13を参照すると、第3の実施形態の検索履歴記録部122は、検索条件入力部164から送信された検索要求に含まれる検索条件と、ユーザ識別値と、該検索条件による検索結果に含まれる検索文書とを相互に関連付けて検索履歴格納部114へ記録する。ここで図5を参照して、第3の実施形態の検索履歴の詳細について説明する。図5(B)に示す検索履歴テーブル210は、第1の実施形態と同様に、検索条件IDが入力されるフィールド210aと、検索条件の内容が入力されるフィールド210cと、検索文書の文書IDのセットが入力されるフィールド210dと、関連文書の文書IDのセットが入力されるフィールド210eとを含む。第3の実施形態の検索履歴テーブル210は、さらに、該検索条件の検索者を識別するユーザIDが入力されるフィールド210bを含んで構成され、検索条件と、ユーザと、関連文書の集合と、検索文書の集合とを関連付けている。
再び図13を参照すると、第3の実施形態のグラフ・テーブル編成部124は、時系列データとして構成される検索履歴テーブル210を検索履歴格納部114から読み出して、検索条件ノード・テーブルおよび関連文書ノード・テーブルに加え、検索者ユーザ毎に整理されて構成されるユーザ・ノード・テーブルを作成し、グラフ・テーブル格納部112へ格納する。第3の実施形態では、状態遷移グラフの各ノードは、検索条件ID、文書ID、およびユーザIDにより識別されることとなる。そして、第3の実施形態のグラフ・テーブル編成部124は、同一ユーザから短期間に頻発して要求された検索要求などの異常な履歴エントリや、同一ユーザからの内容が同一の重複する履歴エントリなど、不要なエントリを適宜除去して、状態遷移グラフに追加するべき履歴エントリを取捨選択しつつ、上記テーブル・セットを作成する。
以下、第3の実施形態の文書検索システム100におけるグラフ構築部126の機能について説明する。グラフ構築部126は、第3の実施形態では、検索条件のノード、関連文書のノードに加えて、ユーザのノードを含む状態遷移グラフを構築する。以下、図14を参照して、第3の実施形態における状態遷移グラフの構築処理の詳細について説明する。
図14は、第3の実施形態によるWebサーバ120が実行する状態遷移グラフ構築処理を示すフローチャートである。図14に示す処理は、例えば起動時にサーバ起動部132から呼び出されて、ステップS300から開始される。ステップS301では、グラフ構築部126は、グラフ・テーブル格納部112への接続を確立する。ステップS302では、グラフ構築部126は、検索条件ノード・テーブル、ユーザ・ノード・テーブルおよび関連文書ノード・テーブルを読み出して、検索条件ノードqiのセット、ユーザ・ノードuiのセット、および関連文書ノードvdiのセットからなる状態遷移グラフを構成する。ステップS302では、より具体的には、検索条件ノードqi、ユーザ・ノードui、および関連文書ノードvdiからなるノード・セットを行および列に配した隣接行列が準備される。
ステップS303では、グラフ構築部126は、各ユーザ・ノード間のリンク(ui→uj)の重み値を計算する。このリンク(ui→uj)の重み値は、検索者ユーザ間の関係性を表し、検索者により入力された過去の検索条件が検索者の興味を好適に反映しているものとして、上記式(3)と同様に算出される各検索者ユーザの過去の検索条件の内容が含有する単語の類似度を用いて算出することができる。その他、システムがユーザ・プロファイルとして保持する検索者ユーザの所属、ブックマーク情報、RSSフィーダ情報などを用いて、上記重み値を算出することができる。例えば、検索者が同じ研究室に属していた場合に、対応するユーザ・ノード間の重みを「0.9」とし、研究室が相違していても学科が同一であれば「0.6」とし、学科が相違していても学部が同一であれば0.3とし、学部も相違すれば0とする、というように設定することができる。
ステップS304では、グラフ構築部126は、第1の実施形態と同様に、対応する検索結果に含まれる検索文書の重複度ObjFeedSim(qi,qj)、対応する関連文書の重複度SubFeedSim(qi,qj)、および検索条件の内容に含まれる単語の類似度ContSim(qi,qj)、またはこれらの少なくとも1つを用いて、各検索条件ノード間のリンク(qi→qj)の重み値を計算する。
ステップS305では、グラフ構築部126は、検索条件ノードとユーザ・ノードとの間のリンク(qi→uj)の重み値を計算する。このリンク(qi→uj)の重み値は、各検索条件と検索者ユーザとの間の関係性を表し、例えば、検索条件と該検索条件による検索要求を行った検索者ユーザとの間の値を「1」に設定し、それ以外の場合に「0」に設定することができる。
ステップS306では、グラフ構築部126は、ユーザ・ノードと関連文書ノードとの間のリンク(ui→vdj)の重み値を計算する。このリンク(ui→vdj)の重み値は、各検索者ユーザと関連文書との間の関係性を表し、例えば、各検索者により検索結果から参照された関連文書と該検索者ユーザとの間の値を「1」に設定し、参照関係に無い関連文書と検索者ユーザとの間の値を「0」に設定することができる。
ステップS307では、グラフ構築部126は、第1の実施形態と同様に、関連文書と検索条件との参照関係の有無から、検索条件ノードと関連文書ノードとの間のリンク(qi→vdj)の重み値を計算する。その他、参照関係のある関連文書および検索条件において、検索結果における関連文書のランキングスコアを適宜規格化した値を当該重み値として採用してもよい。
ステップS308では、上記ユーザ・ノード間のリンク(ui→uj)の重み値、上記検索条件ノード間のリンク(qi→qj)の重み値、検索条件ノードおよびユーザ・ノード間のリンク(ui→qj)の重み値、ユーザ・ノードおよび関連文書ノード間のリンク(ui→vdj)の重み値、および検索条件ノードおよび関連文書ノード間のリンク(qi→vdj)の重み値を用い、逆向きのリンクの重み値が同一であるものとして、また関連文書ノード間のリンク(vdi→vdj)の重み値が「0」であるものとして、準備された隣接行列の成分にこれら重み値を入力して、状態遷移グラフを表現する隣接行列を生成し、ステップS309で処理を終了させる。
再び図13を参照すると、第3の実施形態の文書検索システム100では、入力された検索条件と、検索者ユーザを識別する情報とを含む検索要求を検索条件入力部164から受信すると、上記新規ユーザ判定部150は、当該検索者ユーザが既に状態遷移グラフの中に組み込まれているか否かを判定する。
検索者ユーザが既に状態遷移グラフ中に存在していた場合には、検索条件ノード付加部152のみが呼び出される。この場合、検索条件ノード付加部152は、第1の実施形態の文書検索システム100と同様に、上記グラフ管理部128に対し、この新たな検索条件のノードを状態遷移グラフに追加させて更新する。一方、検索者ユーザが状態遷移グラフ中に存在していない場合には、検索条件ノード付加部152とともにユーザ・ノード付加部154が呼び出される。この場合、検索条件ノード付加部152は、第1の実施形態の文書検索システム100と同様に、上記グラフ管理部128に対し、新たな検索条件のノードを追加させるとともに、ユーザ・ノード付加部154は、新たな検索者ユーザのノードを状態遷移グラフに追加させる。
図15は、第3の実施形態による隣接行列のデータ構造を示す図である。図15に示す隣接行列は、検索条件ノード、ユーザ・ノードおよび関連文書ノードを行および列に配したデータ構造となっており、リンク(qi→qj)の重み値、リンク(qi→vdj:vdi→qj)の重み値に加えて、リンク(ui→uj)の重み値、リンク(qi→uj:ui→qj)の重み値、リンク(ui→vdj:vdi→uj)の重み値を成分として構成されている。また、最後の行および列のそれぞれには、新規検索条件および新規ユーザに対応する行ベクトルおよび列ベクトルのセットが追加されている。
図15に示すデータ構造では、新規検索条件ノードと履歴中の関連文書ノードとのリンク(qnew→vdj;vdi→qnew)、新規検索条件ノードおよび過去の検索条件ノードのリンク(qnew→qj;qi→qnew)に加えて、新規ユーザ・ノードと既存のユーザ・ノードとのリンク(unew→uj;ui→unew)の重み値が与えられている。リンク(unew→uj;ui→unew)の重み値は、既存のユーザ・ノード間のリンク(ui→uj)と同様に、上記式(3)と同様に算出される新規ユーザの当該検索条件と、既存のユーザの過去の検索条件の内容自体に含まれる単語の類似度、検索者ユーザの所属、ブックマーク情報、RSSフィーダ情報などのユーザ・プロファイルを用いて算出することができる。また、適当な情報が無い場合には、リンク(unew→uj;ui→unew)の重み値をすべて「0」に設定することもできる。
図16は、第3の実施形態による隣接行列A、リスタート・ベクトルV、および定常状態のベクトルUssを模式的に例示している。リスタート・ベクトルVは、第1の実施形態のデータ構造と同様に、新規検索条件に対応する成分が1である他、他の成分が0であるベクトルである。また隣接行列Aの行および列には、検索条件ノードqiに対応する検索条件Qi、ユーザ・ノードuiに対応するユーザUi、および関連文書ノードvdiに対応する関連文書Viが示されている。第3の実施形態の文書検索システムでは、図16に示す隣接行列Aが規格化処理部138へ渡されて規格化され、さらにRWR計算部140へ渡される。RWR計算部140は、規格化済みの隣接行列AにRWR方式を適用して、図9に示すフローチャートと同様の処理によって、新規検索条件と、過去の検索条件との間の関連度を計算する。RWR方式を適用して得られたベクトルUSSは、図16に示すように、新規検索条件Qnewに対する過去の検索条件Qi、既存のユーザUiおよび過去の関連文書Viの関連度を成分として含んでいる。
関連検索条件リストを得て検索結果応答部146は、上述したように、関連検索条件の表示および該関連検索条件による検索要求を指令するハイパーリンク情報を検索結果の応答データに含めて生成する。第3の実施形態では、検索結果応答部146は、その際さらに、本検索要求の検索者ユーザと関連付けられている条件をユーザ自身の過去の関連検索条件とし、本検索要求のユーザに関連付けられていない条件を、他の人の過去の関連検索条件として、区別して表示されるように上記応答データを構成する。そして、検索要求に対する検索結果と、自他で区分された関連検索条件の抽出結果の両方を含む応答データがクライアント160へ返信されることとなる。
図17は、第3の実施形態においてWebサーバ120より返信された応答データに従ってクライアント160のディスプレイ上に表示されるGUI画面を示す。図17に示すGUI画面320は、図4に示したGUI画面300で入力された検索条件を示すテキスト322と、検索履歴から抽出された当該検索者の過去の関連検索条件を示すテキスト324と、他の検索者の過去の関連検索条件を示すテキスト326と、検索結果に含まれる上位検索文書をサマリとともに一覧表示するテキスト328と、GUI画面300に戻るためのボタン329とを含んで構成される。図17に示す例では、GUI画面320には、オリジナルの検索条件として「電子図書館」が表示され、検索者自身の過去の検索条件として「電子図書館 マイライブラリ」「専門分野 文献検索」が提示され、他の人の過去の関連検索条件として、「図書館評価」や「図書館ポータル 利用状況」「電子ジャーナル」が提示されている。なお、他の実施形態では、さらに、ユーザが属するグループ情報などに従って、グループの他メンバの過去の関連検索条件を、さらに区別して提示することもできる。なお、第3の実施形態の文書検索システム100では、ゲストユーザにてログインされていた場合には、図17に示すGUI画面320において、テキスト324が表示されず、他の人の過去の関連検索条件を示すテキスト326のみが表示されることとなる。
上述したように、第3の実施形態の文書検索システムにおける関連検索条件の抽出処理により、検索要求を行った検索者に関する情報を活用して、新規検索条件と過去の検索条件との関連度を算出するため、その検索者の興味や関心を反映した関連検索条件を抽出することが可能となる。例えば、過去において異なる検索者が同一の検索条件を用いて検索した場合であっても、それぞれ異なる文書を関連文書として参照または指定する可能性があるため、当該抽出処理によれば、検索要求した検索者の相違も応答して関連度が算出され、得られる関連検索条件も異なることとなる。したがって、その検索者の興味や関心を反映した関連検索条件を抽出することが可能となる。また、第3の実施形態では、当該検索者の過去の検索条件と、他の検索者の過去の検索条件とが識別可能に提示されるため、検索者は、自身の検索目的に合致した関連検索条件を容易に認識することができる。例えば、自身の過去の検索行動や思考を想起したい場合には、自身の過去の検索条件を見ればよく、自身の発想を広げたい場合には、他の人の関連検索条件を参照すればよい。
上述までの実施形態では、検索条件ノードと関連文書ノードとの間のリンク(qi→vdj)の重み値は、各検索条件の検索結果から参照された関連文書と該検索条件との間の値を「1」に設定し、参照関係に無い関連文書と検索条件との間の値を「0」に設定するものとして説明してきた。しかしながら、検索条件と関連文書との関連性としては、参照関係の有無のみならず、種々の信頼性の程度を有する文書を定義付けることができる。例えば、ユーザが単に検索結果から参照した参照文書と、適合性フィードバックにおいてユーザが適合するものと指定した適合文書、詳細な書誌情報を参照した後に適合するものとしてユーザが明示的に指定した指定文書とでは、検索者ユーザの興味や関心の程度が異なり、これらの関連情報と検索条件との間の関連性に対する信頼性は、相違するものと考えられる。
以下、参照関係の有無のみならず、上記の参照文書、適合文書および指定文書の別に応じて求められるリンク(qi→vdj)の重み値を用いる第4の実施形態の文書検索システム100について説明する。第4の実施形態の文書検索システムの概略構成および各装置のハードウェア構成は、第1の実施形態の文書検索システムと同一であるため、説明は割愛する。また、第4の実施形態の文書検索システムの機能ブロックは、第1の実施形態と同様であるため、図3を再び参照して、第4の実施形態による文書検索システム100の機能ブロックについて説明する。なお、図3に示す機能部のうち、第1および第2の実施形態と同様の機能を有するものについては、詳細な説明は省略し、相違点を中心として説明する。
第4の実施形態の検索結果応答部146は、検索要求に応答して、その検索結果の応答データを生成して、クライアント160へ返信する。このとき、第4の実施形態の応答データには、例えばチェックボックスなど、検索文書の中から適合性フィードバックによる適合文書を指定するためのGUI部品、適合文書を用いた再検索を指示するためのGUI部品の表示指令が含められている。クライアント160の結果表示部166は、受信した応答データに従って、適合文書を指定するためのGUI部品、および適合文書を用いた再検索を指令するためのGUI部品を含む検索結果を画面表示する。
図18は、第4の実施形態においてWebサーバ120より返信された応答データに従ってクライアント160のディスプレイ上に表示されるGUI画面を示す。図18に示すGUI画面340は、例えば図4(A)に示したGUI画面300で入力された検索条件を示すテキスト342と、検索履歴から抽出された過去の関連検索条件を示すテキスト344と、上記検索条件の検索結果に含まれる上位検索文書を、適合文書として指定するためのチェックボックス352a〜eおよびサマリとともに一覧表示する結果リスト346と、GUI画面300に戻るためのボタン348と、指定された適合文書を用いた再検索を指令するための再検索ボタン350とを含んで構成される。再検索ボタン350がクリックされると、結果表示部166は、適合文書の指定を含めてWebサーバ120へ適合性フィードバックによる再検索の要求を発行する。
適合性フィードバックによる再検索の要求を受領したWebサーバ120では、照会処理部144が、指定された適合文書に含まれるキーワードで検索条件を拡張してインデックス・データベース116に照会するとともに、指定された適合文書のリストを検索履歴記録部122へ報告する。検索履歴記録部122は、先の検索要求に含まれる検索条件と、報告された適合文書とを相互に関連付けて検索履歴格納部114へ記録する。一方、検索結果応答部146は、二次検索結果として拡張された検索条件に該当する検索文書の文書のリストを取得し、二次検索結果の文書リストを検索履歴記録部122へ報告する。検索履歴記録部122は、先の検索要求に含まれる検索条件と、報告された二次検索結果に含まれる文書とを相互に関連付けて検索履歴格納部114へ記録することができる。
図18に示すGUI画面340の結果リスト346にリストアップされる各上位検索文書には、その詳細な書誌情報を表示させるためのハイパーリンクが付されている。結果表示部166は、GUIを介して検索者からの検索文書の詳細な書誌情報の参照の指示を受けた場合、文書表示部168を呼び出す。呼び出された文書表示部168は、指定された検索文書の詳細な書誌情報へアクセスするとともに、当該検索文書が参照された旨の報告をWebサーバ120へ送信する。報告を受けて検索履歴記録部122は、検索条件に対し、さらに参照文書をさらに関連付けて記録する。
図19は、第4の実施形態において、クライアント160のディスプレイ上に表示される指定文書を指定するためのGUI画面を示す。図19に示すGUI画面360は、詳細な書誌情報を示すテキスト366、図18に示すGUI画面340に戻るための戻るボタン364と、さらに、適合する文書であるとして明示的に指定するためのチェックボックス362とを含んで構成される。戻るボタン364がクリックされると、結果表示部166は、チェックボックス362に対するチェックの有無を参照文書に関連付けて、Webサーバ168へ報告する。報告を受けてWebサーバ120の検索履歴記録部122は、チェックが有りの場合には、当該参照文書を明示的に適合すると指定された指定文書として、当該検索条件に対しさらに関連付けて記録する。
つまり、第4の実施形態のWebサーバ120は、新たに要求された検索条件に対して、ユーザが検索結果から参照した参照文書と、適合性フィードバックにおいてユーザが適合するものと指定した適合文書、詳細な書誌情報の表示から適合するものとしてユーザが明示的に指定した指定文書とを区別して関連付ける。その他、指示された適合文書を用いて拡張された二次検索結果に含まれる文書をさらに区別して関連付けても良い。
ここで、図20を参照して、第4の実施形態における検索履歴の詳細について説明する。図20は、第4の実施形態による検索履歴のデータ構造を示す。図20に示す検索履歴テーブル220は、第1の実施形態と同様に、検索条件を識別する検索条件IDが入力されるフィールド220aと、検索条件の内容が入力されるフィールド220bとを含んで構成される。また、検索履歴テーブル220は、検索結果として上位にヒットした検索文書の文書IDのセットが入力されるフィールド220cと、検索結果から参照された参照文書の文書IDのセットが入力されるフィールド220dと、適合性フィードバックによる再検索のために指定された適合文書の文書IDのセットが入力されるフィールド220eと、詳細な書誌情報の表示から明示的に指定された指定文書の文書IDのセットが入力されるフィールド220fとを含んで構成され、検索条件と、検索文書の集合と、関連文書の集合とを、該関連情報の種別を区別してさらに関連付けている。
第4の実施形態のグラフ・テーブル編成部124は、時系列データとして構成される上記検索履歴を検索履歴格納部114から読み出して、状態遷移グラフを構成するためのテーブル・セットを作成して、グラフ・テーブル格納部112へ格納する。ここで、再び図6を参照して、第4の実施形態における状態遷移グラフの構築処理の詳細について説明する。なお、ステップS104までの処理については、第1の実施形態と同様であるため、説明を割愛する。
第4の実施形態において、ステップS104では、グラフ構築部126は、検索条件ノードと関連文書ノードとの間のリンク(qi→vdj)の重み値を計算する。このリンク(qi→vdj)の重み値は、各検索条件と関連文書との間の関係性を表し、第4の実施形態においては、関連情報が、参照文書であるか、適合文書であるか、指定文書であるかの別に応じて求められる。
参照文書は、上述したように、検索結果の一覧に含まれる文書のタイトルあるいはサマリのみから判断されて、利用者が興味を持って詳細情報などを参照した文書である。しかしながら、利用者に与えられる情報が限定されているため、単に参照したというだけでは、関連度の程度という観点からは信頼性が低いものとなる。一方、適合文書は、適合性フィードバックのためにチェックボックスなどにより指定された文書である。少なくとも利用者が適合するものとして判断した文書であることから、参照文書と比較して、関連度の程度という観点からは信頼性が高いものとなる。しかしながら、より適合性の高い文書を検索するために、手頃な文書をとりあえず選択された場合もあるため、利用者の興味および関心には完全には適合していない可能性がある。これに対して、指定文書は、詳細な書誌情報を表示させた上で、チェックボックスなどにより明示的に適合するものとして指定された文書である。この指定文書は、利用者が適合するものとして判断し、陽に指定した文書であることから、適合文書と比較しても、関連度の程度という観点から信頼性が高いものといえる。
第4の実施形態において、ステップS104では、上述した参照文書、適合文書および指定文書の順に、重み値を大きく設定する。より具体的には、例えば、参照文書、適合文書、指定文書に対して、それぞれ「0.3」、「0.7」、「1.0」などの多値の重み値を与えるよう構成することができる。なお、参照文書、適合文書、指定文書に対して設定されるこれらの数値はあくまで一例であり、その他の値を設定することもできる。例えば、単に参照された文書は関連性がないものとして、参照文書にも「0」を設定してもよい。また、関連文書が複数の上記種別に属する場合には、値の大きい方の重み値を採用すればよい。ステップS105では、上記検索条件ノード間のリンク(qi→qj)の重み値、および検索条件ノードおよび関連文書ノード間のリンク(qi→vdj)の重み値を用い、リンク(vdi→qj)の重み値がリンク(qi→vdj)と同一であるものとして、また関連文書ノード間のリンク(vdi→vdj)の重み値が「0」であるものとして、準備された隣接行列の成分にこれら重み値を入力して、状態遷移グラフを表現する隣接行列を生成し、グラフ記憶部130へ格納し、ステップS106で処理を終了させる。
上述したように、第4の実施形態のWebサーバ120は、新たに要求された検索条件に関連する関連検索条件を抽出するために、要求された検索条件と、該検索条件による検索文書と、参照文書と、適合文書と、指定文書とを対応付けて検索履歴として記録し、この検索条件に対応するノード、および関連文書に対応するノードからなる状態遷移グラフを予め構成しておく。新たな検索要求があった場合には、Webサーバ120は、第1の実施形態について説明したように、状態遷移グラフを用いて関連検索条件の抽出処理を実行する。
再び図3を参照すると、第4の実施形態のWebサーバ120は、作成された状態遷移グラフを用いて、RWR方式を適用して、蓄積した上記検索履歴を利用した関連検索条件の抽出処理を実行する。上記グラフ管理部128は、クライアント160から検索要求を受信すると、関連検索条件を抽出するために、この新たな検索条件のノードを状態遷移グラフに追加して新規検索要求に適合させて更新し、この更新済みの状態遷移グラフの隣接行列を規格化処理部138へと渡す。
図21は、第4の実施形態における隣接行列のデータ構造を示す図である。図22は、第4の実施形態による隣接行列A、リスタート・ベクトルV、および定常状態のベクトルUssを模式的に例示する図である。図21および図22に示す隣接行列は、第1の実施形態と同様に、検索条件ノードおよび関連文書ノードを行および列に配したデータ構造となっており、最後の行および列には、新規検索条件に対応する行ベクトルおよび列ベクトルがそれぞれ追加されている。第4の実施形態のデータ構造では、リンク(vdi→qj)およびリンク(qi→vdj)に、「0」および「1」以外の多値の重みが入力されている様子が示されている。つまり、第4の実施形態では、単に参照された参照文書よりも適合文書の関連性が強化され、適合文書よりも指定文書の関連性が強化されて、状態遷移グラフが構成され、関連検索条件の検索に用いられることとなる。
再び図3を参照すると、規格化処理部138は、隣接行列の各行の総和を1となるよう規格化し、規格化済みの隣接行列をRWR計算部140へ渡し、RWR計算部140は、規格化済みの隣接行列にRWR方式を適用して、新たに要求された検索条件と、過去の検索条件との間の関連度を計算する。RWR方式による関連度計算処理の詳細については、第1の実施形態と同様であるため、詳細な説明は割愛する。
図21に示す第4の実施形態の隣接行列のデータ構造を用いた関連条件の抽出処理により、参照文書であるか、適合文書であるか、または指定文書であるかといった、関連文書の種別による関連性の信頼度の相違を、関連文書および検索条件のノード間の重み付けの値の相違として取り込み、検索者ユーザの興味や関心を、より反映した過去の検索条件を容易に抽出可能とし、抽出の精度を高めることができる。
なお、関連文書の種別としては、上述した参照文書、適合文書、指定文書に特に限定されるものではない。他の実施形態では、適合文書から再検索される文書を種別に含むことができ、またユーザに対して文書に対する重要度を指定させ、該重要度に対応させて関連文書の種別を区別してもよい。また、同様に第3の実施形態におけるリンク(qi→vdj:vdi→qj)の重み値を求める際に、第4の実施形態の構成を採用することもできる。
以上説明したように、上述までの実施形態によれば、検索者自身や他の検索者の過去の検索経験が適切に反映された関連の検索条件を効率的に抽出し、検索者に手間をかけることなく、その興味、関心および検索目的に適合した過去の検索条件を容易に再利用可能とする情報処理装置、情報検索システム、情報処理方法およびプログラムを提供することが可能となる。なお、上述までの実施形態では、文書を検索対象とする文書検索システム100を用いて説明してきたが、検索対象は、文書に限られるものではなく、画像データ、マルチメディア・データ等の種々のコンテンツを対象とすることができる。その際には、これらの検索対象のデータは、好適には、テキスト情報をメタ情報として含むことができる。
また上記機能は、アセンブラ、C、C++、C#、Java(登録商標)、などのレガシープログラミング言語やオブジェクト指向プログラミング言語などで記述されたコンピュータ実行可能なプログラムにより実現でき、ROM、EEPROM、EPROM、フラッシュメモリ、フレキシブルディスク、CD−ROM、CD−RW、DVD、SDカード、MOなど装置可読な記録媒体に格納して頒布することができる。
これまで本発明の実施形態について説明してきたが、本発明の実施形態は上述した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。
12…MPU、14…不揮発メモリ、16…メモリ、18…記憶制御用インタフェース、20…ハードディスク、22…内部バス、24…インタフェース、26…入出力装置、28…VRAM、30…グラフィック・チップ、32…ディスプレイ装置、34…ネットワークI/F(NIC;Network Interface Card)、34…NIC、100…文書検索システム、110…DBサーバ、110a…データベース、112…グラフ・テーブル格納部、114…検索履歴格納部、116…インデックス・データベース、120…Webサーバ、122…検索履歴記録部、124…グラフ・テーブル編成部、126…グラフ構築部、128…グラフ管理部、130…グラフ記憶部、132…サーバ起動部、134…更新要求部、138…規格化処理部、140…RWR計算部、142…関連条件抽出部、144…照会処理部、146…検索結果応答部、148…機能構成、150…新規ユーザ判定部、152…検索条件ノード付加部、154…ユーザ・ノード付加部、160…クライアント、162…ログイン手続部、164…検索条件入力部、166…結果表示部、168…文書表示部、170…ネットワーク、200,210,220…検索履歴テーブル、300,330…GUI画面、302,332…テキスト・ボックス、304,334…検索ボタン、336…ログアウト・ボタン、310…GUI画面、312…テキスト、314…テキスト、316…テキスト、318…ボタン、320…GUI画面、322…テキスト、324…テキスト、326…テキスト、328…テキスト、329…ボタン、340…GUI画面、342…テキスト、344…テキスト、346…結果リスト、348…ボタン、350…ボタン、352…チェックボックス、360…GUI画面、362…チェックボックス、364…ボタン、366…テキスト