JP5617551B2 - 情報検索システム、情報収集装置、情報検索装置、情報収集方法、プログラムおよび記録媒体 - Google Patents

Description

本発明は、情報検索技術に関し、より詳細には、複数のデータソースに格納されたデータ群を横断的に検索するための情報検索システム、情報収集装置、情報検索装置、情報収集方法、プログラムおよび記録媒体に関する。

近年、紙媒体の電子化などによるペーパレス化も進み、官公庁や企業など組織においては、資料データ、顧客データ、製品データその他の業務で用いる種々の書類を電子データとして管理することが一般的となっている。一方、日々の業務に伴って大量の情報が生成されるため、このような大量に存在するデータ群の中から必要な情報を効率よく取り出すための情報検索技術の開発が望まれている。

官公庁や企業などの組織においては、種々の業務システムおよび業務データベースが混在し、これら異種のシステム間では、データソースのフォーマットが統一化されていないことも多い。したがって、企業が保持する情報を検索する、いわゆるエンタープライズ検索においては、このような異種データソースを横断的に精度高く検索することができる情報検索技術の開発が望まれている。

上述した情報検索に関連して、例えば特許第４０４２８３０号公報（特許文献１）は、ネットワーク上に分散したコンテンツ情報を収集し、検索サービスなどに再利用するホスト装置において、情報提供者の閲覧用文書の構造・形式に縛られることなく、サービス提供用データベースの構築を可能とすることを目的として、閲覧用情報と混在してコンテンツ属性情報が含まれる文書ファイルからコンテンツ属性情報を抽出する機能、抽出したコンテンツ属性情報について属性構造の正規化処理を行う機能、構造が正規化されたコンテンツ属性情報について、文字表現形式の正規化、数値表現の正規化処理を行う機能を設けるシステムを開示する。

上記特許文献１に開示される従来技術によれば、データソースである閲覧用文書中の属性および属性値に対して、閲覧時に利用する属性および属性値を正規化することにより、ユーザは、サービス提供用データベースの意図する形式で複数のデータソースを統一した観点で検索することが可能となる。

しかしながら、組織内のデータソースは、一般に、それぞれの特定用途に応じて設計されており、比較的用途が近似するデータソース群を統一した観点で検索可能とすると、便利な反面、データソース毎の特性に応じたきめ細やかな検索を行うことができなくなってしまう。したがって、データベース間で記述に相違がある特定の属性について詳細な検索を行うためには、わざわざデータソース毎に用意された検索手段を利用しなければならず、不便となる。つまり、複数のデータソースを横断的に検索可能するという観点から、属性および属性値を正規化しているが、反対に、横断的検索のための利用と、個別のデータソースの利用とを分断し、データ利用の際の利便性を低下させる可能性がある点で、充分なものではなかった。

本発明は、上記従来技術における問題点に鑑みてなされたものであり、本発明は、異なる観点で定義される複数のデータソースから、データソース間で統一された観点と、各データソースへの依存性の高い細かな観点との両方の観点による検索を同一のシステムとして提供し、横断的検索のための利用と、個別のデータソースの利用との分断を回避し、ひいてはデータ利用の利便性を向上させることができる、情報検索システム、情報収集装置、情報検索装置、情報収集方法、プログラムおよび記録媒体を提供することを目的とする。

本発明は、上記課題を解決するために、下記特徴を有する複数のデータソースにわたって情報検索するための情報検索システムを提供する。本発明の情報検索システムは、情報収集機能として、データソースにアクセスし、検索対象の情報について属性および属性値を含む検索対象データを収集し、データソースそれぞれに定義される属性および属性値の組を、データソース間共通の正規化属性および正規化属性値の組へ対応付ける属性定義テーブルを参照しながら、上記検索対象データを正規化し、対応する正規化属性に関連付けて、正規化属性値と正規化前の属性値とを付与する。そして、情報検索システムは、収集元データソースを識別する情報と、対応する正規化属性と、正規化属性値と、正規化前の属性値とを含む検索用データをデータベースに格納する。本発明の情報検索システムは、さらに、情報検索機能として、検索クエリに応答して、該検索クエリに指定される属性の値に合致する正規化属性値または正規化前の属性値を有するデータを検索して検索結果を返す構成を採用する。

さらに本発明によれば、上述した情報収集機能を実装する情報収集装置、上述した情報検索機能を実装する情報検索装置、上述した情報収集装置が実行する情報収集方法、プログラムおよび記録媒体が提供される。

上記構成によれば、対象となるデータソースについて、正規化された属性値と併せて、データソースに固有な正規化前の属性値が正規化属性名に関連付けて検索用データとして格納され、正規化前の属性値が検索指定可能とされる。このため、上記構成による情報検索システムによれば、ユーザに対し、統一的観点によるデータソース群の検索と、データソースへの依存性の高い細かな観点によるデータソース群の検索とを同一のシステムで提供することが可能となる。

第１の実施形態による横断検索システムを含んで構成されるネットワーク環境１００の機能ブロック図。 データソースが格納するデータのデータ構造を例示する図。 （Ａ）スケジュール管理部が管理するスケジュールの管理データ、（Ｂ）データ収集履歴および（Ｃ）検索用データそれぞれのデータ構造を示す図。 属性変換テーブルのデータ構造を例示する図。 類似属性定義テーブルのデータ構造を例示する図。 第１の実施形態による横断検索システムのデータ収集部が実行する、データ収集処理を示すフローチャート。 （Ａ）第１の実施形態による横断検索システムの検索インタフェース部が提供する検索用ウェブ・ページを表示した検索画面、および（Ｂ）表示用文字列に変換するためのテーブルのデータ構造を示す図。 第１の実施形態による横断検索システムの検索インタフェース部が実行する、検索処理を示すフローチャート。 第２の実施形態による横断検索システムを含んで構成されるネットワーク環境１００の機能ブロック図。 （Ａ）特定表現定義テーブルおよび（Ｂ）属性値変換テーブルのデータ構造を例示する図。 （Ａ）データソース１６０Ｄが格納するデータ、および（Ｂ）データソース属性定義テーブルのデータ構造を例示する図。

以下、本発明について実施形態をもって説明するが、本発明は、後述する実施形態に限定されるものではない。以下の実施形態では、ネットワーク上の複数のデータソースからデータを収集し、情報検索のための検索用データを作成し、一方でクライアント・コンピュータからの検索要求に応えて検索結果を提供する横断検索システム１１０を例として説明する。

図１は、第１の実施形態による横断検索システム１１０を含んで構成されるネットワーク環境１００の機能ブロックを示す。図１に示すネットワーク環境１００は、ネットワークに接続される横断検索システム１１０と、横断検索システム１１０が提供する検索インタフェースにアクセスし、検索要求を行うクライアント・コンピュータ（以下、ユーザ端末という。）１５０と、複数のデータソース１６０Ａ〜１６０Ｃとを含む。上記ネットワークは、特に限定されるものではないが、例えばＴＣＰ／ＩＰおよびイーサネット（登録商標）によるローカル・エリア・ネットワーク（ＬＡＮ）、ＶＰＮ（Virtual Private Network）や専用線を使用するＷＡＮ（Wide Area Network）などとして構成される。

図１に示す複数のデータソース１６０Ａ〜１６０Ｃは、横断検索システム１１０に設定される検索範囲に含まれる情報源であり、検索対象となるドキュメント・データ、画像データ、マルチメディア・データなど種々のデータを格納する。なお、データソース１６０は、横断検索システム１１０がデータ取得可能である限り、如何なる形式の情報源とすることができる。上記データソース１６０としては、特定の実施形態では、リレーショナル・データベース、ＸＭＬ（eXtensible Markup Language）データベース、オブジェクト指向データベース、ファイル・サーバ上のフォルダ、文書（コンテンツ）管理システム、共有フォルダなどを挙げることができる。

