JP4334450B2 - 構造化文書検索装置及び構造化文書検索方法 - Google Patents

Description

本発明は、階層化された論理構造をもつ構造化文書データベースに関する。

Extensible markup language（ＸＭＬ）などで記述された構造化文書データを記憶・検索するための構造化文書管理システムには、いくつかの方式が考えられている。

（Ａ）コレクション方式
データを登録する際に、同種の文書集合を登録する「コレクション」と呼ばれる文書集合を管理するノードを定義する。コレクションは汎用ＯＳで呼ばれる「フォルダ」の概念であるが、コレクション自体はあくまで概念であって、ＸＭＬノードではなく実体を持たない。

汎用ＯＳを考えても、これらコレクション間にも階層情報を持たせて管理したいという要求が多く、この場合は、コレクション間の関係を別途リレーションで管理する必要がある。また、この場合、複数の問合せ言語の検索結果をアプリケーション側で処理し、所望の検索結果を生成しなければならないなど管理の手間、コストともに高い。

（Ｂ）階層管理方式
上記コレクション方式とは異なり、コレクション自体もＸＭＬノードであるとみなし、コレクション間の階層関係もＸＭＬで表現した管理方式である。つまり、登録した構造化文書をそれぞれ部分要素と持つ、巨大なＸＭＬツリーが構築されたデータベースとして管理する。このことにより、ＸＱｕｅｒｙなどの問合せ言語でデータベース全体を横断するような検索が可能となる。これは、上記コレクション方式で問題となっていた、コレクション間の階層関係の管理コストや、検索結果の生成コストなども、ＸＱｕｅｒｙという問合せ言語だけで処理することが可能となり、プログラムによる処理を大幅に削減できる。

特許文献１に記載されている構造化文書管理装置は、データベースのモデルとして、フォルダに対してスキーマを設定することで、登録されるデータの整合性をチェックすることも可能である。

階層管理方式をとることで、データベース全体を巨大なＸＭＬツリーとみなすことができる。また、データベース内では、各文書をその登録日時に基づく順序で記憶・管理されている。

データベースに登録される各文書の内容的及び時間的な順序が予め決定している場合や、更新が無い場合は問題ないが、オンラインで登録、検索、更新されるデータベースを考えた場合、単に登録日時からこれら文書間の順序関係を保持するのは難しい問題となってくる。

すなわち、扱うデータは静的に決定されるのではなく、動的に追加、更新、削除ので、一度決定した文書順序値が変更される可能性があり、特に大規模な階層化構造化文書データベースにおいては、その影響範囲は大きい。また、大規模データベースであるので、順序関係を保持するための情報が非常に大きくなる可能性がある。また、実用に耐えうるシステムであるために、現実的であり、かつ高速であることが必須である。

これまでに、構造化文書の文書順序を判別する方法として以下のようなものが考えられていた。

（Ａ）グローバルオーダ管理方式、ローカルオーダ管理方式、Ｄｅｗｅｙオーダ管理方式（公知）
グローバルオーダは、文書順序をルートから登録順にグローバルな順序値付けを行う方法、ローカルオーダは、各ノードは親要素からの相対順序値だけ持ち、親子関係は実際の文書走査を行い判別する方法、Ｄｅｗｅｙオーダ管理方式は、全てのノードにルートからのパス情報を埋め込むことで順序値付けを行う方法である。それぞれ特徴があるが、基本的には、追加、更新が入った場合に文書順序値を振り直すことになる。文書順序値に余裕を持たせることである程度対応できるが、それでも結局は限界がある。

また、文書内の順序関係を特定する手段であって、複数文書の場合が考慮されていない。

階層型構造化文書データベースでは、この文書順序値の振りなおしのコストが高いことと、複数文書対応が問題である。

（Ｂ）文書順序値の判別に可変長ビットを用いる方法（公知）
こでは、文書順序値に、固定長の値を与えるのではなく、可変長ビットで順序関係を表すことで、文書順序値の全体の振り直しを避ける方法である。判別のためには、全てのパス情報をビットに埋め込まなければならず、特に階層が深くなった場合には非常に大きな情報量になり、現実的には問題である。

（Ｃ）特許文献２には、登録される構造化文書を解析して、論理構造に分割し、この要素単位で、末端要素とそれ以外の要素という２種類のＩＤ付けを行う技術が開示されている。ＩＤが重複しないように素数を利用し、親子間では素数の積を取ること、ユニーク性を保持する。ここで考慮されているのは文書内の各要素の順序、すなわち「文書内順序」のみであり、階層型構造化文書データベースを考えた場合に必要な、「文書間順序」が考慮されていない。

（Ｄ）特許文献３記載の技術は、複数の文書を１つの仮想文書と見なす方法の１つで、考え方自体は公知である「多階層管理」に属する。全ての文書間の繋がりを表すグローバル構造情報で複数文書間の階層関係を表し、各要素の順序関係はグローバル構造情報を経由して判別される。各ノードにこれらグローバル構造情報を持つために情報量は大きいが、もともとは複数人での文書編集方法を主眼としたものである。階層化構造化文書データベースのように、文書数が膨大になった場合には、情報量が大きくなりすぎ、現実的ではない。
特開２００２−２９７６０１ 特開２００１−１３４５９６ 特開２００３−６７４０２

以上説明したように、従来は、文書順が予め定められている複数の構造化文書を記憶する構造化文書データベースでは、各構造化文書を登録順に管理することはできても、文書順に管理することはできなかった。従って、当該データベースから検索された各構造化文書を当該データベースに登録された順ではなく、文書順に並び替えることが容易に行えないという問題点があった。

そこで、本発明は、上記問題点に鑑み、文書順が予め定められている複数の構造化文書を記憶する構造化文書データベースから検索された各構造化文書を文書順に並び替えることが容易に行える構造化文書検索方法及び装置を提供することを目的とする。

本発明は、複数の要素データをそれぞれ含み、文書順が予め定められている複数の構造化文書を記憶する記憶手段と、この記憶手段に記憶された各構造化文書の文書ＩＤであって、当該構造化文書が当該記憶手段により記憶された順番を示す番号を記憶し、上記順番と文書順とが異なる構造化文書の場合には、文書順が当該構造化文書の直前の構造化文書及び直後の構造化文書のうちの少なくとも１つの文書ＩＤに対する当該構造化文書の文書順を示す相対値とともに当該構造化文書の文書ＩＤを記憶する文書ＩＤ記憶手段とを備え、当該記憶手段から検索条件を満たす複数の構造化文書が検索されると、当該検索された複数の構造化文書のうち文書ＩＤ記憶手段で相対値が記憶されている構造化文書の場合には当該相対値を用い、文書ＩＤ記憶手段で前記相対値が記憶されていない構造化文書の場合には文書ＩＤを用いて、当該検索された複数の構造化文書を文書順に並び替える。

本発明によれば、文書順が予め定められている複数の構造化文書を記憶する構造化文書データベースから検索された各構造化文書を文書順に並び替えることが容易に行える。

以下、本発明の実施形態について、図面を参照して説明する。

図１は、構造化文書データ（構造化データ）の一例である。構造化文書を記述するための代表的な言語としてＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）が挙げられる。図１に示す構造化文書はＸＭＬで記述されたものである。ＸＭＬでは、文書構造を構成する個々のパーツを「要素」（エレメント：Ｅｌｅｍｅｎｔ）と呼び、要素はタグ（ｔａｇ）を使って記述する。具体的には、要素の始まりを示すタグ（開始タグ）と、終わりを示すタグ「終了タグ」）の２つのタグでテキストデータを挟み込んで、１つの要素を表現している。なお、開始タグと終了タグで挟み込まれたテキストデータは、当該開始タグと終了タグで表された１つの要素に含まれるテキスト要素である。

図１に示す構造化データは、＜ｂｏｏｋ＞というタグで囲まれた要素をルート要素とする。この「ｂｏｏｋ」要素は、＜ｔｉｔｌｅ＞、＜ａｕｔｈｏｒｓ＞、＜ａｂｓｔｒａｃｔ＞の各タグで囲まれた３つの子要素を有する。「ａｕｔｈｏｒｓ」要素は、＜ａｕｔｈｏｒ＞というタグをもつ２つの子要素を有する。各「ａｕｔｈｏｒ」要素には、＜ｆｉｒｓｔ＞、＜ｌａｓｔ＞という各タグで囲まれた子要素が存在する。「ｆｉｒｓｔ」要素と「ｌａｓｔ」要素は、それぞれ「太郎」や「田中」といったテキスト要素を持っている。

図２は、本実施形態に関る構造化文書管理システムの機能的な構成例を示したものである。構造化文書管理システムは、大きく分けてクライアント２０１とサーバ１０１とから構成されている。クライアント２０１からの格納要求や検索要求を受けて、サーバ１０１が各要求に対応する処理を行う。

クライアント２０１は、主に、構造化文書登録部２０２と検索部２０１と入力部２０４と表示部２０５を有する。キーボードやマウス等の入力装置からなる入力部２０４は、構造化文書を入力したり、各種指示入力を行うためのものである。構造化文書登録部２０２は、入力部２０４から入力された構造化文書や、クライアント２０１のもつ記憶装置などに予め記憶された構造化文書を構造化文書データベース１１１に登録するためのものである。構造化文書登録部２０２は、格納要求とともに登録すべき構造化文書をサーバ１０１へ送信し、また、更新要求とともに、更新された構造化文書をサーバ１０１へ送信する。検索部２０３は、入力部２０４からユーザにより入力された指示に従って、構造化文書データベース１１１から所望のデータを検索するための検索条件などが記述された問合せデータを作成し、当該問合せデータを含む検索要求をサーバ１０１へ送信する。また、サーバ１０１から送信された当該検索要求に対応する結果データを受け取り、それを表示部２０５に表示する。

サーバ１０１は、要求処理部１０２、格納処理部１０３、検索処理部１０４から構成されている。また、サーバ１０１には構造化文書データベース（構造化文書ＤＢ）１１１が接続されている。構造化文書データベース１１１は、構造化文書データ記憶部１１２と構造テンプレート記憶部１１３と索引データ記憶部１１４とから構成されている。

要求処理部１０２は、クライアント２０１から送信される格納要求、更新要求、検索要求を判別し、格納処理部１０３や検索処理部１０４などへ処理の振り分けを行い、格納処理部１０３や検索処理部１０４での処理結果をクライアント２０１に返す。

