JP3842574B2 - 情報抽出方法および構造化文書管理装置およびプログラム - Google Patents

Description

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

Claims (5)

1. 複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに複数のノードをリンクし、各構造化文書の記憶エリアを前記複数のノードのいずれかにリンクした論理構造により前記複数の構造化文書を管理する構造化文書データベースを備えた構造化文書管理装置において、前記構造化文書データベースに格納される構造化文書中の処理対象の要素の値から少なくとも１つの要素をもつ構造化文書を抽出する情報抽出方法であって、
   前記複数のノードのうちの第１のノードにリンクされた前記構造化文書データベースの記憶エリアに、前記処理対象から抽出すべき情報の構造化文書への変換規則を示す変換規則構造化文書を格納するステップと、
   前記複数のノードのうちの第２のノードにリンクされた前記構造化文書データベースの記憶エリアに、当該第２のノードにリンクされて管理される各構造化文書の文書構造を定義するとともに、前記処理対象とすべき要素及び前記処理対象に対し適用する変換規則を指定するスキーマ構造化文書を格納するステップと、
   前記スキーマ構造化文書により指定された前記変換規則を用いて、前記第２のノードにリンクされた記憶エリアに記憶される構造化文書中の前記処理対象の要素の値から、少なくとも１つの要素をもつ構造化文書を抽出する抽出ステップと、
   抽出した構造化文書を前記処理対象の要素の子要素として前記構造化文書データベースに格納するステップと、
   を有する情報抽出方法。
2. 前記抽出ステップは、前記スキーマ構造化文書により指定された前記変換規則のうち、前記処理対象の要素に含まれる語彙に基づき選択された変換規則を用いて、少なくとも１つの要素をもつ構造化文書を抽出することを特徴とする請求項１記載の情報抽出方法。
3. 複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに複数のノードをリンクし、各構造化文書の記憶エリアを前記複数のノードのいずれかにリンクした論理構造により前記複数の構造化文書を管理する構造化文書データベースと、
   前記構造化文書データベースに格納される構造化文書中の処理対象の要素の値から抽出すべき情報の構造化文書への変換規則を示す変換規則構造化文書を、前記複数のノードのうちの第１のノードにリンクされた前記構造化文書データベースの記憶エリアに格納する手段と、
   前記複数のノードのうちの第２のノードにリンクされた前記構造化文書データベースの記憶エリアに、当該第２のノードにリンクされて管理される各構造化文書の文書構造を定義するとともに、前記処理対象とすべき要素及び前記処理対象に対し適用する変換規則を指定するスキーマ構造化文書を格納する手段と、
   前記スキーマ構造化文書により指定された前記変換規則を用いて、前記第２のノードにリンクされた記憶エリアに記憶される構造化文書中の前記処理対象の要素の値から、少なくとも１つの要素をもつ構造化文書を抽出する抽出手段と、
   抽出した構造化文書を前記処理対象の要素の子要素として前記構造化文書データベースに格納する格納手段と、
   を具備したことを特徴とする構造化文書管理装置。
4. 前記抽出手段は、前記スキーマ構造化文書により指定された前記変換規則のうち、前記処理対象の要素に含まれる語彙に基づき選択された変換規則を用いて、少なくとも１つの要素をもつ構造化文書を抽出することを特徴とする請求項３記載の構造化文書管理装置。
5. 複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノー ドに複数のノードをリンクし、各構造化文書の記憶エリアを前記複数のノードのいずれかにリンクした論理構造により前記複数の構造化文書を管理する構造化文書データベースを備えたコンピュータに、
   前記複数のノードのうちの第１のノードにリンクされた前記構造化文書データベースの記憶エリアに、前記処理対象から抽出すべき情報の構造化文書への変換規則を示す変換規則構造化文書を格納するステップと、
   前記複数のノードのうちの第２のノードにリンクされた前記構造化文書データベースの記憶エリアに、当該第２のノードにリンクされて管理される各構造化文書の文書構造を定義するとともに、前記処理対象とすべき要素及び前記処理対象に対し適用する変換規則を指定するスキーマ構造化文書を格納するステップと、
   前記スキーマ構造化文書により指定された前記変換規則を用いて、前記第２のノードにリンクされた記憶エリアに記憶される構造化文書中の前記処理対象の要素の値から、少なくとも１つの要素をもつ構造化文書を抽出する抽出ステップと、
   抽出した構造化文書を前記処理対象の要素の子要素として前記構造化文書データベースに格納するステップと、
   を実行させるプログラム。

Images