JP2007072526A - リポジトリ及びデータ入力装置及びプログラム - Google Patents

Abstract

【課題】スキーマの異なるリポジトリ間でのオブジェクトの移動又はコピーにおいて、オブジェクトに含まれるデータ要素の欠落を防止する。
【解決手段】リポジトリは、当該リポジトリが管理するオブジェクトのスキーマを記憶するスキーマ記憶部、オブジェクトが持つデータ要素のうち前記スキーマに属するデータ要素を記憶するスキーマ内要素記憶部、オブジェクトの持つデータ要素のうち前記スキーマに属さないデータ要素をスキーマ外要素として記憶するスキーマ外要素記憶部、他のリポジトリから入力されるオブジェクトが持つデータ要素のうち、前記スキーマに属する各データ要素はスキーマ内要素記憶部に記憶させ、前記スキーマに属さない各データ要素はスキーマ外要素としてスキーマ外要素記憶部に記憶させるオブジェクト入力処理部、を備える。
【選択図】図１

Description

本発明は、スキーマが異なるリポジトリ間でのオブジェクトの移動又はコピーのための技術に関する。

特許文献１には、データのスキーマを追加又は変更又は削除できるデータ管理システムにおいて、スキーマを追加するときに、元になるスキーマを継承し、継承関係を保持しておき、スキーマの追加又は変更を柔軟に行う方法について述べられている。

しかし特許文献１では、リポジトリが複数存在する場合を考慮していない。したがって、特許文献１の方式をそのまま用いたのでは、スキーマが異なるリポジトリ間でデータの移動又はコピーを行うと、移動元又はコピー元のスキーマにあって、移動先又はコピー先のスキーマにないデータ構造要素は、欠落してしまう可能性があった。

また、特許文献２には、移動元又はコピー元のスキーマにあって、移動先又はコピー先のスキーマにない属性がある場合、その属性に対する類似属性が移動先又はコピー先のスキーマにあれば、その属性の値を類似属性の値として保存する方法が開示されている。

この方法は、属性の欠落を減らすことができる場合もあるが、欠落を完全に防ぐことはできない。また、類似属性として保存するため、予想しない属性として保存されてしまうこともある。

また、このほかの従来技術として、追加の属性をスキーマで管理しない文書管理システムもあり、このシステムでは属性の欠落を防ぐことが可能である。

しかし、スキーマで管理されていない属性は、
・オブジェクトの検索や追加、変更のときに属性の名前、型を入力しなければならない。
・デフォルト値や、有効な値の範囲を定義できない。
・必須な属性、変更不可能な属性などの指定が定義できない。
というように使い勝手に問題がある。

特開２００４−０２１４４９号公報 特開２００２−１２３５０６号公報

本発明の一つの側面では、スキーマの異なるリポジトリ間でのオブジェクトの移動又はコピーにおいて、オブジェクトに含まれるデータ要素の欠落を防止できるようにする。

本発明の１つの側面では、オブジェクト群を管理するリポジトリとしてコンピュータシステムを機能させるためのプログラムであって、該コンピュータシステムを、該リポジトリが管理するオブジェクトのスキーマを記憶するスキーマ記憶部、オブジェクトが持つデータ要素のうち前記スキーマに属するデータ要素を記憶するスキーマ内要素記憶部、オブジェクトの持つデータ要素のうち前記スキーマに属さないデータ要素をスキーマ外要素として記憶するスキーマ外要素記憶部、他のリポジトリから入力されるオブジェクトが持つデータ要素のうち、前記スキーマに属する各データ要素はスキーマ内要素記憶部に記憶させ、前記スキーマに属さない各データ要素はスキーマ外要素としてスキーマ外要素記憶部に記憶させるオブジェクト入力処理部、として機能させるためのプログラムを提供する。

本発明の別の側面では、第１リポジトリが管理するオブジェクトを、第１リポジトリとはオブジェクトのスキーマが異なる第２リポジトリに入力するためのデータ入力装置としてコンピュータシステムを機能させるためのプログラムであって、該コンピュータシステムを、オブジェクトの持つデータ要素のうち、第１リポジトリのスキーマにも第２リポジトリのスキーマにもあるデータ要素を、第２リポジトリのスキーマ内要素として該第２リポジトリに登録するスキーマ内要素入力処理部、オブジェクトの持つデータ要素のうち、第１リポジトリのスキーマにあって第２リポジトリのスキーマにないデータ要素を、第２リポジトリのスキーマ外要素として該第２リポジトリに登録するスキーマ外要素入力処理部、として機能させるためのプログラムを提供する。

以下、図面を参照して、本発明の好適な実施の形態（「実施形態」と呼ぶ）について説明する。

図１は、本発明に係るリポジトリ装置１００Ａと１００Ｂとが、ＬＡＮ（ローカルエリアネットワーク）やインターネットなどのネットワーク１６０を介して接続されて構成されるシステムを示す。

個々のリポジトリ装置１００Ａ，１００Ｂは、コンテンツ管理部１１０Ａ，１１０Ｂ、属性管理部１２０Ａ，１２０Ｂ、スキーマ管理部１３０Ａ，１３０Ｂ、オブジェクト入力処理部１４０Ａ，１４０Ｂ、及びスキーマ編集処理部１５０Ａ，１５０Ｂを有している。両リポジトリ装置１００Ａ及び１００Ｂは機能構成を有するものなので、以下では、適宜リポジトリ装置１００Ａを代表として説明する。

コンテンツ管理部１１０Ａは、リポジトリ装置１００Ａが管理するオブジェクトのコンテンツデータ（本体データ）を管理する機能モジュールである。また、属性管理部１２０Ａは、それらオブジェクトのメタデータ（属性データ）を管理する機能モジュールである。

本実施形態のシステムでは、図２に示すように、管理対象であるオブジェクト１０は、メタデータ２０とコンテンツデータ３０を有している。コンテンツデータ３０は、オブジェクト１０の本体である内容部分のデータであり、例えばオブジェクトが文書である場合、その文書内容のデータである。これに対し、メタデータ２０は、そのコンテンツデータ３０の管理や検索などのために付される属性データの集合乃至リストである。例えば文書オブジェクトの場合、メタデータ２０に含まれる属性としては、文書の作成者名や作成日時、文書種別、キーワードリストなどが例示できる。メタデータ２０は複数の属性データからなるリストを含んでおり、個々の属性データは、属性の識別情報である属性ＩＤ２２と、属性の値である属性値２４とのペアを有している。