データソース１６０には、それぞれ固有の属性および属性値の１以上のセットが付されたデータ群が格納される。複数のデータソース１６０Ａ〜１６０Ｃは、それぞれ異なる観点に基づいて整備されており、例えば、説明する実施形態では、データソース１６０Ａは、提案書を共有するためのデータベースであり、提案書の種類に重点を置いた設計となっている。データソース１６０Ｂは、例えば営業活動を支援するための情報を提供することを目的に整備されたデータベースであり、入力者による入力の表記にぶれが発生し難いように、分類が選択式で入力される設計となっている。一方、データソース１６０Ｃは、営業関係の情報共有を目的に設置されたデータベースであり、情報の共有の便宜を考慮し、最低限必要の文書の種類以外はすべて入力を強要しない設計となっている。

図２は、データソースが格納するデータのデータ構造を例示する。データソース１６０Ａ、データソース１６０Ｂおよびデータソース１６０Ｃには、説明する実施形態では、それぞれ図２（Ａ）、（Ｂ）および（Ｃ）に示すフォーマットのデータが格納される。図２には、属性の属性名、該属性のデータ型、該属性について入力されるサンプルの属性値が示されており、さらに、「説明」の欄において各属性の性質が補足されている。

属性名は、文字列で表される属性の名称であり、データ型は、文字列（string）、日付日時（datetime）、整数値（int）、ブール値（boolean）、単精度浮動小数点型（single）など種々のデータ取扱形式の中から選択される属性値のデータ型である。「データ型」欄において「ｎｕｌｌ可」と示されている属性は、値が設定されないことが許容される形式であることを示す。図２に示す「説明」欄において、「フリーテキスト」と説明されている属性は、入力者が属性値を自由に記述することが可能な形式であることを示す。例えば、自社製品を識別または分類するためのseihin属性などについては、同一企業内では、まったく内容の異なる値が入力される可能性は少ないが、入力者によって粒度が異なる可能性がある。一方、「説明」欄において、「選択式」と説明されている属性は、入力される属性値のバリエーションが所与の値の範囲に固定されている形式であることを示し、この属性においては、入力者による粒度の相違は発生し得ない。また、「説明」欄において、「自動で入力される」と説明されている属性は、それぞれのデータソースを管理するシステムによって自動的に属性値が付与されることを示す。

なお、説明の便宜上、データソース１６０Ａおよび１６０Ｂはリレーショナル・データベースであり、データソース１６０Ｃはファイル・サーバ上のフォルダであるものとして説明する。また、図２（Ｃ）は、データソース１６０Ｃのデータ構造を示しているが、データソース１６０Ｃの各データは、ファイルとして格納され、それぞれ、「事例」や「提案書」などのサブフォルダ内に、カテゴリ、キーワード、コメントなどのプロパティが付与されて格納されている。また、データソース１６０Ｃにおいてデータの内容自体はファイル中に、利用するアプリケーション・ソフトウェアに応じた形式で格納されており、本実施形態では、便宜上、予めテキスト抽出ソフトウェアによってファイルの内容が抽出され、コメント・プロパティとして付与されているものとする。なお、上述したまたは以下に説明する具体例は、説明のための例示するものであり、特にこれに限定されるものではないことはいうまでもない。

上述したように、横断検索システム１１０の検索範囲に含まれる複数のデータソース１６０は、それぞれ異なる観点で設計されたものであるため、同じような名称の属性であっても、それに設定される属性値は、所与の選択肢から選択する選択式であったり、フリーテキストであったり、数値表現であったりと、種々の様式が想定される。したがって、なんら工夫がなされていなければ、ユーザは、あるひとつの観点で検索したいだけであるにもかかわらず、複数のデータソースのそれぞれに対して、それぞれ対応する適切な検索手段を用いて、適切な属性値を指定して、個別に検索しなければならないことになる。

例えば、同じく製品を分類する、データソース１６０Ａのseihin属性と、データソース１６０Ｂのproduct-type属性とは、類似する性質を表す属性であるが、seihin属性がフリーテキストで入力されるのに対し、product-type属性が所定範囲の整数値から選択される。このため、データソース１６０Ｂのproduct-type属性に対応する所与の値を指定してデータソース１６０Ａおよびデータソース１６０Ｂを横断的に検索したとしても、データソース１６０Ｂのみのデータしかヒットしない。したがって、データソース１６０Ａおよび１６０Ｂから例えば財務管理系の製品情報を検索しようとする場合には、データソース１６０Ａについては、seihin属性に「財務管理Ｘ」を指定して検索し、データソース１６０Ｂについては、product-type属性に「1」を指定して別途検索しなければならない。また、上記データソースに格納されたデータを単純にテキストとして処理し、横断的に検索するよう構成しただけでは、充分な検索結果を得ることは難しい。

そこで、本実施形態の横断検索システム１１０は、以下詳細を説明するデータ収集部１１４および類似属性正規化部１１６を備える構成を採用する。データ収集部１１４は、スケジュール管理部１１２から定期または不定期に呼び出され、検索範囲として予め設定されているデータソース１６０Ａ〜１６０Ｃにアクセスし、これらのデータソース１６０Ａ〜１６０Ｃが保有するデータを検索するための検索対象データを収集する。収集される検索対象データは、検索対象の各データについて取得され、１以上の属性および属性値のセットを含み、データソース１６０が保有するデータそのもの、または保有するデータから抽出される。

スケジュール管理部１１２は、データを収集するスケジュールをデータソース１６０毎に管理しており、さらに、収集対象のデータソースの所在を示す情報（以下、アクセス先情報という。）およびアクセス方法を示す情報を記憶する。どのようなスケジュールとするかは、特定のデータソースの更新頻度などの統計情報に応じて適宜設定することができる。図３（Ａ）は、スケジュール管理部１１２が管理するスケジュールの管理データを示し、図３（Ａ）に示されるスケジュール（間隔、曜日、時刻）に従って、アクセス先情報およびアクセス方法を指定してデータ収集部１１４を起動する。データ収集部１１４は、上記アクセス先情報で特定されるデータソースに、上記アクセス方法にてアクセスして、必要な検索対象データを取得する。

スケジュール管理部１１２の実装としては、ＵＮＩＸ（登録商標）系のオペレーティング・システム（ＯＳ）を搭載したシステムであれば、cronを利用することができ、Ｗｉｎｄｏｗｓ（登録商標）系のＯＳを搭載したシステムであれば、タスクスケジューラを利用することができる。cronおよびタスクスケジューラでは、コマンド呼び出し時の引数が指定可能であるため、上記アクセス先情報およびアクセス方法は引数として指定することができる。説明する実施形態では、横断検索システム１１０がＷｉｎｄｏｗｓ（登録商標）系ＯＳで構成されている場合を示すが、この場合、タスクスケジューラに、図３（Ａ）に示すようにスケジュールでデータ収集部１１４を利用するためのコマンドが設定され、コマンドラインのオプションとしてアクセス先情報およびアクセス方法が与えらえる。なお、他のＯＳを使用する実施形態では、使用するＯＳに応じた適切なスケジュール管理手段を利用することができる。

データソース１６０からデータ収集するためのアクセス方法は、データソースの種類により異なり、特に限定されるものではないが、例えばデータソース１６０Ａおよび１６０Ｂについては、リレーショナル・データベースであるので、ＪＤＢＣやＯＤＢＣ（Open DataBase Connectivity）を用いた問い合わせにより行うことができる。例えばデータソース１６０Ｃについては、ファイル・サーバ上のフォルダであるので、Ｗｉｎｄｏｗｓ（登録商標）系であればshell32.dllを用いて行うことができる。図３（Ａ）に示す例では、「RDB-XX」が指定されるデータソース１６０Ａ，１６０Ｂについては、ＪＤＢＣを用いてアクセス先にアクセスし、「filesystem」が指定されるデータソースについては、shell32.dllを用いてアクセス先にアクセスすることになる。なお、企業内においては、データソースにアクセス制限が施されることが通常であるが、その場合、アクセス制限を考慮した既知のデータ収集方法を適宜採用することができる。なお、以下の説明では、便宜上すべてのデータソースについてアクセス制限がかけられていないものとして説明する。

