JP3842575B2 - 構造化文書検索方法、構造化文書管理装置及びプログラム - Google Patents
構造化文書検索方法、構造化文書管理装置及びプログラム Download PDFInfo
- Publication number
- JP3842575B2 JP3842575B2 JP2001098188A JP2001098188A JP3842575B2 JP 3842575 B2 JP3842575 B2 JP 3842575B2 JP 2001098188 A JP2001098188 A JP 2001098188A JP 2001098188 A JP2001098188 A JP 2001098188A JP 3842575 B2 JP3842575 B2 JP 3842575B2
- Authority
- JP
- Japan
- Prior art keywords
- search
- document
- structured document
- search request
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、異なる文書構造の複数の構造化文書を、階層化された論理構造を持つ構造化文書データベースで管理する構造化文書管理システムに関する。
【０００２】
【従来の技術】
現在、ＩＴ（情報技術）の進化により、莫大な量の情報が容易に入手できるようになった。その一方で必要な情報が大量のデータに埋没してしまい、十分に活用できないという弊害も発生している。情報が大量に存在していても、それをうまく活用できなければ意味がない。
【０００３】
そこで、特定の個人や部門が保有するノウハウや業務データのうち企業の経営に重要なものを蓄積して、「経営資産」として活用しようとする活動、すなわち、ナレッジマネージメントが提唱されている。
【０００４】
例えば、特許明細書や、週報など、文書の種類によっては、その書式が予め定められて、１つの書式に統一されているのが一般的である。１つの書式に統一された文書もあれば、全く書式のない自由書式の文書も数多く存在する。
【０００５】
従って、ナレッジマネージメントを実現するためには、このような文書構造が予め定められているような文書も、それ以外の自由書式の文書も全て格納管理できるデータベースが必要となる。
【０００６】
次世代のナレッジマネージメントの中核技術として期待されている技術がＸＭＬである。ＸＭＬ（Ｅｘｔｅｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）は柔軟な拡張性と連携性を備えた標準のドキュメント記述言語であり、主要ベンダーからのサポートも約束されている。
【０００７】
構造化文書データベースとしては、ＲＤＢ（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢｅｓｅ）により構造化文書を格納する方式があるが、この場合、１つのスキーマ（データ構造定義）に従った文書構造の構造化文書群しか格納できす、また、文書構造はそのまま表形式に変換することは困難であり、ＲＤＢをそのまま構造化文書データベースとして用いることはできない。
【０００８】
また、構造化文書は階層的な構造をもつため、構造化文書を構成する各構成要素をオブジェクトとみなしたＯＯＤＢ（オブジェクト指向データベース）と親和性が高いと考えられる。しかし、ＯＯＤＢでは、文書構造は予めスキーマにより決定されていなければならず、子要素の任意繰り返しなど、オブジェクトモデルでモデル化するのは困難であり、ＯＯＤＢをそのまま構造化文書データベースとして用いることはできない。
【０００９】
ＸＭＬ文書はツリー構造を持ったデータである。近年、このようなＸＭＬ文書を蓄積、管理するＸＭＬデータベースが脚光を浴びている。
【００１０】
ＸＭＬデータベースは、管理対象の複数の構造化文書の各構成要素を１つの巨大な構造化文書の文書構造を構成する構成要素として管理するＸＭＬ特化のツリー状の階層的なデータ構造を持つ。階層的な構造上の構成要素は「パス」により特定される。パスは、ＸＭＬデータベース上の特定のエリアを指し示すための手段である。
【００１１】
ＸＭＬデータベースに格納されるＸＭＬ文書群はツリー状の１つの巨大なＸＭＬ文書として構成される。部分的なＸＭＬ文書をアクセスするには、ＸＭＬ文書に対するパスというアクセス手段を用いる。このような特徴により、幅広くＸＭＬ文書を検索したり加工することが可能となる。
【００１２】
ＸＭＬデータベースで格納されるＸＭＬ文書の文書構造は、必ずしもスキーマが定義されている必要はないが、スキーマを定義するとしたら、１つのデータベースに１つのスキーマしか許容されていない。すなわち、スキーマを用いなければ、異なる文書構造の文書を混在させて格納・管理することができるが、スキーマを１つ設定したら、それとは異なる文書構造の文書は混在させることはできない。
【００１３】
【発明が解決しようとする課題】
異なる文書構造の膨大な数の構造化文書をデータベース上で格納・管理するには、ある特定の種類の文書に特定の文書構造が予め定められている場合、そのような種類の文書は、全て同じ文書構造に統一されている方が、後に、検索等のデータ操作の際に都合がよい。
【００１４】
しかし、従来のＸＭＬデータベースでは、１つのデータべース上で種類の違いにより異なる文書構造の文書をそれぞれの種類対応の文書構造で統一性を保持しながら、格納、管理できるものはなかった。すなわち、１つのスキーマに適合した文書の格納・管理はできても、複数のスキーマを混在させてスキーマ対応していない文書とともに、各スキーマ対応の文書の格納・管理はできなかった。
【００１５】
複数のスキーマのそれぞれに対応する複数のデータベースを設けることも考えられるが、この場合、スキーマが異なればアクセスするデータベースも異なる。そのため、多種多様な文書構造の膨大な数の文書へのアクセスが統一的でなく、多種多様な膨大な情報の中から関連する情報群を検索・抽出することが困難であった。
【００１６】
このように、従来は、多種多様な文書構造定義に従った文書を、その文書の種類対応に予め定められた文書構造の同一性を保持しながら、文書構造の定義がなされていない構造化文書とともに一元管理することができないがため、多種多様な文書構造の文書に対し、統一的なアクセスにて、多種多様な膨大な情報の中から関連する情報群を特定の文書構造に限定されずに検索・抽出することができなかった。
【００１７】
また、構造化文書データベースでは、文書構造や語彙を検索条件にして検索を行うようになっている。この場合、管理対象の文書の数が多くなればなるほど、検索時間に長時間を要する。従って、できるだけ、効率のよい検索を行うための手法を講じることが望ましい。特に、頻繁に用いられるような検索条件が存在する場合、そのような検索条件を含む検索を、要求を受けたたびに実行するのでは、効率が悪い。
【００１８】
また、構造化文書データベースには、異なる文書構造の数多くの構造化文書が随時追加あるいは削除されるであろう。このような構造化文書データベースの更新が頻繁に発生する状況下においては、構造化文書データベースの現状との整合性を保ちながら効率のよい検索が行えることが望ましい。
【００１９】
そこで、本発明は、構造化文書データベースに対する検索が効率よく行える構造化文書検索方法および、それを用いた構造化文書検索装置および構造化文書管理装置を提供することを目的とする。
【００２０】
また、本発明は、構造化文書データベースの現状との整合性を保ちながら検索が効率よく行える構造化文書検索方法および、それを用いた構造化文書検索装置および構造化文書管理装置を提供することを目的とする。
【００２１】
【課題を解決するための手段】
本発明は、異なる文書構造の複数の構造化文書を格納した階層化された論理構造を持つ構造化文書データベースに対して、前記論理構造を構成する前記構造化文書の構成要素とその値を検索条件に含む検索要求文に基づき検索を行うものであって、前記構造化文書データベースには、該構造化文書データベースに対し検索を行うための予め前記検索条件の設定された複数の検索要求文が格納され、前記複数の検索要求文のうちの１つを指定した検索要求を受け付けたとき、前記指定された検索要求文に基づき検索を行って、得られた検索結果を要求元に送るとともに、該検索結果を該検索要求文に対応付けて記憶し、前記検索要求を受け付けたときに、前記指定された検索要求文に対応付けて検索結果が記憶されているときは、その記憶されている検索結果を読み出して要求元に送ることを特徴とする。
【００２２】
本発明によれば、例えば、頻繁に用いられる検索条件のクエリであるとか、予め検索が予想されるクエリ、複数のユーザからユーザグループ内である特定の用途のために用いるクエリなどを構造化文書データベースに予め格納しておき、そのようなクエリの検索が実行されたときは、その結果結果を当該クエリに対応付けて記憶しておくことにより、その後に、再び同じクエリによる検索要求がなされたときは、実際に検索を行わず、記憶した検索結果を要求元へ返すことにより、構造化文書データベースに対する検索が効率よく行える。
【００２３】
本発明は、異なる文書構造の複数の構造化文書を格納した階層化された論理構造を持つ構造化文書データベースに対して、前記論理構造を構成する前記構造化文書の構成要素とその値を検索条件に含む検索要求文に基づき検索を行うものであって、前記構造化文書データベースには、該構造化文書データベースに対し検索を行うための予め検索条件の設定された複数の検索要求文が格納され、前記検索要求文には、少なくともその検索要求文に基づく検索実行が許可されている第１の種別のユーザと、該検索要求文に基づく検索実行は許可されていないが該検索要求文対応の検索結果は参照することが許可されている第２の種別のユーザとが設定され、前記第１の種別のユーザから、前記複数の検索要求文のうちの１つを指定した検索要求を受け付けたとき、前記指定された検索要求文に基づき検索を行って、得られた検索結果を要求元に送るとともに、該検索結果を該検索要求文に対応付けて記憶し、前記第２の種別のユーザから前記検索要求を受け付けたときは、前記指定された検索要求文に対応付けて記憶されている検索結果を読み出して要求元に送ることを特徴とする。
【００２４】
本発明によれば、ある特定のユーザ（第１の種別のユーザ）のみに、クエリの検索実行の権限を与えて、この権限のあるユーザからの検索要求に対しては、実際に検索を行って、当該クエリに対応付けて記憶した検索結果の更新を行うことにより、構造化文書データベースの更新内容が検索結果に反映することができ、構造化文書データベースの現状との整合性を保ちながら検索が効率よく行える。
【００２５】
好ましくは、前記第１の種別のユーザから前記検索要求を受け付けたとき、前回検索を実行した時点から所定時間経過しているときは、前記指定された検索要求文に基づき検索を行い、前記所定時間が経過していないときは、前記指定された検索要求文に対応付けて記憶されている検索結果を読み出す。これにより、ある特定のユーザ（第１の種別のユーザ）のみに、クエリの検索実行の権限を与えて、定期的に当該クエリに対応付けて記憶した検索結果の更新を行うことにより、構造化文書データベースの更新内容が検索結果に反映することができ、構造化文書データベースの現状との整合性を保ちながら検索が効率よく行える。
【００２６】
このように、クエリ毎に当該クエリを実行させることが可能なユーザと、当該クエリにより検索結果を参照することが可能なユーザとを限定することにより、例えば、だれもかれもが、むやみやたらに検索を実行して、同じクエリによる検索結果であるのに、（データベースの内容が更新されていることにより）検索結果が様々になってしまうことを防ぐことができる。
【００２７】
また、少なくとも上記所定時間の間は、誰が要求をしても同じクエリによる検索結果が同じであるという好ましい状態を作り出すことができる。これは、検索結果とデータベースの内容の整合性と保つためには重要なことである。
【００２８】
また、好ましくは、前記構造化文書データベースが更新されたとき、該構造化文書データベースに格納されている前記複数の検索要求文のうち、該構造化文書データベースの更新内容が検索結果に影響するような検索要求文を選択して、その選択された検索要求文に基づき前記構造化文書データベースに対し検索を行って、該検索要求文に対応付けて記憶された検索結果を更新することにより、構造化文書データベース自体の更新に伴い、その更新を検索結果に自動的に反映させることができる。従って、検索結果とデータベースの内容の整合性を保つことが容易に行える。
【００２９】
【発明の実施の形態】
まず、本発明の実施形態について説明する前に、構造化文書管理システムについて説明する。
【００３０】
（構造化文書管理システムの説明）
構造化文書として、ＸＭＬやＳＧＭＬなどで記述した文書が挙げられる。ＳＧＭＬ（Ｓｔａｎｄａｒｄ Ｇｅｎｅｒａｌｉｚｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）とは、ＩＳＯ（国際標準化機構）で定められた規格である。ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）とは、Ｗ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）にて定められた規格である。それぞれ文書を構造化することを可能とする構造化文書規約である。
【００３１】
以下、構造化文書として、ＸＭＬにて記述された文書を例に説明を進める。構造化文書の文書構造を定義したデータ（文書構造定義データ）をスキーマと呼ぶ。ＸＭＬではそのスキーマを定義するためにＸＭＬ−ＳｃｈｅｍａやＸＤＲ（ＸＭＬ Ｄａｔａ Ｒｅｄｕｃｅｄ）などのスキーマ言語が提案されている。ここでは、例えば、ＸＤＲでのスキーマを記述する場合を例にとり説明する。
【００３２】
スキーマも、構造化文書管理システムの管理対象の構造化文書であり、従って、スキーマ文書と呼ぶことがある。スキーマ文書と区別するために、特許明細書やメール、週報、広告などの種々雑多な内容を有す文書をコンテンツ文書と呼ぶこともある。
【００３３】
構造化文書管理システムでは、上記スキーマ文書、上記コンテンツ文書、さらに、後述するようなユーザからの検索要求内容を記述したクエリ、すなわち、クエリ文書も管理対象とし、これらを総称して「文書」と呼ぶ。
【００３４】
以下、特にことわりがない場合、「文書」と呼ぶときは、コンテンツ文書、スキーマ文書、クエリ文書を全て指すものとする。
【００３５】
まず、実施形態の説明を前に、ＸＭＬについて簡単に説明する。
【００３６】
図３は、ＸＭＬで記述された構造化文書の一例として、「特許」情報の例を示したものである。ＸＭＬやＳＧＭＬは、文書の構造の表現にタグが用いられる。タグには、開始タグと終了タグがあり、文書構造情報の構成要素を開始タグと終了タグで囲むことにより、文書中の文字列（テキスト）区切りと、そのテキストが構造上どの構成要素に属するのかを明確に記述することができる。
【００３７】
ここで開始タグとは要素名称を記号「＜」、「＞」で閉じたものであり、終了タグとは要素名称を記号「＜／」と「＞」で閉じたものである。タグに続く構成要素の内容が、テキスト（文字列）または子供の構成要素の繰り返しである。また開始タグには「＜要素名称 属性＝“属性値”＞」などのように属性情報を設定することができる。「＜特許ＤＢ＞＜／特許ＤＢ＞」のようにテキストを含まない構成要素は、簡易記法として「＜特許ＤＢ／＞」のように表わすこともできる。
【００３８】
図３に示した文書は、「特許」タグから始まる要素をルート(根)とし、その子要素として「タイトル」、「出願日」、「出願者」、「要約」タグから始まる要素集合が存在する。また、例えば、「タイトル」タグから始まる要素には「ＸＭＬデータベース」といった、１つのテキスト（文字列）が存在する。
【００３９】
ＸＭＬなどの構造化文書は、任意の構成要素を繰り返し含んでいたり、さらには文書構造があらかじめ決まっていない（ＲＤＢ（リレーショナルデータベース）やＯＯＤＢ（オブジェクト指向データベース）のスキーマでは定義できない）のが普通である。
【００４０】
図３に示したような構造化文書を論理的に表現するために、図４に示すようなツリー表現が用いられる。ツリーは、ノード（番号が付され、円形で示されたもの）とアーク（ノードを表す円形間をつなぐデータ付き線）と四角形で囲まれたテキストから構成されている。
【００４１】
ノードは文書オブジェクトに対応し、ノードからタグ名や属性名に相当するラベルが付与された複数のアークが出てきている。そのアークの先は、ノードまたは要素値としての文字列（テキスト）である。ノードの中に記載されている英数字（＃０、＃４９）などはオブジェクトＩＤである。
【００４２】
図４に示したツリー構造を図３に示した構造化文書の文書オブジェクトツリーと呼ぶ。
【００４３】
図１は、本実施形態に係る構造化文書管理システムの構成例を示したものである。図１において、構造化文書管理システムは、大きく分けて、要求制御部１、アクセス要求処理部２、検索要求処理部３、データアクセス部４、文書記憶部５、インデックス記憶部６から構成されている。文書記憶部５、インデックス記憶部６は例えば、外部記憶装置を用いて構成される。
【００４４】
図１のシステム構成は、ソフトウエアを用いて実現可能である。
【００４５】
要求制御部１は、要求受付部１１と結果処理部１２から構成されている。要求受付部１１は、ユーザからの文書格納や文書取得、文書検索などの要求を受け付けて、アクセス要求処理部２を呼び出す。結果処理部１２は、アクセス要求処理部２が処理した結果を要求元のユーザに返す処理を行う。
【００４６】
アクセス要求処理部２は、ユーザからの文書格納や文書取得などの要求に対応した複数の処理部から構成されている。つまり、文書格納部２１、文書取得部２２、文書削除部２３から構成されている。
【００４７】
文書格納部２１は、文書記憶部５中の論理的な指定エリアに文書を格納する処理を行う。
【００４８】
文書取得部２２は、文書記憶部５中の論理的なエリアが指定されたときに、その指定エリアに存在する文書を取得する処理を行う。
【００４９】
文書削除部２３は、文書記憶部５中の論理的な指定エリアに存在する文書を削除する処理を行う。
【００５０】
文書記憶部５は、構造化文書データベースであり、例えば、図８に示すように、文書をＵＮＩＸのディレクトリ構造のように階層的にツリー構造状に格納している。
【００５１】
図８に示すように、構造化文書データベースは、図４に示したような１つの構造化文書のツリー構造と同様に表現できる。すなわち、任意のノード以下の部分階層木（部分ツリー）は、構造化文書データベースから切り出された構造化文書であり、ここでは、これを文書オブジェクトツリーと呼ぶ。各ノードにはオブジェクトＩＤが割り当てられている。オブジェクトＩＤは、構造化文書データベース内ではユニークな数値を持つものとする。
【００５２】
階層木のルートとなるノードには、それがルートノードであることを特定するためのオブジェクトＩＤ「＃０」が割り当てられるものとする。
【００５３】
ルートノード、すなわち、「＃０」のノードからは「ｒｏｏｔ」タグを先頭に持つ「＃１」のノードへリンクが張られている。「＃１」のノードからは、「特許ＤＢ」タグを先頭にもつ「＃２」ノードへのリンクが張られている。「＃２」ノードからは、「特許」タグを先頭に持つ「＃４２」ノード、「＃５２」ノード、「＃６２」ノードへのリンクがそれぞれ張られている。
【００５４】
図３に示した「特許」情報は、「＃４２」ノード以下の部分ツリーに対応している。このノードからは「タイトル」タグ、「出願者」タグ、「要約」タグなどを先頭にもつノードへリンクが張られ、末端のノードからは、「ＸＭＬデータベース」、「Ｔ社」。「ＸＭＬを統一的に管理するデータベースを提供する…」などの文字列（要素値）へのリンクが張られている。
【００５５】
「＃５２」ノード以下の部分ツリー、「＃６２」ノード以下の部分ノードも１つの「特許」情報に対応する部分である。
【００５６】
ところで、例えば、「＃４３」ノードにリンクされた「ＸＭＬデータベース」という要素値は、「＃４３」ノードと「＃ｖａｌｕｅ」という特殊なタグ名で接続されている。このタグ名は、「＃」で始まるためＸＭＬ規格においては標準的なタグ名として利用することはできない。
【００５７】
このような構造化文書データベースの特定ノードを指定するために構造化文書パスを用いる。構造化文書パスは「ｕｉｘ：／／ｒｏｏｔ」から始まる文字列である。ｕｉｘ（Ｕｎｉｖｅｒｓａｌ Ｉｄｅｎｔｉｆｉｅｒ ｆｏｒ ＸＭＬ）は構造化文書パスであることを示す前置文字列である。
【００５８】
例えば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」は、「＃１」ノードから「特許ＤＢ」が付与されたアークが指し示すノード、つまり「＃２」ノードに対応する。このように「ｒｏｏｔ」から「／」で区切られた部分文字列をタグ名とみなすことで「＃０」ノードからタグ名の並びに沿って対応するアークを下っていき、その最後のアークが指すノードが、パスの場所を指し示す。
【００５９】
例えば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許」は、「＃４２」ノード、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／出願日／年」は、「＃４５」ノードを指し示す。
【００６０】
「＃２」ノード以下に、すなわち、「特許ＤＢ」に、複数の「特許」情報を格納する場合には、個々の「特許」情報を識別するために、構造化文書パスにインデックス表現が可能である。
【００６１】
「特許ＤＢ」の最初の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」となるが、これは「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許」と同じとみなす。
【００６２】
「特許ＤＢ」の２番目の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［１］ＤＢ」の５番目の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［４］」となる。
【００６３】
インデックス記憶部６には検索時に用いる、要素名称生起インデックスとデータ生起インデックスが記憶されている。
【００６４】
要素名生起インデックスとは構造化文書データベースに格納されている要素名称のリストと、各要素名称が先頭にある構造化文書（文書オブジェクトツリー）の位置とを関連付けてインデックスファイル化したものである。例えば、図８の構造化文書データベースのように、（「特許」情報に対応する）「特許」という要素名称が「＃４２」ノード以下の構造化文書、「＃５２」ノード以下の構造化文書、「＃６２」ノード以下の構造化文書に存在する場合、これらをインデックス化すると、図９に示すように、それらの親ノード、「＃２」ノードが、要素名称生起インデックスファイルに「特許」キーからのチェーンで格納される。
【００６５】
このように、親ノードでインデックス化すると、インデックスファイルを圧縮することができる。すなわち、親ノードでインデックス化すれば、子ノードが増大しようとも、親ノードで代用しているので、チェーンサイズは増大しない。これに対し、実ノードをインデックス化すれば「特許」情報の格納数の増大とともにチェーンサイズはそれに比例して増加してしまう。
【００６６】
データ生起インデックスとは、構造化文書データベースに格納されている文字列データのリストと各文字列データがある構造化文書（文書オブジェクトツリー）の位置とを関連付けてインデックスファイル化したものである。例えば、図８の構造化文書データベースのように、「ＸＭＬ」という文字列データ（および、「ＸＭＬ」という文字列を含む文字列）が「＃４３」ノード以下の構造化文書、「＃４９」ノード以下の構造化文書に存在する場合、これらをインデックス化すると、図１０に示すように、「＃４３」ノード、「＃４９」ノードが、データ生起インデックスファイルに「ＸＭＬ」キーからのチェーンで格納される。
【００６７】
なお、逆階層インデックスなど、その他のインデックスファイルを用いてもよい。逆階層インデックスとは、あるノードとその親ノードとの対応を格納したものである（あるノードからその親ノードを求めることができる）。
【００６８】
文書記憶部５中の論理的な指定エリアとは、ユーザにより構造化文書パスを用いて指定された文書の格納場所を指す。構造化文書パスは、ユーザにとって認識可能な表現である。
【００６９】
図１の説明に戻る。
【００７０】
データアクセス部４は、文書記憶部５をアクセスする基本インターフェイスの集合である。データアクセス部４は、文書オブジェクトツリー格納部４７、文書オブジェクトツリー削除部４８、文書オブジェクトツリー取得部４９、文書文字列取得部４４、パスから文書オブジェクトツリー取得部４５、文書パーサ部４６、合成文書作成部４７、インデックス更新部４８から構成される。
【００７１】
文書オブジェクトツリー格納部４１は、文書記憶部５中の物理的な指定エリアに文書オブジェクトツリーを格納する処理を行う。
【００７２】
文書オブジェクトツリー削除部４２は、文書記憶部５中の物理的な指定エリアに存在する文書オブジェクトツリーを削除する処理を行う。
【００７３】
文書オブジェクトツリー取得部４３は、文書記憶部５中の物理的な指定エリアに存在する文書オブジェクトツリーを取得する処理を行う。
【００７４】
文書文字列取得部４４は、文書オブジェクトツリーを構造化文書（ＸＭＬ文書）に変換する処理を行う。
【００７５】
パスから文書オブジェクトツリー取得部４５は、構造化文書パスを解析して文書記憶部５中の物理的なエリアを特定して、そのエリアに存在する文書オブジェクトツリーを取り出す処理を行う。
【００７６】
文書パーサ部４６は、ユーザにより入力された構造化文書を読み込んで構文解析して整合性の検査を行い、さらに文書構造定義データであるスキーマが存在すれば構造的に妥当かどうかの検証を行う。出力結果は文書オブジェクトツリーとなる。文書パーサは、通常、ｌｅｘ（ｌｅｘｉｃａｌ ａｎａｌｙｚｅｒ ｇｅｎｅｒａｔｏｒ）といったレキシカルアナライザ（字句解析を行い，トークンに分解する）とｙａｃｃ（ｙｅｔ ａｎｏｔｈｅｒ ｃｏｍｐｉｌｅｒ ｃｏｍｐｉｌｅｒ）といったパーサジェネレータを組み合わせて構築することができる。
【００７７】
合成文書作成部４７は、文書格納や文書削除などをする際に、スキーマに合致しているかどうか検査しなければならないが、この検査時に必要となるデータを作成して出力する。
【００７８】
インデックス更新部４８は、文書格納や文書削除などにより、構造化文書データベースの格納内容が更新されるたびに、図９、図１０に示した要素名称生起インデックスとデータ生起インデックスを更新する。
【００７９】
文書記憶部５中の物理的な指定エリアとは、ファイルオフセットやオブジェクトＩＤなどの構造化文書データベース内ではユニークな文書データの存在場所を指し示す内部データである。ユーザにとっては認識不能なデータである。
【００８０】
文書記憶部５中に格納された文書を検索する処理を行う。要求制御部１の要求受付部１１でユーザからの文書検索の要求が受け付けられると、検索要求処理部３には、要求受付部１１からクエリ言語で記述されたクエリ文書が入力する。そしてデータアクセス部４を通してインデックス記憶部６，文書記憶部５にアクセスし、検索要求に合致する文書集合を取得して、その結果を結果処理部１２を介して出力する。
【００８１】
図２は、図１に示した構造化文書管理システムの一利用形態を示したもので、図２では、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）のバックエンドで、図１に示した構成の構造化文書管理システム１００が動作している場合を示している。
【００８２】
複数（ここでは、例えば３つ）のクライアント端末（例えばパーソナルコンピュータ、携帯通信端末など）１０２のそれぞれでＷＷＷブラウザ１０３が動作している。ユーザは、各クライアント端末からＷＷＷサーバ１０１にアクセスすることにより、構造化文書管理システム１００にアクセスすることができる。ＷＷＷブラウザ１０３とＷＷＷサーバ１０１とは、ＨＴＴＰ（Ｈｙｐｅｒ ＴｅｘｔＴｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）で通信している。また、ＷＷＷサーバ１０１と構造化文書管理システム１００とは、ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）またはＣＯＭ（Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）などで通信している。
【００８３】
ユーザからの文書格納、文書取得、文書検索などの要求は、ＷＷＷブラウザ１０３から送信されて、ＷＷＷサーバ１０１を通して構造化文書管理システム１００にて受け付けられ、処理された結果は、ＷＷＷサーバ１０１を通して要求元のＷＷＷブラウザ１０３へ返信される。
【００８４】
以下、図１の構造化文書管理システムの（１）格納機能、（２）検索機能について詳細に説明する。そして、（３）適用例では、概念検索を用いた特許調査の場合を例にとり説明する。
【００８５】
（１） 格納機能
図１の構造化文書管理システムにおける格納系のコマンドには以下のものがある。
【００８６】
ｉｎｓｅｒｔＸＭＬ（パス、Ｎ番目、ＸＭＬ）：文書格納
ａｐｐｅｎｄＸＭＬ（パス、ＸＭＬ） ：文書格納
ｇｅｔＸＭＬ（パス） ：文書取得
ｒｅｍｏｖｅＸＭＬ（パス） ：文書削除
ｓｅｔＳｃｈｅｍａ（パス、スキーマ） ：スキーマ格納
ｇｅｔＳｃｈｅｍａ（パス） ：スキーマ取得
「ｉｎｓｅｒｔＸＭＬ」は、（ ）内に指定した構造化文書パス以下のＮ番目に文書を挿入するコマンド（以下、簡単に挿入コマンドと呼ぶ）である。
【００８７】
「ａｐｐｅｎｄＸＭＬ」は、（ ）内に指定した構造化文書パス以下の最後に文書を挿入するコマンド（以下、簡単に追加コマンドと呼ぶ）である。
【００８８】
「ｇｅｔＸＭＬ」は、（ ）内に指定した構造化文書パス以下の文書を取り出すコマンド（以下、簡単に取得コマンドと呼ぶ）である。
【００８９】
「ｒｅｍｏｖｅＸＭＬ」は、（ ）内に指定した構造化文書パス以下の文書（スキーマ文書以外の文書で、主に、コンテンツ文書）を削除するコマンド（以下、簡単に削除コマンドと呼ぶ）である。
【００９０】
「ｓｅｔＳｃｈｅｍａ」は、（ ）内に指定した構造化文書パスにスキーマを設定するコマンド（以下、簡単にスキーマ格納コマンドと呼ぶ）である。
【００９１】
「ｇｅｔＳｃｈｅｍａ」は、（ ）内に指定した構造化文書パスに設定されているスキーマを取り出すコマンド（以下、簡単にスキーマ取得コマンドと呼ぶ）である。
【００９２】
上記コマンドのうち、挿入コマンド、追加コマンド、スキーマ格納コマンドについての処理はアクセス要求処理部２の文書格納部２１で実行され、取得コマンド、スキーマ取得コマンドについての処理は文書取得部２２で実行され、削除コマンドについての処理は文書削除部２３で実行される。
【００９３】
図５を参照して、構造化文書データベースの初期状態（図５（ａ）参照）において、追加コマンドを実行する場合について説明する。
【００９４】
図５（ａ）に示すように、「＃０」ノードと「＃１」ノードが「ｒｏｏｔ」アークで接続されている初期状態に対して、
「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」
を実行した結果、図５（ｂ）に示すように、「＃２」ノードと「特許ＤＢ」アークが作成される。
【００９５】
図５（ｂ）に示した状態の構造化文書データベースに対して、取得コマンドを実行する場合について説明する。
【００９６】
例えば、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”）」を実行すると、図５（ｂ）の「ｒｏｏｔ」アークが示す「＃０」ノード以下の文書オブジェクトツリーが取り出され、それをＸＭＬの文字列表現に変換する。その結果、図６に示すように、「＜ｒｏｏｔ＞＜特許ＤＢ／＞＜／ｒｏｏｔ＞」なる文字列が取り出される。取得コマンドの処理は、アクセス要求処理部２の文書取得部２２にて実行される。
【００９７】
次に、図５（ｂ）に示した状態の構造化文書データベースに対して、図３に示すようなコンテンツ文書（ＸＭＬ文書）としての「特許」情報を格納するための追加コマンドを実行する場合について説明する。すなわち、この場合、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」を実行する。このコマンド中「“＜特許＞…＜／特許＞”」が、図３に示した「特許」情報に対応する。
【００９８】
上記追加コマンドの処理が実行されると、図７に示すように、「＃２」ノード以下に「＃４２」ノードをトップとする文書オブジェクトツリー（図４に対応）が追加される。
【００９９】
図５（ｂ）に示した状態の構造化文書データベースに対して、次に示すような追加コマンドを３回繰り返して実行したとする。
【０１００】
「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」
上記コマンド中、「＜特許＞…＜／特許＞」は、図３に示した文書構造のコンテンツ文書に対応する。
【０１０１】
すると、図８に示すように、「＃２」ノード以下に「＃４２」ノード、「＃５２」ノード、「＃６２」ノードをトップとする文書オブジェクトツリーが追加される。
【０１０２】
次に、図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合について説明する。この場合、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」を実行する。すると、「特許ＤＢ」アークが示す「＃２」ノード以下の文書オブジェクトツリーが取り出され、それをＸＭＬの文字列表現（ＸＭＬ文書）に変換する。その結果、図１１に示すように、「＜特許ＤＢ＞＜特許＞…＜／特許＞＜特許＞…＜／特許＞＜特許＞…＜／特許＞＜／特許ＤＢ＞」なる文字列が取り出される。
【０１０３】
構造化文書データベースでは、上記の「特許」情報などのコンテンツ文書（ＸＭＬ文書）の文書構造を定義したデータ、すなわち、スキーマも管理対象とする。
【０１０４】
図１２は、ＸＭＬ文書の文書構造を定義するスキーマの一例を示したものである。ここでは、ＸＭＬの文書構造定義言語の一つであるＸＤＲ（ＸＭＬ−Ｄａｔａ Ｒｅｄｕｃｅｄ）を取り上げる。もちろん、ＸＭＬ−Ｓｃｈｅｍａなど他の文書構造定義言語を用いてもかまわない。
【０１０５】
図１２に示したスキーマは、図３に示した「特許」情報の文書構造をＸＤＲで定義したものである。図１２からも容易に分かるとおり、スキーマもＸＭＬ形式の構造化文書である。「Ｓｃｈｅｍａ」タグから始まる構成要素から始まり、その子要素として、「ＥｌｅｍｅｎｔＴｙｐｅ」タグから始まる要素集合が存在する。
【０１０６】
図１２に示したスキーマにおいて、例えば、最初の「ＥｌｅｍｅｎｔＴｙｐｅ」タグから始まる子要素は以下の情報を意味している。
【０１０７】
・「特許」タグを持つ要素の文書構造定義（「ＥｌｅｍｅｎｔＴｙｐｅ ｎａｍｅ＝”特許”」）である。
【０１０８】
・子要素は要素だけ（「ｃｏｎｔｅｎｔ＝”ｅｌｔＯｎｌｙ”」）である。
【０１０９】
・「タイトル」、「出願日」、「要約」タグから始まる子要素から構成される（「ｅｌｅｍｅｎｔ ｔｙｐｅ＝”タイトル”、…」）。さらに、その順番は一意に決まっている（「ｏｒｄｅｒ＝”ｓｅｑ”」）。
【０１１０】
・上記「特許」タグから始まる要素の文書構造定義の他に、「タイトル」「出願者」「要約」「年」「月」「日」「出願日」の文書構造定義を記述している。すなわち、「出願日」を除く、「タイトル」「出願者」「要約」「年」「月」「日」タグから始まる構成要素の子要素はテキストだけと定義されている（「ｃｏｎｔｅｎｔ＝”ｔｅｘｔＯｎｌｙ”」）。
【０１１１】
・「出願日」タグから始まる構成要素の子要素は、「年」、「月」、「日」の並びである。
【０１１２】
図８に示した状態の構造化文書データベースに対して、図１２に示したスキーマ文書を格納するためのスキーマ格納コマンドを実行する場合について説明する。この場合、「ｓｅｔＳｃｈｅｍａ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”）」を実行する。このコマンド中、「“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”」」が図１２に示したスキーマ文書に対応する。
【０１１３】
上記コマンドの実行により、図１３に示すように、「＃２」ノード以下に「＃ｓｃｈｅｍａ」アークが追加され、その先には、「＃３」ノードをトップノードとする文書オブジェクトツリーが追加される。スキーマ自身がＸＭＬ文書表現になっているため、前述した「特許」情報のようなコンテンツ文書格納のケースと同様にツリー展開可能である。
【０１１４】
図１３において、「＠ｎａｍｅ」など「＠」で始まるアークは属性に対応する。タグ名「＃ｓｃｈｅｍａ」も「＃」、「＠」で始まるためＸＭＬ規格においては標準的なタグ名として利用することはできない。
【０１１５】
「＃２」ノード下に図１２に示したスキーマ文書が格納されたことにより、以後、「＃２」ノード以下にこれから格納される文書の文書構造は、図１２に示したスキーマ文書により定義された文書構造に適合することが要求される。すなわち、「＃２」ノード以下に図１２に示したスキーマが設定されることになる。
【０１１６】
「＃２」ノード以下に図１２に示したスキーマが設定されると、図１４に示すように、「＃２」ノードの文書オブジェクトのファイルには、「＃２」ノード以下の文書オブジェクトツリーには、当該スキーマが存在する旨の属性値がセットされる。
【０１１７】
「＃２」ノード以下に図１２に示したスキーマが設定された後に、このスキーマで定義された文書構造に一致する図３に示したような「特許」情報を、図１４に示したように、文書オブジェクトツリーとして構造化文書データベースに格納したとき、この文書の文書構造には図１２に示したスキーマが存在する旨の属性値が、当該文書オブジェクトツリーを構成する各文書オブジェクトにセットされる。例えば、当該文書オブジェクトツリーを構成する各文書オブジェクトのファイルに対して、スキーマが存在している旨の属性値（例えば、「スキーマ適合有無」）に「１」がセットされる。図１４では、スキーマに適合している各文書オブジェクト（ノード）は２重丸で示している。２重丸で示した各文書オブジェクトには、その文書オブジェクトに対応した文書構造定義が存在することになる。
【０１１８】
図１５は、各文書オブジェクトのファイルの内容を概念的に示したもので、例えば、オブジェクトＩＤが「＃４２」の文書オブジェクトのファイルには、その文書オブジェクトにリンクされている他の文書オブジェクトに関する情報（例えば、アークや、リンク先の文書オブジェクトへのポインタ値など）とともに、上記属性値が記述されている。なお、当該文書オブジェクトに適用するスキーマが存在しないときは、「スキーマ適合有無」の値は「０」となる。
【０１１９】
図１６、図１７は、図１の構造化文書管理システムで、必要に応じて検索で使用される概念階層を構造化文書で表現した例を示す。図１６、図１７に示す「概念」情報はＸＭＬで記述したコンテンツ文書である。
【０１２０】
図１６に示した「概念」情報の例は、いわゆる特許調査における特許文書の内容を分類するための１つの分類軸として用いる「情報モデル」を概念階層で表現している。「概念」タグで囲まれた「概念」情報は、入れ子構造を持った文書構造をもっている。つまり、図１６の例では、概念「情報モデル」の子供概念として、概念「ドキュメント」、概念「リレーション」、概念「オブジェクト」が存在している。また、概念「ドキュメント」の子供概念として、概念「構造化訴求メント」、概念「非構造化ドキュメント」が存在し、さらに、概念「構造化ドキュメント」の子供概念として、概念「ＸＭＬ」、概念「ＳＧＭＬ」が存在している。
【０１２１】
図１７に示す「概念」情報の記述例は、図１６とは異なる分類軸「情報操作」を概念階層で表現している。図１７の例では、概念「情報操作」の子供概念として、概念「検索」、概念「格納」、概念「加工」、概念「流通」が存在している。
【０１２２】
図１６，図１７に示したような「概念」情報も、前述の「特許」情報と同様にして、構造化文書データベース内に格納することができる。すなわち、例えば、まず、図８に示した状態の構造化文書データベースに対して、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜概念ＤＢ／＞”）」を実行して、図１８に示すように、「＃２０１」ノードと「概念ＤＢ」アークが作成される。この状態において、図１６に示した「概念」情報を格納する場合には、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／概念ＤＢ”，“＜概念名前＞…＜／概念＞”）」を実行する。このコマンド中「“＜概念名前＞…＜／概念＞”」が、図１６に示した「概念」情報に対応する。
【０１２３】
上記追加コマンドの処理が実行されると、図１９に示すように、「＃２０１」ノード以下に「＃２０２」ノードをトップとする文書オブジェクトツリーが追加される。
【０１２４】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。そのため、部分的なＸＭＬ文書をアクセスするには巨大なＸＭＬ文書に対するパスという文書構造に依存しない統一的なアクセス手段を用いることにより、幅広くＸＭＬ文書を検索したり加工したりすることが可能になる。
【０１２５】
また、構造化文書データベース上の一部にスキーマを設定することで、格納しようとする文書の文書構造がそのスキーマにより定義されている文書構造に一致するか否かの妥当性のチェックが自動的に行なえる（後述）。
【０１２６】
（１−１）文書格納処理
次に、図１の構造化文書管理システムの文書格納処理動作について、図２０に示すフローチャートを参照して説明する。
【０１２７】
クライアント端末から構造化文書管理システムに対し、文書格納要求として、挿入コマンド、追加コマンド、スキーマ格納コマンドのうちのいずれかが送信されて、要求受付部１１にて受け付けられたとき、図２０に示した処理動作を行う。
【０１２８】
クライアント端末の所定の表示装置には、構造化文書管理システム１００（の例えば、要求制御部１）から提供された、例えば、図３１に示すようなユーザインターフェイスとしての画面が表示されている。
【０１２９】
図３１に示す画面には、構造化文書管理システム１００への操作項目の一覧（メニュー）が表示されている。操作項目として、「ＸＭＬ登録／削除」、「スキーマ設定」、「ＸＭＬ検索」とがある。
【０１３０】
ユーザが例えば、この画面上で「ＸＭＬ登録／削除」をマウス等のポインティングデバイスなどを用いて選択すると、図３２に示したような文書の格納／削除を行うためのユーザインタフェースとしての画面が表示される。
【０１３１】
図３２において、領域Ｗ１には、文書構造化文書データベースの現在のツリー構造の要素名（タグ名）がユーザが理解可能なように簡略的に表示されている。なお、図３２では、上位階層の要素名のみを表示しているが、末端の要素名まで表示可能である。また、領域Ｗ２は、構造化文書パスの入力領域であり、領域Ｗ１の表示内容に従って、構造化文書パスを入力するようになっている。また、領域Ｗ３は、格納する文書を入力したり、取得した文書を表示するようになっている。
【０１３２】
例えば、構造化文書パスとして「ｒｏｏｔ」を入力する場合には、領域Ｗ１の「ｒｏｏｔ」をマウス等で選択すればよい。すると、図３２に示すように、領域Ｗ２の構造化文書パスの入力領域に「ｕｉｘ：／／ｒｏｏｔ」と表示される。また、新たに、「特許ＤＢ」という要素を追加する場合は、図３２に示すように、領域Ｗ３に、「特許ＤＢ」を入力する。そして、「登録」ボタンＢ１を選択すると、クライアント端末からａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」なる追加コマンドが構造化文書管理システムへ送信される。構造化文書管理システムでは、上記追加コマンドを受け、後述するような処理を実行した結果、例えば、図５（ｂ）に示すように、「＃２」ノードと「特許ＤＢ」アークが作成される。また、領域Ｗ１には、図３３に示すように、「ｒｏｏｔ」の下に「特許ＤＢ」が追加表示される。
【０１３３】
さて、ユーザが図３４に示したような文書の格納／削除画面上の領域Ｗ３に、例えば、文書「＜Ａ＞データ＜／Ａ＞」を入力し（あるいはＣＤ−ＲＯＭ等の所定の記録媒体等から読み込むことにより入力し）、領域Ｗ１の「特許［０］」をマウス等で選択すると、構造化文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」と表示される。そして、「登録」ボタンＢ１を選択すると、クライアント端末からａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０１３４】
ここでは、例えば、構造化文書データベースが、図１４に示した状態のときに、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］”，“＜Ａ＞データ＜／Ａ＞”）」なる追加コマンドを受け付けた場合を例にとり説明する。
【０１３５】
要求受付部１１は、上記追加コマンドを受け付けると、上記追加コマンド中の２つのパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」と文書「＜Ａ＞データ＜／Ａ＞」（以下、格納文書と呼ぶ）とを文書格納部２１へ渡す（ステップＳ１）。
【０１３６】
まず、文書格納部２１は、文書パーサ部４６に格納文書を渡す。文書パーサ部４６は、格納文書を読み込んで、構文解析を行い、当該格納文書の文書構造がＸＭＬにて規定された正しい形式であるか否かの整合性の検査を行う（ステップＳ２）。
【０１３７】
この整合性の検査でエラーが見つかれば（ステップＳ３）、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す（ステップＳ４）。
【０１３８】
整合性の検査でエラーが見つからなければ、次に、文書格納部２１は、パスから文書オブジェクトツリー取得部４５へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部４５は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ０）を含む文書オブジェクトツリーを取り出す（ステップＳ５）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ０のオブジェクトＩＤを取得することができるので（ステップＳ６）、その場合は、ステップＳ８へ進む。
【０１３９】
例えば、上記追加コマンドの場合、「＃４２」ノードが文書オブジェクトＯｘ０となるので、そのオブジェクトＩＤとして、「＃４２」を取得するとともに、この「＃４２」ノードを含む文書オブジェクトツリー（例えば、「＃４２」ノードの全ての子孫ノードと「＃４２」ノードと同じ階層にある全ての（兄弟）ノードと、「＃４２」ノードの親ノードである「＃２」ノードとからなる文書オブジェクトツリー）を取得する。
【０１４０】
指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ０が見つからなければ、エラーとなり（ステップＳ６）、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す（ステップＳ７）。
【０１４１】
例えば、構造化文書データベースが、図１８に示した状態のときに、追加コマンドのパラメータとして、構造化文書パスが「ｕｉｘ：／／ｒｏｏｔ／その他」と表されていたとき、これに対応する文書オブジェクトは存在しないので、ステップＳ６でエラーとなり、ステップＳ７へ進む。
【０１４２】
次に、ステップＳ８では、文書オブジェクトＯｘ０にスキーマが存在するか否かを検査する。この検査は、前述したように、各文書オブジェクトのファイルに属性値が記述されているので、この値をチェックすればよい。文書オブジェクトＯｘ０のもつ「スキーマ属性有無」の値が「１」のときは、ステップＳ９へ進む。
【０１４３】
以下、図２０のステップＳ９の処理（合成文書作成部４７の処理）について、図２１に示すフローチャートを参照して詳細に説明する。
【０１４４】
文書格納部２１は、ステップＳ５で取得した文書オブジェクトツリーを合成文書作成部４７へ渡す。
【０１４５】
合成文書作成部４７は、この文書オブジェクトツリーを文書オブジェクトＯｘ０から遡り、「Ｓｃｈｅｍａ」タグを子要素として持つ文書オブジェクトＯｘ１を検索する（ステップＳ２１）。
【０１４６】
例えば、図１４に示した構造化文書データベースでは、文書オブジェクトＯｘ０としての「＃４２」ノードの親ノードである「＃２」ノードから「Ｓｃｈｅｍａ」タグをトップ（先頭）にもつノード（「＃３」ノード）へのリンクが張られているので（「Ｓｃｈｅｍａ」タグを子要素として持つので）、この「＃２」ノードが文書オブジェクトＯｘ１となる。よって、ステップＳ２２をスキップして、ステップＳ２３へ進む。
【０１４７】
この文書オブジェクトＯｘ１から文書オブジェクトＯｘ０、さらに文書オブジェクトＯｘ０からアークを辿って、その下流にある、文書オブジェクトの属性値の値が「１」である全ての子ノードからなる文書オブジェクトツリーＯｔ１を取り出す（ステップＳ２３）。
【０１４８】
例えば、上記追加コマンド中のパラメータの構造化文書パスが「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」と指定されているとき、文書オブジェクトツリーＯｔ１は、「＃４２」ノード〜「＃４９」ノードから構成されたものとなる（図１４参照）。
【０１４９】
次に、ステップＳ２５へ進む。
【０１５０】
ステップＳ２５では、文書オブジェクトツリーＯｔ１に格納文書の文書オブジェクトツリーを文書オブジェクトＯｘ０の子ノードとして挿入する。その結果得られた新たな文書オブジェクトツリーを文書オブジェクトツリーＯｔ２とする。
【０１５１】
この文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換し、それをテンポラリファイルＡに出力する（ステップＳ２７）。
【０１５２】
例えば、上記追加コマンド中のパラメータの格納文書「＜Ａ＞データ＜／Ａ＞」の文書オブジェクトツリー（この場合は、１つの文書オブジェクト）を「＃４２」ノード〜「＃４９」ノードで構成された文書オブジェクトツリーＯｔ１に「＃４２」ノードの子ノードとして挿入して得られた合成文書の文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換した結果を図２２に示す。この合成文書は、もともとある「特許」情報に「＜Ａ＞データ＜／Ａ＞」というデータを追加したものとなっている。
【０１５３】
図２２に示したＸＭＬ文書、すなわち、合成文書がテンポラリファイルＡに出力され、テンポラリファイルＡに一時格納される。
【０１５４】
一方、スキーマタグ以下の文書オブジェクトツリーＯｔ３をＸＭＬ文書に変換して、それをテンポラリファイルＢに出力する（ステップＳ２８）。すなわち、テンポラリファイルＢには、スキーマ文書が一時格納されることになる。
【０１５５】
例えば、文書オブジェクトツリーＯｔ３である「＃３」ノードをトップノードとする文書オブジェクトツリーをＸＭＬ文書に変換した結果を図２３に示す。図２３に示したＸＭＬ文書がテンポラリファイルＢに出力され、テンポラリファイルＢに一時格納される。
【０１５６】
図２２に示すように、テンポラリファイルＡ（「ｔｍｐ０００．ｘｍｌ」）には、もともとある「特許」情報の要素の他に、格納文書、すなわち、ここでは、例えば、「＜Ａ＞データ＜／Ａ＞」が挿入されている。また、「ｘｍｌｎｓ＝”ｘ−ｓｃｈｅｍａ：ｔｍｐ００１．ｘｍｌ”」という、テンポラリファイルＢ（「ｔｍｐ００１．ｘｍｌ」）へのリンク情報の記述がある。この記述は、「特許」情報に適用されるスキーマが出力されているテンポラリファイルＢを指定している。
【０１５７】
次に、図２０の説明に戻る。
【０１５８】
ステップＳ１０では、文書格納部２１は文書パーサ部４６に、合成文書のテンポラリファイルＡとスキーマのテンポラリファイルＢとを与えて、合成文書の文書構造の妥当性をチェックする。すなわち、文書パーサ部４６は、合成文書のテンポラリファイルＡとスキーマのテンポラリファイルＢとを読み込み、合成文書の文書構造が、スキーマにより定義されている文書構造に一致するか否かをチェックする。
【０１５９】
例えば、図２２に示した合成文書と、図２３に示したスキーマとで妥当性のチェックを行った場合、合成文書には、スキーマにより定義されていない「Ａ」という要素が存在するため、図２３の合成文書は、妥当性のチェックでエラーとなる（ステップＳ１１）。この場合、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す（ステップＳ１２）。
【０１６０】
例えば、クライアント端末の所定の表示装置には、図３５に示すようなメッセージが表示される。
【０１６１】
次に、構造化文書データベースが、図１４に示した状態のときに、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドを受け付けた場合について、図２０を参照して説明する。前述同様にして、文書オブジェクトＯｘ０のオブジェクトＩＤ「＃２」を取得する（ステップＳ５）、この文書オブジェクトには、スキーマが存在するので（ステップＳ８）、ステップＳ９において合成文書を作成する。
【０１６２】
この場合、文書オブジェクトＯｘ０である「＃２」ノード自体から「Ｓｃｈｅｍａ」タグをトップ（先頭）にもつノード（「＃３」ノード）へのリンクが張られているので、この「＃２」ノードが文書オブジェクトＯｘ１となる（図２１のステップＳ２１）。すなわち、文書オブジェクトＯｘ０と文書オブジェクトＯｘ１が同じなので（ステップＳ２２）、ステップＳ２９へ進み、格納文書「＜特許＞…＜／特許＞」の文書オブジェクトツリーをＸＭＬ文書に変換し、テンポラリファイルＡに出力する（ステップＳ２９）。
【０１６３】
例えば、図２４に示すように、テンポラリファイルＡ（「ｔｍｐ０００．ｘｍｌ」）には、格納文書である「特許」情報、すなわち、ここでは、「＜特許＞…＜／特許＞」が出力されている。また、「ｘｍｌｎｓ＝”ｘ−ｓｃｈｅｍａ：ｔｍｐ００１．ｘｍｌ”」という、テンポラリファイルＢ（「ｔｍｐ００１．ｘｍｌ」）へのリンク情報の記述がある。
【０１６４】
次に、ステップＳ２８へ進む。図２５に示すように、テンポラリファイルＢには、「＃３」ノードをトップノードとするスキーマの文書オブジェクトツリーをＸＭＬ文書に変換した結果が出力されている。
【０１６５】
図２０のステップＳ１０で、図２４に示した合成文書と、図２５に示したスキーマとで妥当性のチェックを行ったとき、合成文書の文書構造と、スキーマにより定義されている文書構造とは一致する、この場合、ステップＳ１１からステップＳ１３へ進む。
【０１６６】
ステップＳ１３では、格納文書の文書オブジェクトツリーが、文書オブジェクトＯｘ０下に追加される。すなわち、文書格納部２１により、格納文書の文書オブジェクトツリーを構成する各文書オブジェクト（のファイル）にオブジェクトＩＤが与えられ、文書オブジェクトＯｘ０から格納文書の文書オブジェクトツリーの先頭の文書オブジェクトへリンクが張られる。そして、文書オブジェクトツリー格納部４１により、格納文書の文書オブジェクトツリーを構成する各文書オブジェクト（のファイル）が文書記憶部５に格納される。
【０１６７】
次に、ステップＳ１４へ進み、インデックス記憶部６のインデックスを更新する。
【０１６８】
なお、ステップＳ８で、文書オブジェクトＯｘ０のもつ属性値の値が「０」のときは、上述したスキーマを用いた合成文書の文書構造の妥当性のチェックを行わずに、そのままマステップＳ１３へ進み、格納文書の文書オブジェクトツリーを、文書オブジェクトＯｘ０下に追加し（ステップＳ１３）、それに伴い、インデックス記憶部６のインデックスを更新する（ステップＳ１４）。
【０１６９】
（１−２）文書取得処理
次に、図１の構造化文書管理システムの文書取得処理動作について、図２６に示すフローチャートを参照して説明する。
【０１７０】
クライアント端末から構造化文書管理システムに対し、文書取得要求として、取得コマンド、スキーマ取得コマンドのうちのいずれかが送信されて、要求受付部１１にて受け付けられたとき、図２６に示した処理動作を行う。
【０１７１】
例えば、ユーザが図３６に示したような文書の格納／削除画面上の領域Ｗ１の「特許ＤＢ」をマウス等で選択すると（クリックすると）、構造化文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」と表示されとともに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」なる取得コマンドが構造化文書管理システムへ送信される。
【０１７２】
ここでは、例えば、構造化文書データベースが、図８に示した状態のときに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」なる取得コマンドを受け付けた場合を例にとり説明する。
【０１７３】
要求受付部１１は、上記取得コマンドを受け付けると、上記取得コマンド中のパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」を文書取得部２２へ渡す（ステップＳ３１）。
【０１７４】
文書取得部２２は、パスから文書オブジェクトツリー取得部４５へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部４５は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ５）を取り出す（ステップＳ３２）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ５のオブジェクトＩＤを取得することができるので（ステップＳ３３）、その場合は、ステップＳ３５へ進む。
【０１７５】
例えば、上記取得コマンドの場合、「＃２」ノードが文書オブジェクトＯｘ５となるので、そのオブジェクトＩＤとして、「＃２」を取得するとともに、この「＃２」ノード以下の文書オブジェクトツリーＯｔ５（「＃２」ノード、「＃４２」ノード〜「＃４９」ノード、「＃５２」ノード以下、「＃６２」ノード以下）を取得する（ステップＳ３５）。
【０１７６】
ステップＳ３２において、指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ５が見つからなければ、エラーとなり（ステップＳ３３）、文書取得部２２，結果処理部１２を介して、クライアント端末に「文書取得失敗」の旨のメッセージを返す（ステップＳ３４）。
【０１７７】
ステップＳ３５で取得した文書オブジェクトツリーＯｔ５は、文書文字列取得部４４でＸＭＬ文書に変換される。例えば、上記取得コマンドの場合、取得したＸＭＬ文書は、図１１に示すような３つの「特許」情報のＸＭＬ文書となる。
【０１７８】
文書取得部２２は、結果処理部１２を介して、図１１に示したようなＸＭＬ文書を（例えば、ＸＳＬ（ｅＸｔｅｎｓｉｂｌｅ Ｓｔｙｌｅ Ｌａｎｇｕａｇｅ）といった所定のスタイルシートとともに）、クライアント端末へ返す（ステップＳ３７）。
【０１７９】
クライアント端末では、図１１に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図３６に示すように、領域Ｗ２に表示する。
【０１８０】
ＸＳＬを利用すると、ＸＭＬ文書を様々な形に変換することが出来る。違う構文書造のＸＭＬ文書に変換することも出来るし、ＸＭＬ文書からＨＴＭＬページを生成することも出来る。
【０１８１】
（１−３）文書削除処理
次に、図１の構造化文書管理システムの文書削除処理動作について、図２７に示すフローチャートを参照して説明する。
【０１８２】
クライアント端末から構造化文書管理システムに対し、文書削除要求として、削除コマンドが送信されて、要求受付部１１にて受け付けられたとき、図２７に示した処理動作を行う。
【０１８３】
例えば、ユーザが図３６に示したような文書の格納／削除画面上の領域Ｗ１の「特許ＤＢ」をマウス等で選択すると（クリックすると）、構造化文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」と表示され、さらに、「削除」ボタンＢ２を選択すると「ｒｅｍｏｖｅＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」なる削除コマンドが構造化文書管理システムへ送信される。
【０１８４】
ここでは、例えば、構造化文書データベースが、図１４に示した状態のときに、「ｒｅｍｏｖｅＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日”）」なる削除コマンドを受け付けた場合を例にとり説明する。
【０１８５】
要求受付部１１は、上記削除コマンドを受け付けると、上記削除コマンド中のパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日」を文書削除部２３へ渡す（ステップＳ４１）。
【０１８６】
次に、文書削除部２３は、パスから文書オブジェクトツリー取得部４５へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部４５は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ０）を含む文書オブジェクトツリーを取り出す（ステップＳ４２）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ０のオブジェクトＩＤを取得することができるので（ステップＳ４３）、その場合は、ステップＳ４５へ進む。
【０１８７】
例えば、上記削除コマンドの場合、「＃４４」ノードが文書オブジェクトＯｘ０となるので、そのオブジェクトＩＤとして、「＃４４」を取得するとともに、この「＃４４」ノードを含む文書オブジェクトツリー（例えば、「＃４４」ノードの全ての子孫ノードと「＃４４」ノードと同じ階層にある全ての（兄弟）ノードと、「＃４４」ノードの親ノードである「＃４２」ノード、その親ノードである「＃２」ノードとからなる文書オブジェクトツリー）を取得する。
【０１８８】
指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ０が見つからなければ、エラーとなり（ステップＳ４３）、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書削除失敗」の旨のメッセージを返す（ステップＳ４４）。
【０１８９】
次に、ステップＳ４５では、文書オブジェクトＯｘ０にスキーマが存在するか否かを検査する。この検査は、前述したように、各文書オブジェクトのファイルに属性値が記述されているので、この値をチェックすればよい。文書オブジェクトＯｘ０のもつ属性値の値が「１」のときは、ステップＳ４６へ進む。
【０１９０】
以下、図２７のステップＳ４６の処理（合成文書作成部４７の処理（削除コマンド用））について、図２８に示すフローチャートを参照して詳細に説明する。
【０１９１】
なお、図２８において、図２１と同一部分は同一符号を付している。
【０１９２】
文書格納部２１は、ステップＳ４２で取得した文書オブジェクトツリーを合成文書作成部４７へ渡す。
【０１９３】
合成文書作成部４７は、この文書オブジェクトツリーを文書オブジェクトＯｘ０から遡り、「Ｓｃｈｅｍａ」タグを子要素として持つ文書オブジェクトＯｘ１を検索する（ステップＳ２１）。
【０１９４】
例えば、図１４に示した構造化文書データベースでは、文書オブジェクトＯｘ０としての「＃４４」ノードの上流にある「＃２」ノードから「Ｓｃｈｅｍａ」タグをトップ（先頭）にもつノード（「＃３」ノード）へのリンクが張られているので（「Ｓｃｈｅｍａ」タグを子要素として持つので）、この「＃２」ノードが文書オブジェクトＯｘ１となる。
【０１９５】
この文書オブジェクトＯｘ１から文書オブジェクトＯｘ０、さらに文書オブジェクトＯｘ０からアークを辿って、その下流にある、文書オブジェクトの属性値の値が「１」である全ての子ノードからなる文書オブジェクトツリーＯｔ１を取り出す（ステップＳ２３）。
【０１９６】
例えば、上記追加コマンド中のパラメータの構造化文書パスが「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日」と指定されているとき、文書オブジェクトツリーＯｔ１は、「＃４２」ノード〜「＃４９」ノードから構成されたものとなる（図１４参照）。
【０１９７】
次に、ステップＳ２６ヘ進み、文書オブジェクトツリーＯｔ１から文書オブジェクトＯｘ０以下の文書オブジェクトツリーを削除する。その結果得られた新たな文書オブジェクトツリーを文書オブジェクトツリーＯｔ２とする。
【０１９８】
この文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換し、それをテンポラリファイルＡに出力する（ステップＳ２７）。
【０１９９】
例えば、上記削除コマンド中のパラメータの構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日」が指し示す「＃４４」ノード以下の文書オブジェクトツリーを「＃４２」ノード〜「＃４９」ノードで構成された文書オブジェクトツリーＯｔ１から削除することにより得られた合成文書の文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換した結果を図２９に示す。この合成文書は、もともとある「特許」情報から「＜出願日＞…＜／出願日＞」というデータを削除したものとなっている。
【０２００】
図２９に示したＸＭＬ文書、すなわち、合成文書がテンポラリファイルＡに出力され、テンポラリファイルＡに一時格納される。
【０２０１】
一方、スキーマタグ以下の文書オブジェクトツリーＯｔ３をＸＭＬ文書に変換して、それをテンポラリファイルＢに出力する（ステップＳ２８）。すなわち、テンポラリファイルＢには、スキーマ文書が一時格納されることになる。
【０２０２】
例えば、文書オブジェクトツリーＯｔ３である「＃３」ノードをトップノードとする文書オブジェクトツリーをＸＭＬ文書に変換した結果を図３０に示す。図３０に示したＸＭＬ文書がテンポラリファイルＢに出力され、テンポラリファイルＢに一時格納される。
【０２０３】
次に、図２７の説明に戻る。
【０２０４】
ステップＳ４７では、文書削除部２１は文書パーサ部４６に、合成文書のテンポラリファイルＡとスキーマのテンポラリファイルＢとを与えて、文書格納処理の場合と同様にして、合成文書の文書構造の妥当性をチェックする。
【０２０５】
例えば、図２９に示した合成文書と、図３０に示したスキーマとで妥当性のチェックを行った場合、合成文書には、スキーマにより定義されている「出願日」という要素が存在しないため、図２９の合成文書は、妥当性のチェックでエラーとなる（ステップＳ４８）。この場合、文書削除部２１，結果処理部１２を介して、クライアント端末に「文書削除失敗」の旨のメッセージを返す（ステップＳ４９）。
【０２０６】
なお、構造化文書データベースが、図１４に示した状態のときに、「ｒｅｍｏｖｅＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］”）」なる削除コマンドを、図２７に従って処理を行うと、図２８のステップＳ２７において、図２４に示したような合成文書がテンポラリファイルＡに出力される。テンポラリファイルＢは、図３０と同様である。
【０２０７】
このとき、図２４に示した合成文書と、図３０に示したスキーマとで妥当性のチェックを行った場合、合成文書の文書構造と、スキーマにより定義されている文書構造とは一致するので、ステップＳ４８からステップＳ５０へ進む。
【０２０８】
ステップＳ５０では、文書オブジェクトＯｘ０以下の文書オブジェクトツリーを削除する。すなわち、文書オブジェクトツリー削除部４２により、文書オブジェクトＯｘ０以下の文書オブジェクトツリーを構成する各文書オブジェクト（のファイル）が文書記憶部５から削除される。例えば、「＃２」ノードから「＃４２」ノード以下の文書オブジェクトのファイルが削除される。
【０２０９】
次に、ステップＳ５１へ進み、インデックス記憶部６のインデックスを更新する。また、クライアント端末の図３６に示したような表示画面の領域Ｗ１には、「特許［０］」が表示さなくなる。
【０２１０】
なお、ステップＳ４５で、文書オブジェクトＯｘ０のもつ属性値の値が「０」のときは、上述したスキーマを用いた合成文書の文書構造の妥当性のチェックを行わずに、そのままマステップＳ５０へ進み、文書オブジェクトＯｘ０以下の文書オブジェクトツリーを削除し（ステップＳ５０）、それに伴う、インデックス記憶部６のインデックスを更新する（ステップＳ５１）。
【０２１１】
（１−４）スキーマの設定、スキーマを用いた文書格納
図３１に示した画面上で、ユーザが「Ｓｃｈｅｍａ設定Ｗｉｎ」をマウス等のポインティングデバイスなどを用いて選択すると、図３７に示したようなスキーマの設定を行うためのユーザインタフェースとしての画面が表示される。
【０２１２】
ユーザが、領域Ｗ３に、例えば、図１２に示したような「特許」情報のスキーマを入力し、この入力したスキーマを「特許ＤＢ」以下のノードに設定する場合には、領域Ｗ１から「特許ＤＢ」をマウス等でクリックして選択した後（領域Ｗ２には、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される）、「スキーマ設定」ボタンＢ３を選択する。すると、「ｓｅｔＳｃｈｅｍａ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”）」なるスキーマ格納コマンドが構造化文書管理システムへ送信される。このコマンドの処理は前述した文書格納処理動作と同様である。
【０２１３】
次に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」の下に「特許」情報を格納しようとするとき、「特許ＤＢ」以下のノードに既に設定されているスキーマを用いて「特許」情報を入力する場合について説明する。
【０２１４】
まず、スキーマを取得する。例えば、図３８に示すような文書の格納／削除を行うための画面の領域Ｗ１から「スキーマ」をマウス等を用いて選択すると、文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／＃Ｓｃｈｅｍａ」と表示されとともに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／Ｓｃｈｅｍａ”）」なるスキーマ取得コマンドが構造化文書管理システムへ送信される。
【０２１５】
このコマンドの処理は、前述した文書取得処理と同様である。構造化文書管理システムから返されるＸＭＬ文書は、図３８の画面の領域Ｗ３に表示される。
【０２１６】
図３８に示すように、領域Ｒ３には、「特許」情報のデータ入力領域が各要素毎に設定されて表示されている。この表示に従って、ユーザは、データを入力すればよい。例えば、「タイトル」、「年」などのデータ入力領域が階層的に配置され、表示されている。ユーザは、このデータ入力領域にデータを入力することで、スキーマにより定義された文書構造の格納文書が容易に作成することができる。
【０２１７】
また、領域Ｗ３に入力した「特許」情報の格納先として、領域Ｗ１で「特許ＤＢ」をマウス等を用いて選択すると、領域Ｗ２に構造化文書パスとして、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される。その後、「登録」ボタンＢ１を選択すると、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０２１８】
この場合、格納文書は、予めスキーマに従って入力されたものなので、図２０のステップＳ１０の妥当性チェックでエラーとなることはない。
【０２１９】
（２）検索機能
図１の構造化文書管理システムにおける検索系のコマンドには以下のものがある。
【０２２０】
ｑｕｅｒｙ（ｑｌ）
「ｑｕｅｒｙ」は、パラメータとして（ ）内のクエリｑｌを実行し、その結果のＸＭＬ文書を取得するコマンド（以下、検索コマンドと呼ぶ）である。
【０２２１】
クエリは、図３９に示すように、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ ＱｕｅｒｙＬａｎｇｕａｇｅ）に似た形式の言語により、検索位置、検索条件、情報抽出部分などを記述した、構造化されたＸＭＬ文書である。クエリ文書も構造化文書管理システムの管理対象である。
【０２２２】
「ｋｆ：ｆｒｏｍ」タグから始まる要素には、検索位置の指定と文書要素の値に変数を対応付ける記述があり、「ｋｆ：ｗｈｅｒｅ」タグのから始める要素には、変数に関する条件づけの記述があり、「ｋｆ：ｓｅｌｅｃｔ」タグから始まる要素には、検索結果の出力形式が記述される。
【０２２３】
検索には、単純検索と概念検索とがある。単純検索とは、クエリ中に指定された検索条件を満たす情報を検索・抽出するものであり、概念検索とは、クエリ中に指定された概念情報を利用して、クエリ中に指定された検索条件を満たす情報を検索・抽出するものである。
【０２２４】
図４０は、単純検索のクエリの例を示したものである。図４０のクエリは、例えば、図１４に示したような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群において、「１９９９年でかつ、「ＰＣ」のような内容の「要約」という要素をもつ文書（「特許」情報）の「タイトル」を列挙せよ」という検索要求を意味している。
【０２２５】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」、「＄ｙ」、「＄ｓ」に、それぞれ「特許」情報の「タイトル」、「年」、「要約」という文書要素の値が代入される。
【０２２６】
「ｋｆ：ｗｈｅｒｅ」タグから始める要素の記述により、変数「＄ｙ」＝「１９９９」という比較がなされる。また、コンポーネント「ＭｙＬｉｋｅ」は変数「＄ｓ」と「ＰＣ」を引数として、「ＰＣ」と類似する値の変数「＄ｓ」を検知するための関数である。
【０２２７】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」が出力値として利用される。
【０２２８】
なお、「ｋｆ：ｓｔａｒ」タグは構造の曖昧表現であり、例えば「＜特許＞＜ｋｆ：ｓｔａｒ＞＜年＞」は「タグ名が「特許」である要素の子孫の要素としていずれかに存在し、タグ名が「年」である要素」を意味する。
【０２２９】
図４１に図４０の単純検索のクエリを用いた検索結果を示す。この検索結果もＸＭＬ文書である。
【０２３０】
図４２は、概念検索のクエリの例を示したものである。図４２のクエリは、例えば図１８，図１９に示すような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群に対し、「概念ＤＢ」アークが示すノード以下に格納されている「概念」情報を利用して検索するための検索要求である。ここで、概念「周辺装置」の値をもつタグの子要素の値には、概念「ＳＣＳＩ」、「メモリ」、「ＨＤＤ」などがあるものとする。また、図１８には示していないが、各「特許」情報の構成要素には、「キーワード」タグから始める要素も存在するものとする。
【０２３１】
すなわち、図４２のクエリは、「概念「周辺装置」以下の概念のいずれかを「キーワード」という要素の値にもつ文書（「特許」情報）の「タイトル」を列挙せよ」という検索要求を意味している。
【０２３２】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」、変数「＄ｋ」に、それぞれ、「特許」情報の「タイトル」、「キーワード」という要素の値が代入される。また、変数「＄ｘ」は「概念」情報として「周辺装置」の値をもつタグの子要素の値（「ＳＣＳＩ」、「メモリ」、「ＨＤＤ」など）が代入される。
【０２３３】
「ｋｆ：ｗｈｅｒｅ」タグから始める要素の記述により、「＄ｋ」＝「周辺装置」もしくは「＄ｋ」＝「＄ｘ」という比較がなされる。
【０２３４】
次に、図１の構造化文書管理システムの文書検索処理動作について、図４３に示すフローチャートを参照して説明する。
【０２３５】
図３１に示した画面上で、ユーザが「ＸＭＬ検索Ｗｉｎ」をマウス等のポインティングデバイスなどを用いて選択すると、図４４に示すような文書検索を行うためのユーザインタフェースとしての画面が表示される。
【０２３６】
図４４の検索画面において、領域Ｗ１には、前述同様、構造化文書データベースの現在のツリー構造の要素名（タグ名）がユーザが理解可能なように簡略的に表示されてている。
【０２３７】
領域Ｗ２は、検索対象の範囲（ツリー構造上の検索範囲）や、検索条件などを入力するための領域である。領域Ｗ３には、検索結果が表示される。
【０２３８】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「文書」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という検索要求の場合には、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、トップノードとして、「特許」を入力する（この場合、領域Ｗ１から「特許」をマウス等で選択することにより入力してもよい）。また、検索条件として、「「タイトル」という要素の値に「文書」という文字列を含む」「「年」という要素の値が「１９９８」以上である」という内容を予め設定されたデータ入力領域に入力すればよい。
【０２３９】
その後、「検索」ボタンＢ２１を選択することにより、例えば、図４５に示すようなクエリが、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。クエリの格納場所は、予め定められており、システム側が自動的に、この追加コマンドのパラメータを設定することとなる。例えば、構造化文書データベースが図１８に示した状態のとき、当該クエリの格納場所を表すパラメータとしての構造化文書パスは、「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」となる。また、追加コマンドのもう一方のパラメータは、当該クエリ文書である。
【０２４０】
要求受付部１１は、上記クエリを受け付けると（ステップＳ１０１）、当該クエリを検索要求処理部３へ渡す。そして、当該クエリ文書を格納するための追加コマンドのパラメータを文書格納部２１へ渡す。この追加コマンドの処理を、前述同様に行って、当該クエリは、文書記憶部５に格納される。
【０２４１】
例えば、図４２に示すようなクエリの場合、構造化文書データベースには、図４６に示すように展開されて、構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」の示す「＃３０１」ノード以下にリンクされる。
【０２４２】
一方、検索要求処理部３では、受け取ったクエリを基に、データアクセス部４を通してインデックス記憶部６，文書記憶部５にアクセスし、検索要求に合致する文書集合などを取得して、クエリの中で要求された情報を抽出して結果処理部１２を介して出力する。
【０２４３】
例えば、上記クエリの場合、まず、「「タイトル」タグに「文書」という文字列を含む」という条件に合致するものを検索することが検索対象を絞り込む上で効率がよい。そこで、図１０に示したようなデータ生起インデックスを用いて、「文書」という文字列にリンクされているノード（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを上流側に１つ遡り、「タイトル」というタグ名にたどり着いたときは、更に上流に辿っていき、「特許」というタグ名にたどり着いたときは、そのノード以下の文書オブジェクトツリーＯｔ１１を抽出する。
【０２４４】
次に、この抽出された複数の文書オブジェクトツリーＯｔ１１の中から、さらに、「年」という要素の値が「１９９８」年以上の文書オブジェクトツリーＯｔ１２を抽出する。
【０２４５】
この文書オブジェクトツリーＯｔ１２が上記クエリの内容に適合する文書となる。さらに上記クエリの要求内容に従えば、各文書オブジェクトツリーＯｔ１２のトップノードへの構造化文書パスを求める（ステップＳ１０２）。
【０２４６】
なお、上記検索処理は、上記した方法に限るものではなく、インデックス情報を用いた様々な効率のよい検索方法が可能である。
【０２４７】
検索要求処理部３は、ステップＳ１０２で得られた結果を統合して、検索結果としてのＸＭＬ文書を作成する（ステップＳ１０３）。
【０２４８】
例えば、検索結果のＸＭＬ文書は、
となる。
【０２４９】
検索要求処理部３は、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す（ステップＳ１０４）。
【０２５０】
クライアント端末では、図１１に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図４４に示すように、領域Ｗ１２に表示する。
【０２５１】
同様にして、スキーマの検索も行える。
【０２５２】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「ｓｃｈｅｍａ」を先頭タグに持つ文書の中から、「特許」と「要約」というタグ名を持つスキーマを検索せよ」という検索要求の場合には、図４７に示すように、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、トップノードとして、「＃ｓｃｈｅｍａ」を入力する。また、検索条件として、「要素の属性名に「特許」という文字列を含む」「要素の属性名に「要約」という文字列を含む」という内容を予め設定されたデータ入力領域に入力すればよい。
【０２５３】
その後、「検索」ボタンＢ２１を選択することにより、上記検索要求を記述したクエリ（図４８参照）が、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。
【０２５４】
さて、上記クエリの場合、例えば、「「＃ｓｃｈｅｍａ」を先頭タグに持つ」という条件に合致するものを検索する。そこで、図９に示したような要素名称生起インデックスを用いて、「＃ｓｃｈｅｍａ」という要素にリンクされているノードの（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、属性名が「特許」と「要約」いう要素にたどり着いたときは、当該「＃ｓｃｈｅｍａ」を先頭タグにもつ文書オブジェクトツリーＯｔ２１を抽出する。この文書オブジェクトツリーＯｔ２１が上記クエリの内容に適合する文書となる。さらに、図４８に示したクエリの要求内容に従えば、各文書オブジェクトツリーＯｔ２１のトップノードへの構造化文書パスを求める。
【０２５５】
検索要求処理部３は、文書オブジェクトツリーＯｔ２１が複数あれば、それぞれのトップノードへの構造化文書パスをまとめて、検索結果としてのＸＭＬ文書を作成し、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す。
【０２５６】
クライアント端末では、検索結果として受け取ったＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図４４に示すように、領域Ｗ１２に表示する。
【０２５７】
クライアント端末では、検索結果の中の１つのスキーマを選択して、表示させると、例えば、図３８に示すような文書の格納／削除を行うための画面とともに、その領域Ｗ３に、「特許」情報のデータ入力領域が各要素毎に設定されて表示される。
【０２５８】
ユーザは、このデータ入力領域にデータを入力することで、スキーマにより定義された文書構造の格納文書が容易に作成することができる。
【０２５９】
例えば、図３８の領域Ｗ３に入力した「特許」情報の格納先として、領域Ｗ１で「特許ＤＢ」をマウス等を用いて選択すると、領域Ｗ２に構造化文書パスとして、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される。その後、「登録」ボタンＢ１を選択すると、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０２６０】
この場合、格納文書は、予めスキーマに従って入力されたものなので、図２０のステップＳ１０の妥当性チェックでエラーとなることはない。
【０２６１】
同様にして、クエリの検索も行える。クエリを検索して、検索結果として得られた既存のクエリを加工して、再利用することもできる（クエリの再利用）。
【０２６２】
クエリの検索は、前述したような構造化文書の検索と同様にして行われ、その検索範囲は、クエリ群の格納されている構造化データベース上の一部の文書オブジェクトツリーとなる。
【０２６３】
例えば、図１８に示したような状態の構造化文書データベースから、「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリを検索する場合について説明する。そのような検索要求を記述したクエリを図４９に示す。
【０２６４】
図４９に示すクエリは、「「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」の示す「＃３０１」ノード以下に存在するクエリの中から「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリを検索し、その内容（タグ名が「ｑｕｅｒｙ」である要素以下の文書オブジェクトツリーの文書）を列挙せよ」を意味するものである。
【０２６５】
なお、「ｋｆ：ａｓ」タグの内容で変数「＄ｅｌｔ」に、「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリのタグ名が「ｑｕｅｒｙ」である要素以下の文書オブジェクトツリーが代入される。
【０２６６】
このクエリを検索要求処理部３が処理する際には、前述同様にして、例えば、図９に示したような要素名称生起インデックスを用いて、「ｋｆ：ｆｒｏｍ」という要素にリンクされているノードの（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、「特許」というタグ名にたどり着いたときは、さらに、上流側にアークを辿って「ｑｕｅｒｙ」というタグ名に辿りついたとき、当該「ｑｕｅｒｙ」を先頭タグにもつ文書オブジェクトツリーＯｔ３１を抽出する。この文書オブジェクトツリーＯｔ３１が上記クエリの内容に適合する文書となる。
【０２６７】
複数の文書オブジェクトツリーＯｔ３１が検索されたら、それらを統合して、ＸＭＬ文書を作成して、それをスタイルシートとともにクライアント端末へ返す。
【０２６８】
クライアント端末では、検索結果の中の１つのクエリを選択して、表示させると、例えば、図４４に示した検索画面の領域Ｗ１１に、各データ入力領域にデータの入力された状態で、当該クエリに記述された検索要求の内容が表示される。
【０２６９】
ユーザは、この状態から、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「文書」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という当該クエリに記述された検索要求中の「文書」を「ＸＭＬ」に変更して、「検索」ボタンＢ２１を選択すれば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「ＸＭＬ」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という意味のクエリが構造化文書管理システムへ送信される。
【０２７０】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。従って、文書構造が異なる、様々なスキーマを持つ膨大な数の文書の中から検索条件に合致する文書を容易に検索できる。
【０２７１】
また、検索に用いるクエリも構造化文書であるので、構造化文書データベースにログとして格納することにより、過去のクエリを再利用するようなアプリケーションも容易に構築することができる。
【０２７２】
（３）適用例
次に、上記概念検索の特許調査への適用例について説明する。
【０２７３】
図５０は、特許調査における構造化文書データベースの一例であり、「特許」情報の他に、「概念」情報も格納している。
【０２７４】
特許調査において、最も重要となってくる作業は、関連する「特許」情報を収集し、「特許」情報を様々な観点から分析し、特許マップ（図５４参照）を作成することである。特許マップを作成するために、従来、特許マップにおける縦軸、横軸を予め決定し、それに従い、縦軸に並ぶ任意の項目と横軸に並ぶ任意の項目とを検索条件とした検索を逐次行うという方法がとられ、この部分に非常に莫大なコストがかかっていた。しかし、構造化文書管理システムを用いることで、この部分のコストを大幅に減少させることが可能となる。
【０２７５】
なお、ここで、マップとは、縦軸（ｙ軸）に並ぶ任意の項目と横軸（ｘ軸）に並ぶ任意の項目とを検索条件とした検索結果をｘ軸とｙ軸とを分類軸として分類整理するものである。
【０２７６】
構造化文書管理システムで、クライアント端末のユーザが図５４に示すような特許マップを作成しようとする場合、ユーザは、クライアント端末上の表示装置に表示される図５０に示すような構造化文書データベースの現在のツリー構造を参照して、図５１に示すような検索画面上に、分析対象の範囲とする「特許」情報のパスと、分析の軸（例えば、ｘ軸、ｙ軸）となる要素を、それぞれ領域Ｗ２１、Ｗ２２に入力する。分析の軸となる要素は、構造化文書データベース内の「特許」情報の要素、「概念」情報の要素のいずれであってもよい。
【０２７７】
例えば、図５１では、ｘ軸に「機能」、ｙ軸に「技術」という「概念」情報の要素を入力している。
【０２７８】
その後、ユーザは、「実行」ボタンＢ３１を選択すると、クライアント端末から図１の構造化文書管理システムへ、図５２に示したようなクエリが送出される。
【０２７９】
この場合のクエリには、「「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群の中から、「概念ＤＢ」アークが示すノード以下に格納されている、概念「機能」の子要素のいずれかと概念「技術」の子要素のいずれかとを、「キーワード」や「要約」などの要素の値に含む「特許」情報を検索せよ。検索結果として、「機能」の子要素と「技術」の子要素と、それらに対応する「特許」情報の「公開番号」との組を列挙せよ。」という意味の検索要求である。
【０２８０】
概念「機能」には、「検索」「格納」…「分析支援」という子要素があり、概念「技術」には、「実装データベース」「反構造データベース」「自然言語処理」…という子要素があるものとする。
【０２８１】
上記クエリを受けた構造化文書検索システムの検索要求処理部３では、例えば、図１０に示したようなデータ生起インデックスを用いて、概念「機能」の各子要素（文字列）にリンクされているノード（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを上流側に遡り、「特許」というタグにたどり着いたときは、さらに、そのノード以下の文書オブジェクトツリーを下流側に辿って概念「技術」の子要素（文字列）のいずれかにリンクされているタグ名にたどり着いたときは、当該文書オブジェクトツリーと、その「公開番号」タグにリンクされている文字列（要素値）を抽出する。このようにして、抽出された「特許」情報のそれぞれについて、対応の「機能」の子要素と「技術」の子要素と「公開番号」との組を統合して、図５３に示すような検索結果としてのＸＭＬ文書を作成、要求元のクライアント端末へ、所定のスタイルシートとともに返す。
【０２８２】
これらを受け取ったクライアント端末の表示装置には、図５４に示したような表形式の特許マップが表示されることになる。
【０２８３】
このように、所望の概念を「軸」として指定するだけで、構造化文書データベースに蓄積された情報を「軸」として指定された概念に基づき集計・分類して、マップ表示するこたが容易に行える。すなわち、構造化文書データベースに蓄積された情報を、「概念」情報を用いて様々な観点で集計・分類することが容易に行える。
【０２８４】
（本発明の実施形態の説明）
以下、本発明の実施の形態について図面を参照して説明する。
【０２８５】
クエリに基づき、上記構造化文書データベースに対し検索を行う場合、検索条件などが同一のクエリがクライアント端末から送られてくることもある。このような場合、同じクエリを受け取る度に同じ検索を何度も行うことは効率的でない。そこで、頻繁に実行されるクエリについては、そのクエリを実行した結果、すなわち、検索結果を当該クエリに対応付けて一時格納する。再度同じクエリを受け付けた時には、検索を実行せずに、この一時格納した検索結果を返すようにすることで、検索のための処理時間の短縮が図れる。
【０２８６】
図５５は、上記したような機能を有する構造化文書管理システムの構成例を示したものである。なお、図５５において、図１と同一部分には同一符号を付し、異なる部分についてのみ説明する。すなわち、図５５では、検索結果を一時記憶する検索結果記憶部２０１と、実行権限情報テーブル２０２とが新たに追加されている。
【０２８７】
検索結果記憶部２０１には、文書記憶部５、すなわち、構造化文書データベースに格納されているクエリを実行した結果、得られた検索結果が当該クエリに対応付けて記憶されている。
【０２８８】
実行権限情報テーブル２０２は、後述するように、クエリ実行権限のあるユーザと、クエリの実行権限はないが、そのクエリの検索結果は参照可能なユーザの識別情報を登録したテーブルである。
【０２８９】
このような構成の構造化文書管理システムの文書記憶部５に格納されている構造化文書データベースは、現在、図５６に示すような状態である場合を考える。。
【０２９０】
なお、図５６に示した構造化文書データベースの構造化文書の格納状態は、ノードやアークを簡略化し、ノードをオブジェクトＩＤではなく要素名や属性名で表して文書オブジェクトツリーの構造、しいていは、構造化文書データベースの構造を示している。
【０２９１】
図５６において、「ｒｏｏｔ」ノード以下には、「特許ＤＢ」ノードと「クエリＤＢ」ノードがある。「特許ＤＢ」ノード以下には、図５７に示すような文書構造の複数の「特許」情報が格納されている。「クエリＤＢ」ノード以下には、複数のクエリ文書（ＸＭＬ文書）が格納されている。
【０２９２】
図５７に示すように、「特許」情報は、「特許」タグから始まる要素をルート(根)とし、その子要素として「タイトル」、「出願日」、「出願者」、「要約」、「キーワード群」タグから始まる要素集合が存在する。また、「出願日」タグから始まる要素には、「年」「月」「日」タグか始める子要素を有し、「キーワード群」タグから始める要素には、１または複数の「キーワード」タグから始める子要素が存在する。
【０２９３】
図５６に示すように、構造化文書データベースには、予め複数のクエリ（ここでは、インデックス（［０］、［１］、…）を用いて表記されたクエリ［０］、クエリ［１］、…をそれぞれクエリＡ、クエリＢ、…と呼ぶ）が格納されている。
【０２９４】
第２の実施形態では、第１の実施形態で説明したような、クライアント端末から検索条件などを入力することにより作成されたクエリを構造化文書管理システムにて受け付けて検索を実行する以外に、構造化文書データベースに予め格納されているクエリから所望のクエリを選択し、検索結果格納部２０１に当該クエリに対応の検索結果が格納されているときは、その検索結果を読み出して、それをクライアント端末へ返すようになっている。
【０２９５】
構造化文書データベースに予め格納しておくクエリは、例えば、頻繁に用いられる検索条件のクエリであるとか、予め検索が予想されるクエリ、複数のユーザからユーザグループ内である特定の用途のために用いるクエリなど種々考えられる。
【０２９６】
例えば、図５６に示した構造化文書データベースに格納されているクエリのうちの１つであるクエリＡ（クエリ［０］ノード以下の部分文書に対応する）は、図５８に示すような内容のクエリであったとする。
【０２９７】
図５８に示すクエリは、単純検索のクエリの例を示したもので、図５６に示したような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群において、「１９９９年以降でかつ、「ＸＭＬ」をキーワードにもつ（「キーワード」という要素の値が「ＸＭＬ」である「特許」情報の「タイトル」を列挙せよ）という検索要求を意味している。
【０２９８】
図５８に示したクエリＡを検索要求処理部３で実行することにより、例えば、図５９に示したような検索結果Ａが得られたとする。
【０２９９】
検索結果記憶部２０１には、上記クエリＡと上記検索結果Ａとが対応付けて、例えば、図６０に示すようにテーブル形式で記憶される。
【０３００】
クエリＡを含む、構造化文書データベースに格納されている各クエリは、その論理的な格納領域を表す構造化文書パスにより、識別される。すなわち、各クエリの識別情報は、その構造化文書パスであり、例えば、クエリＡの識別情報は、「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ／クエリ［０］」となる。なお、説明の簡単のため、図６０以降の記述、および、以下の説明において、クエリ識別情報に関しては、「ｕｉｘ：／／ｒｏｏｔ」を省略して、「／クエリＤＢ／クエリ［０］」と簡略化する。
【０３０１】
検索要求処理部３に図６０に示しような検索結果記憶部２０１を持たせることにより、図５５の構造化文書管理システムは、図６１に示すような動作が可能となる。
【０３０２】
この場合、クライアント端末の所定の表示装置には、構造化文書管理システム１００（の例えば、要求制御部１）から提供された、例えば、図７０に示すようなユーザインターフェイスとしての画面が表示されている。
【０３０３】
図７０に示す画面の領域Ｗ１０１には、文書構造化文書データベースの現在のツリー構造のうちの一部であって、クエリ格納領域のツリー構造について、ユーザが理解可能なように簡略的に表示されている。なお、図７０では、上位階層の要素名のみを表示しているが、末端の要素名まで表示可能である。また、領域Ｗ１０２は、クエリの構造化文書パスの入力領域であり、領域Ｗ１０１の表示内容に従って、構造化文書パスを入力するようになっている。領域１０２にユーザが所望のクエリの構造化文書パスを入力した後、「検索実行」ボタンＷ１０３をクリックすると、クライアント端末からは、構造化文書パスにてクエリを指定した検索要求が構造化文書管理システムへ送信される。
【０３０４】
この検索要求は、例えば、予め定められた形式のコマンドとして（以下、簡単に検索要求コマンドと呼ぶ）、要求受付部１１で受け付けられる（ステップＳ２０１）。要求受付部１１は、当該検索要求コマンドを検索要求処理部３へ渡す。検索要求処理部３は、検索要求コマンドに含まれるクエリ識別情報としての構造化文書パスを取出し、検索結果記憶部２０１から、当該構造化文書パスのクエリ対応の検索結果が格納されているか否かチェックする。
【０３０５】
当該クエリ対応の検索結果が格納されているときは（ステップＳ２０２）、その検索結果を読み出し（ステップＳ２０３）、結果処理部１２を介して、ＸＭＬ文書としての当該検索結果を所定のスタイルシートとともに、要求元のクライアント端末に返す（ステップＳ２０４）。
【０３０６】
検索要求処理部３が実際に検索を実行するのは、上記ステップＳ２０２において、検索結果記憶部２０１に指定されたクエリ対応の検索結果が格納されていない場合である。この場合は、まず、構造化文書パスにて指定されたクエリをデータアクセス部４で構造化文書データベースから取得する（前述した、パスから文書オブジェクトツリー取得部４５における取得コマンドの実行時と同様）。そして、この取得したクエリを用いて、図４３のステップＳ１０２〜ステップＳ１０３に示したようにして、検索処理を行う（ステップＳ２０５）。そして、検索結果を要求元のクライアント端末に返す前に、クエリ識別情報に対応付けて検索結果記憶部２０１に格納する（ステップＳ２０６）。
【０３０７】
さて、構造化文書データベースは、随時、新たな構造化文書が追加登録されたり、削除されたりして更新されるわけだが、構造化文書データベース自体が更新されれば、同じクエリによる検索であってもデータベースの更新前と更新後の検索結果は異なることもある。
【０３０８】
上記したように、実際には検索を実行せずに、検索結果記憶部２０１に格納されている検索結果を読み出すといった動作を行う場合、データベース自体の更新に伴い、その更新を検索結果にも反映することが好ましい。
【０３０９】
そこで本発明では、そのための一手段として、ある特定のユーザが一定時間毎にクエリを実行し、その度に、得られた検索結果で検索結果記憶部２０１の内容を更新するようにする。このように、一定時間毎に検索結果記憶部２０１に記憶されている検索結果を更新しておくことで、構造化文書データベースの更新内容が検索結果に反映することができるとともに、検索結果とデータベースの状態との整合性を保つことができる。
【０３１０】
検索を実行可能な上記特定のユーザを予め定めて、一定時間毎に検索結果の更新をおこなうことにより、データベースと検索結果との内容の整合性を保つために、本発明では、具体的には、クライアント端末のユーザには上記構造化文書パスにて識別される各クエリについて、当該クエリを実行させることが可能なユーザと、当該クエリにより検索結果を参照することが可能なユーザと限定するために、クエリ実行権限と検索結果参照権限なるものを予め定めるようになっている。
【０３１１】
クエリ実行権限のあるユーザ（クエリ実行権限ユーザ）は、例えば、当該クエリを作成した者とする。また、例えば、このクエリ実行権限ユーザにより当該クエリによる検索結果の参照が許可されたユーザが検索結果参照権限ユーザである。図６２に示すように、各クエリ毎に予め定められたクエリ実行権限ユーザと検索結果参照権限ユーザの識別情報をテーブル形式で登録したものが、実行権限情報テーブル２０２である。
【０３１２】
なお、クエリ実行権限ユーザは、検索結果参照権限ユーザでもある。
【０３１３】
図６２に示すように、実行権限情報テーブルには、クエリ識別情報としての各クエリの構造化文書パスに対応させて、クエリ実行権限ユーザと検索結果参照権限ユーザのそれぞれのユーザ識別情報が列挙されている。
【０３１４】
このように、クエリ毎に当該クエリを実行させることが可能なユーザと、当該クエリにより検索結果を参照することが可能なユーザとを限定することにより、例えば、だれもかれもが、むやみやたらに検索を実行して、同じクエリによる検索結果であるのに、（データベースの内容が更新されていることにより）検索結果が様々になってしまうことを防ぎ、少なくとも上記一定期間の間は、誰が要求をしても同じクエリによる検索結果が同じであるという好ましい状態を作り出すことができる。これは、検索結果とデータベースの内容の整合性と保つためには重要なことである。
【０３１５】
なお、実行権限情報テーブルは、例えば、クライアント端末に図６２に示したな入力画面が表示され、このような入力画面から所定の事項を入力して、システムに登録するようになっていてもよい。
【０３１６】
検索要求処理部３に図６０に示しような検索結果記憶部２０１と図６２に示したような実行権限情報テーブル２０２とを持たせることにより、図５５の構造化文書管理システムは、図６３に示すような動作が可能となる。
【０３１７】
すなわち、クライアント端末からは、例えば、図７０に示したような入力画面を介して、構造化文書パスにてクエリを指定した検索要求が構造化文書管理システムへ送信される。この検索要求は、例えば、予め定められた形式のコマンドとして（以下、簡単に検索要求コマンドと呼ぶ）、要求受付部１１で受け付けられる（ステップＳ２１１）。要求受付部１１は、当該検索要求コマンドを検索要求処理部３へ渡す。
【０３１８】
検索要求処理部３は、検索要求コマンドに含まれるクエリ識別情報としての構造化文書パスを取出し、当該クエリによる前回の検索実行時から、予め定められた一定期間が経過したか否かをチェックする。このチェックのために、検索要求処理部３は、予めタイマを持つものとする（ステップＳ２１２）。
【０３１９】
一定期間がまだ経過していないときは、ステップＳ２１３へ進み、実行権限情報テーブル２０２を参照する。
【０３２０】
検索要求コマンドに含まれる要求元のユーザの識別情報が、実行権限情報テーブル２０２に当該クエリ対応の検索結果参照権限ユーザあるいはクエリ実行権限ユーザとして登録されているときは（ステップＳ２１３）、検索結果記憶部２０１から、当該構造化文書パスのクエリ対応の検索結果を読み出し（ステップＳ２１４）、結果処理部１２を介して、ＸＭＬ文書としての当該検索結果を所定のスタイルシートとともに、要求元のクライアント端末に返す（ステップＳ２１５）。
【０３２１】
上記ステップＳ２１２において、上記一定期間が経過しているときは、ステップＳ２１６へ進み、実行権限情報テーブル２０２を参照する。
【０３２２】
検索要求コマンドに含まれる要求元のユーザの識別情報が、実行権限情報テーブル２０２に当該クエリ対応のクエリ実行権限ユーザとして登録されているときは（ステップＳ２１６）、まず、構造化文書パスにて指定されたクエリをデータアクセス部４で構造化文書データベースから取得する（前述した、パスから文書オブジェクトツリー取得部４５における取得コマンドの実行時と同様）。そして、この取得したクエリを用いて、図４３のステップＳ１０２〜ステップＳ１０３に示したようにして、検索処理を行う（ステップＳ２１７）。そして、検索結果を要求元のクライアント端末に返す（ステップＳ２１５）前に、クエリ識別情報に対応付けて検索結果記憶部２０１に格納する（ステップＳ２１８）。
【０３２３】
前述した、構造化文書データベース自体の更新に伴い、その更新を検索結果にも反映するための他の手段としては、本発明では、構造化文書データベースの更新を検知して、そにより自動的に検索結果を更新するようになっている。
【０３２４】
この構造化文書データベースの更新を検知して、検索結果の自動更新を行うための主要な機能を担うのが、図６４のイベント検出部２０３である。
【０３２５】
ここでは、構造化文書データベースの更新をイベントとして検知する。例えば、構造化文書データベースの構造上のどこがどのように更新されたか、また、いつ更新されたかにより、その更新が検索結果に影響を及ぼすクエリとそうでないクエリとが存在するので、各クエリ対応のイベントを設定し、各クエリ対応のイベントを検知するために、各イベントの条件（イベント条件）を設定する。
【０３２６】
イベント検出部２０３は、図６５に示しようなイベントテーブル２０４を予め記憶している。このイベントテーブル２０４には、構造化文書データベースの更新をイベントとして検知するための条件や、当該条件を満たすイベントが検出されたとき、（検索結果を更新すべく）検索を実行するためのクエリを示した検索結果更新パスとが、当該条件を登録したユーザ（イベントユーザ）に対応付けて登録されている。
【０３２７】
なお、イベントテーブル中の「イベントユーザ」の欄は、イベントテーブルにユーザが明示的に登録するのではなく、構造化文書管理システムにアクセスする際にユーザにより入力されるユーザ識別情報に基づきシステム側が自動的に登録することが望ましい。
【０３２８】
このイベントテーブルに登録されているイベントには大きく分けて、日時イベントとデータ操作イベントとがある。
【０３２９】
日時イベントは、構造化文書データベースに対する何らかの操作（例えば、ｉｎｓｅｒｔＸＭＬ：文書格納、ａｐｐｅｎｄＸＭＬ：文書格納、ｒｅｍｏｖｅＸＭＬ：文書削除、などのコマンドの実行に伴う構造化文書データベースの更新）には関係なく、イベント条件として指定した日時が到来したとき、イベントとして検知される。例えば、図６５では、イベント番号「３」に登録されているイベントは「２００１年２月２７日木曜日１２時００分００秒になったときイベントとして検知し、その際、検索結果更新パスで指定されたクエリ「／クエリＤＢ／クエリ［２］」で検索を実行し、検索結果記憶部２０１に格納されている当該クエリの検索結果を更新する」ためのものである。なお、このようなイベントを登録したユーザ（イベントユーザ）の識別情報が「ｋａｎａｗａ」である。
【０３３０】
データ操作イベントは、構造化文書データベースに対し、イベント条件として指定した構造化文書パス以下に、イベント条件として指定した何らかの操作（例えば、ｉｎｓｅｒｔＸＭＬ：文書格納、ａｐｐｅｎｄＸＭＬ：文書格納、ｒｅｍｏｖｅＸＭＬ：文書削除、などのコマンドの実行に伴う構造化文書データベースの更新）がなされたときに、イベントとして検知される。例えば、図６５では、イベント番号「１」に登録されているイベントは「構造化文書パス「／特許ＤＢ」以下の領域に文書格納コマンドが実行されたときイベントとして検知し、その際、検索結果更新パスで指定されたクエリ「／クエリＤＢ／クエリ［０］」で検索を実行し、検索結果記憶部２０１に格納されている当該クエリの検索結果を更新する」ためのものである。なお、このようなイベントを登録したユーザ（イベントユーザ）の識別情報が「ｎｉｉｎａ」である。
【０３３１】
例えば、図７１に示すような入力画面をクライアント端末に表示して、図６５に示したイベントテーブルに各イベントを登録するようにしてもよい。
【０３３２】
図７１に示した入力画面には、日時イベント、データ操作イベント、検索結果更新パスの設定を行うためのそれぞれの入力領域Ｗ１１１〜Ｗ１１４が設けられており、ユーザは、必要な事項を入力してから「登録」ボタンＷ１１５をクリックすればよい。すると、構造化文書管理システムへ、上記入力内容が送信されて、イベントテーブル２０４に登録される。
【０３３３】
なお、イベントテーブルに登録されている各イベント対応のイベントユーザとは、図６２に示した各クエリ毎に定められたクエリ実行権限ユーザに相当する。すなわち、クエリ実行権限ユーザが図６５に示したようなイベントテーブルにイベントを登録することにより、クエリ実行権限ユーザが、実際にクエリを実行させるのではなく、クエリ実行権限ユーザに代わってシステム自身がクエリを実行するようになっている。
【０３３４】
もちろん、上記イベントテーブルに登録された各イベント検知時に各クエリを実行する際に、そのクエリの実行権限の有り無しを考慮せずとも、本発明の目的（構造化文書データベースと検索結果との内容の整合性を保つこと）は達成される。
【０３３５】
図６６は、図６４の構造化文書管理システムの処理動作を示したもので、上記イベントテーブルに登録された各イベント検知時に各クエリを実行する際に、そのクエリの実行権限の有り無しを考慮しない場合を示したフローチャートである。
【０３３６】
イベント検出部２０３は、データアクセス部４の文書オブジェクトツリー格納部４１，文書オブジェクトツリー削除部４２などで、ｉｎｓｅｒｔＸＭＬ：文書格納、ａｐｐｅｎｄＸＭＬ：文書格納、ｒｅｍｏｖｅＸＭＬ：文書削除、などのコマンドに対応する処理の実行がされたか否か、また、イベント検出部２０３が持つタイマを参照して、イベントテーブルにイベント条件として設定された日時が到来したか否かを常時監視している（ステップＳ２２１）。図６５に示したイベントテーブルに登録されているイベント条件のいずれかを満たすイベントを検知したとき（ステップＳ２２２）、その検知したイベントに対応する検索結果更新パスをイベントテーブルから取得する（ステップＳ２２３）。
【０３３７】
まず、検索結果更新パスにて指定されたクエリをデータアクセス部４で構造化文書データベースから取得する（前述した、パスから文書オブジェクトツリー取得部４５における取得コマンドの実行時と同様）。そして、この取得したクエリを検索要求処理部３に渡し、検索要求処理部３では、当該受け取ったクエリを用いて、図４３のステップＳ１０２〜ステップＳ１０３に示したようにして、検索処理を行う（ステップＳ２２４）。
【０３３８】
検索処理部３は、検索結果を当該クエリのクエリ識別情報に対応付けて検索結果記憶部２０１に格納する（ステップＳ２２５）。
【０３３９】
次に、図６７に示すフローチャートを参照して、上記イベントテーブルに登録された各イベント検知時にその検知されたイベント対応のクエリを実行する際に、そのクエリの実行権限の有り無しを考慮する場合の図６４に示した構造化文書管理システムの処理動作について説明する。
【０３４０】
さて、イベント検出部２０３は、図６６の場合と同様、データアクセス部４の文書オブジェクトツリー格納部４１，文書オブジェクトツリー削除部４２などで、ｉｎｓｅｒｔＸＭＬ：文書格納、ａｐｐｅｎｄＸＭＬ：文書格納、ｒｅｍｏｖｅＸＭＬ：文書削除、などのコマンドに対応する処理の実行がされたか否か、また、イベント検出部２０３が持つタイマを参照して、イベントテーブルにイベント条件として設定された日時が到来したか否かを常時監視している（ステップＳ２３１）。図６５に示したイベントテーブルに登録されているイベント条件のいずれかを満たすイベントを検知したとき（ステップＳ２３２）、その検知したイベントに対応するイベントユーザの識別情報と検索結果更新パスとをイベントテーブルから取得する（ステップＳ２３３）。
【０３４１】
この取得したイベントユーザの識別情報と検索結果更新パスは、イベント検出部２０３から検索要求処理部３へ渡される。
【０３４２】
検索要求処理部３は、図６２に示したような実行権限情報テーブルから、受け取った検索結果更新パスにて指定されたクエリに対し実行権限のあるユーザ（クエリ実行権限ユーザ）の識別情報を取出し、それと、イベント検出部２０３から受け取ったイベントユーザの識別情報とを比較し（ステップＳ２３４）、それらが一致しているときには、ステップＳ２３５へ進み、当該検索結果更新パスにて指定されたクエリを実行する（ステップＳ２３５）。
【０３４３】
すなわち、まず、検索結果更新パスにて指定されたクエリをデータアクセス部４で構造化文書データベースから取得する（前述した、パスから文書オブジェクトツリー取得部４５における取得コマンドの実行時と同様）。そして、この取得したクエリを検索要求処理部３に渡し、検索要求処理部３では、当該受け取ったクエリを用いて、図４３のステップＳ１０２〜ステップＳ１０３に示したようにして、検索処理を行う（ステップＳ２３５）。
【０３４４】
検索処理部３は、検索結果を当該クエリのクエリ識別情報に対応付けて検索結果記憶部２０１に格納する（ステップＳ２３６）。
【０３４５】
なお、ステップＳ２３４で、クエリ実行権限ユーザとイベントユーザとが異なるときは、イベント検出部２０３から受け取ったクエリの実行を拒否し、処理を終了する。
【０３４６】
このように、イベント検知時に、そのイベントの実行権限のあるユーザと、当該イベントの条件を登録したイベントユーザが同じであるか否かをチェックすることにより、例えば、実行権限のないユーザにより、イベントテーブルに、正当なクエリ実行権限ユーザが定められているクエリを用いた検索実行のイベント条件が登録された場合、そのようなイベントにより当該クエリが実行されることを防ぐことができる。従って、検索結果記憶部２０１に格納されている当該クエリ対応の検索結果を不正に書き換えられることを防ぐことができるという効果がある。
【０３４７】
次に、図６８に示すフローチャートを参照して、構造化文書パスにてクエリを指定した検索要求が送信されてきたときの図６４の構造化文書管理システムの処理動作について説明する。なお、図６４に示す構成の場合、イベントが登録されている検索結果は自動的に更新されるので、図６８に示す検索要求は、検索結果の参照要求としてもよい。
【０３４８】
さて、検索要求は、例えば、図７０に示した入力画面を介して、予め定められた形式のコマンドとして（以下、簡単に検索要求コマンドと呼ぶ）、要求受付部１１で受け付けられる（ステップＳ２４１）。要求受付部１１は、当該検索要求コマンドを検索要求処理部３へ渡す。
【０３４９】
検索要求処理部３は、検索要求コマンドに含まれる、クエリ識別情報としての構造化文書パスと要求元のユーザの識別情報とを取出す。そして、要求元のユーザの識別情報が検索結果の参照権限のあるユーザか否かをチェックする（ステップＳ２４２）。当該要求元のユーザの識別情報が、実行権限情報テーブル２０２に当該クエリ対応の検索結果参照権限ユーザあるいはクエリ実行権限ユーザとして登録されているときは、検索結果記憶部２０１から、当該構造化文書パスのクエリ対応の検索結果を読み出し（ステップＳ２４３）、結果処理部１２を介して、ＸＭＬ文書としての当該検索結果を所定のスタイルシートとともに、要求元のクライアント端末に返す（ステップＳ２４４）。
【０３５０】
なお、ステップＳ２４２において、当該要求元のユーザの識別情報が、実行権限情報テーブル２０２に当該クエリ対応の検索結果参照権限ユーザとしても、また、クエリ実行権限ユーザとしても登録されていないときは、そのまま処理を終了する。
【０３５１】
図６９は、イベントテーブル２０４の他の例を示したものである。日時イベントの代わりに有効期限イベントがある点で図６５とは異なる。
【０３５２】
有効期限イベントは、イベント条件として、検索結果記憶部２０１に格納されている検索結果の有効期限として、ある一定の期間が設定され、その期間が経過する度にイベントとして検知される。例えば、図６９では、イベント番号「３」に登録されているイベントは「検索結果更新パスにて示されるクエリ「／クエリＤＢ／クエリ［２］」対応の検索結果の有効期限は１２時間であり、当該クエリを実行してから１２時間経過する度に検索を実行し、検索結果記憶部２０１に格納されている当該クエリの検索結果を更新する」ためのものである。
【０３５３】
図６９に示したイベントテーブルを用いてイベントを検知し、検索結果を更新するための処理動作は、図６７と同様である。
【０３５４】
以上説明したように、本発明によれば、例えば、頻繁に用いられる検索条件のクエリであるとか、予め検索が予想されるクエリ、複数のユーザからユーザグループ内である特定の用途のために用いるクエリなどを構造化文書データベースに予め格納しておき、そのようなクエリの検索が実行されたときは、その結果結果を当該クエリに対応付けて記憶しておくことにより、その後に、再び同じクエリによる検索要求がなされたときは、実際に検索を行わず、記憶した検索結果を要求元へ返すことにより、構造化文書データベースに対する検索が効率よく行える。
【０３５５】
ある特定のユーザ（第１の種別のユーザ）のみに、クエリの検索実行の権限を与えて、この権限のあるユーザからの検索要求に対しては、実際に検索を行って、当該クエリに対応付けて記憶した検索結果の更新を行うことにより、構造化文書データベースの更新内容が検索結果に反映することができ、構造化文書データベースの現状との整合性を保ちながら検索が効率よく行える。
【０３５６】
好ましくは、前記第１の種別のユーザから前記検索要求を受け付けたとき、前回検索を実行した時点から所定時間経過しているときは、前記指定された検索要求文に基づき検索を行い、前記所定時間が経過していないときは、前記指定された検索要求文に対応付けて記憶されている検索結果を読み出す。これにより、ある特定のユーザ（第１の種別のユーザ）のみに、クエリの検索実行の権限を与えて、定期的に当該クエリに対応付けて記憶した検索結果の更新を行うことにより、構造化文書データベースの更新内容が検索結果に反映することができ、構造化文書データベースの現状との整合性を保ちながら検索が効率よく行える。
【０３５７】
このように、クエリ毎に当該クエリを実行させることが可能なユーザと、当該クエリにより検索結果を参照することが可能なユーザとを限定することにより、例えば、だれもかれもが、むやみやたらに検索を実行して、同じクエリによる検索結果であるのに、（データベースの内容が更新されていることにより）検索結果が様々になってしまうことを防ぐことができる。
【０３５８】
また、少なくとも上記所定時間の間は、誰が要求をしても同じクエリによる検索結果が同じであるという好ましい状態を作り出すことができる。これは、検索結果とデータベースの内容の整合性と保つためには重要なことである。
【０３５９】
また、好ましくは、前記構造化文書データベースが更新されたとき、該構造化文書データベースに格納されている前記複数の検索要求文のうち、該構造化文書データベースの更新内容が検索結果に影響するような検索要求文を選択して、その選択された検索要求文に基づき前記構造化文書データベースに対し検索を行って、該検索要求文に対応付けて記憶された検索結果を更新することにより、構造化文書データベース自体の更新に伴い、その更新を検索結果に自動的に反映させることができる。従って、検索結果とデータベースの内容の整合性を保つことが容易に行える。
【０３６０】
なお、本発明の実施の形態に記載した本発明の手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピーディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、半導体メモリなどの記録媒体に格納して頒布することもできる。
【０３６１】
なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。さらに、上記実施形態には種々の段階の発明は含まれており、開示される複数の構成用件における適宜な組み合わせにより、種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題（の少なくとも１つ）が解決でき、発明の効果の欄で述べられている効果（のなくとも１つ）が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【０３６２】
【発明の効果】
以上説明したように、本発明によれば、構造化文書データベースに対する検索が効率よく行える。また、構造化文書データベースの現状との整合性を保ちながら検索が効率よく行える。
【図面の簡単な説明】
【図１】本発明の実施形態に係る構造化文書管理システムの構成例を示した図。
【図２】図１に示した構造化文書管理システムの一利用形態を示したもので、ＷＷＷのバックエンドで、構造化文書管理システムが動作している場合を示した図。
【図３】ＸＭＬで記述された構造化文書の一例を示した図。
【図４】図３の構造化文書の文書構造を模式的に示した図。
【図５】追加コマンドの機能を説明するための図で、構造化文書データベースの初期状態に追加コマンドを実行した場合について示している。
【図６】図５（ｂ）に示した状態の構造化文書データベースに対し、取得コマンドを実行した場合の処理結果を示した図。
【図７】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して１つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図８】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して３つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図９】要素名生起インデックスの格納例を示した図。
【図１０】データ生起インデックスの格納例を示した図。
【図１１】図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合の実行結果を示した図。
【図１２】ＸＭＬ文書の文書構造を定義するスキーマの一例を示した図。
【図１３】図８に示した状態の構造化文書データベースに、スキーマ格納コマンドを実行して、図１２に示したスキーマを追加格納（設定）した場合を示した図。
【図１４】スキーマが設定されて、スキーマが存在している旨の属性値のセットされた文書オブジェクトツリーを示した図。
【図１５】各オブジェクトファイルに、スキーマが存在している旨の属性値が格納されている様子を概念的に示した図。
【図１６】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１７】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１８】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図１９】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図２０】図１の構造化文書管理システムの文書格納処理動作について説明するためのフローチャート。
【図２１】図２０のステップＳ９の処理（合成文書作成部の処理）について説明するためのフローチャート
【図２２】追加コマンド中のパラメータの格納文書の文書オブジェクトツリーを構造化文書データベースから取得した文書オブジェクトツリーに挿入して得られた合成文書の文書オブジェクトツリーをＸＭＬ文書に変換した結果であって、テンポラリファイルＡに格納される合成文書の一例を示した図。
【図２３】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図２４】テンポラリファイルＡに格納される合成文書の他の例を示した図。
【図２５】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図２６】図１の構造化文書管理システムの文書取得処理動作について説明するためのフローチャート。
【図２７】図１の構造化文書管理システムの文書削除処理動作について説明するためのフローチャート。
【図２８】図２７のステップＳ４６の処理（合成文書作成部の処理（削除コマンド用））について説明するためのフローチャート。
【図２９】テンポラリファイルＡに格納される合成文書のさらに他の例であって、削除コマンドの実行時に作成される合成文書の一例を示した図。
【図３０】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図３１】ユーザインタフェースとしての画面の表示例を示した図。
【図３２】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３３】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３４】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３５】妥当性のチェックでエラーとなっときにクライアント端末へ返すメッセージの表示例を表示例を示した図。
【図３６】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示したもので、文書取得動作を説明するための図。
【図３７】スキーマの設定を行うためのユーザインタフェースとしての画面の表示例を示したもので、スキーマの設定動作を説明するための図。
【図３８】スキーマの取得するためのユーザインタフェースとしての画面の表示例を示したもので、取得されたスキーマの表示例を示している。
【図３９】クエリ（ＸＭＬ文書）の一例を示した図。
【図４０】単純検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図４１】図４０の単純検索のクエリを用いた検索結果（ＸＭＬ文書）を示した図。
【図４２】概念検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図４３】図１の構造化文書管理システムの文書検索処理動作について説明するためのフローチャート。
【図４４】文書検索を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図４５】図４４に示した画面上から入力された情報に基づき作成されるクエリを示した図。
【図４６】図４２に示したクエリの構造化文書データベース内における格納例を示した図。
【図４７】文書検索を行うためのユーザインタフェースとしての画面の表示例であって、スキーマの検索処理動作を説明するための図。
【図４８】スキーマ検索のクエリの一例を示した図。
【図４９】クエリを検索するためのクエリの一例を示した図。
【図５０】特許調査における構造化文書データベースの一例を示した図。
【図５１】概念検索のための入力画面の表示例を示した図。
【図５２】図５１に示した入力画面上の入力情報に対応するクエリを示した図。
【図５３】図５２に示したクエリに対応する検索結果としてのＸＭＬ文書を示した図。
【図５４】特許マップの一例を示した図。
【図５５】第２の実施形態に係る構造化文書管理システムの構成例を示した図。
【図５６】構造化文書データベースの一例を示した図。
【図５７】構造化文書の一例であって、「特許」情報を示した図。
【図５８】構造化文書データベースに格納されているクエリの一例を示した図。
【図５９】図５８のクエリを実行した結果得られた検索結果の一例を示した図。
【図６０】検索結果記憶部の記憶例を示した図。
【図６１】図５５の構造化文書管理システムの処理動作を説明するためのフローチャートで、検索要求を行ったユーザのクエリ実行権限の有無を考慮しない場合を示している。
【図６２】実行権限情報テーブルの一例を示した図。
【図６３】図５５の構造化文書管理システムの処理動作を説明するためのフローチャートで、検索要求を行ったユーザのクエリ実行権限の有無を考慮した場合を示している。
【図６４】第２の実施形態に係る構造化文書管理システムの他の構成例を示した図。
【図６５】イベントテーブルの一例を示した図。
【図６６】イベントテーブルに登録された各イベント検知時に、その検知したイベント対応のクエリを実行する際に、そのクエリの実行権限の有り無しを考慮すしない場合の図６４に示した構造化文書管理システムの処理動作について説明するためのフローチャート。
【図６７】イベントテーブルに登録された各イベント検知時に、その検知したイベント対応のクエリを実行する際に、そのクエリの実行権限の有り無しを考慮する場合の図６４に示した構造化文書管理システムの処理動作について説明するためのフローチャート。
【図６８】構造化文書パスにてクエリを指定した検索要求（検索結果の参照要求）が送信されてきたときの図６４の構造化文書管理システムの処理動作について説明するためのフローチャート。
【図６９】イベントテーブルの他の例を示した図。
【図７０】クライアント端末に表示される検索画面の一例を示した図。
【図７１】クライアント端末に表示されるイベント登録画面の一例を示した図。
【符号の説明】
１…要求制御部
２…アクセス要求処理部
３…検索要求処理部
４…データアクセス部
５…文書記憶部
６…インデックス記憶部
１１…受付要求部
１２…結果処理部
２１…文書格納部
２２…文書取得部
２３…文書削除部
４１…文書オブジェクトツリー格納部
４２…文書オブジェクトツリー削除部
４３…文書オブジェクトツリー取得部
４４…文書文字列取得部
４５…パスから文書オブジェクトツリー取得部
４６…文書パーサ
４７…合成文書作成部
４８…インデックス更新部
１００…構造化文書管理システム
１０１…ＷＷＷサーバ
１０２…クライアント端末
１０３…ＷＷＷブラウザ
２０１…検索結果記憶部
２０２…実行権限情報テーブル
２０３…イベント検出部
２０４…イベントテーブル
【発明の属する技術分野】
本発明は、異なる文書構造の複数の構造化文書を、階層化された論理構造を持つ構造化文書データベースで管理する構造化文書管理システムに関する。
【０００２】
【従来の技術】
現在、ＩＴ（情報技術）の進化により、莫大な量の情報が容易に入手できるようになった。その一方で必要な情報が大量のデータに埋没してしまい、十分に活用できないという弊害も発生している。情報が大量に存在していても、それをうまく活用できなければ意味がない。
【０００３】
そこで、特定の個人や部門が保有するノウハウや業務データのうち企業の経営に重要なものを蓄積して、「経営資産」として活用しようとする活動、すなわち、ナレッジマネージメントが提唱されている。
【０００４】
例えば、特許明細書や、週報など、文書の種類によっては、その書式が予め定められて、１つの書式に統一されているのが一般的である。１つの書式に統一された文書もあれば、全く書式のない自由書式の文書も数多く存在する。
【０００５】
従って、ナレッジマネージメントを実現するためには、このような文書構造が予め定められているような文書も、それ以外の自由書式の文書も全て格納管理できるデータベースが必要となる。
【０００６】
次世代のナレッジマネージメントの中核技術として期待されている技術がＸＭＬである。ＸＭＬ（Ｅｘｔｅｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）は柔軟な拡張性と連携性を備えた標準のドキュメント記述言語であり、主要ベンダーからのサポートも約束されている。
【０００７】
構造化文書データベースとしては、ＲＤＢ（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢｅｓｅ）により構造化文書を格納する方式があるが、この場合、１つのスキーマ（データ構造定義）に従った文書構造の構造化文書群しか格納できす、また、文書構造はそのまま表形式に変換することは困難であり、ＲＤＢをそのまま構造化文書データベースとして用いることはできない。
【０００８】
また、構造化文書は階層的な構造をもつため、構造化文書を構成する各構成要素をオブジェクトとみなしたＯＯＤＢ（オブジェクト指向データベース）と親和性が高いと考えられる。しかし、ＯＯＤＢでは、文書構造は予めスキーマにより決定されていなければならず、子要素の任意繰り返しなど、オブジェクトモデルでモデル化するのは困難であり、ＯＯＤＢをそのまま構造化文書データベースとして用いることはできない。
【０００９】
ＸＭＬ文書はツリー構造を持ったデータである。近年、このようなＸＭＬ文書を蓄積、管理するＸＭＬデータベースが脚光を浴びている。
【００１０】
ＸＭＬデータベースは、管理対象の複数の構造化文書の各構成要素を１つの巨大な構造化文書の文書構造を構成する構成要素として管理するＸＭＬ特化のツリー状の階層的なデータ構造を持つ。階層的な構造上の構成要素は「パス」により特定される。パスは、ＸＭＬデータベース上の特定のエリアを指し示すための手段である。
【００１１】
ＸＭＬデータベースに格納されるＸＭＬ文書群はツリー状の１つの巨大なＸＭＬ文書として構成される。部分的なＸＭＬ文書をアクセスするには、ＸＭＬ文書に対するパスというアクセス手段を用いる。このような特徴により、幅広くＸＭＬ文書を検索したり加工することが可能となる。
【００１２】
ＸＭＬデータベースで格納されるＸＭＬ文書の文書構造は、必ずしもスキーマが定義されている必要はないが、スキーマを定義するとしたら、１つのデータベースに１つのスキーマしか許容されていない。すなわち、スキーマを用いなければ、異なる文書構造の文書を混在させて格納・管理することができるが、スキーマを１つ設定したら、それとは異なる文書構造の文書は混在させることはできない。
【００１３】
【発明が解決しようとする課題】
異なる文書構造の膨大な数の構造化文書をデータベース上で格納・管理するには、ある特定の種類の文書に特定の文書構造が予め定められている場合、そのような種類の文書は、全て同じ文書構造に統一されている方が、後に、検索等のデータ操作の際に都合がよい。
【００１４】
しかし、従来のＸＭＬデータベースでは、１つのデータべース上で種類の違いにより異なる文書構造の文書をそれぞれの種類対応の文書構造で統一性を保持しながら、格納、管理できるものはなかった。すなわち、１つのスキーマに適合した文書の格納・管理はできても、複数のスキーマを混在させてスキーマ対応していない文書とともに、各スキーマ対応の文書の格納・管理はできなかった。
【００１５】
複数のスキーマのそれぞれに対応する複数のデータベースを設けることも考えられるが、この場合、スキーマが異なればアクセスするデータベースも異なる。そのため、多種多様な文書構造の膨大な数の文書へのアクセスが統一的でなく、多種多様な膨大な情報の中から関連する情報群を検索・抽出することが困難であった。
【００１６】
このように、従来は、多種多様な文書構造定義に従った文書を、その文書の種類対応に予め定められた文書構造の同一性を保持しながら、文書構造の定義がなされていない構造化文書とともに一元管理することができないがため、多種多様な文書構造の文書に対し、統一的なアクセスにて、多種多様な膨大な情報の中から関連する情報群を特定の文書構造に限定されずに検索・抽出することができなかった。
【００１７】
また、構造化文書データベースでは、文書構造や語彙を検索条件にして検索を行うようになっている。この場合、管理対象の文書の数が多くなればなるほど、検索時間に長時間を要する。従って、できるだけ、効率のよい検索を行うための手法を講じることが望ましい。特に、頻繁に用いられるような検索条件が存在する場合、そのような検索条件を含む検索を、要求を受けたたびに実行するのでは、効率が悪い。
【００１８】
また、構造化文書データベースには、異なる文書構造の数多くの構造化文書が随時追加あるいは削除されるであろう。このような構造化文書データベースの更新が頻繁に発生する状況下においては、構造化文書データベースの現状との整合性を保ちながら効率のよい検索が行えることが望ましい。
【００１９】
そこで、本発明は、構造化文書データベースに対する検索が効率よく行える構造化文書検索方法および、それを用いた構造化文書検索装置および構造化文書管理装置を提供することを目的とする。
【００２０】
また、本発明は、構造化文書データベースの現状との整合性を保ちながら検索が効率よく行える構造化文書検索方法および、それを用いた構造化文書検索装置および構造化文書管理装置を提供することを目的とする。
【００２１】
【課題を解決するための手段】
本発明は、異なる文書構造の複数の構造化文書を格納した階層化された論理構造を持つ構造化文書データベースに対して、前記論理構造を構成する前記構造化文書の構成要素とその値を検索条件に含む検索要求文に基づき検索を行うものであって、前記構造化文書データベースには、該構造化文書データベースに対し検索を行うための予め前記検索条件の設定された複数の検索要求文が格納され、前記複数の検索要求文のうちの１つを指定した検索要求を受け付けたとき、前記指定された検索要求文に基づき検索を行って、得られた検索結果を要求元に送るとともに、該検索結果を該検索要求文に対応付けて記憶し、前記検索要求を受け付けたときに、前記指定された検索要求文に対応付けて検索結果が記憶されているときは、その記憶されている検索結果を読み出して要求元に送ることを特徴とする。
【００２２】
本発明によれば、例えば、頻繁に用いられる検索条件のクエリであるとか、予め検索が予想されるクエリ、複数のユーザからユーザグループ内である特定の用途のために用いるクエリなどを構造化文書データベースに予め格納しておき、そのようなクエリの検索が実行されたときは、その結果結果を当該クエリに対応付けて記憶しておくことにより、その後に、再び同じクエリによる検索要求がなされたときは、実際に検索を行わず、記憶した検索結果を要求元へ返すことにより、構造化文書データベースに対する検索が効率よく行える。
【００２３】
本発明は、異なる文書構造の複数の構造化文書を格納した階層化された論理構造を持つ構造化文書データベースに対して、前記論理構造を構成する前記構造化文書の構成要素とその値を検索条件に含む検索要求文に基づき検索を行うものであって、前記構造化文書データベースには、該構造化文書データベースに対し検索を行うための予め検索条件の設定された複数の検索要求文が格納され、前記検索要求文には、少なくともその検索要求文に基づく検索実行が許可されている第１の種別のユーザと、該検索要求文に基づく検索実行は許可されていないが該検索要求文対応の検索結果は参照することが許可されている第２の種別のユーザとが設定され、前記第１の種別のユーザから、前記複数の検索要求文のうちの１つを指定した検索要求を受け付けたとき、前記指定された検索要求文に基づき検索を行って、得られた検索結果を要求元に送るとともに、該検索結果を該検索要求文に対応付けて記憶し、前記第２の種別のユーザから前記検索要求を受け付けたときは、前記指定された検索要求文に対応付けて記憶されている検索結果を読み出して要求元に送ることを特徴とする。
【００２４】
本発明によれば、ある特定のユーザ（第１の種別のユーザ）のみに、クエリの検索実行の権限を与えて、この権限のあるユーザからの検索要求に対しては、実際に検索を行って、当該クエリに対応付けて記憶した検索結果の更新を行うことにより、構造化文書データベースの更新内容が検索結果に反映することができ、構造化文書データベースの現状との整合性を保ちながら検索が効率よく行える。
【００２５】
好ましくは、前記第１の種別のユーザから前記検索要求を受け付けたとき、前回検索を実行した時点から所定時間経過しているときは、前記指定された検索要求文に基づき検索を行い、前記所定時間が経過していないときは、前記指定された検索要求文に対応付けて記憶されている検索結果を読み出す。これにより、ある特定のユーザ（第１の種別のユーザ）のみに、クエリの検索実行の権限を与えて、定期的に当該クエリに対応付けて記憶した検索結果の更新を行うことにより、構造化文書データベースの更新内容が検索結果に反映することができ、構造化文書データベースの現状との整合性を保ちながら検索が効率よく行える。
【００２６】
このように、クエリ毎に当該クエリを実行させることが可能なユーザと、当該クエリにより検索結果を参照することが可能なユーザとを限定することにより、例えば、だれもかれもが、むやみやたらに検索を実行して、同じクエリによる検索結果であるのに、（データベースの内容が更新されていることにより）検索結果が様々になってしまうことを防ぐことができる。
【００２７】
また、少なくとも上記所定時間の間は、誰が要求をしても同じクエリによる検索結果が同じであるという好ましい状態を作り出すことができる。これは、検索結果とデータベースの内容の整合性と保つためには重要なことである。
【００２８】
また、好ましくは、前記構造化文書データベースが更新されたとき、該構造化文書データベースに格納されている前記複数の検索要求文のうち、該構造化文書データベースの更新内容が検索結果に影響するような検索要求文を選択して、その選択された検索要求文に基づき前記構造化文書データベースに対し検索を行って、該検索要求文に対応付けて記憶された検索結果を更新することにより、構造化文書データベース自体の更新に伴い、その更新を検索結果に自動的に反映させることができる。従って、検索結果とデータベースの内容の整合性を保つことが容易に行える。
【００２９】
【発明の実施の形態】
まず、本発明の実施形態について説明する前に、構造化文書管理システムについて説明する。
【００３０】
（構造化文書管理システムの説明）
構造化文書として、ＸＭＬやＳＧＭＬなどで記述した文書が挙げられる。ＳＧＭＬ（Ｓｔａｎｄａｒｄ Ｇｅｎｅｒａｌｉｚｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）とは、ＩＳＯ（国際標準化機構）で定められた規格である。ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）とは、Ｗ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）にて定められた規格である。それぞれ文書を構造化することを可能とする構造化文書規約である。
【００３１】
以下、構造化文書として、ＸＭＬにて記述された文書を例に説明を進める。構造化文書の文書構造を定義したデータ（文書構造定義データ）をスキーマと呼ぶ。ＸＭＬではそのスキーマを定義するためにＸＭＬ−ＳｃｈｅｍａやＸＤＲ（ＸＭＬ Ｄａｔａ Ｒｅｄｕｃｅｄ）などのスキーマ言語が提案されている。ここでは、例えば、ＸＤＲでのスキーマを記述する場合を例にとり説明する。
【００３２】
スキーマも、構造化文書管理システムの管理対象の構造化文書であり、従って、スキーマ文書と呼ぶことがある。スキーマ文書と区別するために、特許明細書やメール、週報、広告などの種々雑多な内容を有す文書をコンテンツ文書と呼ぶこともある。
【００３３】
構造化文書管理システムでは、上記スキーマ文書、上記コンテンツ文書、さらに、後述するようなユーザからの検索要求内容を記述したクエリ、すなわち、クエリ文書も管理対象とし、これらを総称して「文書」と呼ぶ。
【００３４】
以下、特にことわりがない場合、「文書」と呼ぶときは、コンテンツ文書、スキーマ文書、クエリ文書を全て指すものとする。
【００３５】
まず、実施形態の説明を前に、ＸＭＬについて簡単に説明する。
【００３６】
図３は、ＸＭＬで記述された構造化文書の一例として、「特許」情報の例を示したものである。ＸＭＬやＳＧＭＬは、文書の構造の表現にタグが用いられる。タグには、開始タグと終了タグがあり、文書構造情報の構成要素を開始タグと終了タグで囲むことにより、文書中の文字列（テキスト）区切りと、そのテキストが構造上どの構成要素に属するのかを明確に記述することができる。
【００３７】
ここで開始タグとは要素名称を記号「＜」、「＞」で閉じたものであり、終了タグとは要素名称を記号「＜／」と「＞」で閉じたものである。タグに続く構成要素の内容が、テキスト（文字列）または子供の構成要素の繰り返しである。また開始タグには「＜要素名称 属性＝“属性値”＞」などのように属性情報を設定することができる。「＜特許ＤＢ＞＜／特許ＤＢ＞」のようにテキストを含まない構成要素は、簡易記法として「＜特許ＤＢ／＞」のように表わすこともできる。
【００３８】
図３に示した文書は、「特許」タグから始まる要素をルート(根)とし、その子要素として「タイトル」、「出願日」、「出願者」、「要約」タグから始まる要素集合が存在する。また、例えば、「タイトル」タグから始まる要素には「ＸＭＬデータベース」といった、１つのテキスト（文字列）が存在する。
【００３９】
ＸＭＬなどの構造化文書は、任意の構成要素を繰り返し含んでいたり、さらには文書構造があらかじめ決まっていない（ＲＤＢ（リレーショナルデータベース）やＯＯＤＢ（オブジェクト指向データベース）のスキーマでは定義できない）のが普通である。
【００４０】
図３に示したような構造化文書を論理的に表現するために、図４に示すようなツリー表現が用いられる。ツリーは、ノード（番号が付され、円形で示されたもの）とアーク（ノードを表す円形間をつなぐデータ付き線）と四角形で囲まれたテキストから構成されている。
【００４１】
ノードは文書オブジェクトに対応し、ノードからタグ名や属性名に相当するラベルが付与された複数のアークが出てきている。そのアークの先は、ノードまたは要素値としての文字列（テキスト）である。ノードの中に記載されている英数字（＃０、＃４９）などはオブジェクトＩＤである。
【００４２】
図４に示したツリー構造を図３に示した構造化文書の文書オブジェクトツリーと呼ぶ。
【００４３】
図１は、本実施形態に係る構造化文書管理システムの構成例を示したものである。図１において、構造化文書管理システムは、大きく分けて、要求制御部１、アクセス要求処理部２、検索要求処理部３、データアクセス部４、文書記憶部５、インデックス記憶部６から構成されている。文書記憶部５、インデックス記憶部６は例えば、外部記憶装置を用いて構成される。
【００４４】
図１のシステム構成は、ソフトウエアを用いて実現可能である。
【００４５】
要求制御部１は、要求受付部１１と結果処理部１２から構成されている。要求受付部１１は、ユーザからの文書格納や文書取得、文書検索などの要求を受け付けて、アクセス要求処理部２を呼び出す。結果処理部１２は、アクセス要求処理部２が処理した結果を要求元のユーザに返す処理を行う。
【００４６】
アクセス要求処理部２は、ユーザからの文書格納や文書取得などの要求に対応した複数の処理部から構成されている。つまり、文書格納部２１、文書取得部２２、文書削除部２３から構成されている。
【００４７】
文書格納部２１は、文書記憶部５中の論理的な指定エリアに文書を格納する処理を行う。
【００４８】
文書取得部２２は、文書記憶部５中の論理的なエリアが指定されたときに、その指定エリアに存在する文書を取得する処理を行う。
【００４９】
文書削除部２３は、文書記憶部５中の論理的な指定エリアに存在する文書を削除する処理を行う。
【００５０】
文書記憶部５は、構造化文書データベースであり、例えば、図８に示すように、文書をＵＮＩＸのディレクトリ構造のように階層的にツリー構造状に格納している。
【００５１】
図８に示すように、構造化文書データベースは、図４に示したような１つの構造化文書のツリー構造と同様に表現できる。すなわち、任意のノード以下の部分階層木（部分ツリー）は、構造化文書データベースから切り出された構造化文書であり、ここでは、これを文書オブジェクトツリーと呼ぶ。各ノードにはオブジェクトＩＤが割り当てられている。オブジェクトＩＤは、構造化文書データベース内ではユニークな数値を持つものとする。
【００５２】
階層木のルートとなるノードには、それがルートノードであることを特定するためのオブジェクトＩＤ「＃０」が割り当てられるものとする。
【００５３】
ルートノード、すなわち、「＃０」のノードからは「ｒｏｏｔ」タグを先頭に持つ「＃１」のノードへリンクが張られている。「＃１」のノードからは、「特許ＤＢ」タグを先頭にもつ「＃２」ノードへのリンクが張られている。「＃２」ノードからは、「特許」タグを先頭に持つ「＃４２」ノード、「＃５２」ノード、「＃６２」ノードへのリンクがそれぞれ張られている。
【００５４】
図３に示した「特許」情報は、「＃４２」ノード以下の部分ツリーに対応している。このノードからは「タイトル」タグ、「出願者」タグ、「要約」タグなどを先頭にもつノードへリンクが張られ、末端のノードからは、「ＸＭＬデータベース」、「Ｔ社」。「ＸＭＬを統一的に管理するデータベースを提供する…」などの文字列（要素値）へのリンクが張られている。
【００５５】
「＃５２」ノード以下の部分ツリー、「＃６２」ノード以下の部分ノードも１つの「特許」情報に対応する部分である。
【００５６】
ところで、例えば、「＃４３」ノードにリンクされた「ＸＭＬデータベース」という要素値は、「＃４３」ノードと「＃ｖａｌｕｅ」という特殊なタグ名で接続されている。このタグ名は、「＃」で始まるためＸＭＬ規格においては標準的なタグ名として利用することはできない。
【００５７】
このような構造化文書データベースの特定ノードを指定するために構造化文書パスを用いる。構造化文書パスは「ｕｉｘ：／／ｒｏｏｔ」から始まる文字列である。ｕｉｘ（Ｕｎｉｖｅｒｓａｌ Ｉｄｅｎｔｉｆｉｅｒ ｆｏｒ ＸＭＬ）は構造化文書パスであることを示す前置文字列である。
【００５８】
例えば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」は、「＃１」ノードから「特許ＤＢ」が付与されたアークが指し示すノード、つまり「＃２」ノードに対応する。このように「ｒｏｏｔ」から「／」で区切られた部分文字列をタグ名とみなすことで「＃０」ノードからタグ名の並びに沿って対応するアークを下っていき、その最後のアークが指すノードが、パスの場所を指し示す。
【００５９】
例えば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許」は、「＃４２」ノード、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／出願日／年」は、「＃４５」ノードを指し示す。
【００６０】
「＃２」ノード以下に、すなわち、「特許ＤＢ」に、複数の「特許」情報を格納する場合には、個々の「特許」情報を識別するために、構造化文書パスにインデックス表現が可能である。
【００６１】
「特許ＤＢ」の最初の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」となるが、これは「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許」と同じとみなす。
【００６２】
「特許ＤＢ」の２番目の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［１］ＤＢ」の５番目の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［４］」となる。
【００６３】
インデックス記憶部６には検索時に用いる、要素名称生起インデックスとデータ生起インデックスが記憶されている。
【００６４】
要素名生起インデックスとは構造化文書データベースに格納されている要素名称のリストと、各要素名称が先頭にある構造化文書（文書オブジェクトツリー）の位置とを関連付けてインデックスファイル化したものである。例えば、図８の構造化文書データベースのように、（「特許」情報に対応する）「特許」という要素名称が「＃４２」ノード以下の構造化文書、「＃５２」ノード以下の構造化文書、「＃６２」ノード以下の構造化文書に存在する場合、これらをインデックス化すると、図９に示すように、それらの親ノード、「＃２」ノードが、要素名称生起インデックスファイルに「特許」キーからのチェーンで格納される。
【００６５】
このように、親ノードでインデックス化すると、インデックスファイルを圧縮することができる。すなわち、親ノードでインデックス化すれば、子ノードが増大しようとも、親ノードで代用しているので、チェーンサイズは増大しない。これに対し、実ノードをインデックス化すれば「特許」情報の格納数の増大とともにチェーンサイズはそれに比例して増加してしまう。
【００６６】
データ生起インデックスとは、構造化文書データベースに格納されている文字列データのリストと各文字列データがある構造化文書（文書オブジェクトツリー）の位置とを関連付けてインデックスファイル化したものである。例えば、図８の構造化文書データベースのように、「ＸＭＬ」という文字列データ（および、「ＸＭＬ」という文字列を含む文字列）が「＃４３」ノード以下の構造化文書、「＃４９」ノード以下の構造化文書に存在する場合、これらをインデックス化すると、図１０に示すように、「＃４３」ノード、「＃４９」ノードが、データ生起インデックスファイルに「ＸＭＬ」キーからのチェーンで格納される。
【００６７】
なお、逆階層インデックスなど、その他のインデックスファイルを用いてもよい。逆階層インデックスとは、あるノードとその親ノードとの対応を格納したものである（あるノードからその親ノードを求めることができる）。
【００６８】
文書記憶部５中の論理的な指定エリアとは、ユーザにより構造化文書パスを用いて指定された文書の格納場所を指す。構造化文書パスは、ユーザにとって認識可能な表現である。
【００６９】
図１の説明に戻る。
【００７０】
データアクセス部４は、文書記憶部５をアクセスする基本インターフェイスの集合である。データアクセス部４は、文書オブジェクトツリー格納部４７、文書オブジェクトツリー削除部４８、文書オブジェクトツリー取得部４９、文書文字列取得部４４、パスから文書オブジェクトツリー取得部４５、文書パーサ部４６、合成文書作成部４７、インデックス更新部４８から構成される。
【００７１】
文書オブジェクトツリー格納部４１は、文書記憶部５中の物理的な指定エリアに文書オブジェクトツリーを格納する処理を行う。
【００７２】
文書オブジェクトツリー削除部４２は、文書記憶部５中の物理的な指定エリアに存在する文書オブジェクトツリーを削除する処理を行う。
【００７３】
文書オブジェクトツリー取得部４３は、文書記憶部５中の物理的な指定エリアに存在する文書オブジェクトツリーを取得する処理を行う。
【００７４】
文書文字列取得部４４は、文書オブジェクトツリーを構造化文書（ＸＭＬ文書）に変換する処理を行う。
【００７５】
パスから文書オブジェクトツリー取得部４５は、構造化文書パスを解析して文書記憶部５中の物理的なエリアを特定して、そのエリアに存在する文書オブジェクトツリーを取り出す処理を行う。
【００７６】
文書パーサ部４６は、ユーザにより入力された構造化文書を読み込んで構文解析して整合性の検査を行い、さらに文書構造定義データであるスキーマが存在すれば構造的に妥当かどうかの検証を行う。出力結果は文書オブジェクトツリーとなる。文書パーサは、通常、ｌｅｘ（ｌｅｘｉｃａｌ ａｎａｌｙｚｅｒ ｇｅｎｅｒａｔｏｒ）といったレキシカルアナライザ（字句解析を行い，トークンに分解する）とｙａｃｃ（ｙｅｔ ａｎｏｔｈｅｒ ｃｏｍｐｉｌｅｒ ｃｏｍｐｉｌｅｒ）といったパーサジェネレータを組み合わせて構築することができる。
【００７７】
合成文書作成部４７は、文書格納や文書削除などをする際に、スキーマに合致しているかどうか検査しなければならないが、この検査時に必要となるデータを作成して出力する。
【００７８】
インデックス更新部４８は、文書格納や文書削除などにより、構造化文書データベースの格納内容が更新されるたびに、図９、図１０に示した要素名称生起インデックスとデータ生起インデックスを更新する。
【００７９】
文書記憶部５中の物理的な指定エリアとは、ファイルオフセットやオブジェクトＩＤなどの構造化文書データベース内ではユニークな文書データの存在場所を指し示す内部データである。ユーザにとっては認識不能なデータである。
【００８０】
文書記憶部５中に格納された文書を検索する処理を行う。要求制御部１の要求受付部１１でユーザからの文書検索の要求が受け付けられると、検索要求処理部３には、要求受付部１１からクエリ言語で記述されたクエリ文書が入力する。そしてデータアクセス部４を通してインデックス記憶部６，文書記憶部５にアクセスし、検索要求に合致する文書集合を取得して、その結果を結果処理部１２を介して出力する。
【００８１】
図２は、図１に示した構造化文書管理システムの一利用形態を示したもので、図２では、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）のバックエンドで、図１に示した構成の構造化文書管理システム１００が動作している場合を示している。
【００８２】
複数（ここでは、例えば３つ）のクライアント端末（例えばパーソナルコンピュータ、携帯通信端末など）１０２のそれぞれでＷＷＷブラウザ１０３が動作している。ユーザは、各クライアント端末からＷＷＷサーバ１０１にアクセスすることにより、構造化文書管理システム１００にアクセスすることができる。ＷＷＷブラウザ１０３とＷＷＷサーバ１０１とは、ＨＴＴＰ（Ｈｙｐｅｒ ＴｅｘｔＴｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）で通信している。また、ＷＷＷサーバ１０１と構造化文書管理システム１００とは、ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）またはＣＯＭ（Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）などで通信している。
【００８３】
ユーザからの文書格納、文書取得、文書検索などの要求は、ＷＷＷブラウザ１０３から送信されて、ＷＷＷサーバ１０１を通して構造化文書管理システム１００にて受け付けられ、処理された結果は、ＷＷＷサーバ１０１を通して要求元のＷＷＷブラウザ１０３へ返信される。
【００８４】
以下、図１の構造化文書管理システムの（１）格納機能、（２）検索機能について詳細に説明する。そして、（３）適用例では、概念検索を用いた特許調査の場合を例にとり説明する。
【００８５】
（１） 格納機能
図１の構造化文書管理システムにおける格納系のコマンドには以下のものがある。
【００８６】
ｉｎｓｅｒｔＸＭＬ（パス、Ｎ番目、ＸＭＬ）：文書格納
ａｐｐｅｎｄＸＭＬ（パス、ＸＭＬ） ：文書格納
ｇｅｔＸＭＬ（パス） ：文書取得
ｒｅｍｏｖｅＸＭＬ（パス） ：文書削除
ｓｅｔＳｃｈｅｍａ（パス、スキーマ） ：スキーマ格納
ｇｅｔＳｃｈｅｍａ（パス） ：スキーマ取得
「ｉｎｓｅｒｔＸＭＬ」は、（ ）内に指定した構造化文書パス以下のＮ番目に文書を挿入するコマンド（以下、簡単に挿入コマンドと呼ぶ）である。
【００８７】
「ａｐｐｅｎｄＸＭＬ」は、（ ）内に指定した構造化文書パス以下の最後に文書を挿入するコマンド（以下、簡単に追加コマンドと呼ぶ）である。
【００８８】
「ｇｅｔＸＭＬ」は、（ ）内に指定した構造化文書パス以下の文書を取り出すコマンド（以下、簡単に取得コマンドと呼ぶ）である。
【００８９】
「ｒｅｍｏｖｅＸＭＬ」は、（ ）内に指定した構造化文書パス以下の文書（スキーマ文書以外の文書で、主に、コンテンツ文書）を削除するコマンド（以下、簡単に削除コマンドと呼ぶ）である。
【００９０】
「ｓｅｔＳｃｈｅｍａ」は、（ ）内に指定した構造化文書パスにスキーマを設定するコマンド（以下、簡単にスキーマ格納コマンドと呼ぶ）である。
【００９１】
「ｇｅｔＳｃｈｅｍａ」は、（ ）内に指定した構造化文書パスに設定されているスキーマを取り出すコマンド（以下、簡単にスキーマ取得コマンドと呼ぶ）である。
【００９２】
上記コマンドのうち、挿入コマンド、追加コマンド、スキーマ格納コマンドについての処理はアクセス要求処理部２の文書格納部２１で実行され、取得コマンド、スキーマ取得コマンドについての処理は文書取得部２２で実行され、削除コマンドについての処理は文書削除部２３で実行される。
【００９３】
図５を参照して、構造化文書データベースの初期状態（図５（ａ）参照）において、追加コマンドを実行する場合について説明する。
【００９４】
図５（ａ）に示すように、「＃０」ノードと「＃１」ノードが「ｒｏｏｔ」アークで接続されている初期状態に対して、
「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」
を実行した結果、図５（ｂ）に示すように、「＃２」ノードと「特許ＤＢ」アークが作成される。
【００９５】
図５（ｂ）に示した状態の構造化文書データベースに対して、取得コマンドを実行する場合について説明する。
【００９６】
例えば、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”）」を実行すると、図５（ｂ）の「ｒｏｏｔ」アークが示す「＃０」ノード以下の文書オブジェクトツリーが取り出され、それをＸＭＬの文字列表現に変換する。その結果、図６に示すように、「＜ｒｏｏｔ＞＜特許ＤＢ／＞＜／ｒｏｏｔ＞」なる文字列が取り出される。取得コマンドの処理は、アクセス要求処理部２の文書取得部２２にて実行される。
【００９７】
次に、図５（ｂ）に示した状態の構造化文書データベースに対して、図３に示すようなコンテンツ文書（ＸＭＬ文書）としての「特許」情報を格納するための追加コマンドを実行する場合について説明する。すなわち、この場合、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」を実行する。このコマンド中「“＜特許＞…＜／特許＞”」が、図３に示した「特許」情報に対応する。
【００９８】
上記追加コマンドの処理が実行されると、図７に示すように、「＃２」ノード以下に「＃４２」ノードをトップとする文書オブジェクトツリー（図４に対応）が追加される。
【００９９】
図５（ｂ）に示した状態の構造化文書データベースに対して、次に示すような追加コマンドを３回繰り返して実行したとする。
【０１００】
「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」
上記コマンド中、「＜特許＞…＜／特許＞」は、図３に示した文書構造のコンテンツ文書に対応する。
【０１０１】
すると、図８に示すように、「＃２」ノード以下に「＃４２」ノード、「＃５２」ノード、「＃６２」ノードをトップとする文書オブジェクトツリーが追加される。
【０１０２】
次に、図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合について説明する。この場合、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」を実行する。すると、「特許ＤＢ」アークが示す「＃２」ノード以下の文書オブジェクトツリーが取り出され、それをＸＭＬの文字列表現（ＸＭＬ文書）に変換する。その結果、図１１に示すように、「＜特許ＤＢ＞＜特許＞…＜／特許＞＜特許＞…＜／特許＞＜特許＞…＜／特許＞＜／特許ＤＢ＞」なる文字列が取り出される。
【０１０３】
構造化文書データベースでは、上記の「特許」情報などのコンテンツ文書（ＸＭＬ文書）の文書構造を定義したデータ、すなわち、スキーマも管理対象とする。
【０１０４】
図１２は、ＸＭＬ文書の文書構造を定義するスキーマの一例を示したものである。ここでは、ＸＭＬの文書構造定義言語の一つであるＸＤＲ（ＸＭＬ−Ｄａｔａ Ｒｅｄｕｃｅｄ）を取り上げる。もちろん、ＸＭＬ−Ｓｃｈｅｍａなど他の文書構造定義言語を用いてもかまわない。
【０１０５】
図１２に示したスキーマは、図３に示した「特許」情報の文書構造をＸＤＲで定義したものである。図１２からも容易に分かるとおり、スキーマもＸＭＬ形式の構造化文書である。「Ｓｃｈｅｍａ」タグから始まる構成要素から始まり、その子要素として、「ＥｌｅｍｅｎｔＴｙｐｅ」タグから始まる要素集合が存在する。
【０１０６】
図１２に示したスキーマにおいて、例えば、最初の「ＥｌｅｍｅｎｔＴｙｐｅ」タグから始まる子要素は以下の情報を意味している。
【０１０７】
・「特許」タグを持つ要素の文書構造定義（「ＥｌｅｍｅｎｔＴｙｐｅ ｎａｍｅ＝”特許”」）である。
【０１０８】
・子要素は要素だけ（「ｃｏｎｔｅｎｔ＝”ｅｌｔＯｎｌｙ”」）である。
【０１０９】
・「タイトル」、「出願日」、「要約」タグから始まる子要素から構成される（「ｅｌｅｍｅｎｔ ｔｙｐｅ＝”タイトル”、…」）。さらに、その順番は一意に決まっている（「ｏｒｄｅｒ＝”ｓｅｑ”」）。
【０１１０】
・上記「特許」タグから始まる要素の文書構造定義の他に、「タイトル」「出願者」「要約」「年」「月」「日」「出願日」の文書構造定義を記述している。すなわち、「出願日」を除く、「タイトル」「出願者」「要約」「年」「月」「日」タグから始まる構成要素の子要素はテキストだけと定義されている（「ｃｏｎｔｅｎｔ＝”ｔｅｘｔＯｎｌｙ”」）。
【０１１１】
・「出願日」タグから始まる構成要素の子要素は、「年」、「月」、「日」の並びである。
【０１１２】
図８に示した状態の構造化文書データベースに対して、図１２に示したスキーマ文書を格納するためのスキーマ格納コマンドを実行する場合について説明する。この場合、「ｓｅｔＳｃｈｅｍａ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”）」を実行する。このコマンド中、「“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”」」が図１２に示したスキーマ文書に対応する。
【０１１３】
上記コマンドの実行により、図１３に示すように、「＃２」ノード以下に「＃ｓｃｈｅｍａ」アークが追加され、その先には、「＃３」ノードをトップノードとする文書オブジェクトツリーが追加される。スキーマ自身がＸＭＬ文書表現になっているため、前述した「特許」情報のようなコンテンツ文書格納のケースと同様にツリー展開可能である。
【０１１４】
図１３において、「＠ｎａｍｅ」など「＠」で始まるアークは属性に対応する。タグ名「＃ｓｃｈｅｍａ」も「＃」、「＠」で始まるためＸＭＬ規格においては標準的なタグ名として利用することはできない。
【０１１５】
「＃２」ノード下に図１２に示したスキーマ文書が格納されたことにより、以後、「＃２」ノード以下にこれから格納される文書の文書構造は、図１２に示したスキーマ文書により定義された文書構造に適合することが要求される。すなわち、「＃２」ノード以下に図１２に示したスキーマが設定されることになる。
【０１１６】
「＃２」ノード以下に図１２に示したスキーマが設定されると、図１４に示すように、「＃２」ノードの文書オブジェクトのファイルには、「＃２」ノード以下の文書オブジェクトツリーには、当該スキーマが存在する旨の属性値がセットされる。
【０１１７】
「＃２」ノード以下に図１２に示したスキーマが設定された後に、このスキーマで定義された文書構造に一致する図３に示したような「特許」情報を、図１４に示したように、文書オブジェクトツリーとして構造化文書データベースに格納したとき、この文書の文書構造には図１２に示したスキーマが存在する旨の属性値が、当該文書オブジェクトツリーを構成する各文書オブジェクトにセットされる。例えば、当該文書オブジェクトツリーを構成する各文書オブジェクトのファイルに対して、スキーマが存在している旨の属性値（例えば、「スキーマ適合有無」）に「１」がセットされる。図１４では、スキーマに適合している各文書オブジェクト（ノード）は２重丸で示している。２重丸で示した各文書オブジェクトには、その文書オブジェクトに対応した文書構造定義が存在することになる。
【０１１８】
図１５は、各文書オブジェクトのファイルの内容を概念的に示したもので、例えば、オブジェクトＩＤが「＃４２」の文書オブジェクトのファイルには、その文書オブジェクトにリンクされている他の文書オブジェクトに関する情報（例えば、アークや、リンク先の文書オブジェクトへのポインタ値など）とともに、上記属性値が記述されている。なお、当該文書オブジェクトに適用するスキーマが存在しないときは、「スキーマ適合有無」の値は「０」となる。
【０１１９】
図１６、図１７は、図１の構造化文書管理システムで、必要に応じて検索で使用される概念階層を構造化文書で表現した例を示す。図１６、図１７に示す「概念」情報はＸＭＬで記述したコンテンツ文書である。
【０１２０】
図１６に示した「概念」情報の例は、いわゆる特許調査における特許文書の内容を分類するための１つの分類軸として用いる「情報モデル」を概念階層で表現している。「概念」タグで囲まれた「概念」情報は、入れ子構造を持った文書構造をもっている。つまり、図１６の例では、概念「情報モデル」の子供概念として、概念「ドキュメント」、概念「リレーション」、概念「オブジェクト」が存在している。また、概念「ドキュメント」の子供概念として、概念「構造化訴求メント」、概念「非構造化ドキュメント」が存在し、さらに、概念「構造化ドキュメント」の子供概念として、概念「ＸＭＬ」、概念「ＳＧＭＬ」が存在している。
【０１２１】
図１７に示す「概念」情報の記述例は、図１６とは異なる分類軸「情報操作」を概念階層で表現している。図１７の例では、概念「情報操作」の子供概念として、概念「検索」、概念「格納」、概念「加工」、概念「流通」が存在している。
【０１２２】
図１６，図１７に示したような「概念」情報も、前述の「特許」情報と同様にして、構造化文書データベース内に格納することができる。すなわち、例えば、まず、図８に示した状態の構造化文書データベースに対して、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜概念ＤＢ／＞”）」を実行して、図１８に示すように、「＃２０１」ノードと「概念ＤＢ」アークが作成される。この状態において、図１６に示した「概念」情報を格納する場合には、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／概念ＤＢ”，“＜概念名前＞…＜／概念＞”）」を実行する。このコマンド中「“＜概念名前＞…＜／概念＞”」が、図１６に示した「概念」情報に対応する。
【０１２３】
上記追加コマンドの処理が実行されると、図１９に示すように、「＃２０１」ノード以下に「＃２０２」ノードをトップとする文書オブジェクトツリーが追加される。
【０１２４】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。そのため、部分的なＸＭＬ文書をアクセスするには巨大なＸＭＬ文書に対するパスという文書構造に依存しない統一的なアクセス手段を用いることにより、幅広くＸＭＬ文書を検索したり加工したりすることが可能になる。
【０１２５】
また、構造化文書データベース上の一部にスキーマを設定することで、格納しようとする文書の文書構造がそのスキーマにより定義されている文書構造に一致するか否かの妥当性のチェックが自動的に行なえる（後述）。
【０１２６】
（１−１）文書格納処理
次に、図１の構造化文書管理システムの文書格納処理動作について、図２０に示すフローチャートを参照して説明する。
【０１２７】
クライアント端末から構造化文書管理システムに対し、文書格納要求として、挿入コマンド、追加コマンド、スキーマ格納コマンドのうちのいずれかが送信されて、要求受付部１１にて受け付けられたとき、図２０に示した処理動作を行う。
【０１２８】
クライアント端末の所定の表示装置には、構造化文書管理システム１００（の例えば、要求制御部１）から提供された、例えば、図３１に示すようなユーザインターフェイスとしての画面が表示されている。
【０１２９】
図３１に示す画面には、構造化文書管理システム１００への操作項目の一覧（メニュー）が表示されている。操作項目として、「ＸＭＬ登録／削除」、「スキーマ設定」、「ＸＭＬ検索」とがある。
【０１３０】
ユーザが例えば、この画面上で「ＸＭＬ登録／削除」をマウス等のポインティングデバイスなどを用いて選択すると、図３２に示したような文書の格納／削除を行うためのユーザインタフェースとしての画面が表示される。
【０１３１】
図３２において、領域Ｗ１には、文書構造化文書データベースの現在のツリー構造の要素名（タグ名）がユーザが理解可能なように簡略的に表示されている。なお、図３２では、上位階層の要素名のみを表示しているが、末端の要素名まで表示可能である。また、領域Ｗ２は、構造化文書パスの入力領域であり、領域Ｗ１の表示内容に従って、構造化文書パスを入力するようになっている。また、領域Ｗ３は、格納する文書を入力したり、取得した文書を表示するようになっている。
【０１３２】
例えば、構造化文書パスとして「ｒｏｏｔ」を入力する場合には、領域Ｗ１の「ｒｏｏｔ」をマウス等で選択すればよい。すると、図３２に示すように、領域Ｗ２の構造化文書パスの入力領域に「ｕｉｘ：／／ｒｏｏｔ」と表示される。また、新たに、「特許ＤＢ」という要素を追加する場合は、図３２に示すように、領域Ｗ３に、「特許ＤＢ」を入力する。そして、「登録」ボタンＢ１を選択すると、クライアント端末からａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」なる追加コマンドが構造化文書管理システムへ送信される。構造化文書管理システムでは、上記追加コマンドを受け、後述するような処理を実行した結果、例えば、図５（ｂ）に示すように、「＃２」ノードと「特許ＤＢ」アークが作成される。また、領域Ｗ１には、図３３に示すように、「ｒｏｏｔ」の下に「特許ＤＢ」が追加表示される。
【０１３３】
さて、ユーザが図３４に示したような文書の格納／削除画面上の領域Ｗ３に、例えば、文書「＜Ａ＞データ＜／Ａ＞」を入力し（あるいはＣＤ−ＲＯＭ等の所定の記録媒体等から読み込むことにより入力し）、領域Ｗ１の「特許［０］」をマウス等で選択すると、構造化文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」と表示される。そして、「登録」ボタンＢ１を選択すると、クライアント端末からａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０１３４】
ここでは、例えば、構造化文書データベースが、図１４に示した状態のときに、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］”，“＜Ａ＞データ＜／Ａ＞”）」なる追加コマンドを受け付けた場合を例にとり説明する。
【０１３５】
要求受付部１１は、上記追加コマンドを受け付けると、上記追加コマンド中の２つのパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」と文書「＜Ａ＞データ＜／Ａ＞」（以下、格納文書と呼ぶ）とを文書格納部２１へ渡す（ステップＳ１）。
【０１３６】
まず、文書格納部２１は、文書パーサ部４６に格納文書を渡す。文書パーサ部４６は、格納文書を読み込んで、構文解析を行い、当該格納文書の文書構造がＸＭＬにて規定された正しい形式であるか否かの整合性の検査を行う（ステップＳ２）。
【０１３７】
この整合性の検査でエラーが見つかれば（ステップＳ３）、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す（ステップＳ４）。
【０１３８】
整合性の検査でエラーが見つからなければ、次に、文書格納部２１は、パスから文書オブジェクトツリー取得部４５へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部４５は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ０）を含む文書オブジェクトツリーを取り出す（ステップＳ５）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ０のオブジェクトＩＤを取得することができるので（ステップＳ６）、その場合は、ステップＳ８へ進む。
【０１３９】
例えば、上記追加コマンドの場合、「＃４２」ノードが文書オブジェクトＯｘ０となるので、そのオブジェクトＩＤとして、「＃４２」を取得するとともに、この「＃４２」ノードを含む文書オブジェクトツリー（例えば、「＃４２」ノードの全ての子孫ノードと「＃４２」ノードと同じ階層にある全ての（兄弟）ノードと、「＃４２」ノードの親ノードである「＃２」ノードとからなる文書オブジェクトツリー）を取得する。
【０１４０】
指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ０が見つからなければ、エラーとなり（ステップＳ６）、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す（ステップＳ７）。
【０１４１】
例えば、構造化文書データベースが、図１８に示した状態のときに、追加コマンドのパラメータとして、構造化文書パスが「ｕｉｘ：／／ｒｏｏｔ／その他」と表されていたとき、これに対応する文書オブジェクトは存在しないので、ステップＳ６でエラーとなり、ステップＳ７へ進む。
【０１４２】
次に、ステップＳ８では、文書オブジェクトＯｘ０にスキーマが存在するか否かを検査する。この検査は、前述したように、各文書オブジェクトのファイルに属性値が記述されているので、この値をチェックすればよい。文書オブジェクトＯｘ０のもつ「スキーマ属性有無」の値が「１」のときは、ステップＳ９へ進む。
【０１４３】
以下、図２０のステップＳ９の処理（合成文書作成部４７の処理）について、図２１に示すフローチャートを参照して詳細に説明する。
【０１４４】
文書格納部２１は、ステップＳ５で取得した文書オブジェクトツリーを合成文書作成部４７へ渡す。
【０１４５】
合成文書作成部４７は、この文書オブジェクトツリーを文書オブジェクトＯｘ０から遡り、「Ｓｃｈｅｍａ」タグを子要素として持つ文書オブジェクトＯｘ１を検索する（ステップＳ２１）。
【０１４６】
例えば、図１４に示した構造化文書データベースでは、文書オブジェクトＯｘ０としての「＃４２」ノードの親ノードである「＃２」ノードから「Ｓｃｈｅｍａ」タグをトップ（先頭）にもつノード（「＃３」ノード）へのリンクが張られているので（「Ｓｃｈｅｍａ」タグを子要素として持つので）、この「＃２」ノードが文書オブジェクトＯｘ１となる。よって、ステップＳ２２をスキップして、ステップＳ２３へ進む。
【０１４７】
この文書オブジェクトＯｘ１から文書オブジェクトＯｘ０、さらに文書オブジェクトＯｘ０からアークを辿って、その下流にある、文書オブジェクトの属性値の値が「１」である全ての子ノードからなる文書オブジェクトツリーＯｔ１を取り出す（ステップＳ２３）。
【０１４８】
例えば、上記追加コマンド中のパラメータの構造化文書パスが「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」と指定されているとき、文書オブジェクトツリーＯｔ１は、「＃４２」ノード〜「＃４９」ノードから構成されたものとなる（図１４参照）。
【０１４９】
次に、ステップＳ２５へ進む。
【０１５０】
ステップＳ２５では、文書オブジェクトツリーＯｔ１に格納文書の文書オブジェクトツリーを文書オブジェクトＯｘ０の子ノードとして挿入する。その結果得られた新たな文書オブジェクトツリーを文書オブジェクトツリーＯｔ２とする。
【０１５１】
この文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換し、それをテンポラリファイルＡに出力する（ステップＳ２７）。
【０１５２】
例えば、上記追加コマンド中のパラメータの格納文書「＜Ａ＞データ＜／Ａ＞」の文書オブジェクトツリー（この場合は、１つの文書オブジェクト）を「＃４２」ノード〜「＃４９」ノードで構成された文書オブジェクトツリーＯｔ１に「＃４２」ノードの子ノードとして挿入して得られた合成文書の文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換した結果を図２２に示す。この合成文書は、もともとある「特許」情報に「＜Ａ＞データ＜／Ａ＞」というデータを追加したものとなっている。
【０１５３】
図２２に示したＸＭＬ文書、すなわち、合成文書がテンポラリファイルＡに出力され、テンポラリファイルＡに一時格納される。
【０１５４】
一方、スキーマタグ以下の文書オブジェクトツリーＯｔ３をＸＭＬ文書に変換して、それをテンポラリファイルＢに出力する（ステップＳ２８）。すなわち、テンポラリファイルＢには、スキーマ文書が一時格納されることになる。
【０１５５】
例えば、文書オブジェクトツリーＯｔ３である「＃３」ノードをトップノードとする文書オブジェクトツリーをＸＭＬ文書に変換した結果を図２３に示す。図２３に示したＸＭＬ文書がテンポラリファイルＢに出力され、テンポラリファイルＢに一時格納される。
【０１５６】
図２２に示すように、テンポラリファイルＡ（「ｔｍｐ０００．ｘｍｌ」）には、もともとある「特許」情報の要素の他に、格納文書、すなわち、ここでは、例えば、「＜Ａ＞データ＜／Ａ＞」が挿入されている。また、「ｘｍｌｎｓ＝”ｘ−ｓｃｈｅｍａ：ｔｍｐ００１．ｘｍｌ”」という、テンポラリファイルＢ（「ｔｍｐ００１．ｘｍｌ」）へのリンク情報の記述がある。この記述は、「特許」情報に適用されるスキーマが出力されているテンポラリファイルＢを指定している。
【０１５７】
次に、図２０の説明に戻る。
【０１５８】
ステップＳ１０では、文書格納部２１は文書パーサ部４６に、合成文書のテンポラリファイルＡとスキーマのテンポラリファイルＢとを与えて、合成文書の文書構造の妥当性をチェックする。すなわち、文書パーサ部４６は、合成文書のテンポラリファイルＡとスキーマのテンポラリファイルＢとを読み込み、合成文書の文書構造が、スキーマにより定義されている文書構造に一致するか否かをチェックする。
【０１５９】
例えば、図２２に示した合成文書と、図２３に示したスキーマとで妥当性のチェックを行った場合、合成文書には、スキーマにより定義されていない「Ａ」という要素が存在するため、図２３の合成文書は、妥当性のチェックでエラーとなる（ステップＳ１１）。この場合、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す（ステップＳ１２）。
【０１６０】
例えば、クライアント端末の所定の表示装置には、図３５に示すようなメッセージが表示される。
【０１６１】
次に、構造化文書データベースが、図１４に示した状態のときに、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドを受け付けた場合について、図２０を参照して説明する。前述同様にして、文書オブジェクトＯｘ０のオブジェクトＩＤ「＃２」を取得する（ステップＳ５）、この文書オブジェクトには、スキーマが存在するので（ステップＳ８）、ステップＳ９において合成文書を作成する。
【０１６２】
この場合、文書オブジェクトＯｘ０である「＃２」ノード自体から「Ｓｃｈｅｍａ」タグをトップ（先頭）にもつノード（「＃３」ノード）へのリンクが張られているので、この「＃２」ノードが文書オブジェクトＯｘ１となる（図２１のステップＳ２１）。すなわち、文書オブジェクトＯｘ０と文書オブジェクトＯｘ１が同じなので（ステップＳ２２）、ステップＳ２９へ進み、格納文書「＜特許＞…＜／特許＞」の文書オブジェクトツリーをＸＭＬ文書に変換し、テンポラリファイルＡに出力する（ステップＳ２９）。
【０１６３】
例えば、図２４に示すように、テンポラリファイルＡ（「ｔｍｐ０００．ｘｍｌ」）には、格納文書である「特許」情報、すなわち、ここでは、「＜特許＞…＜／特許＞」が出力されている。また、「ｘｍｌｎｓ＝”ｘ−ｓｃｈｅｍａ：ｔｍｐ００１．ｘｍｌ”」という、テンポラリファイルＢ（「ｔｍｐ００１．ｘｍｌ」）へのリンク情報の記述がある。
【０１６４】
次に、ステップＳ２８へ進む。図２５に示すように、テンポラリファイルＢには、「＃３」ノードをトップノードとするスキーマの文書オブジェクトツリーをＸＭＬ文書に変換した結果が出力されている。
【０１６５】
図２０のステップＳ１０で、図２４に示した合成文書と、図２５に示したスキーマとで妥当性のチェックを行ったとき、合成文書の文書構造と、スキーマにより定義されている文書構造とは一致する、この場合、ステップＳ１１からステップＳ１３へ進む。
【０１６６】
ステップＳ１３では、格納文書の文書オブジェクトツリーが、文書オブジェクトＯｘ０下に追加される。すなわち、文書格納部２１により、格納文書の文書オブジェクトツリーを構成する各文書オブジェクト（のファイル）にオブジェクトＩＤが与えられ、文書オブジェクトＯｘ０から格納文書の文書オブジェクトツリーの先頭の文書オブジェクトへリンクが張られる。そして、文書オブジェクトツリー格納部４１により、格納文書の文書オブジェクトツリーを構成する各文書オブジェクト（のファイル）が文書記憶部５に格納される。
【０１６７】
次に、ステップＳ１４へ進み、インデックス記憶部６のインデックスを更新する。
【０１６８】
なお、ステップＳ８で、文書オブジェクトＯｘ０のもつ属性値の値が「０」のときは、上述したスキーマを用いた合成文書の文書構造の妥当性のチェックを行わずに、そのままマステップＳ１３へ進み、格納文書の文書オブジェクトツリーを、文書オブジェクトＯｘ０下に追加し（ステップＳ１３）、それに伴い、インデックス記憶部６のインデックスを更新する（ステップＳ１４）。
【０１６９】
（１−２）文書取得処理
次に、図１の構造化文書管理システムの文書取得処理動作について、図２６に示すフローチャートを参照して説明する。
【０１７０】
クライアント端末から構造化文書管理システムに対し、文書取得要求として、取得コマンド、スキーマ取得コマンドのうちのいずれかが送信されて、要求受付部１１にて受け付けられたとき、図２６に示した処理動作を行う。
【０１７１】
例えば、ユーザが図３６に示したような文書の格納／削除画面上の領域Ｗ１の「特許ＤＢ」をマウス等で選択すると（クリックすると）、構造化文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」と表示されとともに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」なる取得コマンドが構造化文書管理システムへ送信される。
【０１７２】
ここでは、例えば、構造化文書データベースが、図８に示した状態のときに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」なる取得コマンドを受け付けた場合を例にとり説明する。
【０１７３】
要求受付部１１は、上記取得コマンドを受け付けると、上記取得コマンド中のパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」を文書取得部２２へ渡す（ステップＳ３１）。
【０１７４】
文書取得部２２は、パスから文書オブジェクトツリー取得部４５へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部４５は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ５）を取り出す（ステップＳ３２）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ５のオブジェクトＩＤを取得することができるので（ステップＳ３３）、その場合は、ステップＳ３５へ進む。
【０１７５】
例えば、上記取得コマンドの場合、「＃２」ノードが文書オブジェクトＯｘ５となるので、そのオブジェクトＩＤとして、「＃２」を取得するとともに、この「＃２」ノード以下の文書オブジェクトツリーＯｔ５（「＃２」ノード、「＃４２」ノード〜「＃４９」ノード、「＃５２」ノード以下、「＃６２」ノード以下）を取得する（ステップＳ３５）。
【０１７６】
ステップＳ３２において、指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ５が見つからなければ、エラーとなり（ステップＳ３３）、文書取得部２２，結果処理部１２を介して、クライアント端末に「文書取得失敗」の旨のメッセージを返す（ステップＳ３４）。
【０１７７】
ステップＳ３５で取得した文書オブジェクトツリーＯｔ５は、文書文字列取得部４４でＸＭＬ文書に変換される。例えば、上記取得コマンドの場合、取得したＸＭＬ文書は、図１１に示すような３つの「特許」情報のＸＭＬ文書となる。
【０１７８】
文書取得部２２は、結果処理部１２を介して、図１１に示したようなＸＭＬ文書を（例えば、ＸＳＬ（ｅＸｔｅｎｓｉｂｌｅ Ｓｔｙｌｅ Ｌａｎｇｕａｇｅ）といった所定のスタイルシートとともに）、クライアント端末へ返す（ステップＳ３７）。
【０１７９】
クライアント端末では、図１１に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図３６に示すように、領域Ｗ２に表示する。
【０１８０】
ＸＳＬを利用すると、ＸＭＬ文書を様々な形に変換することが出来る。違う構文書造のＸＭＬ文書に変換することも出来るし、ＸＭＬ文書からＨＴＭＬページを生成することも出来る。
【０１８１】
（１−３）文書削除処理
次に、図１の構造化文書管理システムの文書削除処理動作について、図２７に示すフローチャートを参照して説明する。
【０１８２】
クライアント端末から構造化文書管理システムに対し、文書削除要求として、削除コマンドが送信されて、要求受付部１１にて受け付けられたとき、図２７に示した処理動作を行う。
【０１８３】
例えば、ユーザが図３６に示したような文書の格納／削除画面上の領域Ｗ１の「特許ＤＢ」をマウス等で選択すると（クリックすると）、構造化文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」と表示され、さらに、「削除」ボタンＢ２を選択すると「ｒｅｍｏｖｅＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」なる削除コマンドが構造化文書管理システムへ送信される。
【０１８４】
ここでは、例えば、構造化文書データベースが、図１４に示した状態のときに、「ｒｅｍｏｖｅＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日”）」なる削除コマンドを受け付けた場合を例にとり説明する。
【０１８５】
要求受付部１１は、上記削除コマンドを受け付けると、上記削除コマンド中のパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日」を文書削除部２３へ渡す（ステップＳ４１）。
【０１８６】
次に、文書削除部２３は、パスから文書オブジェクトツリー取得部４５へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部４５は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ０）を含む文書オブジェクトツリーを取り出す（ステップＳ４２）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ０のオブジェクトＩＤを取得することができるので（ステップＳ４３）、その場合は、ステップＳ４５へ進む。
【０１８７】
例えば、上記削除コマンドの場合、「＃４４」ノードが文書オブジェクトＯｘ０となるので、そのオブジェクトＩＤとして、「＃４４」を取得するとともに、この「＃４４」ノードを含む文書オブジェクトツリー（例えば、「＃４４」ノードの全ての子孫ノードと「＃４４」ノードと同じ階層にある全ての（兄弟）ノードと、「＃４４」ノードの親ノードである「＃４２」ノード、その親ノードである「＃２」ノードとからなる文書オブジェクトツリー）を取得する。
【０１８８】
指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ０が見つからなければ、エラーとなり（ステップＳ４３）、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書削除失敗」の旨のメッセージを返す（ステップＳ４４）。
【０１８９】
次に、ステップＳ４５では、文書オブジェクトＯｘ０にスキーマが存在するか否かを検査する。この検査は、前述したように、各文書オブジェクトのファイルに属性値が記述されているので、この値をチェックすればよい。文書オブジェクトＯｘ０のもつ属性値の値が「１」のときは、ステップＳ４６へ進む。
【０１９０】
以下、図２７のステップＳ４６の処理（合成文書作成部４７の処理（削除コマンド用））について、図２８に示すフローチャートを参照して詳細に説明する。
【０１９１】
なお、図２８において、図２１と同一部分は同一符号を付している。
【０１９２】
文書格納部２１は、ステップＳ４２で取得した文書オブジェクトツリーを合成文書作成部４７へ渡す。
【０１９３】
合成文書作成部４７は、この文書オブジェクトツリーを文書オブジェクトＯｘ０から遡り、「Ｓｃｈｅｍａ」タグを子要素として持つ文書オブジェクトＯｘ１を検索する（ステップＳ２１）。
【０１９４】
例えば、図１４に示した構造化文書データベースでは、文書オブジェクトＯｘ０としての「＃４４」ノードの上流にある「＃２」ノードから「Ｓｃｈｅｍａ」タグをトップ（先頭）にもつノード（「＃３」ノード）へのリンクが張られているので（「Ｓｃｈｅｍａ」タグを子要素として持つので）、この「＃２」ノードが文書オブジェクトＯｘ１となる。
【０１９５】
この文書オブジェクトＯｘ１から文書オブジェクトＯｘ０、さらに文書オブジェクトＯｘ０からアークを辿って、その下流にある、文書オブジェクトの属性値の値が「１」である全ての子ノードからなる文書オブジェクトツリーＯｔ１を取り出す（ステップＳ２３）。
【０１９６】
例えば、上記追加コマンド中のパラメータの構造化文書パスが「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日」と指定されているとき、文書オブジェクトツリーＯｔ１は、「＃４２」ノード〜「＃４９」ノードから構成されたものとなる（図１４参照）。
【０１９７】
次に、ステップＳ２６ヘ進み、文書オブジェクトツリーＯｔ１から文書オブジェクトＯｘ０以下の文書オブジェクトツリーを削除する。その結果得られた新たな文書オブジェクトツリーを文書オブジェクトツリーＯｔ２とする。
【０１９８】
この文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換し、それをテンポラリファイルＡに出力する（ステップＳ２７）。
【０１９９】
例えば、上記削除コマンド中のパラメータの構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日」が指し示す「＃４４」ノード以下の文書オブジェクトツリーを「＃４２」ノード〜「＃４９」ノードで構成された文書オブジェクトツリーＯｔ１から削除することにより得られた合成文書の文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換した結果を図２９に示す。この合成文書は、もともとある「特許」情報から「＜出願日＞…＜／出願日＞」というデータを削除したものとなっている。
【０２００】
図２９に示したＸＭＬ文書、すなわち、合成文書がテンポラリファイルＡに出力され、テンポラリファイルＡに一時格納される。
【０２０１】
一方、スキーマタグ以下の文書オブジェクトツリーＯｔ３をＸＭＬ文書に変換して、それをテンポラリファイルＢに出力する（ステップＳ２８）。すなわち、テンポラリファイルＢには、スキーマ文書が一時格納されることになる。
【０２０２】
例えば、文書オブジェクトツリーＯｔ３である「＃３」ノードをトップノードとする文書オブジェクトツリーをＸＭＬ文書に変換した結果を図３０に示す。図３０に示したＸＭＬ文書がテンポラリファイルＢに出力され、テンポラリファイルＢに一時格納される。
【０２０３】
次に、図２７の説明に戻る。
【０２０４】
ステップＳ４７では、文書削除部２１は文書パーサ部４６に、合成文書のテンポラリファイルＡとスキーマのテンポラリファイルＢとを与えて、文書格納処理の場合と同様にして、合成文書の文書構造の妥当性をチェックする。
【０２０５】
例えば、図２９に示した合成文書と、図３０に示したスキーマとで妥当性のチェックを行った場合、合成文書には、スキーマにより定義されている「出願日」という要素が存在しないため、図２９の合成文書は、妥当性のチェックでエラーとなる（ステップＳ４８）。この場合、文書削除部２１，結果処理部１２を介して、クライアント端末に「文書削除失敗」の旨のメッセージを返す（ステップＳ４９）。
【０２０６】
なお、構造化文書データベースが、図１４に示した状態のときに、「ｒｅｍｏｖｅＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］”）」なる削除コマンドを、図２７に従って処理を行うと、図２８のステップＳ２７において、図２４に示したような合成文書がテンポラリファイルＡに出力される。テンポラリファイルＢは、図３０と同様である。
【０２０７】
このとき、図２４に示した合成文書と、図３０に示したスキーマとで妥当性のチェックを行った場合、合成文書の文書構造と、スキーマにより定義されている文書構造とは一致するので、ステップＳ４８からステップＳ５０へ進む。
【０２０８】
ステップＳ５０では、文書オブジェクトＯｘ０以下の文書オブジェクトツリーを削除する。すなわち、文書オブジェクトツリー削除部４２により、文書オブジェクトＯｘ０以下の文書オブジェクトツリーを構成する各文書オブジェクト（のファイル）が文書記憶部５から削除される。例えば、「＃２」ノードから「＃４２」ノード以下の文書オブジェクトのファイルが削除される。
【０２０９】
次に、ステップＳ５１へ進み、インデックス記憶部６のインデックスを更新する。また、クライアント端末の図３６に示したような表示画面の領域Ｗ１には、「特許［０］」が表示さなくなる。
【０２１０】
なお、ステップＳ４５で、文書オブジェクトＯｘ０のもつ属性値の値が「０」のときは、上述したスキーマを用いた合成文書の文書構造の妥当性のチェックを行わずに、そのままマステップＳ５０へ進み、文書オブジェクトＯｘ０以下の文書オブジェクトツリーを削除し（ステップＳ５０）、それに伴う、インデックス記憶部６のインデックスを更新する（ステップＳ５１）。
【０２１１】
（１−４）スキーマの設定、スキーマを用いた文書格納
図３１に示した画面上で、ユーザが「Ｓｃｈｅｍａ設定Ｗｉｎ」をマウス等のポインティングデバイスなどを用いて選択すると、図３７に示したようなスキーマの設定を行うためのユーザインタフェースとしての画面が表示される。
【０２１２】
ユーザが、領域Ｗ３に、例えば、図１２に示したような「特許」情報のスキーマを入力し、この入力したスキーマを「特許ＤＢ」以下のノードに設定する場合には、領域Ｗ１から「特許ＤＢ」をマウス等でクリックして選択した後（領域Ｗ２には、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される）、「スキーマ設定」ボタンＢ３を選択する。すると、「ｓｅｔＳｃｈｅｍａ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”）」なるスキーマ格納コマンドが構造化文書管理システムへ送信される。このコマンドの処理は前述した文書格納処理動作と同様である。
【０２１３】
次に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」の下に「特許」情報を格納しようとするとき、「特許ＤＢ」以下のノードに既に設定されているスキーマを用いて「特許」情報を入力する場合について説明する。
【０２１４】
まず、スキーマを取得する。例えば、図３８に示すような文書の格納／削除を行うための画面の領域Ｗ１から「スキーマ」をマウス等を用いて選択すると、文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／＃Ｓｃｈｅｍａ」と表示されとともに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／Ｓｃｈｅｍａ”）」なるスキーマ取得コマンドが構造化文書管理システムへ送信される。
【０２１５】
このコマンドの処理は、前述した文書取得処理と同様である。構造化文書管理システムから返されるＸＭＬ文書は、図３８の画面の領域Ｗ３に表示される。
【０２１６】
図３８に示すように、領域Ｒ３には、「特許」情報のデータ入力領域が各要素毎に設定されて表示されている。この表示に従って、ユーザは、データを入力すればよい。例えば、「タイトル」、「年」などのデータ入力領域が階層的に配置され、表示されている。ユーザは、このデータ入力領域にデータを入力することで、スキーマにより定義された文書構造の格納文書が容易に作成することができる。
【０２１７】
また、領域Ｗ３に入力した「特許」情報の格納先として、領域Ｗ１で「特許ＤＢ」をマウス等を用いて選択すると、領域Ｗ２に構造化文書パスとして、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される。その後、「登録」ボタンＢ１を選択すると、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０２１８】
この場合、格納文書は、予めスキーマに従って入力されたものなので、図２０のステップＳ１０の妥当性チェックでエラーとなることはない。
【０２１９】
（２）検索機能
図１の構造化文書管理システムにおける検索系のコマンドには以下のものがある。
【０２２０】
ｑｕｅｒｙ（ｑｌ）
「ｑｕｅｒｙ」は、パラメータとして（ ）内のクエリｑｌを実行し、その結果のＸＭＬ文書を取得するコマンド（以下、検索コマンドと呼ぶ）である。
【０２２１】
クエリは、図３９に示すように、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ ＱｕｅｒｙＬａｎｇｕａｇｅ）に似た形式の言語により、検索位置、検索条件、情報抽出部分などを記述した、構造化されたＸＭＬ文書である。クエリ文書も構造化文書管理システムの管理対象である。
【０２２２】
「ｋｆ：ｆｒｏｍ」タグから始まる要素には、検索位置の指定と文書要素の値に変数を対応付ける記述があり、「ｋｆ：ｗｈｅｒｅ」タグのから始める要素には、変数に関する条件づけの記述があり、「ｋｆ：ｓｅｌｅｃｔ」タグから始まる要素には、検索結果の出力形式が記述される。
【０２２３】
検索には、単純検索と概念検索とがある。単純検索とは、クエリ中に指定された検索条件を満たす情報を検索・抽出するものであり、概念検索とは、クエリ中に指定された概念情報を利用して、クエリ中に指定された検索条件を満たす情報を検索・抽出するものである。
【０２２４】
図４０は、単純検索のクエリの例を示したものである。図４０のクエリは、例えば、図１４に示したような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群において、「１９９９年でかつ、「ＰＣ」のような内容の「要約」という要素をもつ文書（「特許」情報）の「タイトル」を列挙せよ」という検索要求を意味している。
【０２２５】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」、「＄ｙ」、「＄ｓ」に、それぞれ「特許」情報の「タイトル」、「年」、「要約」という文書要素の値が代入される。
【０２２６】
「ｋｆ：ｗｈｅｒｅ」タグから始める要素の記述により、変数「＄ｙ」＝「１９９９」という比較がなされる。また、コンポーネント「ＭｙＬｉｋｅ」は変数「＄ｓ」と「ＰＣ」を引数として、「ＰＣ」と類似する値の変数「＄ｓ」を検知するための関数である。
【０２２７】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」が出力値として利用される。
【０２２８】
なお、「ｋｆ：ｓｔａｒ」タグは構造の曖昧表現であり、例えば「＜特許＞＜ｋｆ：ｓｔａｒ＞＜年＞」は「タグ名が「特許」である要素の子孫の要素としていずれかに存在し、タグ名が「年」である要素」を意味する。
【０２２９】
図４１に図４０の単純検索のクエリを用いた検索結果を示す。この検索結果もＸＭＬ文書である。
【０２３０】
図４２は、概念検索のクエリの例を示したものである。図４２のクエリは、例えば図１８，図１９に示すような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群に対し、「概念ＤＢ」アークが示すノード以下に格納されている「概念」情報を利用して検索するための検索要求である。ここで、概念「周辺装置」の値をもつタグの子要素の値には、概念「ＳＣＳＩ」、「メモリ」、「ＨＤＤ」などがあるものとする。また、図１８には示していないが、各「特許」情報の構成要素には、「キーワード」タグから始める要素も存在するものとする。
【０２３１】
すなわち、図４２のクエリは、「概念「周辺装置」以下の概念のいずれかを「キーワード」という要素の値にもつ文書（「特許」情報）の「タイトル」を列挙せよ」という検索要求を意味している。
【０２３２】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」、変数「＄ｋ」に、それぞれ、「特許」情報の「タイトル」、「キーワード」という要素の値が代入される。また、変数「＄ｘ」は「概念」情報として「周辺装置」の値をもつタグの子要素の値（「ＳＣＳＩ」、「メモリ」、「ＨＤＤ」など）が代入される。
【０２３３】
「ｋｆ：ｗｈｅｒｅ」タグから始める要素の記述により、「＄ｋ」＝「周辺装置」もしくは「＄ｋ」＝「＄ｘ」という比較がなされる。
【０２３４】
次に、図１の構造化文書管理システムの文書検索処理動作について、図４３に示すフローチャートを参照して説明する。
【０２３５】
図３１に示した画面上で、ユーザが「ＸＭＬ検索Ｗｉｎ」をマウス等のポインティングデバイスなどを用いて選択すると、図４４に示すような文書検索を行うためのユーザインタフェースとしての画面が表示される。
【０２３６】
図４４の検索画面において、領域Ｗ１には、前述同様、構造化文書データベースの現在のツリー構造の要素名（タグ名）がユーザが理解可能なように簡略的に表示されてている。
【０２３７】
領域Ｗ２は、検索対象の範囲（ツリー構造上の検索範囲）や、検索条件などを入力するための領域である。領域Ｗ３には、検索結果が表示される。
【０２３８】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「文書」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という検索要求の場合には、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、トップノードとして、「特許」を入力する（この場合、領域Ｗ１から「特許」をマウス等で選択することにより入力してもよい）。また、検索条件として、「「タイトル」という要素の値に「文書」という文字列を含む」「「年」という要素の値が「１９９８」以上である」という内容を予め設定されたデータ入力領域に入力すればよい。
【０２３９】
その後、「検索」ボタンＢ２１を選択することにより、例えば、図４５に示すようなクエリが、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。クエリの格納場所は、予め定められており、システム側が自動的に、この追加コマンドのパラメータを設定することとなる。例えば、構造化文書データベースが図１８に示した状態のとき、当該クエリの格納場所を表すパラメータとしての構造化文書パスは、「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」となる。また、追加コマンドのもう一方のパラメータは、当該クエリ文書である。
【０２４０】
要求受付部１１は、上記クエリを受け付けると（ステップＳ１０１）、当該クエリを検索要求処理部３へ渡す。そして、当該クエリ文書を格納するための追加コマンドのパラメータを文書格納部２１へ渡す。この追加コマンドの処理を、前述同様に行って、当該クエリは、文書記憶部５に格納される。
【０２４１】
例えば、図４２に示すようなクエリの場合、構造化文書データベースには、図４６に示すように展開されて、構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」の示す「＃３０１」ノード以下にリンクされる。
【０２４２】
一方、検索要求処理部３では、受け取ったクエリを基に、データアクセス部４を通してインデックス記憶部６，文書記憶部５にアクセスし、検索要求に合致する文書集合などを取得して、クエリの中で要求された情報を抽出して結果処理部１２を介して出力する。
【０２４３】
例えば、上記クエリの場合、まず、「「タイトル」タグに「文書」という文字列を含む」という条件に合致するものを検索することが検索対象を絞り込む上で効率がよい。そこで、図１０に示したようなデータ生起インデックスを用いて、「文書」という文字列にリンクされているノード（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを上流側に１つ遡り、「タイトル」というタグ名にたどり着いたときは、更に上流に辿っていき、「特許」というタグ名にたどり着いたときは、そのノード以下の文書オブジェクトツリーＯｔ１１を抽出する。
【０２４４】
次に、この抽出された複数の文書オブジェクトツリーＯｔ１１の中から、さらに、「年」という要素の値が「１９９８」年以上の文書オブジェクトツリーＯｔ１２を抽出する。
【０２４５】
この文書オブジェクトツリーＯｔ１２が上記クエリの内容に適合する文書となる。さらに上記クエリの要求内容に従えば、各文書オブジェクトツリーＯｔ１２のトップノードへの構造化文書パスを求める（ステップＳ１０２）。
【０２４６】
なお、上記検索処理は、上記した方法に限るものではなく、インデックス情報を用いた様々な効率のよい検索方法が可能である。
【０２４７】
検索要求処理部３は、ステップＳ１０２で得られた結果を統合して、検索結果としてのＸＭＬ文書を作成する（ステップＳ１０３）。
【０２４８】
例えば、検索結果のＸＭＬ文書は、
【０２４９】
検索要求処理部３は、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す（ステップＳ１０４）。
【０２５０】
クライアント端末では、図１１に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図４４に示すように、領域Ｗ１２に表示する。
【０２５１】
同様にして、スキーマの検索も行える。
【０２５２】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「ｓｃｈｅｍａ」を先頭タグに持つ文書の中から、「特許」と「要約」というタグ名を持つスキーマを検索せよ」という検索要求の場合には、図４７に示すように、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、トップノードとして、「＃ｓｃｈｅｍａ」を入力する。また、検索条件として、「要素の属性名に「特許」という文字列を含む」「要素の属性名に「要約」という文字列を含む」という内容を予め設定されたデータ入力領域に入力すればよい。
【０２５３】
その後、「検索」ボタンＢ２１を選択することにより、上記検索要求を記述したクエリ（図４８参照）が、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。
【０２５４】
さて、上記クエリの場合、例えば、「「＃ｓｃｈｅｍａ」を先頭タグに持つ」という条件に合致するものを検索する。そこで、図９に示したような要素名称生起インデックスを用いて、「＃ｓｃｈｅｍａ」という要素にリンクされているノードの（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、属性名が「特許」と「要約」いう要素にたどり着いたときは、当該「＃ｓｃｈｅｍａ」を先頭タグにもつ文書オブジェクトツリーＯｔ２１を抽出する。この文書オブジェクトツリーＯｔ２１が上記クエリの内容に適合する文書となる。さらに、図４８に示したクエリの要求内容に従えば、各文書オブジェクトツリーＯｔ２１のトップノードへの構造化文書パスを求める。
【０２５５】
検索要求処理部３は、文書オブジェクトツリーＯｔ２１が複数あれば、それぞれのトップノードへの構造化文書パスをまとめて、検索結果としてのＸＭＬ文書を作成し、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す。
【０２５６】
クライアント端末では、検索結果として受け取ったＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図４４に示すように、領域Ｗ１２に表示する。
【０２５７】
クライアント端末では、検索結果の中の１つのスキーマを選択して、表示させると、例えば、図３８に示すような文書の格納／削除を行うための画面とともに、その領域Ｗ３に、「特許」情報のデータ入力領域が各要素毎に設定されて表示される。
【０２５８】
ユーザは、このデータ入力領域にデータを入力することで、スキーマにより定義された文書構造の格納文書が容易に作成することができる。
【０２５９】
例えば、図３８の領域Ｗ３に入力した「特許」情報の格納先として、領域Ｗ１で「特許ＤＢ」をマウス等を用いて選択すると、領域Ｗ２に構造化文書パスとして、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される。その後、「登録」ボタンＢ１を選択すると、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０２６０】
この場合、格納文書は、予めスキーマに従って入力されたものなので、図２０のステップＳ１０の妥当性チェックでエラーとなることはない。
【０２６１】
同様にして、クエリの検索も行える。クエリを検索して、検索結果として得られた既存のクエリを加工して、再利用することもできる（クエリの再利用）。
【０２６２】
クエリの検索は、前述したような構造化文書の検索と同様にして行われ、その検索範囲は、クエリ群の格納されている構造化データベース上の一部の文書オブジェクトツリーとなる。
【０２６３】
例えば、図１８に示したような状態の構造化文書データベースから、「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリを検索する場合について説明する。そのような検索要求を記述したクエリを図４９に示す。
【０２６４】
図４９に示すクエリは、「「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」の示す「＃３０１」ノード以下に存在するクエリの中から「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリを検索し、その内容（タグ名が「ｑｕｅｒｙ」である要素以下の文書オブジェクトツリーの文書）を列挙せよ」を意味するものである。
【０２６５】
なお、「ｋｆ：ａｓ」タグの内容で変数「＄ｅｌｔ」に、「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリのタグ名が「ｑｕｅｒｙ」である要素以下の文書オブジェクトツリーが代入される。
【０２６６】
このクエリを検索要求処理部３が処理する際には、前述同様にして、例えば、図９に示したような要素名称生起インデックスを用いて、「ｋｆ：ｆｒｏｍ」という要素にリンクされているノードの（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、「特許」というタグ名にたどり着いたときは、さらに、上流側にアークを辿って「ｑｕｅｒｙ」というタグ名に辿りついたとき、当該「ｑｕｅｒｙ」を先頭タグにもつ文書オブジェクトツリーＯｔ３１を抽出する。この文書オブジェクトツリーＯｔ３１が上記クエリの内容に適合する文書となる。
【０２６７】
複数の文書オブジェクトツリーＯｔ３１が検索されたら、それらを統合して、ＸＭＬ文書を作成して、それをスタイルシートとともにクライアント端末へ返す。
【０２６８】
クライアント端末では、検索結果の中の１つのクエリを選択して、表示させると、例えば、図４４に示した検索画面の領域Ｗ１１に、各データ入力領域にデータの入力された状態で、当該クエリに記述された検索要求の内容が表示される。
【０２６９】
ユーザは、この状態から、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「文書」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という当該クエリに記述された検索要求中の「文書」を「ＸＭＬ」に変更して、「検索」ボタンＢ２１を選択すれば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「ＸＭＬ」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という意味のクエリが構造化文書管理システムへ送信される。
【０２７０】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。従って、文書構造が異なる、様々なスキーマを持つ膨大な数の文書の中から検索条件に合致する文書を容易に検索できる。
【０２７１】
また、検索に用いるクエリも構造化文書であるので、構造化文書データベースにログとして格納することにより、過去のクエリを再利用するようなアプリケーションも容易に構築することができる。
【０２７２】
（３）適用例
次に、上記概念検索の特許調査への適用例について説明する。
【０２７３】
図５０は、特許調査における構造化文書データベースの一例であり、「特許」情報の他に、「概念」情報も格納している。
【０２７４】
特許調査において、最も重要となってくる作業は、関連する「特許」情報を収集し、「特許」情報を様々な観点から分析し、特許マップ（図５４参照）を作成することである。特許マップを作成するために、従来、特許マップにおける縦軸、横軸を予め決定し、それに従い、縦軸に並ぶ任意の項目と横軸に並ぶ任意の項目とを検索条件とした検索を逐次行うという方法がとられ、この部分に非常に莫大なコストがかかっていた。しかし、構造化文書管理システムを用いることで、この部分のコストを大幅に減少させることが可能となる。
【０２７５】
なお、ここで、マップとは、縦軸（ｙ軸）に並ぶ任意の項目と横軸（ｘ軸）に並ぶ任意の項目とを検索条件とした検索結果をｘ軸とｙ軸とを分類軸として分類整理するものである。
【０２７６】
構造化文書管理システムで、クライアント端末のユーザが図５４に示すような特許マップを作成しようとする場合、ユーザは、クライアント端末上の表示装置に表示される図５０に示すような構造化文書データベースの現在のツリー構造を参照して、図５１に示すような検索画面上に、分析対象の範囲とする「特許」情報のパスと、分析の軸（例えば、ｘ軸、ｙ軸）となる要素を、それぞれ領域Ｗ２１、Ｗ２２に入力する。分析の軸となる要素は、構造化文書データベース内の「特許」情報の要素、「概念」情報の要素のいずれであってもよい。
【０２７７】
例えば、図５１では、ｘ軸に「機能」、ｙ軸に「技術」という「概念」情報の要素を入力している。
【０２７８】
その後、ユーザは、「実行」ボタンＢ３１を選択すると、クライアント端末から図１の構造化文書管理システムへ、図５２に示したようなクエリが送出される。
【０２７９】
この場合のクエリには、「「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群の中から、「概念ＤＢ」アークが示すノード以下に格納されている、概念「機能」の子要素のいずれかと概念「技術」の子要素のいずれかとを、「キーワード」や「要約」などの要素の値に含む「特許」情報を検索せよ。検索結果として、「機能」の子要素と「技術」の子要素と、それらに対応する「特許」情報の「公開番号」との組を列挙せよ。」という意味の検索要求である。
【０２８０】
概念「機能」には、「検索」「格納」…「分析支援」という子要素があり、概念「技術」には、「実装データベース」「反構造データベース」「自然言語処理」…という子要素があるものとする。
【０２８１】
上記クエリを受けた構造化文書検索システムの検索要求処理部３では、例えば、図１０に示したようなデータ生起インデックスを用いて、概念「機能」の各子要素（文字列）にリンクされているノード（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを上流側に遡り、「特許」というタグにたどり着いたときは、さらに、そのノード以下の文書オブジェクトツリーを下流側に辿って概念「技術」の子要素（文字列）のいずれかにリンクされているタグ名にたどり着いたときは、当該文書オブジェクトツリーと、その「公開番号」タグにリンクされている文字列（要素値）を抽出する。このようにして、抽出された「特許」情報のそれぞれについて、対応の「機能」の子要素と「技術」の子要素と「公開番号」との組を統合して、図５３に示すような検索結果としてのＸＭＬ文書を作成、要求元のクライアント端末へ、所定のスタイルシートとともに返す。
【０２８２】
これらを受け取ったクライアント端末の表示装置には、図５４に示したような表形式の特許マップが表示されることになる。
【０２８３】
このように、所望の概念を「軸」として指定するだけで、構造化文書データベースに蓄積された情報を「軸」として指定された概念に基づき集計・分類して、マップ表示するこたが容易に行える。すなわち、構造化文書データベースに蓄積された情報を、「概念」情報を用いて様々な観点で集計・分類することが容易に行える。
【０２８４】
（本発明の実施形態の説明）
以下、本発明の実施の形態について図面を参照して説明する。
【０２８５】
クエリに基づき、上記構造化文書データベースに対し検索を行う場合、検索条件などが同一のクエリがクライアント端末から送られてくることもある。このような場合、同じクエリを受け取る度に同じ検索を何度も行うことは効率的でない。そこで、頻繁に実行されるクエリについては、そのクエリを実行した結果、すなわち、検索結果を当該クエリに対応付けて一時格納する。再度同じクエリを受け付けた時には、検索を実行せずに、この一時格納した検索結果を返すようにすることで、検索のための処理時間の短縮が図れる。
【０２８６】
図５５は、上記したような機能を有する構造化文書管理システムの構成例を示したものである。なお、図５５において、図１と同一部分には同一符号を付し、異なる部分についてのみ説明する。すなわち、図５５では、検索結果を一時記憶する検索結果記憶部２０１と、実行権限情報テーブル２０２とが新たに追加されている。
【０２８７】
検索結果記憶部２０１には、文書記憶部５、すなわち、構造化文書データベースに格納されているクエリを実行した結果、得られた検索結果が当該クエリに対応付けて記憶されている。
【０２８８】
実行権限情報テーブル２０２は、後述するように、クエリ実行権限のあるユーザと、クエリの実行権限はないが、そのクエリの検索結果は参照可能なユーザの識別情報を登録したテーブルである。
【０２８９】
このような構成の構造化文書管理システムの文書記憶部５に格納されている構造化文書データベースは、現在、図５６に示すような状態である場合を考える。。
【０２９０】
なお、図５６に示した構造化文書データベースの構造化文書の格納状態は、ノードやアークを簡略化し、ノードをオブジェクトＩＤではなく要素名や属性名で表して文書オブジェクトツリーの構造、しいていは、構造化文書データベースの構造を示している。
【０２９１】
図５６において、「ｒｏｏｔ」ノード以下には、「特許ＤＢ」ノードと「クエリＤＢ」ノードがある。「特許ＤＢ」ノード以下には、図５７に示すような文書構造の複数の「特許」情報が格納されている。「クエリＤＢ」ノード以下には、複数のクエリ文書（ＸＭＬ文書）が格納されている。
【０２９２】
図５７に示すように、「特許」情報は、「特許」タグから始まる要素をルート(根)とし、その子要素として「タイトル」、「出願日」、「出願者」、「要約」、「キーワード群」タグから始まる要素集合が存在する。また、「出願日」タグから始まる要素には、「年」「月」「日」タグか始める子要素を有し、「キーワード群」タグから始める要素には、１または複数の「キーワード」タグから始める子要素が存在する。
【０２９３】
図５６に示すように、構造化文書データベースには、予め複数のクエリ（ここでは、インデックス（［０］、［１］、…）を用いて表記されたクエリ［０］、クエリ［１］、…をそれぞれクエリＡ、クエリＢ、…と呼ぶ）が格納されている。
【０２９４】
第２の実施形態では、第１の実施形態で説明したような、クライアント端末から検索条件などを入力することにより作成されたクエリを構造化文書管理システムにて受け付けて検索を実行する以外に、構造化文書データベースに予め格納されているクエリから所望のクエリを選択し、検索結果格納部２０１に当該クエリに対応の検索結果が格納されているときは、その検索結果を読み出して、それをクライアント端末へ返すようになっている。
【０２９５】
構造化文書データベースに予め格納しておくクエリは、例えば、頻繁に用いられる検索条件のクエリであるとか、予め検索が予想されるクエリ、複数のユーザからユーザグループ内である特定の用途のために用いるクエリなど種々考えられる。
【０２９６】
例えば、図５６に示した構造化文書データベースに格納されているクエリのうちの１つであるクエリＡ（クエリ［０］ノード以下の部分文書に対応する）は、図５８に示すような内容のクエリであったとする。
【０２９７】
図５８に示すクエリは、単純検索のクエリの例を示したもので、図５６に示したような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群において、「１９９９年以降でかつ、「ＸＭＬ」をキーワードにもつ（「キーワード」という要素の値が「ＸＭＬ」である「特許」情報の「タイトル」を列挙せよ）という検索要求を意味している。
【０２９８】
図５８に示したクエリＡを検索要求処理部３で実行することにより、例えば、図５９に示したような検索結果Ａが得られたとする。
【０２９９】
検索結果記憶部２０１には、上記クエリＡと上記検索結果Ａとが対応付けて、例えば、図６０に示すようにテーブル形式で記憶される。
【０３００】
クエリＡを含む、構造化文書データベースに格納されている各クエリは、その論理的な格納領域を表す構造化文書パスにより、識別される。すなわち、各クエリの識別情報は、その構造化文書パスであり、例えば、クエリＡの識別情報は、「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ／クエリ［０］」となる。なお、説明の簡単のため、図６０以降の記述、および、以下の説明において、クエリ識別情報に関しては、「ｕｉｘ：／／ｒｏｏｔ」を省略して、「／クエリＤＢ／クエリ［０］」と簡略化する。
【０３０１】
検索要求処理部３に図６０に示しような検索結果記憶部２０１を持たせることにより、図５５の構造化文書管理システムは、図６１に示すような動作が可能となる。
【０３０２】
この場合、クライアント端末の所定の表示装置には、構造化文書管理システム１００（の例えば、要求制御部１）から提供された、例えば、図７０に示すようなユーザインターフェイスとしての画面が表示されている。
【０３０３】
図７０に示す画面の領域Ｗ１０１には、文書構造化文書データベースの現在のツリー構造のうちの一部であって、クエリ格納領域のツリー構造について、ユーザが理解可能なように簡略的に表示されている。なお、図７０では、上位階層の要素名のみを表示しているが、末端の要素名まで表示可能である。また、領域Ｗ１０２は、クエリの構造化文書パスの入力領域であり、領域Ｗ１０１の表示内容に従って、構造化文書パスを入力するようになっている。領域１０２にユーザが所望のクエリの構造化文書パスを入力した後、「検索実行」ボタンＷ１０３をクリックすると、クライアント端末からは、構造化文書パスにてクエリを指定した検索要求が構造化文書管理システムへ送信される。
【０３０４】
この検索要求は、例えば、予め定められた形式のコマンドとして（以下、簡単に検索要求コマンドと呼ぶ）、要求受付部１１で受け付けられる（ステップＳ２０１）。要求受付部１１は、当該検索要求コマンドを検索要求処理部３へ渡す。検索要求処理部３は、検索要求コマンドに含まれるクエリ識別情報としての構造化文書パスを取出し、検索結果記憶部２０１から、当該構造化文書パスのクエリ対応の検索結果が格納されているか否かチェックする。
【０３０５】
当該クエリ対応の検索結果が格納されているときは（ステップＳ２０２）、その検索結果を読み出し（ステップＳ２０３）、結果処理部１２を介して、ＸＭＬ文書としての当該検索結果を所定のスタイルシートとともに、要求元のクライアント端末に返す（ステップＳ２０４）。
【０３０６】
検索要求処理部３が実際に検索を実行するのは、上記ステップＳ２０２において、検索結果記憶部２０１に指定されたクエリ対応の検索結果が格納されていない場合である。この場合は、まず、構造化文書パスにて指定されたクエリをデータアクセス部４で構造化文書データベースから取得する（前述した、パスから文書オブジェクトツリー取得部４５における取得コマンドの実行時と同様）。そして、この取得したクエリを用いて、図４３のステップＳ１０２〜ステップＳ１０３に示したようにして、検索処理を行う（ステップＳ２０５）。そして、検索結果を要求元のクライアント端末に返す前に、クエリ識別情報に対応付けて検索結果記憶部２０１に格納する（ステップＳ２０６）。
【０３０７】
さて、構造化文書データベースは、随時、新たな構造化文書が追加登録されたり、削除されたりして更新されるわけだが、構造化文書データベース自体が更新されれば、同じクエリによる検索であってもデータベースの更新前と更新後の検索結果は異なることもある。
【０３０８】
上記したように、実際には検索を実行せずに、検索結果記憶部２０１に格納されている検索結果を読み出すといった動作を行う場合、データベース自体の更新に伴い、その更新を検索結果にも反映することが好ましい。
【０３０９】
そこで本発明では、そのための一手段として、ある特定のユーザが一定時間毎にクエリを実行し、その度に、得られた検索結果で検索結果記憶部２０１の内容を更新するようにする。このように、一定時間毎に検索結果記憶部２０１に記憶されている検索結果を更新しておくことで、構造化文書データベースの更新内容が検索結果に反映することができるとともに、検索結果とデータベースの状態との整合性を保つことができる。
【０３１０】
検索を実行可能な上記特定のユーザを予め定めて、一定時間毎に検索結果の更新をおこなうことにより、データベースと検索結果との内容の整合性を保つために、本発明では、具体的には、クライアント端末のユーザには上記構造化文書パスにて識別される各クエリについて、当該クエリを実行させることが可能なユーザと、当該クエリにより検索結果を参照することが可能なユーザと限定するために、クエリ実行権限と検索結果参照権限なるものを予め定めるようになっている。
【０３１１】
クエリ実行権限のあるユーザ（クエリ実行権限ユーザ）は、例えば、当該クエリを作成した者とする。また、例えば、このクエリ実行権限ユーザにより当該クエリによる検索結果の参照が許可されたユーザが検索結果参照権限ユーザである。図６２に示すように、各クエリ毎に予め定められたクエリ実行権限ユーザと検索結果参照権限ユーザの識別情報をテーブル形式で登録したものが、実行権限情報テーブル２０２である。
【０３１２】
なお、クエリ実行権限ユーザは、検索結果参照権限ユーザでもある。
【０３１３】
図６２に示すように、実行権限情報テーブルには、クエリ識別情報としての各クエリの構造化文書パスに対応させて、クエリ実行権限ユーザと検索結果参照権限ユーザのそれぞれのユーザ識別情報が列挙されている。
【０３１４】
このように、クエリ毎に当該クエリを実行させることが可能なユーザと、当該クエリにより検索結果を参照することが可能なユーザとを限定することにより、例えば、だれもかれもが、むやみやたらに検索を実行して、同じクエリによる検索結果であるのに、（データベースの内容が更新されていることにより）検索結果が様々になってしまうことを防ぎ、少なくとも上記一定期間の間は、誰が要求をしても同じクエリによる検索結果が同じであるという好ましい状態を作り出すことができる。これは、検索結果とデータベースの内容の整合性と保つためには重要なことである。
【０３１５】
なお、実行権限情報テーブルは、例えば、クライアント端末に図６２に示したな入力画面が表示され、このような入力画面から所定の事項を入力して、システムに登録するようになっていてもよい。
【０３１６】
検索要求処理部３に図６０に示しような検索結果記憶部２０１と図６２に示したような実行権限情報テーブル２０２とを持たせることにより、図５５の構造化文書管理システムは、図６３に示すような動作が可能となる。
【０３１７】
すなわち、クライアント端末からは、例えば、図７０に示したような入力画面を介して、構造化文書パスにてクエリを指定した検索要求が構造化文書管理システムへ送信される。この検索要求は、例えば、予め定められた形式のコマンドとして（以下、簡単に検索要求コマンドと呼ぶ）、要求受付部１１で受け付けられる（ステップＳ２１１）。要求受付部１１は、当該検索要求コマンドを検索要求処理部３へ渡す。
【０３１８】
検索要求処理部３は、検索要求コマンドに含まれるクエリ識別情報としての構造化文書パスを取出し、当該クエリによる前回の検索実行時から、予め定められた一定期間が経過したか否かをチェックする。このチェックのために、検索要求処理部３は、予めタイマを持つものとする（ステップＳ２１２）。
【０３１９】
一定期間がまだ経過していないときは、ステップＳ２１３へ進み、実行権限情報テーブル２０２を参照する。
【０３２０】
検索要求コマンドに含まれる要求元のユーザの識別情報が、実行権限情報テーブル２０２に当該クエリ対応の検索結果参照権限ユーザあるいはクエリ実行権限ユーザとして登録されているときは（ステップＳ２１３）、検索結果記憶部２０１から、当該構造化文書パスのクエリ対応の検索結果を読み出し（ステップＳ２１４）、結果処理部１２を介して、ＸＭＬ文書としての当該検索結果を所定のスタイルシートとともに、要求元のクライアント端末に返す（ステップＳ２１５）。
【０３２１】
上記ステップＳ２１２において、上記一定期間が経過しているときは、ステップＳ２１６へ進み、実行権限情報テーブル２０２を参照する。
【０３２２】
検索要求コマンドに含まれる要求元のユーザの識別情報が、実行権限情報テーブル２０２に当該クエリ対応のクエリ実行権限ユーザとして登録されているときは（ステップＳ２１６）、まず、構造化文書パスにて指定されたクエリをデータアクセス部４で構造化文書データベースから取得する（前述した、パスから文書オブジェクトツリー取得部４５における取得コマンドの実行時と同様）。そして、この取得したクエリを用いて、図４３のステップＳ１０２〜ステップＳ１０３に示したようにして、検索処理を行う（ステップＳ２１７）。そして、検索結果を要求元のクライアント端末に返す（ステップＳ２１５）前に、クエリ識別情報に対応付けて検索結果記憶部２０１に格納する（ステップＳ２１８）。
【０３２３】
前述した、構造化文書データベース自体の更新に伴い、その更新を検索結果にも反映するための他の手段としては、本発明では、構造化文書データベースの更新を検知して、そにより自動的に検索結果を更新するようになっている。
【０３２４】
この構造化文書データベースの更新を検知して、検索結果の自動更新を行うための主要な機能を担うのが、図６４のイベント検出部２０３である。
【０３２５】
ここでは、構造化文書データベースの更新をイベントとして検知する。例えば、構造化文書データベースの構造上のどこがどのように更新されたか、また、いつ更新されたかにより、その更新が検索結果に影響を及ぼすクエリとそうでないクエリとが存在するので、各クエリ対応のイベントを設定し、各クエリ対応のイベントを検知するために、各イベントの条件（イベント条件）を設定する。
【０３２６】
イベント検出部２０３は、図６５に示しようなイベントテーブル２０４を予め記憶している。このイベントテーブル２０４には、構造化文書データベースの更新をイベントとして検知するための条件や、当該条件を満たすイベントが検出されたとき、（検索結果を更新すべく）検索を実行するためのクエリを示した検索結果更新パスとが、当該条件を登録したユーザ（イベントユーザ）に対応付けて登録されている。
【０３２７】
なお、イベントテーブル中の「イベントユーザ」の欄は、イベントテーブルにユーザが明示的に登録するのではなく、構造化文書管理システムにアクセスする際にユーザにより入力されるユーザ識別情報に基づきシステム側が自動的に登録することが望ましい。
【０３２８】
このイベントテーブルに登録されているイベントには大きく分けて、日時イベントとデータ操作イベントとがある。
【０３２９】
日時イベントは、構造化文書データベースに対する何らかの操作（例えば、ｉｎｓｅｒｔＸＭＬ：文書格納、ａｐｐｅｎｄＸＭＬ：文書格納、ｒｅｍｏｖｅＸＭＬ：文書削除、などのコマンドの実行に伴う構造化文書データベースの更新）には関係なく、イベント条件として指定した日時が到来したとき、イベントとして検知される。例えば、図６５では、イベント番号「３」に登録されているイベントは「２００１年２月２７日木曜日１２時００分００秒になったときイベントとして検知し、その際、検索結果更新パスで指定されたクエリ「／クエリＤＢ／クエリ［２］」で検索を実行し、検索結果記憶部２０１に格納されている当該クエリの検索結果を更新する」ためのものである。なお、このようなイベントを登録したユーザ（イベントユーザ）の識別情報が「ｋａｎａｗａ」である。
【０３３０】
データ操作イベントは、構造化文書データベースに対し、イベント条件として指定した構造化文書パス以下に、イベント条件として指定した何らかの操作（例えば、ｉｎｓｅｒｔＸＭＬ：文書格納、ａｐｐｅｎｄＸＭＬ：文書格納、ｒｅｍｏｖｅＸＭＬ：文書削除、などのコマンドの実行に伴う構造化文書データベースの更新）がなされたときに、イベントとして検知される。例えば、図６５では、イベント番号「１」に登録されているイベントは「構造化文書パス「／特許ＤＢ」以下の領域に文書格納コマンドが実行されたときイベントとして検知し、その際、検索結果更新パスで指定されたクエリ「／クエリＤＢ／クエリ［０］」で検索を実行し、検索結果記憶部２０１に格納されている当該クエリの検索結果を更新する」ためのものである。なお、このようなイベントを登録したユーザ（イベントユーザ）の識別情報が「ｎｉｉｎａ」である。
【０３３１】
例えば、図７１に示すような入力画面をクライアント端末に表示して、図６５に示したイベントテーブルに各イベントを登録するようにしてもよい。
【０３３２】
図７１に示した入力画面には、日時イベント、データ操作イベント、検索結果更新パスの設定を行うためのそれぞれの入力領域Ｗ１１１〜Ｗ１１４が設けられており、ユーザは、必要な事項を入力してから「登録」ボタンＷ１１５をクリックすればよい。すると、構造化文書管理システムへ、上記入力内容が送信されて、イベントテーブル２０４に登録される。
【０３３３】
なお、イベントテーブルに登録されている各イベント対応のイベントユーザとは、図６２に示した各クエリ毎に定められたクエリ実行権限ユーザに相当する。すなわち、クエリ実行権限ユーザが図６５に示したようなイベントテーブルにイベントを登録することにより、クエリ実行権限ユーザが、実際にクエリを実行させるのではなく、クエリ実行権限ユーザに代わってシステム自身がクエリを実行するようになっている。
【０３３４】
もちろん、上記イベントテーブルに登録された各イベント検知時に各クエリを実行する際に、そのクエリの実行権限の有り無しを考慮せずとも、本発明の目的（構造化文書データベースと検索結果との内容の整合性を保つこと）は達成される。
【０３３５】
図６６は、図６４の構造化文書管理システムの処理動作を示したもので、上記イベントテーブルに登録された各イベント検知時に各クエリを実行する際に、そのクエリの実行権限の有り無しを考慮しない場合を示したフローチャートである。
【０３３６】
イベント検出部２０３は、データアクセス部４の文書オブジェクトツリー格納部４１，文書オブジェクトツリー削除部４２などで、ｉｎｓｅｒｔＸＭＬ：文書格納、ａｐｐｅｎｄＸＭＬ：文書格納、ｒｅｍｏｖｅＸＭＬ：文書削除、などのコマンドに対応する処理の実行がされたか否か、また、イベント検出部２０３が持つタイマを参照して、イベントテーブルにイベント条件として設定された日時が到来したか否かを常時監視している（ステップＳ２２１）。図６５に示したイベントテーブルに登録されているイベント条件のいずれかを満たすイベントを検知したとき（ステップＳ２２２）、その検知したイベントに対応する検索結果更新パスをイベントテーブルから取得する（ステップＳ２２３）。
【０３３７】
まず、検索結果更新パスにて指定されたクエリをデータアクセス部４で構造化文書データベースから取得する（前述した、パスから文書オブジェクトツリー取得部４５における取得コマンドの実行時と同様）。そして、この取得したクエリを検索要求処理部３に渡し、検索要求処理部３では、当該受け取ったクエリを用いて、図４３のステップＳ１０２〜ステップＳ１０３に示したようにして、検索処理を行う（ステップＳ２２４）。
【０３３８】
検索処理部３は、検索結果を当該クエリのクエリ識別情報に対応付けて検索結果記憶部２０１に格納する（ステップＳ２２５）。
【０３３９】
次に、図６７に示すフローチャートを参照して、上記イベントテーブルに登録された各イベント検知時にその検知されたイベント対応のクエリを実行する際に、そのクエリの実行権限の有り無しを考慮する場合の図６４に示した構造化文書管理システムの処理動作について説明する。
【０３４０】
さて、イベント検出部２０３は、図６６の場合と同様、データアクセス部４の文書オブジェクトツリー格納部４１，文書オブジェクトツリー削除部４２などで、ｉｎｓｅｒｔＸＭＬ：文書格納、ａｐｐｅｎｄＸＭＬ：文書格納、ｒｅｍｏｖｅＸＭＬ：文書削除、などのコマンドに対応する処理の実行がされたか否か、また、イベント検出部２０３が持つタイマを参照して、イベントテーブルにイベント条件として設定された日時が到来したか否かを常時監視している（ステップＳ２３１）。図６５に示したイベントテーブルに登録されているイベント条件のいずれかを満たすイベントを検知したとき（ステップＳ２３２）、その検知したイベントに対応するイベントユーザの識別情報と検索結果更新パスとをイベントテーブルから取得する（ステップＳ２３３）。
【０３４１】
この取得したイベントユーザの識別情報と検索結果更新パスは、イベント検出部２０３から検索要求処理部３へ渡される。
【０３４２】
検索要求処理部３は、図６２に示したような実行権限情報テーブルから、受け取った検索結果更新パスにて指定されたクエリに対し実行権限のあるユーザ（クエリ実行権限ユーザ）の識別情報を取出し、それと、イベント検出部２０３から受け取ったイベントユーザの識別情報とを比較し（ステップＳ２３４）、それらが一致しているときには、ステップＳ２３５へ進み、当該検索結果更新パスにて指定されたクエリを実行する（ステップＳ２３５）。
【０３４３】
すなわち、まず、検索結果更新パスにて指定されたクエリをデータアクセス部４で構造化文書データベースから取得する（前述した、パスから文書オブジェクトツリー取得部４５における取得コマンドの実行時と同様）。そして、この取得したクエリを検索要求処理部３に渡し、検索要求処理部３では、当該受け取ったクエリを用いて、図４３のステップＳ１０２〜ステップＳ１０３に示したようにして、検索処理を行う（ステップＳ２３５）。
【０３４４】
検索処理部３は、検索結果を当該クエリのクエリ識別情報に対応付けて検索結果記憶部２０１に格納する（ステップＳ２３６）。
【０３４５】
なお、ステップＳ２３４で、クエリ実行権限ユーザとイベントユーザとが異なるときは、イベント検出部２０３から受け取ったクエリの実行を拒否し、処理を終了する。
【０３４６】
このように、イベント検知時に、そのイベントの実行権限のあるユーザと、当該イベントの条件を登録したイベントユーザが同じであるか否かをチェックすることにより、例えば、実行権限のないユーザにより、イベントテーブルに、正当なクエリ実行権限ユーザが定められているクエリを用いた検索実行のイベント条件が登録された場合、そのようなイベントにより当該クエリが実行されることを防ぐことができる。従って、検索結果記憶部２０１に格納されている当該クエリ対応の検索結果を不正に書き換えられることを防ぐことができるという効果がある。
【０３４７】
次に、図６８に示すフローチャートを参照して、構造化文書パスにてクエリを指定した検索要求が送信されてきたときの図６４の構造化文書管理システムの処理動作について説明する。なお、図６４に示す構成の場合、イベントが登録されている検索結果は自動的に更新されるので、図６８に示す検索要求は、検索結果の参照要求としてもよい。
【０３４８】
さて、検索要求は、例えば、図７０に示した入力画面を介して、予め定められた形式のコマンドとして（以下、簡単に検索要求コマンドと呼ぶ）、要求受付部１１で受け付けられる（ステップＳ２４１）。要求受付部１１は、当該検索要求コマンドを検索要求処理部３へ渡す。
【０３４９】
検索要求処理部３は、検索要求コマンドに含まれる、クエリ識別情報としての構造化文書パスと要求元のユーザの識別情報とを取出す。そして、要求元のユーザの識別情報が検索結果の参照権限のあるユーザか否かをチェックする（ステップＳ２４２）。当該要求元のユーザの識別情報が、実行権限情報テーブル２０２に当該クエリ対応の検索結果参照権限ユーザあるいはクエリ実行権限ユーザとして登録されているときは、検索結果記憶部２０１から、当該構造化文書パスのクエリ対応の検索結果を読み出し（ステップＳ２４３）、結果処理部１２を介して、ＸＭＬ文書としての当該検索結果を所定のスタイルシートとともに、要求元のクライアント端末に返す（ステップＳ２４４）。
【０３５０】
なお、ステップＳ２４２において、当該要求元のユーザの識別情報が、実行権限情報テーブル２０２に当該クエリ対応の検索結果参照権限ユーザとしても、また、クエリ実行権限ユーザとしても登録されていないときは、そのまま処理を終了する。
【０３５１】
図６９は、イベントテーブル２０４の他の例を示したものである。日時イベントの代わりに有効期限イベントがある点で図６５とは異なる。
【０３５２】
有効期限イベントは、イベント条件として、検索結果記憶部２０１に格納されている検索結果の有効期限として、ある一定の期間が設定され、その期間が経過する度にイベントとして検知される。例えば、図６９では、イベント番号「３」に登録されているイベントは「検索結果更新パスにて示されるクエリ「／クエリＤＢ／クエリ［２］」対応の検索結果の有効期限は１２時間であり、当該クエリを実行してから１２時間経過する度に検索を実行し、検索結果記憶部２０１に格納されている当該クエリの検索結果を更新する」ためのものである。
【０３５３】
図６９に示したイベントテーブルを用いてイベントを検知し、検索結果を更新するための処理動作は、図６７と同様である。
【０３５４】
以上説明したように、本発明によれば、例えば、頻繁に用いられる検索条件のクエリであるとか、予め検索が予想されるクエリ、複数のユーザからユーザグループ内である特定の用途のために用いるクエリなどを構造化文書データベースに予め格納しておき、そのようなクエリの検索が実行されたときは、その結果結果を当該クエリに対応付けて記憶しておくことにより、その後に、再び同じクエリによる検索要求がなされたときは、実際に検索を行わず、記憶した検索結果を要求元へ返すことにより、構造化文書データベースに対する検索が効率よく行える。
【０３５５】
ある特定のユーザ（第１の種別のユーザ）のみに、クエリの検索実行の権限を与えて、この権限のあるユーザからの検索要求に対しては、実際に検索を行って、当該クエリに対応付けて記憶した検索結果の更新を行うことにより、構造化文書データベースの更新内容が検索結果に反映することができ、構造化文書データベースの現状との整合性を保ちながら検索が効率よく行える。
【０３５６】
好ましくは、前記第１の種別のユーザから前記検索要求を受け付けたとき、前回検索を実行した時点から所定時間経過しているときは、前記指定された検索要求文に基づき検索を行い、前記所定時間が経過していないときは、前記指定された検索要求文に対応付けて記憶されている検索結果を読み出す。これにより、ある特定のユーザ（第１の種別のユーザ）のみに、クエリの検索実行の権限を与えて、定期的に当該クエリに対応付けて記憶した検索結果の更新を行うことにより、構造化文書データベースの更新内容が検索結果に反映することができ、構造化文書データベースの現状との整合性を保ちながら検索が効率よく行える。
【０３５７】
このように、クエリ毎に当該クエリを実行させることが可能なユーザと、当該クエリにより検索結果を参照することが可能なユーザとを限定することにより、例えば、だれもかれもが、むやみやたらに検索を実行して、同じクエリによる検索結果であるのに、（データベースの内容が更新されていることにより）検索結果が様々になってしまうことを防ぐことができる。
【０３５８】
また、少なくとも上記所定時間の間は、誰が要求をしても同じクエリによる検索結果が同じであるという好ましい状態を作り出すことができる。これは、検索結果とデータベースの内容の整合性と保つためには重要なことである。
【０３５９】
また、好ましくは、前記構造化文書データベースが更新されたとき、該構造化文書データベースに格納されている前記複数の検索要求文のうち、該構造化文書データベースの更新内容が検索結果に影響するような検索要求文を選択して、その選択された検索要求文に基づき前記構造化文書データベースに対し検索を行って、該検索要求文に対応付けて記憶された検索結果を更新することにより、構造化文書データベース自体の更新に伴い、その更新を検索結果に自動的に反映させることができる。従って、検索結果とデータベースの内容の整合性を保つことが容易に行える。
【０３６０】
なお、本発明の実施の形態に記載した本発明の手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピーディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、半導体メモリなどの記録媒体に格納して頒布することもできる。
【０３６１】
なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。さらに、上記実施形態には種々の段階の発明は含まれており、開示される複数の構成用件における適宜な組み合わせにより、種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題（の少なくとも１つ）が解決でき、発明の効果の欄で述べられている効果（のなくとも１つ）が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【０３６２】
【発明の効果】
以上説明したように、本発明によれば、構造化文書データベースに対する検索が効率よく行える。また、構造化文書データベースの現状との整合性を保ちながら検索が効率よく行える。
【図面の簡単な説明】
【図１】本発明の実施形態に係る構造化文書管理システムの構成例を示した図。
【図２】図１に示した構造化文書管理システムの一利用形態を示したもので、ＷＷＷのバックエンドで、構造化文書管理システムが動作している場合を示した図。
【図３】ＸＭＬで記述された構造化文書の一例を示した図。
【図４】図３の構造化文書の文書構造を模式的に示した図。
【図５】追加コマンドの機能を説明するための図で、構造化文書データベースの初期状態に追加コマンドを実行した場合について示している。
【図６】図５（ｂ）に示した状態の構造化文書データベースに対し、取得コマンドを実行した場合の処理結果を示した図。
【図７】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して１つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図８】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して３つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図９】要素名生起インデックスの格納例を示した図。
【図１０】データ生起インデックスの格納例を示した図。
【図１１】図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合の実行結果を示した図。
【図１２】ＸＭＬ文書の文書構造を定義するスキーマの一例を示した図。
【図１３】図８に示した状態の構造化文書データベースに、スキーマ格納コマンドを実行して、図１２に示したスキーマを追加格納（設定）した場合を示した図。
【図１４】スキーマが設定されて、スキーマが存在している旨の属性値のセットされた文書オブジェクトツリーを示した図。
【図１５】各オブジェクトファイルに、スキーマが存在している旨の属性値が格納されている様子を概念的に示した図。
【図１６】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１７】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１８】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図１９】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図２０】図１の構造化文書管理システムの文書格納処理動作について説明するためのフローチャート。
【図２１】図２０のステップＳ９の処理（合成文書作成部の処理）について説明するためのフローチャート
【図２２】追加コマンド中のパラメータの格納文書の文書オブジェクトツリーを構造化文書データベースから取得した文書オブジェクトツリーに挿入して得られた合成文書の文書オブジェクトツリーをＸＭＬ文書に変換した結果であって、テンポラリファイルＡに格納される合成文書の一例を示した図。
【図２３】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図２４】テンポラリファイルＡに格納される合成文書の他の例を示した図。
【図２５】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図２６】図１の構造化文書管理システムの文書取得処理動作について説明するためのフローチャート。
【図２７】図１の構造化文書管理システムの文書削除処理動作について説明するためのフローチャート。
【図２８】図２７のステップＳ４６の処理（合成文書作成部の処理（削除コマンド用））について説明するためのフローチャート。
【図２９】テンポラリファイルＡに格納される合成文書のさらに他の例であって、削除コマンドの実行時に作成される合成文書の一例を示した図。
【図３０】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図３１】ユーザインタフェースとしての画面の表示例を示した図。
【図３２】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３３】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３４】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３５】妥当性のチェックでエラーとなっときにクライアント端末へ返すメッセージの表示例を表示例を示した図。
【図３６】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示したもので、文書取得動作を説明するための図。
【図３７】スキーマの設定を行うためのユーザインタフェースとしての画面の表示例を示したもので、スキーマの設定動作を説明するための図。
【図３８】スキーマの取得するためのユーザインタフェースとしての画面の表示例を示したもので、取得されたスキーマの表示例を示している。
【図３９】クエリ（ＸＭＬ文書）の一例を示した図。
【図４０】単純検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図４１】図４０の単純検索のクエリを用いた検索結果（ＸＭＬ文書）を示した図。
【図４２】概念検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図４３】図１の構造化文書管理システムの文書検索処理動作について説明するためのフローチャート。
【図４４】文書検索を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図４５】図４４に示した画面上から入力された情報に基づき作成されるクエリを示した図。
【図４６】図４２に示したクエリの構造化文書データベース内における格納例を示した図。
【図４７】文書検索を行うためのユーザインタフェースとしての画面の表示例であって、スキーマの検索処理動作を説明するための図。
【図４８】スキーマ検索のクエリの一例を示した図。
【図４９】クエリを検索するためのクエリの一例を示した図。
【図５０】特許調査における構造化文書データベースの一例を示した図。
【図５１】概念検索のための入力画面の表示例を示した図。
【図５２】図５１に示した入力画面上の入力情報に対応するクエリを示した図。
【図５３】図５２に示したクエリに対応する検索結果としてのＸＭＬ文書を示した図。
【図５４】特許マップの一例を示した図。
【図５５】第２の実施形態に係る構造化文書管理システムの構成例を示した図。
【図５６】構造化文書データベースの一例を示した図。
【図５７】構造化文書の一例であって、「特許」情報を示した図。
【図５８】構造化文書データベースに格納されているクエリの一例を示した図。
【図５９】図５８のクエリを実行した結果得られた検索結果の一例を示した図。
【図６０】検索結果記憶部の記憶例を示した図。
【図６１】図５５の構造化文書管理システムの処理動作を説明するためのフローチャートで、検索要求を行ったユーザのクエリ実行権限の有無を考慮しない場合を示している。
【図６２】実行権限情報テーブルの一例を示した図。
【図６３】図５５の構造化文書管理システムの処理動作を説明するためのフローチャートで、検索要求を行ったユーザのクエリ実行権限の有無を考慮した場合を示している。
【図６４】第２の実施形態に係る構造化文書管理システムの他の構成例を示した図。
【図６５】イベントテーブルの一例を示した図。
【図６６】イベントテーブルに登録された各イベント検知時に、その検知したイベント対応のクエリを実行する際に、そのクエリの実行権限の有り無しを考慮すしない場合の図６４に示した構造化文書管理システムの処理動作について説明するためのフローチャート。
【図６７】イベントテーブルに登録された各イベント検知時に、その検知したイベント対応のクエリを実行する際に、そのクエリの実行権限の有り無しを考慮する場合の図６４に示した構造化文書管理システムの処理動作について説明するためのフローチャート。
【図６８】構造化文書パスにてクエリを指定した検索要求（検索結果の参照要求）が送信されてきたときの図６４の構造化文書管理システムの処理動作について説明するためのフローチャート。
【図６９】イベントテーブルの他の例を示した図。
【図７０】クライアント端末に表示される検索画面の一例を示した図。
【図７１】クライアント端末に表示されるイベント登録画面の一例を示した図。
【符号の説明】
１…要求制御部
２…アクセス要求処理部
３…検索要求処理部
４…データアクセス部
５…文書記憶部
６…インデックス記憶部
１１…受付要求部
１２…結果処理部
２１…文書格納部
２２…文書取得部
２３…文書削除部
４１…文書オブジェクトツリー格納部
４２…文書オブジェクトツリー削除部
４３…文書オブジェクトツリー取得部
４４…文書文字列取得部
４５…パスから文書オブジェクトツリー取得部
４６…文書パーサ
４７…合成文書作成部
４８…インデックス更新部
１００…構造化文書管理システム
１０１…ＷＷＷサーバ
１０２…クライアント端末
１０３…ＷＷＷブラウザ
２０１…検索結果記憶部
２０２…実行権限情報テーブル
２０３…イベント検出部
２０４…イベントテーブル
Claims (10)
- 複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに、構造化文書の種別に対応する種別ノードをリンクし、当該種別ノードに、各構造化文書に含まれる各要素の記憶エリアを当該構造化文書の文書構造に従ってリンクした論理構造により、前記複数の構造化文書を管理する構造化文書データベースと、
前記要素と当該要素に含まれる値とが指定された検索条件と、検索結果の出力形式を指定する出力条件とを含む検索要求文に基づき、前記論理構造から、当該検索要求文中の前記検索条件により指定された値を含む要素を検索し、当該検索された要素を含む構造化文書を求めるとともに、求めた構造化文書から、当該検索要求文中の前記出力条件により指定された出力形式の検索結果を生成する検索手段と、
前記検索要求文と前記検索結果とを対応付けて記憶する記憶手段と、
を備えた構造化文書管理装置における構造化文書検索方法であって、
入力された複数の検索要求文を、前記構造化文書データベースに格納する第１のステップと、
前記複数の検索要求文のうちの１つを指定した検索要求を受け付ける第２のステップと、
前記指定された検索要求文に対応する検索結果が前記記憶手段に記憶されているときは、その記憶されている検索結果を読み出して要求元に出力する第３のステップと、
前記指定された検索要求文に対応する検索結果が前記記憶手段に記憶されていないときには、前記検索手段が当該指定された検索要求文に基づき検索を行って、得られた検索結果を要求元に出力するとともに、当該検索結果を当該指定された検索要求文に対応付けて前記記憶手段に記憶する第４のステップと、
を有する構造化文書検索方法。 - 複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに、構造化文書の種別に対応する種別ノードをリンクし、当該種別ノードに、各構造化文書に含まれる各要素の記憶エリアを当該構造化文書の文書構造に従ってリンクした論理構造により、前記複数の構造化文書を管理する構造化文書データベースと、
前記要素と当該要素に含まれる値とが指定された検索条件と、検索結果の出力形式を指定する出力条件とを含む検索要求文に基づき、前記論理構造から、当該検索要求文中の前記検索条件により指定された値を含む要素を検索し、当該検索された要素を含む構造化文書を求めるとともに、求めた構造化文書から、当該検索要求文中の前記出力条件により指定された出力形式の検索結果を生成する検索手段と、
前記検索要求文と前記検索結果とを対応付けて記憶する記憶手段と、
を備えた構造化文書管理装置における構造化文書検索方法であって、
入力された複数の検索要求文を、前記構造化文書データベースに格納する第１のステップと、
前記複数の検索要求文のそれぞれに、その検索要求文に基づく検索実行が許可されている第１の種別のユーザと、該検索要求文に基づく検索実行は許可されていないが該検索要求文対応の検索結果は参照することが許可されている第２の種別のユーザとを設定する第２のステップと、
前記複数の検索要求文のうちの１つを指定した検索要求を受け付ける第３のステップと、
前記第３のステップで、前記第１の種別のユーザから前記検索要求を受け付けたとき、前記検索手段が当該指定された検索要求文に基づき検索を行って、得られた検索結果を要求元に出力するとともに、当該検索結果を当該指定された検索要求文に対応付けて前記記憶手段に記憶する第４のステップと、
前記第３のステップで、前記第２の種別のユーザから前記検索要求を受け付けたときは、前記指定された検索要求文に対応付けて前記記憶手段に記憶されている検索結果を読み出して要求元に出力する第５のステップと、
を有する構造化文書検索方法。 - 前記第４のステップは、
前記第１の種別のユーザから前記検索要求を受け付けたとき、前回検索を実行した時点から所定時間経過しているときは、前記検索手段が当該指定された検索要求文に基づき検索を行って、得られた検索結果を要求元に出力するとともに、当該検索結果を当該指定された検索要求文に対応付けて前記記憶手段に記憶するステップと、
前記第１の種別のユーザから前記検索要求を受け付けたとき、前回検索を実行した時点から所定時間経過していないときは、前記指定された検索要求文に対応付けて前記記憶手段に記憶されている検索結果を読み出して要求元に出力するステップと、
を含むことを特徴とする請求項２記載の構造化文書検索方法。 - 前記複数の検索要求文のうちの特定検索要求文に対し、前記論理構造上の範囲の指定されたイベント条件を設定するステップと、
前記構造化文書データベースに対する構造化文書の格納及び削除を含む複数の操作のうちのいずれかによる、前記イベント条件により指定された範囲の前記論理構造の更新を検知して、前記構造化文書データベースから前記特定検索要求文を取得するステップと、
前記検索手段が、取得された前記特定検索要求文に基づき検索を行って、得られた検索結果で、前記記憶手段に当該特定検索要求文に対応付けて記憶されている検索結果を更新するステップと、
をさらに有する請求項１または２記載の構造化文書検索方法。 - 複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに、構造化文書の種別に対応する種別ノードをリンクし、当該種別ノードに、各構造化文書に含まれる各要素の記憶エリアを当該構造化文書の文書構造に従ってリンクした論理構造により、前記複数の構造化文書を管理する構造化文書データベースと、
前記要素と当該要素に含まれる値とが指定された検索条件と、検索結果の出力形式を指定する出力条件とを含む検索要求文に基づき、前記論理構造から、当該検索要求文中の前記検索条件により指定された値を含む要素を検索し、当該検索された要素を含む構造化文書を求めるとともに、求めた構造化文書から、当該検索要求文中の前記出力条件により指定された出力形式の検索結果を生成する検索手段と、
前記検索要求文と前記検索結果とを対応付けて記憶する記憶手段と、
入力された複数の検索要求文を、前記構造化文書データベースに格納する手段と、
前記複数の検索要求文のうちの１つを指定した検索要求を受け付ける検索要求受付手段と、
前記指定された検索要求文に対応する検索結果が前記記憶手段に記憶されているときは、その記憶されている検索結果を読み出して要求元に出力する第１の制御手段と、
前記指定された検索要求文に対応する検索結果が前記記憶手段に記憶されていないときには、前記検索手段に当該指定された検索要求文に基づき検索を行わせ、得られた検索結果を要求元に出力するとともに、当該検索結果を当該指定された検索要求文に対応付けて前記記憶手段に記憶する第２の制御手段と、
を具備したことを特徴とする構造化文書管理装置。 - 複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに、構造化文書の種別に対応する種別ノードをリンクし、当該種別ノードに、各構造化文書に含まれる各要素の記憶エリアを当該構造化文書の文書構造に従ってリンクした論理構造により、前記複数の構造化文書を管理する構造化文書データベースと、
前記要素と当該要素に含まれる値とが指定された検索条件と、検索結果の出力形式を指定する出力条件とを含む検索要求文に基づき、前記論理構造から、当該検索要求文中の前 記検索条件により指定された値を含む要素を検索し、当該検索された要素を含む構造化文書を求めるとともに、求めた構造化文書から、当該検索要求文中の前記出力条件により指定された出力形式の検索結果を生成する検索手段と、
前記検索要求文と前記検索結果とを対応付けて記憶する記憶手段と、
入力された複数の検索要求文を、前記構造化文書データベースに格納する手段と、
前記複数の検索要求文のそれぞれに、その検索要求文に基づく検索実行が許可されている第１の種別のユーザと、該検索要求文に基づく検索実行は許可されていないが該検索要求文対応の検索結果は参照することが許可されている第２の種別のユーザとを定めた実行権限情報テーブルと、
前記複数の検索要求文のうちの１つを指定した検索要求を受け付ける検索要求受付手段と、
前記検索要求受付手段で、前記第１の種別のユーザから前記検索要求を受け付けたとき、前記検索手段に当該指定された検索要求文に基づき検索を行わせ、得られた検索結果を要求元に出力するとともに、当該検索結果を当該指定された検索要求文に対応付けて前記記憶手段に記憶する第１の制御手段と、
前記検索要求受付手段で、前記第２の種別のユーザから前記検索要求を受け付けたときは、前記指定された検索要求文に対応付けて前記記憶手段に記憶されている検索結果を読み出して要求元に出力する第２の制御手段と、
を具備したことを特徴とする構造化文書管理装置。 - 前記第１の制御手段は、
前記第１の種別のユーザから前記検索要求を受け付けたとき、前回検索を実行した時点から所定時間経過しているときは、前記検索手段に当該指定された検索要求文に基づき検索を行わせ、得られた検索結果を要求元に出力するとともに、当該検索結果を当該指定された検索要求文に対応付けて前記記憶手段に記憶する手段と、
前記第１の種別のユーザから前記検索要求を受け付けたとき、前回検索を実行した時点から所定時間経過していないときは、前記指定された検索要求文に対応付けて前記記憶手段に記憶されている検索結果を読み出して要求元に出力する手段と、
を含むことを特徴とする請求項６記載の構造化文書管理装置。 - 前記複数の検索要求文のうちの特定検索要求文に対し、前記論理構造上の範囲の指定されたイベント条件を示すイベントテーブルと、
前記構造化文書データベースに対する構造化文書の格納及び削除を含む複数の操作のうちのいずれかによる、前記イベント条件により指定された範囲の前記論理構造の更新を検知して、前記構造化文書データベースから前記特定検索要求文を取得する手段と、
前記検索手段に、取得された前記特定検索要求文に基づき検索を行わせ、得られた検索結果で、前記記憶手段に当該特定検索要求文に対応付けて記憶されている検索結果を更新する第３の制御手段と、
をさらに具備したことを特徴とする請求項５または６記載の構造化文書管理装置。 - 複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに、構造化文書の種別に対応する種別ノードをリンクし、当該種別ノードに、各構造化文書に含まれる各要素の記憶エリアを当該構造化文書の文書構造に従ってリンクした論理構造により、前記複数の構造化文書を管理する構造化文書データベースと、
前記要素と当該要素に含まれる値とが指定された検索条件と、検索結果の出力形式を指定する出力条件とを含む検索要求文に基づき、前記論理構造から、当該検索要求文中の前記検索条件により指定された値を含む要素を検索し、当該検索された要素を含む構造化文書を求めるとともに、求めた構造化文書から、当該検索要求文中の前記出力条件により指定された出力形式の検索結果を生成する検索手段と、
前記検索要求文と前記検索結果とを対応付けて記憶する記憶手段と、
を備えたコンピュータに、
入力された複数の検索要求文を、前記構造化文書データベースに格納する第１のステップと、
前記複数の検索要求文のうちの１つを指定した検索要求を受け付ける第２のステップと、
前記指定された検索要求文に対応する検索結果が前記記憶手段に記憶されているときは、その記憶されている検索結果を読み出して要求元に出力する第３のステップと、
前記指定された検索要求文に対応する検索結果が前記記憶手段に記憶されていないときには、前記検索手段に当該指定された検索要求文に基づき検索を行わせ、得られた検索結果を要求元に出力するとともに、当該検索結果を当該指定された検索要求文に対応付けて前記記憶手段に記憶する第４のステップと、
を実行させるためのプログラム。 - 複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに、構造化文書の種別に対応する種別ノードをリンクし、当該種別ノードに、各構造化文書に含まれる各要素の記憶エリアを当該構造化文書の文書構造に従ってリンクした論理構造により、前記複数の構造化文書を管理する構造化文書データベースと、
前記要素と当該要素に含まれる値とが指定された検索条件と、検索結果の出力形式を指定する出力条件とを含む検索要求文に基づき、前記論理構造から、当該検索要求文中の前記検索条件により指定された値を含む要素を検索し、当該検索された要素を含む構造化文書を求めるとともに、求めた構造化文書から、当該検索要求文中の前記出力条件により指定された出力形式の検索結果を生成する検索手段と、
前記検索要求文と前記検索結果とを対応付けて記憶する記憶手段と、
を備えたコンピュータに、
入力された複数の検索要求文を、前記構造化文書データベースに格納する第１のステップと、
前記複数の検索要求文のそれぞれに、その検索要求文に基づく検索実行が許可されている第１の種別のユーザと、該検索要求文に基づく検索実行は許可されていないが該検索要求文対応の検索結果は参照することが許可されている第２の種別のユーザとを設定する第２のステップと、
前記複数の検索要求文のうちの１つを指定した検索要求を受け付ける第３のステップと、
前記第３のステップで、前記第１の種別のユーザから前記検索要求を受け付けたとき、前記検索手段に当該指定された検索要求文に基づき検索を行わせ、得られた検索結果を要求元に出力するとともに、当該検索結果を当該指定された検索要求文に対応付けて前記記憶手段に記憶する第４のステップと、
前記第３のステップで、前記第２の種別のユーザから前記検索要求を受け付けたときは、前記指定された検索要求文に対応付けて前記記憶手段に記憶されている検索結果を読み出して要求元に出力する第５のステップと、
を実行させるためのプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001098188A JP3842575B2 (ja) | 2001-03-30 | 2001-03-30 | 構造化文書検索方法、構造化文書管理装置及びプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001098188A JP3842575B2 (ja) | 2001-03-30 | 2001-03-30 | 構造化文書検索方法、構造化文書管理装置及びプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002297604A JP2002297604A (ja) | 2002-10-11 |
| JP3842575B2 true JP3842575B2 (ja) | 2006-11-08 |
Family
ID=18951863
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001098188A Expired - Fee Related JP3842575B2 (ja) | 2001-03-30 | 2001-03-30 | 構造化文書検索方法、構造化文書管理装置及びプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3842575B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5057460B2 (ja) * | 2007-12-25 | 2012-10-24 | キヤノンマーケティングジャパン株式会社 | 文書管理システム、文書管理装装置、文書管理方法、およびプログラム |
| JP4811451B2 (ja) * | 2008-11-13 | 2011-11-09 | コニカミノルタホールディングス株式会社 | データベースシステム、およびデータ生成方法 |
-
2001
- 2001-03-30 JP JP2001098188A patent/JP3842575B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002297604A (ja) | 2002-10-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3842573B2 (ja) | 構造化文書検索方法、構造化文書管理装置及びプログラム | |
| JP3842577B2 (ja) | 構造化文書検索方法および構造化文書検索装置およびプログラム | |
| US7370061B2 (en) | Method for querying XML documents using a weighted navigational index | |
| JP3754253B2 (ja) | 構造化文書検索方法、構造化文書検索装置及び構造化文書検索システム | |
| US6618727B1 (en) | System and method for performing similarity searching | |
| US20070219959A1 (en) | Computer product, database integration reference method, and database integration reference apparatus | |
| US20080183689A1 (en) | Search method and apparatus for plural databases | |
| US20110087708A1 (en) | Business object based operational reporting and analysis | |
| JP3914081B2 (ja) | アクセス権限設定方法および構造化文書管理システム | |
| CN100498771C (zh) | 用于管理结构化文件的系统和方法 | |
| Saputra et al. | A metadata approach for building web application user interface | |
| JP3842572B2 (ja) | 構造化文書管理方法および構造化文書管理装置およびプログラム | |
| JP3842576B2 (ja) | 構造化文書編集方法及び構造化文書編集システム | |
| JP5056384B2 (ja) | 検索プログラム、方法及び装置 | |
| JP3842574B2 (ja) | 情報抽出方法および構造化文書管理装置およびプログラム | |
| JP3842575B2 (ja) | 構造化文書検索方法、構造化文書管理装置及びプログラム | |
| JPH10187680A (ja) | 単語、文、部分の粒度で管理するドキュメントリポジトリ装置 | |
| Liu et al. | An XML-enabled data extraction toolkit for web sources | |
| CN1326078C (zh) | 包装器的生成方法 | |
| JP2003316783A (ja) | 異種半構造化情報源統合検索装置、方法、プログラム及び該プログラムを記録した記録媒体 | |
| JP3910901B2 (ja) | 文書構造検索方法、文書構造検索装置および文書構造検索プログラム | |
| JP2004118543A (ja) | 構造化文書検索方法、検索支援方法、検索支援装置および検索支援プログラム | |
| JP2003288365A (ja) | 付加情報管理方法及び付加情報管理システム | |
| Mihaila et al. | Locating and accessing data repositories with WebSemantics | |
| JP2004118379A (ja) | 構造化文書分析表示方法および構造化文書分析表示装置およびプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051025 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051108 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060110 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060808 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060810 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100818 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100818 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110818 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120818 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120818 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130818 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |