JP3842573B2 - 構造化文書検索方法、構造化文書管理装置及びプログラム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、異なる文書構造の複数の構造化文書を、階層化された論理構造を持つ構造化文書データベースで管理する構造化文書管理システムに関する。
【０００２】
【従来の技術】
現在、ＩＴ（情報技術）の進化により、莫大な量の情報が容易に入手できるようになった。その一方で必要な情報が大量のデータに埋没してしまい、十分に活用できないという弊害も発生している。情報が大量に存在していても、それをうまく活用できなければ意味がない。
【０００３】
そこで、特定の個人や部門が保有するノウハウや業務データのうち企業の経営に重要なものを蓄積して、「経営資産」として活用しようとする活動、すなわち、ナレッジマネージメントが提唱されている。
【０００４】
例えば、特許明細書や、週報など、文書の種類によっては、その書式が予め定められて、１つの書式に統一されているのが一般的である。１つの書式に統一された文書もあれば、全く書式のない自由書式の文書も数多く存在する。
【０００５】
従って、ナレッジマネージメントを実現するためには、このような文書構造が予め定められているような文書も、それ以外の自由書式の文書も全て格納管理できるデータベースが必要となる。
【０００６】
次世代のナレッジマネージメントの中核技術として期待されている技術がＸＭＬである。ＸＭＬ（Ｅｘｔｅｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）は柔軟な拡張性と連携性を備えた標準のドキュメント記述言語であり、主要ベンダーからのサポートも約束されている。
【０００７】
構造化文書データベースとしては、ＲＤＢ（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢｅｓｅ）により構造化文書を格納する方式があるが、この場合、１つのスキーマ（データ構造定義）に従った文書構造の構造化文書群しか格納できす、また、文書構造はそのまま表形式に変換することは困難であり、ＲＤＢをそのまま構造化文書データベースとして用いることはできない。
【０００８】
また、構造化文書は階層的な構造をもつため、構造化文書を構成する各構成要素をオブジェクトとみなしたＯＯＤＢ（オブジェクト指向データベース）と親和性が高いと考えられる。しかし、ＯＯＤＢでは、文書構造は予めスキーマにより決定されていなければならず、子要素の任意繰り返しなど、オブジェクトモデルでモデル化するのは困難であり、ＯＯＤＢをそのまま構造化文書データベースとして用いることはできない。
【０００９】
ＸＭＬ文書はツリー構造を持ったデータである。近年、このようなＸＭＬ文書を蓄積、管理するＸＭＬデータベースが脚光を浴びている。
【００１０】
ＸＭＬデータベースは、管理対象の複数の構造化文書の各構成要素を１つの巨大な構造化文書の文書構造を構成する構成要素として管理するＸＭＬ特化のツリー状の階層的なデータ構造を持つ。階層的な構造上の構成要素は「パス」により特定される。パスは、ＸＭＬデータベース上の特定のエリアを指し示すための手段である。
【００１１】
ＸＭＬデータベースに格納されるＸＭＬ文書群はツリー状の１つの巨大なＸＭＬ文書として構成される。部分的なＸＭＬ文書をアクセスするには、ＸＭＬ文書に対するパスというアクセス手段を用いる。このような特徴により、幅広くＸＭＬ文書を検索したり加工することが可能となる。
【００１２】
ＸＭＬデータベースで格納されるＸＭＬ文書の文書構造は、必ずしもスキーマが定義されている必要はないが、スキーマを定義するとしたら、１つのデータベースに１つのスキーマしか許容されていない。すなわち、スキーマを用いなければ、異なる文書構造の文書を混在させて格納・管理することができるが、スキーマを１つ設定したら、それとは異なる文書構造の文書は混在させることはできない。
【００１３】
ＸＭＬデータベースに１つのスキーマを設定して、この設定されたスキーマに適合する文書のみを格納・管理する方式を提案しているものに、特開平７−５６７８６号公報「構造化文書管理装置」がある。
【００１４】
一方で、ＯＬＡＰ（Ｏｎｌｉｎｅ Ａｎａｌｙｔｉｃａｌ Ｐｒｏｃｅｓｓｉｎｇ）と呼ばれる技術がある。これは、エンドユーザーが直接データベースを検索・集計して問題点や解決策を発見する分析型アプリケーションである。この技術を用いることにより、例えば、各店舗毎の膨大な売上情報を、製品別、地域別、年度別などの様々な次元ごとに瞬時に切り替えて分析を行うことが可能である。
【００１５】
このＯＬＡＰを適用するデータベースとして、複数の属性項目（次元）を次々に切り替えて、データを検索・集計できる多次元データベースが注目を集めている。任意の２つの属性項目を選ぶと、即座に２次元の表形式（マップ）でデータを表示する。
【００１６】
しかし、多次元データベースは、属性項目の全ての組合せに対応する集計結果を予め用意しておくため、大量のデータを管理しなければならないし、独自のデータ構造を持つため、専用のクライアント・ソフトも必要となる。
【００１７】
これに対してリレーショナル・データベース（ＲＤＢ）は正規化されたデータを２次元の表形式で管理し、分析に必要な複数の表を結合することで集計結果の１つの表を作成する。視点を変える毎にデータを連結するため、応答に時間がかかる。
【００１８】
【発明が解決しようとする課題】
異なる文書構造の膨大な数の構造化文書をデータベース上で格納・管理するには、ある特定の種類の文書に特定の文書構造が予め定められている場合、そのような種類の文書は、全て同じ文書構造に統一されている方が、後に、検索等の操データ操作の際に都合がよい。
【００１９】
しかし、従来のＸＭＬデータベースでは、１つのデータべース上で種類の違いにより異なる文書構造の文書をそれぞれの種類対応の文書構造で統一性を保持しながら、格納、管理できるものはなかった。すなわち、１つのスキーマに適合した文書の格納・管理はできても、複数のスキーマを混在させてスキーマ対応していない文書とともに、各スキーマ対応の文書の格納・管理はできなかった。
【００２０】
複数のスキーマのそれぞれに対応する複数のデータベースを設けることも考えられるが、この場合、スキーマが異なればアクセスするデータベースも異なる。そのため、多種多様な文書構造の膨大な数の文書へのアクセスが統一的でなく、多種多様な膨大な情報の中から関連する情報群を検索・抽出することが困難であった。
【００２１】
このように、従来は、多種多様な文書構造定義に従った文書を、その文書の種類対応に予め定められた文書構造の同一性を保持しながら、文書構造の定義がなされていない構造化文書とともに一元管理することができないがため、多種多様な文書構造の文書に対し、統一的なアクセスにて、多種多様な膨大な情報の中から関連する情報群を特定の文書構造に限定されずに検索・抽出することができなかった。
【００２２】
従って、従来は、多種多様な文書構造定義に従った膨大な数の構造化文書の中から、複数の属性項目（次元）を次々に切り替えて、データを検索し、集計した結果を表示するＯＬＡＰを容易に実現することができなかった。
【００２３】
一度、分析の視点の変更のために属性項目を変更した場合には、その変更された属性項目を検索条件に設定し直して、検索・集計操作をやり直さなければならない。このような手間を経るために、ある視点に基づき設定された属性項目による検索・集計結果の表示画面から、違った視点からの検索・集計結果の表示画面に遷移させることが容易に行えなかった。
【００２４】
このように、ＯＬＡＰを実現するためには、分析する視点が変更される度に、変更された属性項目によるデータの検索・集計結果の表示画面を切り替える必要があるが、このような検索・集計を伴う画面遷移が容易に行えないという問題点があった。
【００２５】
そこで、本発明は、上記問題点に鑑み、構造化文書データベースでＯＬＡＰを実現可能にし、様々な観点からのデータ分析が容易に行える構造化文書検索方法およびそれを用いた構造化文書検索装置および構造化文書管理装置およびプログラムおよび記録媒体を提供することを目的とする。
【００２６】
また、多種多様な文書構造定義に従った文書を、その文書の種類対応に予め定められた文書構造の同一性を保持しながら、文書構造の定義がなされていない構造化文書とともに一元管理する構造化文書データベースでＯＬＡＰを実現可能にし、様々な観点からのデータ分析が容易に行える構造化文書検索方法およびそれを用いた構造化文書検索装置および構造化文書管理装置およびプログラムおよび記録媒体を提供することを目的とする。
【００２７】
【課題を解決するための手段】
本発明は、複数の構造化文書を格納した階層化された論理構造を持つ構造化文書データベースに対して、前記論理構造を構成する前記構造化文書の構成要素とその値を検索条件に含む検索要求に基づき検索を行うものであって、前記検索条件を与えるための、少なくとも前記構成要素とその値とを含む指示データを受け付けて、前記指示データを基に前記構造化文書データベースに対し検索を行うための検索要求文を作成し、この作成された検索要求文に基づき前記構造化文書データベースに対し検索を行い、得られた検索結果は、前記検索要求文に対応した表示形式で要求元で画面表示させるとともに、該検索結果の画面表示から他の検索結果の表示画面への画面遷移が可能なときは、前記検索結果の表示領域に画面遷移に必要な前記指示データを関連付け、前記指示データの関連付けられた表示領域がユーザにより指定されたとき、その表示領域に関連付けられた前記指示データを受け付けて、該指示データを基に前記検索要求文を作成し、この作成された検索要求文に基づき前記構造化文書データベースに対し検索を行い、得られた検索結果を該検索要求文に対応した表示形式で要求元で画面表示させることにより、検索を伴う画面遷移が容易に行え、上記構造化文書データベースでＯＬＡＰを実現可能にし、様々な観点からのデータ分析が容易に行える。
【００２８】
好ましくは、前記構造化文書データベースには、予め概念の分類構造が格納され、前記検索条件として、少なくとも前記構成要素と、該構成要素の値として前記分類構造上の構成要素を与える。
【００２９】
また、好ましくは、前記検索要求文は、予め定義された文書構造に従って記述された構造化文書であって、前記構造化文書データベースは、予め前記検索要求文を格納し、前記指示データには、前記検索要求文を特定するための識別情報を含み、この識別情報に基づき前記構造化文書データベースから検索要求文を取得し、この取得した検索要求文中の検索条件に、前記指示データに含まれる前記構成要素とその値を設定することで、前記構造化文書データベースに対し検索を行うための検索要求文を作成する。
【００３０】
【発明の実施の形態】
まず、本発明の実施形態について説明する前に、構造化文書管理システムについて説明する。
【００３１】
（構造化文書管理システムの説明）
構造化文書として、ＸＭＬやＳＧＭＬなどで記述した文書が挙げられる。ＳＧＭＬ（Ｓｔａｎｄａｒｄ Ｇｅｎｅｒａｌｉｚｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）とは、ＩＳＯ（国際標準化機構）で定められた規格である。ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）とは、Ｗ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）にて定められた規格である。それぞれ文書を構造化することを可能とする構造化文書規約である。
【００３２】
以下、構造化文書として、ＸＭＬにて記述された文書を例に説明を進める。構造化文書の文書構造を定義したデータ（文書構造定義データ）をスキーマと呼ぶ。ＸＭＬではそのスキーマを定義するためにＸＭＬ−ＳｃｈｅｍａやＸＤＲ（ＸＭＬ Ｄａｔａ Ｒｅｄｕｃｅｄ）などのスキーマ言語が提案されている。ここでは、例えば、ＸＤＲでのスキーマを記述する場合を例にとり説明する。
【００３３】
スキーマも、構造化文書管理システムの管理対象の構造化文書であり、従って、スキーマ文書と呼ぶことがある。スキーマ文書と区別するために、特許明細書やメール、週報、広告などの種々雑多な内容を有す文書をコンテンツ文書と呼ぶこともある。
【００３４】
構造化文書管理システムでは、上記スキーマ文書、上記コンテンツ文書、さらに、後述するようなユーザからの検索要求内容を記述したクエリ、すなわち、クエリ文書も管理対象とし、これらを総称して「文書」と呼ぶ。
【００３５】
以下、特にことわりがない場合、「文書」と呼ぶときは、コンテンツ文書、スキーマ文書、クエリ文書を全て指すものとする。
【００３６】
まず、実施形態の説明を前に、ＸＭＬについて簡単に説明する。
【００３７】
図３は、ＸＭＬで記述された構造化文書の一例として、「特許」情報の例を示したものである。ＸＭＬやＳＧＭＬは、文書の構造の表現にタグが用いられる。タグには、開始タグと終了タグがあり、文書構造情報の構成要素を開始タグと終了タグで囲むことにより、文書中の文字列（テキスト）区切りと、そのテキストが構造上どの構成要素に属するのかを明確に記述することができる。
【００３８】
ここで開始タグとは要素名称を記号「＜」、「＞」で閉じたものであり、終了タグとは要素名称を記号「＜／」と「＞」で閉じたものである。タグに続く構成要素の内容が、テキスト（文字列）または子供の構成要素の繰り返しである。また開始タグには「＜要素名称 属性＝“属性値”＞」などのように属性情報を設定することができる。「＜特許ＤＢ＞＜／特許ＤＢ＞」のようにテキストを含まない構成要素は、簡易記法として「＜特許ＤＢ／＞」のように表わすこともできる。
【００３９】
図３に示した文書は、「特許」タグから始まる要素をルート(根)とし、その子要素として「タイトル」、「出願日」、「出願者」、「要約」タグから始まる要素集合が存在する。また、例えば、「タイトル」タグから始まる要素には「ＸＭＬデータベース」といった、１つのテキスト（文字列）が存在する。
【００４０】
ＸＭＬなどの構造化文書は、任意の構成要素を繰り返し含んでいたり、さらには文書構造があらかじめ決まっていない（ＲＤＢ（リレーショナルデータベース）やＯＯＤＢ（オブジェクト指向データベース）のスキーマでは定義できない）のが普通である。
【００４１】
図３に示したような構造化文書を論理的に表現するために、図４に示すようなツリー表現が用いられる。ツリーは、ノード（番号が付され、円形で示されたもの）とアーク（ノードを表す円形間をつなぐデータ付き線）と四角形で囲まれたテキストから構成されている。
【００４２】
ノードは文書オブジェクトに対応し、ノードからタグ名や属性名に相当するラベルが付与された複数のアークが出てきている。そのアークの先は、ノードまたは要素値としての文字列（テキスト）である。ノードの中に記載されている英数字（＃０、＃４９）などはオブジェクトＩＤである。
【００４３】
図４に示したツリー構造を図３に示した構造化文書の文書オブジェクトツリーと呼ぶ。
【００４４】
図１は、本実施形態に係る構造化文書管理システムの構成例を示したものである。図１において、構造化文書管理システムは、大きく分けて、要求制御部１、アクセス要求処理部２、検索要求処理部３、データアクセス部４、文書記憶部５、インデックス記憶部６から構成されている。文書記憶部５、インデックス記憶部６は例えば、外部記憶装置を用いて構成される。
【００４５】
図１のシステム構成は、ソフトウエアを用いて実現可能である。
【００４６】
要求制御部１は、要求受付部１１と結果処理部１２から構成されている。要求受付部１１は、ユーザからの文書格納や文書取得、文書検索などの要求を受け付けて、アクセス要求処理部２を呼び出す。結果処理部１２は、アクセス要求処理部２が処理した結果を要求元のユーザに返す処理を行う。
【００４７】
アクセス要求処理部２は、ユーザからの文書格納や文書取得などの要求に対応した複数の処理部から構成されている。つまり、文書格納部２１、文書取得部２２、文書削除部２３から構成されている。
【００４８】
文書格納部２１は、文書記憶部５中の論理的な指定エリアに文書を格納する処理を行う。
【００４９】
文書取得部２２は、文書記憶部５中の論理的なエリアが指定されたときに、その指定エリアに存在する文書を取得する処理を行う。
【００５０】
文書削除部２３は、文書記憶部５中の論理的な指定エリアに存在する文書を削除する処理を行う。
【００５１】
文書記憶部５は、構造化文書データベースであり、例えば、図８に示すように、文書をＵＮＩＸのディレクトリ構造のように階層的にツリー構造状に格納している。
【００５２】
図８に示すように、構造化文書データベースは、図４に示したような１つの構造化文書のツリー構造と同様に表現できる。すなわち、任意のノード以下の部分階層木（部分ツリー）は、構造化文書データベースから切り出された構造化文書であり、ここでは、これを文書オブジェクトツリーと呼ぶ。各ノードにはオブジェクトＩＤが割り当てられている。オブジェクトＩＤは、構造化文書データベース内ではユニークな数値を持つものとする。
【００５３】
階層木のルートとなるノードには、それがルートノードであることを特定するためのオブジェクトＩＤ「＃０」が割り当てられるものとする。
【００５４】
ルートノード、すなわち、「＃０」のノードからは「ｒｏｏｔ」タグを先頭に持つ「＃１」のノードへリンクが張られている。「＃１」のノードからは、「特許ＤＢ」タグを先頭にもつ「＃２」ノードへのリンクが張られている。「＃２」ノードからは、「特許」タグを先頭に持つ「＃４２」ノード、「＃５２」ノード、「＃６２」ノードへのリンクがそれぞれ張られている。
【００５５】
図３に示した「特許」情報は、「＃４２」ノード以下の部分ツリーに対応している。このノードからは「タイトル」タグ、「出願者」タグ、「要約」タグなどを先頭にもつノードへリンクが張られ、末端のノードからは、「ＸＭＬデータベース」、「Ｔ社」。「ＸＭＬを統一的に管理するデータベースを提供する…」などの文字列（要素値）へのリンクが張られている。
【００５６】
「＃５２」ノード以下の部分ツリー、「＃６２」ノード以下の部分ノードも１つの「特許」情報に対応する部分である。
【００５７】
ところで、例えば、「＃４３」ノードにリンクされた「ＸＭＬデータベース」という要素値は、「＃４３」ノードと「＃ｖａｌｕｅ」という特殊なタグ名で接続されている。このタグ名は、「＃」で始まるためＸＭＬ規格においては標準的なタグ名として利用することはできない。
【００５８】
このような構造化文書データベースの特定ノードを指定するために構造化文書パスを用いる。構造化文書パスは「ｕｉｘ：／／ｒｏｏｔ」から始まる文字列である。ｕｉｘ（Ｕｎｉｖｅｒｓａｌ Ｉｄｅｎｔｉｆｉｅｒ ｆｏｒ ＸＭＬ）は構造化文書パスであることを示す前置文字列である。
【００５９】
例えば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」は、「＃１」ノードから「特許ＤＢ」が付与されたアークが指し示すノード、つまり「＃２」ノードに対応する。このように「ｒｏｏｔ」から「／」で区切られた部分文字列をタグ名とみなすことで「＃０」ノードからタグ名の並びに沿って対応するアークを下っていき、その最後のアークが指すノードが、パスの場所を指し示す。
【００６０】
例えば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許」は、「＃４２」ノード、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／出願日／年」は、「＃４５」ノードを指し示す。
【００６１】
「＃２」ノード以下に、すなわち、「特許ＤＢ」に、複数の「特許」情報を格納する場合には、個々の「特許」情報を識別するために、構造化文書パスにインデックス表現が可能である。
【００６２】
「特許ＤＢ」の最初の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」となるが、これは「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許」と同じとみなす。
【００６３】
「特許ＤＢ」の２番目の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［１］ＤＢ」の５番目の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［４］」となる。
【００６４】
インデックス記憶部６には検索時に用いる、要素名称生起インデックスとデータ生起インデックスが記憶されている。
【００６５】
要素名生起インデックスとは構造化文書データベースに格納されている要素名称のリストと、各要素名称が先頭にある構造化文書（文書オブジェクトツリー）の位置とを関連付けてインデックスファイル化したものである。例えば、図８の構造化文書データベースのように、（「特許」情報に対応する）「特許」という要素名称が「＃４２」ノード以下の構造化文書、「＃５２」ノード以下の構造化文書、「＃６２」ノード以下の構造化文書に存在する場合、これらをインデックス化すると、図９に示すように、それらの親ノード、「＃２」ノードが、要素名称生起インデックスファイルに「特許」キーからのチェーンで格納される。
【００６６】
このように、親ノードでインデックス化すると、インデックスファイルを圧縮することができる。すなわち、親ノードでインデックス化すれば、子ノードが増大しようとも、親ノードで代用しているので、チェーンサイズは増大しない。これに対し、実ノードをインデックス化すれば「特許」情報の格納数の増大とともにチェーンサイズはそれに比例して増加してしまう。
【００６７】
データ生起インデックスとは、構造化文書データベースに格納されている文字列データのリストと各文字列データがある構造化文書（文書オブジェクトツリー）の位置とを関連付けてインデックスファイル化したものである。例えば、図８の構造化文書データベースのように、「ＸＭＬ」という文字列データ（および、「ＸＭＬ」という文字列を含む文字列）が「＃４３」ノード以下の構造化文書、「＃４９」ノード以下の構造化文書に存在する場合、これらをインデックス化すると、図１０に示すように、「＃４３」ノード、「＃４９」ノードが、データ生起インデックスファイルに「ＸＭＬ」キーからのチェーンで格納される。
【００６８】
なお、逆階層インデックスなど、その他のインデックスファイルを用いてもよい。逆階層インデックスとは、あるノードとその親ノードとの対応を格納したものである（あるノードからその親ノードを求めることができる）。
【００６９】
文書記憶部５中の論理的な指定エリアとは、ユーザにより構造化文書パスを用いて指定された文書の格納場所を指す。構造化文書パスは、ユーザにとって認識可能な表現である。
【００７０】
図１の説明に戻る。
【００７１】
データアクセス部４は、文書記憶部５をアクセスする基本インターフェイスの集合である。データアクセス部４は、文書オブジェクトツリー格納部４７、文書オブジェクトツリー削除部４８、文書オブジェクトツリー取得部４９、文書文字列取得部４４、パスから文書オブジェクトツリー取得部４５、文書パーサ部４６、合成文書作成部４７、インデックス更新部４８から構成される。
【００７２】
文書オブジェクトツリー格納部４１は、文書記憶部５中の物理的な指定エリアに文書オブジェクトツリーを格納する処理を行う。
【００７３】
文書オブジェクトツリー削除部４２は、文書記憶部５中の物理的な指定エリアに存在する文書オブジェクトツリーを削除する処理を行う。
【００７４】
文書オブジェクトツリー取得部４３は、文書記憶部５中の物理的な指定エリアに存在する文書オブジェクトツリーを取得する処理を行う。
【００７５】
文書文字列取得部４４は、文書オブジェクトツリーを構造化文書（ＸＭＬ文書）に変換する処理を行う。
【００７６】
パスから文書オブジェクトツリー取得部４５は、構造化文書パスを解析して文書記憶部５中の物理的なエリアを特定して、そのエリアに存在する文書オブジェクトツリーを取り出す処理を行う。
【００７７】
文書パーサ部４６は、ユーザにより入力された構造化文書を読み込んで構文解析して整合性の検査を行い、さらに文書構造定義データであるスキーマが存在すれば構造的に妥当かどうかの検証を行う。出力結果は文書オブジェクトツリーとなる。文書パーサは、通常、ｌｅｘ（ｌｅｘｉｃａｌ ａｎａｌｙｚｅｒ ｇｅｎｅｒａｔｏｒ）といったレキシカルアナライザ（字句解析を行い，トークンに分解する）とｙａｃｃ（ｙｅｔ ａｎｏｔｈｅｒ ｃｏｍｐｉｌｅｒ ｃｏｍｐｉｌｅｒ）といったパーサジェネレータを組み合わせて構築することができる。
【００７８】
合成文書作成部４７は、文書格納や文書削除などをする際に、スキーマに合致しているかどうか検査しなければならないが、この検査時に必要となるデータを作成して出力する。
【００７９】
インデックス更新部４８は、文書格納や文書削除などにより、構造化文書データベースの格納内容が更新されるたびに、図９、図１０に示した要素名称生起インデックスとデータ生起インデックスを更新する。
【００８０】
文書記憶部５中の物理的な指定エリアとは、ファイルオフセットやオブジェクトＩＤなどの構造化文書データベース内ではユニークな文書データの存在場所を指し示す内部データである。ユーザにとっては認識不能なデータである。
【００８１】
文書記憶部５中に格納された文書を検索する処理を行う。要求制御部１の要求受付部１１でユーザからの文書検索の要求が受け付けられると、検索要求処理部３には、要求受付部１１からクエリ言語で記述されたクエリ文書が入力する。そしてデータアクセス部４を通してインデックス記憶部６，文書記憶部５にアクセスし、検索要求に合致する文書集合を取得して、その結果を結果処理部１２を介して出力する。
【００８２】
図２は、図１に示した構造化文書管理システムの一利用形態を示したもので、図２では、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）のバックエンドで、図１に示した構成の構造化文書管理システム１００が動作している場合を示している。
【００８３】
複数（ここでは、例えば３つ）のクライアント端末（例えばパーソナルコンピュータ、携帯通信端末など）１０２のそれぞれでＷＷＷブラウザ１０３が動作している。ユーザは、各クライアント端末からＷＷＷサーバ１０１にアクセスすることにより、構造化文書管理システム１００にアクセスすることができる。ＷＷＷブラウザ１０３とＷＷＷサーバ１０１とは、ＨＴＴＰ（Ｈｙｐｅｒ ＴｅｘｔＴｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）で通信している。また、ＷＷＷサーバ１０１と構造化文書管理システム１００とは、ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）またはＣＯＭ（Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）などで通信している。
【００８４】
ユーザからの文書格納、文書取得、文書検索などの要求は、ＷＷＷブラウザ１０３から送信されて、ＷＷＷサーバ１０１を通して構造化文書管理システム１００にて受け付けられ、処理された結果は、ＷＷＷサーバ１０１を通して要求元のＷＷＷブラウザ１０３へ返信される。
【００８５】
以下、図１の構造化文書管理システムの（１）格納機能、（２）検索機能について詳細に説明する。そして、（３）適用例では、概念検索を用いた特許調査の場合を例にとり説明する。
【００８６】
（１） 格納機能
図１の構造化文書管理システムにおける格納系のコマンドには以下のものがある。
【００８７】
ｉｎｓｅｒｔＸＭＬ（パス、Ｎ番目、ＸＭＬ）：文書格納
ａｐｐｅｎｄＸＭＬ（パス、ＸＭＬ） ：文書格納
ｇｅｔＸＭＬ（パス） ：文書取得
ｒｅｍｏｖｅＸＭＬ（パス） ：文書削除
ｓｅｔＳｃｈｅｍａ（パス、スキーマ） ：スキーマ格納
ｇｅｔＳｃｈｅｍａ（パス） ：スキーマ取得
「ｉｎｓｅｒｔＸＭＬ」は、（ ）内に指定した構造化文書パス以下のＮ番目に文書を挿入するコマンド（以下、簡単に挿入コマンドと呼ぶ）である。
【００８８】
「ａｐｐｅｎｄＸＭＬ」は、（ ）内に指定した構造化文書パス以下の最後に文書を挿入するコマンド（以下、簡単に追加コマンドと呼ぶ）である。
【００８９】
「ｇｅｔＸＭＬ」は、（ ）内に指定した構造化文書パス以下の文書を取り出すコマンド（以下、簡単に取得コマンドと呼ぶ）である。
【００９０】
「ｒｅｍｏｖｅＸＭＬ」は、（ ）内に指定した構造化文書パス以下の文書（スキーマ文書以外の文書で、主に、コンテンツ文書）を削除するコマンド（以下、簡単に削除コマンドと呼ぶ）である。
【００９１】
「ｓｅｔＳｃｈｅｍａ」は、（ ）内に指定した構造化文書パスにスキーマを設定するコマンド（以下、簡単にスキーマ格納コマンドと呼ぶ）である。
【００９２】
「ｇｅｔＳｃｈｅｍａ」は、（ ）内に指定した構造化文書パスに設定されているスキーマを取り出すコマンド（以下、簡単にスキーマ取得コマンドと呼ぶ）である。
【００９３】
上記コマンドのうち、挿入コマンド、追加コマンド、スキーマ格納コマンドについての処理はアクセス要求処理部２の文書格納部２１で実行され、取得コマンド、スキーマ取得コマンドについての処理は文書取得部２２で実行され、削除コマンドについての処理は文書削除部２３で実行される。
【００９４】
図５を参照して、構造化文書データベースの初期状態（図５（ａ）参照）において、追加コマンドを実行する場合について説明する。
【００９５】
図５（ａ）に示すように、「＃０」ノードと「＃１」ノードが「ｒｏｏｔ」アークで接続されている初期状態に対して、
「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」
を実行した結果、図５（ｂ）に示すように、「＃２」ノードと「特許ＤＢ」アークが作成される。
【００９６】
図５（ｂ）に示した状態の構造化文書データベースに対して、取得コマンドを実行する場合について説明する。
【００９７】
例えば、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”）」を実行すると、図５（ｂ）の「ｒｏｏｔ」アークが示す「＃０」ノード以下の文書オブジェクトツリーが取り出され、それをＸＭＬの文字列表現に変換する。その結果、図６に示すように、「＜ｒｏｏｔ＞＜特許ＤＢ／＞＜／ｒｏｏｔ＞」なる文字列が取り出される。取得コマンドの処理は、アクセス要求処理部２の文書取得部２２にて実行される。
【００９８】
次に、図５（ｂ）に示した状態の構造化文書データベースに対して、図３に示すようなコンテンツ文書（ＸＭＬ文書）としての「特許」情報を格納するための追加コマンドを実行する場合について説明する。すなわち、この場合、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」を実行する。このコマンド中「“＜特許＞…＜／特許＞”」が、図３に示した「特許」情報に対応する。
【００９９】
上記追加コマンドの処理が実行されると、図７に示すように、「＃２」ノード以下に「＃４２」ノードをトップとする文書オブジェクトツリー（図４に対応）が追加される。
【０１００】
図５（ｂ）に示した状態の構造化文書データベースに対して、次に示すような追加コマンドを３回繰り返して実行したとする。
【０１０１】
「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」
上記コマンド中、「＜特許＞…＜／特許＞」は、図３に示した文書構造のコンテンツ文書に対応する。
【０１０２】
すると、図８に示すように、「＃２」ノード以下に「＃４２」ノード、「＃５２」ノード、「＃６２」ノードをトップとする文書オブジェクトツリーが追加される。
【０１０３】
次に、図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合について説明する。この場合、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」を実行する。すると、「特許ＤＢ」アークが示す「＃２」ノード以下の文書オブジェクトツリーが取り出され、それをＸＭＬの文字列表現（ＸＭＬ文書）に変換する。その結果、図１１に示すように、「＜特許ＤＢ＞＜特許＞…＜／特許＞＜特許＞…＜／特許＞＜特許＞…＜／特許＞＜／特許ＤＢ＞」なる文字列が取り出される。
【０１０４】
構造化文書データベースでは、上記の「特許」情報などのコンテンツ文書（ＸＭＬ文書）の文書構造を定義したデータ、すなわち、スキーマも管理対象とする。
【０１０５】
図１２は、ＸＭＬ文書の文書構造を定義するスキーマの一例を示したものである。ここでは、ＸＭＬの文書構造定義言語の一つであるＸＤＲ（ＸＭＬ−Ｄａｔａ Ｒｅｄｕｃｅｄ）を取り上げる。もちろん、ＸＭＬ−Ｓｃｈｅｍａなど他の文書構造定義言語を用いてもかまわない。
【０１０６】
図１２に示したスキーマは、図３に示した「特許」情報の文書構造をＸＤＲで定義したものである。図１２からも容易に分かるとおり、スキーマもＸＭＬ形式の構造化文書である。「Ｓｃｈｅｍａ」タグから始まる構成要素から始まり、その子要素として、「ＥｌｅｍｅｎｔＴｙｐｅ」タグから始まる要素集合が存在する。
【０１０７】
図１２に示したスキーマにおいて、例えば、最初の「ＥｌｅｍｅｎｔＴｙｐｅ」タグから始まる子要素は以下の情報を意味している。
【０１０８】
・「特許」タグを持つ要素の文書構造定義（「ＥｌｅｍｅｎｔＴｙｐｅ ｎａｍｅ＝”特許”」）である。
【０１０９】
・子要素は要素だけ（「ｃｏｎｔｅｎｔ＝”ｅｌｔＯｎｌｙ”」）である。
【０１１０】
・「タイトル」、「出願日」、「要約」タグから始まる子要素から構成される（「ｅｌｅｍｅｎｔ ｔｙｐｅ＝”タイトル”、…」）。さらに、その順番は一意に決まっている（「ｏｒｄｅｒ＝”ｓｅｑ”」）。
【０１１１】
・上記「特許」タグから始まる要素の文書構造定義の他に、「タイトル」「出願者」「要約」「年」「月」「日」「出願日」の文書構造定義を記述している。すなわち、「出願日」を除く、「タイトル」「出願者」「要約」「年」「月」「日」タグから始まる構成要素の子要素はテキストだけと定義されている（「ｃｏｎｔｅｎｔ＝”ｔｅｘｔＯｎｌｙ”」）。
【０１１２】
・「出願日」タグから始まる構成要素の子要素は、「年」、「月」、「日」の並びである。
【０１１３】
図８に示した状態の構造化文書データベースに対して、図１２に示したスキーマ文書を格納するためのスキーマ格納コマンドを実行する場合について説明する。この場合、「ｓｅｔＳｃｈｅｍａ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”）」を実行する。このコマンド中、「“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”」」が図１２に示したスキーマ文書に対応する。
【０１１４】
上記コマンドの実行により、図１３に示すように、「＃２」ノード以下に「＃ｓｃｈｅｍａ」アークが追加され、その先には、「＃３」ノードをトップノードとする文書オブジェクトツリーが追加される。スキーマ自身がＸＭＬ文書表現になっているため、前述した「特許」情報のようなコンテンツ文書格納のケースと同様にツリー展開可能である。
【０１１５】
図１３において、「＠ｎａｍｅ」など「＠」で始まるアークは属性に対応する。タグ名「＃ｓｃｈｅｍａ」も「＃」、「＠」で始まるためＸＭＬ規格においては標準的なタグ名として利用することはできない。
【０１１６】
「＃２」ノード下に図１２に示したスキーマ文書が格納されたことにより、以後、「＃２」ノード以下にこれから格納される文書の文書構造は、図１２に示したスキーマ文書により定義された文書構造に適合することが要求される。すなわち、「＃２」ノード以下に図１２に示したスキーマが設定されることになる。
【０１１７】
「＃２」ノード以下に図１２に示したスキーマが設定されると、図１４に示すように、「＃２」ノードの文書オブジェクトのファイルには、「＃２」ノード以下の文書オブジェクトツリーには、当該スキーマが存在する旨の属性値がセットされる。
【０１１８】
「＃２」ノード以下に図１２に示したスキーマが設定された後に、このスキーマで定義された文書構造に一致する図３に示したような「特許」情報を、図１４に示したように、文書オブジェクトツリーとして構造化文書データベースに格納したとき、この文書の文書構造には図１２に示したスキーマが存在する旨の属性値が、当該文書オブジェクトツリーを構成する各文書オブジェクトにセットされる。例えば、当該文書オブジェクトツリーを構成する各文書オブジェクトのファイルに対して、スキーマが存在している旨の属性値（例えば、「スキーマ適合有無」）に「１」がセットされる。図１４では、スキーマに適合している各文書オブジェクト（ノード）は２重丸で示している。２重丸で示した各文書オブジェクトには、その文書オブジェクトに対応した文書構造定義が存在することになる。
【０１１９】
図１５は、各文書オブジェクトのファイルの内容を概念的に示したもので、例えば、オブジェクトＩＤが「＃４２」の文書オブジェクトのファイルには、その文書オブジェクトにリンクされている他の文書オブジェクトに関する情報（例えば、アークや、リンク先の文書オブジェクトへのポインタ値など）とともに、上記属性値が記述されている。なお、当該文書オブジェクトに適用するスキーマが存在しないときは、「スキーマ適合有無」の値は「０」となる。
【０１２０】
図１６、図１７は、図１の構造化文書管理システムで、必要に応じて検索で使用される概念階層を構造化文書で表現した例を示す。図１６、図１７に示す「概念」情報はＸＭＬで記述したコンテンツ文書である。
【０１２１】
図１６に示した「概念」情報の例は、いわゆる特許調査における特許文書の内容を分類するための１つの分類軸として用いる「情報モデル」を概念階層で表現している。「概念」タグで囲まれた「概念」情報は、入れ子構造を持った文書構造をもっている。つまり、図１６の例では、概念「情報モデル」の子供概念として、概念「ドキュメント」、概念「リレーション」、概念「オブジェクト」が存在している。また、概念「ドキュメント」の子供概念として、概念「構造化訴求メント」、概念「非構造化ドキュメント」が存在し、さらに、概念「構造化ドキュメント」の子供概念として、概念「ＸＭＬ」、概念「ＳＧＭＬ」が存在している。
【０１２２】
図１７に示す「概念」情報の記述例は、図１６とは異なる分類軸「情報操作」を概念階層で表現している。図１７の例では、概念「情報操作」の子供概念として、概念「検索」、概念「格納」、概念「加工」、概念「流通」が存在している。
【０１２３】
図１６，図１７に示したような「概念」情報も、前述の「特許」情報と同様にして、構造化文書データベース内に格納することができる。すなわち、例えば、まず、図８に示した状態の構造化文書データベースに対して、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜概念ＤＢ／＞”）」を実行して、図１８に示すように、「＃２０１」ノードと「概念ＤＢ」アークが作成される。この状態において、図１６に示した「概念」情報を格納する場合には、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／概念ＤＢ”，“＜概念名前＞…＜／概念＞”）」を実行する。このコマンド中「“＜概念名前＞…＜／概念＞”」が、図１６に示した「概念」情報に対応する。
【０１２４】
上記追加コマンドの処理が実行されると、図１９に示すように、「＃２０１」ノード以下に「＃２０２」ノードをトップとする文書オブジェクトツリーが追加される。
【０１２５】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。そのため、部分的なＸＭＬ文書をアクセスするには巨大なＸＭＬ文書に対するパスという文書構造に依存しない統一的なアクセス手段を用いることにより、幅広くＸＭＬ文書を検索したり加工したりすることが可能になる。
【０１２６】
また、構造化文書データベース上の一部にスキーマを設定することで、格納しようとする文書の文書構造がそのスキーマにより定義されている文書構造に一致するか否かの妥当性のチェックが自動的に行なえる（後述）。
【０１２７】
（１−１）文書格納処理
次に、図１の構造化文書管理システムの文書格納処理動作について、図２０に示すフローチャートを参照して説明する。
【０１２８】
クライアント端末から構造化文書管理システムに対し、文書格納要求として、挿入コマンド、追加コマンド、スキーマ格納コマンドのうちのいずれかが送信されて、要求受付部１１にて受け付けられたとき、図２０に示した処理動作を行う。
【０１２９】
クライアント端末の所定の表示装置には、構造化文書管理システム１００（の例えば、要求制御部１）から提供された、例えば、図３１に示すようなユーザインターフェイスとしての画面が表示されている。
【０１３０】
図３１に示す画面には、構造化文書管理システム１００への操作項目の一覧（メニュー）が表示されている。操作項目として、「ＸＭＬ登録／削除」、「スキーマ設定」、「ＸＭＬ検索」とがある。
【０１３１】
ユーザが例えば、この画面上で「ＸＭＬ登録／削除」をマウス等のポインティングデバイスなどを用いて選択すると、図３２に示したような文書の格納／削除を行うためのユーザインタフェースとしての画面が表示される。
【０１３２】
図３２において、領域Ｗ１には、文書構造化文書データベースの現在のツリー構造の要素名（タグ名）がユーザが理解可能なように簡略的に表示されている。なお、図３２では、上位階層の要素名のみを表示しているが、末端の要素名まで表示可能である。また、領域Ｗ２は、構造化文書パスの入力領域であり、領域Ｗ１の表示内容に従って、構造化文書パスを入力するようになっている。また、領域Ｗ３は、格納する文書を入力したり、取得した文書を表示するようになっている。
【０１３３】
例えば、構造化文書パスとして「ｒｏｏｔ」を入力する場合には、領域Ｗ１の「ｒｏｏｔ」をマウス等で選択すればよい。すると、図３２に示すように、領域Ｗ２の構造化文書パスの入力領域に「ｕｉｘ：／／ｒｏｏｔ」と表示される。また、新たに、「特許ＤＢ」という要素を追加する場合は、図３２に示すように、領域Ｗ３に、「特許ＤＢ」を入力する。そして、「登録」ボタンＢ１を選択すると、クライアント端末からａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」なる追加コマンドが構造化文書管理システムへ送信される。構造化文書管理システムでは、上記追加コマンドを受け、後述するような処理を実行した結果、例えば、図５（ｂ）に示すように、「＃２」ノードと「特許ＤＢ」アークが作成される。また、領域Ｗ１には、図３３に示すように、「ｒｏｏｔ」の下に「特許ＤＢ」が追加表示される。
【０１３４】
さて、ユーザが図３４に示したような文書の格納／削除画面上の領域Ｗ３に、例えば、文書「＜Ａ＞データ＜／Ａ＞」を入力し（あるいはＣＤ−ＲＯＭ等の所定の記録媒体等から読み込むことにより入力し）、領域Ｗ１の「特許［０］」をマウス等で選択すると、構造化文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」と表示される。そして、「登録」ボタンＢ１を選択すると、クライアント端末からａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０１３５】
ここでは、例えば、構造化文書データベースが、図１４に示した状態のときに、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］”，“＜Ａ＞データ＜／Ａ＞”）」なる追加コマンドを受け付けた場合を例にとり説明する。
【０１３６】
要求受付部１１は、上記追加コマンドを受け付けると、上記追加コマンド中の２つのパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」と文書「＜Ａ＞データ＜／Ａ＞」（以下、格納文書と呼ぶ）とを文書格納部２１へ渡す（ステップＳ１）。
【０１３７】
まず、文書格納部２１は、文書パーサ部４６に格納文書を渡す。文書パーサ部４６は、格納文書を読み込んで、構文解析を行い、当該格納文書の文書構造がＸＭＬにて規定された正しい形式であるか否かの整合性の検査を行う（ステップＳ２）。
【０１３８】
この整合性の検査でエラーが見つかれば（ステップＳ３）、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す（ステップＳ４）。
【０１３９】
整合性の検査でエラーが見つからなければ、次に、文書格納部２１は、パスから文書オブジェクトツリー取得部４５へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部４５は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ０）を含む文書オブジェクトツリーを取り出す（ステップＳ５）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ０のオブジェクトＩＤを取得することができるので（ステップＳ６）、その場合は、ステップＳ８へ進む。
【０１４０】
例えば、上記追加コマンドの場合、「＃４２」ノードが文書オブジェクトＯｘ０となるので、そのオブジェクトＩＤとして、「＃４２」を取得するとともに、この「＃４２」ノードを含む文書オブジェクトツリー（例えば、「＃４２」ノードの全ての子孫ノードと「＃４２」ノードと同じ階層にある全ての（兄弟）ノードと、「＃４２」ノードの親ノードである「＃２」ノードとからなる文書オブジェクトツリー）を取得する。
【０１４１】
指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ０が見つからなければ、エラーとなり（ステップＳ６）、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す（ステップＳ７）。
【０１４２】
例えば、構造化文書データベースが、図１８に示した状態のときに、追加コマンドのパラメータとして、構造化文書パスが「ｕｉｘ：／／ｒｏｏｔ／その他」と表されていたとき、これに対応する文書オブジェクトは存在しないので、ステップＳ６でエラーとなり、ステップＳ７へ進む。
【０１４３】
次に、ステップＳ８では、文書オブジェクトＯｘ０にスキーマが存在するか否かを検査する。この検査は、前述したように、各文書オブジェクトのファイルに属性値が記述されているので、この値をチェックすればよい。文書オブジェクトＯｘ０のもつ「スキーマ属性有無」の値が「１」のときは、ステップＳ９へ進む。
【０１４４】
以下、図２０のステップＳ９の処理（合成文書作成部４７の処理）について、図２１に示すフローチャートを参照して詳細に説明する。
【０１４５】
文書格納部２１は、ステップＳ５で取得した文書オブジェクトツリーを合成文書作成部４７へ渡す。
【０１４６】
合成文書作成部４７は、この文書オブジェクトツリーを文書オブジェクトＯｘ０から遡り、「Ｓｃｈｅｍａ」タグを子要素として持つ文書オブジェクトＯｘ１を検索する（ステップＳ２１）。
【０１４７】
例えば、図１４に示した構造化文書データベースでは、文書オブジェクトＯｘ０としての「＃４２」ノードの親ノードである「＃２」ノードから「Ｓｃｈｅｍａ」タグをトップ（先頭）にもつノード（「＃３」ノード）へのリンクが張られているので（「Ｓｃｈｅｍａ」タグを子要素として持つので）、この「＃２」ノードが文書オブジェクトＯｘ１となる。よって、ステップＳ２２をスキップして、ステップＳ２３へ進む。
【０１４８】
この文書オブジェクトＯｘ１から文書オブジェクトＯｘ０、さらに文書オブジェクトＯｘ０からアークを辿って、その下流にある、文書オブジェクトの属性値の値が「１」である全ての子ノードからなる文書オブジェクトツリーＯｔ１を取り出す（ステップＳ２３）。
【０１４９】
例えば、上記追加コマンド中のパラメータの構造化文書パスが「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」と指定されているとき、文書オブジェクトツリーＯｔ１は、「＃４２」ノード〜「＃４９」ノードから構成されたものとなる（図１４参照）。
【０１５０】
次に、ステップＳ２５へ進む。
【０１５１】
ステップＳ２５では、文書オブジェクトツリーＯｔ１に格納文書の文書オブジェクトツリーを文書オブジェクトＯｘ０の子ノードとして挿入する。その結果得られた新たな文書オブジェクトツリーを文書オブジェクトツリーＯｔ２とする。
【０１５２】
この文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換し、それをテンポラリファイルＡに出力する（ステップＳ２７）。
【０１５３】
例えば、上記追加コマンド中のパラメータの格納文書「＜Ａ＞データ＜／Ａ＞」の文書オブジェクトツリー（この場合は、１つの文書オブジェクト）を「＃４２」ノード〜「＃４９」ノードで構成された文書オブジェクトツリーＯｔ１に「＃４２」ノードの子ノードとして挿入して得られた合成文書の文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換した結果を図２２に示す。この合成文書は、もともとある「特許」情報に「＜Ａ＞データ＜／Ａ＞」というデータを追加したものとなっている。
【０１５４】
図２２に示したＸＭＬ文書、すなわち、合成文書がテンポラリファイルＡに出力され、テンポラリファイルＡに一時格納される。
【０１５５】
一方、スキーマタグ以下の文書オブジェクトツリーＯｔ３をＸＭＬ文書に変換して、それをテンポラリファイルＢに出力する（ステップＳ２８）。すなわち、テンポラリファイルＢには、スキーマ文書が一時格納されることになる。
【０１５６】
例えば、文書オブジェクトツリーＯｔ３である「＃３」ノードをトップノードとする文書オブジェクトツリーをＸＭＬ文書に変換した結果を図２３に示す。図２３に示したＸＭＬ文書がテンポラリファイルＢに出力され、テンポラリファイルＢに一時格納される。
【０１５７】
図２２に示すように、テンポラリファイルＡ（「ｔｍｐ０００．ｘｍｌ」）には、もともとある「特許」情報の要素の他に、格納文書、すなわち、ここでは、例えば、「＜Ａ＞データ＜／Ａ＞」が挿入されている。また、「ｘｍｌｎｓ＝”ｘ−ｓｃｈｅｍａ：ｔｍｐ００１．ｘｍｌ”」という、テンポラリファイルＢ（「ｔｍｐ００１．ｘｍｌ」）へのリンク情報の記述がある。この記述は、「特許」情報に適用されるスキーマが出力されているテンポラリファイルＢを指定している。
【０１５８】
次に、図２０の説明に戻る。
【０１５９】
ステップＳ１０では、文書格納部２１は文書パーサ部４６に、合成文書のテンポラリファイルＡとスキーマのテンポラリファイルＢとを与えて、合成文書の文書構造の妥当性をチェックする。すなわち、文書パーサ部４６は、合成文書のテンポラリファイルＡとスキーマのテンポラリファイルＢとを読み込み、合成文書の文書構造が、スキーマにより定義されている文書構造に一致するか否かをチェックする。
【０１６０】
例えば、図２２に示した合成文書と、図２３に示したスキーマとで妥当性のチェックを行った場合、合成文書には、スキーマにより定義されていない「Ａ」という要素が存在するため、図２３の合成文書は、妥当性のチェックでエラーとなる（ステップＳ１１）。この場合、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す（ステップＳ１２）。
【０１６１】
例えば、クライアント端末の所定の表示装置には、図３５に示すようなメッセージが表示される。
【０１６２】
次に、構造化文書データベースが、図１４に示した状態のときに、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドを受け付けた場合について、図２０を参照して説明する。前述同様にして、文書オブジェクトＯｘ０のオブジェクトＩＤ「＃２」を取得する（ステップＳ５）、この文書オブジェクトには、スキーマが存在するので（ステップＳ８）、ステップＳ９において合成文書を作成する。
【０１６３】
この場合、文書オブジェクトＯｘ０である「＃２」ノード自体から「Ｓｃｈｅｍａ」タグをトップ（先頭）にもつノード（「＃３」ノード）へのリンクが張られているので、この「＃２」ノードが文書オブジェクトＯｘ１となる（図２１のステップＳ２１）。すなわち、文書オブジェクトＯｘ０と文書オブジェクトＯｘ１が同じなので（ステップＳ２２）、ステップＳ２９へ進み、格納文書「＜特許＞…＜／特許＞」の文書オブジェクトツリーをＸＭＬ文書に変換し、テンポラリファイルＡに出力する（ステップＳ２９）。
【０１６４】
例えば、図２４に示すように、テンポラリファイルＡ（「ｔｍｐ０００．ｘｍｌ」）には、格納文書である「特許」情報、すなわち、ここでは、「＜特許＞…＜／特許＞」が出力されている。また、「ｘｍｌｎｓ＝”ｘ−ｓｃｈｅｍａ：ｔｍｐ００１．ｘｍｌ”」という、テンポラリファイルＢ（「ｔｍｐ００１．ｘｍｌ」）へのリンク情報の記述がある。
【０１６５】
次に、ステップＳ２８へ進む。図２５に示すように、テンポラリファイルＢには、「＃３」ノードをトップノードとするスキーマの文書オブジェクトツリーをＸＭＬ文書に変換した結果が出力されている。
【０１６６】
図２０のステップＳ１０で、図２４に示した合成文書と、図２５に示したスキーマとで妥当性のチェックを行ったとき、合成文書の文書構造と、スキーマにより定義されている文書構造とは一致する、この場合、ステップＳ１１からステップＳ１３へ進む。
【０１６７】
ステップＳ１３では、格納文書の文書オブジェクトツリーが、文書オブジェクトＯｘ０下に追加される。すなわち、文書格納部２１により、格納文書の文書オブジェクトツリーを構成する各文書オブジェクト（のファイル）にオブジェクトＩＤが与えられ、文書オブジェクトＯｘ０から格納文書の文書オブジェクトツリーの先頭の文書オブジェクトへリンクが張られる。そして、文書オブジェクトツリー格納部４１により、格納文書の文書オブジェクトツリーを構成する各文書オブジェクト（のファイル）が文書記憶部５に格納される。
【０１６８】
次に、ステップＳ１４へ進み、インデックス記憶部６のインデックスを更新する。
【０１６９】
なお、ステップＳ８で、文書オブジェクトＯｘ０のもつ属性値の値が「０」のときは、上述したスキーマを用いた合成文書の文書構造の妥当性のチェックを行わずに、そのままマステップＳ１３へ進み、格納文書の文書オブジェクトツリーを、文書オブジェクトＯｘ０下に追加し（ステップＳ１３）、それに伴い、インデックス記憶部６のインデックスを更新する（ステップＳ１４）。
【０１７０】
（１−２）文書取得処理
次に、図１の構造化文書管理システムの文書取得処理動作について、図２６に示すフローチャートを参照して説明する。
【０１７１】
クライアント端末から構造化文書管理システムに対し、文書取得要求として、取得コマンド、スキーマ取得コマンドのうちのいずれかが送信されて、要求受付部１１にて受け付けられたとき、図２６に示した処理動作を行う。
【０１７２】
例えば、ユーザが図３６に示したような文書の格納／削除画面上の領域Ｗ１の「特許ＤＢ」をマウス等で選択すると（クリックすると）、構造化文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」と表示されとともに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」なる取得コマンドが構造化文書管理システムへ送信される。
【０１７３】
ここでは、例えば、構造化文書データベースが、図８に示した状態のときに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」なる取得コマンドを受け付けた場合を例にとり説明する。
【０１７４】
要求受付部１１は、上記取得コマンドを受け付けると、上記取得コマンド中のパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」を文書取得部２２へ渡す（ステップＳ３１）。
【０１７５】
文書取得部２２は、パスから文書オブジェクトツリー取得部４５へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部４５は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ５）を取り出す（ステップＳ３２）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ５のオブジェクトＩＤを取得することができるので（ステップＳ３３）、その場合は、ステップＳ３５へ進む。
【０１７６】
例えば、上記取得コマンドの場合、「＃２」ノードが文書オブジェクトＯｘ５となるので、そのオブジェクトＩＤとして、「＃２」を取得するとともに、この「＃２」ノード以下の文書オブジェクトツリーＯｔ５（「＃２」ノード、「＃４２」ノード〜「＃４９」ノード、「＃５２」ノード以下、「＃６２」ノード以下）を取得する（ステップＳ３５）。
【０１７７】
ステップＳ３２において、指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ５が見つからなければ、エラーとなり（ステップＳ３３）、文書取得部２２，結果処理部１２を介して、クライアント端末に「文書取得失敗」の旨のメッセージを返す（ステップＳ３４）。
【０１７８】
ステップＳ３５で取得した文書オブジェクトツリーＯｔ５は、文書文字列取得部４４でＸＭＬ文書に変換される。例えば、上記取得コマンドの場合、取得したＸＭＬ文書は、図１１に示すような３つの「特許」情報のＸＭＬ文書となる。
【０１７９】
文書取得部２２は、結果処理部１２を介して、図１１に示したようなＸＭＬ文書を（例えば、ＸＳＬ（ｅＸｔｅｎｓｉｂｌｅ Ｓｔｙｌｅ Ｌａｎｇｕａｇｅ）といった所定のスタイルシートとともに）、クライアント端末へ返す（ステップＳ３７）。
【０１８０】
クライアント端末では、図１１に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図３６に示すように、領域Ｗ２に表示する。
【０１８１】
ＸＳＬを利用すると、ＸＭＬ文書を様々な形に変換することが出来る。違う構文書造のＸＭＬ文書に変換することも出来るし、ＸＭＬ文書からＨＴＭＬページを生成することも出来る。
【０１８２】
（１−３）文書削除処理
次に、図１の構造化文書管理システムの文書削除処理動作について、図２７に示すフローチャートを参照して説明する。
【０１８３】
クライアント端末から構造化文書管理システムに対し、文書削除要求として、削除コマンドが送信されて、要求受付部１１にて受け付けられたとき、図２７に示した処理動作を行う。
【０１８４】
例えば、ユーザが図３６に示したような文書の格納／削除画面上の領域Ｗ１の「特許ＤＢ」をマウス等で選択すると（クリックすると）、構造化文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」と表示され、さらに、「削除」ボタンＢ２を選択すると「ｒｅｍｏｖｅＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」なる削除コマンドが構造化文書管理システムへ送信される。
【０１８５】
ここでは、例えば、構造化文書データベースが、図１４に示した状態のときに、「ｒｅｍｏｖｅＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日”）」なる削除コマンドを受け付けた場合を例にとり説明する。
【０１８６】
要求受付部１１は、上記削除コマンドを受け付けると、上記削除コマンド中のパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日」を文書削除部２３へ渡す（ステップＳ４１）。
【０１８７】
次に、文書削除部２３は、パスから文書オブジェクトツリー取得部４５へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部４５は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ０）を含む文書オブジェクトツリーを取り出す（ステップＳ４２）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ０のオブジェクトＩＤを取得することができるので（ステップＳ４３）、その場合は、ステップＳ４５へ進む。
【０１８８】
例えば、上記削除コマンドの場合、「＃４４」ノードが文書オブジェクトＯｘ０となるので、そのオブジェクトＩＤとして、「＃４４」を取得するとともに、この「＃４４」ノードを含む文書オブジェクトツリー（例えば、「＃４４」ノードの全ての子孫ノードと「＃４４」ノードと同じ階層にある全ての（兄弟）ノードと、「＃４４」ノードの親ノードである「＃４２」ノード、その親ノードである「＃２」ノードとからなる文書オブジェクトツリー）を取得する。
【０１８９】
指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ０が見つからなければ、エラーとなり（ステップＳ４３）、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書削除失敗」の旨のメッセージを返す（ステップＳ４４）。
【０１９０】
次に、ステップＳ４５では、文書オブジェクトＯｘ０にスキーマが存在するか否かを検査する。この検査は、前述したように、各文書オブジェクトのファイルに属性値が記述されているので、この値をチェックすればよい。文書オブジェクトＯｘ０のもつ属性値の値が「１」のときは、ステップＳ４６へ進む。
【０１９１】
以下、図２７のステップＳ４６の処理（合成文書作成部４７の処理（削除コマンド用））について、図２８に示すフローチャートを参照して詳細に説明する。
【０１９２】
なお、図２８において、図２１と同一部分は同一符号を付している。
【０１９３】
文書格納部２１は、ステップＳ４２で取得した文書オブジェクトツリーを合成文書作成部４７へ渡す。
【０１９４】
合成文書作成部４７は、この文書オブジェクトツリーを文書オブジェクトＯｘ０から遡り、「Ｓｃｈｅｍａ」タグを子要素として持つ文書オブジェクトＯｘ１を検索する（ステップＳ２１）。
【０１９５】
例えば、図１４に示した構造化文書データベースでは、文書オブジェクトＯｘ０としての「＃４４」ノードの上流にある「＃２」ノードから「Ｓｃｈｅｍａ」タグをトップ（先頭）にもつノード（「＃３」ノード）へのリンクが張られているので（「Ｓｃｈｅｍａ」タグを子要素として持つので）、この「＃２」ノードが文書オブジェクトＯｘ１となる。
【０１９６】
この文書オブジェクトＯｘ１から文書オブジェクトＯｘ０、さらに文書オブジェクトＯｘ０からアークを辿って、その下流にある、文書オブジェクトの属性値の値が「１」である全ての子ノードからなる文書オブジェクトツリーＯｔ１を取り出す（ステップＳ２３）。
【０１９７】
例えば、上記追加コマンド中のパラメータの構造化文書パスが「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日」と指定されているとき、文書オブジェクトツリーＯｔ１は、「＃４２」ノード〜「＃４９」ノードから構成されたものとなる（図１４参照）。
【０１９８】
次に、ステップＳ２６ヘ進み、文書オブジェクトツリーＯｔ１から文書オブジェクトＯｘ０以下の文書オブジェクトツリーを削除する。その結果得られた新たな文書オブジェクトツリーを文書オブジェクトツリーＯｔ２とする。
【０１９９】
この文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換し、それをテンポラリファイルＡに出力する（ステップＳ２７）。
【０２００】
例えば、上記削除コマンド中のパラメータの構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日」が指し示す「＃４４」ノード以下の文書オブジェクトツリーを「＃４２」ノード〜「＃４９」ノードで構成された文書オブジェクトツリーＯｔ１から削除することにより得られた合成文書の文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換した結果を図２９に示す。この合成文書は、もともとある「特許」情報から「＜出願日＞…＜／出願日＞」というデータを削除したものとなっている。
【０２０１】
図２９に示したＸＭＬ文書、すなわち、合成文書がテンポラリファイルＡに出力され、テンポラリファイルＡに一時格納される。
【０２０２】
一方、スキーマタグ以下の文書オブジェクトツリーＯｔ３をＸＭＬ文書に変換して、それをテンポラリファイルＢに出力する（ステップＳ２８）。すなわち、テンポラリファイルＢには、スキーマ文書が一時格納されることになる。
【０２０３】
例えば、文書オブジェクトツリーＯｔ３である「＃３」ノードをトップノードとする文書オブジェクトツリーをＸＭＬ文書に変換した結果を図３０に示す。図３０に示したＸＭＬ文書がテンポラリファイルＢに出力され、テンポラリファイルＢに一時格納される。
【０２０４】
次に、図２７の説明に戻る。
【０２０５】
ステップＳ４７では、文書削除部２１は文書パーサ部４６に、合成文書のテンポラリファイルＡとスキーマのテンポラリファイルＢとを与えて、文書格納処理の場合と同様にして、合成文書の文書構造の妥当性をチェックする。
【０２０６】
例えば、図２９に示した合成文書と、図３０に示したスキーマとで妥当性のチェックを行った場合、合成文書には、スキーマにより定義されている「出願日」という要素が存在しないため、図２９の合成文書は、妥当性のチェックでエラーとなる（ステップＳ４８）。この場合、文書削除部２１，結果処理部１２を介して、クライアント端末に「文書削除失敗」の旨のメッセージを返す（ステップＳ４９）。
【０２０７】
なお、構造化文書データベースが、図１４に示した状態のときに、「ｒｅｍｏｖｅＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］”）」なる削除コマンドを、図２７に従って処理を行うと、図２８のステップＳ２７において、図２４に示したような合成文書がテンポラリファイルＡに出力される。テンポラリファイルＢは、図３０と同様である。
【０２０８】
このとき、図２４に示した合成文書と、図３０に示したスキーマとで妥当性のチェックを行った場合、合成文書の文書構造と、スキーマにより定義されている文書構造とは一致するので、ステップＳ４８からステップＳ５０へ進む。
【０２０９】
ステップＳ５０では、文書オブジェクトＯｘ０以下の文書オブジェクトツリーを削除する。すなわち、文書オブジェクトツリー削除部４２により、文書オブジェクトＯｘ０以下の文書オブジェクトツリーを構成する各文書オブジェクト（のファイル）が文書記憶部５から削除される。例えば、「＃２」ノードから「＃４２」ノード以下の文書オブジェクトのファイルが削除される。
【０２１０】
次に、ステップＳ５１へ進み、インデックス記憶部６のインデックスを更新する。また、クライアント端末の図３６に示したような表示画面の領域Ｗ１には、「特許［０］」が表示さなくなる。
【０２１１】
なお、ステップＳ４５で、文書オブジェクトＯｘ０のもつ属性値の値が「０」のときは、上述したスキーマを用いた合成文書の文書構造の妥当性のチェックを行わずに、そのままマステップＳ５０へ進み、文書オブジェクトＯｘ０以下の文書オブジェクトツリーを削除し（ステップＳ５０）、それに伴う、インデックス記憶部６のインデックスを更新する（ステップＳ５１）。
【０２１２】
（１−４）スキーマの設定、スキーマを用いた文書格納
図３１に示した画面上で、ユーザが「Ｓｃｈｅｍａ設定Ｗｉｎ」をマウス等のポインティングデバイスなどを用いて選択すると、図３７に示したようなスキーマの設定を行うためのユーザインタフェースとしての画面が表示される。
【０２１３】
ユーザが、領域Ｗ３に、例えば、図１２に示したような「特許」情報のスキーマを入力し、この入力したスキーマを「特許ＤＢ」以下のノードに設定する場合には、領域Ｗ１から「特許ＤＢ」をマウス等でクリックして選択した後（領域Ｗ２には、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される）、「スキーマ設定」ボタンＢ３を選択する。すると、「ｓｅｔＳｃｈｅｍａ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”）」なるスキーマ格納コマンドが構造化文書管理システムへ送信される。このコマンドの処理は前述した文書格納処理動作と同様である。
【０２１４】
次に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」の下に「特許」情報を格納しようとするとき、「特許ＤＢ」以下のノードに既に設定されているスキーマを用いて「特許」情報を入力する場合について説明する。
【０２１５】
まず、スキーマを取得する。例えば、図３８に示すような文書の格納／削除を行うための画面の領域Ｗ１から「スキーマ」をマウス等を用いて選択すると、文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／＃Ｓｃｈｅｍａ」と表示されとともに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／Ｓｃｈｅｍａ”）」なるスキーマ取得コマンドが構造化文書管理システムへ送信される。
【０２１６】
このコマンドの処理は、前述した文書取得処理と同様である。構造化文書管理システムから返されるＸＭＬ文書は、図３８の画面の領域Ｗ３に表示される。
【０２１７】
図３８に示すように、領域Ｒ３には、「特許」情報のデータ入力領域が各要素毎に設定されて表示されている。この表示に従って、ユーザは、データを入力すればよい。例えば、「タイトル」、「年」などのデータ入力領域が階層的に配置され、表示されている。ユーザは、このデータ入力領域にデータを入力することで、スキーマにより定義された文書構造の格納文書が容易に作成することができる。
【０２１８】
また、領域Ｗ３に入力した「特許」情報の格納先として、領域Ｗ１で「特許ＤＢ」をマウス等を用いて選択すると、領域Ｗ２に構造化文書パスとして、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される。その後、「登録」ボタンＢ１を選択すると、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０２１９】
この場合、格納文書は、予めスキーマに従って入力されたものなので、図２０のステップＳ１０の妥当性チェックでエラーとなることはない。
【０２２０】
（２）検索機能
図１の構造化文書管理システムにおける検索系のコマンドには以下のものがある。
【０２２１】
ｑｕｅｒｙ（ｑｌ）
「ｑｕｅｒｙ」は、パラメータとして（ ）内のクエリｑｌを実行し、その結果のＸＭＬ文書を取得するコマンド（以下、検索コマンドと呼ぶ）である。
【０２２２】
クエリは、図３９に示すように、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ ＱｕｅｒｙＬａｎｇｕａｇｅ）に似た形式の言語により、検索位置、検索条件、情報抽出部分などを記述した、構造化されたＸＭＬ文書である。クエリ文書も構造化文書管理システムの管理対象である。
【０２２３】
「ｋｆ：ｆｒｏｍ」タグから始まる要素には、検索位置の指定と文書要素の値に変数を対応付ける記述があり、「ｋｆ：ｗｈｅｒｅ」タグのから始める要素には、変数に関する条件づけの記述があり、「ｋｆ：ｓｅｌｅｃｔ」タグから始まる要素には、検索結果の出力形式が記述される。
【０２２４】
検索には、単純検索と概念検索とがある。単純検索とは、クエリ中に指定された検索条件を満たす情報を検索・抽出するものであり、概念検索とは、クエリ中に指定された概念情報を利用して、クエリ中に指定された検索条件を満たす情報を検索・抽出するものである。
【０２２５】
図４０は、単純検索のクエリの例を示したものである。図４０のクエリは、例えば、図１４に示したような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群において、「１９９９年でかつ、「ＰＣ」のような内容の「要約」という要素をもつ文書（「特許」情報）の「タイトル」を列挙せよ」という検索要求を意味している。
【０２２６】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」、「＄ｙ」、「＄ｓ」に、それぞれ「特許」情報の「タイトル」、「年」、「要約」という文書要素の値が代入される。
【０２２７】
「ｋｆ：ｗｈｅｒｅ」タグから始める要素の記述により、変数「＄ｙ」＝「１９９９」という比較がなされる。また、コンポーネント「ＭｙＬｉｋｅ」は変数「＄ｓ」と「ＰＣ」を引数として、「ＰＣ」と類似する値の変数「＄ｓ」を検知するための関数である。
【０２２８】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」が出力値として利用される。
【０２２９】
なお、「ｋｆ：ｓｔａｒ」タグは構造の曖昧表現であり、例えば「＜特許＞＜ｋｆ：ｓｔａｒ＞＜年＞」は「タグ名が「特許」である要素の子孫の要素としていずれかに存在し、タグ名が「年」である要素」を意味する。
【０２３０】
図４１に図４０の単純検索のクエリを用いた検索結果を示す。この検索結果もＸＭＬ文書である。
【０２３１】
図４２は、概念検索のクエリの例を示したものである。図４２のクエリは、例えば図１８，図１９に示すような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群に対し、「概念ＤＢ」アークが示すノード以下に格納されている「概念」情報を利用して検索するための検索要求である。ここで、概念「周辺装置」の値をもつタグの子要素の値には、概念「ＳＣＳＩ」、「メモリ」、「ＨＤＤ」などがあるものとする。また、図１８には示していないが、各「特許」情報の構成要素には、「キーワード」タグから始める要素も存在するものとする。
【０２３２】
すなわち、図４２のクエリは、「概念「周辺装置」以下の概念のいずれかを「キーワード」という要素の値にもつ文書（「特許」情報）の「タイトル」を列挙せよ」という検索要求を意味している。
【０２３３】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」、変数「＄ｋ」に、それぞれ、「特許」情報の「タイトル」、「キーワード」という要素の値が代入される。また、変数「＄ｘ」は「概念」情報として「周辺装置」の値をもつタグの子要素の値（「ＳＣＳＩ」、「メモリ」、「ＨＤＤ」など）が代入される。
【０２３４】
「ｋｆ：ｗｈｅｒｅ」タグから始める要素の記述により、「＄ｋ」＝「周辺装置」もしくは「＄ｋ」＝「＄ｘ」という比較がなされる。
【０２３５】
次に、図１の構造化文書管理システムの文書検索処理動作について、図４３に示すフローチャートを参照して説明する。
【０２３６】
図３１に示した画面上で、ユーザが「ＸＭＬ検索Ｗｉｎ」をマウス等のポインティングデバイスなどを用いて選択すると、図４４に示すような文書検索を行うためのユーザインタフェースとしての画面が表示される。
【０２３７】
図４４の検索画面において、領域Ｗ１には、前述同様、構造化文書データベースの現在のツリー構造の要素名（タグ名）がユーザが理解可能なように簡略的に表示されてている。
【０２３８】
領域Ｗ２は、検索対象の範囲（ツリー構造上の検索範囲）や、検索条件などを入力するための領域である。領域Ｗ３には、検索結果が表示される。
【０２３９】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「文書」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という検索要求の場合には、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、トップノードとして、「特許」を入力する（この場合、領域Ｗ１から「特許」をマウス等で選択することにより入力してもよい）。また、検索条件として、「「タイトル」という要素の値に「文書」という文字列を含む」「「年」という要素の値が「１９９８」以上である」という内容を予め設定されたデータ入力領域に入力すればよい。
【０２４０】
その後、「検索」ボタンＢ２１を選択することにより、例えば、図４５に示すようなクエリが、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。クエリの格納場所は、予め定められており、システム側が自動的に、この追加コマンドのパラメータを設定することとなる。例えば、構造化文書データベースが図１８に示した状態のとき、当該クエリの格納場所を表すパラメータとしての構造化文書パスは、「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」となる。また、追加コマンドのもう一方のパラメータは、当該クエリ文書である。
【０２４１】
要求受付部１１は、上記クエリを受け付けると（ステップＳ１０１）、当該クエリを検索要求処理部３へ渡す。そして、当該クエリ文書を格納するための追加コマンドのパラメータを文書格納部２１へ渡す。この追加コマンドの処理を、前述同様に行って、当該クエリは、文書記憶部５に格納される。
【０２４２】
例えば、図４２に示すようなクエリの場合、構造化文書データベースには、図４６に示すように展開されて、構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」の示す「＃３０１」ノード以下にリンクされる。
【０２４３】
一方、検索要求処理部３では、受け取ったクエリを基に、データアクセス部４を通してインデックス記憶部６，文書記憶部５にアクセスし、検索要求に合致する文書集合などを取得して、クエリの中で要求された情報を抽出して結果処理部１２を介して出力する。
【０２４４】
例えば、上記クエリの場合、まず、「「タイトル」タグに「文書」という文字列を含む」という条件に合致するものを検索することが検索対象を絞り込む上で効率がよい。そこで、図１０に示したようなデータ生起インデックスを用いて、「文書」という文字列にリンクされているノード（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを上流側に１つ遡り、「タイトル」というタグ名にたどり着いたときは、更に上流に辿っていき、「特許」というタグ名にたどり着いたときは、そのノード以下の文書オブジェクトツリーＯｔ１１を抽出する。
【０２４５】
次に、この抽出された複数の文書オブジェクトツリーＯｔ１１の中から、さらに、「年」という要素の値が「１９９８」年以上の文書オブジェクトツリーＯｔ１２を抽出する。
【０２４６】
この文書オブジェクトツリーＯｔ１２が上記クエリの内容に適合する文書となる。さらに上記クエリの要求内容に従えば、各文書オブジェクトツリーＯｔ１２のトップノードへの構造化文書パスを求める（ステップＳ１０２）。
【０２４７】
なお、上記検索処理は、上記した方法に限るものではなく、インデックス情報を用いた様々な効率のよい検索方法が可能である。
【０２４８】
検索要求処理部３は、ステップＳ１０２で得られた結果を統合して、検索結果としてのＸＭＬ文書を作成する（ステップＳ１０３）。
【０２４９】
例えば、検索結果のＸＭＬ文書は、

