(57)【要約】【課題】階層構造を有するＸＭＬデータベースから漠然とした検索条件を基に文書構造を効率よく検索することのできる文書構造検索装置を提供する。【解決手段】階層構造を有するデータベースに記憶されている複数の構造化文書の異なる文書構造の中から所望の文書構造を検索するものであって、文書構造を検索するための検索条件として、少なくとも１つのキーワードが入力されると、当該キーワードの類似語を求めて、異なる文書構造のそれぞれを構成する各構成要素で構成された階層構造から、キーワードと類似語のうちのいずれかを要素名あるいは要素値に含む構成要素を検索し、この検索された構成要素を含む文書構造を検索結果として出力する。【選択図】　　図１
2004126640.tif 000002
【特許請求の範囲】
【請求項１】
階層構造を有するデータベースに記憶されている複数の構造化文書の異なる文書構造の中から所望の文書構造を検索するための文書構造検索方法であって、
前記階層構造は、前記異なる文書構造のそれぞれを構成する各構成要素で構成されており、
前記文書構造を検索するための検索条件として、少なくとも１つのキーワードが入力されると、
当該キーワードの類似語を求めて、前記階層構造から前記キーワードと前記類似語のうちのいずれかを要素名あるいは要素値に含む構成要素を検索し、
この検索された構成要素を含む文書構造を検索結果として出力することを特徴とする文書構造検索方法。
【請求項２】
前記検出された構成要素を基点として前記階層構造を上流に辿っていくことで当該文書構造の先頭の構成要素を検出し、当該検出された構成要素を先頭とする文書構造を検索結果として出力することを特徴とする請求項１記載の文書構造検索方法。
【請求項３】
前記検出された構成要素を含む文書構造から、当該文書構造に必須の構成要素を抽出して前記検索結果の文書構造として出力することを特徴とする請求項１記載の文書構造検索方法。
【請求項４】
少なくとも、前記データベースに格納されている前記複数の構造化文書のそれぞれの文書構造と前記階層構造上の格納位置とを含む論理構造を記憶し、
文書構造が同一あるいは一部が同一の複数の構造化文書が前記階層構造上の同じ格納位置に格納されるとき、前記論理構造上では、複数の構造化文書で共通する構成要素は１つに集約して１つの構成要素として表されており、
この論理構造の前記検出された構成要素を基点として、当該論理構造を上流に辿っていくことで前記文書構造の先頭の構成要素を検出し、当該検出された構成要素を先頭とする文書構造を検索結果として出力することを特徴とする請求項１記載の文書構造検索方法。
【請求項５】
前記論理構造には、前記複数の構造化文書のそれぞれに対応する文書構造の先頭の構成要素に対し、当該構成要素が先頭の構成要素であることを表す第１の属性情報が付加されており、
この第１の属性情報に基づき、前記論理構造から前記検索結果としての文書構造を抽出することを特徴とする請求項４記載の文書構造検索方法。
【請求項６】
前記論理構造には、前記複数の構造化文書のそれぞれに対応する文書構造を構成する構成要素のうち当該文書構造に必須の構成要素に対し、当該構成要素が必須の構成要素であることを表す第２の属性情報が付加されており、
この第２の属性情報に基づき、前記論理構造から前記必須の構成要素からなる文書構造を前記検索結果として抽出することを特徴とする請求項４記載の文書構造検索方法。
【請求項７】
前記検索された構成要素の要素名あるいは要素値と前記キーワードとの類似度に基づき、前記検索結果の文書構造の評価値を求めて、この評価値とともに、前記検索結果の文書構造を出力することを特徴とする請求項１記載の文書構造検索方法。
【請求項８】
階層構造を有するデータベースに記憶されている複数の構造化文書の異なる文書構造の中から所望の文書構造を検索するための文書構造検索方法であって、
前記階層構造は、前記異なる文書構造のそれぞれを構成する各構成要素で構成されており、
前記文書構造を検索するための検索条件として、少なくとも１つの第１のキーワードと、少なくとも１つの第２のキーワードが入力されると、
前記第１のキーワードの類似語を求めて、前記階層構造から前記第１のキーワードとその類似語のうちのいずれかを要素名あるいは要素値に含む第１の構成要素を検索するとともに、
前記第２のキーワードの類似語を求めて、前記階層構造から前記第２のキーワードとその類似語のうちのいずれかを要素名に含む第２の構成要素を検索し、
少なくとも、前記第２の構成要素を先頭とする文書構造のうち、前記第１の構成要素を含む文書構造を検索結果として出力することを特徴とする文書構造検索方法。
【請求項９】
前記第１の構成要素を基点として前記階層構造を上流に辿っていくことで前記第２の構成要素に至るとき、当該第２の構成要素を先頭とする文書構造を検索結果として出力することを特徴とする請求項８記載の文書構造検索方法。
【請求項１０】
前記第２の構成要素を先頭とする、前記第１の構成要素を含む文書構造から当該文書構造に必須の構成要素を抽出して前記検索結果の文書構造として出力することを特徴とする請求項８記載の文書構造検索方法。
【請求項１１】
少なくとも、前記データベースに格納されている前記複数の構造化文書のそれぞれの文書構造と前記階層構造上の格納位置とを含む論理構造を記憶し、
文書構造が同一あるいは一部が同一の複数の構造化文書が前記階層構造上の同じ格納位置に格納されるとき、前記論理構造上では、複数の構造化文書で共通する構成要素は１つに集約して１つの構成要素として表されており、
この論理構造の前記第１の構成要素を基点として、当該論理構造を上流に辿っていくことで前記第２の構成要素に至るとき、当該第２の構成要素を先頭とする文書構造を検索結果として出力することを特徴とする請求項８記載の文書構造検索方法。
【請求項１２】
前記論理構造には、前記複数の構造化文書のそれぞれに対応する文書構造の先頭の構成要素に対し、当該構成要素が先頭の構成要素であることを表す第１の属性情報が付加されており、
この第１の属性情報に基づき、前記論理構造から前記検索結果としての文書構造を抽出することを特徴とする請求項１１記載の文書構造検索方法。
【請求項１３】
前記論理構造には、前記複数の構造化文書のそれぞれに対応する文書構造を構成する構成要素のうち当該文書構造に必須の構成要素に対し、当該構成要素が必須の構成要素であることを表す第２の属性情報が付加されており、
この第２の属性情報に基づき、前記論理構造から前記必須の構成要素からなる文書構造を前記検索結果として抽出することを特徴とする請求項１１記載の文書構造検索方法。
【請求項１４】
前記第１の構成要素の要素名あるいは要素値と前記第１のキーワードとの第１の類似度と、前記第２の構成要素の要素名と前記第２のキーワードとの第２の類似度とに基づき、前記検索結果の文書構造の評価値を求めて、この評価値とともに、前記検索結果の文書構造を出力することを特徴とする請求項８記載の文書構造検索方法。
【請求項１５】
階層構造を有するデータベースに記憶されている複数の構造化文書の異なる文書構造の中から所望の文書構造を検索するための文書構造検索装置であって、
前記文書構造を検索するための検索条件として、少なくとも１つのキーワードを入力する入力手段と、
この入力手段で入力されたキーワードの類似語を求める手段と、
前記異なる文書構造のそれぞれを構成する各構成要素で構成された前記階層構造から、前記キーワードと前記類似語のうちのいずれかを要素名あるいは要素値に含む構成要素を検索する検索手段と、
この検索手段で検索された構成要素を含む文書構造を前記階層構造から抽出する抽出手段と、
この抽出手段で抽出された文書構造を検索結果として出力する手段と、
を具備したことを特徴とする文書構造検索装置。
【請求項１６】
少なくとも、前記データベースに格納されている前記複数の構造化文書のそれぞれの文書構造と前記階層構造上の格納位置とを含む論理構造を記憶する記憶手段をさらに具備し、
文書構造が同一あるいは一部が同一の複数の構造化文書が前記階層構造上の同じ格納位置に格納されるとき、前記論理構造上では、複数の構造化文書で共通する構成要素は１つに集約して１つの構成要素として表されており、
前記抽出手段は、前記論理構造の前記検出された構成要素を基点として、当該論理構造を上流に辿っていくことで前記文書構造の先頭の構成要素を検出し、当該検出された構成要素を先頭とする文書構造を検索結果として抽出することを特徴とする請求項１５記載の文書構造検索装置。
【請求項１７】
前記論理構造には、前記複数の構造化文書のそれぞれに対応する文書構造の先頭の構成要素に対し、当該構成要素が先頭の構成要素であることを表す第１の属性情報が付加されており、
前記抽出手段は、前記第１の属性情報に基づき、前記論理構造から前記検索結果としての文書構造を抽出することを特徴とする請求項１６記載の文書構造検索装置。
【請求項１８】
階層構造を有するデータベースに記憶されている複数の構造化文書の異なる文書構造の中から所望の文書構造を検索するための文書構造検索装置であって、
前記文書構造を検索するための検索条件として、少なくとも１つの第１のキーワードと、少なくとも１つの第２のキーワードを入力する入力手段と、
前記入力手段で入力された前記第１のキーワードの類似語と、前記第２のキーワードの類似語を求める手段と、
前記異なる文書構造のそれぞれを構成する各構成要素で構成された前記階層構造から、前記第１のキーワードとその類似語のうちのいずれかを要素名あるいは要素値に含む第１の構成要素を検索する第１の検索手段と、
前記階層構造から、前記第２のキーワードとその類似語のうちのいずれかを要素名に含む第２の構成要素を検索する第２の検索手段と、
少なくとも、前記第２の構成要素を先頭とする文書構造のうち、前記第１の構成要素を含む文書構造を前記階層構造から抽出する抽出手段と、
この抽出手段で抽出された文書構造を検索結果として出力する手段と、
を具備したことを特徴とする文書構造検索装置。
【請求項１９】
少なくとも、前記データベースに格納されている前記複数の構造化文書のそれぞれの文書構造と前記階層構造上の格納位置とを含む論理構造を記憶する記憶手段をさらに具備し、
文書構造が同一あるいは一部が同一の複数の構造化文書が前記階層構造上の同じ格納位置に格納されるとき、前記論理構造上では、複数の構造化文書で共通する構成要素は１つに集約して１つの構成要素として表されており、
前記抽出手段は、前記論理構造の前記第１の構成要素を基点として、当該論理構造を上流に辿っていくことで前記第２の構成要素に至るとき、当該第２の構成要素を先頭とする文書構造を検索結果として出力することを特徴とする請求項１８記載の文書構造検索装置。
【請求項２０】
前記論理構造には、前記複数の構造化文書のそれぞれに対応する文書構造の先頭の構成要素に対し、当該構成要素が先頭の構成要素であることを表す第１の属性情報が付加されており、
前記抽出手段は、前記第１の属性情報に基づき、前記論理構造から前記検索結果としての文書構造を抽出することを特徴とする請求項１９記載の文書構造検索装置。
【請求項２１】
階層構造を有するデータベースに記憶されている複数の構造化文書の異なる文書構造の中から所望の文書構造を検索するための文書構造検索プログラムであって、
コンピュータに、
前記文書構造を検索するための検索条件として、少なくとも１つのキーワードを入力する入力ステップと、
この入力ステップで入力されたキーワードの類似語を求めるステップと、
前記異なる文書構造のそれぞれを構成する各構成要素で構成された前記階層構造から、前記キーワードと前記類似語のうちのいずれかを要素名あるいは要素値に含む構成要素を検索する検索ステップと、
この検索ステップで検索された構成要素を含む文書構造を前記階層構造から抽出する抽出ステップと、
この抽出ステップで抽出された文書構造を検索結果として出力するステップと、
を実行させる文書構造検索プログラム。
【請求項２２】
階層構造を有するデータベースに記憶されている複数の構造化文書の異なる文書構造の中から所望の文書構造を検索するための文書構造検索プログラムであって、
コンピュータに、
前記文書構造を検索するための検索条件として、少なくとも１つの第１のキーワードと、少なくとも１つの第２のキーワードを入力する入力ステップと、
前記入力手段で入力された前記第１のキーワードの類似語と、前記第２のキーワードの類似語を求めるステップと、
前記異なる文書構造のそれぞれを構成する各構成要素で構成された前記階層構造から、前記第１のキーワードとその類似語のうちのいずれかを要素名あるいは要素値に含む第１の構成要素を検索する第１の検索ステップと、
前記階層構造から、前記第２のキーワードとその類似語のうちのいずれかを要素名に含む第２の構成要素を検索する第２の検索ステップと、
少なくとも、前記第２の構成要素を先頭とする文書構造のうち、前記第１の構成要素を含む文書構造を前記階層構造から抽出する抽出ステップと、
この抽出ステップで抽出された文書構造を検索結果として出力するステップと、
を実行させるプログラム。
【発明の詳細な説明】
【０００１】
【発明属する技術分野】
本発明は、階層構造を有するデータベースに記憶されている複数の構造化文書の異なる文書構造の中から所望の文書構造を検索するための文書構造検索方法および構造化文書検索装置に関する。
【０００２】
【従来の技術】
ＸＭＬ（Ｅｘｔｅｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）で記述された文書のような構造化文書を格納するデータベースとして、階層構造を有し、文書構造の異なる複数の構造化文書のそれぞれを１つの大きなツリー構造上の一部分文書として格納して管理するものがある。
【０００３】
ＸＭＬで記述された文書（以下、ＸＭＬ文書、ＸＭＬデータなどとも呼ぶ）などの構造化文書の文書構造のことをスキーマと呼ぶ。スキーマはデータ作成者が、明示的にスキーマ言語（ＸＭＬ−ＳＣＨＥＭＡやＲｅｌａｘ　ＮＧなど）を用いて規定することも可能である（スキーマ言語によりスキーマを記述したものをスキーマ文書とよび、これも構造化文書である）が、一般的にスキーマ言語によりスキーマを記述するのは手間がかかる。更に、ＸＭＬはＳＧＭＬと異なり、データに対してスキーマ言語によってスキーマを規定する必要はなく、あくまで、オプションの位置付けである。
【０００４】
なお、上記のような階層構造をもつＸＭＬデータベースとは異なり、フォルダ単位に各ＸＭＬ文書を格納するフラットな（階層化されていない）データ構造をもつＸＭＬデータベースも存在するが、この場合は、明らかにスキーマはフォルダ単位で格納されており、階層化されて管理されていない。
【０００５】
階層構造をもち、１つの大きなツリー構造にてＸＭＬ文書を管理するＸＭＬデータベース（以下、階層化ＸＭＬデータベースと呼ぶ）の場合、各構造化文書の文書構造は、階層構造の一部として管理されることになる。
【０００６】
スキーマは必ずしも予め定めておく必要はないが、階層化ＸＭＬデータベースに格納されている全てのＸＭＬ文書がそれぞれ異なる文書構造をもつとなれば、管理しずらくなることは否めない。格納文書を効率よく管理する上からも、内容的に類似する（同じカテゴリに属する）ＸＭＬ文書は、全く異なる文書構造であるよりも、同じ文書構造である方が望ましい。
【０００７】
ＸＭＬ文書作成者が各自ばらばらの文書構造によりＸＭＬ文書を作成した場合、文書構造が氾濫し、階層かＸＭＬデータベースは単なる検索エンジン以上の利用方法が行えなくなり、ＸＭＬのメリットが失われる恐れがある。
【０００８】
すなわち、階層化ＸＭＬデータベースにおいては、スキーマの氾濫を極力抑えることが望ましい。このためにＸＭＬ文書を作成する前に階層化ＸＭＬデータベース中の内容的に類似するＸＭＬ文書のもつスキーマを検索し、そのスキーマを利用してデータを作成する、ということが考えられる。
【０００９】
しかしながら、従来の階層化ＸＭＬデータベースでは、以下の２つの問題点が存在する。
【００１０】
第１の問題点としては、階層ＸＭＬデータベースにおいて、所望の文書構造のみを検索する有効な手段がないということである。全ての格納文書に対してスキーマ言語によりスキーマを規定しておけば、これらをデータベースで管理することで、スキーマ検索は容易になるのだが、スキーマ言語の規定はあくまでオプションであるので、この場合だと、登録されたスキーマ言語しか検索されないことになる。
【００１１】
これとは別の方法で、曖昧な構造を指定してデータをＸＱｕｅｒｙなどで検索した結果のＸＭＬデータを吟味して構造をユーザの目で抽出する方法も考えられるが、この場合のコストも大きい。欲しいのはスキーマであって、データではないからである。
【００１２】
例えば、任意の要素名を検索条件に指定し、検索結果として文書とともにその文書が従うＤＴＤ（Ｄｏｃｕｍｅｎｔ　Ｔｙｐｅ　Ｄｅｆｉｎｉｔｉｏｎ）情報も返すというものある（例えば、特許文献１参照）。しかしながら、この手法によれば、ＤＴＤに従わない文書に対してはその情報を得ることはできず、また、その粒度も文書単位であり、ＤＴＤの構成要素のみを返す（部分文書のスキーマのみを返す）といったことはできない。
【００１３】
また、種文書から類似する文書を検索して表示させるというものもある（例えば、特許文献２参照）。ここに開示されている手法は、取得した文書がどのスキーマに従うか、などは目視に頼らざるを得ず、また、検索結果としてはやはり文書単位であるので、部分文書に含まれるスキーマなどの抽出においては類似度が低くなるなどの問題点が残る。
【００１４】
さらに、新規に登録される要素名、属性名をテーブルで管理するといものもある（例えば、特許文献３参照）。しかし、この手法は、ＸＭＬ文書をフラット管理するデータベースのみで有効な手法で、文書構造が階層的に管理されている階層化ＸＭＬデータベースについては全く考慮にいれていない。
【００１５】
第２の問題点としては、ユーザが文書構造を検索しようとする際に、どのように検索を行えばよいか、どのような結果があればよいか、など、検索対象が曖昧で漠然としている場合がほとんであるから、このような場合に対処可能なように、曖昧性を含んだ文書構造の検索条件の指定方法が存在しなかった。
【００１６】
どのような検索を行うか、に関して言えば、例えば、「本」情報のスキーマを検索したい場合は、一般的には、本という要素を定義したスキーマ要素を検索する。しかしながら、正確に「本」と定義されておらず、「書物」とか「Ｂｏｏｋ」などを定義したスキーマで検索して欲しい場合もある。
【００１７】
更に漠然とキーワードだけから、まとめあげるようなスキーマを検索したいという要求もある。この場合は、このキーワードが意味するものが要素であるか、属性であるか、値であるかなどの判別がまるでなく、漠然としたデータを格納するスキーマをなんでもよいから検索せよ、という意図が込められている。
【００１８】
このように、ユーザはスキーマを検索する時点においては、漠然としたもので、確定したものではなく、これを吸収できる仕組みにするべきである。
【００１９】
従来ある検索手法では（例えば、特許文献２参照）、タグ名に完全一致しない限りは検索として出力されなかった。予めＤＴＤを指定すれば、それに従った構造を示してくれるが、スキーマを検索するという本発明の主眼からは外れる。
【００２０】
また、どのような結果、に対しても、単なる、スキーマ言語を返すのではなく、ユーザが利用したい情報も付加するべきである。
【００２１】
スキーマ言語によりスキーマは規定しなくても、データをＸＭＬ文書として管理しようと考える際には、ユーザは暗黙的にスキーマを想定し、それに従って文書を作成する場合が多い。更に、似たスキーマを持つデータは階層化されたデータベース中の同一のパスに並べて管理する傾向が強い。これらは暗黙のスキーマ定義であると見なせ、スキーマ言語による明示的スキーマ定義と同様に管理する方法が必要である。
【００２２】
また、ユーザの意図に応じてスキーマ検索（文書構造の検索）の用途が異なるが、主に２通りに分かれる。
【００２３】
１つ目は、ある程度検索したいスキーマを予測できる場合である。例えば、「特許関連のスキーマ」を検索する場合は、抽出すべきスキーマは「特許」情報のＸＭＬ文書を規定したスキーマに類似するようなスキーマが検索される。
【００２４】
２つ目は、データは存在しているがどういう構造にして、どういう風にまとめあげるか、という視点すらまだ決まっていないが、近いスキーマを検索して欲しい、というものである。この場合、格納したいデータから、その関連でいかに有益なスキーマをユーザに提示してやるかが主眼となる。
【００２５】
検索結果にしても、階層化データベースであり、スキーマも階層的に配置されることが前提となる。
【００２６】
【特許文献１】
特開２０００−２００２８６号公報
【００２７】
【特許文献２】
特開２００１−１４３２６号公報
【００２８】
【特許文献３】
特開２００２−７４３９号公報
【００２９】
【発明が解決しようとする課題】
このように、従来は、階層構造を有するＸＭＬデータベースから文書構造のみを検索条件の曖昧性を加味しながら効率よく検索する手法が存在しなかった。
【００３０】
そこで、本発明は、階層構造を有するＸＭＬデータベースから漠然とした検索条件を基に文書構造を効率よく検索することのできる文書構造検索方法、文書構造検索装置およびプログラムを提供することを目的とする。
【００３１】
【課題を解決するための手段】
本発明は、階層構造を有するデータベースに記憶されている複数の構造化文書の異なる文書構造の中から所望の文書構造を検索するためのものであって、前記階層構造は、前記異なる文書構造のそれぞれを構成する各構成要素で構成されており、前記文書構造を検索するための検索条件として、少なくとも１つのキーワードが入力されると、当該キーワードの類似語を求めて、前記階層構造から前記キーワードと前記類似語のうちのいずれかを要素名あるいは要素値に含む構成要素を検索し、この検索された構成要素を含む文書構造を検索結果として出力することを特徴とする。
【００３２】
本発明によれば、少なくとも１つのキーワードを入力するだけで、当該キーワードとその類似範囲にある語のうちのいずれかを要素名や要素値にもつ構成要素を含む文書構造を効率よく求めることができる。
【００３３】
また、本発明は、階層構造を有するデータベースに記憶されている複数の構造化文書の異なる文書構造の中から所望の文書構造を検索するためのものであって、前記階層構造は、前記異なる文書構造のそれぞれを構成する各構成要素で構成されており、前記文書構造を検索するための検索条件として、少なくとも１つの第１のキーワードと、少なくとも１つの第２のキーワードが入力されると、前記第１のキーワードの類似語を求めて、前記階層構造から前記第１のキーワードとその類似語のうちのいずれかを要素名あるいは要素値に含む第１の構成要素を検索するとともに、前記第２のキーワードの類似語を求めて、前記階層構造から前記第２のキーワードとその類似語のうちのいずれかを要素名に含む第２の構成要素を検索し、少なくとも、前記第２の構成要素を先頭とする文書構造のうち、前記第１の構成要素を含む文書構造を検索結果として出力することを特徴とする。
【００３４】
本発明によれば、少なくとも１つの第１のキーワードと少なくとも１つの第２のキーワードを入力するだけで、当該第１のキーワードとその類似範囲にある語のうちのいずれかを要素名や要素値にもつ構成要素を含む文書構造であって、当該第２のキーワードとその類似範囲にある語のうちのいずれかを要素名にもつ構成要素を先頭とする文書構造を効率よく求めることができる。
【００３５】
【発明の実施の形態】
まず、本発明の実施形態について説明する前に、構造化文書管理システムの基本的な構成および処理動作について説明する。
【００３６】
（構造化文書管理システムの説明）
構造化文書として、ＸＭＬやＳＧＭＬなどで記述した文書が挙げられる。ＳＧＭＬ（Ｓｔａｎｄａｒｄ　Ｇｅｎｅｒａｌｉｚｅｄ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）とは、ＩＳＯ（国際標準化機構）で定められた規格である。ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）とは、Ｗ３Ｃ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂ　Ｃｏｎｓｏｒｔｉｕｍ）にて定められた規格である。これらは、文書を構造化することを可能とする構造化文書の規格である。
【００３７】
以下、構造化文書として、ＸＭＬにて記述された文書を例に説明を進める。構造化文書の文書構造を定義したデータ（文書構造定義データ）をスキーマと呼ぶ。ＸＭＬではスキーマを定義するためにＸＭＬ−ＳｃｈｅｍａやＸＤＲ（ＸＭＬＤａｔａ　Ｒｅｄｕｃｅｄ）などのスキーマ言語が提案されている。ここでは、例えば、ＸＤＲでスキーマを記述する場合を例にとり説明する。
【００３８】
スキーマも、構造化文書管理システムの管理対象の構造化文書であり、ここでは、スキーマ文書と呼ぶことがある。スキーマ文書以外の構造化文書であって、特許明細書やメール、週報、広告などの種々雑多な内容を有する文書を、ここでは、コンテンツ文書と呼ぶこともある。
【００３９】
構造化文書管理システムでは、上記スキーマ文書、上記コンテンツ文書、さらに、後述するようなユーザからの検索要求を記述したクエリ、すなわち、クエリ文書も管理対象とし、これらを総称して「文書」と呼ぶ。
【００４０】
以下、特にことわりがない場合、「文書」と呼ぶときは、コンテンツ文書、スキーマ文書、クエリ文書を全て指すものとする。
【００４１】
まず、実施形態の説明の前に、ＸＭＬについて簡単に説明する。
【００４２】
図３は、ＸＭＬで記述された構造化文書の一例として、「特許」情報の例を示したものである。ＸＭＬやＳＧＭＬは、文書の構造の表現にタグが用いられる。タグには、開始タグと終了タグがある。文書構造の各構成要素は、開始タグと終了タグで囲まれている。開始タグとは構成要素の要素名を「＞」で閉じたものであり、終了タグとは要素名を記号「＜／」と「＞」で閉じたものである。タグに続く構成要素の内容が、テキスト（文字列）または子供の構成要素の繰り返しである。また開始タグには「＜要素名　属性＝“属性値”＞」などのように属性情報を設定することができる。「＜特許ＤＢ＞＜／特許ＤＢ＞」のようにテキストを含まない構成要素は、簡易記法として「＜特許ＤＢ／＞」のように表わすこともできる。
【００４３】
図３に示した文書は、「特許」タグから始まる要素をルートとし、その子要素として「タイトル」、「出願日」、「出願者」、「要約」タグから始まる要素が存在する。また、例えば、「タイトル」タグから始まる要素には「ＸＭＬデータベース」といった、１つのテキスト（文字列）が要素値として存在する。
【００４４】
ＸＭＬなどの構造化文書は、任意の構成要素を繰り返し含んでいたり、さらには文書構造があらかじめ決まっていないのが普通である。
【００４５】
図３に示したような構造化文書を論理的に表現するために、図４に示すようなツリー表現が用いられる。ツリーは、ノード（番号が付され、円形で示されたもの）とアーク（ノードを表す円形間をつなぐデータ付き線）と四角形で囲まれたテキストから構成されている。
【００４６】
１つのノードは１つの構成要素、すなわち、１つの文書オブジェクトに対応する。ノードからタグ名や属性名に相当するラベルが付与された複数のアークが出てきている。そのアークの先は、ノード値または要素値としての文字列（テキスト）である。ノードの中に記載されている英数字（例えば「＃０」、「＃４９」）などは、各文書オブジェクトを識別するためのオブジェクトＩＤである。
【００４７】
図４に示したツリー構造を図３に示した構造化文書の文書オブジェクトツリーと呼ぶ。
【００４８】
図１は、本実施形態に係る構造化文書管理システムの構成例を示したものである。図１において、構造化文書管理システムは、大きく分けて、要求制御部１、アクセス要求処理部２、検索要求処理部３、データアクセス部４、文書記憶部５、インデックス記憶部６から構成されている。文書記憶部５、インデックス記憶部６は例えば、外部記憶装置で構成される。
【００４９】
図１のシステム構成は、ソフトウエアを用いて実現可能である。
【００５０】
要求制御部１は、要求受付部１１と結果処理部１２から構成されている。要求受付部１１は、文書の格納、文書の取得、文書の検索などのユーザからの要求を受け付けて、アクセス要求処理部２を呼び出す。結果処理部１２は、アクセス要求処理部２が処理した結果を要求元のユーザに返す処理を行う。
【００５１】
アクセス要求処理部２は、文書の格納、文書の取得、文書の削除などのユーザからの各種要求に対応した複数の処理部から構成されている。つまり、文書格納部２１、文書取得部２２、文書削除部２３から構成されている。
【００５２】
文書格納部２１は、文書記憶部５中の指定された論理的なエリアに文書を格納する処理を行う。
【００５３】
文書取得部２２は、文書記憶部５中の論理的なエリアが指定されたときに、その指定エリアに存在する文書を取得する処理を行う。
【００５４】
文書削除部２３は、文書記憶部５中の指定された論理的なエリアに存在する文書を削除する処理を行う。
【００５５】
文書記憶部５は、構造化文書データベースであり、例えば、図８に示すように、文書をＵＮＩＸのディレクトリ構造のように階層的にツリー構造状に格納している。
【００５６】
図８に示すように、構造化文書データベースは、図４に示したような１つの構造化文書のツリー構造と同様に表現できる。すなわち、任意のノード以下の部分的な階層木（部分ツリー）は、構造化文書データベースから切り出された構造化文書であり、ここでは、これを文書オブジェクトツリーと呼ぶ。各ノードにはオブジェクトＩＤが割り当てられている。オブジェクトＩＤは、構造化文書データベース内ではユニークな数値である。
【００５７】
階層木のルートとなるノードには、それがルートノードであることを特定するためのオブジェクトＩＤ「＃０」が割り当てられるものとする。
【００５８】
ルートノード、すなわち、「＃０」のノードからは「ｒｏｏｔ」タグを先頭に持つオブジェクトＩＤ「＃１」のノードへリンクが張られている。「＃１」のノードからは、「特許ＤＢ」タグを先頭にもつオブジェクトＩＤ「＃２」のノードへのリンクが張られている。「＃２」ノードからは、「特許」タグを先頭に持つ、オブジェクトＩＤ「＃４２」のノード、「＃５２」のノード、「＃６２」のノードへのリンクがそれぞれ張られている。
【００５９】
図３に示した「特許」情報は、図８の「＃４２」ノード以下の部分ツリーに対応している。このノードからは「タイトル」タグ、「出願者」タグ、「要約」タグなどを先頭にもつノードへリンクが張られ、末端のノードからは、「ＸＭＬデータベース」、「Ｔ社」、「ＸＭＬを統一的に管理するデータベースを提供する…」などの文字列（要素値）へのリンクが張られている。
【００６０】
図８において、オブジェクトＩＤ「＃５２」のノード以下の部分ツリー、オブジェクトＩＤ「＃６２」のノード以下の部分ノードも１つの「特許」情報に対応する文書オブジェクトツリーである。
【００６１】
ところで、例えば、「＃４３」ノードにリンクされた「ＸＭＬデータベース」という要素値は、「＃４３」ノードと「＃ｖａｌｕｅ」という特殊なタグ名で接続されている。このタグ名は、「＃」で始まるためＸＭＬの規格においては標準的なタグ名として利用することはできない。
【００６２】
このような構造化文書データベースの特定ノードを指定するために構造化文書パスを用いる。構造化文書パスは「ｕｉｘ：／／ｒｏｏｔ」から始まる文字列である。ｕｉｘ（Ｕｎｉｖｅｒｓａｌ　Ｉｄｅｎｔｉｆｉｅｒ　ｆｏｒ　ＸＭＬ）は構造化文書パスであることを示す文字列である。
【００６３】
例えば、構造化文書パスとして「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」と表すと、この構造化文書パスの示す文書記憶部５中の論理的なエリアは、図８において、「＃１」ノードから「特許ＤＢ」が付与されたアークが指し示すノード、つまり「＃２」ノードである。
【００６４】
同様にして、構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許」は、図８における「＃４２」ノードを指し示し、構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／出願日／年」は、図８における「＃４５」ノードを指し示す。
【００６５】
例えば、図８において、「＃２」ノード以下に、すなわち、「特許ＤＢ」という構成要素に、複数の「特許」情報を格納する場合には、各「特許」情報を識別するために、要素名（例えば、この場合「特許」）にインデックスを追加してもよい。
【００６６】
「特許ＤＢ」の最初の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」となるが、これは「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許」と同じとみなす。「特許ＤＢ」の２番目の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［１］」、「特許ＤＢ」の５番目の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［４］」となる。
【００６７】
インデックス記憶部６には，検索時に用いる、要素名称生起インデックスとデータ生起インデックスが記憶されている。
【００６８】
要素名生起インデックスとは構造化文書データベースに格納されている要素名と、その要素名の構成要素が先頭にある構造化文書（文書オブジェクトツリー）の位置とを関連付けたインデックスファイルである。例えば、図８の構造化文書データベースでは、（「特許」情報に対応する）「特許」という要素名が「＃４２」ノード以下の構造化文書、「＃５２」ノード以下の構造化文書、「＃６２」ノード以下の構造化文書に存在する場合、要素名生起インデックスには、図９に示すように、「＃４２」ノード、「＃５２」ノード、「＃６２」ノードの親ノード、すなわち、「＃２」ノードが、要素名「特許」にリンクされて格納される。
【００６９】
このように、親ノードでインデックス化すると、インデックスファイルを圧縮することができる。すなわち、親ノードでインデックス化すれば、子ノードが増大しようとも、親ノードで代用しているので、要素名にリンクすべきノードは増大しない。
【００７０】
データ生起インデックスとは、構造化文書データベースに格納されている文字列データと、その文字列データが存在する構造化文書（文書オブジェクトツリー）の位置とを関連付けたインデックスファイルである。例えば、図８の構造化文書データベースでは、「ＸＭＬ」という文字列が「＃４３」ノード以下の構造化文書、「＃４９」ノード以下の構造化文書に存在する。この場合、データ生起インデックスには、図１０に示すように、「＃４３」ノード、「＃４９」ノードが、「ＸＭＬ」という文字列にリンクされて格納される。
【００７１】
文書記憶部５中の指定された論理的なエリアとは、構造化文書パスを用いてユーザにより指定された文書の格納場所である。構造化文書パスは、ユーザにとって認識可能な表現である。
【００７２】
図１の説明に戻る。
【００７３】
データアクセス部４は、文書記憶部５をアクセスするための各種処理を行うものである。データアクセス部４は、文書オブジェクトツリー格納部４１、文書オブジェクトツリー削除部４２、文書オブジェクトツリー取得部４３、文書文字列取得部４４、文書パーサ部４６、合成文書作成部４７、インデックス更新部４８から構成される。
【００７４】
文書オブジェクトツリー格納部４１は、文書記憶部５中の指定された物理的なエリアに文書オブジェクトツリーを格納するための処理を行う。
【００７５】
文書オブジェクトツリー削除部４２は、文書記憶部５中の指定された物理的なエリアに存在する文書オブジェクトツリーを削除するための処理を行う。
【００７６】
文書オブジェクトツリー取得部４３は、文書記憶部５中の（構造化文書パスなどにより）指定された物理的なエリアに存在する文書オブジェクトツリーを取得するための処理を行う。
【００７７】
文書文字列取得部４４は、文書オブジェクトツリーを構造化文書（ＸＭＬ文書）に変換するための処理を行う。
【００７８】
文書パーサ部４６は、ユーザにより入力された構造化文書を読み込んで、その文書構造の検査を行う。さらに文書構造の定義データであるスキーマが存在すれば、入力された構造化文書の文書構造がスキーマにしたがっているかどうかの検証を行う。出力結果は文書オブジェクトツリーとなる。文書パーサは、通常、ｌｅｘ（ｌｅｘｉｃａｌ　ａｎａｌｙｚｅｒ　ｇｅｎｅｒａｔｏｒ）といったレキシカルアナライザ（字句解析を行い，トークンに分解する）とｙａｃｃ（ｙｅｔａｎｏｔｈｅｒ　ｃｏｍｐｉｌｅｒ　ｃｏｍｐｉｌｅｒ）といったパーサジェネレータを組み合わせて構築することができる。
【００７９】
合成文書作成部４７は、文書の格納や文書の削除などをする際に、スキーマに合致しているかどうか検査しなければならないが、この検査時に必要となるデータを作成する。
【００８０】
インデックス更新部４８は、文書の格納や文書の削除などにより、構造化文書データベースの格納内容が更新されるたびに、図９、図１０に示した要素名称生起インデックスとデータ生起インデックスを更新する。
【００８１】
文書記憶部５中の物理的なエリアとは、ファイルオフセットやオブジェクトＩＤなどの構造化文書データベース内ではユニークな文書データの存在場所を指し示す内部データである。ユーザにとっては認識不可能なデータである。
【００８２】
検索要求処理部３は、データアクセス部４に備わっている各処理機能部を用いて、文書記憶部５中に格納された文書を検索する処理を行う。要求制御部１の要求受付部１１でユーザからの文書検索の要求が受け付けられると、検索要求処理部３には、要求受付部１１からクエリ言語で記述されたクエリ文書が入力する。そしてデータアクセス部４を通してインデックス記憶部６，文書記憶部５にアクセスし、検索要求に合致する文書の集合を取得して、その結果を結果処理部１２を介して出力する。
【００８３】
図２は、図１に示した構造化文書管理システムの一利用形態を示したもので、図２では、ＷＷＷ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂ）のバックエンドで、図１に示した構成の構造化文書管理システム１００が動作している場合を示している。
【００８４】
複数（ここでは、例えば３つ）のクライアント端末（例えばパーソナルコンピュータ、携帯通信端末など）１０２のそれぞれでＷＷＷブラウザ１０３が動作している。ユーザは、各クライアント端末からＷＷＷサーバ１０１にアクセスすることにより、構造化文書管理システム１００にアクセスすることができる。ＷＷＷブラウザ１０３とＷＷＷサーバ１０１とは、ＨＴＴＰ（Ｈｙｐｅｒ　ＴｅｘｔＴｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）で通信している。また、ＷＷＷサーバ１０１と構造化文書管理システム１００とは、ＣＧＩ（Ｃｏｍｍｏｎ　Ｇａｔｅｗａｙ　Ｉｎｔｅｒｆａｃｅ）またはＣＯＭ（Ｃｏｍｐｏｎｅｎｔ　Ｏｂｊｅｃｔ　Ｍｏｄｅｌ）などで通信している。
【００８５】
文書の格納、文書の取得、文書の検索などのユーザからの要求は、ＷＷＷブラウザ１０３から送信されて、ＷＷＷサーバ１０１を通して構造化文書管理システム１００にて受け付けられる。構造化文書管理システム１００にて処理された結果は、ＷＷＷサーバ１０１を通して要求元のＷＷＷブラウザ１０３へ返信される。
【００８６】
以下、図１の構造化文書管理システムの（１）格納機能、（２）検索機能について詳細に説明する。
【００８７】
（格納機能）
図１の構造化文書管理システムにおける格納系のコマンドには以下のものがある。
【００８８】
ｉｎｓｅｒｔＸＭＬ（パス、Ｎ番目、ＸＭＬ）：文書格納
ａｐｐｅｎｄＸＭＬ（パス、ＸＭＬ）　　　　：文書格納
ｇｅｔＸＭＬ（パス）　　　　　　　　　　　：文書取得
ｒｅｍｏｖｅＸＭＬ（パス）　　　　　　　　：文書削除
ｓｅｔＳｃｈｅｍａ（パス、スキーマ）　　　：スキーマ格納
ｇｅｔＳｃｈｅｍａ（パス）　　　：スキーマ取得
「ｉｎｓｅｒｔＸＭＬ」は、（　）内に指定した構造化文書パス以下のＮ番目に文書を挿入するコマンド（以下、簡単に挿入コマンドと呼ぶ）である。
【００８９】
「ａｐｐｅｎｄＸＭＬ」は、（　）内に指定した構造化文書パス以下の最後に文書を挿入するコマンド（以下、簡単に追加コマンドと呼ぶ）である。
【００９０】
「ｇｅｔＸＭＬ」は、（　）内に指定した構造化文書パス以下の文書を取り出すコマンド（以下、簡単に取得コマンドと呼ぶ）である。
【００９１】
「ｒｅｍｏｖｅＸＭＬ」は、（　）内に指定した構造化文書パス以下の文書（スキーマ文書以外の文書で、主に、コンテンツ文書）を削除するコマンド（以下、簡単に削除コマンドと呼ぶ）である。
【００９２】
「ｓｅｔＳｃｈｅｍａ」は、（　）内に指定した構造化文書パスにスキーマを設定するコマンド（以下、簡単にスキーマ格納コマンドと呼ぶ）である。
【００９３】
「ｇｅｔＳｃｈｅｍａ」は、（　）内に指定した構造化文書パスに設定されているスキーマを取り出すコマンド（以下、簡単にスキーマ取得コマンドと呼ぶ）である。
【００９４】
上記コマンドのうち、挿入コマンド、追加コマンド、スキーマ格納コマンドについての処理はアクセス要求処理部２の文書格納部２１で実行され、取得コマンド、スキーマ取得コマンドについての処理は文書取得部２２で実行され、削除コマンドについての処理は文書削除部２３で実行される。
【００９５】
図５を参照して、構造化文書データベースの初期状態（図５（ａ）参照）において、追加コマンドを実行する場合について説明する。
【００９６】
図５（ａ）に示すように、「＃０」ノードと「＃１」ノードが「ｒｏｏｔ」アークで接続されている初期状態に対して、
「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」を実行した結果、図５（ｂ）に示すように、「＃２」ノードと「特許ＤＢ」アークが作成される。
【００９７】
図５（ｂ）に示した状態の構造化文書データベースに対して、取得コマンドを実行する場合について説明する。
【００９８】
例えば、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”）」を実行すると、図５（ｂ）の「ｒｏｏｔ」アークが示す「＃０」ノード以下の文書オブジェクトツリーが取り出され、それをＸＭＬ文書に変換する。その結果、「＜ｒｏｏｔ＞＜特許ＤＢ／＞＜／ｒｏｏｔ＞」なる文字列が取り出されて、図６に示すようなＸＭＬ文書に変換される。取得コマンドの処理は、アクセス要求処理部２の文書取得部２２にて実行される。
【００９９】
次に、図５（ｂ）に示した状態の構造化文書データベースに対して、図３に示すようなコンテンツ文書（ＸＭＬ文書）としての「特許」情報を格納するための追加コマンドを実行する場合について説明する。すなわち、この場合、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」を実行する。このコマンド中「“＜特許＞…＜／特許＞”」が、図３に示した「特許」情報のＸＭＬ文書に対応する。
【０１００】
上記追加コマンドの処理が実行されると、図７に示すように、「＃２」ノード以下に「＃４２」ノードをトップとする文書オブジェクトツリー（図４に対応）が追加される。
【０１０１】
図５（ｂ）に示した状態の構造化文書データベースに対して、次に示すような追加コマンドを３回繰り返して実行したとする。
【０１０２】
「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」
上記コマンド中、「＜特許＞…＜／特許＞」は、図３に示したＸＭＬ文書と同じ文書構造のコンテンツ文書に対応する。
【０１０３】
すると、図８に示すように、「＃２」ノード以下に「＃４２」ノード、「＃５２」ノード、「＃６２」ノードをトップとする文書オブジェクトツリーが追加される。
【０１０４】
次に、図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合について説明する。この場合、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」を実行する。すると、「特許ＤＢ」アークが示す「＃２」ノード以下の文書オブジェクトツリーが取り出される。その結果、図１１に示すように、「＜特許ＤＢ＞＜特許＞…＜／特許＞＜特許＞…＜／特許＞＜特許＞…＜／特許＞＜／特許ＤＢ＞」なるＸＭＬ文書が取得できる。
【０１０５】
構造化文書データベースでは、上記の「特許」情報などのコンテンツ文書（ＸＭＬ文書）の文書構造を定義したデータ、すなわち、スキーマも管理対象とする。
【０１０６】
図１２は、ＸＭＬ文書の文書構造を定義するスキーマの一例を示したものである。ここでは、ＸＭＬの文書構造定義言語の一つであるＸＤＲ（ＸＭＬ−Ｄａｔａ　Ｒｅｄｕｃｅｄ）を取り上げる。もちろん、ＸＭＬ−Ｓｃｈｅｍａなど他の文書構造定義言語を用いてもかまわない。
【０１０７】
図１２に示したスキーマは、図３に示した「特許」情報の文書構造をＸＤＲで定義したものである。図１２からも容易に分かるとおり、スキーマもＸＭＬ形式の構造化文書である。「Ｓｃｈｅｍａ」タグから始まる構成要素から始まり、その子要素として、「ＥｌｅｍｅｎｔＴｙｐｅ」タグから始まる要素集合が存在する。
【０１０８】
図８に示した状態の構造化文書データベースに対して、図１２に示したスキーマ文書を格納するためのスキーマ格納コマンドを実行する場合について説明する。この場合、「ｓｅｔＳｃｈｅｍａ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”）」を実行する。このコマンド中、「“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”」」が図１２に示したスキーマ文書に対応する。
【０１０９】
上記コマンドの実行により、図１３に示すように、「＃２」ノード以下に「＃ｓｃｈｅｍａ」アークが追加され、その先には、「＃３」ノードをトップノードとする文書オブジェクトツリーが追加される。スキーマ自身がＸＭＬ文書表現になっているため、前述した「特許」情報のようなコンテンツ文書格納のケースと同様に、図１３に示したように、ツリー展開される。
【０１１０】
図１３において、「＠ｎａｍｅ」のように、「＠」で始まるアークは属性に対応する。タグ名「＃ｓｃｈｅｍａ」も「＃」、「＠」で始まるためＸＭＬ規格においては標準的なタグ名として利用することはできない。
【０１１１】
「＃２」ノード以下に図１２に示したスキーマ文書が格納されたことにより、以後、「＃２」ノード以下に格納される文書の文書構造は、図１２に示したスキーマ文書により定義された文書構造に適合することを要求してもよい。すなわち、この場合、「＃２」ノード以下に図１２に示したスキーマが設定されることになる。
【０１１２】
「＃２」ノード以下に図１２に示したスキーマが設定されると、例えば、図１４に示すように、「＃２」ノード以下の文書オブジェクトツリーの各ノード（のファイル）には、スキーマが存在する旨の属性値がセットされる。
【０１１３】
「＃２」ノード以下に図１２に示したスキーマが設定された後に、このスキーマで定義された文書構造に一致する図３に示したような「特許」情報の文書を、図１４に示したように、文書オブジェクトツリーとして構造化文書データベースに格納したとき、この文書の文書構造には図１２に示したスキーマが存在する旨の属性値が、当該文書オブジェクトツリーを構成する各文書オブジェクトにセットされる。例えば、当該文書オブジェクトツリーを構成する各文書オブジェクトのファイルに対して、スキーマが存在している旨の属性値（例えば、「スキーマ適合有無」）に「１」がセットされる。図１４では、スキーマに適合している各文書オブジェクト（ノード）は２重丸で示している。２重丸で示した各文書オブジェクトには、その文書オブジェクトに対応した文書構造定義が存在することになる。
【０１１４】
図１５は、各文書オブジェクトのファイルの内容を概念的に示したもので、例えば、オブジェクトＩＤが「＃４２」の文書オブジェクトのファイルには、その文書オブジェクトにリンクされている他の文書オブジェクトに関する情報（例えば、アークや、リンク先の文書オブジェクトへのポインタ値など）とともに、上記属性値が記述されている。なお、当該文書オブジェクトに適用するスキーマが存在しないときは、「スキーマ適合有無」の値は「０」となる。
【０１１５】
図１６、図１７は、図１の構造化文書管理システムで、必要に応じて検索条件として用いるキーワードなどとして使用される語をその意味内容から階層的に分類した結果である概念階層を構造化文書で表現した例を示す。図１６、図１７に示す「概念」情報はＸＭＬで記述したコンテンツ文書である。
【０１１６】
図１６に示した「概念」情報の例は、いわゆる特許調査における特許文書の内容を分類するための１つの分類軸として用いる「情報モデル」を概念階層で表現している。「概念」タグで囲まれた「概念」情報は、入れ子構造を持った文書構造をもっている。つまり、図１６の例では、概念「情報モデル」の子供概念として、概念「ドキュメント」、概念「リレーション」、概念「オブジェクト」が存在している。また、概念「ドキュメント」の子供概念として、概念「構造化ドキュメント」、概念「非構造化ドキュメント」が存在する。さらに、概念「構造化ドキュメント」の子供概念として、概念「ＸＭＬ」、概念「ＳＧＭＬ」が存在している。
【０１１７】
図１７に示す「概念」情報の記述例は、図１６とは異なる分類軸「情報操作」を概念階層で表現している。図１７の例では、概念「情報操作」の子供概念として、概念「検索」、概念「格納」、概念「加工」、概念「流通」が存在している。
【０１１８】
図１６，図１７に示したような「概念」情報も、前述の「特許」情報と同様にして、構造化文書データベース内に格納することができる。すなわち、例えば、まず、図８に示した状態の構造化文書データベースに対して、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜概念ＤＢ／＞”）」を実行して、図１８に示すように、「＃２０１」ノードと「概念ＤＢ」アークが作成される。この状態において、図１６に示した「概念」情報を格納する場合には、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／概念ＤＢ”，“＜概念名前＞…＜／概念＞”）」を実行する。このコマンド中「“＜概念名前＞…＜／概念＞”」が、図１６に示した「概念」情報に対応する。
【０１１９】
上記追加コマンドの処理が実行されると、図１９に示すように、「＃２０１」ノード以下に「＃２０２」ノードをトップとする文書オブジェクトツリーが追加される。
【０１２０】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。そのため、部分的なＸＭＬ文書をアクセスするには巨大なＸＭＬ文書に対するパスという、文書構造に依存しない統一的なアクセス手段を用いることにより、幅広くＸＭＬ文書を検索したり加工したりすることが可能になる。
【０１２１】
また、構造化文書データベース上の一部にスキーマを設定することで、格納しようとする文書の文書構造がそのスキーマにより定義されている文書構造に一致するか否かの妥当性のチェックを自動的に行うようにしてもよい。
【０１２２】
（検索機能）
図１の構造化文書管理システムにおける検索系のコマンドには以下のものがある。
【０１２３】
ｑｕｅｒｙ（ｑｌ）
「ｑｕｅｒｙ」は、パラメータとして（　）内のクエリｑｌを実行し、その結果のＸＭＬ文書を取得するコマンド（以下、検索コマンドと呼ぶ）である。
【０１２４】
クエリは、例えば、図２０に示すように、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ　Ｑｕｅｒｙ　Ｌａｎｇｕａｇｅ）に似た形式の言語により、検索位置、検索条件、情報抽出部分などを記述した、文書構造をもつＸＭＬ文書である。クエリ文書も構造化文書管理システムの管理対象である。
【０１２５】
「ｋｆ：ｆｒｏｍ」タグから始まる要素には、検索位置の指定と文書要素の値に変数を対応付ける記述があり、「ｋｆ：ｗｈｅｒｅ」タグのから始める要素には、変数に関する条件づけの記述があり、「ｋｆ：ｓｅｌｅｃｔ」タグから始まる要素には、検索結果の出力形式が記述される。
【０１２６】
検索には、単純検索と概念検索とがある。単純検索とは、クエリ中に指定された検索条件を満たす情報を検索・抽出するものであり、概念検索とは、クエリ中に指定された概念情報を利用して、クエリ中に指定された検索条件を満たす情報を検索・抽出するものである。
【０１２７】
図２１は、単純検索のクエリの例を示したものである。図２１のクエリは、例えば、図１４に示したような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群において、「１９９９年でかつ、「ＰＣ」のような内容の「要約」という要素をもつ文書（「特許」情報）の「タイトル」を列挙せよ」という検索要求の記述例を示している。
【０１２８】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」、「＄ｙ」、「＄ｓ」に、それぞれ「特許」情報の「タイトル」、「年」、「要約」という文書要素の値が代入される。
【０１２９】
「ｋｆ：ｗｈｅｒｅ」タグから始める要素の記述により、変数「＄ｙ」＝「１９９９」という比較がなされる。また、コンポーネント「ＭｙＬｉｋｅ」は変数「＄ｓ」と「ＰＣ」を引数として、「ＰＣ」と類似する値の変数「＄ｓ」を検知するための関数である。
【０１３０】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」が出力値として利用される。
【０１３１】
なお、「ｋｆ：ｓｔａｒ」タグは構造の曖昧表現であり、例えば「＜特許＞＜ｋｆ：ｓｔａｒ＞＜年＞」は「タグ名が「特許」である要素の子孫の要素としていずれかに存在し、タグ名が「年」である要素」を意味する。
【０１３２】
図２２に図２１の単純検索のクエリを用いた検索結果を示す。この検索結果もＸＭＬ文書である。
【０１３３】
図２３は、概念検索のクエリの例を示したものである。図２３のクエリは、例えば図１８，図１９に示すような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群に対し、「概念ＤＢ」アークが示すノード以下に格納されている「概念」情報を利用して検索するための検索要求の記述例を示している。ここで、概念「周辺装置」の値をもつタグの子要素の値には、概念「ＳＣＳＩ」、「メモリ」、「ＨＤＤ」などがあるものとする。また、図１８には示していないが、各「特許」情報の構成要素には、「キーワード」タグから始める要素も存在するものとする。
【０１３４】
すなわち、図２３のクエリは、「概念「周辺装置」以下の概念のいずれかを「キーワード」という構成要素の要素値としてもつ「特許」情報の「タイトル」を列挙せよ」という検索要求の記述例を示している。
【０１３５】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」、変数「＄ｋ」に、それぞれ、「特許」情報の「タイトル」、「キーワード」という要素の値が代入される。また、変数「＄ｘ」は「概念」情報として「周辺装置」の値をもつタグの子要素の値（「ＳＣＳＩ」、「メモリ」、「ＨＤＤ」など）が代入される。
【０１３６】
「ｋｆ：ｗｈｅｒｅ」タグから始める要素の記述により、「＄ｋ」＝「周辺装置」もしくは「＄ｋ」＝「＄ｘ」という比較がなされる。
【０１３７】
次に、図１の構造化文書管理システムの文書検索処理動作について、図２４に示すフローチャートを参照して説明する。
【０１３８】
クライアント端末の所定の表示装置には、構造化文書管理システム１００（の例えば、要求制御部１）から提供された、例えば、図２５に示すようなユーザインターフェイスとしての画面が表示されている。
【０１３９】
図２５に示した画面上で、ユーザが「ＸＭＬ検索Ｗｉｎ」をマウス等のポインティングデバイスなどを用いて選択すると、図２６に示すような文書検索を行うためのユーザインタフェースとしての画面が表示される。
【０１４０】
図２６の検索画面において、領域Ｗ１には、構造化文書データベースの現在のツリー構造の構成要素の要素名（タグ名）がユーザが理解可能なように簡略的に表示されている。なお、図２６では、上位階層の要素名のみを表示しているが、末端の要素名まで表示可能である。
【０１４１】
領域Ｗ１１は、検索対象の範囲（ツリー構造上の検索範囲）や、検索条件などを入力するための領域である。領域Ｗ１２には、検索結果が表示される。
【０１４２】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグをもつ構成要素の要素値に「文書」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という検索要求の場合には、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、領域Ｗ１１には、まず、トップノードとして、「特許」を入力する（この場合、領域Ｗ１から「特許」をマウス等で選択することにより入力してもよい）。また、検索条件としての、「「タイトル」という構成要素の要素値に「文書」という文字列を含む」「「年」という構成要素の要素値が「１９９８」以上である」という内容は、予め設けられたデータ入力領域に入力すればよい。
【０１４３】
その後、「検索」ボタンＢ２１を選択することにより、例えば、図２７に示すようなクエリが、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。なお、クエリの格納場所は、予め定められており、システム側が自動的に、この追加コマンドのパラメータを設定することとなる。例えば、構造化文書データベースが図１８に示した状態のとき、当該クエリの格納場所を表すパラメータとしての構造化文書パスは、「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」となる。また、追加コマンドのもう一方のパラメータは、当該クエリ文書である。
【０１４４】
要求受付部１１は、上記クエリを受け付けると（ステップＳ１００）、当該クエリを検索要求処理部３へ渡す。そして、当該クエリ文書を格納するための追加コマンドのパラメータを文書格納部２１へ渡す。文書格納部２１では、追加コマンドの処理を行って、当該クエリは、文書記憶部５に格納される（ステップＳ１０１）。
【０１４５】
一方、検索要求処理部３では、受け取ったクエリを基に、データアクセス部４を通してインデックス記憶部６，文書記憶部５にアクセスし、検索要求に合致する文書集合などを取得して、クエリの中で要求された情報を抽出して結果処理部１２を介して出力する。
【０１４６】
例えば、上記クエリの場合、まず、「「タイトル」タグをもつ構成要素の要素値に「文書」という文字列を含む」という条件に合致するものを検索することが検索対象を絞り込む上で効率がよい。そこで、図１０に示したようなデータ生起インデックスを用いて、「文書」という文字列にリンクされているノード（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを上流側に１つ遡り、「タイトル」というタグ名にたどり着いたときは、更に上流に辿っていき、「特許」というタグ名にたどり着いたときは、そのノード以下の文書オブジェクトツリーＯｔ１１を抽出する。
【０１４７】
次に、この抽出された複数の文書オブジェクトツリーＯｔ１１の中から、さらに、「年」という構成要素の要素値が「１９９８」年以上の文書オブジェクトツリーＯｔ１２を抽出する。
【０１４８】
この文書オブジェクトツリーＯｔ１２が上記クエリの内容に適合する文書となる。さらに上記クエリの要求内容に従えば、各文書オブジェクトツリーＯｔ１２のトップノードへの構造化文書パスを求める（ステップＳ１０２）。
【０１４９】
なお、上記検索処理は、上記した方法に限るものではなく、インデックス情報を用いた様々な効率のよい検索方法が可能である。
【０１５０】
検索要求処理部３は、ステップＳ１０２で得られた結果を統合して、検索結果としてのＸＭＬ文書を作成する（ステップＳ１０３）。
【０１５１】
例えば、検索結果のＸＭＬ文書は、
＜ｏｕｔ＞
＜ｒｅｓｕｌｔ＞
ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］
＜／ｒｅｓｕｌｔ＞
＜ｒｅｓｕｌｔ＞
ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［２］
＜／ｒｅｓｕｌｔ＞
＜／ｏｕｔ＞
となる。
【０１５２】
検索要求処理部３は、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す（ステップＳ１０４）。
【０１５３】
クライアント端末では、図１１に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図２６に示すように、領域Ｗ１２に表示する。ここでは、例えば検索結果として得られた構造化文書の数が多いために、検索された構造化文書の構造化文書パスが検索結果として表示されている。この場合、例えば、図２６の領域Ｗ１２に表示された検索結果の構造化文書パスのうち、所望の１つがユーザにより選択されたとする。例えば、図２６の領域Ｗ１２に表示された構造化文書パスのうち、最初のものが選択されたとする。この場合、クライアント端末から構造化文書管理システムに対し、当該選択された構造化文書パスにより特定される構造化文書を取得するために文書取得要求として、取得コマンドを送信するようにしてもよい。
【０１５４】
取得コマンドが構造化文書管理システムの要求受付部１１にて受け付けられたときの、図１の構造化文書管理システムの文書取得処理動作について、図２８に示すフローチャートを参照して説明する。
【０１５５】
例えば、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］”）」なる取得コマンドが構造化文書管理システムへ送信される。
【０１５６】
ここでは、例えば、構造化文書データベースが、図８に示した状態のときに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］”）」なる取得コマンドを受け付けた場合を例にとり説明する。
【０１５７】
要求受付部１１は、上記取得コマンドを受け付けると、上記取得コマンド中のパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」を文書取得部２２へ渡す（ステップＳ３１）。
【０１５８】
文書取得部２２は、文書オブジェクトツリー取得部４３へ構造化文書パスを渡す。文書オブジェクトツリー取得部４３は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ５）を取り出す（ステップＳ３２）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ５のオブジェクトＩＤを取得することができるので（ステップＳ３３）、その場合は、ステップＳ３５へ進む。
【０１５９】
例えば、上記取得コマンドの場合、「＃４２」ノードが文書オブジェクトＯｘ５となるので、そのオブジェクトＩＤとして、「＃４２」を取得するとともに、この「＃４２」ノード以下の文書オブジェクトツリーＯｔ５（「＃４２」ノード〜「＃４９」ノード）を取得する（ステップＳ３５）。
【０１６０】
ステップＳ３２において、指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ５が見つからなければ、エラーとなり（ステップＳ３３）、文書取得部２２，結果処理部１２を介して、クライアント端末に「文書取得失敗」の旨のメッセージを返す（ステップＳ３４）。
【０１６１】
ステップＳ３５で取得した文書オブジェクトツリーＯｔ５は、文書文字列取得部４４でＸＭＬ文書に変換される。例えば、上記取得コマンドの場合、取得したＸＭＬ文書は、図３に示すような「特許」情報のＸＭＬ文書となる。
【０１６２】
文書取得部２２は、結果処理部１２を介して、図３に示したようなＸＭＬ文書を（例えば、ＸＳＬ（ｅＸｔｅｎｓｉｂｌｅ　Ｓｔｙｌｅ　Ｌａｎｇｕａｇｅ）といった所定のスタイルシートとともに）、クライアント端末へ返す（ステップＳ３７）。
【０１６３】
クライアント端末では、図３に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図２９に示すように、領域Ｗ１３に表示する。
【０１６４】
ＸＳＬを利用すると、ＸＭＬ文書を様々な形に変換することが出来る。違う構文書造のＸＭＬ文書に変換することも出来るし、ＸＭＬ文書からＨＴＭＬページを生成することも出来る。
【０１６５】
同様にして、スキーマの検索も行える。
【０１６６】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「ｓｃｈｅｍａ」を先頭タグに持つ文書の中から、「特許」と「要約」というタグ名を持つスキーマを検索せよ」という検索要求の場合には、図３０に示すように、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、トップノードとして、「＃ｓｃｈｅｍａ」を入力する。また、検索条件として、「構成要素の属性名に「特許」という文字列を含む」「構成要素の属性名に「要約」という文字列を含む」という内容を予め設けられたデータ入力領域に入力すればよい。
【０１６７】
その後、「検索」ボタンＢ２１を選択することにより、上記検索要求を記述した、例えば、図３１に示したようなクエリが、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。
【０１６８】
さて、上記クエリの場合、例えば、「「＃ｓｃｈｅｍａ」を先頭タグに持つ」という条件に合致するものを検索する。そこで、図９に示したような要素名称生起インデックスを用いて、「＃ｓｃｈｅｍａ」という要素にリンクされているノードの（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、属性名が「特許」と「要約」いう要素にたどり着いたときは、当該「＃ｓｃｈｅｍａ」を先頭タグにもつ文書オブジェクトツリーＯｔ２１を抽出する。この文書オブジェクトツリーＯｔ２１が上記クエリの内容に適合する文書となる。さらに、図３１に示したクエリの要求内容に従えば、各文書オブジェクトツリーＯｔ２１のトップノードへの構造化文書パスを求める。
【０１６９】
検索要求処理部３は、文書オブジェクトツリーＯｔ２１が複数あれば、それぞれのトップノードへの構造化文書パスをまとめて、検索結果としてのＸＭＬ文書を作成し、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す。
【０１７０】
クライアント端末では、検索結果として受け取ったＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図２６に示すように、領域Ｗ１２に表示する。
【０１７１】
クライアント端末では、検索結果の中の１つのスキーマを選択して、表示させると、例えば、図３２に示すような文書の格納／削除を行うための画面とともに、その領域Ｗ３に、「特許」情報のデータ入力領域が各要素毎に設定されて表示される。
【０１７２】
ユーザは、このデータ入力領域にデータを入力することで、スキーマにより定義された文書構造の格納文書が容易に作成することができる。
【０１７３】
例えば、図３２の領域Ｗ３に入力した「特許」情報の格納先として、領域Ｗ１で「特許ＤＢ」をマウス等を用いて選択すると、領域Ｗ２に構造化文書パスとして、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される。その後、「登録」ボタンＢ１を選択すると、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０１７４】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。従って、文書構造が異なる、様々なスキーマを持つ膨大な数の文書の中から検索条件に合致する文書を容易に検索できる。
【０１７５】
また、検索に用いるクエリも構造化文書であるので、構造化文書データベースにログとして格納することにより、過去のクエリを再利用するようなアプリケーションも容易に構築することができる。
【０１７６】
（文書構造検索）
以下、前述の構造化文書管理システムの基本的な構成および処理動作の説明にさらに追加するかたちで、本発明の実施形態に係る、文書構造（スキーマ）検索のための構成と処理動作について説明する。
【０１７７】
図１に示すように、構造化文書管理システム１００は、スキーマ検索を行うために、スキーマ検索処理部３０３と、データアクセス部４の中にテンプレート処理部３０６を具備し、さらに、テンプレート記憶部４０４と意味ネットワーク記憶部４０５とを具備している。
【０１７８】
テンプレート処理部３０６では、構造化文書データベース（以下、ＸＭＬデータベースとも呼ぶ）の階層化された論理構造を管理するために、当該論理構造を表現したテンプレートツリーを作成する。このテンプレートツリーは、新たなＸＭＬ文書を格納する度に更新される。
【０１７９】
ここで作成されるテンプレートツリーは、テンプレート記憶部４０４に格納されている。
【０１８０】
クライアント端末１０２はスキーマ検索要求文（クエリ）を構造化文書管理システム１００へ送信する。このスキーマ検索要求文は、構造化文書管理システム１００の要求受付部１１で受け取られ、ここから当該スキーマ検索要求文はスキーマ検索処理部３０３へ渡される。
【０１８１】
スキーマ検索処理部３０３は、スキーマ検索要求文を基に、意味ネットワーク記憶部４０５に記憶されている意味ネットワークやテンプレート記憶部４０４に記憶されているテンプレートを参照しながらスキーマ検索するためのものである。
【０１８２】
（１）テンプレートツリーの更新
まず、テンプレート処理部３０６における、文書格納時におけるテンプレートツリーの更新処理動作について説明する。
【０１８３】
前述したように、文書格納部２１は、追加コマンドを実行して、登録対象のＸＭＬ文書を文書記憶部５に登録する際、テンプレート処理部３０６に、登録対象のＸＭＬ文書の格納先のデータベース上の構造化文書パスと、当該登録対象のＸＭＬ文書の文書構造の情報を通知する。
【０１８４】
図３３は、テンプレート処理部３０６の構成例を示したものである。
【０１８５】
テンプレート処理部３０６は、まず、当該登録対象のＸＭＬ文書の文書構造の情報から、構造抽出部３０６ａにおいて、構成要素の要素名や属性名などの当該ＸＭＬ文書の構造情報を抽出する。それと構造化文書パスとを基に、テンプレートツリー処理部３０６ｂは、テンプレート記憶部４０４に記憶されている、ＸＭＬデータベース中の論理構造を表したテンプレートツリーを更新する。
【０１８６】
テンプレートツリーは、ＸＭＬデータベースに格納されているＸＭＬ文書の文書構造を抽出して、ＸＭＬデータベースの階層構造に従ってツリー化したもので、各ノード（各構成要素）にはテンプレートＩＤが割り当てられて記憶される。前述したように、文書格納部２１には、登録対象のＸＭＬ文書が、その各構成要素に対して、これらオブジェクトＩＤが付加されて格納されているが、さらに、テンプレートＩＤも付加されて格納されている。登録対象のＸＭＬ文書の文書構造を構成する全ての構成要素の要素名や、属性名などは、このテンプレートＩＤが割り当てられて、テンプレートツリー上に記憶される。
【０１８７】
例えば、更新前には、図３４に示すようなテンプレートツリーがテンプレート記憶部４０４に記憶されている場合を考える。この場合、ＸＭＬデータベースの状態も図３４と同様である。このとき、ＸＭＬデータベースに、図３５（ａ）に示すようなＸＭＬ文書６０１を、「／文献ＤＢ／特許ＤＢ」以下に登録し、図３５（ｂ）に示すようなＸＭＬ文書６０２を「／人事ＤＢ／従業員ＤＢ」以下に登録する場合を考える。ここで、「／文献ＤＢ／特許ＤＢ」という表現は、ＸＭＬデータベース中の構成要素の位置を表現する際に用いた構造化文書パスと同様であり、ここでは、テンプレートツリー上の構成要素の位置を表現するためにも用いられる。
【０１８８】
テンプレートツリーは、少なくとも、ＸＭＬデータベースに格納されているＸＭＬ文書のそれぞれの文書構造とＸＭＬデータベースの階層構造上の格納位置とを含む論理構造を記憶するものである。
【０１８９】
なお、ここで、各構成要素の要素名や属性名に与えられるテンプレートＩＤは、図３４〜図３５における各構成要素の要素名（タグ名）や属性名に対し振られている符号ＴＩＤ１〜ＴＩＤ１３と同一であるとする。
【０１９０】
この場合、全ての要素がテンプレートツリー上のノードとして新規要素であるので、図３６に示すように、テンプレートツリーが更新される。
【０１９１】
また、文書構造が全く同一、あるいは文書構造の一部が同一の複数のＸＭＬ文書が、同じ構造化文書パスで表される格納位置に格納される場合、テンプレートツリー（論理構造）上では、２つ以上のＸＭＬ文書で共通する構成要素は１つに集約して、１つの構成要素として表す。この場合、テンプレートツリー上の構成要素のテンプレートＩＤと、ＸＭＬデータベース上の各構成要素のオブジェクトＩＤとの対応関係を管理する必要がある。そのために、例えば、テンプレートツリー上で、各構成要素のテンプレートＩＤと、ＸＭＬ文書中の当該構成要素のオブジェクトＩＤとを記録するようにしてもよいし、テンプレートＩＤとオブジェクトＩＤとの対応関係を記録するテーブルを別途設けてもよい。
【０１９２】
なお、実際には、テンプレートツリーは、図３７に示すようなＸＭＬ文書としてテンプレート記憶部４０４に記憶されている。これをここでは、テンプレートツリー文書と呼ぶ。
【０１９３】
テンプレートツリー文書は、図３７に示すように、例えば、先頭に「ｘｓｐ：Ｎｏｄｅ」を要素名とする構成要素で階層化されたＸＭＬ文書である。このテンプレートツリー文書にも記述されているように、ＸＭＬデータベースにＸＭＬ文書を登録する際には、当該登録対象のＸＭＬ文書のルートノード（先頭の構成要素の要素名）に対しては「ｄｏｃｕｍｅｎｔ」、それ以外の各要素の要素名に対しては「ｅｌｅｍｅｎｔ」、属性を表す構成要素に対しては「ａｔｔｒｉｂｕｔｅ」を、「ｘｓｐ：Ｎｏｄｅ」のｔｙｐｅ属性の属性値として付加されている。
【０１９４】
また、フォルダ作成の場合は、「ｆｏｌｄｅｒ」，ＸＭＬデータベースのルートとしては「ｒｏｏｔＥｌｅｍｅｎｔ」をｔｙｐｅ属性として付加する。更に、登録対象のＸＭＬ文書中の構成要素のうち、毎回登録されている構成要素は、その文書構造上必須である可能性が高いので、「ｒｅｑｕｉｒｅｄ」という属性で必須であることを記録しておく（必須である場合には当該属性の属性値を「ｙｅｓ」とする）。また、同一文書上に１つ以上の要素が出現するのは、回数制限がない（ｍａｘＯｃｃｕｒｓ＝「＊」）という、簡単なスキーマ抽出を行っておく。また、型推定ステップを行い、候補の値（「ｄａｔａＴｙｐｅ」）を書いておくことも可能である。これは、候補外の値がこの要素に来た場合はスルーさせる。
【０１９５】
また、テンプレートツリー上の１つの構成要素に集約された実際の構成要素の数（オブジェクトＩＤの数）をｃｏｕｎｔ属性として記述してもよい。なお、図３７には、ｃｏｕｎｔ，ｔｙｐｅの属性のみを表している。
【０１９６】
文書格納部２１で追加コマンドを実行して、登録対象のＸＭＬ文書を登録する際には、前述したように、当該ＸＭＬ文書に対応するインデックスが作成される。
【０１９７】
（２）スキーマ検索処理の概略
クライアント端末１０２はスキーマ検索要求文を構造化文書管理システム１００へ送信する。このスキーマ検索要求文は、構造化文書管理システム１００の要求受付部１１で受け取られ、ここから当該スキーマ検索要求文（スキーマクエリ）はスキーマ検索処理部３０３へ渡される。
【０１９８】
図３８は、スキーマ検索処理部３０３の構成例を示したものである。
【０１９９】
スキーマ検索処理部３０３は、スキーマクエリ解析部３２１、スキーマクエリ条件処理部３２２、スキーマクエリ出力処理部３３３から構成される。
【０２００】
スキーマクエリ解析部３２１は、スキーマを検索するための検索条件などの記述された検索要求文、すなわちスキーマクエリを解析する。クエリの記述言語としては、例えば、ＸＱｕｅｒｙなどがある。図３９は、スキーマクエリの一具体例を示したものである。なお、スキーマ検索は、スキーマを推定したデータを擬似的に作成し、検索を行う必要があるので、スキーマクエリは、通常のＸＱｕｅｒｙなどでは表現はできない。
【０２０１】
スキーマクエリは、「ｘｓｐ：ｑｕｅｒｙ」タグをもつ構成要素で始まり、その中に、主に、「ｘｓｐ：ｒｅｔｒｕｎ」というタグをもつ構成要素で記述される部分（以下、簡単にｒｅｔｕｒｎ節とも呼ぶ）と「ｘｓｐ：ｗｈｅｒｅ」というタグの構成要素で記述される部分（以下、簡単にｗｈｅｒｅ節とも呼ぶ）が含まれている。
【０２０２】
先頭にある「ｘｓｐ：ｑｕｅｒｙ」タグが存在することで、要求受付部１１は、当該クエリがスキーマクエリであることが判断できる。
【０２０３】
「ｘｓｐ：ｒｅｔｕｒｎ」タグをもつ構成要素には、抽出すべき文書構造の先頭の構成要素の要素名もしくは属性名などに対応する文字列（キーワード）が記述されている。この「ｘｓｐ：ｒｅｔｕｒｎ」節中の要素は全て、「ｘｓｐ：ｅｌｅｍ」である。ここには複数の候補を記述しても良く、例えば、関連が近いと想定される、要素名、属性名をｎａｍｅ属性で記述する。図３９に示したスキーマクエリにおいては、「特許」と「文献」がそれぞれ記述されている。
【０２０４】
この場合、完全一致以外の曖昧な揺らぎも考慮される。「特許」のスキーマとして記述されていなくて、例えば、「Ｐａｔｅｎｔ」で定義されるようなスキーマも同様に検索するためである。
【０２０５】
この揺らぎを吸収するものとして、意味ネットワーク記憶部４０５には図４１に示すような意味ネットワークを記憶している。意味ネットワークとは、図４１に示すように、語彙の間の関係をグラフで表現したものであり、語彙間のウエイト（類似度）をアーク上に付加させている。例えば、「構造化文書」や「ＸＭＬ」の類似度は「０．８」となっている。類似度を表す数値は「０」から「１」までの値を取る。
【０２０６】
類似度計算のアルゴリズムを図４２に示す。
【０２０７】
ここでは、図４２に示すフローチャートを参照して、「ＸＭＬ」に類似する語彙を類似度を計算しながら求める場合を例にとり説明する。
【０２０８】
ここで、文字列「ＸＭＬ」という語彙に類似すると判断できる類似度の閾値を例えば「０．６」とする。まず、「ＸＭＬ」の意味ネットワーク上の位置を検索する（ステップＳ２０１）。検索位置のウェイト（類似度）を「１．０」に設定する（ステップＳ２０２）。その後、まず、現キーワードを探索候補リスト及び確定候補リストに追加する（ステップＳ２０３）。
【０２０９】
図４１に示した意味ネットワークから、「ＸＭＬ」に類似する語彙「構造化文書」、「マークアップ言語」が取り出され、それぞれ類似度は「０．８」である。この場合、展開元の語彙「ＸＭＬ」のウエイト「１．０」と、取り出された各語彙のウエイトを乗じて、それぞれ「０．８」が得られる。探索候補リストから、展開元の語彙「ＸＭＬ」を削除して、この２つの語彙を追加する（ステップＳ２０５）。
【０２１０】
この２つの語彙の類似度は、「０．８」であるので、確定候補リストにも追加する（ステップＳ２０６〜ステップＳ２０７）。
【０２１１】
次に、探索候補リスト上の「構造化文書」を展開元として、図４１に示した意味ネットワークを１段展開すると、「構造文書」の類似度は、展開元との間の類似度「０．５」と展開元のウエイト「０．８」を乗じて「０．４」が得られる。今、閾値を「０．６」に設定しているのでこれ以後の展開は行わない。以上の作業を繰り返すことにより、結果として、「ＸＭＬ」（１．０）、「マークアップ言語」（０．８）、「ＳＧＭＬ」（０．６４）、「ＨＴＭＬ」（０．６４）、「半構造化文書」（０．６４）が確定候補リスト上に残ることになる。
【０２１２】
図３９に示したスキーマクエリでは、上記類似度の閾値を表すために、当該閾値を、「ｘｓｐ：ｅｌｅｍ」の属性として記述している。すなわち、ここでは、「ｓｉｍ」という属性名を用いて、このｓｉｍ属性の属性値として記述している。この属性値により閾値を設定しておくと、ここで定めた閾値以下の類似度を持った語彙を求めるための意味ネットワーク上の展開を抑制することができる。なお、この閾値は、ユーザが例えば検索条件を入力する際に設定するようにしてもよいが、この場合に限らず、スキーマクエリ上に予め書き込まれたデフォルト値を用いてもよい。また、スキーマクエリに記述されていなくとも、スキーマ検索処理部３０３で予め定められた値を用いてもよい。
【０２１３】
スキーマを検索する際は、抽出部分すら分からない場合がある。この場合は、スキーマクエリ中に「＜ｘｓｐ：ｒｅｔｕｒｎ　ｔｙｐｅ＝“ａｌｌ”／＞」を記述しておけば、自動的にスキーマ検索処理部３０３が文書のルートノードを判別し（すなわち、前述したように、テンプレートツリー上では、１つのＸＭＬ文書の先頭の構成要素には「ｄｏｃｕｍｅｎｔ」という属性値が記述されているので、これをチェックすることによりルートノードを判別することができる）、テンプレートツリーから、当該ルートノードを先頭とする文書構造を取り出して（擬似的なスキーマを作成し）、返すことが可能となる。
【０２１４】
図３９のスキーマクエリの説明にもどり、「ｘｓｐ：ｗｈｅｒｅ」タグをもつ構成要素には、検索条件として、構成要素の要素名や属性名に含まれる文字列（キーワード）が記述されている。この節においても曖昧な状態を残したまま、検索条件が記述されている。
【０２１５】
例えば、要素名か属性名かどちらか分からない場合は、「＜ｘｓｐ：ｅｌｅｍｔｙｐｅ＝“ｅｌｅｍｅｎｔ”／＞」、要素値が属性値か分からない場合は、「＜ｘｓｐ：ｅｌｅｍ　ｔｙｐｅ＝“ｗｏｒｄ”／＞」で表現する。要素名か、属性名か、要素値か、属性値か全くわからない場合もあり、その場合は、「＜ｘｓｐ：ｅｌｅｍ　ｔｙｐｅ＝“ａｌｌ”／＞」を記述しておく。
【０２１６】
すなわち、ユーザにより、ある文字列が指定された場合、それを要素名（あるいは属性値でもよい）にもつスキーマを検索するための検索条件とするときには、「＜ｘｓｐ：ｅｌｅｍ　ｔｙｐｅ＝“ｅｌｅｍｅｎｔ”／＞」と記述し、当該文字列を要素値（あるいは属性値）にもつスキーマを検索するための検索条件とするときには、「＜ｘｓｐ：ｅｌｅｍ　ｔｙｐｅ＝“ｗｏｒｄ”／＞」と記述し、当該文字列を要素名（あるいは属性名）と要素値（あるいは属性値）のうちのいずれか一方にもつスキーマを検索するための検索条件とするときには、「＜ｘｓｐ：ｅｌｅｍ　ｔｙｐｅ＝”ａｌｌ”／＞」を記述する。
【０２１７】
スキーマを表す名前はｎａｍｅ属性で記述される。ここには、図４０に示したスキーマクエリでは、ｄａｔａＴｙｐｅ属性などで「ｉｎｔ」と、整数型という、型指定を明記した検索も行える。同様に、展開する近さに関してはｓｉｍで記述する。
【０２１８】
次に、図４３に示すフローチャートを参照して、スキーマ検索処理部３０３におけるスキーマ検索の概略的な処理の流れを説明する。
【０２１９】
スキーマ検索処理部３０３にスキーマクエリは、まず、ｗｈｅｒｅ節の処理を行い（ステップＳ３０１）、次に、ｒｅｔｕｒｎ節の処理を行った後（ステップＳ３０２）、それらの処理結果をマージし（ステップＳ３０３）、その結果に対してスキーマ推定処理を行い、すなわち、スキーマを抽出し（ステップＳ３０４）、それら抽出された各スキーマのスコアリング処理に基づくソート処理を行い（ステップＳ３０５）、最後に出力形式を整形して（ステップＳ３０６）、その結果を返す。
【０２２０】
次に、具体例を挙げて、スキーマ検索について、より詳細に説明する。
【０２２１】
（３）具体例
クライアント端末１０２には、図４４に示すようなスキーマ検索のための検索条件の入力画面が表示される。この入力画面上で、ユーザは、検索したいスキーマとして、例えば、「ＸＭＬ関連の特許で著者が記述されているようなスキーマ」という内容の自然文を入力したとする。
【０２２２】
この入力された内容は、クライアント端末１０２では、例えば、自然文解析により、図４５に示すようなスキーマクエリに変換されて、構造化文書管理システム１００へ送信される。
【０２２３】
なお、ここでは、ユーザは、スキーマ検索のために自然文を入力するとしたが、この場合に限らず、例えば、（条件１）どのような文字列を要素名（あるいは属性値）、要素値（あるいは属性値）として含むのか、（条件２）どのような種類の文書の文書構造を抽出したいのか、といった内容が含まれていれば、自然文で入力する必要はない。また、上記条件１、条件２を入力するための別個の入力領域が設けられていてもよい。また、条件１のみを入力する場合であってもよい。条件１を入力する場合、少なくとも１つの文字列が入力されていればよく、複数の文字列をカンマなどで区切りながら入力してもよい。
【０２２４】
また、条件１として指定される文字列は、構成要素の要素名である場合と、属性名である場合と、要素値である場合と、属性値である場合とがあるが、これらを別個の入力領域から入力するようにしてもよいし、１つの入力領域のみを設けて、そこに入力された文字列はこれらのうちのいずれか１つであると予め定めておいて、スキーマクエリを作成してもよい。また、条件２として入力される文字列も構成要素の要素名である場合と、属性名である場合とがあるが、これらを別個の入力領域から入力するようにしてもよいし、１つの入力領域のみを設けて、そこに入力された文字列はこれらのうちのいずれか１つであると予め定めておいて、スキーマクエリを作成してもよい。
【０２２５】
また、条件１のみであってもよいし、条件２のみであってもよい。
【０２２６】
クライアント端末１０２では、上記条件１、条件２に対応する文字列を代入すれば完成するようなスキーマクエリの雛形を複数種類（例えば、条件１と条件２が指定された場合のスキーマクエリ、条件２のみが指定された場合のスキーマクエリ、条件２に複数の文字列が指定された場合のスキーマクエリなど）記憶しておき、入力（指定）された条件に応じてこれらのうちの１つを選択し、空欄部分に条件１や条件２に対応する文字列を代入することで、スキーマクエリを作成するようにしてもよい。
【０２２７】
また、クライアント端末１０２では、ユーザにより入力された、上記条件１や条件２に対応する文字列や自然文をそのまま構造化文書管理システムへ検索要求として送信するようにしてもよい。そして、この場合には、このような検索要求を受信した構造化文書管理システムの要求受付部１１において、上記スキーマクエリを作成するようにしてもよい。要求受付部１１にてスキーマクエリを作成する場合も、前述同様である。
【０２２８】
図４４に示した入力内容の場合、条件１に対応する文字列は、「ＸＭＬ」と「著書」であり、前者は、例えば要素値に含まれる文字列であり、後者は例えば要素名あるいは属性名に含まれる文字列である。また、条件２に対応する文字列は、「特許」であり、例えば要素名に含まれる文字列であると判断され、その結果、図４５に示すようなスキーマクエリが作成される。
【０２２９】
当該スキーマクエリは、構造化文書管理システム１００の要求受付部１１を経由して、スキーマ検索処理部３０３に渡される。あるいは、要求受付部１１にて作成されて、スキーマ検索処理部３０３に渡される。
【０２３０】
まず、スキーマクエリ解析部３２１において、スキーマクエリのｗｈｅｒｅ節の解析を行う（図４３のステップＳ３０１）。この処理動作について、図５４に示すフローチャートを参照して説明する。
【０２３１】
このｗｈｅｒｅ節では、上記条件１に対応する文字列が、１つずつ「ｘｓｐ：ｅｌｅｍ」という要素名（タグ名）の構成要素の記述されている。構成要素の要素名（あるいは要素名と属性名のうちのいずれか一方）に含まれる文字列（例えば、ここでは、「著書」）を表すときは、当該文字列に対し、「ｔｙｐｅ＝“ｅｌｅｍｅｎｔ”」と指定されている。また、構成要素の要素値（あるいは要素値と属性値のうちのいずれか一方）に含まれる文字列（例えば、ここでは、「ＸＭＬ」）を表すときは、当該文字列に対し、「ｔｙｐｅ＝“ｗｏｒｄ”」と指定されている。また、構成要素の要素名（あるいは要素名と属性名のうちのいずれか一方）と、構成要素の要素値（あるいは要素値と属性値のうちのいずれか一方）のうちのいずれかに含まれる文字列を表すときは、当該文字列に対し、「ｔｙｐｅ＝“ａｌｌ”」と指定されている。
【０２３２】
まず、ｗｈｅｒｅ節内の構成要素を１つづつ取り出して（ステップＳ４０１）、各要素が、上記のいずれかであるかをチェックする（ステップＳ４０２〜ステップＳ４０４）。
【０２３３】
図４５に示したスキーマクエリの場合、１つ目の要素では、「著者」という文字列に対して「ｔｙｐｅ＝“ｅｌｅｍｅｎｔ”」と記述されているので（ステップＳ４０２）、ステップＳ４０５へ進み、例えば、ここでは、「著書」という文字列とこれに類似する語彙の文字列を要素名として持つ（要素名に一致あるいは含む）構成要素を検索する処理を行う（構造推定処理）。
【０２３４】
また、２つ目の要素では、「ＸＭＬ」という文字列に対して、「ｔｙｐｅ＝“ｗｏｒｄ”」と記述されているので（ステップＳ４０３）、ステップＳ４０６へ進み、例えば、ここでは、「ＸＭＬ」という文字列とこれに類似する語彙の文字列を要素値として持つ（要素値に一致あるいは要素値に含む）構成要素を検索する処理を行う（語彙推定処理）。
【０２３５】
また、ｗｈｅｒｅ節内の構成要素として、「ｔｙｐｅ＝“ａｌｌ”」と記述された文字列が存在する場合には（ステップＳ４０４）、ステップＳ４０５とステップＳ４０６と同様にして、当該文字列とこれに類似する文字列を要素名や要素値として持つ構成要素を検索する処理を行う（ステップＳ４０７，ステップＳ４０８）。
【０２３６】
以上ステップＳ４０１〜ステップＳ４０８の処理をｗｈｅｒｅ節内の全ての構成要素について繰り返す。
【０２３７】
ここで、処理対象の文字列を「著者」とした場合を例にとり、ステップＳ４０５、ステップＳ４０７の構造推定処理について、図５５に示すフローチャートを参照して説明する。
【０２３８】
まず、意味ネットワークを利用して「著書」の類義語を抽出する（ステップＳ４１１）。なお、ここでは、類似度の閾値が指定されていない（ｓｉｍ属性が記述されていない）ので、予め決められた閾値以下（ここでは「０．６」に設定）になるまで、ネットワークを展開する。図４１に示したの意味ネットワークの場合、「著者」（類似度は「１．０」）、「ａｕｔｈｏｒ」（類似度は「０．８」×「０．８」）、「名前」（類似度は「０．７」）という語彙が得られる。
【０２３９】
次に、前述した文書の検索の場合と同様にして、インデックス記憶部６に記憶されている要素名称生起インデックスを検索して、処理対象の文字列と上記抽出された類似語のそれぞれを要素名としてもつ構成要素のオブジェクトＩＤを取得し、さらに、例えば、前述したようなテーブルあるいはテンプレートツリー上の記述を基に、この取得した各オブジェクトＩＤのそれぞれに対応するテンプレートＩＤを取得する（ステップＳ４１２）。
【０２４０】
そして、各テンプレートＩＤに対して評価値（第１の評価値）を求める（ステップＳ４１３）。この第１の評価値は、取得したテンプレートＩＤに対応する構成要素が、検索条件として指定された文字列（語彙）にどれだけ類似するかを評価するものであれば、何でもよい。
【０２４１】
例えば、現在のＸＭＬデータベースが図４６に示すような状態であるとき、ステップＳ４１２において取得されるテンプレートＩＤは、「ＴＩＤ７」、「ＴＩＤ１５」、「ＴＩＤ５７」の３通りであり、これらの評価値は、例えば、その要素名に含まれていた語彙の類似度をそのまま用いて、例えば、「ＴＩＤ７」の評価値は「１．０」、「ＴＩＤ１５」の評価値は「０．７」、「ＴＩＤ５７」の評価値は「０．６４」とする。各テンプレートＩＤとその評価値をリストＬ１に記録しておく。このとき、この取得したテンプレートＩＤのそれぞれについて、当該テンプレートＩＤに対応するオブジェクトＩＤと、その数もリストＬ１に記録する。
【０２４２】
次に、処理対象の文字列を「ＸＭＬ」とした場合を例にとり、ステップＳ４０６，ステップＳ４０８の語彙推定処理について、図５６に示すフローチャートを参照して説明する。
【０２４３】
まず、意味ネットワークを用いて、「ＸＭＬ」の類似語を抽出する（ステップＳ４２１）。この場合、「ＸＭＬ」（類似度「１．０」）、「ＳＧＭＬ」（類似度「０．７２」）、「構造化文書」（類似度「０．８１」）が得られる（ステップＳ４２１）。
【０２４４】
次に、前述した文書の検索の場合と同様にして、インデックス記憶部６に記憶されているデータ生起インデックスを検索して、処理対象の文字列と上記抽出された類似語の各語彙のそれぞれを要素値に持つ構成要素のオブジェクトＩＤを取得し、さらに、例えば、前述したようなテーブルあるいはテンプレートツリー上の記述を基に、この取得した各オブジェクトＩＤのそれぞれに対応するテンプレートＩＤを取得する（ステップＳ４２２）。
【０２４５】
そして、各テンプレートＩＤに対して評価値（第２の評価値）を求める（ステップＳ４２３）。この第２の評価値は、取得したテンプレートＩＤに対応する構成要素が、検索条件として指定された文字列（語彙）にどれだけ類似するか、また、検索条件として指定された文字列（語彙）とその類似語とのうちのいずれかをどれだけ多く含む構成要素であるかなどを評価するものであれば、何でもよい。
【０２４６】
取得されたテンプレートＩＤのそれぞれに対応する構成要素が、上記複数の語彙のうちの一部あるいは全ての複数の語彙を要素値としてもつ場合もある。また、この取得したテンプレートＩＤに対応する構成要素のオブジェクトＩＤがデータ生起インデックスから複数個取得されている場合もある。
【０２４７】
ここでは、例えば、取得された各テンプレートＩＤについて、当該テンプレートＩＤに対応する構成要素が要素値に上記複数の語彙のうちのどの語彙を含むのかを基に上記評価値を与える。なお、各テンプレートＩＤに対応する（データ生起インデックスから取得された）オブジェクトＩＤの数と語彙の類似度を掛け合わせて求めてもよい。
【０２４８】
例えば、現在のＸＭＬデータベースが図４６に示すような状態であるとき、ステップＳ４２２では、「タイトル」という要素名を持つ構成要素（テンプレートＩＤ「ＴＩＤ６」）と、その他に「ＴＩＤ１７」、「ＴＩＤ５８」というテンプレートＩＤが得られたものとする。
【０２４９】
テンプレートＩＤ「ＴＩＤ６」の「タイトル」という構成要素は、「ＸＭＬ」という語彙（類似度は「１．０」）と「ＳＧＭＬ」という語彙（類似度は「０．７２」）とから検索されているので、例えば、これら語彙の類似度を加算して、１＋０．７２＝１．７２を評価値として与える。例えば、「ＸＭＬ」という語彙で検索されたオブジェクトＩＤの数が１００件で、「ＳＧＭＬ」という語彙で検索されたオブジェクトＩＤの数が５０件であれば、１×１００＋０．７２×５０＝１３６を評価値としてもよい。以下の説明では、評価値の算出は、説明の簡単のため、前者の例をとることにする。
【０２５０】
テンプレートＩＤ「ＴＩＤ１７」の構成要素は、「ＸＭＬ」という語彙のみから検索されているので、この語彙の類似度「１．０」を評価値として与える。
【０２５１】
テンプレートＩＤ「ＴＩＤ５８」の構成要素は、「ＸＭＬ」という語彙のみから検索されているので、この語彙の類似度「１．０」を評価値として与える。
【０２５２】
各テンプレートＩＤとその評価値（第２の評価値）をリストＬ２に記録しておく。このとき、この取得したテンプレートＩＤのそれぞれについて、当該テンプレートＩＤに対応するオブジェクトＩＤと、その数もリストＬ２に記録する。
【０２５３】
以上のｗｈｅｒｅ節の処理から、以下のようなテンプレートＩＤが得られたことになる。なお、括弧内には、「Ｄ」から始まる数字で第２の評価値を示し、「Ｓ」から始まる数字で第１の評価値を示している。
【０２５４】
｛ＴＩＤ６（Ｄ１．７２）、ＴＩＤ７（Ｓ１．０）、ＴＩＤ１５（Ｓ１．０）、ＴＩＤ１７（Ｄ１．０）、ＴＩＤ５７（Ｓ０．６４）、ＴＩＤ５８（Ｄ１．０）｝
次に、スキーマクエリ解析部３２１において、スキーマクエリのｒｅｔｕｒｎ節の解析を行う（図４３のステップＳ３０２）。この処理動作について、図５７に示すフローチャートを参照して説明する。
【０２５５】
ｒｅｔｕｒｎ節には、抽出すべき文書構造の先頭の構成要素の要素名や属性名が、１つずつ「ｘｓｐ：ｅｌｅｍ」という要素名（タグ名）の構成要素に記述されている。図４５に示したスキーマクエリでは、要素名に含まれる文字列として、「特許」が指定されている。
【０２５６】
まず、ｒｅｔｕｒｎ節から要素（「ｘｓｐ：ｅｌｅｍ」という要素名の構成要素）を１つずつ取出し（ステップＳ４３１）、当該要素に記述されている文字列、例えば、ここでは「特許」を処理対象の文字列として、図５５に示したように、構造推定処理を行う（ステップＳ４３２）。上記ステップＳ４３１〜ステップＳ４３２をｒｅｔｕｒｎ節内に記述された全ての要素について行う（ステップＳ４３３）。
【０２５７】
構造推定処理では、前述同様にして、まず、処理対象の文字列の類似語を意味ネットワークを用いて抽出する。
【０２５８】
この場合、「特許」（類似度「１．０」）、「Ｐａｔｅｎｔ」（類似度「０．８」）が抽出される。
【０２５９】
例えば、現在のＸＭＬデータベースが図４６に示すような状態であるとき、上記２つの語彙のいずれかを要素名にもつ構成要素を要素名称生起インデックスから求めると、以下のような３つのテンプレートＩＤが得られる。
【０２６０】
｛ＴＩＤ４（Ｓ１．０）、ＴＩＤ５５（Ｓ０．８）、ＴＩＤ７２（Ｓ１．０）｝なお、図４６では、上記３つのテンプレートＩＤに対応する構成要素（ノード）を丸印で囲み示している。
【０２６１】
次に、図４３のステップＳ３０３の処理を行う。すなわち、ｗｈｅｒｅ節を処理した結果得られた構成要素と、ｒｅｔｕｒｎ節を処理した結果得られた構成要素とから、テンプレートツリーから１つのＸＭＬ文書の文書構造の先頭となる構成要素を抽出する。具体的には、ｒｅｔｕｒｎ節の処理により抽出された構成要素と、ｗｈｅｒｅ節の処理により抽出された構成要素とのテンプレートツリー上の親子関係をチェックする。
【０２６２】
ｗｈｅｒｅ節の処理により抽出される構成要素は、文書構造の下流にある構成要素であり、ｒｅｔｕｒｎ節の処理により抽出される構成要素は、文書構造の先頭の構成要素である。
【０２６３】
例えば、ｒｅｔｕｒｎ節の処理により抽出された構成要素に対応するノード以下に、ｗｈｅｒｅ節の処理により抽出された構成要素が存在する場合には、ｒｅｔｕｒｎ節の処理により抽出された当該構成要素を、抽出すべき文書構造の先頭の構成要素の候補として、出力候補リストに登録する。
【０２６４】
以下、ＸＭＬデータベースが図４６に示したような状態である場合を例にとり説明するが、この場合のテンプレートツリーの構造も、図４６と同様である。但し、図４６に示すように、「ＸＭＬ」や「ＳＧＭＬ」などの語彙は、テンプレートツリーには含まれていない。また、図４６には、構成要素の属性は、２重の四角形で囲み、示している。
【０２６５】
まず、テンプレートツリーを下流側にある構成要素から上流へ向かって探索して、上記親子関係をチェックする。
【０２６６】
例えば、テンプレートＩＤ「ＴＩＤ６」の構成要素の親要素（１段上の階層にある構成要素であって、テンプレートＩＤ「ＴＩＤ６」の構成要素を包含する構成要素）は、テンプレートＩＤ「ＴＩＤ４」の構成要素である。このテンプレートＩＤ「ＴＩＤ４」の構成要素は、ｒｅｔｕｒｎ節の処理により抽出された構成要素であるので、この時点で、テンプレートＩＤ「ＴＩＤ４」は出力候補リストに追加する。
【０２６７】
続いて、テンプレートＩＤ「ＴＩＤ７」の構成要素に対してであるが、これも上記同様に、テンプレートＩＤ「ＴＩＤ４」が親要素である。テンプレートＩＤ「ＴＩＤ４」は、既に出力候補リストに登録されているので、次に進む。
【０２６８】
テンプレートＩＤ「ＴＩＤ１５」の親要素は、テンプレートＩＤ「ＴＩＤ１４」の構成要素であるが、これは、ｒｅｔｕｒｎ節の処理により抽出された構成要素ではないので、更に上流に遡る。「ＴＩＤ１４」の１段上の階層には「ＴＩＤ１３」があり、さらに、その１段上の階層には「ＴＩＤ１２」があり、さらに、その１段上の階層には「ＴＩＤ１」がある。これらはどれもｒｅｔｕｒｎ節の処理により抽出された構成要素ではないので、テンプレートＩＤ「ＴＩＤ１５」はスキーマ検索から除外する。
【０２６９】
同様にして、テンプレートＩＤ「ＴＩＤ１７」も除外される。
【０２７０】
テンプレートＩＤ「ＴＩＤ５７」、テンプレートＩＤ「ＴＩＤ５８」は、それぞれ上流にテンプレートＩＤ「ＴＩＤ５５」を持ち、これはｒｅｔｕｒｎ節の処理により抽出された構成要素であるから、当該テンプレートＩＤ「ＴＩＤ５５」を出力候補リストに登録する。
【０２７１】
この時点での、出力候補リストには、「ＴＩＤ４」と「ＴＩＤ５５」が登録されている。
【０２７２】
次に、テンプレートツリーを上流から下流に探索して、上記親子関係をチェックする。
【０２７３】
ｒｅｔｕｒｎ節の処理に抽出されたテンプレートＩＤは、「ＴＩＤ４」と「ＴＩＤ５５」と「ＴＩＤ７２」であったが、このうち、「ＴＩＤ４」と「ＴＩＤ５５」は、既に、出力候補リストに登録されている。従って、例えばここでは、残りの「ＴＩＤ７２」も出力候補リストに追加登録する。もちろん、この場合、「ＴＩＤ７２」は出力候補リストに登録しなくともよい。
【０２７４】
この時点で出力候補リストには、「ＴＩＤ４」、「ＴＩＤ５５」、「ＴＩＤ７２」が登録されている。
【０２７５】
次に、図４３のステップＳ３０４のスキーマ推定処理により、先に抽出された構成要素を先頭とする文書構造から、抽出すべき構成要素群を抽出する。
【０２７６】
図４６に示したように、「ＴＩＤ４」を先頭する文書構造を構成する構成要素群は、｛ＴＩＤ４（Ｓ１．０）、ＴＩＤ５、ＴＩＤ６（Ｄ１．７２）、ＴＩＤ７（Ｓ１．０）、ＴＩＤ８、ＴＩＤ９、ＴＩＤ１０、ＴＩＤ１１｝である（図４７参照）。
【０２７７】
まず、図３７に示したようなテンプレートツリーに記述されている情報（例えば、「ｒｅｑｕｉｒｅｄ」という属性の値）を基に、これら各構成要素の中から、「ＴＩＤ４」を先頭する文書構造を構成するために必ず必要となる構成要素を選択する。
【０２７８】
上記構成要素のうち、テンプレートツリー上に、「ＴＩＤ４」を先頭する文書構造を構成するために必須と指定されているもの（すなわち、「ｒｅｑｕｉｒｅｄ」という属性の値が「ｙｅｓ」となっている構成要素）は、「ＴＩＤ５」、「ＴＩＤ６」、「ＴＩＤ７」、「ＴＩＤ８」であるので、これら構成要素からなる文書構造（スキーマ）が検索結果の１つして求めることができる。
【０２７９】
なお、図４８に、上記文書構造をＸＭＬＳＣＨＥＭＡで記述した場合のスキーマ文書（ＸＭＬ文書）を示す。この文書には、＜ｘｓｄ：ｓｅｑｕｅｎｃｅ＞が付加されることになる。
【０２８０】
同様に、「ＴＩＤ５５」を先頭する文書構造を構成する構成要素群は、｛ＴＩＤ５５、ＴＩＤ５６、ＴＩＤ５７、ＴＩＤ５８｝である（図４９参照）。これら全ての構成要素は、テンプレートツリー上に、「ＴＩＤ５５」を先頭する文書構造を構成するために必須と指定されているので、上記構成要素群からなる文書構造（スキーマ）が検索結果の他の１つして求めることができる。
【０２８１】
なお、図５０に、上記文書構造をＸＭＬＳＣＨＥＭＡで記述した場合のスキーマ文書（ＸＭＬ文書）を示す。
【０２８２】
同様に、「ＴＩＤ７２」を先頭する文書構造を構成する構成要素群は、｛ＴＩＤ７２、ＴＩＤ７３、ＴＩＤ７４、ＴＩＤ７５｝である（図５１参照）。これら全ての構成要素は、テンプレートツリー上に、「ＴＩＤ７２」を先頭する文書構造を構成するために必須と指定されているので、上記構成要素群からなる文書構造（スキーマ）が検索結果のさらに他の１つして求めることができる。図３７に示したようなテンプレートツリーには、「ＴＩＤ７５」の構成要素については、数値型を定める情報、すなわち、「ｄａｔａＴｙｐｅ」が記述されているので、この「年」という構成要素に対しては数値型のスキーマが設定される。
【０２８３】
このように、図４３のステップＳ３０３で、文書構造の先頭の構成要素を求めたら、ステップＳ３０４では、テンプレートツリーから当該構成要素を先頭とする文書構造を構成する構成要素群を抽出する。その際、上記のように、テンプレートツリーに記述されている各構成要素についての記述を基に、抽出すべき構成要素を選択するようにしてもよいし、選択せずに、当該文書構造を構成する全ての構成要素を抽出してもよい。
【０２８４】
また、抽出した文書構造をＸＭＬ文書、すなわち、図４８や図５０に示したようなスキーマ文書に変換する。このスキーマ文書に変換する際、テンプレートツリー上の当該構成要素に対し記述されている情報を基に、各構成要素の属性（例えば、数値型など）などを記述する。
【０２８５】
このように、テンプレートツリーには、図３７に示したようなＸＭＬ文書として、スキーマを検索し、スキーマ文書を作成する際に用いる情報が全て記述されている。
【０２８６】
次に、図４３のステップＳ３０５に進み、検索結果として得られた各スキーマに対し、評価点（スコア）を算出する。
【０２８７】
例えば、検索結果として得られた、テンプレートＩＤ「ＴＩＤ４」の構成要素を先頭とするスキーマを構成する構成要素群はその第１の評価値（Ｓ）や第２の評価値（Ｄ）とともに示すと、｛ＴＩＤ４（Ｓ１．０）、ＴＩＤ５、ＴＩＤ６（Ｄ１．７２）、ＴＩＤ７（Ｓ１．０）、ＴＩＤ８、ＴＩＤ９、ＴＩＤ１０、ＴＩＤ１１｝であった。このスキーマの評価点は、各構成要素に与えられた第１の評価値と第２の評価値の総和であり、Ｓ１．０＋Ｓ１．０＋Ｄ１．７２＝３．７２となる。
【０２８８】
ここで、総和を求める際には、第１の評価値や第２の評価値にそれぞれ重みを設定してもよい。上記例の場合、第１の評価値や第２の評価値のそれぞれについて重みを「１」として計算している。
【０２８９】
また、検索結果として得られた、テンプレートＩＤ「ＴＩＤ５５」の構成要素を先頭とするスキーマを構成する構成要素群はその第１の評価値（Ｓ）や第２の評価値（Ｄ）とともに示すと、例えば、｛ＴＩＤ５５（Ｓ０．８）、ＴＩＤ５６、ＴＩＤ５７（Ｓ１．０）、ＴＩＤ５８｝であったとする。このスキーマの評価点は、上記同様にして求めると、Ｓ０．８＋Ｓ１．０＝１．８　となる。
【０２９０】
さらに、検索結果として得られた、テンプレートＩＤ「ＴＩＤ７２」の構成要素を先頭とするスキーマを構成する構成要素群はその第１の評価値（Ｓ）や第２の評価値（Ｄ）とともに示すと、｛ＴＩＤ７２（Ｓ１．０）、ＴＩＤ７３、ＴＩＤ７４、ＴＩＤ７５｝であったとする。このスキーマの評価点は、上記同様にして求めると、「１．０」となる。
【０２９１】
次に、図４３のステップＳ３０６に進み、出力データを作成する。
【０２９２】
ここでは、例えば、ステップＳ３０４において、検索結果として抽出された各スキーマのスキーマ文書に、上記ステップＳ３０５で求めた評価点を書き込み、このスキーマ文書を１つのＸＭＬ文書としてまとめて、例えば、図５２に示したような出力データを作成する。図５２に示したＸＭＬ文書は、評価点の高い物から順にスキーマ文書を並べて表示するためのものである。
【０２９３】
スキーマ検索処理部３０３で作成された、図５２に示したような出力データ（検索結果文書）は（必要に応じて、当該検索結果文書を表示するためのスタイルシートとともに）、結果処理部１２から、クライアント端末１０２へ送信される。
【０２９４】
クライアント端末１０２では、図５２に示した検索結果文書を受け取ると、当該検索結果文書とともに送られてきた（あるいは、予め定められた）スタイルシートを用いて、当該検索結果文書を表示するとともに、例えば、その中からユーザにより選択されたスキーマを、当該検索結果文書とともに送られてきた（あるいは、予め定められた）スタイルシートを用いて表示する。図５３は、検索結果として得られたスキーマの表示例を示したものであり、図５２に示した検索結果文書中の最初のスキーマ（テンプレートＩＤ「ＴＩＤ４」の構成要素を先頭とする文書構造）の表示例を示している。
【０２９５】
図５３に示す表示例では、そのまま入力フォームとなるように、入力領域が設けられている。
【０２９６】
なお、検索結果として得られたスキーマをもつＸＭＬ文書のＸＭＬデータベースの階層構造上の格納位置（構造化文書パス）は、テンプレートツリー上の当該スキーマの位置と同じであるから、例えば、図５３に示した入力フォームからデータを入力することにより作成された新規なＸＭＬ文書をＸＭＬデータベースに格納する場合、当該構造化文書パスを挿入コマンドや追加コマンドのパスの指定に用いればよい。よって、ユーザは、新規に作成したＸＭＬ文書の格納位置をどこにすればよいかと迷うことなく、当該新規なＸＭＬ文書をＸＭＬデータベース上の適切な格納位置に格納することができる。
【０２９７】
このようにして、上記文書構造の検索結果を用いて新規にＸＭＬ文書を作成した場合、内容的に類似する（同じカテゴリに属する）ＸＭＬ文書は、ほぼ同じ文書構造のものとなり（スキーマの氾濫を極力抑えることができ）、また、ＸＭＬデータベース上の格納位置もユーザがわざわざ指定することもないので、内容的に類似する（同じカテゴリに属する）ＸＭＬ文書は、ＸＭＬデータベース上で管理し易い格納位置にまとめられて記憶することができる（例えば、図４６において、先頭が「特許」という要素名の構成要素の文書であれば、それらは全て「特許ＤＢ」ノード以下に格納される）。
【０２９８】
次に、スキーマ検索のための検索条件の入力画面上に、ユーザは、検索したいスキーマとして、例えば、「ＸＭＬ関連のスキーマ」という、上記（条件１）、すなわち、要素名あるいは要素値あるいは属性値に含まれる文字列のみを指定した、検索条件を入力したとする。この場合は、キーワードレベルの漠然とした要求しかない場合である。
【０２９９】
この様な検索条件が入力された場合、クライアント端末１０２、あるは構造化文書管理システムの要求受付部１１では、例えば、「ＸＭＬ」という文字列を要素値に含む文書構造を検索する検索要求文（スキーマクエリ）が作成されたとする。
【０３００】
このスキーマクエリが、前述同様にして、図４６に示すようなＸＭＬデータベースをもつ構造化文書管理システムのスキーマ検索処理部３０３にて処理される。ｗｈｅｒｅ節の処理では、「ＸＭＬ」とこれに類似する語彙を表す文字列（例えば、「ＳＧＭＬ」など）のいずれかを要素値にもつ構成要素のテンプレートＩＤとして、「ＴＩＤ６」、「ＴＩＤ１７」「ＴＩＤ５８」が語彙推定処理により抽出される。なお、「ＸＭＬ」の類似度は「１．０」、「ＳＧＭＬ」の類似度は「０．６４」であるので、これら抽出された各構成要素をその評価値とともに示すと、｛ＴＩＤ６（Ｄ１．６７）、ＴＩＤ１７（Ｄ１．０）、ＴＩＤ５８（Ｄ１．０）｝となる。
【０３０１】
次に、ｒｅｔｕｒｎ節の処理であるが、この場合は、ｒｅｔｕｒｎ節に記述するようなユーザにより指定された条件そのものが存在しない。この場合、スキーマクエリのｒｅｔｕｒｎ節には、例えば、「＜ｘｓｐ：ｒｅｔｕｒｎ　ｔｙｐｅ＝”ａｌｌ”／＞」と記述されているので、スキーマ検索処理部３０３では、テンプレートツリー上の文書のルートノードを判別し（すなわち、前述したように、テンプレートツリー上では、１つのＸＭＬ文書の先頭の構成要素には「ｄｏｃｕｍｅｎｔ」という属性値が記述されているので、これをチェックすることによりルートノードを判別することができる）、テンプレートツリーから、ルートノードを先頭とする文書構造であって、ｗｈｅｒｅ節を処理することにより抽出された構成要素（「ＴＩＤ６」、「ＴＩＤ１７」、「ＴＩＤ５８」）のいずれかを含む文書構造を取り出すこととなる。
【０３０２】
すなわち、この場合、図４３のステップＳ３０３へ進む。まず、テンプレートＩＤ「ＴＩＤ６」の構成要素について、その上流に遡ると、「ＴＩＤ４」に至るが（図４６参照）、この構成要素について、図３７に示したようなテンプレートツリーの記述をチェックする。すると、この構成要素には、「＜ｘｓｐ：Ｎｏｄｅ　ｔｙｐｅ＝“ｄｏｃｕｍｅｎｔ”＞」と記述されているので、この「ＴＩＤ４」を先頭とする文書構造を抽出候補とする。すなわち、「ＴＩＤ４」を出力候補リストに登録する。
【０３０３】
同様にして、「ＴＩＤ１４」、「ＴＩＤ５」８も出力候補リストに追加されることになる。
【０３０４】
つまり、この時点で、抽出すべき文書構造として、
▲１▼｛ＴＩＤ４、ＴＩＤ５、ＴＩＤ６、ＴＩＤ７、ＴＩＤ８、ＴＩＤ９、ＴＩＤ１０、ＴＩＤ１１｝
▲２▼｛ＴＩＤ１４、ＴＩＤ１５、ＴＩＤ１６、ＴＩＤ１７｝
▲３▼｛ＴＩＤ５５、ＴＩＤ５６、ＴＩＤ５７、ＴＩＤ５８｝
という３つの文書構造が挙がる。
【０３０５】
以上３つの文書構造を構成する各構成要素のうち、テンプレートツリーの記述を基に、必須な構成要素のみを選択するなどして、抽出すべき構成要素群（スキーマ）を抽出する（図４３のステップＳ３０４）。
【０３０６】
さらに、この検索結果として得られた各スキーマに対し、評価点を求めて（図４３のステップＳ３０５）、出力データを作成する。
【０３０７】
なお、以上のようにして、検索されたスキーマについて、予めスキーマが設定されている場合（予め定められたスキーマに従って記述された文書のスキーマである場合）には、当該スキーマを記述したスキーマ文書をＸＭＬデータベースから検索して、それを検索結果のスキーマとして用いてもよい。
【０３０８】
また、ＸＱｕｅｒｙなどによって検索した結果に対して、データとともに付加的にスキーマ情報をクライアントに通知するようにしてもよい。ＸＱｕｅｒｙで検索した結果はデータだけになり、それらの構造が見えにくい部分があるが、それを補完することが可能となる。また、その結果情報として、テンプレート要素に対して、累積カウントを記述することで、それらをブラウジングすることで、データベース中のパスと、その頻度を一目で把握することも容易となる。
【０３０９】
また、アクセス権限をテンプレートツリー上の各構成要素に設定されていてもよい。例えば、部署Ａと部署Ｂがあり、それぞれの管轄範囲のＸＭＬ文書が、ＸＭＬデータベース上の予め定められた領域に格納されているとする。この場合、部署Ａの管轄文書に対して、部署Ｂはアクセスできないが、文書Ｂにはスキーマのみであれば公開するといったアクセス権限が設定されていてもよい。スキーマを公開することで、例えば、後に部署Ａ，部署Ｂ内のアプリケーション連携を行う際に、それらスキーマの違いを吸収することなく、コスト削減が行える。
【０３１０】
また、各種文書をＸＭＬデータベース内に格納しようとした場合、このデータはどこに格納するのが適しているか、などが分からなくなり、一時的に適当な位置に格納しておくだけ、といった場合が多く、その場合、その情報は埋もれています場合が多い。ＸＭＬデータベース管理下においては、それらがサーバ側で管理されており、１つのＸＭＬツリーとして表されているために、格納対象の文書をどこに格納すれば良いかの指針も示してくれる。さらにいえば、格納場所はフォルダである必要もなく、部分文書であってもよい。よって、スキーマの氾濫を極力減らすことも可能である。
【０３１１】
以上のように、上記実施形態によれば、階層構造をもつＸＭＬデータベースから、構造、語彙が確定していない曖昧な条件から所望のスキーマおよび、そのスキーマを抽出したＸＭＬデータベース中の位置を、スキーマの明示的な定義の有無を問わず検索することが容易に可能となる。
【０３１２】
【発明の効果】
以上説明したように、本発明によれば、階層構造を有するＸＭＬデータベースから漠然とした検索条件を基に文書構造を効率よく検索することができる。
【図面の簡単な説明】
【図１】本発明の実施形態に係る構造化文書管理システムの構成例を示した図。
【図２】図１に示した構造化文書管理システムの一利用形態を示したもので、ＷＷＷのバックエンドで、構造化文書管理システムが動作している場合を示した図。
【図３】ＸＭＬで記述された構造化文書の一例を示した図。
【図４】図３の構造化文書の文書構造を模式的に示した図。
【図５】追加コマンドの機能を説明するための図で、構造化文書データベースの初期状態に追加コマンドを実行した場合について示している。
【図６】図５（ｂ）に示した状態の構造化文書データベースに対し、取得コマンドを実行した場合の処理結果を示した図。
【図７】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して１つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図８】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して３つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図９】要素名生起インデックスの格納例を示した図。
【図１０】データ生起インデックスの格納例を示した図。
【図１１】図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合の実行結果を示した図。
【図１２】ＸＭＬ文書の文書構造を定義するスキーマの一例を示した図。
【図１３】図８に示した状態の構造化文書データベースに、スキーマ格納コマンドを実行して、図１２に示したスキーマを追加格納（設定）した場合を示した図。
【図１４】スキーマが設定されて、スキーマが存在している旨の属性値のセットされた文書オブジェクトツリーを示した図。
【図１５】各オブジェクトファイルに、スキーマが存在している旨の属性値が格納されている様子を概念的に示した図。
【図１６】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１７】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１８】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図１９】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図２０】クエリ（ＸＭＬ文書）の一例を示した図。
【図２１】単純検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図２２】図２１の単純検索のクエリを用いた検索結果（ＸＭＬ文書）を示した図。
【図２３】概念検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図２４】図１の構造化文書管理システムの文書検索処理動作について説明するためのフローチャート。
【図２５】ユーザインタフェースとしての画面の表示例を示した図。
【図２６】文書検索を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図２７】図２６に示した画面上から入力された情報に基づき作成されるクエリを示した図。
【図２８】図１の構造化文書管理システムの文書取得処理動作について説明するためのフローチャート。
【図２９】文書取得コマンドを実行した結果得られた構造化文書の表示例を示した図。
【図３０】文書検索を行うためのユーザインタフェースとしての画面の表示例であって、スキーマの検索処理動作を説明するための図。
【図３１】スキーマ検索のクエリの一例を示した図。
【図３２】スキーマの取得するためのユーザインタフェースとしての画面の表示例を示したもので、取得されたスキーマの表示例を示している。
【図３３】テンプレート処理部の構成例を示した図。
【図３４】テンプレートツリーの一例を示した図。
【図３５】ＸＭＬ文書の具体例を示した図。
【図３６】図３４に示したテンプレートツリーの更新後を示した図。
【図３７】テンプレートツリーの記憶例を示した図。
【図３８】スキーマ検索処理部３０３の構成例を示した図。
【図３９】スキーマクエリの一例を示した図。
【図４０】スキーマクエリの他の例を示した図。
【図４１】意味ネットワークの具体例を示した図。
【図４２】意味ネットワークを用いて検索条件として指定されたキーワードの類似語を求める処理を説明するためのフローチャート。
【図４３】スキーマ検索処理部の処理動作を説明するためのフローチャート。
【図４４】スキーマ検索のための検索条件の入力画面の表示例を示した図。
【図４５】図４４に示した入力画面から入力された検索条件に基づき作成されたスキーマクエリの一例を示した図。
【図４６】テンプレートツリーの具体例を示した図。
【図４７】検索した結果得られた文書構造を示した図。
【図４８】図４７に示した文書構造を記述したＸＭＬ文書の一例を示した図。
【図４９】検索した結果得られた他の文書構造を示した図。
【図５０】図４９に示した文書構造を記述したＸＭＬ文書の一例を示した図。
【図５１】検索した結果得られたさらに他の文書構造を示した図。
【図５２】出力データの一例を示した図。
【図５３】検索結果として得られたスキーマの表示例を示した図。
【図５４】スキーマクエリ中のｗｈｅｒｅ節の処理手順を説明するためのフローチャート。
【図５５】構造推定処理を説明するためのフローチャート。
【図５６】語彙推定処理を説明するためのフローチャート。
【図５７】スキーマクエリ中のｒｅｔｕｒｎ節の処理手順を説明するためのフローチャート。
【符号の説明】
１００…構造化文書管理システム
３０３…スキーマ検索処理部
３０６…テンプレート処理部
３０６ａ…構造抽出部
３０６ｂ…テンプレートツリー処理部
３２１…スキーマクエリ解析部
３２２…スキーマクエリ条件処理部
３２３…スキーマクエリ出力処理部
４０４…テンプレート記憶部
４０５…意味ネットワーク記憶部
【図１】
2004126640.tif 000003
【図２】
2004126640.tif 000004
【図３】
2004126640.tif 000005
【図４】
2004126640.tif 000006
【図５】
2004126640.tif 000007
【図６】
2004126640.tif 000008
【図７】
2004126640.tif 000009
【図８】
2004126640.tif 000010
【図９】
2004126640.tif 000011
【図１０】
2004126640.tif 000012
【図１１】
2004126640.tif 000013
【図１２】
2004126640.tif 000014
【図１３】
2004126640.tif 000015
【図１４】
2004126640.tif 000016
【図１５】
2004126640.tif 000017
【図１６】
2004126640.tif 000018
【図１７】
2004126640.tif 000019
【図１８】
2004126640.tif 000020
【図１９】
2004126640.tif 000021
【図２０】
2004126640.tif 000022
【図２１】
2004126640.tif 000023
【図２２】
2004126640.tif 000024
【図２３】
2004126640.tif 000025
【図２４】
2004126640.tif 000026
【図２５】
2004126640.tif 000027
【図２６】
2004126640.tif 000028
【図２７】
2004126640.tif 000029
【図２８】
2004126640.tif 000030
【図２９】
2004126640.tif 000031
【図３０】
2004126640.tif 000032
【図３１】
2004126640.tif 000033
【図３２】
2004126640.tif 000034
【図３３】
2004126640.tif 000035
【図３４】
2004126640.tif 000036
【図３５】
2004126640.tif 000037
【図３６】
2004126640.tif 000038
【図３７】
2004126640.tif 000039
【図３８】
2004126640.tif 000040
【図３９】
2004126640.tif 000041
【図４０】
2004126640.tif 000042
【図４１】
2004126640.tif 000043
【図４２】
2004126640.tif 000044
【図４３】
2004126640.tif 000045
【図４４】
2004126640.tif 000046
【図４５】
2004126640.tif 000047
【図４６】
2004126640.tif 000048
【図４７】
2004126640.tif 000049
【図４８】
2004126640.tif 000050
【図４９】
2004126640.tif 000051
【図５０】
2004126640.tif 000052
【図５１】
2004126640.tif 000053
【図５２】
2004126640.tif 000054
【図５３】
2004126640.tif 000055
【図５４】
2004126640.tif 000056
【図５５】
2004126640.tif 000057
【図５６】
2004126640.tif 000058
【図５７】
2004126640.tif 000059