このようなオブジェクト１０のうちコンテンツデータ３０はコンテンツ管理部１１０Ａで、メタデータ２０は属性管理部１２０Ａで、それぞれ管理される。例えば、コンテンツ管理部１１０Ａには、オブジェクト１０の識別子と対応づけてそのオブジェクト１０のコンテンツデータ３０が登録され、属性管理部１２０Ａには、オブジェクト１０の識別子と対応づけてそのオブジェクトのメタデータ２０が登録される。

スキーマ管理部１３０Ａは、コンテンツ管理部１１０Ａ及び属性管理部１２０Ａに登録され管理されるオブジェクト１０のメタデータ２０のスキーマを管理する機能モジュールである。スキーマは、オブジェクト１０のメタデータ２０に含まれる属性の組合せを表現したデータである。また、スキーマには、それら各属性の名前、データ型、制約など、各属性についての付加情報が含まれてもよい。

スキーマのデータ構造の例を図３に示す。この例では、１つのスキーマは、１つのスキーマ定義４０と１以上の属性定義５０を有する。スキーマ定義４０は、オブジェクト１０のクラスに対して規定されるものであり、そのスキーマに対応するクラスの識別情報であるクラスＩＤ４２，そのクラスの名称であるクラス名４４を含んでいる。また、本実施形態では、オブジェクト１０のクラス間に継承関係を規定することができ、あるクラス（派生元）から派生したクラスは、派生元クラスのスキーマ定義４０に含まれる属性項目の全部又は一部を継承することができる。この派生元クラスを指し示す識別情報が、スキーマ定義４０の派生元クラスＩＤ４６に記述される。また、スキーマ定義４０は、属性リスト４８を含む。属性リスト４８は、そのスキーマ４０に対応するクラスのオブジェクト１０が含む各属性項目の識別情報（属性ＩＤ４９−１，４９−２，・・・）のリストである。

属性定義５０は、個々の属性項目の定義情報であり、その属性項目の識別情報である属性ＩＤ５２，その属性項目の名称である属性名５４を含む。また、属性定義５０には、その属性の値がとるデータ型５６，デフォルト値５８，及び値の範囲５９が記述される。このような属性定義５０が、属性リスト４８に含まれる属性ごとに存在する。属性定義５０と属性リスト４８に含まれる属性とは、属性ＩＤ（４９−１，４９−２，・・・及び５２）でリンクされている。なお、図５に示したのはあくまで一例であり、属性定義５０は属性名５４，データ型５６，デフォルト値５８，及び値の範囲５９の全てを有する必要はないし、またこれら以外の付加情報を含んでもよい。

リポジトリ装置１００Ａは、複数のスキーマを持つ（すなわち複数のクラスのオブジェクトを管理する）ことができる。複数のスキーマを管理する場合、スキーマ管理部１３０にはそれら各スキーマのスキーマ定義４０及び属性定義５０が登録される。

属性管理部１２０Ａは、管理する各オブジェクト１０のメタデータ２０を、例えば図４に示すように、当該オブジェクト１０の識別情報であるオブジェクトＩＤ６２、当該オブジェクト１０のメタデータ２０が準拠するスキーマのクラスＩＤ６４、及び各属性項目の属性ＩＤ６６−１，６６−２，・・・と属性値６８−１，６８−２，・・・のペアのリストの組として管理する。個々の属性項目の属性名やデータ型などは、スキーマ管理部１３０ＡからクラスＩＤ６４に対応するスキーマ定義４０を読み出し、その中から属性ＩＤ６６−１，６６−２，・・・に対応する属性定義５０を読み出すことで求めることができる。

さて、１つのリポジトリ装置１００Ａだけで閉じたシステムであれば、取り扱うオブジェクトはスキーマ管理部１３０Ａが管理するスキーマに従ったものだけで基本的によい。しかし、複数のリポジトリ装置が存在するシステムを考えると、同じ又は類似のクラスであってもリポジトリ装置によってメタデータ２０の属性リストが多少異なる場合を想定する必要がある。すなわち、あるリポジトリ装置１００Ｂではスキーマに定義された属性であっても、別のリポジトリ装置１００Ａではその属性がスキーマに定義されていないという場合が生じうる。従来技術では、そのような属性の値はリポジトリ装置１００Ｂからリポジトリ装置１００Ａに移動又はコピーされる際に欠落するか、或いは類似属性に登録されるかのいずれかであった。これに対し、本実施形態には、リポジトリ装置１００Ａに、当該リポジトリ装置１００Ａが管理するスキーマに定義されない属性項目の値を保存するためのスキーマ外属性管理部１２２Ａを設けた。以下、当該リポジトリ装置が管理するスキーマには定義されない属性をスキーマ外属性と呼び、これに対し、スキーマに定義される属性をスキーマ内属性と呼ぶ。

図５に、スキーマ外属性管理部１２２Ａが管理するオブジェクトのスキーマ外属性のデータ構造の例を示す。この例では、オブジェクトＩＤ７２に対応づけて、当該オブジェクトの各スキーマ外属性の属性名７４−１，７４−２，・・・と属性値７６−１，７６−２，・・・のペアを管理している。ここで、各スキーマ外属性を属性ＩＤではなく属性名で管理しているのは、属性ＩＤはスキーマが分からないと一般に無意味なビット列乃至文字列になってしまうのに対し、属性名だとスキーマが不明でも人間が読めばある程度意味が分かるからである。

図５のデータ構造がオブジェクトのスキーマ外属性を管理するものであるのに対し、図４に示したデータ構造は、オブジェクトが持つ属性のうちのスキーマ内属性を管理するためのデータ構造である。リポジトリ装置１００Ａは、属性管理部１２０Ａにおけるスキーマ内属性の情報とスキーマ管理部１３０Ａとを用いることで、スキーマに従って属性データのチェック（例えば属性値のデータ型のチェックや、属性値が所定の範囲に収まっているかのチェックなど）を行ったり、属性に対して入力がなされない時にデフォルト値をセットしたりするなどの処理を行うことができる。

図１では、スキーマ外属性管理部１２２Ａが属性管理部１２０Ａの管理下にあるものとして表示したが、スキーマ外属性管理部１２２Ａと、オブジェクトのスキーマ内属性を保持・管理する管理部とが対等な関係で存在する構成でも構わない。

オブジェクト入力処理部１４０Ａは、他のリポジトリ装置１００Ｂからネットワーク１６０等を介して入力されるオブジェクトのデータをコンテンツ管理部１１０Ａ、属性管理部１２０Ａ及びスキーマ外属性管理部１２２Ａへと格納するための処理を行う機能モジュールである。オブジェクト入力処理部１４０Ａの処理内容は後で詳しく説明する。

