情報検索システム及び方法
【課題】情報検索システムにおいて複雑な動的問合せを効率的に生成することができる情報検索システムを提供する。
【解決手段】情報検索システムのデマンドエージェント１０２は、ユーザー１０１がサーチ表現を特定することができるユーザーインタフェースと、ユーザーが第１問合せと第２問合せ間のチャンネルを特定することができる問合せ仕様インタフェースとを備え、第１問合せの属性に関するサーチ結果を第２問合せの属性として提供する。また、情報検索システムのブローカーエージェント１０３は、前記サーチ表現を処理して特定情報ソースのサーチ要求を作り出すサーチ検索要素と、第１問合せの属性の結果を第２問合せに関連付けるチャンネル要素を備えている。更に、情報検索システムは、前記サーチ要求を受け取り、前記サーチ要求に応答する情報ソースに要求し、そこからドキュメントを得るサプライエージェント１０５を備えている。
【解決手段】情報検索システムのデマンドエージェント１０２は、ユーザー１０１がサーチ表現を特定することができるユーザーインタフェースと、ユーザーが第１問合せと第２問合せ間のチャンネルを特定することができる問合せ仕様インタフェースとを備え、第１問合せの属性に関するサーチ結果を第２問合せの属性として提供する。また、情報検索システムのブローカーエージェント１０３は、前記サーチ表現を処理して特定情報ソースのサーチ要求を作り出すサーチ検索要素と、第１問合せの属性の結果を第２問合せに関連付けるチャンネル要素を備えている。更に、情報検索システムは、前記サーチ要求を受け取り、前記サーチ要求に応答する情報ソースに要求し、そこからドキュメントを得るサプライエージェント１０５を備えている。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースなどの情報リポジトリのサーチ、より詳細には動的問合せを生成し、構成する組み立てる機構（ファシリティ）に関する。
【背景技術】
【０００２】
イントラネットで異種レガシー・データベースにアクセスするとき、あるいはインターネットで多数の情報ソースに問合せをするとき、エンドユーザーは簡単な直接的なアクセスポイントをもつことだけを望んでいる。
【０００３】
典型的な情報検索（retrieval＝リトリーバル）アーキテクチャが、論文“System Components for Embedded Information Retrieval Form Multiple Disparate Information Sources”, Ramana B. Rao, Daniel M. Russell, and Jock D. Mackinlay, Proceedings of 1993 ACM Symposium on User Interface Software and Technology, Atlanta, GA, November 1993 ACM SIGGRAPH and SIGCHI に記載されている。情報検索アーキテクチャは情報アクセス・クライアント（すなわちユーザー）と種々の情報ソース間のアクセス要求を調停する中間サーバーを組み入れている。従って、ユーザーは、多数の情報ソースから情報を検索するために単に情報アクセス・クライアントにインタフェースする必要があるだけである。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】“System Components for Embedded Information Retrieval Form Multiple Disparate Information Sources”, Ramana B. Rao, Daniel M. Russell, and Jock D. Mackinlay, Proceedings of 1993 ACM Symposium on User Interface Software and Technology, Atlanta, GA, November 1993 ACM SIGGRAPH and SIGCHI
【発明の概要】
【発明が解決しようとする課題】
【０００５】
情報検索におけるもう１つの問題は問合せの生成である。有効な問合せを生成するプロセスは対話型のものが多い。そのようなプロセスの場合、ある問合せの結果を使用して、より狭い範囲の第２の問合せが作られることが多い。これが起きる理由は、最初の問合せの範囲が広過ぎたためかもしれないし、また大量の使用できないデータまたは冗長なデータが戻されたからかもしれない。また、既知の問合せシステムは本質的に「静的」である。言い換えると、問合せを始めるには、すべての問合せ項目を固定しなければならない。しかし、ＷＷＷ上で膨大な情報を常時入手可能になったので、問合せは、本質上、より動的にすることが望ましいであろう。さらに、情報リポジトリは本質的に異なるので、問合せの部分が並列にランしていることがある。従って、サーチ項目が静的でないように、本質上動的である問合せを特定し、実行することができることが望ましい。
【課題を解決するための手段】
【０００６】
本発明は、ネットワークでアクセス可能な分散型ベータベース、たとえばインターネット上で見られるようなデータベースのサーチに関するものである。問合わせの組合せを可能にするドラグアンドドロップサーチチャンネルが記述されている。問合わせはコンピュータシステムのディスプレイに問合わせウィンドウとして視覚的に表示される。問合わせウィンドウ上で、意図した問合わせの特質および範囲を定義する属性を入力することができる。属性を論理的に組み合せて、意図した問合せを生成することができる。各属性の仕様（または明細：specification）はオブジェクトとして表現される。ユーザーは、最初の問合せの属性を第２の問合せの属性として含めるように属性を選択する。それにより、属性の図的表現が生成される。次に、ユーザーはその属性の図的表現を第２問合せの属性仕様領域へ「ドラグアンドドロップ」する。その結果、２つの問合せの間に、以下に説明するプロパティをもつことができる通信チャンネルが確立される。
【０００７】
ドラッグアンドドロップサーチチャンネルは計算変換（Computational Transformation）を行う。計算変換は、チャンネルに対応付けられた結果を問合せの文脈（コンテキスト）に自動的に適応させることを考慮に入れている。
【０００８】
ドラグアンドドロップサーチチャンネルは、さらに複合問合せを動的および増分的（インクリメンタル）に生成する能力を提供し、さらにユーザーがサーチ結果を作用させて、手動でフィルタすることができるように区切り点（ブレークポイント）を提供する。
【図面の簡単な説明】
【０００９】
【図１】本発明の好ましい実施例の情報検索システムの構成要素と処理の流れを示すブロック図である。
【図２】本発明の好ましい実施例において使用することができる簡単な問合せウィンドウを示す図である。
【図３】本発明の好ましい実施例において使用することができる複雑な問合せウィンドウを示す図である。
【図４】本発明の好ましい実施例において使用することができる簡単な結果ウィンドウを示す図である。
【図５】本発明の好ましい実施例において使用することができる複雑な結果ウィンドウを示す図である。
【図６】本発明の好ましい実施例において実施することができる、問合せ間のチャンネル生成の例をサンプル画面表示で示した図である。
【図７】図６と同様なサンプル画面表示で示した図である。
【図８】本発明の好ましい実施例において実施することができる、計算変換すなわち問合せ間のチャンネル内の区切り点を特定するユーザーインタフェースをサンプル画面表示で示した図である。
【図９】本発明の好ましい実施例において使用することができる、問合せ間のチャンネル関係を示すために使用される複雑な問合せのデータ構造を示す図である。
【図１０】本発明の好ましい実施例を実施するため使用することができるコンピュータベースシステムを示す図である。
【発明を実施するための形態】
【００１０】
本発明は、１つまたはそれ以上の情報ソースへ問合せを生成して、その１つまたはそれ以上の情報ソースから情報を検索（リトリーバル）するインタフェースに向けられている。本発明の好ましい実施例は、多数の異種データベースに問い合せ、情報を再構成し、カスタマイズされたリポートを生成することができるソフトウェアエージェントを備えた情報検索システムの中に具体化されている。以下、情報検索システムについて説明するが、米国出願時現在のより包括的な説明は、
WWW (URL http://www.xrce.xerox.com/research/ct/rsearch/cbkb.html) 上で見ることができる。
【００１１】
本発明は、複雑な動的問合せを構成する機構（ファシリティ）を提供することによって情報検索システムを構築する。複雑な動的問合せは、問合せの属性の仕様（specification）が静的でなく動的であるので、ある問合せの結果（または部分的結果）は別の問合せによって属性仕様として使用することができる。さらに、前記機能は、周知のドラグアンドドロップ-グラフィックユーザーインタフェース法を使用して非常に直観的なやり方でユーザーが利用できるようになっている。
【００１２】
本発明の好ましい実施例は、適当なJava(登録商標)使用可能ウェブブラウザを使用してWWW(ウェブ)にアクセスすることができるコンピュータベースのシステム上で使用するように具体化されている。具体化に使用した種々のソフトウェアプログラムは周知のJavaプログラミング言語で書かれている。
【００１３】
WWW上の電子的ソースまたは他のオンライン情報リポジトリから入手できる情報量は指数関数的に増えている。これらのリポジトリから関連情報を抽出するにはツールが必要である。情報検索システムは情報を効率的に検索し、組み合わせる機能を洗練化した。図１は、情報検索システムにおいて情報がどのように処理されるかを示す。図１を参照すると、ユーザー１０１は、デマンドエージェント１０２を介して情報を要求する。デマンドエージェント１０２は、一般に、ユーザーに提供されるユーザーインタフェースを取り入れている。好ましい実施例の場合、デマンドエージェント１０２は、Java Applet（登録商標）である。Java Appletは、ユーザーのパーソナルコンピュータシステムにダウンロードされ、適切に構成されたウェブブラウザ（たとえば、適当なJava（登録商標）ソフトウェア機能をもつNetscape Navigator(登録商標)）を使用してアクセスできる。
【００１４】
次に、デマンドエージェント１０２は、情報要求を、ブローカーエージェント１０３へ送る。ブローカーエージェント１０３は、情報要求を、相互依存性のサブリクエストに分解する。それ以上分解することができない要求すなわちサブリクエスト１０４は、サーチエンジン１０６を介して電子情報リポジトリにアクセスするサプライエージェント１０５へ送られる。サプライエージェント１０５は一般に特定のサーチエンジン１０６のプロトコルを使用してインタフェースするように構成されるであろう。たとえば、Alta Vista(登録商標)サーチエンジンにインターフェースし、要求を行うためにサプライエージェント１０５を設けることができる。好ましい実施例の場合、ブローカーエージェントとサプライエージェントは情報検索を行うサーバーシステム上で動作するであろう。
【００１５】
情報検索の結果はブローカーエージェント１０３によって受け取られ、そのあと再構成（re-composition）される。情報検索システムは、いくつかの情報ソースによっては提供されない、進歩した問合せ機構をユーザーに提供しており、これによって、前記の再構成が、結果をフィルタすることを含み、この進歩した問合せ機構を使用可能にすることに留意されたい。再構成は、さらに、受け取った情報をフォーマット化すること、および／または問合せ要求に関する結果をランク付けすることなどの諸タスクを含んでいることがある。再構成が終了すると直ちに、結果がデマンドエージェント１０２へ戻され、ユーザー１０１に提供される。
【００１６】
要求、情報および結果は、フィーチャ制約（feature constraints）で表すことが好ましいことに留意すべきである。要求は完全に定義する必要がない。すなわち、要求は要求する情報の部分的な仕様と対応することがあるからである。さらに、完全に満たすことができない要求は、その属性の一部を例示することによって、または新しい属性を追加する、つまりユーザーフィードバックを行うことによって、最初の要求を精緻にする部分オブジェクトの形で結果を得ることができる。
【００１７】
情報検索システムの種々の態様は、以下の国際公開公報 WO 98/48359(29 October 1998)およびWO 98/48361(29 October 1998)の中に見つけることができる。
【００１８】
上に述べた々のエージェントはそれぞれ適切に構成されたコンピュータベースシステムにおいて実行するJavaプログラミング言語で書かれたソフトウェアプログラムとして取り入れることが好ましい。
【００１９】
図２は、問合せを特定（または指定）するための問合せウィンドウを示す。図２を参照すると、問合せウィンドウ２００のドメイン領域２０１は問合せに対し複数の所定ドメインの１つを特定する手段となる。問合せドメインはサーチしようとする情報の種類に関連がある。たとえば、問合せドメインはドキュメントの種類（たとえば、書籍または論文）または主題領域（たとえば、物理学またはオペラ）であってもよい。好ましい実施例の場合、それらのドメインは前もって決定され、問合せが送られる１つまたはそれ以上の情報ソースに対応している。領域２０２〜２０４はサーチパターンを特定するために設けられている。領域２０２は所定の属性（たとえば、題名または著者）を特定するためにある。領域２０３は属性および特定されたキーワードに課すべき制約（たとえば、含んでいる、または厳密に一致する）を特定するためにある。領域２０４は所望のキーワードを特定するためにあり、キーワードとブール演算子で作られる表現を定義することができる。もしサーチパターンが正しければ、“ADD TO SPECIFICATION”のラベルが付いたボタン２０５を押すと、仕様領域２０６に示すように、現在の問合せ仕様にそのパターンが追加される。もしサーチパターンが正しくなければ、リセットボタン２０７を使用してリセットすることができる。仕様領域２０６はユーザーによって特定されたすべての所望のサーチパターンを含んでいる。
【００２０】
ボタン２０８〜２１１は仕様を編集するために設けられている。ボタン２０８は選択したサーチパターンを編集するためにある。ボタン２０９はサーチパターンを削除する手段となる。ボタン２１０は、全仕様をクリヤする手段となる。ボタン２１１は、部分問合せ（SUBQUERY）を取り消すためにある。最後に、ボタン２１２と２１３はそれぞれ、問合せの提出と取消しの制御のために設けられている。
【００２１】
図３は、問合せ内の部分問合せ、すなわち複雑な問合せを実行するためのウィンドウを示す。複雑な問合せの場合、部分問合せは一組の部分結果を生成する。生成された結果は、それらが主問合せ（一般に、より高いレベルの問合せ）の問合せパターン内に使用される値を引き渡すという意味で、部分結果である。部分問合せは、領域２０３内の所定のオプション（すなわち、オプションの「応答」を選択することによって提供される。これにより、図３のウィンドウが表示される。図３から判るように、部分問合せであることを指示する新しいタブ３０１が含まれている。このタブ３０１により、ユーザーは主問合せと部分問合せとの間で移動することができる。部分問合せの残部は主問合せに類似していることに留意されたい。
【００２２】
図４と図５は、それぞれ、サーチからの結果ウィンドウの要約図と詳細図を示す。図４の要約図は、すべてのヒットのリストと、ヒット数のような一定の全体的要約情報を示す。図５には、個々の「ヒット」に関係するすべての情報フィールドが表示される。本体領域５０１は、ドキュメントのテキスト内容を示す。情報領域５０２はデータ、ＵＲＬロケーション、情報ソース、サイズ、題名などの種々の情報を提供する。この図の場合、ヒットのリストを前後に閲覧（すなわちトラバース）するため、ウィンドウの中には、PREVIOUSボタン５０３とNEXTボタン５０４とが設けられている。
【００２３】
２つの問合せ間にドラグアンドドロップ・チャンネルを確立することは、ソース問合せの属性フィールドに戻された応答を、目標問合せの属性フィールドへの入力値として渡すための命令になる。ある点では、これは問合せと部分問合せ間の関係に概念的に類似している。しかし、本発明のドラグアンドドロップ・チャンネルはそれ以上の機能性を提供する。すなわち、ドラグアンドドロップ・チャンネルは、
・ユーザーが複合問合せを動的かつ増分的（インクリメンタル）に生成することを可能にする、問合せ間の生きたリンク、
・ユーザーがドラグアンドドロップした属性値を問合せの文脈に自動的に適応させることを可能にする計算変換、および
・ユーザーがドラグアンドドロップ・チャンネルに沿って渡した値をフィルタするのを可能にする、サーチプロセスへのユーザー介入の区切り点（ブレーク点）
を提供する。
【００２４】
問合せ間の生きたリンクは、ユーザーが複合問合せを動的かつインクリメンタルに生成することを可能にする。ユーザーは、複雑な問合せを送り出すことに関して、演繹的にばかりでなく帰納的に問合せ間にドラグアンドドロップ・チャンネルを導入することができる。
【００２５】
複合問合せの定義は、通常、たとえば構造化問合せ言語(SQL: Structured Query Language)で、演繹的に行わなければならない。ユーザーがすべての複雑な問合せを定義し、全複合問合せを送り出す前にそれらをリンクするには、ユーザーは、どのように幾つかの問合せをリンクしてサーチしているものを得るかを前もって知っていなければならない。
【００２６】
しかし、これは、必ずしも複合問合せを生成する現実的なやり方ではない。問合せの結果を点検することによって、それらをどのように使用するかについて新しい着想を思いつくことが多い。しかし、もし問合せを動的に組み合せることができれば、既に得た問合せ結果を入力として別の問合せに使用することができる。これはドラグアンドドロップ・チャンネルによって可能である。ソース問合せが既に（かつ連続的に）ランしている場合、ドラグアンドドロップ・チャンネルは帰納的に確立することができる。この帰納的操作は、問合せ結果を連続的に蓄積することができる（すなわち、新しいドキュメントが問合せドメイン内に置かれた結果、問合せ結果を連続的に送り戻すことができる）情報検索システムに設けられたフィーチャの結果、使用可能にされる。
【００２７】
もしドラグアンドドロップ・チャンネルが帰納的に導入されれば、既に存在する結果が直ちに目標問合せへ送られる。いずれにせよ、ドラグアンドドロップ・チャンネルの導入後に到着するすべての結果は、それらが到着すると送り出される。
【００２８】
計算変換は、ドラグアンドドロップした属性値を問合せの文脈へ自動的に適応させるため行われる。ドラグアンドドロップ・チャンネルのソース属性からその目標属性へ値を渡すことは、必ずしも即座に可能とは限らない。もしソース属性と目標属性が同じタイプ、アリティ(arity)、または単位を有していなければ、あるいはリンクされた問合せの全般的文脈が違っていれば、問題が起きる。計算変換は問合せ間の値の受渡しを可能にするために必要である。以下に計算変換の例を示す。
【実施例】
【００２９】
例（属性タイプ統合）
整数属性を文字列属性の上にドロップする場合には、出力属性フィールドの整数値を入力属性フィールドへの文字列値へ変換しなければならない。
【００３０】
例（属性アリティ(arity)統合）
リンクされた属性のアリティが同じでない場合には、特にドラグアンドドロップ・チャンネルのソース属性が値のリストを含んでいて、目標属性が単一値を予定している場合には、それらの単一値を目標問合せへ渡すことができる前に、それらをリストから抽出しなければならない。たとえば、それらの値が（見つけた論文のすべての共同著者で構成される）名前リストを含んでいる属性を単一名前を予定している属性の上にドロップする場合には（たとえば、個人のホームページをサーチするために）、最初に著者の姓を抽出し、次にそれらを入力属性フィールドへ１つづつ渡さなければならない。
【００３１】
例（属性単位統合）
ソース属性と目標族生の単位が違っている場合には、ドロップする値を自動的に計算することができる。たとえば、１ｋｍを１０００ｍへ変換するには１０００を掛ける、あるいは１分を１／６０時間へ変換するには６０で割る。
【００３２】
例（言語統合）
また、リンクされた問合せ、たとえばそれらの言語の他の特徴によって、変換を決定することができる。各問合せごとに言語が定義されており（または、言語がたとえば言語推測法によって推論することができ）、かつ異なる言語の２つの問合せがリンクされている場合には、変換は、たとえばソース問合せの言語から目標問合せの言語へ値を翻訳することである。そのようなさまざまな言語にかかわる情報検索を実行するやり方は、係属中の米国特許出願（発明の名称“System For Providing Cross-Lingual Information Retrieval”）(出願番号はまだ付されていない)に記載されている。
【００３３】
もしシステムがソース属性と目標属性および問合せの特徴を知ったならば、上記の計算変換を自動的に導入することができる。さもなければ、それらをユーザーが定義することができる。
【００３４】
ドラグアンドドロップ・チャンネルは、サーチプロセスへのユーザー介入の可能な区切り点を設置する。実際には、ユーザーはドラグアンドドロップ・チャンネルのソース属性に関して見つけたすべての値を自動的にその目標属性へ渡すことを望まないことが多い。その代わりに、ユーザーはこのプロセスを制御し、値を手動でフィルタすることを望む。従って、ドラグアンドドロップ・チャンネルは自動的に制御することもできるし、ユーザーが制御することもできる。ユーザーは、各ドラグアンドドロップ・チャンネルごとに、値が自動的に渡るようにするか、ユーザーが値をフィルタすることを望むかを特定することができる。
【００３５】
ソース問合せの問合せ結果の精度が低い場合には、すなわち問合せ結果の中の多くのドキュメントが次の問合せへの入力として使用するのに適当でない場合には、これは特に役に立つ。もしすべての不適当な値が自動的に次のサーチへ渡されれば、複合問合せの最終結果の精度は非常に低くなるであろう。したがって、ドラグアンドドロップ・チャンネルをユーザー制御にすることにより、ユーザーは最終結果の精度を高めることができる。さらに、それは渡された値によって生成される問合せの数を減らすので、サーチプロセスの効率が向上する。
【００３６】
ユーザーフィルタリング点としてドラグアンドドロップ・チャンネルの使用は、さらに、帰納的に導入されたドラグアンドドロップ・チャンネルの機能性を拡張する。すなわち、ソース属性を目標属性の上にドラグすることによってドラグアンドドロップ・チャンネルを確立する前に、ユーザーは一定の不適当な結果すなわち属性値を隠すことを望むかもしれない。これは帰納的フィルタリングに相当する。ゆえに、後で確立されたドラグアンドドロップ・チャンネルはユーザーが制御するドラグアンドドロップ・チャンネルである。
【００３７】
図６および図７は、問合せ間のチャンネルがどのように生成されるかを示す例示画面表示である。図６を参照すると、問合せ１（符号６０１）の「著者」（author）属性６１１は問合せ４（符号６０４）にリンクされている。ここで、問合せ２（符号６０２）の著者属性６１２も同様に問合せ４の属性としてリンクしなければならない。ハイライトで示すように、著者属性はドラグアンドドロップ・ユーザーインタフェース操作によって選択されたあと、移動中である。図７はその結果を示す。問合せ４（符号６０４）はこのとき、さらに問合せ４（符号６０４）の属性として含まれる問合せ２（符号６０２）の著者属性６１２の結果を含んでいる。
【００３８】
図８は、問合せ間のチャンネルの動作特性を特定するためのインタフェースを示す例示画面表示である。図８について説明すると、問合せ２をもつチャンネルが選択されており、ポップアップ制御ウィンドウ８００を表示するためマウスのダブルクリックなどのユーザーインタフェース動作が行われたと仮定する。このポップアップ制御ウィンドウは、チャンネルについて種々の制御フィーチャを選択するために使用される。たとえば、第１選択領域８０１は、属性問合せ結果を自動転送するか、ユーザー制御転送するかを選択できるチェックボックス８０１と８０２を有する。これは、目標問合せ（この場合は、問合せ４）の中に区切り点を導入することができるやり方である。
【００３９】
第２選択領域８０６は、もし目標問合せ文脈内にあるように属性結果を自動的に変換することが望ましければ、それを特定するため使用されるチェックボックス８０４を有する。ここでは、変換はソース問合せ文脈と目標問合せ文脈に基づいて自動的に識別される（８０５）（たとえば、問合せ２はListフォーマット内の著者情報を検索するのに対し、問合せ４は単一名前フォーマット内の著者情報を検索する）。上に述べたことは、リンクの動作特性をどのように特定することができるかの１つのやり方であり、本発明の範囲を限定するものではない。他のやり方は、たとえばチャンネルに対応付けられた制御チェックボックスを介して使用することができるであろうし、それは本発明の精神および範囲から逸脱しないであろう。
【００４０】
図６〜図８に示したユーザーインタフェースは、一般に、図１に示したように、デマンドエージェントを介してユーザーに提供されることに留意すべきである。
【００４１】
図９は、問合せ間のチャンネルの関係を示す複雑な問合せのためのデータ構造の例である。簡単な問合せは、一般に図９に記載された部分問合せの１つの中に見られる構造を有することに留意すべきである。とにかく、図９について説明すると、行９０１〜９０５は問合せの部分を定義している。この場合には、２つの計算変換と一緒に、３つの部分問合せが定義されている。問合せ１の定義は、行９０６で始まり、行９１６で終る。これらの行から、問合せ１が“computer science”のドメインと、題名が文字列“database systems”を含んでいる問合せ属性と、問合せによってフィルインされる著者の問合せ属性とを有することがわかる。タイプ“nameExtraction”の計算変換は、著者属性の内容について実行され、“A11”として示したロケーションに格納される（行９１１〜９１６）。
【００４２】
問合せ２の定義は行９１７で始まる。問合せ２のドメインは“computer science”であり、題名はその中にワード“constraints”を持たなければならない。問合せ２の場合、著者属性は問合せ１において見つけたと同じ計算変換を受ける（行９２２〜９２６）。
【００４３】
最後に、問合せ３は行９２７で始まる。問合せ３の場合、ドメインは“computer science”であり、著者属性は問合せ１と２の著者属性の結果を含んでいる。
これこそが、問合せ３と各問合せ１と２の間に確立されたチャンネルである。
【００４４】
一般に、図９のデータ構造は図１に示したようにブローカーエージェントによって翻訳される。
【００４５】
次に図１０を参照して、本発明の好ましい実施例をその上に具体化することができるコンピュータベースシステムについて説明する。たとえば、コンピュータベースシステム１０はユーザーシステム（その上でデマンドエージェントが実行する）と、ユーザーに提供されるユーザーインタフェースを取り入れることができる、あるいはサーバーシステム（そこでは、種々のブローカエージェントやサプライエージェントが実行する）であってもよい。とにかく、図１０について説明すると、コンピュータベースシステムはバス１００１を介して結合された複数の構成要素を備えている。図示したバス１００１は本発明を明確にするため単純化してある。バス１００１は、バスの階層（たとえば、プロセッサバス、ローカルバス、および入出力バス）のほかに、複数の並列バス（たとえば、アドレスバス、データバス、および状態バス）から成っていてもよい。いずれにしても、コンピュータベースシステムは、さらに、バス１００１を介して内部メモリ１００３から与えられた命令を実行するプロセッサ１００２を備えている（内部メモリ１００３は、一般にＲＡＭまたはＲＯＭの組合せである）。プロセッサ１００２と内部メモリＲＯＭ１００３は、個別構成要素、または本発明の機能的フィーチャを取り入れるように設計された特定用途向け集積回路(ASIC)チップのような単一集積デバイスであってもよい。
【００４６】
そのほかに、バス１００１には、英数入力を入力するためのキーボード１００４、データを格納するための外部記憶装置１００５、カーソルを操作するためのカーソル制御装置１００６、および可視出力を表示するためのディスプレイ１００７が結合されている。キーボード１００４は一般に標準のＱＷＥＲＴＹキーボードであるが、電話に似たキーパッドであってもよい。外部記憶装置１００５は固定型または可動型磁気ディスクドライブまたは光ディスクドライブであってもよい。カーソル制御装置１００６は一般に一定の機能の実行をプログラムすることができる対応付けられたボタンまたはスイッチを備えている。ネットワーク接続１００８は、媒体のビットマップ表現を含むデータを受信し、送信し、またはその両方を行うために使用される。
【符号の説明】
【００４７】
１０１ ユーザー
１０２ デマンドエージェント
１０３ ブローカエージェント
１０４ 部分問合せ
１０５ サプライエージェント
１０６ サーチエンジン
２００ 問合せウィンドウ
２０１ ドメイン領域
２０２ 所定属性特定領域
２０３ 制約特定領域
２０４ 所望キーワード特定領域
２０５ 追加ボタン
２０６ 仕様領域
２０７ リセットボタン
２０８ サーチパターン編集ボタン
２０９ サーチパターン除去ボタン
２１０ 全仕様クリヤボタン
２１１ 部分問合せ取消しボタン
２１２ 問合せ提出制御ボタン
２１３ 問合せ取消し制御ボタン
３０１ 新しいタブ
５０１ ドキュメントのテキスト内容を示す本体領域
５０２ 情報領域
５０３ PREVIOUSボタン
５０４ NEXTボタン
６０１，６０２，６０４ 問合せ
６１１，６１２ 「著者」属性
８００ ポップアップ制御ウィンドウ
８０１ 第１選択領域
８０２，８０３，８０４ チェックボックス
８０６ 第２選択領域
１００１ バス
１００２ プロセッサ
１００３ 内部メモリ
１００４ キーボー
１００５ 外部記憶装置
１００６ カーソル制御装置
１００７ ディスプレイ
１００８ ネットワーク接続
【技術分野】
【０００１】
本発明は、データベースなどの情報リポジトリのサーチ、より詳細には動的問合せを生成し、構成する組み立てる機構（ファシリティ）に関する。
【背景技術】
【０００２】
イントラネットで異種レガシー・データベースにアクセスするとき、あるいはインターネットで多数の情報ソースに問合せをするとき、エンドユーザーは簡単な直接的なアクセスポイントをもつことだけを望んでいる。
【０００３】
典型的な情報検索（retrieval＝リトリーバル）アーキテクチャが、論文“System Components for Embedded Information Retrieval Form Multiple Disparate Information Sources”, Ramana B. Rao, Daniel M. Russell, and Jock D. Mackinlay, Proceedings of 1993 ACM Symposium on User Interface Software and Technology, Atlanta, GA, November 1993 ACM SIGGRAPH and SIGCHI に記載されている。情報検索アーキテクチャは情報アクセス・クライアント（すなわちユーザー）と種々の情報ソース間のアクセス要求を調停する中間サーバーを組み入れている。従って、ユーザーは、多数の情報ソースから情報を検索するために単に情報アクセス・クライアントにインタフェースする必要があるだけである。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】“System Components for Embedded Information Retrieval Form Multiple Disparate Information Sources”, Ramana B. Rao, Daniel M. Russell, and Jock D. Mackinlay, Proceedings of 1993 ACM Symposium on User Interface Software and Technology, Atlanta, GA, November 1993 ACM SIGGRAPH and SIGCHI
【発明の概要】
【発明が解決しようとする課題】
【０００５】
情報検索におけるもう１つの問題は問合せの生成である。有効な問合せを生成するプロセスは対話型のものが多い。そのようなプロセスの場合、ある問合せの結果を使用して、より狭い範囲の第２の問合せが作られることが多い。これが起きる理由は、最初の問合せの範囲が広過ぎたためかもしれないし、また大量の使用できないデータまたは冗長なデータが戻されたからかもしれない。また、既知の問合せシステムは本質的に「静的」である。言い換えると、問合せを始めるには、すべての問合せ項目を固定しなければならない。しかし、ＷＷＷ上で膨大な情報を常時入手可能になったので、問合せは、本質上、より動的にすることが望ましいであろう。さらに、情報リポジトリは本質的に異なるので、問合せの部分が並列にランしていることがある。従って、サーチ項目が静的でないように、本質上動的である問合せを特定し、実行することができることが望ましい。
【課題を解決するための手段】
【０００６】
本発明は、ネットワークでアクセス可能な分散型ベータベース、たとえばインターネット上で見られるようなデータベースのサーチに関するものである。問合わせの組合せを可能にするドラグアンドドロップサーチチャンネルが記述されている。問合わせはコンピュータシステムのディスプレイに問合わせウィンドウとして視覚的に表示される。問合わせウィンドウ上で、意図した問合わせの特質および範囲を定義する属性を入力することができる。属性を論理的に組み合せて、意図した問合せを生成することができる。各属性の仕様（または明細：specification）はオブジェクトとして表現される。ユーザーは、最初の問合せの属性を第２の問合せの属性として含めるように属性を選択する。それにより、属性の図的表現が生成される。次に、ユーザーはその属性の図的表現を第２問合せの属性仕様領域へ「ドラグアンドドロップ」する。その結果、２つの問合せの間に、以下に説明するプロパティをもつことができる通信チャンネルが確立される。
【０００７】
ドラッグアンドドロップサーチチャンネルは計算変換（Computational Transformation）を行う。計算変換は、チャンネルに対応付けられた結果を問合せの文脈（コンテキスト）に自動的に適応させることを考慮に入れている。
【０００８】
ドラグアンドドロップサーチチャンネルは、さらに複合問合せを動的および増分的（インクリメンタル）に生成する能力を提供し、さらにユーザーがサーチ結果を作用させて、手動でフィルタすることができるように区切り点（ブレークポイント）を提供する。
【図面の簡単な説明】
【０００９】
【図１】本発明の好ましい実施例の情報検索システムの構成要素と処理の流れを示すブロック図である。
【図２】本発明の好ましい実施例において使用することができる簡単な問合せウィンドウを示す図である。
【図３】本発明の好ましい実施例において使用することができる複雑な問合せウィンドウを示す図である。
【図４】本発明の好ましい実施例において使用することができる簡単な結果ウィンドウを示す図である。
【図５】本発明の好ましい実施例において使用することができる複雑な結果ウィンドウを示す図である。
【図６】本発明の好ましい実施例において実施することができる、問合せ間のチャンネル生成の例をサンプル画面表示で示した図である。
【図７】図６と同様なサンプル画面表示で示した図である。
【図８】本発明の好ましい実施例において実施することができる、計算変換すなわち問合せ間のチャンネル内の区切り点を特定するユーザーインタフェースをサンプル画面表示で示した図である。
【図９】本発明の好ましい実施例において使用することができる、問合せ間のチャンネル関係を示すために使用される複雑な問合せのデータ構造を示す図である。
【図１０】本発明の好ましい実施例を実施するため使用することができるコンピュータベースシステムを示す図である。
【発明を実施するための形態】
【００１０】
本発明は、１つまたはそれ以上の情報ソースへ問合せを生成して、その１つまたはそれ以上の情報ソースから情報を検索（リトリーバル）するインタフェースに向けられている。本発明の好ましい実施例は、多数の異種データベースに問い合せ、情報を再構成し、カスタマイズされたリポートを生成することができるソフトウェアエージェントを備えた情報検索システムの中に具体化されている。以下、情報検索システムについて説明するが、米国出願時現在のより包括的な説明は、
WWW (URL http://www.xrce.xerox.com/research/ct/rsearch/cbkb.html) 上で見ることができる。
【００１１】
本発明は、複雑な動的問合せを構成する機構（ファシリティ）を提供することによって情報検索システムを構築する。複雑な動的問合せは、問合せの属性の仕様（specification）が静的でなく動的であるので、ある問合せの結果（または部分的結果）は別の問合せによって属性仕様として使用することができる。さらに、前記機能は、周知のドラグアンドドロップ-グラフィックユーザーインタフェース法を使用して非常に直観的なやり方でユーザーが利用できるようになっている。
【００１２】
本発明の好ましい実施例は、適当なJava(登録商標)使用可能ウェブブラウザを使用してWWW(ウェブ)にアクセスすることができるコンピュータベースのシステム上で使用するように具体化されている。具体化に使用した種々のソフトウェアプログラムは周知のJavaプログラミング言語で書かれている。
【００１３】
WWW上の電子的ソースまたは他のオンライン情報リポジトリから入手できる情報量は指数関数的に増えている。これらのリポジトリから関連情報を抽出するにはツールが必要である。情報検索システムは情報を効率的に検索し、組み合わせる機能を洗練化した。図１は、情報検索システムにおいて情報がどのように処理されるかを示す。図１を参照すると、ユーザー１０１は、デマンドエージェント１０２を介して情報を要求する。デマンドエージェント１０２は、一般に、ユーザーに提供されるユーザーインタフェースを取り入れている。好ましい実施例の場合、デマンドエージェント１０２は、Java Applet（登録商標）である。Java Appletは、ユーザーのパーソナルコンピュータシステムにダウンロードされ、適切に構成されたウェブブラウザ（たとえば、適当なJava（登録商標）ソフトウェア機能をもつNetscape Navigator(登録商標)）を使用してアクセスできる。
【００１４】
次に、デマンドエージェント１０２は、情報要求を、ブローカーエージェント１０３へ送る。ブローカーエージェント１０３は、情報要求を、相互依存性のサブリクエストに分解する。それ以上分解することができない要求すなわちサブリクエスト１０４は、サーチエンジン１０６を介して電子情報リポジトリにアクセスするサプライエージェント１０５へ送られる。サプライエージェント１０５は一般に特定のサーチエンジン１０６のプロトコルを使用してインタフェースするように構成されるであろう。たとえば、Alta Vista(登録商標)サーチエンジンにインターフェースし、要求を行うためにサプライエージェント１０５を設けることができる。好ましい実施例の場合、ブローカーエージェントとサプライエージェントは情報検索を行うサーバーシステム上で動作するであろう。
【００１５】
情報検索の結果はブローカーエージェント１０３によって受け取られ、そのあと再構成（re-composition）される。情報検索システムは、いくつかの情報ソースによっては提供されない、進歩した問合せ機構をユーザーに提供しており、これによって、前記の再構成が、結果をフィルタすることを含み、この進歩した問合せ機構を使用可能にすることに留意されたい。再構成は、さらに、受け取った情報をフォーマット化すること、および／または問合せ要求に関する結果をランク付けすることなどの諸タスクを含んでいることがある。再構成が終了すると直ちに、結果がデマンドエージェント１０２へ戻され、ユーザー１０１に提供される。
【００１６】
要求、情報および結果は、フィーチャ制約（feature constraints）で表すことが好ましいことに留意すべきである。要求は完全に定義する必要がない。すなわち、要求は要求する情報の部分的な仕様と対応することがあるからである。さらに、完全に満たすことができない要求は、その属性の一部を例示することによって、または新しい属性を追加する、つまりユーザーフィードバックを行うことによって、最初の要求を精緻にする部分オブジェクトの形で結果を得ることができる。
【００１７】
情報検索システムの種々の態様は、以下の国際公開公報 WO 98/48359(29 October 1998)およびWO 98/48361(29 October 1998)の中に見つけることができる。
【００１８】
上に述べた々のエージェントはそれぞれ適切に構成されたコンピュータベースシステムにおいて実行するJavaプログラミング言語で書かれたソフトウェアプログラムとして取り入れることが好ましい。
【００１９】
図２は、問合せを特定（または指定）するための問合せウィンドウを示す。図２を参照すると、問合せウィンドウ２００のドメイン領域２０１は問合せに対し複数の所定ドメインの１つを特定する手段となる。問合せドメインはサーチしようとする情報の種類に関連がある。たとえば、問合せドメインはドキュメントの種類（たとえば、書籍または論文）または主題領域（たとえば、物理学またはオペラ）であってもよい。好ましい実施例の場合、それらのドメインは前もって決定され、問合せが送られる１つまたはそれ以上の情報ソースに対応している。領域２０２〜２０４はサーチパターンを特定するために設けられている。領域２０２は所定の属性（たとえば、題名または著者）を特定するためにある。領域２０３は属性および特定されたキーワードに課すべき制約（たとえば、含んでいる、または厳密に一致する）を特定するためにある。領域２０４は所望のキーワードを特定するためにあり、キーワードとブール演算子で作られる表現を定義することができる。もしサーチパターンが正しければ、“ADD TO SPECIFICATION”のラベルが付いたボタン２０５を押すと、仕様領域２０６に示すように、現在の問合せ仕様にそのパターンが追加される。もしサーチパターンが正しくなければ、リセットボタン２０７を使用してリセットすることができる。仕様領域２０６はユーザーによって特定されたすべての所望のサーチパターンを含んでいる。
【００２０】
ボタン２０８〜２１１は仕様を編集するために設けられている。ボタン２０８は選択したサーチパターンを編集するためにある。ボタン２０９はサーチパターンを削除する手段となる。ボタン２１０は、全仕様をクリヤする手段となる。ボタン２１１は、部分問合せ（SUBQUERY）を取り消すためにある。最後に、ボタン２１２と２１３はそれぞれ、問合せの提出と取消しの制御のために設けられている。
【００２１】
図３は、問合せ内の部分問合せ、すなわち複雑な問合せを実行するためのウィンドウを示す。複雑な問合せの場合、部分問合せは一組の部分結果を生成する。生成された結果は、それらが主問合せ（一般に、より高いレベルの問合せ）の問合せパターン内に使用される値を引き渡すという意味で、部分結果である。部分問合せは、領域２０３内の所定のオプション（すなわち、オプションの「応答」を選択することによって提供される。これにより、図３のウィンドウが表示される。図３から判るように、部分問合せであることを指示する新しいタブ３０１が含まれている。このタブ３０１により、ユーザーは主問合せと部分問合せとの間で移動することができる。部分問合せの残部は主問合せに類似していることに留意されたい。
【００２２】
図４と図５は、それぞれ、サーチからの結果ウィンドウの要約図と詳細図を示す。図４の要約図は、すべてのヒットのリストと、ヒット数のような一定の全体的要約情報を示す。図５には、個々の「ヒット」に関係するすべての情報フィールドが表示される。本体領域５０１は、ドキュメントのテキスト内容を示す。情報領域５０２はデータ、ＵＲＬロケーション、情報ソース、サイズ、題名などの種々の情報を提供する。この図の場合、ヒットのリストを前後に閲覧（すなわちトラバース）するため、ウィンドウの中には、PREVIOUSボタン５０３とNEXTボタン５０４とが設けられている。
【００２３】
２つの問合せ間にドラグアンドドロップ・チャンネルを確立することは、ソース問合せの属性フィールドに戻された応答を、目標問合せの属性フィールドへの入力値として渡すための命令になる。ある点では、これは問合せと部分問合せ間の関係に概念的に類似している。しかし、本発明のドラグアンドドロップ・チャンネルはそれ以上の機能性を提供する。すなわち、ドラグアンドドロップ・チャンネルは、
・ユーザーが複合問合せを動的かつ増分的（インクリメンタル）に生成することを可能にする、問合せ間の生きたリンク、
・ユーザーがドラグアンドドロップした属性値を問合せの文脈に自動的に適応させることを可能にする計算変換、および
・ユーザーがドラグアンドドロップ・チャンネルに沿って渡した値をフィルタするのを可能にする、サーチプロセスへのユーザー介入の区切り点（ブレーク点）
を提供する。
【００２４】
問合せ間の生きたリンクは、ユーザーが複合問合せを動的かつインクリメンタルに生成することを可能にする。ユーザーは、複雑な問合せを送り出すことに関して、演繹的にばかりでなく帰納的に問合せ間にドラグアンドドロップ・チャンネルを導入することができる。
【００２５】
複合問合せの定義は、通常、たとえば構造化問合せ言語(SQL: Structured Query Language)で、演繹的に行わなければならない。ユーザーがすべての複雑な問合せを定義し、全複合問合せを送り出す前にそれらをリンクするには、ユーザーは、どのように幾つかの問合せをリンクしてサーチしているものを得るかを前もって知っていなければならない。
【００２６】
しかし、これは、必ずしも複合問合せを生成する現実的なやり方ではない。問合せの結果を点検することによって、それらをどのように使用するかについて新しい着想を思いつくことが多い。しかし、もし問合せを動的に組み合せることができれば、既に得た問合せ結果を入力として別の問合せに使用することができる。これはドラグアンドドロップ・チャンネルによって可能である。ソース問合せが既に（かつ連続的に）ランしている場合、ドラグアンドドロップ・チャンネルは帰納的に確立することができる。この帰納的操作は、問合せ結果を連続的に蓄積することができる（すなわち、新しいドキュメントが問合せドメイン内に置かれた結果、問合せ結果を連続的に送り戻すことができる）情報検索システムに設けられたフィーチャの結果、使用可能にされる。
【００２７】
もしドラグアンドドロップ・チャンネルが帰納的に導入されれば、既に存在する結果が直ちに目標問合せへ送られる。いずれにせよ、ドラグアンドドロップ・チャンネルの導入後に到着するすべての結果は、それらが到着すると送り出される。
【００２８】
計算変換は、ドラグアンドドロップした属性値を問合せの文脈へ自動的に適応させるため行われる。ドラグアンドドロップ・チャンネルのソース属性からその目標属性へ値を渡すことは、必ずしも即座に可能とは限らない。もしソース属性と目標属性が同じタイプ、アリティ(arity)、または単位を有していなければ、あるいはリンクされた問合せの全般的文脈が違っていれば、問題が起きる。計算変換は問合せ間の値の受渡しを可能にするために必要である。以下に計算変換の例を示す。
【実施例】
【００２９】
例（属性タイプ統合）
整数属性を文字列属性の上にドロップする場合には、出力属性フィールドの整数値を入力属性フィールドへの文字列値へ変換しなければならない。
【００３０】
例（属性アリティ(arity)統合）
リンクされた属性のアリティが同じでない場合には、特にドラグアンドドロップ・チャンネルのソース属性が値のリストを含んでいて、目標属性が単一値を予定している場合には、それらの単一値を目標問合せへ渡すことができる前に、それらをリストから抽出しなければならない。たとえば、それらの値が（見つけた論文のすべての共同著者で構成される）名前リストを含んでいる属性を単一名前を予定している属性の上にドロップする場合には（たとえば、個人のホームページをサーチするために）、最初に著者の姓を抽出し、次にそれらを入力属性フィールドへ１つづつ渡さなければならない。
【００３１】
例（属性単位統合）
ソース属性と目標族生の単位が違っている場合には、ドロップする値を自動的に計算することができる。たとえば、１ｋｍを１０００ｍへ変換するには１０００を掛ける、あるいは１分を１／６０時間へ変換するには６０で割る。
【００３２】
例（言語統合）
また、リンクされた問合せ、たとえばそれらの言語の他の特徴によって、変換を決定することができる。各問合せごとに言語が定義されており（または、言語がたとえば言語推測法によって推論することができ）、かつ異なる言語の２つの問合せがリンクされている場合には、変換は、たとえばソース問合せの言語から目標問合せの言語へ値を翻訳することである。そのようなさまざまな言語にかかわる情報検索を実行するやり方は、係属中の米国特許出願（発明の名称“System For Providing Cross-Lingual Information Retrieval”）(出願番号はまだ付されていない)に記載されている。
【００３３】
もしシステムがソース属性と目標属性および問合せの特徴を知ったならば、上記の計算変換を自動的に導入することができる。さもなければ、それらをユーザーが定義することができる。
【００３４】
ドラグアンドドロップ・チャンネルは、サーチプロセスへのユーザー介入の可能な区切り点を設置する。実際には、ユーザーはドラグアンドドロップ・チャンネルのソース属性に関して見つけたすべての値を自動的にその目標属性へ渡すことを望まないことが多い。その代わりに、ユーザーはこのプロセスを制御し、値を手動でフィルタすることを望む。従って、ドラグアンドドロップ・チャンネルは自動的に制御することもできるし、ユーザーが制御することもできる。ユーザーは、各ドラグアンドドロップ・チャンネルごとに、値が自動的に渡るようにするか、ユーザーが値をフィルタすることを望むかを特定することができる。
【００３５】
ソース問合せの問合せ結果の精度が低い場合には、すなわち問合せ結果の中の多くのドキュメントが次の問合せへの入力として使用するのに適当でない場合には、これは特に役に立つ。もしすべての不適当な値が自動的に次のサーチへ渡されれば、複合問合せの最終結果の精度は非常に低くなるであろう。したがって、ドラグアンドドロップ・チャンネルをユーザー制御にすることにより、ユーザーは最終結果の精度を高めることができる。さらに、それは渡された値によって生成される問合せの数を減らすので、サーチプロセスの効率が向上する。
【００３６】
ユーザーフィルタリング点としてドラグアンドドロップ・チャンネルの使用は、さらに、帰納的に導入されたドラグアンドドロップ・チャンネルの機能性を拡張する。すなわち、ソース属性を目標属性の上にドラグすることによってドラグアンドドロップ・チャンネルを確立する前に、ユーザーは一定の不適当な結果すなわち属性値を隠すことを望むかもしれない。これは帰納的フィルタリングに相当する。ゆえに、後で確立されたドラグアンドドロップ・チャンネルはユーザーが制御するドラグアンドドロップ・チャンネルである。
【００３７】
図６および図７は、問合せ間のチャンネルがどのように生成されるかを示す例示画面表示である。図６を参照すると、問合せ１（符号６０１）の「著者」（author）属性６１１は問合せ４（符号６０４）にリンクされている。ここで、問合せ２（符号６０２）の著者属性６１２も同様に問合せ４の属性としてリンクしなければならない。ハイライトで示すように、著者属性はドラグアンドドロップ・ユーザーインタフェース操作によって選択されたあと、移動中である。図７はその結果を示す。問合せ４（符号６０４）はこのとき、さらに問合せ４（符号６０４）の属性として含まれる問合せ２（符号６０２）の著者属性６１２の結果を含んでいる。
【００３８】
図８は、問合せ間のチャンネルの動作特性を特定するためのインタフェースを示す例示画面表示である。図８について説明すると、問合せ２をもつチャンネルが選択されており、ポップアップ制御ウィンドウ８００を表示するためマウスのダブルクリックなどのユーザーインタフェース動作が行われたと仮定する。このポップアップ制御ウィンドウは、チャンネルについて種々の制御フィーチャを選択するために使用される。たとえば、第１選択領域８０１は、属性問合せ結果を自動転送するか、ユーザー制御転送するかを選択できるチェックボックス８０１と８０２を有する。これは、目標問合せ（この場合は、問合せ４）の中に区切り点を導入することができるやり方である。
【００３９】
第２選択領域８０６は、もし目標問合せ文脈内にあるように属性結果を自動的に変換することが望ましければ、それを特定するため使用されるチェックボックス８０４を有する。ここでは、変換はソース問合せ文脈と目標問合せ文脈に基づいて自動的に識別される（８０５）（たとえば、問合せ２はListフォーマット内の著者情報を検索するのに対し、問合せ４は単一名前フォーマット内の著者情報を検索する）。上に述べたことは、リンクの動作特性をどのように特定することができるかの１つのやり方であり、本発明の範囲を限定するものではない。他のやり方は、たとえばチャンネルに対応付けられた制御チェックボックスを介して使用することができるであろうし、それは本発明の精神および範囲から逸脱しないであろう。
【００４０】
図６〜図８に示したユーザーインタフェースは、一般に、図１に示したように、デマンドエージェントを介してユーザーに提供されることに留意すべきである。
【００４１】
図９は、問合せ間のチャンネルの関係を示す複雑な問合せのためのデータ構造の例である。簡単な問合せは、一般に図９に記載された部分問合せの１つの中に見られる構造を有することに留意すべきである。とにかく、図９について説明すると、行９０１〜９０５は問合せの部分を定義している。この場合には、２つの計算変換と一緒に、３つの部分問合せが定義されている。問合せ１の定義は、行９０６で始まり、行９１６で終る。これらの行から、問合せ１が“computer science”のドメインと、題名が文字列“database systems”を含んでいる問合せ属性と、問合せによってフィルインされる著者の問合せ属性とを有することがわかる。タイプ“nameExtraction”の計算変換は、著者属性の内容について実行され、“A11”として示したロケーションに格納される（行９１１〜９１６）。
【００４２】
問合せ２の定義は行９１７で始まる。問合せ２のドメインは“computer science”であり、題名はその中にワード“constraints”を持たなければならない。問合せ２の場合、著者属性は問合せ１において見つけたと同じ計算変換を受ける（行９２２〜９２６）。
【００４３】
最後に、問合せ３は行９２７で始まる。問合せ３の場合、ドメインは“computer science”であり、著者属性は問合せ１と２の著者属性の結果を含んでいる。
これこそが、問合せ３と各問合せ１と２の間に確立されたチャンネルである。
【００４４】
一般に、図９のデータ構造は図１に示したようにブローカーエージェントによって翻訳される。
【００４５】
次に図１０を参照して、本発明の好ましい実施例をその上に具体化することができるコンピュータベースシステムについて説明する。たとえば、コンピュータベースシステム１０はユーザーシステム（その上でデマンドエージェントが実行する）と、ユーザーに提供されるユーザーインタフェースを取り入れることができる、あるいはサーバーシステム（そこでは、種々のブローカエージェントやサプライエージェントが実行する）であってもよい。とにかく、図１０について説明すると、コンピュータベースシステムはバス１００１を介して結合された複数の構成要素を備えている。図示したバス１００１は本発明を明確にするため単純化してある。バス１００１は、バスの階層（たとえば、プロセッサバス、ローカルバス、および入出力バス）のほかに、複数の並列バス（たとえば、アドレスバス、データバス、および状態バス）から成っていてもよい。いずれにしても、コンピュータベースシステムは、さらに、バス１００１を介して内部メモリ１００３から与えられた命令を実行するプロセッサ１００２を備えている（内部メモリ１００３は、一般にＲＡＭまたはＲＯＭの組合せである）。プロセッサ１００２と内部メモリＲＯＭ１００３は、個別構成要素、または本発明の機能的フィーチャを取り入れるように設計された特定用途向け集積回路(ASIC)チップのような単一集積デバイスであってもよい。
【００４６】
そのほかに、バス１００１には、英数入力を入力するためのキーボード１００４、データを格納するための外部記憶装置１００５、カーソルを操作するためのカーソル制御装置１００６、および可視出力を表示するためのディスプレイ１００７が結合されている。キーボード１００４は一般に標準のＱＷＥＲＴＹキーボードであるが、電話に似たキーパッドであってもよい。外部記憶装置１００５は固定型または可動型磁気ディスクドライブまたは光ディスクドライブであってもよい。カーソル制御装置１００６は一般に一定の機能の実行をプログラムすることができる対応付けられたボタンまたはスイッチを備えている。ネットワーク接続１００８は、媒体のビットマップ表現を含むデータを受信し、送信し、またはその両方を行うために使用される。
【符号の説明】
【００４７】
１０１ ユーザー
１０２ デマンドエージェント
１０３ ブローカエージェント
１０４ 部分問合せ
１０５ サプライエージェント
１０６ サーチエンジン
２００ 問合せウィンドウ
２０１ ドメイン領域
２０２ 所定属性特定領域
２０３ 制約特定領域
２０４ 所望キーワード特定領域
２０５ 追加ボタン
２０６ 仕様領域
２０７ リセットボタン
２０８ サーチパターン編集ボタン
２０９ サーチパターン除去ボタン
２１０ 全仕様クリヤボタン
２１１ 部分問合せ取消しボタン
２１２ 問合せ提出制御ボタン
２１３ 問合せ取消し制御ボタン
３０１ 新しいタブ
５０１ ドキュメントのテキスト内容を示す本体領域
５０２ 情報領域
５０３ PREVIOUSボタン
５０４ NEXTボタン
６０１，６０２，６０４ 問合せ
６１１，６１２ 「著者」属性
８００ ポップアップ制御ウィンドウ
８０１ 第１選択領域
８０２，８０３，８０４ チェックボックス
８０６ 第２選択領域
１００１ バス
１００２ プロセッサ
１００３ 内部メモリ
１００４ キーボー
１００５ 外部記憶装置
１００６ カーソル制御装置
１００７ ディスプレイ
１００８ ネットワーク接続
【特許請求の範囲】
【請求項１】
情報検索システムから１つまたはそれ以上の情報ソースからの情報を得る方法であって、
ａ）ユーザーは、第１問合せに関する１つまたはそれ以上の問合せの属性を特定するステップと、
ｂ）前記ユーザーは、第２問合せに関する属性の少なくとも１つが第１問合せからの問合せの属性の結果であるように、前記第２問合せを特定するステップと、
ｃ）前記情報検索システムは、第１問合せの結果を提供するステップと、
ｄ）前記情報検索システムは、第１問合せの結果から、特定した問合せの属性に関する結果を抽出するステップと、
ｅ）前記情報検索システムは、前記特定した問合せの属性に関する結果を前記第２問合せに関する結果として提供するステップと、
ｆ）前記情報検索システムは、ユーザーへ第２問合せの結果を提供するステップと、
から成ることを特徴とする方法。
【請求項２】
前記情報検索システムが前記特定した問合せの属性に関する結果を前記第２問合せに関する結果として提供するステップの前に、前記ユーザーは、計算変換が前記特定した問合せの属性に関する前記結果に対して実行されて、前記結果が、前記第二問合せの文脈に適応されることを特定するステップを実行し、前記システムは、結果が受信されるときに、前記計算変換を実行することを特徴とする請求項１に記載の方法。
【請求項３】
前記計算変換は、ソース言語から目標言語に翻訳することを特徴とする請求項２に記載の方法。
【請求項４】
前記計算変換は、属性の種類の統合であることを特徴とする請求項２に記載の方法。
【請求項５】
前記計算変換は、属性のアリティの統合であることを特徴とする請求項２に記載の方法。
【請求項６】
前記計算変換は、属性の単位の統合であることを特徴とする請求項２に記載の方法。
【請求項７】
前記情報検索システムが前記特定した問合せの属性に関する結果を前記第２問合せに関する結果として提供するステップの前に、前記ユーザーは、前記特定した問合せの属性に関する前記結果が、ユーザー制御されることを特定するステップを実行し、前記システムは、ユーザーが前記第二問合せに提供されるものから結果を除外できるようにすることを特徴とする請求項１に記載の方法。
【請求項１】
情報検索システムから１つまたはそれ以上の情報ソースからの情報を得る方法であって、
ａ）ユーザーは、第１問合せに関する１つまたはそれ以上の問合せの属性を特定するステップと、
ｂ）前記ユーザーは、第２問合せに関する属性の少なくとも１つが第１問合せからの問合せの属性の結果であるように、前記第２問合せを特定するステップと、
ｃ）前記情報検索システムは、第１問合せの結果を提供するステップと、
ｄ）前記情報検索システムは、第１問合せの結果から、特定した問合せの属性に関する結果を抽出するステップと、
ｅ）前記情報検索システムは、前記特定した問合せの属性に関する結果を前記第２問合せに関する結果として提供するステップと、
ｆ）前記情報検索システムは、ユーザーへ第２問合せの結果を提供するステップと、
から成ることを特徴とする方法。
【請求項２】
前記情報検索システムが前記特定した問合せの属性に関する結果を前記第２問合せに関する結果として提供するステップの前に、前記ユーザーは、計算変換が前記特定した問合せの属性に関する前記結果に対して実行されて、前記結果が、前記第二問合せの文脈に適応されることを特定するステップを実行し、前記システムは、結果が受信されるときに、前記計算変換を実行することを特徴とする請求項１に記載の方法。
【請求項３】
前記計算変換は、ソース言語から目標言語に翻訳することを特徴とする請求項２に記載の方法。
【請求項４】
前記計算変換は、属性の種類の統合であることを特徴とする請求項２に記載の方法。
【請求項５】
前記計算変換は、属性のアリティの統合であることを特徴とする請求項２に記載の方法。
【請求項６】
前記計算変換は、属性の単位の統合であることを特徴とする請求項２に記載の方法。
【請求項７】
前記情報検索システムが前記特定した問合せの属性に関する結果を前記第２問合せに関する結果として提供するステップの前に、前記ユーザーは、前記特定した問合せの属性に関する前記結果が、ユーザー制御されることを特定するステップを実行し、前記システムは、ユーザーが前記第二問合せに提供されるものから結果を除外できるようにすることを特徴とする請求項１に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１１−２３０３０（Ｐ２０１１−２３０３０Ａ）
【公開日】平成２３年２月３日（２０１１．２．３）
【国際特許分類】
【出願番号】特願２０１０−２０４４６８（Ｐ２０１０−２０４４６８）
【出願日】平成２２年９月１３日（２０１０．９．１３）
【分割の表示】特願平１１−３５３９６２の分割
【原出願日】平成１１年１２月１４日（１９９９．１２．１４）
【出願人】（５９６１７０１７０）ゼロックス コーポレイション (1,961)
【氏名又は名称原語表記】ＸＥＲＯＸ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公開日】平成２３年２月３日（２０１１．２．３）
【国際特許分類】
【出願日】平成２２年９月１３日（２０１０．９．１３）
【分割の表示】特願平１１−３５３９６２の分割
【原出願日】平成１１年１２月１４日（１９９９．１２．１４）
【出願人】（５９６１７０１７０）ゼロックス コーポレイション (1,961)
【氏名又は名称原語表記】ＸＥＲＯＸ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]