(57)【特許請求の範囲】
【請求項１】
入力手段と処理手段および記憶手段を備え、前記処理手段がプログラムを実行して、前記入力手段が入力した文書の前記記憶手段への登録を行うコンピュータ装置からなる文書登録システムの構造化文書の登録方法であって、
前記処理手段は、前記入力手段が入力した文書の登録を行う処理の過程で、
各登録対象文書の持つ論理構造を順次重ね合わせ、文書中における出現位置および種別が同一である構造要素群を単一のメタノードによって代表させた構造インデックスを作成し、該構造インデックスの木構造を構成する各メタノードに、該メタノードを一意に識別する文脈識別子を与える構造インデックス作成ステップを有し、
該ステップにおいて、
二つの登録対象文書の持つ木構造を重ね合わせる際に、
両文書の木構造を構成する二つのノードを比較したときに、両ノードが共に木構造の根であれば両ノードは互いに対応していると見なし、
両ノードが根でない場合には、両ノードの上位ノードが互いに対応し、かつ両ノードの種別が一致し、かつ種別の等しい兄弟ノードの並びの先頭から正順に数えた出現順序が等しい場合に両ノードは対応していると見なし、対応している両ノードを単一のメタノードによって代表するように前記構造インデックスを構築し、
該構築した構造インデックスを前記記憶手段に格納することを特徴とした構造化文書の登録方法。
【請求項２】
入力手段と処理手段および記憶手段を備え、前記処理手段がプログラムを実行して、前記入力手段が入力した文書の前記記憶手段への登録を行うコンピュータ装置からなる文書登録システムの構造化文書の登録方法であって、
前記処理手段は、前記入力手段が入力した文書の登録を行う処理の過程で、
各登録対象文書の持つ論理構造を順次重ね合わせ、文書中における出現位置および種別が同一である構造要素群を単一のメタノードによって代表させた構造インデックスを作成し、該構造インデックスの木構造を構成する各メタノードに、該メタノードを一意に識別する文脈識別子を与える構造インデックス作成ステップを有し、
該ステップにおいて、
二つの登録対象文書の持つ木構造を重ね合わせる際に、
両文書の木構造を構成する二つのノードを比較したときに、両ノードが共に木構造の根であれば両ノードは互いに対応していると見なし、
両ノードが根でない場合には、両ノードの上位ノードが互いに対応し、かつ両ノードの種別が一致し、かつ種別の等しい兄弟ノードの並びの末尾から逆順に数えた出現順序が等しい場合に両ノードは対応していると見なし、
対応している両ノードを単一のメタノードによって代表するように前記構造インデックスを構築し、
該構築した構造インデックスを前記記憶手段に格納することを特徴とした構造化文書の登録方法。
【請求項３】
入力手段と処理手段および記憶手段を備え、前記処理手段がプログラムを実行して、前記入力手段が入力した文書の前記記憶手段への登録を行うコンピュータ装置からなる文書登録システムの構造化文書の登録方法であって、
前記処理手段は、前記入力手段が入力した文書の登録を行う処理の過程で、
各登録対象文書の持つ論理構造を順次重ね合わせ、文書中における出現位置および種別が同一である構造要素群を単一のメタノードによって代表させた構造インデックスを作成し、該構造インデックスの木構造を構成する各メタノードに、該メタノードを一意に識別する文脈識別子を与える構造インデックス作成ステップを有し、
該ステップにおいて、
二つの登録対象文書の持つ木構造を重ね合わせる際に、
両文書の木構造を構成する二つのノードを比較したときに、両ノードが共に木構造の根であれば両ノードは互いに対応していると見なし、
両ノードが根でない場合には、両ノードの上位ノードが互いに対応し、かつ両ノードの種別が一致し、かつ種別の等しい兄弟ノードの並び中において、両ノードが共に該並びの先頭位置にあるか、または両ノードが共に先頭以外の位置にある場合に、両ノードは対応していると見なし、
対応している両ノードを単一のメタノードによって代表するように前記構造インデックスを構築し、
該構築した構造インデックスを前記記憶手段に格納することを特徴とした構造化文書の登録方法。
【請求項４】
入力手段と処理手段および記憶手段を備え、前記処理手段がプログラムを実行して、前記入力手段が入力した文書の前記記憶手段への登録を行うコンピュータ装置からなる文書登録システムの構造化文書の登録方法であって、
前記処理手段は、前記入力手段が入力した文書の登録を行う処理の過程で、
各登録対象文書の持つ論理構造を順次重ね合わせ、文書中における出現位置および種別が同一である構造要素群を単一のメタノードによって代表させた構造インデックスを作成し、該構造インデックスの木構造を構成する各メタノードに、該メタノードを一意に識別する文脈識別子を与える構造インデックス作成ステップを有し、
該ステップにおいて、
二つの登録対象文書の持つ木構造を重ね合わせる際に、
両文書の木構造を構成する二つのノードを比較したときに、両ノードが共に木構造の根であれば両ノードは互いに対応していると見なし、
両ノードが根でない場合には、両ノードの上位ノードが互いに対応し、かつ両ノードの種別が一致し、かつ種別の等しい兄弟ノードの並び中において、両ノードが共に該並びの末尾位置にあるか、または両ノードが共に末尾以外の位置にある場合に、両ノードは対応していると見なし、
対応している両ノードを単一のメタノードによって代表するように前記構造インデックスを構築し、
該構築した構造インデックスを前記記憶手段に格納することを特徴とした構造化文書の登録方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンピュータ装置を用いた文書検索システムや文書管理システム等における文書登録方法および文書検索方法に係わり、特に、各文書がそれぞれ論理的な構造を備えている構造化文書の集合を対象として、特定の文書内容の検索を高速に行うことのできるようにした構造化文書の登録方法，検索方法、およびそれに用いられる可搬型媒体に関する。
【０００２】
【従来の技術】
情報化社会の本格的な進展に伴い、ワードプロセッサ、パーソナルコンピュータ等を用いて作成された電子化文書情報が爆発的な勢いで増加しつつある。このような状況下において、蓄積された膨大な電子化文書群の中から、必要とする情報を含んだ文書を高速かつ確実に検索したいという要求が高まっている。
このような要求に応える技術として全文検索がある。全文検索では登録対象文書中のテキスト全体を計算機システムに投入してデータベース化し、該データベース上で指定文字列（以後、検索タームと呼ぶ）を直接検索するので、キーワードを必要とせず、原理的に検出漏れのない検索が可能となる。
【０００３】
また、例えばＳＧＭＬ（ISO 8879:1986, Ｓtandard Ｇeneralized Ｍarkup Ｌanguage）で記述された文書など、文書を構成する個々の論理的な構造要素が識別できる文書（以下、構造化文書と呼ぶ）を対象として、論理構造に関する条件を検索条件中に付加した検索（以下、構造指定検索と呼ぶ）を行うことにより、精度の高い検索を実現することができる。
構造指定検索を可能にする方式としては、例えば特開平８−１４７３１１号公報に示す発明（以下、公知例１と呼ぶ）で提案した検索方法がある。以下、公知例１の概要について説明する。
公知例１の構造化文書検索方法は、文書を登録する際、まず登録文書をそのまま本文として検索用データベースに登録する。
【０００４】
次に、登録した本文について各論理構造の先頭を表わす特定の文字列（これを公知例１では前方マーカと呼ぶ）および末尾を表わす特定の文字列（これを公知例１では後方マーカと呼ぶ）を検出することにより論理構造の識別処理を行うとともに、本文を論理構造ごとに分割する処理を行う。例えば、電子出願特許明細書の場合には、論理構造「要約」の範囲を示す前方マーカとして“<SD0 ABJ>”を、後方マーカとして“</SD0>”を検出し、これらによって囲まれるテキストを「要約」に対応する本文として切り出す。他の論理構造についても同様な切り出しを行い、本文を論理構造ごとに分割する。
【０００５】
次に、分割された各論理構造に対応する本文について、それぞれ凝縮本文の作成処理を行う。すなわち、「要約」については「要約」に関する本文テキストを単語単位に部分文字列に分割し、分割した部分文字列間で相互に包含関係を調べ、他の部分文字列に含まれる文字列を排除することにより「要約」に関する凝縮本文を作成する。他の論理構造についても同様な処理を行うことにより論理構造別の凝縮本文を作成し、これを凝縮本文ファイルとして検索用データベースに登録する。
【０００６】
次に、本文中に現れた文字の文字コードに対応するビットに‘１’を設定することにより文字成分表を作成し、これを検索用データベースに文字成分表ファイルとして登録する。
このようにして検索用データベースを構築した後、公知例１では次のようにして文書検索処理を行う。
はじめに、指定された検索タームを文字単位に分解し、検索タームを構成するすべての文字がともに含まれる文書を上記文字成分表を参照して抽出する。
【０００７】
次に、各論理構造に対応する凝縮本文ファイルのうち、検索対象として指定された論理構造に関する凝縮本文ファイルをサーチ対象として選択するとともに、その中で文字成分表サーチによって抽出された文書の凝縮本文だけを対象としてサーチすることにより、指定された論理構造中に指定された検索タームが含まれている文書を抽出する。指定された検索条件式に複数の検索ターム間の本文中での位置関係が指定されていない場合にはここで検索処理を終了する。他方、そのような位置関係が指定されている場合には凝縮本文サーチの結果抽出された文書に対応する本文の内容を読み、指定された検索タームがすべて含まれ、かつ検索ターム間の位置関係について、指定された条件が満たされるもののみを抽出する。
このようにして、公知例１の方法によれば、大規模なテキストデータベースに対する実用的な検索速度を保ち、かつ構造指定検索を可能にすることができる。
【０００８】
【発明が解決しようとする課題】
前記公知例１に示す従来技術によって、一定の構造指定検索が可能となる。しかし、公知例１による構造指定検索では意図した構造条件に従った検索ができない場合がある。
公知例１の方式では、登録対象文書の持つ構造を予め定めておいたいくつかの部分構造に切り分け、各部分構造ごとに凝縮本文ファイルを作成し、検索時には、部分構造の構造名と凝縮本文ファイルとの対応を定義したテーブルを参照して検索対象とすべき凝縮本文ファイルの集合を決定し、該集合中に含まれる凝縮本文ファイルだけを対象として検索を行うことにより構造指定検索を実現する。
【０００９】
この方式では、テキストデータベースを構築する段階で、将来どのような構造条件を指定した検索が行われるかを想定し、そのような条件に対応した検索が可能となるように凝縮本文ファイルの切り分けを行うので、データベース構築時に想定していなかった構造条件を指定した検索は不可能となる。
例えば、文書が“要約”と“本体”の二つの論理要素（以下、要素と呼ぶ）から構成され、“本体”はさらに任意個数の“節”の繰り返しからなり、各“節”は１個の“節題”と任意個数の“段落”からなる場合を考える。このような構造を持つ文書群からなるテキストデータベースを構築する際に、凝縮本文ファイルを“要約”に対応するものと“本体”に対応するものの二つに分けて作成したとすると、「節題中に文字列○○を含む文書群を求める」という条件を満たす構造指定検索は不可能となってしまう。
【００１０】
もちろん、“本体”全体で１個の凝縮本文ファイルとする代わりに、これをさらに“節題”と“段落”とに分けて凝縮本文ファイルを作成しておけばこの条件に対応することはできる。しかし、仮にこのようにファイルを構成しても、例えば「最初の節の内部（節題または段落中）に文字列○○を含む文書群を求める」、あるいは「節中で最後の段落に文字列××を含む文書群を求める」というような構造条件には対応できない。このような順位指定付きの構造条件に対応しようとすると、予め節および段落の出現順位ごとに別々に凝縮本文ファイルを用意しておくことが必要となるが、節および節内の段落はそれぞれ任意個数出現しうるため凝縮本文ファイルの数が極めて多数となるだけでなく、公知例１は出現順位に関する任意の指定を含んだ構造条件から細分化された凝縮本文ファイルの集合への対応付けを行う手段を備えていないので、実際にはこのような条件を満たす検索は不可能となる。
このように、前記従来技術では、文書中に現れた論理要素の出現位置に関する条件を構造条件指定中に含めることができないため、精度の高い構造指定検索ができないという問題があった。
本発明の目的は、前記従来技術の持つ上記問題点を解決し、高精度でかつ効率のよい構造指定検索を行う機能を提供することにある。
【００１１】
【課題を解決するための手段】
上記課題を解決するため、本発明による文書登録および検索方法は、以下に示すステップを備える。
すなわち、本発明による文書登録方法において、文書の登録処理は、
（１）登録対象文書の持つ論理構造を解析して解析済み文書データを生成し、これを文書データベースに登録する解析済み文書データ生成登録ステップと、
（２）各登録対象文書の持つ論理構造を、登録順に従って順次重ね合わせ、文書中における出現位置および種別が同じである要素群は単一のメタ要素によって代表させ、文書中における出現位置が同じである文字列データ群は単一のメタ文字列データによって代表させることにより、メタ要素群およびメタ文字列データ群（以下、これらを総称してメタノードと呼ぶ）の木構造から構成される構造インデックスを生成し、該構造インデックスを構成するすべてのメタノードに対して、それらを構造インデックス中で一意に識別する識別子である文脈識別子を与える構造インデックス生成ステップと、
（３）各登録対象文書について、その文書に対応する解析済み文書データ中に含まれるすべての文字列データと、その文字列データを構造インデックス中で代表するメタ文字列データの文脈識別子との対応関係の定義から構成される構造化全文データを生成する構造化全文データ生成ステップと、
（４）各登録対象文書に対応する構造化全文データから、所定の部分文字列と、該部分文字列の前記登録対象文書中における文字位置情報と、前記登録対象文書を文書データベース中で一意に識別する文書識別子と、前記部分文字列を含む文字列データを構造インデックス中で代表するメタ文字列データの文脈識別子とを抽出し、前記文字位置情報および前記文書識別子および前記文脈識別子からなる構造化文字位置情報を生成し、前記部分文字列と前記構造化文字位置情報との対応関係を登録して文字列インデックスを更新する文字列インデックス更新ステップを有する。
【００１２】
また、本発明による文書検索方法において、登録済み文書の検索処理は、
（１）前記構造インデックスを参照し、指定された構造条件を満たす文脈識別子の集合を決定する構造条件判定ステップと、
（２）検索タームから所定の部分文字列を抽出し、前記文字列インデックスを参照して該部分文字列に対応する構造化文字位置情報の集合を抽出する構造化文字位置情報抽出ステップと、
（３）前記構造化文字位置情報の集合中から、前記構造条件判定ステップで決定した集合中に含まれる文脈識別子をもち、かつ前記検索ターム上における部分文字列の並びと同じ位置関係を持つ構造化文字位置情報を抽出するインデックス検索ステップ
を有する。
【００１３】
【発明の実施の形態】
（第一の実施例）
以下、本発明を適用した第一の実施例について、図面を用いて説明する。
はじめに、本実施例のシステム構成について説明する。
図１は、本発明による文書検索システムの第一の実施例の全体構成を示す図である。図１に示すとおり、本発明による文書検索システムの第一の実施例は、文書登録サブシステム１０１、文書検索サーバ１０２、文書検索クライアント１０３および１０４、ネットワーク１０５から構成される。
【００１４】
文書登録サブシステム１０１は、検索対象として入力される各文書の構造を解析し、検索時に必要となるインデックスデータを作成する。このインデックスデータは、ネットワーク１０５を介して文書検索サーバ１０２に転送され、後に文書検索サーバ１０２が構造検索処理を行う際に用いられる。
文書検索サーバ１０２は、検索クライアント１０３および１０４からの検索コマンドを受け取り、文書登録サブシステム１０１が作成したインデックスデータを用いて該検索コマンドの指定する条件に適合する文書内容の検索を行い、検索結果データを要求元の検索クライアントに送り返す。
【００１５】
検索クライアント１０３および１０４は、ユーザが対話的に検索条件を指定するための画面をディスプレイ上に表示し、この画面上でユーザが指定した検索条件を、文書検索サーバ１０２によって解釈可能な検索コマンドの形に変換し、この検索コマンドをネットワーク１０５を介して文書検索サーバ１０２に送信する。前記のとおり文書検索サーバ１０２が検索コマンドに対応する検索処理を行い、検索結果データを送り返して来ると、検索クライアント１０２は受け取った検索結果データを画面に表示してユーザに提示する。なお、図１には２台のコンピュータ１０３および１０４を検索クライアントとして使用する構成例を示したが、検索クライアントは１台のみとする構成をとることも、３台以上とする構成をとることもできる。
ネットワーク１０５は、ローカルエリアネットワークおよび／または広域ネットワークであって、文書登録サブシステム１０１、文書検索サーバ１０２、検索クライアント１０３および１０４が各種データやコマンドを交換するために用いられる。
【００１６】
ここで、図１では文書登録サブシステム１０１から文書検索サーバ１０２にインデックスデータを転送するためにネットワーク１０５を使用するものとしたが、代わりにフロッピーディスク、光磁気ディスク、追記型光ディスク等の可搬型媒体を使用する構成をとることもできる。あるいは、文書登録サブシステム１０１と文書検索サーバ１０２を１台のコンピュータ上に実装し、データ転送を行わない構成をとることもできる。
さらに、図１では検索クライアント１０３および１０４と文書検索サーバ１０２には別個のコンピュータを使用するものとしたが、１個以上の検索クライアントを文書検索サーバと同一のコンピュータ上で実行する構成をとることもできる。
【００１７】
以下、本実施例における文書登録サブシステム、すなわち図１の１０１について説明する。
図２は、本実施例における文書登録サブシステム１０１の構成を示す図である。
図２に示す文書登録サブシステム１０１は、ディスプレイ２０１、キーボード２０２、中央処理装置（ＣＰＵ）２０３、フロッピーディスクドライブ２０４、フロッピーディスク２０５、通信制御装置２０６、主メモリ２０７、磁気ディスク装置２０８、システムバス２０９から構成される。
【００１８】
ディスプレイ２０１は、本サブシステムにおける処理の実行状況等を表示するために使用する。キーボード２０２は、文書登録処理の実行等を指示するコマンドを入力するために使用する。中央処理装置２０３は、本サブシステムを構成する各種プログラムを実行する。フロッピーディスクドライブ２０４は、フロッピーディスク２０５に対するデータの読み書きのために使用する。フロッピーディスク２０５は、予め登録対象文書を格納しておき、これを本サブシステムに入力するために使用する。通信制御装置２０６は、ネットワーク１０５を介して前記文書検索サーバ１０２と通信し、リクエストおよびデータの交換を行うために使用する。主メモリ２０７は、本サブシステムによる処理を実行するための各種プログラムおよび一時的なデータを保持するために使用する。磁気ディスク装置２０８は、登録された文書データおよび本サブシステムが生成するインデックスデータを格納するために使用する。システムバス２０９は、これらの各種装置を接続するために使用する。
【００１９】
主メモリ２０７中には、文書構造解析プログラム２１０、構造インデックス作成プログラム２１１、構造化全文データ生成プログラム２１２、文字列インデックス作成プログラム２１３、文書登録制御プログラム２１４およびシステムプログラム２１５が格納され、またワークエリア２１６が保持される。磁気ディスク装置２０８中には、解析済み文書データ格納領域２１７、構造インデックス格納領域２１８、構造化全文データ格納領域２１９および文字列インデックス格納領域２２０が確保される。
【００２０】
文書構造解析プログラム２１０は、ＳＧＭＬを用いて記述され、フロッピーディスク２０５に格納された登録対象文書を読みだし、その論理構造を解析して解析済み文書データを生成し、これを解析済み文書データ格納領域２１７に格納する。構造インデックス作成プログラム２１１は、前記解析済み文書データの持つ論理構造に関する情報を、構造インデックス格納領域２１８に格納されている構造インデックスに登録して構造インデックスを更新する。構造化全文データ生成プログラム２１２は、前記解析済み文書データから前記登録対象文書に関する構造化全文データを生成し、これを構造化全文データ格納領域２１９に格納する。文字列インデックス作成プログラム２１３は、前記構造化全文データから、所定の部分文字列と、該部分文字列の構造化文字位置情報との対応関係を表わすデータを生成し、これを文字列インデックス格納領域２２０に格納されている文字列インデックスに登録して文字列インデックスを更新する。
【００２１】
文書登録制御プログラム２１４は、文書構造解析プログラム２１０、構造インデックス作成プログラム２１１、構造化全文データ生成プログラム２１２および文字列インデックス作成プログラム２１３の起動および実行制御を行うとともに、これらのプログラムによって生成された解析済み文書データ、構造インデックスおよび文字列インデックスをネットワーク１０５を介して前記文書検索サーバ１０２に転送する。システムプログラム２１５は、周辺装置との間のデータの入出力など、コンピュータ上で本サブシステムを構成する各プログラムを実行するための基本機能を提供する。ワークエリア２１６は、プログラムの実行時に一時的に必要となるデータを記憶するために用いられる。
【００２２】
なお、本実施例ではフロッピーディスク２０５に格納された登録対象文書を入力として読み込む構成としたが、光磁気ディスク、追記型光ディスク等、他種の可搬型媒体から読み込む構成をとることもでき、ネットワーク１０５を介して転送されてくる文書を入力とする構成をとることもできる。さらに、本実施例では生成された解析済み文書データ、構造インデックスおよび文字列インデックスを文書検索サーバ１０２に転送するためにネットワーク１０５を使用するものとしたが、代わりにフロッピーディスク、光磁気ディスク、追記型光ディスク等の可搬型媒体を使用する構成をとることもできる。あるいは、文書登録サブシステム１０１と文書検索サーバ１０２を１台のコンピュータ上に実装し、データ転送を行わない構成をとることもできる。
【００２３】
次に、本実施例における文書登録処理の手順について説明する。
図３は、本発明の第一の実施例における文書登録処理の概略手順を示すＰＡＤ（Problem Analysis Diagram）図である。キーボード２０２からの登録指示コマンド等により文書登録制御プログラム２１４が起動されると、本プログラムはまずフロッピーディスク２０５に格納されている登録対象文書の有無とその数を調べ、すべての登録対象文書について、ステップ３０２から３０５までに示す一連の処理を繰り返し実行する（ステップ３０１）。
【００２４】
ステップ３０２では、フロッピーディスク２０５に格納されている登録対象文書群の中から、未処理の登録対象文書を１個選択して読み込む。ステップ３０３では、読み込んだ登録対象文書に文書識別子を割り当てる。文書識別子は、文書データベース中で特定の文書を一意に識別する番号である。
ステップ３０４では、この登録対象文書を入力として文書構造解析プログラム２１０を実行する。ここで、文書構造解析プログラム２１０は、この登録対象文書に対応する解析済み文書データを生成して解析済み文書データ格納領域２１７に格納する。
【００２５】
ステップ３０５では、ステップ３０４で生成した解析済み文書データを入力として構造インデックス作成プログラム２１１を実行する。構造インデックス作成プログラム２１１は、まず構造インデックス格納領域２１７から現時点での構造インデックスを読み出し、与えられた解析済み文書データの持つ構造情報をこの構造インデックスに登録し、更新された構造インデックスを再び構造インデックス格納領域２１８に格納する。
【００２６】
ステップ３０６では、ステップ３０４で生成した解析済み文書データを入力として、構造化全文データ生成プログラム２１２を実行する。構造化全文データ生成プログラム２１２は、与えられた解析済み文書データを参照して、ステップ３０３で読み込んだ登録対象文書に対応する構造化全文データを生成し、構造化全文データ格納領域２１９に格納する。
【００２７】
ステップ３０７では、ステップ３０６で生成した構造化全文データを入力として文字列インデックス作成プログラム２１３を実行する。文字列インデックス作成プログラム２１３は、まず文字列インデックス格納領域２２０から現時点での文字列インデックスを読み出し、構造化全文データから、所定の部分文字列と、該部分文字列の構造化文字位置情報との対応関係を表わすデータを生成してこれを文字列インデックスに登録し、更新された文字列インデックスを再び文字列インデックス格納領域２２０に格納する。
【００２８】
すべての登録対象文書についてステップ３０２から３０７までに示す一連の処理が終了すると、文書登録制御プログラム２１４はステップ３０８を実行して処理を終了する。ステップ３０８では、解析済み文書データ格納領域２１７に格納されたすべての解析済み文書データ、構造インデックス格納領域２１８に格納された構造インデックス、および文字列インデックス格納領域２２０に格納された文字列インデックスを、ネットワーク１０５を介して文書検索サーバ１０２に転送する。
【００２９】
次に、図３におけるステップ３０４の詳細、すなわち本実施例における文書構造解析プログラム２１０の処理手順について説明する。
ここで、文書構造解析プログラム２１０は、ＳＧＭＬを用いて記述された１個の登録対象文書を対象として構造解析処理を行う。ＳＧＭＬでは、特定の種別に属する文書群に共通する論理構造を、ＤＴＤ（Document Type Definition）によって定義する。図４がＤＴＤの一例である。ＤＴＤは、文書を構成する論理要素（以下、これを単に「要素」と呼ぶ）の集合を定義することによって、文書の論理的構造を定義する。図４において、文字列“<!ELEMENT”と文字列“>”で囲まれた部分を要素型宣言と呼び、１個の要素型宣言が、１種類の要素型に属する要素群が共通して持つ名前（これを要素型名と呼ぶ）とその構造を規定する。要素型宣言中の左側に示されている文字列が要素型名、右側に示されている部分がその内容がとる構造の定義である。
【００３０】
図４に示すＤＴＤにおいて、要素型“論文”に関する要素型宣言は、この要素型に属する要素の内容が、“タイトル”、“執筆者”、“日付”、“本文”および“文献リスト”という要素型に属する要素１個ずつを、この順序に従って並べた構造を持つことを規定している。ここで、複数の要素型名を文字“,”で区切って並べることにより、それらの要素型名に属する要素が指定した順序で出現しなければならないことを表現する。
【００３１】
要素型“執筆者”に関する要素型宣言は、この要素型に属する要素の内容が、要素型“名前”に属する要素の１個以上の繰り返しからなる構造を持つことを規定している。ここで、要素型名の後ろに文字“+”を付加することにより、その要素型名に属する要素が１個以上出現することを表現する。
要素型“本文”に関する要素型宣言は、この要素型に属する要素の内容が、要素型“章”に属する要素の０個以上の繰り返しからなる構造を持つことを規定している。ここで、要素型名の後ろに文字“*”を付加することにより、その要素型名に属する要素が０個以上出現することを表現する。
【００３２】
要素型“章”に関する要素型宣言は、この要素型に属する要素の内容が、要素型“章題”に属する要素１個の後ろに、要素型“段落”または“備考”に属する要素を０個以上続け、さらにその後ろに要素型“節”に属する要素を０個以上繰り返した構造を持つことを規定している。ここで、複数の要素型名を文字“|”で区切って並べることにより、それらのいずれかの要素型に属する要素が出現することを表現する。
要素型“節”に関する要素型宣言は、この要素型に属する要素の内容が、要素型“節題”に属する要素１個の後ろに、要素型“段落”または“備考”に属する要素を０個以上続け、さらにその後ろに要素型“項”に属する要素を０個以上繰り返した構造を持つことを規定している。
【００３３】
要素型“項”に関する要素型宣言は、この要素型に属する要素の内容が、要素型“項題”に属する要素１個の後ろに、要素型“段落”または“備考”に属する要素を０個以上繰り返した構造を持つことを規定している。
要素型“文献リスト”に関する要素型宣言は、この要素型に属する要素の内容が、要素型“文献”に属する要素の１個以上の繰り返しからなる構造を持つことを規定している。
要素型“文献”に関する要素型宣言は、この要素型に属する要素の内容が、“タイトル”、“執筆者”、“日付”および“出典”という要素型に属する要素１個ずつを、この順序に並べた構造を持つことを規定している。
【００３４】
また、要素型“タイトル”、“名前”、“日付”、“章題”、“節題”、“項題”、“強調”および“出典”に属する要素の内容は、単に“#PCDATA”と規定されている。これは、これらの要素がそれ以上の下位構造をもたず、単なる文字の列からなる内容を持つことを規定している。要素型“段落”および“備考”に関する要素型宣言は、これらの要素型に属する要素が、要素型“強調”に属する要素または単なる文字列を０個以上繰り返した構造を持つことを規定している。
【００３５】
ＤＴＤ中において、文字列“<!ATTLIST”と文字列“>”で囲まれた部分を属性リスト宣言と呼び、１個の属性リスト宣言が、１種類の要素型に属する要素群が共通して持つ属性を定義する。図４に示すＤＴＤでは、要素型“備考”に属する要素が、属性“type”を持つこと、この属性は“参照”または“注釈”のいずれかを値としてとることができ、指定が省略された場合には“参考”が値として与えられることを規定している。
【００３６】
図４に示すＤＴＤに従って記述されたＳＧＭＬ文書の一例を、図５に示す。文書先頭の、文字列“<!DOCTYPE”と文字列“>”で囲まれた部分を文書型宣言と呼び、そのＳＧＭＬ文書が従うＤＴＤと、最上位要素の要素型名を宣言する。図５に示した例では、この文書がファイル“ronbun.dtd”に格納されているＤＴＤに従い、最上位要素の要素型名は“論文”であることが規定されている。ここでは、ファイル“ronbun.dtd”に図４に示した前記ＤＴＤが格納されているものとする。
【００３７】
図５に示すとおり、ＳＧＭＬでは文書を構成する個々の要素について、その先頭位置と末尾位置を示すマークを付加することにより、文書構造を明示的に記述する。各要素の先頭位置を示すマークを“開始タグ”、終了位置を示すマークを“終了タグ”と呼ぶ。開始タグは、文字列“<”と“>”との間に、その要素の要素型名を記述することによって示す。終了タグは、文字列“</”と“>”との間に、その要素の要素型名を記述することによって示す。要素が属性を持つ場合、属性値の指定を開始タグ中（要素型名の後ろ）に記述することができる。属性値の指定は、属性名と属性値との間に文字列“=”を置くことによって示す。例えば図５において、開始タグ“<備考 type=注釈>”は、要素“備考”の属性“type”に属性値“注釈”を与えている。ＳＧＭＬ文書中において、これらのタグを用いて文書構造を記述している部分を「文書インスタンス」と呼ぶ。
【００３８】
図３におけるステップ３０４の詳細、すなわち本実施例における文書構造解析プログラム２１０の処理手順を示すＰＡＤ図を、図７に示す。
図７に示すとおり、文書構造解析プログラム２１０は、ＳＧＭＬを用いて記述された１個の登録対象文書を入力として起動されると、まず該文書の先頭に記述された文書型宣言を読み、その構文を解析する（ステップ７０１）。次に、ステップ７０２において、文書型宣言中における構文エラーの有無を判定する。構文エラーが検出された場合、ステップ７０３に進み、エラーメッセージを出力して処理を中断する。
【００３９】
文書型宣言に構文エラーがない場合にはステップ７０４に進み、その文書型宣言で指定されているＤＴＤファイルが存在するかどうかを判定する。ＤＴＤファイルが検出されない場合、ステップ７０５に進み、エラーメッセージを出力して処理を中断する。
ＤＴＤファイルが検出された場合にはステップ７０６に進み、該ファイルの内容を読み込んでその構文解析を行う。次に、ステップ７０７において、ＤＴＤ中における構文エラーの有無を判定する。構文エラーが検出された場合、ステップ７０８に進み、エラーメッセージを出力して処理を中断する。構文エラーが検出されなかった場合にはステップ７０９に進み、ＤＴＤが定義する文書構造モデルを記述したデータである文書構造テーブルをメモリ上に生成する。
【００４０】
次に、ステップ７１０において、前記文書構造テーブルを参照しながら文書インスタンスを読み込み、構造解析を行い、その結果として解析済み文書データを生成する。次に、ステップ７１１において、文書インスタンス中に構文エラーや構造エラー（ＤＴＤが定義する構造モデルからの逸脱）がないかどうかを判定する。構文エラーまたは構造エラーが検出された場合にはステップ７１２に進み、エラーメッセージを出力して処理を中断する。エラーが検出されなかった場合にはステップ７１３に進み、前記登録対象文書を識別する文書識別子と、前記ステップ７１０における構造解析によって得られた解析結果データとからなる解析済み文書データを、解析済み文書データ格納領域２１７に出力して処理を終了する。
【００４１】
ここで一例として、図５に示すＳＧＭＬ文書を登録対象文書として文書構造解析プログラム２１０を実行し、該文書が参照するＤＴＤファイル“ronbun.dtd”の内容が図４に示すＤＴＤだった場合について説明する。この場合、ステップ７０９において生成される文書構造テーブルは、図８に示すようなデータ構造をとる。図８に示すとおり、文書構造テーブルは構造定義と属性定義の二つの部分からなる。構造定義は、ＤＴＤを構成する各要素型の要素型名に対応させて、その要素型に属する要素がとりうる内容のデータモデルを定義する。また属性定義は、ＤＴＤを構成する各要素型の要素型名に対応させて、その要素型に属する要素が持つ各属性の属性名、属性値のタイプおよびデフォルト値を定義する。この構造定義を参照することにより、文書インスタンス中に現れる要素群の並び順や階層関係が正しいかどうか（構造エラーの有無）を判断し、また省略されたタグや属性値指定があった場合、それらを補足することができる。
【００４２】
図５に示すＳＧＭＬ文書が登録対象文書として文書構造解析プログラム２１０への入力として与えられ、そのＤＴＤが図４に示すものだった場合、図６に示す木構造データが解析済み文書データとして得られる。図６は、図５に示すＳＧＭＬ記述によって表現されている文書の論理構造を、図形的に示した模式図である。図６に示すように、構造化文書の持つ論理的構造は、個々の要素を中間節、文字列データを終端節とする木構造としてとらえることができる。図６では、各要素を楕円形、文字列データを矩形で表わしている。
【００４３】
なお、本実施例ではＳＧＭＬを用いて記述された構造化文書を登録対象文書として処理する構成をとったが、ＯＤＡ（Open Document Architecture）など、他の形式によって記述された構造化文書を登録対象文書とするように構成することもできる。
【００４４】
図９は、図３におけるステップ３０５の詳細、すなわち本実施例における構造インデックス作成プログラム２１１の処理手順を示すＰＡＤ図である。
構造インデックス作成プログラム２１１は、まずステップ９０１において、既存の構造インデックスが構造インデックス格納領域２１８中に存在しているかどうかを判定する。該領域中に構造インデックスが存在しない場合にはステップ９０２に進み、初期状態（空）の構造インデックスを生成する。既存の構造インデックスを検出した場合にはステップ９０３に進み、該構造インデックスを読み込む。
【００４５】
次に、ステップ９０４において、解析済み文書データ格納領域２１７から登録対象文書の解析済み文書データを読み込む。
次に、ステップ９０５において、前記解析済み文書データの木構造を構成するすべてのノード（要素および文字列データ）を対象として、ステップ９０６からステップ９０９に示す処理を繰り返す。
【００４６】
ステップ９０６では、解析済み文書データ中で現在着目しているノードについて、構造インデックス中に、該ノードに対応するメタノード（メタ要素またはメタ文字列データ）が存在するかどうかを判定する。対応メタノードが存在しない場合はステップ９０７に進み、該ノードに対応するメタノードを生成して構造インデックスに登録し、さらに該登録したメタノードに対して、該メタノードを構造インデックス中で一意に識別する番号である文脈識別子を割り当てる（ステップ９０８）。ステップ９０９では、解析済み文書データ中で現在着目しているノードと、構造インデックス中で該ノードに対応するメタノードを識別する文脈識別子との対応関係を、解析済み文書データに付加して該解析済み文書データを更新する。
【００４７】
ステップ９０５以下の繰り返しを終了するとステップ９１０に進み、前記更新された解析済み文書データを出力して解析済み文書データ格納領域２１７に格納する。次に、ステップ９１１では、前記更新された構造インデックスを出力して構造インデックス格納領域２１８に格納し、処理を終了する。
【００４８】
ここで、前記ステップ９０５において解析済み文書データの木構造を構成するすべてのノードを対象とする繰り返し処理を行う際に、該木構造を辿り、個々のノードを処理していく順序を図１０を用いて説明する。図１０では、楕円形で要素ノード、矩形で文字列ノードを表現し、あるノードが複数の下位ノードを持つ場合には、各下位ノードをその出現順に左から右に並べて表現している。また、各ノードに表示された数字がその処理順序を示している。図１０に示すとおり、ステップ９０５においてノード群を処理していく順序は、木構造の根に位置するノードから出発し、ある特定のノードとその下位ノード群を処理する際には、まず該ノードの処理を行い、次に該ノードの下位ノード群を、その出現順に従って処理していく順序となる。
【００４９】
次に、前記ステップ９０６における処理、すなわち解析済み文書データ中で現在着目しているノードについて、構造インデックス中に、該ノードに対応するメタノードが存在するかどうかを判定する処理の内容を、図１１を用いて説明する。図１１は、図の左側に示す解析済み文書データの木構造を構成するノード群と、右側に示す構造インデックスの木構造を構成するノード（メタノード）群との対応関係を示す図である。
【００５０】
ここで、本実施例では、解析済み文書の木構造中におけるあるノードの木構造アドレスと、構造インデックスの木構造中におけるあるメタノードの木構造アドレスとが等しい場合に、該ノードと該メタノードとは対応するものと定義する。ここでいう木構造アドレスとは、木構造の根から出発して上位ノードから下位ノードへと辿り、特定のノードに至るまでの道筋を、該道筋上に存在する各ノードの種別（要素か文字列データか、要素の場合、どの要素型に属するか）と、それらのノードが種別の等しい兄弟ノード群中で何番目に現れたかを示す番号との組み合わせによって表現するアドレスのことである。
【００５１】
例えば、図１１に示す解析済み文書データ中のノード群のうち、ノード１１０１は上位ノードをもたず、兄弟ノード中では最初の“論文”要素ノードであるから、その木構造アドレスは“/論文[1]”と表記することができる。同様に、ノード１１０２はノード１１０１の下位ノードであり、兄弟ノード中では最初の“章”要素ノードであるから、その木構造アドレスは“/論文[1]/章[1]”と表記することができる。また、ノード１１０３はノード１１０２の下位ノードであり、兄弟ノード中では２番目の“節”要素ノードであるから、その木構造アドレスは“/論文[1]/章[1]/節[2]”と表記することができる。また、ノード１１０４はノード１１０３の下位ノードであり、兄弟ノード中では最初の“段落”要素ノードであるから、その木構造アドレスは“/論文[1]/章[1]/節[2]/段落[1]”と表記することができる。
【００５２】
同様にして、図１１右側の構造インデックスの木構造を構成する各メタノードについてその木構造アドレスを求めてみると、メタノード１１０５の木構造アドレスは“/論文[1]”となり、ノード１１０１の木構造アドレスと等しくなる。同様に、メタノード１１０６の木構造アドレスは“/論文[1]/章[1]”となってノード１１０２の木構造アドレスと等しく、メタノード１１０７の木構造アドレスは“/論文[1]/章[1]/節[2]”となってノード１１０３の木構造アドレスと等しくなる。よって、前記ステップ９０６において、ノード１１０１はメタノード１１０５と、ノード１１０２はメタノード１１０６と、ノード１１０３はメタノード１１０７とそれぞれ対応するものと判定される。
【００５３】
なお、図１１の構造インデックス中にはノード１１０４と等しい木構造アドレスを持つメタノードはないので、ノード１１０４と対応するメタノードは構造インデックス中に存在しないものと判定され、前記ステップ９０７において新たなメタノードが生成され、該メタノードが構造インデックスに登録されることになる。前記ステップ９０７において、あるノードに対応する新たなメタノードを登録する際には、該ノードの上位ノードに対応するメタノードの持つ下位ノード群の末尾に、該ノードに対応する種別のメタノードを追加する。図１１のノード１１０４に対応するメタノードを登録する場合には、ノード１１０４の上位ノードであるノード１１０３に対応するメタノード１１０７の下位に、要素型“段落”のメタノードが追加され、該メタノードは兄弟メタノード群の末尾に置かれることになる。
【００５４】
次に、複数の解析済み文書データを順次重ね合わせることにより構造インデックスを生成していく過程について、図１２を用いて説明する。図１２において、１２０１、１２０３および１２０５は、それぞれ登録対象文書の解析済み文書データを表わしている。これらの解析済み文書データの構造を既存の構造インデックス上に順次重ね合わせることにより、構造インデックスが形成されていく。まず最初に文書１の解析済み文書データ１２０１が入力されると、最初の段階では構造インデックスは初期状態（空）であるため、該解析済みデータと等価な木構造が生成されてそのまま構造インデックスに登録され、構造インデックスは１２０２に示す状態となる。新たに生成されたメタ要素にはＥ１からＥ５までの文脈識別子、新たに生成されたメタ文字列データにはＣ１からＣ３までの文脈識別子が割り当てられる。
【００５５】
次に文書２の解析済み文書データ１２０３が入力されると、既存の構造インデックス（１２０２）と構造が重複する部分については何も行わず、１２０２上に対応する部分がなかった部分構造（図中の斜線部分）だけが新たに登録される。新たに生成されたメタ要素には文脈識別子Ｅ６およびＥ７、新たに生成されたメタ文字列データには文脈識別子Ｃ４が割り当てられる。次に文書３の解析済み文書データ１２０５が入力されると、既存の構造インデックス（１２０４）と構造が重複する部分については何も行わず、１２０４上に対応する部分がなかった部分構造（図中の斜線部分）だけが新たに登録される。新たに生成されたメタ要素には文脈識別子Ｅ８、Ｅ９およびＥ１０、新たに生成されたメタ文字列データには文脈識別子Ｃ５およびＣ６が割り当てられる。このようにして、３個の文書が登録された段階で、構造インデックスは１２０６に示す状態となる。
【００５６】
図１３は、図３におけるステップ３０６の詳細、すなわち本実施例における構造化全文データ生成プログラム２１２の処理手順を示すＰＡＤ図である。
構造化全文データ生成プログラム２１２は、まずステップ１３０１において、解析済み文書データ格納領域２１７から前記登録対象文書の解析済み文書データを読み込む。
【００５７】
次に、ステップ１３０２において、前記登録対象文書を識別する文書識別子を構造化全文データ格納領域２１９に出力する。
次に、ステップ１３０３において、前記解析済み文書データの木構造を構成するすべてのノード（要素ノードおよび文字列データノード）を対象として、ステップ１３０４からステップ１３０６に示す処理を繰り返す。
【００５８】
ステップ１３０４では、解析済み文書データ中で現在着目しているノードについて、該ノードが要素ノードであるか文字列データノードであるかを判定し、該ノードが文字列データノードである場合に限りステップ１３０５に進む。ステップ１３０５では、前記解析済み文書データから、前記現在着目している文字列データノードに対応する文脈識別子を求め、該文脈識別子を構造化全文データ格納領域２１９に出力する。次に、ステップ１３０６で、前記現在着目している文字列データノードの内容文字列を構造化全文データ格納領域２１９に出力する。
ステップ１３０３以下の繰り返しをすべて終了した段階で本プログラムは処理を終了する。
【００５９】
図１４に、構造化全文データ生成プログラム２１２が出力する構造化全文データのファイル形式を示す。図１４は、図５に示したＳＧＭＬ文書を入力として構造化全文データを生成した場合について例示している。図１４に示すとおり、本実施例における構造化全文データのデータファイルは、先頭に文書識別子を記述し、その後ろに、文脈識別子と該文脈識別子に対応する内容文字列との対を、文書中に存在する文字列データの数だけ繰り返した構造をとる。
【００６０】
例えば、図１４に示す構造化全文データに対応する登録対象文書の文書識別子は“D1”であり、図５において“日付”要素の内容として記述されていた文字列データには文脈識別子“C5”が与えられている。なお、図１４他ではこれらの識別子を記号により表現しているが、文書識別子としてデータ中に実際に記録される値は登録対象文書の集合中で特定の文書を一意に識別する番号（整数値）であり、文脈識別子の値は構造インデックスを構成するメタノードの集合中で特定のメタノードを一意に識別する番号（整数値）である。
【００６１】
図１５は、図３におけるステップ３０７の詳細、すなわち本実施例における文字列インデックス作成プログラム２１３の処理手順を示すＰＡＤ図である。
文字列インデックス作成プログラム２１３は、まずステップ１５０１において、既存の文字列インデックスが文字列インデックス格納領域２２０中に存在しているかどうかを判定する。該領域中に文字列インデックスが存在しない場合にはステップ１５０２に進み、初期状態（空）の文字列インデックスを生成する。既存の文字列インデックスを検出した場合にはステップ１５０３に進み、該文字列インデックスを読み込む。
【００６２】
次に、ステップ１５０４において、登録対象文書の構造化全文データを構造化全文データ格納領域２１９から読み込む。
次に、ステップ１５０５において、前記構造化全文データを構成するすべての内容文字列を対象として、ステップ１５０６から１５０７に示す処理を繰り返す。
ステップ１５０６では、構造化全文データ中で現在着目している内容文字列から、所定の部分文字列を抽出する。ステップ１５０７では、前記ステップ１５０６で抽出した各部分文字列と該部分文字列の構造化文字位置情報との対応関係を、前記文字列インデックスに登録する。
ステップ１５０５以下の繰り返しを終了するとステップ１５０８に進み、不要となった構造化全文データを構造化全文データ格納領域２１９から削除して破棄する。次に、ステップ１５０９において、更新された文字列インデックスを出力して文字列インデックス格納領域２２０に格納し、処理を終了する。
【００６３】
ここで、前記ステップ１５０６において、ある内容文字列から所定の部分文字列を抽出する際には、予め抽出すべき部分文字列の長さを定めておき、対象とする内容文字列の先頭から出発して、開始位置を１ずつ増しながら前記予め定めておいた長さの部分文字列を順次抽出する。例えば、抽出する部分文字列の長さを２文字とし、処理対象として図１４に示す内容文字列群のうち文脈識別子Ｃ１２９に対応する内容文字列“変換処理の実例”を用いた場合、抽出される部分文字列は“変換”、“換処”、“処理”、“理の”、“の実”および“実例”の６個となる。
【００６４】
更に、内容文字列の末尾部分については、長さ１文字から部分文字列長−１文字までの各部分文字列をも抽出する。前記の例では“例”が抽出される。これらの部分文字列を前記ステップ１５０７において文字列インデックスに登録する際には、各部分文字列と、それらが出現した位置を表わす構造化文字位置情報との対応関係を登録する。ここで、構造化文字位置情報は、対応する部分文字列を含む文書の文書識別子、該文書中において前記部分文字列を含む文字列データの文書構造中における位置を識別する文脈識別子、および文書中における前記部分文字列の先頭文字位置から構成される。
【００６５】
図１６に、本実施例における文字列インデックスのデータ構造を示す。図１６は、文字列インデックス作成プログラム２１３を用いて図１４に示す構造化全文データを処理し、文字列インデックスに該構造化全文データに含まれる部分文字列群の登録を終えた段階において、該文字列インデックスのデータ構造の一部（前記内容文字列“変換処理の一例”に関連する部分）を図示したものである。ただし、図１６では、前記内容文字列の末尾“例”に対応する文字ノードおよび構造化文字位置情報は省略している。また、前記内容文字列の直前に位置する文字の文字位置を“Ｘ”として、相対的に文字位置を表現している。
【００６６】
図１６に示すとおり、文字列インデックスは、登録対象文書中に現れる所定長さの部分文字列すべてについて、その出現位置情報（文書識別子、文脈識別子および先頭文字位置の組み合わせからなる構造化文字位置情報）のリストを保持する。ここで、インデックス検索を高速化するため、１文字目が共通する部分文字列群については、１文字目の情報をすべての部分文字列が共有するデータ構造をとり、また文字列インデックスのルートから１文字目のノードへのポインタの並びは、ポインタが指す文字の文字コード順となるように配列する。同様に、１文字目のノードから２文字目のノードへのポインタの並びも、ポインタが指す文字の文字コード順となるように配列する。
【００６７】
文書データベースに登録するすべての登録対象文書を処理してその内部に現れる部分文字列群を文字列インデックスに登録しておけば、この文字列インデックスを参照するだけで（文書データ本体を一切走査することなく）任意の２文字からなる文字列がどの文書中のどの位置に出現するかを知ることができる。（2文字以外の長さの文字列を検索する方法については後述する。）
【００６８】
なお、本実施例では、予め定める部分文字列の長さを２文字としたが、該長さをこれ以外の値としても同様な文字列インデックスを構築することができる。また、本実施例では部分文字列の長さを固定長としたが、この長さを可変として同様な文字列インデックスを構築することもできる。
以上が、本実施例における文書登録サブシステム１０１の説明である。
【００６９】
以下、本発明の第一の実施例における文書検索サーバ、すなわち図１の１０２について説明する。
図１７は、本実施例における文書検索サーバ１０２の構成を示す図である。
図１７に示す文書検索サーバ１０２は、ディスプレイ２０１、キーボード２０２、中央処理装置（ＣＰＵ）２０３、通信制御装置２０６、主メモリ２０７、磁気ディスク装置２０８、システムバス２０９から構成される。
【００７０】
ディスプレイ２０１は、本サーバの稼動状況等を表示するために使用する。キーボード２０２は、本サーバの起動・停止等を指示するコマンドを入力するために使用する。中央処理装置２０３は、本サーバを構成する各種プログラムを実行する。通信制御装置２０６は、ネットワーク１０５を介して前記文書登録サブシステム１０１および前記検索クライアント（１０３および１０４）と通信し、リクエストおよびデータの交換を行うために使用する。主メモリ２０７は、本サーバによる処理を実行するための各種プログラムおよび一時的なデータを保持するために使用する。磁気ディスク装置２０８は、文書データベースを構成する文書データ群および本サーバが文書検索時に参照するインデックスデータを格納するために使用する。システムバス２０９は、これらの各種装置を接続するために使用する。
【００７１】
主メモリ２０７中には、検索条件解析プログラム１７０１、文字列インデックス検索プログラム１７０２、文書検索制御プログラム１７０３およびシステムプログラム２１５が格納され、またワークエリア２１６が保持される。磁気ディスク装置２０８中には、解析済み文書データ格納領域２１７、構造インデックス格納領域２１８、文字列インデックス格納領域２２０および検索結果データ格納領域１７０４が確保される。
【００７２】
検索条件解析プログラム１７０１は、検索クライアント１０３および１０４から受信した検索リクエスト中に含まれる検索条件式を解析し、文字列インデックス検索プログラム１７０２によって直接検索可能な条件指定に翻訳する。文字列インデックス検索プログラム１７０２は、検索条件解析プログラム１７０１によって翻訳された条件指定に従って、文字列インデックス格納領域２２０に格納されている文字列インデックスを検索し、得られた検索結果データを検索結果データ格納領域１７０４に格納する。
【００７３】
文書検索制御プログラム１７０３は、検索条件解析プログラム１７０１および文字列インデックス検索プログラム１７０２の起動および実行制御を行うとともに、ネットワーク１０５を介して、文書登録サブシステム１０１および検索クライアント（１０３および１０４）との間でリクエストおよびデータの交換を行う。システムプログラム２１５は、周辺装置との間のデータの入出力など、コンピュータ上で本サーバを構成する各プログラムを実行するための基本機能を提供する。ワークエリア２１６は、プログラムの実行時に一時的に必要となるデータを記憶するために用いられる。
【００７４】
なお、本実施例では文書登録サブシステム１０１および検索クライアント１０３および１０４との間でデータを転送するためにネットワーク１０５を使用するものとしたが、代わりにフロッピーディスク、光磁気ディスク、追記型光ディスク等の可搬型媒体を使用する構成をとることもできる。また、文書登録サブシステム１０１と文書検索サーバ１０２を１台のコンピュータ上に実装し、これらの間でデータ転送を行わない構成をとることもできる。また、１個以上の検索クライアントを文書検索サーバ１０２と同一のコンピュータ上で実行し、これらの間でデータ転送を行わない構成をとることもできる。
【００７５】
図１８は、本発明の第一の実施例における文書検索処理の概略手順を示すＰＡＤ図である。キーボード２０２からのサーバ起動コマンド等により文書検索制御プログラム１７０３が起動されると、本プログラムはサーバとして文書登録サブシステム１０１および検索クライアント（１０３、１０４等）からリクエストを受信してはその処理を行うループに入る（ステップ１８０１）。このループは、キーボード２０２からサーバの停止を指示するコマンドが入力されるまで継続する。
【００７６】
ステップ１８０１のループは、文書登録サブシステム１０１および検索クライアント（１０３および１０４）からリクエストを受信する処理（ステップ１８０２）と、受信したリクエストの種別を判定し、該種別に対応する処理に分岐する処理（ステップ１８０３）を繰り返す。
ステップ１８０３では、受信したリクエストの種別を判定し、該リクエストが、文書登録サブシステム１０１から送信されたデータベース更新リクエスト（新たな文書群を登録して文書データベースを更新することを求めるリクエスト）であった場合、ステップ１８０４およびステップ１８０５からなる処理に分岐する。
【００７７】
また、前記リクエストが、検索クライアント（１０３、１０４等）から送信された文書検索リクエスト（特定の検索条件を満たす文書群の検索を求めるリクエスト）であった場合、ステップ１８０６、１８０７および１８０８からなる処理に分岐する。また、前記リクエストが、検索クライアント（１０３、１０４等）から送信された、検索結果問い合わせリクエスト（特定の検索処理の結果を問い合わせるリクエスト）であった場合、ステップ１８０９からなる処理に分岐する。また、前記リクエストが、検索クライアント（１０３、１０４等）から送信された、文書転送リクエスト（指定された文書データの転送を求めるリクエスト）であった場合、ステップ１８１０からなる処理に分岐する。分岐先の処理が終了した後は再びステップ１８０２に戻ってループを継続する。
【００７８】
ステップ１８０４では、文書登録サブシステム１０１から、新規に登録された文書群の解析済み文書データを受信し、該解析済み文書データを解析済み文書データ格納領域２１６に追加する。次に、ステップ１８０５では、文書登録サブシステム１０１から、新規に登録された前記文書群の内容を反映して更新された構造インデックスおよび文字列インデックスを受信し、これらをそれぞれ構造インデックス格納領域２１８および文字列インデックス格納領域２２０に格納する。
【００７９】
ステップ１８０６では、検索条件解析プログラム１７０１を実行し、文書検索リクエスト中で指定されている検索条件を解析し、該検索条件を、文字列インデックス検索プログラム１７０２によって直接処理可能な条件指定（以下、これを展開済み検索条件データと呼ぶ）に変換する。次に、ステップ１８０７では、前記ステップ１８０６によって生成された展開済み検索条件データを入力として文字列インデックス検索プログラム１７０２を実行し、該展開済み検索条件データが指定する条件を満たす文書群を検索して、検索結果データを求め、該検索結果データを一意に識別する検索結果識別子と対応付けて検索結果データ格納領域１７０４に格納する。次に、ステップ１８０８では、前記検索結果識別子を、要求元の検索クライアントに返送する。
【００８０】
ステップ１８０９では、問い合わせの内容に応じて前記ステップ１８０７で求めた検索結果データの一部または全体を検索結果データ格納領域１７０４から抽出し、要求元の検索クライアントに転送する。
ステップ１８１０では、文書転送リクエスト中で指定されている文書（複数の文書が指定されている場合には指定されている文書すべて）の解析済み文書データを解析済み文書データ格納領域２１７から抽出し、要求元の検索クライアントに転送する。
【００８１】
図１９は、図１８におけるステップ１８０６の詳細、すなわち本実施例における検索条件解析プログラム１７０１の処理手順を示すＰＡＤ図である。
検索条件解析プログラム１７０１は、文書検索リクエスト中で指定されている検索条件を入力として起動されると、まずステップ１９０１において、該検索条件中に構造条件が含まれているかどうかを判定する。そして、構造条件が含まれている場合に限り、ステップ１９０２およびステップ１９０３からなる処理を実行する。構造条件が含まれていなかった場合にはステップ１９０４に進む。
【００８２】
ステップ１９０２では、構造インデックス格納領域２１８から構造インデックスを読み込む。次に、ステップ１９０３では、該構造インデックスを参照して、前記構造条件を満たす構造内に含まれるすべての文字列データの文脈識別子の集合を求める。以下、該集合を文脈識別子集合と呼ぶ。
ステップ１９０４では、前記検索条件中に文字列条件として指定された文字列の長さが、前記文字列インデックスを作成する際に予め定めた部分文字列長を超えているかどうかを判定する。前記指定文字列の長さが前記部分文字列長を超えている場合にはステップ１９０５に進み、前記指定文字列の先頭から、開始文字位置を１ずつ増しつつ、前記部分文字列長に等しい長さの部分文字列群を抽出し、これらの部分文字列を要素とする部分文字列リストを生成する。前記指定文字列の長さが前記部分文字列長を超えていない場合にはステップ１９０６に進み、空の（要素をもたない）部分文字列リストを生成する。
【００８３】
ステップ１９０７では、前記ステップ１９０３で求めた文脈識別子集合、前記検索条件中に含まれていた指定文字列、および前記ステップ１９０５またはステップ１９０６で生成した部分文字列リストから構成される展開済み部分文字列データを生成して処理を終了する。
ここで、図２０は、検索条件解析プログラム１７０１の処理過程における、展開済み解析条件データの生成例を示す図である。
図２０において、２００１は、文書検索リクエスト中で指定された検索条件の一例である。検索条件２００１は、構造条件指定“章/段落[1]”と、文字列条件指定“ガード”とから構成されている。前記検索条件は、“章”要素の直接の下位にある最初の“段落”要素内に、文字列“ガード”が出現するケースを検索すべきことを指定している。
【００８４】
ここで、構造インデックスの内容が２００２に示すとおりであったとすると、前記ステップ１９０３においてこの構造インデックスを参照することにより、前記構造条件指定を満たす“段落”要素の文脈識別子はＥ５およびＥ１４であることがわかる。従って、これらの段落の下位にある文字列データ、すなわち文脈識別子がＣ３またはＣ９である文字列データ内に、文字列“ガード”が出現するケースを検索すればよいことがわかる。ただし、検索に用いる文字列インデックスには、長さ２の部分文字列についてのみその出現位置が登録されているので、３文字からなる前記指定文字列を直接検索することはできない。そこで、ステップ１９０５において、前記指定文字列を分解して長さ２の部分文字列からなるリストを生成する。前記のとおり指定文字列が“ガード”だった場合、抽出される部分文字列は“ガー”および“ード”となる。
【００８５】
この結果、前記ステップ１９０７において、２００３に示す展開済み検索条件データ、すなわち文脈識別子集合が｛Ｃ３，Ｃ９｝、指定文字列が“ガード”、部分文字列リストが｛“ガー”，“ード”｝であるデータが生成される。
【００８６】
図２１は、図１８におけるステップ１８０７の詳細、すなわち本実施例における文字列インデックス検索プログラム１７０２の処理手順を示すＰＡＤ図である。
文字列インデックス検索プログラム１７０２は、前記検索条件解析プログラム１７０１が生成した展開済み検索条件データを入力として起動される。本プログラムは、起動されるとまずステップ２１０１において、文字列インデックス格納領域２２０から文字列インデックスを読み込む。次に、ステップ２１０２に進み、検索結果データを初期化する。
【００８７】
次に、ステップ２１０３では、前記展開済み検索条件データ中に含まれている指定文字列の長さと、前記文字列インデックスを作成する際に予め定めた部分文字列の長さとを比較する。前記指定文字列の長さが前記部分文字列の長さに等しい場合にはステップ２１０４に分岐する。前記指定文字列の長さが前記部分文字列の長さに満たない場合にはステップ２１０５に分岐する。前記指定文字列の長さが前記部分文字列の長さを超える場合にはステップ２１０６に分岐する。
【００８８】
ステップ２１０４では、文字列インデックス中で前記指定文字列を検索し、該文字列に対応している構造化文字位置の集合を求め、次に該集合の中から、前記展開済み検索条件データ中の文脈識別子集合に含まれているいずれかの文脈識別子を持つ構造化文字位置情報群のみを抽出し、該抽出した構造化文字位置情報群からなるヒット位置集合を生成する。
【００８９】
ステップ２１０５では、文字列インデックス中で前記指定文字列を検索し、該文字列の末尾に対応する文字ノードより前方に存在するすべての構造化文字位置情報の集合を求め、次に該集合の中から、前記展開済み検索条件データ中の文脈識別子集合に含まれているいずれかの文脈識別子を持つ構造化文字位置情報群のみを抽出し、該抽出した構造化文字位置情報群からなるヒット位置集合を生成する。
【００９０】
ステップ２１０６では、前記展開済み検索条件データ中の部分文字列リストを構成する各部分文字列について、ステップ２１０７を繰り返す。ステップ２１０７では、文字列インデックス中で前記部分文字列を検索し、該文字列に対応している構造化文字位置情報の集合を求め、次に該集合の中から、前記展開済み検索条件データ中の文脈識別子集合に含まれているいずれかの文脈識別子を持つ構造化文字位置情報群のみを抽出し、該抽出した構造化文字位置情報群を前記部分文字列に対応付けて記憶する。
【００９１】
ステップ２１０６での繰り返しを終了するとステップ２１０８に進み、前記ステップ２１０７で対応付けを行った構造化文字位置情報群について連接判定処理を行い、連続した文字列として前記指定文字列を構成する構造化文字位置情報のグループのみを抽出し、該抽出した各グループ中で前記指定文字列の先頭に位置する部分文字列に対応する構造化文字位置情報のみを抽出し、該抽出した構造化文字位置情報群からなるヒット位置集合を生成する。
【００９２】
ステップ２１０３から分岐したすべての処理を終えるとステップ２１０９に進み、前記ヒット位置集合中に含まれる構造化文字位置情報群を、同一の文書識別子を持つものからなるグループにまとめて前記検索結果データに登録する。
ここで、前記ステップ２１０８、すなわち文字列インデックス検索プログラム１７０２の処理過程における連接判定処理について、図２２を用いてさらに詳しく説明する。
【００９３】
図２２において、２２０１は、文字列インデックスの一例（部分）を表わしている。２２０１に示すデータを保持している文字列インデックス上で、図２０の２００３に示す展開済み検索条件データが示す条件に従って検索を行うと、前記ステップ２１０７に示したとおり、まず部分文字列“ガー”および“ード”に対応する構造化文字位置情報群の中から、文脈識別子がＣ３またはＣ９であるもののみが抽出される。該抽出された構造化文字位置情報群を、部分文字列に対応付けたデータを２２０２に示す。連接判定処理は該データの上で行われる。
【００９４】
前記ステップ２１０８に示す連接判定処理では、抽出された構造化文字位置情報群の中に、全体として前記指定文字列を構成する一連の構造化文字位置情報の組み合わせが存在するかどうかを判定する。ここで、このような組み合わせは次に示す条件を満たさなければならない。
（１）構造化文字位置情報群の間で、文書識別子がすべて一致している。
（２）構造化文字位置情報群の間で、文脈識別子がすべて一致している。
（３）構造化文字位置情報を、その文字位置の値が小さいものから順に並べ、それらの文字位置に従って対応する部分文字列群を配置すると、全体として指定文字列に等しい文字列が得られる。
【００９５】
ここで、２２０２に示す事例には、全体として指定文字列“ガード”を構成する組み合わせが一例含まれている。
上記の条件を満たす構造化文字位置情報の組み合わせが見つかると、該組み合わせ中に含まれる構造化文字位置情報群のうち、文字位置の値が最小であるものを代表として選び、前記ヒット位置集合に登録する。
【００９６】
次に、図２３は、個々の検索処理の結果として生成される検索結果データのデータ構造を示す図である。本図に示すとおり、検索結果データは、ヒット位置集合中に含まれる文字位置情報群を文書識別子ごとにグループ化し、それらのグループを要素とするリストを作り、さらに検出文書の総数を示す情報を付加した構造を持つ。検索結果データは、検索結果データの集合中でその検索結果データを一意に識別する検索結果識別子と対応付けられたうえで、検索結果データ格納領域１７０４に格納される。
【００９７】
次に、図１８におけるステップ１８０９、すなわち検索結果問い合わせリクエストの内容に対応して検索結果を要求元クライアントに転送する処理について、図２４を用いてさらに詳しく説明する。図２４は、前記ステップ１８０９の詳細な処理手順を示すＰＡＤ図である。
ここで、検索結果問い合わせリクエストの本体は、検索結果識別子指定、問い合わせ種別指定および文書識別子指定の三部分からなる。問い合わせの種別によっては、文書識別子指定をもたない場合もある。
【００９８】
図２４に示すとおり、前記ステップ１８０９に対応する処理では、まずステップ２４０１において、問い合わせリクエスト中で指定されている検索結果識別子に対応する検索結果データを検索し、該検索結果データを検索結果データ格納領域１７０４から読み込む。
次に、ステップ２４０２では、問い合わせ種別を判定し、該問い合わせ種別が検出文書数問い合わせであった場合にはステップ２４０３、該問い合わせ種別が文書識別子問い合わせであった場合にはステップ２４０４、該問い合わせ種別が文字位置情報問い合わせであった場合にはステップ２４０５に分岐する。
ステップ２４０３では、前記ステップ２４０１で読み込んだ検索結果データから検出文書数を抽出し、該検出文書数の値を要求元の検索クライアントに転送して処理を終了する。
【００９９】
ステップ２４０４では、前記ステップ２４０１で読み込んだ検索結果データ中に含まれるすべての文書識別子からなる集合を求め、該集合を要求元の検索クライアントに転送して処理を終了する。
ステップ２４０５では、前記ステップ２４０１で読み込んだ検索結果データから、問い合わせ中で指定された文書識別子に対応する構造化文字位置情報のリストを抽出し、該リストを要求元の検索クライアントに転送して処理を終了する。
以上が、本実施例における文書検索サーバ１０２の説明である。
【０１００】
以下、本発明の第一の実施例における文書検索クライアント、すなわち図１の１０３および１０４について説明する。
図２５は、１０３および１０４に共通する、本実施例における文書検索クライアントの構成を示す図である。
図２５に示す文書検索クライアントは、ディスプレイ２０１、キーボード２０２、中央処理装置（ＣＰＵ）２０３、通信制御装置２０６、主メモリ２０７、磁気ディスク装置２０８、システムバス２０９から構成される。
【０１０１】
ディスプレイ２０１は、ユーザが対話的に検索条件を入力するための画面や検索結果等を表示するために使用する。キーボード２０２は、検索条件、検索処理の実行等を指示するコマンドを入力するために使用する。中央処理装置２０３は、本クライアントを構成する各種プログラムを実行する。通信制御装置２０６は、ネットワーク１０５を介して前記文書検索サーバ１０２と通信し、リクエストおよびデータの交換を行うために使用する。主メモリ２０７は、本クライアントによる処理を実行するための各種プログラムおよび一時的なデータを保持するために使用する。磁気ディスク装置２０８は、検索結果として得られた文書およびその他のデータを格納するために使用する。システムバス２０９は、これらの各種装置を接続するために使用する。
【０１０２】
主メモリ２０７中には、検索条件入力プログラム２５０１、検索結果表示プログラム２５０２、クライアント制御プログラム２５０３およびシステムプログラム２１５が格納され、またワークエリア２１６が保持される。磁気ディスク装置２０８中には、解析済み文書データ格納領域２１７および検索結果データ格納領域１７０４が確保される。
【０１０３】
検索条件入力プログラム２５０１は、ユーザと対話しつつ検索条件の入力および解釈を行う。検索結果表示プログラム２５０２は、文書検索サーバ１０２から受け取った検索結果の表示を行う。クライアント制御プログラム２５０３は、検索条件入力プログラム２５０１および検索結果表示プログラム２５０２の起動および実行制御を行うとともに、ネットワーク１０５を介して、文書検索サーバ１０２との間でリクエストおよびデータの交換を行う。システムプログラム２１５は、周辺装置との間のデータの入出力など、コンピュータ上で本クライアントを構成する各プログラムを実行するための基本機能を提供する。ワークエリア２１６は、プログラムの実行時に一時的に必要となるデータを記憶するために用いられる。
【０１０４】
なお、本実施例では文書検索サーバ１０２との間でデータを転送するためにネットワーク１０５を使用するものとしたが、代わりにフロッピーディスク、光磁気ディスク、追記型光ディスク等の可搬型媒体を使用する構成をとることもできる。また、１個以上の検索クライアントを文書検索サーバ１０２と同一のコンピュータ上で実行し、これらの間でデータ転送を行わない構成をとることもできる。本クライアントにプリンタを接続し、検索結果を印刷できるよう構成することもできる。
【０１０５】
図２６は、本発明の第一の実施例における検索クライアントの動作手順を示すＰＡＤ図である。キーボード２０２からのクライアント起動コマンド等によりクライアント制御プログラム２５０３が起動されると、本プログラムはユーザから文書検索を指示するコマンドを受け取ってはその処理を行うループに入る（ステップ２６０１）。このループは、キーボード２０２からクライアントの停止を指示するコマンドが入力されるまで継続する。
ステップ２６０１のループは、ステップ２６０２からステップ２６０５までに示す処理を繰り返す。
【０１０６】
ステップ２６０２では、検索条件入力プログラム２５０１を実行し、ユーザとの対話により検索条件を入力し、該検索条件を、文書検索サーバ１０２が解釈可能な文書検索リクエストに変換する。ステップ２６０３では、前記文書検索リクエストを、ネットワーク１０５を介して文書検索サーバ１０２に送信する。ステップ２６０４では、文書検索サーバ１０２から前記文書検索リクエストへの返送として検索結果識別子が返されるのを待ち、該識別子を受信する。
ステップ２６０５では、前記検索結果識別子を入力として検索結果表示プログラム２５０２を実行し、ユーザと対話しつつ検索結果データの問い合わせおよび画面表示を行う。
【０１０７】
図２７は、前記図２６のステップ２６０２において実行する検索条件入力プログラム２５０１の詳細な処理手順を示すＰＡＤ図である。検索条件入力プログラム２５０１は、クライアント制御プログラム２５０３から起動されると、まず検索条件をユーザが対話的に指定するための画面をディスプレイ２０１に表示する（ステップ２７０１）。
【０１０８】
次に、ステップ２７０２において、前記画面上でユーザが指示した検索条件を読み込む。
次に、ステップ２７０３において、前記ステップ２７０２において読み込んだ検索条件を、文書検索サーバ１０２が直接解釈可能な文書検索リクエストの形に変換する。
【０１０９】
図２８は、前記図２６のステップ２６０５において実行する検索結果表示プログラム２５０２の詳細な処理手順を示すＰＡＤ図である。検索結果表示プログラム２５０２は、クライアント制御プログラム２５０３から前記検索結果識別子を入力として起動されると、ただちにステップ２８０１のループに入る。該ループは、ユーザから検索結果表示の終了を指示されるまで、ステップ２８０２からステップ２８１５までに示す処理を、繰り返し実行する。
前記ステップ２８０１のループ内では、まずステップ２８０２において、検索結果の表示とユーザからの指示入力のために用いる画面をディスプレイ２０１に表示する。次に、ステップ２８０３において、前記画面上でユーザが指定した指示内容を読み込む。
【０１１０】
次に、ステップ２８０４において、前記ユーザ指示の種別を判定し、その種別に対応した分岐を行う。すなわち、該指示が検出文書数の表示を求めるものであった場合にはステップ２８０５およびステップ２８０６に示す処理に分岐し、該指示が検出文書群の文書識別子リストの表示を求めるものであった場合にはステップ２８０７およびステップ２８０８に示す処理に分岐し、該指示が文書内容の表示を求めるものであった場合にはステップ２８０９からステップ２８１５までに示す処理に分岐する。各分岐先の処理が終了するとステップ２８０２に戻り、再び前記ループを再開する。
ここで、ステップ２８０５では、検出文書数を問い合わせるための検出文書数問い合わせリクエストを生成し、該リクエストを文書検索サーバ１０２に送信する。次に、ステップ２８０６では、前記リクエストに対応して文書検索サーバ１０２から転送されてきた検出文書数を受信し、該数値をディスプレイ２０１に表示する。
【０１１１】
ステップ２８０７では、検出文書群の文書識別子リストを問い合わせるための文書識別子問い合わせリクエストを生成し、該リクエストを文書検索サーバ１０２に送信する。次に、ステップ２８０８では、前記リクエストに対応して文書検索サーバ１０２から転送されてきた文書識別子の集合を受信し、該集合に含まれる文書識別子群をディスプレイ２０１にリスト表示する。
【０１１２】
ステップ２８０９では、表示すべき文書を特定する文書識別子を入力する。次に、ステップ２８１０では、該識別子が識別する文書の解析済み文書データを得るための文書転送リクエストを生成し、該リクエストを文書検索サーバ１０２に送信する。次に、ステップ２８１１では、前記リクエストに対応して文書検索サーバ１０２から転送されてきた解析済み文書データを受信し、該データを解析済み文書データ格納領域２１７に格納する。
【０１１３】
次に、ステップ２８１２では、前記解析済み文書データ中において、検索条件中に指定した指定文字列が検出された位置を問い合わせるための文字位置情報問い合わせリクエストを生成し、該リクエストを文書検索サーバ１０２に送信する。次に、ステップ２８１３では、前記リクエストに対応して文書検索サーバ１０２から転送されてきた構造化文字位置情報のリストを受信し、該リストを検索結果データ格納領域１７０４に格納する。
【０１１４】
次に、ステップ２８１４では、前記ステップ２８１１で受信した解析済み文書データおよび前記ステップ２８１３で受信した構造化文字位置情報リストを参照し、文書検索時における指定文字列検出部分を反転表示するためのデータ加工処理を行う。次に、ステップ２８１５では、前記反転処理済みの解析済み文書データを、書式化してディスプレイ２０１上に表示する。
以上が、本発明の第一の実施例における検索クライアント１０３および１０４の動作手順の説明である。
【０１１５】
（第二の実施例）
以下、本発明を適用した第二の実施例について、図面を用いて説明する。
図２９は、本実施例における文書登録サブシステム１０１の構成を示す図である。
図２９に示す文書登録サブシステム１０１は、そのハードウェア構成に関しては、図２に示す第一の実施例の場合と変わらない。ただし、主メモリ２０７中には、第一の実施例において保持するプログラム群に加えて、逆順構造インデックス作成プログラム２９０１を保持する。また、磁気ディスク装置２０８中には、第一の実施例において確保する領域群に加えて、逆順構造インデックス格納領域２９０２が確保される。逆順構造インデックス作成プログラム２９０１は、登録対象文書の解析済み文書データが持つ論理構造に関する情報を、逆順構造インデックス格納領域２９０２に格納されている逆順構造インデックスに登録して逆順構造インデックスを更新する。
【０１１６】
本実施例において、文書登録制御プログラム２１４は、文書構造解析プログラム２１０、構造インデックス作成プログラム２１１、逆順構造インデックス作成プログラム２９０１、構造化全文データ生成プログラム２１２および文字列インデックス作成プログラム２１３の起動および実行制御を行うとともに、これらのプログラムによって生成された解析済み文書データ、構造インデックス、逆順構造インデックスおよび文字列インデックスをネットワーク１０５を介して文書検索サーバ１０２に転送する。
【０１１７】
なお、本実施例ではフロッピーディスク２０５に格納された登録対象文書を入力として読み込む構成としたが、光磁気ディスク、追記型光ディスク等、他種の可搬型媒体から読み込む構成をとることもでき、ネットワーク１０５を介して転送されてくる文書を入力とする構成をとることもできる。さらに、本実施例では生成された解析済み文書データ、構造インデックス、逆順構造インデックスおよび文字列インデックスを文書検索サーバ１０２に転送するためにネットワーク１０５を使用するものとしたが、代わりにフロッピーディスク、光磁気ディスク、追記型光ディスク等の可搬型媒体を使用する構成をとることもできる。あるいは、文書登録サブシステム１０１と文書検索サーバ１０２を１台のコンピュータ上に実装し、データ転送を行わない構成をとることもできる。
【０１１８】
図３０は、本発明の第二の実施例における文書登録処理の概略手順を示すＰＡＤ図である。本図に示す処理手順は、図３に示す第一の実施例における処理手順とほぼ同様であるが、図３におけるステップ３０５の直後にステップ３００１が追加されている点と、ステップ３０８の代わりにステップ３００２を実行する点が異なる。
【０１１９】
ここで、ステップ３００１では、ステップ３０４で生成した解析済み文書データを入力として逆順構造インデックス作成プログラム２９０１を実行する。逆順構造インデックス作成プログラム２９０１は、まず逆順構造インデックス格納領域２９０２から現時点での逆順構造インデックスを読み出し、与えられた解析済み文書データの持つ構造情報をこの逆順構造インデックスに登録し、更新された逆順構造インデックスを再び逆順構造インデックス格納領域２９０２に格納する。
【０１２０】
ステップ３００２では、解析済み文書データ格納領域２１７に格納されたすべての解析済み文書データ、構造インデックス格納領域２１８に格納された構造インデックス、逆順構造インデックス格納領域２９０２に格納された逆順構造インデックス、および文字列インデックス格納領域２２０に格納された文字列インデックスを、ネットワーク１０５を介して文書検索サーバ１０２に転送する。
【０１２１】
図３１は、図３０におけるステップ３００１の詳細、すなわち本実施例における逆順構造インデックス作成プログラム２９０１の処理手順を示すＰＡＤ図である。
逆順構造インデックス作成プログラム２９０１は、まずステップ３１０１において、既存の逆順構造インデックスが逆順構造インデックス格納領域２９０２中に存在しているかどうかを判定する。該領域中に逆順構造インデックスが存在しない場合にはステップ３１０２に進み、初期状態（空）の逆順構造インデックスを生成する。既存の逆順構造インデックスを検出した場合にはステップ３１０３に進み、該逆順構造インデックスを読み込む。
【０１２２】
次に、ステップ３１０４において、登録対象文書の解析済み文書データを読み込む。
次に、ステップ３１０５において、前記解析済み文書データの木構造を構成するすべてのノード（要素および文字列データ）を対象として、ステップ３１０６からステップ３１０９に示す処理を繰り返す。
【０１２３】
ステップ３１０６では、解析済み文書データ中で現在着目しているノードについて、逆順構造インデックス中に、該ノードに対応するメタノード（メタ要素またはメタ文字列データ）が存在するかどうかを判定する。対応メタノードが存在しない場合ステップ３１０７に進み、該ノードに対応するメタノードを生成して逆順構造インデックスに登録し、さらに該登録したメタノードに対して、該メタノードを逆順構造インデックス中で一意に識別する番号である逆順文脈識別子を割り当てる（ステップ３１０８）。
ステップ３１０９では、解析済み文書データ中で現在着目しているノードと、逆順構造インデックス中で該ノードに対応するメタノードを識別する逆順文脈識別子との対応関係を、解析済み文書データに付加して該解析済み文書データを更新する。
【０１２４】
ステップ３１０５以下の繰り返しを終了するとステップ３１１０に進み、前記更新された解析済み文書データを出力して解析済み文書データ格納領域２１７に格納する。次に、ステップ３１１１では、前記更新された逆順構造インデックスを出力して逆順構造インデックス格納領域２９０２に格納し、処理を終了する。
【０１２５】
以上に述べたとおり、逆順構造インデックス作成プログラム２９０１の処理手順は図９に示す構造インデックス作成プログラム２１１の処理手順とほぼ対応している。しかし、ステップ３１０５の繰り返しにおいて解析済み文書の木構造を辿る順序が構造インデックス作成プログラム２１１の場合とは異なっており、その結果構築される逆順構造インデックスの木構造も構造インデックスの木構造とは異なったものとなる。
【０１２６】
ここで、前記ステップ３１０５において解析済み文書データの木構造を構成するすべてのノードを対象とする繰り返しを行う際に、該木構造を辿り、個々のノードを処理していく順序を図３２を用いて説明する。図３２では、楕円形で要素ノード、矩形で文字列ノードを表現し、あるノードが複数の下位ノードを持つ場合には、各下位ノードをその出現順に左から右に並べて表現している。また、各ノードに表示された数字がその処理順序を示している。
【０１２７】
図３２に示すとおり、ステップ３１０５においてノード群を処理していく順序は、木構造の根に位置するノードから出発し、ある特定のノードとその下位ノード群を処理する際には、まず該ノードの処理を行い、次に該ノードの下位ノード群を、その出現順の逆順に従って処理していく順序となる。
【０１２８】
次に、前記ステップ３１０６における処理、すなわち解析済み文書データ中で現在着目しているノードについて、逆順構造インデックス中に、該ノードに対応するメタノードが存在するかどうかを判定する処理について、図３３を用いて説明する。図３３は、図の左側に示す解析済み文書データの木構造を構成するノード群と、右側に示す逆順構造インデックスの木構造を構成するノード（メタノード）群との対応関係を示す図である。
【０１２９】
ここで、本実施例では、解析済み文書の木構造中におけるあるノードの逆順木構造アドレスと、逆順構造インデックスの木構造中におけるあるメタノードの逆順木構造アドレスとが等しい場合に、該ノードと該メタノードとは対応するものと定義する。ここでいう逆順木構造アドレスとは、木構造の根から出発して上位ノードから下位ノードへと辿り、特定のノードに至るまでの道筋を、該道筋上に存在する各ノードの種別（要素か文字列データか、要素の場合、どの要素型に属するか）と、それらのノードが種別の等しい兄弟ノード群中で後ろから何番目に現れたかを示す番号との組み合わせによって表現するアドレスのことである（通常の木構造アドレスと区別するため、逆順木構造アドレスでは前記番号を負の整数として表記する）。
【０１３０】
例えば、図３３に示す解析済み文書データ中のノード群のうち、ノード３３０１は上位ノードをもたず、兄弟ノード中では最後の“論文”要素ノードであるから、その逆順木構造アドレスは“/論文[-1]”と表記することができる。同様に、ノード３３０２はノード３３０１の下位ノードであり、兄弟ノード中では最後の“章”要素ノードであるから、その逆順木構造アドレスは“/論文[-1]/章[-1]”と表記することができる。また、ノード３３０３はノード３３０２の下位ノードであり、兄弟ノード中では後ろから２番目の“節”要素ノードであるから、その逆順木構造アドレスは“/論文[-1]/章[-1]/節[-2]”と表記することができる。また、ノード３３０４はノード３３０３の下位ノードであり、兄弟ノード中では最後の“段落”要素ノードであるから、その逆順木構造アドレスは“/論文[-1]/章[-1]/節[-2]/段落[-1]”と表記することができる。
【０１３１】
同様にして、図３３右側の構造インデックスの木構造を構成する各メタノードについてその逆順木構造アドレスを求めてみると、メタノード３３０５の逆順木構造アドレスは“/論文[-1]”となり、ノード３３０１の逆順木構造アドレスと等しくなる。同様に、メタノード３３０６の逆順木構造アドレスは“/論文[-1]/章[-1]”となってノード３３０２の逆順木構造アドレスと等しく、メタノード３３０７の逆順木構造アドレスは“/論文[-1]/章[-1]/節[-2]”となってノード３３０３の逆順木構造アドレスと等しくなる。よって、前記ステップ３１０６において、ノード３３０１はメタノード３３０５、ノード３３０２はメタノード３３０６、ノード３３０３はメタノード３３０７とそれぞれ対応するものと判定される。なお、図３３の構造インデックス中にはノード３３０４と等しい逆順木構造アドレスを持つメタノードはないので、ノード３３０４と対応すメタノードは逆順構造インデックス中に存在しないものと判定され、前記ステップ３１０７において新たなメタノードが生成され、該メタノードが構造インデックスに登録されることになる。
【０１３２】
前記ステップ３１０７において、あるノードに対応する新たなメタノードを登録する際には、該ノードの上位ノードに対応するメタノードの持つ下位メタノード群の先頭に、該ノードに対応する種別のメタノードを追加する。図３３のノード３３０４に対応するメタノードを登録する場合には、ノード３３０４の上位ノードであるノード３３０３に対応するメタノード３３０７の下位に、要素型“段落”のメタノードが追加され、該メタノードは兄弟メタノード群の先頭に置かれることになる。
【０１３３】
次に、複数の解析済み文書データを順次重ね合わせることにより逆順構造インデックスを生成していく過程について、図３４を用いて説明する。図３４において、３４０１、３４０３および３４０５は、それぞれ登録対象文書の解析済み文書データを表わしている。これらの解析済み文書データの構造を既存の逆順構造インデックス上に順次重ね合わせることにより、逆順構造インデックスが形成されていく。
【０１３４】
まず最初に文書１の解析済み文書データ３４０１が入力されると、最初の段階では逆順構造インデックスは初期状態（空）であるため、該解析済みデータと等価な木構造が生成されてそのまま逆順構造インデックスに登録され、逆順構造インデックスは３４０２に示す状態となる。新たに生成されたメタ要素には−Ｅ１から−Ｅ５までの文脈識別子、新たに生成されたメタ文字列データには−Ｃ１から−Ｃ３までの文脈識別子が割り当てられる。
【０１３５】
次に文書２の解析済み文書データ３４０３が入力されると、既存の逆順構造インデックス（３４０２）と構造が重複する部分については何も行わず、３４０２上に対応する部分がなかった部分構造（図中の斜線部分）だけが新たに登録される。新たに生成されたメタ要素には文脈識別子−Ｅ６および−Ｅ７、新たに生成されたメタ文字列データには文脈識別子−Ｃ４が割り当てられる。
【０１３６】
次に文書３の解析済み文書データ３４０５が入力されると、既存の逆順構造インデックス（３４０４）と構造が重複する部分については何も行わず、３４０４上に対応する部分がなかった部分構造（図中の斜線部分）だけが新たに登録される。新たに生成されたメタ要素には文脈識別子−Ｅ８、−Ｅ９および−Ｅ１０、新たに生成されたメタ文字列データには文脈識別子−Ｃ５および−Ｃ６が割り当てられる。このようにして、３個の文書が登録された段階で、逆順構造インデックスは３４０６に示す状態となる。
【０１３７】
図３５は、図３０におけるステップ３０６の詳細、すなわち本実施例における構造化全文データ生成プログラム２１２の処理手順を示すＰＡＤ図である。図３５に示すとおり、本実施例における構造化全文データ生成プログラム２１２の処理手順は、図１３に示す前記第一の実施例の場合の処理手順とほぼ同一である。ただし、本実施例の場合、図１３におけるステップ１３０５の代わりにステップ３５０１を行う点が異なっている。
ここで、ステップ３５０１では、解析済み文書データから、現在着目している文字列データノードに対応する文脈識別子および逆順文脈識別子を求め、該文脈識別子および該逆順文脈識別子を構造化全文データ格納領域２１９に出力する。
【０１３８】
図３６に、本実施例において構造化全文データ生成プログラム２１２が出力する構造化全文データのファイル形式を示す。図３６は、図５に示したＳＧＭＬ文書を入力として構造化全文データを生成した場合について例示している。図３６に示すとおり、本実施例における構造化全文データのデータファイルは、先頭に文書識別子を記述し、その後ろに、文脈識別子、逆順文脈識別子およびそれらに対応する内容文字列からなる三つ組みを、文書中に存在する文字列データの数だけ繰り返した構造をとる。
【０１３９】
本実施例における文字列インデックスは、前記第一の実施例の場合と同じく、図１５に示す処理手順に従って作成される。図３７に、本実施例における文字列インデックスのデータ構造を示す。図３７は、文字列インデックス作成プログラム２１３を用いて図３６に示す構造化全文データを処理し、文字列インデックスに該構造化全文データに含まれる部分文字列群の登録を終えた段階において、該文字列インデックスのデータ構造の一部（内容文字列“変換処理の一例”に関連する部分）を図示したものである。
【０１４０】
図３７に示すとおり、本実施例における文字列インデックスでは、個々の構造化文字位置情報中に、前記第一の実施例の場合に保持する情報に加えて、逆順文脈識別子をも保持する。ただし、図３７では、前記第一の実施例における図１６と同様、前記内容文字列の末尾“例”に対応する文字ノードおよび構造化文字位置情報は省略している。また、前記内容文字列の直前に位置する文字の文字位置を“Ｘ”として、相対的に文字位置を表現している。
以上が、本実施例における文書登録サブシステム１０１の説明である。
【０１４１】
以下、本発明の第二の実施例における文書検索サーバ、すなわち図１の１０２について説明する。
図３８は、本実施例における文書検索サーバ１０２の構成を示す図である。図３８に示すとおり、本実施例における文書検索サーバ１０２は、前記第一の実施例の場合の構成要素群に加えて、磁気ディスク装置２０８中に、逆順構造インデックス格納領域２９０２を保持する。
【０１４２】
なお、本実施例の場合も、文書登録サブシステム１０１および検索クライアントとの間でデータを転送するためにネットワーク１０５を使用する代わりにフロッピーディスク、光磁気ディスク、追記型光ディスク等の可搬型媒体を使用する構成をとることもできる。また、文書登録サブシステム１０１と文書検索サーバ１０２を１台のコンピュータ上に実装し、これらの間でデータ転送を行わない構成をとることもできる。また、１個以上の検索クライアントを文書検索サーバ１０２と同一のコンピュータ上で実行し、これらの間でデータ転送を行わない構成をとることもできる。
【０１４３】
図３９は、本発明の第二の実施例における文書検索処理の概略手順を示すＰＡＤ図である。図３９に示すとおり、本実施例における文書検索処理の手順は、図１８に示す前記第一の実施例の場合とほぼ同一であるが、前記第一の実施例におけるステップ１８０５の代わりにステップ３９０１を実行する点が異なっている。ステップ３９０１では、文書登録サブシステム１０１から、新規に登録された文書群の内容を反映して更新された構造インデックス、逆順構造インデックスおよび文字列インデックスを受信し、これらをそれぞれ構造インデックス格納領域２１８、逆順構造インデックス格納領域２９０２および文字列インデックス格納領域２２０に格納する。
【０１４４】
図４０は、図３９におけるステップ１８０６の詳細、すなわち本実施例における検索条件解析プログラム１７０１の処理手順を示すＰＡＤ図である。
本実施例の場合、検索条件解析プログラム１７０１は、文書検索リクエスト中で指定されている検索条件を入力として起動されると、まずステップ４００１において、該検索条件中に含まれている構造条件について判定する。ここで、該検索条件中に正順の（すなわち前記第一の実施例におけるものと同様な）構造条件が含まれている場合には、ステップ１９０２およびステップ１９０３からなる処理に分岐する。ここで、ステップ１９０２および１９０３での処理は、前記第一の実施例の場合と同一である。該検索条件中に逆順の構造条件が含まれている場合には、ステップ４００２およびステップ４００３からなる処理に分岐する。該検索条件中に構造条件が含まれていなかった場合には何もせずにステップ１９０４に進む。
【０１４５】
ステップ４００２では、逆順構造インデックス格納領域２９０２から逆順構造インデックスを読み込む。次に、ステップ４００３では、該逆順構造インデックスを参照して、前記構造条件を満たす構造内に含まれるすべての文字列データの逆順文脈識別子の集合を求める。以下、該集合を逆順文脈識別子集合と呼ぶ。
ステップ１９０４およびそこから分岐するステップ１９０５およびステップ１９０６における処理は、前記第一の実施例の場合と同一であり、これらの処理を終了した後、ステップ４００４に進む。
【０１４６】
ステップ４００４では、ステップ１９０３で求めた文脈識別子集合、前記ステップ４００３で求めた逆順文脈識別子集合、前記検索条件中に含まれていた指定文字列、および前記ステップ１９０５またはステップ１０９６で生成した部分文字列リストから構成される展開済み部分文字列データを生成して処理を終了する。
【０１４７】
ここで、図４１は、本実施例での検索条件解析プログラム１７０１の処理過程における、展開済み解析条件データの生成例を示す図である。
図４１において、４１０１は、文書検索リクエスト中で指定された検索条件の一例である。検索条件４１０１は、構造条件指定“章/段落[-1]”と、文字列条件指定“ガード”とから構成されている。前記検索条件は、“章”要素の直接の下位にある最後の“段落”要素内に、文字列“ガード”が出現するケースを検索すべきことを指定している。
【０１４８】
ここで、前記検索条件中で指定されている構造条件は、構造を後ろ側からに辿って条件を指定する逆順の構造条件であるから、逆順構造インデックスの内容が４１０２に示すとおりであったとすると、前記ステップ４００３においてこの構造インデックスを参照することにより、前記構造条件指定を満たす“段落”要素の逆順文脈識別子は−Ｅ３および−Ｅ１２であることがわかる。従って、これらの段落の下位にある文字列データ、すなわち逆順文脈識別子が−Ｃ１または−Ｃ７である文字列データ内に、文字列“ガード”が出現するケースを検索すればよいことがわかる。ただし、検索に用いる文字列インデックスには、長さ２の部分文字列についてのみその出現位置が登録されているので、３文字からなる前記指定文字列を直接検索することはできない。そこで、ステップ１９０５において、前記指定文字列を分解して長さ２の部分文字列からなるリストを生成する。前記のとおり指定文字列が“ガード”だった場合、抽出される部分文字列は“ガー”および“ード”となる。
この結果、前記ステップ４００４において、４１０３に示す展開済み検索条件データ、すなわち文脈識別子集合が空集合、逆順文脈識別子集合が｛−Ｃ１，−Ｃ７｝、指定文字列が“ガード”、部分文字列リストが｛“ガー”，“ード”｝であるデータが生成される。
【０１４９】
図４２は、図３９におけるステップ１８０７の詳細、すなわち本実施例における文字列インデックス検索プログラム１７０２の処理手順を示すＰＡＤ図である。
文字列インデックス検索プログラム１７０２は、前記検索条件解析プログラム１７０１が生成した展開済み検索条件データを入力として起動される。図４２に示すとおり、本プログラムの処理手順は図２１に示す第一の実施例の場合の処理手順とほぼ同様であるが、前記図２１におけるステップ２１０４、ステップ２１０５およびステップ２１０７に代わって、それぞれステップ４２０１、ステップ４２０２およびステップ４２０３が実行される。
【０１５０】
ステップ４２０１では、文字列インデックス中で前記展開済み検索条件データ中における指定文字列を検索し、該文字列に対応している構造化文字位置の集合を求め、次に該集合の中から、前記展開済み検索条件データ中の文脈識別子集合に含まれているいずれかの文脈識別子、または前記展開済み検索条件データ中の逆順文脈識別子集合に含まれているいずれかの逆順文脈識別子を持つ構造化文字位置情報群のみを抽出し、該抽出した構造化文字位置情報群からなるヒット位置集合を生成する。
【０１５１】
ステップ４２０２では、文字列インデックス中で前記指定文字列を検索し、該文字列の末尾に対応する文字ノードより前方に存在するすべての構造化文字位置情報の集合を求め、次に該集合の中から、前記展開済み検索条件データ中の文脈識別子集合に含まれているいずれかの文脈識別子、または前記展開済み検索条件データ中の逆順文脈識別子集合に含まれているいずれかの逆順文脈識別子を持つ構造化文字位置情報群のみを抽出し、該抽出した構造化文字位置情報群からなるヒット位置集合を生成する。
【０１５２】
ステップ４２０３では、前記展開済み検索条件データ中における部分文字列リスト中に含まれている部分文字列群のうち、ステップ２１０６の繰り返し中で現在着目している部分文字列を文字列インデックス中で検索し、該文字列に対応している構造化文字位置情報の集合を求め、次に該集合の中から、前記展開済み検索条件データ中の文脈識別子集合に含まれているいずれかの文脈識別子、または前記展開済み検索条件データ中の逆順文脈識別子集合に含まれているいずれかの逆順文脈識別子を持つ構造化文字位置情報群のみを抽出し、該抽出した構造化文字位置情報群を前記部分文字列に対応付けて記憶する。
【０１５３】
図４２におけるステップ２１０８、すなわち文字列インデックス検索プログラム１７０２の処理過程における連接判定処理は、図２２に示す前記第一の実施例の場合と同様となる。ただし、検索条件中の構造条件が逆順の構造条件だった場合には、連接判定の際、文脈識別子の一致ではなく逆順文脈識別子の一致を判定することになる。
【０１５４】
以上説明したように、本実施例に示した構成によれば、前記第一の実施例において検索が可能となる各種構造条件に加えて、「論文中で最後の章の中で、ある特定の文字列を検索する」、あるいは「後ろから２番目の参考文献の中で、ある特定の文字列を検索する」のように、文書の論理構造を逆順に（後ろから）辿った構造条件を指定した検索も可能となる。
以上が、本発明の第二の実施例の説明である。
【０１５５】
（第三の実施例）
以下、本発明を適用した第三の実施例について、図面を用いて説明する。
本実施例は、システムの構成および各プログラムの処理手順のいずれについても前記第一の実施例と同一であるが、文書木構造中のノードと構造インデックス中のメタノードとの対応のさせ方が異なり、その結果、同一の文書群を入力とした場合でも構造インデックスの構造および文脈インデックスの割り当てが前記第一の実施例とは異なってくる。
【０１５６】
ここで、本実施例における、文書木構造中のノードと構造インデックス中のメタノードとの対応関係を、図４３を用いて説明する。図４３は、図の左側に示す解析済み文書データの木構造を構成するノード群と、右側に示す構造インデックスの木構造を構成するノード（メタノード）群との対応関係を示している。
本実施例においても、解析済み文書の木構造中におけるあるノードの木構造アドレスと、構造インデックスの木構造中におけるあるメタノードの木構造アドレスとが等しい場合に、該ノードと該メタノードとは対応するものと定義する。ただし、本実施例では、前記第一の実施例とは異なり、共通の上位ノードを持つ同種の兄弟ノード間での出現順位を考える際に、先頭のノードと２番目のノードとの区別は行うが、２番目のノードとそれ以降に現れたノードとの区別は行わない。すなわち、木構造アドレス中で出現順位を表わす番号は常に[1]または[2]のいずれかをとり、[3]以上の値をとることはない。
【０１５７】
例えば、図４３に示す解析済み文書データ中のノード群のうち、ノード４３０１は上位ノードをもたず、兄弟ノード中では最初の“論文”要素ノードであるから、その木構造アドレスは“/論文[1]”と表記することができる。同様に、ノード４３０２はノード４３０１の下位ノードであり、兄弟ノード中では最初の“章”要素ノードであるから、その木構造アドレスは“/論文[1]/章[1]”となる。これに対して、ノード４３０３はノード４３０２の下位ノードであり、兄弟ノード中では４番目の“節”要素ノードであるが、前記規則から、その木構造アドレスは“/論文[1]/章[1]/節[2]”となる。また、ノード４３０４はノード４３０３の下位ノードであり、兄弟ノード中では２番目の“段落”要素ノードであるから、その木構造アドレスは“/論文[1]/章[1]/節[2]/段落[2]”となる。
【０１５８】
同様にして、図４３右側の構造インデックスの木構造を構成する各メタノードについてその木構造アドレスを求めてみると、メタノード４３０５の木構造アドレスは“/論文[1]”となり、ノード４３０１の木構造アドレスと等しくなる。同様に、メタノード４３０６の木構造アドレスは“/論文[1]/章[1]”となってノード４３０２の木構造アドレスと等しく、メタノード４３０７の木構造アドレスは“/論文[1]/章[1]/節[2]”となってノード４３０３の木構造アドレスと等しくなる。よって、ノード４３０１はメタノード４３０５、ノード４３０２はメタノード４３０６、ノード４３０３はメタノード４３０７とそれぞれ対応するものと判定される。なお、図４３の構造インデックス中にはノード４３０４と等しい木構造アドレスを持つメタノードはないので、ノード４３０４と対応するメタノードは構造インデックス中に存在しないものとみなされる。
【０１５９】
以上説明したように、上記規則の結果、本実施例において形成される構造インデックスでは、同一のメタノードの下位に、同種のメタノードが３個以上付加されることはなく、文書木構造中で同種のノードが３個以上連続している場合、２番目以降のノードには同一の文脈識別子が割り当てられる。よって、本実施例による文書検索方法では、構造条件中で任意の出現順位を指定することはできず、同種要素中で先頭の要素か、２番目以降の要素かを区別できるだけとなる。その代わり、本実施例では構造インデックスのデータ構造が前記第一の実施例の場合と比べて簡略になり、構造インデックス格納領域２１８として必要となる容量を削減することができる。
【０１６０】
なお、本実施例におけるノードとメタノードとの対応付けを採用した場合においても、前記第二の実施例同様に正順・逆順二つの構造インデックスを用意することにより、出現順を後ろから辿った構造指定をも可能とすることができる。
以上が、本発明の第三の実施例の説明である。
【０１６１】
（第四の実施例）
以下、本発明を適用した第四の実施例について、図面を用いて説明する。
図４４は、本実施例における文書登録サブシステム１０１の構成を示す図である。
図４４に示す文書登録サブシステム１０１は、そのハードウェア構成および磁気ディスク２０８中の格納領域の構成に関しては、図２に示す第一の実施例の場合と変わらない。ただし、主メモリ２０７中には、第一の実施例において保持するプログラム群に加えて、文書構造正規化プログラム４４０１を保持する。
【０１６２】
本実施例において、文書登録制御プログラム２１４は、文書構造解析プログラム２１０、文書構造正規化プログラム４４０１、構造インデックス作成プログラム２１１、構造化全文データ生成プログラム２１２および文字列インデックス作成プログラム２１３の起動および実行制御を行うとともに、これらのプログラムによって生成された解析済み文書データ、構造インデックスおよび文字列インデックスをネットワーク１０５を介して文書検索サーバ１０２に転送する。
【０１６３】
なお、本実施例ではフロッピーディスク２０５に格納された登録対象文書を入力として読み込む構成としたが、光磁気ディスク、追記型光ディスク等、他種の可搬型媒体から読み込む構成をとることもでき、ネットワーク１０５を介して転送されてくる文書を入力とする構成をとることもできる。さらに、本実施例では生成された解析済み文書データ、構造インデックスおよび文字列インデックスを文書検索サーバ１０２に転送するためにネットワーク１０５を使用するものとしたが、代わりにフロッピーディスク、光磁気ディスク、追記型光ディスク等の可搬型媒体を使用する構成をとることもできる。あるいは、文書登録サブシステム１０１と文書検索サーバ１０２を１台のコンピュータ上に実装し、データ転送を行わない構成をとることもできる。
【０１６４】
図４５は、本発明の第四の実施例における文書登録処理の概略手順を示すＰＡＤ図である。本図に示す処理手順は、図３に示す第一の実施例における処理手順とほぼ同様であるが、ステップ３０４の直後にステップ４５０１が追加されている点が異なる。
ここで、ステップ４５０１では、ステップ３０４で生成した解析済み文書データを入力として文書構造正規化プログラム４４０１を実行する。文書構造正規化プログラム４４０１は、解析済み文書データの中から、検索対象としては不適切な構造および内容文字列を抽出してこれらを削除する。
【０１６５】
図４６に、文書構造正規化プログラム４４０１の処理手順を示す。本プログラムは、起動されるとまずステップ４６０１において、正規化パラメタの指定の有無を確認する。正規化パラメタが指定されている場合にはステップ４６０２からステップ４６０８までに示す処理を実行し、正規化パラメタが指定されていない場合には何もせずに処理を終了する。
【０１６６】
ここで、正規化パラメタとは、接続対象要素および削除対象要素の要素型名を指定するパラメタのことである。ここで言う接続対象要素とは、例えば文章の一部を強調表示するために用いられる非構造的な要素であって、検索時にはその要素の境界をまたいで文字列を検出する必要があるもののことである。また、削除対象要素とは、その内部に本来の文書内容とは異なる種類のデータを保持しており、検索時にはその内容を無視して文字列の検出を行うべきもののことである。削除対象要素の例としては、例えばテキスト中に参照先の文献へのリンクデータを埋め込むために用いられる要素などがある。
【０１６７】
ステップ４６０２では、指定されている正規化パラメタを読み込む。ここで、正規化パラメタは、ユーザがキーボード２０２から入力するか、または予め特定のファイルに書き込んでおくなどして指定する。接続対象要素および削除対象要素の要素型名は、それぞれ複数個指定してもよく、あるいは省略してもよい。次に、ステップ４６０３では、解析済み文書データを解析済み文書データ格納領域２１７から読み込む。
次に、ステップ４６０４では、解析済み文書データの木構造を順次たどりつつ、すべての要素ノードについて、ステップ４６０５からステップ４６０７までに示す処理を繰り返す。そして、すべての要素ノードについて該処理を終了した後、ステップ４６０８に進む。
【０１６８】
ステップ４６０５では、現在着目している要素ノードについて、正規化パラメタが何を指定しているかを判定する。該着目要素の要素型名が接続対象として指定されている場合にはステップ４６０６に進み、該要素ノードを削除するとともに、該要素の内部に含まれるすべての文字列データを、該要素の前後にある文字列データに接続する。また、該着目要素の要素型名が削除対象として指定されている場合にはステップ４６０７に進み、該要素ノードおよびその下位にあるすべてのノードを削除する。
前記のごとくステップ４６０５以下の処理を行った後、ステップ４６０８に進み、正規化対象要素群を処理して更新された解析済み文書データを、解析済み文書データ格納領域２１７に再び格納する。
【０１６９】
図４７は、正規化処理の具体的な例を示す図である。
図４７において、４７０１は正規化パラメタの一例を示しており、ここでは接続対象要素の要素型名として“bold”と“italic”の二つ、削除対象要素の要素型名として“link”と“index”の二つが指定されている。この場合、解析済み文書データ中に４７０２に示すような構造を持つ部分があると、要素“bold”に対して前記ステップ４６０６に示す接続処理が行われ、その結果は４７０３に示す構造となる。また、解析済み文書データ中に４７０４に示すような構造を持つ部分があると、要素“link”に対して前記ステップ４６０７に示す削除処理が行われ、その結果は４７０５に示す構造となる。
【０１７０】
以上説明したように、本実施例では、解析済み文書データに対して前記正規化処理を行った後に構造インデックスへの登録以下の処理が行われるので、登録対象文書中に含まれていた非構造的な要素に妨げられることなくテキストの検索を行うことができる。
なお、本実施例における正規化処理を採用した場合においても、前記第二の実施例同様に正順・逆順二つの構造インデックスを用意することにより、出現順を後ろから辿った構造指定も可能とすることができる。
以上が、本発明の第四の実施例の説明である。
【０１７１】
【発明の効果】
以上説明したように、本発明による構造化文書の検索方法によれば、文書中に現れる論理要素の文書中における出現位置に関する条件を構造条件指定中に含めることができるので、複雑な論理構造を備えた多数の文書からなる文書データベース上においても精度の高い構造指定検索ができる。
【図面の簡単な説明】
【図１】本発明による文書検索システムの第一の実施例の全体構成を示す図である。
【図２】本発明の第一の実施例における文書登録サブシステムの構成を示す図である。
【図３】本発明の第一の実施例における文書登録処理の概略手順を示すＰＡＤ図である。
【図４】文書論理構造を定義するＤＴＤの一例を示す図である。
【図５】ＳＧＭＬによる構造化文書の記述例を示す図である。
【図６】ＳＧＭＬが表現する文書の論理構造を図形的に示した模式図である。
【図７】本発明の第一の実施例における文書構造解析プログラムの処理手順を示すＰＡＤ図である。
【図８】文書構造テーブルのデータ構造を示す図である。
【図９】本発明の第一の実施例における構造インデックス作成プログラムの処理手順を示すＰＡＤ図である。
【図１０】本発明の第一の実施例における解析済み文書データの辿り順を示す図である。
【図１１】本発明の第一の実施例におけるノードとメタノードとの対応関係を示す図である。
【図１２】本発明の第一の実施例における構造インデックスの生成過程を示す図である。
【図１３】本発明の第一の実施例における構造化全文データ生成プログラムの処理手順を示す図である。
【図１４】本発明の第一の実施例における構造化全文データのファイル形式を示す図である。
【図１５】本発明の第一の実施例における文字列インデックス作成プログラムの処理手順を示すＰＡＤ図である。
【図１６】本発明の第一の実施例における文字列インデックスのデータ構造を示す図である。
【図１７】本発明の第一の実施例における文書検索サーバの構成を示す図である。
【図１８】本発明の第一の実施例における文書検索処理の概略手順を示すＰＡＤ図である。
【図１９】本発明の第一の実施例における検索条件解析プログラムの処理手順を示すＰＡＤ図である。
【図２０】本発明の第一の実施例における展開済み検索条件データの生成例を示す図である。
【図２１】本発明の第一の実施例における文字列インデックス検索プログラムの処理手順を示すＰＡＤ図である。
【図２２】本発明の第一の実施例における連接判定処理の実行例を示す図である。
【図２３】本発明の第一の実施例における検索結果データのデータ構造を示す図である。
【図２４】本発明の第一の実施例における検索結果データ転送処理の詳細手順を示すＰＡＤ図である。
【図２５】本発明の第一の実施例における文書検索クライアントの構成を示す図である。
【図２６】本発明の第一の実施例における検索クライアントの動作手順を示すＰＡＤ図である。
【図２７】本発明の第一の実施例における検索条件入力プログラムの処理手順を示すＰＡＤ図である。
【図２８】本発明の第一の実施例における検索結果表示プログラムの処理手順を示すＰＡＤ図である。
【図２９】本発明の第二の実施例における文書登録サブシステムの構成を示す図である。
【図３０】本発明の第二の実施例における文書登録処理の概略手順を示すＰＡＤ図である。
【図３１】本発明の第二の実施例における逆順構造インデックス作成プログラムの処理手順を示すＰＡＤ図である。
【図３２】本発明の第二の実施例における解析済み文書データの辿り順を示す図である。
【図３３】本発明の第二の実施例におけるノードとメタノードとの対応関係を示す図である。
【図３４】本発明の第二の実施例における逆順構造インデックスの生成過程を示す図である。
【図３５】本発明の第二の実施例における構造化全文データ生成プログラムの処理手順を示すＰＡＤ図である。
【図３６】本発明の第二の実施例における構造化全文データのファイル形式を示す図である。
【図３７】本発明の第二の実施例における文字列インデックスのデータ形式を示すＰＡＤ図である。
【図３８】本発明の第二の実施例における文書検索サーバの構成を示す図である。
【図３９】本発明の第二の実施例における文書検索処理の概略手順を示すＰＡＤ図である。
【図４０】本発明の第二の実施例における検索条件解析プログラムの処理手順を示すＰＡＤ図である。
【図４１】本発明の第二の実施例における展開済み検索条件データの生成例を示す図である。
【図４２】本発明の第二の実施例における文字列インデックス検索プログラムの処理手順を示すＰＡＤ図である。
【図４３】本発明の第三の実施例におけるノードとメタノードとの対応関係を示す図である。
【図４４】本発明の第三の実施例における文書登録サブシステムの構成を示す図である。
【図４５】本発明の第四の実施例における文書登録処理の概略手順を示すＰＡＤ図である。
【図４６】本発明の第四の実施例における文書構造正規化プログラムの処理手順を示すＰＡＤ図である。
【図４７】本発明の第四の実施例における正規化処理の具体例を示す図である。
【符号の説明】
１０１…文書登録サブシステム、
１０２…文書検索サーバ、
１０３…文書検索クライアント、
２１０…文書構造解析プログラム、
２１１…構造インデックス作成プログラム、
２１２…構造化全文データ生成プログラム、
２１３…文字列インデックス作成プログラム、
２１４…文書登録制御プログラム、
２１７…解析済み文書データ格納領域、
２１８…構造インデックス格納領域、
２１９…構造化全文データ格納領域、
２２０…文字列インデックス格納領域、
１７０１…検索条件解析プログラム、
１７０２…文字列インデックス検索プログラム、
１７０３…文書検索制御プログラム、
１７０４…検索結果データ格納領域、
２００１…検索条件の一例、
２００２…構造インデックスの一例、
２００３…展開済み検索条件データの一例、
２２０１…文字列インデックスの一例、
２５０１…検索条件入力プログラム、
２５０２…検索結果表示プログラム、
２５０３…クライアント制御プログラム、
２９０１…逆順構造インデックス作成プログラム、
２９０２…逆順構造インデックス格納領域、
４１０２…逆順構造インデックスの一例、
４４０１…文書構造正規化プログラム
【図１】
0003887867.tif 000002
【図２】
0003887867.tif 000003
【図３】
0003887867.tif 000004
【図４】
0003887867.tif 000005
【図５】
0003887867.tif 000006
【図６】
0003887867.tif 000007
【図７】
0003887867.tif 000008
【図８】
0003887867.tif 000009
【図９】
0003887867.tif 000010
【図１０】
0003887867.tif 000011
【図１１】
0003887867.tif 000012
【図１２】
0003887867.tif 000013
【図１３】
0003887867.tif 000014
【図１４】
0003887867.tif 000015
【図１５】
0003887867.tif 000016
【図１６】
0003887867.tif 000017
【図１７】
0003887867.tif 000018
【図１８】
0003887867.tif 000019
【図１９】
0003887867.tif 000020
【図２０】
0003887867.tif 000021
【図２１】
0003887867.tif 000022
【図２２】
0003887867.tif 000023
【図２３】
0003887867.tif 000024
【図２４】
0003887867.tif 000025
【図２５】
0003887867.tif 000026
【図２６】
0003887867.tif 000027
【図２７】
0003887867.tif 000028
【図２８】
0003887867.tif 000029
【図２９】
0003887867.tif 000030
【図３０】
0003887867.tif 000031
【図３１】
0003887867.tif 000032
【図３２】
0003887867.tif 000033
【図３３】
0003887867.tif 000034
【図３４】
0003887867.tif 000035
【図３５】
0003887867.tif 000036
【図３６】
0003887867.tif 000037
【図３７】
0003887867.tif 000038
【図３８】
0003887867.tif 000039
【図３９】
0003887867.tif 000040
【図４０】
0003887867.tif 000041
【図４１】
0003887867.tif 000042
【図４２】
0003887867.tif 000043
【図４３】
0003887867.tif 000044
【図４４】
0003887867.tif 000045
【図４５】
0003887867.tif 000046
【図４６】
0003887867.tif 000047
【図４７】
0003887867.tif 000048