スキーマ編集処理部１５０Ａは、スキーマ管理部１３０Ａが管理するスキーマに対する編集作業を行うための機能モジュールである。編集には、スキーマに対する属性項目の追加、削除、属性項目の変更（例えば属性名、データ型の変更など）などの処理が含まれる。スキーマ編集処理部１５０Ａは、スキーマ編集のためのユーザインタフェース画面をユーザに提供し、その画面に対してユーザが行った入力内容に応じてスキーマを編集する。

次に、図６〜図９を参照して、本実施形態の第１のリポジトリ装置１００Ａから第２のリポジトリ装置１００Ｂにオブジェクトを移動又はコピーした場合を例にとり、本実施形態のリポジトリ装置の動作を説明する。なお、以下では、煩雑さを避けるため、移動の場合を代表して説明する。

図６は、第１のリポジトリ装置１００Ａがある時点で持つ、「特許文書」クラスに属するオブジェクトのメタデータの例を示す図である。この例では、「特許文書」クラスのメタデータには、「タイトル」、「作成日」、「作成者」、「特許番号」、「評価」という属性名を持つ５つのスキーマ内属性が含まれる。例えば属性「タイトル」の属性値は文字列型であり、「作成日」の属性値は日付型である。また例えば属性「特許番号」の値は整数型であり、その値の範囲が１００００〜９９９９９と規定されている。このように、図６に示した表の３つの行のうち、第１行がスキーマ管理部１３０Ａで管理されるスキーマ情報であり、第２行、第３行が属性管理部１２０Ａで管理される属性情報である。なお、この時点では、リポジトリ装置１００Ａの「特許文書」クラスのオブジェクト群には、スキーマ外属性を有するものはない。

図７は、第２のリポジトリ装置１００Ｂがある時点で保持する、「文書」クラスに属するオブジェクトのメタデータの例を示す図である。このクラスには、「タイトル」、「作成日」、「作成者」という属性名を持つ３つのスキーマ内属性が含まれる。この時点では、リポジトリ装置１００Ｂの「文書」クラスのオブジェクト群には、スキーマ外属性を有するものはない。

このような状況で第１のリポジトリ装置１００Ａが持つオブジェクト「特許文書２」を第２のリポジトリ装置１００Ｂの管理する「文書」クラスへと移動する場合を考える。この場合、「特許番号」と「評価」という属性は、第１のリポジトリ装置１００Ａの「特許文書」クラスにはあるが、第２のリポジトリ装置１００Ｂの「文書」クラスにはない。したがって、これら２つの属性は、第２のリポジトリ装置１００Ｂではスキーマ外属性として保存される。すなわち、図８に示すように、オブジェクト「特許文書２」の「タイトル」と「作成日」と「作成者」の各属性値は、第２のリポジトリ装置１００Ｂでは、同名のスキーマ内属性として管理されることになるが、「特許番号」と「評価」の属性は、スキーマ外属性としてスキーマ外属性管理部１２２Ｂに保存されることになる。スキーマ外属性管理部１２２Ｂには、図示のごとく、「特許番号：１０００２」及び「評価：Ａ」のように属性名と属性値のペアが、属性ごとに列挙して登録される。スキーマ外属性のデータ型は、汎用性と人間にとっての可読性の観点から、文字列型とすることが好ましい。図では、オブジェクトＩＤを明示しなかったが、スキーマ内属性もスキーマ外属性も、オブジェクトＩＤと対応づけて保存される。

このように、オブジェクトの移動乃至コピーに伴って、移動先のスキーマから外れてしまう属性の情報を、スキーマ外属性管理部１２２Ｂに登録することで、元のオブジェクトにあった属性を欠落させることなく保存できる。また、スキーマ外属性として保存する情報として、属性名と属性値のペアを採用したことで、少なくとも人間が見て各スキーマ外属性の意味を把握することができる。なお、移動されたオブジェクトのメタデータの内、移動先のリポジトリ装置１００Ｂのスキーマ内属性については、そのスキーマに従った管理が従来同様可能である。

他のリポジトリ装置１００Ａから移動によりオブジェクトが入力されてきた時の、受け入れ側のリポジトリ装置１００Ｂのオブジェクト入力処理部１４０Ｂの処理手順を、図９を参照して説明する。

オブジェクトは、コンテンツデータ、メタデータ、及び当該メタデータのスキーマ情報の３つの情報の組として、リポジトリ装置１００Ａからリポジトリ装置１００Ｂへと送られてくる。ここに含まれるスキーマ情報は、移動元であるリポジトリ装置１００Ａでの当該オブジェクトのスキーマの内容を示すものである。これを受け取ったオブジェクト入力処理部１４０Ｂは、まずそのオブジェクトのスキーマと同じスキーマが自分のリポジトリ装置１００Ｂのスキーマ管理部１３０Ｂにあるかどうかを判定する（Ｓ１）。例えば、受け取ったオブジェクトのスキーマ情報に含まれるクラスＩＤ４２（図３参照）と同じクラスＩＤを持つスキーマがスキーマ管理部１３０Ｂにあれば、そのスキーマを移動先のスキーマと判定する。そして、オブジェクトのコンテンツデータ及びメタデータをそのスキーマの管理下のデータとして、コンテンツ管理部１１０Ｂ及び属性管理部１２０Ｂに登録する（Ｓ４）。

なお、スキーマの同一性をクラスＩＤの同一性に基づき判断するのは、本システムに参加する全てのリポジトリ装置が同じクラスライブラリを用いている（すなわち同じクラスＩＤが同じスキーマを指し示す）場合に有効な手法である。このような前提が成り立たない場合は、スキーマの属性リスト４８（図３）に含まれる属性群の属性名の組合せが一致するスキーマを、移動先のスキーマと判定するようにしてもよい。

ステップＳ１の判定で、入力されたオブジェクトのスキーマと一致するスキーマがリポジトリ装置１００Ｂにないことが判明した場合、スキーマ管理部１３０Ｂ内にあるスキーマの中から移動先とするスキーマを決定する（Ｓ２）。この決定方式としては、例えば次の３つの方式を挙げることができる。
（１）どのリポジトリにも存在する基本スキーマを移動先とする
（２）入力されたオブジェクトと同じ基本スキーマを継承しているスキーマを移動先とする。そのようなスキーマが複数あれば、それら候補のスキーマを提示し、その中からユーザに移動先を選択させる
（３）入力されたオブジェクトと同じ基本スキーマを継承しているスキーマのうち、属性名が一致する属性の数が最も多いものを移動先とする。