また、データ収集部１１４は、図３（Ｂ）に示すようなデータ収集履歴を保持しており、２回目以降のデータ収集では、データソース１６０内のデータのうち、前回収集日時以降に変化があったデータについての情報を収集し、検索対象データを更新し、新たな検索対象のデータを追加し、または存在しなくなった検索対象のデータを削除する。

データ収集部１１４は、問い合わせの結果として検索対象データを取得すると、得られた検索対象データについて、属性変換テーブル１１８および類似属性正規化部１１６を用いてデータの加工を行い、その結果を検索用データとして検索用データベース１２２に格納する。属性変換テーブル１１８は、データソース固有に定義される一部の属性（属性名およびデータ型のセット）を、データソース間共通の属性（属性名およびデータ型のセット）に変換するためのテーブルである。

図４は、属性変換テーブルのデータ構造を例示する。図４に示す属性変換テーブル１１８は、データソースを特定する情報が入力されるカラムと、データソースにおける属性名およびデータ型がそれぞれ入力される各カラムと、共通の対応属性名および対応データ型がそれぞれ入力される各カラムとを含むレコードから構成される。属性変換テーブル１１８中に定義される属性としては、（１）id属性、docid属性、絶対パス属性などの検索対象を識別する属性（これらはdoc_id属性に正規化される。）、（２）koushin属性、lastupdate属性、前回保存日時属性などの検索対象の最終更新日時を示す属性（これらはdoc_updateTime属性に正規化される。）、（３）title属性、subject属性、ファイル名属性など検索対象の名称を示す属性（これらはdoc_title属性に正規化される。）、（４）body属性、content属性、コメント属性など検索対象の内容を表す属性（これらはdoc_body属性に正規化される。）など、概ねデータソースに共通して定義される共用性の高い属性が定義される。

データ収集部１１４は、図４に示すような属性変換テーブル１１８を参照して、問い合わせの結果として得られた検索対象データについて、データソース間でまちまちであった属性を共通の属性に変換する。データ収集部１１４は、属性変換した後、さらに、検索対象データの各属性について、類似属性正規化部１１６を呼び出し、検索対象データを正規化する。類似属性正規化部１１６は、類似属性定義テーブル１２０を参照して、検索対象データ中に含まれる属性のうち、該テーブル１２０内に定義される属性について正規化を行う。

類似属性定義テーブル１２０は、データソース固有に定義される属性名および属性値の組を、データソース間共通の正規化された属性名（以下、正規化属性名という。）および属性値（以下、正規化属性値という。）の組に対応付けるテーブルである。図５は、類似属性定義テーブルのデータ構造を例示する。図５に示す類似属性定義テーブル１２０は、データソースを特定する情報が入力されるカラムと、データソースにおける属性名および属性値がそれぞれ入力される各カラムと、正規化属性名および正規化属性値がそれぞれ入力される各カラムとを含むレコードから構成される。

類似属性定義テーブル１２０には、複数のデータソース間で表記にぶれが存在し得る属性名および属性値の組が定義されており、類似属性正規化部１１６は、類似属性定義テーブル１２０を参照して、データソース固有の属性名および属性値をデータソース間共通の正規化属性名および正規化属性値に正規化し、適用結果をデータ収集部１１４に返す。類似属性定義テーブル１２０中の「＊」印は、文字列の後ろに付されて前方一致を表し、文字列の前に付されて後方一致を表し、文字列の前後に付されて部分一致を表し、単独で用いられて文字数不定の任意の文字列に無条件にマッチするワイルドカードを表す。例えば、図５に示す類似属性定義テーブル１２０中の２番目のレコードは、teian-type属性の属性値が「提案」に後方一致する場合には、doc_docType正規化属性に、正規化属性値「提案書」が一律にラベルされることになる。また、図５に示す類似属性定義テーブル１２０中の８番目のレコードでは、３番目からのレコードに規定される条件、つまりkokyaku属性の属性値が「全業種」、「設備」、「学校」、「塾」・・・のいずれにも該当しない場合に、正規化属性値としてｎｕｌｌ値がラベルされることになる。

類似属性正規化部１１６からの適用結果を返されたデータ収集部１１４は、収集元データソースを識別する情報と、適用結果として得られた正規化属性に、正規化属性値に加えて正規化前の属性値を関連付けて、検索用データとして検索用データベース１２２に追加し、または更新する。図３（Ｃ）は、検索用データベース内に格納される検索用データのデータ構造を示す。図３（Ｃ）に示すように、各検索対象について作成される検索用データは、doc_dataSource属性とdoc_id属性とによって固有に識別され、図２（Ａ）〜（Ｃ）に示されたデータソース固有の属性が正規化されたデータ構造を有する。図３（Ｃ）中の「データ型」欄におけるstring配列は、この属性値には文字列データ形式のデータ配列が保持されることを表しており、この属性値には上記正規化属性値および正規化前の属性値が配列として入力され得る。

以下、図６を参照しながら、データ収集処理についてより詳細に説明する。図６は、横断検索システム１１０のデータ収集部１１４が実行する、データ収集処理を示すフローチャートである。図６に示す処理は、スケジュール管理部１１２が、スケジュールされたタイミングで、データソースのアクセス先情報およびアクセス方法を指定してデータ収集部１１４を呼び出したことに応答して、ステップＳ１００から開始する。例えば、現在の日時が２０ｘｘ年８月３１日の２２：００であるとすると、スケジュール管理部１１２から、データソース１６０Ａ（//target_server:port/target_db）を指定して、データ収集部１１４が呼び出される。なお、図６に示す処理は、データソース毎に行われる処理である。

ステップＳ１０１では、データ収集部１１４は、図３（Ｂ）に示すようなデータ収集履歴を参照して、指定されたデータソースについての前回収集日時を取得する。図３（Ｂ）に示す例では、データソース１６０Ａについて日時（２０ｘｘ年８月２９日２２：００）が取得される。ステップＳ１０２では、データ収集部１１４は、当該データソースのデータ収集履歴の前回収集日時を現在日時で更新する。説明する例では、前回収集日時を現在日時（２０ｘｘ年８月３１日２２：００）で上書きする。ステップＳ１０３では、当該データソースに対し、指定されたアクセス手法を用いてアクセスして、前回収集日時以降に変化があったデータを取得し、その検索対象データを作成する。説明する例では、更新前の前回収集日時（２０ｘｘ年８月３１日２２：００）以降に変化があるデータ（lastupdate属性の属性値が20xx-08-31 22:00以上のもの）を問い合わせ、データソース１６０Ａから変化分のデータを取得する。

なお、図６を参照したデータ収集処理の説明では、収集されるデータは、レコード毎またはファイル毎に取得され、前回収集日時以降に変化があったすべてのデータベースのレコードまたはファイルについて、ステップＳ１０３〜ステップＳ１０７の処理が繰り返されるものとして説明する。

現在の日時が２０ｘｘ年９月４日の１０：００であるとすると、データソース１６０Ｃ（\\test_server3\target_folder）に関するデータ収集が行われる。データソース１６０Ｃはファイル・サーバであるため、データ収集部１１４は、ステップＳ１０３で、指定されたフォルダ以下のサブフォルダすべてについて、ファイルのプロパティを検査し、更新前の前回収集日時（２０ｘｘ年８月３１日２２：００）以降に保存されたファイル（前回保存日時が２０ｘｘ年８月２８日の１０：００以降となっているファイル）について、プロパティ情報のカテゴリ、キーワード、前回保存日時およびコメントを、サブフォルダおよび絶対パスの情報と併せて取得する。