となる。
【０２５０】
検索要求処理部３は、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す（ステップＳ１０４）。
【０２５１】
クライアント端末では、図１１に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図４４に示すように、領域Ｗ１２に表示する。
【０２５２】
同様にして、スキーマの検索も行える。
【０２５３】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「ｓｃｈｅｍａ」を先頭タグに持つ文書の中から、「特許」と「要約」というタグ名を持つスキーマを検索せよ」という検索要求の場合には、図４７に示すように、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、トップノードとして、「＃ｓｃｈｅｍａ」を入力する。また、検索条件として、「要素の属性名に「特許」という文字列を含む」「要素の属性名に「要約」という文字列を含む」という内容を予め設定されたデータ入力領域に入力すればよい。
【０２５４】
その後、「検索」ボタンＢ２１を選択することにより、上記検索要求を記述したクエリ（図４８参照）が、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。
【０２５５】
さて、上記クエリの場合、例えば、「「＃ｓｃｈｅｍａ」を先頭タグに持つ」という条件に合致するものを検索する。そこで、図９に示したような要素名称生起インデックスを用いて、「＃ｓｃｈｅｍａ」という要素にリンクされているノードの（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、属性名が「特許」と「要約」いう要素にたどり着いたときは、当該「＃ｓｃｈｅｍａ」を先頭タグにもつ文書オブジェクトツリーＯｔ２１を抽出する。この文書オブジェクトツリーＯｔ２１が上記クエリの内容に適合する文書となる。さらに、図４８に示したクエリの要求内容に従えば、各文書オブジェクトツリーＯｔ２１のトップノードへの構造化文書パスを求める。
【０２５６】
検索要求処理部３は、文書オブジェクトツリーＯｔ２１が複数あれば、それぞれのトップノードへの構造化文書パスをまとめて、検索結果としてのＸＭＬ文書を作成し、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す。
【０２５７】
クライアント端末では、検索結果として受け取ったＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図４４に示すように、領域Ｗ１２に表示する。
【０２５８】
クライアント端末では、検索結果の中の１つのスキーマを選択して、表示させると、例えば、図３８に示すような文書の格納／削除を行うための画面とともに、その領域Ｗ３に、「特許」情報のデータ入力領域が各要素毎に設定されて表示される。
【０２５９】
ユーザは、このデータ入力領域にデータを入力することで、スキーマにより定義された文書構造の格納文書が容易に作成することができる。
【０２６０】
例えば、図３８の領域Ｗ３に入力した「特許」情報の格納先として、領域Ｗ１で「特許ＤＢ」をマウス等を用いて選択すると、領域Ｗ２に構造化文書パスとして、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される。その後、「登録」ボタンＢ１を選択すると、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０２６１】
この場合、格納文書は、予めスキーマに従って入力されたものなので、図２０のステップＳ１０の妥当性チェックでエラーとなることはない。
【０２６２】
同様にして、クエリの検索も行える。クエリを検索して、検索結果として得られた既存のクエリを加工して、再利用することもできる（クエリの再利用）。
【０２６３】
クエリの検索は、前述したような構造化文書の検索と同様にして行われ、その検索範囲は、クエリ群の格納されている構造化データベース上の一部の文書オブジェクトツリーとなる。
【０２６４】
例えば、図１８に示したような状態の構造化文書データベースから、「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリを検索する場合について説明する。そのような検索要求を記述したクエリを図４９に示す。
【０２６５】
図４９に示すクエリは、「「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」の示す「＃３０１」ノード以下に存在するクエリの中から「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリを検索し、その内容（タグ名が「ｑｕｅｒｙ」である要素以下の文書オブジェクトツリーの文書）を列挙せよ」を意味するものである。
【０２６６】
なお、「ｋｆ：ａｓ」タグの内容で変数「＄ｅｌｔ」に、「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリのタグ名が「ｑｕｅｒｙ」である要素以下の文書オブジェクトツリーが代入される。
【０２６７】
このクエリを検索要求処理部３が処理する際には、前述同様にして、例えば、図９に示したような要素名称生起インデックスを用いて、「ｋｆ：ｆｒｏｍ」という要素にリンクされているノードの（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、「特許」というタグ名にたどり着いたときは、さらに、上流側にアークを辿って「ｑｕｅｒｙ」というタグ名に辿りついたとき、当該「ｑｕｅｒｙ」を先頭タグにもつ文書オブジェクトツリーＯｔ３１を抽出する。この文書オブジェクトツリーＯｔ３１が上記クエリの内容に適合する文書となる。
【０２６８】
複数の文書オブジェクトツリーＯｔ３１が検索されたら、それらを統合して、ＸＭＬ文書を作成して、それをスタイルシートとともにクライアント端末へ返す。
【０２６９】
クライアント端末では、検索結果の中の１つのクエリを選択して、表示させると、例えば、図４４に示した検索画面の領域Ｗ１１に、各データ入力領域にデータの入力された状態で、当該クエリに記述された検索要求の内容が表示される。
【０２７０】
ユーザは、この状態から、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「文書」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という当該クエリに記述された検索要求中の「文書」を「ＸＭＬ」に変更して、「検索」ボタンＢ２１を選択すれば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「ＸＭＬ」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という意味のクエリが構造化文書管理システムへ送信される。
【０２７１】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。従って、文書構造が異なる、様々なスキーマを持つ膨大な数の文書の中から検索条件に合致する文書を容易に検索できる。
【０２７２】
また、検索に用いるクエリも構造化文書であるので、構造化文書データベースにログとして格納することにより、過去のクエリを再利用するようなアプリケーションも容易に構築することができる。
【０２７３】
（３）適用例
次に、上記概念検索の特許調査への適用例について説明する。
【０２７４】
図５０は、特許調査における構造化文書データベースの一例であり、「特許」情報の他に、「概念」情報も格納している。
【０２７５】
特許調査において、最も重要となってくる作業は、関連する「特許」情報を収集し、「特許」情報を様々な観点から分析し、特許マップ（図５４参照）を作成することである。特許マップを作成するために、従来、特許マップにおける縦軸、横軸を予め決定し、それに従い、縦軸に並ぶ任意の項目と横軸に並ぶ任意の項目とを検索条件とした検索を逐次行うという方法がとられ、この部分に非常に莫大なコストがかかっていた。しかし、構造化文書管理システムを用いることで、この部分のコストを大幅に減少させることが可能となる。
【０２７６】
なお、ここで、マップとは、縦軸（ｙ軸）に並ぶ任意の項目と横軸（ｘ軸）に並ぶ任意の項目とを検索条件とした検索結果をｘ軸とｙ軸とを分類軸として分類整理するものである。
【０２７７】
構造化文書管理システムで、クライアント端末のユーザが図５４に示すような特許マップを作成しようとする場合、ユーザは、クライアント端末上の表示装置に表示される図５０に示すような構造化文書データベースの現在のツリー構造を参照して、図５１に示すような検索画面上に、分析対象の範囲とする「特許」情報のパスと、分析の軸（例えば、ｘ軸、ｙ軸）となる要素を、それぞれ領域Ｗ２１、Ｗ２２に入力する。分析の軸となる要素は、構造化文書データベース内の「特許」情報の要素、「概念」情報の要素のいずれであってもよい。
【０２７８】
例えば、図５１では、ｘ軸に「機能」、ｙ軸に「技術」という「概念」情報の要素を入力している。
【０２７９】
その後、ユーザは、「実行」ボタンＢ３１を選択すると、クライアント端末から図１の構造化文書管理システムへ、図５２に示したようなクエリが送出される。
【０２８０】
この場合のクエリには、「「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群の中から、「概念ＤＢ」アークが示すノード以下に格納されている、概念「機能」の子要素のいずれかと概念「技術」の子要素のいずれかとを、「キーワード」や「要約」などの要素の値に含む「特許」情報を検索せよ。検索結果として、「機能」の子要素と「技術」の子要素と、それらに対応する「特許」情報の「公開番号」との組を列挙せよ。」という意味の検索要求である。
【０２８１】
概念「機能」には、「検索」「格納」…「分析支援」という子要素があり、概念「技術」には、「実装データベース」「反構造データベース」「自然言語処理」…という子要素があるものとする。
【０２８２】
上記クエリを受けた構造化文書検索システムの検索要求処理部３では、例えば、図１０に示したようなデータ生起インデックスを用いて、概念「機能」の各子要素（文字列）にリンクされているノード（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを上流側に遡り、「特許」というタグにたどり着いたときは、さらに、そのノード以下の文書オブジェクトツリーを下流側に辿って概念「技術」の子要素（文字列）のいずれかにリンクされているタグ名にたどり着いたときは、当該文書オブジェクトツリーと、その「公開番号」タグにリンクされている文字列（要素値）を抽出する。このようにして、抽出された「特許」情報のそれぞれについて、対応の「機能」の子要素と「技術」の子要素と「公開番号」との組を統合して、図５３に示すような検索結果としてのＸＭＬ文書を作成、要求元のクライアント端末へ、所定のスタイルシートとともに返す。
【０２８３】
これらを受け取ったクライアント端末の表示装置には、図５４に示したような表形式の特許マップが表示されることになる。
【０２８４】
このように、所望の概念を「軸」として指定するだけで、構造化文書データベースに蓄積された情報を「軸」として指定された概念に基づき集計・分類して、マップ表示するこたが容易に行える。すなわち、構造化文書データベースに蓄積された情報を、「概念」情報を用いて様々な観点で集計・分類することが容易に行える。
【０２８５】
（本発明の実施の形態の説明）
以下、本発明の実施形態について図面を参照して説明する。
【０２８６】
ここでは、上記構造化文書データベース上でＯＬＡＰを実現するための手法について説明する。ここでは、例えば、概念検索の適用例として説明する。
【０２８７】
図５５は、構造化文書データベースの論理構造を模式的に示したもので、「論文」情報、「概念」情報が格納されている状態を示したものである。すなわち、「論文」情報は、「論文群」ノード以下に格納され、「概念」情報は、「概念ツリー」ノード以下に格納されている。
【０２８８】
図５６は、ＸＭＬで記述された構造化文書の一例として、上記「論文」情報の例を示したものである。
【０２８９】
図５６に示した文書は、「論文」タグから始める要素をルートとし、その子要素として、「報告番号」「書誌名」「報告年月日」「タイトル」「報告者一覧」「要約」「キーワード群」タグから始める要素集合が存在する。また、「報告年月日」「報告者一覧」「キーワード群」タグから始める各要素には、それぞれ子要素が存在する。
【０２９０】
図５６に示した構造化文書は、図５５に示したように論理的に展開されて（文書オブジェクトツリーに展開されて）、構造化文書データベース上に格納されている。
【０２９１】
図５７は、図５５に示した「概念ツリー」ノード以下の「概念」情報の文書オブジェクトツリーに対応するＸＭＬ文書である。
【０２９２】
例えば、図５７に示したようなＸＭＬ文書が構造化文書データベース上に格納されると、図５５に示したように、文書オブジェクトツリーに展開される。
【０２９３】
図５５に示すように、「概念」情報は、「機能」と「技術」とに大分類される概念項目を階層的に分類したもので、例えば、「機能」という概念項目は「格納機能」と「検索機能」という概念項目を包含し、「格納機能」は「文書格納機能」と「テーブル格納機能」という概念項目を包含し、さらに、「文書格納機能」は「文書格納」という概念項目を包含するといった概念の分類構造を表したものである。このような「概念」情報の分類構造をなす各構成要素（すなわち、各概念項目）は、構造化文書データベースの構成要素としてと管理されている。
【０２９４】
なお、図５５に示す構造化文書データベースには、クエリが「クエリ群」ノード以下に予め格納されている。構造化文書データベースに格納されている各クエリは、そのそれぞれを識別するための識別情報（クエリＩＤ）をもつ。構造化文書データベースに格納されているクエリは、その個々のクエリを識別するために構造化パスにインデックス表現を用いているものとする。そこで、ここでは、各クエリＩＤは、各クエリへの構造化文書パスとする。
【０２９５】
ここでは、検索条件としての構造化文書を構成する各構成要素を表すタグ（要素名）と、そのタグの値をパラメータ化したクエリを用いて検索を行い、その結果をスタイルシートを用いて、マップとして、検索条件として用いたタグに対応させて分類表示する。検索結果はマップとして表示されるが、このマップは、画面遷移が関連付けられている領域を有している。画面遷移が関連付けられている領域には、予めクエリＩＤと、そのクエリのパラメータが関連付けられている。ユーザがその領域を指示することで、この関連付けられたクエリＩＤと、パラメータとが構造化文書管理システムへ送信される。構造化文書管理システムでは、当該クエリＩＤで特定されるクエリに当該パラメータを設定（代入）して、そのクエリ用いて検索を行い、その結果と所定のスタイルシートとをクライアント端末に送り返す、クライアント端末では、受け取った検索結果をスタイルシートを用いてマップ表示することで、画面遷移が行われる。
【０２９６】
このように、本発明によれば、検索結果を分類表示する画面から、その分類表示をさらに詳細に分類表示した検索結果の画面へと、検索という明示的な操作を行う必要なく画面遷移が容易に行える。
【０２９７】
図５５に示すような状態の構造化文書データベースに対し、「論文」情報の文書群の中から、概念「機能」の子要素のいずれかと、概念「技術」の子要素のいずれかに該当する論文の検索を行って（具体的には、例えば、「論文」情報の構成要素である「キーワード」に、概念「機能」の子要素のいずれかと、概念「技術」の子要素のいずれかを含む「論文」情報の検索を行う）、概念「機能」の子要素と概念「技術」の子要素と検索結果の論文とを対応付けたマップ表示する場合について説明する。
【０２９８】
この場合、上記マップは、検索結果を分類表示するための分析軸としてｘ軸、ｙ軸に概念「機能」の子要素と概念「技術」の子要素のそれぞれを分類項目として並べたテーブル形式となる。
【０２９９】
構造化文書管理システムでクライアント端末のユーザが上記マップを作成しようとする場合、ユーザは、クライアント端末上の表示装置に表示される図５５に示すような構造化文書データベースの現在のツリー構造を参照して、図５８に示すような検索画面上に、分析の軸（ｘ軸、ｙ軸）となる要素を入力する。なお、ここでは、説明の簡単のため、図５８に示す画面は、検索対象の範囲が「概念ツリー」ノード以下の「論文」情報である場合の検索画面とする。
【０３００】
図５８に示すように、ｘ軸には、「論文」情報のキーワードが存在する要素を表すタグ名として、「キーワード群／キーワード」を入力し、さらに、ｘ軸に割り当てる分類項目の概念「機能」を入力する。また、ｙ軸には、「論文」情報のキーワードが存在する要素を表すタグ名として、「キーワード群／キーワード」を入力し、さらに、ｙ軸に割り当てる分類項目の概念「技術」を入力する。その後、ユーザが「マップ生成」ボタンを例えばマウスクリックすると、構造化文書管理システムに対し検索要求がなされる。
【０３０１】
以下、図５９に従って、図６９に示すフローチャートを参照しながら、構造化文書管理システムとクライアント端末との間の処理動作について説明する。なお、図６９は、構造化文書管理システムの処理動作を説明するためのフローチャートである。
【０３０２】
さて、図５８に示した検索画面上の「マップ生成」ボタンをマウスクリックすると（ステップＳ２０１）、クエリＩＤ「Ｑｉｄ０」と、パラメータとを含む検索要求が構造化文書管理システムへ送信される（ステップＳ２０２）。
【０３０３】
ここで、クエリＩＤ「Ｑｉｄ０」は、構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／クエリ群／クエリ［０］」である。パラメータは、（パラメータ１、パラメータ２，パラメータ３，パラメータ４）という４つのパラメータからなり、ｘ軸上の検索条件は、パラメータ１とパラメータ２に、ｙ軸上の検索条件は、パラメータ３とパラメータ４に対応する。パラメータ１はｘ軸で用いる検索対象のタグ名「キーワード群／キーワード」であり、パラメータ２はｘ軸で用いる概念「機能」である。パラメータ３はｙ軸で用いる検索対象のタグ名「キーワード群／キーワード」であり、パラメータ４はｙ軸で用いる概念「技術」である。
【０３０４】
上記検索要求は構造化文書管理システムの要求受付部１１にて受け付けられ（図６９のステップＳ２２１）、当該検索要求は、検索要求処理部３で処理される。
【０３０５】
検索要求処理部３は、クエリＩＤ「Ｑｉｄ０」に対応するクエリを構造化文書データベースから獲得する（ステップＳ２０３、図６９のステップＳ２２２）。すなわち、クエリＩＤ「Ｑｉｄ０」は、ここでは、構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／クエリ群／クエリ［０］」に対応するので、図５５に示す構造化文書データベースから当該クエリＩＤ（構造化文書パス）にて特定されるクエリを取得し、このクエリに、検索要求として送信されてきたパラメータを設定し（図６９のステップＳ２２３）、このパラメータの設定されたクエリを用いて、構造化文書データベース中の「論文群」ノード以下に格納されている文書の中から、概念「機能」の子要素のいずれかと、概念「技術」の子要素のいずれかが、タグ名「キーワード」の要素値に含まれる「論文」情報の検索を行う（ステップＳ２０４、図６９のステップＳ２２４）。
【０３０６】
図６０は、クエリＩＤ「Ｑｉｄ０」のクエリを示したものである。
【０３０７】
このクエリの引数は４つあり、順に、「＄ｔａｇ１」にはｘ軸で用いるタグ名、「＄ｃａｔｅｇｏｒｙ１」はｘ軸で用いる概念、「＄ｔａｇ２」はｙ軸で用いるタグ名、「＄ｃａｔｅｇｏｒｙ２」はｙ軸で用いる概念を意味する。
【０３０８】
まず「ｈｅａｄ」タグで囲まれた部分で上記変数にパラメータとして与えられた値が設定される。すなわち、「＄ｔａｇ１」、「＄ｔａｇ２」には、「キーワード群／キーワード」が設定され、「＄ｃａｔｅｇｏｒｙ１」、「＄ｃａｔｅｇｏｒｙ２」には、「機能」、「技術」がそれぞれ設定される。
【０３０９】
「ｋｆ：ｆｒｏｍ」タグで囲まれた部分には、「ｕｉｘ：／／ｒｏｏｔ／論文群」以下に格納されている「論文」情報にある要素「キーワード」の値が、概念「機能」の各子要素と、概念「技術」の各子要素との値と一致すること」という検索条件が記述されている。この記述により、概念「機能」の各子要素は、変数「＄ｓｕｂ１」に代入され、概念「技術」の各子要素は、変数変数「＄ｓｕｂ２」に代入され、これら２つの変数と全ての「論文」情報中の「キーワード」の要素値とが比較され、上記検索条件を満たす「論文」情報が抽出されるようになっている。
【０３１０】
「ｒｅｓｕｌｔ」タグで囲まれた部分の記述により、検索中に「ｋｆ：ｆｒｏｍ」タグで囲まれた部分に記述された検索条件を満たす「論文」情報が抽出されたとき、変数「＄ｓｕｂ１」と「＄ｓｕｂ２」の値別に、その検索条件を満たした「論文」情報の件数をカウントして集計結果を求めるになっている。また、この記述は、変数「＄ｓｕｂ１」と「＄ｓｕｂ２」の値別の集計結果として、そのカウント値と変数「＄ｓｕｂ１」の値と変数「＄ｓｕｂ２」の値とを、集計分の個数だけ出力することを意味する。
【０３１１】
「ｋｆ：ｆｒｏｍ」タグで囲まれた部分は３つ存在する。１番目の「ｋｆ：ｆｒｏｍ」タグで囲まれた部分は、パス「ｕｉｘ：／／ｒｏｏｔ／論文群」の直下にある「論文」情報の直下のタグ「＄ｔａｇ１」（この場合、検索要求として送られてきたパラメータ１のタグ）の値を変数「＄ｋｅｙｗｏｒｄ１」に代入し、さらに該「論文」情報の直下のタグ「＄ｔａｇ２」（この場合、検索要求として送られてきたパラメータ３のタグ）の値を変数「＄ｋｅｙｗｏｒｄ２」に代入することを意味する。
【０３１２】
２番目の「ｋｆ：ｆｒｏｍ」タグで囲まれた部分は、パス「ｕｉｘ：／／ｒｏｏｔ／概念ツリー」の子孫で、「ｎａｍｅ」属性の値が「＄ｃａｔｅｇｏｒｙ１」である「概念」タグ（この場合、検索要求として送られてきたパラメータ２の「機能」）の直下にある「概念」タグで、かつ該「概念」タグの子孫で「ｎａｍｅ」属性の値が「＄ｋｅｙｗｏｒｄ１」と等しい「概念」タグをもつ、該「概念」タグの「ｎａｍｅ」属性の値を変数「＄ｓｕｂ１」に代入することを意味する。
【０３１３】
３番目の「ｋｆ：ｆｒｏｍ」タグで囲まれた部分は、パス「ｕｉｘ：／／ｒｏｏｔ／概念ツリー」の子孫で、「ｎａｍｅ」属性の値が「＄ｃａｔｅｇｏｒｙ２」である「概念」タグ（この場合、検索要求として送られてきたパラメータ４の「機能」）の直下にある「概念」タグで、かつ該「概念」タグの子孫で「ｎａｍｅ」属性の値が該「ｋｅｙｗｏｒｄ２」と等しい「概念」タグをもつ、該「概念」タグの「ｎａｍｅ」属性の値を変数「＄ｓｕｂ２」に代入することを意味する。
【０３１４】
「ｋｆ：ｓｅｌｅｃｔ」タグで囲まれた部分では、上記代入して得られた変数「＄ｓｕｂ１」の値と変数「＄ｓｕｂ２」の値を、それぞれｘ軸のメイン概念「機能」のサブ概念、ｙ軸のメイン概念「技術」のサブ概念とみなして、それぞれ「Ｘ」タグと「Ｙ」タグに設定し、変数「＄ｓｕｂ１」と変数「＄ｓｕｂ２」の値別の集計結果を「件数」タグの値に設定することを意味する。
【０３１５】
「ｋｆ：ｇｒｏｕｐＢｙ」タグにより、変数「＄ｓｕｂ１」と変数「＄ｓｕｂ２」の値別に処理することを意味する。
【０３１６】
図６０に示したクエリに基づく実際の検索処理は、前述同様にして、図９に示した要素名称生起インデックスや図１０に示したデータ生起インデックスを用いて行ってもよいが、ここでは、構造化文書データベースに格納されている全ての「論文」情報の１つ１つについて、「「キーワード」タグに概念「機能」のサブ概念の「格納機能」（および、概念「格納機能」の子孫概念）あるいは「検索機能」（および概念「検索機能」の子孫概念）という文字列を含む」という条件に合致するもの、および、「「キーワード」タグに概念「技術」のサブ概念である「データベース技術」あるいは「自然言語技術」あるいは「知識処理技術」いう文字列を含む」という条件に合致するものを検索する。
【０３１７】
上記２つの条件を満たす「論文」情報の件数を、ｘ軸上のサブ概念とｙ軸上のサブ概念とに対応付けた検索集計結果とする。
【０３１８】
図６１は、上記のようにして、構造化文書データベースに対し検索を行って得られた検索結果としてのＸＭＬ文書である。
【０３１９】
図６１において、「ｒｅｓｕｌｔ」タグで囲まれた部分は、ｘ軸に並べられる概念「機能」のサブ概念のうちの１つと、ｙ軸に並べられる概念「技術」のサブ概念のうちの１つと、それらを検索条件に用いて「論文」情報を検索集計した結果である「件数」との記述である。概念「機能」のサブ概念が２つ、概念「技術」のサブ概念が３つあるので、この「ｒｅｓｕｌｔ」タグで囲まれた部分は、全部で６つ存在する。
【０３２０】
さて、図５９の説明に戻り、検索結果を得たら、次に、クエリＩＤ「Ｑｉｄ０」に対応するスタイルシートを獲得する（ステップＳ２０５、図６９のステップＳ２２５）。
【０３２１】
スタイルシートはクエリＩＤにて特定されるクエリ対応の検索結果の表示スタイルを定義した記述文書で、これもやはり構造化文書であり、構造化文書データベースの管理対象である。また、スタイルシートは、例えば、ＸＳＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｓｔｙｌｅ Ｌａｎｇｕａｇｅ）などにて記述されている。
【０３２２】
スタイルシートは、構造化文書データベースに格納されているので、スタイルＩＤは、クエリＩＤと同様、当該スタイルシートの格納されている論理的なエリア表す構造化文書パスで表されているのが好ましい。検索要求処理部３は、図５５に示す構造化文書データベースから当該スタイルＩＤ（構造化文書パス）にて特定されるスタイルシートを取得する。
【０３２３】
検索要求処理部３は、予め図６２に示すようなクエリＩＤとスタイルシートとを対応付けたテーブルを記憶している。なお、個々のスタイルシートはスタイルＩＤにて区別されているものとし、図６２では、クエリＩＤとスタイルＩＤとの対応関係を示している。ステップＳ２０５では、図６２に示したテーブルから、受け取ったクエリＩＤに対応するスタイルシートを獲得し、図６１に示したような検索結果としてのＸＭＬ文書と、当該獲得したスタイルシートとを要求元のクライアント端末へ送り返す（ステップＳ２０６、図６９のステップＳ２２６）。
【０３２４】
スタイルシートを用いることで、図６１に示す検索結果のＸＭＬ文書は、クライアント端末において、例えば、図６３（ａ）に示すようにマトリックス形式のマップとして表示される（ステップＳ２０７）。
【０３２５】
図６３（ａ）に示すマップは、ｘ軸上に概念「機能」のサブ概念である「格納機能」「検索機能」を並べ、ｙ軸上に概念「技術」のサブ概念である「データベース技術」「自然言語技術」「知識処理技術」を並べてマトリックを構成し、ｘ軸上のあるサブ概念とｙ軸上のあるサブ概念との交点にある要素に、それらを検索条件に用いて「論文」情報を検索集計した結果である「件数」の値が表示されている。
【０３２６】
ここでは、説明の便宜上、マップのマトリックスを構成する各要素を、図６３（ｂ）に示すように、要素（ｘ、ｙ）と座標表現する。なお、ここでは、ｘ＝１，２，３、ｙ＝１，２，３，４である。
【０３２７】
図６１に示す検索結果のＸＭＬ文書を図６３（ａ）に示すようにマップを表示する際には、クエリＩＤ「Ｑｉｄ０」に対応付けられたスタイルシートの記述により、マップのマトリックス構成中の各要素には、図６４に示すように、クエリＩＤと、そのクエリＩＤにて特定されるクエリに設定されるパラメータとを関連付けるようになっている。
【０３２８】
図６１に示した検索結果のＸＭＬ文書において、「ｈｅａｄ」タグで囲まれた部分で、次の画面遷移を行う際に用いるクエリＩＤ、パラメータであって、マップのマトリックス構成中の各要素に関連付けるクエリＩＤや、パラメータが定義されている。ユーザが、図６３（ａ）に示したマップ上のこれらが関連付けられている要素をマウスクリック等したとき、画面遷移を行うべく、その要素に関連付けられたクエリＩＤ、パラメータが検索要求として、構造化文書管理システムへ送出される。
【０３２９】
図６１において、「ＸＴＡＧ」タグ、「ＸＶＡＬ」タグにて、次の画面遷移の最に用いる、ｘ軸上の検索条件に用いるパラメータであって、検索対象のタグ名「キーワード群／キーワード」と概念「機能」が定義されている。
【０３３０】
「ＹＴＡＧ」タグ、「ＹＶＡＬ」タグにて、次の画面遷移の際に用いる、ｙ軸上の検索条件に用いるパラメータであって、検索対象のタグ名「キーワード群／キーワード」と概念「技術」が定義されている。
【０３３１】
「ＱＩＤ１」タグ、「ＱＩＤ２」タグにて、次の画面遷移の際に用いる、クエリのクエリＩＤを定義している。
【０３３２】
次に、図６１と図６４を用いて、マップのマトリックス構成中の各構成要素に、スタイルシートによりクエリＩＤとパラメータを割り当てる方法について説明する。スタイルシートには、このマップのマトリックス構成中の各構成要素に、クエリＩＤとパラメータを割り当てるための記述があり、このスタイルシートと図６１に示した検索結果としてのＸＭＬ文書とを基に、クライアント端末のブラウザが、マップのマトリックス構成中の各構成要素に、クエリＩＤとパラメータを関連付けを行う。なお、このようなブラウザの処理は、周知の技術である。
【０３３３】
クエリＩＤ「Ｑｉｄ０」対応のスタイルシートには、例えば、以下の（１）〜（４）に示すような内容が記述されている。
【０３３４】
（１）「Ｘ」タグの要素値の集合｛Ｘ０、Ｘ１、…Ｘｉ｝と、その要素値の数ＭａｘＸ、そして、「Ｙ」タグの要素値の集合｛Ｙ０、Ｙ１、…Ｙｊ｝とその要素値の数ＭａｘＹを求める。但し、ｉは「０」以上「ＭａｘＸ」未満の整数を、ｊは「０」以上「ＭａｘＹ」未満の整数を意味するもとのとする。
【０３３５】
（２）マップのマトリックス構成中の最上段の要素については、（「ＱＩＤ１」タグの値、「ＸＴＡＧ」タグの値、Ｘｉ、「ＹＴＡＧ」タグの値、「ＹＶＡＬ」タグの値）を割り当てる。
【０３３６】
（３）マップのマトリックス構成中の最左段の要素については、（「ＱＩＤ１」タグの値、「ＸＴＡＧ」タグの値、「ＸＶＡＬ」タグの値、「ＹＴＡＧ」タグの値、Ｙｊ）を割り当てる。
【０３３７】
（４）マトリックス構成中のその他の要素については、（「ＱＩＤ２」タグの値、「ＸＴＡＧ」タグの値、Ｘｉ、「ＹＴＡＧ」タグの値、Ｙｊ）を割り当てる。
【０３３８】
この記述に従えば、まず、図６１の検索結果のＸＭＬ文書から、「Ｘ」タグの要素値の集合｛Ｘ０、Ｘ１、…Ｘｉ｝（＝｛格納機能、検索機能｝）とその要素値の数ＭａｘＸ（＝２）、そして、「Ｙ」タグの要素値の集合｛Ｙ０、Ｙ１、…Ｙｊ｝（＝｛データベース技術、自然言語技術、知識処理技術｝）とその要素値の数ＭａｘＹ（＝３）を求める。例えば、Ｘ１＝「検索機能」であり、Ｙ２＝「知識処理技術」である。
【０３３９】
続いて、上記で求めた値を用いて、クエリＩＤとパラメータの割り当てを行う。
【０３４０】
まず、図６４において、マップのマトリックス構成中の最上段の要素（２，１）、（３、１）については、（「ＱＩＤ１」タグの値、「ＸＴＡＧ」タグの値、Ｘｉ、「ＹＴＡＧ」タグの値、「ＹＶＡＬ」タグの値）を割り当てる。この規則に従えば、要素（２，１）には、（Ｑｉｄ０，キーワード群／キーワード、格納機能、キーワード群／キーワード、技術）が関連付けられる。また、要素（３，１）には、（Ｑｉｄ０，キーワード群／キーワード、検索機能、キーワード群／キーワード、技術）が関連付けられる。
【０３４１】
次に、図６４において、マップのマトリックス構成中の最左段の要素（１，２）、（１，３）、（１，４）については、（「ＱＩＤ１」タグの値、「ＸＴＡＧ」タグの値、「ＸＶＡＬ」タグの値、「ＹＴＡＧ」タグの値、Ｙｊ）を割り当てる。この規則に従えば、要素（１，２）には、（Ｑｉｄ０，キーワード群／キーワード、機能、キーワード群／キーワード、データベース技術）が関連付けられる。また、要素（１，３）には、（Ｑｉｄ０，キーワード群／キーワード、機能、キーワード群／キーワード、自然言語技術）が関連付けられる。また、要素（１，４）には、（Ｑｉｄ０，キーワード群／キーワード、機能、キーワード群／キーワード、知識処理技術）が関連付けられる。
【０３４２】
マトリックス構成中のその他の要素（２，２）（２，３）（２，４）（３，２）（３，３）（３，４）については、（「ＱＩＤ２」タグの値、「ＸＴＡＧ」タグの値、Ｘｉ、「ＹＴＡＧ」タグの値、Ｙｊ）を割り当てる。この規則に従えば、例えば、要素（２，３）には、（Ｑｉｄ１，キーワード群／キーワード、格納機能、キーワード群／キーワード、自然言語技術）が関連付けられ、また、要素（３，２）には、（Ｑｉｄ１，キーワード群／キーワード、検索機能、キーワード群／キーワード、データベース技術）が関連付けられる。
【０３４３】
次に、クライアント端末に、図６３（ａ）に示したマップが表示された後の画面遷移について、図６５を参照して説明する。
【０３４４】
図６５において、クライアント端末に表示されたマップＭ１（図６３（ａ）と同じもの）が表示されたとする。マップＭ１のマトリックス構成中の要素（３，１）をユーザがマウスクリック等すると、他のマップＭ２の表示画面へと画面遷移する。また、マップＭ１のマトリックス構成中の要素（３，４）をユーザがマウスクリック等すると、論文一覧Ｍ３の表示画面へと画面遷移する。
【０３４５】
マップＭ１の要素（３，１）には、図６４に示したように、（Ｑｉｄ０，キーワード群／キーワード、検索機能、キーワード群／キーワード、技術）というクエリＩＤとパラメータが関連付けられている。ユーザが、例えば、要素（３，１）をマウスクリック等することにより、画面遷移の指示がなされる（ステップＳ２０８）。この指示により、当該要素（３，１）に関連付けられたクエリＩＤ「Ｑｉｄ０」と検索条件としての当該パラメータ（パラメータ１、パラメータ２，パラメータ３，パラメータ４）＝（キーワード群／キーワード、検索機能、キーワード群／キーワード、技術）を含む検索要求が構造化文書管理システムへ送信される。
【０３４６】
上記検索要求は、前述同様、構造化文書管理システムの要求受付部１１にて受け付けられ（図６９のステップＳ２２１）、当該検索要求は、図６９のステップＳ２２２〜ステップＳ２２６に示したように、検索要求処理部３で処理される。
【０３４７】
検索要求処理部３は、クエリＩＤ「Ｑｉｄ０」に対応するクエリを構造化文書データベースから獲得する（ステップＳ２１０）。すなわち、クエリＩＤ「Ｑｉｄ０」は、ここでは、構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／クエリ群／クエリ［０］」に対応するので、図５５に示す構造化文書データベースから当該クエリＩＤ（構造化文書パス）にて特定されるクエリを取得し、このクエリに、検索要求として送信されてきたパラメータを設定して、構造化文書データベース中の「論文群」ノード以下に格納されている文書の中から、概念「検索機能」の子要素のいずれかと、概念「技術」の子要素のいずれかが、タグ名「キーワード」の要素値に含まれる「論文」情報の検索を行う（ステップＳ２１１）。
【０３４８】
ステップＳ２１１の検索の際に用いるクエリは、図６０に示したクエリＩＤ「Ｑｉｄ０」のクエリを用いるが、ここでは、パラメータが異なるので、「ｈｅａｄ」タグで囲まれた部分で、４つの引数に設定される値が異なる。すなわち、「＄ｔａｇ１」、「＄ｔａｇ２」には、「キーワード群／キーワード」が設定され、「＄ｃａｔｅｇｏｒｙ１」、「＄ｃａｔｅｇｏｒｙ２」には、「検索機能」、「技術」がそれぞれ設定される。その他は図６０と同様である。
【０３４９】
上記クエリに基づく実際の検索処理は、前述同様にして、例えば、構造化文書データベースに格納されている全ての「論文」情報の１つ１つについて、「「キーワード」タグに概念「検索機能」のサブ概念の「キーワード検索機能」「タグ検索機能」「画像検索機能」「曖昧検索機能」という文字列を含む」という条件に合致するもの、および、「「キーワード」タグに概念「技術」のサブ概念である「データベース技術」あるいは「自然言語技術」あるいは「知識処理技術」いう文字列を含む」という条件に合致するものを検索する。
【０３５０】
上記２つの条件を満たす「論文」情報の件数を、ｘ軸上のサブ概念とｙ軸上のサブ概念とに対応付けた検索集計結果とする。
【０３５１】
図６６は、上記のようにして、構造化文書データベースに対し検索を行って得られた検索結果としてのＸＭＬ文書である。
【０３５２】
図６６において、「ｒｅｓｕｌｔ」タグで囲まれた部分は、ｘ軸に並べられる概念「検索機能」のサブ概念のうちの１つと、ｙ軸に並べられる概念「技術」のサブ概念のうちの１つと、それらを検索条件に用いて「論文」情報を検索集計した結果である「件数」との記述である。概念「検索機能」のサブ概念が４つ、概念「技術」のサブ概念が３つあるので、この「ｒｅｓｕｌｔ」タグで囲まれた部分は、全部で１２個存在する。
【０３５３】
さて、検索結果を得たら、次に、クエリＩＤ「Ｑｉｄ０」に対応するスタイルシートを図６２に示したテーブルから獲得する（ステップＳ２１２）。
【０３５４】
図６６示したような検索結果としてのＸＭＬ文書と、当該獲得したスタイルシートとを要求元のクライアント端末へ送り返す（ステップＳ２１３）。
【０３５５】
図６６示す検索結果のＸＭＬ文書は、クライアント端末において、例えば、図６５の示すようにマトリックス形式のマップＭ２として表示される（ステップＳ２１４）。すなわち、クライアント端末では、マップＭ１の画面表示において、そのマップの要素（３，１）をマウスクリックすることで、マップＭ２の画面表示へと画面遷移がなされたことになる。
【０３５６】
ところで、図６５のマップＭ２のマトリックス構成中の各要素にも、マップＭ１と同様、スタイルシートにより、クエリＩＤとパラメータが関連付けられている。
【０３５７】
ここでは、説明の便宜上、図６７（ｂ）に示すように、マップＭ２のマトリックスを構成する各要素を、要素（ｘ、ｙ）と座標表現する。なお、ここでは、ｘ＝１〜５、ｙ＝１〜４である。
【０３５８】
前述同様にして、クエリＩＤ「Ｑｉｄ０」に対応付けられたスタイルシートにより、マップＭ２のマトリックス構成中の最上段の要素（２，１）、（３、１）、（４，１）、（５、１）については、（「ＱＩＤ１」タグの値、「ＸＴＡＧ」タグの値、Ｘｉ、「ＹＴＡＧ」タグの値、「ＹＶＡＬ」タグの値）を割り当てる。この規則に従えば、要素（２，１）には、（Ｑｉｄ０，キーワード群／キーワード、キーワード検索機能、キーワード群／キーワード、技術）が関連付けられる。また、要素（３，１）には、（Ｑｉｄ０，キーワード群／キーワード、タグ検索機能、キーワード群／キーワード、技術）が関連付けられる。また、要素（４，１）には、（Ｑｉｄ０，キーワード群／キーワード、画像検索機能、キーワード群／キーワード、技術）が関連付けられる。また、要素（５，１）には、（Ｑｉｄ０，キーワード群／キーワード、曖昧検索機能、キーワード群／キーワード、技術）が関連付けられる。
【０３５９】
マップＭ２のマトリックス構成中の最左段の要素（１，２）、（１，３）、（１，４）については、（「ＱＩＤ１」タグの値、「ＸＴＡＧ」タグの値、「ＸＶＡＬ」タグの値、「ＹＴＡＧ」タグの値、Ｙｊ）を割り当てる。この規則に従えば、要素（１，２）には、（Ｑｉｄ０，キーワード群／キーワード、検索機能、キーワード群／キーワード、データベース技術）が関連付けられる。また、要素（１，３）には、（Ｑｉｄ０，キーワード群／キーワード、検索機能、キーワード群／キーワード、自然言語技術）が関連付けられる。また、要素（１，４）には、（Ｑｉｄ０，キーワード群／キーワード、検索機能、キーワード群／キーワード、知識処理技術）が関連付けられる。
【０３６０】
マトリックス構成中のその他の要素については、（「ＱＩＤ２」タグの値、「ＸＴＡＧ」タグの値、Ｘｉ、「ＹＴＡＧ」タグの値、Ｙｊ）を割り当てる。この規則に従えば、例えば、要素（２，３）には、（Ｑｉｄ１，キーワード群／キーワード、キーワード格納機能、キーワード群／キーワード、自然言語技術）が関連付けられ、また、要素（３，２）には、（Ｑｉｄ１，キーワード群／キーワード、タグ検索機能、キーワード群／キーワード、データベース技術）が関連付けられる。
【０３６１】
ユーザが、マップＭ２のマトリックス構成中のクエリＩＤとパラメータが関連付けられている要素をマウスクリックして、画面遷移を指示すると、前述同様にして、当該指示のあった要素に関連付けられていたクエリＩＤとパラメータとを含む検索要求が構造化文書管理システムに送信されて、画面遷移がなされる（ステップＳ２０８〜ステップＳ２１４）。
【０３６２】
さて、図６５において、マップＭ１のマトリックス構成中の要素（３，４）をユーザがマウスクリック等すると、論文一覧Ｍ３の表示画面へと画面遷移する。
【０３６３】
マップＭ１の要素（３，４）には、図６４に示したように、（Ｑｉｄ１，キーワード群／キーワード、検索機能、キーワード群／キーワード、知識処理技術）というクエリＩＤとパラメータが関連付けられている。ユーザが、例えば、要素（３，４）をマウスクリック等することにより、画面遷移の指示がなされる（ステップＳ２０８）。この指示により、当該要素（３，４）に関連付けられたクエリＩＤ「Ｑｉｄ１」と検索条件としての当該パラメータ（パラメータ１、パラメータ２，パラメータ３，パラメータ４）＝（キーワード群／キーワード、検索機能、キーワード群／キーワード、知識処理技術）を含む検索要求が構造化文書管理システムへ送信される。
【０３６４】
上記検索要求は、前述同様、構造化文書管理システムの要求受付部１１にて受け付けられ、当該検索要求は、検索要求処理部３で処理される。
【０３６５】
検索要求処理部３は、クエリＩＤ「Ｑｉｄ１」に対応するクエリを構造化文書データベースから獲得する（ステップＳ２１０）。すなわち、クエリＩＤ「Ｑｉｄ１」は、ここでは、構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／クエリ群／クエリ［１］」に対応するので、図５５に示す構造化文書データベースから当該クエリＩＤ（構造化文書パス）にて特定されるクエリを取得し、このクエリに、検索要求として送信されてきたパラメータを設定して、構造化文書データベース中の「論文群」ノード以下に格納されている文書の中から、概念「検索機能」の子孫要素のいずれかと、概念「知識処理技術」とが、タグ名「キーワード」の要素値に含まれる「論文」情報の検索を行う（ステップＳ２１１）。
【０３６６】
ステップＳ２１１の検索の際に用いるクエリＩＤ「Ｑｉｄ１」のクエリを、図６８に示す。
【０３６７】
このクエリの引数は４つあり、順に、「＄ｔａｇ１」にはｘ軸で用いるタグ名、「＄ｃａｔｅｇｏｒｙ１」はｘ軸で用いる概念、「＄ｔａｇ２」はｙ軸で用いるタグ名、「＄ｃａｔｅｇｏｒｙ２」はｙ軸で用いる概念を意味する。
【０３６８】
まず「ｈｅａｄ」タグで囲まれた部分で上記変数にパラメータとして与えられた値が設定される。すなわち、「＄ｔａｇ１」、「＄ｔａｇ２」には、「キーワード群／キーワード」が設定され、「＄ｃａｔｅｇｏｒｙ１」、「＄ｃａｔｅｇｏｒｙ２」には、「検索機能」、「知識処理技術」がそれぞれ設定される。
【０３６９】
。
【０３７０】
「ｋｆ：ｆｒｏｍ」タグで囲まれた部分には、「ｕｉｘ：／／ｒｏｏｔ／論文群」以下に格納されている「論文」情報にある要素「キーワード」の値が、概念「検索機能」の各子孫要素と、概念「知識処理技術」の各子孫要素との値と一致すること」という検索条件が記述されている。
【０３７１】
＜ｒｅｓｕｌｔ＞タグで囲まれた部分の記述により、検索中に「ｋｆ：ｆｒｏｍ」タグで囲まれた部分に記述された検索条件を満たす「論文」情報が抽出されたとき、その抽出された「論文」情報自体（あるいは当該「論文」情報の文書オブジェクトツリーのトップノードのタグ名）が代入された変数「＄ｅｌｔ」の値を出力し、変数「＄ｅｌｔ」の値は、抽出された「論文」情報の数分のだけ出力することを意味する。
【０３７２】
「ｋｆ：ｆｒｏｍ」タグで囲まれた部分は３つ存在する。１番目の「ｋｆ：ｆｒｏｍ」タグで囲まれた部分は、パス「ｕｉｘ：／／ｒｏｏｔ／論文群」の直下にある「論文」情報の直下のタグ「＄ｔａｇ１」の値を変数「＄ｋｅｙｗｏｒｄ１」に代入し、さらに該「論文」情報の直下のタグ「＄ｔａｇ２」の値を変数「＄ｋｅｙｗｏｒｄ２」に代入し、「ｋｆ：ａｓ」タグに囲まれた部分により、該「論文」情報自体を変数「＄ｅｌｔ」に代入することを意味する。
【０３７３】
２番目の「ｋｆ：ｆｒｏｍ」タグで囲まれた部分は、検索条件として、パス「ｕｉｘ：／／ｒｏｏｔ／概念ツリー」の子孫で、「ｎａｍｅ」属性の値が「＄ｃａｔｅｇｏｒｙ１」である「概念」タグの子孫に「ｎａｍｅ」属性の値が該「＄ｋｅｙｗｏｒｄ１」と等しい「概念」タグが存在することを意味する。
【０３７４】
３番目の「ｋｆ：ｆｒｏｍ」タグで囲まれた部分は、検索条件として、パス「ｕｉｘ：／／ｒｏｏｔ／概念ツリー」の子孫で、「ｎａｍｅ」属性の値が「＄ｃａｔｅｇｏｒｙ２」である「概念」タグの子孫に「ｎａｍｅ」属性の値が該「＄ｋｅｙｗｏｒｄ２」と等しい「概念」タグが存在することを意味する。
【０３７５】
「ｋｆ：ｓｅｌｅｃｔ」タグで囲まれた部分では、変数「＄ｅｌｔ」に代入された値（例えば、抽出された「論文」情報自体）を「ｒｅｓｕｌｔ」タグの値に設定することを意味する。
【０３７６】
「ｋｆ：ｇｒｏｕｐＢｙ」タグにより、変数「＄ｅｌｔ」の値別に処理することを意味する。
【０３７７】
図６８に示したクエリに基づく実際の検索処理は、前述同様にして、構造化文書データベースに格納されている全ての「論文」情報の１つ１つについて、「「キーワード」タグに概念「検索機能」（および、概念「検索機能」の各子孫概念）という文字列を含む」という条件に合致するもの、および、「「キーワード」タグに概念「知識処理技術」いう文字列を含む」という条件に合致するものを検索する。
【０３７８】
上記２つの条件を満たす「論文」情報を検索結果とする。
【０３７９】
さて、検索結果を得たら、次に、クエリＩＤ「Ｑｉｄ０」に対応するスタイルシートを図６２に示したテーブルから獲得する（ステップＳ２１２）。
【０３８０】
検索結果としてのＸＭＬ文書と、当該獲得したスタイルシートとを要求元のクライアント端末へ送り返す（ステップＳ２１３）。
【０３８１】
当該検索結果のＸＭＬ文書は、クライアント端末において、当該スタイルシートにより、例えば、「論文」情報中の「タイトル」タグの値のみが取り出されて、図６５の示すように論文一覧Ｍ３として表示される（ステップＳ２１４）。すなわち、クライアント端末では、マップＭ１の画面表示において、そのマップの要素（３，４）をマウスクリックすることで、論文一覧Ｍ３の画面表示へと画面遷移がなされたことになる。
【０３８２】
以上説明したように、上記第２の実施形態によれば、検索条件に用いるタグとタグの値をパラメータ化したクエリと、各クエリに予め対応付けられたスタイルシートとを用いるとともに、検索結果の表示画面上に、上記クエリの識別情報としてのクエリＩＤと上記パラメータを関連付けることにより、検索を伴う画面遷移が容易に行える。
【０３８３】
すなわち、検索結果の表示画面上のクエリＩＤとパラメータの関連付けられた表示領域がユーザにより指定されたとき、構造化文書管理システムは、その表示領域に関連付けらたれたクエリＩＤとパラメータ（指示データ）とを受け付けて、当該クエリＩＤに対応するクエリに当該パラメータとして受け取った検索条件を設定して、構造化文書データベースに対し検索を行い、得られた検索結果を当該クエリＩＤに対応したスタイルシートで要求元で画面表示させることにより、ユーザは、画面上に表示された検索結果をみて、より詳細な情報を見ようとする際、単に表示画面上の所望の表示領域を指示するだけで、その表示領域に表示された内容のより詳細な情報（検索・集計結果）の表示画面が表示される。
【０３８４】
このように、本発明によれば、例えば、図５５等に示すような多種多様な文書構造定義に従った文書を、その文書の種類対応に予め定められた文書構造の同一性を保持しながら、文書構造の定義がなされていない構造化文書とともに一元管理する構造化文書データベース上で、ある観点からの検索条件による検索結果の表示から、違った観点からの検索結果の表示へと画面遷移させることが容易に行える検索を実現することができる。
【０３８５】
また、従来からある、ある１つの文書構造に特化された構造化文書の構造化文書データベースに対しても、本発明の検索方法を適用することにより、ＯＬＡＰを実現することができる。この場合、クエリやスタイルシートなど、上記特定の文書構造の構造化文書でない情報は、構造化文書データベースとは別個に格納・管理されることになる。
【０３８６】
なお、本発明の実施の形態に記載した本発明の手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピーディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、半導体メモリなどの記録媒体に格納して頒布することもできる。
【０３８７】
なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。さらに、上記実施形態には種々の段階の発明は含まれており、開示される複数の構成用件における適宜な組み合わせにより、種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題（の少なくとも１つ）が解決でき、発明の効果の欄で述べられている効果（の少なくとも１つ）が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【０３８８】
【発明の効果】
以上説明したように、本発明によれば、多種多様な文書構造定義に従った文書を、その文書の種類対応に予め定められた文書構造の同一性を保持しながら、文書構造の定義がなされていない構造化文書とともに一元管理する構造化文書データベースでＯＬＡＰを実現可能にし、様々な観点からのデータ分析が容易に行える。
【図面の簡単な説明】
【図１】本発明の実施形態に係る構造化文書管理システムの構成例を示した図。
【図２】図１に示した構造化文書管理システムの一利用形態を示したもので、ＷＷＷのバックエンドで、構造化文書管理システムが動作している場合を示した図。
【図３】ＸＭＬで記述された構造化文書の一例を示した図。
【図４】図３の構造化文書の文書構造を模式的に示した図。
【図５】追加コマンドの機能を説明するための図で、構造化文書データベースの初期状態に追加コマンドを実行した場合について示している。
【図６】図５（ｂ）に示した状態の構造化文書データベースに対し、取得コマンドを実行した場合の処理結果を示した図。
【図７】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して１つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図８】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して３つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図９】要素名生起インデックスの格納例を示した図。
【図１０】データ生起インデックスの格納例を示した図。
【図１１】図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合の実行結果を示した図。
【図１２】ＸＭＬ文書の文書構造を定義するスキーマの一例を示した図。
【図１３】図８に示した状態の構造化文書データベースに、スキーマ格納コマンドを実行して、図１２に示したスキーマを追加格納（設定）した場合を示した図。
【図１４】スキーマが設定されて、スキーマが存在している旨の属性値のセットされた文書オブジェクトツリーを示した図。
【図１５】各オブジェクトファイルに、スキーマが存在している旨の属性値が格納されている様子を概念的に示した図。
【図１６】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１７】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１８】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図１９】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図２０】図１の構造化文書管理システムの文書格納処理動作について説明するためのフローチャート。
【図２１】図２０のステップＳ９の処理（合成文書作成部の処理）について説明するためのフローチャート
【図２２】追加コマンド中のパラメータの格納文書の文書オブジェクトツリーを構造化文書データベースから取得した文書オブジェクトツリーに挿入して得られた合成文書の文書オブジェクトツリーをＸＭＬ文書に変換した結果であって、テンポラリファイルＡに格納される合成文書の一例を示した図。
【図２３】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図２４】テンポラリファイルＡに格納される合成文書の他の例を示した図。
【図２５】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図２６】図１の構造化文書管理システムの文書取得処理動作について説明するためのフローチャート。
【図２７】図１の構造化文書管理システムの文書削除処理動作について説明するためのフローチャート。
【図２８】図２７のステップＳ４６の処理（合成文書作成部の処理（削除コマンド用））について説明するためのフローチャート。
【図２９】テンポラリファイルＡに格納される合成文書のさらに他の例であって、削除コマンドの実行時に作成される合成文書の一例を示した図。
【図３０】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図３１】ユーザインタフェースとしての画面の表示例を示した図。
【図３２】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３３】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３４】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３５】妥当性のチェックでエラーとなっときにクライアント端末へ返すメッセージの表示例を表示例を示した図。
【図３６】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示したもので、文書取得動作を説明するための図。
【図３７】スキーマの設定を行うためのユーザインタフェースとしての画面の表示例を示したもので、スキーマの設定動作を説明するための図。
【図３８】スキーマの取得するためのユーザインタフェースとしての画面の表示例を示したもので、取得されたスキーマの表示例を示している。
【図３９】クエリ（ＸＭＬ文書）の一例を示した図。
【図４０】単純検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図４１】図４０の単純検索のクエリを用いた検索結果（ＸＭＬ文書）を示した図。
【図４２】概念検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図４３】図１の構造化文書管理システムの文書検索処理動作について説明するためのフローチャート。
【図４４】文書検索を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図４５】図４４に示した画面上から入力された情報に基づき作成されるクエリを示した図。
【図４６】図４２に示したクエリの構造化文書データベース内における格納例を示した図。
【図４７】文書検索を行うためのユーザインタフェースとしての画面の表示例であって、スキーマの検索処理動作を説明するための図。
【図４８】スキーマ検索のクエリの一例を示した図。
【図４９】クエリを検索するためのクエリの一例を示した図。
【図５０】特許調査における構造化文書データベースの一例を示した図。
【図５１】概念検索のための入力画面の表示例を示した図。
【図５２】図５１に示した入力画面上の入力情報に対応するクエリを示した図。
【図５３】図５２に示したクエリに対応する検索結果としてのＸＭＬ文書を示した図。
【図５４】特許マップの一例を示した図。
【図５５】第２の実施形態に係る構造化文書データベースの一例を示した図。
【図５６】ＸＭＬで記述された構造化文書の一例として、上記「論文」情報の例を示した図。
【図５７】図５５に示した「概念ツリー」ノード以下の「概念」情報の文書オブジェクトツリーに対応するＸＭＬ文書の記述を示した図。
【図５８】概念検索のための検索条件の入力画面の一例で、検索条件検索対象の範囲を「概念ツリー」ノード以下の「論文」情報に限定された概念検索のための検索条件の入力画面を示した図。
【図５９】構造化文書管理システムとクライアント端末との間の処理動作について説明するためのフローチャート。
【図６０】クエリＩＤ「Ｑｉｄ０」のクエリを示した図。
【図６１】図６０のクエリを用いて検索した結果得られたＸＭＬ文書を示した図。
【図６２】検索要求処理部に記憶される、クエリＩＤとスタイルＩＤとの対応テーブルの一例を示した図。
【図６３】クライアント端末での検索結果の表示例であって、検索結果をマトリックス形式のマップとして表示した場合の画面表示例を示した図。
【図６４】図６３のマップのマトリックスを構成する各要素へのクエリＩＤ、パラメータの関連付けを説明するための図。
【図６５】クライアント端末における画面遷移について説明するための図。
【図６６】ユーザからの画面遷移の指示を受けてクライアント端末から送信された検索要求に基づく検索結果としてのＸＭＬ文書の示した図。
【図６７】図６６のＸＭＬ文書の画面表示例を示した図。
【図６８】クエリＩＤ「Ｑｉｄ１」のクエリを示した図。
【図６９】構造化文書管理システムの処理動作を説明するためのフローチャート。
【符号の説明】
１…要求制御部
２…アクセス要求処理部
３…検索要求処理部
４…データアクセス部
５…文書記憶部
６…インデックス記憶部
１１…受付要求部
１２…結果処理部
２１…文書格納部
２２…文書取得部
２３…文書削除部
４１…文書オブジェクトツリー格納部
４２…文書オブジェクトツリー削除部
４３…文書オブジェクトツリー取得部
４４…文書文字列取得部
４５…パスから文書オブジェクトツリー取得部
４６…文書パーサ
４７…合成文書作成部
４８…インデックス更新部
１００…構造化文書管理システム
１０１…ＷＷＷサーバ
１０２…クライアント端末
１０３…ＷＷＷブラウザ