ここで、基本スキーマは、例えばリポジトリ装置を提供するシステムベンダがあらかじめ用意して顧客に提供するスキーマである。リポジトリ装置を利用する各顧客は、自分の必要に応じてその基本スキーマを継承した派生スキーマを作成し、それを使用することができる。したがって、派生スキーマは必ずしも他のリポジトリ装置に同じものがあるとは限らないが、基本スキーマは他のリポジトリ装置にも必ずあると想定できる。例えば、あるリポジトリ装置には、基本スキーマとして「文書」と「フォルダ」があり、「文書」を継承した「特許文書」という派生スキーマがあるという場合を考える。そのようなリポジトリ装置に「文書」オブジェクトを移動した場合は、「文書」又は「特許文書」が移動先のスキーマの候補となる。

なおスキーマの派生元である基本スキーマは、そのスキーマの定義の派生元クラスＩＤ４６（図３参照）から求めることができる。なお、基本スキーマから複数段階の継承を認める場合は、派生元クラスＩＤ４６に、基本スキーマから当該スキーマの親スキーマまでのクラスＩＤの連鎖を持たせておくことで、基本スキーマを特定することができる。

以上に例示した３つの方式以外でも、移動先のスキーマを決定できる方式があれば、それを採用してももちろんよい。

移動先スキーマが決まると、次にオブジェクト入力処理部１４０Ｂは、オブジェクトが持つ属性のうち、その移動先スキーマにない属性の属性名と属性値のペアを、当該オブジェクトのＩＤと対応づけてスキーマ外属性管理部１２２Ｂに保存する。

そしてオブジェクト入力処理部１４０Ｂは、オブジェクトのコンテンツデータをコンテンツ管理部１１０Ｂに登録すると共に、メタデータを移動先スキーマのクラスＩＤに対応づけて属性管理部１２０Ｂに登録する（Ｓ４）。ステップＳ４の処理は、従来と同様のオブジェクト移動処理と同じものでよい。ステップＳ４の処理では、メタデータのうち、移動先スキーマでのスキーマ内属性が属性管理部１２０Ｂに登録されることになる。

以上のような手順により、移動先のスキーマから外れてしまう属性の情報も保存することが可能となる。

このように、スキーマ外属性を保存しておくと、後でそのスキーマ外属性をスキーマに追加することも可能となる。例えば、属性管理部１２０Ｂが図８に示したメタデータを保持している状態で、「文書」クラスのスキーマ内に属性「特許番号」を追加すると、属性管理部１２０Ｂのデータ内容は図１０に示すようなものとなる。このようなスキーマへの属性の追加は、ユーザがスキーマ編集処理部１５０Ａを操作して行う。なお、この場合、新たなスキーマ内属性「特許番号」は整数型となっているが、このようなデータ型の指定は、スキーマ編集を行うユーザが行う。

また、スキーマへの属性の追加の際には、異なる属性名のスキーマ外属性を１つにまとめて追加することもできる。例えば、図１１に示すメタデータ群の例で、オブジェクト「特許文献２」が持つスキーマ外属性「特許番号：１０００２」と、オブジェクト「特許文献３」が持つスキーマ外属性「整理番号：１００２５」とが、仮に同じ種類の属性情報であったとする。「特許文献２」が元々存在していたリポジトリ装置と、「特許文献３」が元々存在していたリポジトリ装置とで、特許に関する同じ種類の番号を異なる属性名で読んでいた場合などに、このような事態は生じうる。しかし、スキーマの編集を行うユーザならば、当該スキーマで管理するオブジェクトについてはかなり知っているはずなので、「特許番号：１０００２」及び「整理番号：１００２５」という情報を見れば、それらが同じ種類のものかどうか、判断できる場合も多い。そして、ユーザが同じ種類と判断してその旨をスキーマ編集処理部１５０Ｂに入力すれば、スキーマ編集処理部１５０Ｂは、それら同一種類として指定された各属性名のスキーマ外属性を、同じ属性ＩＤかつ同じ属性名（これらはユーザに指定してもらう）の属性値としてスキーマ内に追加する。図１１のようなメタデータ群において、「特許番号」と「整理番号」とを同じ属性としてスキーマに追加した場合、そのメタデータ群のデータ構造は図１２に示すようになる。

このようなスキーマ外属性のスキーマ内への追加が指示された場合の、スキーマ編集処理部１５０Ｂの処理手順を図１３に示す。

ユーザが、スキーマを指定して、スキーマ外属性をそのスキーマ内へ追加することを指示した場合、スキーマ編集処理部１５０Ｂは、まず、スキーマ外属性管理部１２２Ｂの中に、そのスキーマに属するオブジェクトのスキーマ外属性が保存されているかどうかを調べる（Ｓ１１）。そのようなスキーマ外属性がなければ処理は終了する。

そのスキーマに属するオブジェクトのスキーマ外属性がスキーマ外属性管理部１２２Ｂの中に保存されていれば、スキーマ編集処理部１５０Ｂは、それら保存されているスキーマ外属性の一覧を表示する（Ｓ１２）。例えば図１１の例では、「特許番号：１０００２」、「評価：Ａ」、「整理番号：１００２５」等と言った各スキーマ外属性が一覧表示される。そして、スキーマ編集処理部１５０Ｂは、それら一覧表示したスキーマ外属性の中で、スキーマ内に追加するものを選択するよう、ユーザに促す。これに応じてユーザが追加すべきスキーマ外属性を１つ選択すると、スキーマ編集処理部１５０Ｂは、その選択を受け付け（Ｓ１３）、選択されたスキーマ外属性と１つにまとめるべき他のスキーマ外属性の選択を受け付けるためのユーザインタフェース画面をユーザに提供する（Ｓ１４）。この画面に応じてユーザが１つにまとめるべき１つ又は複数のスキーマ外属性を選択すると、スキーマ編集処理部１５０Ｂは、スキーマ管理部１３０Ｂにおける当該スキーマの定義データに対し、ステップＳ１３で選択されたスキーマ外属性の属性名をもつスキーマ内属性を追加する（Ｓ１５）。このとき、追加したスキーマ内属性に対し、データ型やデフォルト値などといった属性についての制約条件の入力のためのユーザインタフェース画面をユーザに提供し、ユーザに入力させるようにしてもよい。そして、属性管理部１２０Ｂに登録されたオブジェクトのうち当該スキーマに属するもののスキーマ外属性をスキーマ外属性管理部１２２Ｂにて調べ、その中にステップＳ１３で選択された属性名、及びステップＳ１４で提供したユーザインタフェース画面に応じて選択された属性名、のいずれかに該当するものがあれば、その該当する属性名のスキーマ外属性の属性値をステップＳ１５で当該スキーマに追加したスキーマ内属性の属性ＩＤに対応づけて、当該オブジェクトのスキーマ内属性として保存する（Ｓ１７）。