ステップＳ１０４では、データ収集部１１４は、作成された検索対象データに対して、属性変換テーブル１１８を適用し、データソース間共通の対応属性名および対応データ型から構成される属性に変換し、検索用データを作成する。例えばデータソース１６０Ａであれば、データ収集部１１４は、各属性毎に、データソース１６０Ａを識別するアクセス先情報（//target_server:port/target_db）と属性名をキーに、属性変換テーブル１１８を参照する。図４に示す属性変換テーブル１１８では、id属性、koushin属性、title属性、body属性の４つの属性について対応属性名が記載されており、データ収集部１１４は、属性名を対応属性名に変換する処理を行う。なお、図４に示す例では、属性値のデータ型の変化はないため、各属性値は、変更されず、そのまま対応する属性に引き継がれる。

ステップＳ１０５では、データ収集部１１４は、作成された検索対象データ中の各属性について、類似属性正規化部１１６を呼び出し、ステップＳ１０６で、類似属性正規化部１１６から適用結果を受け取り、検索用データに追加する。データソース１６０Ａであれば、データ収集部１１４は、各属性毎に、データソースを識別するアクセス先情報と、属性名と、属性値とを、文字列として類似属性正規化部１１６に渡し、適用結果として、図５に示した類似属性定義テーブル１２０に定義される３つの正規化属性（doc_docType属性，doc_customorType属性，doc_productType属性）について、それぞれ文字列の配列を受け取る。データソース１６０Ａであれば、取得された変更にかかる各データについて、図２（Ａ）に例示する最初のid属性から最後のbody属性まで、類似属性正規化部１１６が合計７回呼び出され、適用結果が累積される。

類似属性正規化部１１６は、類似属性定義テーブル１２０を適用し、データソースと、属性名と、属性値とのセットを受け取ると、まず、文字列で表現された属性値を、全角または半角のカンマ、全角または半角の読点、全角または半角のスペースなどのデリミタで分割し、属性値の文字列の配列を作成する。類似属性正規化部１１６は、その後、データソース、属性名、属性値(文字列の配列の個別要素)をキーとして、図５に示すような類似属性定義テーブル１２０を参照して正規化し、適用結果を返す。

例えば、セット（//target_server:port/target_db，id，2010-08-31-00231）では、類似属性定義テーブル１２０に該当する属性名が存在しないため、類似属性正規化部１１６は、３つの正規化属性（doc_docType属性，doc_customorType属性，doc_productType属性）のそれぞれについて空の配列を返却する。セット（//target_server:port/target_db，teian-type，個別提案）では、類似属性定義テーブル１２０の２番目レコードの属性値「*提案」にマッチするため、正規化属性（doc_docType属性）に「提案書」と、さらに元となった正規化前の属性値である「個別提案」とが格納され、残りのdoc_customorType属性(空の配列)およびdoc_productType属性の空の配列と共に適用結果が返される。

セット（//target_server:port/target_db，kokyaku，”学校，塾”）のセットでは、属性値がデリミタで分割され、サブセット（//target_server:port/target_db，kokyaku，学校）およびサブセット（//target_server:port/target_db，kokyaku，塾）となり、類似属性定義テーブル１２０の５番目、６番目、８番目にマッチするため、doc_docType属性(空の配列)、doc_customorType属性(［O.教育学習支援業，学校，塾］)、doc_productType属性(空の配列)が返される。seihin属性に関するセットからは、doc_docType属性(空の配列)、doc_customorType(空の配列)、doc_productType属性(［財務管理系，財務管理Ｘ］)が返される。なお、配列へのデータを格納する際には、説明する実施形態では、重複データは改めて格納されないものとする。