格納処理部１０３は、クライアント２０１からの格納要求を受けて、クライアント２０１から送信された新たな構造化文書を構造化文書データベース１１１に格納する処理を行う。また、クライアント２０１からの更新要求を受けて、クライアント２０１から送信された更新された構造化文書を基に、既に構造化文書ＤＢ１１１に登録されている元の構造化文書のデータを更新するための処理を行う。

格納処理部１０３は、構造化文書構文解析部３１と構造化文書構造抽出部３２と構造化文書構造照合部３３と構造化文書格納部３４から構成される。

新たな構造化文書を構造化文書ＤＢ１１１に登録する場合には、構造化文書構文解析部３１は、要求処理部１０２から渡された新たな構造化文書を構文解析し、その解析結果を基に構造化文書構造抽出部３２では当該構造化文書の（文書）構造を抽出する。構造化文書構造照合部３３は、抽出された構造と構造化文書データベース１１１に記憶された構造テンプレートとを照合する。構造化文書格納部３４は、構造化文書構造照合部３３での照合結果を基に、当該新たな構造化文書の各要素にオブジェクトＩＤ及び更新フラグ(後述するように、新規登録の場合は常に値は「０」)を与えて、構造化文書データベース１１１の構造化文書データ記憶部１１２に格納するとともに、索引データを索引データ記憶部１１４に格納する。

既に構造化文書ＤＢ１１１に登録されている構造化文書を更新する場合（例えば、当該構造化文書に新たな要素を追加する場合）には、構造化文書構文解析部３１は、要求処理部１０２から渡された更新された構造化文書を構文解析し、その解析結果を基に構造化文書構造抽出部３２では当該更新された構造化文書の（文書）構造を抽出する。構造化文書構造照合部３３は、抽出された構造と構造化文書データベース１１１に記憶された構造テンプレートとを照合する。構造化文書格納部３４は、構造化文書構造照合部３３での照合結果と、既に構造化文書データ記憶部１１２に記憶されている元の構造化文書のデータと、その各要素のＯＩＤとを基に、新たに追加された要素にオブジェクトＩＤ及び更新フラグ（後述するように、更新により新たな追加された要素の場合には、値「１」）を与えて、構造化文書データベース１１１の構造化文書データ記憶部１１２に格納するとともに、索引データを索引データ記憶部１１４に格納する。

検索処理部１０４は、クライアント２０１からの検索要求を受けて、指定された条件（問合せデータ）に合致するデータを構造化文書データベース１１１から探し出し、得られたデータを結果データとして返す処理を行う。検索処理部１０４は、問合せ構文解析部４１と問合せ構造抽出部４２と問合せ構造照合部４３と問合せ実行部４４から構成される。

問合せ構文解析部４１は、要求処理部１０２から渡された問合せデータを構文解析し、その解析結果を基に問合せ構造抽出部４２では、当該問合せデータの構造を抽出する。問合せ構造照合部４３は、抽出された構造と構造化文書データベース１１１に記憶されている構造テンプレートとを照合する。問合せ実行部４４は、問合せ構造照合部４３での照合結果を基に、構造化文書データベース１１１に記憶されている構造化文書データや構造テンプレートや索引データにアクセスして、問合せデータに記述された条件に合致する結果データを生成する。

図３は、サーバ１０１のハードウエア的な構成例を示したもので、バス１に通信Ｉ／Ｆ装置２、可搬記録媒体ドライブ装置３、表示装置４、入力装置５、出力装置６、演算装置（ＣＰＵ）７および外部記憶装置８並びにメモリ９が接続されて構成されている。さらに、図３に示す構成では、バス１に、図２の構造化文書データベース１１１が接続されている。

図２の要求処理部１０２と格納処理部１０３と検索処理部１０４のそれぞれの機能を実現するためのプログラムは、図３の外部記憶装置８に予め記憶され、必要に応じて、各プログラムがメモリ９に読み込まれて実行される。

以下、図２を参照して説明する。

まず、構造化文文書ＤＢ１１１での構造化文書の格納方法について説明する。

図４は、構造化文書データ記憶部１１２のデータ構造を模式的に表したものである。構造化文書データ記憶部１１２には、論理的には、大量の構造化文書が「ｒｏｏｔ」ノード３０１をルートする１つの構造化文書の部分文書として記憶されている。図４では、この「ｒｏｏｔ」ノード３０１をルートする１つの構造化文書の構造をノードとアークから構成される階層木で表している。各ノードは構造化文書の要素（テキスト要素を含む）を示し、要素間の親子関係をアークで示している。実装上は、ノードはオブジェクトデータのファイルとして構造化文書データ記憶部１１２に格納される。各ノードには、オブジェクトＩＤ（ＯＩＤ）と呼ばれる識別子が割当てられている。なお、図４では、説明の簡単のため、ＯＩＤを「０」〜「４７」の数字で表している。ＯＩＤを指定することで所望のオブジェクトデータを取り出すことができる。

ノード間の親子関係を表わすアークは、オブジェクトデータ間のリンクであり、このリンクはオブジェクトデータ内に子要素及び親要素のオブジェクト集合を指すＯＩＤ配列として、構造化文書データ記憶部１１２に記憶される。

「ｒｏｏｔ」ノード３０１の下には「ｂｏｏｋＦｏｌｄｅｒ」、「ｐａｐｅｒＦｏｌｄｅｒ」の２つのノード３０２、３０３が存在する。「ｂｏｏｋＦｏｌｄｅｒ」ノードの下には、２つの「ｂｏｏｋ」ノード３０４、３０５が存在する。ＯＩＤが「２」の「ｂｏｏｋ」ノードには、図１で示した構造化文書データが格納されている。

このように「ｒｏｏｔ」ノード以下のデータは、複数の構造化文書のそれぞれの各要素からなる１つの大きな構造化文書データであり、図１で示した構造化文書データは、当該大きな構造化文書データの一部分として格納されている。例えば、図１の構造化文書＜ｂｏｏｋ＞…＜／ｂｏｏｋ＞は、図４の構造化文書では、＜ｒｏｏｔ＞＜ｂｏｏｋＦｏｌｄｅｒ＞＜ｂｏｏｋ＞…＜／ｂｏｏｋ＞＜ｂｏｏｋＦｏｌｄｅｒ＞＜ｒｏｏｔ＞と表すことができる。

なお、このような複数のノードからなる階層構造は、汎用のＯＳで広く採用されているディレクトリ構造に当てはめると、これら各ノードは、ディレクトリ構造のフォルダとファイルに対応する。すなわち、図４に示す階層構造は、「ｒｏｏｔ」フォルダの下に、「ｂｏｏｋＦｏｌｄｅｒ」、「ｐａｐｅｒＦｏｌｄｅｒ」という２つの子フォルダがあり、「ｂｏｏｋＦｏｌｄｅｒ」フォルダの下に、「ｂｏｏｋ」という要素をルートに持つ２つのドキュメントファイル３１１、３１２が存在し、「ｐａｐｅｒＦｏｌｄｅｒ」フォルダの下に、「ｐａｐｅｒ」という要素をルートに持つ１つのドキュメントファイル３１３が存在するディレクトリ構造で構造化文書データ記憶部１１２に記憶される。

以下、「ｒｏｏｔ」ノード、「ｂｏｏｋＦｏｌｄｅｒ」ノード、「ｐａｐｅｒＦｏｌｄｅｒ」ノードをフォルダと解釈し、フォルダ以下のデータをまとめてドキュメントファイルと解釈する。例えば、図４の場合、「ｂｏｏｋＦｏｌｄｅｒ」フォルダに２つの「ｂｏｏｋ」ドキュメント（ファイル３１１、３１２）が格納され、「ｐａｐｅｒＦｏｌｄｅｒ」フォルダに１つの「ｐａｐｅｒ」ドキュメント（ファイル３１３）が格納されていると解釈することができる。

図５は、従来の構造化文書ＤＢの構成例である。構造化文書ＤＢに対する検索を行うには、問合せデータを与える必要がある。問合せデータには、テキスト（単語などの文字列）を検索条件として指定したもの、構造化文書の構造を検索条件として指定したもの、あるいは両者を組み合わせて検索条件として指定したものがある。問合せデータに単語などの文字列が検索条件として含まれる場合、構造化文書管理システムでは高速に検索を行うため、語彙索引データを用いる。語彙索引データとは、格納された構造化文書データに含まれるテキスト要素のテキストデータ（文字列）を抽出し、テキストデータと当該テキストデータを含む構造化文書データ中の要素のオブジェクトＩＤ（ＯＩＤ）との対応関係を表す情報である。

図５に示す構造化文書ＤＢには、構造化文書データを格納する構造化文書データ記憶部と、索引データを格納する索引データ記憶部から構成されている。

図１で示した構造化文書データには、「ＸＭＬデータベース」、「ＸＭＬデータの検索技術」、「田中」、などのテキストデータが含まれている。これらのテキストデータを字句解析することで「ＸＭＬ」、「データ」、「データベース」などの語彙（文字列）に分解している。

索引データ記憶部には、語彙テーブルと当該語彙テーブル中の各語彙にリンクされた当該語彙を含むテキスト要素のＯＩＤを記録する複数のテーブルが記憶されている。語彙テーブル中の語彙からリンクをたどることで、その語彙を含むテキスト要素の出現位置、つまりＯＩＤが得られる。

図６は、本実施形態に関る構造化文書ＤＢ１１１の構成例である。構造化文書データ記憶部１１２は図５と同じであるが、新たに構造テンプレート記憶部１１３及び文書ＩＤ記憶部１１５が追加されている。また、索引データ記憶部１１４は、語彙テーブルと当該語彙テーブル中の各語彙にリンクされた当該語彙を含むテキスト要素のＯＩＤ及び更新フラグ（後述）を記録する複数のテーブルが記憶されている。語彙テーブル中の語彙からリンクをたどることで、その語彙を含むテキスト要素の出現位置、つまりＯＩＤと、更新フラグの値が得られる。

構造テンプレート記憶部１１３には、構造テンプレートデータが格納されている。構造テンプレートデータには、構造化文書データ記憶部１１２に格納されている構造化文書データから抽出された構造データが格納されている。