Claims (15)

1. 複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに、構造化文書の種別を示す種別ノードをリンクし、当該種別ノードに、各構造化文書に含まれる各要素の記憶エリアを当該構造化文書の文書構造に従ってリンクした論理構造により、前記複数の構造化文書を管理する構造化文書データベースから、構造化文書を検索する構造化文書検索方法であって、
   前記構造化文書データベースに、階層的に分類された複数の概念名の概念階層構造を示す概念情報を格納する概念情報格納ステップと、
   第１の要素名、第２の要素名、前記複数の概念名のうちの１つの第１の概念名及び他の１つの第２の概念名、前記第１の要素名の要素が前記概念階層構造上前記第１の概念名に属する概念名を含む構造、及び前記第２の要素名の要素が前記概念階層構造上前記第２の概念名に属する概念名を含む構造が指定された第１の検索条件を含む第１の検索要求文を入力するステップと、
   前記概念階層構造から、前記第１の概念名に属する第１の概念名群と、前記第２の概念名に属する第２の概念名群とを求めるステップと、
   前記論理構造から、前記第１の概念名群のうちのいずれかを含む前記第１の要素名の要素と、前記第２の概念名群のうちのいずれかを含む前記第２の要素名の要素とを含む第１の検索結果の構造化文書群を求めるステップと、
   縦の各列の見出しが、前記概念階層構造上の前記第１の概念名の直下の各概念名であり、横の各列の見出しが、前記概念階層構造上の前記第２の概念名の直下の各概念名であるテーブル上の縦の列と横の列との交点にある各データセルで、前記第１の検索結果の構造化文書群のうち、前記第１の要素名の要素が当該縦の列の見出しの概念名に属する概念名を含み、かつ前記第２の要素名の要素が当該横の列の見出しの概念名に属する概念名を含む構造化文書の集計結果を示すとともに、縦の列の見出しを示す各見出しセルに、前記第１の要素名、前記第２の要素名、当該縦の列の見出しである概念名及び前記第２の概念名を含む検索条件のパラメータが対応付けられた、前記第１の検索結果を表示するための第１のテーブルを生成する第１の生成ステップと、
   前記第１のテーブルを表示手段で表示するステップと、
   表示された前記第１のテーブル上の縦の列の任意の見出しセルが指示されると、当該見出しセルに対応付けられている前記パラメータを用いて、前記第１の要素名、前記第２の要素名、当該縦の列の見出しである第３の概念名、前記第２の概念名、前記第１の要素名の要素が前記概念階層構造上前記第３の概念名に属する概念名を含む構造、及び前記第２の要素名の要素が前記概念階層構造上前記第２の概念名に属する概念名を含む構造が指定された第２の検索条件を含む第２の検索要求文を生成するステップと、
   前記概念階層構造から、前記第２の検索条件で指定されている前記第３の概念名に属する第３の概念名群と、前記第２の検索条件で指定されている前記第２の概念名に属する第２の概念名群とを求めるステップと、
   前記論理構造から、前記第３の概念名群のうちのいずれかを含む前記第１の要素名の要素と、前記第２の概念名群のうちのいずれかを含む前記第２の要素名の要素とを含む第２の検索結果の構造化文書群を求めるステップと、
   を含む構造化文書検索方法。