データソース１６０Ｂについても同様であり、まずステップＳ１０４で、属性変換テーブル１１８により、docid属性(int)がdoc_id属性(string)へ、lastupdate属性(datetime)がdoc_updateTime属性(datetime)へ、subject属性(string)がdoc_title属性(string)へ、content属性(string)がdoc_body属性(string)へ変換され、さらにgoushu-2属性(string)がdoc_body属性(string)の末尾に変換後追加される。次に、ステップＳ１０５で、各属性毎に類似属性正規化部１１６が呼び出され、類似属性正規化部１１６は、類似属性定義テーブル１２０を参照して正規化処理を行う。処理結果として、information-type属性に関するセットからは、doc_docType属性(［商談事例，3］）、doc_customorType属性(空の配列)、doc_productType属性(空の配列)が返され、gyoushu-1属性に関するセットからはdoc_docType属性(空の配列）、doc_customorType属性(［農業，3］）、doc_productType属性(空の配列)が返され、product-type属性に関するセットからはdoc_docType属性(空の配列)、doc_customorType属性(空の配列)、doc_productType属性(［顧客管理系，7］)が返される。

データソース１６０Ｃについても同様であり、まずステップＳ１０４で、属性変換テーブル１１８を用いて、絶対パス属性(string)がdoc_id(string)属性へ、前回保存日時属性(string)がdoc_updateTime属性(datetime)へ、ファイル名属性(string)がdoc_title属性(string)へ、コメント属性(string)がdoc_body属性（string）へ変換される。続いて、ステップＳ１０５で、各属性毎に類似属性正規化部１１６が呼び出され、類似属性正規化部１１６による処理の結果として、サブフォルダに関するセットからはdoc_docType属性（カタログ)、doc_customorType属性(空の配列)、doc_productType属性(空の配列)が返され、カテゴリに関するセットからはdoc_docType属性(空の配列)、doc_customorType属性(空の配列)、doc_productType属性(空の配列)が返り、キーワードに関するセットからはdoc_docType属性(空の配列)、doc_customorType属性(空の配列)、doc_productType属性(管理系Ｘ）が返される。管理系Ｘと参照される製品に適切に正規化属性値を与える定義は、図５に示す類似属性定義テーブル１２０中には存在しないが、データソース１６０Ｃ（\\test_server3\target_folder）の末尾に、任意の文字列にマッチする属性値が「＊」設定されているため、その結果として、元の属性値である「管理系Ｘ」は、doc_productType属性の属性値として格納される。

引き続き図６を参照すると、ステップＳ１０７では、データ収集部１１４は、最終的な検索用データを検索用データベース１２２に格納する。検索用データは、処理対象としているデータソースのアクセス先情報が格納されるdoc_dataSource属性、doc_id属性、doc_updateTime属性、doc_docType属性、doc_customorType属性、doc_productType属性、doc_title属性およびdoc_body属性を含む。ここでは、取得された検索対象が新規なものであれば、検索用データベース１２０に検索用データが挿入され、既に存在する場合には更新される。例えば、当該doc_dataSource属性およびdoc_id属性の値のセットを持つ検索用データについて更新操作（UPDATE）を行い、更新が成功すればそれで終了し、更新が失敗した場合には、検索用データベース１２２へ検索用データの挿入操作（INSERT）を行う。

ステップＳ１０８では、データ収集部１１４は、指定のデータソースにおいて処理すべきデータが他に存在するか否かを判定する。ステップＳ１０８で、処理すべきデータが他にまだ存在すると判定された場合（ＹＥＳ）には、ステップＳ１０３へループさせ、データソース中に前回更新時刻以降変化があったデータが存在しなくなるまで、処理を繰り返させる。一方、ステップＳ１０８で、処理すべきデータがもう存在しないと判定された場合（ＮＯ）には、ステップＳ１０９へ処理を分岐させる。ステップＳ１０９では、データ収集部１１４は、当該データソースについての検索用データが格納済みの検索対象について存在確認し、存在しなくなっているものについては検索用データ自体を削除し、または検索用データに削除フラグを設定する。

この際に、当該データソースへのアクセスに必要なデータ形式で検索対象を識別する識別子を得るため、属性変換テーブル１１８を適用して、データソース間共通の対応属性doc_idから、アクセス先データソース固有の形式（データソース１６０Ａであればid属性）に変換し、元の属性名を取得する。存在確認は、当該データソースに対し、doc_id属性の属性値（例えば20xx-08-31-00231）を元の属性（データソース１６０Ａでは、id属性である。）として有する情報の問い合わせすることにより行うことができ、その値を有するデータが存在しなければ、エラー応答があるため、これにより存在を確認することができる。検索用データベース１２２からの削除は、当該データソースのdoc_dataSource属性の属性値および当該doc_id属性の属性値を指定した検索用データの削除または削除フラグの設定により行うことができる。

以上説明したデータ収集処理によって検索対象の検索用データが検索用データベース１２２に格納されると、当該検索対象が実際に検索可能となる。以下、図１、図７および図８を参照して、第１の実施形態の横断検索システム１１０を用いた検索処理について説明する。

図１を再び参照すると、横断検索システム１１０は、さらにユーザ端末１５０に対し検索用のグラフィカル・ユーザ・インタフェース（以下、ＧＵＩと参照する。）を提供する検索インタフェース部１２４を含む。検索インタフェース部１２４は、説明する実施形態では、ＣＧＩ(Common Gateway Interface)、ＳＳＩ（Server Side Include）、サーブレット、ウェブ・アプリケーションなどのサーバ・プログラムとして実装され、ＨＴＴＰプロトコルを使用して、ユーザ端末１５０のブラウザ１５２に対して検索用ウェブ・ページを提供し、当該検索用ウェブ・ページを介した検索要求を受信して、検索結果を返すよう構成されている。ユーザ端末１５０は、ウェブ・ブラウザ１５２を実装する汎用コンピュータ装置またはＰＤＡや携帯電話などの携帯端末装置などとして構成されており、横断検索システム１１０に対し検索要求を発行し、検索結果を取得して、その表示デバイス上に検索結果を表示する。

図７（Ａ）は、第１の実施形態による横断検索システムの検索インタフェース部が提供する検索用ウェブ・ページが表示された検索画面を例示する。図７（Ａ）に示す検索画面２００は、文書の種類、製品分類、業種、キーワードを入力するためのＧＵＩ部品２１０，２２０，２３０，２４０を含み、ユーザ端末１５０の利用者は、各ＧＵＩ部品に値をセットすることが可能であり、これらに値がセットされた後、検索ボタン２５０がクリックされると、ブラウザ１５２は、ＧＵＩ部品にセットされた値を含めて検索クエリを横断検索システム１１０の検索インタフェース部１２４に送信し、検索インタフェース部１２４から検索結果を受信して、検索結果表示エリア２６０に表示する。

検索画面２００上の文書の種類、業種、製品分類を指定するための各ＧＵＩ部品２１０，２２０，２３０は、それぞれ、検索用データベース１２２におけるdoc_docType属性、doc_customorType属性およびdoc_productType属性の属性値を指定するためのものであり、新規入力可能なコンボボックスにより実現されている。それぞれのＧＵＩ部品２１０，２２０，２３０の右端にある下向き矢印のボタンをクリックすると、選択可能な値のリストが表示され、その中から反転表示２１２で値を選択することにより、各属性に対する値がセットされる。リストの先頭と末尾は特殊な項目であり、先頭は「選択なし」の項目、末尾は「新規入力」の項目となっている。「選択なし」の項目が選択された状態では、対応する属性値はセットされない。「新規入力」の項目２１４が選択された状態では、「新規入力」の文字列の上に文字列の上書入力が可能となり、属性に対する値の指定としては、上書入力した文字列がセットされる。

キーワードを入力するためのＧＵＩ部品２４０は、例えばテキストボックスにより実現され、ユーザは、自由に文字列が入力可能とされ、単語毎にデリミタで区切って文字列を入力することが期待される。検索ボタン２５０がクリックされると、ブラウザ１５２は、ＧＵＩ部品２１０〜２４０にセットされた値に従って検索条件が記述された検索クエリを検索インタフェース部１２４に送信する。検索インタフェース部１２４は、検索クエリを解釈し、上記キーワードについては、ＧＵＩ部品２４０にセットされたキーワード文字列をデリミタにして分割し、検索用キーワード列Ｗ（０）〜Ｗ（ｎ）（ここで、ｎはキーワード要素数に応じた数である。）を得る。なお、これらの検索用キーワード列と、文書の種類、業種、製品分類のそれぞれについては、値がセットされていない場合は検索条件としては使用されない。

検索インタフェース部１２４は、上記文書の種類（doc_docType属性）、業種（doc_customorType属性）、製品分類（doc_productType属性）に対する値の指定と、検索用キーワード列Ｗ（０）〜Ｗ（ｎ）を論理積（ＡＮＤ）で結合した条件式を検索条件とし、検索条件に合致する検索用データを検索用データベース１２２から検索し、検索結果を取得する。検索インタフェース部１２４は、検索結果を取得すると、ユーザが認識しやすい表示用の形式に検索結果を整形し、ユーザ端末１５０のブラウザ１５２へ整形後の検索結果を送信する。ブラウザ１５２は、整形後の検索結果を受け取り、図７（Ａ）に示す検索画面２００の検索結果表示エリア２６０を検索結果に応じて更新し、表示デバイスを介してユーザに提示する。

図８は、第１の実施形態による横断検索システムの検索インタフェース部が実行する、検索処理を示すフローチャートである。図８に示す処理は、ユーザ端末１５０のブラウザ１５２から検索クエリが送信されたことに応答して、ステップＳ２００から開始する。ステップＳ２０１では、検索インタフェース部１２４は、ユーザ端末１５０から検索クエリを受信する。図７（Ａ）に示す検索画面では、文書の種類として「商談事例」が選択され、キーワードとして「オーエス サイト構築」がセットされているため、この状態で、検索ボタン２５０がクリックされると、doc_docType属性に対して値（商談事例）を指定し、キーワード文字列（「オーエス サイト構築」）を含む検索クエリが発行される。

ステップ２０２では、検索インタフェース部１２４は、検索クエリを解釈して、上記属性に対する値および検索キーワード列を含む検索条件を抽出する。図７（Ａ）に示す検索画面の例では、キーワードについては、デリミタで分割され、「オーエス」および「サイト構築」のキーワード列が取得される。製品分類、業種については値がセットされていないため検索条件としては採用されない。ステップＳ２０３では、検索インタフェース部１２４は、上記抽出した検索条件に合致する検索用データを検索用データベース１２２から検索し、検索結果を取得する。説明の例では、検索条件（doc_docType=「商談事例」 AND doc_body=「*linux*」 AND doc_body=「*サイト構築*」）で検索用データベース１２２への問い合わせが行われる。

ステップＳ２０４では、検索インタフェース部１２４は、表示用に検索結果を整形し、検索結果表示用データを作成する。例えば、検索結果は、１データごとに５行づつ、１０データ毎に表示され、タイトル(doc_title)が１行目に、データソース(doc_dataSource属性)およびデータの識別子(doc_id)が２行目に、当該文書からの抜粋が３行目および４行目に、空行が５行目に含まれる。対応するデータソースが、ブラウザからアクセス可能な形式のものであれば、２行目のデータソースおよびデータの識別子の表示に代えて、１行目のタイトルに当該検索対象のデータへのハイパーリンクを張ることもできる。この場合には、検索用データベース１２２のデータ構造において、doc_dataSource属性、doc_id属性の他、検索対象の格納位置を特定するＵＲＬを格納するdoc_URL属性を設け、このためのデータ取得、変換規則を設ければよい。

また、データソースは、doc_dataSource属性に格納された値そのままでは、通常ユーザには理解し難いため、検索インタフェース部１２４は、上記整形処理として、図７（Ｂ）に示すようなテーブルを参照して、doc_dataSource属性値を表示用文字列に変換する処理を行うことができる。

ステップＳ２０５では、検索インタフェース部１２４は、ユーザ端末１５０に対し、検索結果として検索結果表示用データを返信する。図７（Ａ）に示す例では、検索結果表示エリア２６０中、１番目がデータソース１６０Ａからの結果、２番目がデータソース１６０Ｂからの結果となっており、３番目以降は、画面から見切れており、スクロール・バー等によって順次表示していくように構成されている。なお、図７（Ｂ）から、データソース１６０Ｂは「営業のモト」に、データソース１６０Ｃは「営業部共有ファイル・サーバ」として表示される。３行目および４行目は、指定したキーワードによるヒット位置前後の当該文書から抜粋された文字列が表示される。

なお、上述した横断検索システム１１０に含まれる各機能部および各処理は、コンピュータ装置が、コンピュータ可読な記録媒体からプログラムを読み出し、メモリ上にプログラムを展開し、ＣＰＵがプログラムを実行し、各ハードウェア資源を動作制御することによって実現することができる。上記実施形態において、横断検索システム１１０は、データ収集機能および検索機能の両方を備えるコンピュータ装置として構成することもできるが、図１に点線で示すように、データ収集機能を専ら担当する情報収集サーバと、データ検索機能を専ら担当する情報検索サーバとに分けて、複数のコンピュータ装置として横断検索システム１１０を構成することもできる。

なお、本実施形態の横断検索システム１１０を構成するコンピュータ装置は、概ねパーソナル・コンピュータ、ワークステーション、ミッドレンジまたはメインフレームなどの汎用コンピュータ装置として構成される。コンピュータ装置は、より具体的には、シングルコア・プロセッサまたはマルチコア・プロセッサなどのＣＰＵ、キャッシュ・メモリ、ＲＡＭ、ネットワーク・インタフェース・カード、ストレージ・インタフェースを介して接続されるストレージ装置などを備え、ＷＩＮＤＯＷＳ（登録商標）２００Ｘ、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）などのオペレーティング・システム（以下、ＯＳとして参照する。）の制御の下、データベース管理システムを実装し、上記ストレージ装置が提供する記憶領域に、各種テーブル１１８，１２０および検索用データベース１２２をデータベースとして実現している。

上述したデータ収集処理により、検索範囲の各データソースについて、データソース間で共通の正規化された属性値と併せて、データソース固有の正規化前の属性値も、正規化属性名に関連付けて検索用データベース１２２に格納され、正規化前後の属性値を指定した検索が可能とされる。したがって、上述したデータ検索処理により、ユーザは、それぞれ異なった観点で設計された複数のデータソースに対して、正規化属性値による統一的な観点で検索を行えるとともに、それぞれのデータソース固有な属性値によるきめ細やかな観点で検索を行うことが可能となる。ひいては、ユーザに対し、統一的観点によるデータソース群の検索と、データソースへの依存性の高いきめ細かな観点によるデータソース群の検索とを同一のシステム内で提供し、従来では分断された作業を統合して、データ利用の利便性を向上させることができる。

以下、第２の実施形態による横断検索システムについて説明する。図９は、第２の実施形態による横断検索システムを含んで構成されるネットワーク環境の機能ブロックを示す。なお、第２の実施形態による横断検索システムは、第１の実施形態と同様な機能を有するため、以下、同様の機能を奏する機能部には同一符番を付して参照し、以下、相違点を中心に説明する。

第２の実施形態による横断検索システム１１０は、図９に示すように、特定表現定義テーブル１２６、属性値変換テーブル１２８およびデータソース属性定義テーブル１３０を備え、類似属性正規化部１１６が、類似属性定義テーブル１２０に加えて、これら特定表現定義テーブル１２６、属性値変換テーブル１２８およびデータソース属性定義テーブル１３０を参照しながら検索対象データを正規化する点を除いて、第１の実施形態と同様である。また、データソース１６０は、第１の実施形態で参照したデータソース１６０Ａ〜１６０Ｃに加えて、データソース１６０Ｄが存在する点でも相違する。

以下、類似属性正規化部１１６による、特定表現定義テーブル１２６を用いた正規化処理について、より詳細に説明する。データソース１６０は、第１の実施形態において上述した通り、提案書を共有するための情報源等であるが、情報は予め用意された分類のみで分類しきれない場合も多い。そして、運用上、入力者が適当な分類を新たに定義して、その分類を目立つような形で示しつつ入力するというような運用が行われる可能性がある。例えば、図２（Ａ）に例示するように、title属性において、「〔事例あり〕」などの文字列の特定表現により、分類名を付加するという提示方法が想定される。

説明する例では、データソース１６０Ａの運用上、title属性がフリーテキストであるが、規則として、データソース１６０Ａが提案書を共有することとなっており、teian-type属性に入力可能な情報の分類値が「提案書」や「お知らせ」程度であるため、説明の便宜上、「提案書」以外の情報の存在は、タイトルへの「〔」および「〕」で囲って特定表現により分類を付加するという分類提示方法で補う運用とされているものとする。

第２の実施形態による類似属性正規化部１１６は、類似属性定義テーブル１２０を参照して検索対象データを正規化するとともに、特定表現定義テーブル１２６を参照して、上記運用上の分類提示方法に対応した正規化処理を行う。特定表現定義テーブル１２６は、指定属性の属性値中に特定表現が存在する場合に、それに対応付けて正規化属性値を付すためのテーブルであり、データソース固有に定義される属性名、および属性値中の特定表現の組を、正規化属性名および正規化属性値の組に対応付ける。図１０（Ａ）は、特定表現定義テーブル１２６のデータ構造を例示する。図１０（Ａ）に示す特定表現定義テーブル１２６は、データソースを特定する情報が入力されるカラムと、データソースにおける属性名が入力されるカラムと、属性値中の特定表現が入力されるカラムと、正規化属性名および正規化属性値がそれぞれ入力される各カラムとを含むレコードから構成される。

第２の実施形態による類似属性正規化部１１６は、データ収集部１１４より指定された属性について、類似属性定義テーブル１２０の参照後、さらに、類似属性定義テーブル１２０の場合と同様の動作で、データソース、属性名、属性値(文字列の配列の個別要素)をキーとして特定表現定義テーブル１２６を参照する。図１０（Ａ）に示す特定表現定義テーブル１２６では、図２（Ａ）に示すデータソース１６０Ａのデータは、タイトル（title属性）に文字列（〔事例あり〕）を含むため、doc_docType正規化属性として「商談事例」と、正規化前の属性として「〔事例あり〕」が付される。上記構成により、ユーザは、データソースの設計とは離れて、データソース１６０に格納される内容そのものに埋め込む形で属性が記述される運用が行われている場合においても、統一的観点での検索と、データソース固有の観点での検索を同一システム内で提供することが可能となる。

以下、類似属性正規化部１１６による、属性値変換テーブル１２８を用いた正規化処理についてより詳細に説明する。データソース１６０は、第１の実施形態において上述した通り、営業支援情報を提供するための情報源等であるが、選択式の値を持つ項目については、データベース設計上、表示される値と格納される値とを分け、表示される値はユーザにわかりやすい文字列で、格納される値は無機質な数値で格納することがしばしばある。図２（Ｂ）に示すデータソース１６０Ｂは、上述のような設計とされており、属性値が数値で格納されている。したがって、正規化前の属性値として、文字列を表現した数値（例えば7）などを格納したとしても、このままでは、ユーザの検索に役立たない可能性がある。

そこで、第２の実施形態による類似属性正規化部１１６は、類似属性定義テーブル１２０を参照して正規化するとともに、さらに、属性値変換テーブル１２８を参照して、上記属性値の正規化処理を行う。属性値変換テーブル１２８は、指定属性の属性値が無機質な数値で表現されている場合に、該無機質な数値から、人間が理解可能な意味を提示する提示属性値に変換するためのテーブルであり、データソース固有に定義される属性名、および属性値を提示属性値に対応付ける。図１０（Ｂ）は、属性値変換テーブル１２８のデータ構造を例示する。図１０（Ｂ）に示す属性値変換テーブル１２８は、データソースを特定する情報が入力されるカラムと、データソースにおける属性名が入力されるカラムと、属性値中の特定表現が入力されるカラムと、提示属性値が入力されるカラムとを含むレコードから構成される。

第２の実施形態による類似属性正規化部１１６は、データ収集部１１４より指定された属性について、類似属性定義テーブル１２０の参照後、さらに、類似属性定義テーブル１２０の場合と同様の動作により、データソース、属性名、属性値(文字列の配列の個別要素)をキーとして、属性値変換テーブル１２８を参照する。図１０（Ｂ）に示す属性値変換テーブル１２８によれば、図２（Ｂ）に示すデータソース１６０Ｂのデータでは、属性値（information-type属性=3）については正規化属性値（事例）が、属性値（gyoushu-1属性=3）については正規化属性値（農業）が、属性値（product-type=7）については正規化属性値（人事系製品）が、それぞれ数値の替わりに格納される。上記構成により、ユーザに提示される文字列とは異なる値がデータソース１６０に実際に格納されている場合であっても、ユーザがデータソース１６０について記憶している、覚えやすい観点を指定しても、良好な結果を得ることが可能となる。

以下、類似属性正規化部１１６による、データソース属性定義テーブル１３０を用いた正規化処理についてより詳細に説明する。図１１（Ａ）は、データソース１６０Ｄが格納するデータのデータ構造を例示する。データソース１６０Ｄは、データソース１６０Ａと同様に提案書を共有する目的で設計されているものであるが、データソース１６０Ａと異なるデータ構造を有する。具体的には、データソース１６０Ａに備わっていた属性のうち、teian-type属性が、データソース１６０Ｄには備わっていない。データソース１６０Ａとデータソース１６０Ｄのように、データベースの方向性は同じであっても、特定の部分に特化してデータを提供するケースは多くあり、このような場合には、大きな観点では必要とされる属性値も、自明なため付与されず、省略されることがある。

そこで、第２の実施形態による類似属性正規化部１１６は、類似属性定義テーブル１２０を参照して正規化するとともに、さらに、データソース属性定義テーブル１３０を参照して、上記データソースに対し正規化属性を補足する。データソース属性定義テーブル１３０は、上述のように属性値の付与が省略される場合に、データソースに対して正規化属性を補足するためのテーブルであり、データソースを正規化属性名および正規化属性値へ対応付ける。図１１（Ｂ）は、データソース属性定義テーブル１３０のデータ構造を例示する。図１１（Ｂ）に示すデータソース属性定義テーブル１３０は、データソースを特定する情報が入力されるカラムと、正規化属性名および正規化属性値がそれぞれ入力される各カラムとを含むレコードから構成される。

第２の実施形態による類似属性正規化部１１６は、データ収集部１１４より指定された属性について、類似属性定義テーブル１２０の参照後、さらに、データソースをキーとして、データソース属性定義テーブル１３０を参照し、キーがマッチする場合は、対応する正規化属性を補足し、当該正規化属性に正規化属性値を格納する。図１１（Ｂ）に示すデータソース属性定義テーブル１３０によれば、図１１（Ａ）に示すデータソース１６０Ｄのデータでは、doc_docType属性に対して値（提案書）が格納される。上記構成により、データソースにも、文書の中身にも手がかりとなる属性名、属性値が明確に示されておらず、データソースの利用目的自体から、暗黙のうちに属性が設定されているような場合であっても、観点が欠落しているためにシステムの対象にできないという状況を解消し、システムから統一的観点で検索することが可能となる。

以上説明したように、上述した実施形態によれば、異なる観点で定義される複数のデータソースから、データソース間で統一された観点と、各データソースへの依存性の高い細かな観点との両方の観点による検索を同一のシステムとして提供し、横断的検索のための利用と、個別のデータソースの利用との分断を回避し、ひいてはデータ利用の利便性を向上させることができる、情報検索システム、情報収集装置、情報検索装置、情報収集方法、プログラムおよび記録媒体を提供することが可能とされる。

上記機能は、アセンブラ、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標）、などのレガシープログラミング言語やオブジェクト指向プログラミング言語などで記述されたコンピュータ実行可能なプログラムにより実現でき、ＲＯＭ、ＥＥＰＲＯＭ、ＥＰＲＯＭ、フラッシュメモリ、フレキシブルディスク、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ブルーレイディスク、ＳＤカード、ＭＯなど装置可読な記録媒体に格納して、あるいは電気通信回線を通じて頒布することができる。

これまで本発明の実施形態について説明してきたが、本発明の実施形態は上述した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

１００…ネットワーク環境、１１０…横断検索システム、１１２…スケジュール管理部、１１４…データ収集部、１１６…類似属性正規化部、１１８…属性変換テーブル、１２０…類似属性定義テーブル、１２２…検索用データベース、１２４…検索インタフェース部、１２６…特定表現定義テーブル、１２８…属性値変換テーブル、１３０…データソース属性定義テーブル、１４０…情報収集機能、１４２…情報検索機能、１５０…ユーザ端末、１５２…ブラウザ、１６０…データソース、２００…検索画面、２１０，２２０，２３０，２４０…ＧＵＩ部品、２１２…反転表示、２１４…「新規入力」の項目、２５０…検索ボタン、２６０…検索結果表示エリア

特許第４０４２８３０号公報

Claims (13)

1. 複数のデータソースにわたって情報検索するための情報検索システムであって、
   前記データソースにアクセスし、検索対象の情報について属性および属性値を含む検索対象データを収集する収集手段と、
   前記データソースそれぞれに定義される属性および属性値の組を、前記データソース間共通の正規化属性および正規化属性値の組へ対応付ける属性定義テーブルと、
   前記属性定義テーブルを参照して前記検索対象データを正規化し、対応する正規化属性に関連付けて、正規化属性値と正規化前の属性値とを付与する正規化手段と、
   収集元データソースを識別する情報と、前記対応する正規化属性と、前記正規化属性値と、前記正規化前の属性値とを含む検索用データを格納するデータベースと、
   検索クエリに応答して、前記検索クエリに指定される属性の値に合致する正規化属性値または正規化前の属性値を有するデータを検索して検索結果を返す検索手段と、
   前記データソースそれぞれに対し正規化属性および正規化属性値を対応付けるデータソース属性定義テーブルと
   を含み、前記正規化手段は、データソースを識別して、前記検索用データに、対応する正規化属性および正規化属性値を補足することを特徴とする、情報検索システム。
2. 前記情報検索システムは、さらに、
   前記データソースそれぞれに定義される属性および属性値に含まれる特定表現の組を、前記データソース間共通の正規化属性および正規化属性値の組へ対応付ける特定表現定義テーブルを含み、前記正規化手段は、前記特定表現定義テーブルを参照して前記検索対象データ中の前記特定表現を正規化し、対応する正規化属性に関連付けて、正規化属性値と、正規化前の属性値に含まれる特定表現とを付与することを特徴とする、請求項１に記載の情報検索システム。
3. 前記情報検索システムは、さらに、
   前記データソースそれぞれに定義される属性に対する無機質な属性値を、属性値の意味を提示する提示属性値へ対応付ける属性値変換テーブルを含み、前記正規化手段は、前記属性値変換テーブルを参照して、前記検索対象データ中の前記無機質な属性値を前記提示属性値に変換して、前記正規化前の属性値とすることを特徴とする、請求項１または請求項２に記載の情報検索システム。
4. 前記情報検索システムは、定期または不定期に前記収集手段を呼び出し、前回収集時以降に更新されたデータソース内の検索対象の情報について検索対象データを収集するよう指令するスケジュール管理手段をさらに含む、請求項１〜３のいずれか１項に記載の情報検索システム。
5. 複数のデータソースにわたって情報検索するための検索用データを収集する情報収集装置であって、
   前記データソースにアクセスし、検索対象について属性および属性値を含む検索対象データを収集する収集手段と、
   前記データソースそれぞれに定義される属性および属性値の組を、前記データソース間共通の正規化属性および正規化属性値の組へ対応付ける属性定義テーブルと、
   前記属性定義テーブルを参照して前記検索対象データを正規化し、対応する正規化属性に関連付けて、正規化属性値と正規化前の属性値とを付与する正規化手段と、
   収集元データソースを識別する情報と、前記対応する正規化属性と、前記正規化属性値と、前記正規化前の属性値とを関連付けて、検索用データとして、データベースに登録する手段と、
   前記データソースそれぞれに対し正規化属性および正規化属性値を対応付けるデータソース属性定義テーブルと
   を含み、前記正規化手段は、データソースを識別して、前記検索用データに、対応する正規化属性および正規化属性値を補足することを特徴とする、情報収集装置。
6. 前記情報収集装置は、さらに、
   前記データソースそれぞれに定義される属性および属性値に含まれる特定表現の組を、前記データソース間共通の正規化属性および正規化属性値の組へ対応付ける特定表現定義テーブルを含み、前記正規化手段は、前記特定表現定義テーブルを参照して前記検索対象データ中の前記特定表現を正規化し、対応する正規化属性に関連付けて、正規化属性値と、正規化前の属性値に含まれる特定表現とを付与することを特徴とする、請求項５に記載の情報収集装置。
7. 請求項５または６に記載の情報収集装置によって検索用データが登録されたデータベースに接続され、複数のデータソースにわたって情報検索するための情報検索装置であって、
   検索クエリに応答して、前記検索クエリに指定される属性の値に合致する正規化属性値または正規化前の属性値を有するデータを検索して検索結果を返す検索手段
   を含む、情報検索装置。
8. 情報処理装置が実行する、複数のデータソースにわたって情報検索するための検索用データを収集する情報収集方法であって、
   前記情報処理装置が、前記データソースにアクセスし、検索対象の情報について属性および属性値を含む検索対象データを収集するステップと、
   前記情報処理装置が、前記データソースそれぞれに定義される属性および属性値の組を、前記データソース間共通の正規化属性および正規化属性値の組へ対応付ける属性定義テーブルを参照して前記検索対象データを正規化し、対応する正規化属性に関連付けて、正規化属性値と正規化前の属性値とを付与するステップと、
   前記情報処理装置が、収集元データソースを識別する情報と、前記対応する正規化属性と、前記正規化属性値と、前記正規化前の属性値とを含む検索用データをデータベースに登録するステップと
   を含み、さらに
   前記データソースそれぞれに対し正規化属性および正規化属性値を対応付けるデータソース属性定義テーブルを参照し、データソースを識別して、前記検索用データに、対応する正規化属性および正規化属性値を補足するステップ
   を含む、情報収集方法。
9. 複数のデータソースにわたって情報検索するための検索用データを収集する情報収集装置を実現するためのコンピュータ実行可能なプログラムであって、前記プログラムは、コンピュータを、
   前記データソースにアクセスし、検索対象の情報について属性および属性値を含む検索対象データを収集する収集手段、
   前記データソースそれぞれに定義される属性および属性値の組を、前記データソース間共通の正規化属性および正規化属性値の組へ対応付ける属性定義テーブル、
   前記属性定義テーブルを参照して前記検索対象データを正規化し、対応する正規化属性に関連付けて、正規化属性値と正規化前の属性値とを付与する正規化手段、
   収集元データソースを識別する情報と、前記対応する正規化属性と、前記正規化属性値と、前記正規化前の属性値とを関連付けて、検索用データとして、データベースに登録する手段、および
   前記データソースそれぞれに対し正規化属性および正規化属性値を対応付けるデータソース属性定義テーブル
   として機能させるためのプログラムであり、前記正規化手段は、データソースを識別して、前記検索用データに、対応する正規化属性および正規化属性値を補足することを特徴とする、プログラム。
10. 請求項９に記載のコンピュータ実行可能なプログラムをコンピュータ可読に格納する記録媒体。
11. 複数のデータソースにわたって情報検索するための情報検索システムであって、
    前記データソースにアクセスし、検索対象の情報について属性および属性値を含む検索対象データを収集する収集手段と、
    前記データソースそれぞれに定義される属性および属性値の組を、前記データソース間共通の正規化属性および正規化属性値の組へ対応付ける属性定義テーブルと、
    前記属性定義テーブルを参照して前記検索対象データを正規化し、対応する正規化属性に関連付けて、正規化属性値と正規化前の属性値とを付与する正規化手段と、
    収集元データソースを識別する情報と、前記対応する正規化属性と、前記正規化属性値と、前記正規化前の属性値とを含む検索用データを格納するデータベースと、
    検索クエリに応答して、前記検索クエリに指定される属性の値に合致する正規化属性値または正規化前の属性値を有するデータを検索して検索結果を返す検索手段と、
    前記データソースそれぞれに定義される属性に対する無機質な属性値を、属性値の意味を提示する提示属性値へ対応付ける属性値変換テーブルと
    を含み、前記正規化手段は、前記属性値変換テーブルを参照して、前記検索対象データ中の前記無機質な属性値を前記提示属性値に変換して、前記正規化前の属性値とすることを特徴とする、情報検索システム。
12. 複数のデータソースにわたって情報検索するための検索用データを収集する情報収集装置であって、
    前記データソースにアクセスし、検索対象について属性および属性値を含む検索対象データを収集する収集手段と、
    前記データソースそれぞれに定義される属性および属性値の組を、前記データソース間共通の正規化属性および正規化属性値の組へ対応付ける属性定義テーブルと、
    前記属性定義テーブルを参照して前記検索対象データを正規化し、対応する正規化属性に関連付けて、正規化属性値と正規化前の属性値とを付与する正規化手段と、
    収集元データソースを識別する情報と、前記対応する正規化属性と、前記正規化属性値と、前記正規化前の属性値とを関連付けて、検索用データとして、データベースに登録する手段と、
    前記データソースそれぞれに定義される属性に対する無機質な属性値を、属性値の意味を提示する提示属性値へ対応付ける属性値変換テーブルと
    を含み、前記正規化手段は、前記属性値変換テーブルを参照して、前記検索対象データ中の前記無機質な属性値を前記提示属性値に変換して、前記正規化前の属性値とすることを特徴とする、情報収集装置。
13. 複数のデータソースにわたって情報検索するための検索用データを収集する情報収集装置を実現するためのコンピュータ実行可能なプログラムであって、前記プログラムは、コンピュータを、
    前記データソースにアクセスし、検索対象の情報について属性および属性値を含む検索対象データを収集する収集手段、
    前記データソースそれぞれに定義される属性および属性値の組を、前記データソース間共通の正規化属性および正規化属性値の組へ対応付ける属性定義テーブル、
    前記属性定義テーブルを参照して前記検索対象データを正規化し、対応する正規化属性に関連付けて、正規化属性値と正規化前の属性値とを付与する正規化手段、
    収集元データソースを識別する情報と、前記対応する正規化属性と、前記正規化属性値と、前記正規化前の属性値とを関連付けて、検索用データとして、データベースに登録する手段、および
    前記データソースそれぞれに定義される属性に対する無機質な属性値を、属性値の意味を提示する提示属性値へ対応付ける属性値変換テーブル
    として機能させるためのプログラムであり、前記正規化手段は、前記属性値変換テーブルを参照して、前記検索対象データ中の前記無機質な属性値を前記提示属性値に変換して、前記正規化前の属性値とすることを特徴とする、プログラム。