(57)【特許請求の範囲】
【請求項１】
階層化された論理構造を有する構造化文書を検索するためのクエリデータの入力を受け付けるクエリデータ受付部と、
前記クエリデータを、構造条件を含む複数の要素毎に分割する構造条件分割部と、
分割された前記構造条件の種類が、下位の階層から上位の階層を指定する先祖構造条件、同一階層の前後を指定する兄弟構造条件、及び構造条件の中にＸＭＬデータに含まれる要素の順序関係を指定する順序構造条件のいずれかであった場合、前記構造条件を、前記構造条件の前後の構造条件に影響を与えないように構造条件の種類毎に予め定められた子孫構造条件と結合演算処理とを含む書換えクエリに書き換える構造条件書換え部と、
前記構造条件、及び書換えクエリを含むクエリデータを入力として、検索結果を出力するクエリ実行部と、
を備える構造化文書管理装置。
【請求項２】
前記構造条件書換え部は、さらに、前記分割された各前記構造条件のうちの第１構造条件に対して、前記構造条件の種類が直下の階層のノードを取得対象とする構造条件であった場合、第１構造条件で指定される文字列と、前記第１構造条件の次に位置する第２構造条件とを取得して、前記第２構造条件が直上の階層のノードの任意の文字列を取得対象とする構造条件であるか否かを判定し、
前記第２構造条件が直上の階層のノードの任意の文字列を取得対象とする構造条件であると判定された場合は、前記第１構造条件で指定される文字列を指定する子孫構造条件を有する単一の前記書換えクエリへと、前記第１構造条件、及び第２構造条件を変換する、
請求項１に記載の構造化文書管理装置。
【請求項３】
クエリデータ受付部が階層化された論理構造を有する構造化文書を検索するためのクエリデータの入力を受け付けるステップと、
構造条件分割部が前記クエリデータを、構造条件を含む複数の要素毎に分割するステップと、
構造条件書換え部が分割された前記構造条件の種類が、下位の階層から上位の階層を指定する先祖構造条件、同一階層の前後を指定する兄弟構造条件、及び構造条件の中にＸＭＬデータに含まれる要素の順序関係を指定する順序構造条件のいずれかであった場合、前記構造条件を、前記構造条件の前後の構造条件に影響を与えないように構造条件の種類毎に予め定められた子孫構造条件と結合演算処理とを含む書換えクエリに書き換えるステップと、
クエリ実行部が前記構造条件、及び書換えクエリを含むクエリデータを入力として、検索結果を出力するステップと、
を含むことを特徴とする構造化文書管理方法。
【請求項４】
コンピュータに、
階層化された論理構造を有する構造化文書を検索するためのクエリデータの入力を受け付けるクエリデータ受付機能と、
前記クエリデータを、構造条件を含む複数の要素毎に分割する構造条件分割機能と、
分割された前記構造条件の種類が、下位の階層から上位の階層を指定する先祖構造条件、同一階層の前後を指定する兄弟構造条件、及び構造条件の中にＸＭＬデータに含まれる要素の順序関係を指定する順序構造条件のいずれかであった場合、前記構造条件を、前記構造条件の前後の構造条件に影響を与えないように構造条件の種類毎に予め定められた子孫構造条件と結合演算処理とを含む書換えクエリに書き換える構造条件書換え機能と、
前記構造条件、及び書換えクエリを含むクエリデータを入力として、検索結果を出力するクエリ実行機能と、
を実行させるための構造化文書管理プログラム。
【請求項５】
階層化された論理構造を有する構造化文書を検索するためのクエリデータの入力を受け付けるクエリデータ受付部と、
前記クエリデータを、構造条件を含む複数の要素毎に分割する構造条件分割部と、
分割された前記構造条件の種類が構造化文書の上位の階層から下位の階層を指定する子孫構造条件以外であった場合、前記構造条件を、前記構造条件の前後の構造条件に影響を与えないように構造条件の種類毎に予め定められた子孫構造条件と結合演算処理とを含む書換えクエリに書き換える構造条件書換え部と、
前記構造条件、及び書換えクエリを含むクエリデータを入力として、検索結果を出力するクエリ実行部と、を備え、
前記構造条件書換え部は、さらに、前記分割された各前記構造条件のうちの第１構造条件に対して、前記構造条件の種類が直下の階層のノードを取得対象とする構造条件であった場合、第１構造条件で指定される文字列と、前記第１構造条件の次に位置する第２構造条件とを取得して、前記第２構造条件が直上の階層のノードの任意の文字列を取得対象とする構造条件であるか否かを判定し、
前記第２構造条件が直上の階層のノードの任意の文字列を取得対象とする構造条件であると判定された場合は、前記第１構造条件で指定される文字列を指定する子孫構造条件を有する単一の前記書換えクエリへと、前記第１構造条件、及び第２構造条件を変換する、
構造化文書管理装置。
【請求項６】
クエリデータ受付部が階層化された論理構造を有する構造化文書を検索するためのクエリデータの入力を受け付けるステップと、
構造条件分割部が前記クエリデータを、構造条件を含む複数の要素毎に分割するステップと、
構造条件書換え部が分割された前記構造条件の種類が構造化文書の上位の階層から下位の階層を指定する子孫構造条件以外であった場合、前記構造条件を、前記構造条件の前後の構造条件に影響を与えないように構造条件の種類毎に予め定められた子孫構造条件と結合演算処理とを含む書換えクエリに書き換えるステップと、
構造条件書換え部が前記分割された各前記構造条件のうちの第１構造条件に対して、前記構造条件の種類が直下の階層のノードを取得対象とする構造条件であった場合、第１構造条件で指定される文字列と、前記第１構造条件の次に位置する第２構造条件とを取得して、前記第２構造条件が直上の階層のノードの任意の文字列を取得対象とする構造条件であるか否かを判定するステップと、
構造条件書換え部が前記第２構造条件が直上の階層のノードの任意の文字列を取得対象とする構造条件であると判定された場合は、前記第１構造条件で指定される文字列を指定する子孫構造条件を有する単一の前記書換えクエリへと、前記第１構造条件、及び第２構造条件を変換するステップと、
クエリ実行部が前記構造条件、及び書換えクエリを含むクエリデータを入力として、検索結果を出力するステップと、
を含むことを特徴とする構造化文書管理方法。
【請求項７】
コンピュータに、
階層化された論理構造を有する構造化文書を検索するためのクエリデータの入力を受け付けるクエリデータ受付機能と、
前記クエリデータを、構造条件を含む複数の要素毎に分割する構造条件分割機能と、
分割された前記構造条件の種類が構造化文書の上位の階層から下位の階層を指定する子孫構造条件以外であった場合、前記構造条件を、前記構造条件の前後の構造条件に影響を与えないように構造条件の種類毎に予め定められた子孫構造条件と結合演算処理とを含む書換えクエリに書き換える構造条件書換え機能と、
前記構造条件、及び書換えクエリを含むクエリデータを入力として、検索結果を出力するクエリ実行機能と、を実行させ、
前記構造条件書換え機能は、さらに、前記分割された各前記構造条件のうちの第１構造条件に対して、前記構造条件の種類が直下の階層のノードを取得対象とする構造条件であった場合、第１構造条件で指定される文字列と、前記第１構造条件の次に位置する第２構造条件とを取得して、前記第２構造条件が直上の階層のノードの任意の文字列を取得対象とする構造条件であるか否かを判定し、
前記第２構造条件が直上の階層のノードの任意の文字列を取得対象とする構造条件であると判定された場合は、前記第１構造条件で指定される文字列を指定する子孫構造条件を有する単一の前記書換えクエリへと、前記第１構造条件、及び第２構造条件を変換する、
構造化文書管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、構造化文書管理装置、方法およびプログラムに関する。
【背景技術】
【０００２】
従来、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）などで記述された構造化文書データを記憶・検索するための構造化文書管理装置が知られている。構造化文書管理装置における構造化文書データの検索のために、ＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ  Ｄａｔａｂａｓｅ  Ｍａｎａｇｅｍａｎｔ  Ｓｙｓｔｅｍ）における問い合わせ言語ＳＱＬのように、ＸＭＬデータに対する問い合わせ言語ＸＱｕｅｒｙ（ＸＭＬ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）が策定されており、多くの構造化文書管理装置でサポートされている。【０００３】
ＸＱｕｅｒｙは、ＸＭＬデータ集合をデータベースのように扱うための言語であり、条件に合致するデータ集合の取り出しや集計・分析を行うための方法が提供されている。ＸＭＬデータは親子や兄弟などの要素が組み合わさった階層化された論理構造（階層構造）を持つため、条件にはこの階層構造に関する条件（構造条件）を指定することができる。【０００４】
構造条件の処理には、構造化文書管理装置が記憶している構造化文書データが条件に合致する構造を持つかを照合する構造照合処理を行う必要がある。この構造照合処理は、構造条件が上位の階層から下位の階層を指定する処理（子孫構造条件）のみであれば比較的高速に処理することが可能であるが、下位の階層から上位の階層を指定する処理（先祖構造条件）や、同一階層の前後を指定する処理（兄弟構造条件）、構造条件の中にＸＭＬデータに含まれる要素の順序関係を指定する処理（順序構造条件）が含まれる場合は、高速に処理することが難しい。【０００５】
これに対して先祖構造条件、兄弟構造条件、及び順序構造条件を子孫構造条件と結合演算の組み合わせに変換することにより高速な処理を実現する試みが実施されている。例えば、構造ガイドと呼ばれる登録文書を構成するタグに付与したＩＤを利用する方法がある。また、ＸＱｕｅｒｙ内の先祖構造条件、兄弟構造条件及び順序構造条件を同じＸＱｕｅｒｙとして書き換えることによっても実現可能である。【０００６】
しかしながら、構造ガイドと呼ばれる文書を登録する際に割り当てたＩＤを必要とするため、構造化文書装置に登録されていない外部のリソースに対して処理する場合や、ＸＱｕｅｒｙの内部で一時的に生成される構造化文書に対しては、あらかじめ構造ガイドを決定することができない。そのようなケースにおいては、先祖構造条件、兄弟構造条件及び順序構造条件を変換した実行計画（プラン）を生成できないため、構造照合処理の効率が悪くなる問題が存在する。またＸＱｕｅｒｙを、構造ガイドを利用した独自の形式に変換する処理が必要であるため、構成が複雑になってしまう問題がある。【０００７】
また、構造条件を書き換える際に、対象となる構造条件より前に記述された構造条件を全て書き換える必要があるため、書換えのオーバーヘッドが大きい問題がある。また、１つの構造化文書を対象とすることを想定しているため、構造化文書集合に対して書き換えたＸＱｕｅｒｙを適用すると、構造化文書集合に対する絞り込み条件が活用されず、性能が悪くなる場合がある。あるいは１文書ごとにＸＱｕｅｒｙを適用する必要があるため性能が悪くなってしまう。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００７−２２６４５２号公報
【非特許文献】
【０００９】
【非特許文献１】XPath:  Looking  Forward/Dan  Olteanu,Holger  Meuss,Tim  Furche,Francois  Bry/Insitute  for  Computer  Schience  and  Center  fo  Information  and  Language  Processing  Uniceristy  of  Munich,Germany(2002)
【発明の概要】
【発明が解決しようとする課題】
【００１０】
本発明が解決しようとする課題は、単純な構成で高速な構造総合処理を実現することができる構造化文書管理装置、方法およびプログラムを提供することである。
【課題を解決するための手段】
【００１１】
実施形態の構造化文書管理装置は、構造化文書データ受付部と、構造化文書データ記憶部と、クエリデータ受付部と、構造条件分割部と、構造条件書換え部と、クエリ実行部を備える。構造化文書データ受付部は、階層化された論理構造を有する構造化文書データの入力を受け付ける。構造化文書データ記憶部は、前記構造化文書データを記憶する。クエリデータ受付部は、クエリデータの入力を受け付ける。構造条件分割部は、入力されたクエリデータ内の構造条件部分のみを切り出して分割する。構造条件書換え部は、切り出した構造条件を軸の種類に応じて書き換えて、分割したクエリデータの他の部分と結合する。クエリ実行部は、前記構造条件書換え部が出力したクエリを実行する。
【図面の簡単な説明】
【００１２】
【図１】第１の実施形態の構造化文書管理システムのシステム構築例を示す模式図。
【図２】第１の実施形態のサーバおよびクライアント端末のモジュール構成図。
【図３】第１の実施形態のサーバおよびクライアント端末の概略構成を示すブロック図。
【図４】第１の実施形態の構造化文書ＤＢに登録される構造化文書データの一例を示す説明図。
【図５】第１の実施形態のクエリデータの一例を示す説明図。
【図６】第１の実施形態の構造条件を分類及び、処理内容の一覧の一例を示す模式図。
【図７】第１の実施形態のクエリデータについて構造条件の分割処理を行った結果を示す説明図。
【図８】第１の実施形態の構造条件分割処理で、分割される構造条件の一覧を示す説明図。
【図９】第１の実施形態の構造条件書換え処理の流れを示すフローチャート。
【図１０】第１の実施形態の構造条件書換え処理を、構造条件書換え部で書き換える際に必要なルール一覧の一例を示す説明図。
【図１１】第１の実施形態のクエリデータを書き換えた結果の一例を示す説明図。
【図１２】第１の実施形態のクエリデータの結果データを示す説明図。
【図１３】第２の実施形態のクエリデータの一例を示す説明図。
【図１４】第２の実施形態のクエリデータについて構造条件の分割処理を行った結果を示す説明図。
【図１５】第２の実施形態の構造条件書換え処理の流れを示すフローチャート。
【図１６】第２の実施形態の構造条件書換え処理を、構造条件書換え部で書き換える際に必要なルール一覧の一例を示す説明図。
【図１７】第２の実施形態のクエリデータを書き換えた結果の一例を示す説明図。
【図１８】第２の実施形態のクエリデータの結果データを示す説明図。
【発明を実施するための形態】
【００１３】
以下、実施形態の構造化文書管理装置を図面を参照して説明する。
【００１４】
（第１の実施形態）
まず、第１の実施形態について、図１〜図１２を参照して説明する。図１は、第１の実施形態にかかる構造化文書管理システムのシステム構築例を示す模式図である。ここでは、実施形態の構造化文書管理システムとして、図１に示すように、構造化文書管理装置であるサーバコンピュータ（以下、サーバという。）１に、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等のネットワーク２を介して、クライアントコンピュータ（以下、クライアント端末という。）３が複数台接続されたサーバクライアントシステムを想定する。
【００１５】
図２は、サーバ１およびクライアント端末３のモジュール構成図である。サーバ１およびクライアント端末３は、例えば、通常のコンピュータを利用したハードウェア構成を有している。すなわち、サーバ１およびクライアント端末３は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１０１、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１０２、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１０３、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）１０４、媒体駆動装置１０５、通信制御装置１０６、表示部１０７、入力部１０８、及びバスコントローラ１０９を備えている。
【００１６】
ＣＰＵ１０１は、各種情報処理を実行する。ＲＯＭ１０２は、ＢＩＯＳなどを記憶した読出し専用メモリである。ＲＡＭ１０３は、各種データを書換え可能に記憶する。ＨＤＤ１０４は、各種データベースとして機能するとともに各種のプログラムを格納する。媒体駆動装置１０５は、記憶媒体１１０を用いて情報を保管したり外部に情報を配布したり外部から情報を入手するためのＣＤ−ＲＯＭドライブ等である。
【００１７】
通信制御装置１０６は、ネットワーク２を介して外部の他のコンピュータと通信により情報を伝達する。表示部１０７は、処理経過や結果等を操作者に表示するＣＲＴ（Ｃａｔｈｏｄｅ  Ｒａｙ  Ｔｕｂｅ）やＬＣＤ（Ｌｉｑｕｉｄ  Ｃｒｉｓｔａｌ  Ｄｉｓｐｌａｙ）等である。入力部１０８は、操作者がＣＰＵ１０１に命令や情報等を入力するためのキーボードやマウス等である。バスコントローラ１０９は、各部間で送受信されるデータを調停する。
【００１８】
このようなサーバ１およびクライアント端末３では、ユーザが電源を投入するとＣＰＵ１０１がＲＯＭ１０２内のローダーというプログラムを起動させ、ＨＤＤ１０４よりＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）というコンピュータのハードウェアとソフトウェアとを管理するプログラムをＲＡＭ１０３に読み込み、このＯＳを起動させる。このようなＯＳは、ユーザの操作に応じてプログラムを起動したり、情報を読み込んだり、保存を行ったりする。ＯＳのうち代表的なものとしては、Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）等が知られている。これらのＯＳ上で動作するプログラムをアプリケーションプログラムと呼んでいる。なお、アプリケーションプログラムは、所定のＯＳ上で動作するものに限らず、後述の各種処理の一部の実行をＯＳに肩代わりさせるものであってもよいし、所定のアプリケーションソフトやＯＳなどを構成する一群のプログラムファイルの一部として含まれているものであってもよい。
【００１９】
ここで、サーバ１は、アプリケーションプログラムとして、構造化文書管理プログラムをＨＤＤ１０４に記憶している。この意味で、ＨＤＤ１０４は、構造化文書管理プログラムを記憶する記憶媒体として機能する。また、一般的には、サーバ１のＨＤＤ１０４にインストールされるアプリケーションプログラムは、ＣＤ−ＲＯＭやＤＶＤなどの各種の光ディスク、各種光磁気ディスク、フレキシブルディスクなどの各種磁気ディスク、半導体メモリ等の各種方式のメディア等の記憶媒体１１０に記録されて提供される。このため、ＣＤ−ＲＯＭ等の光情報記録メディアやＦＤ等の磁気メディア等の可搬性を有する記憶媒体１１０も、構造化文書管理プログラムを記憶する記憶媒体となり得る。さらには、構造化文書管理プログラムは、例えば通信制御装置１０６を介して外部から取り込まれ、ＨＤＤ１０４にインストールされてもよい。
【００２０】
サーバ１は、ＯＳ上で動作する構造化文書管理プログラムが起動すると、この構造化文書管理プログラムに従い、ＣＰＵ１０１が各種の演算処理を実行して各部を集中的に制御する。一方、クライアント端末３は、ＯＳ上で動作するアプリケーションプログラムが起動すると、このアプリケーションプログラムに従い、ＣＰＵ１０１が各種の演算処理を実行して各部を集中的に制御する。サーバ１およびクライアント端末３のＣＰＵ１０１が実行する各種の演算処理のうち、実施形態の構造化文書管理システム関連する処理について、以下に説明する。
【００２１】
図３は、本実施形態におけるサーバ１およびクライアント端末３の概略構成を示すブロック図である。図３に示すように、クライアント端末３は、アプリケーションプログラムにより実現される機能構成として、構造化文書登録部１１と、検索部１２とを備える。
【００２２】
構造化文書登録部１１は、入力部１０８から入力された構造化文書データやクライアント端末３のＨＤＤ１０４に予め記憶された構造化文書データを、後述するサーバ１の構造化文書データベース（構造化文書ＤＢ）２１に登録するためのものである。この構造化文書登録部１１は、登録すべき構造化文書データとともに格納要求をサーバ１に送信する。
【００２３】
図４は、構造化文書ＤＢ２１に登録された構造化文書データの一例を示したものである。構造化文書データを記述するための代表的な言語としてＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）が挙げられる。図４に示す２つ構造化文書データＤ１、Ｄ２は、ＸＭＬで記述されたものである。ＸＭＬでは、文書構造を構成する個々のパーツを「要素」（エレメント：Ｅｌｅｍｅｎｔ）と呼び、要素はタグ（ｔａｇ）を使って記述される。具体的には、要素の始まりを示すタグ（開始タグ）と、終わりを示すタグ（終了タグ）の２つのタグでデータを挟み込んで、１つの要素を表現している。なお、開始タグと終了タグで挟み込まれたテキストデータは、当該開始タグと終了タグで表された１つの要素に含まれるテキスト要素である。
【００２４】
図４に示す例では、構造化文書Ｄ１は＜ｂｏｏｋ＞というタグで囲まれたルート要素が存在する。この＜ｂｏｏｋ＞要素は、＜ｔｉｔｌｅ＞、＜ａｕｔｈｏｒ＞、＜ｐｕｂｌｉｓｈｅｒ＞の各タグで囲まれた複数の子要素を包含する。＜ｔｉｔｌｅ＞要素は、「Ｄａｔａ  Ｏｎ  Ｔｈｅ  Ｗｅｂ」などのテキスト要素をもつ。
【００２５】
＜ｂｏｏｋ＞要素は、２つの＜ａｕｔｈｏｒ＞要素を持ち、これら２つの＜ａｕｔｈｏｒ＞要素が＜ｔｉｔｌｅ＞要素の後に出現する順序であり、その次に＜ｐｕｂｌｉｓｈｅｒ＞要素が出現する。各＜ａｕｔｈｏｒ＞要素は＜ｌａｓｔ＞、＜ｆｉｒｓｔ＞の順番で現れる２つの子要素を包含する。
【００２６】
構造化文書Ｄ２は構造化文書Ｄ１と同様にルート要素が＜ｂｏｏｋ＞であるが、＜ｂｏｏｋ＞の子要素がＤ１と異なり＜ａｕｔｈｏｒ＞ではなく＜ｅｄｉｔｏｒ＞という要素を代わりに持っている。＜ｅｄｉｔｏｒ＞要素は＜ａｕｔｈｏｒ＞要素と同様に＜ｌａｓｔ＞、＜ｆｉｒｓｔ＞の順番で現れる２つの子要素を包含する。
【００２７】
図３に戻り、検索部１２は、ユーザにより入力部１０８から入力された指示に従って、構造化文書ＤＢ２１から所望のデータを検索するための検索条件などが記述されたクエリデータを作成し、当該クエリデータを含む検索要求をサーバ１へ送信する。また、検索部１２は、サーバ１から送信された当該検索要求に対応する結果データを受け取り、これを表示部１０７に表示する。
【００２８】
一方、サーバ１は、構造化文書管理プログラムにより実現される機能構成として、格納処理部２２と、検索処理部２３とを備える。また、サーバ１は、ＨＤＤ１０４などの記憶装置を利用した構造化文書ＤＢ２１を備える。
【００２９】
格納処理部２２は、クライアント端末３からの構造化文書の格納要求を受けて、クライアント端末３から送信された構造化文書データを構造化文書ＤＢ２１に格納する処理を行う。この格納処理部２２は、格納インタフェース部２４を備えている。
【００３０】
格納インタフェース部２４は、構造化文書データの入力を受け付けて（構造化文書データ受付部）、構造化文書データを構造化文書ＤＢ２１に格納する。
【００３１】
検索処理部２３は、クライアント端末３からの検索要求を受けて、クエリデータにより指定された条件に合致するデータを構造化文書ＤＢ２１から探し出し、この探し出したデータを結果データとしてクライアント端末３へと返信する。この検索処理部２３は、検索インタフェース部２６と、構造条件分割部２７と、構造条件書換え部２８と、クエリ実行部２９を備えている。
【００３２】
検索インタフェース部２６は、クエリデータの入力を受け付けて（クエリデータ受付部）、受け付けたクエリデータにより指定された条件を満足する結果データを得るために構造条件分割部２７を呼び出す。
【００３３】
構造条件分割部２７は、クライアント端末３から送信され、検索インタフェース部２６を介して入力されたクエリデータ（以下、入力クエリデータという。）を構文解析し、この入力クエリデータ内で、構造化文書データの論理構造における階層関係を指定する条件を示す構造条件の部分（以下、「構造条件分割リスト３１」という。）を分割して取り出す。
【００３４】
構造条件書換え部２８は、構造条件分割部２７で出力された構造条件分割リスト３１のうち、子孫構造条件以外の構造条件を、子孫構造条件と結合演算の組み合わせによって書き換える。書き換えの詳細については、後述する。書き換えたクエリデータは書き換えなかったその他のクエリデータと単純に結合して、最終的な書換えクエリデータ３２として出力する。
【００３５】
クエリ実行部２９は、クエリ実行部として機能するものであって、構造条件書換え成部２８から出力された書換えクエリデータ３２を構造化文書ＤＢ２１に記憶された構造化文書データのデータ集合に対して実行し、得られた結果データ３３を出力する。
【００３６】
検索インタフェース部２６は、クエリ実行部２９から出力された結果データ３３を、検索の結果データ３４としてクライアント端末３へ返却する。
【００３７】
図５は、クエリデータの一例を示す説明図である。ＸＭＬでは、Ｗ３Ｃで提案されているＸＱｕｅｒｙという問合せ言語があり、図５に示すクエリデータは、このＸＱｕｅｒｙに基づいた問合せ記述方法に則っている。図５は「姓が“Ｓｕｃｉｕ”という著者よりも前に列挙された著者一覧を出せ」という意図であり、下記のような複雑な階層構造に関する条件（構造条件）を含むクエリデータＱ１が示されている。構造条件はクエリデータ内で、文字“／”で始まり、“／”と文字列“：：”の間に「軸」と呼ばれる構造条件の種類と処理内容を識別する文字列が入り、文字列“：：”の右側に要素名や要素の種類を示す要素指定文字列が入る。要素指定文字列は“：：”の次の文字から次の構造条件の開始を表す文字“／”や構造条件の以外の種類を示す文字列が現れるまでの文字列で構成される。
【００３８】
Ｑ１：構造化文書ＤＢ２１の各構造化文書データについて、最上位の階層に「ｂｏｏｋ」という要素があり、その「ｂｏｏｋ」という要素は、その直下に「ａｕｔｈｏｒ」という要素を持ち、さらにこの「ａｕｔｈｏｒ」という要素の直下に、「ｌａｓｔ」という要素を持ち、さらに「ｌａｓｔ」という要素の直下に値が「“Ｓｕｃｉｕ“」であるテキスト要素があり、さらにそのテキスト要素を上位層のどこかに「ａｕｔｈｏｒ」という要素があり、さらにその「ａｕｔｈｏｒ」という要素と同一の親要素を持つ兄弟要素のうち、構造化文書における出現順序が前である「ａｕｔｈｏｒ」要素の一覧を返すということを示している。
【００３９】
図６は、サーバ１の検索処理部２３による検索処理の流れを示すフローチャートである。まず、検索インタフェース部２６は、クライアント端末３からネットワーク２経由で送信されたクエリデータの入力が受け付ける（ステップＳ１）。
【００４０】
次に、構造条件分割部２７は、入力クエリデータに対して構造条件部分を分割する処理を行う（ステップＳ２）。
【００４１】
図７は、図５に示されるクエリデータを、構造条件分割部２７が構造条件ごとに分割した結果であり、［１］から［７］の７つの構造条件に分割されている。［１］はクエリデータの先頭の文字“／”から次の“／”までの構造条件を切り出したものである。軸は“ｃｈｉｌｄ”であり要素指定文字列は“ｂｏｏｋ”となっている。［２］，［３］、［４］も同様に軸が“ｃｈｉｌｄ”で要素指定文字列は各々“ａｕｔｈｏｒ”、“ｌａｓｔ”、“ｔｅｘｔ（）”となっている。“ｔｅｘｔ（）”は要素名ではなく、テキスト要素を指定する文字列である。［５］は構造条件ではなく、［５］の出力結果に対して、その要素の持つ文字列値が“Ｓｕｃｉｕ”のみを残すことを指定する絞り込み条件である。なお、［５］の絞込み条件は［４］の構造条件とひとまとまりとなるように分割されてもよい。［６］は軸名が“ａｎｃｅｓｔｏｒ−ｏｒ−ｓｅｌｆ”で要素指定文字列が“ａｕｔｈｏｒ”、［７］は軸名が“ｐｒｅｃｅｄｉｎｇ−ｓｉｂｌｉｎｇ”で要素指定文字列が“ａｕｔｈｏｒ”の構造条件である。
【００４２】
図８は、構造条件の種類とその処理内容を示す表である。図８で示す表は、「軸名」、「構造条件の種類」、「処理内容」の３つの項目を有する。「軸名」は構造条件の処理内容を一意に決定するものであり、クエリとして用いられる。「構造条件の種類」は各軸が、構造条件が上位の階層から下位の階層を指定する子孫構造条件か、下位の階層から上位の階層を指定する先祖構造条件か、同一階層の前後を指定する兄弟構造条件か、構造条件の中にＸＭＬデータに含まれる要素の順序関係を指定する順序構造条件のどのカテゴリに属するかを示すものである。「処理内容」は各軸の構造条件の取得対象を具体的に書いたものである。
【００４３】
図６に戻り、構造条件分割部２７による構造条件分割が終了すると、次に、構造条件書換え部２８は、構造条件分割部２７が分割した各構造条件に対して書換え処理を行う（ステップＳ３）。なお、構造条件以外の要素（図７の例では［５］）に対しては書換えは行われない。構造条件書換え部２８による書換え処理の一例を、図９を参照して説明する。
【００４４】
図９は、構造条件書換えの流れを示すフローチャートである。構造条件書換え部２８は、はじめに、入力として与えられた構造条件毎に分割したリストから先頭の要素を取得して、取得完了後にリストから削除する（ステップＳ２１）。
【００４５】
次に、構造条件書換え部２８は、ステップＳ２１で取得した要素をチェックして、構造条件かそれ以外かを判定する（ステップＳ２２）。構造条件とは、図８で定義された軸名を有する要素であり、図７で示した例では、［５］のみが構造条件ではない。構造化条件であると判定された場合（ステップＳ２２：Ｙｅｓ）、構造条件書換え部２８は、構造条件内の要素指定文字列を書換えパラメータＸとする（ステップＳ２３）。次に、構造条件書換え部２８は、取得した要素に含まれる構造条件の軸名から、図８の構造条件の種類を取得する（ステップＳ２４）。この表は、例えばＨＤＤ１０４などに予め記憶されている。次に、構造条件書換え部２８は、取得した構造条件の種類が祖先構造条件、兄弟構造条件、順序構造条件のいずれかであるかを判定する（ステップＳ２５）。
【００４６】
構造条件の種類が祖先構造条件、兄弟構造条件、順序構造条件のいずれかであった場合（ステップＳ２５がＹｅｓ）、構造条件書換え部２８は、図１０で示す表から構造条件の種類に対応する書換えベースクエリＹを取得する（ステップＳ２８）。
【００４７】
図１０は、構造条件書換えにおける各軸の書換えルールの一例である。図１０で示す表は「番号」「軸名」、「構造条件の種類」「書換えベースクエリ」、及び「書換えパラメータ」の項目を有する。「番号」は書換えルール毎に割り当てられる識別番号である。「軸名」と「構造条件の種類」は図８と同様である。「書換えベースクエリ」は構造条件の種類ごとの書換えクエリの基本テンプレートである。［パラメータＡ］［パラメータＢ］は書換えベースクエリの変更可能なパラメータ部分である。ここで「書換えベースクエリ」は最初の１行目で、構造条件の入力を表す「．」を変数＄１に代入し、以降この変数＄１を起点にして処理を実施している。このため書き換えたクエリは、入力として構造条件より前で実施した絞り込み条件によって絞り込まれた構造化文書の要素のみが渡されることになる。また「書換えベースクエリ」に出てくる関数“ｒｏｏｔ”は入力として渡された要素を含む構造化文書の先頭要素を取得する関数である。一度先頭要素に戻って上位から下位へ辿りなおす形に書き換えている。「書換えパラメータ」は「書換えベースクエリ」の［パラメータＢ］に代入される軸毎の値である。この表は、例えばＨＤＤ１０４などに予め記憶されている。書換えベースクエリＹの内容について以下説明する。
【００４８】
祖先構造条件に対応する書換えベースクエリは、入力となるノードを保持する変数＄１に対して、＄１のノードを保持するＸＭＬ文書内に存在するタグ名が［パラメータＡ］の全てのノードを保持する＄２を求める。そして、＄２に保持された各ノードに対して各々、［パラメータＢ］の構造条件を満たす全てのノードを保持する＄３を求め、＄３内に＄１が保持するノードと同一のノードが存在する条件を満たす場合、＄２が祖先構造条件を満たすノードであるとして、＄２を返すという意味である。これは、すなわち入力ノードが存在ずる文書内で［パラメータＡ］のタグ名を持つノードを全て探し出し、そのノードＡの子供(子孫)内に入力ノードが存在すれば、そのノードＡが入力ノードの親(祖先)であることを意味する。
【００４９】
また、兄弟構造条件に対応するベースクエリは、入力となるノードを保持する変数＄１に対して＄１のノードを保持するＸＭＬ文書内に存在するタグ名が［パラメータＡ］の全てのノードを保持する＄２を求め、＄２に保持された各ノードに対して各々、そのノードを保持するＸＭＬ文書内の全てのノードを保持する＄３を求め、＄３に保持された各ノードに対して各々、その子供のノードを保持する＄４を求め、＄４内に＄２のノードが存在する場合のみ、＄４のノードを＄５として保持し、＄２と＄１の順序関係が［パラメータＢ］を満たし、さらに＄５内に$1のノードが存在する場合、＄２が兄弟構造条件を満たすノードとなり、＄２を返す式である。すなわち、本クエリは、入力ノードが存在ずる文書内で［パラメータＡ］のタグ名を持つノードＡを全て探し出し、そのノードＡと親が同じノードの集合Ｂを取得し、ノード集合Ｂに入力ノードが含まれ、かつノードＡが入力ノードよりも順序が早ければ(遅ければ)、ノードＡは入力ノードの兄(弟)である、ということを示している。
【００５０】
また、順序構造条件のうち、preceding条件を満たすノードを求めるベースクエリについて説明する。クエリは、入力となるノードを保持する変数＄１に対して、＄１のノードを保持するＸＭＬ文書内に存在するタグ名が［パラメータＡ］の全てのノードを保持する＄２を求め、＄２に保持された各ノードに対して各々、その子孫ノードを保持する＄３を求め、＄２が＄１よりも順序が早く、かつ＄１内に＄３のノードが存在しない場合、＄２が条件を満たすノードであるとして、＄２を返す式である。すなわち、入力ノードが存在ずる文書内で［パラメータＡ］のタグ名を持つノードＡを全て探し出し、さらにノードＡの子孫ノード集合Ｂを取得する。そして、ノードＡが入力ノードよりも順序が早く、入力ノードがノードＡの子孫ノード集合Ｂに含まれていなければ、ノードＡは入力ノードに対してpreceding条件を満たすということを意味する。
【００５１】
また、順序構造条件のうち、following条件を満たすノードを求めるベースクエリについて説明する。クエリは、入力となるノードを保持する変数＄１に対して、＄１のノードを保持するＸＭＬ文書内に存在するタグ名が［パラメータＡ］の全てのノードを保持する＄２を求め、次いで＄１の全ての子孫ノードを保持する＄３を求め、＄２が＄１よりも順序が遅く、かつ＄２内に＄３のノードが存在しない場合、＄２がfollowing条件を満たすノードであるとして、＄２の値を返す式である。すなわち、入力ノードが存在ずる文書内で［パラメータＡ］のタグ名を持つノードＡを全て探し出し、さらに入力ノードの子孫ノード集合Ｂを取得する。ノードＡが入力ノードよりも順序が遅く、ノードＡが入力ノードの子孫ノード集合Ｂに含まれていなければ、ノードＡは入力ノードに対してfollowing条件を満たす。
【００５２】
次に、構造条件書換え部２８は、書換えベースクエリＹの［パラメータＡ］の部分を、書換えパラメータＸに書き換える（ステップＳ２９）。次に、構造条件書換え部２８は、図１０で示す表から軸の種類に対応する書換えパラメータＺを取得する（ステップＳ３０）。次に、構造条件書換え部２８は、書換えベースクエリＹの［パラメータＢ］の部分を書換えパラメータＺに書き換える（ステップＳ３１）。次に、構造条件書換え部２８は、書き換えた結果を書換えクエリに追加する（ステップＳ２６）。
【００５３】
次に構造条件書換え部２８は、分割リストが空かを判定する（ステップＳ２７）。分割リストが空の場合（ステップＳ２７：Ｙｅｓ）、すなわちステップＳ２１において削除した要素が、最後の要素であった場合、構造条件書換え部２８は、構造条件書換え処理を終了し書換えクエリを出力する。
【００５４】
一方、ステップＳ２２の判定で要素が構造条件ではなかった場合（ステップＳ２２：Ｎｏ）、構造条件書換え部２８は、要素を書き換えずにそのまま書換えクエリに追加する（ステップＳ２６）。次にステップ２７に進み同様の処理を繰り返す。
【００５５】
一方、ステップ２７の判定で分割リストが空でなかった場合（ステップＳ２７がＮｏ）、ステップＳ２１に進み再び同じ処理を繰り返す。
【００５６】
ここで、図７に例示した構造条件分割結果を用いて、一般的な構造条件書換えを行った場合の処理の概要を、図９〜図１１を参照して説明する。
【００５７】
はじめに、構造条件書換え部２８は、入力として図７の［１］から［７］までの７つの要素からなる分割リストを受け取り、最初の要素［１］を取り出した後、［１］をリストから削除する（ステップＳ２１）。次に、構造条件書換え部２８は、［１］が構造条件かどうかを判定し、構造条件であったため要素指定文字列“ｂｏｏｋ”を書換えパラメータＸとする（ステップＳ２２、Ｓ２３）。次に、構造条件書換え部２８は、［１］の軸が“ｃｈｉｌｄ”であるための構造条件の種類として図８の表から子孫構造条件を取得する（ステップＳ２４）。次に、構造条件書換え部２８は、［１］が祖先構造条件、兄弟構造条件、順序構造条件のいずれでもなかったため書換えクエリに［１］を追加して書換えクエリは「／ｃｈｉｌｄ：：ｂｏｏｋ」となる（ステップＳ２５、Ｓ２６）。次に分割リストは空ではないため次のリストの先頭要素［２］を取得してリストから［２］を削除する（ステップＳ２７、Ｓ２１）。
【００５８】
分割リストの［２］、［３］、［４］はいずれも軸が［１］と同じ“ｃｈｉｌｄ”であるため、Ｓ２２からＳ２７まで全く同じ処理を繰り返す。その結果書換えクエリは「／ｃｈｉｌｄ：：ｂｏｏｋ／ｃｈｉｌｄ：：ａｕｔｈｏｒ：：ｃｈｉｌｄ：：ｌａｓｔ／ｃｈｉｌｄ：：ｔｅｘｔ（）」となる。
【００５９】
次に、構造条件書換え部２８は、再び分割リストの先頭要素［５］を取得して、［５］をリストから削除する（ステップＳ２１）。次に、構造条件書換え部２８は、要素が構造条件ではないため書換えクエリに［５］である「［．＝“Ｓｕｃｉｕ”］」を追加する（ステップＳ２２、Ｓ２６）。
【００６０】
次に、構造条件書換え部２８は、分割リストの先頭から［６］を取り出してリストから削除する（ステップＳ２１）。次に、構造条件書換え部２８は、要素が構造条件であるため、書換えパラメータＸに“ａｕｔｈｏｒ”を代入し、軸の種類“ａｎｃｅｓｔｏｒ−ｏｒ−ｓｅｌｆ”から構造条件の種類として祖先構造条件を取得する（ステップＳ２２、Ｓ２３、Ｓ２４）。次に、構造条件書換え部２８は、要素が祖先構造条件であるため、図１０から構造条件の種類に対応する書換えベースクエリＹを取得する（ステップＳ２５、Ｓ２８）。次に、構造条件書換え部２８は、書換えベースクエリＹの［パラメータＡ］の部分を書換えパラメータＸの“ａｕｔｈｏｒ”で書き換える（ステップ２９）。次に、構造条件書換え部２８は、図１０から軸の種類に対応する書換えパラメータＺとして“ｄｅｓｃｅｎｄａｎｔ−ｏｒ−ｓｅｌｆ”を取得し、書換えベースクエリＹの［パラメータＢ］を書換えパラメータＺに書き換える（ステップＳ３０、Ｓ３１）。そして、構造条件書換え部２８は、書き換えた結果を書換えクエリに追加する（ステップ２６）。次に、構造条件書換え部２８は、分割リストが空ではないため、リストの先頭要素から［７］を取り出してリストから削除する（ステップＳ２７、Ｓ２１）。
【００６１】
次に、［７］の要素が構造条件であるため、構造条件書換え部２８は、書換えパラメータＸに“ａｕｔｈｏｒ”を代入し、軸の種類“ｐｒｅｃｅｄｉｎｇ−ｓｉｂｌｉｎｇ”から構造条件の種類として兄弟構造条件を取得する（ステップＳ２２、Ｓ２３、Ｓ２４）。［７］は、兄弟構造条件であるため、構造条件書換え部２８は、図１０から構造条件の種類に対応する書換えベースクエリＹを取得する（ステップＳ２５、Ｓ２８）。次に、構造条件書換え部２８は、書換えベースクエリＹの［パラメータＡ］の部分を書換えパラメータＸの“ａｕｔｈｏｒ”で書き換える（ステップ２９）。次に、構造条件書換え部２８は、図１０から軸の種類に対応する書換えパラメータＺとして“ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ”を取得し、書換えベースクエリＹの［パラメータＢ］を書換えパラメータＺに書き換える（ステップＳ３０、Ｓ３１）。構造条件書換え部２８は、書き換えた結果を書換えクエリに追加する（ステップ２６）。次にリストが空であるため構造条件書換え部２８は、構造条件書換え処理を終了する（ステップＳ２７）。
【００６２】
図１１は図７に例示した構造条件分割結果を用いて、構造条件書換えを行った書換えクエリの結果である。［６］、［７］に該当する構造条件が２つの（）で始まるブロックに単純に書き換えられえている。［６］の書き換えた部分の入力は［１］〜［５］までの演算結果となるため、［１］〜［５］の条件によって構造化文書集合が絞り込まれた場合、対象となる構造化文書構造に対してのみ［６］の書換え結果が適用される。同様に［６］で絞り込まれた構造文書集合に対してのみ［７］で書き換えられた結果が適用される。
【００６３】
構造条件書換え部２８による構造条件書換え処理が終了すると、書き換えられた書換えクエリがＸＱｕｅｒｙとして出力される。次に図６に示されるように、クエリ実行部２９は、書き換えられたＸＱｕｅｒｙを実行する（ステップＳ４）。書き換えられた後もＸＱｕｅｒｙの形を保っているため、クエリ実行処理は、任意のＸＱｕｅｒｙ処理系で実行可能である。
【００６４】
クエリ実行部２９によるクエリ実行処理が終了すると、最後に、検索インタフェース部２６は、クエリ実行部２９による出力を結果データとしてクライアント端末３に返却して処理を終了する（ステップＳ５）。
【００６５】
図１２は、図４の構造化文書Ｄ１、Ｄ２に対して図５に例示した書換えＸＱｕｅｒｙを実行した結果である。「姓が“Ｓｕｃｉｕ”という著者よりも前に列挙された著者一覧を出せ」という元のＸＱｕｅｒｙの意図通りに、構造化文書Ｄ１内の“ｌａｓｔ”要素の直下のテキスト要素が“Ｓｕｃｉｕ”の祖先である“ａｕｔｈｏｒ”要素よりも前に出現する  “ａｕｔｈｏｒ”要素が条件に合致して出力されている。構造化文書Ｄ２は要素“ａｕｔｈｏｒ”を持たないため図７の［２］に該当する構造条件をチェックした段階で対象構造化文書構造から削除される。
【００６６】
以上、具体的な例を挙げながら説明したように、本実施形態によれば、サーバ１が、構造化文書データを構造化文書ＤＢ２１に格納する。また、サーバ１は、構造化文書データの検索時には、クライアント端末３からの入力クエリデータを構文解析して、入力クエリデータから、構造化文書データの論理構造における階層構造を指定する構造条件を分割し、分割した構造条件が上位の階層から下位の階層を指定する子孫構造条件以外であった場合に、該当する構造条件部分を、子孫構造条件と結合条件を用いて書換えている。したがって、入力クエリデータに子孫構造条件以外の構造条件を含む場合でも、この入力クエリデータを単純な子孫構造条件のみからなる構造照合処理と結合演算処理とで処理することで、構造照合処理の高速化を実現することができるようになる。
【００６７】
また上記実施形態では、子孫構造条件以外の構造条件を書き換える際に、該当する構造条件部分のみを書き換えるため、該当しないクエリデータの他の部分に影響を与えず単純な部分置換で書き換えることができる。さらに上記の具体例では、子孫構造条件と結合演算処理に書き換える際に、書き換えた子孫構造条件の入力が、それまでのクエリデータの処理で得られた構造化文書のみを対象とするように書き換えている。これにより書き換えた構造条件を構造化文書集合全てに対してではなく、それまでの処理で絞り込まれた構造化文書集合に対してのみ子孫構造条件を実施すれば良いため検索を高速に実行することができる。
【００６８】
なお、上記の具体例では、入力クエリデータに、兄弟構造条件及び祖先構造条件として「ｐｒｅｃｅｅｄｉｎｇ−ｓｉｂｌｉｎｇ」と「ａｎｃｅｓｔｏｒ−ｏｒ−ｓｅｌｆ」が含まれる場合を例示して説明したが、兄弟構造条件及び祖先構造条件の他の条件、例えば「ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ」、「ａｎｃｅｓｔｏｒ」、「ｐａｒｅｎｔ」などが含まれる場合や、順序構造条件「ｐｒｅｃｅｄｉｎｇ」、「ｆｏｌｌｗｏｉｎｇ」であっても、上記の具体例と同様に処理することができる。
【００６９】
（第２の実施形態）
次に、第２の実施形態について、説明する。本実施形態は、子孫構造条件以外の構造条件を書き換える際に、要素単独で書き換えずに前後の構造条件と組み合わせて書き換えるようにした例である。なお、以下の説明において、上述した第１の実施形態と共通の構成については同一の符号を付し、重複した説明を省略する。
【００７０】
図１３は、本実施形態で想定するクエリデータの一例を示す説明図である。この図１３に示すクエリデータＱ２は、第１の実施形態で説明したクエリデータＱ１と同じくＸＱｕｅｒｙで記述されている。図１３のクエリは「著者名が”ｅｄｉｔｏｒ”要素以下に記述された構造化文書のタイトルを出せ」という意図であり、下記のような意味の複雑な階層構造に関する条件（構造条件）を含んでいる。
【００７１】
Ｑ２：構造化文書ＤＢ２１の各構造化文書データについて、最上位の階層に「ｂｏｏｋ」という要素があり、その「ｂｏｏｋ」という要素はその中に「ｅｄｉｔｏｒ」という要素を持ち、さらにこの「ｅｄｉｔｏｒ」という要素の一つ上の階層に要素に戻り、その要素の直下にある、「ｔｉｔｌｅ」という要素の一覧を返す。
【００７２】
クエリデータＱ２では、「／ｃｈｉｌｄ：：ｅｄｉｔｏｒ」で一度「ｂｏｏｋ」要素から一つ下の階層に降りた後で、「／ｐａｒｅｎｔ：：ｎｏｄｅ（）」という構造条件でもう一度元の要素に戻った後に、再び「／ｃｈｉｌｄ：：ｔｉｔｌｅ」で一つ下の異なる要素に降りている。これにより、「ｂｏｏｋ」要素の下に「ｅｄｉｔｏｒ」要素があることを確認した後で、「ｔｉｔｌｅ」要素を出力する。
【００７３】
本実施形態における検索処理部２３による検索処理の流れは、図６に示した第１の実施形態のものと同様である。ただし、本実施形態では、ステップＳ３の構造条件書換え処理の中で、異なる書換えルールの下で構造条件書き換え処理が実施される。
【００７４】
図１４は、図１３のクエリデータに対して構造条件分割部２７によって各要素に分割した結果であり、［１］から［４］の４つの要素に分割されている。［１］はクエリデータの先頭の文字“／”から次の“／”までの構造条件を切り出したものである。軸は“ｃｈｉｌｄ”であり要素指定文字列は“ｂｏｏｋ”となっている。［２］、［４］も同様に軸が“ｃｈｉｌｄ”で要素指定文字列は各々“ｅｄｉｔｏｒ”、“ｔｉｔｌｅ”となっている。［３］は軸名が“ｐａｒｅｎｔ”で要素指定文字列が“ｎｏｄｅ（）”の構造条件である。“ｎｏｄｅ（）”は要素名ではなく、任意の種類の要素を指定する文字列である。
【００７５】
図１５は、本実施形態における構造条件書換え処理の流れを示すフローチャートである。この図１５のフローチャートにおいて、ステップＳ１０１の処理は、第１の実施形態で説明したステップＳ２１と同様であるため、説明を省略する。
【００７６】
ステップＳ１０１の処理の次に、構造条件書換え部２８は、ステップＳ１０１で取得した要素Ｐの軸名が子孫構造条件の１種であるｃｈｉｌｄであるか否かを判定する（ステップＳ１０２）。
【００７７】
要素Ｐの軸名が子孫構造条件の１種であるｃｈｉｌｄであると判定された場合（ステップＳ１０２：Ｙｅｓ）、構造条件書換え部２８は、構造条件内の要素指定文字列を書換えパラメータＸとする（ステップＳ１０３）。次に、構造条件書換え部２８は、分割リストが空かを判定する（ステップＳ１０４）。
【００７８】
分割リストが空でないと判定された場合（ステップＳ１０４：Ｎｏ）、構造条件書換え部２８は、分割リストの先頭の要素Ｑを取得する（ステップＳ１０５）。次に、構造条件書換え部２８は、要素Ｑが、軸の値が”ｐａｒｅｎｔ”かつ要素指定文字列が”ｎｏｄｅ（）”の構造条件であるか否かを判定する（ステップＳ１０６）。
【００７９】
要素Ｑが、軸の値が”ｐａｒｅｎｔ”かつ要素指定文字列が”ｎｏｄｅ（）”の構造条件であると判定された場合（ステップＳ１０６：Ｙｅｓ）、構造条件書換え部２８は、図１６で示す表から書換えベースクエリＹを取得する（ステップＳ１０９）。図１６は、構造条件書換えにおける２つの連続した構造条件の書換えルールの一例である。図１６は「番号」「先頭軸名」、「後続軸名」「後続要素文字列」、「書換えベースクエリ」の項目を有する。「番号」は書換えルール毎に割り当てられる識別番号である。今回は説明を単純化するため１つだけとする。「先頭軸名」は最初にチェックされる構造条件の軸名である。「構造軸名」は先頭の構造条件の次の構造条件の軸名である。「後続要素文字列」は先頭の構造条件の次の構造条件の要素文字列である。「書換えベースクエリ」はルールごとの書換えクエリの基本テンプレートである。［パラメータＣ］は書換えベースクエリの変更可能なパラメータ部分である。図１６のルールは、該当条件が連続する２つの構造条件が必要になるが、書換えベースクエリは図１０の書換えベースクエリと比較して単純な形に変換可能である。
【００８０】
次に、構造条件書換え部２８は、書換えベースクエリＹの［パラメータＣ］の部分を書換えパラメータＸに書き換える（ステップＳ１１０）。次に、構造条件書換え部２８は、書き換えた結果を書換えクエリに追加する（ステップＳ１１１）。次に、構造条件書換え部２８は、要素Ｑを分割リストから削除する（ステップＳ１１２）。
【００８１】
次に、構造条件書換え部２８は、分割リストが空か否かを判定する（ステップＳ１０８）。分割リストが空と判定された場合（ステップＳ１０８がＹｅｓ）、構造条件書換え部２８は、構造条件書換え処理を終了し書換えクエリを出力する。
【００８２】
一方、要素Ｐの軸名が子孫構造条件の１種であるｃｈｉｌｄでないと判定された場合（ステップＳ１０２：Ｎｏ）、要素Ｐを書き換えずにそのまま書換えクエリに追加する（ステップＳ１０７）。次にステップ１０８に進み同様の処理を繰り返す。
【００８３】
一方、分割リストが空の場合（ステップＳ１０４：Ｙｅｓ）、ステップＳ１０７に進み再び同じ処理を繰り返す。
【００８４】
一方、要素Ｑが、軸の値が”ｐａｒｅｎｔ”かつ要素指定文字列が”ｎｏｄｅ（）”の構造条件ではないと判定された場合（ステップＳ１０６：Ｎｏ）、ステップＳ１０７に進み再び同じ処理を繰り返す。
【００８５】
ここで、図１４に例示した構造条件分割結果を用いて、一般的な構造条件書換えを行った場合の処理の概要を説明する。
【００８６】
はじめに入力として図１４の［１］から［４］までの４つの要素からなる分割リストを受け取り、構造条件書換え部２８は、最初の要素［１］を取り出した後、［１］をリストから削除する（ステップＳ１０１）。次に、構造条件書換え部２８は、［１］の軸名が“ｃｈｉｌｄ”構造条件かどうかを判定し、条件に合致したため要素指定文字列“ｂｏｏｋ”を書換えパラメータＸとする（ステップＳ１０２、Ｓ１０３）。
【００８７】
次に、構造条件書換え部２８は、分割リストが空かを判定し、空ではないため先頭要素Ｑとして［２］を取得する（ステップＳ１０４、Ｓ１０５）。次にＱの軸が“ｐａｒｅｎｔ”ではないため要素Ｐである［１］を書換えクエリに追加する（ステップＳ１０６、Ｓ１０７）。次に分割リストが空ではないため、構造条件書換え部２８は、リストの先頭の［２］を要素Ｐとして取得する（ステップＳ１０８、Ｓ１０１）。要素Ｐである［２］の軸が“ｃｈｉｌｄ”の構造条件であるため、要素指定文字列“ｅｄｉｔｏｒ”を書換えパラメータＸとする（ステップＳ１０２、Ｓ１０３）。
【００８８】
次に、構造条件書換え部２８は、分割リストが空かを判定し、空ではないため先頭要素Ｑとして［３］を取得する（ステップＳ１０４、Ｓ１０５）。次にＱの軸が“ｐａｒｅｎｔ”であり、要素文字列が“ｎｏｄｅ（）”の構造条件であるため、図１６の表から書換えベースクエリＹを取得する（ステップＳ１０６、ステップＳ１０９）。次に、構造条件書換え部２８は、書換えベースクエリＹの［パラメータＣ］の部分を書換えパラメータＸである“ｅｄｉｔｏｒ”に書き換える（ステップＳ１１０）。次に、構造条件書換え部２８は、書換えベースＹを書換えクエリに追加して、分割リストから要素Ｑを削除する（ステップＳ１１１、Ｓ１１２）。
【００８９】
次に、構造条件書換え部２８は、分割リストが空ではないため、リストの先頭の［４］を要素Ｐとして取得する（ステップＳ１０８、Ｓ１０１）。要素Ｐである［４］の軸が“ｃｈｉｌｄ”の構造条件であるため、構造条件書換え部２８は、要素指定文字列“ｔｉｔｌｅ”を書換えパラメータＸとする（ステップＳ１０２、Ｓ１０３）。次に分割リストが空であるため、構造条件書換え部２８は、要素Ｐである［４］を書換えクエリに追加する（ステップＳ１０４、Ｓ１０７）。
【００９０】
次に、分割リストが空であるため、構造条件書換え部２８は、構造条件書換え処理を終了する（ステップＳ１０８）。図１７は図１４に例示した構造条件分割結果を用いて、構造条件書換えを行った書換えクエリの結果である。［２］、［３］に該当する構造条件が１つの書換えルールで（）で始まるブロックに単純に書き換えられている。
【００９１】
構造条件書換え部２８による構造条件書換え処理が終了すると、構造条件書換え部２８は、書き換えられたＸＱｕｅｒｙを出力する。以降は第１の実施形態と同様に、クエリ実行部２９は、書き換えられたＸＱｕｅｒｙを実行して、検索され結果を出力する（ステップＳ４）。
【００９２】
クエリ実行部２９によるクエリ実行処理が終了すると、最後に、検索インタフェース部２６は、クエリ実行部２９による出力を結果データとしてクライアント端末３に返却する（ステップＳ５）。
【００９３】
図１８は、図４の構造化文書Ｄ１、Ｄ２に対して図１３に例示した書換えＸＱｕｅｒｙを実行した結果である。「著者名が”ｅｄｉｔｏｒ”要素以下に記述された構造化文書のタイトルを出せ」という元のＸＱｕｅｒｙの意図通りに、構造化文書Ｄ１は著者名を表す要素名が“ｅｄｉｔｏｒ”ではなく“ａｕｔｈｏｒ”であるため出力されず、構造化文書Ｄ２は著者名を表す要素名が“ｅｄｉｔｏｒ”であるため、兄弟要素である“ｔｉｔｌｅ”要素が出力される。
【００９４】
以上、具体的な例を挙げながら説明したように、本実施形態によれば、子孫構造条件以外の構造条件を書き換える際に、前後する他の構造条件と組み合わせて書き換えることで、該当部分の構造条件を単独で書き換えるよりも単純な書換え結果を実現することができる。
【００９５】
以上説明した各実施形態におけるサーバ１の機能は、例えば、コンピュータの演算装置であるＣＰＵ１０１が、アプリケーションプログラムとして実装された構造化文書管理プログラムを実行することにより実現される。
【００９６】
また各実施形態におけるサーバ１で実行される構造化文書管理プログラムは、例えば、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）などのコンピュータで読み取り可能な記録媒体１１０に記録されて提供される。
【００９７】
また、各実施形態におけるサーバ１で実行される構造化文書管理プログラムを、インターネットなどのネットワーク２に接続されたコンピュータ上に格納し、ネットワーク２経由でダウンロードさせることにより提供するように構成してもよい。また、各実施形態におけるサーバ１で実行される構造化文書管理プログラムを、インターネットなどのネットワーク２経由で提供または配布するように構成してもよい。さらに、各実施形態におけるサーバ１で実行される構造化文書管理プログラムを、ＲＯＭ１０２などに予め組み込んで提供するように構成してもよい。
【００９８】
また、各実施形態におけるサーバ１で実行される構造化文書管理プログラムは、格納インタフェース部２４、検索インタフェース部２６、構造条件分割部２７、構造条件書換え部２８、クエリ実行部２９などを含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ（プロセッサ）１０１がＨＤＤ１０４などから構造化文書管理プログラムを読み出して実行することにより上記各部が主記憶装置（例えばＲＡＭ１０３）上にロードされ、格納インタフェース部２４、検索インタフェース部２６、構造条件分割部２７、構造条件書換え部２８、クエリ実行部２９、などが主記憶装置上に生成されるようになっている。
【００９９】
以上述べた少なくとも一つの実施形態にかかる構造化文書管理システムによれば、入力クエリデータを単純な構造条件に変えて構造照合処理を実行するようにしているので、入力クエリデータが複雑な構造条件を含む場合でも、構造照合処理の高速化を実現し、複雑な構造条件を含むクエリデータによる検索を高速に実行することができる。また入力クエリデータの該当する構造条件部分のみを書き換えているため単純な構成で実現できる。さらに構造条件に書き換える際に、書き換えた子孫構造条件の入力が、それまでのクエリデータの処理で得られた構造化文書のみを対象とするように書き換えている。これにより構造化文書集合全てに対してではなく、それまでの処理で絞り込まれた構造化文書集合に対してのみ書き換えた子孫構造条件を実施すれば良いため検索を高速に実行することができる。
【０１００】
なお、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、請求の範囲に記載された発明とその均等の範囲に含まれる。
【要約】
構造化文書管理装置（１）は、階層化された論理構造を有する構造化文書を検索するためのクエリデータの入力を受け付ける検索インタフェース部（２６）と、クエリデータを、複数の構造条件を含む要素単位に分割する構造条件分割部（２７）と、分割された前記構造条件の種類が構造化文書の上位の階層から下位の階層を指定する子孫構造条件以外であった場合、前記構造条件を、構造条件の前後の前記要素に影響を与えないようにそれぞれの前記構造条件の種類毎に予め定められた子孫構造条件と結合演算処理とを含む書換えクエリに書き換える構造条件書換え部（２８）と、前記構造条件、及び書換えクエリとを含むクエリデータを入力として、検索結果を出力するクエリ実行部（２９）と、を備える。【図１】
0005439606.tif 000002
【図２】
0005439606.tif 000003
【図３】
0005439606.tif 000004
【図４】
0005439606.tif 000005
【図５】
0005439606.tif 000006
【図６】
0005439606.tif 000007
【図７】
0005439606.tif 000008
【図８】
0005439606.tif 000009
【図９】
0005439606.tif 000010
【図１０】
0005439606.tif 000011
【図１１】
0005439606.tif 000012
【図１２】
0005439606.tif 000013
【図１３】
0005439606.tif 000014
【図１４】
0005439606.tif 000015
【図１５】
0005439606.tif 000016
【図１６】
0005439606.tif 000017
【図１７】
0005439606.tif 000018
【図１８】
0005439606.tif 000019