2. 前記第１の生成ステップで生成される第１のテーブルには、横の列の見出しを示す各見出しセルに、前記第１の要素名、前記第２の要素名、前記第１の概念名、及び当該横の列の見出しである概念名を含む検索条件のパラメータが対応付けられ、各データセルに、前記第１の要素名、前記第２の要素名、当該データセルを含む縦の列の見出しである概念名、及び当該データセルを含む横の列の見出しである概念名を含む検索条件のパラメータが対応付けられていることを特徴とする請求項１記載の構造化文書検索方法。
3. 縦の各列の見出しが、前記概念階層構造上の前記第３の概念名の直下の各概念名であり、横の各列の見出しが、前記概念階層構造上の前記第２の概念名の直下の各概念名であるテーブル上の縦の列と横の列との交点にある各データセルで、前記第２の検索結果の構造化文書群のうち、前記第１の要素名の要素が当該縦の列の見出しの概念名に属する概念名を含み、かつ前記第２の要素名の要素が当該横の列の見出しの概念名に属する概念名を含む構造化文書の集計結果を示す、前記第２の検索結果を表示するための第２のテーブルを生成する第２の生成ステップと、
   前記第２のテーブルを前記表示手段で表示するステップと、
   をさらに含む請求項１記載の構造化文書検索方法。
4. 前記第２の生成ステップで生成される前記第２のテーブルには、縦の列の見出しを示す各見出しセルに、前記第１の要素名、前記第２の要素名、当該縦の列の見出しである概念名及び前記第２の概念名を含む検索条件のパラメータが対応付けられ、横の列の見出しを示す各見出しセルに、前記第１の要素名、前記第２の要素名、前記第１の概念名、及び当該横の列の見出しである概念名を含む検索条件のパラメータが対応付けられ、各データセルに、前記第１の要素名、前記第２の要素名、当該データセルを含む縦の列の見出しである概念名、及び当該データセルを含む横の列の見出しである概念名を含む検索条件のパラメータが対応付けられていることを特徴とする請求項３記載の構造化文書検索方法。
5. 表示された前記第１のテーブル上の任意のデータセルが指示されると、当該データセルに対応付けられているパラメータを用いて、前記第１の要素名、前記第２の要素名、当該データセルを含む縦の列の見出しである第４の概念名、当該データセルを含む横の列の見出しである第５の概念名、前記第１の要素名の要素が前記概念階層構造上前記第４の概念名に属する概念名を含む構造、及び前記第２の要素名の要素が前記概念階層構造上前記第５の概念名に属する概念名を含む構造が指定された第３の検索条件を含む第３の検索要求文を生成するステップと、
   前記概念階層構造から、前記第３の検索条件で指定されている前記第４の概念名に属する第４の概念名群と、前記第３の検索条件で指定されている前記第５の概念名に属する第５の概念名群とを求めるステップと、
   前記論理構造から、前記第４の概念名群のうちのいずれかを含む前記第１の要素名の要素と、前記第５の概念名群のうちのいずれかを含む前記第２の要素名の要素とを含む第３の検索結果の構造化文書群を求めるステップと、
   をさらに含む請求項２記載の構造化文書検索方法。
