(57)【特許請求の範囲】
【請求項１】
複数の文書スキーマに基づいた文書属性データを文書コンテンツに対応付けて登録し、複数の文書スキーマの混在運用を可能にした文書管理方法において、それぞれの文書スキーマを示すスキーマ識別子およびその文書スキーマに定義された各属性を示す属性識別子を文書スキーマを構成する情報として自動生成して登録するとともに、登録された前記文書スキーマに新規な属性識別子を追加する場合は新たに属性識別子を自動生成して追加登録し、登録された前記文書スキーマに対して属性識別子の追加又は削除のいずれにも該当しない変更を行う場合は属性識別子を維持することを特徴とする文書管理方法。
【請求項２】
請求項１に記載の文書管理方法において、文書スキーマ間の属性識別子を比較することにより複数の文書スキーマに共通した共通属性か否かを判定し、その判定結果に従って異なる文書スキーマに基づいた文書属性データを生成することを特徴とする文書管理方法。
【請求項３】
請求項１または請求項２に記載の文書管理方法において、自動生成した識別子を含む文書スキーマを他の文書管理システムへ持ち出し可能なスキーマ定義ファイルに書き込むことを特徴とする文書管理方法。
【請求項４】
請求項１乃至請求項３のいずれか１つの請求項に記載の文書管理方法において、自動生成された識別子を含む文書スキーマを他の文書管理システムより得たスキーマ定義ファイルから読み込んで新たな文書スキーマとして登録することを特徴とする文書管理方法。
【請求項５】
請求項１乃至請求項４のいずれか１つの請求項に記載の文書管理方法において、複数の文書スキーマに共通して属する文書属性データを文書属性データが記憶されている文書属性管理テーブル中から検索する際、検索条件として指定されたスキーマ名または属性名をスキーマ識別子または前記文書属性管理テーブルの前記属性名に対応付けられたフィールドを示す情報に変換して検索することを特徴とする文書管理方法。
【請求項６】
請求項１乃至請求項５のいずれか１つの請求項に記載の文書管理方法を実施するためのプログラムを記憶したことを特徴とする機械読み取り可能な記憶媒体。
【請求項７】
複数の文書スキーマに基づいた文書属性データを文書コンテンツに対応付けて登録し、複数の文書スキーマの混在運用を可能にした文書管理装置において、それぞれの文書スキーマを示すスキーマ識別子およびその文書スキーマに定義された各属性を示す属性識別子を文書スキーマを構成する情報として自動生成する識別子生成手段と、前記識別子生成手段により自動生成された識別子を登録する文書スキーマ登録手段と、を備え、
登録された前記文書スキーマに新規な属性識別子を追加する場合、前記文書スキーマ登録手段は、新たに前記識別子生成手段により自動生成された属性識別子を追加登録し、
登録された前記文書スキーマに対して属性識別子の追加又は削除のいずれにも該当しない変更を行う場合、前記文書スキーマ登録手段は、前記文書スキーマの属性識別子を維持することを特徴とする文書管理装置。
【請求項８】
請求項７に記載の文書管理装置において、文書スキーマ間の属性識別子を比較することにより複数の文書スキーマに共通した共通属性か否かを判定する判定手段を備え、前記文書スキーマ登録手段は、前記判定手段による判定結果に従って異なる文書スキーマに基づいた文書属性データを生成することを特徴とする文書管理装置。
【請求項９】
請求項７または請求項８に記載の文書管理装置において、前記識別子生成手段により自動生成された識別子を含む文書スキーマを他の文書管理システムへ持ち出し可能なスキーマ定義ファイルに書き込む書込手段を備えたことを特徴とする文書管理装置。
【請求項１０】
請求項７乃至請求項９のいずれか１つの請求項に記載の文書管理装置において、前記文書スキーマ登録手段は、前記識別子生成手段により自動生成された識別子を含む文書スキーマを他の文書管理システムより得たスキーマ定義ファイルから読み込んで新たな文書スキーマとして登録することを特徴とする文書管理装置。
【請求項１１】
請求項７乃至請求項１０のいずれか１つの請求項に記載の文書管理装置において、複数の文書スキーマに共通して属する文書属性データを文書属性データが記憶されている文書属性管理テーブル中から検索する検索手段を備え、前記検索手段は、検索条件として指定されたスキーマ名または属性名をスキーマ識別子または前記文書属性管理テーブルの前記属性名に対応付けられたフィールドを示す情報に変換して検索することを特徴とする文書管理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数の文書スキーマ（文書属性事項のデータ構造）に基づいた文書属性データ（書誌情報）を登録しておいて、文書検索などを行う際にそのいずれの文書スキーマの文書属性データも用いることができる文書管理方法およびその方法を実施するためのプログラムを記憶した記憶媒体に関する。
【０００２】
【従来の技術】
文書管理システムは、例えば図10に示すように、一つまたは複数の文書管理サーバ12と複数のパーソナルコンピュータなどクライアント端末装置11とから成るネットワークシステムとして構成されている。文書管理サーバ12内には、ハードディスクやコンパクトディスクなどの部分領域から構成されたフォルダなどと呼ばれている文書保管場所単位を複数有した文書記憶手段を備え、その中に文書データなどを保管する。また、クライアント端末装置11内にも文書記憶手段を備え、その中に文書データなどを保管する。
そして、文書管理サーバ12内の文書記憶手段に文書データを保管する場合には、例えば文書を登録する際には、利用者が、登録しようとする文書コンテンツと、それにリンクさせる文書名、登録者名およびキーワードなど文書属性データ（書誌情報）を与え、文書コンテンツを保管するフォルダなどを指定する。これにより、文書管理サーバ12内の文書管理手段が、与えられた文書属性データや例えば時計回路から取得した登録日などを文書属性管理テーブルに追加して登録すると共に、与えられた文書コンテンツを追加した文書属性データにリンクさせて指定されたフォルダなどに保管する。
また、保管されている所望の文書コンテンツを取り出す際には、利用者が、例えば検索条件としてフォルダ名と文書名など一部の文書属性データとを指定した閲覧指示などを与え、文書管理サーバ12内の文書管理手段が、閲覧指示などに従って該当する文書を検索し、該当文書の一覧情報を作成し、クライアント端末装置11がそれを表示する。そして、その中から所望の文書を指定させることによりその文書の文書コンテンツを文書管理サーバ12内の文書記憶手段から読み出し、それを受信したクライアント端末装置11が文書コンテンツをその中の表示装置に表示し、文書コンテンツを用紙に記録してその用紙を出力する。なお、文書一覧情報を構成しているそれぞれの単位情報は、文書名（ファイル名）、登録者名、登録日およびキーワードなどから成っている。
また、近年では、例えば管理している複数種類の文書データベースのそれぞれに対応付けて複数種類の文書スキーマ（文書属性事項のデータ構造，形式）の文書属性データを登録しておき、いずれの文書スキーマの文書属性データを用いても文書検索などが行えるようにした文書管理システムも提供されている。例えば文書スキーマＡでは、文書属性項目が文書名，作成者および登録日であり、文書スキーマＢでは、文書属性項目が著書名，著者名，発行日および出版者名であるような複数の文書スキーマが用意されている。また、このような文書管理システムでは、文書登録時、どの文書スキーマを適用するかを選択することができる。
【０００３】
図11に、従来技術による文書スキーマの定義例を示す。複数の文書スキーマをそれぞれスキーマ識別子（ID）で識別し、一つの文書空間で複数の文書スキーマを利用できるようにしている。それぞれの文書IDにその文書属性データを対応付ける文書属性管理テーブルに文書毎にスキーマIDを書き込み、データベース内に記憶されている文書コンテンツの属性をスキーマIDによって識別できるようにしているのである（図３参照）。文書IDに対応するスキーマIDにより、各属性値がそれぞれ文書属性管理テーブル上のどのフィールドに保存されているかが分かる。文書の登録時や検索時、入力フィールドや文書一覧の表示画面を作る際に、このようなスキーマ定義が参照される。例として、図12に文書登録時の処理フローを示す。この例では、文書コンテンツを登録し（ステップＳ51）、その後、文書属性登録に先立ってどのスキーマに従って文書属性登録を行うかを利用者が選択し（ステップＳ52）、それに従った属性入力画面を自動的に作成して表示し（ステップＳ53）、利用者の入力した文書属性データをスキーマ定義に従って文書属性管理テーブルの該当フィールドに保存して行く（ステップＳ54）。
また、利用者が文書属性事項の構成を変更できるようにした文書管理システムも提供されている。このような文書管理システムでは、運用中のスキーマ変更に対処する必要があるし、この場合、既に登録されている文書の属性データに対しても変更内容を反映する必要があるので、そのための機能も備えているのが普通である。
【０００４】
【発明が解決しようとする課題】
しかしながら、従来の文書管理システムでは、文書スキーマの適用範囲が特定のデータベースに限られたり、別データベースに同じ文書スキーマを適用することができても文書スキーマ変更時には利用者自身がすべてのデータベースに対して同期を取る（例えば一つのデータベースでの変更をすべてのデータベースに反映させる）必要があったり、自動的に同期を取る機能を設けていてもオフライン状態のデータベースや過去に取ったデータベースのバックアップに対してまでは同期を取ることが不可能なため、データの不整合が生じ、正常に処理することができないというような問題がある。
本発明の課題は、このような従来の技術の問題を解決することにある。すなわち、本発明の目的は、文書の検索の際などに用いる文書属性の種類を利用者が自由に定義できるように複数の文書スキーマ定義を登録および保持し、複数の文書スキーマを混在運用可能な文書管理システムにおいて、登録済みの文書スキーマの変更などを安全に行えたり、過去に登録した文書のバックアップデータや別システムで管理されている文書との間で不整合が発生しないようにしたりできる文書管理方法およびその方法を実施するためのプログラムを記憶した記憶媒体を提供することにある。
【０００５】
【課題を解決するための手段】
前記課題を解決するために、請求項１に記載の発明は、複数の文書スキーマに基づいた文書属性データを文書コンテンツに対応付けて登録し、複数の文書スキーマの混在運用を可能にした文書管理方法において、それぞれの文書スキーマを示すスキーマ識別子およびその文書スキーマに定義された各属性を示す属性識別子を文書スキーマを構成する情報として自動生成して登録するとともに、登録された前記文書スキーマに新規な属性識別子を追加する場合は新たに属性識別子を自動生成して追加登録し、登録された前記文書スキーマに対して属性識別子の追加又は削除のいずれにも該当しない変更を行う場合は属性識別子を維持することを特徴とする。
請求項２に記載の発明は、請求項１に記載の文書管理方法において、文書スキーマ間の属性識別子を比較することにより複数の文書スキーマに共通した共通属性か否かを判定し、その判定結果に従って異なる文書スキーマに基づいた文書属性データを生成することを特徴とする。
請求項３に記載の発明は、請求項１または請求項２に記載の文書管理方法において、自動生成した識別子を含む文書スキーマを他の文書管理システムへ持ち出し可能なスキーマ定義ファイルに書き込むことを特徴とする。
請求項４に記載の発明は、請求項１乃至請求項３のいずれか１つの請求項に記載の文書管理方法において、自動生成された識別子を含む文書スキーマを他の文書管理システムより得たスキーマ定義ファイルから読み込んで新たな文書スキーマとして登録することを特徴とする。
請求項５に記載の発明は、請求項１乃至請求項４のいずれか１つの請求項に記載の文書管理方法において、複数の文書スキーマに共通して属する文書属性データを文書属性データが記憶されている文書属性管理テーブル中から検索する際、検索条件として指定されたスキーマ名または属性名をスキーマ識別子または前記文書属性管理テーブルの前記属性名に対応付けられたフィールドを示す情報に変換して検索することを特徴とする。
請求項６に記載の発明は、請求項１乃至請求項５のいずれか１つの請求項に記載の文書管理方法を実施するためのプログラムを記憶したことを特徴とする。
請求項７に記載の発明は、複数の文書スキーマに基づいた文書属性データを文書コンテンツに対応付けて登録し、複数の文書スキーマの混在運用を可能にした文書管理装置において、それぞれの文書スキーマを示すスキーマ識別子およびその文書スキーマに定義された各属性を示す属性識別子を文書スキーマを構成する情報として自動生成する識別子生成手段と、前記識別子生成手段により自動生成された識別子を登録する文書スキーマ登録手段と、を備え、登録された前記文書スキーマに新規な属性識別子を追加する場合、前記文書スキーマ登録手段は、新たに前記識別子生成手段により自動生成された属性識別子を追加登録し、登録された前記文書スキーマに対して属性識別子の追加又は削除のいずれにも該当しない変更を行う場合、前記文書スキーマ登録手段は、前記文書スキーマの属性識別子を維持することを特徴とする。
請求項８に記載の発明は、請求項７に記載の文書管理装置において、文書スキーマ間の属性識別子を比較することにより複数の文書スキーマに共通した共通属性か否かを判定する判定手段を備え、前記文書スキーマ登録手段は、前記判定手段による判定結果に従って異なる文書スキーマに基づいた文書属性データを生成することを特徴とする。
請求項９に記載の発明は、請求項７または請求項８に記載の文書管理装置において、前記識別子生成手段により自動生成された識別子を含む文書スキーマを他の文書管理システムへ持ち出し可能なスキーマ定義ファイルに書き込む書込手段を備えたことを特徴とする。
請求項１０に記載の発明は、請求項７乃至請求項９のいずれか１つの請求項に記載の文書管理装置において、前記文書スキーマ登録手段は、前記識別子生成手段により自動生成された識別子を含む文書スキーマを他の文書管理システムより得たスキーマ定義ファイルから読み込んで新たな文書スキーマとして登録することを特徴とする。
請求項１１に記載の発明は、請求項７乃至請求項１０のいずれか１つの請求項に記載の文書管理装置において、複数の文書スキーマに共通して属する文書属性データを文書属性データが記憶されている文書属性管理テーブル中から検索する検索手段を備え、前記検索手段は、検索条件として指定されたスキーマ名または属性名をスキーマ識別子または前記文書属性管理テーブルの前記属性名に対応付けられたフィールドを示す情報に変換して検索することを特徴とする。
【０００６】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。
図１は本発明の実施の形態に係る文書管理方法を実施する文書管理装置を示すブロック図である。図１に示したように、この実施の形態に係る文書管理装置は、ＣＰＵ１と、メモリ（例えばＲＡＭ）２と、入力装置３と、表示装置４と、補助記憶装置（例えばハードディスク装置）５と、外部記憶装置６および通信制御装置７などを備えている。
ＣＰＵ１は、プログラムに従って装置各部を制御し文書管理処理を行う。メモリ２は、プログラムおよび各種データを一時的に記憶しておく。入力装置３は、キーボード入力装置およびマウス入力装置などからなる。表示装置４は、各種データなどを表示する。補助記憶装置５は、プログラムおよび文書コンテンツやその文書属性データなどを保管しておく。外部記憶装置６は、着脱可能な記憶媒体からなる。通信制御装置７は、ネットワークを介した通信を制御する。
図２は、本発明の各実施例の文書スキーマの定義例を説明をするための説明図である。図２に示すように、スキーマIDとは、個々の文書スキーマに対応した識別子である。属性IDとは、個々の文書属性に対応した識別子ある。スキーマIDおよび属性IDは、分散環境でもユニークな識別子（同じ値のものが２つとない識別子）が設定されることを保証するためにどちらも例えばGUID（Global Unique Identifire ）値を用いる。GUIDとは、コンピュータネットワーク関係の規約である）。また、属性タイプとは、文字列型、数値型および日付型と言ったようなデータ型である。対応フィールド名とは、文書属性管理テーブルのどのフィールドが対応しているかを示すための名前である。このような文書スキーマの定義が図11に示した従来の文書スキーマと異なるのは各属性ごとにシステム全体でユニークな属性IDを付けて定義している点である。この属性IDによって、例えば文書スキーマ変更前後でどの文書属性が変更になったかというようなことが明確に分かるので、変更した文書スキーマに対して変更前の文書スキーマに属する文書が何らかの理由により混在した状況で、変更前の文書スキーマに従ったままになっている文書属性データ（以下、属性データと略す）を変更後の文書スキーマに変更して提示するというようなことができる。
【０００７】
図３は、文書属性管理テーブルを示す説明図である。図３において、String1〜Nとは、文書スキーマで定義された各文書属性のうち文字列型の属性が割り当てられるフィールドである。Numeric1〜Nとは、数値型の属性である。DateTime1〜Nとは、日付型の属性が割り当てられるフィールドであり、スキーマIDが違えば同じフィールドでも違う属性値が入る。
図４は、本発明の第１の実施例を示す文書スキーマ作成の動作を説明するためのフロー図である。以下、図４などに基づいてこの第１の実施例の動作を説明する。
図示したように、まず、ＣＰＵ１がプログラムに従って利用者にスキーマ名を入力させる（ステップＳ１）。そして、そのスキーマ名に付けるスキーマIDを自動生成し（あるいは通信制御装置７によりネットワークを介して外部から取得し）（ステップＳ２）、さらに、文書スキーマを構成する一つの属性について、属性名、属性タイプ（データ型）および表示順などを利用者に入力させる（ステップＳ３）。
続いて、スキーマIDの場合と同様にして当該属性に属性IDを付け（ステップＳ４）、文書属性管理テーブルのフィールドを割り当て（ステップＳ５）、さらに、一つの属性について前のステップで得た属性名など属性項目情報を文書スキーマに書き込む（ステップＳ６）。
こうして、一つの文書属性について作成が終了すると、まだ作成していない属性が有るか否かを判定し（ステップＳ７）、有る場合には（ステップＳ７でYes）その１つについてステップＳ３から繰り返す。そして、すべての文書属性について作成が終了すると（ステップＳ７でNo）、この動作を終了させる。
【０００８】
次に、図５は本発明の文書管理方法によるスキーマ変更時の動作を説明するためのフロー図である。を説明する。図５に基づいてこのスキーマ変更時の動作を説明するまず、ＣＰＵ１が、メッセージなどを表示させて、例えば追加する属性名、削除する属性名、または変更内容などを入力させる（ステップＳ11）。そして、入力された内容に規定に反する内容が含まれていないかどうかをチェックする（ステップＳ12）。
続いて、入力された内容から、その変更が文書属性の追加か否かを判定し（ステップＳ13）、文書属性の追加であれば（ステップＳ13でYes）その文書属性に付ける新規の属性IDを生成し（ステップＳ14）、その文書属性（以下、属性と略す）に文書属性管理テーブルのフィールドを割り当て（ステップＳ15）、文書スキーマにその属性の属性名など属性項目情報を追加する（ステップＳ16）。
これに対して、ステップＳ13において属性の追加でないと判定されたならば（ステップＳ13でNo）、入力された変更が属性の削除か否かを判定する（ステップＳ17）。そして、属性の削除であれば（ステップＳ17でYes）、指定された属性の属性項目情報を文書スキーマから削除し（ステップＳ18）、文書属性管理テーブルのフィールドの割り当てを削除し（ステップＳ19）、文書属性管理テーブル中の全文書の該当フィールド値を消去する（ステップＳ20）。また、ステップＳ17において属性の削除でないと判定されたならば（ステップＳ17でNo）、属性名称などの変更であると判断し、入力された変更内容を文書スキーマに反映させる（ステップＳ21）。
前記ステップＳ16，Ｓ20またはＳ21が実行された後は、入力された内容中にまだ処理していない内容が有るか否かを判定し（ステップＳ22）、有る場合には  （ステップＳ22でYes）ステップＳ13から繰り返し、また、入力された内容中にまだ処理していない内容が無ければ（ステップＳ22でNo）スキーマIDを新しい値に変更して文書属性管理テーブルにも反映させ（ステップＳ23）、この動作を終了させる。
【０００９】
図６は、本発明の文書管理方法によるデータ移行処理を説明するためのフロー図である。次に、文書空間内においてスキーマ変更前の属性データ（バックアップデータを再利用する際や、他システムと共有していた文書スキーマが変更され、その変更をまだ他システムに反映させていないような場合を想定している）を変更後のスキーマ定義に従って同調させる処理（データ移行処理）の動作を図６に基づいて説明する。
このデータ移行処理では、まず、例えば外部記憶装置６に装着されている着脱可能な記憶媒体から変更前の文書スキーマとそれに従っている文書属性管理テーブルを読み出し、補助記憶装置５に記憶されている変更後の文書スキーマとそれに従っている文書属性管理テーブルを読み出す。そして、変更前文書スキーマから最初の属性項目情報を取り出し（ステップＳ31）、その変更前文書スキーマの属性IDを変更後文書スキーマの各属性IDと比較して、変更後文書スキーマ（新スキーマ）に同じ属性IDが存在するか否かを判定する（ステップＳ32）。こうして、変更前文書スキーマに存在して変更後文書スキーマに存在しない属性IDがあれば（ステップＳ32でNo）、変更前の文書スキーマに従っている文書属性管理テーブル中の全文書の該当フィールド値を消去する（ステップＳ33）。
１つの属性について該当フィールド値を消去した後、またはステップＳ32において変更後文書スキーマに同じ属性IDが存在すると判定された場合には（ステップＳ32でYes）、未処理の属性（文書スキーマを構成している次の属性）が変更前文書スキーマに有るか否かを判定し（ステップＳ34）、有る場合には（ステップＳ34でYes）次の属性項目情報を取り出し（ステップＳ31）、以下、繰り返す。
そして、変更前文書スキーマに未処理の属性が無いと判定されたならば（ステップＳ34でNo）、つまり、変更後文書スキーマに従った属性データの生成（データ移行）が終了したならば、変更前文書スキーマを変更後文書スキーマで置き換える（ステップＳ35）。なお、属性名が変更になっているような場合もあるが、これについては、スキーマ定義を上書きする以外、特に必要な処理は発生しない。
【００１０】
前記のように、本発明では、例えば変更前後の二つの文書スキーマ間において各属性が共通か否かを判定するのに属性名の代わりに属性IDを用いたが、文書群（文書空間）を用途に応じて例えば基本スキーマとその派生スキーマなど複数の文書スキーマに属させるような場合にも文書スキーマ間の各属性の共通性判断を属性名でなく属性IDで行う。複数の文書スキーマに共通した共通属性か否かを属性IDを用いて判定し、その判定結果に従って複数の文書スキーマに基づいた文書属性データを生成するのである。
また、この実施例では、図２に示した文書スキーマ定義情報を他の文書管理システムへ持ち出すための機能を提供している。例えば図２で示したような文書スキーマ定義情報を着脱可能な記憶媒体にファイルとして書き込むのである。他の文書管理システムへ持ち出してもスキーマIDや属性IDの重複が発生しないように、図２に示した文書スキーマ定義情報ではそれぞれのID値としてGUID値を用いている。なお、この外部への持ち出しの目的は他の文書管理システムにおける新規取り込みや共有スキーマの変更である。新規取り込みは着脱可能な記憶媒体のデータを文書スキーマとして登録するだけで実現できる。これに対して、共有スキーマの変更の場合は既存文書スキーマ（前記変更前文書スキーマに相当）を着脱可能な記憶媒体に格納された新文書スキーマに移行する必要があるので、図６に示した処理が必要になる。
このような文書管理システムでは、本来文書空間を構成する情報に包含されない文書スキーマ定義情報を文書空間内に複製として保持する。図７に示すように、例えば一つの文書管理システム（例えば一つの文書管理装置）Ｓ内の文書空間A を構成する情報をバックアップしたり他の文書管理システムへ移したりする際に、その文書管理システムＳ内に登録されている文書スキーマ▲１▼、文書スキーマ▲２▼を文書空間A の付随情報として持ち出すことにより同期ずれによる文書スキーマと文書空間の不整合を防ぐのである。元の文書管理システムにある共通リソースとしての文書スキーマ定義情報と複製として持ち出した文書スキーマ定義情報との間の不整合は発生し得るが、その場合でも複製した文書スキーマ定義情報を前記変更前スキーマ定義情報（旧スキーマ定義情報）、共通リソース側を変更後スキーマ定義情報（新スキーマ定義情報）として図６に示した処理を実行することにより整合を取ることができる。
こうして、以上説明した第１の実施例によれば、複数の文書スキーマを混在運用可能な文書管理システムにおいて、複数の文書スキーマ間で個々の属性が共通か否かを属性名でなくユニークな属性IDを用いて判定できるので、属性が違うにもかかわらず同じであると誤判定したり同じであるにもかかわらず違っていると誤判定したりすることがなくなり、したがって、文書スキーマの変更などを安全に行えるし、文書スキーマを文書属性管理テーブルや文書コンテンツに付随させて他の文書管理システムへ持ち出すことにより過去に登録した文書のバックアップデータや別システムで管理されている文書との間で不整合が発生しないようにしたりできる。
【００１１】
本発明の第２の実施例では、図８に示すような文書検索条件の変換を行う。図８に示したように、文書検索条件としてスキーマ名が与えられている場合にはそのスキーマ名をスキーマIDに変換し、検索条件として属性名が与えられている場合には文書スキーマ定義に従ってその属性名をフィールド名に変換する。なお、文書スキーマ定義が複数になる場合は、検索条件として与えられている属性は検索対象となる文書スキーマ全てが共通に持つ属性である必要があり、これを満たさない検索条件はエラーとなる。この第２の実施例の動作を説明するためのフローを図９に示す。以下、図９などに基づいてこの第２の実施例の動作を説明する。
図９に示したように、まず、登録されている複数の文書スキーマ中から検索条件式中に与えられた最初のスキーマ名を探し（ステップＳ41）、そのスキーマ名が見つかると、その文書スキーマからスキーマIDを取得し、検索条件式中のスキーマ名を取得したスキーマIDに置き換える（ステップＳ42）。そして、置き換えたスキーマIDをメモリ２内の所定領域に設けたスキーマリスト中に記憶し（ステップＳ43）、検索条件式中の最後のスキーマ名まで達したか否かを判定する（ステップＳ44）。
その結果、最後のスキーマ名まで達していなければ（ステップＳ44）検索条件式中の次のスキーマ名を複数の文書スキーマ中から探す（ステップＳ41）。そして、検索条件式中のすべてのスキーマ名がスキーマIDに置き換えられると（ステップＳ44でYes）、スキーマIDへの置換を行った最初の文書スキーマ中から検索条件式中の検索対象属性名を探し（ステップＳ45）、その検索対象属性名がその文書スキーマ中に共通してあるか否かを調べる（ステップＳ46）。こうして、共通してあると判定されたならば（ステップＳ47でYes）、スキーマリスト中の最初のスキーマIDつまり検索条件式の最初の文書スキーマに対応付けてその文書スキーマの検索対象属性名のフィールド名を記憶する（ステップＳ48）。
【００１２】
続いて、フィールド名の記憶の処理、すなわち、フィールド名への置換が検索条件式中の最後の文書スキーマまで終了したか否かを判定し（ステップＳ49）、終了していなければ（ステップＳ49でNo）次の文書スキーマについてステップＳ46から繰り返す。そして、最後の文書スキーマまで終了すると（ステップＳ49でYes）、この動作フローを終了させる。
それに対して、ステップＳ46〜Ｓ49の繰り返しのなかで検索対象属性名の属性がない文書スキーマが出てきた場合には（ステップＳ47でNo）、所定のエラー処理を行い（ステップＳ50）、この動作を終了させる。
こうして、第２の実施例によれば、文書スキーマに依存しない形式の検索条件で検索を行うことができるので、複数の文書スキーマに属する属性データを対象にして一度の操作で検索を行うことができる。
また、以上説明したような本発明の文書管理方法を実施するためのプログラムを記憶した機械読み取り可能な記憶媒体を得ることができる。この記憶媒体に記憶されたプログラムをパーソナルコンピュータなどの情報処理装置に読み取らせ実行させることにより本発明の文書管理方法を実施することができる。
【００１３】
【発明の効果】
以上説明したように、請求項１に記載の発明によれば、それぞれの文書スキーマを示すスキーマ識別子だけでなくその文書スキーマに定義された各属性を示す属性識別子が文書スキーマを構成する情報として自動生成され、登録されるとともに、登録された文書スキーマに新規な属性識別子が追加される場合は新たに属性識別子が自動生成されて追加登録され、登録された前記文書スキーマに対して属性識別子の追加又は削除のいずれにも該当しない変更が行われる場合は属性識別子が維持されるので、それぞれの文書スキーマに属している属性が同じ属性か否かが明確に分かる。
また、請求項２に記載の発明によれば、請求項１に記載の発明において、文書スキーマ間の属性識別子を比較することにより複数の文書スキーマに共通した共通属性か否かが判定され、その判定結果に従って異なる文書スキーマに基づいた文書属性データが生成されるので、属性が同じか否かに基づいて他の文書スキーマに従った文書属性データから当該文書スキーマに従った文書属性データを生成する際、誤りなく生成することができるから、登録済みの文書スキーマの変更などを安全に行えるし、過去に登録した文書のバックアップデータや別システムで管理されている文書との間で不整合が発生しないようにしたりできる。
また、請求項３に記載の発明によれば、請求項１または請求項２に記載の発明において、自動生成した識別子を含む文書スキーマが他の文書管理システムへ持ち出し可能なスキーマ定義ファイルに書き込まれるので、そのスキーマ定義ファイルを用いて他の文書管理システムでも請求項１または請求項２記載の発明の効果を得ることができる。
また、請求項４に記載の発明によれば、請求項１乃至請求項３のいずれか１つの請求項に記載の発明において、自動生成された識別子を含む文書スキーマが他の文書管理システムより得たスキーマ定義ファイルから読み込まれ、新たな文書スキーマとして登録されるので、文書スキーマの登録を効率よく行うことができる。
また、請求項５に記載の発明によれば、請求項１乃至請求項４のいずれか１つの請求項に記載の発明において、複数の文書スキーマに共通して属する文書属性データを文書属性データが記憶されている文書属性管理テーブル中から検索する際、検索条件として指定されたスキーマ名または属性名がスキーマ識別子または前記文書属性管理テーブルの前記属性名に対応付けられたフィールドを示す情報に変換され、そのスキーマ識別子またはフィールドを示す情報に従って検索されるので、文書スキーマに依存しない形式の検索条件で検索を行うことができるから、複数の文書スキーマに属する属性データを対象にして一度の操作で検索を行うことができる。
また、請求項６に記載の発明によれば、請求項１乃至請求項５のいずれか１つの記載の文書管理方法を実施するためのプログラムを記憶した機械読み取り可能な記憶媒体を得ることができるから、この記憶媒体に記憶されたプログラムをパーソナルコンピュータなどの情報処理装置に読み取らせ実行させることにより請求項１乃至請求項５の文書管理方法を実施することができるので、請求項１乃至請求項５に記載の発明の効果を得ることができる。
また、請求項７に記載の発明によれば、請求項１と同様の効果を得ることができる。
また、請求項８に記載の発明によれば、請求項２と同様の効果を得ることができる。
また、請求項９に記載の発明によれば、請求項３と同様の効果を得ることができる。
また、請求項１０に記載の発明によれば、請求項４と同様の効果を得ることができる。
また、請求項１１に記載の発明によれば、請求項５と同様の効果を得ることができる。
【図面の簡単な説明】
【図１】本発明の１つの実施の形態に係る文書管理方法を実施する文書管理装置を示すブロック図である。
【図２】本発明の文書管理方法の各実施例における文書スキーマの定義例を説明するための説明図である。
【図３】本発明の文書管理方法における各実施例に用いる文書属性管理テーブルを説明するための説明図である。
【図４】本発明の第１の実施例を説明するためのフロー図である。
【図５】本発明の第１の実施例を説明するための他のフロー図である。
【図６】本発明の第１の実施例を説明するための他のフロー図である。
【図７】本発明の第１の実施例を説明するための他の説明図である。
【図８】（ａ）は本発明の第２の実施例における利用者が入力した検索条件による処理を説明するための説明図であり、（ｂ）はスキーマ定義により検索条件をスキーマに依存しない形式に変換する処理を説明するための説明図である。
【図９】本発明の第２の実施例を説明するためのフロー図である。
【図１０】従来の技術の１例を示す文書管理システムを示すブロック図である。
【図１１】従来の文書管理方法を説明するための説明図である。
【図１２】従来の文書管理方法を説明するためのフロー図である。
【符号の説明】
1ＣＰＵ、２  メモリ、３  入力装置、４  表示装置、５  補助記憶装置、６外部記憶装置、７  通信制御装置。
【図１】
0004136267.tif 000002
【図２】
0004136267.tif 000003
【図３】
0004136267.tif 000004
【図４】
0004136267.tif 000005
【図５】
0004136267.tif 000006
【図６】
0004136267.tif 000007
【図７】
0004136267.tif 000008
【図８】
0004136267.tif 000009
【図９】
0004136267.tif 000010
【図１０】
0004136267.tif 000011
【図１１】
0004136267.tif 000012
【図１２】
0004136267.tif 000013