JP2004118543A - 構造化文書検索方法、検索支援方法、検索支援装置および検索支援プログラム - Google Patents
構造化文書検索方法、検索支援方法、検索支援装置および検索支援プログラム Download PDFInfo
- Publication number
- JP2004118543A JP2004118543A JP2002281207A JP2002281207A JP2004118543A JP 2004118543 A JP2004118543 A JP 2004118543A JP 2002281207 A JP2002281207 A JP 2002281207A JP 2002281207 A JP2002281207 A JP 2002281207A JP 2004118543 A JP2004118543 A JP 2004118543A
- Authority
- JP
- Japan
- Prior art keywords
- document
- search
- structured
- documents
- processed
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】構造化文書の文書構造を意識することなく、検索結果を絞り込みながら所望の構造化文書を迅速に効率よく検索することができる、構造化文書検索方法、およびそれを用いた検索支援装置を提供する。
【解決手段】少なくとも１つのキーワードを初期条件として入力されたら、異なる文書構造の複数の構造化文書を記憶するデータベースから、当該キーワードを構成要素の要素値に含む構造化文書を検索し、この検索された構造化文書を処理対象の文書として、当該処理対象の文書のそれぞれの文書構造と構成要素の要素値として包含する語彙を比較することにより、処理対象の文書から絞り込み条件の候補として抽出した、要素名や要素値として包含する語彙を表示し、表示された候補の中から選択された候補を絞り込み条件として用いて、前回検索された構造化文書の中から当該選択された絞り込み条件を満たす構造化文書を検索する。
【選択図】 図３３
【解決手段】少なくとも１つのキーワードを初期条件として入力されたら、異なる文書構造の複数の構造化文書を記憶するデータベースから、当該キーワードを構成要素の要素値に含む構造化文書を検索し、この検索された構造化文書を処理対象の文書として、当該処理対象の文書のそれぞれの文書構造と構成要素の要素値として包含する語彙を比較することにより、処理対象の文書から絞り込み条件の候補として抽出した、要素名や要素値として包含する語彙を表示し、表示された候補の中から選択された候補を絞り込み条件として用いて、前回検索された構造化文書の中から当該選択された絞り込み条件を満たす構造化文書を検索する。
【選択図】 図３３
Description
【０００１】
【発明の属する技術分野】
本発明は、異なる文書構造の複数の構造化文書を記憶する、階層化された論理構造を持つ構造化文書データベースで管理する構造化文書管理システムに関し、特に、当該データベースから所望の構造化文書を検索するための絞り込み検索に関する。
【０００２】
【従来の技術】
ＸＭＬ（Ｅｘｔｅｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）データベースなど構造化文書データベースでは、検索言語によって記述されたユーザ検索要求により所望の構造化文書を検索する手段が提供されてる。検索言語には、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）に似た構文を持ち、検索位置、検索条件、情報抽出部分などを記述したものもある。この手段により多種多様な構造化文書を検索することができる。しかし、このような検索言語をベースとしたクエリデータを作成するには、ユーザ側にあらかじめ構造化文書データベース中に存在する構造化文書の文書構造（ＤＴＤ）や語彙発生状況などに関する情報が必要であった。
【０００３】
一方、ユーザ側の構造化文書の文書構造（ＤＴＤ）や語彙発生状況などに関する情報欠如を補うために、いくつかの支援方法が提案されてきた。
【０００４】
検索対象を初期検索の段階から絞り込むために、ＤＴＤの一覧を提示し、そこから文書構造のスケルトンを表示させて、ユーザに検索対象の構造に関する条件を設定させる。検索された結果は、出力パターン指定された構造化文書形式に変換して出力する（例えば特許文献１参照）。
【０００５】
一方、初期検索では十分に絞り込めないという状況を考慮して、二次検索での絞り込みを支援する方法もある。これはＲＤＢなどに格納されたデータベースを検索対象にする。初期検索では、ユーザに語彙などの粗い検索条件を設定させる。大量の候補が出た場合に、データベースとは別の階層構造を持った背景知識を用いて、効果的な順番で質問を行い、絞り込みを支援するものである（例えば特許文献２参照）。
【０００６】
また、テキストで表現されたフルテキストデータベースを検索に対象としたものもある。これは初期検索では、ユーザに語彙などの粗い検索条件を設定させる。大量の候補が出た場合に、データベースとは別の階層構造を持った背景知識を用いて、語彙を背景知識を用いて効果的に展開し、設定された件数になるように自動的に絞り込みを行うものである（例えば特許文献３参照）。
【０００７】
【特許文献１】特開２０００−２００２８６号公報（第８頁、第４図）
【０００８】
【特許文献２】特開平１０−１８７７３９（第６頁、第１図）
【０００９】
【特許文献３】特開７−２２５７７２ （第１０頁、第１図）
【００１０】
【発明が解決しようとする課題】
ユーザが構造化文書を検索する場合には、あらかじめ文書構造（ＤＴＤ）や語彙発生状況などに関する情報が必要であった。
【００１１】
そのためには、いくつかの検索支援方法が提案されてきたが、以下のような問題点があった。
【００１２】
（１）ＤＴＤがデータベース上に設定されていないと構造条件の候補を提示できず、検索支援できない。
【００１３】
（２）２次検索を行って絞り込みをする場合、特別な背景知識が無いと検索支援できない。
【００１４】
構造化文書の場合、検索条件として、構造に関する条件、語彙に関する条件、を指定する必要があるが、従来は、これらを適切に組合せた検索、および検索支援ができていなかった。
【００１５】
そこで、本発明は上記問題点に鑑み、構造化文書の文書構造を意識することなく、検索結果を絞り込みながら所望の構造化文書を迅速に効率よく検索することができる、構造化文書検索方法、およびそれを用いた検索支援装置を提供することを目的とする。
【００１６】
【課題を解決するための手段】
（１）本発明は、異なる文書構造の複数の構造化文書を記憶するデータベース（特に、前記複数の構造化文書のそれぞれの構成要素で構成された階層化された論理構造を有するデータベース）から、所望の構造化文書を検索するためのものであって、少なくとも１つのキーワードを初期条件として入力されたら、前記データベースから、前記キーワードを構成要素の要素名と要素値とのうちの少なくとも一方に含む複数の構造化文書を検索し、この検索された複数の構造化文書を処理対象の文書として、当該処理対象の文書のそれぞれの文書構造と構成要素の要素値として包含する語彙を比較することにより、絞り込み条件の候補として、前記処理対象の文書から、構成要素の要素名と要素値として包含する語彙のうちの少なくとも一方を抽出し、この抽出された候補を表示し、表示された候補の中から選択された候補を絞り込み条件として用いて、前回検索された構造化文書の中から当該選択された絞り込み条件を満たす構造化文書を検索した結果を前記処理対象の文書として取得することを特徴とする。
【００１７】
好ましくは、前記処理対象の文書間の違いとして、構成要素の要素名と要素値として包含する語彙のうちの少なくとも一方を抽出し、この違いを絞り込み条件の候補として表示する。
【００１８】
本発明によれば、予めユーザ側で文書構造や語彙に関する情報を知らなくとも効果的に構造的な条件や語彙的な条件を優先順位付けして提示することで、必要な構造化文書集合を容易に検索することができる。
【００１９】
（２）本発明は、異なる文書構造の複数の構造化文書を記憶するデータベース（特に、前記複数の構造化文書のそれぞれの構成要素で構成された階層化された論理構造を有するデータベース）から、指定された検索条件を満足する構造化文書を検索する検索装置を用いて、所望の構造化文書を検索するための支援を行う検索支援装置であって、少なくとも１つのキーワードを初期条件として入力されたら、前記検索装置が、前記キーワードを構成要素の要素名と要素値とのうちの少なくとも一方に含む構造化文書を検索するための検索要求文を作成する作成手段と、前記検索要求文に基づき前記検索装置で検索された構造化文書を処理対象の文書として取得する取得手段と、前記処理対象の文書のそれぞれの文書構造と構成要素の要素値として包含する語彙を比較することにより、絞り込み条件の候補として、前記処理対象の文書から、構成要素の要素名と要素値として包含する語彙のうちの少なくとも一方を抽出する手段と、この抽出手段で抽出された絞り込み条件の候補を表示する表示手段と、この表示手段で表示された候補の中から選択された候補を絞り込み条件として用いて、前回検索された構造化文書の中から当該選択された絞り込み条件を満たす構造化文書を検索した結果を前記処理対象の文書として取得する手段とを具備したことを特徴とする。
【００２０】
好ましくは、前記抽出手段は、前記処理対象の文書間の違いとして、構成要素の要素名と要素値として包含する語彙のうちの少なくとも一方を抽出し、前記表示手段は、前記前記抽出手段で抽出された違いを絞り込み条件の候補として表示する。
【００２１】
本発明によれば、予めユーザ側で文書構造や語彙に関する情報を知らなくとも効果的に構造的な条件や語彙的な条件を優先順位付けして提示することで、必要な構造化文書集合を検索装置から容易に取り出すことができる。
【００２２】
【発明の実施の形態】
まず、本発明の実施形態について説明する前に、構造化文書管理システムの概要について説明する。
【００２３】
（構造化文書管理システムの説明）
構造化文書として、ＸＭＬやＳＧＭＬなどで記述した文書が挙げられる。ＳＧＭＬ（Ｓｔａｎｄａｒｄ Ｇｅｎｅｒａｌｉｚｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）とは、ＩＳＯ（国際標準化機構）で定められた規格である。ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）とは、Ｗ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）にて定められた規格である。これらは、文書を構造化することを可能とする構造化文書の規格である。
【００２４】
以下、構造化文書として、ＸＭＬにて記述された文書を例に説明を進める。構造化文書の文書構造を定義したデータ（文書構造定義データ）をスキーマと呼ぶ。ＸＭＬではスキーマを定義するためにＸＭＬ−ＳｃｈｅｍａやＸＤＲ（ＸＭＬＤａｔａ Ｒｅｄｕｃｅｄ）などのスキーマ言語が提案されている。ここでは、例えば、ＸＤＲでスキーマを記述する場合を例にとり説明する。
【００２５】
スキーマも、構造化文書管理システムの管理対象の構造化文書であり、ここでは、スキーマ文書と呼ぶことがある。スキーマ文書以外の構造化文書であって、特許明細書やメール、週報、広告などの種々雑多な内容を有する文書を、ここでは、コンテンツ文書と呼ぶこともある。
【００２６】
構造化文書管理システムでは、上記スキーマ文書、上記コンテンツ文書、さらに、後述するようなユーザからの検索要求を記述したクエリ、すなわち、クエリ文書も管理対象とし、これらを総称して「文書」と呼ぶ。
【００２７】
以下、特にことわりがない場合、「文書」と呼ぶときは、コンテンツ文書、スキーマ文書、クエリ文書を全て指すものとする。
【００２８】
まず、実施形態の説明の前に、ＸＭＬについて簡単に説明する。
【００２９】
図３は、ＸＭＬで記述された構造化文書の一例として、「特許」情報の例を示したものである。ＸＭＬやＳＧＭＬは、文書の構造の表現にタグが用いられる。タグには、開始タグと終了タグがある。文書構造の各構成要素は、開始タグと終了タグで囲まれている。開始タグとは構成要素の要素名を「＞」で閉じたものであり、終了タグとは要素名を記号「＜／」と「＞」で閉じたものである。タグに続く構成要素の内容が、テキスト（文字列）または子供の構成要素の繰り返しである。また開始タグには「＜要素名 属性＝“属性値”＞」などのように属性情報を設定することができる。「＜特許ＤＢ＞＜／特許ＤＢ＞」のようにテキストを含まない構成要素は、簡易記法として「＜特許ＤＢ／＞」のように表わすこともできる。
【００３０】
図３に示した文書は、「特許」タグから始まる要素をルートとし、その子要素として「タイトル」、「出願日」、「出願者」、「要約」タグから始まる要素が存在する。また、例えば、「タイトル」タグから始まる要素には「ＸＭＬデータベース」といった、１つのテキスト（文字列）が要素値として存在する。
【００３１】
ＸＭＬなどの構造化文書は、任意の構成要素を繰り返し含んでいたり、さらには文書構造があらかじめ決まっていないのが普通である。
【００３２】
図３に示したような構造化文書を論理的に表現するために、図４に示すようなツリー表現が用いられる。ツリーは、ノード（番号が付され、円形で示されたもの）とアーク（ノードを表す円形間をつなぐデータ付き線）と四角形で囲まれたテキストから構成されている。
【００３３】
１つのノードは１つの構成要素、すなわち、１つの文書オブジェクトに対応する。ノードからタグ名や属性名に相当するラベルが付与された複数のアークが出てきている。そのアークの先は、ノード値または要素値としての文字列（テキスト）である。ノードの中に記載されている英数字（例えば「＃０」、「＃４９」）などは、各文書オブジェクトを識別するためのオブジェクトＩＤである。
【００３４】
図４に示したツリー構造を図３に示した構造化文書の文書オブジェクトツリーと呼ぶ。
【００３５】
図１は、本実施形態に係る構造化文書管理システムの構成例を示したものである。図１において、構造化文書管理システムは、大きく分けて、要求制御部１、アクセス要求処理部２、検索要求処理部３、データアクセス部４、文書記憶部５、インデックス記憶部６から構成されている。文書記憶部５、インデックス記憶部６は例えば、外部記憶装置で構成される。
【００３６】
図１のシステム構成は、ソフトウエアを用いて実現可能である。
【００３７】
要求制御部１は、要求受付部１１と結果処理部１２から構成されている。要求受付部１１は、文書の格納、文書の取得、文書の検索などのユーザからの要求を受け付けて、アクセス要求処理部２を呼び出す。結果処理部１２は、アクセス要求処理部２が処理した結果を要求元のユーザに返す処理を行う。
【００３８】
アクセス要求処理部２は、文書の格納、文書の取得、文書の削除などのユーザからの各種要求に対応した複数の処理部から構成されている。つまり、文書格納部２１、文書取得部２２、文書削除部２３から構成されている。
【００３９】
文書格納部２１は、文書記憶部５中の指定された論理的なエリアに文書を格納する処理を行う。
【００４０】
文書取得部２２は、文書記憶部５中の論理的なエリアが指定されたときに、その指定エリアに存在する文書を取得する処理を行う。
【００４１】
文書削除部２３は、文書記憶部５中の指定された論理的なエリアに存在する文書を削除する処理を行う。
【００４２】
文書記憶部５は、構造化文書データベースであり、例えば、図８に示すように、文書をＵＮＩＸのディレクトリ構造のように階層的にツリー構造状に格納している。
【００４３】
図８に示すように、構造化文書データベースは、図４に示したような１つの構造化文書のツリー構造と同様に表現できる。すなわち、任意のノード以下の部分的な階層木（部分ツリー）は、構造化文書データベースから切り出された構造化文書であり、ここでは、これを文書オブジェクトツリーと呼ぶ。各ノードにはオブジェクトＩＤが割り当てられている。オブジェクトＩＤは、構造化文書データベース内ではユニークな数値である。
【００４４】
階層木のルートとなるノードには、それがルートノードであることを特定するためのオブジェクトＩＤ「＃０」が割り当てられるものとする。
【００４５】
ルートノード、すなわち、「＃０」のノードからは「ｒｏｏｔ」タグを先頭に持つオブジェクトＩＤ「＃１」のノードへリンクが張られている。「＃１」のノードからは、「特許ＤＢ」タグを先頭にもつオブジェクトＩＤ「＃２」のノードへのリンクが張られている。「＃２」ノードからは、「特許」タグを先頭に持つ、オブジェクトＩＤ「＃４２」のノード、「＃５２」のノード、「＃６２」のノードへのリンクがそれぞれ張られている。
【００４６】
図３に示した「特許」情報は、図８の「＃４２」ノード以下の部分ツリーに対応している。このノードからは「タイトル」タグ、「出願者」タグ、「要約」タグなどを先頭にもつノードへリンクが張られ、末端のノードからは、「ＸＭＬデータベース」、「Ｔ社」、「ＸＭＬを統一的に管理するデータベースを提供する…」などの文字列（要素値）へのリンクが張られている。
【００４７】
図８において、オブジェクトＩＤ「＃５２」のノード以下の部分ツリー、オブジェクトＩＤ「＃６２」のノード以下の部分ノードも１つの「特許」情報に対応する文書オブジェクトツリーである。
【００４８】
ところで、例えば、「＃４３」ノードにリンクされた「ＸＭＬデータベース」という要素値は、「＃４３」ノードと「＃ｖａｌｕｅ」という特殊なタグ名で接続されている。このタグ名は、「＃」で始まるためＸＭＬの規格においては標準的なタグ名として利用することはできない。
【００４９】
このような構造化文書データベースの特定ノードを指定するために構造化文書パスを用いる。構造化文書パスは「ｕｉｘ：／／ｒｏｏｔ」から始まる文字列である。ｕｉｘ（Ｕｎｉｖｅｒｓａｌ Ｉｄｅｎｔｉｆｉｅｒ ｆｏｒ ＸＭＬ）は構造化文書パスであることを示す文字列である。
【００５０】
例えば、構造化文書パスとして「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」と表すと、この構造化文書パスの示す文書記憶部５中の論理的なエリアは、図８において、「＃１」ノードから「特許ＤＢ」が付与されたアークが指し示すノード、つまり「＃２」ノードである。
【００５１】
同様にして、構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許」は、図８における「＃４２」ノードを指し示し、構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／出願日／年」は、図８における「＃４５」ノードを指し示す。
【００５２】
例えば、図８において、「＃２」ノード以下に、すなわち、「特許ＤＢ」という構成要素に、複数の「特許」情報を格納する場合には、各「特許」情報を識別するために、要素名（例えば、この場合「特許」）にインデックスを追加してもよい。
【００５３】
「特許ＤＢ」の最初の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」となるが、これは「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許」と同じとみなす。「特許ＤＢ」の２番目の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［１］」、「特許ＤＢ」の５番目の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［４］」となる。
【００５４】
インデックス記憶部６には，検索時に用いる、要素名称生起インデックスとデータ生起インデックスが記憶されている。
【００５５】
要素名生起インデックスとは構造化文書データベースに格納されている要素名と、その要素名の構成要素が先頭にある構造化文書（文書オブジェクトツリー）の位置とを関連付けたインデックスファイルである。例えば、図８の構造化文書データベースでは、（「特許」情報に対応する）「特許」という要素名が「＃４２」ノード以下の構造化文書、「＃５２」ノード以下の構造化文書、「＃６２」ノード以下の構造化文書に存在する場合、要素名生起インデックスには、図９に示すように、「＃４２」ノード、「＃５２」ノード、「＃６２」ノードの親ノード、すなわち、「＃２」ノードが、要素名「特許」にリンクされて格納される。
【００５６】
このように、親ノードでインデックス化すると、インデックスファイルを圧縮することができる。すなわち、親ノードでインデックス化すれば、子ノードが増大しようとも、親ノードで代用しているので、要素名にリンクすべきノードは増大しない。
【００５７】
データ生起インデックスとは、構造化文書データベースに格納されている文字列データと、その文字列データが存在する構造化文書（文書オブジェクトツリー）の位置とを関連付けたインデックスファイルである。例えば、図８の構造化文書データベースでは、「ＸＭＬ」という文字列が「＃４３」ノード以下の構造化文書、「＃４９」ノード以下の構造化文書に存在する。この場合、データ生起インデックスには、図１０に示すように、「＃４３」ノード、「＃４９」ノードが、「ＸＭＬ」という文字列にリンクされて格納される。
【００５８】
文書記憶部５中の指定された論理的なエリアとは、構造化文書パスを用いてユーザにより指定された文書の格納場所である。構造化文書パスは、ユーザにとって認識可能な表現である。
【００５９】
図１の説明に戻る。
【００６０】
データアクセス部４は、文書記憶部５をアクセスするための各種処理を行うものである。データアクセス部４は、文書オブジェクトツリー格納部４１、文書オブジェクトツリー削除部４２、文書オブジェクトツリー取得部４３、文書文字列取得部４４、文書パーサ部４６、合成文書作成部４７、インデックス更新部４８から構成される。
【００６１】
文書オブジェクトツリー格納部４１は、文書記憶部５中の指定された物理的なエリアに文書オブジェクトツリーを格納するための処理を行う。
【００６２】
文書オブジェクトツリー削除部４２は、文書記憶部５中の指定された物理的なエリアに存在する文書オブジェクトツリーを削除するための処理を行う。
【００６３】
文書オブジェクトツリー取得部４３は、文書記憶部５中の（構造化文書パスなどにより）指定された物理的なエリアに存在する文書オブジェクトツリーを取得するための処理を行う。
【００６４】
文書文字列取得部４４は、文書オブジェクトツリーを構造化文書（ＸＭＬ文書）に変換するための処理を行う。
【００６５】
文書パーサ部４６は、ユーザにより入力された構造化文書を読み込んで、その文書構造の検査を行う。さらに文書構造の定義データであるスキーマが存在すれば、入力された構造化文書の文書構造がスキーマにしたがっているかどうかの検証を行う。出力結果は文書オブジェクトツリーとなる。文書パーサは、通常、ｌｅｘ（ｌｅｘｉｃａｌ ａｎａｌｙｚｅｒ ｇｅｎｅｒａｔｏｒ）といったレキシカルアナライザ（字句解析を行い，トークンに分解する）とｙａｃｃ（ｙｅｔａｎｏｔｈｅｒ ｃｏｍｐｉｌｅｒ ｃｏｍｐｉｌｅｒ）といったパーサジェネレータを組み合わせて構築することができる。
【００６６】
合成文書作成部４７は、文書の格納や文書の削除などをする際に、スキーマに合致しているかどうか検査しなければならないが、この検査時に必要となるデータを作成する。
【００６７】
インデックス更新部４８は、文書の格納や文書の削除などにより、構造化文書データベースの格納内容が更新されるたびに、図９、図１０に示した要素名称生起インデックスとデータ生起インデックスを更新する。
【００６８】
文書記憶部５中の物理的なエリアとは、ファイルオフセットやオブジェクトＩＤなどの構造化文書データベース内ではユニークな文書データの存在場所を指し示す内部データである。ユーザにとっては認識不可能なデータである。
【００６９】
検索要求処理部３は、データアクセス部４に備わっている各処理機能部を用いて、文書記憶部５中に格納された文書を検索する処理を行う。要求制御部１の要求受付部１１でユーザからの文書検索の要求が受け付けられると、検索要求処理部３には、要求受付部１１からクエリ言語で記述されたクエリ文書が入力する。そしてデータアクセス部４を通してインデックス記憶部６，文書記憶部５にアクセスし、検索要求に合致する文書の集合を取得して、その結果を結果処理部１２を介して出力する。
【００７０】
図２は、図１に示した構造化文書管理システムの一利用形態を示したもので、図２では、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）のバックエンドで、図１に示した構成の構造化文書管理システム１００が動作している場合を示している。
【００７１】
複数（ここでは、例えば３つ）のクライアント端末（例えばパーソナルコンピュータ、携帯通信端末など）１０２のそれぞれでＷＷＷブラウザ１０３が動作している。ユーザは、各クライアント端末からＷＷＷサーバ１０１にアクセスすることにより、構造化文書管理システム１００にアクセスすることができる。ＷＷＷブラウザ１０３とＷＷＷサーバ１０１とは、ＨＴＴＰ（Ｈｙｐｅｒ ＴｅｘｔＴｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）で通信している。また、ＷＷＷサーバ１０１と構造化文書管理システム１００とは、ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）またはＣＯＭ（Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）などで通信している。
【００７２】
文書の格納、文書の取得、文書の検索などのユーザからの要求は、ＷＷＷブラウザ１０３から送信されて、ＷＷＷサーバ１０１を通して構造化文書管理システム１００にて受け付けられる。構造化文書管理システム１００にて処理された結果は、ＷＷＷサーバ１０１を通して要求元のＷＷＷブラウザ１０３へ返信される。
【００７３】
以下、図１の構造化文書管理システムの（１）格納機能、（２）検索機能について詳細に説明する。
【００７４】
（格納機能）
図１の構造化文書管理システムにおける格納系のコマンドには以下のものがある。
【００７５】
ｉｎｓｅｒｔＸＭＬ（パス、Ｎ番目、ＸＭＬ）：文書格納
ａｐｐｅｎｄＸＭＬ（パス、ＸＭＬ） ：文書格納
ｇｅｔＸＭＬ（パス） ：文書取得
ｒｅｍｏｖｅＸＭＬ（パス） ：文書削除
ｓｅｔＳｃｈｅｍａ（パス、スキーマ） ：スキーマ格納
ｇｅｔＳｃｈｅｍａ（パス） ：スキーマ取得
「ｉｎｓｅｒｔＸＭＬ」は、（ ）内に指定した構造化文書パス以下のＮ番目に文書を挿入するコマンド（以下、簡単に挿入コマンドと呼ぶ）である。
【００７６】
「ａｐｐｅｎｄＸＭＬ」は、（ ）内に指定した構造化文書パス以下の最後に文書を挿入するコマンド（以下、簡単に追加コマンドと呼ぶ）である。
【００７７】
「ｇｅｔＸＭＬ」は、（ ）内に指定した構造化文書パス以下の文書を取り出すコマンド（以下、簡単に取得コマンドと呼ぶ）である。
【００７８】
「ｒｅｍｏｖｅＸＭＬ」は、（ ）内に指定した構造化文書パス以下の文書（スキーマ文書以外の文書で、主に、コンテンツ文書）を削除するコマンド（以下、簡単に削除コマンドと呼ぶ）である。
【００７９】
「ｓｅｔＳｃｈｅｍａ」は、（ ）内に指定した構造化文書パスにスキーマを設定するコマンド（以下、簡単にスキーマ格納コマンドと呼ぶ）である。
【００８０】
「ｇｅｔＳｃｈｅｍａ」は、（ ）内に指定した構造化文書パスに設定されているスキーマを取り出すコマンド（以下、簡単にスキーマ取得コマンドと呼ぶ）である。
【００８１】
上記コマンドのうち、挿入コマンド、追加コマンド、スキーマ格納コマンドについての処理はアクセス要求処理部２の文書格納部２１で実行され、取得コマンド、スキーマ取得コマンドについての処理は文書取得部２２で実行され、削除コマンドについての処理は文書削除部２３で実行される。
【００８２】
図５を参照して、構造化文書データベースの初期状態（図５（ａ）参照）において、追加コマンドを実行する場合について説明する。
【００８３】
図５（ａ）に示すように、「＃０」ノードと「＃１」ノードが「ｒｏｏｔ」アークで接続されている初期状態に対して、
「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」を実行した結果、図５（ｂ）に示すように、「＃２」ノードと「特許ＤＢ」アークが作成される。
【００８４】
図５（ｂ）に示した状態の構造化文書データベースに対して、取得コマンドを実行する場合について説明する。
【００８５】
例えば、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”）」を実行すると、図５（ｂ）の「ｒｏｏｔ」アークが示す「＃０」ノード以下の文書オブジェクトツリーが取り出され、それをＸＭＬ文書に変換する。その結果、「＜ｒｏｏｔ＞＜特許ＤＢ／＞＜／ｒｏｏｔ＞」なる文字列が取り出されて、図６に示すようなＸＭＬ文書に変換される。取得コマンドの処理は、アクセス要求処理部２の文書取得部２２にて実行される。
【００８６】
次に、図５（ｂ）に示した状態の構造化文書データベースに対して、図３に示すようなコンテンツ文書（ＸＭＬ文書）としての「特許」情報を格納するための追加コマンドを実行する場合について説明する。すなわち、この場合、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」を実行する。このコマンド中「“＜特許＞…＜／特許＞”」が、図３に示した「特許」情報のＸＭＬ文書に対応する。
【００８７】
上記追加コマンドの処理が実行されると、図７に示すように、「＃２」ノード以下に「＃４２」ノードをトップとする文書オブジェクトツリー（図４に対応）が追加される。
【００８８】
図５（ｂ）に示した状態の構造化文書データベースに対して、次に示すような追加コマンドを３回繰り返して実行したとする。
【００８９】
「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」
上記コマンド中、「＜特許＞…＜／特許＞」は、図３に示したＸＭＬ文書と同じ文書構造のコンテンツ文書に対応する。
【００９０】
すると、図８に示すように、「＃２」ノード以下に「＃４２」ノード、「＃５２」ノード、「＃６２」ノードをトップとする文書オブジェクトツリーが追加される。
【００９１】
次に、図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合について説明する。この場合、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」を実行する。すると、「特許ＤＢ」アークが示す「＃２」ノード以下の文書オブジェクトツリーが取り出される。その結果、図１１に示すように、「＜特許ＤＢ＞＜特許＞…＜／特許＞＜特許＞…＜／特許＞＜特許＞…＜／特許＞＜／特許ＤＢ＞」なるＸＭＬ文書が取得できる。
【００９２】
構造化文書データベースでは、上記の「特許」情報などのコンテンツ文書（ＸＭＬ文書）の文書構造を定義したデータ、すなわち、スキーマも管理対象とする。
【００９３】
図１２は、ＸＭＬ文書の文書構造を定義するスキーマの一例を示したものである。ここでは、ＸＭＬの文書構造定義言語の一つであるＸＤＲ（ＸＭＬ−Ｄａｔａ Ｒｅｄｕｃｅｄ）を取り上げる。もちろん、ＸＭＬ−Ｓｃｈｅｍａなど他の文書構造定義言語を用いてもかまわない。
【００９４】
図１２に示したスキーマは、図３に示した「特許」情報の文書構造をＸＤＲで定義したものである。図１２からも容易に分かるとおり、スキーマもＸＭＬ形式の構造化文書である。「Ｓｃｈｅｍａ」タグから始まる構成要素から始まり、その子要素として、「ＥｌｅｍｅｎｔＴｙｐｅ」タグから始まる要素集合が存在する。
【００９５】
図８に示した状態の構造化文書データベースに対して、図１２に示したスキーマ文書を格納するためのスキーマ格納コマンドを実行する場合について説明する。この場合、「ｓｅｔＳｃｈｅｍａ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”）」を実行する。このコマンド中、「“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”」」が図１２に示したスキーマ文書に対応する。
【００９６】
上記コマンドの実行により、図１３に示すように、「＃２」ノード以下に「＃ｓｃｈｅｍａ」アークが追加され、その先には、「＃３」ノードをトップノードとする文書オブジェクトツリーが追加される。スキーマ自身がＸＭＬ文書表現になっているため、前述した「特許」情報のようなコンテンツ文書格納のケースと同様に、図１３に示したように、ツリー展開される。
【００９７】
図１３において、「＠ｎａｍｅ」のように、「＠」で始まるアークは属性に対応する。タグ名「＃ｓｃｈｅｍａ」も「＃」、「＠」で始まるためＸＭＬ規格においては標準的なタグ名として利用することはできない。
【００９８】
「＃２」ノード以下に図１２に示したスキーマ文書が格納されたことにより、以後、「＃２」ノード以下に格納される文書の文書構造は、図１２に示したスキーマ文書により定義された文書構造に適合することを要求してもよい。すなわち、この場合、「＃２」ノード以下に図１２に示したスキーマが設定されることになる。
【００９９】
「＃２」ノード以下に図１２に示したスキーマが設定されると、例えば、図１４に示すように、「＃２」ノード以下の文書オブジェクトツリーの各ノード（のファイル）には、スキーマが存在する旨の属性値がセットされる。
【０１００】
「＃２」ノード以下に図１２に示したスキーマが設定された後に、このスキーマで定義された文書構造に一致する図３に示したような「特許」情報の文書を、図１４に示したように、文書オブジェクトツリーとして構造化文書データベースに格納したとき、この文書の文書構造には図１２に示したスキーマが存在する旨の属性値が、当該文書オブジェクトツリーを構成する各文書オブジェクトにセットされる。例えば、当該文書オブジェクトツリーを構成する各文書オブジェクトのファイルに対して、スキーマが存在している旨の属性値（例えば、「スキーマ適合有無」）に「１」がセットされる。図１４では、スキーマに適合している各文書オブジェクト（ノード）は２重丸で示している。２重丸で示した各文書オブジェクトには、その文書オブジェクトに対応した文書構造定義が存在することになる。
【０１０１】
図１５は、各文書オブジェクトのファイルの内容を概念的に示したもので、例えば、オブジェクトＩＤが「＃４２」の文書オブジェクトのファイルには、その文書オブジェクトにリンクされている他の文書オブジェクトに関する情報（例えば、アークや、リンク先の文書オブジェクトへのポインタ値など）とともに、上記属性値が記述されている。なお、当該文書オブジェクトに適用するスキーマが存在しないときは、「スキーマ適合有無」の値は「０」となる。
【０１０２】
図１６、図１７は、図１の構造化文書管理システムで、必要に応じて検索条件として用いるキーワードなどとして使用される語をその意味内容から階層的に分類した結果である概念階層を構造化文書で表現した例を示す。図１６、図１７に示す「概念」情報はＸＭＬで記述したコンテンツ文書である。
【０１０３】
図１６に示した「概念」情報の例は、いわゆる特許調査における特許文書の内容を分類するための１つの分類軸として用いる「情報モデル」を概念階層で表現している。「概念」タグで囲まれた「概念」情報は、入れ子構造を持った文書構造をもっている。つまり、図１６の例では、概念「情報モデル」の子供概念として、概念「ドキュメント」、概念「リレーション」、概念「オブジェクト」が存在している。また、概念「ドキュメント」の子供概念として、概念「構造化ドキュメント」、概念「非構造化ドキュメント」が存在する。さらに、概念「構造化ドキュメント」の子供概念として、概念「ＸＭＬ」、概念「ＳＧＭＬ」が存在している。
【０１０４】
図１７に示す「概念」情報の記述例は、図１６とは異なる分類軸「情報操作」を概念階層で表現している。図１７の例では、概念「情報操作」の子供概念として、概念「検索」、概念「格納」、概念「加工」、概念「流通」が存在している。
【０１０５】
図１６，図１７に示したような「概念」情報も、前述の「特許」情報と同様にして、構造化文書データベース内に格納することができる。すなわち、例えば、まず、図８に示した状態の構造化文書データベースに対して、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜概念ＤＢ／＞”）」を実行して、図１８に示すように、「＃２０１」ノードと「概念ＤＢ」アークが作成される。この状態において、図１６に示した「概念」情報を格納する場合には、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／概念ＤＢ”，“＜概念名前＞…＜／概念＞”）」を実行する。このコマンド中「“＜概念名前＞…＜／概念＞”」が、図１６に示した「概念」情報に対応する。
【０１０６】
上記追加コマンドの処理が実行されると、図１９に示すように、「＃２０１」ノード以下に「＃２０２」ノードをトップとする文書オブジェクトツリーが追加される。
【０１０７】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。そのため、部分的なＸＭＬ文書をアクセスするには巨大なＸＭＬ文書に対するパスという、文書構造に依存しない統一的なアクセス手段を用いることにより、幅広くＸＭＬ文書を検索したり加工したりすることが可能になる。
【０１０８】
また、構造化文書データベース上の一部にスキーマを設定することで、格納しようとする文書の文書構造がそのスキーマにより定義されている文書構造に一致するか否かの妥当性のチェックを自動的に行うようにしてもよい。
【０１０９】
（検索機能）
図１の構造化文書管理システムにおける検索系のコマンドには以下のものがある。
【０１１０】
ｑｕｅｒｙ（ｑｌ）
「ｑｕｅｒｙ」は、パラメータとして（ ）内のクエリｑｌを実行し、その結果のＸＭＬ文書を取得するコマンド（以下、検索コマンドと呼ぶ）である。
【０１１１】
クエリは、例えば、図２０に示すように、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）に似た形式の言語により、検索位置、検索条件、情報抽出部分などを記述した、文書構造をもつＸＭＬ文書である。クエリ文書も構造化文書管理システムの管理対象である。
【０１１２】
「ｋｆ：ｆｒｏｍ」タグから始まる要素には、検索位置の指定と文書要素の値に変数を対応付ける記述があり、「ｋｆ：ｗｈｅｒｅ」タグのから始める要素には、変数に関する条件づけの記述があり、「ｋｆ：ｓｅｌｅｃｔ」タグから始まる要素には、検索結果の出力形式が記述される。
【０１１３】
検索には、単純検索と概念検索とがある。単純検索とは、クエリ中に指定された検索条件を満たす情報を検索・抽出するものであり、概念検索とは、クエリ中に指定された概念情報を利用して、クエリ中に指定された検索条件を満たす情報を検索・抽出するものである。
【０１１４】
図２１は、単純検索のクエリの例を示したものである。図２１のクエリは、例えば、図１４に示したような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群において、「１９９９年でかつ、「ＰＣ」のような内容の「要約」という要素をもつ文書（「特許」情報）の「タイトル」を列挙せよ」という検索要求の記述例を示している。
【０１１５】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」、「＄ｙ」、「＄ｓ」に、それぞれ「特許」情報の「タイトル」、「年」、「要約」という文書要素の値が代入される。
【０１１６】
「ｋｆ：ｗｈｅｒｅ」タグから始める要素の記述により、変数「＄ｙ」＝「１９９９」という比較がなされる。また、コンポーネント「ＭｙＬｉｋｅ」は変数「＄ｓ」と「ＰＣ」を引数として、「ＰＣ」と類似する値の変数「＄ｓ」を検知するための関数である。
【０１１７】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」が出力値として利用される。
【０１１８】
なお、「ｋｆ：ｓｔａｒ」タグは構造の曖昧表現であり、例えば「＜特許＞＜ｋｆ：ｓｔａｒ＞＜年＞」は「タグ名が「特許」である要素の子孫の要素としていずれかに存在し、タグ名が「年」である要素」を意味する。
【０１１９】
図２２に図２１の単純検索のクエリを用いた検索結果を示す。この検索結果もＸＭＬ文書である。
【０１２０】
図２３は、概念検索のクエリの例を示したものである。図２３のクエリは、例えば図１８，図１９に示すような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群に対し、「概念ＤＢ」アークが示すノード以下に格納されている「概念」情報を利用して検索するための検索要求の記述例を示している。ここで、概念「周辺装置」の値をもつタグの子要素の値には、概念「ＳＣＳＩ」、「メモリ」、「ＨＤＤ」などがあるものとする。また、図１８には示していないが、各「特許」情報の構成要素には、「キーワード」タグから始める要素も存在するものとする。
【０１２１】
すなわち、図２３のクエリは、「概念「周辺装置」以下の概念のいずれかを「キーワード」という構成要素の要素値としてもつ「特許」情報の「タイトル」を列挙せよ」という検索要求の記述例を示している。
【０１２２】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」、変数「＄ｋ」に、それぞれ、「特許」情報の「タイトル」、「キーワード」という要素の値が代入される。また、変数「＄ｘ」は「概念」情報として「周辺装置」の値をもつタグの子要素の値（「ＳＣＳＩ」、「メモリ」、「ＨＤＤ」など）が代入される。
【０１２３】
「ｋｆ：ｗｈｅｒｅ」タグから始める要素の記述により、「＄ｋ」＝「周辺装置」もしくは「＄ｋ」＝「＄ｘ」という比較がなされる。
【０１２４】
次に、図１の構造化文書管理システムの文書検索処理動作について、図２４に示すフローチャートを参照して説明する。
【０１２５】
クライアント端末の所定の表示装置には、構造化文書管理システム１００（の例えば、要求制御部１）から提供された、例えば、図２５に示すようなユーザインターフェイスとしての画面が表示されている。
【０１２６】
図２５に示した画面上で、ユーザが「ＸＭＬ検索Ｗｉｎ」をマウス等のポインティングデバイスなどを用いて選択すると、図２６に示すような文書検索を行うためのユーザインタフェースとしての画面が表示される。
【０１２７】
図２６の検索画面において、領域Ｗ１には、構造化文書データベースの現在のツリー構造の構成要素の要素名（タグ名）がユーザが理解可能なように簡略的に表示されている。なお、図２６では、上位階層の要素名のみを表示しているが、末端の要素名まで表示可能である。
【０１２８】
領域Ｗ１１は、検索対象の範囲（ツリー構造上の検索範囲）や、検索条件などを入力するための領域である。領域Ｗ１２には、検索結果が表示される。
【０１２９】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグをもつ構成要素の要素値に「文書」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という検索要求の場合には、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、領域Ｗ１１には、まず、トップノードとして、「特許」を入力する（この場合、領域Ｗ１から「特許」をマウス等で選択することにより入力してもよい）。また、検索条件としての、「「タイトル」という構成要素の要素値に「文書」という文字列を含む」「「年」という構成要素の要素値が「１９９８」以上である」という内容は、予め設けられたデータ入力領域に入力すればよい。
【０１３０】
その後、「検索」ボタンＢ２１を選択することにより、例えば、図２７に示すようなクエリが、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。なお、クエリの格納場所は、予め定められており、システム側が自動的に、この追加コマンドのパラメータを設定することとなる。例えば、構造化文書データベースが図１８に示した状態のとき、当該クエリの格納場所を表すパラメータとしての構造化文書パスは、「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」となる。また、追加コマンドのもう一方のパラメータは、当該クエリ文書である。
【０１３１】
要求受付部１１は、上記クエリを受け付けると（ステップＳ１００）、当該クエリを検索要求処理部３へ渡す。そして、当該クエリ文書を格納するための追加コマンドのパラメータを文書格納部２１へ渡す。文書格納部２１では、追加コマンドの処理を行って、当該クエリは、文書記憶部５に格納される（ステップＳ１０１）。
【０１３２】
一方、検索要求処理部３では、受け取ったクエリを基に、データアクセス部４を通してインデックス記憶部６，文書記憶部５にアクセスし、検索要求に合致する文書集合などを取得して、クエリの中で要求された情報を抽出して結果処理部１２を介して出力する。
【０１３３】
例えば、上記クエリの場合、まず、「「タイトル」タグをもつ構成要素の要素値に「文書」という文字列を含む」という条件に合致するものを検索することが検索対象を絞り込む上で効率がよい。そこで、図１０に示したようなデータ生起インデックスを用いて、「文書」という文字列にリンクされているノード（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを上流側に１つ遡り、「タイトル」というタグ名にたどり着いたときは、更に上流に辿っていき、「特許」というタグ名にたどり着いたときは、そのノード以下の文書オブジェクトツリーＯｔ１１を抽出する。
【０１３４】
次に、この抽出された複数の文書オブジェクトツリーＯｔ１１の中から、さらに、「年」という構成要素の要素値が「１９９８」年以上の文書オブジェクトツリーＯｔ１２を抽出する。
【０１３５】
この文書オブジェクトツリーＯｔ１２が上記クエリの内容に適合する文書となる。さらに上記クエリの要求内容に従えば、各文書オブジェクトツリーＯｔ１２のトップノードへの構造化文書パスを求める（ステップＳ１０２）。
【０１３６】
なお、上記検索処理は、上記した方法に限るものではなく、インデックス情報を用いた様々な効率のよい検索方法が可能である。
【０１３７】
検索要求処理部３は、ステップＳ１０２で得られた結果を統合して、検索結果としてのＸＭＬ文書を作成する（ステップＳ１０３）。
【０１３８】
例えば、検索結果のＸＭＬ文書は、
＜ｏｕｔ＞
＜ｒｅｓｕｌｔ＞
ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］
＜／ｒｅｓｕｌｔ＞
＜ｒｅｓｕｌｔ＞
ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［２］
＜／ｒｅｓｕｌｔ＞
＜／ｏｕｔ＞
となる。
【０１３９】
検索要求処理部３は、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す（ステップＳ１０４）。
【０１４０】
クライアント端末では、図１１に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図２６に示すように、領域Ｗ１２に表示する。ここでは、例えば検索結果として得られた構造化文書の数が多いために、検索された構造化文書の構造化文書パスが検索結果として表示されている。この場合、例えば、図２６の領域Ｗ１２に表示された検索結果の構造化文書パスのうち、所望の１つがユーザにより選択されたとする。例えば、図２６の領域Ｗ１２に表示された構造化文書パスのうち、最初のものが選択されたとする。この場合、クライアント端末から構造化文書管理システムに対し、当該選択された構造化文書パスにより特定される構造化文書を取得するために文書取得要求として、取得コマンドを送信するようにしてもよい。
【０１４１】
取得コマンドが構造化文書管理システムの要求受付部１１にて受け付けられたときの、図１の構造化文書管理システムの文書取得処理動作について、図２８に示すフローチャートを参照して説明する。
【０１４２】
例えば、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］”）」なる取得コマンドが構造化文書管理システムへ送信される。
【０１４３】
ここでは、例えば、構造化文書データベースが、図８に示した状態のときに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］”）」なる取得コマンドを受け付けた場合を例にとり説明する。
【０１４４】
要求受付部１１は、上記取得コマンドを受け付けると、上記取得コマンド中のパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」を文書取得部２２へ渡す（ステップＳ３１）。
【０１４５】
文書取得部２２は、文書オブジェクトツリー取得部４３へ構造化文書パスを渡す。文書オブジェクトツリー取得部４３は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ５）を取り出す（ステップＳ３２）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ５のオブジェクトＩＤを取得することができるので（ステップＳ３３）、その場合は、ステップＳ３５へ進む。
【０１４６】
例えば、上記取得コマンドの場合、「＃４２」ノードが文書オブジェクトＯｘ５となるので、そのオブジェクトＩＤとして、「＃４２」を取得するとともに、この「＃４２」ノード以下の文書オブジェクトツリーＯｔ５（「＃４２」ノード〜「＃４９」ノード）を取得する（ステップＳ３５）。
【０１４７】
ステップＳ３２において、指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ５が見つからなければ、エラーとなり（ステップＳ３３）、文書取得部２２，結果処理部１２を介して、クライアント端末に「文書取得失敗」の旨のメッセージを返す（ステップＳ３４）。
【０１４８】
ステップＳ３５で取得した文書オブジェクトツリーＯｔ５は、文書文字列取得部４４でＸＭＬ文書に変換される。例えば、上記取得コマンドの場合、取得したＸＭＬ文書は、図３に示すような「特許」情報のＸＭＬ文書となる。
【０１４９】
文書取得部２２は、結果処理部１２を介して、図３に示したようなＸＭＬ文書を（例えば、ＸＳＬ（ｅＸｔｅｎｓｉｂｌｅ Ｓｔｙｌｅ Ｌａｎｇｕａｇｅ）といった所定のスタイルシートとともに）、クライアント端末へ返す（ステップＳ３７）。
【０１５０】
クライアント端末では、図３に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図２９に示すように、領域Ｗ１３に表示する。
【０１５１】
ＸＳＬを利用すると、ＸＭＬ文書を様々な形に変換することが出来る。違う構文書造のＸＭＬ文書に変換することも出来るし、ＸＭＬ文書からＨＴＭＬページを生成することも出来る。
【０１５２】
同様にして、スキーマの検索も行える。
【０１５３】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「ｓｃｈｅｍａ」を先頭タグに持つ文書の中から、「特許」と「要約」というタグ名を持つスキーマを検索せよ」という検索要求の場合には、図３０に示すように、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、トップノードとして、「＃ｓｃｈｅｍａ」を入力する。また、検索条件として、「構成要素の属性名に「特許」という文字列を含む」「構成要素の属性名に「要約」という文字列を含む」という内容を予め設けられたデータ入力領域に入力すればよい。
【０１５４】
その後、「検索」ボタンＢ２１を選択することにより、上記検索要求を記述した、例えば、図３１に示したようなクエリが、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。
【０１５５】
さて、上記クエリの場合、例えば、「「＃ｓｃｈｅｍａ」を先頭タグに持つ」という条件に合致するものを検索する。そこで、図９に示したような要素名称生起インデックスを用いて、「＃ｓｃｈｅｍａ」という要素にリンクされているノードの（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、属性名が「特許」と「要約」いう要素にたどり着いたときは、当該「＃ｓｃｈｅｍａ」を先頭タグにもつ文書オブジェクトツリーＯｔ２１を抽出する。この文書オブジェクトツリーＯｔ２１が上記クエリの内容に適合する文書となる。さらに、図３１に示したクエリの要求内容に従えば、各文書オブジェクトツリーＯｔ２１のトップノードへの構造化文書パスを求める。
【０１５６】
検索要求処理部３は、文書オブジェクトツリーＯｔ２１が複数あれば、それぞれのトップノードへの構造化文書パスをまとめて、検索結果としてのＸＭＬ文書を作成し、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す。
【０１５７】
クライアント端末では、検索結果として受け取ったＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図２６に示すように、領域Ｗ１２に表示する。
【０１５８】
クライアント端末では、検索結果の中の１つのスキーマを選択して、表示させると、例えば、図３２に示すような文書の格納／削除を行うための画面とともに、その領域Ｗ３に、「特許」情報のデータ入力領域が各要素毎に設定されて表示される。
【０１５９】
ユーザは、このデータ入力領域にデータを入力することで、スキーマにより定義された文書構造の格納文書が容易に作成することができる。
【０１６０】
例えば、図３２の領域Ｗ３に入力した「特許」情報の格納先として、領域Ｗ１で「特許ＤＢ」をマウス等を用いて選択すると、領域Ｗ２に構造化文書パスとして、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される。その後、「登録」ボタンＢ１を選択すると、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０１６１】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。従って、文書構造が異なる、様々なスキーマを持つ膨大な数の文書の中から検索条件に合致する文書を容易に検索できる。
【０１６２】
また、検索に用いるクエリも構造化文書であるので、構造化文書データベースにログとして格納することにより、過去のクエリを再利用するようなアプリケーションも容易に構築することができる。
【０１６３】
（絞込検索）
以下、本発明の実施形態について、図面を参照して説明する。
【０１６４】
ここでは、ユーザは、単に、検索したい構造化文書の構成要素の要素名や要素値に含まれるようなキーワードを入力しさえすれば、絞込検索を通じて所望の構造化文書が容易に検索することができる手法を適用した検索支援装置について説明する。
【０１６５】
この検索支援装置は、例えば、図２のクライアント端末１０２内に構成されていてもよい。この場合、検索支援装置は、前述の図１に示した構造化文書管理システムに入力するためのクエリを生成して、それを図１の構造化文書管理システムに送信したり、また、当該クエリに基づく検索結果を取得して、この検索結果から絞込条件を抽出しユーザに呈示するなどの処理を行うものである。
【０１６６】
図３３は、本実施形態にかかる検索支援装置２０１の構成例を示したもので、例えば、クライアント端末１０２のブラウザ１０３に組み込まれて構成されている。このように図３３に示した検索支援装置２０１は、アドインソフトとして構成可能である。
【０１６７】
図３３に示したように、検索支援装置２０１は、初期条件入力部２１１と検索要求発行部２１２と検索結果取得部２１３と検索結果サンプリング部２１４と絞り込み条件抽出部２１５と選択部２１６と検索結果表示部２１７から構成されている。
【０１６８】
構造化文書管理システム１００は、検索支援装置２０１から送られてきたクエリと呼ばれる検索要求を受信して、ＸＭＬデータベース（すなわち、ここでは文書記憶部５に格納されている、例えば、図８に示したような階層化された論理構造をもつデータベース）から当該検索要求にマッチする検索結果としてのＸＭＬ文書を検索し、ＸＭＬデータの並びという形式で検索支援装置２０１に送信する。
【０１６９】
ＸＭＬデータの並びは、必ずしもテキスト列というわけではなく、バイナリ化されている場合もある。
【０１７０】
初期条件入力部２１１は、検索したい文書を検索するための検索条件を生成するために必要な、少なくとも１つのキーワード（複数のキーワードであってもよい）を入力するためのものである。
【０１７１】
前述したように、ＸＭＬデータベースには様々な構造（文書構造）や語彙を持ったＸＭＬデータ（ＸＭＬ文書）が大量に格納されているため、ユーザはこのＸＭＬデータベースの中から所望の文書を検索するために前もって明確なＸＭＬデータに対する検索条件を設定することは困難である。明確な検索条件とは、ＸＭＬデータに対する構造に関する条件や語彙に関する条件が必要十分なことである。そこで、ユーザはフルテキスト検索などと同様にキーワードレベルの粗い検索条件しか設定できない場合がほとんどである。初期条件入力部２１１では、そのような粗い検索条件がユーザにより入力されると、検索要求発行部２１２を呼び出す。
【０１７２】
検索要求発行部２１２では、上記入力されたキーワードを検索条件として構造化文書管理システムが認識できるような形式に変換する。すなわち、上記入力されたキーワードを構成要素の要素名あるいは要素値に含むようなＸＭＬ文書を検索するためのクエリ（あるいは、以下に示すように、入力されたキーワードを構成要素の要素値に含むようなＸＭＬ文書を検索するためのクエリであってもよい）を生成し、当該クエリを構造化文書管理システム１００へ送信する。
【０１７３】
検索結果取得部２１３は、検索要求発行部２１２で生成されたクエリに基づき構造化文書管理システム１００で検索されたＸＭＬデータ（ＸＭＬ文書、簡単に文書と呼ぶこともある）の集合を取得する。ここで検索結果として得られたＸＭＬ文書の数が多い場合には、検索結果サンプリング部２１４にて、当該検索結果として得られたＸＭＬ文書の中から所定数のＸＭＬ文書を選択し、この選択したＸＭＬ文書を処理対象の文書として絞り込み条件抽出部２１５へ渡す。例えば、検索結果のうちの「最初の１００件」を無作為に取り出すことにより、実用時間内で応答するように制御するようになっている。もちろん検索結果として得られたＸＭＬ文書の数が少ない（例えば、上記の例の場合、１００件に満たない場合）には、その全てを処理対象の文書として絞り込み条件抽出部２１５へ渡すようにしてもよい。
【０１７４】
なお、検索結果サンプリング部２１４は、必ずしも設ける必要はなく、この構成部のない検索支援装置も構成可能である。この場合、検索結果取得部２１３は、構造化文書管理システム１００から得られた検索結果としてのＸＭＬ文書を全て処理対象の文書として絞り込み条件抽出部２１５へ渡せばよい。
【０１７５】
絞り込み条件抽出部２１５は、検索結果として得られたＸＭＬ文書（具体的には、検索結果サンプリング部２１４で取り出されたＸＭＬ文書）を処理対象として、この処理対象の文書から、さらに絞り込みをかけるための、より詳細な検索条件としての絞り込み条件を抽出する。なお、絞り込み条件とは、初期条件入力部２１１にてユーザから設定された粗い検索条件をより詳細化した検索条件である。例えば、処理対象の文書の文書構造上の違いや、各処理対象の文書に含まれている単語などの語彙の違いなどが絞り込み条件の候補として抽出される。
【０１７６】
検索結果表示部２１７は、抽出された絞り込み条件と、検索結果として得られたＸＭＬ文書の一覧などを表示するための表示データを作成し、クライアント端末１０２のディスプレイなどに表示する。
【０１７７】
選択部２１６は、検索結果表示部２１７により表示された複数の絞り込み条件のうちの１つがユーザにより選択されると、検索要求発行部２１２を呼び出す。このとき、検索要求発行部２１２では、直前の検索結果のＸＭＬ文書の中から、さらに当該選択された絞り込み条件を満たすＸＭＬ文書を検索するためのクエリ（すなわち、初期条件とそれまでに選択された絞り込み条件とを全て満たすＸＭＬ文書を検索するためのクエリ）が生成される。このクエリは構造化文書管理システムへ送信される。構造化文書管理システムにおいて当該クエリに基づき検索を行った結果は、検索結果取得部２１３により取得される。
【０１７８】
次に、図３４〜３６に示すフローチャートに従って、図３３に示した検索支援装置の処理動作について説明する。
【０１７９】
前述したように、ＸＭＬデータベースには、異なる文書構造の複数のＸＭＬ文書がその文書構造に基づく階層構造に従って格納されている。この検索支援装置の処理動作の説明に際しては、ＸＭＬデータベースの具体例を示さないが、以下に示す検索結果として得られた「ＢＯＯＫ」タグを先頭とする４つの文書は、ＸＭＬデータベースの「ｒｏｏｔ」ノード以下のいずれかに記憶されているものとする。また、「ＢＯＯＫ」ノード以下に格納されている文書は、全て同じ文書構造であるとは限らない（すなわち、スキーマが設定されていない）ものとする。従って、「ＢＯＯＫ」ノード以下に格納されている各文書は、例えば内容的には類似するものの文書構造が全て同一であるとは限らない。
【０１８０】
まず、ユーザは、初期条件入力部２１１から文書検索のための初期条件として、少なくとも１つのキーワードを入力する（ステップＳ２０１）。
【０１８１】
図３７は、初期条件入力部２１１からクライアント端末１０２のディスプレイに表示される初期条件入力画面の一例を示したものである。ユーザは、この初期条件入力画面上に設けられた入力領域Ｘ１に、文書を検索するための初期条件として、少なくとも１つのキーワードを入力する。ここでは、「ＸＭＬ」というキーワードが入力されているが、複数のキーワードを入力する場合には、それらをカンマなどで区切りながら並べて入力するようにしてもよい。
【０１８２】
ユーザにより初期条件としてのキーワードが入力されると、検索要求発行部２１２が起動し、ここでは、当該入力されたキーワードを構成要素の要素値に含むＸＭＬ文書を検索するためのクエリを生成する（ステップＳ２０２）。
【０１８３】
図３８は、検索要求発行部２１２で生成されたクエリの一例で、「ＸＭＬ」というキーワードをいずれかの構成要素の要素値に含むＸＭＬ文書を検索することを構造化文書管理システム１００に指示する検索要求文である。つまり、「ｋｆ：ｆｒｏｍ」節では、ＸＭＬデータベース中の検索位置として、構造化文書パスにて、「ｕｉｘ：／／ｒｏｏｔ」が指定されている。また、「ｋｆ：ｗｈｅｒｅ」節では、「ＸＭＬ」を要素値に含むという条件が記述されている。「ｋｆ：ｓｅｌｅｃｔ」節では、「ｕｉｘ：／／ｒｏｏｔ」以下に格納されている文書のうち、「ｋｆ：ｗｈｅｒｅ」節に記述されている条件にマッチする文書の集合を返すことが記述されている。
【０１８４】
なお、図３８に示したクエリは、要素値に「ＸＭＬ」というキーワードを含む文書を検索するクエリであるが、同様にして、検索要求発行部２１２は、要素名に「ＸＭＬ」というキーワードを含む文書を検索するクエリや、要素名と要素値のうちの少なくとも一方に「ＸＭＬ」というキーワードを含む文書を検索するクエリを生成することも可能である。
【０１８５】
検索要求発行部２１２は、例えば、図３８に示したようなクエリを生成するためのクエリの雛形を記憶している。この雛形は、例えば、ユーザにより入力されたキーワード「ＸＭＬ」を代入すれば、図３８に示したようなクエリが完成するものである。このように、検索要求発行部２１２は、ユーザにより入力された初期条件、あるいは選択された絞り込み条件を代入、追加さえすればクエリとして完成するクエリの雛形を複数種類予め記憶しておき、これを基にクエリを生成するようにしてもよい。
【０１８６】
さて、検索要求発行部２１２で生成されたクエリ（例えば、図３８に示したようなクエリ）は、構造化文書管理システム１００へ送信されると、構造化文書管理システム１００の要求処理部１で当該クエリが受け付けられ、前述したようにして、当該クエリに基づきＸＭＬデータベースの「ｒｏｏｔ」ノード以下から、要素値に「ＸＭＬ」というキーワードを含むＸＭＬ文書が検索される。検索した結果得られた文書は、クライアント端末１０２へ送信され、検索支援装置２０１の検索結果取得部２１３が当該検索結果を取得する（ステップＳ２０３）。
【０１８７】
例えば、構造化文書管理システムおいて１２０件の文書が検索されたものとする。この１２０件の文書全てが検索結果として検索支援装置２０１の検索結果取得部２１３で取得されるものとする。そして、検索結果サンプリング部２１４では、このうち、例えば、先頭の４件の文書を選択（サンプリング）したとする。
【０１８８】
この４件の文書を、図３９に示す。図３９に示すように、各文書Ｒｅｃ１〜４は、全て「ＢＯＯＫ」タグをルートとする構造化文書であり、「ＣＡＴＥＧＯＲＹ」タグをもつ構成要素は、４つの文書に共通する構成要素であり、また、「ＰＲＩＣＥ」タグをもつ構成要素は文書Ｒｅｃ１〜３には存在するが、文書Ｒｅｃ４には存在しない。
【０１８９】
図３９に示した４つの文書が処理対象の文書として、絞り込み条件抽出部２１５に渡される。絞り込み条件抽出部２１５では、これら４つの文書のそれぞれの文書構造と構成要素の要素値とから、絞り込み条件を抽出する（ステップＳ２０４）。絞り込み条件とは、初期条件入力部２１１にてユーザから設定された粗い検索条件をより詳細化した条件である。
【０１９０】
ここで、ステップＳ２０４の絞り込み条件抽出部２１５における絞り込み条件の抽出処理の一例について、図３６に示すフローチャートを参照して説明する。
【０１９１】
まず、今回の処理対象の４つの文書は、最初の検索結果であるので（ステップＳ２２１）、ステップＳ２２２へ進む。
【０１９２】
ステップＳ２２２では、この処理対象の文書のそれぞれの先頭の構成要素の要素名を抽出し、この抽出された要素名を条件としたとき、処理対象の文書のそれぞれが上記条件のうちどの条件を満たすのかを表した構造テーブルを作成する（ステップＳ２２２）。
【０１９３】
構造テーブルを作成することにより、処理対象の文書の文書構造上、語彙上の相違点が明らかとなる。構造テーブル上に、処理対象の文書の相違点が表れていれば、当該構造テーブル上の条件を絞り込み条件として用いることにより、絞り込みがより効率よく行える。そこで、この生成された構造テーブル上に、処理対象の文書間に存在する相違点が表れていないときには（ステップＳ２２３）、展開元の構成要素を選択し（ステップＳ２２４）、当該展開元の構成要素に包含される当該構成要素の要素値や構成要素などを抽出して、上記ステップＳ２２２と同様にして、これらを条件としたとき、処理対象の文書のそれぞれが、どの条件を満たすのかを表した構造テーブルを作成し（ステップＳ２２５）、ステップＳ２２３へ戻る。
【０１９４】
ステップＳ２２３において、作成された構造テーブルから、処理対象の文書に相違点があると判断することができるときには、ステップＳ２２６へ進む。
【０１９５】
次に、ステップＳ２２２やステップＳ２２５での処理の詳細と、構造テーブルについて説明する。
【０１９６】
構造テーブルのｘ軸方向には各文書の文書ＩＤを列のインデックスとして設定し、ｙ軸方向には、上記抽出された条件を行のインデックスとして設定し、各文書に対応する列を構成するセルのうち、当該文書が満たしている条件に対応するセルには「○」、当該文書が満たしていない条件に対応するセルに「×」が書き込まれている。
【０１９７】
ＸＭＬ文書の集合を絞り込むための絞り込み条件は、一般に複数ある。構造テーブルにより、絞り込み条件を優先順位付けしてユーザに提示することで、ユーザは効率よく絞り込みが行えることになる。つまり、「どのような絞り込み条件があるのか分からない」、「どの絞り込み条件を設定すれば効率良く絞り込みができるのか分からない」、などのユーザ要求があるが、これを支援することができるのである。
【０１９８】
図４０は、構造テーブルの一例を示す図である。２つの構造テーブルが存在する。図４０（ａ）に示す構造テーブルは、処理対象としての４つのＸＭＬ文書Ｒｅｃ１〜Ｒｅｃ４から生成された最初の構造テーブルである。すなわち、ステップＳ２２２で生成された構造テーブルである。構造テーブルのｘ軸には、各ＸＭＬ文書の文書ＩＤ「Ｒｅｃ１」〜「Ｒｅｃ４」が並んでいる。ｙ軸には、各ＸＭＬ文書のルート（先頭）から各文書構造を展開した結果得られた条件が並んでいる。４つのＸＭＬ文書をルートから構造的に見ると、先頭の構成要素は、全て「ＢＯＯＫ」タグをもつ構成要素がある。すなわち、この時点で、“「ＢＯＯＫ」タグを持つ”という条件が抽出された。４つの文書Ｒｅｃ１〜Ｒｅｃ４には、それぞれ「ＢＯＯＫ」タグがあるので、図４０（ａ）に示すように、この条件を満足した印である「○」が並んでいる。
【０１９９】
これは、すべて条件を満足する「○」なので（４つの文書に相違点がない（「×」がない）ので）、ステップＳ２２３からステップＳ２２４へ進み、次に、この最初の構造テーブルを展開する（階層構造を１段下流に向かって掘り下げて、そこに存在する文書構造や語彙を調べる）ための処理を行う。
【０２００】
まず、この最初の構造テーブル上の条件の中から展開元を選択する（ステップＳ２２４）。この場合、「ＢＯＯＫ」という構成要素だけなので、必然的にこの「ＢＯＯＫ」が選択される。そして、ステップＳ２２５では、「ＢＯＯＫ」という構成要素に包含される（下流に繋がる）当該構成要素の要素値や構成要素の要素名を処理対象の文書のそれぞれから抽出し、それらを条件としたとき、処理対象の文書のそれぞれがどの条件を満たすのかを表した構造テーブルを作成する（図４０（ｂ））。
【０２０１】
例えば、処理対象の４つの文書のうちの１つである文書Ｒｅｃ１の「ＢＯＯＫ」という構成要素の１段下の階層には、図３９からも明らかなように、「ＣＡＴＥＧＯＲＹ」タグ、「ＴＩＴＬＥ」タグ、「ＰＵＢＬＩＳＨＥＤＤＡＴＥ」タグ、「ＰＲＩＣＥ」タグ、「ＡＢＳＴＲＡＣＴ」タグをそれぞれもつ構成要素がある。
【０２０２】
すなわち、ステップＳ２２５では、“「ＢＯＯＫ」タグを持つという条件”を展開することにより、“「ＢＯＯＫ」タグの下に「ＣＡＴＥＧＯＲＹ」タグがある”、“「ＢＯＯＫ」タグの下に「ＴＩＴＬＥ」タグがある”、“「ＢＯＯＫ」タグの下に「ＰＵＢＬＩＳＨＥＤＤＡＴＥ」がある”、などの構造的な条件群が得られる。もちろん、「ＢＯＯＫ」タグをもつ構成要素に要素値をもつものがあれば、それもこの段階で抽出されて、語彙的な条件として用いることもできる。
【０２０３】
図４０（ｂ）に示す構造テーブルでは、ｙ軸上に上記のような条件が並び、処理対象の４つの文書のそれぞれについて、当該条件を満たすか満たさないかを「○」「×」で表している。
【０２０４】
図４０（ｂ）からも明らかなように、「ＡＵＴＨＯＲ」という要素名の構成要素は、文書Ｒｅｃ２には存在しない。また、「ＰＲＩＣＥ」という要素名の構成要素は、文書Ｒｅｃ４には存在しない。すなわち、図４０（ｂ）に示した構造テーブルから、処理対象の４つの文書に相違点があることがわかる。そこで、この場合には、ステップＳ２２３からステップＳ２２６へ進む。
【０２０５】
なお、“「ＢＯＯＫ」タグを持つという条件”を展開しても、処理対象の文書に相違点が存在しないときには、ステップＳ２４へ進み、展開元として、例えば、図４０（ｂ）に示す構造テーブル上の条件のうち最初の条件から順番に選択して、相違点が表れるまで図４０（ｂ）に示す構造テーブルを展開するようにしてもよい。
【０２０６】
このように、構造テーブルは、処理対象の文書のそれぞれがもつ文書構造や、処理対象の文書のそれぞれが要素値として包含している語彙を比較するためのものであり、この構造テーブルを用いることにより、処理対象の文書における構造的な特徴と語彙的な特徴の一致点、相違点が明らかとなる。この処理対象の文書における構造的な特徴と語彙的な特徴の相違点を、絞り込み検索の際に用いる条件として用いれば、検索範囲をより限定することができ、絞り込みを効率よく行える。そこで、ここでは、この点に着目し、上記相違点を絞り込み条件の候補として優先的にユーザに呈示するものである。すなわち、各処理対象の文書の文書構造と、各処理対象の文書により包含される語彙とから抽出される条件のうち、処理対象の文書間に違いを生じさせるものほど、検索範囲を限定することができる絞り込み条件となり得るから、そのような条件ほど優先度（優先順位）を高く設定する。
【０２０７】
構造テーブル上に処理対象の文書の相違点が表れている場合、ステップＳ２２６では、例えば、図４０（ｂ）に示したような構造テーブル上の行のインデックスとして設定された各条件に対し、優先順位を定める。すなわち、ここでは、より絞り込まれた検索結果が得られるような条件ほど優先順位が高くなるように、優先順位を求める。
【０２０８】
優先順位の算出手法について、以下に詳細に説明する。この手法は、ＩＤ３（Ｊ．Ｒ．Ｑｕｉｎｌａｎ， ”Ｉｎｄｕｃｔｉｏｎ ｏｆ Ｄｅｃｉｓｉｏｎ Ｔｒｅｅｓ”， Ｍａｃｈｉｎｅ Ｌｅａｒｎｉｎｇ， Ｖｏｌ．１， ｐｐ．８１−ｐｐ．１０６， １９８６）などで使用されている期待情報量最大化原理に基づいて行うものである。つまり、Ｃを属性とその属性値、所属クラスによって表現される事例集合とする。Ａを属性の集合とし、Ｋをクラスの数、Ｐｊを事例集合Ｃの中で暮らすｊに属する事例の比率とすると、事例集合Ｃの情報量（エントロピー）Ｍ（Ｃ）は以下の式で表わされる。
【０２０９】
Ｍ（Ｃ）＝−Σ｛ｊ＝１，ｋ｝Ｐｊｌｏｇ２（Ｐｊ）
Ｃをある属性ａの属性値ａｉ，…ａｎによって部分集合Ｃ１，…Ｃｎに分割したときの期待情報量Ｂ（Ｃ，ａ）は以下の式で表わされる。
【０２１０】
Ｂ（Ｃ，ａ）＝Σ｛ｉ＝１，ｎ｝｜Ｃｉ｜／｜Ｃ｜×Ｍ（Ｃｉ）
獲得情報量の期待値ｇａｉｎ（Ｃ，ａ）は以下の式になる。
【０２１１】
ｇａｉｎ（Ｃ，ａ）＝Ｍ（Ｃ）−Ｂ（Ｃ，ａ）
このｇａｉｎ（Ｃ，ａ）を最大にする属性ａで事例集合を分割していくことで、効率的に事例をクラスに分けることができる。
【０２１２】
本実施形態の場合、各検索結果は、それぞれ別のクラスであるとして扱う。
【０２１３】
Ｍ（Ｃ）＝（−１／ｎ×ｌｏｇ２（１／ｎ））×ｎ （ｎ：条件Ｃを満たす文書の数）
ここで、図４０（ｂ）に示した構造テーブルの行のインデックスとして設定された各条件（Ｃ）についてＭ（Ｃ）を計算する。
【０２１４】
Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ”）＝（−１／４×ｌｏｇ２（１／４））×４＝２
Ｍ（“ＯＯＫ／ＴＩＴＬＥ”）＝２
Ｍ（“ＢＯＯＫ／ＰＵＢＬＩＳＨＥＤＤＡＴＥ”）＝２
Ｍ（“ＢＯＯＫ／ＡＵＴＨＯＲ”）＝（−１／３×ｌｏｇ２（１／３））×３＋（−１／１× ｌｏｇ２（１／１））×１＝１．１９
Ｍ（“ＢＯＯＫ／ＰＲＩＣＥ”）＝１．１９
Ｍ（“ＢＯＯＫ／ＡＢＳＴＲＡＣＴ”）＝２
この場合、Ｍ（Ｃ）の値が小さいものほど、絞り込まれた検索結果が得られる条件であることを表しており、優先順位の高い条件となる。
【０２１５】
以上から、各条件を優先順位の高い順に並べると、
“ＢＯＯＫ／ＡＵＴＨＯＲ”＞＝“ＢＯＯＫ／ＰＲＩＣＥ”＞“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ”＝“ＢＯＯＫ／ＴＩＴＬＥ”＝“ＢＯＯＫ／ＰＵＢＬＩＳＨＥＤＤＡＴＥ”
となる。
【０２１６】
絞り込み条件抽出部２１５は、上記優先順位に従って、図４０（ｂ）に示したような構造テーブル上の行のインデックスとして設定された各条件を並べて、絞り込み条件の表示データを作成する（ステップＳ２２６）。
【０２１７】
図３４の説明に戻り、ステップＳ２０４において、絞り込み条件の表示データが絞り込み条件抽出部２１５で作成されると、検索結果表示部２１７では、処理対象の４つの文書の一覧データを作成するとともに、この一覧データと、絞り込み条件の表示データとから、絞り込み条件と検索結果の文書の一覧をユーザに呈示するための検索結果表示画面データを作成し、クライアント端末１０２のディスプレイに表示する（ステップＳ２０５）。
【０２１８】
図４１は、検索結果表示部２１７で表示する検索結果表示画面の表示例を示したものである。
【０２１９】
検索結果表示画面の領域Ｙ２には、絞り込み条件が、絞り込み条件抽出部２１５で求めた優先順位の高い順に並べられて表示されている。図４１において、各絞り込み条件の左端にある図形により、他の文書との間の相違点の有無、すなわち、構造テーブル上で「○」と「×」が混在してい文書であるか否かを視覚的に表している。例えば、「◇」は、「○」「×」が発生する条件を表わし、「□」は全て「○」となっている条件を表わしている。
【０２２０】
検索結果表示画面の領域Ｙ３には、検索結果の文書の一覧が表示されている。ここでは、構造化文書パスにて表示されている。この一覧中の構造化文書パスのうち所望の１つがユーザによりマウス等の入力デバイスを用いて選択されると、図３５のステップＳ２０８からステップＳ２０９へ進み、選択部２１６は、検索結果表示部２１７を通じて、当該選択された構造化文書パスに対応する文書の内容を表示させる。また、検索結果表示画面上に設けられた「終了」ボタンが選択されると、検索支援装置２０１の処理動作は終了する。
【０２２１】
検索結果表示画面の領域Ｙ２に表示されている絞り込み条件の中から、ユーザは、マウス等の入力デバイスを用いて所望の絞り込み条件を選択することができる。ユーザは、領域Ｙ３に表示された検索結果にさらに絞り込みをかけたいときなどは、領域Ｙ２から所望の絞り込み条件を選択すればよい。例えば、ユーザにより、「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ」が選択されたとする（ステップＳ２０６）。
【０２２２】
ユーザにより絞り込み条件が選択されると、選択部２１６は、検索要求発行部２１２を起動する。検索要求発行部２１２では、前回の検索結果の文書の中から、当該選択された絞り込み条件を満たす文書を検索するためのクエリをステップＳ２０２の場合と同様にして生成する（ステップＳ２０７）。すなわち、例えば、前回の検索の際に生成されたクエリの検索条件を記述する「ｋｆ：ｗｈｅｒｅ」節に、今回選択された絞り込み条件をさらに追加するなどしてクエリを生成することもできる。
【０２２３】
この生成されたクエリは、前述同様、構造化文書管理システム１００へ送信されて、当該クエリに基づき、ＸＭＬデータベースの「ｒｏｏｔ」ノード以下から、要素値に「ＸＭＬ」というキーワードを含むＸＭＬ文書のうち、「ＢＯＯＫ」ノードの下に「ＣＡＴＥＧＯＲＹ」ノードがあるＸＭＬ文書が検索される。検索した結果得られた文書は、クライアント端末１０２へ送信され、検索支援装置２０１の検索結果取得部２１３が当該検索結果を取得し（ステップＳ２０３）、検索結果として得られた文書の数に応じて、そのうちの先頭の４件が、処理対象として選択される。
【０２２４】
なお、上記例の場合、処理対象の文書は、前回の検索と同様文書Ｒｅｃ１〜Ｒｅｃ４である。
【０２２５】
次に、２回目の検索結果に対して、ステップＳ２０４で行われる、絞り込み条件抽出部２１５の処理動作について、図３６を参照して説明する。今回の処理対象の文書は、絞り込み検索の検索結果として得られた文書であるから、ステップＳ２２１からステップＳ２２４へ進み、展開元として、今回の絞り込み検索の際に用いられた絞り込み条件を選択し、次に、ステップＳ２２５へ進む。
【０２２６】
ステップＳ２２５では、図４０（ｂ）に示した構造テーブルを、この構造テーブル上の条件のうち、今回の絞り込み検索において、ユーザにより選択された絞り込み条件「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ」を展開元として展開する。
【０２２７】
処理対象の文書Ｒｅｃ１〜Ｒｅｃ４のそれぞれは、図３９に示したように、「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ」の下には要素値としてのテキストがあり、それらは「コンピュータ」か「経済」のいずれかである。従って、この２つの語彙のそれぞれを含む条件を、構造テーブルの行のインデックスに設定する。また、文書Ｒｅｃ２以外の文書には「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ」の下に「ＳＵＢＣＡＴＥＧＯＲＹ」という構成要素が発生している（存在している）。従って、この構造上の条件も構造テーブルの行のインデックスに設定する。
【０２２８】
図４２は、このようにして「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ」を展開元として展開した結果得られた構造テーブルを示している。なお、図４２では、前回までに作成した構造テーブル上の優先順位の高い条件に、さらに上記語彙情報、構造情報を新たな条件として追加するかたちで作成された構造テーブルの一例を示している。
【０２２９】
次に、ステップＳ２２３からステップＳ２２６へ進み、前述同様にして、各条件についてＭ（Ｃ）の値を求めると、以下のようになる。
【０２３０】
Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）＝コンピュータ”）＝１．１９
Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）＝経済”）＝１．１９
Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）”）＝ＭＩＮ｛Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）＝コンピュータ”），Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）＝経済”）｝＝１．１９
Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ”）＝１．１９
Ｍ（“ＢＯＯＫ／ＡＵＴＨＯＲ”）＝１．１９
Ｍ（“ＢＯＯＫ／ＰＲＩＣＥ”）＝１．１９
この場合、上記全ての条件のＭ（Ｃ）は同じ値となっているので、絞り込み条件抽出部２１５は、例えば、構造テーブルの順番に、上記優先順位の等しい条件を並べて、絞り込み条件の表示データを作成する（ステップＳ２２６）。
【０２３１】
図４３は、今回、検索結果表示部２１７で表示する検索結果表示画面の表示例を示したものである。
【０２３２】
ユーザは、図４３に示した検索結果表示画面の領域Ｙ２から絞り込み条件として「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ」を選択したとする。これを絞り込み条件として絞り込み検索を行うと、検索結果の中から文書Ｒｅｃ２は除かれるので（文書Ｒｅｃ２は、今回の絞り込み条件を満たさないので）、絞り込み条件抽出部２１５の処理対象の文書は、文書Ｒｅｃ１、Ｒｅｃ３、Ｒｅｃ４となる。この３つの文書を処理対象の文書として、検索支援装置２０１の絞り込み条件抽出部２１５で、「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ」を展開元として作成した構造テーブルの一例を図４４に示す。
【０２３３】
処理対象の文書のそれぞれは、図４４に示したように、「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ」の下には要素値としてのテキストがあり、それらは「ソフトウエア」か「ハードウエア」のいずれかである。従って、この２つの語彙のそれぞれ含む条件が、構造テーブルの行のインデックスに設定されている。なお、図４４では、前回までに作成した構造テーブル上の優先順位の高い条件に、さらに上記語彙情報を新たな条件として追加するかたちで作成された構造テーブルの一例を示している。
【０２３４】
図４４に示した構造テーブル上の各条件についてＭ（Ｃ）の値を求めると、以下のようになる。
【０２３５】
Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）＝ソフトウエア”）＝１
Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）＝ハードウエア”）＝１．１９
Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）”＝ＭＩＮ（１，１．１９）＝１
Ｍ（“ＢＯＯＫ／ＡＵＴＨＯＲ”）＝１．１９
Ｍ（“ＢＯＯＫ／ＰＲＩＣＥ”）＝１．１９
上記算出結果を基に、各条件を優先順位の高い順に並べると、
“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）”＞“ＢＯＯＫ／ＡＵＴＨＯＲ”＝“ＢＯＯＫ／ＰＲＩＣＥ”となる。
【０２３６】
絞り込み条件抽出部２１５は、上記条件を優先順位の高い順に並べて絞り込み条件の表示データを作成した結果、図４５に示したような検索結果表示画面が表示される。上記優先順位の高い順に絞り込み条件（の候補）が並べられている。
【０２３７】
ユーザは、図４５に示した検索結果表示画面の領域Ｙ２から絞り込み条件として「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）＝ソフトウェア」を選んだものとする。そして、絞り込み条件を追加した再検索（絞り込み検索）を行うため、ユーザは、「実行」ボタンを押す。
【０２３８】
図４６は、このとき検索要求発行部２１２で生成されたクエリデータの一例である。「ＸＭＬ」というキーワードを含むＸＭＬデータを検索するという初期条件以外に、これまでに選択された絞り込み条件が追加されている。つまり、この場合、「ｋｆ：ｆｒｏｍ」節では、「“ｕｉｘ：／／ｒｏｏｔ”以下のＸＭＬ文書のうち、「ＢＯＯＫ」というタグの構成要素を持ち、その下に「ＣＡＴＥＧＯＲＹ」タグをもつ構成要素があり、この構成要素に「コンピュータ」というテキストがあり、さらに、当該構成要素は「ＳＵＢＣＡＴＥＧＯＲＹ」タグを持つ構成要素を包含し、この「ＳＵＢＣＡＴＥＧＯＲＹ」タグをもつ構成要素に「ソフトウェア」というテキストを持つＸＭＬ文書」という検索条件が記述されている。
【０２３９】
図４６に示したクエリに基づき構造化文書管理システム１００で検索を行った結果、例えば、図４７に示すように、文書Ｒｅｃ１と文書Ｒｅｃ４とが検索されたとする。
【０２４０】
文書Ｒｅｃ１とＲｅｃ４とを処理対象として絞り込み条件抽出部２１５では、図３６に示したフローチャートに従って、今回の絞り込み条件、すなわち、「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）＝ソフトウェア」を展開元として構造テーブルを展開するが、この場合、もうこれ以上展開することはできない。
【０２４１】
この場合、当該絞り込み条件が設定されている元の構造テーブル、すなわち、図４４に示した構造テーブル上に、文書Ｒｅｃ１とＲｅｃ４との相違点を表す条件も設定されているので、新たに、展開元を選択することなく、この構造テーブルを用いて、当該構造テーブル上の条件のうち、今回の絞り込み検索に用いた絞り込み条件を除く、文書Ｒｅｃ１とＲｅｃ４に該当する各条件について、前述同様にしてＭ（Ｃ）の値を求める。そして、その値を基に、優先順位の高い順に条件を並べて、絞り込み条件の表示データを作成する。
【０２４２】
図４８は、今回、検索結果表示部２１７で表示する検索結果表示画面の表示例を示したものである。
【０２４３】
図４９は、検索結果表示画面の他の例を示したものである。図４９に示した検索結果表示画面は、図４５に示した検索結果表示画面に対応するが、異なるのは、領域Ｙ３における検索結果一覧の表示方法である。
【０２４４】
図４９では、検索結果の各文書について、その文書の構造化文書パスと、当該文書の要約情報も表示している。要約情報としては、図４９に示すように、例えば、同じ画面上の領域Ｙ２で表示されている絞り込み条件のうち、優先順位の高い条件に対応するＸＭＬ文書の断片であってもよい。
【０２４５】
すなわち、「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ」が最も優先順位の高い絞り込み条件であるので、処理対象の各文書中の、この構成要素の周辺データが要約情報として表示されている。このように、ユーザの焦点に合わせて、ユーザが絞り込み条件を選択する手掛かりとなるような情報を各文書に対応付けて表示することもできる。
【０２４６】
以上説明したように、上記実施形態に係る絞り込み検索によれば、少なくとも１つのキーワードを初期条件として入力されたら、ＸＭＬデータベースに格納されている複数の構造化文書の中から、当該キーワードを構成要素の要素値に含む構造化文書を検索し、この検索された複数の構造化文書を処理対象の文書として、当該処理対象の文書のそれぞれの文書構造と構成要素の要素値として包含する語彙を比較することにより、当該処理対象の文書間の違いを抽出し、少なくともこの違いを絞り込み条件の候補として表示し、表示された候補の中から選択された候補を絞り込み条件として用いて、前回検索された構造化文書の中から当該選択された絞り込み条件を満たす構造化文書を検索し、その結果を今回の処理対象の文書として取得する。
【０２４７】
上記手法によれば、予めユーザ側で文書構造や語彙に関する情報を知らなくとも効果的に構造的な条件や語彙的な条件を優先順位付けして提示することで、必要な構造化文書集合を容易に取り出すことができる。
【０２４８】
また、上記実施形態に係る検索支援装置２０１は、ＸＭＬデータベースに格納されている複数の構造化文書の中から、指定された検索条件を満足する構造化文書を検索する構造化文書管理システム１００を用いて、所望の構造化文書を検索するための支援を行うものであって、少なくとも１つのキーワードを初期条件として入力されたら、構造化文書管理システム１００が上記キーワードを構成要素の要素値に含む複数の構造化文書を検索するための検索要求文（以下、クエリ）を作成して、構造化文書管理システム１００に入力し、このクエリに基づき構造化文書管理システム１００で検索された複数の構造化文書を処理対象の文書として取得すると、当該処理対象の文書のそれぞれの文書構造と構成要素の要素値として包含する語彙を比較することにより、絞り込み条件の候補として、少なくとも当該処理対象の文書間の違いを抽出して表示し、この表示された候補の中から選択された候補を絞り込み条件として用いて、前回検索された構造化文書の中から、当該選択された絞り込み条件を満たす構造化文書を検索した結果を、今回の処理対象の文書として取得する。
【０２４９】
上記検索支援装置２０１によれば、予めユーザ側で文書構造や語彙に関する情報を知らなくとも効果的に構造的な条件や語彙的な条件を優先順位付けして提示することで、必要な構造化文書集合を構造化文書管理システム１００から容易に取り出すことができる。
【０２５０】
すなわち、上記実施形態によれば、異なる文書構造の複数の構造化文書を記憶するデータベースであって、各構造化文書の構成要素で構成された階層化された論理構造を有するデータベースから、ユーザは、上記論理構造や各構造化文書の文書構造、どの構成要素にどのような語彙が包含されているかなどを意識せず、単なるキーワードを指定するだで、効率よく所望の構造化文書を検索することができる。特に、呈示された絞り込み条件の中から所望のものを選択するという操作だけで、検索結果として得られた大量の文書の中から、容易に絞り込みが行える。
【０２５１】
上記実施形態では、処理対象の文書から絞り込み条件を抽出する際には、各処理対象の文書を、検索結果が得られる度に、処理対象の文書の文書構造を１段ずつ掘り下げて（展開して）構成要素や語彙を抽出し、構造テーブルを作成する（展開する）。掘り下げる際には、掘り下げる基点としての展開元は、その都度選択する。例えば、構造テーブルに条件として挙げられた構成要素を順番に選択したり、絞り込み条件として選択された構成要素を優先的に選択してもよい。１段掘り下げたところで処理対象の文書間の違いが見つからなければ、さらに１段掘り下げて構成要素や語彙を抽出し構造テーブルを作成する（展開する）。
【０２５２】
なお、上記実施形態では、絞り込み受験が選択されるたびに、検索要求発行部２１２がクエリを生成し、構造化文書管理システム１００へ検索を依頼するようになっているが、この場合に限らず、初期条件に基づく検索結果が得られたら（構造化文書管理システムから送られてきたら）、検索支援装置２０１自身が、この検索結果の文書の中から、選択された絞り込み条件を満足する文書を選択（検索）するようにしてもよい。
【０２５３】
本発明の実施の形態に記載した絞り込み検索手法（図３４〜図３６参照）は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピーディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、半導体メモリなどの記録媒体に格納して頒布することもできる。
【０２５４】
なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。さらに、上記実施形態には種々の段階の発明は含まれており、開示される複数の構成用件における適宜な組み合わせにより、種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題（の少なくとも１つ）が解決でき、発明の効果の欄で述べられている効果（のなくとも１つ）が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【０２５５】
【発明の効果】
以上説明したように、本発明によれば、構造化文書の文書構造を意識することなく、検索結果を絞り込みながら所望の構造化文書を迅速に効率よく検索することができる。
【図面の簡単な説明】
【図１】本発明の実施形態に係る構造化文書管理システムの構成例を示した図。
【図２】図１に示した構造化文書管理システムの一利用形態を示したもので、ＷＷＷのバックエンドで、構造化文書管理システムが動作している場合を示した図。
【図３】ＸＭＬで記述された構造化文書の一例を示した図。
【図４】図３の構造化文書の文書構造を模式的に示した図。
【図５】追加コマンドの機能を説明するための図で、構造化文書データベースの初期状態に追加コマンドを実行した場合について示している。
【図６】図５（ｂ）に示した状態の構造化文書データベースに対し、取得コマンドを実行した場合の処理結果を示した図。
【図７】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して１つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図８】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して３つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図９】要素名生起インデックスの格納例を示した図。
【図１０】データ生起インデックスの格納例を示した図。
【図１１】図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合の実行結果を示した図。
【図１２】ＸＭＬ文書の文書構造を定義するスキーマの一例を示した図。
【図１３】図８に示した状態の構造化文書データベースに、スキーマ格納コマンドを実行して、図１２に示したスキーマを追加格納（設定）した場合を示した図。
【図１４】スキーマが設定されて、スキーマが存在している旨の属性値のセットされた文書オブジェクトツリーを示した図。
【図１５】各オブジェクトファイルに、スキーマが存在している旨の属性値が格納されている様子を概念的に示した図。
【図１６】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１７】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１８】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図１９】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図２０】クエリ（ＸＭＬ文書）の一例を示した図。
【図２１】単純検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図２２】図２１の単純検索のクエリを用いた検索結果（ＸＭＬ文書）を示した図。
【図２３】概念検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図２４】図１の構造化文書管理システムの文書検索処理動作について説明するためのフローチャート。
【図２５】ユーザインタフェースとしての画面の表示例を示した図。
【図２６】文書検索を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図２７】図２６に示した画面上から入力された情報に基づき作成されるクエリを示した図。
【図２８】図１の構造化文書管理システムの文書取得処理動作について説明するためのフローチャート。
【図２９】文書取得コマンドを実行した結果得られた構造化文書の表示例を示した図。
【図３０】文書検索を行うためのユーザインタフェースとしての画面の表示例であって、スキーマの検索処理動作を説明するための図。
【図３１】スキーマ検索のクエリの一例を示した図。
【図３２】スキーマの取得するためのユーザインタフェースとしての画面の表示例を示したもので、取得されたスキーマの表示例を示している。
【図３３】本発明の実施形態に係る検索支援装置の構成例を示した図。
【図３４】図３３の検索支援装置の処理動作を説明するためのフローチャート。
【図３５】図３３の検索支援装置の処理動作を説明するためのフローチャート。
【図３６】絞り込み条件抽出部の処理動作を説明するためのフローチャート。
【図３７】初期条件入力画面の表示例を示した図。
【図３８】検索要求発行部で生成されたクエリの一例を示す図。
【図３９】図３８に示したクエリに基づき構造化文書管理システムで検索した結果得られたＸＭＬ文書の集合のうち、選択された４件の文書の具体例を示した図。
【図４０】絞り込み条件抽出の際に作成される構造テーブルの具体例を示した図。
【図４１】絞り込み条件の表示例を示した図。
【図４２】絞り込み検索の結果得られたＸＭＬ文書について作成された構造テーブルの具体例を示した図。
【図４３】絞り込み条件の表示例を示した図。
【図４４】絞り込み検索の結果得られたＸＭＬ文書について作成された構造テーブルの具体例を示した図。
【図４５】絞り込み条件の表示例を示した図。
【図４６】ユーザにより選択された絞り込み条件を用いて作成されたクエリの具体例を示した図。
【図４７】図４６に示したクエリに基づき検索した結果得られたＸＭＬ文書の具体例を示した図。
【図４８】絞り込み条件の表示例を示した図。
【図４９】絞り込み条件とともに表示される検索結果一覧の他の表示例を示した図。
【符号の説明】
１００…構造化文書管理システム
２０１…検索支援装置
２１１…初期条件入力部
２１２…検索要求発行部
２１３…検索結果取得部
２１４…検索結果サンプリング部
２１５…絞り込み条件抽出部
２１６…選択部
２１７…検索結果表示部
【発明の属する技術分野】
本発明は、異なる文書構造の複数の構造化文書を記憶する、階層化された論理構造を持つ構造化文書データベースで管理する構造化文書管理システムに関し、特に、当該データベースから所望の構造化文書を検索するための絞り込み検索に関する。
【０００２】
【従来の技術】
ＸＭＬ（Ｅｘｔｅｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）データベースなど構造化文書データベースでは、検索言語によって記述されたユーザ検索要求により所望の構造化文書を検索する手段が提供されてる。検索言語には、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）に似た構文を持ち、検索位置、検索条件、情報抽出部分などを記述したものもある。この手段により多種多様な構造化文書を検索することができる。しかし、このような検索言語をベースとしたクエリデータを作成するには、ユーザ側にあらかじめ構造化文書データベース中に存在する構造化文書の文書構造（ＤＴＤ）や語彙発生状況などに関する情報が必要であった。
【０００３】
一方、ユーザ側の構造化文書の文書構造（ＤＴＤ）や語彙発生状況などに関する情報欠如を補うために、いくつかの支援方法が提案されてきた。
【０００４】
検索対象を初期検索の段階から絞り込むために、ＤＴＤの一覧を提示し、そこから文書構造のスケルトンを表示させて、ユーザに検索対象の構造に関する条件を設定させる。検索された結果は、出力パターン指定された構造化文書形式に変換して出力する（例えば特許文献１参照）。
【０００５】
一方、初期検索では十分に絞り込めないという状況を考慮して、二次検索での絞り込みを支援する方法もある。これはＲＤＢなどに格納されたデータベースを検索対象にする。初期検索では、ユーザに語彙などの粗い検索条件を設定させる。大量の候補が出た場合に、データベースとは別の階層構造を持った背景知識を用いて、効果的な順番で質問を行い、絞り込みを支援するものである（例えば特許文献２参照）。
【０００６】
また、テキストで表現されたフルテキストデータベースを検索に対象としたものもある。これは初期検索では、ユーザに語彙などの粗い検索条件を設定させる。大量の候補が出た場合に、データベースとは別の階層構造を持った背景知識を用いて、語彙を背景知識を用いて効果的に展開し、設定された件数になるように自動的に絞り込みを行うものである（例えば特許文献３参照）。
【０００７】
【特許文献１】特開２０００−２００２８６号公報（第８頁、第４図）
【０００８】
【特許文献２】特開平１０−１８７７３９（第６頁、第１図）
【０００９】
【特許文献３】特開７−２２５７７２ （第１０頁、第１図）
【００１０】
【発明が解決しようとする課題】
ユーザが構造化文書を検索する場合には、あらかじめ文書構造（ＤＴＤ）や語彙発生状況などに関する情報が必要であった。
【００１１】
そのためには、いくつかの検索支援方法が提案されてきたが、以下のような問題点があった。
【００１２】
（１）ＤＴＤがデータベース上に設定されていないと構造条件の候補を提示できず、検索支援できない。
【００１３】
（２）２次検索を行って絞り込みをする場合、特別な背景知識が無いと検索支援できない。
【００１４】
構造化文書の場合、検索条件として、構造に関する条件、語彙に関する条件、を指定する必要があるが、従来は、これらを適切に組合せた検索、および検索支援ができていなかった。
【００１５】
そこで、本発明は上記問題点に鑑み、構造化文書の文書構造を意識することなく、検索結果を絞り込みながら所望の構造化文書を迅速に効率よく検索することができる、構造化文書検索方法、およびそれを用いた検索支援装置を提供することを目的とする。
【００１６】
【課題を解決するための手段】
（１）本発明は、異なる文書構造の複数の構造化文書を記憶するデータベース（特に、前記複数の構造化文書のそれぞれの構成要素で構成された階層化された論理構造を有するデータベース）から、所望の構造化文書を検索するためのものであって、少なくとも１つのキーワードを初期条件として入力されたら、前記データベースから、前記キーワードを構成要素の要素名と要素値とのうちの少なくとも一方に含む複数の構造化文書を検索し、この検索された複数の構造化文書を処理対象の文書として、当該処理対象の文書のそれぞれの文書構造と構成要素の要素値として包含する語彙を比較することにより、絞り込み条件の候補として、前記処理対象の文書から、構成要素の要素名と要素値として包含する語彙のうちの少なくとも一方を抽出し、この抽出された候補を表示し、表示された候補の中から選択された候補を絞り込み条件として用いて、前回検索された構造化文書の中から当該選択された絞り込み条件を満たす構造化文書を検索した結果を前記処理対象の文書として取得することを特徴とする。
【００１７】
好ましくは、前記処理対象の文書間の違いとして、構成要素の要素名と要素値として包含する語彙のうちの少なくとも一方を抽出し、この違いを絞り込み条件の候補として表示する。
【００１８】
本発明によれば、予めユーザ側で文書構造や語彙に関する情報を知らなくとも効果的に構造的な条件や語彙的な条件を優先順位付けして提示することで、必要な構造化文書集合を容易に検索することができる。
【００１９】
（２）本発明は、異なる文書構造の複数の構造化文書を記憶するデータベース（特に、前記複数の構造化文書のそれぞれの構成要素で構成された階層化された論理構造を有するデータベース）から、指定された検索条件を満足する構造化文書を検索する検索装置を用いて、所望の構造化文書を検索するための支援を行う検索支援装置であって、少なくとも１つのキーワードを初期条件として入力されたら、前記検索装置が、前記キーワードを構成要素の要素名と要素値とのうちの少なくとも一方に含む構造化文書を検索するための検索要求文を作成する作成手段と、前記検索要求文に基づき前記検索装置で検索された構造化文書を処理対象の文書として取得する取得手段と、前記処理対象の文書のそれぞれの文書構造と構成要素の要素値として包含する語彙を比較することにより、絞り込み条件の候補として、前記処理対象の文書から、構成要素の要素名と要素値として包含する語彙のうちの少なくとも一方を抽出する手段と、この抽出手段で抽出された絞り込み条件の候補を表示する表示手段と、この表示手段で表示された候補の中から選択された候補を絞り込み条件として用いて、前回検索された構造化文書の中から当該選択された絞り込み条件を満たす構造化文書を検索した結果を前記処理対象の文書として取得する手段とを具備したことを特徴とする。
【００２０】
好ましくは、前記抽出手段は、前記処理対象の文書間の違いとして、構成要素の要素名と要素値として包含する語彙のうちの少なくとも一方を抽出し、前記表示手段は、前記前記抽出手段で抽出された違いを絞り込み条件の候補として表示する。
【００２１】
本発明によれば、予めユーザ側で文書構造や語彙に関する情報を知らなくとも効果的に構造的な条件や語彙的な条件を優先順位付けして提示することで、必要な構造化文書集合を検索装置から容易に取り出すことができる。
【００２２】
【発明の実施の形態】
まず、本発明の実施形態について説明する前に、構造化文書管理システムの概要について説明する。
【００２３】
（構造化文書管理システムの説明）
構造化文書として、ＸＭＬやＳＧＭＬなどで記述した文書が挙げられる。ＳＧＭＬ（Ｓｔａｎｄａｒｄ Ｇｅｎｅｒａｌｉｚｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）とは、ＩＳＯ（国際標準化機構）で定められた規格である。ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）とは、Ｗ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）にて定められた規格である。これらは、文書を構造化することを可能とする構造化文書の規格である。
【００２４】
以下、構造化文書として、ＸＭＬにて記述された文書を例に説明を進める。構造化文書の文書構造を定義したデータ（文書構造定義データ）をスキーマと呼ぶ。ＸＭＬではスキーマを定義するためにＸＭＬ−ＳｃｈｅｍａやＸＤＲ（ＸＭＬＤａｔａ Ｒｅｄｕｃｅｄ）などのスキーマ言語が提案されている。ここでは、例えば、ＸＤＲでスキーマを記述する場合を例にとり説明する。
【００２５】
スキーマも、構造化文書管理システムの管理対象の構造化文書であり、ここでは、スキーマ文書と呼ぶことがある。スキーマ文書以外の構造化文書であって、特許明細書やメール、週報、広告などの種々雑多な内容を有する文書を、ここでは、コンテンツ文書と呼ぶこともある。
【００２６】
構造化文書管理システムでは、上記スキーマ文書、上記コンテンツ文書、さらに、後述するようなユーザからの検索要求を記述したクエリ、すなわち、クエリ文書も管理対象とし、これらを総称して「文書」と呼ぶ。
【００２７】
以下、特にことわりがない場合、「文書」と呼ぶときは、コンテンツ文書、スキーマ文書、クエリ文書を全て指すものとする。
【００２８】
まず、実施形態の説明の前に、ＸＭＬについて簡単に説明する。
【００２９】
図３は、ＸＭＬで記述された構造化文書の一例として、「特許」情報の例を示したものである。ＸＭＬやＳＧＭＬは、文書の構造の表現にタグが用いられる。タグには、開始タグと終了タグがある。文書構造の各構成要素は、開始タグと終了タグで囲まれている。開始タグとは構成要素の要素名を「＞」で閉じたものであり、終了タグとは要素名を記号「＜／」と「＞」で閉じたものである。タグに続く構成要素の内容が、テキスト（文字列）または子供の構成要素の繰り返しである。また開始タグには「＜要素名 属性＝“属性値”＞」などのように属性情報を設定することができる。「＜特許ＤＢ＞＜／特許ＤＢ＞」のようにテキストを含まない構成要素は、簡易記法として「＜特許ＤＢ／＞」のように表わすこともできる。
【００３０】
図３に示した文書は、「特許」タグから始まる要素をルートとし、その子要素として「タイトル」、「出願日」、「出願者」、「要約」タグから始まる要素が存在する。また、例えば、「タイトル」タグから始まる要素には「ＸＭＬデータベース」といった、１つのテキスト（文字列）が要素値として存在する。
【００３１】
ＸＭＬなどの構造化文書は、任意の構成要素を繰り返し含んでいたり、さらには文書構造があらかじめ決まっていないのが普通である。
【００３２】
図３に示したような構造化文書を論理的に表現するために、図４に示すようなツリー表現が用いられる。ツリーは、ノード（番号が付され、円形で示されたもの）とアーク（ノードを表す円形間をつなぐデータ付き線）と四角形で囲まれたテキストから構成されている。
【００３３】
１つのノードは１つの構成要素、すなわち、１つの文書オブジェクトに対応する。ノードからタグ名や属性名に相当するラベルが付与された複数のアークが出てきている。そのアークの先は、ノード値または要素値としての文字列（テキスト）である。ノードの中に記載されている英数字（例えば「＃０」、「＃４９」）などは、各文書オブジェクトを識別するためのオブジェクトＩＤである。
【００３４】
図４に示したツリー構造を図３に示した構造化文書の文書オブジェクトツリーと呼ぶ。
【００３５】
図１は、本実施形態に係る構造化文書管理システムの構成例を示したものである。図１において、構造化文書管理システムは、大きく分けて、要求制御部１、アクセス要求処理部２、検索要求処理部３、データアクセス部４、文書記憶部５、インデックス記憶部６から構成されている。文書記憶部５、インデックス記憶部６は例えば、外部記憶装置で構成される。
【００３６】
図１のシステム構成は、ソフトウエアを用いて実現可能である。
【００３７】
要求制御部１は、要求受付部１１と結果処理部１２から構成されている。要求受付部１１は、文書の格納、文書の取得、文書の検索などのユーザからの要求を受け付けて、アクセス要求処理部２を呼び出す。結果処理部１２は、アクセス要求処理部２が処理した結果を要求元のユーザに返す処理を行う。
【００３８】
アクセス要求処理部２は、文書の格納、文書の取得、文書の削除などのユーザからの各種要求に対応した複数の処理部から構成されている。つまり、文書格納部２１、文書取得部２２、文書削除部２３から構成されている。
【００３９】
文書格納部２１は、文書記憶部５中の指定された論理的なエリアに文書を格納する処理を行う。
【００４０】
文書取得部２２は、文書記憶部５中の論理的なエリアが指定されたときに、その指定エリアに存在する文書を取得する処理を行う。
【００４１】
文書削除部２３は、文書記憶部５中の指定された論理的なエリアに存在する文書を削除する処理を行う。
【００４２】
文書記憶部５は、構造化文書データベースであり、例えば、図８に示すように、文書をＵＮＩＸのディレクトリ構造のように階層的にツリー構造状に格納している。
【００４３】
図８に示すように、構造化文書データベースは、図４に示したような１つの構造化文書のツリー構造と同様に表現できる。すなわち、任意のノード以下の部分的な階層木（部分ツリー）は、構造化文書データベースから切り出された構造化文書であり、ここでは、これを文書オブジェクトツリーと呼ぶ。各ノードにはオブジェクトＩＤが割り当てられている。オブジェクトＩＤは、構造化文書データベース内ではユニークな数値である。
【００４４】
階層木のルートとなるノードには、それがルートノードであることを特定するためのオブジェクトＩＤ「＃０」が割り当てられるものとする。
【００４５】
ルートノード、すなわち、「＃０」のノードからは「ｒｏｏｔ」タグを先頭に持つオブジェクトＩＤ「＃１」のノードへリンクが張られている。「＃１」のノードからは、「特許ＤＢ」タグを先頭にもつオブジェクトＩＤ「＃２」のノードへのリンクが張られている。「＃２」ノードからは、「特許」タグを先頭に持つ、オブジェクトＩＤ「＃４２」のノード、「＃５２」のノード、「＃６２」のノードへのリンクがそれぞれ張られている。
【００４６】
図３に示した「特許」情報は、図８の「＃４２」ノード以下の部分ツリーに対応している。このノードからは「タイトル」タグ、「出願者」タグ、「要約」タグなどを先頭にもつノードへリンクが張られ、末端のノードからは、「ＸＭＬデータベース」、「Ｔ社」、「ＸＭＬを統一的に管理するデータベースを提供する…」などの文字列（要素値）へのリンクが張られている。
【００４７】
図８において、オブジェクトＩＤ「＃５２」のノード以下の部分ツリー、オブジェクトＩＤ「＃６２」のノード以下の部分ノードも１つの「特許」情報に対応する文書オブジェクトツリーである。
【００４８】
ところで、例えば、「＃４３」ノードにリンクされた「ＸＭＬデータベース」という要素値は、「＃４３」ノードと「＃ｖａｌｕｅ」という特殊なタグ名で接続されている。このタグ名は、「＃」で始まるためＸＭＬの規格においては標準的なタグ名として利用することはできない。
【００４９】
このような構造化文書データベースの特定ノードを指定するために構造化文書パスを用いる。構造化文書パスは「ｕｉｘ：／／ｒｏｏｔ」から始まる文字列である。ｕｉｘ（Ｕｎｉｖｅｒｓａｌ Ｉｄｅｎｔｉｆｉｅｒ ｆｏｒ ＸＭＬ）は構造化文書パスであることを示す文字列である。
【００５０】
例えば、構造化文書パスとして「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」と表すと、この構造化文書パスの示す文書記憶部５中の論理的なエリアは、図８において、「＃１」ノードから「特許ＤＢ」が付与されたアークが指し示すノード、つまり「＃２」ノードである。
【００５１】
同様にして、構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許」は、図８における「＃４２」ノードを指し示し、構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／出願日／年」は、図８における「＃４５」ノードを指し示す。
【００５２】
例えば、図８において、「＃２」ノード以下に、すなわち、「特許ＤＢ」という構成要素に、複数の「特許」情報を格納する場合には、各「特許」情報を識別するために、要素名（例えば、この場合「特許」）にインデックスを追加してもよい。
【００５３】
「特許ＤＢ」の最初の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」となるが、これは「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許」と同じとみなす。「特許ＤＢ」の２番目の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［１］」、「特許ＤＢ」の５番目の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［４］」となる。
【００５４】
インデックス記憶部６には，検索時に用いる、要素名称生起インデックスとデータ生起インデックスが記憶されている。
【００５５】
要素名生起インデックスとは構造化文書データベースに格納されている要素名と、その要素名の構成要素が先頭にある構造化文書（文書オブジェクトツリー）の位置とを関連付けたインデックスファイルである。例えば、図８の構造化文書データベースでは、（「特許」情報に対応する）「特許」という要素名が「＃４２」ノード以下の構造化文書、「＃５２」ノード以下の構造化文書、「＃６２」ノード以下の構造化文書に存在する場合、要素名生起インデックスには、図９に示すように、「＃４２」ノード、「＃５２」ノード、「＃６２」ノードの親ノード、すなわち、「＃２」ノードが、要素名「特許」にリンクされて格納される。
【００５６】
このように、親ノードでインデックス化すると、インデックスファイルを圧縮することができる。すなわち、親ノードでインデックス化すれば、子ノードが増大しようとも、親ノードで代用しているので、要素名にリンクすべきノードは増大しない。
【００５７】
データ生起インデックスとは、構造化文書データベースに格納されている文字列データと、その文字列データが存在する構造化文書（文書オブジェクトツリー）の位置とを関連付けたインデックスファイルである。例えば、図８の構造化文書データベースでは、「ＸＭＬ」という文字列が「＃４３」ノード以下の構造化文書、「＃４９」ノード以下の構造化文書に存在する。この場合、データ生起インデックスには、図１０に示すように、「＃４３」ノード、「＃４９」ノードが、「ＸＭＬ」という文字列にリンクされて格納される。
【００５８】
文書記憶部５中の指定された論理的なエリアとは、構造化文書パスを用いてユーザにより指定された文書の格納場所である。構造化文書パスは、ユーザにとって認識可能な表現である。
【００５９】
図１の説明に戻る。
【００６０】
データアクセス部４は、文書記憶部５をアクセスするための各種処理を行うものである。データアクセス部４は、文書オブジェクトツリー格納部４１、文書オブジェクトツリー削除部４２、文書オブジェクトツリー取得部４３、文書文字列取得部４４、文書パーサ部４６、合成文書作成部４７、インデックス更新部４８から構成される。
【００６１】
文書オブジェクトツリー格納部４１は、文書記憶部５中の指定された物理的なエリアに文書オブジェクトツリーを格納するための処理を行う。
【００６２】
文書オブジェクトツリー削除部４２は、文書記憶部５中の指定された物理的なエリアに存在する文書オブジェクトツリーを削除するための処理を行う。
【００６３】
文書オブジェクトツリー取得部４３は、文書記憶部５中の（構造化文書パスなどにより）指定された物理的なエリアに存在する文書オブジェクトツリーを取得するための処理を行う。
【００６４】
文書文字列取得部４４は、文書オブジェクトツリーを構造化文書（ＸＭＬ文書）に変換するための処理を行う。
【００６５】
文書パーサ部４６は、ユーザにより入力された構造化文書を読み込んで、その文書構造の検査を行う。さらに文書構造の定義データであるスキーマが存在すれば、入力された構造化文書の文書構造がスキーマにしたがっているかどうかの検証を行う。出力結果は文書オブジェクトツリーとなる。文書パーサは、通常、ｌｅｘ（ｌｅｘｉｃａｌ ａｎａｌｙｚｅｒ ｇｅｎｅｒａｔｏｒ）といったレキシカルアナライザ（字句解析を行い，トークンに分解する）とｙａｃｃ（ｙｅｔａｎｏｔｈｅｒ ｃｏｍｐｉｌｅｒ ｃｏｍｐｉｌｅｒ）といったパーサジェネレータを組み合わせて構築することができる。
【００６６】
合成文書作成部４７は、文書の格納や文書の削除などをする際に、スキーマに合致しているかどうか検査しなければならないが、この検査時に必要となるデータを作成する。
【００６７】
インデックス更新部４８は、文書の格納や文書の削除などにより、構造化文書データベースの格納内容が更新されるたびに、図９、図１０に示した要素名称生起インデックスとデータ生起インデックスを更新する。
【００６８】
文書記憶部５中の物理的なエリアとは、ファイルオフセットやオブジェクトＩＤなどの構造化文書データベース内ではユニークな文書データの存在場所を指し示す内部データである。ユーザにとっては認識不可能なデータである。
【００６９】
検索要求処理部３は、データアクセス部４に備わっている各処理機能部を用いて、文書記憶部５中に格納された文書を検索する処理を行う。要求制御部１の要求受付部１１でユーザからの文書検索の要求が受け付けられると、検索要求処理部３には、要求受付部１１からクエリ言語で記述されたクエリ文書が入力する。そしてデータアクセス部４を通してインデックス記憶部６，文書記憶部５にアクセスし、検索要求に合致する文書の集合を取得して、その結果を結果処理部１２を介して出力する。
【００７０】
図２は、図１に示した構造化文書管理システムの一利用形態を示したもので、図２では、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）のバックエンドで、図１に示した構成の構造化文書管理システム１００が動作している場合を示している。
【００７１】
複数（ここでは、例えば３つ）のクライアント端末（例えばパーソナルコンピュータ、携帯通信端末など）１０２のそれぞれでＷＷＷブラウザ１０３が動作している。ユーザは、各クライアント端末からＷＷＷサーバ１０１にアクセスすることにより、構造化文書管理システム１００にアクセスすることができる。ＷＷＷブラウザ１０３とＷＷＷサーバ１０１とは、ＨＴＴＰ（Ｈｙｐｅｒ ＴｅｘｔＴｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）で通信している。また、ＷＷＷサーバ１０１と構造化文書管理システム１００とは、ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）またはＣＯＭ（Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）などで通信している。
【００７２】
文書の格納、文書の取得、文書の検索などのユーザからの要求は、ＷＷＷブラウザ１０３から送信されて、ＷＷＷサーバ１０１を通して構造化文書管理システム１００にて受け付けられる。構造化文書管理システム１００にて処理された結果は、ＷＷＷサーバ１０１を通して要求元のＷＷＷブラウザ１０３へ返信される。
【００７３】
以下、図１の構造化文書管理システムの（１）格納機能、（２）検索機能について詳細に説明する。
【００７４】
（格納機能）
図１の構造化文書管理システムにおける格納系のコマンドには以下のものがある。
【００７５】
ｉｎｓｅｒｔＸＭＬ（パス、Ｎ番目、ＸＭＬ）：文書格納
ａｐｐｅｎｄＸＭＬ（パス、ＸＭＬ） ：文書格納
ｇｅｔＸＭＬ（パス） ：文書取得
ｒｅｍｏｖｅＸＭＬ（パス） ：文書削除
ｓｅｔＳｃｈｅｍａ（パス、スキーマ） ：スキーマ格納
ｇｅｔＳｃｈｅｍａ（パス） ：スキーマ取得
「ｉｎｓｅｒｔＸＭＬ」は、（ ）内に指定した構造化文書パス以下のＮ番目に文書を挿入するコマンド（以下、簡単に挿入コマンドと呼ぶ）である。
【００７６】
「ａｐｐｅｎｄＸＭＬ」は、（ ）内に指定した構造化文書パス以下の最後に文書を挿入するコマンド（以下、簡単に追加コマンドと呼ぶ）である。
【００７７】
「ｇｅｔＸＭＬ」は、（ ）内に指定した構造化文書パス以下の文書を取り出すコマンド（以下、簡単に取得コマンドと呼ぶ）である。
【００７８】
「ｒｅｍｏｖｅＸＭＬ」は、（ ）内に指定した構造化文書パス以下の文書（スキーマ文書以外の文書で、主に、コンテンツ文書）を削除するコマンド（以下、簡単に削除コマンドと呼ぶ）である。
【００７９】
「ｓｅｔＳｃｈｅｍａ」は、（ ）内に指定した構造化文書パスにスキーマを設定するコマンド（以下、簡単にスキーマ格納コマンドと呼ぶ）である。
【００８０】
「ｇｅｔＳｃｈｅｍａ」は、（ ）内に指定した構造化文書パスに設定されているスキーマを取り出すコマンド（以下、簡単にスキーマ取得コマンドと呼ぶ）である。
【００８１】
上記コマンドのうち、挿入コマンド、追加コマンド、スキーマ格納コマンドについての処理はアクセス要求処理部２の文書格納部２１で実行され、取得コマンド、スキーマ取得コマンドについての処理は文書取得部２２で実行され、削除コマンドについての処理は文書削除部２３で実行される。
【００８２】
図５を参照して、構造化文書データベースの初期状態（図５（ａ）参照）において、追加コマンドを実行する場合について説明する。
【００８３】
図５（ａ）に示すように、「＃０」ノードと「＃１」ノードが「ｒｏｏｔ」アークで接続されている初期状態に対して、
「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」を実行した結果、図５（ｂ）に示すように、「＃２」ノードと「特許ＤＢ」アークが作成される。
【００８４】
図５（ｂ）に示した状態の構造化文書データベースに対して、取得コマンドを実行する場合について説明する。
【００８５】
例えば、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”）」を実行すると、図５（ｂ）の「ｒｏｏｔ」アークが示す「＃０」ノード以下の文書オブジェクトツリーが取り出され、それをＸＭＬ文書に変換する。その結果、「＜ｒｏｏｔ＞＜特許ＤＢ／＞＜／ｒｏｏｔ＞」なる文字列が取り出されて、図６に示すようなＸＭＬ文書に変換される。取得コマンドの処理は、アクセス要求処理部２の文書取得部２２にて実行される。
【００８６】
次に、図５（ｂ）に示した状態の構造化文書データベースに対して、図３に示すようなコンテンツ文書（ＸＭＬ文書）としての「特許」情報を格納するための追加コマンドを実行する場合について説明する。すなわち、この場合、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」を実行する。このコマンド中「“＜特許＞…＜／特許＞”」が、図３に示した「特許」情報のＸＭＬ文書に対応する。
【００８７】
上記追加コマンドの処理が実行されると、図７に示すように、「＃２」ノード以下に「＃４２」ノードをトップとする文書オブジェクトツリー（図４に対応）が追加される。
【００８８】
図５（ｂ）に示した状態の構造化文書データベースに対して、次に示すような追加コマンドを３回繰り返して実行したとする。
【００８９】
「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」
上記コマンド中、「＜特許＞…＜／特許＞」は、図３に示したＸＭＬ文書と同じ文書構造のコンテンツ文書に対応する。
【００９０】
すると、図８に示すように、「＃２」ノード以下に「＃４２」ノード、「＃５２」ノード、「＃６２」ノードをトップとする文書オブジェクトツリーが追加される。
【００９１】
次に、図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合について説明する。この場合、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」を実行する。すると、「特許ＤＢ」アークが示す「＃２」ノード以下の文書オブジェクトツリーが取り出される。その結果、図１１に示すように、「＜特許ＤＢ＞＜特許＞…＜／特許＞＜特許＞…＜／特許＞＜特許＞…＜／特許＞＜／特許ＤＢ＞」なるＸＭＬ文書が取得できる。
【００９２】
構造化文書データベースでは、上記の「特許」情報などのコンテンツ文書（ＸＭＬ文書）の文書構造を定義したデータ、すなわち、スキーマも管理対象とする。
【００９３】
図１２は、ＸＭＬ文書の文書構造を定義するスキーマの一例を示したものである。ここでは、ＸＭＬの文書構造定義言語の一つであるＸＤＲ（ＸＭＬ−Ｄａｔａ Ｒｅｄｕｃｅｄ）を取り上げる。もちろん、ＸＭＬ−Ｓｃｈｅｍａなど他の文書構造定義言語を用いてもかまわない。
【００９４】
図１２に示したスキーマは、図３に示した「特許」情報の文書構造をＸＤＲで定義したものである。図１２からも容易に分かるとおり、スキーマもＸＭＬ形式の構造化文書である。「Ｓｃｈｅｍａ」タグから始まる構成要素から始まり、その子要素として、「ＥｌｅｍｅｎｔＴｙｐｅ」タグから始まる要素集合が存在する。
【００９５】
図８に示した状態の構造化文書データベースに対して、図１２に示したスキーマ文書を格納するためのスキーマ格納コマンドを実行する場合について説明する。この場合、「ｓｅｔＳｃｈｅｍａ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”）」を実行する。このコマンド中、「“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”」」が図１２に示したスキーマ文書に対応する。
【００９６】
上記コマンドの実行により、図１３に示すように、「＃２」ノード以下に「＃ｓｃｈｅｍａ」アークが追加され、その先には、「＃３」ノードをトップノードとする文書オブジェクトツリーが追加される。スキーマ自身がＸＭＬ文書表現になっているため、前述した「特許」情報のようなコンテンツ文書格納のケースと同様に、図１３に示したように、ツリー展開される。
【００９７】
図１３において、「＠ｎａｍｅ」のように、「＠」で始まるアークは属性に対応する。タグ名「＃ｓｃｈｅｍａ」も「＃」、「＠」で始まるためＸＭＬ規格においては標準的なタグ名として利用することはできない。
【００９８】
「＃２」ノード以下に図１２に示したスキーマ文書が格納されたことにより、以後、「＃２」ノード以下に格納される文書の文書構造は、図１２に示したスキーマ文書により定義された文書構造に適合することを要求してもよい。すなわち、この場合、「＃２」ノード以下に図１２に示したスキーマが設定されることになる。
【００９９】
「＃２」ノード以下に図１２に示したスキーマが設定されると、例えば、図１４に示すように、「＃２」ノード以下の文書オブジェクトツリーの各ノード（のファイル）には、スキーマが存在する旨の属性値がセットされる。
【０１００】
「＃２」ノード以下に図１２に示したスキーマが設定された後に、このスキーマで定義された文書構造に一致する図３に示したような「特許」情報の文書を、図１４に示したように、文書オブジェクトツリーとして構造化文書データベースに格納したとき、この文書の文書構造には図１２に示したスキーマが存在する旨の属性値が、当該文書オブジェクトツリーを構成する各文書オブジェクトにセットされる。例えば、当該文書オブジェクトツリーを構成する各文書オブジェクトのファイルに対して、スキーマが存在している旨の属性値（例えば、「スキーマ適合有無」）に「１」がセットされる。図１４では、スキーマに適合している各文書オブジェクト（ノード）は２重丸で示している。２重丸で示した各文書オブジェクトには、その文書オブジェクトに対応した文書構造定義が存在することになる。
【０１０１】
図１５は、各文書オブジェクトのファイルの内容を概念的に示したもので、例えば、オブジェクトＩＤが「＃４２」の文書オブジェクトのファイルには、その文書オブジェクトにリンクされている他の文書オブジェクトに関する情報（例えば、アークや、リンク先の文書オブジェクトへのポインタ値など）とともに、上記属性値が記述されている。なお、当該文書オブジェクトに適用するスキーマが存在しないときは、「スキーマ適合有無」の値は「０」となる。
【０１０２】
図１６、図１７は、図１の構造化文書管理システムで、必要に応じて検索条件として用いるキーワードなどとして使用される語をその意味内容から階層的に分類した結果である概念階層を構造化文書で表現した例を示す。図１６、図１７に示す「概念」情報はＸＭＬで記述したコンテンツ文書である。
【０１０３】
図１６に示した「概念」情報の例は、いわゆる特許調査における特許文書の内容を分類するための１つの分類軸として用いる「情報モデル」を概念階層で表現している。「概念」タグで囲まれた「概念」情報は、入れ子構造を持った文書構造をもっている。つまり、図１６の例では、概念「情報モデル」の子供概念として、概念「ドキュメント」、概念「リレーション」、概念「オブジェクト」が存在している。また、概念「ドキュメント」の子供概念として、概念「構造化ドキュメント」、概念「非構造化ドキュメント」が存在する。さらに、概念「構造化ドキュメント」の子供概念として、概念「ＸＭＬ」、概念「ＳＧＭＬ」が存在している。
【０１０４】
図１７に示す「概念」情報の記述例は、図１６とは異なる分類軸「情報操作」を概念階層で表現している。図１７の例では、概念「情報操作」の子供概念として、概念「検索」、概念「格納」、概念「加工」、概念「流通」が存在している。
【０１０５】
図１６，図１７に示したような「概念」情報も、前述の「特許」情報と同様にして、構造化文書データベース内に格納することができる。すなわち、例えば、まず、図８に示した状態の構造化文書データベースに対して、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜概念ＤＢ／＞”）」を実行して、図１８に示すように、「＃２０１」ノードと「概念ＤＢ」アークが作成される。この状態において、図１６に示した「概念」情報を格納する場合には、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／概念ＤＢ”，“＜概念名前＞…＜／概念＞”）」を実行する。このコマンド中「“＜概念名前＞…＜／概念＞”」が、図１６に示した「概念」情報に対応する。
【０１０６】
上記追加コマンドの処理が実行されると、図１９に示すように、「＃２０１」ノード以下に「＃２０２」ノードをトップとする文書オブジェクトツリーが追加される。
【０１０７】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。そのため、部分的なＸＭＬ文書をアクセスするには巨大なＸＭＬ文書に対するパスという、文書構造に依存しない統一的なアクセス手段を用いることにより、幅広くＸＭＬ文書を検索したり加工したりすることが可能になる。
【０１０８】
また、構造化文書データベース上の一部にスキーマを設定することで、格納しようとする文書の文書構造がそのスキーマにより定義されている文書構造に一致するか否かの妥当性のチェックを自動的に行うようにしてもよい。
【０１０９】
（検索機能）
図１の構造化文書管理システムにおける検索系のコマンドには以下のものがある。
【０１１０】
ｑｕｅｒｙ（ｑｌ）
「ｑｕｅｒｙ」は、パラメータとして（ ）内のクエリｑｌを実行し、その結果のＸＭＬ文書を取得するコマンド（以下、検索コマンドと呼ぶ）である。
【０１１１】
クエリは、例えば、図２０に示すように、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）に似た形式の言語により、検索位置、検索条件、情報抽出部分などを記述した、文書構造をもつＸＭＬ文書である。クエリ文書も構造化文書管理システムの管理対象である。
【０１１２】
「ｋｆ：ｆｒｏｍ」タグから始まる要素には、検索位置の指定と文書要素の値に変数を対応付ける記述があり、「ｋｆ：ｗｈｅｒｅ」タグのから始める要素には、変数に関する条件づけの記述があり、「ｋｆ：ｓｅｌｅｃｔ」タグから始まる要素には、検索結果の出力形式が記述される。
【０１１３】
検索には、単純検索と概念検索とがある。単純検索とは、クエリ中に指定された検索条件を満たす情報を検索・抽出するものであり、概念検索とは、クエリ中に指定された概念情報を利用して、クエリ中に指定された検索条件を満たす情報を検索・抽出するものである。
【０１１４】
図２１は、単純検索のクエリの例を示したものである。図２１のクエリは、例えば、図１４に示したような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群において、「１９９９年でかつ、「ＰＣ」のような内容の「要約」という要素をもつ文書（「特許」情報）の「タイトル」を列挙せよ」という検索要求の記述例を示している。
【０１１５】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」、「＄ｙ」、「＄ｓ」に、それぞれ「特許」情報の「タイトル」、「年」、「要約」という文書要素の値が代入される。
【０１１６】
「ｋｆ：ｗｈｅｒｅ」タグから始める要素の記述により、変数「＄ｙ」＝「１９９９」という比較がなされる。また、コンポーネント「ＭｙＬｉｋｅ」は変数「＄ｓ」と「ＰＣ」を引数として、「ＰＣ」と類似する値の変数「＄ｓ」を検知するための関数である。
【０１１７】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」が出力値として利用される。
【０１１８】
なお、「ｋｆ：ｓｔａｒ」タグは構造の曖昧表現であり、例えば「＜特許＞＜ｋｆ：ｓｔａｒ＞＜年＞」は「タグ名が「特許」である要素の子孫の要素としていずれかに存在し、タグ名が「年」である要素」を意味する。
【０１１９】
図２２に図２１の単純検索のクエリを用いた検索結果を示す。この検索結果もＸＭＬ文書である。
【０１２０】
図２３は、概念検索のクエリの例を示したものである。図２３のクエリは、例えば図１８，図１９に示すような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群に対し、「概念ＤＢ」アークが示すノード以下に格納されている「概念」情報を利用して検索するための検索要求の記述例を示している。ここで、概念「周辺装置」の値をもつタグの子要素の値には、概念「ＳＣＳＩ」、「メモリ」、「ＨＤＤ」などがあるものとする。また、図１８には示していないが、各「特許」情報の構成要素には、「キーワード」タグから始める要素も存在するものとする。
【０１２１】
すなわち、図２３のクエリは、「概念「周辺装置」以下の概念のいずれかを「キーワード」という構成要素の要素値としてもつ「特許」情報の「タイトル」を列挙せよ」という検索要求の記述例を示している。
【０１２２】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」、変数「＄ｋ」に、それぞれ、「特許」情報の「タイトル」、「キーワード」という要素の値が代入される。また、変数「＄ｘ」は「概念」情報として「周辺装置」の値をもつタグの子要素の値（「ＳＣＳＩ」、「メモリ」、「ＨＤＤ」など）が代入される。
【０１２３】
「ｋｆ：ｗｈｅｒｅ」タグから始める要素の記述により、「＄ｋ」＝「周辺装置」もしくは「＄ｋ」＝「＄ｘ」という比較がなされる。
【０１２４】
次に、図１の構造化文書管理システムの文書検索処理動作について、図２４に示すフローチャートを参照して説明する。
【０１２５】
クライアント端末の所定の表示装置には、構造化文書管理システム１００（の例えば、要求制御部１）から提供された、例えば、図２５に示すようなユーザインターフェイスとしての画面が表示されている。
【０１２６】
図２５に示した画面上で、ユーザが「ＸＭＬ検索Ｗｉｎ」をマウス等のポインティングデバイスなどを用いて選択すると、図２６に示すような文書検索を行うためのユーザインタフェースとしての画面が表示される。
【０１２７】
図２６の検索画面において、領域Ｗ１には、構造化文書データベースの現在のツリー構造の構成要素の要素名（タグ名）がユーザが理解可能なように簡略的に表示されている。なお、図２６では、上位階層の要素名のみを表示しているが、末端の要素名まで表示可能である。
【０１２８】
領域Ｗ１１は、検索対象の範囲（ツリー構造上の検索範囲）や、検索条件などを入力するための領域である。領域Ｗ１２には、検索結果が表示される。
【０１２９】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグをもつ構成要素の要素値に「文書」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という検索要求の場合には、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、領域Ｗ１１には、まず、トップノードとして、「特許」を入力する（この場合、領域Ｗ１から「特許」をマウス等で選択することにより入力してもよい）。また、検索条件としての、「「タイトル」という構成要素の要素値に「文書」という文字列を含む」「「年」という構成要素の要素値が「１９９８」以上である」という内容は、予め設けられたデータ入力領域に入力すればよい。
【０１３０】
その後、「検索」ボタンＢ２１を選択することにより、例えば、図２７に示すようなクエリが、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。なお、クエリの格納場所は、予め定められており、システム側が自動的に、この追加コマンドのパラメータを設定することとなる。例えば、構造化文書データベースが図１８に示した状態のとき、当該クエリの格納場所を表すパラメータとしての構造化文書パスは、「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」となる。また、追加コマンドのもう一方のパラメータは、当該クエリ文書である。
【０１３１】
要求受付部１１は、上記クエリを受け付けると（ステップＳ１００）、当該クエリを検索要求処理部３へ渡す。そして、当該クエリ文書を格納するための追加コマンドのパラメータを文書格納部２１へ渡す。文書格納部２１では、追加コマンドの処理を行って、当該クエリは、文書記憶部５に格納される（ステップＳ１０１）。
【０１３２】
一方、検索要求処理部３では、受け取ったクエリを基に、データアクセス部４を通してインデックス記憶部６，文書記憶部５にアクセスし、検索要求に合致する文書集合などを取得して、クエリの中で要求された情報を抽出して結果処理部１２を介して出力する。
【０１３３】
例えば、上記クエリの場合、まず、「「タイトル」タグをもつ構成要素の要素値に「文書」という文字列を含む」という条件に合致するものを検索することが検索対象を絞り込む上で効率がよい。そこで、図１０に示したようなデータ生起インデックスを用いて、「文書」という文字列にリンクされているノード（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを上流側に１つ遡り、「タイトル」というタグ名にたどり着いたときは、更に上流に辿っていき、「特許」というタグ名にたどり着いたときは、そのノード以下の文書オブジェクトツリーＯｔ１１を抽出する。
【０１３４】
次に、この抽出された複数の文書オブジェクトツリーＯｔ１１の中から、さらに、「年」という構成要素の要素値が「１９９８」年以上の文書オブジェクトツリーＯｔ１２を抽出する。
【０１３５】
この文書オブジェクトツリーＯｔ１２が上記クエリの内容に適合する文書となる。さらに上記クエリの要求内容に従えば、各文書オブジェクトツリーＯｔ１２のトップノードへの構造化文書パスを求める（ステップＳ１０２）。
【０１３６】
なお、上記検索処理は、上記した方法に限るものではなく、インデックス情報を用いた様々な効率のよい検索方法が可能である。
【０１３７】
検索要求処理部３は、ステップＳ１０２で得られた結果を統合して、検索結果としてのＸＭＬ文書を作成する（ステップＳ１０３）。
【０１３８】
例えば、検索結果のＸＭＬ文書は、
＜ｏｕｔ＞
＜ｒｅｓｕｌｔ＞
ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］
＜／ｒｅｓｕｌｔ＞
＜ｒｅｓｕｌｔ＞
ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［２］
＜／ｒｅｓｕｌｔ＞
＜／ｏｕｔ＞
となる。
【０１３９】
検索要求処理部３は、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す（ステップＳ１０４）。
【０１４０】
クライアント端末では、図１１に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図２６に示すように、領域Ｗ１２に表示する。ここでは、例えば検索結果として得られた構造化文書の数が多いために、検索された構造化文書の構造化文書パスが検索結果として表示されている。この場合、例えば、図２６の領域Ｗ１２に表示された検索結果の構造化文書パスのうち、所望の１つがユーザにより選択されたとする。例えば、図２６の領域Ｗ１２に表示された構造化文書パスのうち、最初のものが選択されたとする。この場合、クライアント端末から構造化文書管理システムに対し、当該選択された構造化文書パスにより特定される構造化文書を取得するために文書取得要求として、取得コマンドを送信するようにしてもよい。
【０１４１】
取得コマンドが構造化文書管理システムの要求受付部１１にて受け付けられたときの、図１の構造化文書管理システムの文書取得処理動作について、図２８に示すフローチャートを参照して説明する。
【０１４２】
例えば、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］”）」なる取得コマンドが構造化文書管理システムへ送信される。
【０１４３】
ここでは、例えば、構造化文書データベースが、図８に示した状態のときに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］”）」なる取得コマンドを受け付けた場合を例にとり説明する。
【０１４４】
要求受付部１１は、上記取得コマンドを受け付けると、上記取得コマンド中のパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」を文書取得部２２へ渡す（ステップＳ３１）。
【０１４５】
文書取得部２２は、文書オブジェクトツリー取得部４３へ構造化文書パスを渡す。文書オブジェクトツリー取得部４３は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ５）を取り出す（ステップＳ３２）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ５のオブジェクトＩＤを取得することができるので（ステップＳ３３）、その場合は、ステップＳ３５へ進む。
【０１４６】
例えば、上記取得コマンドの場合、「＃４２」ノードが文書オブジェクトＯｘ５となるので、そのオブジェクトＩＤとして、「＃４２」を取得するとともに、この「＃４２」ノード以下の文書オブジェクトツリーＯｔ５（「＃４２」ノード〜「＃４９」ノード）を取得する（ステップＳ３５）。
【０１４７】
ステップＳ３２において、指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ５が見つからなければ、エラーとなり（ステップＳ３３）、文書取得部２２，結果処理部１２を介して、クライアント端末に「文書取得失敗」の旨のメッセージを返す（ステップＳ３４）。
【０１４８】
ステップＳ３５で取得した文書オブジェクトツリーＯｔ５は、文書文字列取得部４４でＸＭＬ文書に変換される。例えば、上記取得コマンドの場合、取得したＸＭＬ文書は、図３に示すような「特許」情報のＸＭＬ文書となる。
【０１４９】
文書取得部２２は、結果処理部１２を介して、図３に示したようなＸＭＬ文書を（例えば、ＸＳＬ（ｅＸｔｅｎｓｉｂｌｅ Ｓｔｙｌｅ Ｌａｎｇｕａｇｅ）といった所定のスタイルシートとともに）、クライアント端末へ返す（ステップＳ３７）。
【０１５０】
クライアント端末では、図３に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図２９に示すように、領域Ｗ１３に表示する。
【０１５１】
ＸＳＬを利用すると、ＸＭＬ文書を様々な形に変換することが出来る。違う構文書造のＸＭＬ文書に変換することも出来るし、ＸＭＬ文書からＨＴＭＬページを生成することも出来る。
【０１５２】
同様にして、スキーマの検索も行える。
【０１５３】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「ｓｃｈｅｍａ」を先頭タグに持つ文書の中から、「特許」と「要約」というタグ名を持つスキーマを検索せよ」という検索要求の場合には、図３０に示すように、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、トップノードとして、「＃ｓｃｈｅｍａ」を入力する。また、検索条件として、「構成要素の属性名に「特許」という文字列を含む」「構成要素の属性名に「要約」という文字列を含む」という内容を予め設けられたデータ入力領域に入力すればよい。
【０１５４】
その後、「検索」ボタンＢ２１を選択することにより、上記検索要求を記述した、例えば、図３１に示したようなクエリが、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。
【０１５５】
さて、上記クエリの場合、例えば、「「＃ｓｃｈｅｍａ」を先頭タグに持つ」という条件に合致するものを検索する。そこで、図９に示したような要素名称生起インデックスを用いて、「＃ｓｃｈｅｍａ」という要素にリンクされているノードの（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、属性名が「特許」と「要約」いう要素にたどり着いたときは、当該「＃ｓｃｈｅｍａ」を先頭タグにもつ文書オブジェクトツリーＯｔ２１を抽出する。この文書オブジェクトツリーＯｔ２１が上記クエリの内容に適合する文書となる。さらに、図３１に示したクエリの要求内容に従えば、各文書オブジェクトツリーＯｔ２１のトップノードへの構造化文書パスを求める。
【０１５６】
検索要求処理部３は、文書オブジェクトツリーＯｔ２１が複数あれば、それぞれのトップノードへの構造化文書パスをまとめて、検索結果としてのＸＭＬ文書を作成し、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す。
【０１５７】
クライアント端末では、検索結果として受け取ったＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図２６に示すように、領域Ｗ１２に表示する。
【０１５８】
クライアント端末では、検索結果の中の１つのスキーマを選択して、表示させると、例えば、図３２に示すような文書の格納／削除を行うための画面とともに、その領域Ｗ３に、「特許」情報のデータ入力領域が各要素毎に設定されて表示される。
【０１５９】
ユーザは、このデータ入力領域にデータを入力することで、スキーマにより定義された文書構造の格納文書が容易に作成することができる。
【０１６０】
例えば、図３２の領域Ｗ３に入力した「特許」情報の格納先として、領域Ｗ１で「特許ＤＢ」をマウス等を用いて選択すると、領域Ｗ２に構造化文書パスとして、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される。その後、「登録」ボタンＢ１を選択すると、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０１６１】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。従って、文書構造が異なる、様々なスキーマを持つ膨大な数の文書の中から検索条件に合致する文書を容易に検索できる。
【０１６２】
また、検索に用いるクエリも構造化文書であるので、構造化文書データベースにログとして格納することにより、過去のクエリを再利用するようなアプリケーションも容易に構築することができる。
【０１６３】
（絞込検索）
以下、本発明の実施形態について、図面を参照して説明する。
【０１６４】
ここでは、ユーザは、単に、検索したい構造化文書の構成要素の要素名や要素値に含まれるようなキーワードを入力しさえすれば、絞込検索を通じて所望の構造化文書が容易に検索することができる手法を適用した検索支援装置について説明する。
【０１６５】
この検索支援装置は、例えば、図２のクライアント端末１０２内に構成されていてもよい。この場合、検索支援装置は、前述の図１に示した構造化文書管理システムに入力するためのクエリを生成して、それを図１の構造化文書管理システムに送信したり、また、当該クエリに基づく検索結果を取得して、この検索結果から絞込条件を抽出しユーザに呈示するなどの処理を行うものである。
【０１６６】
図３３は、本実施形態にかかる検索支援装置２０１の構成例を示したもので、例えば、クライアント端末１０２のブラウザ１０３に組み込まれて構成されている。このように図３３に示した検索支援装置２０１は、アドインソフトとして構成可能である。
【０１６７】
図３３に示したように、検索支援装置２０１は、初期条件入力部２１１と検索要求発行部２１２と検索結果取得部２１３と検索結果サンプリング部２１４と絞り込み条件抽出部２１５と選択部２１６と検索結果表示部２１７から構成されている。
【０１６８】
構造化文書管理システム１００は、検索支援装置２０１から送られてきたクエリと呼ばれる検索要求を受信して、ＸＭＬデータベース（すなわち、ここでは文書記憶部５に格納されている、例えば、図８に示したような階層化された論理構造をもつデータベース）から当該検索要求にマッチする検索結果としてのＸＭＬ文書を検索し、ＸＭＬデータの並びという形式で検索支援装置２０１に送信する。
【０１６９】
ＸＭＬデータの並びは、必ずしもテキスト列というわけではなく、バイナリ化されている場合もある。
【０１７０】
初期条件入力部２１１は、検索したい文書を検索するための検索条件を生成するために必要な、少なくとも１つのキーワード（複数のキーワードであってもよい）を入力するためのものである。
【０１７１】
前述したように、ＸＭＬデータベースには様々な構造（文書構造）や語彙を持ったＸＭＬデータ（ＸＭＬ文書）が大量に格納されているため、ユーザはこのＸＭＬデータベースの中から所望の文書を検索するために前もって明確なＸＭＬデータに対する検索条件を設定することは困難である。明確な検索条件とは、ＸＭＬデータに対する構造に関する条件や語彙に関する条件が必要十分なことである。そこで、ユーザはフルテキスト検索などと同様にキーワードレベルの粗い検索条件しか設定できない場合がほとんどである。初期条件入力部２１１では、そのような粗い検索条件がユーザにより入力されると、検索要求発行部２１２を呼び出す。
【０１７２】
検索要求発行部２１２では、上記入力されたキーワードを検索条件として構造化文書管理システムが認識できるような形式に変換する。すなわち、上記入力されたキーワードを構成要素の要素名あるいは要素値に含むようなＸＭＬ文書を検索するためのクエリ（あるいは、以下に示すように、入力されたキーワードを構成要素の要素値に含むようなＸＭＬ文書を検索するためのクエリであってもよい）を生成し、当該クエリを構造化文書管理システム１００へ送信する。
【０１７３】
検索結果取得部２１３は、検索要求発行部２１２で生成されたクエリに基づき構造化文書管理システム１００で検索されたＸＭＬデータ（ＸＭＬ文書、簡単に文書と呼ぶこともある）の集合を取得する。ここで検索結果として得られたＸＭＬ文書の数が多い場合には、検索結果サンプリング部２１４にて、当該検索結果として得られたＸＭＬ文書の中から所定数のＸＭＬ文書を選択し、この選択したＸＭＬ文書を処理対象の文書として絞り込み条件抽出部２１５へ渡す。例えば、検索結果のうちの「最初の１００件」を無作為に取り出すことにより、実用時間内で応答するように制御するようになっている。もちろん検索結果として得られたＸＭＬ文書の数が少ない（例えば、上記の例の場合、１００件に満たない場合）には、その全てを処理対象の文書として絞り込み条件抽出部２１５へ渡すようにしてもよい。
【０１７４】
なお、検索結果サンプリング部２１４は、必ずしも設ける必要はなく、この構成部のない検索支援装置も構成可能である。この場合、検索結果取得部２１３は、構造化文書管理システム１００から得られた検索結果としてのＸＭＬ文書を全て処理対象の文書として絞り込み条件抽出部２１５へ渡せばよい。
【０１７５】
絞り込み条件抽出部２１５は、検索結果として得られたＸＭＬ文書（具体的には、検索結果サンプリング部２１４で取り出されたＸＭＬ文書）を処理対象として、この処理対象の文書から、さらに絞り込みをかけるための、より詳細な検索条件としての絞り込み条件を抽出する。なお、絞り込み条件とは、初期条件入力部２１１にてユーザから設定された粗い検索条件をより詳細化した検索条件である。例えば、処理対象の文書の文書構造上の違いや、各処理対象の文書に含まれている単語などの語彙の違いなどが絞り込み条件の候補として抽出される。
【０１７６】
検索結果表示部２１７は、抽出された絞り込み条件と、検索結果として得られたＸＭＬ文書の一覧などを表示するための表示データを作成し、クライアント端末１０２のディスプレイなどに表示する。
【０１７７】
選択部２１６は、検索結果表示部２１７により表示された複数の絞り込み条件のうちの１つがユーザにより選択されると、検索要求発行部２１２を呼び出す。このとき、検索要求発行部２１２では、直前の検索結果のＸＭＬ文書の中から、さらに当該選択された絞り込み条件を満たすＸＭＬ文書を検索するためのクエリ（すなわち、初期条件とそれまでに選択された絞り込み条件とを全て満たすＸＭＬ文書を検索するためのクエリ）が生成される。このクエリは構造化文書管理システムへ送信される。構造化文書管理システムにおいて当該クエリに基づき検索を行った結果は、検索結果取得部２１３により取得される。
【０１７８】
次に、図３４〜３６に示すフローチャートに従って、図３３に示した検索支援装置の処理動作について説明する。
【０１７９】
前述したように、ＸＭＬデータベースには、異なる文書構造の複数のＸＭＬ文書がその文書構造に基づく階層構造に従って格納されている。この検索支援装置の処理動作の説明に際しては、ＸＭＬデータベースの具体例を示さないが、以下に示す検索結果として得られた「ＢＯＯＫ」タグを先頭とする４つの文書は、ＸＭＬデータベースの「ｒｏｏｔ」ノード以下のいずれかに記憶されているものとする。また、「ＢＯＯＫ」ノード以下に格納されている文書は、全て同じ文書構造であるとは限らない（すなわち、スキーマが設定されていない）ものとする。従って、「ＢＯＯＫ」ノード以下に格納されている各文書は、例えば内容的には類似するものの文書構造が全て同一であるとは限らない。
【０１８０】
まず、ユーザは、初期条件入力部２１１から文書検索のための初期条件として、少なくとも１つのキーワードを入力する（ステップＳ２０１）。
【０１８１】
図３７は、初期条件入力部２１１からクライアント端末１０２のディスプレイに表示される初期条件入力画面の一例を示したものである。ユーザは、この初期条件入力画面上に設けられた入力領域Ｘ１に、文書を検索するための初期条件として、少なくとも１つのキーワードを入力する。ここでは、「ＸＭＬ」というキーワードが入力されているが、複数のキーワードを入力する場合には、それらをカンマなどで区切りながら並べて入力するようにしてもよい。
【０１８２】
ユーザにより初期条件としてのキーワードが入力されると、検索要求発行部２１２が起動し、ここでは、当該入力されたキーワードを構成要素の要素値に含むＸＭＬ文書を検索するためのクエリを生成する（ステップＳ２０２）。
【０１８３】
図３８は、検索要求発行部２１２で生成されたクエリの一例で、「ＸＭＬ」というキーワードをいずれかの構成要素の要素値に含むＸＭＬ文書を検索することを構造化文書管理システム１００に指示する検索要求文である。つまり、「ｋｆ：ｆｒｏｍ」節では、ＸＭＬデータベース中の検索位置として、構造化文書パスにて、「ｕｉｘ：／／ｒｏｏｔ」が指定されている。また、「ｋｆ：ｗｈｅｒｅ」節では、「ＸＭＬ」を要素値に含むという条件が記述されている。「ｋｆ：ｓｅｌｅｃｔ」節では、「ｕｉｘ：／／ｒｏｏｔ」以下に格納されている文書のうち、「ｋｆ：ｗｈｅｒｅ」節に記述されている条件にマッチする文書の集合を返すことが記述されている。
【０１８４】
なお、図３８に示したクエリは、要素値に「ＸＭＬ」というキーワードを含む文書を検索するクエリであるが、同様にして、検索要求発行部２１２は、要素名に「ＸＭＬ」というキーワードを含む文書を検索するクエリや、要素名と要素値のうちの少なくとも一方に「ＸＭＬ」というキーワードを含む文書を検索するクエリを生成することも可能である。
【０１８５】
検索要求発行部２１２は、例えば、図３８に示したようなクエリを生成するためのクエリの雛形を記憶している。この雛形は、例えば、ユーザにより入力されたキーワード「ＸＭＬ」を代入すれば、図３８に示したようなクエリが完成するものである。このように、検索要求発行部２１２は、ユーザにより入力された初期条件、あるいは選択された絞り込み条件を代入、追加さえすればクエリとして完成するクエリの雛形を複数種類予め記憶しておき、これを基にクエリを生成するようにしてもよい。
【０１８６】
さて、検索要求発行部２１２で生成されたクエリ（例えば、図３８に示したようなクエリ）は、構造化文書管理システム１００へ送信されると、構造化文書管理システム１００の要求処理部１で当該クエリが受け付けられ、前述したようにして、当該クエリに基づきＸＭＬデータベースの「ｒｏｏｔ」ノード以下から、要素値に「ＸＭＬ」というキーワードを含むＸＭＬ文書が検索される。検索した結果得られた文書は、クライアント端末１０２へ送信され、検索支援装置２０１の検索結果取得部２１３が当該検索結果を取得する（ステップＳ２０３）。
【０１８７】
例えば、構造化文書管理システムおいて１２０件の文書が検索されたものとする。この１２０件の文書全てが検索結果として検索支援装置２０１の検索結果取得部２１３で取得されるものとする。そして、検索結果サンプリング部２１４では、このうち、例えば、先頭の４件の文書を選択（サンプリング）したとする。
【０１８８】
この４件の文書を、図３９に示す。図３９に示すように、各文書Ｒｅｃ１〜４は、全て「ＢＯＯＫ」タグをルートとする構造化文書であり、「ＣＡＴＥＧＯＲＹ」タグをもつ構成要素は、４つの文書に共通する構成要素であり、また、「ＰＲＩＣＥ」タグをもつ構成要素は文書Ｒｅｃ１〜３には存在するが、文書Ｒｅｃ４には存在しない。
【０１８９】
図３９に示した４つの文書が処理対象の文書として、絞り込み条件抽出部２１５に渡される。絞り込み条件抽出部２１５では、これら４つの文書のそれぞれの文書構造と構成要素の要素値とから、絞り込み条件を抽出する（ステップＳ２０４）。絞り込み条件とは、初期条件入力部２１１にてユーザから設定された粗い検索条件をより詳細化した条件である。
【０１９０】
ここで、ステップＳ２０４の絞り込み条件抽出部２１５における絞り込み条件の抽出処理の一例について、図３６に示すフローチャートを参照して説明する。
【０１９１】
まず、今回の処理対象の４つの文書は、最初の検索結果であるので（ステップＳ２２１）、ステップＳ２２２へ進む。
【０１９２】
ステップＳ２２２では、この処理対象の文書のそれぞれの先頭の構成要素の要素名を抽出し、この抽出された要素名を条件としたとき、処理対象の文書のそれぞれが上記条件のうちどの条件を満たすのかを表した構造テーブルを作成する（ステップＳ２２２）。
【０１９３】
構造テーブルを作成することにより、処理対象の文書の文書構造上、語彙上の相違点が明らかとなる。構造テーブル上に、処理対象の文書の相違点が表れていれば、当該構造テーブル上の条件を絞り込み条件として用いることにより、絞り込みがより効率よく行える。そこで、この生成された構造テーブル上に、処理対象の文書間に存在する相違点が表れていないときには（ステップＳ２２３）、展開元の構成要素を選択し（ステップＳ２２４）、当該展開元の構成要素に包含される当該構成要素の要素値や構成要素などを抽出して、上記ステップＳ２２２と同様にして、これらを条件としたとき、処理対象の文書のそれぞれが、どの条件を満たすのかを表した構造テーブルを作成し（ステップＳ２２５）、ステップＳ２２３へ戻る。
【０１９４】
ステップＳ２２３において、作成された構造テーブルから、処理対象の文書に相違点があると判断することができるときには、ステップＳ２２６へ進む。
【０１９５】
次に、ステップＳ２２２やステップＳ２２５での処理の詳細と、構造テーブルについて説明する。
【０１９６】
構造テーブルのｘ軸方向には各文書の文書ＩＤを列のインデックスとして設定し、ｙ軸方向には、上記抽出された条件を行のインデックスとして設定し、各文書に対応する列を構成するセルのうち、当該文書が満たしている条件に対応するセルには「○」、当該文書が満たしていない条件に対応するセルに「×」が書き込まれている。
【０１９７】
ＸＭＬ文書の集合を絞り込むための絞り込み条件は、一般に複数ある。構造テーブルにより、絞り込み条件を優先順位付けしてユーザに提示することで、ユーザは効率よく絞り込みが行えることになる。つまり、「どのような絞り込み条件があるのか分からない」、「どの絞り込み条件を設定すれば効率良く絞り込みができるのか分からない」、などのユーザ要求があるが、これを支援することができるのである。
【０１９８】
図４０は、構造テーブルの一例を示す図である。２つの構造テーブルが存在する。図４０（ａ）に示す構造テーブルは、処理対象としての４つのＸＭＬ文書Ｒｅｃ１〜Ｒｅｃ４から生成された最初の構造テーブルである。すなわち、ステップＳ２２２で生成された構造テーブルである。構造テーブルのｘ軸には、各ＸＭＬ文書の文書ＩＤ「Ｒｅｃ１」〜「Ｒｅｃ４」が並んでいる。ｙ軸には、各ＸＭＬ文書のルート（先頭）から各文書構造を展開した結果得られた条件が並んでいる。４つのＸＭＬ文書をルートから構造的に見ると、先頭の構成要素は、全て「ＢＯＯＫ」タグをもつ構成要素がある。すなわち、この時点で、“「ＢＯＯＫ」タグを持つ”という条件が抽出された。４つの文書Ｒｅｃ１〜Ｒｅｃ４には、それぞれ「ＢＯＯＫ」タグがあるので、図４０（ａ）に示すように、この条件を満足した印である「○」が並んでいる。
【０１９９】
これは、すべて条件を満足する「○」なので（４つの文書に相違点がない（「×」がない）ので）、ステップＳ２２３からステップＳ２２４へ進み、次に、この最初の構造テーブルを展開する（階層構造を１段下流に向かって掘り下げて、そこに存在する文書構造や語彙を調べる）ための処理を行う。
【０２００】
まず、この最初の構造テーブル上の条件の中から展開元を選択する（ステップＳ２２４）。この場合、「ＢＯＯＫ」という構成要素だけなので、必然的にこの「ＢＯＯＫ」が選択される。そして、ステップＳ２２５では、「ＢＯＯＫ」という構成要素に包含される（下流に繋がる）当該構成要素の要素値や構成要素の要素名を処理対象の文書のそれぞれから抽出し、それらを条件としたとき、処理対象の文書のそれぞれがどの条件を満たすのかを表した構造テーブルを作成する（図４０（ｂ））。
【０２０１】
例えば、処理対象の４つの文書のうちの１つである文書Ｒｅｃ１の「ＢＯＯＫ」という構成要素の１段下の階層には、図３９からも明らかなように、「ＣＡＴＥＧＯＲＹ」タグ、「ＴＩＴＬＥ」タグ、「ＰＵＢＬＩＳＨＥＤＤＡＴＥ」タグ、「ＰＲＩＣＥ」タグ、「ＡＢＳＴＲＡＣＴ」タグをそれぞれもつ構成要素がある。
【０２０２】
すなわち、ステップＳ２２５では、“「ＢＯＯＫ」タグを持つという条件”を展開することにより、“「ＢＯＯＫ」タグの下に「ＣＡＴＥＧＯＲＹ」タグがある”、“「ＢＯＯＫ」タグの下に「ＴＩＴＬＥ」タグがある”、“「ＢＯＯＫ」タグの下に「ＰＵＢＬＩＳＨＥＤＤＡＴＥ」がある”、などの構造的な条件群が得られる。もちろん、「ＢＯＯＫ」タグをもつ構成要素に要素値をもつものがあれば、それもこの段階で抽出されて、語彙的な条件として用いることもできる。
【０２０３】
図４０（ｂ）に示す構造テーブルでは、ｙ軸上に上記のような条件が並び、処理対象の４つの文書のそれぞれについて、当該条件を満たすか満たさないかを「○」「×」で表している。
【０２０４】
図４０（ｂ）からも明らかなように、「ＡＵＴＨＯＲ」という要素名の構成要素は、文書Ｒｅｃ２には存在しない。また、「ＰＲＩＣＥ」という要素名の構成要素は、文書Ｒｅｃ４には存在しない。すなわち、図４０（ｂ）に示した構造テーブルから、処理対象の４つの文書に相違点があることがわかる。そこで、この場合には、ステップＳ２２３からステップＳ２２６へ進む。
【０２０５】
なお、“「ＢＯＯＫ」タグを持つという条件”を展開しても、処理対象の文書に相違点が存在しないときには、ステップＳ２４へ進み、展開元として、例えば、図４０（ｂ）に示す構造テーブル上の条件のうち最初の条件から順番に選択して、相違点が表れるまで図４０（ｂ）に示す構造テーブルを展開するようにしてもよい。
【０２０６】
このように、構造テーブルは、処理対象の文書のそれぞれがもつ文書構造や、処理対象の文書のそれぞれが要素値として包含している語彙を比較するためのものであり、この構造テーブルを用いることにより、処理対象の文書における構造的な特徴と語彙的な特徴の一致点、相違点が明らかとなる。この処理対象の文書における構造的な特徴と語彙的な特徴の相違点を、絞り込み検索の際に用いる条件として用いれば、検索範囲をより限定することができ、絞り込みを効率よく行える。そこで、ここでは、この点に着目し、上記相違点を絞り込み条件の候補として優先的にユーザに呈示するものである。すなわち、各処理対象の文書の文書構造と、各処理対象の文書により包含される語彙とから抽出される条件のうち、処理対象の文書間に違いを生じさせるものほど、検索範囲を限定することができる絞り込み条件となり得るから、そのような条件ほど優先度（優先順位）を高く設定する。
【０２０７】
構造テーブル上に処理対象の文書の相違点が表れている場合、ステップＳ２２６では、例えば、図４０（ｂ）に示したような構造テーブル上の行のインデックスとして設定された各条件に対し、優先順位を定める。すなわち、ここでは、より絞り込まれた検索結果が得られるような条件ほど優先順位が高くなるように、優先順位を求める。
【０２０８】
優先順位の算出手法について、以下に詳細に説明する。この手法は、ＩＤ３（Ｊ．Ｒ．Ｑｕｉｎｌａｎ， ”Ｉｎｄｕｃｔｉｏｎ ｏｆ Ｄｅｃｉｓｉｏｎ Ｔｒｅｅｓ”， Ｍａｃｈｉｎｅ Ｌｅａｒｎｉｎｇ， Ｖｏｌ．１， ｐｐ．８１−ｐｐ．１０６， １９８６）などで使用されている期待情報量最大化原理に基づいて行うものである。つまり、Ｃを属性とその属性値、所属クラスによって表現される事例集合とする。Ａを属性の集合とし、Ｋをクラスの数、Ｐｊを事例集合Ｃの中で暮らすｊに属する事例の比率とすると、事例集合Ｃの情報量（エントロピー）Ｍ（Ｃ）は以下の式で表わされる。
【０２０９】
Ｍ（Ｃ）＝−Σ｛ｊ＝１，ｋ｝Ｐｊｌｏｇ２（Ｐｊ）
Ｃをある属性ａの属性値ａｉ，…ａｎによって部分集合Ｃ１，…Ｃｎに分割したときの期待情報量Ｂ（Ｃ，ａ）は以下の式で表わされる。
【０２１０】
Ｂ（Ｃ，ａ）＝Σ｛ｉ＝１，ｎ｝｜Ｃｉ｜／｜Ｃ｜×Ｍ（Ｃｉ）
獲得情報量の期待値ｇａｉｎ（Ｃ，ａ）は以下の式になる。
【０２１１】
ｇａｉｎ（Ｃ，ａ）＝Ｍ（Ｃ）−Ｂ（Ｃ，ａ）
このｇａｉｎ（Ｃ，ａ）を最大にする属性ａで事例集合を分割していくことで、効率的に事例をクラスに分けることができる。
【０２１２】
本実施形態の場合、各検索結果は、それぞれ別のクラスであるとして扱う。
【０２１３】
Ｍ（Ｃ）＝（−１／ｎ×ｌｏｇ２（１／ｎ））×ｎ （ｎ：条件Ｃを満たす文書の数）
ここで、図４０（ｂ）に示した構造テーブルの行のインデックスとして設定された各条件（Ｃ）についてＭ（Ｃ）を計算する。
【０２１４】
Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ”）＝（−１／４×ｌｏｇ２（１／４））×４＝２
Ｍ（“ＯＯＫ／ＴＩＴＬＥ”）＝２
Ｍ（“ＢＯＯＫ／ＰＵＢＬＩＳＨＥＤＤＡＴＥ”）＝２
Ｍ（“ＢＯＯＫ／ＡＵＴＨＯＲ”）＝（−１／３×ｌｏｇ２（１／３））×３＋（−１／１× ｌｏｇ２（１／１））×１＝１．１９
Ｍ（“ＢＯＯＫ／ＰＲＩＣＥ”）＝１．１９
Ｍ（“ＢＯＯＫ／ＡＢＳＴＲＡＣＴ”）＝２
この場合、Ｍ（Ｃ）の値が小さいものほど、絞り込まれた検索結果が得られる条件であることを表しており、優先順位の高い条件となる。
【０２１５】
以上から、各条件を優先順位の高い順に並べると、
“ＢＯＯＫ／ＡＵＴＨＯＲ”＞＝“ＢＯＯＫ／ＰＲＩＣＥ”＞“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ”＝“ＢＯＯＫ／ＴＩＴＬＥ”＝“ＢＯＯＫ／ＰＵＢＬＩＳＨＥＤＤＡＴＥ”
となる。
【０２１６】
絞り込み条件抽出部２１５は、上記優先順位に従って、図４０（ｂ）に示したような構造テーブル上の行のインデックスとして設定された各条件を並べて、絞り込み条件の表示データを作成する（ステップＳ２２６）。
【０２１７】
図３４の説明に戻り、ステップＳ２０４において、絞り込み条件の表示データが絞り込み条件抽出部２１５で作成されると、検索結果表示部２１７では、処理対象の４つの文書の一覧データを作成するとともに、この一覧データと、絞り込み条件の表示データとから、絞り込み条件と検索結果の文書の一覧をユーザに呈示するための検索結果表示画面データを作成し、クライアント端末１０２のディスプレイに表示する（ステップＳ２０５）。
【０２１８】
図４１は、検索結果表示部２１７で表示する検索結果表示画面の表示例を示したものである。
【０２１９】
検索結果表示画面の領域Ｙ２には、絞り込み条件が、絞り込み条件抽出部２１５で求めた優先順位の高い順に並べられて表示されている。図４１において、各絞り込み条件の左端にある図形により、他の文書との間の相違点の有無、すなわち、構造テーブル上で「○」と「×」が混在してい文書であるか否かを視覚的に表している。例えば、「◇」は、「○」「×」が発生する条件を表わし、「□」は全て「○」となっている条件を表わしている。
【０２２０】
検索結果表示画面の領域Ｙ３には、検索結果の文書の一覧が表示されている。ここでは、構造化文書パスにて表示されている。この一覧中の構造化文書パスのうち所望の１つがユーザによりマウス等の入力デバイスを用いて選択されると、図３５のステップＳ２０８からステップＳ２０９へ進み、選択部２１６は、検索結果表示部２１７を通じて、当該選択された構造化文書パスに対応する文書の内容を表示させる。また、検索結果表示画面上に設けられた「終了」ボタンが選択されると、検索支援装置２０１の処理動作は終了する。
【０２２１】
検索結果表示画面の領域Ｙ２に表示されている絞り込み条件の中から、ユーザは、マウス等の入力デバイスを用いて所望の絞り込み条件を選択することができる。ユーザは、領域Ｙ３に表示された検索結果にさらに絞り込みをかけたいときなどは、領域Ｙ２から所望の絞り込み条件を選択すればよい。例えば、ユーザにより、「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ」が選択されたとする（ステップＳ２０６）。
【０２２２】
ユーザにより絞り込み条件が選択されると、選択部２１６は、検索要求発行部２１２を起動する。検索要求発行部２１２では、前回の検索結果の文書の中から、当該選択された絞り込み条件を満たす文書を検索するためのクエリをステップＳ２０２の場合と同様にして生成する（ステップＳ２０７）。すなわち、例えば、前回の検索の際に生成されたクエリの検索条件を記述する「ｋｆ：ｗｈｅｒｅ」節に、今回選択された絞り込み条件をさらに追加するなどしてクエリを生成することもできる。
【０２２３】
この生成されたクエリは、前述同様、構造化文書管理システム１００へ送信されて、当該クエリに基づき、ＸＭＬデータベースの「ｒｏｏｔ」ノード以下から、要素値に「ＸＭＬ」というキーワードを含むＸＭＬ文書のうち、「ＢＯＯＫ」ノードの下に「ＣＡＴＥＧＯＲＹ」ノードがあるＸＭＬ文書が検索される。検索した結果得られた文書は、クライアント端末１０２へ送信され、検索支援装置２０１の検索結果取得部２１３が当該検索結果を取得し（ステップＳ２０３）、検索結果として得られた文書の数に応じて、そのうちの先頭の４件が、処理対象として選択される。
【０２２４】
なお、上記例の場合、処理対象の文書は、前回の検索と同様文書Ｒｅｃ１〜Ｒｅｃ４である。
【０２２５】
次に、２回目の検索結果に対して、ステップＳ２０４で行われる、絞り込み条件抽出部２１５の処理動作について、図３６を参照して説明する。今回の処理対象の文書は、絞り込み検索の検索結果として得られた文書であるから、ステップＳ２２１からステップＳ２２４へ進み、展開元として、今回の絞り込み検索の際に用いられた絞り込み条件を選択し、次に、ステップＳ２２５へ進む。
【０２２６】
ステップＳ２２５では、図４０（ｂ）に示した構造テーブルを、この構造テーブル上の条件のうち、今回の絞り込み検索において、ユーザにより選択された絞り込み条件「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ」を展開元として展開する。
【０２２７】
処理対象の文書Ｒｅｃ１〜Ｒｅｃ４のそれぞれは、図３９に示したように、「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ」の下には要素値としてのテキストがあり、それらは「コンピュータ」か「経済」のいずれかである。従って、この２つの語彙のそれぞれを含む条件を、構造テーブルの行のインデックスに設定する。また、文書Ｒｅｃ２以外の文書には「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ」の下に「ＳＵＢＣＡＴＥＧＯＲＹ」という構成要素が発生している（存在している）。従って、この構造上の条件も構造テーブルの行のインデックスに設定する。
【０２２８】
図４２は、このようにして「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ」を展開元として展開した結果得られた構造テーブルを示している。なお、図４２では、前回までに作成した構造テーブル上の優先順位の高い条件に、さらに上記語彙情報、構造情報を新たな条件として追加するかたちで作成された構造テーブルの一例を示している。
【０２２９】
次に、ステップＳ２２３からステップＳ２２６へ進み、前述同様にして、各条件についてＭ（Ｃ）の値を求めると、以下のようになる。
【０２３０】
Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）＝コンピュータ”）＝１．１９
Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）＝経済”）＝１．１９
Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）”）＝ＭＩＮ｛Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）＝コンピュータ”），Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）＝経済”）｝＝１．１９
Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ”）＝１．１９
Ｍ（“ＢＯＯＫ／ＡＵＴＨＯＲ”）＝１．１９
Ｍ（“ＢＯＯＫ／ＰＲＩＣＥ”）＝１．１９
この場合、上記全ての条件のＭ（Ｃ）は同じ値となっているので、絞り込み条件抽出部２１５は、例えば、構造テーブルの順番に、上記優先順位の等しい条件を並べて、絞り込み条件の表示データを作成する（ステップＳ２２６）。
【０２３１】
図４３は、今回、検索結果表示部２１７で表示する検索結果表示画面の表示例を示したものである。
【０２３２】
ユーザは、図４３に示した検索結果表示画面の領域Ｙ２から絞り込み条件として「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ」を選択したとする。これを絞り込み条件として絞り込み検索を行うと、検索結果の中から文書Ｒｅｃ２は除かれるので（文書Ｒｅｃ２は、今回の絞り込み条件を満たさないので）、絞り込み条件抽出部２１５の処理対象の文書は、文書Ｒｅｃ１、Ｒｅｃ３、Ｒｅｃ４となる。この３つの文書を処理対象の文書として、検索支援装置２０１の絞り込み条件抽出部２１５で、「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ」を展開元として作成した構造テーブルの一例を図４４に示す。
【０２３３】
処理対象の文書のそれぞれは、図４４に示したように、「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ」の下には要素値としてのテキストがあり、それらは「ソフトウエア」か「ハードウエア」のいずれかである。従って、この２つの語彙のそれぞれ含む条件が、構造テーブルの行のインデックスに設定されている。なお、図４４では、前回までに作成した構造テーブル上の優先順位の高い条件に、さらに上記語彙情報を新たな条件として追加するかたちで作成された構造テーブルの一例を示している。
【０２３４】
図４４に示した構造テーブル上の各条件についてＭ（Ｃ）の値を求めると、以下のようになる。
【０２３５】
Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）＝ソフトウエア”）＝１
Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）＝ハードウエア”）＝１．１９
Ｍ（“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）”＝ＭＩＮ（１，１．１９）＝１
Ｍ（“ＢＯＯＫ／ＡＵＴＨＯＲ”）＝１．１９
Ｍ（“ＢＯＯＫ／ＰＲＩＣＥ”）＝１．１９
上記算出結果を基に、各条件を優先順位の高い順に並べると、
“ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）”＞“ＢＯＯＫ／ＡＵＴＨＯＲ”＝“ＢＯＯＫ／ＰＲＩＣＥ”となる。
【０２３６】
絞り込み条件抽出部２１５は、上記条件を優先順位の高い順に並べて絞り込み条件の表示データを作成した結果、図４５に示したような検索結果表示画面が表示される。上記優先順位の高い順に絞り込み条件（の候補）が並べられている。
【０２３７】
ユーザは、図４５に示した検索結果表示画面の領域Ｙ２から絞り込み条件として「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）＝ソフトウェア」を選んだものとする。そして、絞り込み条件を追加した再検索（絞り込み検索）を行うため、ユーザは、「実行」ボタンを押す。
【０２３８】
図４６は、このとき検索要求発行部２１２で生成されたクエリデータの一例である。「ＸＭＬ」というキーワードを含むＸＭＬデータを検索するという初期条件以外に、これまでに選択された絞り込み条件が追加されている。つまり、この場合、「ｋｆ：ｆｒｏｍ」節では、「“ｕｉｘ：／／ｒｏｏｔ”以下のＸＭＬ文書のうち、「ＢＯＯＫ」というタグの構成要素を持ち、その下に「ＣＡＴＥＧＯＲＹ」タグをもつ構成要素があり、この構成要素に「コンピュータ」というテキストがあり、さらに、当該構成要素は「ＳＵＢＣＡＴＥＧＯＲＹ」タグを持つ構成要素を包含し、この「ＳＵＢＣＡＴＥＧＯＲＹ」タグをもつ構成要素に「ソフトウェア」というテキストを持つＸＭＬ文書」という検索条件が記述されている。
【０２３９】
図４６に示したクエリに基づき構造化文書管理システム１００で検索を行った結果、例えば、図４７に示すように、文書Ｒｅｃ１と文書Ｒｅｃ４とが検索されたとする。
【０２４０】
文書Ｒｅｃ１とＲｅｃ４とを処理対象として絞り込み条件抽出部２１５では、図３６に示したフローチャートに従って、今回の絞り込み条件、すなわち、「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ／ｔｅｘｔ（）＝ソフトウェア」を展開元として構造テーブルを展開するが、この場合、もうこれ以上展開することはできない。
【０２４１】
この場合、当該絞り込み条件が設定されている元の構造テーブル、すなわち、図４４に示した構造テーブル上に、文書Ｒｅｃ１とＲｅｃ４との相違点を表す条件も設定されているので、新たに、展開元を選択することなく、この構造テーブルを用いて、当該構造テーブル上の条件のうち、今回の絞り込み検索に用いた絞り込み条件を除く、文書Ｒｅｃ１とＲｅｃ４に該当する各条件について、前述同様にしてＭ（Ｃ）の値を求める。そして、その値を基に、優先順位の高い順に条件を並べて、絞り込み条件の表示データを作成する。
【０２４２】
図４８は、今回、検索結果表示部２１７で表示する検索結果表示画面の表示例を示したものである。
【０２４３】
図４９は、検索結果表示画面の他の例を示したものである。図４９に示した検索結果表示画面は、図４５に示した検索結果表示画面に対応するが、異なるのは、領域Ｙ３における検索結果一覧の表示方法である。
【０２４４】
図４９では、検索結果の各文書について、その文書の構造化文書パスと、当該文書の要約情報も表示している。要約情報としては、図４９に示すように、例えば、同じ画面上の領域Ｙ２で表示されている絞り込み条件のうち、優先順位の高い条件に対応するＸＭＬ文書の断片であってもよい。
【０２４５】
すなわち、「ＢＯＯＫ／ＣＡＴＥＧＯＲＹ／ＳＵＢＣＡＴＥＧＯＲＹ」が最も優先順位の高い絞り込み条件であるので、処理対象の各文書中の、この構成要素の周辺データが要約情報として表示されている。このように、ユーザの焦点に合わせて、ユーザが絞り込み条件を選択する手掛かりとなるような情報を各文書に対応付けて表示することもできる。
【０２４６】
以上説明したように、上記実施形態に係る絞り込み検索によれば、少なくとも１つのキーワードを初期条件として入力されたら、ＸＭＬデータベースに格納されている複数の構造化文書の中から、当該キーワードを構成要素の要素値に含む構造化文書を検索し、この検索された複数の構造化文書を処理対象の文書として、当該処理対象の文書のそれぞれの文書構造と構成要素の要素値として包含する語彙を比較することにより、当該処理対象の文書間の違いを抽出し、少なくともこの違いを絞り込み条件の候補として表示し、表示された候補の中から選択された候補を絞り込み条件として用いて、前回検索された構造化文書の中から当該選択された絞り込み条件を満たす構造化文書を検索し、その結果を今回の処理対象の文書として取得する。
【０２４７】
上記手法によれば、予めユーザ側で文書構造や語彙に関する情報を知らなくとも効果的に構造的な条件や語彙的な条件を優先順位付けして提示することで、必要な構造化文書集合を容易に取り出すことができる。
【０２４８】
また、上記実施形態に係る検索支援装置２０１は、ＸＭＬデータベースに格納されている複数の構造化文書の中から、指定された検索条件を満足する構造化文書を検索する構造化文書管理システム１００を用いて、所望の構造化文書を検索するための支援を行うものであって、少なくとも１つのキーワードを初期条件として入力されたら、構造化文書管理システム１００が上記キーワードを構成要素の要素値に含む複数の構造化文書を検索するための検索要求文（以下、クエリ）を作成して、構造化文書管理システム１００に入力し、このクエリに基づき構造化文書管理システム１００で検索された複数の構造化文書を処理対象の文書として取得すると、当該処理対象の文書のそれぞれの文書構造と構成要素の要素値として包含する語彙を比較することにより、絞り込み条件の候補として、少なくとも当該処理対象の文書間の違いを抽出して表示し、この表示された候補の中から選択された候補を絞り込み条件として用いて、前回検索された構造化文書の中から、当該選択された絞り込み条件を満たす構造化文書を検索した結果を、今回の処理対象の文書として取得する。
【０２４９】
上記検索支援装置２０１によれば、予めユーザ側で文書構造や語彙に関する情報を知らなくとも効果的に構造的な条件や語彙的な条件を優先順位付けして提示することで、必要な構造化文書集合を構造化文書管理システム１００から容易に取り出すことができる。
【０２５０】
すなわち、上記実施形態によれば、異なる文書構造の複数の構造化文書を記憶するデータベースであって、各構造化文書の構成要素で構成された階層化された論理構造を有するデータベースから、ユーザは、上記論理構造や各構造化文書の文書構造、どの構成要素にどのような語彙が包含されているかなどを意識せず、単なるキーワードを指定するだで、効率よく所望の構造化文書を検索することができる。特に、呈示された絞り込み条件の中から所望のものを選択するという操作だけで、検索結果として得られた大量の文書の中から、容易に絞り込みが行える。
【０２５１】
上記実施形態では、処理対象の文書から絞り込み条件を抽出する際には、各処理対象の文書を、検索結果が得られる度に、処理対象の文書の文書構造を１段ずつ掘り下げて（展開して）構成要素や語彙を抽出し、構造テーブルを作成する（展開する）。掘り下げる際には、掘り下げる基点としての展開元は、その都度選択する。例えば、構造テーブルに条件として挙げられた構成要素を順番に選択したり、絞り込み条件として選択された構成要素を優先的に選択してもよい。１段掘り下げたところで処理対象の文書間の違いが見つからなければ、さらに１段掘り下げて構成要素や語彙を抽出し構造テーブルを作成する（展開する）。
【０２５２】
なお、上記実施形態では、絞り込み受験が選択されるたびに、検索要求発行部２１２がクエリを生成し、構造化文書管理システム１００へ検索を依頼するようになっているが、この場合に限らず、初期条件に基づく検索結果が得られたら（構造化文書管理システムから送られてきたら）、検索支援装置２０１自身が、この検索結果の文書の中から、選択された絞り込み条件を満足する文書を選択（検索）するようにしてもよい。
【０２５３】
本発明の実施の形態に記載した絞り込み検索手法（図３４〜図３６参照）は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピーディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、半導体メモリなどの記録媒体に格納して頒布することもできる。
【０２５４】
なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。さらに、上記実施形態には種々の段階の発明は含まれており、開示される複数の構成用件における適宜な組み合わせにより、種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題（の少なくとも１つ）が解決でき、発明の効果の欄で述べられている効果（のなくとも１つ）が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【０２５５】
【発明の効果】
以上説明したように、本発明によれば、構造化文書の文書構造を意識することなく、検索結果を絞り込みながら所望の構造化文書を迅速に効率よく検索することができる。
【図面の簡単な説明】
【図１】本発明の実施形態に係る構造化文書管理システムの構成例を示した図。
【図２】図１に示した構造化文書管理システムの一利用形態を示したもので、ＷＷＷのバックエンドで、構造化文書管理システムが動作している場合を示した図。
【図３】ＸＭＬで記述された構造化文書の一例を示した図。
【図４】図３の構造化文書の文書構造を模式的に示した図。
【図５】追加コマンドの機能を説明するための図で、構造化文書データベースの初期状態に追加コマンドを実行した場合について示している。
【図６】図５（ｂ）に示した状態の構造化文書データベースに対し、取得コマンドを実行した場合の処理結果を示した図。
【図７】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して１つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図８】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して３つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図９】要素名生起インデックスの格納例を示した図。
【図１０】データ生起インデックスの格納例を示した図。
【図１１】図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合の実行結果を示した図。
【図１２】ＸＭＬ文書の文書構造を定義するスキーマの一例を示した図。
【図１３】図８に示した状態の構造化文書データベースに、スキーマ格納コマンドを実行して、図１２に示したスキーマを追加格納（設定）した場合を示した図。
【図１４】スキーマが設定されて、スキーマが存在している旨の属性値のセットされた文書オブジェクトツリーを示した図。
【図１５】各オブジェクトファイルに、スキーマが存在している旨の属性値が格納されている様子を概念的に示した図。
【図１６】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１７】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１８】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図１９】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図２０】クエリ（ＸＭＬ文書）の一例を示した図。
【図２１】単純検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図２２】図２１の単純検索のクエリを用いた検索結果（ＸＭＬ文書）を示した図。
【図２３】概念検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図２４】図１の構造化文書管理システムの文書検索処理動作について説明するためのフローチャート。
【図２５】ユーザインタフェースとしての画面の表示例を示した図。
【図２６】文書検索を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図２７】図２６に示した画面上から入力された情報に基づき作成されるクエリを示した図。
【図２８】図１の構造化文書管理システムの文書取得処理動作について説明するためのフローチャート。
【図２９】文書取得コマンドを実行した結果得られた構造化文書の表示例を示した図。
【図３０】文書検索を行うためのユーザインタフェースとしての画面の表示例であって、スキーマの検索処理動作を説明するための図。
【図３１】スキーマ検索のクエリの一例を示した図。
【図３２】スキーマの取得するためのユーザインタフェースとしての画面の表示例を示したもので、取得されたスキーマの表示例を示している。
【図３３】本発明の実施形態に係る検索支援装置の構成例を示した図。
【図３４】図３３の検索支援装置の処理動作を説明するためのフローチャート。
【図３５】図３３の検索支援装置の処理動作を説明するためのフローチャート。
【図３６】絞り込み条件抽出部の処理動作を説明するためのフローチャート。
【図３７】初期条件入力画面の表示例を示した図。
【図３８】検索要求発行部で生成されたクエリの一例を示す図。
【図３９】図３８に示したクエリに基づき構造化文書管理システムで検索した結果得られたＸＭＬ文書の集合のうち、選択された４件の文書の具体例を示した図。
【図４０】絞り込み条件抽出の際に作成される構造テーブルの具体例を示した図。
【図４１】絞り込み条件の表示例を示した図。
【図４２】絞り込み検索の結果得られたＸＭＬ文書について作成された構造テーブルの具体例を示した図。
【図４３】絞り込み条件の表示例を示した図。
【図４４】絞り込み検索の結果得られたＸＭＬ文書について作成された構造テーブルの具体例を示した図。
【図４５】絞り込み条件の表示例を示した図。
【図４６】ユーザにより選択された絞り込み条件を用いて作成されたクエリの具体例を示した図。
【図４７】図４６に示したクエリに基づき検索した結果得られたＸＭＬ文書の具体例を示した図。
【図４８】絞り込み条件の表示例を示した図。
【図４９】絞り込み条件とともに表示される検索結果一覧の他の表示例を示した図。
【符号の説明】
１００…構造化文書管理システム
２０１…検索支援装置
２１１…初期条件入力部
２１２…検索要求発行部
２１３…検索結果取得部
２１４…検索結果サンプリング部
２１５…絞り込み条件抽出部
２１６…選択部
２１７…検索結果表示部
Claims (14)
- 異なる文書構造の複数の構造化文書を記憶するデータベースから、所望の構造化文書を検索するための検索方法であって、
少なくとも１つのキーワードを初期条件として入力されたら、前記データベースから、前記キーワードを構成要素の要素名と要素値とのうちの少なくとも一方に含む複数の構造化文書を検索し、
この検索された複数の構造化文書を処理対象の文書として、当該処理対象の文書のそれぞれの文書構造と構成要素の要素値として包含する語彙とを比較することにより、絞り込み条件の候補として、前記処理対象の文書から、構成要素の要素名と要素値として包含する語彙のうちの少なくとも一方を抽出し、この抽出された候補を表示し、表示された候補の中から選択された候補を絞り込み条件として用いて、前回検索された構造化文書の中から、当該選択された絞り込み条件を満たす構造化文書を検索して、それを前記処理対象の文書として取得することを特徴とする構造化文書検索方法。 - 前記処理対象の文書間の違いとして、構成要素の要素名と要素値として包含する語彙のうちの少なくとも一方を抽出し、この違いを絞り込み条件の候補として表示することを特徴とする請求項１記載の構造化文書検索方法。
- 前記抽出された各候補に対し、検索範囲をより限定することのできる候補ほど優先順位が高くなるように優先順位を求め、この優先順位に従って、当該候補を並べて表示することを特徴とする請求項１記載の構造化文書検索方法。
- 前記検索結果として得られた構造化文書の中から所定数の構造化文書を選択して、この選択された構造化文書を前記処理対象の文書として用いることを特徴とする請求項１記載の構造化文書検索方法。
- 前記優先順位は、期待情報量最大化原理に基づき求めることを特徴とする請求項３記載の構造化文書検索方法。
- 前記処理対象の文書のそれぞれの文書構造と、各処理対象の文書が要素値として包含する語彙を比較するためのテーブルを作成して、このテーブル上の比較項目を前記絞り込み条件の候補として抽出することを特徴とする請求項１記載の構造化文書検索方法。
- 異なる文書構造の複数の構造化文書を記憶するデータベースから、指定された検索条件を満足する構造化文書を検索する検索装置を用いて、所望の構造化文書を検索するための支援を行う検索支援装置であって、
少なくとも１つのキーワードを初期条件として入力されたら、前記検索装置が、前記キーワードを構成要素の要素名と要素値とのうちの少なくとも一方に含む構造化文書を検索するための検索要求文を作成する作成手段と、
前記検索要求文に基づき前記検索装置で検索された構造化文書を処理対象の文書として取得する取得手段と、
前記処理対象の文書のそれぞれの文書構造と構成要素の要素値として包含する語彙とを比較することにより、絞り込み条件の候補として、前記処理対象の文書から、構成要素の要素名と要素値として包含する語彙のうちの少なくとも一方を抽出する抽出手段と、
この前記抽出手段で抽出された絞り込み条件の候補を表示する表示手段と、
この表示手段で表示された候補の中から選択された候補を絞り込み条件として用いて、前回検索された構造化文書の中から検索された、当該選択された絞り込み条件を満たす構造化文書を、前記処理対象の文書として取得する手段と、
を具備したことを特徴とする検索支援装置。 - 前記抽出手段は、前記処理対象の文書間の違いとして、構成要素の要素名と要素値として包含する語彙のうちの少なくとも一方を抽出し、
前記表示手段は、前記前記抽出手段で抽出された違いを絞り込み条件の候補として表示することを特徴とする請求項７記載の検索装置。 - 前記抽出手段で抽出された各候補に対し、検索範囲をより限定することのできる候補ほど優先順位が高くなるように優先順位を求め、前記表示手段は、この優先順位に従って、当該候補を並べて表示することを特徴とする請求項７記載の検索支援装置。
- 前記検索結果として得られた構造化文書の中から所定数の構造化文書を選択して、この選択された構造化文書を前記処理対象の文書として用いることを特徴とする請求項７記載の検索支援装置。
- 前記優先順位は、期待情報量最大化原理に基づき求めることを特徴とする請求項９記載の検索支援装置。
- 前記処理対象の文書のそれぞれの文書構造と、各処理対象の文書が要素値として包含する語彙を比較するためのテーブルを作成して、このテーブル上の比較項目を前記絞り込み条件の候補として抽出することを特徴とする請求項７記載の検索支援装置。
- 異なる文書構造の複数の構造化文書を記憶するデータベースから指定された検索条件を満足する構造化文書を検索する検索装置を用いて、所望の構造化文書を検索するための支援を行う検索支援方法であって、
少なくとも１つのキーワードを初期条件として入力されたら、前記検索装置が、前記キーワードを構成要素の要素名と要素値とのうちの少なくとも一方に含む構造化文書を検索するための検索要求文を作成し、この検索要求文に基づき前記検索装置で検索された構造化文書を処理対象の文書として取得すると、当該処理対象の文書のそれぞれの文書構造と構成要素の要素値として包含する語彙を比較することにより、前記処理対象の文書から、絞り込み条件の候補として、構成要素の要素名と要素値として包含する語彙のうちの少なくとも一方を抽出し、この抽出された候補を表示し、表示された候補の中から選択された候補を絞り込み条件として用いて、前回検索された構造化文書の中から検索された、当該選択された絞り込み条件を満たす構造化文書を前記処理対象の文書として取得することを特徴とする検索支援方法。 - 異なる文書構造の複数の構造化文書を記憶するデータベースから、指定された検索条件を満足する構造化文書を検索する検索装置を用いて、所望の構造化文書を検索するための支援を行う検索支援プログラムであって、
コンピュータに、
少なくとも１つのキーワードを初期条件として入力されたら、前記検索装置が、前記キーワードを構成要素の要素名と要素値とのうちの少なくとも一方に含む構造化文書を検索するための検索要求文を作成するステップと、
前記検索要求文に基づき前記検索装置で検索された構造化文書を処理対象の文書として取得するステップと、
前記処理対象の文書のそれぞれの文書構造と構成要素の要素値として包含する語彙を比較することにより、前記処理対象の文書から、絞り込み条件の候補として、構成要素の要素名と要素値として包含する語彙のうちの少なくとも一方を抽出する抽出するステップと、
前記絞り込み条件の候補を表示するステップと、
前記表示された候補の中から選択された候補を絞り込み条件として用いて、前回検索された構造化文書の中から検索された、当該選択された絞り込み条件を満たす構造化文書を前記処理対象の文書として取得するステップと、
を実行させる検索支援プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002281207A JP2004118543A (ja) | 2002-09-26 | 2002-09-26 | 構造化文書検索方法、検索支援方法、検索支援装置および検索支援プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002281207A JP2004118543A (ja) | 2002-09-26 | 2002-09-26 | 構造化文書検索方法、検索支援方法、検索支援装置および検索支援プログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004118543A true JP2004118543A (ja) | 2004-04-15 |
Family
ID=32275713
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002281207A Pending JP2004118543A (ja) | 2002-09-26 | 2002-09-26 | 構造化文書検索方法、検索支援方法、検索支援装置および検索支援プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004118543A (ja) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007328401A (ja) * | 2006-06-06 | 2007-12-20 | Osk:Kk | 一括印刷システム |
| JP2008065543A (ja) * | 2006-09-06 | 2008-03-21 | Toshiba Corp | 構造化文書検索装置及び構造化文書検索方法 |
| JP2008262442A (ja) * | 2007-04-13 | 2008-10-30 | Yahoo Japan Corp | 検索キーデータを表示させる方法及びサーバ |
| WO2011142134A1 (ja) * | 2010-05-14 | 2011-11-17 | 日本電気株式会社 | 情報検索装置、情報検索方法、コンピュータ・プログラムおよびデータ構造 |
| JP2013518318A (ja) * | 2010-01-21 | 2013-05-20 | インディジーン ライフシステムズ プライベート リミテッド | 臨床データマイニング及び分析のためのツール |
-
2002
- 2002-09-26 JP JP2002281207A patent/JP2004118543A/ja active Pending
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007328401A (ja) * | 2006-06-06 | 2007-12-20 | Osk:Kk | 一括印刷システム |
| JP4547356B2 (ja) * | 2006-06-06 | 2010-09-22 | 株式会社Ｏｓｋ | 一括印刷システム |
| JP2008065543A (ja) * | 2006-09-06 | 2008-03-21 | Toshiba Corp | 構造化文書検索装置及び構造化文書検索方法 |
| JP2008262442A (ja) * | 2007-04-13 | 2008-10-30 | Yahoo Japan Corp | 検索キーデータを表示させる方法及びサーバ |
| JP2013518318A (ja) * | 2010-01-21 | 2013-05-20 | インディジーン ライフシステムズ プライベート リミテッド | 臨床データマイニング及び分析のためのツール |
| WO2011142134A1 (ja) * | 2010-05-14 | 2011-11-17 | 日本電気株式会社 | 情報検索装置、情報検索方法、コンピュータ・プログラムおよびデータ構造 |
| JP4947245B2 (ja) * | 2010-05-14 | 2012-06-06 | 日本電気株式会社 | 情報検索装置、情報検索方法、コンピュータ・プログラムおよびデータ構造 |
| US9141727B2 (en) | 2010-05-14 | 2015-09-22 | Nec Corporation | Information search device, information search method, computer program, and data structure |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3842573B2 (ja) | 構造化文書検索方法、構造化文書管理装置及びプログラム | |
| JP3842577B2 (ja) | 構造化文書検索方法および構造化文書検索装置およびプログラム | |
| US7739257B2 (en) | Search engine | |
| US20070078889A1 (en) | Method and system for automated knowledge extraction and organization | |
| JP2005190163A (ja) | 構造化データ検索方法、構造化データ検索装置およびプログラム | |
| JP2000020537A (ja) | テキスト検索装置及びテキスト検索プログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| JP3914081B2 (ja) | アクセス権限設定方法および構造化文書管理システム | |
| JP3842572B2 (ja) | 構造化文書管理方法および構造化文書管理装置およびプログラム | |
| JP4439497B2 (ja) | 検索処理装置及びプログラム | |
| JP2004118543A (ja) | 構造化文書検索方法、検索支援方法、検索支援装置および検索支援プログラム | |
| JP2003196294A (ja) | 知識分析システムおよび知識分析方法 | |
| JP3842576B2 (ja) | 構造化文書編集方法及び構造化文書編集システム | |
| Yu et al. | Metadata management system: design and implementation | |
| JP3842574B2 (ja) | 情報抽出方法および構造化文書管理装置およびプログラム | |
| JP3842575B2 (ja) | 構造化文書検索方法、構造化文書管理装置及びプログラム | |
| JP2003288332A (ja) | 構造化文書作成支援方法及び構造化文書作成支援システム | |
| JP3910901B2 (ja) | 文書構造検索方法、文書構造検索装置および文書構造検索プログラム | |
| JP2003288365A (ja) | 付加情報管理方法及び付加情報管理システム | |
| Hong et al. | Extracting Web query interfaces based on form structures and semantic similarity | |
| Marin-Castro et al. | VR-Tree: A novel tree-based approach for modeling Web Query Interfaces | |
| AU2010212480B2 (en) | Improved search engine | |
| AU2012200686B2 (en) | Improved search engine | |
| JP2012194950A (ja) | 構造化文書管理装置、方法およびプログラム | |
| JPH10293764A (ja) | 構造化文書データベース検索方法、構造化文書データベース検索システム及び記録媒体 | |
| Palmer | CSE 400 Professor: Camillo J. Taylor Advisor: Pat Palmer April 11, 2005 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060704 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20061128 |