図４に示したように、構造化文書ＤＢ１１１に、２つの「ｂｏｏｋ」ドキュメントファイル３１１、３１２と、１つの「ｐａｐｅｒ」ドキュメントファイル３１３が記憶されている場合に、構造テンプレート記憶部１１３に記憶されている構造テンプレートデータを図７に示す。図４では、フォルダやドキュメントファイルが階層的に配置されていた。図７の構造テンプレートデータは、「ｒｏｏｔ」、「ｂｏｏｋＦｏｌｄｅｒ」、「ｐａｐｅｒＦｏｌｄｅｒ」という３つのフォルダ３５１〜３５３からなる階層構造と、「ｂｏｏｋＦｏｌｄｅｒ」というフォルダに格納されている２つのドキュメントの文書構造のベース（基準）となる文書構造（要素（テキスト要素を含む）３６１〜３６９で構成される階層構造）と、「ｐａｐｅｒＦｏｌｄｅｒ」というフォルダに格納されている１つのドキュメントの文書構造のベース（基準）となる文書構造（要素（テキスト要素を含む）３８１〜３８９で構成される階層構造）を表したものである。

図４では、「ｂｏｏｋ」ドキュメントファイル３１１は、その先頭のノードである「ｂｏｏｋ」ノード３０４直下に「ａｕｔｈｏｒｓ」ノードがあり、その下には２つの「ａｕｔｈｏｒ」ノードがあったが、図７に示し構造テンプレートでは、「ａｕｔｈｏｒ」ノードは１つにまとめられて、テキストノード（テキスト要素）は「＃ｔｅｘｔ」ノードとして表されている。

図７の構造テンプレートデータの六角形で表された各ノード（各ノードは、フォルダ、ファイル、要素、テキスト要素に対応する）には、「Ｆ０」、「Ｄ２」、「Ｅ３」、「Ｔ４」などのユニークなＩＤが割り振られている。構造テンプレートデータの各ノードの種別や構造上の位置を識別するために、各ノードに割り振られたＩＤをテンプレートＩＤ（ＴＩｄ）と呼ぶ。

テンプレートＩＤについて説明する。テンプレートＩＤは、構造テンプレート上の当該ノードの種類を表す情報と、同じ種類のノードのなかで各ノードを識別するための番号とから構成されている。ノードの種類は、「Ｆ」「Ｄ」「Ｅ」「Ｔ」という４種の文字により表されている。「Ｆ」はフォルダ、「Ｄ」はドキュメントファイル、「Ｅ」は要素（テキスト要素ではない要素）、「Ｔ」はテキスト要素を表す。ノードの種類を表す文字とそれに続く番号「ｘ」とからなるテンプレートＩＤにより、当該ノードの種類と、当該テンプレートＩＤを持つノードが構造テンプレート上のどのノードであるかを識別することができる。

テンプレートＩＤが「Ｆｘ」であるノードはフォルダを表し、これをフォルダ型構造テンプレートノードと呼ぶ。テンプレートＩＤが「Ｄｘ」であるノードはドキュメントを表し、ドキュメント型構造テンプレートノードと呼ぶ。テンプレートＩＤが「Ｅｘ」であるノードはドキュメント内の要素（テキスト要素でない要素）を表し、エレメント型構造テンプレートノードと呼ぶ。テンプレートＩＤが「Ｔｘ」であるノードはドキュメント内のテキスト要素を表し、テキスト型構造テンプレートノードと呼ぶ。なお、ここでは、「ｘ」は、構造テンプレートデータの各ノードにユニークなシリアルな整数とする。

本実施形態に関る構造化文書データ記憶部１１２には、図４の「ｒｏｏｔ」ノード３０１や「ｂｏｏｋｆｏｌｄｅｒ」ノード３０２、「ｐａｐｅｒｆｏｌｄｅｒ」ノード３０３、「ｂｏｏｋ」ドキュメントや「ｐａｐｅｒ」ドキュメントの各要素（テキスト要素を含む）に対応する各ノードを識別するためのＯＩＤには、上記テンプレートＩＤが含まれている。

図８は、図４と同様、構造化文書データ記憶部１１２に格納されている構造化文書データの記憶例を模式的に示したものである。図８では、各ノードのＯＩＤを図４よりも詳細に示している。すなわち、本実施形態では、データファイルに格納されている構造化文書データの各ノードのＯＩＤは、ドキュメントＩＤ（ＤｏｃＩＤ）、要素ＩＤ（ＥｌｅｍＩｄ）、上記テンプレートＩＤ（ＴＩｄ）から構成されている。さらに、各要素にはＯＩＤとともに、更新フラグが付加されている。ここでは、ＯＩＤを＜ＤｏｃＩｄ，ＥｌｅｍＩｄ，ＴＩｄ＞と表し、このＯＩＤに次に、更新フラグを示している。すなわち、図８では、各要素が、「＜ＤｏｃＩｄ，ＥｌｅｍＩｄ，ＴＩｄ＞，更新フラグ」という情報を有していることを示している。

ＤｏｃＩｄとは、ドキュメント、フォルダに割当てられるデータファイル内でユニークなＩＤであり、ドキュメントファイルの識別子、フォルダの識別子である。本実施形態では、このＤｏｃＩＤは、ドキュメントやフォルダの構造化文書ＤＢ１１１への登録順（登録日時の早い順）に、番号「０」「１」「２」…と割り振るものとする。従って、このＤｏｃＩＤは、当該ＤｏｃＩＤをもつドキュメントやフォルダの構造化文書ＤＢ１１１への登録順を示している。

一方、構造化文書ＤＢに登録される各文書には、上記登録順の他に、各文書の内容（例えば、各文書が１つの大きな文書のうちの一部分であり、第１章、第２章、…という順番を有するものである場合など）に基づく文書順を有する。そして、この文書順は上記登録順とは一致しない場合がある。例えば、先に第３章の文書、第２章の文書を作成して登録した後に第１章の文書を登録する場合には、第１章の文書の登録順は３番目であるにも関わらず、文書順は１番目である。

そこで、本実施形態では、構造化文書ＤＢに登録される各文書を従来同様、ＤｏｃＩＤを用いて登録順に管理するとともに、後述するように、文書順も管理するようになっている。文書ＩＤ記憶部１１５は、登録順と文書順が一致するような文書については、第１の文書ＩＤリスト１１５ａで、当該文書の登録順を示すＤｏｃＩＤを登録し、登録順と文書順が一致しないような文書については、第２の文書ＩＤリスト１１５ｂで、当該文書の登録順を示すＤｏｃＩＤと文書順を示す情報（ここでは、当該文書を２つの文書の間に挿入する場合、例えば当該２つの文書のＤｏｃＩＤの中間値）とを登録する。

文書順が予め定められている複数の構造化文書を、この文書順に従って、構造化文書ＤＢ１１１に登録すれば登録順すなわち文書ＩＤと文書順とは一致する。しかし、文書順が１番目の構造化文書を、文書順が２番目の構造化文書を登録した後に登録する場合、文書順が２番目のＤｏｃＩＤが「１」である場合、文書順が１番目のＤｏｃＩＤは「２」となる。すなわち、文書順の番号が大きい方の構造化文書の登録順の番号が小さくなってしまう。そこで、文書順が１番目の構造化文書には、ＤｏｃＩＤ「２」の他に、当該構造化文書の文書順を示す情報として、文書順が当該構造化文書の直前および直後の構造化文書のうちの少なくとも１つのＤｏｃＩＤに対する当該構造化文書の文書順を示す相対値を付与する。この場合、文書順が２番目のＤｏｃＩＤ「１」の構造化文書の直前に文書順が１番目の構造化文書を配置すればよく、そのために、ＤｏｃＩＤ「１」の構造化文書より文書順が前であること示すため、例えば「０．５」や「０．２」などＤｏｃＩＤ「１」よりも小さい値を、ＤｏｃＩＤ「２」の構造化文書の文書順を示す情報として用いる。

また、文書順が１番目の構造化文書と、文書順が３番目の構造化文書とをこの順に構造化文書ＤＢ１１１に登録した後、文書順が２番目の構造化文書を構造化文書ＤＢ１１１に登録する場合を考える。このとき、文書順が１番目の構造化文書、文書順が３番目の構造化文書のＤｏｃＩＤはそれぞれ「１」「２」であるとする。文書順が２番目の構造化文書のＤｏｃＩＤは「３」となる。

この場合、文書順が１番目のＤｏｃＩＤ「１」の構造化文書と、文書順が３番目のＤｏｃＩＤ「１」の構造化文書との間に、文書順が２番目の構造化文書を配置すればよく、そのために、ＤｏｃＩＤ「１」の構造化文書より文書順が後であり、かつ、ＤｏｃＩＤ「２」の構造化文書より文書順が前であること示すため、例えば「１．５」や「１．１」「１．９」などＤｏｃＩＤ「１」よりも大きくＤｏｃＩＤ「２」よりも小さい値を、ＤｏｃＩＤ「３」の構造化文書の文書順を示す情報として用いる。

ＥｌｅｍＩｄは、各ドキュメント内の各要素に割当てられる各ドキュメント内でユニークなＩＤである。ＴＩｄとは、前述したように構造テンプレートデータ内のノードが持つＩＤ、すなわち、テンプレートＩＤである。

例えば、図１０に示すように、「ｒｏｏｔ」ノード３０１、「ｂｏｏｋＦｏｌｄｅｒ」ノード３０２、「ｂｏｏｋ」ノード３０４、「ｂｏｏｋ」ノード３０５をこの順に構造化文書ＤＢ１１１へ登録した場合には、「ｒｏｏｔ」ノード３０１のＤｏｃＩＤは「０」、「ｂｏｏｋＦｏｌｄｅｒ」ノード３０２のＤｏｃＩｄは「１」、「ｂｏｏｋ」ノード３０４のＤｏｃＩＤは「２」、「ｂｏｏｋ」ノード３０５のＤｏｃＩＤは「３」となる。その後、さらに、「ｐａｐｅｒＦｏｌｄｅｒ」ノード３０３や「ｐａｐｅｒ」ノード３０６が構造化文書ＤＢ１１１に登録された場合には、「ｐａｐｅｒＦｏｌｄｅｒ」ノード３０３にＤｏｃＩＤ「４」、「ｐａｐｅｒ」ノード３０６にＤｏｃＩＤ「５」が付与されることになる。このように、ＤｏｃＩｄにより、データファイル中のフォルダやドキュメントファイルをそれぞれ識別することができる。

また、ＤｏｃＩｄが「２」の「ｂｏｏｋ」ノード以下の「ｂｏｏｋ」ドキュメント中の各要素（テキスト要素を含む）には、それぞれ、「０」〜「１４」というＥｌｅｍＩｄが与えられている。このＥｌｅｍＩｄにより、当該ドキュメント内での各要素を識別することができる。このＥｌｅｍＩＤも当該ドキュメント（文書）内の各要素の存在位置に応じて、例えば、図１の構造化データでは、先頭から順番に「０」「１」「２」…とＥｌｅｍＩｄが与えられる。すなわち、図８の「ｂｏｏｋ」ノード３０４以下のドキュメントツリー（階層構造）に示すように、上位階層の要素（同じ階層に複数の要素が存在する場合には、より左側に配置されている要素）から順に深さ優先で各要素にＥｌｅｍＩｄが与えられる。各要素に与えられる要素ＩＤの値は、文書内での当該要素の出現順を表すものと云える。

さらに、ＤｏｃＩｄが「２」の「ｂｏｏｋ」ノード以下の「ｂｏｏｋ」ドキュメント中の各要素（テキスト要素を含む）には、図７に示す構造テンプレート中の当該要素に対応するノードのＴＩｄが与えられている。

このように、ドキュメントファイル内のある要素のＯＩＤを見れば、当該ＯＩＤに含まれるＤｏｃＩｄからは当該ＯＩＤをもつノードを含むドキュメントファイルを識別することができるとともに、当該ＯＩＤをもつノードを含むドキュメントファイルの構造化文書ＤＢ１１１への登録順を識別することができる。当該ＯＩＤに含まれるＴＩｄからは当該ノードの構造テンプレート中の存在位置とノードの種別を識別することができ、ＥｌｅｍＩｄからは当該ノードの当該ドキュメント中の存在位置を識別することができるのである。

例えば、図８の「ｂｏｏｋ」ドキュメント３１１に含まれるテキストノード（テキスト要素）「ＸＭＬデータベース」は、＜２、２、Ｔ４＞というＯＩＤを持っている。このＯＩＤからは、当該テキストノードが属するドキュメント３１１のＤｏｃＩｄは「２」であることがわかる。また、当該テキストノードは、当該ドキュメント３１１内では「２」というＥｌｅｍＩｄを持っている。さらにこのテキストノードは、構造テンプレートデータ内では、図７の「Ｔ４」というＴＩｄを持つノードに対応している。

このように、本実施形態では、構造化文書ＤＢ１１１に格納される構造化文書の各要素は、当該要素が属するフォルダ、ファイルの識別子であるＤｏｃＩｄと、当該要素が属するファイル内で当該要素を識別するためのＥｌｅｍＩｄと、当該要素に対応する構造上の識別子であるＴＩｄとを含むＯＩＤにより識別される。

さらに、構造化文書ＤＢ１１１に格納される構造化文書の各要素は、上記ＯＩＤの他に更新フラグを有している。更新フラグは、構造化文書ＤＢ１１１に登録されている各構造化文書の各要素が更新により追加された要素であるか否かを識別するための情報である。例えば、新たな構造化文書を構造化文書ＤＢ１１１に登録する際には、当該新たな構造化文書の各要素の更新フラグの値は「０」である。既に構造化文書ＤＢ１１１に登録されている任意の構造化文書に対し新たな要素を追加する更新を行った場合、当該新たな要素の更新フラグの値は「１」である。

図９は、本実施形態に関る索引データ記憶部１１４に記憶される索引データのデータ構造を模式的に示したものである。索引データ記憶部１１４は、図５と同様、語彙テーブルと当該語彙テーブル中の各語彙にリンクされた当該語彙を含むテキスト要素のＯＩＤを記録する複数のテーブルが記憶されている。語彙テーブル中の語彙からリンクをたどることで、その語彙を含むテキスト要素の出現位置、つまりＯＩＤが得られる。

図９に示した索引データと図５に示した索引データとの異なる点は、図９に示した索引データでは、ＯＩＤが＜ＤｏｃＩｄ、ＥｌｅｍＩｄ、ＴＩｄ＞と、３つのＩＤで表されている点と、ＯＩＤに更新フラグが付加されている点である。なお、図９では、語彙テーブル中の各語彙にリンクされた当該語彙を含むテキスト要素のＯＩＤ及び更新フラグとを「ＤｏｃＩｄ、ＥｌｅｍＩｄ、ＴＩｄ、更新フラグ」と列挙した形で示している。

構造化文書データ記憶部１１２に格納されている各フォルダ、ドキュメントのＤｏｃＩＤは、文書ＩＤ記憶部１１５に記憶されている。文書ＩＤ記憶部１１５は、第１の文書リスト１１５ａと第２の文書リスト１１５ｂが記憶されている。第１の文書リスト１１５ａには、各文書の内容に基づく文書順（この文書順は、当該文書の格納時にユーザにより指定された格納先により定まる）が登録順のとおりであるような各文書のＤｏｃＩＤが登録されている。第２の文書ＩＤリスト１１５ｂには、文書順が登録順に一致しない文書のＤｏｃＩＤ及び文書順を示す情報が登録されている。文書順が登録順に一致しない文書とは、例えば、登録順が最後であっても、文書順が、ＤｏｃＩＤ「２」の文書とＤｏｃＩＤ「３」の文書の間であるような文書である。

構造化文書データ記憶部１１２では、各構造化文書の各要素に対応するオブジェクトデータをＯＩＤ及び更新フラグとともに格納する。各文書の階層構造を表すオブジェクトデータ間の親子関係を示すリンクは、各オブジェクトデータ内に子要素及び親要素のオブジェクト集合を示すＯＩＤ配列として記憶されている。

（格納処理：新規登録）
次に、図１１に示すような構造化文書Ａ（以下、文書Ａと呼ぶ）を図１０に示したような状態の構造化文書ＤＢ１１１に登録する場合を例にとり、図１２〜図１３に示すフローチャートを参照して、図２の格納処理部１０３の処理動作について説明する。

なお、図１０では、説明の簡単のため、フォルダ、ドキュメントファイルのノードについてのみ、ＯＩＤ及び更新フラグを示している。

クライアント２０１の構造化文書登録部２０２からは、新たに格納すべき文書Ａと、その格納先を示す情報を含む格納要求メッセージが送信される。（ａ１）格納先として、単にフォルダのみが指定されている場合に当該フォルダ内に文書Ａを格納する場合と、（ａ２）フォルダ及び当該フォルダ内に既に格納されている文書の直前に文書Ａを挿入する場合とに分けて説明する。後者は、構造化文書ＤＢ１１１内に既に格納されている文書の順序が変更される場合である。

なお、クライアント２０１では、格納先を次のようにして得ることができる。クライアント２０１の検索部２０３には、例えば、図１０に示すような構造化文書ＤＢ１１１の概略構造を表示するためのＧＵＩを有している。このＧＵＩにより表示された構造からユーザが格納先のフォルダとして「ｂｏｏｋＦｏｌｄｅｒ」ノード３０２を指示したときには、当該ノードに対応するＯＩＤを得るための問合せデータが作成され、サーバ１０１へ送信される。サーバ１０１では、当該問合せデータから、当該指示されたノードのＯＩＤを獲得して、クライアント２０１の検索部２０３へ返す。検索部２０３は、この得られたフォルダのＯＩＤ（これをＯＩＤｐと示す）を格納先として構造化文書登録部２０２へ渡す。

また、上記ＧＵＩにより表示された構造からユーザが、文書Ａの文書順が図１０の「ｂｏｏｋＦｏｌｄｅｒ」ノード３０２の子要素として格納されているドキュメント３１１とドキュメント３１２の間にするために、例えば、「ｂｏｏｋＦｏｌｄｅｒ」ノード３０２の子要素として格納されているドキュメント３１１とドキュメント３１２の間を格納先として指示したときには、ドキュメント３１１とドキュメント３１２のそれぞれのルートノード３０４、３０５に対応するＯＩＤを得るための問合せデータが作成され、サーバ１０１へ送信される。サーバ１０１では、当該問合せデータから、当該各ルートノードのＯＩＤを獲得して、クライアント２０１の検索部２０３へ返す。検索部２０３は、この得られた各ＯＩＤ（これをＯＩＤｐ（１）、ＯＩＤｐ（２）と示す）を格納先として構造化文書登録部２０２へ渡す。

まず、上記（ａ１）の場合について説明する。

サーバ１０１の要求処理部１０２では、文書Ａと格納先のフォルダのＯＩＤｐを含む格納要求メッセージを受け取る（ステップＳ１）。ここでは、例えば、「ｂｏｏｋＦｏｌｄｅｒ」３０２に対応するＯＩＤ（＜１，０，Ｆ１＞）が格納先のフォルダＯＩＤとして指定され、このフォルダ下に新たに文書Ａを格納するケースを考える。

格納要求メッセージに含まれる、格納すべき構造化文書データ、すなわち文書Ａが、格納処理部１０３の構造化文書構文解析部３１へ渡されて、当該文書Ａの構文解析が行われる。その結果得られるものは、文書Ａの複数のオブジェクトデータからなる階層構造であり、メモリ上に展開される（ステップＳ２）。すなわち、構造化文書構文解析部３１は、ＸＭＬデータである構造化文書データに対し、構文解析処理を行うことによりＤＯＭ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）形式のオブジェクトデータに展開するＸＭＬパーサに相当する機能を有するものである。

さらに、文書ＩＤ記憶部１１５に記憶されているＤｏｃＩＤを参照して、当該文書Ａに対し、新たなドキュメントＩＤ（ＤｏｃＩＤ）を付与する（ステップＳ３）。この（ａ１）の場合、文書Ａの新規登録であり、当該文書Ａには、ＤｏｃＩＤをまだ付与されていない。また、格納先としてフォルダが指定されており、文書順を変更する登録ではない。

図１０に示した状態の構造化文書ＤＢ１１１の場合の、文書ＩＤ記憶部１１５に記憶されている第１及び第２の文書ＩＤリスト１１５ａ、１１５ｂを図１４に示す。図１４に示すように、第１の文書ＩＤリスト１１５ａには、ＤｏｃＩＤが既に「５」まで登録されて（使用されている）、第２の文書ＩＤリスト１１５ｂには１つもＤｏｃＩＤが登録されていないから、文書ＡのＤｏｃＩＤは「６」となる。従って、図１５に示すように、第１の文書ＩＤリスト１１５ａに、文書ＡのＤｏｃＩＤ「６」が登録される。

次に、構造化文書構造抽出部３２は、構造化文書構文解析部３１での解析結果をそのルートから辿ることによって、文書Ａの構造、すなわち、当該文書Ａ中の各要素に対応する複数のードと、当該複数のノードからなる構造を抽出する。文書Ａの構造をＳｃとする（ステップＳ４）。

構造化文書構造照合部３３は、格納先フォルダのＯＩＤｐをキーに構造テンプレート記憶部１１３から構造を取得する。ここでは、ＯＩＤｐが＜１，０，Ｆ１＞であるので、まず、ＴＩＤ「Ｆ１」を取得する。このＯＩＤｐから取得したＴＩＤをＴＩＤｐと表す。構造化文書構造照合部３３は、ＴＩＤｐをキーにして構造テンプレート記憶部１１３をスキャンすることで、対応する構造を取得できる（ステップＳ５）。取得した構造をＳｐとする（ステップＳ６）。

構造化文書構造照合部３３は、ＳｃとＳｐの照合を行う（ステップＳ７）。これはツリーの単純なマッチングである。すなわち、Ｓｃの構造要素に対応するＳｐの構造要素があれば、当該Ｓｃの構造要素に当該Ｓｐの構成要素のＴＩｄを付与する。Ｓｃの構造要素に対応するＳｐの構造要素がなければ、Ｓｐに存在せずに、Ｓｃに存在する新たな要素に新たなＴＩｄを付与し、Ｓｐに当該新たな要素を追加する。また、Ｓｃの当該新たな要素に当該新たなＴＩｄを付与する。この操作をＳｃの全ての構造要素に対し行う。

文書Ａは新規に登録されるから（ステップＳ８）、構造化文書構造照合部３３は、Ｓｃの各要素に要素ＩＤ（ＥｌｅｍＩＤ）を付与する（ステップＳ９）。例えば、Ｓｃの構造をルートノードから下流方向へ辿りながら、各要素に対しＥｌｅｍＩＤを付与する。

以上の処理により、当該Ｓｃ内の各要素に対し、＜ＤｏｃＩｄ，ＥｌｅｍＩＤ，ＴＩｄ＞という構成のＯＩＤが与えられたことになる。すなわち、文書ＡのルートノードのＯＩＤは、＜ＤｏｃＩｄ，０，ＴＩｄ＞＝＜６，０、Ｄ２＞となっている。また、文書Ａは新規に登録されるから、Ｓｃの各要素には、ＯＩＤの他に更新フラグ「０」が付与される（ステップＳ１０）。

最後に、構造化文書格納部３４は、更新されたＳｐを構造テンプレート記憶部１１３に格納する。これにより、構造テンプレート記憶部１１３に格納される構造テンプレートの更新がなされる。

また、構造化文書格納部３４は、Ｓｃを構成する複数の要素のうち、テキスト要素を基に、索引データ記憶部１１４を更新する（図１３のステップＳ１１）。ここで、テキスト要素のテキストデータから語彙（文字列）を抽出し、抽出した語彙が図９に示すような語彙テーブル中に無ければ、それを追加する。そして、各テキスト要素のＯＩＤ及び更新フラグを、当該テキスト要素のテキストデータに含まれる語彙テーブル中の語彙にリンクして記憶する。

さらに、構造化文書格納部３４は、構造化文書データ記憶部１１２内をスキャンすることで、格納先のＯＩＤｐに対応するオブジェクトを取得し、当該オブジェクトデータの子要素のオブジェクトの集合を示すＯＩＤ配列に、当該文書ＡのルートノードのＯＩＤを追加する。すなわち、構造化文書データ記憶部１１２に、各要素に上記のようなＯＩＤ及び更新フラグの付された文書Ａが、ＯＩＤｐが＜１，０，Ｆ１＞の「ｂｏｏｋＦｏｌｄｅｒ」３０２の直下の最後に追加される形で、文書Ａが格納される（ステップＳ１２）。図１６は、文素Ａを格納した後の構造化文書データ記憶部１１２のデータ構造を模式的に表したもので、文書順（この場合は登録順と同じ）に、フォルダと各文書のルートノードのみを示し、各文書の階層構造は省略して示している。

次に、上記（ａ２）の場合について説明する。

サーバ１０１の要求処理部１０２では、文書Ａと格納先のＯＩＤｐ（ＯＩＤｐ（１）、ＯＩＤｐ（２））を含む格納要求メッセージを受け取る（ステップＳ１）。ここでは、例えば、ドキュメント３１１，３１２のルートノード３０４，３０５に対応するＯＩＤ（＜２，０，Ｄ２＞、＜３，０，Ｄ２＞）が格納先のＯＩＤｐとして指定され、文書Ａの文書順がこの２つの文書の間となるように、新たに文書Ａを格納するケースを考える。

上記（ａ１）の場合と同様に、図１２のステップＳ２において、文書Ａの複数のオブジェクトデータからなる階層構造を求めた後、ステップＳ３において、当該文書Ａに対し、新たなドキュメントＩＤ（ＤｏｃＩＤ）を付与する。この（ａ２）の場合、文書Ａの文書順は登録順（番号）とは異なる。

図１０に示した状態の構造化文書ＤＢ１１１の場合、図１４に示すように、第１の文書ＩＤリスト１１５ａには、ＤｏｃＩＤが既に「５」まで登録されて（使用されている）、第２の文書ＩＤリスト１１５ｂには１つもＤｏｃＩＤが登録されていないから、文書ＡのＤｏｃＩＤは「６」となる。しかし、格納先として指定されている位置は、図１０のＤｏｃＩＤが「２」のドキュメント３１１、ＤｏｃＩＤが「３」のドキュメント３１２の間である。すなわち、文書順と登録順とは一致しない。この場合には、文書Ａの文書順を、ＤｏｃＩＤ「２」と「３」の間の中間の値、例えば、「２．５」とする。そして、文書ＡのＤｏｃＩＤ「６」と文書順「２．５」とを１組にして、図１７に示すように、第２の文書ＩＤリスト１１５ｂに登録する。

以下の処理は、前述の（ａ１）の場合と同様である。

そして、図１３のステップ１２では、構造化文書格納部３４は、構造化文書データ記憶部１１２内をスキャンすることで、格納先の２つのＯＩＤｐ＜２，０，Ｄ２＞＜３，０，Ｄ２＞の上位階層のフォルダに対応するオブジェクト（この場合、ＯＩＤ＜１，０，Ｆ１＞の「ｂｏｏｋＦｏｌｄｅｒ」）を取得し、当該オブジェクトデータの子要素のオブジェクトの集合を示すＯＩＤ配列に、当該文書ＡのルートノードのＯＩＤを追加する。すなわち、構造化文書データ記憶部１１２に、各要素に上記のようなＯＩＤ及び更新フラグの付された文書Ａが、ＯＩＤｐが＜１，０，Ｆ１＞の「ｂｏｏｋＦｏｌｄｅｒ」３０２の直下の最後に追加される形で、文書Ａが格納される（ステップＳ１１）。図１８は、文素Ａを格納した後の構造化文書データ記憶部１１２のデータ構造を模式的に表したもので、文書順（この場合は登録順とは異なる）に、フォルダと各文書のルートノードのみを示し、各文書の階層構造は省略して示している。

図１９は、文書Ａの複数のオブジェクトデータからなる階層構造を示したものである。

図２０は、構造化文書データ記憶部１１２での各構造化文書の記憶方法を説明するための図である。各構造化文書の各要素に対応するオブジェクトデータは、図２０に示すように、ＯＩＤ及び更新フラグとともに格納されている。なお、図２０では、各オブジェクトデータに含まれる、各文書内のオブジェクトデータ間の親子関係を表す、子要素及び親要素のオブジェクト集合を示すＯＩＤ配列は省略して示している。

構造化文書データ記憶部１１２に記憶された文書のうち、登録順と文書順が異なる文書のＤｏｃＩＤについては、その文書順を示す情報とともに、図１７に示すように、文書ＩＤ記憶部１１５の第２の文書ＩＤリスト１１５ｂに登録されている。

（格納処理：更新）
次に、図１８に示したように、構造化文書ＤＢ１１１に登録されている文書Ａに対し、更新を行う場合について説明する。

クライアント２０１は、既に構造化文書ＤＢ１１１に登録されている文書Ａを次のようにして得ることができる。クライアント２０１の検索部２０３には、例えば、図１８に示すような構造化文書ＤＢ１１１の概略構造を表示するためのＧＵＩを有している。このＧＵＩにより表示された構造からユーザが文書Ａを指定すると、文書Ａを得るための問合せデータが作成され、サーバ１０１へ送信される。サーバ１０１では、当該問合せデータから、当該指示された文書Ａ（及びそのルートノードのＯＩＤ等）を獲得して、クライアント２０１の検索部２０３へ返す。検索部２０３は、この得られた文書Ａを表示部２０５に表示する。

ユーザは、表示部２０５に表示された文書Ａに対して、図２１に示すように更新を行う。すなわち、「＜ａｕｔｈｏｒ＞ ＜ｆｉｒｓｔ＞太郎＜／ｆｉｒｓｔ＞ ＜ｌａｓｔ＞山田＜／ｌａｓｔ＞ ＜／ａｕｔｈｏｒ＞」を＜ａｕｔｈｏｒｓ＞の直下に挿入したとする。図２１に示すような更新された文書Ａを文書Ａ´とも呼ぶ。

以下、図１２〜図１３に示すフローチャートを参照して、説明する。

サーバ１０１の要求処理部１０２では、更新された文書Ａと文書ＡのルートノードのＯＩＤ等を含む更新要求メッセージを受け取る（ステップＳ１）。ここでは、文書ＡのＯＩＤをＯＩＤｐとする。

更新要求メッセージに含まれる、更新された文書Ａ（文書Ａ´）が、格納処理部１０３の構造化文書構文解析部３１へ渡されて、当該文書Ａ´の構文解析が行われる。その結果得られるものは、文書Ａ´の複数のオブジェクトデータからなる階層構造であり、メモリ上に展開される（ステップＳ２）。すなわち、構造化文書構文解析部３１は、ＸＭＬデータである構造化文書データに対し、構文解析処理を行うことによりＤＯＭ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）形式のオブジェクトデータに展開するＸＭＬパーサに相当する機能を有するものである。

ステップＳ３では、文書Ａ´にＤｏｃＩＤを付与するが、文書Ａ´のルートノードには、既にＯＩＤ＜６，０，Ｄ２＞が与えられているので、新たにＤｏｃＩＤを付与することなく、次に、ステップＳ４へ進む。

ステップＳ４では、構造化文書構造抽出部３２は、構造化文書構文解析部３１での解析結果をそのルートから辿ることによって、文書Ａ´の構造、すなわち、当該文書Ａ´中の各要素に対応する複数のードと、当該複数のノードからなる構造を抽出する。文書Ａ´の構造をＳｃとする（ステップＳ４）。

構造化文書構造照合部３３は、文書Ａ´のルートノードであるＯＩＤｐをキーに構造テンプレート記憶部１１３から構造を取得する。ここでは、ＯＩＤｐが＜６，０，Ｄ２＞であるので、まず、ＴＩＤ「Ｄ２」を取得する。このＯＩＤｐから取得したＴＩＤをＴＩＤｐと表す。構造化文書構造照合部３３は、ＴＩＤｐをキーにして構造テンプレート記憶部１１３をスキャンすることで、対応する構造を取得できる（ステップＳ５）。取得した構造をＳｐとする（ステップＳ６）。なお、Ｓｐは、図７のＴＩＤ「Ｄ２」以下の構造である。

構造化文書構造照合部３３は、ＳｃとＳｐの照合を行う（ステップＳ７）。ここでは、新たなに追加された各要素（ノード）について、当該要素に対応するＳｐの構造要素があれば、当該要素に当該Ｓｐの構成要素のＴＩｄを付与する。Ｓｃの構造要素に対応するＳｐの構造要素がなければ、Ｓｐに存在せずに、Ｓｃに存在する新たな要素に新たなＴＩｄを付与し、Ｓｐに当該新たな要素を追加する。また、Ｓｃの当該新たな要素に当該新たなＴＩｄを付与する。この操作を、更新により新たに追加された（ＴＩＤが与えられていない）Ｓｃの各構造要素に対し行う。

文書Ａの更新であるから（ステップＳ８）、構造化文書構造照合部３３は、更新により新たに追加された（要素ＩＤの与えられていない）Ｓｃの各要素に要素ＩＤ（ＥｌｅｍＩＤ）を付与する（ステップＳ１３）。また、文書Ａ´の更新により新たに追加された各要素に更新フラグ「１」が付与される（ステップＳ１４）。

以上の処理により、図２２に示すように、当該Ｓｃ内の更新により新たなに追加された各要素に対し、ＯＩＤと更新フラグ「１」が与えられたことになる。

最後に、構造化文書格納部３４は、更新されたＳｐを構造テンプレート記憶部１１３に格納する。これにより、構造テンプレート記憶部１１３に格納される構造テンプレートの更新がなされる。

また、構造化文書格納部３４は、更新により新たに追加されたＳｃの要素のうち、テキスト要素を基に、索引データ記憶部１１４を更新する（図１３のステップＳ１１）。

さらに、構造化文書格納部３４は、文書ＡのルートノードであるＯＩＤｐをキーに、構造化文書データ記憶部１１２内をスキャンすることで、文書Ａの格納位置を得、図２３に示すように、当該格納位置に、更新により新たに追加された各要素に対応する新たなオブジェクトデータを追加するとともに、新たなオブジェクトデータと既存のオブジェクトデータ間のリンクを更新し、元の文書Ａを図２２に示すような文書Ａ´に更新する（ステップＳ１２）。

要素ＩＤは、上位階層の要素（同じ階層に複数の要素が存在する場合には、より左側に配置されている要素）から順に深さ優先で各要素に与えられる番号であるが、更新により文書Ａに新たに追加された「ａｕｔｈｏｒ」ノード以下の要素ＩＤが「１１」〜「１５」の各要素の文書Ａ´内での出現位置は、図２２に示すように、要素ＩＤが「４」〜「８」の「＜ａｕｔｈｏｒ＞ ＜ｆｉｒｓｔ＞花子＜／ｆｉｒｓｔ＞ ＜ｌａｓｔ＞山田＜／ｌａｓｔ＞ ＜／ａｕｔｈｏｒ＞」よりも先である。しかも、出現順が後の要素よりも大きい値の要素ＩＤが与えられている。すなわち、文書内に要素を追加するなどの更新を行うことにより、要素ＩＤが当該要素の文書内での出現順に一致しない状態が発生する。

更新フラグは、文書内で更新された要素については、当該要素の要素ＩＤが当該文書内での出現順に一致しない可能性があることを示すために更新フラグを「１」とする。

（検索処理）
次に、図２の検索処理部１０４の処理動作について説明する。

図２４は、検索処理部１０４に入力する問合せデータの一例を示したものである。ＸＭＬでは、ＸＱｕｅｒｙ（ＸＭＬ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）という問合せ言語があり、それに基づいた問合せ記述方法に則っている。

図２４に示す問合せデータには、「構造化文書ＤＢ「ＤＢ」の階層木の中に「ｂｏｏｋ」という要素がある。その中に「山田」という文字列を含むテキスト要素をもつ「ｌａｓｔ」という要素がある」という条件が記述されている。

図２４に示すような問合せデータは、クライアント２０１の検索部２０３からサーバ１へ送信され、サーバ１０１の要求処理部１０２で受信される。

以下、図２５〜図２６に示すフローチャートを参照して、例えば、図２４に示したような問合せデータを受信した検索処理部１０４が、図１８に示したような状態の構造化文書データ記憶部１１２から文書を検索する場合の処理動作の概略を説明する。

要求処理部１０２で受信された問合せデータは、検索処理部１０４の問合せ構文解析部４１に渡される。問合せ構文解析部４１では、受け取った問合せデータの構文解析を行い（ステップＳ１０１）、その結果を基に、問合せ構造抽出部４２では、当該問合せデータから、問合せグラフと呼ばれるグラフ構造を抽出する（ステップＳ１０２）。例えば、図２４に示した問合せデータの場合、図２７に示すような問合せグラフが得られる。ここでは、問合せグラフで表されるような問合せデータ中の構造をＳｃと表す。

問合せグラフは、図２７に示すように、問合せデータ中に含まれる要素名（例えば、「ｄｂ“ＤＢ”」、「ｂｏｏｋ」、「ｌａｓｔ」）、や文字列（「山田」）にそれぞれ対応する変数と、各変数を、問合せデータ中に含まれる要素と文字列の包含関係に従って接続して構成されている。

次に、問合せ構造照合部４３は、構造化文書ＤＢ１１１の構造テンプレート記憶部１１３から構造を取り出す。取り出した構造をＳｐと表す。ここでは、例えば、問合せデータ中で指定された、構造化文書データベースの階層木の最も上流にある要素、すなわち、「ｂｏｏｋ」という要素以下の構造を抽出する。そして、この取り出した構造Ｓｐと先ほどのＳｃとの照合を行う。その結果、Ｓｃの各要素に対して、取り得るＴＩＤを割当てる（ステップＳ１０３）。

問合せ実行部４４は、問合せグラフに含まれる全ての変数の具体化を目標として、テーブルと呼ばれる変数集合の取り得る値の組み合わせを表すデータを次々と生成する。ここでは、１つのテーブルを生成する単位処理をオペレータと呼ぶ。

まず、問合せグラフに含まれる全ての変数が１テーブルで具体化されているか判定する（ステップＳ１０４）。Ｙｅｓであれば、全ての変数の取り得る値の組合せが具体化されたので、ステップＳ１２１へ進む。なお、変数が取り得る値とは、ＯＩＤのことである。

以下、問合せグラフに含まれる全ての変数が１テーブルで具体化されていないならば、そうなるまで、ステップＳ１０５〜ステップＳ１１０を繰り返す。

ステップＳ１０５では、索引データ記憶部１１４に記憶されている索引データを用いた検索が可能か判定する。「ｃｏｎｔａｉｎｓ」など語彙索引系の関数があれば、構造化文書ＤＢ１１中の索引データを用いて検索を高速化できる。その場合ＬｅｘｉｃａｌＳｃａｎＷｉｔｈＴｉｄオペレータを実行する。

図２６のステップＳ１０６では、親ドキュメント取得操作が可能か判定する。子要素ＯＩＤから親ドキュメントルートＯＩＤをダイレクトに取り出すことができれば、ＧｅｔＤｏｃｕｍｅｎｔオペレータを実行する。

ステップＳ１０７では、複数テーブルに同一変数が発生しているか判定する。その場合は２つのテーブル毎にＪｏｉｎオペレータを実行する。

ステップＳ１０８では、値を取得すべき変数がすべて具体化されており、問合せの先頭にあるデータベースのルートを指定する「ｄｂ（）」しか残っていなければ、Ｎｏｐオペレータ（無操作）を実行する。

ステップＳ１０９では、任意の２変数の上位階層にある変数に対してドキュメント型ＴＩＤが割当てられており、その２変数の値が具体化されていれば、ＦｉｌｔｅｒＤｏｃｕｍｅｎｔオペレータを実行する。

ステップＳ１１０では、変数の上位階層に変数があり、下位階層にある変数が具体化されていて上位階層にある変数が具体化されていなければ、ＳｃａｎＡｎｃｅｓｔｏｒＷｉｔｈＴＩｄオペレータを実行する。

ステップＳ１１１では、結果出力処理を行う。ここで各変数の取り得る値の組合せがテーブルとして得られている。その要素を変形することで問合せデータに合致する構造化文書データ集合を得ることができる。

図２７に示した問合せグラフでは、変数は、丸で囲まれたノードで表されており、丸のなかに変数名が記述されている。これを変数ノードと呼ぶ。また、問合せデータ中に指定されていた要素は、六角形のなかに「ＴＡＧ」と書かれたノードで表されている。これをタグノードと呼ぶ。さらに、問合せデータ中に指定されていた文字列は、六角形のなかに「ＶＡＬＣＭＰ」と書かれたノードで表されている。これを値比較タグノードと呼ぶ。

図２８は、図２５のステップＳ１０３で付与された、図２４の問合せグラフ中の各変数に対応するＴＩＤを示したものである。