また、ステップＳ１４で、複数のスキーマ外属性を１つにまとめることはしないとの指示がユーザから入力された場合、スキーマ編集処理部１５０Ｂは、ステップＳ１３で選択されたスキーマ外属性の属性名を持つ属性を当該スキーマに追加し（Ｓ１６）、属性管理部１２０Ｂに登録されたオブジェクトのうち当該スキーマに属するもののスキーマ外属性を調べ、その中にステップＳ１３で選択された属性名に該当するものがあれば、その該当する属性名のスキーマ外属性の属性値をステップＳ１６で当該スキーマに追加したスキーマ内属性の属性ＩＤに対応づけて、当該オブジェクトのスキーマ内属性として保存する（Ｓ１７）。

以上のようにして、スキーマ外属性をスキーマ内に移管することができる。複数のスキーマ外属性をスキーマ内に移管する場合は、以上の処理をそれらスキーマ外属性毎に繰り返せばよい。

以上に示した例では、リポジトリ装置に入力されるオブジェクトがスキーマ外属性を持っている場合を考慮していなかった。このような場合を考慮した場合、スキーマ外属性の取扱ポリシーの一つとしては、スキーマ外属性は移動先でもスキーマ外属性として保存するという方法が考えられる。

また、別のポリシーとして、スキーマ外属性の中で移動先のスキーマ内属性に該当するものがあれば、前者を後者にマッピングするというポリシーも考えられる。このポリシーに従った場合の、オブジェクト入力処理部１４０Ｂの処理手順を図１４に示す。

この手順では、まずオブジェクト入力処理部１４０Ｂは、リポジトリ装置１００Ａから入力されたオブジェクトのスキーマ内属性及びスキーマ外属性の属性名を求める（Ｓ２１）。次に、スキーマ管理部１３０Ｂ内の各スキーマの中から、ステップＳ２１で求めた属性名の集合に最も近い属性名の集合を持つスキーマを求め、そのスキーマを移動先に決定する（Ｓ２２）。そして、入力されたオブジェクトの各スキーマ内属性のうち、移動先のスキーマにない属性の属性名及び属性値のペアを、当該オブジェクトのスキーマ外属性としてスキーマ外属性管理部１２２Ｂに登録する（Ｓ２３）。そして、従来のオブジェクトの入力処理と同様の処理でオブジェクトの各スキーマ内属性を属性管理部１２０Ｂに登録する（Ｓ２４）。また、入力されたオブジェクトのスキーマ外属性のうち移動先スキーマのスキーマ内属性に該当するものはスキーマ内属性としてその属性値を属性管理部１２０Ｂに登録し、移動先スキーマのスキーマ内属性にないものは、当該オブジェクトのスキーマ外属性としてスキーマ外属性管理部１２２Ｂに登録する（Ｓ２５）。

図１４の手順で、ステップＳ２３〜Ｓ２５の実行順序はどのような順序でもよい。また、図１４の例では、属性名の集合の一致度合いによって移動先スキーマを決定した（Ｓ２１，Ｓ２２）が、これに限らず、図９の手順のステップＳ２のように、基本スキーマやそれを継承しているスキーマを移動先に決定してもよい。

また、以上の実施形態において、オブジェクトの属性データをスキーマ外属性として保存する場合に、属性名と属性値のペアだけでなく、移動元のリポジトリ装置１００Ａを一意に特定するリポジトリ識別子も併せてスキーマ外属性管理部１２２Ｂに登録することも好適である。こうすることで、異なるリポジトリ装置が、種類の微妙に異なる情報を同じ属性名で管理している場合などに、それらが移動先のリポジトリ装置で同じ種類の属性と認識されてしまうこと（属性名の衝突）を防止することができる。また、移動先のリポジトリ装置でユーザがスキーマ外属性をスキーマ内に繰り込むときにも、リポジトリ識別子の情報があれば、同じ属性名のスキーマ外属性のうち本当に繰り込むべきものをリポジトリ識別子により判別することができる。

また、本実施形態のスキーマ外属性管理部１２２Ｂは、上述のようなオブジェクトの移動又はコピーの場合だけでなく、更に他の利用も可能である。例えば、オブジェクトを新たにリポジトリ装置１００Ｂに追加したり、既存のオブジェクトを編集したりする際に、現時点のスキーマには存在しない情報を当該オブジェクトに対する一時的なメモとしてスキーマ外属性管理部１２２に保存することができる。また、スキーマ編集処理部１５０Ｂによるスキーマ編集によりスキーマから属性が削除された場合、その削除された属性の値をスキーマ外属性管理部１２２Ｂにスキーマ外属性として保存することもできる。このようにして保存されたスキーマ外属性は、図１３の処理によりスキーマ内に組み込むこともできる。

以上、リポジトリ装置１００Ａからオブジェクトを受け入れるリポジトリ装置１００Ｂの動作を説明したが、当然ながらリポジトリ装置１００Ａも他からオブジェクトを受け入れる場合は、同様の動作を実行する。

次に、上記実施形態の変形例を説明する。この説明でも、オブジェクトの「移動」を代表として説明するが、この他にも「コピー」など、リポジトリ装置の外にあったオブジェクトがリポジトリ装置内に入力される場合一般に、この変形例は有効である。

この変形例では、図１５に示すように、リポジトリ装置１００Ａ，１００Ｂに元スキーマ管理部１２４Ａ，１２４Ｂを設けた。この変形例のリポジトリ装置１００Ａ，１００Ｂは、その他の点については、図１に示した上記実施形態のリポジトリ装置１００Ａ，１００Ｂと同じなので、以下ではこの相違点を中心に説明する。以下では便宜上、リポジトリ装置１００Ａからリポジトリ装置１００Ｂにオブジェクトが移動した場合を例にとる。

元スキーマ管理部１２４Ｂには、入力されてきたオブジェクトが準拠しているスキーマ（すなわちこの例ではリポジトリ装置１００Ａにあった時の当該オブジェクトのスキーマ。以下、元スキーマと呼ぶ）の情報が、当該オブジェクトのＩＤと関連づけて保存される。この保存処理は、オブジェクト入力処理部１４０Ｂが実行する。

このように、元スキーマを移動先のリポジトリ装置１００Ｂに保存することで、スキーマ外属性をスキーマ内に組み込む際に、その属性のデータ型やデフォルト値等の属性の制約条件（図３参照）を元スキーマから求め、組み込み先のスキーマの定義に登録することができる。この点につき、図１６〜図１９を参照して説明する。

図１６は、リポジトリ装置１００Ａがある時点で持つ、「特許文書」クラスに属するオブジェクトのメタデータの例であり、スキーマ内属性の内容は図６と同じである。この時点では、どのオブジェクトにも元スキーマの情報は登録されていない。

同様に図１７は、リポジトリ装置１００Ｂがある時点で持つ、「文書」クラスに属するオブジェクトのメタデータの例である。この場合も、どのオブジェクトにも元スキーマの情報は登録されていない。

さて、リポジトリ装置１００Ａ内のオブジェクト「特許文書２」をリポジトリ１００Ｂの「文書」クラスに移動させた場合を考える。この場合、「文書」クラスのスキーマに属さない「特許番号：１０００２」及び「評価：Ａ」という属性が「特許文献２」のスキーマ外属性としてスキーマ外属性管理部１２２Ｂに保存されると同時に、「特許文献２」の元スキーマの情報が元スキーマ管理部１２４Ｂに保存される。図１８の例では、元スキーマは、「クラス名（属性名／制約条件，属性名／制約条件，・・・）」という形式で記述されるが、これは一例に過ぎない。元スキーマが含む各属性の属性名と制約条件との関係を記述できれば、どのような記述形式でも構わない。

このような状態のリポジトリ装置１００Ｂにおいて、スキーマ外属性「特許番号」を「文書」クラスのスキーマに組み込む場合を考える。上記実施形態では、組み込む属性のデータ型などの制約条件はユーザが手動で入力しなければならなかったが、この変形例では元スキーマの情報から「特許番号」の制約条件、すなわちデータ型が整数型で、値の範囲が１００００〜９９９９９という条件が取得できるので、スキーマ編集処理部１５０Ｂは、その制約条件を編集対象のスキーマに新たに追加した属性の定義（図３参照）に登録する。この結果、図１９に示すように、属性「特許番号」に制約条件が自動的に登録されることになる。

また、この変形例によれば、オブジェクトのスキーマ外属性の値を変更する際に、元スキーマ管理部１２４Ｂに保存されたそのオブジェクトの元スキーマを参照することで、その属性値の変更が制約条件を満足するかどうかを自動判定することもできる。

また、この変形例によれば、元スキーマ管理部１２４Ｂに保存されている元スキーマを、新たなスキーマとしてスキーマ管理部１３０Ｂに追加することも可能となる。この場合、スキーマ編集処理部１５０Ｂは、元スキーマ管理部１２４Ｂにある元スキーマの一覧をユーザに提供し、ユーザがその中からスキーマに採用したいものを選択する。また、元スキーマの中の属性の１つ乃至複数を、その元スキーマを持つオブジェクトが現在属するスキーマに属性として追加できるようにすることも同様に可能である。

また、オブジェクトの元スキーマを保存しておけば、そのオブジェクトを移動先から移動元のリポジトリ装置に戻した際に、その元スキーマを参照することで、移動元のスキーマに正しく戻すことができる。

この変形例でのオブジェクト入力処理部１４０Ｂの処理手順を図２０に示す。この手順では、オブジェクト入力処理部１４０Ｂは、リポジトリ装置１００Ａから入力されたオブジェクトの中に、元スキーマが保存されているかどうかを判定し（Ｓ３１）、そのような元スキーマがあれば、リポジトリ装置１００Ａでの当該オブジェクトのスキーマの代わりに、その元スキーマを移動元のスキーマと判定する（Ｓ３２）。これは、オブジェクトが複数のリポジトリ装置を渡り歩く場合に、オブジェクトが最初に作成された時のスキーマを尊重して残すというポリシーにしたがったものである。すなわち、この手順によれば、オブジェクトが最初に作成されたリポジトリ装置から次のリポジトリ装置に移動した場合に、最初のリポジトリ装置でのスキーマが元スキーマとして次のリポジトリ装置に保存されるが、更に別のリポジトリ装置にそのオブジェクトが移動した場合も、その元スキーマが再び元スキーマとして保存されることになる。

なお、このようなポリシーを採用しない場合は、ステップＳ３１及びＳ３２は不要である。

以降の手順の内、ステップＳ３３，Ｓ３４，Ｓ３６及びＳ３７は、図９に示した手順のステップＳ１，Ｓ２，Ｓ３及びＳ４とそれぞれ同様の処理である。ステップＳ３５では、移動元のスキーマを元スキーマ管理部１２４Ｂに保存する。

次に、図２１を参照して、この変形例における、スキーマ外属性をスキーマに追加する場合の処理手順を説明する。

この手順において、ステップＳ４１〜Ｓ４４までの各ステップは、図１３に示した手順のステップＳ１１〜Ｓ１４とそれぞれ同内容の処理である。ステップＳ４４で複数のスキーマ外属性を１つの属性にまとめると判定された場合、スキーマ編集処理部１５０Ｂは、それら複数のスキーマ外属性のうちどれを基準にするかをユーザに問い合わせ、この問合せに応じてユーザが選択したスキーマ外属性の属性名及び制約条件の情報を元スキーマから取得し（Ｓ４５）、これらの情報をスキーマに追加した属性の情報としてスキーマ管理部１３０Ｂに登録する（Ｓ４６）。

複数のスキーマ外属性を１つにまとめることをしない場合、スキーマ編集処理部１５０Ｂは、ステップＳ４３で選択されたスキーマ外属性の属性名及び制約条件の情報を元スキーマから取得し、これらの情報をスキーマに追加した属性の情報としてスキーマ管理部１３０Ｂに登録する（Ｓ４７）。

ステップＳ４８の処理内容は、図１３の手順のステップＳ１７と同様である。

次に、図２２を参照して、この変形例において、保存されている元スキーマを、正式のスキーマとしてスキーマ管理部１３０Ｂに登録する処理の手順を説明する。

元スキーマをスキーマとして登録する処理がユーザから指示された場合、スキーマ編集処理部１５０Ｂは、まず元スキーマ管理部１２４Ｂに元スキーマが保存されているかどうかを判定する（Ｓ５１）。保存されていなければ処理は終了する。

保存されている元スキーマがあれば、スキーマ編集処理部１５０Ｂはそれら元スキーマの一覧を表示し（Ｓ５２）、ユーザの選択を求める。これに応じてユーザが元スキーマを選択すると、その選択結果を受け取り（Ｓ５３）、その選択された元スキーマにクラスＩＤを付与してスキーマ管理部１３０Ｂに登録する（Ｓ５４）。このとき、クラス名や各属性の属性名や制約条件の情報は元スキーマから取得できるので、それを利用すればよい。属性ＩＤは新たに付与すればよい。

元スキーマに対応するスキーマが新たにスキーマ管理部１３０Ｂに追加されると、スキーマ編集処理部１５０Ｂは、その元スキーマを持っているオブジェクトを元スキーマ管理部１２４Ｂから求め、求めたオブジェクトをその新たなスキーマに関連づける（Ｓ５５）。すなわち、求めたオブジェクトのクラスＩＤ（図４参照）をその新たなスキーマのものに変更し、各属性値をそのスキーマの属性ＩＤに対応づけて属性管理部１２０Ｂに登録すればよい。

以上の変形例によれば、元スキーマの情報を保存することができるので、複数のリポジトリ装置間でオブジェクトの移動やコピーを繰り返した場合にも、その移動先やコピー先で元のスキーマに近いスキーマを探す手がかりとして使用できる。

なお、この変形例において、元スキーマ管理部１２４Ｂに対して保存する元スキーマに、その元スキーマの由来元のリポジトリ装置（すなわち、オブジェクトの移動元、或いはオブジェクトが最初に作成されたリポジトリ装置）の識別子を対応づけて記憶するようにすれば、元スキーマ管理部１２４Ｂ内でのスキーマ名の衝突を避けることができる。

以上、本発明の実施形態及び変形例を説明したが、これらはあくまで例示に過ぎず、本発明の範囲内で様々な変形が可能である。

例えば、以上の例では、各リポジトリ装置１００Ａ、１００Ｂがオブジェクト入力処理部１４０Ａ，１４０Ｂを備え、オブジェクトを受け入れる側のオブジェクト入力処理部１４０Ａ又は１４０Ｂが、スキーマ外の属性に対する処理を請け負っていたが、このような構成以外の構成も考えられる。例えば、オブジェクト入力処理部１４０Ａ、１４０Ｂと同様の機能を備えるサーバをネットワーク１６０上に設け、リポジトリ装置１００Ａからリポジトリ装置１００Ｂにオブジェクトを移動又はコピーする際には、そのサーバでオブジェクトの各属性を移動先のリポジトリ装置１００Ｂのスキーマに合わせてスキーマ内属性及びスキーマ外属性に分別し、リポジトリ装置１００Ｂに入力してもよい。また、このサーバの機能を移動元のリポジトリ装置で実行してもよい。

また、以上の例では、オブジェクトのメタデータのスキーマを例にとって説明したが、メタデータに限らず、オブジェクトのコンテンツデータがスキーマに準拠するものである場合、そのようなコンテンツのスキーマに対しても上記実施形態又は変形例の手法は適用可能である。

以上に説明した実施形態又は変形例のリポジトリ装置及びデータ入力装置は、典型的には、以上に説明した各構成要素の機能を記述したプログラムをコンピュータに実行させることにより実現される。このプログラムは、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ、フレキシブルディスク、ハードディスクなどのコンピュータ読み取り可能な記録媒体に記録した状態でユーザに提供することができる。また、このプログラムは、データ通信ネットワークを介してサーバからユーザのコンピュータにダウンロードすることもできる。

実施形態のシステム構成を示す図である。 オブジェクトのデータ構造を模式的に示す図である。 スキーマのデータ構造の例を模式的に示す図である。 属性管理部が管理するメタデータのデータ構造の例を示す図である。 スキーマ外属性管理部が管理するオブジェクトのスキーマ外属性のデータ構造の例を示す図である。 第１のリポジトリ装置が保持する、「特許文書」クラスに属するオブジェクトのメタデータの例を示す図である。 第２のリポジトリ装置が保持する、「文書」クラスに属するオブジェクトのメタデータの例を示す図である。 第１のリポジトリ装置が保持する、「特許文書」クラスに属するオブジェクトを、第２のリポジトリ装置の「文書」クラスの管理下に移動又はコピーした時のメタデータの内容の例を示す図である。 オブジェクト入力処理部の処理手順を示すフローチャートである。 スキーマ外属性をスキーマに追加した場合のメタデータの内容の例を示す図である。 種類の同じ属性が異なる属性名でスキーマ外属性に登録されたメタデータの例を示す図である。 属性名の異なるスキーマ外属性を１つにまとめてスキーマに登録した場合のメタデータの例を示す図である。 スキーマ外属性をスキーマに追加する場合のスキーマ編集部の処理手順を示すフローチャートである。 オブジェクト入力処理部の処理手順の別の例を示すフローチャートである。 移動元のスキーマも保存する変形例のシステム構成を示す図である。 変形例での、第１のリポジトリ装置が保持する、「特許文書」クラスに属するオブジェクトのメタデータの例を示す図である。 変形例での、第２のリポジトリ装置が保持する、「文書」クラスに属するオブジェクトのメタデータの例を示す図である。 変形例での、第１のリポジトリ装置が保持する、「特許文書」クラスに属するオブジェクトを、第２のリポジトリ装置の「文書」クラスの管理下に移動又はコピーした時のメタデータの内容の例を示す図である。 変形例において、スキーマ外属性をスキーマに追加した場合のメタデータの内容の例を示す図である。 変形例でのオブジェクト入力処理部の処理手順の例を示すフローチャートである。 変形例においてスキーマ外属性をスキーマに追加する場合のスキーマ編集部の処理手順を示すフローチャートである。 変形例において、保存されている元スキーマを、正式のスキーマとしてスキーマ管理部に登録する処理の手順を示すフローチャートである。

符号の説明

１００Ａ，１００Ｂ リポジトリ装置、１１０Ａ，１１０Ｂ コンテンツ管理部、１２０Ａ，１２０Ｂ 属性管理部、１２２Ａ，１２２Ｂ スキーマ外属性管理部、１２４Ａ，１２４Ｂ 元スキーマ管理部、１３０Ａ，１３０Ｂ スキーマ管理部、１４０Ａ，１４０Ｂ オブジェクト入力処理部、１５０Ａ，１５０Ｂ スキーマ編集処理部。

Claims (15)

1. オブジェクト群を管理するリポジトリとしてコンピュータシステムを機能させるためのプログラムであって、該コンピュータシステムを、
   該リポジトリが管理するオブジェクトのスキーマを記憶するスキーマ記憶部、
   オブジェクトが持つデータ要素のうち前記スキーマに属するデータ要素を記憶するスキーマ内要素記憶部、
   オブジェクトの持つデータ要素のうち前記スキーマに属さないデータ要素をスキーマ外要素として記憶するスキーマ外要素記憶部、
   他のリポジトリから入力されるオブジェクトが持つデータ要素のうち、前記スキーマに属する各データ要素はスキーマ内要素記憶部に記憶させ、前記スキーマに属さない各データ要素はスキーマ外要素としてスキーマ外要素記憶部に記憶させるオブジェクト入力処理部、
   として機能させるためのプログラム。
2. 請求項１記載のプログラムであって、
   前記オブジェクト入力処理部は、他のリポジトリから入力されるオブジェクトが含むデータ要素のうち、前記スキーマに属さないデータ要素については、そのデータ要素の値を前記他のリポジトリのスキーマにおけるそのデータ要素の識別名と対応づけて前記スキーマ外要素記憶部に記憶させる、
   ことを特徴とするプログラム。
3. 請求項１記載のプログラムであって、
   前記オブジェクト入力処理部は、他のリポジトリから入力されるオブジェクトがスキーマ外要素を含む場合において、そのスキーマ外要素の識別名と一致する識別名のデータ要素がスキーマ内に存在する場合には、該スキーマ外要素をそのスキーマ内のデータ要素として前記スキーマ内要素記憶部に記憶させる、
   ことを特徴とするプログラム。
4. 請求項２記載のプログラムであって、
   前記オブジェクト入力処理部は、前記スキーマ外要素記憶部に記憶させるデータ要素に対し、前記他のリポジトリの識別子を対応づけて記憶させる、
   ことを特徴とするプログラム。
5. 請求項１記載のプログラムであって、前記コンピュータシステムを、更に、
   前記スキーマ外要素記憶部に記憶されたスキーマ外要素をユーザに提示し、前記スキーマに組み込むスキーマ外要素の選択を受け付ける要素選択部、
   選択されたスキーマ外要素を前記スキーマにデータ要素として追加するスキーマ内要素追加部、
   として機能させるプログラム。
6. 請求項５記載のプログラムであって、
   前記スキーマ内要素追加部は、ユーザに選択された複数のスキーマ外要素をまとめて１つのデータ要素として前記スキーマに追加する、
   ことを特徴とするプログラム。
7. 請求項１記載のプログラムであって、前記コンピュータシステムを、更に、
   前記スキーマ記憶部に記憶されるスキーマを編集するスキーマ編集部、
   前記スキーマ編集部による編集により前記スキーマからデータ要素が削除された場合、前記スキーマ内要素記憶部に記憶された各オブジェクトにおける前記削除されたデータ要素を、スキーマ外要素として前記スキーマ外要素記憶部に記憶させる要素保存処理部、
   として機能させるプログラム。
8. 請求項１記載のプログラムであって、前記コンピュータシステムを、更に、
   オブジェクトに対する前記スキーマに属さないデータ項目の入力を受け付けるための入力部、
   前記入力部から入力されたデータを、当該オブジェクトのスキーマ外要素として前記スキーマ外要素記憶部に記憶させるスキーマ外要素登録部、
   として機能させるためのプログラム。
9. 請求項１記載のプログラムであって、前記コンピュータシステムを、更に、
   他のリポジトリから入力されたオブジェクトに対応づけて、そのオブジェクトの元スキーマを記憶する元スキーマ保存部、
   として機能させるためのプログラム。
10. 請求項９記載のプログラムであって、前記コンピュータシステムを、更に、
    前記スキーマ外要素記憶部に記憶されたスキーマ外要素をユーザに提示し、前記スキーマに組み込むスキーマ外要素の選択を受け付ける要素選択部、
    選択されたスキーマ外要素を前記スキーマにデータ要素として追加するスキーマ内要素部であって、該データ要素に対する制約条件を前記元スキーマに保存された元スキーマから求めて前記スキーマに登録するスキーマ内要素部、
    として機能させるプログラム。
11. オブジェクト群を管理するリポジトリであって、
    該リポジトリが管理するオブジェクトのスキーマを記憶するスキーマ記憶部、
    オブジェクトが持つデータ要素のうち前記スキーマに属するデータ要素を記憶するスキーマ内要素記憶部、
    オブジェクトの持つデータ要素のうち前記スキーマに属さないデータ要素をスキーマ外要素として記憶するスキーマ外要素記憶部、
    他のリポジトリから入力されるオブジェクトが持つデータ要素のうち、前記スキーマに属する各データ要素はスキーマ内要素記憶部に記憶させ、前記スキーマに属さない各データ要素はスキーマ外要素としてスキーマ外要素記憶部に記憶させるオブジェクト入力処理部、
    を備えるリポジトリ。
12. オブジェクト群を管理するリポジトリの制御方法であって、
    他のリポジトリから入力されるオブジェクトが持つデータ要素のうち、該リポジトリのスキーマに属する各データ要素は所定のスキーマ内要素記憶部に記憶させ、
    前記オブジェクトが持つデータ要素のうち、前記スキーマに属さない各データ要素はスキーマ外要素として所定のスキーマ外要素記憶部に記憶させる、
    リポジトリの制御方法。
13. 第１リポジトリが管理するオブジェクトを、第１リポジトリとはオブジェクトのスキーマが異なる第２リポジトリに入力するためのデータ入力装置としてコンピュータシステムを機能させるためのプログラムであって、該コンピュータシステムを、
    オブジェクトの持つデータ要素のうち、第１リポジトリのスキーマにも第２リポジトリのスキーマにもあるデータ要素を、第２リポジトリのスキーマ内要素として該第２リポジトリに登録するスキーマ内要素入力処理部、
    オブジェクトの持つデータ要素のうち、第１リポジトリのスキーマにあって第２リポジトリのスキーマにないデータ要素を、第２リポジトリのスキーマ外要素として該第２リポジトリに登録するスキーマ外要素入力処理部、
    として機能させるためのプログラム。
14. 第１リポジトリが管理するオブジェクトを、第１リポジトリとはオブジェクトのスキーマが異なる第２リポジトリに入力するためのデータ入力装置であって、
    オブジェクトの持つデータ要素のうち、第１リポジトリのスキーマにも第２リポジトリのスキーマにもあるデータ要素を、第２リポジトリのスキーマ内要素として該第２リポジトリに登録するスキーマ内要素入力処理部、
    オブジェクトの持つデータ要素のうち、第１リポジトリのスキーマにあって第２リポジトリのスキーマにないデータ要素を、第２リポジトリのスキーマ外要素として該第２リポジトリに登録するスキーマ外要素入力処理部、
    を備えるデータ入力装置。
15. 第１リポジトリが管理するオブジェクトを、第１リポジトリとはオブジェクトのスキーマが異なる第２リポジトリに入力するためにコンピュータシステムが実行するデータ入力方法であって、
    オブジェクトの持つデータ要素のうち、第１リポジトリのスキーマにも第２リポジトリのスキーマにもあるデータ要素を、第２リポジトリのスキーマ内要素として該第２リポジトリに登録し、
    オブジェクトの持つデータ要素のうち、第１リポジトリのスキーマにあって第２リポジトリのスキーマにないデータ要素を、第２リポジトリのスキーマ外要素として該第２リポジトリに登録する、
    データ入力方法。

Images