JP4146479B2 - 構造化文書検索装置、構造化文書検索方法および構造化文書検索プログラム - Google Patents

Description

この発明は、階層化された論理構造を持つ構造化文書データベースで管理された異なる文書構造の複数の構造化文書を検索する構造化文書検索装置および構造化文書検索方法に関するものである。

近年、ＸＭＬ（eXtensible Markup Language）などで記述された構造化文書情報を記憶・検索する構造化文書データベースが実現されている。構造化文書データベースに対する問合せは、Ｗ３Ｃ（World Wide Web Consortium）が標準化を進めているＸＱｕｅｒｙ（XML Query）という問合せ言語によって行われることが主流となっている。

ＸＱｕｅｒｙはパス（構造）やキーワード（語彙）を指定した検索が可能であり、非常に高い言語記述能力を持つことに特徴がある。例えば、構造条件に関しては「/*」や「//」などの記号を用いて、構造の曖昧性を含んだ形で検索条件を記述することができる。

ＸＱｕｅｒｙでは、要素や属性などのＤＯＭ（Document Object Model）におけるノードレベルの情報を検索対象とする。例えば、特許文献１では、以下の方法により、構造化文書のノードレベルの情報の検索を行う技術が提案されている。

まず、構造化文書をデータベースに格納する際に、対象となる文書のデータ構造を解析し、その構造（ノード）に対する解析情報を語彙索引情報などに埋め込んで索引を作成する。次に、検索時に検索クエリを解析して問合せグラフを作成し、コスト計算をした上でクエリ実行のプランを作成する。そして作成したプランにしたがってクエリを実行し、問合せグラフの構造制約を満たすノードの情報を検索結果として取得する。

このような構造化文書データベース中に格納されるデータは多種に渡り、それらが統一的に管理されるため、結果として構造化文書データベース中には様々なデータ構造（スキーマ）が含まれることになる。ＸＱｕｅｒｙを処理する際はこれら様々なスキーマを有するデータの中から対象候補を「漏れなく」、かつ「高速に」検索（加工）する必要がある。

検索の高速化のためには、従来から（１）特定のパスに対して語彙索引や数値索引を付加する方法、（２）格納対象のデータ構造を解析し、特徴的な構造に対するスキーマ解析情報を抽出する方法などが考えられている。

（１）の方法については、例えば、「/タイトル=“XML"」のような検索を行う場合、＜タイトル＞タグに対して語彙索引を付加することにより、語彙からの逆引きが行えるため、検索の高速化が期待できる。

（２）の方法については、例えば、＜ヘッダ＞の子要素として＜タイトル＞が「必ず」かつ「唯一」存在しているという情報を登録することにより、＜ヘッダ＞の下に＜タイトル＞が存在することを検証する構造照合処理コストを低減できるため、検索の高速化が期待できる。

一方、一般的に検索処理でコストを要する部分は、構造照合処理や値照合処理などに代表されるデータ照合処理である。値照合処理とは、検索キーとして指定された語句（値）が含まれることを検証する処理である。

検索最適化処理を考える上で問題となるのは、いかにコストが低いプランを作成するかであるが、コストが高い代表的な処理が上述のデータ照合処理である。これは実際にデータベース中の構造化文書にアクセスする「データスキャン」を行わなければならないからであるが、一般的にデータスキャンは、索引だけの処理と比較して低速である。

これに対し、特許文献２では、構造化文書の構造情報（親子関係や兄弟関係）を予めＩＤ化しておいてすべての索引情報に付加することにより、索引だけで構造照合を実行可能とし、データスキャンを極力不要とする技術が提案されている。

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

しかしながら、特許文献２などのような索引を利用して検索を高速化する技術では、索引種別が混在する場合に検索処理速度が低下する場合があるという問題があった。

例えば、＜ヘッダ＞の子要素として＜タイトル＞と＜本文＞が存在し、＜タイトル＞に対しては語彙索引（語彙からその位置を特定できる索引）が付加されているが、＜本文＞には語彙索引が付いていない場合を考える。この場合に、「/ヘッダ［.//text（） = "XML"］」などのような複数のパスを条件に指定されると、＜本文＞に関しては索引を用いることができないため値照合処理が必要となり、検索処理速度が低下する。

また、例えば、登録時に解析したスキーマ解析情報により、＜特許＞の下には必ず＜タイトル＞を含み、かつ唯一であることが判明している場合を考える。この場合に、「/ヘッダ［.//text（） = "XML"］」などのような複数のパスを条件に指定されると、＜タイトル＞に関しては構造照合処理が不要であるが、＜本文＞に関しては構造照合処理が必要となるため、検索処理速度が低下する。

すなわち、あるパスは索引等を利用可能なためデータスキャンが不要であり高速に処理できるにも関らず、特定のパスに対してはデータスキャンが発生するために、全体として検索処理速度が低下する場合があった。

一般的に検索処理は、検索条件を解析し、解を求める処理順序を決定した後、処理順序に従いデータ制約を満足する中間候補を残す処理を繰り返すことによって実行される。上記問題は、この中間候補を求める際に候補全件に対して厳密に制約チェックを行う点に起因する。

本発明は、上記に鑑みてなされたものであって、厳密な制約チェックを行わずに制約を緩和することにより、検索処理を高速化することができる構造化文書検索装置、構造化文書検索方法および構造化文書検索プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、階層化された論理構造の単位である構造要素に対応するオブジェクトと、前記オブジェクトを識別するオブジェクトＩＤとを含み、前記論理構造を有する構造化文書情報を記憶する構造化文書記憶手段と、前記構造要素を識別する構造ＩＤと、前記オブジェクトＩＤとを対応づけた構造索引を記憶する構造索引記憶手段と、前記構造化文書情報に含まれる語彙を識別する語彙ＩＤと、前記オブジェクトＩＤとを対応づけた語彙索引を記憶する語彙索引記憶手段と、前記構造ＩＤに前記語彙索引が付加されているか否かを表す判別情報を含む前記構造要素に関する構造情報を記憶する構造情報記憶手段と、入力された検索条件に含まれる検索キーを前記検索キーの検索対象となる前記構造ＩＤに対応づけ、前記検索キーを対応づけた前記構造ＩＤである検索対象構造ＩＤと、前記検索条件の検索結果として取得すべき前記構造ＩＤである検索結果構造ＩＤとを階層構造の単位として含み、前記検索対象構造ＩＤと前記検索結果構造ＩＤとの間で満たすべき前記階層構造に関する構造制約を定めた階層型検索条件を生成する条件生成手段と、前記検索対象構造ＩＤのうち、前記語彙索引が付加されていないことを示す前記判別情報が対応づけられた前記検索対象構造ＩＤについて、前記検索対象構造ＩＤに対応づけられた前記オブジェクトＩＤを前記構造索引記憶手段から取得する第１取得手段と、前記第１取得手段が取得した前記オブジェクトＩＤに前記検索キーを第１制約条件として対応づけ、前記第１制約条件を対応づけた前記オブジェクトＩＤを含む前記検索結果の候補を生成する候補生成手段と、生成された前記候補に含まれる前記オブジェクトＩＤに対応する前記検索対象構造ＩＤに対して、前記階層型検索条件で定めた前記構造制約に適合する前記検索結果構造ＩＤを取得する第２取得手段と、取得した前記検索結果構造ＩＤに対応する前記オブジェクトＩＤのうち前記第１制約条件を満たす前記オブジェクトＩＤに対応する前記オブジェクトを前記構造化文書記憶手段から取得する結果取得手段と、を備えたことを特徴とする。

また、本発明は、上記装置を実行することができる構造化文書検索方法および構造化文書検索プログラムである。

本発明によれば、語彙索引が存在しない場合に構造索引によって候補を取得するように制約を緩和することができるため、検索処理を高速化することができるという効果を奏する。

以下に添付図面を参照して、この発明にかかる構造化文書検索装置、構造化文書検索方法および構造化文書検索プログラムの最良な実施の形態を詳細に説明する。

本実施の形態にかかる構造化文書検索装置は、検索条件における構造の制約や値の制約を処理コストが低くなる制約に緩和し、コストが高い処理を実際のデータ取得する段階まで遅延させることで処理速度の高速化を実現するものである。

これは、制約条件を緩和した場合であっても、結果的に候補として同一となる候補に対する処理をスキップすることを目的としている。処理途中に緩和した候補が別の条件により候補から除外されたときや、取得件数を予め指定したときなどに、その候補自体が不要となる場合があるからである。

以下に、本実施の形態にかかる構造化文書検索装置による構造化文書検索処理の概要を示す。まず、入力された検索条件であるＸＱｕｅｒｙを解析し、データスキャンを極力行わないように制約（値、構造）を緩和した形で検索のプラン（クエリプラン）を生成する。その際、制約を緩和した候補群に対しては緩和した制約（構造、値）から取得処理の優先順位を表す処理優先度を計算し、それぞれの値に付加する。

次に、制約を緩和しなかった候補集合を正確な中間候補とし、それ以外の候補を仮候補として、データ取得段階まで制約を緩和して得られた候補のまま処理を進める。一般的に処理途中の候補はデータベース中で一意に識別されるオブジェクトＩＤ（ＯＩＤ）で管理されるが、仮候補に対しては大域的な情報、例えば、正確ではないが大まかな構造情報を付加し、データ結合時には、その時点までに判明している情報でデータ結合処理等を行う。

最後に、実際にデータを取得する時点で初めて仮候補に対する制約を解除し、条件を満たすものだけを解として値を具体化する。この際コスト（ディスクＩＯ等）が最小になるように、緩和した制約を解除する順序を決定することで高速化を実現する。

このように、本実施の形態は、中間段階の解候補としてはノイズを含む状態で判明している候補だけを残しておき、他の制約によって削除できる候補は可能な限り削除することにより、データ取得の段階まで可能な限り高コストの処理を実行しない点に特徴がある。また、本実施の形態は、遅延させた緩和制約条件の中から高速に処理できるように順序を決定できる点に特徴がある。

構造化文書データベースの検索処理では、索引種別が混在する場合や、パス式中の特定構造のみスキーマ解析が実行される場合が多いため、高コストとなる特定の索引種別または特定構造に関する処理を遅延させることは効果的であるといえる。

なお、後述するように順序を決定するための情報として処理優先度を用いるが、処理優先度は検索精度の向上ではなく、検索処理の高速化を主な目的とする情報である。また、緩和した制約は最終的には除去されるため、厳密な候補を検索結果として取得することができる。

図１は、本実施の形態にかかる構造化文書検索装置１００の構成を示すブロック図である。同図に示すように、構造化文書検索装置１００は、ネットワーク２００を介してクライアント３００と接続されており、通信部１０１と、構造化文書記憶部１４１と、構造情報記憶部１４２と、構造索引記憶部１４３と、語彙索引記憶部１４４と、格納処理部１１０と、検索処理部１２０と、結果取得部１３０と、制約記憶部１５１と、候補記憶部１５２とを備えている。

クライアント３００は、登録する構造化文書（構造化文書）や、登録済みの構造化文書を対象とする検索条件を構造化文書検索装置１００に送信し、検索結果を受信するものである。

ネットワーク２００は、クライアント３００と構造化文書検索装置１００とを接続するもので、例えば、インターネット、有線ＬＡＮ（Local Area Network）、無線ＬＡＮなどのあらゆるネットワーク構成を適用することができる。

通信部１０１は、ネットワーク２００を介して、クライアント３００から各種処理の要求や登録する構造化文書を受信するとともに、検索結果をクライアント３００に送信するものである。

クライアント３００から受信する命令には、格納命令、検索命令、取得命令が含まれる。格納命令は、入力された構造化文書を格納する処理の実行を要求する命令である。検索命令は、問い合わせ言語（ＸＱｕｅｒｙなど）を入力として、結果集合を取得するための命令である。結果集合とは、検索結果であるＯＩＤの集合をいう。

取得命令は、結果集合からユーザが指定した構造化文書の実際のデータを取得するための命令である。この際、ユーザは、結果集合中から何件取得するか、または全件取得するかなどといった取得件数の指定を行うことができる。

通信部１０１が受信した格納命令、検索命令、取得命令は、それぞれ格納処理部１１０、検索処理部１２０、結果取得部１３０に対して通知される。

構造化文書記憶部１４１は、ＸＭＬで記述された構造化文書を記憶する記憶部である。ここで、構造化文書の記述形式について説明する。図２は、ＸＭＬで記述された構造化文書の一例を示す説明図である。

同図では、特許に関する情報をＸＭＬ形式で記述した構造化文書の例が示されている。ＸＭＬでは、文書の構造の表現にタグが用いられる。タグには、開始タグと終了タグが存在し、構造化文書の構成要素を開始タグと終了タグで囲むことにより、文書中の文字列（テキスト）の区切りと、そのテキストが構造上いずれの構成要素に属するのかを明確に記述することができる。

なお、ＸＭＬでは、タグを使って定義したデータの単位を要素という。例えば、＜特許＞タグと＜／特許＞タグとを含み、両タグで囲まれたデータが１つの要素を構成する。

また、要素には、省略可能か、繰り返しが可能かなどの付加的な情報を追加するための属性を指定することができる。属性は、開始タグに「＜要素名称 属性＝"属性値"＞」のような書式で設定する。

また、開始タグとは要素名称を記号「＜」、「＞」で閉じた書式で記載され、終了タグとは要素名称を記号「＜／」と「＞」で閉じた書式で記載される。開始タグと終了タグとの間には、構造化文書の実情報を表すテキスト、または他の要素（子要素）が設定される。「＜特許ＤＢ＞＜／特許ＤＢ＞」のようにテキストを含まない構成要素は、簡易記法として「＜特許ＤＢ／＞」のように表すこともできる。

同図に示した文書は、「特許」タグから始まる要素を文書ルート（根）とし、その子要素として「ヘッダ」、「タイトル」、「本文」、「キーワードリスト」、「キーワード」、「内容」タグから始まる要素を有する。また、例えば、「タイトル」タグから始まる要素には「ＸＭＬＤＢ」といった、１つのテキスト（文字列）が存在する。

なお、このようなＸＭＬ形式の構造化文書から、各タグの名称や階層関係、繰り返しの個数などを抽出した情報を構造情報という。また、構造化文書の構造情報を構成する論理的な構造の単位を構造要素という。本実施の形態では、上述の要素、属性、テキストが構造要素となる。

また、同図に示すように、各文書には構造化文書記憶部１４１内で文書を一意に識別するための文書ＩＤと、文書内で各構造要素を一意に識別する要素ＩＤとが付与されている。なお文書ＩＤと要素ＩＤとを合わせた情報により、構造化文書記憶部１４１内のすべての要素を一意に識別することができる。以下では、この情報をオブジェクトＩＤ（ＯＩＤ）といい、ＯＩＤで特定される要素のことをオブジェクトという。

構造情報記憶部１４２は、上述のようなＸＭＬ形式の構造化文書から抽出された構造情報を格納するものである。構造情報記憶部１４２は、構造化文書記憶部１４１に格納する構造化文書の構造を、構造情報と照合して解析する際に参照される。

図３は、本実施の形態における構造情報記憶部１４２に格納された構造情報のデータ構造の一例を示す説明図である。同図は、構造情報を木構造で表した例を示している。

同図に示すように、階層化された構造情報の単位である構造要素を木構造のノードとし、各ノードには対応する構造要素を一意に識別するための識別子である構造ＩＤ（以下、ＴＩＤ（テンプレートＩＤ）という）が付与されている。構造情報は、複数の構造化文書から、構造を表す情報のみを抽出した情報である。したがって、例えば、図２の「キーワード」タグのノードのように、構造化文書内では複数設定されうる情報であっても、構造情報上では１つに集約される。

また、本実施の形態では、統計情報等を利用して適宜スキーマ解析情報が抽出されることを前提としている。スキーマ解析情報とは、構造化文書の構造を定める情報をいう。図３では、例えば、ヘッダとタイトルとは１対１の関係にあること、すなわち、＜ヘッダ＞の下には必ず＜タイトル＞が１つ存在するというような統計情報がスキーマ解析情報として保持されていることが示されている。

このような場合は、実際にデータスキャンを行ってＯＩＤを求める必要がなく、大域的な構造情報であるＴＩＤだけで構造に対する制約を解決してＯＩＤを特定できる。スキーマ解析情報は、索引から求めた値に対して構造チェックする場合に有効である。例えば、索引から求めたタイトルの要素ＩＤがＥ３である場合、親要素であるヘッダは必ず存在し、その要素ＩＤはＥ２であることを、データスキャンを行わずに求めることができる。

また、同図に示すように、テキスト情報を有するノードに対しては、語彙索引が付加されているか否かを示す判別情報が付与される。同図では、タイトル、本文、内容の各ノードに対して形態素による語彙索引（形態素索引）が付加され、キーワードノードには索引が付加されていないことを表す判別情報が付与された例が示されている。

なお、語彙索引の種別は形態素索引に限られるものではなく、Ｎグラム索引、数値索引などのあらゆる索引を用いることができる。

構造索引記憶部１４３は、ＴＩＤとＯＩＤとを対応づけた構造索引を記憶するものである。すなわち、構造索引を利用することにより、ＴＩＤに対応するＯＩＤのリストを取得することができる。

語彙索引記憶部１４４は、構造化文書記憶部１４１に記憶されたすべての構造化文書に含まれる語彙を識別する語彙ＩＤと、ＯＩＤとを対応づけた語彙索引を記憶するものである。図４は、語彙索引記憶部１４４に格納された語彙索引のデータ構造の一例を示す説明図である。

同図に示すように、語彙索引記憶部１４４は、各語彙の発生順に昇順に付与された語彙の識別子である語彙ＩＤと、語彙の全構造化文書内での発生頻度と、転置ファイル番号とを対応づけた語彙索引を格納している。転置ファイル番号とは、語彙ＩＤに対応する語彙を含む要素に関する情報を含む転置ファイルを一意に識別するための番号をいう。

同図の下部には、転置ファイルのデータ構造の一例が示されている。転置ファイルは、ＴＩＤと、文書ＩＤと、要素ＩＤと、発生位置とを対応づけて格納している。

発生位置とは、当該転置ファイルに対応する語彙が、文書ＩＤと要素ＩＤとで識別される構造化文書の要素内で出現する位置を表す情報である。このような転置ファイルを含む語彙索引により、各語彙に対応するオブジェクト（要素）を特定することができる。なお、これら情報に加えてデータから所定の規則に従い算出したハッシュ値などの特徴量を加えるように構成してもよい。

なお、構造化文書記憶部１４１、構造情報記憶部１４２、構造索引記憶部１４３、および語彙索引記憶部１４４は、ＨＤＤ（Hard Disk Drive）、光ディスク、メモリカード、ＲＡＭ（Random Access Memory）などの一般的に利用されているあらゆる記憶媒体により構成することができる。

格納処理部１１０は、クライアント３００から受信した格納命令に従い、構造化文書、構造化文書から抽出した構造情報および索引を格納する処理を実行するもので、スキーマ解析部１１１と、語彙索引作成部１１２と、構造索引作成部１１３と、登録部１１４とを備えている。

スキーマ解析部１１１は、通信部１０１から取得したテキスト形式のデータである構造化文書を構文解析し、ＤＯＭのようなオブジェクトツリー形式に展開し、木構造の各ノードを特徴的な構造情報として抽出するものである。以下では、このように抽出された木構造の構造情報を構造テンプレートという。

語彙索引作成部１１２は、構造化文書のテキスト部分を語彙分割し語彙索引を作成して語彙索引記憶部１４４に登録するものである。語彙の分割方法としては、語彙索引の種類に応じて形態素解析やＮグラム分割などを適用可能であり、いずれの方法を用いるかをユーザが指定する。

構造索引作成部１１３は、スキーマ解析部１１１で解析したパス（ＴＩＤ）に対するＩＯＤを取得して構造索引として構造索引記憶部１４３に登録するものである。

通常、語彙を指定した検索では、構造索引を用いるより語彙索引を用いたほうが高速になる場合が多い。図５は、構造索引による検索と語彙索引による検索との比較について説明した模式図である。

同図の上部に示すような検索条件「/タイトル=“XML"」が指定された場合は、構造索引を用いた場合は、まず構造索引から「/タイトル」の候補集合｛$1｝を求めた後、それらすべての候補に対してデータスキャンを行い、値として“XML"を含むか否かを検証し、条件を満たす[$2]を求める必要がある。

一方、語彙索引を用いる場合は語彙と構造を関連付けた索引を保持しているので、直接「/タイトル=“XML"」を満たす候補集合[$2]を求めることができるので、探索空間を限定して索引だけで処理が行うことができる。このため、語彙索引を用いた検索のほうが構造索引を用いた検索より高速に実行される。

また、構造索引で問題となるのは構造索引の候補数が過大となる場合である。一般的に構造索引は語彙索引と比較して索引情報として付加する情報の数が少ないことから候補数が増大する場合が多い。これを抑止するため、構造索引の情報量を増やすことによって高速化を行う。例えば、候補となる要素値に対する特徴量を計算し、索引情報として新たに追加する。

また、このように特徴量を付加して構造索引を作成する処理を、語彙索引が付加されていないＴＩＤに対応する要素に対してだけ行うことで必要最小限の索引だけを作成するように構成してもよい。

図６は、図２のような構造化文書情報から作成した構造索引の一例を示す説明図である。同図に示すように、ＴＩＤ＝Ｔ２（タイトル）に対しては語彙索引が付与されているため、文書ＩＤと要素ＩＤとからなるＯＩＤのみをＴＩＤに対応づけた構造索引が生成される。ＴＩＤ＝Ｔ５（キーワード）に対しては語彙索引が付与されていないため、ハッシュ値計算を行い、算出した値（例えば、１２４７）を特徴量として付加した構造索引が生成される。

なお、本実施の形態では、ユーザはＴＩＤごとに語彙索引、構造索引を作成するか否かを指定することができる。設定できる索引種別としては、構造索引、語彙索引の他、特定のＴＩＤに対しては索引を付加しないこと、または、特定のＴＩＤに数値が含まれることが多いことが予め判明している場合には数値索引を付加することを指定することも可能である。このようにデータ内容に応じてＴＩＤごとに索引種別を指定可能とすることにより、さらに検索の高速化が実現可能となる。

登録部１１４は、オブジェクトツリー形式に展開した各ノードに対して親子兄弟関係を付加し、構造化文書記憶部１４１に格納するものである。なお、スキーマ解析部１１１で解析された各ノードに対応するオブジェクトに対しては、ユニークなＯＩＤが付加され、構造化文書記憶部１４１に記憶される。

検索処理部１２０は、クライアント３００から受信した検索命令に従い、入力された検索条件に対して検索処理を実行して結果集合を生成するものであり、検索処理部１２０は、条件生成部１２１と、クエリプランニング部１２２と、クエリ実行部１２３とを備えている。

なお、検索処理部１２０に入力される検索条件はＸＱｕｅｒｙなどの構造化文書に対するクエリ言語であることを前提とする。また、検索処理部１２０は、特許文献１に記載された方法と同様に、検索条件を解析した内部形式から検索条件を木構造で表したクエリグラフを作成し、クエリグラフに含まれるすべての変数の具体化を目標として、テーブルと呼ばれる変数集合の取り得る値（候補集合）の組み合わせを表すデータを次々と生成することにより検索結果を求めるものである。１つのテーブルを生成する単位処理をオペレータと呼び、各オペレータの結果は、候補集合として候補記憶部１５２（後述）に保存される。

条件生成部１２１は、入力された検索条件を構文解析（パージング）し、解析結果としてクエリグラフを生成するものである。この際、各ノードが満たさなければならない構造に対する制約条件を付加する。図７は、クエリグラフの一例を示す説明図である。

同図では、検索条件（クエリ）として、「配下のオブジェクトのテキストに“ＸＭＬ”を含み、かつ配下のタイトルオブジェクトのさらに配下のテキストに“ＳＧＭＬ”を含む特許文書に含まれるヘッダオブジェクトを取得し、“＜検索結果＞”タグで囲った検索結果データを出力する」ことを意味する検索条件が入力された例が示されている。

同図に示すように、クエリグラフは構造情報の各構造要素に対応したノードを含む木構造で表される。例えば、同図のクエリグラフのノード２は、ヘッダタグが対応することを示している。また、例えば、ノード３はタイトルタグが、ノード４はタイトルタグ下のテキスト要素が対応することを示している。

また、クエリグラフの各ノードには、ノードが相互に満たさなければならない構造に関する構造制約が付加される。例えば、クエリグラフのノード４はタイトルタグ下のテキスト要素でなければならないといった制約が構造制約として付加される。この場合、ノード４には、対応する構造要素の候補として、ＴＩＤ＝Ｔ２の構造要素が取得される。同様に、ノード６に対してはＴＩＤ＝Ｔ３の構造要素が、ノード８に対してはＴＩＤ＝Ｔ５の構造要素が、ノード１２に対してはＴＩＤ＝Ｔ８の構造要素が候補として取得される。

構造要素に対する検索条件（以下、検索キー）、すなわち、構造要素に含まれるテキストの値に関する値制約が存在する場合は、当該検索キーを、検索キーの検索対象となる構造要素に対応するノードに対応づける。例えば、ノード４に対応するタイトルタグ下のテキスト要素に対して検索キーとして「contains “SGML”」が対応づけられている。

検索キーが付与されたノードに対応するＴＩＤは、検索キーを満たすか否かを判定する必要があることを意味する。以下では、このようなＴＩＤを検索対象ＴＩＤという。また、検索結果として取得するノードに対応するＴＩＤを以下では検索結果ＴＩＤという。例えば、同図では、Ｔ２、Ｔ３、Ｔ５、Ｔ８が検索対象ＴＩＤであり、Ｔ１が検索結果ＴＩＤである。

このように、条件生成部１２１は、構造情報記憶部１４２を参照して、検索条件と構造化文書の大域的な構造情報（ＴＩＤ）を照合してクエリグラフを作成することにより、探索空間を絞り込む処理を実行している。探索空間を絞り込むことによって、索引情報をスキャンする際に不必要な情報をスキップすることができ、高速に検索処理が実行されることが期待される。

図８は、語彙索引により検索した候補集合から候補を絞り込む過程を表した模式図である。同図に示すように、例えば条件生成部１２１が生成したクエリグラフの構造制約から、候補がＴＩＤ＝｛Ｔ７、Ｔ１１｝に特定されている場合は、語彙索引による候補集合から当該ＴＩＤ以外のＴＩＤを有する候補を除去することで探索空間を限定することができる。

クエリプランニング部１２２は、クエリグラフから、処理コストが最小になるようなプラン（処理順序）を作成するものである。具体的には、クエリプランニング部１２２は、コストが高いデータスキャン（ディスクスキャン）を極力回避するように、値制約および構造制約を緩和してプラン生成を行う。

制約の緩和とは、データスキャンが必要な制約を、実際には解ではない候補（ノイズ）を取得する可能性はあるが解を漏れなく取得しうる制約であって、データスキャンが不要となる制約に置き換えることを意味する。

クエリ実行部１２３は、クエリプランニング部１２２が作成したプランに従って検索を行って検索結果である結果集合を取得するものであり、値制約処理部１２４と、第２取得部１２８とを備えている。

値制約処理部１２４は、クエリグラフに含まれる制約のうち、値制約を満たす候補を取得する処理を行うものである。具体的には、値制約処理部１２４は、語彙索引を利用して、クエリグラフに含まれる値制約を満たす候補を取得する処理である索引スキャンオペレータを実行する。値制約処理部１２４は、第１取得部１２５と、第３取得部１２６と、候補生成部１２７とを備えている。

第１取得部１２５は、語彙索引が付加されていないＴＩＤに対して、構造索引を用いることにより、値制約を緩和した制約により候補となるＯＩＤを取得するものである。具体的には、第１取得部１２５は、検索対象ＴＩＤに対応するＯＩＤを構造索引記憶部１４３から取得することにより、取得したＯＩＤを検索結果の候補として取得する。

通常、語彙索引が存在しないＴＩＤに対してはデータスキャンを行って検索キーを満たすＯＩＤを取得する必要がある。これに対し、本実施の形態では、第１取得部１２５により、単に構造索引からＴＩＤに対応するＯＩＤを取得する。これにより、高コストのデータスキャン処理を回避しつつ、実際の解を含む候補を取得できる。なお、取得したＯＩＤに対しては、最終的に検索キーを満たすＯＩＤに絞り込むために必要な制約条件が候補生成部１２７（後述）によって付加される。

第３取得部１２６は、語彙索引が付加されているＴＩＤに対して、語彙索引を用いて値制約を満たす候補を取得するものである。具体的には、第３取得部１２６は、検索キーに含まれる語彙の語彙ＩＤに対応するＯＩＤを語彙索引記憶部１４４から取得することにより、値制約を満たすＯＩＤを検索結果の候補として取得する。

候補生成部１２７は、第１取得部１２５および第３取得部１２６が取得したそれぞれの候補を統合して１つの値制約に対する検索結果の候補を生成するものである。具体的には、まず、候補生成部１２７は、第１取得部１２５が取得したＯＩＤに対して、検索キーを制約条件として対応づける。次に、候補生成部１２７は、制約条件を対応づけたＯＩＤと、第３取得部１２６が取得したＯＩＤとを検索結果の候補として生成する。

なお、候補に対応づけられる制約条件は、制約記憶部１５１に記憶される。図９は、制約記憶部１５１に記憶される制約条件のデータ構造の一例を示す説明図である。同図に示すように、制約記憶部１５１は、制約条件を一意に識別する制約ＩＤと、制約条件の内容を表す制約とを対応づけて格納している。

また、候補生成部１２７が生成した検索結果の候補は、候補記憶部１５２に記憶される。図１０は、候補記憶部１５２に記憶される候補のデータ構造の一例を示す説明図である。同図に示すように、候補記憶部１５２は、文書ＩＤと、ＴＩＤと、要素ＩＤと、制約ＩＤと、処理優先度とを対応づけた候補を格納している。

制約ＩＤは、制約記憶部１５１に記憶されている制約条件を特定するための情報であり、制約条件が付加されていない場合には空欄となる。処理優先度とは、結果取得部１３０（後述）が検索結果を取得するときの優先順位を表す情報であり、０以上１以下の値を取る。制約が付加されていない候補の取得処理が最優先されるため、制約が付加されていない候補の処理優先度には１が設定される。

なお、制約記憶部１５１および候補記憶部１５２は、ＨＤＤ、光ディスク、メモリカード、ＲＡＭなどの一般的に利用されているあらゆる記憶媒体により構成することができるが、検索処理の中間データとして生成される候補や制約条件を記憶するものであるため、高速にアクセス可能なＲＡＭ等で構成するのが望ましい。

第２取得部１２８は、クエリグラフに含まれる制約のうち、構造制約を満たす候補を取得する処理を行うものである。具体的には、第２取得部１２８は、候補生成部１２７が生成した候補に対し、構造制約を満たすか否かを確認する処理である構造照合オペレータを実行する。

すなわち、第２取得部１２８は、候補生成部１２７が生成した候補に含まれるＯＩＤに対して構造制約を満たすＯＩＤであって、検索結果として取得する検索結果ＴＩＤに対応するＯＩＤを取得する。対応するＯＩＤを取得できない候補は、構造制約を満たさない候補としてこの時点で削除される。この際、第２取得部１２８は、構造制約を緩和した制約により候補となるＯＩＤを取得する。構造制約の緩和の詳細については後述する。

通常、構造照合では、索引から求めた候補集合が構造制約を満たすかどうかを、厳密に実際のデータアクセスを行ってチェックする必要がある。これに対し、本実施の形態では、第２取得部１２８により構造制約を緩和し、高コストのデータスキャン処理を回避しつつ、実際の解を含む候補を取得できる。

なお、取得したＯＩＤに対しては、最終的に構造制約を満たすＯＩＤに絞り込むために必要な制約条件が第２取得部１２８によって付加される。また、付加された制約条件は、制約記憶部１５１に保存される。

結果取得部１３０は、クライアント３００から受信した取得命令に従い、指定された件数の検索結果を取得してクライアント３００に送信するものである。取得命令には、結果集合に対して取得すべき件数が含まれる。なお、取得件数は全件であってもよい。結果取得部１３０は、順序決定部１３１と、制約解決部１３２と、結果生成部１３３とを備えている。

順序決定部１３１は、検索結果の取得順序を決定するものである。具体的には、順序決定部１３１は、制約を緩和していない候補を優先的に割り当て、制約を緩和した候補に対しては、処理優先度の高い順に処理を行うように順序を決定する。この際、同一文書中に含まれる候補または同一文書内でより近傍に存在する候補を優先的に処理する。なお、これらの順序決定方法はユーザにより指定できるものとする。

制約解決部１３２は、値制約および構造制約を緩和することによって付加された制約条件を解決して、各制約を満たす候補を取得するものである。例えば、制約解決部１３２は、値制約の緩和によって検索キーが対応づけられた候補が存在する場合に、当該候補から検索キーを満たす候補のみを抽出して検索結果の候補として取得する。

結果生成部１３３は、制約解決部１３２によって取得された検索結果の候補を参照し、クライアント３００に返信すべき文字列データを生成するものである。具体的には、結果生成部１３３は、候補として取得されたＯＩＤに対応する構造化文書内のオブジェクトを構造化文書記憶部１４１から取得し、取得したオブジェクトをクライアント３００に返信する文字列データとして生成する。

次に、このように構成された本実施の形態にかかる構造化文書検索装置１００による構造化文書検索処理について説明する。なお、構造化文書検索処理とは、クライアント３００から検索命令を受けて検索処理部１２０が結果集合を返す処理を指している。図１１は、本実施の形態における構造化文書検索処理の全体の流れを示すフローチャートである。

まず、通信部１０１は、クライアント３００から検索条件（検索クエリ）を受信する（ステップＳ１１０１）。次に、条件生成部１２１が、受信した検索クエリを解析し、クエリグラフを生成する（ステップＳ１１０２）。

次に、クエリプランニング部１２２が、クエリグラフを参照して、コストを最小とするプランを作成するクエリプランニング処理を実行する（ステップＳ１１０３）。クエリプランニング処理の詳細については後述する。

次に、クエリ実行部１２３が、作成されたプランに従って検索処理を行うクエリ実行処理を行う（ステップＳ１１０４）。クエリ実行処理の詳細については後述する。

次に、通信部１０１が、クエリ実行処理の検索結果である結果集合をクライアント３００に送信し、構造化文書検索処理を終了する（ステップＳ１１０５）。

次に、ステップＳ１１０３のクエリプランニング処理の詳細について説明する。まず、クエリプランニング処理で考慮されるプランの概要について説明する。図１２は、クエリプランニング処理で生成されるプランの一例を示した説明図である。

例えば、「//特許［contains（.//text（）、"XML"）］」のような検索クエリを考えた場合、クエリプランとして、プラン１：ドキュメントスキャン（データスキャン）してテキスト取得した後、「XML」が含まれる値を照合するプラン（上位からトラバース）と、プラン２：索引スキャンを行い「XML」を含む候補であるポスト情報を取得した後、その親要素に「特許」タグが存在するか否かを構造照合により判断するプラン（下位からトラバース）の２通りのプランが考えられる。

一般的にデータスキャンの個数が増えるほどその処理速度は低下することから、プラン２のほうが低コストである。したがって、プラン２を選択することが望ましい。一方、漏れなくデータを検索することを考慮すると、プラン２を選択するためには、「特許」以下のすべての構造要素に対して索引情報が付加されている必要がある。

すべての構造要素に索引が付加されていない場合は、データスキャンのコストが増大するため、プラン１が選択される可能性もある。しかし、ある一部の構造要素にのみ索引が付与されていない状況では、プラン２を選択したほうが効率的である。本実施の形態では、これを実現するために、上述のような値制約の緩和や構造制約の緩和を行う。制約を緩和してデータスキャン不要とすれば、プラン２が選択される可能性が高くなるためである。

値制約の緩和とは、上述のように、探索すべき構造要素を索引が付与されている構造要素と付与されていない構造要素を分離し、索引が付与されていない構造に対しても仮想的に索引が付与されているものとして索引スキャンオペレータを実行することを意味する。

構造制約の緩和は、一般的には索引スキャンオペレータの後、索引のポスト情報から各候補が構造制約を満たすか否かをチェックする構造照合オペレータにおける処理コストを低減するために利用される。

以下では、プラン２が選択されるような検索条件が入力されたことを前提とし、プラン２を選択する際のクエリプランニング処理について説明する。実際のクエリプランニング処理では、制約を緩和した際に発生するノイズを含めた個数やデータスキャンの個数などを統計情報などから算出して処理コストを計算し、プラン１、プラン２を含むすべてのプランから、最もコストが低いプランが生成される。

次に、ステップＳ１１０３のクエリプランニング処理の処理フローについて説明する。図１３は、本実施の形態におけるクエリプランニング処理の全体の流れを示すフローチャートである。

まず、クエリプランニング部１２２は、値制約を満たす候補を取得するプラン生成のために、検索対象ＴＩＤの集合（以下、ＴＷという。）を取得する（ステップＳ１３０１）。クエリプランニング部１２２は、クエリグラフから検索キーが対応づけられたＴＩＤを取得することによりＴＷを取得可能である。

次に、クエリプランニング部１２２は、ＴＷを、語彙索引が存在するＴＩＤの集合（以下、Ｐ１という。）と、語彙索引が存在しないＴＩＤの集合（以下、Ｐ２という。）に分離する（ステップＳ１３０２）。クエリプランニング部１２２は、構造情報記憶部１４２を参照して、各ＴＩＤに付与された判別情報によって、語彙索引の有無を判断する。

次に、クエリプランニング部１２２は、Ｐ２が空か否かを判断する（ステップＳ１３０３）。空である場合、すなわち、すべてのＴＩＤに語彙索引が付与されている場合は（ステップＳ１３０３：ＹＥＳ）、クエリプランニング部１２２は、語彙索引による制約条件によって候補を求めるプランを作成する（ステップＳ１３０６）。語彙索引を用いてデータスキャンせずに候補を求められるため、制約を緩和する必要がないためである。

Ｐ２が空でない場合、すなわち、語彙索引が付与されていないＴＩＤが存在する場合は（ステップＳ１３０３：ＮＯ）、クエリプランニング部１２２は、Ｐ２の各候補の値制約を緩和するプランを作成する（ステップＳ１３０４）。具体的には、クエリプランニング部１２２は、データスキャンを行って値制約を満たす候補を取得するプランではなく、構造索引を満たすだけの候補を取得するプランを作成する。

次に、クエリプランニング部１２２は、Ｐ１の各候補の制約条件と、Ｐ２に対してステップＳ１３０４で緩和した制約条件とをマージした条件によって候補を求めるプランを生成する（ステップＳ１３０５）。これにより、値制約を満たす候補を取得する処理である索引スキャンオペレータのためのプランが作成される。

次に、クエリプランニング部１２２は、構造制約を緩和するプランを作成する（ステップＳ１３０７）。具体的には、クエリプランニング部１２２は、索引から求めた候補集合が構造制約を満たすか否かを、厳密に実際のデータアクセスを行ってチェックするプランではなく、構造情報上の対応するＴＩＤに置き換えるだけの処理を行うプランを作成する。

このように、構造制約の緩和は無条件にＴＩＤを置き換えるだけの処理であるため、値制約の緩和と異なり、得られた候補集合は実際に存在しないＯＩＤを差す可能性があることに特徴がある。

次に、ステップＳ１１０４のクエリ実行処理の詳細について説明する。図１４は、本実施の形態におけるクエリ実行処理の全体の流れを示すフローチャートである。

クエリ実行処理では、クエリプランニング処理で作成されたプランに従った検索処理が実行されるが、ここでは、値制約と構造制約が緩和され、上述のプラン２が選択された場合に実行される検索処理について説明する。

まず、第３取得部１２６が、語彙索引による候補の取得処理を実行する（ステップＳ１４０１）。具体的には、第３取得部１２６は、語彙索引が付加されているＴＩＤについて、ＴＩＤに対応づけられた検索キーに含まれる語彙の語彙ＩＤに対応するＯＩＤを、検索結果の候補として語彙索引記憶部１４４から取得する。

次に、第１取得部１２５が、値制約を緩和した条件による候補の取得を実行する（ステップＳ１４０２）。具体的には、第１取得部１２５は、語彙索引が付加されていないＴＩＤに対応するＯＩＤを、検索結果の候補として構造索引記憶部１４３から取得する。

次に、候補生成部１２７が、第３取得部１２６および第１取得部１２５が取得した候補をマージした検索結果の候補を作成する（ステップＳ１４０３）。具体的には、候補生成部１２７は、第１取得部１２５が取得したＯＩＤについては検索キーを制約条件として対応づけて候補とし、第３取得部１２６が取得したＯＩＤについては取得したＯＩＤをそのまま検索結果の候補とする。ここまでの処理で、値制約を解決した候補が取得される。

図１５は、値制約を解決して取得した候補の一例を示す説明図である。同図は、図２、図３のような情報が構造化文書記憶部１４１および構造情報記憶部１４２にそれぞれ記憶され、「//特許［contains（.//text（）、"XML"）］」という検索条件が入力されたときの値制約の緩和について示したものである。

例えば、文書ＩＤ＝Ｆ１の構造化文書は、図３に示すようにＴＩＤ＝Ｔ２については語彙索引が付与されているが、ＴＩＤ＝Ｔ５については語彙索引が付与されていない。このため、候補６件のうち、候補２、３、５に関しては値制約を緩和した条件（「//特許//text()」）によって構造索引から求めた値（Ｆ１：Ｅ６、Ｆ１：Ｅ７、Ｆ２：Ｅ４）が求められる。

また、図１５に示すように、候補２、３、５に対しては、結果取得時に参照する制約条件の制約ＩＤ＝２が付与されている。この例では、図９に示すような制約と同様に、制約ＩＤ＝２の制約条件として「contains “XML”」が付与される。

さらに、制約条件を付加した候補２、３、５に対しては、付与した制約条件を具体化するのに必要なコストの見積もり値である処理優先度を付与する。処理優先度の算出方法としては、例えばクエリプランにおける処理の進行度を考慮し、結果を取得するプランに近いほど後戻りが発生した場合のコストが高いことから、処理優先度の値を小さく設定する方法などが適用できる。

このように、クエリ実行時の中間候補に埋め込まれた制約条件は、データ取得要求を受信する時点まで、当該制約条件を満たす候補の検索処理が遅延されることになる。

図１４に戻り、第２取得部１２８が、構造制約を緩和した条件による候補の取得を実行する（ステップＳ１４０４）。以下に、第２取得部１２８による構造制約の緩和の詳細について説明する。図１６は、ＸＭＬで記述された構造化文書の一例を示す説明図である。

同図に示すような構造化文書に対して、「//ヘッダ［contains（./タイトル/text（）、“XML"）］」が検索条件として指定された場合、語彙索引から取得した候補集合の要素ＩＤはＥ３、Ｅ１３となる。

取得した要素ＩＤ等の情報だけでは、検索結果として取得すべき親要素のＴＩＤを取得することは可能であるが（図３の例ではＴ１）、スキーマ解析情報が抽出されていない場合は、当該親要素の要素ＩＤを求めることはできない。この場合、通常はデータスキャンにより親要素の要素ＩＤを求める必要がある。

本実施の形態では、第２取得部１２８が、この制約実行を遅延させて、要素ＩＤを不定値（遷移前の値）にしたまま、ＴＩＤだけ遷移後の値にすることにより、構造制約を緩和した候補の取得を行う。

ここで、遷移前の値とは、構造制約を解決する前の候補の値をいい、遷移後の値とは、構造制約を解決した後の候補の値をいう。したがって、ＴＩＤだけ遷移後の値にするとは、実際には構造制約を満たすか否かをチェックしていないが、構造制約を満たすべき親要素のＴＩＤで無条件に置換することを意味する。

図１７は、構造制約を解決して取得した候補の一例を示す説明図である。同図は、図１６、図３のような情報が構造化文書記憶部１４１および構造情報記憶部１４２にそれぞれ記憶され、「//ヘッダ［contains（./タイトル/text（）、“XML"）］」という検索条件が入力されたときの構造制約の緩和について示したものである。

この場合、Ｅ３やＥ７に対してＴ２を親要素のＴＩＤとして有するか否かをチェックし、有する場合に親要素の要素ＩＤを正確に求めることをせずに、遷移前の要素ＩＤと遷移後のＴＩＤを候補として残しておく。そして、制約条件として、「relation［Ｔ２、Ｔ３］」を付与し、要素ＩＤはそのままとして処理を続行して正確な候補の取得処理をデータ取得時まで遅延させる。

このように、値制約と構造制約を適宜緩和することで、その制約に対するコストを削減することが可能で、結果的に高速に検索処理を実行することが可能となる。

なお、構造制約を緩和した場合も、値制約の緩和と同様に、候補に対して処理優先度が付与される。処理優先度の算出方法としては、例えば親構造を求めるための構造の段数が小さい候補に大きい値を設定する方法や、クエリプランにおける処理の進行度を考慮した方法などが適用できる。

図１４に戻り、クエリ実行部１２３が、候補集合結合処理を実行する（ステップＳ１４０５）。候補集合結合処理とは、プラン実行中に生成された中間候補を結合する処理であり、制約を緩和した候補間の結合処理や、重複除去処理を含む。候補集合結合処理の詳細については後述する。

次に、クエリ実行部１２３が、結合した候補を結果集合として出力し（ステップＳ１４０６）、クエリ実行処理を終了する。

次に、ステップＳ１４０５の候補集合結合処理の詳細について説明する。図１８は、候補集合結合処理の全体の流れを示すフローチャートである。

まず、クエリ実行部１２３は、結合対象の候補集合Ａ１、Ａ２を取得する（ステップＳ１８０１）。次に、クエリ実行部１２３は、Ａ１、Ａ２からそれぞれ候補を１つずつ取り出し、それぞれＣ１、Ｃ２とする（ステップＳ１８０２）。

次に、クエリ実行部１２３は、Ｃ１およびＣ２の文書ＩＤおよびＴＩＤがそれぞれ一致するか否かを判断し（ステップＳ１８０３）、一致する場合は（ステップＳ１８０３：ＹＥＳ）、さらにＣ１、Ｃ２がともに制約を緩和した候補か否かを判断する（ステップＳ１８０４）。

ともに制約を緩和した候補である場合は（ステップＳ１８０４：ＹＥＳ）、クエリ実行部１２３は、Ｃ１、Ｃ２を結合し、結合した候補に対して制約緩和情報を引き継ぐ（ステップＳ１８０５）。また、クエリ実行部１２３は、結合した候補を候補集合に残す（ステップＳ１８０７）。具体的には、クエリ実行部１２３は、以下のようにして候補の結合を行う。

まず、クエリ実行部１２３は、結合する２つの候補を中間処理時に候補記憶部１５２に記憶したときのアドレスをそれぞれ候補に付与する。図１９は、制約緩和した候補を結合する処理の一例を示す説明図である。

同図は、候補集合であるリスト１、リスト２に対する結合作業と、制約緩和条件の指定方法および制約解除の方法の一例を示したものである。なお、リスト１は、「start-with（.//text（）、“SGML"）」という検索キーに対する候補集合を表し、リスト２は、「contains（.//text（）、“XML"）」という検索キーに対する候補集合を表す。

リスト１の候補の１つであるレコード５、およびリスト２の候補の１つであるレコード２０ともに、制約緩和を行った候補であるため制約ＩＤが付加されているが、両レコードは、文書ＩＤ（Ｆ１）とＴＩＤ（Ｔ２）とが一致する。したがって、要素ＩＤを不定値にしたまま結合結果としても文書ＩＤとＴＩＤとをそのまま残しておく。この際、結合元になる２つのレコードのアドレス（＊１、＊２）を残しておくことで、後で制約緩和した候補の具体化を行うことができる。

なお、制約を解除する際には、アドレスが記述されている場合はそれら分岐元のアドレスを辿ることで制約解除を行うことができる。ただし、この処理自体はコストが高いので、制約を解除する順序としての優先度を極力下げるような戦略を取ることが望ましい。このため、同図に示すように結合後のレコードの処理優先度は低く設定されている。

このように、結合処理の場合は、要素ＩＤを未確定としたまま、そのときまでに確定している情報である文書ＩＤとＴＩＤだけで一致するものを結合し、両ＩＤが一致しないものを削除する。未確定な要素に対しても文書ＩＤとＴＩＤで結合処理を行い、一致しない候補をこの段階でフィルタすることで、結果的に要素ＩＤを具体化するという高コストの処理をスキップすることができる。

ステップＳ１８０４で、Ｃ１、Ｃ２がともに制約を緩和した候補でない場合は（ステップＳ１８０４：ＮＯ）、クエリ実行部１２３は、要素ＩＤが一致するか否かを判断する（ステップＳ１８０６）。

要素ＩＤが一致する場合は（ステップＳ１８０６：ＹＥＳ）、一致する候補同士を結合した候補を候補集合に残す（ステップＳ１８０７）。

ステップＳ１８０３で、Ｃ１およびＣ２の文書ＩＤおよびＴＩＤが一致しないと判断された場合（ステップＳ１８０３：ＮＯ）、または、ステップＳ１８０６で要素ＩＤが一致しないと判断された場合（ステップＳ１８０６：ＮＯ）、クエリ実行部１２３は、Ａ１、Ａ２内のすべての候補を処理したか否かを判断する（ステップＳ１８０８）。

すべての候補を処理していない場合は（ステップＳ１８０８：ＮＯ）、クエリ実行部１２３は、次の候補を取得して処理を繰り返す（ステップＳ１８０２）。

すべての候補を処理した場合は（ステップＳ１８０８：ＹＥＳ）、クエリ実行部１２３は、すべての候補集合を処理したか否かを判断する（ステップＳ１８０９）。すべての候補集合を処理していない場合は（ステップＳ１８０９：ＮＯ）、クエリ実行部１２３は、次の候補集合を取得して処理を繰り返す（ステップＳ１８０１）。

すべての候補集合を処理した場合は（ステップＳ１８０９：ＹＥＳ）、候補集合結合処理を終了する。

なお、図１８では、制約条件を候補内に複数指定する場合の例として、複数の制約緩和候補を結合する場合の例について説明した。制約条件を候補内に複数指定する場合としては、中間候補の生成時に、制約を緩和した候補に対してさらに制約を緩和する場合も考えられる。以下では、この場合の候補の生成処理について説明する。

図２０は、制約緩和した候補にさらに制約の緩和を行う処理の一例を示す説明図である。同図は、候補集合であるリスト１に対して構造制約を緩和し、さらに構造制約を緩和した場合の候補の内容の一例を示したものである。

なお、リスト１は、「contains（.//text（）、“XML"）」という検索キーに対する候補集合を表す。また、同図は、リスト１に対し、親要素にタイトルが存在することを表す構造制約（.//タイトル）と、さらに親要素にヘッダが存在することを表す構造制約（.//ヘッダ）と、を緩和して加えることを示している。

この場合、リスト１に対して、親構造にタイトル（ＴＩＤ＝Ｔ２）を含むものを求めるが、この段階ではデータスキャンを行わず、遷移先のＴＩＤ＝Ｔ２だけを残して制約条件が付加される。図２１は、このときの制約条件の一例を示す説明図である。

図２０の例に対しては、図２１の制約ＩＤ＝３の制約（relation［Ｔ２、Ｔ４］）が付与され、制約を緩和したあとの候補集合であるリスト２のレコードには、制約ＩＤ（＝３）が付与される。

その後、さらに親構造にヘッダ（ＴＩＤ＝Ｔ１）を含むものを求めるが、この段階では、リスト２の条件を引き継ぐために、制約条件として遷移前のアドレス（＊１）と、制約条件が付加される。ここでは、図２１の制約ＩＤ＝４の制約（制約ＩＤ＝３、relation［Ｔ１、Ｔ２］）が付与される。

以上で、検索処理部１２０による構造化文書検索処理について説明した。構造化文書検索処理では、クエリプランを最後まで実行した結果が候補記憶部１５２に保存される。この段階では、緩和した制約から求めた候補に対しては制約を解除していないのでノイズを含んだ情報である。クライアント３００には結果集合と、この状態での結果件数を返すため、ユーザは取得件数の概略の見積もりを知ることが可能となる。

ユーザは、結果集合を参照し、結果集合から取得する件数、または全件取得することを指定する取得命令を構造化文書検索装置１００に送信する。取得命令を受信すると、結果取得部１３０による結果取得処理が実行される。

結果取得処理は、制約を解除していない候補を具体化し、指定された件数の検索結果を返す処理である。以下に、結果取得処理の具体例について説明する。

まず、順序決定部１３１が、結果を取得する順序を決定する。図２２は、順序決定方法の一例を説明するための模式図である。同図は、結果集合として５件の候補がクライアント３００に返信された例を示している。

この結果集合に対し、例えば、ユーザにより結果取得件数として１件が指定された場合は、順序決定部１３１は、各候補単体での処理優先度の高い（１）候補１のみを含む候補集合２２０１を優先的に処理することを決定する。

また、例えば、ユーザにより結果取得件数として３件が指定された場合は、順序決定部１３１は、候補単体の処理優先度は低いが（０．７）、同一文書（文書ＩＤ＝Ｆ３）に含まれる候補をまとめて処理することが可能な候補３、４、５を含む候補集合２２０２を優先的に処理することを決定する。同一文書内に含まれる候補であれば、データスキャンコストを削減することが可能と判断できるからである。同様に、同一文書内で要素ＩＤが近い候補を優先して処理するように構成してもよい。

順序決定後、緩和した制約を含む候補が存在する場合には、制約解決部１３２による制約を具体化する処理が実行される。

例えば、図１９に示すような値制約を緩和した候補を具体化する場合を考える。なお、制約記憶部１５１には、図２１に示すような制約条件が記憶されているものとする。

この場合、結合後のレコードのアドレス（＊１）を参照してリスト１のレコード５の情報を候補記憶部１５２から読出し、読み出したレコード５の制約の具体化を行う。すなわち、レコード５のＯＩＤ（＜Ｆ１、Ｅ３＞）が、制約ＩＤ＝１の制約条件である「starts-with "SGML"」を満たすことを確認する。

次に、結合後のレコードのアドレス（＊２）を参照してリスト２のレコード２０の情報を候補記憶部１５２から読出し、読み出したレコード２０の制約の具体化を行う。すなわち、レコード２０のＯＩＤ（＜Ｆ１、Ｅ７＞）が、制約ＩＤ＝２の制約条件である「contains "XML"」を満たすことを確認する。

そして、ＯＩＤ＝＜Ｆ１、Ｅ３＞の要素から親要素に辿り、ＴＩＤ＝Ｔ２となる要素の要素ＩＤを求める。ここでは、例えば、Ｅ１が求まったとする。さらに、ＯＩＤ＝＜Ｆ１、Ｅ７＞の要素から親要素に辿り、ＴＩＤ＝Ｔ２となる要素の要素ＩＤを求め、Ｅ１であったとすれば、解候補としてＯＩＤ＝＜Ｆ１、Ｅ１＞が確定する。

この制約解除の途中で、一つでも制約を満たさない候補が存在した場合、その時点で当該候補は解になりえないと判断できるため、処理を中断する。

次に、図２０に示すような構造制約を緩和した候補を具体化する場合を考える。なお、制約記憶部１５１には、図２１に示すような制約条件が記憶されているものとする。

この場合、結合後の候補集合であるリスト３のアドレス（＊１）を参照してリスト２の情報を候補記憶部１５２から読出し、読み出したリスト２に関する制約の具体化を行う。すなわち、ＯＩＤ＝＜Ｆ１、Ｅ５＞が、制約ＩＤ＝３の制約条件である「relation［Ｔ２、Ｔ４］」を満たすことを確認する。ここでは、この制約条件を満たす要素ＩＤ＝Ｅ２が取得できたものとする。さらに、ＯＩＤ＝＜Ｆ１、Ｅ２＞に対して、制約ＩＤ＝４の制約条件である「relation［Ｔ１、Ｔ２］」を満たす親要素、すなわち、ＴＩＤ＝Ｔ１である親要素の要素ＩＤを求める。例えば、Ｅ１が求められた場合は、解候補としてＯＩＤ＝＜Ｆ１、Ｅ１＞が取得される。

次に、構造化文書検索処理の具体例についてさらに説明する。以下では、図２および図３に示すような情報がそれぞれ構造化文書記憶部１４１および構造情報記憶部１４２に記憶されていることを前提として説明する。

図２３は、入力された検索条件の一例を示す説明図である。同図の検索条件の左側の条件から、「//ヘッダ//text（）」の構造制約、すなわち、「ヘッダ」下のいずれかの構造要素にテキスト情報を有する構造要素が含まれていることを示す構造制約が得られる。この場合、図３に示すような構造情報から、［Ｔ２、Ｔ３、Ｔ５、Ｔ８］が構造制約として取得できる。なお、構造制約［Ｔ２、Ｔ３、Ｔ５、Ｔ８］とは、解候補がＴＩＤ＝Ｔ２、Ｔ３、Ｔ５、またはＴ８である必要があることを意味する制約である。

図３に示すように、Ｔ５に関しては語彙索引が存在しないため、従来の方法では、構造照合のためのデータスキャンが発生する。本実施の形態では、このような場合に値制約の緩和を実行する。

図２４は、この例における値制約の緩和について説明するための模式図である。同図は、図２３の検索条件を緩和した検索条件を示している。

「//ヘッダ//キーワード/text（）」がＴＩＤ＝Ｔ５に対応して制約を緩和した部分であり、この部分に対しては構造索引から候補を求める。その他の語彙索引が存在するＴＩＤ＝Ｔ２、Ｔ３、Ｔ８に対応する「//ヘッダ（タイトル | 本文）/text（）」の部分に関しては、語彙索引をそのまま利用して候補を求める。

図２５は、この例における構造制約の緩和について説明するための模式図である。同図に示すように、本来、Ｔ５の親要素としてＴ１が存在することをチェックする必要があるが、要素ＩＤを遷移前の状態としたまま、ＴＩＤのみをＴ１に変更することにより、構造制約の緩和を行い、このチェックを回避している。

このように、制約の緩和が可能となると、下位からトラバースする上述のプラン２が選択されやすくなる。図２６は、作成されたプランの一例を示す説明図である。同図では、索引スキャンオペレータ、構造照合オペレータを実行後、結合処理を行って（結合処理オペレータ）、データ取得を行うプランが示されている。

通常、構造照合オペレータで、索引スキャンオペレータを行った結果から親構造となる要素ＩＤを特定するためには、実際にデータスキャンを行う必要がある。

図３に示すように、スキーマ解析情報から＜ヘッダ＞の下には＜タイトル＞が１対１で存在することが判明している場合は、この部分の構造制約であるＴＩＤ＝Ｔ２の候補に対しては、その遷移前の要素ＩＤ（Ｅ３）から、遷移後の要素ＩＤ（Ｅ２）をデータスキャンせずに特定できる。

一方、これ以外のＴＩＤ＝Ｔ３、Ｔ５、Ｔ８の候補に関しては、データスキャンが必要となる。本実施の形態では、この構造照合オペレータの段階ではデータスキャンを実行せず、構造制約を緩和する。

例えば、Ｔ５からＴ１への構造チェックに関しては、遷移後の要素ＩＤを不定値にしたまま、ＴＩＤだけ遷移後のＴ１とする。すなわち、この時点では、遷移前の情報である＜文書ＩＤ、ＴＩＤ、要素ＩＤ＞＝＜Ｆ１、Ｔ５、Ｅ５＞に対して、遷移後の情報を＜Ｆ１、Ｔ１、Ｅ５＞とする。また、制約緩和条件として、「relation［Ｔ１、Ｔ５］」の構造制約条件を付加する。

この候補は遷移後の要素ＩＤが不定なため、ノイズを含む可能性がある候補である。しかし、不定な要素ＩＤを除いた文書ＩＤとＴＩＤだけでも結合処理が行うことができる。例えば、図３に示すような木構造の場合、「//ヘッダ」に対応するＴＩＤとしてＴ１とＴ７が存在するが、これらは木の性質を考慮すると「構造上」同一要素ではありえない。すなわち、要素ＩＤを求めなくてもテンプレート番号を見るだけで結合処理が行える場合が存在し、このような場合はデータスキャンコストを削減することができる。

次に、実際のオペレータの処理について説明する。図２６に示すプランに対応したオペレータの挙動を以下に示す。

（１） //ヘッダ/text（）に“XML"を含む集合を索引から求める。
（２） //ヘッダ/タイトル/text（）に“SGML"を含む集合を索引から求める。
（３）（１）で求めた候補集合のうち、親要素にヘッダを含むものを候補として残す。
（４）（２）で求めた候補集合のうち、親要素にヘッダを含むものを候補として残す。
（５）（３）と（４）で取得した候補に対して結合処理を行い、同一ＩＤを持つものだけを候補として残す。
（６） 指定された結果件数に応じてデータを取得する。

次に、索引スキャンオペレータの処理の概要について説明する。図２７は、図２６の（１）に示す索引スキャンオペレータで求められた候補の一例を示す説明図である。

まず、語彙索引の存在するＴＩＤ＝Ｔ２、Ｔ３、Ｔ８の構造要素に対しては、語彙索引を用いて候補を求める。この場合の解候補はノイズを含まないことが保証される。また、制約条件は不要であり（×）、処理優先度は１が設定される。

語彙索引の存在しないＴＩＤ＝Ｔ５の構造要素に対しては、“XML"の値を含むという値制約を緩和し、候補集合を構造索引から求める。この場合はノイズを含むので、処理優先度に１ではない値、例えば、０．９を設定する。

緩和した候補それぞれに対して求められた条件は、制約記憶部１５１に保存される。図２８は、このときの制約記憶部１５１の一例を示す説明図である。この例では、制約を緩和した部分は、当該ＯＩＤが“XML"を含むか、という部分であるので、この条件（contains "XML"）に制約ＩＤ＝１を付加して制約記憶部１５１に保存する。

図２９は、図２６の（２）に示す索引スキャンオペレータで求められた候補の一例を示す説明図である。この場合は、検索対象となるＴＩＤ＝Ｔ２、Ｔ８ともに語彙索引が存在し、ノイズとなる候補が存在しないことから、語彙索引で求めた結果をそのまま候補集合とする。

図３０は、図２６の（３）に示す構造照合オペレータで求められた候補の一例を示す説明図である。

まず、（１）で求めた結果に対して親要素として「ヘッダ」に対応する構造要素であるＴＩＤ＝Ｔ１またはＴ７が存在するか否かをチェックし、存在する場合にその要素ＩＤを求める。この場合、ノイズを含まないものから処理を実行する。

さらに、この例では、スキーマ解析情報からＴ１とＴ２とは１対１の関係にあり、要素ＩＤとして固定値が割り当てられていることが判明しているので、このスキーマ解析情報を有するＴＩＤを優先的に処理する。これら条件のうち一つでも制約を満足するものがあれば結果的に他の制約を解除せずに解候補と見なせるからである。

例えば、＜Ｆ１、Ｔ２、Ｅ２＞に関してはデータスキャンを実行せずに、スキーマ解析情報よりヘッダの要素ＩＤがＥ１であることが分かる。すなわち、データスキャン不要で解候補として＜Ｆ１、Ｔ１、Ｅ１＞を求めることができる。

要素ＩＤ＝Ｅ５に関してもＥ１は一意に定まることになるので結果的にはこの部分のデータスキャンは不要となる。＜Ｆ２、Ｔ２、Ｅ２＞も同様にデータスキャンなしで要素ＩＤを特定できる。

＜Ｆ４、Ｔ３、Ｅ３＞に関してはスキーマ解析情報が存在しないので、ヘッダとなる要素ＩＤを求めるためには構造情報を緩和する。すなわち、親要素がＴ１となる必要があるので、ＴＩＤのみを置換して＜Ｆ４、Ｔ１、Ｅ３＞を候補とするとともに、制約情報として、制約ＩＤ＝２:relation［Ｔ１、Ｔ５］を付与する。

図３１は、このときの制約記憶部１５１の一例を示す説明図である。同図では、制約ＩＤ＝２として構造制約を緩和したときの制約条件が追加された例が示されている。

図３２は、図２６の（４）に示す構造照合オペレータで求められた候補の一例を示す説明図である。

この場合は、スキーマ解析情報より、Ｔ５とＴ１、Ｔ８とＴ７が１対１に対応することが判明しているため、データスキャンなしで要素ＩＤを特定できる。すなわち、この場合は無条件にＥ１を候補として残すことができる。

図３３は、図２６の（５）に示す結合処理オペレータで求められた候補の一例を示す説明図である。

結合処理オペレータでは、構造照合オペレータの結果に対して同じＯＩＤを有する候補だけを残す処理を行う。結合処理オペレータでも、ノイズのない候補、すなわち、制約を緩和していない候補を優先して処理を開始する。

同図に示すように、構造照合オペレータの結果のうち、最初の２件の候補は、＜Ｆ１、Ｔ１、Ｅ１＞、および、＜Ｆ２. Ｔ１、Ｅ１＞であり、ＯＩＤが一致するので候補として残す。また、３番目の候補について、（３）の構造照合オペレータから得られた＜Ｆ３、Ｔ１、Ｅ５＞は制約を緩和して得た値であるのでＯＩＤとしては不定である。一方、（４）の構造照合オペレータから得られた＜Ｆ３、Ｔ７、Ｅ１＞は確定値である。

したがって、ＯＩＤレベルでは結合処理は行うことができないが、図３に示すような構造情報の木構造の性質を考慮すると、Ｔ１とＴ７とが同一要素であることはありえないので候補から除外する。すなわち、厳密なＯＩＤを求めなくても異なる値であることを、構造テンプレート等を使った大域的な情報で判断することができ、解候補を絞り込むことが可能となる。

４番目の候補に関しては、この時点では上記のような判別が行えないため、ＯＩＤを未定義な状態のまま残す。この場合は＜Ｆ４、Ｔ１、Ｅ３＞の候補に関してのみＯＩＤが不定値であり、制約ＩＤ＝２の制約条件だけを解決すればよい。

以上のような検索処理により、３件の候補が得られたことになるが、従来の方法では計算時間を要する部分であったデータスキャン処理をすべてスキップしてきたために、検索処理時間を大幅に削減することが可能となる。また、この時点で残った解候補集合は、ノイズは含む可能性があるが、検索漏れが存在しないという特徴を有する。

検索処理により得られた候補の件数は、検索結果の概算件数としてクライアント３００側に提示される。ユーザはこの件数をもとに所望する取得件数を設定した取得命令の送信や、検索条件をさらに絞込んだ検索命令の送信などを行うことができる。

検索処理で得られた解候補はノイズを含んでいる可能性があるほか、データの具体値（ＯＩＤ）が求まっていないので、結果取得処理では正確な値を求める必要がある。例えば、上述の例では、３件の候補のうち、Ｆ１、Ｆ２に関してはＯＩＤとして正しい解候補であるが、Ｆ４に関しては不確かさを含んでいる。したがって、３件目の候補の具体値を取得する際にはここまでの処理で付加された制約条件から正確な解を復元する。

候補数が指定された取得件数を超えている場合は、制約を解決する処理を省略できる場合がある。例えば、ユーザが取得件数として２件を指定した場合、Ｆ１、Ｆ２を取得した時点で処理を打ち切ることができる。これにより、処理負荷の高い制約解決処理を回避して高速に検索結果を返すことが可能となる。

最後に、図２６の（６）データ取得処理について説明する。図３４は、データ取得処理で求められた候補の一例を示す説明図である。

制約を解除する際には、上述のように処理優先度が高い候補を優先して処理を行うが、この例では不定値を含む候補は＜Ｆ４、Ｔ１、Ｅ３＞だけであるため、この候補に関する制約を解除する。

ＯＩＤが不定な値に関してはその制約を緩和した段階で制約条件を付加しており、この例では、図３１に示すような制約ＩＤ＝２の制約条件「制約ＩＤ＝１、relation［Ｔ１、Ｔ５］」が付加されている。

制約ＩＤ＝１の制約条件は、図３１に示すように、「contains "XML"」であるため、結果としてこの候補に対する制約条件は、「contains "XML" かつ relation［Ｔ１、Ｔ５］」である。そこで、この条件を満たすＯＩＤを取得するためにデータスキャンを行う。すなわち、＜Ｆ４、Ｔ１、Ｅ３＞のＯＩＤに対応するデータを取得し、“XML"を含むか否かをチェックする。ここで、仮に"XML"を含まないことが判明した場合は、その時点で処理を打ち切ってよい。

“XML"を含む場合は、その候補から親要素を辿り、ＴＩＤ＝Ｔ１を満たすＯＩＤが存在するか否かをチェックし、その値を取得する。例えば、Ｅ１を取得できた場合は、＜Ｆ４、Ｔ１、Ｅ１＞が求める解候補として確定される。

このように、本実施の形態にかかる構造化文書検索装置では、語彙索引が存在しない場合等であっても、検索条件における構造制約や値制約を緩和してデータスキャンを回避することにより、検索処理を高速化することが可能となる。

また、データ取得件数が指定されている場合は、制約を緩和していない候補を優先して処理することができるため、処理負荷の高い制約解除処理を回避し、データ取得処理のレスポンスタイムを飛躍的に向上させることが可能となる。

図３５は、本実施の形態にかかる構造化文書検索装置のハードウェア構成を示す説明図である。

本実施の形態にかかる構造化文書検索装置は、ＣＰＵ（Central Processing Unit）５１などの制御装置と、ＲＯＭ（Read Only Memory）５２やＲＡＭ５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、ＨＤＤ（Hard Disk Drive）、ＣＤ（Compact Disc）ドライブ装置などの外部記憶装置と、ディスプレイ装置などの表示装置と、キーボードやマウスなどの入力装置と、各部を接続するバス６１を備えており、通常のコンピュータを利用したハードウェア構成となっている。

本実施の形態にかかる構造化文書検索装置で実行される構造化文書検索プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。

また、本実施の形態にかかる構造化文書検索装置で実行される構造化文書検索プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本実施の形態にかかる構造化文書検索装置で実行される構造化文書検索プログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。

また、本実施の形態の構造化文書検索プログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

本実施の形態にかかる構造化文書検索装置で実行される構造化文書検索プログラムは、上述した各部（通信部、格納処理部、検索処理部、結果取得部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ５１（プロセッサ）が上記記憶媒体から構造化文書検索プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上述した各部が主記憶装置上に生成されるようになっている。

以上のように、本発明にかかる構造化文書検索装置、構造化文書検索方法および構造化文書検索プログラムは、索引種別が混在する構造化文書などを検索する構造化文書検索装置、構造化文書検索方法および構造化文書検索プログラムに適している。

本実施の形態にかかる構造化文書検索装置の構成を示すブロック図である。 ＸＭＬで記述された構造化文書の一例を示す説明図である。 構造情報記憶部に格納された構造情報のデータ構造の一例を示す説明図である。 語彙索引記憶部に格納された語彙索引のデータ構造の一例を示す説明図である。 構造索引による検索と語彙索引による検索との比較について説明した模式図である。 構造索引の一例を示す説明図である。 クエリグラフの一例を示す説明図である。 候補を絞り込む過程を表した模式図である。 制約記憶部に記憶される制約条件のデータ構造の一例を示す説明図である。 候補記憶部に記憶される候補のデータ構造の一例を示す説明図である。 本実施の形態における構造化文書検索処理の全体の流れを示すフローチャートである。 プランの一例を示した説明図である。 本実施の形態におけるクエリプランニング処理の全体の流れを示すフローチャートである。 本実施の形態におけるクエリ実行処理の全体の流れを示すフローチャートである。 値制約を解決して取得した候補の一例を示す説明図である。 ＸＭＬで記述された構造化文書の一例を示す説明図である。 構造制約を解決して取得した候補の一例を示す説明図である。 候補集合結合処理の全体の流れを示すフローチャートである。 制約緩和した候補を結合する処理の一例を示す説明図である。 制約緩和した候補にさらに制約の緩和を行う処理の一例を示す説明図である。 制約条件の一例を示す説明図である。 順序決定方法の一例を説明するための模式図である。 入力された検索条件の一例を示す説明図である。 値制約の緩和について説明するための模式図である。 構造制約の緩和について説明するための模式図である。 作成されたプランの一例を示す説明図である。 索引スキャンオペレータで求められた候補の一例を示す説明図である。 制約記憶部の一例を示す説明図である。 索引スキャンオペレータで求められた候補の一例を示す説明図である。 構造照合オペレータで求められた候補の一例を示す説明図である。 制約記憶部の一例を示す説明図である。 構造照合オペレータで求められた候補の一例を示す説明図である。 結合処理オペレータで求められた候補の一例を示す説明図である。 データ取得処理で求められた候補の一例を示す説明図である。 本実施の形態にかかる構造化文書検索装置のハードウェア構成を示す説明図である。

符号の説明

５１ ＣＰＵ
５２ ＲＯＭ
５３ ＲＡＭ
５４ 通信Ｉ／Ｆ
６１ バス
１００ 構造化文書検索装置
１０１ 通信部
１１０ 格納処理部
１１１ スキーマ解析部
１１２ 語彙索引作成部
１１３ 構造索引作成部
１１４ 登録部
１２０ 検索処理部
１２１ 条件生成部
１２２ クエリプランニング部
１２３ クエリ実行部
１２４ 値制約処理部
１２５ 第１取得部
１２６ 第３取得部
１２７ 候補生成部
１２８ 第２取得部
１３０ 結果取得部
１３１ 順序決定部
１３２ 制約解決部
１３３ 結果生成部
１４１ 構造化文書記憶部
１４２ 構造情報記憶部
１４３ 構造索引記憶部
１４４ 語彙索引記憶部
１５１ 制約記憶部
１５２ 候補記憶部
２００ ネットワーク
３００ クライアント
２２０１、２２０２ 候補集合

Claims (18)

1. 階層化された論理構造の単位である構造要素に対応するオブジェクトと、前記オブジェクトを識別するオブジェクトＩＤとを含み、前記論理構造を有する構造化文書情報を記憶する構造化文書記憶手段と、
   前記構造要素を識別する構造ＩＤと、前記オブジェクトＩＤとを対応づけた構造索引を記憶する構造索引記憶手段と、
   前記構造化文書情報に含まれる語彙を識別する語彙ＩＤと、前記オブジェクトＩＤとを対応づけた語彙索引を記憶する語彙索引記憶手段と、
   前記構造ＩＤに前記語彙索引が付加されているか否かを表す判別情報を含む前記構造要素に関する構造情報を記憶する構造情報記憶手段と、入力された検索条件に含まれる検索キーを前記検索キーの検索対象となる前記構造ＩＤに対応づけ、前記検索キーを対応づけた前記構造ＩＤである検索対象構造ＩＤと、前記検索条件の検索結果として取得すべき前記構造ＩＤである検索結果構造ＩＤとを階層構造の単位として含み、前記検索対象構造ＩＤと前記検索結果構造ＩＤとの間で満たすべき前記階層構造に関する構造制約を定めた階層型検索条件を生成する条件生成手段と、
   前記検索対象構造ＩＤのうち、前記語彙索引が付加されていないことを示す前記判別情報が対応づけられた前記検索対象構造ＩＤについて、前記検索対象構造ＩＤに対応づけられた前記オブジェクトＩＤを前記構造索引記憶手段から取得する第１取得手段と、
   前記第１取得手段が取得した前記オブジェクトＩＤに前記検索キーを第１制約条件として対応づけ、前記第１制約条件を対応づけた前記オブジェクトＩＤを含む前記検索結果の候補を生成する候補生成手段と、
   生成された前記候補に含まれる前記オブジェクトＩＤに対応する前記検索対象構造ＩＤに対して、前記階層型検索条件で定めた前記構造制約に適合する前記検索結果構造ＩＤを取得する第２取得手段と、
   取得した前記検索結果構造ＩＤに対応する前記オブジェクトＩＤのうち前記第１制約条件を満たす前記オブジェクトＩＤに対応する前記オブジェクトを前記構造化文書記憶手段から取得する結果取得手段と、
   を備えたことを特徴とする構造化文書検索装置。
2. 前記検索対象構造ＩＤのうち、前記語彙索引が付加されていることを示す前記判別情報が対応づけられた前記検索対象構造ＩＤについて、前記検索対象構造ＩＤに対応づけられた前記検索キーに含まれる前記語彙の前記語彙ＩＤに対応する前記オブジェクトＩＤを前記語彙索引記憶手段から取得する第３取得手段をさらに備え、
   前記候補生成手段は、前記第１取得手段が取得した前記オブジェクトＩＤに前記検索キーを第１制約条件として対応づけ、前記第１制約条件を対応づけた前記オブジェクトＩＤと前記第３取得手段が取得した前記オブジェクトＩＤとを含む前記検索結果の候補を生成すること、
   を特徴とする請求項１に記載の構造化文書検索装置。
3. 前記候補生成手段は、前記オブジェクトＩＤに対応する前記検索対象構造ＩＤを含む前記候補を生成し、
   前記第２取得手段は、さらに前記候補に含まれる前記検索対象構造ＩＤを取得した前記検索結果構造ＩＤに置換し、前記構造制約を第２制約条件として前記オブジェクトＩＤに対応づけること、
   を特徴とする請求項１に記載の構造化文書検索装置。
4. 前記候補生成手段は、前記第１取得手段が取得した前記オブジェクトＩＤに、前記結果取得手段が前記オブジェクトを取得するときの優先順位を表す優先度をさらに対応づけた前記候補を生成し、
   前記結果取得手段は、前記優先度が大きい前記オブジェクトＩＤに対応する前記オブジェクトを、前記優先度が小さい前記オブジェクトＩＤに対応する前記オブジェクトより優先して取得すること、
   を特徴とする請求項１に記載の構造化文書検索装置。
5. 前記候補生成手段は、複数の前記検索キーに対する複数の前記候補のうち、先に取得する前記候補に含まれる前記オブジェクトＩＤに対し、後に取得する前記候補に含まれる前記オブジェクトＩＤより大きい前記優先度を対応づけた前記候補を生成すること、
   を特徴とする請求項４に記載の構造化文書検索装置。
6. 前記第２取得手段は、前記第２制約条件を対応づけた前記オブジェクトＩＤに、前記結果取得手段が前記オブジェクトを取得するときの優先順位を表す優先度をさらに対応づけ、
   前記結果取得手段は、前記優先度が大きい前記オブジェクトＩＤに対応する前記オブジェクトを、前記優先度が小さい前記オブジェクトＩＤに対応する前記オブジェクトより優先して取得すること、
   を特徴とする請求項３に記載の構造化文書検索装置。
7. 前記第２取得手段は、前記検索対象構造ＩＤから前記検索結果構造ＩＤまでの階層数が小さい前記オブジェクトＩＤに対し、前記検索対象構造ＩＤから前記検索結果構造ＩＤまでの階層数が大きい前記オブジェクトＩＤより大きい前記優先度を対応づけること、
   を特徴とする請求項６に記載の構造化文書検索装置。
8. 前記第２取得手段は、複数の前記検索キーに対する複数の前記候補のうち、先に取得する前記候補に含まれる前記オブジェクトＩＤに対し、後に取得する前記候補に含まれる前記オブジェクトＩＤより大きい前記優先度を対応づけること、
   を特徴とする請求項６に記載の構造化文書検索装置。
9. 前記構造化文書記憶手段は、前記構造化文書情報を識別する文書ＩＤと前記構造化文書情報内で前記オブジェクトを識別する要素ＩＤとを含む前記オブジェクトＩＤと、前記オブジェクトと、を対応づけて記憶し、
   前記構造索引記憶手段は、前記構造ＩＤと、前記文書ＩＤと前記要素ＩＤとを含む前記オブジェクトＩＤと、を対応づけた前記構造索引を記憶し、
   前記語彙索引記憶手段は、前記語彙ＩＤと、前記文書ＩＤと前記要素ＩＤとを含む前記オブジェクトＩＤと、を対応づけた前記語彙索引を記憶し、
   前記候補生成手段は、前記階層型検索条件にＡＮＤ条件で結合された複数の前記検索キーが含まれる場合に、前記検索キーのそれぞれに対する複数の前記候補から、前記オブジェクトＩＤに含まれる前記文書ＩＤと、前記オブジェクトＩＤに対応する前記構造ＩＤとが共通する前記オブジェクトＩＤを取得し、取得した前記オブジェクトＩＤを含む前記候補を生成すること、
   を特徴とする請求項１に記載の構造化文書検索装置。
10. 前記候補を記憶する候補記憶手段をさらに備え、
    前記候補生成手段は、取得した前記オブジェクトＩＤのそれぞれに前記第１制約条件が対応づけられている場合に、前記候補記憶手段における複数の前記候補を記憶した位置を示す位置情報を前記オブジェクトＩＤに対応づけた前記候補を取得すること、
    を特徴とする請求項９に記載の構造化文書検索装置。
11. 前記結果取得手段は、前記候補に前記位置情報が含まれる場合に、前記候補記憶手段の前記位置情報で示される位置から前記候補を取得し、取得した前記候補に含まれる前記第１制約条件を満たす前記オブジェクトＩＤに対応する前記オブジェクトを取得すること、
    を特徴とする請求項１０に記載の構造化文書検索装置。
12. 前記結果取得手段は、前記第１制約条件が対応づけられていない前記オブジェクトＩＤを、前記第１制約条件が対応づけられた前記オブジェクトＩＤより優先して取得すること、
    を特徴とする請求項１に記載の構造化文書検索装置。
13. 前記結果取得手段は、前記第２制約条件が対応づけられていない前記オブジェクトＩＤを、前記第２制約条件が対応づけられた前記オブジェクトＩＤより優先して取得すること、
    を特徴とする請求項３に記載の構造化文書検索装置。
14. 前記結果取得手段は、前記第１制約条件が対応づけられた前記オブジェクトＩＤを含む複数の前記候補を取得する場合に、複数の前記候補に含まれる前記オブジェクトが互いに同一の前記構造化文書情報内に含まれる複数の前記候補を、複数の前記候補に含まれる前記オブジェクトが互いに異なる前記構造化文書情報内に含まれる複数の前記候補より優先して取得すること、
    を特徴とする請求項１に記載の構造化文書検索装置。
15. 前記結果取得手段は、前記第２制約条件が対応づけられた前記オブジェクトＩＤを含む複数の前記候補を取得する場合に、複数の前記候補に含まれる前記オブジェクトが互いに同一の前記構造化文書情報内に含まれる複数の前記候補を、複数の前記候補に含まれる前記オブジェクトが互いに異なる前記構造化文書情報内に含まれる複数の前記候補より優先して取得すること、
    を特徴とする請求項３に記載の構造化文書検索装置。
16. ネットワークを介して接続された端末装置から前記検索条件を受信し、受信した前記検索条件に対して前記候補生成手段が生成した前記候補の件数を前記端末装置に送信する通信手段をさらに備えたこと、
    を特徴とする請求項１に記載の構造化文書検索装置。
17. 階層化された論理構造の単位である構造要素に対応するオブジェクトと、前記オブジェクトを識別するオブジェクトＩＤとを含み、前記論理構造を有する構造化文書情報を構造化文書記憶手段に記憶する構造化文書記憶ステップと、
    前記構造要素を識別する構造ＩＤと、前記オブジェクトＩＤとを対応づけた構造索引を構造索引記憶手段に記憶する構造索引記憶ステップと、
    前記構造化文書情報に含まれる語彙を識別する語彙ＩＤと、前記オブジェクトＩＤとを対応づけた語彙索引を語彙索引記憶手段に記憶する語彙索引記憶ステップと、
    前記構造ＩＤに前記語彙索引が付加されているか否かを表す判別情報を含む前記構造要素に関する構造情報を構造情報記憶手段に記憶する構造情報記憶ステップと、
    条件生成手段によって、入力された検索条件に含まれる検索キーを前記検索キーの検索対象となる前記構造ＩＤに対応づけ、前記検索キーを対応づけた前記構造ＩＤである検索対象構造ＩＤと、前記検索条件の検索結果として取得すべき前記構造ＩＤである検索結果構造ＩＤとを階層構造の単位として含み、前記検索対象構造ＩＤと前記検索結果構造ＩＤとの間で満たすべき前記階層構造に関する構造制約を定めた階層型検索条件を生成する条件生成ステップと、
    第１取得手段によって、前記検索対象構造ＩＤのうち、前記語彙索引が付加されていないことを示す前記判別情報が対応づけられた前記検索対象構造ＩＤについて、前記検索対象構造ＩＤに対応づけられた前記オブジェクトＩＤを前記構造索引記憶手段から取得する第１取得ステップと、
    候補生成手段によって、前記第１取得ステップが取得した前記オブジェクトＩＤに前記検索キーを第１制約条件として対応づけ、前記第１制約条件を対応づけた前記オブジェクトＩＤを含む前記検索結果の候補を生成する候補生成ステップと、
    第２取得手段によって、生成された前記候補に含まれる前記オブジェクトＩＤに対応する前記検索対象構造ＩＤに対して、前記階層型検索条件で定めた前記構造制約に適合する前記検索結果構造ＩＤを取得する第２取得ステップと、
    結果取得手段によって、取得した前記検索結果構造ＩＤに対応する前記オブジェクトＩＤのうち前記第１制約条件を満たす前記オブジェクトＩＤに対応する前記オブジェクトを前記構造化文書記憶手段から取得する結果取得ステップと、
    を備えたことを特徴とする構造化文書検索方法。
18. 階層化された論理構造の単位である構造要素に対応するオブジェクトと、前記オブジェクトを識別するオブジェクトＩＤとを含み、前記論理構造を有する構造化文書情報を構造化文書記憶手段に記憶する構造化文書記憶手順と、
    前記構造要素を識別する構造ＩＤと、前記オブジェクトＩＤとを対応づけた構造索引を構造索引記憶手段に記憶する構造索引記憶手順と、
    前記構造化文書情報に含まれる語彙を識別する語彙ＩＤと、前記オブジェクトＩＤとを対応づけた語彙索引を語彙索引記憶手段に記憶する語彙索引記憶手順と、
    前記構造ＩＤに前記語彙索引が付加されているか否かを表す判別情報を含む前記構造要素に関する構造情報を構造情報記憶手段に記憶する構造情報記憶手順と、
    入力された検索条件に含まれる検索キーを前記検索キーの検索対象となる前記構造ＩＤに対応づけ、前記検索キーを対応づけた前記構造ＩＤである検索対象構造ＩＤと、前記検索条件の検索結果として取得すべき前記構造ＩＤである検索結果構造ＩＤとを階層構造の単位として含み、前記検索対象構造ＩＤと前記検索結果構造ＩＤとの間で満たすべき前記階層構造に関する構造制約を定めた階層型検索条件を生成する条件生成手順と、
    前記検索対象構造ＩＤのうち、前記語彙索引が付加されていないことを示す前記判別情報が対応づけられた前記検索対象構造ＩＤについて、前記検索対象構造ＩＤに対応づけられた前記オブジェクトＩＤを前記構造索引記憶手段から取得する第１取得手順と、
    前記第１取得手順が取得した前記オブジェクトＩＤに前記検索キーを第１制約条件として対応づけ、前記第１制約条件を対応づけた前記オブジェクトＩＤを含む前記検索結果の候補を生成する候補生成手順と、
    生成された前記候補に含まれる前記オブジェクトＩＤに対応する前記検索対象構造ＩＤに対して、前記階層型検索条件で定めた前記構造制約に適合する前記検索結果構造ＩＤを取得する第２取得手順と、
    取得した前記検索結果構造ＩＤに対応する前記オブジェクトＩＤのうち前記第１制約条件を満たす前記オブジェクトＩＤに対応する前記オブジェクトを前記構造化文書記憶手段から取得する結果取得手順と、
    をコンピュータに実行させる構造化文書検索プログラム。

Images