図２９は、図２７の問合せグラフに基づき検索を行う際に用いられるオペレータ系列を示したものである。図３０は図２９のオペレータ系列をオペレータ入出力という観点で視覚化した図である。

図２８に示すように、構造化文書ＤＢ「ＤＢ」の階層木の中の「ｂｏｏｋ」要素のなかの「ｌａｓｔ」要素に含まれるテキスト要素のＴＩＤは、図７に示す構造テンプレートからも明らかなように、「Ｔ１０」であり、構造化文書ＤＢ「ＤＢ」の階層木の中の「ｂｏｏｋ」要素のＴＩＤは、図７に示す構造テンプレートからも明らかなように、「Ｄ２」であり、構造化文書ＤＢ「ＤＢ」の階層木のルートノードは、図７に示す構造テンプレートからも明らかなように、「Ｆ０」である。

図２９（ａ）に示すように、ＬｅｘｉｃａｌＳｃａｎＷｉｔｈＴｉｄオペレータにより、「山田」という文字列を含むテキスト要素であって、ＴＩＤが「Ｔ１０」であるＯＩＤ集合を得る（図３０（ａ）参照）。索引データ記憶部１１４には、各文書に含まれる語彙と、当該語彙を含むオブジェクトデータのＯＩＤ及び更新フラグが、当該文書の登録順に登録されるため、ＬｅｘｉｃａｌＳｃａｎＷｉｔｈＴｉｄオペレータにより得られるＯＩＤも文書の登録順に取得される。すなわち、図３０（ａ）に示すように、最初にＯＩＤ＜３，８，Ｔ１０＞更新フラグ「０」を取得し、次にＯＩＤ＜６，８，Ｔ１０＞更新フラグ「０」を取得する。

変数Ｖ２のＴＩＤがドキュメント｛Ｄ２｝なので、変数Ｖ１に関し、親ドキュメント取得操作が可能である。ＧｅｔＤｏｃｕｍｅｎｔオペレータを実行する。ここで変数Ｖ２が具体化する。

ＧｅｔＤｏｃｕｍｅｎｔオペレータは、入力パラメータとして与えられたＯＩＤ集合に対して、当該ＯＩＤ集合の各ＯＩＤと同じ文書中の上流のノードのＯＩＤ集合を返す。ここで、構造化文書データの文書構造を辿るのではなく、当該与えられたＯＩＤから、その上流ノードのＯＩＤへと変換を行っている。つまり、ＧｅｔＤｏｃｕｍｅｎｔオペレータは、問合せデータに発生する構造を考慮したため、構造化文書ＤＢ中のデータファイルをスキャンする必要が無い。そのため、ディスクＩ／Ｏなど処理コストが小さくて済む。

図３０（ｂ）に示すように、ＧｅｔＤｏｃｕｍｅｎｔオペレータにより、ＯＩＤ＜３，８，Ｔ１０＞を、当該ＯＩＤの要素の上流のノードであって、ＴＩＤが「Ｄ２」であるノードのＯＩＤに変換する。すなわち、ＯＩＤ＜３，０，Ｄ２＞を得る。また、ＯＩＤ＜６，８，Ｔ１０＞を、当該ＯＩＤの要素の上流のノードであって、ＴＩＤが「Ｄ２」であるノードのＯＩＤに変換する。すなわち、ＯＩＤ＜６，０，Ｄ２＞を得る。また、得られたＯＩＤ＜３，０，Ｄ２＞、＜６，０，Ｄ２＞について、構造化文書データ記憶部１１２をスキャンして、それぞれのオブジェクトデータから更新フラグを得る。

次に、変数Ｖ０は出力オペレータではないので、Ｎｏｐオペレータを実行する。

以上で、問合せグラフに含まれる全ての変数が１テーブルで具体化されたので（ステップＳ１０４）、図２５のステップＳ１２１へ進む。

なお、図３０（ｂ）に示したテーブルの２行目以下の各行は、検索結果である１つの「ｂｏｏｋ」ドキュメントに対応する。

ステップＳ１２１では、問合せ実行部４４がテーブル内の行を文書順、同じ文書については文書内の各要素の出現順にソーティングする。

ソーティングは、ＤｏｃＩＤ、ＴＩＤ、ＥｌｅｍＩＤの順でチェックする。

図３０（ｂ）に示したテーブルの場合、まず、検索結果として得られた各文書のＤｏｃＩＤを比較する。１番目の文書のＤｏｃＩＤは「３」、２番目の文書のＤｏｃＩＤは「６」である。問合せ実行部４４は、図１７に示したような、文書ＩＤ記憶部１１５に記憶されている第１の文書ＩＤリスト１１５ａと第２の文書ＩＤリスト１１５ｂとを参照して、これら２つの文書順を認識する。すなわち、ＤｏｃＩＤは「３」は第１の文書ＩＤリスト１１５ａに登録されているが、ＤｏｃＩＤは「６」は第２の文書ＩＤリスト１１５ｂに登録されており、文書順を示す情報が「２．５」である。従って、ＤｏｃＩＤ「６」の文書は、文書順がＤｏｃＩＤ「３」の文書よりも先であることを認識する。そこで、図３０（ｂ）のテーブル上の１番目の検索結果と２番目の検索結果とを入れ替えて、図３０（ｃ）に示すようテーブルを得る。

図３０（ｃ）に示すテーブルでは、これ以上ソーティングの余地はないので、このテーブル上の各文書が、この順番に検索結果として問合せ実行部４４から出力される（ステップＳ１２２）。検索結果は、要求処理部１０２から検索要求元のクライアント２０１へ渡される。クライアント１０２では、サーバ１０１から受け取った構造化データを表示部２０５へ表示する。

上記例では、問合せグラフに含まれる全ての変数が１テーブルで具体化された後に、ソーティングを行う場合を示したが、この場合に限らず、例えば、ＬｅｘｉｃａｌＳｃａｎＷｉｔｈＴｉｄオペレータにより得られるＯＩＤの集合に対してソーティングを行うようにしてもよい。

例えば、図２４に示す問い合せデータを用いて、文書Ａを更新した後の図１８に示したような状態の構造化文書ＤＢ１１１から検索を行う場合を例にとり説明する。

「ｌａｓｔ」要素に含まれるテキスト要素のＴＩＤは、図７に示す構造テンプレートからも明らかなように、「Ｔ１０」である。ＬｅｘｉｃａｌＳｃａｎＷｉｔｈＴｉｄオペレータにより、「山田」という文字列を含むテキスト要素であって、ＴＩＤが「Ｔ１０」であるＯＩＤ集合を得ると、図３１（ａ）に示すように、文書３１２の「ＯＩＤ＜３，８、Ｔ１０＞、更新フラグ「０」」（図８参照）、文書Ａ´の「ＯＩＤ＜６，８、Ｔ１０＞、更新フラグ「０」」（図２２参照）、同じく文書Ａ´の「ＯＩＤ＜６，１５、Ｔ１０＞、更新フラグ「１」」（図２２参照）がこの順に得られる。これは、索引データ記憶部１１４には、各文書の各要素に含まれる語彙と、当該語彙を含むオブジェクトデータのＯＩＤ及び更新フラグが、当該文書及び当該要素の登録順に登録されるため、ＬｅｘｉｃａｌＳｃａｎＷｉｔｈＴｉｄオペレータにより得られるＯＩＤも文書や要素の登録順に取得されるからである。

図３１（ａ）に示したテーブルの場合、まず、検索結果として得られた各文書のＤｏｃＩＤを比較する。１番目の文書のＤｏｃＩＤは「３」、２番目、３番目の文書のＤｏｃＩＤは「６」である。問合せ実行部４４は、図１７に示したような、文書ＩＤ記憶部１１５に記憶されている第１の文書ＩＤリスト１１５ａと第２の文書ＩＤリスト１１５ｂとを参照して、これら２つの文書順を認識する。すなわち、ＤｏｃＩＤは「３」は第１の文書ＩＤリスト１１５ａに登録されているが、ＤｏｃＩＤは「６」は第２の文書ＩＤリスト１１５ｂに登録されており、文書順を示す情報が「２．５」である。従って、ＤｏｃＩＤ「６」の文書は、文書順がＤｏｃＩＤ「３」の文書よりも先であることを認識する。そこで、図３０（ａ）のテーブル上の１番目の検索結果と、２番目の検索結果とを入れ替え、さらに、３番目の検索結果とも入れ替えて、図３０（ｂ）に示すようテーブルを得る。

次に、各ＯＩＤのＴＩＤを比較する。この場合、ＴＩＤは全て「Ｔ１０」で同一であるから、次に、要素ＩＤを比較する。図３１（ｂ）の１番目と２番目のＯＩＤの要素ＩＤは「８」、「１５」であるが、２番目のＯＩＤの更新フラグは「１」である。

このように、同じ文書内の比較対象の２つのＯＩＤのうちの少なくとも１つの更新フラグ「１」である場合には、（例えば図２２に示した２つの「ａｕｔｈｏｒ」要素のように、）要素ＩＤの値が小さい方の要素でも、当該要素の当該文書内での出現位置は要素ＩＤの値が大きい方の要素よりも後である可能性もある。そこで、このような場合には、問合せ実行部４４は、構造化文書データ記憶部１１２にアクセスして、当該文書の各オブジェクトデータ間のリンクを辿ることで、当該文書内の当該２つの要素の出現位置を認識する。

文書Ａ´の場合、図２２に示すような階層構造を有しているから、要素ＩＤ「１５」の要素の方が、要素ＩＤ「８」の要素よりも出現順が先である。従って、図３１（ｂ）に示したテーブル中の番目と２番目を入れ替えて、図３１（ｃ）に示すようなテーブルを得る。

なお、同じ文書内の比較対象の２つのＯＩＤのうちのいずれにも更新フラグが「０」である場合には、要素ＩＤの値の大小を比較するだけでよい。

図３１（ｃ）に示したテーブルについて、ＧｅｔＤｏｃｕｍｅｎｔを実行することにより、図３１（ｄ）に示したようなテーブルが得られる。このテーブル上の３つの行には、文書順、同じ文書の場合には、当該文書内での要素の出現順に３つの検索結果が記述されている。