6. 前記第３の検索結果の構造化文書群の一覧を生成するステップと、
   前記一覧を前記表示手段で表示するステップと、
   をさらに含むことを特徴とする請求項５記載の構造化文書検索方法。
7. 前記概念情報格納ステップで格納された前記概念情報は、前記概念階層構造が前記文書構造として表された構造化文書であり、当該概念情報は、前記ルートノードにリンクされた、前記概念情報に対応する前記種別ノードに、各概念名の記憶エリアを前記概念階層構造に従ってリンクされて管理されることを特徴とする請求項１記載の構造化文書管理方法。
8. 複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに、構造化文書の種別を示す種別ノードをリンクし、当該種別ノードに、各構造化文書に含まれる各要素の記憶エリアを当該構造化文書の文書構造に従ってリンクした論理構造により、前記複数の構造化文書を管理する構造化文書データベースと、
   前記構造化文書データベースに、階層的に分類された複数の概念名の概念階層構造を示す概念情報を格納する概念情報格納手段と、
   第１の要素名、第２の要素名、前記複数の概念名のうちの１つの第１の概念名及び他の１つの第２の概念名、前記第１の要素名の要素が前記概念階層構造上前記第１の概念名に属する概念名を含む構造、及び前記第２の要素名の要素が前記概念階層構造上前記第２の概念名に属する概念名を含む構造が指定された第１の検索条件を含む第１の検索要求文を入力する手段と、
   前記概念階層構造から、前記第１の概念名に属する第１の概念名群と、前記第２の概念名に属する第２の概念名群とを求める手段と、
   前記論理構造から、前記第１の概念名群のうちのいずれかを含む前記第１の要素名の要素と、前記第２の概念名群のうちのいずれかを含む前記第２の要素名の要素とを含む第１の検索結果の構造化文書群を求める手段と、
   縦の各列の見出しが、前記概念階層構造上の前記第１の概念名の直下の各概念名であり、横の各列の見出しが、前記概念階層構造上の前記第２の概念名の直下の各概念名であるテーブル上の縦の列と横の列との交点にある各データセルで、前記第１の検索結果の構造化文書群のうち、前記第１の要素名の要素が当該縦の列の見出しの概念名に属する概念名を含み、かつ前記第２の要素名の要素が当該横の列の見出しの概念名に属する概念名を含む構造化文書の集計結果を示すとともに、縦の列の見出しを示す各見出しセルに、前記第１の要素名、前記第２の要素名、当該縦の列の見出しである概念名及び前記第２の概念名を含む検索条件のパラメータが対応付けられた、前記第１の検索結果を表示するための第１のテーブルを生成する第１の生成手段と、
   前記第１のテーブルを表示する表示手段と、
   表示された前記第１のテーブル上の縦の列の任意の見出しセルが指示されると、当該見出しセルに対応付けられている前記パラメータを用いて、前記第１の要素名、前記第２の要素名、当該縦の列の見出しである第３の概念名、前記第２の概念名、前記第１の要素名の要素が前記概念階層構造上前記第３の概念名に属する概念名を含む構造、及び前記第２の要素名の要素が前記概念階層構造上前記第２の概念名に属する概念名を含む構造が指定された第２の検索条件を含む第２の検索要求文を生成する手段と、
   前記概念階層構造から、前記第２の検索条件で指定されている前記第３の概念名に属する第３の概念名群と、前記第２の検索条件で指定されている前記第２の概念名に属する第２の概念名群とを求める手段と、
   前記論理構造から、前記第３の概念名群のうちのいずれかを含む前記第１の要素名の要素と、前記第２の概念名群のうちのいずれかを含む前記第２の要素名の要素とを含む第２の検索結果の構造化文書群を求める手段と、
   を含む構造化文書管理装置。
