(57)【特許請求の範囲】
【請求項１】
複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに複数のノードをリンクし、当該複数のノードのうちの１つに、各構造化文書の各要素の記憶エリアを前記文書構造に従ってリンクした論理構造により前記複数の構造化文書を管理する構造化文書データベースと、
要素名及び当該要素名の要素の値に含まれる語が指定された検索条件を含む検索要求文に基づき、前記論理構造から前記検索条件を満たす要素を含む構造化文書を検索する検索手段と、
を備えた構造化文書管理装置の前記検索手段で検索された構造化文書を編集するための構造化文書編集方法であって、
前記検索手段で検索された構造化文書中の予め定められた位置に追加された新たな要素を、当該構造化文書に対応付けて記憶手段に記憶するステップと、
前記複数の構造化文書中の要素の要素名及び当該要素の値に含まれる語が指定された第１の検索条件と、前記新たな要素の要素名及び当該新たな要素の値が指定された第２の検索条件とを入力する入力ステップと、
前記第１の検索条件を含む前記構造化文書データベースに対する第１の検索要求文と、前記第２の検索条件を含む前記記憶手段に対する第２の検索要求文とを生成する生成ステップと、
前記検索手段が、前記第１の検索要求文に基づき、前記第１の検索条件を満たす構造化文書を検索する第１の検索ステップと、
前記第２の検索要求文に基づき前記記憶手段から、前記第２の検索条件を満たす新たな要素を検索する第２の検索ステップと、
前記第１の検索ステップで検索された構造化文書中の前記予め定められた位置に、前記第２の検索ステップで検索された新たな要素のうち当該構造化文書に対応付けられている新たな要素を追加することにより、拡張文書を生成するステップと、
前記拡張文書を表示手段で表示するステップと、
を有する構造化文書編集方法。
【請求項２】
前記入力ステップは、前記新たな要素の要素名と、当該新たな要素のとり得る値とを記憶するユーザタグ記憶手段で記憶されている要素名及び値のうち、選択された要素名及び値を、前記第２の検索条件として入力することを特徴とする請求項１記載の構造化文書編集方法。
【請求項３】
複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに複数のノードをリンクし、当該複数のノードのうちの１つに、各構造化文書の各要素の記憶エリアを前記文書構造に従ってリンクした論理構造により前記複数の構造化文書を管理する構造化文書データベースと、
要素名及び当該要素名の要素の値に含まれる語が指定された検索条件を含む検索要求文に基づき、前記論理構造から前記検索条件を満たす要素を含む構造化文書を検索する第１の検索手段と、
を備えた構造化文書管理装置と、
前記第１の検索手段で検索された構造化文書中の予め定められた位置に追加された新たな要素を、当該構造化文書に対応付けて記憶する第１の記憶手段と、
前記複数の構造化文書中の要素の要素名及び当該要素の値に含まれる語が指定された第１の検索条件と、前記新たな要素の要素名及び当該新たな要素の値が指定された第２の検索条件とを入力する入力手段と、
前記第１の検索条件を含む前記構造化文書データベースに対する第１の検索要求文と、前記第２の検索条件を含む前記第１の記憶手段に対する第２の検索要求文とを生成する生成手段と、
前記第１の検索要求文を前記構造化文書管理装置へ送信する手段と、
前記第２の検索要求文に基づき前記第１の記憶手段から、前記第２の検索条件を満たす新たな要素を検索する第２の検索手段と、
前記構造化文書管理装置から、前記第１の検索手段で前記第１の検索要求文に基づき検索した結果得られた構造化文書を受信する手段と、
前記第１の検索要求文に基づき検索した結果得られた構造化文書中の前記予め定められた位置に、前記第２の検索手段で検索された新たな要素のうち当該構造化文書に対応付けられている新たな要素を追加することにより拡張文書を生成する手段と、
前記拡張文書を表示手段で表示する手段と、
を備えた構造化文書編集装置と、
を含むことを特徴とする構造化文書編集システム。
【請求項４】
前記構造化文書編集装置は、
前記新たな要素の要素名と、当該新たな要素のとり得る値とを入力する手段と、
入力された新たな要素の要素名と、当該新たな要素のとり得る値とを記憶する第２の記憶手段と、
をさらに備え、
前記入力手段は、前記第２の記憶手段で記憶されている要素名及び値のうち選択された要素名及び値を、前記第２の検索条件として入力することを特徴とする請求項３記載の構造化文書編集システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、階層化された論理構造を持つ構造化文書データベースに格納されている構造化文書の編集方法および、それを用いた構造化文書編集装置に関する。
【０００２】
【従来の技術】
現在、ＩＴ（情報技術）の進化により、莫大な量の情報が容易に入手できるようになった。その一方で必要な情報が大量のデータに埋没してしまい、十分に活用できないという弊害も発生している。情報が大量に存在していても、それをうまく活用できなければ意味がない。
【０００３】
そこで、特定の個人や部門が保有するノウハウや業務データのうち企業の経営に重要なものを蓄積して、「経営資産」として活用しようとする活動、すなわち、ナレッジマネージメントが提唱されている。
【０００４】
例えば、特許明細書や、週報など、文書の種類によっては、その書式が予め定められて、１つの書式に統一されているのが一般的である。１つの書式に統一された文書もあれば、全く書式のない自由書式の文書も数多く存在する。
【０００５】
従って、ナレッジマネージメントを実現するためには、このような文書構造が予め定められているような文書も、それ以外の自由書式の文書も全て格納管理できるデータベースが必要となる。
【０００６】
次世代のナレッジマネージメントの中核技術として期待されている技術がＸＭＬである。ＸＭＬ（Ｅｘｔｅｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）は柔軟な拡張性と連携性を備えた標準のドキュメント記述言語であり、主要ベンダーからのサポートも約束されている。
【０００７】
一方、近年のインターネット技術の発達により、ＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）に代表されるネットワーク上の文書共有システムが急速に普及している。ＷＷＷでは、ネットワーク上の文書が現在、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）で記述されている。この分野においてもＨＴＭＬに継ぐ次世代の文書記述言語としてＸＭＬが期待されている。ＸＭＬでは、文書データの構造と表示スタイルを分けて定義することができるため文書構造の変更や文書の再利用がしやすい、タグを用いて文書の構造を厳密に定義できるためタグの条件指定による検索に適している、といった特徴がある。
【０００８】
このような、ＨＴＭＬ、ＸＭＬで記述された文書は構造化文書と呼ばれており、今後ますます構造化文書をネットワーク上で共有する場面が増えることが予想される。特にＸＭＬで記述された構造化文書に関しては、タグの条件指定による検索要求（クエリ）をクライアントから発行して、サーバ上に置かれた構造化文書の中から所望のデータを検索する検索システムの構築が普及すると期待される。以下、ネットワーク上の構造化文書のことを単に文書と呼ぶことにする。
【０００９】
一方、インターネットでＷＷＷを通じて得られる文書は、不特定多数のユーザが共有して閲覧することが前提となるため、ユーザ個人のタグ（あるいはマークやコメント）を通常付加することができないようになっている。
【００１０】
しかしながら、文書が例えば、営業員が閲覧する顧客データのとき、各営業員が顧客への訪問や案件処理の優先順位（緊急度）を個人的にタグとしてつけたいという要望が生ずる場合がある。あるいは、文書が特許データのとき、各特許に対しての評価や、何年何月何日に閲覧したかをタグとして追加したいという要望が生ずる場合がある。
【００１１】
従って、書き換えが許可されていない構造化文書データベースから、ネットワーク経由で不特定多数のユーザが構造化文書を検索表示するシステムにおいて、ユーザが個人用のタグを追加できる仕組みが望まれている。
【００１２】
ここで、上記の要望に応えるための従来技術として、文書に対してユーザが個人的なマークやコメント等の情報を付加する方法が、特開２００１−２２７４９号公報に開示されている。そこでは、文書を提供するサーバ側が、予め個人付加情報データベースや個人付加情報管理部を文書とともに保持しており、ユーザが構造化文書を表示する際にマークやコメントを付与して表示することで、組織内の複数メンバー間でこれらの個人付加情報をつけた文書を共有して閲覧する方式が提案されている。
【００１３】
しかしながら、上記の方法では文書を提供するサーバと文書を表示するクライアントの両方を新規に作りこむ必要がある。したがって、文書を提供するサーバが外部組織に属していて、その構成を変えることが許可されていない場合にはこの方法を適用することができない。
【００１４】
また、上記の方法は、新規に付加した個人付加情報はマークやコメントを想定しているため、個人付加情報を基に構造化文書を検索するといった機能は用意されていない。しかしながら、例えば文書が特許データのとき、自分で付与した評価が「Ａ」の特許だけを検索したい、といった要望が生ずる場合がある。さらに、例えば文書のタグが閲覧日であり、その子要素の「年」、「月」、「日」を取り得る場合もあるため、個人用のタグ自体も階層構造を持つことが可能であることが望まれている。
【００１５】
以上より、文書を提供するサーバの構成を変えることなく、個人用のタグを追加するための構造化文書の編集や、編集内容を反映した構造化文書の検索が行えるシステムが望まれている。
【００１６】
特に、追加した個人用のタグを基にクライアントから検索できたり、そのために、個人用のタグは階層構造を持つことができることが望まれている。
【００１７】
【発明が解決しようとする課題】
以上説明したように、サーバ側に構造化文書をおき、ネットワーク経由でクライアント側から検索要求を発行して所望の構造化文書を検索表示する形態において、構造化文書の書き換えが許可されていないときであってもユーザが個人用のタグを付加する編集を行いたいという要望に対し、特開２００１−２２７４９号公報に開示されている方法では、文書を提供するサーバ構成の変更が許可されていない場合に適用できないという問題点があった。
【００１８】
また、上記開示されている方法は、新規に付加したマークやコメント等の個人付加情報を文書に付加して表示するためのものであり、個人付加情報を基に構造化文書を検索することはできないという問題点があった。
【００１９】
そこで、本発明は、上記問題点に鑑み、構造化文書データベースを有し、その構造化文書データベースに格納されている構造化文書をクライアントからの要求に応じて提供するサーバの構成を変えることなく、また、構造化文書データベースに対し、何ら操作を行うことなく、構造化文書データベースに格納されている構造化文書に個人用のタグを追加する編集と、その編集した結果を反映した構造化文書の検索が容易に行える構造化文書編集方法およびそれを用いた構造化文書編集装置および端末装置およびプログラムを提供することを目的とする。
【００２０】
【課題を解決するための手段】
本発明は、階層化された論理構造を持つ構造化文書データベースに格納されている複数の構成要素からなる構造化文書に追加する新たな構成要素を作成して、この作成された新たな構成要素を該構造化文書に対応付けて記憶し、前記構成要素とその値を検索条件に含む検索要求に基づき、前記記憶手段で記憶された新たな構成要素を検索するための第１の検索要求と、前記構造化文書データベースに格納された構造化文書を検索するための第２の検索要求とを生成し、前記第２の検索要求に基づき前記構造化文書データベースから検索された構造化文書に前記第１の検索要求に基づき検索された新たな構成要素が対応付けられているときは、該構造化文書に該新たな構成要素を追加して表示することを特徴とする。
【００２１】
本発明によれば、構造化文書を提供する側（例えば、構造化文書管理システムおよびＷＷＷサーバ）の構成は一切変更することなく、しかも、構造化文書データベースに対しては何ら操作を行う必要なく、書き換えが許可されていない構造化文書データべース上の構造化文書への編集（加工）と、その編集した結果を含めた構造化文書の検索が容易に行える。
【００２２】
【発明の実施の形態】
まず、本発明の実施形態について説明する前に、構造化文書管理システムについて説明する。
【００２３】
（構造化文書管理システムの説明）
構造化文書として、ＸＭＬやＳＧＭＬなどで記述した文書が挙げられる。ＳＧＭＬ（Ｓｔａｎｄａｒｄ  Ｇｅｎｅｒａｌｉｚｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）とは、ＩＳＯ（国際標準化機構）で定められた規格である。ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）とは、Ｗ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）にて定められた規格である。それぞれ文書を構造化することを可能とする構造化文書規約である。
【００２４】
以下、構造化文書として、ＸＭＬにて記述された文書を例に説明を進める。構造化文書の文書構造を定義したデータ（文書構造定義データ）をスキーマと呼ぶ。ＸＭＬではそのスキーマを定義するためにＸＭＬ−ＳｃｈｅｍａやＸＤＲ（ＸＭＬ  Ｄａｔａ  Ｒｅｄｕｃｅｄ）などのスキーマ言語が提案されている。ここでは、例えば、ＸＤＲでのスキーマを記述する場合を例にとり説明する。
【００２５】
スキーマも、構造化文書管理システムの管理対象の構造化文書であり、従って、スキーマ文書と呼ぶことがある。スキーマ文書と区別するために、特許明細書やメール、週報、広告などの種々雑多な内容を有す文書をコンテンツ文書と呼ぶこともある。
【００２６】
構造化文書管理システムでは、上記スキーマ文書、上記コンテンツ文書、さらに、後述するようなユーザからの検索要求内容を記述したクエリ、すなわち、クエリ文書も管理対象とし、これらを総称して「文書」と呼ぶ。
【００２７】
以下、特にことわりがない場合、「文書」と呼ぶときは、コンテンツ文書、スキーマ文書、クエリ文書を全て指すものとする。
【００２８】
まず、実施形態の説明を前に、ＸＭＬについて簡単に説明する。
【００２９】
図３は、ＸＭＬで記述された構造化文書の一例として、「特許」情報の例を示したものである。ＸＭＬやＳＧＭＬは、文書の構造の表現にタグが用いられる。タグには、開始タグと終了タグがあり、文書構造情報の構成要素を開始タグと終了タグで囲むことにより、文書中の文字列（テキスト）区切りと、そのテキストが構造上どの構成要素に属するのかを明確に記述することができる。
【００３０】
ここで開始タグとは要素名称を記号「＜」、「＞」で閉じたものであり、終了タグとは要素名称を記号「＜／」と「＞」で閉じたものである。タグに続く構成要素の内容が、テキスト（文字列）または子供の構成要素の繰り返しである。また開始タグには「＜要素名称  属性＝“属性値”＞」などのように属性情報を設定することができる。「＜特許ＤＢ＞＜／特許ＤＢ＞」のようにテキストを含まない構成要素は、簡易記法として「＜特許ＤＢ／＞」のように表わすこともできる。
【００３１】
図３に示した文書は、「特許」タグから始まる要素をルート(根)とし、その子要素として「タイトル」、「出願日」、「出願者」、「要約」タグから始まる要素集合が存在する。また、例えば、「タイトル」タグから始まる要素には「ＸＭＬデータベース」といった、１つのテキスト（文字列）が存在する。
【００３２】
ＸＭＬなどの構造化文書は、任意の構成要素を繰り返し含んでいたり、さらには文書構造があらかじめ決まっていない（ＲＤＢ（リレーショナルデータベース）やＯＯＤＢ（オブジェクト指向データベース）のスキーマでは定義できない）のが普通である。
【００３３】
図３に示したような構造化文書を論理的に表現するために、図４に示すようなツリー表現が用いられる。ツリーは、ノード（番号が付され、円形で示されたもの）とアーク（ノードを表す円形間をつなぐデータ付き線）と四角形で囲まれたテキストから構成されている。
【００３４】
ノードは文書オブジェクトに対応し、ノードからタグ名や属性名に相当するラベルが付与された複数のアークが出てきている。そのアークの先は、ノードまたは要素値としての文字列（テキスト）である。ノードの中に記載されている英数字（＃０、＃４９）などはオブジェクトＩＤである。
【００３５】
図４に示したツリー構造を図３に示した構造化文書の文書オブジェクトツリーと呼ぶ。
【００３６】
図１は、本実施形態に係る構造化文書管理システムの構成例を示したものである。図１において、構造化文書管理システムは、大きく分けて、要求制御部１、アクセス要求処理部２、検索要求処理部３、データアクセス部４、文書記憶部５、インデックス記憶部６から構成されている。文書記憶部５、インデックス記憶部６は例えば、外部記憶装置を用いて構成される。
【００３７】
図１のシステム構成は、ソフトウエアを用いて実現可能である。
【００３８】
要求制御部１は、要求受付部１１と結果処理部１２から構成されている。要求受付部１１は、ユーザからの文書格納や文書取得、文書検索などの要求を受け付けて、アクセス要求処理部２を呼び出す。結果処理部１２は、アクセス要求処理部２が処理した結果を要求元のユーザに返す処理を行う。
【００３９】
アクセス要求処理部２は、ユーザからの文書格納や文書取得などの要求に対応した複数の処理部から構成されている。つまり、文書格納部２１、文書取得部２２、文書削除部２３から構成されている。
【００４０】
文書格納部２１は、文書記憶部５中の論理的な指定エリアに文書を格納する処理を行う。
【００４１】
文書取得部２２は、文書記憶部５中の論理的なエリアが指定されたときに、その指定エリアに存在する文書を取得する処理を行う。
【００４２】
文書削除部２３は、文書記憶部５中の論理的な指定エリアに存在する文書を削除する処理を行う。
【００４３】
文書記憶部５は、構造化文書データベースであり、例えば、図８に示すように、文書をＵＮＩＸのディレクトリ構造のように階層的にツリー構造状に格納している。
【００４４】
図８に示すように、構造化文書データベースは、図４に示したような１つの構造化文書のツリー構造と同様に表現できる。すなわち、任意のノード以下の部分階層木（部分ツリー）は、構造化文書データベースから切り出された構造化文書であり、ここでは、これを文書オブジェクトツリーと呼ぶ。各ノードにはオブジェクトＩＤが割り当てられている。オブジェクトＩＤは、構造化文書データベース内ではユニークな数値を持つものとする。
【００４５】
階層木のルートとなるノードには、それがルートノードであることを特定するためのオブジェクトＩＤ「＃０」が割り当てられるものとする。
【００４６】
ルートノード、すなわち、「＃０」のノードからは「ｒｏｏｔ」タグを先頭に持つ「＃１」のノードへリンクが張られている。「＃１」のノードからは、「特許ＤＢ」タグを先頭にもつ「＃２」ノードへのリンクが張られている。「＃２」ノードからは、「特許」タグを先頭に持つ「＃４２」ノード、「＃５２」ノード、「＃６２」ノードへのリンクがそれぞれ張られている。
【００４７】
図３に示した「特許」情報は、「＃４２」ノード以下の部分ツリーに対応している。このノードからは「タイトル」タグ、「出願者」タグ、「要約」タグなどを先頭にもつノードへリンクが張られ、末端のノードからは、「ＸＭＬデータベース」、「Ｔ社」。「ＸＭＬを統一的に管理するデータベースを提供する…」などの文字列（要素値）へのリンクが張られている。
【００４８】
「＃５２」ノード以下の部分ツリー、「＃６２」ノード以下の部分ノードも１つの「特許」情報に対応する部分である。
【００４９】
ところで、例えば、「＃４３」ノードにリンクされた「ＸＭＬデータベース」という要素値は、「＃４３」ノードと「＃ｖａｌｕｅ」という特殊なタグ名で接続されている。このタグ名は、「＃」で始まるためＸＭＬ規格においては標準的なタグ名として利用することはできない。
【００５０】
このような構造化文書データベースの特定ノードを指定するために構造化文書パスを用いる。構造化文書パスは「ｕｉｘ：／／ｒｏｏｔ」から始まる文字列である。ｕｉｘ（Ｕｎｉｖｅｒｓａｌ  Ｉｄｅｎｔｉｆｉｅｒ  ｆｏｒ  ＸＭＬ）は構造化文書パスであることを示す前置文字列である。
【００５１】
例えば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」は、「＃１」ノードから「特許ＤＢ」が付与されたアークが指し示すノード、つまり「＃２」ノードに対応する。このように「ｒｏｏｔ」から「／」で区切られた部分文字列をタグ名とみなすことで「＃０」ノードからタグ名の並びに沿って対応するアークを下っていき、その最後のアークが指すノードが、パスの場所を指し示す。
【００５２】
例えば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許」は、「＃４２」ノード、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／出願日／年」は、「＃４５」ノードを指し示す。
【００５３】
「＃２」ノード以下に、すなわち、「特許ＤＢ」に、複数の「特許」情報を格納する場合には、個々の「特許」情報を識別するために、構造化文書パスにインデックス表現が可能である。
【００５４】
「特許ＤＢ」の最初の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」となるが、これは「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許」と同じとみなす。
【００５５】
「特許ＤＢ」の２番目の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［１］ＤＢ」の５番目の「特許」情報であれば、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［４］」となる。
【００５６】
インデックス記憶部６には検索時に用いる、要素名称生起インデックスとデータ生起インデックスが記憶されている。
【００５７】
要素名生起インデックスとは構造化文書データベースに格納されている要素名称のリストと、各要素名称が先頭にある構造化文書（文書オブジェクトツリー）の位置とを関連付けてインデックスファイル化したものである。例えば、図８の構造化文書データベースのように、（「特許」情報に対応する）「特許」という要素名称が「＃４２」ノード以下の構造化文書、「＃５２」ノード以下の構造化文書、「＃６２」ノード以下の構造化文書に存在する場合、これらをインデックス化すると、図９に示すように、それらの親ノード、「＃２」ノードが、要素名称生起インデックスファイルに「特許」キーからのチェーンで格納される。
【００５８】
このように、親ノードでインデックス化すると、インデックスファイルを圧縮することができる。すなわち、親ノードでインデックス化すれば、子ノードが増大しようとも、親ノードで代用しているので、チェーンサイズは増大しない。これに対し、実ノードをインデックス化すれば「特許」情報の格納数の増大とともにチェーンサイズはそれに比例して増加してしまう。
【００５９】
データ生起インデックスとは、構造化文書データベースに格納されている文字列データのリストと各文字列データがある構造化文書（文書オブジェクトツリー）の位置とを関連付けてインデックスファイル化したものである。例えば、図８の構造化文書データベースのように、「ＸＭＬ」という文字列データ（および、「ＸＭＬ」という文字列を含む文字列）が「＃４３」ノード以下の構造化文書、「＃４９」ノード以下の構造化文書に存在する場合、これらをインデックス化すると、図１０に示すように、「＃４３」ノード、「＃４９」ノードが、データ生起インデックスファイルに「ＸＭＬ」キーからのチェーンで格納される。
【００６０】
なお、逆階層インデックスなど、その他のインデックスファイルを用いてもよい。逆階層インデックスとは、あるノードとその親ノードとの対応を格納したものである（あるノードからその親ノードを求めることができる）。
【００６１】
文書記憶部５中の論理的な指定エリアとは、ユーザにより構造化文書パスを用いて指定された文書の格納場所を指す。構造化文書パスは、ユーザにとって認識可能な表現である。
【００６２】
図１の説明に戻る。
【００６３】
データアクセス部４は、文書記憶部５をアクセスする基本インターフェイスの集合である。データアクセス部４は、文書オブジェクトツリー格納部４７、文書オブジェクトツリー削除部４８、文書オブジェクトツリー取得部４９、文書文字列取得部４４、パスから文書オブジェクトツリー取得部４５、文書パーサ部４６、合成文書作成部４７、インデックス更新部４８から構成される。
【００６４】
文書オブジェクトツリー格納部４１は、文書記憶部５中の物理的な指定エリアに文書オブジェクトツリーを格納する処理を行う。
【００６５】
文書オブジェクトツリー削除部４２は、文書記憶部５中の物理的な指定エリアに存在する文書オブジェクトツリーを削除する処理を行う。
【００６６】
文書オブジェクトツリー取得部４３は、文書記憶部５中の物理的な指定エリアに存在する文書オブジェクトツリーを取得する処理を行う。
【００６７】
文書文字列取得部４４は、文書オブジェクトツリーを構造化文書（ＸＭＬ文書）に変換する処理を行う。
【００６８】
パスから文書オブジェクトツリー取得部４５は、構造化文書パスを解析して文書記憶部５中の物理的なエリアを特定して、そのエリアに存在する文書オブジェクトツリーを取り出す処理を行う。
【００６９】
文書パーサ部４６は、ユーザにより入力された構造化文書を読み込んで構文解析して整合性の検査を行い、さらに文書構造定義データであるスキーマが存在すれば構造的に妥当かどうかの検証を行う。出力結果は文書オブジェクトツリーとなる。文書パーサは、通常、ｌｅｘ（ｌｅｘｉｃａｌ  ａｎａｌｙｚｅｒ  ｇｅｎｅｒａｔｏｒ）といったレキシカルアナライザ（字句解析を行い，トークンに分解する）とｙａｃｃ（ｙｅｔ  ａｎｏｔｈｅｒ  ｃｏｍｐｉｌｅｒ  ｃｏｍｐｉｌｅｒ）といったパーサジェネレータを組み合わせて構築することができる。
【００７０】
合成文書作成部４７は、文書格納や文書削除などをする際に、スキーマに合致しているかどうか検査しなければならないが、この検査時に必要となるデータを作成して出力する。
【００７１】
インデックス更新部４８は、文書格納や文書削除などにより、構造化文書データベースの格納内容が更新されるたびに、図９、図１０に示した要素名称生起インデックスとデータ生起インデックスを更新する。
【００７２】
文書記憶部５中の物理的な指定エリアとは、ファイルオフセットやオブジェクトＩＤなどの構造化文書データベース内ではユニークな文書データの存在場所を指し示す内部データである。ユーザにとっては認識不能なデータである。
【００７３】
文書記憶部５中に格納された文書を検索する処理を行う。要求制御部１の要求受付部１１でユーザからの文書検索の要求が受け付けられると、検索要求処理部３には、要求受付部１１からクエリ言語で記述されたクエリ文書が入力する。そしてデータアクセス部４を通してインデックス記憶部６，文書記憶部５にアクセスし、検索要求に合致する文書集合を取得して、その結果を結果処理部１２を介して出力する。
【００７４】
図２は、図１に示した構造化文書管理システムの一利用形態を示したもので、図２では、ＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）のバックエンドで、図１に示した構成の構造化文書管理システム１００が動作している場合を示している。
【００７５】
複数（ここでは、例えば３つ）のクライアント端末（例えばパーソナルコンピュータ、携帯通信端末など）１０２のそれぞれでＷＷＷブラウザ１０３が動作している。ユーザは、各クライアント端末からＷＷＷサーバ１０１にアクセスすることにより、構造化文書管理システム１００にアクセスすることができる。ＷＷＷブラウザ１０３とＷＷＷサーバ１０１とは、ＨＴＴＰ（Ｈｙｐｅｒ  ＴｅｘｔＴｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）で通信している。また、ＷＷＷサーバ１０１と構造化文書管理システム１００とは、ＣＧＩ（Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ）またはＣＯＭ（Ｃｏｍｐｏｎｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ）などで通信している。
【００７６】
ユーザからの文書格納、文書取得、文書検索などの要求は、ＷＷＷブラウザ１０３から送信されて、ＷＷＷサーバ１０１を通して構造化文書管理システム１００にて受け付けられ、処理された結果は、ＷＷＷサーバ１０１を通して要求元のＷＷＷブラウザ１０３へ返信される。
【００７７】
以下、図１の構造化文書管理システムの（１）格納機能、（２）検索機能について詳細に説明する。そして、（３）適用例では、概念検索を用いた特許調査の場合を例にとり説明する。
【００７８】
格納機能
図１の構造化文書管理システムにおける格納系のコマンドには以下のものがある。
【００７９】
ｉｎｓｅｒｔＸＭＬ（パス、Ｎ番目、ＸＭＬ）：文書格納
ａｐｐｅｎｄＸＭＬ（パス、ＸＭＬ）        ：文書格納
ｇｅｔＸＭＬ（パス）                      ：文書取得
ｒｅｍｏｖｅＸＭＬ（パス）                ：文書削除
ｓｅｔＳｃｈｅｍａ（パス、スキーマ）      ：スキーマ格納
ｇｅｔＳｃｈｅｍａ（パス）      ：スキーマ取得
「ｉｎｓｅｒｔＸＭＬ」は、（  ）内に指定した構造化文書パス以下のＮ番目に文書を挿入するコマンド（以下、簡単に挿入コマンドと呼ぶ）である。
【００８０】
「ａｐｐｅｎｄＸＭＬ」は、（  ）内に指定した構造化文書パス以下の最後に文書を挿入するコマンド（以下、簡単に追加コマンドと呼ぶ）である。
【００８１】
「ｇｅｔＸＭＬ」は、（  ）内に指定した構造化文書パス以下の文書を取り出すコマンド（以下、簡単に取得コマンドと呼ぶ）である。
【００８２】
「ｒｅｍｏｖｅＸＭＬ」は、（  ）内に指定した構造化文書パス以下の文書（スキーマ文書以外の文書で、主に、コンテンツ文書）を削除するコマンド（以下、簡単に削除コマンドと呼ぶ）である。
【００８３】
「ｓｅｔＳｃｈｅｍａ」は、（  ）内に指定した構造化文書パスにスキーマを設定するコマンド（以下、簡単にスキーマ格納コマンドと呼ぶ）である。
【００８４】
「ｇｅｔＳｃｈｅｍａ」は、（  ）内に指定した構造化文書パスに設定されているスキーマを取り出すコマンド（以下、簡単にスキーマ取得コマンドと呼ぶ）である。
【００８５】
上記コマンドのうち、挿入コマンド、追加コマンド、スキーマ格納コマンドについての処理はアクセス要求処理部２の文書格納部２１で実行され、取得コマンド、スキーマ取得コマンドについての処理は文書取得部２２で実行され、削除コマンドについての処理は文書削除部２３で実行される。
【００８６】
図５を参照して、構造化文書データベースの初期状態（図５（ａ）参照）において、追加コマンドを実行する場合について説明する。
【００８７】
図５（ａ）に示すように、「＃０」ノードと「＃１」ノードが「ｒｏｏｔ」アークで接続されている初期状態に対して、
「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」
を実行した結果、図５（ｂ）に示すように、「＃２」ノードと「特許ＤＢ」アークが作成される。
【００８８】
図５（ｂ）に示した状態の構造化文書データベースに対して、取得コマンドを実行する場合について説明する。
【００８９】
例えば、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”）」を実行すると、図５（ｂ）の「ｒｏｏｔ」アークが示す「＃０」ノード以下の文書オブジェクトツリーが取り出され、それをＸＭＬの文字列表現に変換する。その結果、図６に示すように、「＜ｒｏｏｔ＞＜特許ＤＢ／＞＜／ｒｏｏｔ＞」なる文字列が取り出される。取得コマンドの処理は、アクセス要求処理部２の文書取得部２２にて実行される。
【００９０】
次に、図５（ｂ）に示した状態の構造化文書データベースに対して、図３に示すようなコンテンツ文書（ＸＭＬ文書）としての「特許」情報を格納するための追加コマンドを実行する場合について説明する。すなわち、この場合、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」を実行する。このコマンド中「“＜特許＞…＜／特許＞”」が、図３に示した「特許」情報に対応する。
【００９１】
上記追加コマンドの処理が実行されると、図７に示すように、「＃２」ノード以下に「＃４２」ノードをトップとする文書オブジェクトツリー（図４に対応）が追加される。
【００９２】
図５（ｂ）に示した状態の構造化文書データベースに対して、次に示すような追加コマンドを３回繰り返して実行したとする。
【００９３】
「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」
上記コマンド中、「＜特許＞…＜／特許＞」は、図３に示した文書構造のコンテンツ文書に対応する。
【００９４】
すると、図８に示すように、「＃２」ノード以下に「＃４２」ノード、「＃５２」ノード、「＃６２」ノードをトップとする文書オブジェクトツリーが追加される。
【００９５】
次に、図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合について説明する。この場合、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」を実行する。すると、「特許ＤＢ」アークが示す「＃２」ノード以下の文書オブジェクトツリーが取り出され、それをＸＭＬの文字列表現（ＸＭＬ文書）に変換する。その結果、図１１に示すように、「＜特許ＤＢ＞＜特許＞…＜／特許＞＜特許＞…＜／特許＞＜特許＞…＜／特許＞＜／特許ＤＢ＞」なる文字列が取り出される。
【００９６】
構造化文書データベースでは、上記の「特許」情報などのコンテンツ文書（ＸＭＬ文書）の文書構造を定義したデータ、すなわち、スキーマも管理対象とする。
【００９７】
図１２は、ＸＭＬ文書の文書構造を定義するスキーマの一例を示したものである。ここでは、ＸＭＬの文書構造定義言語の一つであるＸＤＲ（ＸＭＬ−Ｄａｔａ  Ｒｅｄｕｃｅｄ）を取り上げる。もちろん、ＸＭＬ−Ｓｃｈｅｍａなど他の文書構造定義言語を用いてもかまわない。
【００９８】
図１２に示したスキーマは、図３に示した「特許」情報の文書構造をＸＤＲで定義したものである。図１２からも容易に分かるとおり、スキーマもＸＭＬ形式の構造化文書である。「Ｓｃｈｅｍａ」タグから始まる構成要素から始まり、その子要素として、「ＥｌｅｍｅｎｔＴｙｐｅ」タグから始まる要素集合が存在する。
【００９９】
図１２に示したスキーマにおいて、例えば、最初の「ＥｌｅｍｅｎｔＴｙｐｅ」タグから始まる子要素は以下の情報を意味している。
【０１００】
・「特許」タグを持つ要素の文書構造定義（「ＥｌｅｍｅｎｔＴｙｐｅ  ｎａｍｅ＝”特許”」）である。
【０１０１】
・子要素は要素だけ（「ｃｏｎｔｅｎｔ＝”ｅｌｔＯｎｌｙ”」）である。
【０１０２】
・「タイトル」、「出願日」、「要約」タグから始まる子要素から構成される（「ｅｌｅｍｅｎｔ  ｔｙｐｅ＝”タイトル”、…」）。さらに、その順番は一意に決まっている（「ｏｒｄｅｒ＝”ｓｅｑ”」）。
【０１０３】
・上記「特許」タグから始まる要素の文書構造定義の他に、「タイトル」「出願者」「要約」「年」「月」「日」「出願日」の文書構造定義を記述している。すなわち、「出願日」を除く、「タイトル」「出願者」「要約」「年」「月」「日」タグから始まる構成要素の子要素はテキストだけと定義されている（「ｃｏｎｔｅｎｔ＝”ｔｅｘｔＯｎｌｙ”」）。
【０１０４】
・「出願日」タグから始まる構成要素の子要素は、「年」、「月」、「日」の並びである。
【０１０５】
図８に示した状態の構造化文書データベースに対して、図１２に示したスキーマ文書を格納するためのスキーマ格納コマンドを実行する場合について説明する。この場合、「ｓｅｔＳｃｈｅｍａ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”）」を実行する。このコマンド中、「“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”」」が図１２に示したスキーマ文書に対応する。
【０１０６】
上記コマンドの実行により、図１３に示すように、「＃２」ノード以下に「＃ｓｃｈｅｍａ」アークが追加され、その先には、「＃３」ノードをトップノードとする文書オブジェクトツリーが追加される。スキーマ自身がＸＭＬ文書表現になっているため、前述した「特許」情報のようなコンテンツ文書格納のケースと同様にツリー展開可能である。
【０１０７】
図１３において、「＠ｎａｍｅ」など「＠」で始まるアークは属性に対応する。タグ名「＃ｓｃｈｅｍａ」も「＃」、「＠」で始まるためＸＭＬ規格においては標準的なタグ名として利用することはできない。
【０１０８】
「＃２」ノード下に図１２に示したスキーマ文書が格納されたことにより、以後、「＃２」ノード以下にこれから格納される文書の文書構造は、図１２に示したスキーマ文書により定義された文書構造に適合することが要求される。すなわち、「＃２」ノード以下に図１２に示したスキーマが設定されることになる。
【０１０９】
「＃２」ノード以下に図１２に示したスキーマが設定されると、図１４に示すように、「＃２」ノードの文書オブジェクトのファイルには、「＃２」ノード以下の文書オブジェクトツリーには、当該スキーマが存在する旨の属性値がセットされる。
【０１１０】
「＃２」ノード以下に図１２に示したスキーマが設定された後に、このスキーマで定義された文書構造に一致する図３に示したような「特許」情報を、図１４に示したように、文書オブジェクトツリーとして構造化文書データベースに格納したとき、この文書の文書構造には図１２に示したスキーマが存在する旨の属性値が、当該文書オブジェクトツリーを構成する各文書オブジェクトにセットされる。例えば、当該文書オブジェクトツリーを構成する各文書オブジェクトのファイルに対して、スキーマが存在している旨の属性値（例えば、「スキーマ適合有無」）に「１」がセットされる。図１４では、スキーマに適合している各文書オブジェクト（ノード）は２重丸で示している。２重丸で示した各文書オブジェクトには、その文書オブジェクトに対応した文書構造定義が存在することになる。
【０１１１】
図１５は、各文書オブジェクトのファイルの内容を概念的に示したもので、例えば、オブジェクトＩＤが「＃４２」の文書オブジェクトのファイルには、その文書オブジェクトにリンクされている他の文書オブジェクトに関する情報（例えば、アークや、リンク先の文書オブジェクトへのポインタ値など）とともに、上記属性値が記述されている。なお、当該文書オブジェクトに適用するスキーマが存在しないときは、「スキーマ適合有無」の値は「０」となる。
【０１１２】
図１６、図１７は、図１の構造化文書管理システムで、必要に応じて検索で使用される概念階層を構造化文書で表現した例を示す。図１６、図１７に示す「概念」情報はＸＭＬで記述したコンテンツ文書である。
【０１１３】
図１６に示した「概念」情報の例は、いわゆる特許調査における特許文書の内容を分類するための１つの分類軸として用いる「情報モデル」を概念階層で表現している。「概念」タグで囲まれた「概念」情報は、入れ子構造を持った文書構造をもっている。つまり、図１６の例では、概念「情報モデル」の子供概念として、概念「ドキュメント」、概念「リレーション」、概念「オブジェクト」が存在している。また、概念「ドキュメント」の子供概念として、概念「構造化訴求メント」、概念「非構造化ドキュメント」が存在し、さらに、概念「構造化ドキュメント」の子供概念として、概念「ＸＭＬ」、概念「ＳＧＭＬ」が存在している。
【０１１４】
図１７に示す「概念」情報の記述例は、図１６とは異なる分類軸「情報操作」を概念階層で表現している。図１７の例では、概念「情報操作」の子供概念として、概念「検索」、概念「格納」、概念「加工」、概念「流通」が存在している。
【０１１５】
図１６，図１７に示したような「概念」情報も、前述の「特許」情報と同様にして、構造化文書データベース内に格納することができる。すなわち、例えば、まず、図８に示した状態の構造化文書データベースに対して、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜概念ＤＢ／＞”）」を実行して、図１８に示すように、「＃２０１」ノードと「概念ＤＢ」アークが作成される。この状態において、図１６に示した「概念」情報を格納する場合には、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／概念ＤＢ”，“＜概念名前＞…＜／概念＞”）」を実行する。このコマンド中「“＜概念名前＞…＜／概念＞”」が、図１６に示した「概念」情報に対応する。
【０１１６】
上記追加コマンドの処理が実行されると、図１９に示すように、「＃２０１」ノード以下に「＃２０２」ノードをトップとする文書オブジェクトツリーが追加される。
【０１１７】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。そのため、部分的なＸＭＬ文書をアクセスするには巨大なＸＭＬ文書に対するパスという文書構造に依存しない統一的なアクセス手段を用いることにより、幅広くＸＭＬ文書を検索したり加工したりすることが可能になる。
【０１１８】
また、構造化文書データベース上の一部にスキーマを設定することで、格納しようとする文書の文書構造がそのスキーマにより定義されている文書構造に一致するか否かの妥当性のチェックが自動的に行なえる（後述）。
【０１１９】
（１−１）文書格納処理
次に、図１の構造化文書管理システムの文書格納処理動作について、図２０に示すフローチャートを参照して説明する。
【０１２０】
クライアント端末から構造化文書管理システムに対し、文書格納要求として、挿入コマンド、追加コマンド、スキーマ格納コマンドのうちのいずれかが送信されて、要求受付部１１にて受け付けられたとき、図２０に示した処理動作を行う。
【０１２１】
クライアント端末の所定の表示装置には、構造化文書管理システム１００（の例えば、要求制御部１）から提供された、例えば、図３１に示すようなユーザインターフェイスとしての画面が表示されている。
【０１２２】
図３１に示す画面には、構造化文書管理システム１００への操作項目の一覧（メニュー）が表示されている。操作項目として、「ＸＭＬ登録／削除」、「スキーマ設定」、「ＸＭＬ検索」とがある。
【０１２３】
ユーザが例えば、この画面上で「ＸＭＬ登録／削除」をマウス等のポインティングデバイスなどを用いて選択すると、図３２に示したような文書の格納／削除を行うためのユーザインタフェースとしての画面が表示される。
【０１２４】
図３２において、領域Ｗ１には、文書構造化文書データベースの現在のツリー構造の要素名（タグ名）がユーザが理解可能なように簡略的に表示されている。なお、図３２では、上位階層の要素名のみを表示しているが、末端の要素名まで表示可能である。また、領域Ｗ２は、構造化文書パスの入力領域であり、領域Ｗ１の表示内容に従って、構造化文書パスを入力するようになっている。また、領域Ｗ３は、格納する文書を入力したり、取得した文書を表示するようになっている。
【０１２５】
例えば、構造化文書パスとして「ｒｏｏｔ」を入力する場合には、領域Ｗ１の「ｒｏｏｔ」をマウス等で選択すればよい。すると、図３２に示すように、領域Ｗ２の構造化文書パスの入力領域に「ｕｉｘ：／／ｒｏｏｔ」と表示される。また、新たに、「特許ＤＢ」という要素を追加する場合は、図３２に示すように、領域Ｗ３に、「特許ＤＢ」を入力する。そして、「登録」ボタンＢ１を選択すると、クライアント端末からａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」なる追加コマンドが構造化文書管理システムへ送信される。構造化文書管理システムでは、上記追加コマンドを受け、後述するような処理を実行した結果、例えば、図５（ｂ）に示すように、「＃２」ノードと「特許ＤＢ」アークが作成される。また、領域Ｗ１には、図３３に示すように、「ｒｏｏｔ」の下に「特許ＤＢ」が追加表示される。
【０１２６】
さて、ユーザが図３４に示したような文書の格納／削除画面上の領域Ｗ３に、例えば、文書「＜Ａ＞データ＜／Ａ＞」を入力し（あるいはＣＤ−ＲＯＭ等の所定の記録媒体等から読み込むことにより入力し）、領域Ｗ１の「特許［０］」をマウス等で選択すると、構造化文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」と表示される。そして、「登録」ボタンＢ１を選択すると、クライアント端末からａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ”，“＜特許ＤＢ／＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０１２７】
ここでは、例えば、構造化文書データベースが、図１４に示した状態のときに、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］”，“＜Ａ＞データ＜／Ａ＞”）」なる追加コマンドを受け付けた場合を例にとり説明する。
【０１２８】
要求受付部１１は、上記追加コマンドを受け付けると、上記追加コマンド中の２つのパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」と文書「＜Ａ＞データ＜／Ａ＞」（以下、格納文書と呼ぶ）とを文書格納部２１へ渡す（ステップＳ１）。
【０１２９】
まず、文書格納部２１は、文書パーサ部４６に格納文書を渡す。文書パーサ部４６は、格納文書を読み込んで、構文解析を行い、当該格納文書の文書構造がＸＭＬにて規定された正しい形式であるか否かの整合性の検査を行う（ステップＳ２）。
【０１３０】
この整合性の検査でエラーが見つかれば（ステップＳ３）、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す（ステップＳ４）。
【０１３１】
整合性の検査でエラーが見つからなければ、次に、文書格納部２１は、パスから文書オブジェクトツリー取得部４５へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部４５は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ０）を含む文書オブジェクトツリーを取り出す（ステップＳ５）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ０のオブジェクトＩＤを取得することができるので（ステップＳ６）、その場合は、ステップＳ８へ進む。
【０１３２】
例えば、上記追加コマンドの場合、「＃４２」ノードが文書オブジェクトＯｘ０となるので、そのオブジェクトＩＤとして、「＃４２」を取得するとともに、この「＃４２」ノードを含む文書オブジェクトツリー（例えば、「＃４２」ノードの全ての子孫ノードと「＃４２」ノードと同じ階層にある全ての（兄弟）ノードと、「＃４２」ノードの親ノードである「＃２」ノードとからなる文書オブジェクトツリー）を取得する。
【０１３３】
指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ０が見つからなければ、エラーとなり（ステップＳ６）、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す（ステップＳ７）。
【０１３４】
例えば、構造化文書データベースが、図１８に示した状態のときに、追加コマンドのパラメータとして、構造化文書パスが「ｕｉｘ：／／ｒｏｏｔ／その他」と表されていたとき、これに対応する文書オブジェクトは存在しないので、ステップＳ６でエラーとなり、ステップＳ７へ進む。
【０１３５】
次に、ステップＳ８では、文書オブジェクトＯｘ０にスキーマが存在するか否かを検査する。この検査は、前述したように、各文書オブジェクトのファイルに属性値が記述されているので、この値をチェックすればよい。文書オブジェクトＯｘ０のもつ「スキーマ属性有無」の値が「１」のときは、ステップＳ９へ進む。
【０１３６】
以下、図２０のステップＳ９の処理（合成文書作成部４７の処理）について、図２１に示すフローチャートを参照して詳細に説明する。
【０１３７】
文書格納部２１は、ステップＳ５で取得した文書オブジェクトツリーを合成文書作成部４７へ渡す。
【０１３８】
合成文書作成部４７は、この文書オブジェクトツリーを文書オブジェクトＯｘ０から遡り、「Ｓｃｈｅｍａ」タグを子要素として持つ文書オブジェクトＯｘ１を検索する（ステップＳ２１）。
【０１３９】
例えば、図１４に示した構造化文書データベースでは、文書オブジェクトＯｘ０としての「＃４２」ノードの親ノードである「＃２」ノードから「Ｓｃｈｅｍａ」タグをトップ（先頭）にもつノード（「＃３」ノード）へのリンクが張られているので（「Ｓｃｈｅｍａ」タグを子要素として持つので）、この「＃２」ノードが文書オブジェクトＯｘ１となる。よって、ステップＳ２２をスキップして、ステップＳ２３へ進む。
【０１４０】
この文書オブジェクトＯｘ１から文書オブジェクトＯｘ０、さらに文書オブジェクトＯｘ０からアークを辿って、その下流にある、文書オブジェクトの属性値の値が「１」である全ての子ノードからなる文書オブジェクトツリーＯｔ１を取り出す（ステップＳ２３）。
【０１４１】
例えば、上記追加コマンド中のパラメータの構造化文書パスが「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］」と指定されているとき、文書オブジェクトツリーＯｔ１は、「＃４２」ノード〜「＃４９」ノードから構成されたものとなる（図１４参照）。
【０１４２】
次に、ステップＳ２５へ進む。
【０１４３】
ステップＳ２５では、文書オブジェクトツリーＯｔ１に格納文書の文書オブジェクトツリーを文書オブジェクトＯｘ０の子ノードとして挿入する。その結果得られた新たな文書オブジェクトツリーを文書オブジェクトツリーＯｔ２とする。
【０１４４】
この文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換し、それをテンポラリファイルＡに出力する（ステップＳ２７）。
【０１４５】
例えば、上記追加コマンド中のパラメータの格納文書「＜Ａ＞データ＜／Ａ＞」の文書オブジェクトツリー（この場合は、１つの文書オブジェクト）を「＃４２」ノード〜「＃４９」ノードで構成された文書オブジェクトツリーＯｔ１に「＃４２」ノードの子ノードとして挿入して得られた合成文書の文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換した結果を図２２に示す。この合成文書は、もともとある「特許」情報に「＜Ａ＞データ＜／Ａ＞」というデータを追加したものとなっている。
【０１４６】
図２２に示したＸＭＬ文書、すなわち、合成文書がテンポラリファイルＡに出力され、テンポラリファイルＡに一時格納される。
【０１４７】
一方、スキーマタグ以下の文書オブジェクトツリーＯｔ３をＸＭＬ文書に変換して、それをテンポラリファイルＢに出力する（ステップＳ２８）。すなわち、テンポラリファイルＢには、スキーマ文書が一時格納されることになる。
【０１４８】
例えば、文書オブジェクトツリーＯｔ３である「＃３」ノードをトップノードとする文書オブジェクトツリーをＸＭＬ文書に変換した結果を図２３に示す。図２３に示したＸＭＬ文書がテンポラリファイルＢに出力され、テンポラリファイルＢに一時格納される。
【０１４９】
図２２に示すように、テンポラリファイルＡ（「ｔｍｐ０００．ｘｍｌ」）には、もともとある「特許」情報の要素の他に、格納文書、すなわち、ここでは、例えば、「＜Ａ＞データ＜／Ａ＞」が挿入されている。また、「ｘｍｌｎｓ＝”ｘ−ｓｃｈｅｍａ：ｔｍｐ００１．ｘｍｌ”」という、テンポラリファイルＢ（「ｔｍｐ００１．ｘｍｌ」）へのリンク情報の記述がある。この記述は、「特許」情報に適用されるスキーマが出力されているテンポラリファイルＢを指定している。
【０１５０】
次に、図２０の説明に戻る。
【０１５１】
ステップＳ１０では、文書格納部２１は文書パーサ部４６に、合成文書のテンポラリファイルＡとスキーマのテンポラリファイルＢとを与えて、合成文書の文書構造の妥当性をチェックする。すなわち、文書パーサ部４６は、合成文書のテンポラリファイルＡとスキーマのテンポラリファイルＢとを読み込み、合成文書の文書構造が、スキーマにより定義されている文書構造に一致するか否かをチェックする。
【０１５２】
例えば、図２２に示した合成文書と、図２３に示したスキーマとで妥当性のチェックを行った場合、合成文書には、スキーマにより定義されていない「Ａ」という要素が存在するため、図２３の合成文書は、妥当性のチェックでエラーとなる（ステップＳ１１）。この場合、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す（ステップＳ１２）。
【０１５３】
例えば、クライアント端末の所定の表示装置には、図３５に示すようなメッセージが表示される。
【０１５４】
次に、構造化文書データベースが、図１４に示した状態のときに、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドを受け付けた場合について、図２０を参照して説明する。前述同様にして、文書オブジェクトＯｘ０のオブジェクトＩＤ「＃２」を取得する（ステップＳ５）、この文書オブジェクトには、スキーマが存在するので（ステップＳ８）、ステップＳ９において合成文書を作成する。
【０１５５】
この場合、文書オブジェクトＯｘ０である「＃２」ノード自体から「Ｓｃｈｅｍａ」タグをトップ（先頭）にもつノード（「＃３」ノード）へのリンクが張られているので、この「＃２」ノードが文書オブジェクトＯｘ１となる（図２１のステップＳ２１）。すなわち、文書オブジェクトＯｘ０と文書オブジェクトＯｘ１が同じなので（ステップＳ２２）、ステップＳ２９へ進み、格納文書「＜特許＞…＜／特許＞」の文書オブジェクトツリーをＸＭＬ文書に変換し、テンポラリファイルＡに出力する（ステップＳ２９）。
【０１５６】
例えば、図２４に示すように、テンポラリファイルＡ（「ｔｍｐ０００．ｘｍｌ」）には、格納文書である「特許」情報、すなわち、ここでは、「＜特許＞…＜／特許＞」が出力されている。また、「ｘｍｌｎｓ＝”ｘ−ｓｃｈｅｍａ：ｔｍｐ００１．ｘｍｌ”」という、テンポラリファイルＢ（「ｔｍｐ００１．ｘｍｌ」）へのリンク情報の記述がある。
【０１５７】
次に、ステップＳ２８へ進む。図２５に示すように、テンポラリファイルＢには、「＃３」ノードをトップノードとするスキーマの文書オブジェクトツリーをＸＭＬ文書に変換した結果が出力されている。
【０１５８】
図２０のステップＳ１０で、図２４に示した合成文書と、図２５に示したスキーマとで妥当性のチェックを行ったとき、合成文書の文書構造と、スキーマにより定義されている文書構造とは一致する、この場合、ステップＳ１１からステップＳ１３へ進む。
【０１５９】
ステップＳ１３では、格納文書の文書オブジェクトツリーが、文書オブジェクトＯｘ０下に追加される。すなわち、文書格納部２１により、格納文書の文書オブジェクトツリーを構成する各文書オブジェクト（のファイル）にオブジェクトＩＤが与えられ、文書オブジェクトＯｘ０から格納文書の文書オブジェクトツリーの先頭の文書オブジェクトへリンクが張られる。そして、文書オブジェクトツリー格納部４１により、格納文書の文書オブジェクトツリーを構成する各文書オブジェクト（のファイル）が文書記憶部５に格納される。
【０１６０】
次に、ステップＳ１４へ進み、インデックス記憶部６のインデックスを更新する。
【０１６１】
なお、ステップＳ８で、文書オブジェクトＯｘ０のもつ属性値の値が「０」のときは、上述したスキーマを用いた合成文書の文書構造の妥当性のチェックを行わずに、そのままマステップＳ１３へ進み、格納文書の文書オブジェクトツリーを、文書オブジェクトＯｘ０下に追加し（ステップＳ１３）、それに伴い、インデックス記憶部６のインデックスを更新する（ステップＳ１４）。
【０１６２】
（１−２）文書取得処理
次に、図１の構造化文書管理システムの文書取得処理動作について、図２６に示すフローチャートを参照して説明する。
【０１６３】
クライアント端末から構造化文書管理システムに対し、文書取得要求として、取得コマンド、スキーマ取得コマンドのうちのいずれかが送信されて、要求受付部１１にて受け付けられたとき、図２６に示した処理動作を行う。
【０１６４】
例えば、ユーザが図３６に示したような文書の格納／削除画面上の領域Ｗ１の「特許ＤＢ」をマウス等で選択すると（クリックすると）、構造化文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」と表示されとともに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」なる取得コマンドが構造化文書管理システムへ送信される。
【０１６５】
ここでは、例えば、構造化文書データベースが、図８に示した状態のときに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」なる取得コマンドを受け付けた場合を例にとり説明する。
【０１６６】
要求受付部１１は、上記取得コマンドを受け付けると、上記取得コマンド中のパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」を文書取得部２２へ渡す（ステップＳ３１）。
【０１６７】
文書取得部２２は、パスから文書オブジェクトツリー取得部４５へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部４５は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ５）を取り出す（ステップＳ３２）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ５のオブジェクトＩＤを取得することができるので（ステップＳ３３）、その場合は、ステップＳ３５へ進む。
【０１６８】
例えば、上記取得コマンドの場合、「＃２」ノードが文書オブジェクトＯｘ５となるので、そのオブジェクトＩＤとして、「＃２」を取得するとともに、この「＃２」ノード以下の文書オブジェクトツリーＯｔ５（「＃２」ノード、「＃４２」ノード〜「＃４９」ノード、「＃５２」ノード以下、「＃６２」ノード以下）を取得する（ステップＳ３５）。
【０１６９】
ステップＳ３２において、指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ５が見つからなければ、エラーとなり（ステップＳ３３）、文書取得部２２，結果処理部１２を介して、クライアント端末に「文書取得失敗」の旨のメッセージを返す（ステップＳ３４）。
【０１７０】
ステップＳ３５で取得した文書オブジェクトツリーＯｔ５は、文書文字列取得部４４でＸＭＬ文書に変換される。例えば、上記取得コマンドの場合、取得したＸＭＬ文書は、図１１に示すような３つの「特許」情報のＸＭＬ文書となる。
【０１７１】
文書取得部２２は、結果処理部１２を介して、図１１に示したようなＸＭＬ文書を（例えば、ＸＳＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｓｔｙｌｅ  Ｌａｎｇｕａｇｅ）といった所定のスタイルシートとともに）、クライアント端末へ返す（ステップＳ３７）。
【０１７２】
クライアント端末では、図１１に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図３６に示すように、領域Ｗ２に表示する。
【０１７３】
ＸＳＬを利用すると、ＸＭＬ文書を様々な形に変換することが出来る。違う構文書造のＸＭＬ文書に変換することも出来るし、ＸＭＬ文書からＨＴＭＬページを生成することも出来る。
【０１７４】
（１−３）文書削除処理
次に、図１の構造化文書管理システムの文書削除処理動作について、図２７に示すフローチャートを参照して説明する。
【０１７５】
クライアント端末から構造化文書管理システムに対し、文書削除要求として、削除コマンドが送信されて、要求受付部１１にて受け付けられたとき、図２７に示した処理動作を行う。
【０１７６】
例えば、ユーザが図３６に示したような文書の格納／削除画面上の領域Ｗ１の「特許ＤＢ」をマウス等で選択すると（クリックすると）、構造化文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」と表示され、さらに、「削除」ボタンＢ２を選択すると「ｒｅｍｏｖｅＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”）」なる削除コマンドが構造化文書管理システムへ送信される。
【０１７７】
ここでは、例えば、構造化文書データベースが、図１４に示した状態のときに、「ｒｅｍｏｖｅＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日”）」なる削除コマンドを受け付けた場合を例にとり説明する。
【０１７８】
要求受付部１１は、上記削除コマンドを受け付けると、上記削除コマンド中のパラメータである構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日」を文書削除部２３へ渡す（ステップＳ４１）。
【０１７９】
次に、文書削除部２３は、パスから文書オブジェクトツリー取得部４５へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部４５は、構造化文書パスから文書記憶部５中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード（文書オブジェクトＯｘ０）を含む文書オブジェクトツリーを取り出す（ステップＳ４２）。構造化文書パスの指定が正しければ、文書オブジェクトＯｘ０のオブジェクトＩＤを取得することができるので（ステップＳ４３）、その場合は、ステップＳ４５へ進む。
【０１８０】
例えば、上記削除コマンドの場合、「＃４４」ノードが文書オブジェクトＯｘ０となるので、そのオブジェクトＩＤとして、「＃４４」を取得するとともに、この「＃４４」ノードを含む文書オブジェクトツリー（例えば、「＃４４」ノードの全ての子孫ノードと「＃４４」ノードと同じ階層にある全ての（兄弟）ノードと、「＃４４」ノードの親ノードである「＃４２」ノード、その親ノードである「＃２」ノードとからなる文書オブジェクトツリー）を取得する。
【０１８１】
指定された構造化文書パスからそれに対応する文書オブジェクトＯｘ０が見つからなければ、エラーとなり（ステップＳ４３）、文書格納部２１，結果処理部１２を介して、クライアント端末に「文書削除失敗」の旨のメッセージを返す（ステップＳ４４）。
【０１８２】
次に、ステップＳ４５では、文書オブジェクトＯｘ０にスキーマが存在するか否かを検査する。この検査は、前述したように、各文書オブジェクトのファイルに属性値が記述されているので、この値をチェックすればよい。文書オブジェクトＯｘ０のもつ属性値の値が「１」のときは、ステップＳ４６へ進む。
【０１８３】
以下、図２７のステップＳ４６の処理（合成文書作成部４７の処理（削除コマンド用））について、図２８に示すフローチャートを参照して詳細に説明する。
【０１８４】
なお、図２８において、図２１と同一部分は同一符号を付している。
【０１８５】
文書格納部２１は、ステップＳ４２で取得した文書オブジェクトツリーを合成文書作成部４７へ渡す。
【０１８６】
合成文書作成部４７は、この文書オブジェクトツリーを文書オブジェクトＯｘ０から遡り、「Ｓｃｈｅｍａ」タグを子要素として持つ文書オブジェクトＯｘ１を検索する（ステップＳ２１）。
【０１８７】
例えば、図１４に示した構造化文書データベースでは、文書オブジェクトＯｘ０としての「＃４４」ノードの上流にある「＃２」ノードから「Ｓｃｈｅｍａ」タグをトップ（先頭）にもつノード（「＃３」ノード）へのリンクが張られているので（「Ｓｃｈｅｍａ」タグを子要素として持つので）、この「＃２」ノードが文書オブジェクトＯｘ１となる。
【０１８８】
この文書オブジェクトＯｘ１から文書オブジェクトＯｘ０、さらに文書オブジェクトＯｘ０からアークを辿って、その下流にある、文書オブジェクトの属性値の値が「１」である全ての子ノードからなる文書オブジェクトツリーＯｔ１を取り出す（ステップＳ２３）。
【０１８９】
例えば、上記追加コマンド中のパラメータの構造化文書パスが「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日」と指定されているとき、文書オブジェクトツリーＯｔ１は、「＃４２」ノード〜「＃４９」ノードから構成されたものとなる（図１４参照）。
【０１９０】
次に、ステップＳ２６ヘ進み、文書オブジェクトツリーＯｔ１から文書オブジェクトＯｘ０以下の文書オブジェクトツリーを削除する。その結果得られた新たな文書オブジェクトツリーを文書オブジェクトツリーＯｔ２とする。
【０１９１】
この文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換し、それをテンポラリファイルＡに出力する（ステップＳ２７）。
【０１９２】
例えば、上記削除コマンド中のパラメータの構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］／出願日」が指し示す「＃４４」ノード以下の文書オブジェクトツリーを「＃４２」ノード〜「＃４９」ノードで構成された文書オブジェクトツリーＯｔ１から削除することにより得られた合成文書の文書オブジェクトツリーＯｔ２をＸＭＬ文書に変換した結果を図２９に示す。この合成文書は、もともとある「特許」情報から「＜出願日＞…＜／出願日＞」というデータを削除したものとなっている。
【０１９３】
図２９に示したＸＭＬ文書、すなわち、合成文書がテンポラリファイルＡに出力され、テンポラリファイルＡに一時格納される。
【０１９４】
一方、スキーマタグ以下の文書オブジェクトツリーＯｔ３をＸＭＬ文書に変換して、それをテンポラリファイルＢに出力する（ステップＳ２８）。すなわち、テンポラリファイルＢには、スキーマ文書が一時格納されることになる。
【０１９５】
例えば、文書オブジェクトツリーＯｔ３である「＃３」ノードをトップノードとする文書オブジェクトツリーをＸＭＬ文書に変換した結果を図３０に示す。図３０に示したＸＭＬ文書がテンポラリファイルＢに出力され、テンポラリファイルＢに一時格納される。
【０１９６】
次に、図２７の説明に戻る。
【０１９７】
ステップＳ４７では、文書削除部２１は文書パーサ部４６に、合成文書のテンポラリファイルＡとスキーマのテンポラリファイルＢとを与えて、文書格納処理の場合と同様にして、合成文書の文書構造の妥当性をチェックする。
【０１９８】
例えば、図２９に示した合成文書と、図３０に示したスキーマとで妥当性のチェックを行った場合、合成文書には、スキーマにより定義されている「出願日」という要素が存在しないため、図２９の合成文書は、妥当性のチェックでエラーとなる（ステップＳ４８）。この場合、文書削除部２１，結果処理部１２を介して、クライアント端末に「文書削除失敗」の旨のメッセージを返す（ステップＳ４９）。
【０１９９】
なお、構造化文書データベースが、図１４に示した状態のときに、「ｒｅｍｏｖｅＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］”）」なる削除コマンドを、図２７に従って処理を行うと、図２８のステップＳ２７において、図２４に示したような合成文書がテンポラリファイルＡに出力される。テンポラリファイルＢは、図３０と同様である。
【０２００】
このとき、図２４に示した合成文書と、図３０に示したスキーマとで妥当性のチェックを行った場合、合成文書の文書構造と、スキーマにより定義されている文書構造とは一致するので、ステップＳ４８からステップＳ５０へ進む。
【０２０１】
ステップＳ５０では、文書オブジェクトＯｘ０以下の文書オブジェクトツリーを削除する。すなわち、文書オブジェクトツリー削除部４２により、文書オブジェクトＯｘ０以下の文書オブジェクトツリーを構成する各文書オブジェクト（のファイル）が文書記憶部５から削除される。例えば、「＃２」ノードから「＃４２」ノード以下の文書オブジェクトのファイルが削除される。
【０２０２】
次に、ステップＳ５１へ進み、インデックス記憶部６のインデックスを更新する。また、クライアント端末の図３６に示したような表示画面の領域Ｗ１には、「特許［０］」が表示さなくなる。
【０２０３】
なお、ステップＳ４５で、文書オブジェクトＯｘ０のもつ属性値の値が「０」のときは、上述したスキーマを用いた合成文書の文書構造の妥当性のチェックを行わずに、そのままマステップＳ５０へ進み、文書オブジェクトＯｘ０以下の文書オブジェクトツリーを削除し（ステップＳ５０）、それに伴う、インデックス記憶部６のインデックスを更新する（ステップＳ５１）。
【０２０４】
（１−４）スキーマの設定、スキーマを用いた文書格納
図３１に示した画面上で、ユーザが「Ｓｃｈｅｍａ設定Ｗｉｎ」をマウス等のポインティングデバイスなどを用いて選択すると、図３７に示したようなスキーマの設定を行うためのユーザインタフェースとしての画面が表示される。
【０２０５】
ユーザが、領域Ｗ３に、例えば、図１２に示したような「特許」情報のスキーマを入力し、この入力したスキーマを「特許ＤＢ」以下のノードに設定する場合には、領域Ｗ１から「特許ＤＢ」をマウス等でクリックして選択した後（領域Ｗ２には、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される）、「スキーマ設定」ボタンＢ３を選択する。すると、「ｓｅｔＳｃｈｅｍａ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜Ｓｃｈｅｍａ＞…＜／Ｓｃｈｅｍａ＞”）」なるスキーマ格納コマンドが構造化文書管理システムへ送信される。このコマンドの処理は前述した文書格納処理動作と同様である。
【０２０６】
次に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」の下に「特許」情報を格納しようとするとき、「特許ＤＢ」以下のノードに既に設定されているスキーマを用いて「特許」情報を入力する場合について説明する。
【０２０７】
まず、スキーマを取得する。例えば、図３８に示すような文書の格納／削除を行うための画面の領域Ｗ１から「スキーマ」をマウス等を用いて選択すると、文書パスの入力領域Ｗ２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／＃Ｓｃｈｅｍａ」と表示されとともに、「ｇｅｔＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／Ｓｃｈｅｍａ”）」なるスキーマ取得コマンドが構造化文書管理システムへ送信される。
【０２０８】
このコマンドの処理は、前述した文書取得処理と同様である。構造化文書管理システムから返されるＸＭＬ文書は、図３８の画面の領域Ｗ３に表示される。
【０２０９】
図３８に示すように、領域Ｒ３には、「特許」情報のデータ入力領域が各要素毎に設定されて表示されている。この表示に従って、ユーザは、データを入力すればよい。例えば、「タイトル」、「年」などのデータ入力領域が階層的に配置され、表示されている。ユーザは、このデータ入力領域にデータを入力することで、スキーマにより定義された文書構造の格納文書が容易に作成することができる。
【０２１０】
また、領域Ｗ３に入力した「特許」情報の格納先として、領域Ｗ１で「特許ＤＢ」をマウス等を用いて選択すると、領域Ｗ２に構造化文書パスとして、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される。その後、「登録」ボタンＢ１を選択すると、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０２１１】
この場合、格納文書は、予めスキーマに従って入力されたものなので、図２０のステップＳ１０の妥当性チェックでエラーとなることはない。
【０２１２】
（２）検索機能
図１の構造化文書管理システムにおける検索系のコマンドには以下のものがある。
【０２１３】
ｑｕｅｒｙ（ｑｌ）
「ｑｕｅｒｙ」は、パラメータとして（  ）内のクエリｑｌを実行し、その結果のＸＭＬ文書を取得するコマンド（以下、検索コマンドと呼ぶ）である。
【０２１４】
クエリは、図３９に示すように、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  ＱｕｅｒｙＬａｎｇｕａｇｅ）に似た形式の言語により、検索位置、検索条件、情報抽出部分などを記述した、構造化されたＸＭＬ文書である。クエリ文書も構造化文書管理システムの管理対象である。
【０２１５】
「ｋｆ：ｆｒｏｍ」タグから始まる要素には、検索位置の指定と文書要素の値に変数を対応付ける記述があり、「ｋｆ：ｗｈｅｒｅ」タグのから始める要素には、変数に関する条件づけの記述があり、「ｋｆ：ｓｅｌｅｃｔ」タグから始まる要素には、検索結果の出力形式が記述される。
【０２１６】
検索には、単純検索と概念検索とがある。単純検索とは、クエリ中に指定された検索条件を満たす情報を検索・抽出するものであり、概念検索とは、クエリ中に指定された概念情報を利用して、クエリ中に指定された検索条件を満たす情報を検索・抽出するものである。
【０２１７】
図４０は、単純検索のクエリの例を示したものである。図４０のクエリは、例えば、図１４に示したような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群において、「１９９９年でかつ、「ＰＣ」のような内容の「要約」という要素をもつ文書（「特許」情報）の「タイトル」を列挙せよ」という検索要求を意味している。
【０２１８】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」、「＄ｙ」、「＄ｓ」に、それぞれ「特許」情報の「タイトル」、「年」、「要約」という文書要素の値が代入される。
【０２１９】
「ｋｆ：ｗｈｅｒｅ」タグから始める要素の記述により、変数「＄ｙ」＝「１９９９」という比較がなされる。また、コンポーネント「ＭｙＬｉｋｅ」は変数「＄ｓ」と「ＰＣ」を引数として、「ＰＣ」と類似する値の変数「＄ｓ」を検知するための関数である。
【０２２０】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」が出力値として利用される。
【０２２１】
なお、「ｋｆ：ｓｔａｒ」タグは構造の曖昧表現であり、例えば「＜特許＞＜ｋｆ：ｓｔａｒ＞＜年＞」は「タグ名が「特許」である要素の子孫の要素としていずれかに存在し、タグ名が「年」である要素」を意味する。
【０２２２】
図４１に図４０の単純検索のクエリを用いた検索結果を示す。この検索結果もＸＭＬ文書である。
【０２２３】
図４２は、概念検索のクエリの例を示したものである。図４２のクエリは、例えば図１８，図１９に示すような状態の構造化文書データベースに対し、「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群に対し、「概念ＤＢ」アークが示すノード以下に格納されている「概念」情報を利用して検索するための検索要求である。ここで、概念「周辺装置」の値をもつタグの子要素の値には、概念「ＳＣＳＩ」、「メモリ」、「ＨＤＤ」などがあるものとする。また、図１８には示していないが、各「特許」情報の構成要素には、「キーワード」タグから始める要素も存在するものとする。
【０２２４】
すなわち、図４２のクエリは、「概念「周辺装置」以下の概念のいずれかを「キーワード」という要素の値にもつ文書（「特許」情報）の「タイトル」を列挙せよ」という検索要求を意味している。
【０２２５】
「ｋｆ：ｆｒｏｍ」タグから始まる要素の記述により、変数「＄ｔ」、変数「＄ｋ」に、それぞれ、「特許」情報の「タイトル」、「キーワード」という要素の値が代入される。また、変数「＄ｘ」は「概念」情報として「周辺装置」の値をもつタグの子要素の値（「ＳＣＳＩ」、「メモリ」、「ＨＤＤ」など）が代入される。
【０２２６】
「ｋｆ：ｗｈｅｒｅ」タグから始める要素の記述により、「＄ｋ」＝「周辺装置」もしくは「＄ｋ」＝「＄ｘ」という比較がなされる。
【０２２７】
次に、図１の構造化文書管理システムの文書検索処理動作について、図４３に示すフローチャートを参照して説明する。
【０２２８】
図３１に示した画面上で、ユーザが「ＸＭＬ検索Ｗｉｎ」をマウス等のポインティングデバイスなどを用いて選択すると、図４４に示すような文書検索を行うためのユーザインタフェースとしての画面が表示される。
【０２２９】
図４４の検索画面において、領域Ｗ１には、前述同様、構造化文書データベースの現在のツリー構造の要素名（タグ名）がユーザが理解可能なように簡略的に表示されてている。
【０２３０】
領域Ｗ２は、検索対象の範囲（ツリー構造上の検索範囲）や、検索条件などを入力するための領域である。領域Ｗ３には、検索結果が表示される。
【０２３１】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「文書」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という検索要求の場合には、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、トップノードとして、「特許」を入力する（この場合、領域Ｗ１から「特許」をマウス等で選択することにより入力してもよい）。また、検索条件として、「「タイトル」という要素の値に「文書」という文字列を含む」「「年」という要素の値が「１９９８」以上である」という内容を予め設定されたデータ入力領域に入力すればよい。
【０２３２】
その後、「検索」ボタンＢ２１を選択することにより、例えば、図４５に示すようなクエリが、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。クエリの格納場所は、予め定められており、システム側が自動的に、この追加コマンドのパラメータを設定することとなる。例えば、構造化文書データベースが図１８に示した状態のとき、当該クエリの格納場所を表すパラメータとしての構造化文書パスは、「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」となる。また、追加コマンドのもう一方のパラメータは、当該クエリ文書である。
【０２３３】
要求受付部１１は、上記クエリを受け付けると（ステップＳ１０１）、当該クエリを検索要求処理部３へ渡す。そして、当該クエリ文書を格納するための追加コマンドのパラメータを文書格納部２１へ渡す。この追加コマンドの処理を、前述同様に行って、当該クエリは、文書記憶部５に格納される。
【０２３４】
例えば、図４２に示すようなクエリの場合、構造化文書データベースには、図４６に示すように展開されて、構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」の示す「＃３０１」ノード以下にリンクされる。
【０２３５】
一方、検索要求処理部３では、受け取ったクエリを基に、データアクセス部４を通してインデックス記憶部６，文書記憶部５にアクセスし、検索要求に合致する文書集合などを取得して、クエリの中で要求された情報を抽出して結果処理部１２を介して出力する。
【０２３６】
例えば、上記クエリの場合、まず、「「タイトル」タグに「文書」という文字列を含む」という条件に合致するものを検索することが検索対象を絞り込む上で効率がよい。そこで、図１０に示したようなデータ生起インデックスを用いて、「文書」という文字列にリンクされているノード（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを上流側に１つ遡り、「タイトル」というタグ名にたどり着いたときは、更に上流に辿っていき、「特許」というタグ名にたどり着いたときは、そのノード以下の文書オブジェクトツリーＯｔ１１を抽出する。
【０２３７】
次に、この抽出された複数の文書オブジェクトツリーＯｔ１１の中から、さらに、「年」という要素の値が「１９９８」年以上の文書オブジェクトツリーＯｔ１２を抽出する。
【０２３８】
この文書オブジェクトツリーＯｔ１２が上記クエリの内容に適合する文書となる。さらに上記クエリの要求内容に従えば、各文書オブジェクトツリーＯｔ１２のトップノードへの構造化文書パスを求める（ステップＳ１０２）。
【０２３９】
なお、上記検索処理は、上記した方法に限るものではなく、インデックス情報を用いた様々な効率のよい検索方法が可能である。
【０２４０】
検索要求処理部３は、ステップＳ１０２で得られた結果を統合して、検索結果としてのＸＭＬ文書を作成する（ステップＳ１０３）。
【０２４１】
例えば、検索結果のＸＭＬ文書は、
＜ｏｕｔ＞
＜ｒｅｓｕｌｔ＞
ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［０］
＜／ｒｅｓｕｌｔ＞
＜ｒｅｓｕｌｔ＞
ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ／特許［２］
＜／ｒｅｓｕｌｔ＞
＜／ｏｕｔ＞
となる。
【０２４２】
検索要求処理部３は、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す（ステップＳ１０４）。
【０２４３】
クライアント端末では、図１１に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図４４に示すように、領域Ｗ１２に表示する。
【０２４４】
同様にして、スキーマの検索も行える。
【０２４５】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「ｓｃｈｅｍａ」を先頭タグに持つ文書の中から、「特許」と「要約」というタグ名を持つスキーマを検索せよ」という検索要求の場合には、図４７に示すように、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、トップノードとして、「＃ｓｃｈｅｍａ」を入力する。また、検索条件として、「要素の属性名に「特許」という文字列を含む」「要素の属性名に「要約」という文字列を含む」という内容を予め設定されたデータ入力領域に入力すればよい。
【０２４６】
その後、「検索」ボタンＢ２１を選択することにより、上記検索要求を記述したクエリ（図４８参照）が、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。
【０２４７】
さて、上記クエリの場合、例えば、「「＃ｓｃｈｅｍａ」を先頭タグに持つ」という条件に合致するものを検索する。そこで、図９に示したような要素名称生起インデックスを用いて、「＃ｓｃｈｅｍａ」という要素にリンクされているノードの（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、属性名が「特許」と「要約」いう要素にたどり着いたときは、当該「＃ｓｃｈｅｍａ」を先頭タグにもつ文書オブジェクトツリーＯｔ２１を抽出する。この文書オブジェクトツリーＯｔ２１が上記クエリの内容に適合する文書となる。さらに、図４８に示したクエリの要求内容に従えば、各文書オブジェクトツリーＯｔ２１のトップノードへの構造化文書パスを求める。
【０２４８】
検索要求処理部３は、文書オブジェクトツリーＯｔ２１が複数あれば、それぞれのトップノードへの構造化文書パスをまとめて、検索結果としてのＸＭＬ文書を作成し、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す。
【０２４９】
クライアント端末では、検索結果として受け取ったＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図４４に示すように、領域Ｗ１２に表示する。
【０２５０】
クライアント端末では、検索結果の中の１つのスキーマを選択して、表示させると、例えば、図３８に示すような文書の格納／削除を行うための画面とともに、その領域Ｗ３に、「特許」情報のデータ入力領域が各要素毎に設定されて表示される。
【０２５１】
ユーザは、このデータ入力領域にデータを入力することで、スキーマにより定義された文書構造の格納文書が容易に作成することができる。
【０２５２】
例えば、図３８の領域Ｗ３に入力した「特許」情報の格納先として、領域Ｗ１で「特許ＤＢ」をマウス等を用いて選択すると、領域Ｗ２に構造化文書パスとして、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される。その後、「登録」ボタンＢ１を選択すると、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０２５３】
この場合、格納文書は、予めスキーマに従って入力されたものなので、図２０のステップＳ１０の妥当性チェックでエラーとなることはない。
【０２５４】
同様にして、クエリの検索も行える。クエリを検索して、検索結果として得られた既存のクエリを加工して、再利用することもできる（クエリの再利用）。
【０２５５】
クエリの検索は、前述したような構造化文書の検索と同様にして行われ、その検索範囲は、クエリ群の格納されている構造化データベース上の一部の文書オブジェクトツリーとなる。
【０２５６】
例えば、図１８に示したような状態の構造化文書データベースから、「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリを検索する場合について説明する。そのような検索要求を記述したクエリを図４９に示す。
【０２５７】
図４９に示すクエリは、「「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」の示す「＃３０１」ノード以下に存在するクエリの中から「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリを検索し、その内容（タグ名が「ｑｕｅｒｙ」である要素以下の文書オブジェクトツリーの文書）を列挙せよ」を意味するものである。
【０２５８】
なお、「ｋｆ：ａｓ」タグの内容で変数「＄ｅｌｔ」に、「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリのタグ名が「ｑｕｅｒｙ」である要素以下の文書オブジェクトツリーが代入される。
【０２５９】
このクエリを検索要求処理部３が処理する際には、前述同様にして、例えば、図９に示したような要素名称生起インデックスを用いて、「ｋｆ：ｆｒｏｍ」という要素にリンクされているノードの（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、「特許」というタグ名にたどり着いたときは、さらに、上流側にアークを辿って「ｑｕｅｒｙ」というタグ名に辿りついたとき、当該「ｑｕｅｒｙ」を先頭タグにもつ文書オブジェクトツリーＯｔ３１を抽出する。この文書オブジェクトツリーＯｔ３１が上記クエリの内容に適合する文書となる。
【０２６０】
複数の文書オブジェクトツリーＯｔ３１が検索されたら、それらを統合して、ＸＭＬ文書を作成して、それをスタイルシートとともにクライアント端末へ返す。
【０２６１】
クライアント端末では、検索結果の中の１つのクエリを選択して、表示させると、例えば、図４４に示した検索画面の領域Ｗ１１に、各データ入力領域にデータの入力された状態で、当該クエリに記述された検索要求の内容が表示される。
【０２６２】
ユーザは、この状態から、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「文書」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という当該クエリに記述された検索要求中の「文書」を「ＸＭＬ」に変更して、「検索」ボタンＢ２１を選択すれば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「ＸＭＬ」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という意味のクエリが構造化文書管理システムへ送信される。
【０２６３】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。従って、文書構造が異なる、様々なスキーマを持つ膨大な数の文書の中から検索条件に合致する文書を容易に検索できる。
【０２６４】
また、検索に用いるクエリも構造化文書であるので、構造化文書データベースにログとして格納することにより、過去のクエリを再利用するようなアプリケーションも容易に構築することができる。
【０２６５】
（３）適用例
次に、上記概念検索の特許調査への適用例について説明する。
【０２６６】
図５０は、特許調査における構造化文書データベースの一例であり、「特許」情報の他に、「概念」情報も格納している。
【０２６７】
特許調査において、最も重要となってくる作業は、関連する「特許」情報を収集し、「特許」情報を様々な観点から分析し、特許マップ（図５４参照）を作成することである。特許マップを作成するために、従来、特許マップにおける縦軸、横軸を予め決定し、それに従い、縦軸に並ぶ任意の項目と横軸に並ぶ任意の項目とを検索条件とした検索を逐次行うという方法がとられ、この部分に非常に莫大なコストがかかっていた。しかし、構造化文書管理システムを用いることで、この部分のコストを大幅に減少させることが可能となる。
【０２６８】
なお、ここで、マップとは、縦軸（ｙ軸）に並ぶ任意の項目と横軸（ｘ軸）に並ぶ任意の項目とを検索条件とした検索結果をｘ軸とｙ軸とを分類軸として分類整理するものである。
【０２６９】
構造化文書管理システムで、クライアント端末のユーザが図５４に示すような特許マップを作成しようとする場合、ユーザは、クライアント端末上の表示装置に表示される図５０に示すような構造化文書データベースの現在のツリー構造を参照して、図５１に示すような検索画面上に、分析対象の範囲とする「特許」情報のパスと、分析の軸（例えば、ｘ軸、ｙ軸）となる要素を、それぞれ領域Ｗ２１、Ｗ２２に入力する。分析の軸となる要素は、構造化文書データベース内の「特許」情報の要素、「概念」情報の要素のいずれであってもよい。
【０２７０】
例えば、図５１では、ｘ軸に「機能」、ｙ軸に「技術」という「概念」情報の要素を入力している。
【０２７１】
その後、ユーザは、「実行」ボタンＢ３１を選択すると、クライアント端末から図１の構造化文書管理システムへ、図５２に示したようなクエリが送出される。
【０２７２】
この場合のクエリには、「「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群の中から、「概念ＤＢ」アークが示すノード以下に格納されている、概念「機能」の子要素のいずれかと概念「技術」の子要素のいずれかとを、「キーワード」や「要約」などの要素の値に含む「特許」情報を検索せよ。検索結果として、「機能」の子要素と「技術」の子要素と、それらに対応する「特許」情報の「公開番号」との組を列挙せよ。」という意味の検索要求である。
【０２７３】
概念「機能」には、「検索」「格納」…「分析支援」という子要素があり、概念「技術」には、「実装データベース」「反構造データベース」「自然言語処理」…という子要素があるものとする。
【０２７４】
上記クエリを受けた構造化文書検索システムの検索要求処理部３では、例えば、図１０に示したようなデータ生起インデックスを用いて、概念「機能」の各子要素（文字列）にリンクされているノード（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを上流側に遡り、「特許」というタグにたどり着いたときは、さらに、そのノード以下の文書オブジェクトツリーを下流側に辿って概念「技術」の子要素（文字列）のいずれかにリンクされているタグ名にたどり着いたときは、当該文書オブジェクトツリーと、その「公開番号」タグにリンクされている文字列（要素値）を抽出する。このようにして、抽出された「特許」情報のそれぞれについて、対応の「機能」の子要素と「技術」の子要素と「公開番号」との組を統合して、図５３に示すような検索結果としてのＸＭＬ文書を作成、要求元のクライアント端末へ、所定のスタイルシートとともに返す。
【０２７５】
これらを受け取ったクライアント端末の表示装置には、図５４に示したような表形式の特許マップが表示されることになる。
【０２７６】
このように、所望の概念を「軸」として指定するだけで、構造化文書データベースに蓄積された情報を「軸」として指定された概念に基づき集計・分類して、マップ表示するこたが容易に行える。すなわち、構造化文書データベースに蓄積された情報を、「概念」情報を用いて様々な観点で集計・分類することが容易に行える。
【０２７７】
（本発明の実施形態の説明−構造化文書の編集）
以下、本発明の実施の形態について図面を参照して説明する。
【０２７８】
上記構造化文書データベースに格納されている構造化文書は、書き換えが許可されていないとする。このような場合であっても、ユーザは、個々の利用目的に応じて、クライアント端末１０２を介して上記構造化文書データベースから検索した構造化文書を編集、加工したという要望がある。
【０２７９】
上記構造化文書データベースから検索した構造化文書に付け加えたい情報としては、例えば、個人的な評価、日報における（案件処理の）緊急度、人事データにおける重要人物度、その他、複数の特定のユーザからなるユーザグループ内では共有したいが、それ以外のユーザには秘密にしておきたい情報などがある。
【０２８０】
以下、構造化文書への書き換えが不可能な場合、構造化文書データべースに対しては何ら操作を行わずに、構造化文書への編集（加工）が行え、その編集した結果を含めて、文書の検索を可能にする構造化文書編集機能について説明する。
【０２８１】
図５５は、上記したような機能を実現するためのクライアント端末１０２の構成例を示したものである。
【０２８２】
図５５に示したクライアント端末１０２は、図２に示したように、ＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）のバックエンドで動作する、図１に示した構成の構造化文書管理システム１００に対し、アクセスする場合を示している。また、図５５に示したクライアント端末１０２の各構成部の機能を、ＷＷＷブラウザ１０３にアドインして実現することもできる。
【０２８３】
図５５の場合、クライアント端末１０２とＷＷＷサーバ１０１とは、図２と同様、例えば、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）で通信し、また、ＷＷＷサーバ１０１と構造化文書管理システム１００とは、ＣＧＩ（Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ）またはＣＯＭ（Ｃｏｍｐｏｎｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ）などで通信している場合を示している。
【０２８４】
図５５に示した構成において、クライアント端末１０２は、ユーザタグ登録部２０１、検索要求入力部２０２，検索結果表示処理部２０３，文書編集部２０４，拡張文書検索要求入力部２０５，ユーザタグ記憶部２０６，追加文書抽出部２０７，検索要求分離部２０８，追加文書検索部２０９，追加文書記憶部２１０，文書合成部２１１から構成されている。
【０２８５】
図５５に示した構成のクライアント端末１０２を用いて、ユーザは、まず、個人利用のためのタグ、すなわち、ユーザタグを登録し、このユーザタグで囲まれた新たな構成要素を、構造化文書データベースから読み出された構造化文書に追加することにより、当該構造化文書の編集を行う。その際、ユーザ側から見れば、構造化文書には新たな構成要素が追加して、実際に当該構造化文書自体を編集したことになるが、この編集によっては構造化文書データベースに対し何ら操作を行うことはないので、構造化文書データベースからみれば、単に、格納済みの構造化文書を読み出してクライアント端末１０２に提供しているにすぎない。すなわち、構造化文書データベースに格納されている構造化文書が書き換えられることはない。
【０２８６】
なお、新たな構成要素の（構造化文書における）追加位置は、予め定められた固定位置とし、ここでは、構造化文書の最後の構成要素としてこの新たな構成要素を追加するものとする。なお、新たな構成要素の追加位置を上記したように「最後」とする場合に限らず、先頭、すなわち、最初の構成要素として追加するようにしてもよいし、場合によっては、上から２番目、３番目、…の構成要素として、構造化文書の中間に追加するようにしてもよい。本発明においては、新たな構成要素の追加位置を特に限定するものではないが、好ましくは、本実施形態のように、最後の構成要素として、構造化文書の最後に追加することが望ましい。
【０２８７】
構造化文書に追加された、ユーザタグで囲まれた新たな構成要素を含むＸＭＬ形式の構造化文書を追加文書と呼ぶ。
【０２８８】
上記編集結果を検索にも反映するために、上記新たな構成要素（を含む追加文書）を、その新たな構造化文書が追加される構造化文書に対応付けて記憶しておく。
【０２８９】
検索時には、新たな構成要素に基づく検索条件の指定も可能となる。この場合、ユーザから指定された検索条件などのが記述されたクエリ（拡張クエリ）をそのまま構造化文書管理システム１００に送出することはできないので、当該クエリから新たな構成要素を指定した検索条件などの記述を取り除いてから、構造化文書管理システム１００にクエリを送出する。同時に、新たな構成要素を指定した検索条件を満たす追加文書を検索するための追加文書用のクエリも作成して、この追加文書用クエリを用いて、追加文書の検索を行う。
【０２９０】
そして、構造化文書管理システム１００から送られてきた検索結果としての構造化文書に、追加文書の検索結果として得られた追加文書を合成した後、拡張文書としてユーザに提示する。
【０２９１】
ユーザタグ登録部２０１は、ユーザタグ（タグ名と、その取り得る値（の範囲））をユーザタグ記憶部２０６に登録するためのものである。
【０２９２】
検索要求入力部２０２は、ユーザから入力された検索対象の範囲や、検索要求等に基づき、構造化文書管理システム１００へそのまま送信可能な（通常の）クエリを生成する。
【０２９３】
拡張文書検索要求入力部２０５は、ユーザから入力された検索対象の範囲や、検索要求等に基づき、拡張クエリを生成する。
【０２９４】
検索結果表示処理部２０３は、構造化文書管理システムで上記通常のクエリを実行した結果得られた検索結果や、上記拡張クエリを実行した結果得られた検索結果を、クライアント端末１０２の表示装置に表示するための処理を行う。
【０２９５】
その際、構造化文書管理システムから当該検索結果とともに送られてくるスタイルシートを用いて当該検索結果を表示するようにしてもよいが、この場合に限らず、予め定められたスタイルで、検索結果を表示するようにしてもよい。また、後述するように、検索結果として拡張文書を表示する際には、当該スタイルシートを拡張文書対応に変更して用いるようにしてもよい。
【０２９６】
文書編集部２０４は、ユーザタグ記憶部２０６に登録したユーザタグを用いて新たな構成要素を作成して、それを構造化文書管理システムで上記通常のクエリを実行した結果得られた構造化文書に追加することにより、構造化文書データベースに格納されている構造化文書を編集するためのものである。
【０２９７】
追加文書抽出部２０７は、文書編集部２０４で構造化文書に追加された新たな構成要素を取出し、それに、この新たな構成要素が追加された構造化文書の文書ＩＤを加えて、ＸＭＬ形式の構造化文書である追加文書を作成する。ここで作成された追加文書は、追加文書記憶部２１０に記憶される。
【０２９８】
検索要求分離部２０８は、拡張文書検索要求入力部２０５で生成された拡張クエリからユーザタグを指定した検索条件を取り除いた通常のクエリと、追加文書用のクエリとを生成する。
【０２９９】
追加文書検索部２０９は、追加文書用クエリに基づき、当該クエリに記述された検索条件を満たす追加文書を追加文書記憶部２１０から検索する。
【０３００】
文書合成部２１１は、追加文書用クエリを実行して得られた追加文書と、通常のクエリを実行して得られた構造化文書とを合成して、拡張文書を作成する。
【０３０１】
ここで、構造化文書管理システム１００の文書記憶部５に格納されている構造化文書データベースは、現在、図５６に示すような状態である場合を考える。
【０３０２】
なお、図５６に示した構造化文書データベースの構造化文書の格納状態は、ノードやアークを簡略化し、ノードをオブジェクトＩＤではなく要素名や属性名で表して文書オブジェクトツリーの構造、しいていは、構造化文書データベースの構造を示している。
【０３０３】
図５６において、「ｒｏｏｔ」ノード以下には、「特許ＤＢ」ノードがある。「特許ＤＢ」ノード以下には、図５７に示すような文書構造の複数の「特許」情報が格納されている。
【０３０４】
図５７に示すように、「特許」情報は、「特許」タグから始まる要素をルート(根)とし、その子要素として「文書ＩＤ」「タイトル」、「出願人」、「出願番号」、「要約」タグから始まる要素集合が存在する。文書ＩＤは、構造化文書データベースに格納されている全ての構造化文書のそれぞれを識別するための識別情報であり、各構造化文書を構造化文書データベースに格納する際に、追加される構成要素である。文書ＩＤは、システム１００側で自動的に発番して追加する構成要素であってもよい。
【０３０５】
さて、図５５に示した構成のクライアント端末１０２の処理動作について、図７６〜図７７に示すフローチャートに従って説明する。
【０３０６】
まず、図７６に示すフローチャートに従って、文書編集処理について説明する。
【０３０７】
（ステップＳ２０１）
ユーザタグ登録部２０１は、ユーザが、例えば、個人利用のための情報を、構造化文書データベース上の構造化文書に追加するために用いる新たな構成要素の要素名（ユーザタグ名）と、その要素のとりえる値の（範囲）とを登録するためのものである。
【０３０８】
ユーザタグ登録部２０１からは、クライアント端末１０２の表示装置に、例えば、図５８に示すようなユーザタグ登録画面が表示される。この画面上に、所望の要素名（タグ名）と、その取り得る値（の範囲）とを入力して、「登録」ボタンＢ１０１をマウス等でクリックすることで、ユーザタグの登録が行える。
【０３０９】
図５８では、１人のユーザにつき、３つまでのユーザタグの登録が可能となっている。タグ名の入力領域Ｗ１０１〜Ｗ１０３に所望のタグ名を入力し、そのそれぞれについて、そのとりえる値（の範囲）を入力領域Ｗ１０４〜Ｗ１０６に入力する。例えば、図５８では、「評価」というタグ名と、その取り得る値として、「Ａ」、「Ｂ」、「Ｃ」、「Ｄ」、「Ｅ」が入力され、「処理形態」というタグ名には、その取り得る値として、「公開まで」、「審査請求」、「外国出願」が入力されている。
【０３１０】
なお、各ユーザタグの登録領域には、それぞれ「オプション」ボタンＢ１０２〜Ｂ１０４が設けられているが、これは、各ユーザタグの要素に子要素を設定する場合に用いる。例えば、ユーザタグとして「閲覧日」を登録したとする。この「閲覧日」要素の子要素として、「年」、「月」、「日」を登録したい場合には、この「オプション」ボタンをクリックしてから、これらを登録すればよい。
【０３１１】
さて、図５８に示したユーザタグ登録画面上に、所望のユーザタグと、その取り得る値（の範囲）を入力した後、「登録」ボタンＢ１０１をクリックすると、ユーザタグ記憶部２０６には、当該ユーザの識別情報としてのユーザＩＤに対応付けて、図５９に示したように、ユーザタグが登録される。
【０３１２】
図５９において、ユーザタグ記憶部２０６には、ユーザＩＤに対応付けて、当該ユーザが登録したユーザタグ名と、その取り得る値（の範囲）とが記憶されている。
【０３１３】
（ステップＳ２０２）
図５５の検索要求入力部２０２は、構造化文書管理システム１００に対する、ユーザタグの指定を含まない、通常の検索要求を行うためのクエリを生成するためのものである。
【０３１４】
検索要求入力部２０２からは、クライアント端末１０２の表示装置に、例えば、図６０に示すような検索画面が表示される。
【０３１５】
図６０に示した検索画面上の領域Ｗ１１１には、構造化文書データベースの現在のツリー構造の要素名（タグ名）がユーザが理解可能なように簡略的に表示されてている。
【０３１６】
領域Ｗ１１２〜Ｗ１１６は、検索対象の範囲（ツリー構造上の検索範囲）や、検索条件などを入力するための領域である。
【０３１７】
例えば、「「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」以下に格納されている文書の中から、「出願人」タグに「Ｔ社」という文字列を含む文書を検索せよ」という検索要求の場合には、領域Ｗ１１１から「特許ＤＢ」をマウス等で選択することにより、検索対象の範囲と指定する構造化文書パスの入力領域Ｗ１１２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が入力する。また、検索条件として、「「出願人」という要素の値に「Ｔ社」という文字列を含む」という内容を設定するために、タグ名の入力領域Ｗ１１３に「出願人」、その値の入力領域Ｗ１１４に「Ｔ社」を入力すればよい。例えば、タグ名を入力する際には、その入力領域のリストボックスのボタンをクリックして、リストボックスを表示させ、その中から所望のタグ名を選択するようにしてもよい。この場合、リストボックスには、構造化文書データベースに現在格納されている全ての構造化文書の各構成要素のタグ名が表示される。
【０３１８】
その後、「検索実行」ボタンＢ１１１を選択することにより、例えば、「「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」以下に格納されている文書の中から、「出願人」タグに「Ｔ社」という文字列を含む文書を検索せよ」という内容のクエリが構造化文書管理システム１００へ送信される。このとき、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信されてもよい。
【０３１９】
このようなクエリを受け取った構造化文書管理システム１００からは、当該クエリを実行して、その検索結果をスタイルシートとともに、要求元のクライアント端末１０２へ送り返す。クライアント端末１０２では、検索結果表示処理部２０３で上記検索結果としてのＸＭＬ文書をスタイルシートを用いてＨＴＭＬデータに変換して、クライアント端末１０２の表示装置に表示する。
【０３２０】
なお、検索結果表示処理部２０３で検索結果を表示する際の処理には、構造化文書管理システム１００から当該検索結果とともに送られてきたスタイルシートを必ずしも用いる必要はない。予め定められたスタイルで、検索結果を表示するようにしてもよい。また、後述するように、検索結果として拡張文書を表示する際には、当該スタイルシートを拡張文書対応に変更して用いるようにしてもよい。
【０３２１】
さて、上記クエリを実行した結果として、クライアント端末１０２の表示装置には、図６１に示すような、上記検索条件を満たす構造化文書の文書ＩＤの一覧が表示される。この一覧から、ユーザが所望の文書ＩＤ、例えば「ＤＯＣ１００」を選択することにより、当該文書ＩＤの内容が、例えば、図６２に示したように表示される。
【０３２２】
図６２では、文書ＩＤ「ＤＯＣ１００」の「特許」情報をその各構成要素毎に、その要素名（タグ名）に対応付けて表示している。
【０３２３】
（ステップＳ２０３）
文書編集部２０４は、構造化文書データベースから検索して得られた構造化文書に対し、ユーザタグを用いて編集を行うためのものである。ここでいう編集とは、前述したように、構造化文書にユーザタグにて囲まれた新たな構成要素を追加することである。
【０３２４】
新たな構成要素の（構造化文書における）追加位置は、予め定められた固定位置とし、ここでは、構造化文書の最後の構成要素としてこの新たな構成要素を追加するものとする。
【０３２５】
例えば、図６２に示した検索結果閲覧画面上に表示されている構造化文書に対し、編集を行う場合、当該画面上に設けられている「編集」ボタンＢ１２１をマウス等でクリックすればよい。すると、クライアント端末１０２の表示装置には、文書編集部２０４から、図６３に示すような文書編集画面が提供される。
【０３２６】
図６３に示した文書編集画面には、先の検索結果閲覧画面に表示されていた文書ＩＤ「ＤＯＣ１００」の構造化文書の各構成要素の他に新たな構成要素を追加するための入力領域Ｗ１３１〜Ｗ１３６が表示されている。ここでは、１人のユーザに３つまでのユーザタグの登録が許されているから、最高３つまでの新たな構成要素が追加可能になっている。
【０３２７】
ユーザは、図６３の文書編集画面上で、当該構造化文書に、ユーザタグ名が「評価」の構成要素を追加する場合、まず、入力領域Ｗ１３１に「評価」を入力し、入力領域Ｗ１３２に、その値として、例えば、「Ａ」を入力すればよい。
【０３２８】
この場合も、タグ名を入力するときは、入力領域Ｗ１３１に設けられているリストボックスのボタンをクリックして、図６４（ａ）に示すような、当該ユーザが登録したユーザタグ名を一覧表示したリストボックスを表示させ、その中から所望のタグ名を選択するようにしてもよい。この場合、リストボックスには、ユーザタグ記憶部２０６から当該ユーザのユーザＩＤに対応つけられて記憶されたユーザタグ名が読み出されて表示される。
【０３２９】
同様にして、要素値を入力する際も、入力領域Ｗ１３２に設けられているリストボックスのボタンをクリックして、図６４（ｂ）に示すような、当該ユーザが登録した当該タグ名の要素値を一覧表示したリストボックスを表示させ、その中から所望の要素値を選択するようにしてもよい。この場合、リストボックスには、ユーザタグ記憶部２０６から当該ユーザのユーザＩＤに対応つけられて記憶されたユーザタグ名対応の要素値が読み出されて表示される。
【０３３０】
図６３に示したように、文書編集画面上で、当該構造化文書に、ユーザタグ名が「評価」の構成要素の入力を行った後、「編集完了」ボタンＢ１３１をマウス等でクリックすることにより、当該構造化文書の編集が終了する。
【０３３１】
（ステップＳ２０４）
「編集完了」ボタンＢ１３１がクリックされると、図５５の追加文書抽出部２０７は、文書編集画面上で追加された新たな構成要素から追加文書を抽出する。
【０３３２】
すなわち、追加文書抽出部２０７は、追加された新たな構成要素（例えば、ここでは、＜評価＞Ａ＜／評価＞）を取出し、それに、この新たな構成要素の追加された構造化文書の文書ＩＤ（例えば、ここでは、＜文書ＩＤ＞ＤＯＣ１００＜／文書ＩＤ＞）を加えて、図６５に示したようなＸＭＬ形式の追加文書を作成する。
【０３３３】
（ステップＳ２０５）
図６５に示したような追加文書は、追加文書記憶部２１０に記憶される。
【０３３４】
追加文書記憶部２１０には、各追加文書が、図６６に示すように、各ユーザ毎に追加文書の論理構造に基づくツリー構造状に格納されている。この追加文書記憶部２１０における追加文書を記憶するためのデータ構造は、構造化文書管理システム１００の構造化文書データベースと同様であってもよい。
【０３３５】
なお、本発明では、追加文書を記憶する際のデータ構造は特に限定するものではないので、上記したように、追加文書をＸＭＬ形式の構造化文書として記憶する以外に、例えば、新たな構成要素であるユーザタグ名と、その値とを、当該新たな構成要素の追加される構造化文書の文書ＩＤや、ユーザＩＤとともに、テーブル形式記憶するようにしてもよい。要は、追加文書記憶部２１０では、少なくとも、新たな構成要素を、その所有者であるユーザと、当該新たな構成要素の追加される構造化文書とに対応つけて記憶するようになっていればよい。ただし、検索の効率を考慮すると、本実施形態のように、ＸＭＬ形式の構造化文書として、構造化文書管理システム１００の構造化文書データベースと同様なデータ構造にて記憶することが望ましい。
【０３３６】
例えば、図６６に示すような追加文書記憶部２１０のデータ構造において、ユーザＩＤ「ａｂｃ」のユーザ対応の追加文書の格納領域の構造化文書パスは「ｕｉｘ：／／ｒｏｏｔ／ユーザａｂｃ」となる。図６５に示した追加文書は、図６６では、構造化文書パス「ｕｉｘ：／／ｒｏｏｔ／ユーザａｂｃ／追加文書［２］」と表すことのできる格納領域に格納されている。
【０３３７】
次に、図７７に示すフローチャートに従って、図５５のクライアント端末１０２の拡張文書の検索処理動作について説明する。
【０３３８】
（ステップＳ２１１）
図５５の拡張文書検索要求入力部２０５は、以上のようにして、構造化文書データベースから検索された構造化文書に新たな構成要素を追加した結果である拡張文書の検索を行うためのものである。
【０３３９】
この拡張文書の検索を行うための検索画面は、例えば、検索要求入力部２０２から提供される図６０に示したような検索画面上に設けられた「拡張文書検索」ボタンＢ１１３がマウス等でクリックされたとき、拡張文書検索要求入力部２０５から提供される。
【０３４０】
拡張文書要求入力部２０５からは、クライアント端末１０２の表示装置に、例えば、図６７に示すような拡張文書検索画面が表示される。
【０３４１】
図６７に示す拡張文書検索画面には、図６０に示した検索画面のように、構造化文書データベースに基づく検索対象の範囲（ツリー構造上の検索範囲）や、検索条件などを入力するための領域Ｗ１４２〜Ｗ１４６以外に、ユーザタグを指定した検索条件を入力するため領域Ｗ１４７〜Ｗ１５２が設けられている。
【０３４２】
図６７に示した拡張文書検索画面上の領域Ｗ１４１には、構造化文書データベースの現在のツリー構造の要素名（タグ名）がユーザが理解可能なように簡略的に表示されてている。
【０３４３】
領域Ｗ１４２〜Ｗ１５２は、検索対象の範囲（ツリー構造上の検索範囲）や、検索条件などを入力するための領域である。
【０３４４】
例えば、「「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」以下に格納されている文書の中から、「出願人」タグに「Ｔ社」という文字列を含み、かつ、「評価」タグに「Ａ」という文字列を含む文書を検索せよ」という検索要求の場合には、領域Ｗ１４１から「特許ＤＢ」をマウス等で選択することにより、検索対象の範囲と指定する構造化文書パスの入力領域Ｗ１４２に、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が入力する。
【０３４５】
また、検索条件として、「「出願人」という要素の値に「Ｔ社」という文字列を含む」という内容を設定するために、タグ名の入力領域Ｗ１４３に「出願人」、その値の入力領域Ｗ１４４に「Ｔ社」を入力すればよい。例えば、タグ名を入力する際には、その入力領域のリストボックスのボタンをクリックして、リストボックスを表示させ、その中から所望のタグ名を選択するようにしてもよい。この場合、リストボックスには、構造化文書データベースに現在格納されている全ての構造化文書の各構成要素のタグ名が表示される。
【０３４６】
また、検索条件として、「ユーザタグ名「評価」という要素の値に「Ａ」という文字列を含む」という内容を設定するために、ユーザタグ名の入力領域Ｗ１４７に「評価」、その値の入力領域Ｗ１４８に「Ａ」を入力すればよい。例えば、ユーザタグ名を入力する際には、その入力領域のリストボックスのボタンをクリックして、図６４（ａ）に示すような、当該ユーザが登録したユーザタグ名を一覧表示したリストボックスを表示させ、その中から所望のタグ名を選択するようにしてもよい。この場合、リストボックスには、ユーザタグ記憶部２０６から当該ユーザのユーザＩＤに対応つけられて記憶されたユーザタグ名が読み出されて表示される。
【０３４７】
同様にして、要素値を入力する際も、入力領域Ｗ１４７に設けられているリストボックスのボタンをクリックして、図６４（ｂ）に示すような、当該ユーザが登録した当該タグ名の要素値を一覧表示したリストボックスを表示させ、その中から所望の要素値を選択するようにしてもよい。この場合、リストボックスには、ユーザタグ記憶部２０６から当該ユーザのユーザＩＤに対応つけられて記憶されたユーザタグ名対応の要素値が読み出されて表示される。
【０３４８】
（ステップＳ２１２）
その後、「検索実行」ボタンＢ１４１を選択することにより、例えば、図６８に示すような、「「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」以下に格納されている文書の中から、「出願人」タグに「Ｔ社」という文字列を含み、かつ、「評価」タグに「Ａ」という文字列を含む文書を検索せよ」という内容のユーザタグを指定した検索条件を含むクエリ（ここでは、これを通常のクエリと区別するために拡張クエリと呼ぶ）が生成される。
【０３４９】
なお、拡張クエリは、ユーザタグを指定した検索条件の記述を含み以外は、通常のクエリと同様である。
【０３５０】
（ステップＳ２１３）
図６８に示したクエリには、１０行目と１５行目に、ユーザタグを指定した検索条件が含まれているので、このままでは、構造化文書管理システムへは送ることができない。
【０３５１】
そこで、図５５の検索要求分離部２０８は、拡張文書検索要求入力部２０５で生成された、例えば、図６８に示したような拡張クエリからユーザタグを指定した検索条件を取り除いた通常のクエリと、追加文書用のクエリをとを生成する。
【０３５２】
拡張クエリから通常のクエリを生成するためには、単純に、当該ユーザタグを指定した検索条件の記述を削除すればよい。
【０３５３】
例えば、図６８に示した拡張クエリの記述のうち、１０行目と１５行目を削除すれば、図６９に示したような、構造化文書管理システム１００へ送出するための通常のクエリを生成することができる。
【０３５４】
一方、追加文書用のクエリを生成するために、検索要求分離部２０８は、数種類のクエリのテンプレートを予め記憶しているものとする。
【０３５５】
例えば、図６８に示したクエリは、「「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」以下に格納されている文書の中から、「出願人」タグに「Ｔ社」という文字列を含み、かつ、「評価」タグに「Ａ」という文字列を含む文書を検索せよ」という内容のものであったが、クエリは、一般的に、検索対象の範囲（上記クエリの場合、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」）と、構造化文書の構成要素（上記クエリの場合、「出願人」と「評価」）とその値（上記クエリの場合、「Ｔ社」と「Ａ」）とを指定した少なくとも１つの検索条件（上記クエリの場合、２つの検索条件がある）の記述から構成されている。
【０３５６】
そこで、図７０に示すような、追加文書用クエリのテンプレートを予め作成しておく。図７０に示した追加用文書用クエリのテンプレートは、クエリの記述のうち検索対象の範囲を記述する部分（ｔ１）と、検索条件としての構成要素を記述する部分（ｔ２，ｔ３）、構成要素の値を記述する部分（ｔ４，ｔ５）に、拡張クエリを介してユーザにより指定された検索対象の範囲と、検索条件としての構成要素とその値とを代入すれば、即、クエリとして実際に実行可能となるものである。
【０３５７】
図７０に示した追加文書用クエリのテンプレートは、検索条件が２つある場合のテンプレートであるが、検索条件の数に応じて複数のテンプレートを予め用意するようにしてもよい。
【０３５８】
例えば、図６８に示した拡張クエリの場合、ユーザタグを指定した検索条件は１つのみであるので、検索要求分離部２０８は図７１に示すような検索条件が１つの追加文書用クエリのテンプレートを用いる。
【０３５９】
図７１のテンプレート中、検索対象の範囲を記述する部分ｔ１には、検索要求を行ったユーザ（例えばユーザＩＤが「ａｂｃ」であるユーザ）対応に予め定められた追加文書記憶部２１０の追加文書の格納場所を指定するための「「ｕｉｘ：／／ｒｏｏｔ／ユーザａｂｃ」が代入される。また、検索条件としての構成要素を記述する部分ｔ２には、図６８の拡張クエリ中にあるユーザタグのタグ名、すなわち、「評価」が代入される。さらに、当該構成要素の値を記述する部分ｔ４には、図６８の拡張クエリ中にあるユーザタグ「評価」に対し指定された値「Ａ」が代入される。
【０３６０】
その結果、図７２に示すような追加文書用クエリが生成される。
【０３６１】
図７２に示した追加文書用クエリは、「「ｕｉｘ：／／ｒｏｏｔ／ユーザａｂｃ」以下に格納されている追加文書の中から、「評価」タグに「Ａ」という文字列を含む文書を検索せよ」という内容のものである。
【０３６２】
（ステップＳ２１４）
例えば、図６８に示したような拡張クエリから生成された図６９に示したような通常のクエリは、構造化文書管理システムへ送信され、当該クエリに基づき、図４３に示したようにして、構造化文書データベースに対し検索が実行される。
【０３６３】
（ステップＳ２１５）
一方、図６８に示したような拡張クエリから生成された図７２に示したような追加文書用クエリは、図５５の追加文書検索部２０９へ渡される。
【０３６４】
図５５の追加文書検索部２０９は、受け取った図７２に示したような追加文書用クエリに基づき、当該クエリに記述された検索条件を満たす追加文書を追加文書記憶部２１０から検索する。
【０３６５】
追加文書検索部２０９では、追加文書を図６６に示したようなデータ構造にて格納している。そこで、追加文書検索部２０９は、追加文書用クエリで、検索対象の範囲として指定された構造化文書パス（例えば、図７２のクエリの場合「ｕｉｘ：／／ｒｏｏｔ／ユーザａｂｃ」）で表される論理的な格納領域に格納されている追加文書の中から、「評価」タグに「Ａ」という文字列を含む追加文書を検索する。
【０３６６】
（ステップＳ２１６、Ｓ２１７）
さて、図５５の文書合成部２１１では、構造化文書管理システム１００で、例えば、図６９に示したような通常のクエリを実行して得られた検索結果を受け取るとともに、追加文書検索部２０９で、例えば図７２に示したような追加文書用クエリを実行して得られた検索結果を受け取る。
【０３６７】
例えば、図７２に示したような追加文書用クエリを実行して得られた検索結果として、図６５に示した追加文書が得られ、図６９に示したような通常のクエリを実行して得られた検索結果として、図５７に示したような構造化文書が得られたとする。
【０３６８】
（ステップＳ２１８〜ステップＳ２１９）
文書合成部２１１は、当該追加文書と、当該構造化文書の構成要素として含まれている「文書ＩＤ」を取出す。この場合、両者の「文書ＩＤ」の値が同じ「ＤＯＣ１００」であるので、図５７の構造化文書の最後の構成要素として、図６５の追加文書にあるユーザタグ「評価」の構成要素「＜評価＞ａ＜／評価＞」を追加・合成し、図７３に示すようなＸＭＬ文書である拡張文書を作成する。
【０３６９】
なお、拡張文書を作成する際の、新たな構成要素の（構造化文書における）追加位置は、編集時の場合と同様で、予め定められた固定位置とし、ここでは、構造化文書の最後の構成要素としてこの新たな構成要素を追加するものとする。なお、新たな構成要素の追加位置を上記したように「最後」とする場合に限らず、先頭、すなわち、最初の構成要素として追加するようにしてもよいし、場合によっては、上から２番目、３番目、…の構成要素として、構造化文書の中間に追加するようにしてもよい。本発明においては、新たな構成要素の追加位置を特に限定するものではないが、好ましくは、本実施形態のように、最後の構成要素として、構造化文書の最後に追加することが望ましい。
【０３７０】
文書ＩＤ「ＤＯＣ１０８」の構造化文書にも、それに対応の追加文書が検索されたとすると、上記同様にして、拡張文書を作成する。
【０３７１】
このようようにして作成された拡張文書群が、例えば図６８に示したような拡張クエリの実行結果である検索結果として、検索結果表示処理部２０３へ渡される。
【０３７２】
（ステップＳ２２０）
検索結果表示処理部２０３では、まず、拡張文書の文書ＩＤの一覧を、例えば、図７４に示すような検索結果一覧画面上に表示する。この検索結果一覧画面には、拡張文書の文書ＩＤとして、例えば、「ＤＯＣ１００」と「ＤＯＣ１０８」が表示されている。この中から、ユーザが、例えば、「ＤＯＣ１００」をマウス等でクリックして選択することにより、当該文書ＩＤの拡張文書の内容が図７５に示したように表示される。
【０３７３】
図７５に示した検索結果閲覧画面には、文書ＩＤ「ＤＯＣ１００」の「特許」情報の拡張文書の内容が、その各構成要素毎に、その要素名（タグ名）に対応付けて表示している。この場合、ユーザタグ「評価」の構成要素も表示されている。すなわち、文書編集部２０４での編集結果が反映されて表示されている。
【０３７４】
以上の説明は、クライアント端末１０２が上記全ての構造化文書編集機能をもつ場合であるが、この場合に限らず、例えば、図７８に示すように、クライアント端末１０２，構造化文書管理システム１００と互いに通信可能なように所定のネットワークに接続された構造化文書編集装置３０１を設け、この構造化文書編集装置３０１に、図５５のクライアント端末１０２の持つ機能の一部を持たせるようにしてもよい。
【０３７５】
この場合のクライアント端末１０２と、構造化文書編集装置３１０の構成を図７９に示す。なお、図５５と同一部分には同一符号を付し、異なる部分について説明する。すなわち、クライアント端末１０２は、ユーザタグ登録部２０１、検索要求入力部２０２，検索結果表示処理部２０３，文書編集部２０４，拡張文書検索要求入力部２０５を有し、構造化文書編集装置３０１は、記憶部２０６，追加文書抽出部２０７，検索要求分離部２０８，追加文書検索部２０９，追加宇文書記憶部２１０，文書合成部２１１を有している。
【０３７６】
各クライアント端末１０２には、データの入力や表示のための機能部だけを持たせ、構造化文書編集装置３０１には、複数のユーザで共有可能な機能部を持たせ、各クライアント端末１０２から送られてきたクエリ（通常のクエリ、拡張クエリ）に対する処理やユーザタグなどの処理をしたり、構造化文書管理システムからの検索結果を処理したり等する。
【０３７７】
このような構成により、クライアント端末１０２のユーザタグ登録部２０１，検索要求入力部２０２，文書編集部２０４，拡張文書検索要求入力部２０５を用いて、ユーザタグの登録や、検索要求を行う際には、必ず、構造化文書編集装置３０１を経由するようになっている。
【０３７８】
図５５に示した構成では、ユーザタグ記憶部２０６や、追加文書記憶部２１０には、１人のユーザのみのユーザタグや、追加文書が格納されていればよかった。しかし、図７９に示した構造化文書編集装置３０１は、複数のユーザで共有されるため、ユーザタグ記憶部２０６や、追加文書記憶部２１０には、必ず、複数のユーザのユーザタグや追加文書が格納されている。また、クライアント端末１０２からの各種コマンドメッセージなどから各ユーザを識別するためのユーザＩＤを取り出してから、これらユーザタグ記憶部２０６、追加文書記憶部２１０にアクセスする必要がある。
【０３７９】
その他、構造化文書編集装置３０１の持つ各機能部の処理動作は、前述同様である。
【０３８０】
以上説明したように、上記実施形態によれば、構造化文書管理システム１００およびＷＷＷサーバ１０１の構成は一切変更することなく、しかも、構造化文書データベースに対しては何ら操作を行う必要なく、書き換えが許可されていない構造化文書データべース上の構造化文書への編集（加工）と、その編集した結果を含めた構造化文書の検索が容易に行える。
【０３８１】
また、構造化文書データベースに対しては何ら操作を行っていないにもかかわらず、ユーザからは、構造化文書データベースに格納されていた構造化文書を直接加工したかのごとく、編集した内容のまま、構造化文書の検索、表示が可能となる。
【０３８２】
単なるメモを構造化文書に付加するのとは異なり、構造化文書に新たな構成要素を追加するという形態で構造化文書の編集が行えるので、個人的な利用目的で利用する各種情報（例えば、評価、日報における（案件処理の）緊急度、人事データにおける重要人物度など）や、複数の特定のユーザからなるユーザグループ内では共有したいが、それ以外のユーザには秘密にしておきたい情報などをユーザタグを用いて書き込むことにより、一般公開されている情報（構造化文書データベースに格納されている構造化文書）を用いて限定された範囲内のユーザにのみ（個人的な利用を含む）公開可能な情報（拡張文書）を作成することが容易に行える。
【０３８３】
また、ユーザタグを用いて、１つの構造化文書内で、一般公開可能な情報と限定された範囲内のユーザのみに公開可能な情報とを混在させることもできる。
【０３８４】
なお、上記実施形態では、構造化文書データベースに格納されている構造化文書には、全て、文書ＩＤが与えられていることを前提に、この文書ＩＤを用いて、追加文書をその追加先の構造化文書に対応付けるようになっているが、この場合に限らず、ポインタを用いて対応付けることも可能である。
【０３８５】
この場合は、各構造化文書が文書ＩＤを持つ必要がない（すなわち、各構造化文書には「文書ＩＤ」タグが存在しない）。例えば、（新たな構成要素を追加する編集操作が行われた）各構造化文書毎に、当該構造化文書の編集操作を行ったユーザＩＤ対応の２種類のポインタを登録したテーブルを持たせておく。このテーブルは、例えば、追加文書記憶部２１０に格納されていてもよい。一方のポインタ値として、例えば、当該構造化文書の構造化文書パスを格納し、他方のポインタ値として、追加文書記憶部２１０に記憶されている追加文書の格納領域へのポインタ値を格納すればよい。
【０３８６】
なお、本発明の実施の形態に記載した本発明の手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピーディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、半導体メモリなどの記録媒体に格納して頒布することもできる。
【０３８７】
なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。さらに、上記実施形態には種々の段階の発明は含まれており、開示される複数の構成用件における適宜な組み合わせにより、種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題（の少なくとも１つ）が解決でき、発明の効果の欄で述べられている効果（のなくとも１つ）が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【０３８８】
【発明の効果】
以上説明したように、本発明によれば、構造化文書を提供する側（例えば、構造化文書管理システムおよびＷＷＷサーバ）の構成は一切変更することなく、しかも、構造化文書データベースに対しては何ら操作を行う必要なく、書き換えが許可されていない構造化文書データべース上の構造化文書への編集（加工）と、その編集した結果を含めた構造化文書の検索が容易に行える。
【図面の簡単な説明】
【図１】本発明の実施形態に係る構造化文書管理システムの構成例を示した図。
【図２】図１に示した構造化文書管理システムの一利用形態を示したもので、ＷＷＷのバックエンドで、構造化文書管理システムが動作している場合を示した図。
【図３】ＸＭＬで記述された構造化文書の一例を示した図。
【図４】図３の構造化文書の文書構造を模式的に示した図。
【図５】追加コマンドの機能を説明するための図で、構造化文書データベースの初期状態に追加コマンドを実行した場合について示している。
【図６】図５（ｂ）に示した状態の構造化文書データベースに対し、取得コマンドを実行した場合の処理結果を示した図。
【図７】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して１つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図８】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して３つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図９】要素名生起インデックスの格納例を示した図。
【図１０】データ生起インデックスの格納例を示した図。
【図１１】図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合の実行結果を示した図。
【図１２】ＸＭＬ文書の文書構造を定義するスキーマの一例を示した図。
【図１３】図８に示した状態の構造化文書データベースに、スキーマ格納コマンドを実行して、図１２に示したスキーマを追加格納（設定）した場合を示した図。
【図１４】スキーマが設定されて、スキーマが存在している旨の属性値のセットされた文書オブジェクトツリーを示した図。
【図１５】各オブジェクトファイルに、スキーマが存在している旨の属性値が格納されている様子を概念的に示した図。
【図１６】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１７】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１８】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図１９】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図２０】図１の構造化文書管理システムの文書格納処理動作について説明するためのフローチャート。
【図２１】図２０のステップＳ９の処理（合成文書作成部の処理）について説明するためのフローチャート
【図２２】追加コマンド中のパラメータの格納文書の文書オブジェクトツリーを構造化文書データベースから取得した文書オブジェクトツリーに挿入して得られた合成文書の文書オブジェクトツリーをＸＭＬ文書に変換した結果であって、テンポラリファイルＡに格納される合成文書の一例を示した図。
【図２３】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図２４】テンポラリファイルＡに格納される合成文書の他の例を示した図。
【図２５】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図２６】図１の構造化文書管理システムの文書取得処理動作について説明するためのフローチャート。
【図２７】図１の構造化文書管理システムの文書削除処理動作について説明するためのフローチャート。
【図２８】図２７のステップＳ４６の処理（合成文書作成部の処理（削除コマンド用））について説明するためのフローチャート。
【図２９】テンポラリファイルＡに格納される合成文書のさらに他の例であって、削除コマンドの実行時に作成される合成文書の一例を示した図。
【図３０】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図３１】ユーザインタフェースとしての画面の表示例を示した図。
【図３２】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３３】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３４】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３５】妥当性のチェックでエラーとなっときにクライアント端末へ返すメッセージの表示例を表示例を示した図。
【図３６】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示したもので、文書取得動作を説明するための図。
【図３７】スキーマの設定を行うためのユーザインタフェースとしての画面の表示例を示したもので、スキーマの設定動作を説明するための図。
【図３８】スキーマの取得するためのユーザインタフェースとしての画面の表示例を示したもので、取得されたスキーマの表示例を示している。
【図３９】クエリ（ＸＭＬ文書）の一例を示した図。
【図４０】単純検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図４１】図４０の単純検索のクエリを用いた検索結果（ＸＭＬ文書）を示した図。
【図４２】概念検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図４３】図１の構造化文書管理システムの文書検索処理動作について説明するためのフローチャート。
【図４４】文書検索を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図４５】図４４に示した画面上から入力された情報に基づき作成されるクエリを示した図。
【図４６】図４２に示したクエリの構造化文書データベース内における格納例を示した図。
【図４７】文書検索を行うためのユーザインタフェースとしての画面の表示例であって、スキーマの検索処理動作を説明するための図。
【図４８】スキーマ検索のクエリの一例を示した図。
【図４９】クエリを検索するためのクエリの一例を示した図。
【図５０】特許調査における構造化文書データベースの一例を示した図。
【図５１】概念検索のための入力画面の表示例を示した図。
【図５２】図５１に示した入力画面上の入力情報に対応するクエリを示した図。
【図５３】図５２に示したクエリに対応する検索結果としてのＸＭＬ文書を示した図。
【図５４】特許マップの一例を示した図。
【図５５】第２の実施形態に係るクライアント端末の構成例であって、構造化文書データべースに対しては何ら操作を行わずに、構造化文書への編集（加工）が行え、その編集した結果を含めて、文書の検索を可能にする構造化文書編集機能を有したクライアント端末の構成例を示した図。
【図５６】構造化文書データベースの一例を示した図。
【図５７】構造化文書の一例であって、「特許」情報を示した図。
【図５８】ユーザタグ登録画面の表示例を示した図。
【図５９】ユーザタグ記憶部のユーザタグの記憶例を示した図。
【図６０】検索画面の表示例を示した図。
【図６１】検索結果一覧画面の表示例を示した図。
【図６２】検索結果閲覧画面の表示例を示した図。
【図６３】文書編集画面の表示例を示した図。
【図６４】検索条件として、ユーザタグや、その値を指定する際に表示されるリストボックスの表示例を示した図。
【図６５】追加文書の一例を示した図。
【図６６】追加文書記憶部の追加文書を格納するためのデータ構造を示した図。
【図６７】拡張文書検索画面の表示例を示した図。
【図６８】拡張クエリの一例を示した図。
【図６９】図６８の拡張クエリから生成された通常のクエリを示した図。
【図７０】検索要求分離部が記憶する追加文書用クエリのテンプレートの一例を示した図。
【図７１】検索要求分離部が記憶する追加文書用クエリのテンプレートの他の例を示した図。
【図７２】図６８の拡張クエリから生成された追加文書用クエリを示した図。
【図７３】拡張文書の一例を示した図。
【図７４】検索結果一覧画面の表示例を示した図。
【図７５】検索結果閲覧画面の表示例であって、拡張文書の表示例を示した図。
【図７６】文書編集処理動作を説明するためのフローチャート。
【図７７】拡張文書の検索処理動作を説明するためのフローチャート。
【図７８】構造化文書編集装置の位置づけを説明するための図。
【図７９】クライアント端末と構造化文書編集装置の構成例を示した図。
【符号の説明】
１…要求制御部
２…アクセス要求処理部
３…検索要求処理部
４…データアクセス部
５…文書記憶部
６…インデックス記憶部
１１…受付要求部
１２…結果処理部
２１…文書格納部
２２…文書取得部
２３…文書削除部
４１…文書オブジェクトツリー格納部
４２…文書オブジェクトツリー削除部
４３…文書オブジェクトツリー取得部
４４…文書文字列取得部
４５…パスから文書オブジェクトツリー取得部
４６…文書パーサ
４７…合成文書作成部
４８…インデックス更新部
１００…構造化文書管理システム
１０１…ＷＷＷサーバ
１０２…クライアント端末
１０３…ＷＷＷブラウザ
２０１…ユーザタグ登録部
２０２…検索要求入力部
２０３…検索結果表示処理部
２０４…文書編集部
２０５…拡張文書検索要求入力部
２０６…ユーザタグ記憶部
２０７…追加文書抽出部
２０８…検索要求分離部
２０９…追加文書検索部
２１０…追加文書記憶部
２１１…文書合成部
３０１…構造化文書編集装置
【図１】
0003842576.tif 000002
【図２】
0003842576.tif 000003
【図３】
0003842576.tif 000004
【図４】
0003842576.tif 000005
【図５】
0003842576.tif 000006
【図６】
0003842576.tif 000007
【図７】
0003842576.tif 000008
【図８】
0003842576.tif 000009
【図９】
0003842576.tif 000010
【図１０】
0003842576.tif 000011
【図１１】
0003842576.tif 000012
【図１２】
0003842576.tif 000013
【図１３】
0003842576.tif 000014
【図１４】
0003842576.tif 000015
【図１５】
0003842576.tif 000016
【図１６】
0003842576.tif 000017
【図１７】
0003842576.tif 000018
【図１８】
0003842576.tif 000019
【図１９】
0003842576.tif 000020
【図２０】
0003842576.tif 000021
【図２１】
0003842576.tif 000022
【図２２】
0003842576.tif 000023
【図２３】
0003842576.tif 000024
【図２４】
0003842576.tif 000025
【図２５】
0003842576.tif 000026
【図２６】
0003842576.tif 000027
【図２７】
0003842576.tif 000028
【図２８】
0003842576.tif 000029
【図２９】
0003842576.tif 000030
【図３０】
0003842576.tif 000031
【図３１】
0003842576.tif 000032
【図３２】
0003842576.tif 000033
【図３３】
0003842576.tif 000034
【図３４】
0003842576.tif 000035
【図３５】
0003842576.tif 000036
【図３６】
0003842576.tif 000037
【図３７】
0003842576.tif 000038
【図３８】
0003842576.tif 000039
【図３９】
0003842576.tif 000040
【図４０】
0003842576.tif 000041
【図４１】
0003842576.tif 000042
【図４２】
0003842576.tif 000043
【図４３】
0003842576.tif 000044
【図４４】
0003842576.tif 000045
【図４５】
0003842576.tif 000046
【図４６】
0003842576.tif 000047
【図４７】
0003842576.tif 000048
【図４８】
0003842576.tif 000049
【図４９】
0003842576.tif 000050
【図５０】
0003842576.tif 000051
【図５１】
0003842576.tif 000052
【図５２】
0003842576.tif 000053
【図５３】
0003842576.tif 000054
【図５４】
0003842576.tif 000055
【図５５】
0003842576.tif 000056
【図５６】
0003842576.tif 000057
【図５７】
0003842576.tif 000058
【図５８】
0003842576.tif 000059
【図５９】
0003842576.tif 000060
【図６０】
0003842576.tif 000061
【図６１】
0003842576.tif 000062
【図６２】
0003842576.tif 000063
【図６３】
0003842576.tif 000064
【図６４】
0003842576.tif 000065
【図６５】
0003842576.tif 000066
【図６６】
0003842576.tif 000067
【図６７】
0003842576.tif 000068
【図６８】
0003842576.tif 000069
【図６９】
0003842576.tif 000070
【図７０】
0003842576.tif 000071
【図７１】
0003842576.tif 000072
【図７２】
0003842576.tif 000073
【図７３】
0003842576.tif 000074
【図７４】
0003842576.tif 000075
【図７５】
0003842576.tif 000076
【図７６】
0003842576.tif 000077
【図７７】
0003842576.tif 000078
【図７８】
0003842576.tif 000079
【図７９】
0003842576.tif 000080