図３１（ｄ）に示すテーブルでは、これ以上ソーティングの余地はないので、このテーブル上の各文書が、この順番に検索結果として問合せ実行部４４から出力される（ステップＳ１２２）。検索結果は、要求処理部１０２から検索要求元のクライアント２０１へ渡される。クライアント１０２では、サーバ１０１から受け取った構造化データを表示部２０５へ表示する。

なお、構造化文書データ記憶部１１２に記憶されている複数の構造化文書のＯＩＤに、これら複数の構造化文書の順番を示す数値（これを指標と呼ぶ）が予め付加されている場合は、この指標値の大小関係に基づきソーティングを行ってもよい。この場合、文書ＩＤ記憶部１１５に文書ＩＤとともに登録される文書順と示す情報（相対値）参照することなくソーティングすることができる。

また、構造化文書データ記憶部１１２に記憶されている任意の構造化文書に含まれる複数の要素に、これら複数の要素の順番を示す数値（これを指標と呼ぶ）が予め付加されている場合は、この指標値の大小関係に基づきソーティングを行ってもよい。この場合、上記複数の要素のうちの少なくとも１つの更新フラグが「１」であっても、構造化文書データ記憶部１１２にアクセスすることなくソーティングすることができる。

（まとめ）
以上説明したように、上記実施形態によれば、複数の要素を含み、各要素は当該要素を識別するためのテンプレートＩＤを有する構造テンプレートを構造テンプレート記憶部１１３に記憶するとともに、上記複数の要素のうちのいずれか１つのテンプレートＩＤがそれぞれ割り振られた複数の要素データをそれぞれ含み、文書順が予め定められている複数の構造化データを構造化文書データ記憶部１１２に記憶しておく。

さらに、構造化文書データ記憶部１１２に記憶された各構造化文書に与えられた各構造化文書を識別するための文書ＩＤであって、当該構造化文書が構造化文書データ記憶部１１２により記憶された順番を示す番号を文書ＩＤ記憶部１１５に記憶し、当該順番と文書順とが異なる構造化文書の場合には、文書順が当該構造化文書の直前の構造化文書及び直後の構造化文書のうちの少なくとも１つの文書ＩＤに対する当該構造化文書の文書順を示す相対値（例えば、直前の構造化文書の文書ＩＤと直後の構造化文書の文書ＩＤの中間値）とともに当該構造化文書の文書ＩＤを文書ＩＤ記憶部１１５に記憶する。

所望の要素データを検索するための検索条件が入力されると、検索処理部１０４は、上記構造テンプレート上の各要素のテンプレートＩＤを基に構造化文書データ記憶部１１２に記憶されている複数の構造化文書のなかから、上記検索条件を満たす要素データを含む複数の構造化文書を検索する。そして、検索された複数の構造化文書のうち文書ＩＤ記憶部１１５で相対値が記憶されている構造化文書の場合には当該相対値を用い、文書ＩＤ記憶部１１５で相対値が記憶されていない構造化文書の場合には文書ＩＤを用いて、これらの大小関係に基づき、当該検索された複数の構造化文書を文書順に並び替えることにより、検索結果として得られた複数の構造化文書を、構造化文書データ記憶部１１２への登録順ではなく、各構造化文書の内容に基づく文書順に従ってユーザに提示することができる。

また、検索処理部１０４で、１つの構造化文書から複数の所望の要素データが検索される場合がある。このような場合、文書順に並び替えた検索された複数の構造化文書のうち、同一の文書ＩＤをもつ構造化文書については、さらに、当該構造化文書内での当該複数の所望の要素データの出現順に基づき並び替えることにより、検索結果として得られた複数の構造化文書を文書順に、しかも同一文書ＩＤの構造化文書については、当該構造化文書内での複数の所望の要素データの出現順に従ってユーザに提示することができる。

本発明の実施の形態に記載した本発明の手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フレキシブルディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、半導体メモリなどの記録媒体に格納して頒布することもできる。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組合せにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

構造化文書データの一具体例を示した図。 本発明の実施形態に係る構造化文書管理システムの機能的な構成例を示した図。 サーバのハードウエア的な構成例を示した図。 構造化文書データ記憶部のデータ構造を模式的に表した図。 従来の構造化文書ＤＢの構成例を示した図。 本発明の実施形態に関る構造化文書ＤＢの構成例を示した図。 構造テンプレート記憶部に記憶されている構造テンプレートデータの一例を示した図。 構造化文書データ記憶部に格納されている構造化文書データの記憶例を模式的に示した図。 索引データ記憶部に記憶される索引データのデータ構造を模式的に示した図。 構造化文書データ記憶部のデータ構造を模式的に表した図。 構造化文書データ（文書Ａ）の一具体例を示した図。 格納処理部の処理動作を説明するためのフローチャート。 格納処理部の処理動作を説明するためのフローチャート。 文書ＩＤ記憶部での文書ＩＤ（ＤｏｃＩＤ）の記憶例を示した図。 文書ＩＤ記憶部での文書ＩＤ（ＤｏｃＩＤ）の記憶例を示した図。 図１０に示した状態の構造化文書データ記憶部に、図１１の文書Ａを登録した後の構造化文書データ記憶部の状態を示した図。 文書ＩＤ記憶部での文書ＩＤ（ＤｏｃＩＤ）の記憶例を示した図。 図１０に示した状態の構造化文書データ記憶部に、図１１の文書Ａを登録した後の構造化文書データ記憶部の状態を示した図。 図１１の文書Ａの階層構造を示した図。 構造化文書データ記憶部での各構造化文書の記憶方法を説明するための図。 更新された文書Ａ（文書Ａ´）を示した図。 図２１の文書Ａ´の階層構造を示した図。 構造化文書データ記憶部での各構造化文書の記憶方法を説明するための図。 問合せデータの一例を示した図。 検索処理部の処理動作を説明するためのフローチャート。 検索処理部の処理動作を説明するためのフローチャート。 図２４の問合せデータから得られる問合せグラフを示した図。 図２７の問合せグラフ中の各変数に対応するＴＩＤを示した図。 図２７の問合せグラフに基づく検索処理に用いられるオペレータ系列を示した図。 検索処理部の処理動作を説明するための図。 検索処理部の他の処理動作を説明するための図。

符号の説明

３１…構造化文書構文解析部、３２…構造化文書構造抽出部、３３…構造化文書構造照合部、３４…構造化文書格納部、４１…問合せ構文解析部、４２…問合せ構造抽出部、４３…問合せ構造照合部、４４…問合せ実行部、１０１…サーバ装置、１０２…要求処理部、１０３…格納処理部、１０４…検索処理部、１１１…構造化文書データベース、１１２…構造化文書データ記憶部、１１３…構造テンプレート記憶部、１１４…索引データ記憶部、１１５…文書ＩＤ記憶部、２０１…クライアント装置、２０２…構造化文書登録部、２０３…検索部、２０４…入力部、２０５…表示部。

Claims (2)

1. 複数の要素データからなる階層構造を有する構造化文書であって、各要素データは、前記階層構造上の位置を示すテンプレートＩＤと、当該要素データを含む構造化文書内での当該要素データの出現位置を識別するための要素ＩＤとして、当該構造化文書内での当該要素データの出現順を示す番号とが割り当てられている、複数の構造化文書のそれぞれを、当該構造化文書中の各要素データをその親子関係を示すリンクで結び、同じ要素データを親とする同じ階層の複数の要素データは、より左側に配置されているほど出現順が先の階層木として記憶する記憶手段と、
   前記記憶手段に記憶された任意の構造化文書の前記階層木に対し、新たな要素データをその出現位置に追加し、当該新たな要素データに、該更新前に当該構造化文書内に存在する各要素データの要素ＩＤと重複しない番号を前記要素ＩＤとして与えるとともに、更新された旨を示すフラグ情報を付加する更新手段と、
   所望の要素データを検索するための検索条件を入力する入力手段と、
   前記複数の構造化文書のなかから、前記検索条件を満たす要素データを検索する検索手段と、
   前記検索手段で検索された、同じ構造化文書内の複数の要素データのうち、前記テンプレートＩＤが同じ２つの要素データの少なくとも１つに前記フラグ情報が付加されている場合、前記要素ＩＤに関わらず、前記記憶手段に記憶されている当該構造化文書の前記階層木内での当該２つの要素データの前記出現順に、当該２つの要素データを並び替えるソーティング手段と、
   を具備したことを特徴とする構造化文書検索装置。
2. 複数の要素データからなる階層構造を有する構造化文書であって、各要素データは、前記階層構造上の位置を示すテンプレートＩＤと、当該要素データを含む構造化文書内での当該要素データの出現位置を識別するための要素ＩＤとして、当該構造化文書内での当該要素データの出現順を示す番号とが割り当てられている、複数の構造化文書のそれぞれを、当該構造化文書中の各要素データをその親子関係を示すリンクで結び、同じ要素データを親とする同じ階層の複数の要素データは、より左側に配置されているほど出現順が先の階層木として記憶する記憶手段と、
   前記記憶手段に記憶された任意の構造化文書に対し、新たな要素データを追加する更新を行う更新手段と、
   所望の要素データを検索するための検索条件を入力する入力手段と、
   前記記憶手段に記憶されている複数の構造化文書のなかから、前記検索条件を満たす要素データを検索する検索手段と、
   検索された要素データを並び替えるソーティング手段と、
   を含む構造化文書検索装置における構造化文書検索方法であって、
   前記更新手段が、前記記憶手段に記憶された前記複数の構造化文書のうち、指定された構造化文書に対し、新たな要素データをその出現位置に追加し、当該新たな要素データに、該更新前に当該構造化文書内に存在する各要素データの要素ＩＤと重複しない番号を前記要素ＩＤとして与えるとともに、更新された旨を示すフラグ情報を付加する更新ステップと、
   前記入力手段が前記検索条件を入力する入力ステップと、
   前記検索手段が、前記記憶手段に記憶されている複数の構造化文書のなかから、前記検索条件を満たす要素データを検索する検索ステップと、
   前記ソーティング手段が、前記検索ステップで検索された、同じ構造化文書内の複数の要素データのうち、前記テンプレートＩＤが同じ２つの要素データの少なくとも１つに前記フラグ情報が付加されている場合、前記要素ＩＤに関わらず、前記記憶手段に記憶されている当該構造化文書の前記階層木内での当該２つの要素データの前記出現順に、当該２つの要素データを並び替えるソーティングステップと、
   を含む構造化文書検索方法。

Images