9. 前記第１の生成手段で生成される第１のテーブルには、横の列の見出しを示す各見出しセルに、前記第１の要素名、前記第２の要素名、前記第１の概念名、及び当該横の列の見出しである概念名を含む検索条件のパラメータが対応付けられ、各データセルに、前記第１の要素名、前記第２の要素名、当該データセルを含む縦の列の見出しである概念名、及び当該データセルを含む横の列の見出しである概念名を含む検索条件のパラメータが対応付けられていることを特徴とする請求項８記載の構造化文書管理装置。
10. 縦の各列の見出しが、前記概念階層構造上の前記第３の概念名の直下の各概念名であり、横の各列の見出しが、前記概念階層構造上の前記第２の概念名の直下の各概念名であるテーブル上の縦の列と横の列との交点にある各データセルで、前記第２の検索結果の構造化文書群のうち、前記第１の要素名の要素が当該縦の列の見出しの概念名に属する概念名を含み、かつ前記第２の要素名の要素が当該横の列の見出しの概念名に属する概念名を含む構造化文書の集計結果を示す、前記第２の検索結果を表示するための第２のテーブルを生成する第２の生成手段と、
    をさらに含み、
    前記第２のテーブルを前記表示手段で表示する請求項８記載の構造化文書管理装置。
11. 前記第２の生成手段で生成される前記第２のテーブルには、縦の列の見出しを示す各見出しセルに、前記第１の要素名、前記第２の要素名、当該縦の列の見出しである概念名及び前記第２の概念名を含む検索条件のパラメータが対応付けられ、横の列の見出しを示す各見出しセルに、前記第１の要素名、前記第２の要素名、前記第１の概念名、及び当該横の列の見出しである概念名を含む検索条件のパラメータが対応付けられ、各データセルに、前記第１の要素名、前記第２の要素名、当該データセルを含む縦の列の見出しである概念名、及び当該データセルを含む横の列の見出しである概念名を含む検索条件のパラメータが対応付けられていることを特徴とする請求項１０記載の構造化文書管理装置。
12. 表示された前記第１のテーブル上の任意のデータセルが指示されると、当該データセルに対応付けられている前記パラメータを用いて、前記第１の要素名、前記第２の要素名、当該データセルを含む縦の列の見出しである第４の概念名、当該データセルを含む横の列の見出しである第５の概念名、前記第１の要素名の要素が前記概念階層構造上前記第４の概念名に属する概念名を含む構造、及び前記第２の要素名の要素が前記概念階層構造上前記第５の概念名に属する概念名を含む構造が指定された第３の検索条件を含む第３の検索要求文を生成する手段と、
    前記概念階層構造から、前記第３の検索条件で指定されている前記第４の概念名に属する第４の概念名群と、前記第３の検索条件で指定されている前記第５の概念名に属する第５の概念名群とを求める手段と、
    前記論理構造から、前記第４の概念名群のうちのいずれかを含む前記第１の要素名の要素と、前記第５の概念名群のうちのいずれかを含む前記第２の要素名の要素とを含む第３の検索結果の構造化文書群を求める手段と
    をさらに含む請求項９記載の構造化文書管理装置。
13. 前記第３の検索結果の構造化文書群の一覧を生成する手段をさらに含み、
    前記一覧を前記表示手段で表示する請求項１２記載の構造化文書管理装置。
14. 前記概念情報格納手段で格納された前記概念情報は、前記概念階層構造が前記文書構造として表された構造化文書であり、当該概念情報は、前記ルートノードにリンクされた、前記概念情報に対応する種別ノードに、各概念名の記憶エリアを前記概念階層構造に従ってリンクされて管理されることを特徴とする請求項８記載の構造化文書管理装置。
15. 複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに、構造化文書の種別を示す種別ノードをリンクし、当該種別ノードに、各構造化文書に含まれる各要素の記憶エリアを当該構造化文書の文書構造に従ってリンクした論理構造により、前記複数の構造化文書を管理する構造化文書データベースを備えたコンピュータに、
    前記構造化文書データベースに、階層的に分類された複数の概念名の概念階層構造を示す概念情報を格納する概念情報格納ステップと、
    第１の要素名、第２の要素名、前記複数の概念名のうちの１つの第１の概念名及び他の１つの第２の概念名、前記第１の要素名の要素が前記概念階層構造上前記第１の概念名に属する概念名を含む構造、及び前記第２の要素名の要素が前記概念階層構造上前記第２の概念名に属する概念名を含む構造が指定された第１の検索条件を含む第１の検索要求文を入力するステップと、
    前記概念階層構造から、前記第１の概念名に属する第１の概念名群と、前記第２の概念名に属する第２の概念名群とを求めるステップと、
    前記論理構造から、前記第１の概念名群のうちのいずれかを含む前記第１の要素名の要素と、前記第２の概念名群のうちのいずれかを含む前記第２の要素名の要素とを含む第１の検索結果の構造化文書群を求めるステップと、
    縦の各列の見出しが、前記概念階層構造上の前記第１の概念名の直下の各概念名であり、横の各列の見出しが、前記概念階層構造上の前記第２の概念名の直下の各概念名であるテーブル上の縦の列と横の列との交点にある各データセルで、前記第１の検索結果の構造化文書群のうち、前記第１の要素名の要素が当該縦の列の見出しの概念名に属する概念名を含み、かつ前記第２の要素名の要素が当該横の列の見出しの概念名に属する概念名を含む構造化文書の集計結果を示すとともに、縦の列の見出しを示す各見出しセルに、前記第１の要素名、前記第２の要素名、当該縦の列の見出しである概念名及び前記第２の概念名を含む検索条件のパラメータが対応付けられた、前記第１の検索結果を表示するための第１のテーブルを生成する第１の生成ステップと、
    前記第１のテーブルを表示手段で表示するステップと、
    表示された前記第１のテーブル上の縦の列の任意の見出しセルが指示されると、当該見出しセルに対応付けられている前記パラメータを用いて、前記第１の要素名、前記第２の要素名、当該縦の列の見出しである第３の概念名、前記第２の概念名、前記第１の要素名の要素が前記概念階層構造上前記第３の概念名に属する概念名を含む構造、及び前記第２の要素名の要素が前記概念階層構造上前記第２の概念名に属する概念名を含む構造が指定された第２の検索条件を含む第２の検索要求文を生成するステップと、
    前記概念階層構造から、前記第２の検索条件で指定されている前記第３の概念名に属する第３の概念名群と、前記第２の検索条件で指定されている前記第２の概念名に属する第２の概念名群とを求めるステップと、
    前記論理構造から、前記第３の概念名群のうちのいずれかを含む前記第１の要素名の要素と、前記第２の概念名群のうちのいずれかを含む前記第２の要素名の要素とを含む第２の検索結果の構造化文書群を求めるステップと、
    を実行させるためのプログラム。

Images