(57)【要約】【課題】送信データのデータ量を削減して、送信データの作成と送信を効率よく行えるデータ交換方法およびそれを用いたデータ交換装置を提供する。【解決手段】複数の分類項目を階層的に関連付けた複数個の階層構造をもち、当該複数個の階層構造のそれぞれを構成する各分類項目は当該分類項目の上位階層の分類項目の属性を含む属性をもち、各分類項目に当該分類項目のもつ属性のそれぞれに対応する値で構成されるコンテンツデータを登録するデータベースを有し、当該データベースから読み出された、前記複数個の階層構造のうちの１つである第１の階層構造の分類項目に登録されている複数のコンテンツデータを送信する際には、当該複数のコンテンツデータのそれぞれを構成する各値の間をコンマで区切り、コンテンツデータ間を改行コードで区切ったテキストデータと、第１の階層構造の識別子およびバージョン情報を含む第１の送信データを作成する。【選択図】    図１
2004326583.tif 000002
【特許請求の範囲】
【請求項１】
複数の分類項目を階層的に関連付けて構成された複数個の階層構造であって、当該複数個の階層構造のそれぞれを構成する各分類項目は当該分類項目の上位階層の分類項目の属性を含む属性をもつ当該複数個の階層構造のそれぞれに関するデータと、前記各分類項目の属性に関するデータを記憶する第１の記憶手段と、
前記複数個の階層構造のいずれかを構成する分類項目に属し、当該分類項目のもつ属性の値で構成される複数のコンテンツデータを記憶する第２の記憶手段と、
前記複数個の階層構造のうちの１つである第１の階層構造の分類項目に属する前記第２の記憶手段に記憶されている複数のコンテンツデータのそれぞれを構成する各値の間を第１の区切りコードで区切り、コンテンツデータ間を第２の区切りコードで区切ったテキストデータと、前記第１の記憶手段に記憶されている前記第１の階層構造の識別子およびバージョン情報とを含む第１の送信データを作成する第１の手段と、
前記第１の送信データを送信する第２の手段と、
を具備したことを特徴とするデータ交換装置。
【請求項２】
前記第１の送信データは構造化文書であり、前記テキストデータは、当該構造化文書を構成する要素の値として含まれていることを特徴とする請求項１記載のデータ交換装置。
【請求項３】
前記第１の記憶手段に記憶されている前記第１の階層構造を構成する前記複数の分類項目とそれらの親子関係に関する第１のテキストデータと、当該複数の分類項目の属性に関する第２のテキストデータを含む第２のテキストデータを含む第２の送信データを作成する第３の手段と、
前記第２の送信データを送信する第４の手段と、
を具備したことを特徴とする請求項１記載のデータ交換装置。
【請求項４】
前記第２の送信データは構造化文書であり、前記第１のテキストデータと前記第２のテキストデータは、それぞれ、当該構造化文書を構成する要素の値として含まれていることを特徴とする請求項３記載のデータ交換装置。
【請求項５】
前記第１の送信データの送信先から前記第１の階層構造に関する情報の送信要求を受けたときに、前記第３の手段で前記第２の送信データを作成することを特徴とする請求項３記載のデータ交換装置。
【請求項６】
前記第１の手段は、前記テキストデータを所定の圧縮方式で圧縮して、前記第第１の送信データを作成することを特徴とする請求項１記載のデータ交換装置。
【請求項７】
複数の分類項目を階層的に関連付けた複数個の階層構造をもち、当該複数個の階層構造のそれぞれを構成する各分類項目は当該分類項目の上位階層の分類項目の属性を含む属性をもち、各分類項目に当該分類項目のもつ属性のそれぞれに対応する値で構成されるコンテンツデータを登録するデータベースと、
前記データベースに登録すべき複数のコンテンツデータを表すテキストデータと、前記複数のコンテンツデータのそれぞれが登録されている前記分類項目を含む前記複数個の階層構造のうちの１つである第１の階層構造の識別子およびバージョン情報とを含む第１の送信データを受信する第１の手段と、
受信した前記第１の送信データに含まれる前記識別子と前記バージョン情報に対応する前記第１の階層構造が前記データベースに存在しないとき、当該第１の階層構造に関する情報を要求する第２の手段と、
を具備したことを特徴とするデータ交換装置。
【請求項８】
複数の分類項目を階層的に関連付けた複数個の階層構造をもち、当該複数個の階層構造のそれぞれを構成する各分類項目は当該分類項目の上位階層の分類項目の属性を含む属性をもち、各分類項目には当該分類項目のもつ属性のそれぞれに対応する値で構成されるコンテンツデータが登録されているデータベースから、前記複数個の階層構造のうちの１つである第１の階層構造の分類項目に登録されている複数のコンテンツデータを読み出す第１のステップと、
読み出された前記複数のコンテンツデータを、各コンテンツデータを構成する各値の間を第１の区切りコードで区切り、コンテンツデータ間を第２の区切りコードで区切ったテキストデータと、前記第１の階層構造の識別子およびバージョン情報とを含む第１の送信データを作成する第２のステップと、
前記第１の送信データを送信する第３のステップと、
を有するデータ交換方法。
【請求項９】
前記第１の送信データは構造化文書であり、前記テキストデータは、当該構造化文書を構成する要素の値として含まれていることを特徴とする請求項８記載のデータ交換方法。
【請求項１０】
前記第１の階層構造を構成する前記複数の分類項目とそれらの親子関係に関する第１のテキストデータと、当該複数の分類項目の属性に関する第２のテキストデータを含む第２のテキストデータを含む第２の送信データを作成する第４のステップと、
前記第２の送信データを送信する第５のステップと、
を有することを特徴とする請求項８記載のデータ交換方法。
【請求項１１】
前記第２の送信データは構造化文書であり、前記第１のテキストデータと前記第２のテキストデータは、それぞれ、当該構造化文書を構成する要素の値として含まれていることを特徴とする請求項１０記載のデータ交換方法。
【請求項１２】
前記第１の送信データの送信先から前記第１の階層構造に関する情報の送信要求を受信する第６のステップを更に有し、
前記第４のステップは、前記第６のステップで前記送信要求を受信したとき、前記第２の送信データを作成することを特徴とする請求項１０記載のデータ交換方法。
【請求項１３】
前記第２のステップは、前記テキストデータを所定の圧縮方式で圧縮して、前記第第１の送信データを作成することを特徴とする請求項８記載のデータ交換方法。
【請求項１４】
前記データベースに登録すべき複数のコンテンツデータを表すテキストデータと、前記複数のコンテンツデータのそれぞれが登録されている前記分類項目を含む前記複数個の階層構造のうちの１つである第２の階層構造の識別子およびバージョン情報とを含む第３の送信データを受信する第７のステップと、
受信した前記第３の送信データに含まれる前記識別子と前記バージョン情報に対応する前記第２の階層構造が前記データベースに存在しないとき、当該第２の階層構造に関する情報を要求する第８のステップと、
を有する請求項８記載のデータ交換方法。
【請求項１５】
複数の分類項目を階層的に関連付けた複数個の階層構造をもち、当該複数個の階層構造のそれぞれを構成する各分類項目は当該分類項目の上位階層の分類項目の属性を含む属性をもち、各分類項目には当該分類項目のもつ属性のそれぞれに対応する値で構成されるコンテンツデータが登録されているデータベースから、前記複数個の階層構造のうちの１つである第１の階層構造の分類項目に登録されている複数のコンテンツデータを読み出す第１のステップと、
読み出された前記複数のコンテンツデータを、各コンテンツデータを構成する各値の間を第１の区切りコードで区切り、コンテンツデータ間を第２の区切りコードで区切ったテキストデータと、前記第１の階層構造の識別子およびバージョン情報とを含む第１の送信データを作成する第２のステップと、
前記第１の送信データを送信する第３のステップと、
をコンピュータに実行させるプログラム。
【請求項１６】
前記第１の階層構造を構成する前記複数の分類項目とそれらの親子関係に関する第１のテキストデータと、当該複数の分類項目の属性に関する第２のテキストデータを含む第２のテキストデータを含む第２の送信データを作成する第４のステップと、
前記第２の送信データを送信する第５のステップと、
をさらに有する請求項１５記載のプログラム。
【請求項１７】
前記データベースに登録すべき複数のコンテンツデータを表すテキストデータと、前記複数のコンテンツデータのそれぞれが登録されている前記分類項目を含む前記複数個の階層構造のうちの１つである第２の階層構造の識別子およびバージョン情報とを含む第３の送信データを受信する第６のステップと、
受信した前記第３の送信データに含まれる前記識別子と前記バージョン情報に対応する前記第２の階層構造が前記データベースに存在しないとき、当該第２の階層構造に関する情報を要求する第７のステップと、
を有する請求項１５記載のプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
データ変換装置およびデータ交換装置に関する。
【０００２】
【従来の技術】
インターネット上で、製品情報を電子的に提供する電子カタログシステムを実装するための国際規格としてＩＳＯ１３５８４（Ｐａｒｔｓ  Ｌｉｂｒａｒｙ）がある。ＩＳＯ１３５８４では電子カタログをスキーマとコンテンツで構成し、これらを統一したデータ構造を与えることで、製品情報の共有・再利用を目指している。ＩＳＯ１３５８４で定義しているスキーマでは、製品分類は「製品クラス」を単一木構造で階層的に表現されている。各「製品クラス」はそれぞれ「属性項目」を持つようになっており、ある「製品クラス」の「属性項目」は下位の「製品クラス」に継承される。また、「製品クラス」および「属性項目」は一意に特定できるようそれぞれ「ＢＳＵコード」とよばれるユニークなＩＤをつけるようになっている。一方、コンテンツの部分はこのスキーマに定義された属性項目にそれぞれの製品固有の属性値を埋め込んだテーブルとして表現される。
【０００３】
ＩＳＯ１３５８４が電子カタログとしてのフレームワークを提供している一方で、実際のスキーマについての国際標準化も進められており、ＩＥＣ６１３６０では電気・電子分野でのスキーマの上位階層部分、つまり「製品クラス」と「属性項目」についての一般的な部分の標準化を推進している。これにより、各社の製品カタログ作成者は、ＩＥＣ６１３６０からの下位展開として独自の詳細な「製品クラス」と「属性項目」を決め、各自のコンテンツを作成することができる。
【０００４】
このように作成されたコンテンツを電子カタログの利用者は「製品クラス」の分類階層を辿り、属性値を参照して自分に必要な製品を絞り込んでいき、所望の製品を検索することが可能となる。近年、これらの流れをうけてＩＳＯ１３５８４に準拠したシステムがいくつか開発されようになってきている。
【０００５】
ＩＳＯ１３５８４準拠のスキーマを部分セットに分割し交換する方法として、部分セットを作成する時に、それを復元するために必要な分割ファイルの識別子を補完データとして付与するというものがある（例えば、特許文献１参照）。
【０００６】
Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ  （ＳＯＡＰ）はＷ３Ｃで仕様をまとめている非集中／分散環境におけるシステム間で構造化され型付けされた情報の交換のためのＸＭＬベースのプロトコルである。ＳＯＡＰは、データをモジュールとして符号化するためのモジュール式のパッケージングモデルと符号化のメカニズムを提供することにより、アプリケーションのセマンティクスを表現するための単純なメカニズムを定義する。
【０００７】
ＸＭＬ文書を圧縮するために、ＣＳＶ（Ｃｏｍｍａ  ｓｅｐａｒａｔｅｄ  ｖａｌｕｅ）を用いる方法がある。これは、ＸＭＬ文書中を処理対象と非処理対象とに分類し、非処理対象部分をＣＳＶ形式で羅列した１個の要素に変換することによってＸＭＬ文書を圧縮するというものである。
【０００８】
ＩＳＯ１３５８４では、スキーマをメタデータとして交換可能なモデルとなっている。コンテンツは対応するスキーマを識別することによって、スキーマと分離可能な記述となっているが、実際は１つのフォーマットでスキーマとコンテンツを同時にデータ交換を行っていた。
【０００９】
スキーマとコンテンツを分離してデータ交換を行うようにＸＭＬ形式で記述する方法がある。しかし、ＸＭＬは構造を持つ分類や属性を記述するのには適しているが、膨大な量のコンテンツを交換する場合、データ作成に時間がかかり、交換するためのデータ容量が大きくなるため通信コストが高くなるという問題点があった。
【００１０】
一方、コンテンツはほとんどの情報は帳票形式で記述することができる。帳票形式では、普及した表現方法でありながら記述効率は、同じ情報をＸＭＬで記述した時に比べ３分の１程度に抑えることができる。しかし、帳票形式では記述能力が不足しているため近年のＢ２Ｂビジネスにおけるデータ交換フォーマットにおいて有効とはいえない。
【００１１】
上記特許文献１には、スキーマを分割することによって必要な量のデータ交換を可能としているが、データ交換するためのフォーマットの効率化については特に言及していない。
【００１２】
ＳＯＡＰにおいては、ＸＭＬによるデータ交換のプロトコルについての仕様であるが、その送信するデータの形式の意味について規定するものではない。
【００１３】
ＸＭＬ文書をＣＳＶ圧縮する手法では、非処理対象部分をＣＳＶ圧縮しており処理対象部分においては圧縮することができない。また、この技術は、ＸＭＬ文書をベースにしているものであり、データベースから取得したデータを一旦ＸＭＬフォーマットで記述しなければならない。
【００１４】
【特許文献１】
特開２００１−１４７９２０公報
【００１５】
【発明が解決しようとする課題】
このように、従来、階層構造により整理された膨大な量のコンテンツデータを他の装置へ転送する（交換する）際には、階層構造を表すスキーマとコンテンツデータの両方を送るか、コンテンツデータをＸＭＬ形式で送るといったように、コンテンツデータと階層構造とを完全に切り離すことなく、一体化した送信データを作成する必要があり、そのため送信データの作成のための処理時間や送信時間を容易に短縮することはできないという問題点があった。
【００１６】
そこで、本発明は、上記問題点に鑑み、送信データのデータ量を削減して、送信データの作成と送信を効率よく行えるデータ交換方法およびそれを用いたデータ交換装置を提供することを目的とする。
【００１７】
【課題を解決するための手段】
本発明は、複数の分類項目を階層的に関連付けた複数個の階層構造をもち、当該複数個の階層構造のそれぞれを構成する各分類項目は当該分類項目の上位階層の分類項目の属性を含む属性をもち、各分類項目に当該分類項目のもつ属性のそれぞれに対応する値で構成されるコンテンツデータを登録するデータベースを有し、当該データベースから読み出された、前記複数個の階層構造のうちの１つである第１の階層構造の分類項目に登録されている複数のコンテンツデータを送信する際には、当該複数のコンテンツデータのそれぞれを構成する各値の間を第１の区切りコード（例えば、コンマや、コロン（：）、セミコロン（；）、タブコードなど）で区切り、コンテンツデータ間を第２の区切りコード（例えば、ピリオド（．）コードや改行コード、さらに、第１の区切りコードとして用いたコードより区切りが強くなるものであれば、コロン（：）、セミコロン（；）、タブコードなどであってもよい）で区切ったテキストデータと、前記第１の階層構造の識別子およびバージョン情報とを含む第１の送信データを作成することにより、送信データのデータ量を削減して、送信データの作成と送信が効率よく行える。
【００１８】
また、上記データベースは、複数の分類項目を階層的に関連付けて構成された複数個の階層構造であって、当該複数個の階層構造のそれぞれを構成する各分類項目は当該分類項目の上位階層の分類項目の属性を含む属性をもつ当該複数個の階層構造のそれぞれに関するデータと、前記各分類項目の属性に関するデータを記憶する第１の記憶手段と、前記複数個の階層構造のいずれかを構成する分類項目に属し、当該分類項目のもつ属性の値で構成されるコンテンツデータを記憶する第２の記憶手段とを有することを特徴とする。
【００１９】
また、上記送信データを受信する受信側においては、前記データベースに登録すべき複数のコンテンツデータを表すテキストデータと、前記複数のコンテンツデータのそれぞれが登録されている前記分類項目を含む前記複数個の階層構造のうちの１つである第２の階層構造の識別子およびバージョン情報とを含む第３の送信データを受信し、受信した前記第３の送信データに含まれる前記識別子と前記バージョン情報に対応する前記第２の階層構造が前記データベースに存在しないとき、当該第２の階層構造に関する情報を要求する。
【００２０】
そして、この要求を受けた上記送信データを送信する送信側においては、前記第２の階層構造を構成する前記複数の分類項目とそれらの親子関係に関する第１のテキストデータと、当該複数の分類項目の属性に関する第２のテキストデータを含む第２のテキストデータを含む第２の送信データを作成することにより、送信データのデータ量を削減して、送信データの作成と送信が効率よく行える。
【００２１】
【発明の実施の形態】
以下、本発明の実施形態について図面を参照して説明する。
【００２２】
図１は、本発明の実施形態に係るデータ交換装置の構成例と、このデータ交換装置を用いてデータを交換する際のシステムの構成例を示したものである。ここでは、複数（ここでは、２つ）のデータ交換装置２１ａ、２１ｂとの間でデータを交換する場合を示し、どちらも同じ構成である。データ交換装置２１ａからデータを送信し、データ交換装置２１ｂで、その送信データを受信する場合を例にとり説明する。なお、送信側と受信側のデータ交換装置の構成は同じであるので、ここでは、データ交換装置２１ａの構成を例にとり説明する。
【００２３】
図１において、データ交換装置２１ａは、表示部１と、入力部２とデータ検索部３と、送信データ作成部４と、通信部５と、受信データ解析部６と受信データ登録部７と、スキーマ記憶部８とコンテンツ記憶部９とを有する階層型データベース１０から構成される。
【００２４】
データ交換装置２１ａと２１ｂは、例えばインターネット等のネットワークを介して互いに通信可能に接続する。
【００２５】
階層型データベース１０は、１つのルートノードに複数の分類項目（部門）を階層的に関連付けた複数個の階層構造を接続した構造をもち、複数個の階層構造のそれぞれを構成する各分類項目は当該分類項目の上位階層の分類項目の属性を含む属性をもち、各分類項目には当該分類項目の属性と同じ属性をもつコンテンツデータが登録されている。スキーマ記憶部８には、上記複数個の階層構造のそれぞれを構成する分類項目と分類項目間の親子関係と、各分類項目の属性などの各階層構造に関する情報、すなわち、スキーマデータが記憶されている。コンテンツ記憶部８には、各分類項目の属性と同じ属性をもつコンテンツデータが、スキーマ記憶部８に記憶されている当該分類項目に対応付けて記憶されている。コンテンツ記憶部９に記憶されている複数の属性のそれぞれに対応する値で構成されているコンテンツデータをレコードデータとも呼ぶ。
【００２６】
スキーマ記憶部８には、上記のように、複数個の階層構造（スキーマデータ）が記憶されているが、各階層構造にはそれぞれを識別するための識別子（スキーマ識別子）が与えられている。また、各階層構造（スキーマデータ）は、随時更新される。従って、各階層構造は、その識別子とともに、バージョン情報（例えばここでは、バージョン番号（ｖｅｒｓｉｏｎ）とリビジョン番号（ｒｅｖｉｓｉｏｎ）との組み合わせで表すものとする）とともに、一意に特定するようになっている。
【００２７】
また、スキーマ記憶部８に記憶されている複数の分類項目や、分類項目間の親子関係や、属性などは、例えば、ＩＳＯ１３５８４準拠の分類項目や属性のように、予め規定されたものであり、コンテンツ記憶部９に格納されているコンテンツデータも、この規定された分類項目や属性に沿ったものである。また、分類項目や属性には、予めそれぞれを識別するための識別子（例えば、ＩＳＯ１３５８４で規定されているＢＳＵコードなど）をもつ。
【００２８】
各データ交換装置２１ａ、２１ｂは、階層構造を識別するための識別子とバージョン情報、各階層構造を構成する分類項目や属性に対し与えられた識別子（コード）により、階層構造や分類項目や属性を識別することができるものとする。従って、データ交換装置２１ａ、２１ｂで同じ識別子で同じバージョン情報のスキーマ情報が予めそれぞれのスキーマ記憶部８に記憶されているならば、当該階層構造上に登録されているコンテンツデータについて、少なくとも、それが属する分類項目が与えられれば、当該コンテンツデータがどのような属性値をもつのかは自明なこととなる。この場合、さらに、当該コンテンツデータを構成する各属性値が登録されるべき属性の識別子を明確に指定しているならば、当該コンテンツデータ中の各属性値がどの属性のものであるかも特定することができる。すると、コンテンツデータと階層構造（スキーマデータ）とは完全に分離して、コンテンツデータのみを最も簡単なテキスト形式で表してもそれを受け取るデータ交換装置２１ｂでは、何ら不都合はない。
【００２９】
入力部２は、階層型データベース１０から所望のコンテンツデータやスキーマを求めるための検索条件を入力したり、送信データ作成部４、通信部５、受信データ登録部７に対し、各種指示を入力したりするためのものである。
【００３０】
データ検索部３は、入力部２から入力された検索条件を満足するコンテンツデータや当該コンテンツデータに対応するスキーマデータを階層型データベース１０から検索し、検索結果を表示部１に表示する。
【００３１】
表示部１に表示された内容を確認して、ユーザは、入力部２から送信データとしてデータ交換部２１ｂへ送信するデータを指定する。
【００３２】
送信データ作成部４は、コンテンツ記憶部９に記憶されたコンテンツデータを例えば、ＣＳＶといったテキストデータに変換し、これを転送先（ここでは、データ交換装置２１ｂ）へ転送するための送信データ（第１の送信データ）を作成する。また、スキーマ記憶部８に記憶されたスキーマデータも例えばＣＳＶといったテキストデータに変換し、これを転送先（ここでは、データ交換装置２１ｂ）へ転送するための送信データ（第２の送信データ）を作成する。
【００３３】
より具体的には、スキーマ記憶部８から送信するコンテンツデータのスキーマを識別する識別子を取得し、分類項目別に構造化文書のタグを作成する。コンテンツデータをテキスト形式で記述し終了タグで囲む。さらに圧縮を行いたい場合、例えば入力部２から圧縮する方法を入力することによって、テキストデータ部分を圧縮して圧縮フォーマットの情報を構造化文書タグに添付する。送信するコンテンツデータが複数の分類にまたがり、なおかつそれぞれの分類でまとめられた部分がお互いに関連がある場合、その関連情報を構造化文書に記述する。
【００３４】
送信データ作成部４で作成された送信データ（第１および第２の送信データ）は、入力部２で指定された転送先（ここでは、データ交換装置２１ｂ）へ、通信部５から送信される。
【００３５】
ネットワークを介して通信部５が第１の送信データ、第２の送信データを受信すると、それらは、まず、受信データ解析部６へ送られる。
【００３６】
受信データ解析部６では、第１の送信データ中のスキーマのバージョン情報を基に、第１の送信データにて受け取ったコンテンツデータに対応するスキーマがスキーマ記憶部８に存在するかどうかをチェックする。また、受信した第１、第２の送信データが圧縮されているときには、その解凍処理を実行する。受信した第１、第２の送信データに対して受信データ解析部６において、必要な処理が施された後、第１、第２の送信データ中のコンテンツデータやスキーマデータは、受信データ登録部７に渡される。
【００３７】
受信データ登録部７は、受け取ったコンテンツデータやスキーマデータを階層型データベース１０へ登録するための処理を行う。
【００３８】
図２は、階層型データベース１０の階層構造を概略的に示したものである。図２に示すように、階層型データベース１０には、「Ｕｎｉｖｅｓａｌ」という分類項目をルートノードとし、このルートノードに、２つの階層構造（スキーマ識別子「ＡＡＡ」の階層構造（これを簡単に第１の階層構造あるいは第１のスキーマと呼ぶこともある）とスキーマ識別子「ＢＢＢ」の階層構造（これを簡単に第２の階層構造あるいは第２のスキーマと呼ぶこともある））を接続して１つの階層構造を形成している。すなわち、「Ｕｎｉｖｅｓａｌ」の子ノードとして第１の階層構造のルートノード「ＡＡＡ  ｓｃｈｅｍａ  ｒｏｏｔ」と、第２の階層構造のルートノード「ＢＢＢ  ｓｃｈｅｍａ  ｒｏｏｔ」が関連付けられ、さらに、「ＡＡＡ  ｓｃｈｅｍａ  ｒｏｏｔ」ノードに、その子ノードとして「Ｃａｒ」という分類項目のノードが関連付けられ、「Ｃａｒ」ノードに、「Ｓｅｄａｎ」と「Ｓｐｏｒｔｓ  Ｃａｒ」と「Ｗａｇｏｎ」という分類項目のノードが関連付けられた階層構造を有している。
【００３９】
これは、「Ｕｎｉｖｅｓａｌ」は、「ＡＡＡ  ｓｃｈｅｍａ  ｒｏｏｔ」と「ＢＢＢ  ｓｃｈｅｍａ  ｒｏｏｔ」という２つの分類項目に細分化され、「ＡＡＡ  ｓｃｈｅｍａ  ｒｏｏｔ」は「Ｃａｒ」という分類項目を含み、これは、「Ｓｅｄａｎ」と「Ｓｐｏｒｔｓ  Ｃａｒ」と「Ｗａｇｏｎ」という３つの分類項目に細分化されていることを表している。
【００４０】
図２に示す階層構造では、「ＡＡＡ」と「ＢＢＢ」という２つの階層構造を有する。各階層構造には、当該階層構造のバージョン情報と当該階層構造を識別するためのスキーマ識別子が記憶されている。ここでは、図３に示すように、「ＡＡＡ  ｓｃｈｅｍａ  ｒｏｏｔ」ノード以下の階層構造と「ＢＢＢ  ｓｃｈｅｍａ  ｒｏｏｔ」ノード以下の階層構造のそれぞれに「ｖｅｒｓｉｏｎ１，ｒｅｖｉｓｉｏｎ１」というバージョン情報がそれぞれ対応つけて記憶されており、また、スキーマ識別子「ＡＡＡ」と「ＢＢＢ」が対応付けて記憶されている。
【００４１】
また、階層的に関連付けられた各分類項目は、それぞれ固有の属性（点線で囲まれた部分）が定められている。各分類項目は、階層構造における当該分類項目の上位階層の分類項目の属性を継承する。例えば、「Ｃａｒ」ノードのもつ属性は、「Ｃａｒ」ノード自身の固有の属性の他、その上位ノード「ＡＡＡ  ｓｃｈｅｍａ  ｒｏｏｔ」ノードそれぞれの固有の属性を継承する。すなわち、「Ｃａｒ」ノードは、「ＡＡＡ  ｓｃｈｅｍａ  ｒｏｏｔ」ノードに定義されている属性（「製造会社名」）と、「Ｃａｒ」ノードに定められた属性（「製品コード」、「販売価格」）を有する。
【００４２】
また、「Ｓｅｄａｎ」ノードは、その上位ノード「Ｃａｒ」ノードと「ＡＡＡｓｃｈｅｍａ  ｒｏｏｔ」ノードそれぞれの固有の属性を継承する。すなわち、「Ｃａｒ」ノードに定義されている属性（「製品コード」、「販売価格」）と、「ＡＡＡ  ｓｃｈｅｍａ  ｒｏｏｔ」ノードに定義されている属性（「製造会社名」）を有する。
【００４３】
このようなデータモデルは、部品ライブラリの交換フォーマットの国際標準であるＩＳＯ１３５８４／Ｐａｒｔｓ  Ｌｉｂｒａｒｙ（ＰＬＩＢ）で用いられているものと基本的に同じである。なおＰＬＩＢでは、各分類、属性を識別するコード体系として、世の中で一意なコードであることを保証したＢＳＵコードを用いている。ここでは説明の簡単化のために、図３に分類項目名、属性名に括弧書きで、上記ＢＳＵコードと同様な役割をする、分類項目を識別するための分類識別子や属性を識別するための属性識別子を記している。
【００４４】
各階層構造はスキーマとも呼び、当該階層構造を表す情報（例えば、階層構造を構成する複数の分類項目や、それらの親子関係（接続関係）、各分類項目に定められた属性などを表す情報）をスキーマデータと呼ぶ。ここでは、各スキーマには「ＡＡＡ」や「ＢＢＢ」といったスキーマ識別子とバージョン情報をもつ。このスキーマ識別子やバージョン情報も各スキーマデータに含まれる情報である。
【００４５】
なお、上記各分類項目と、それらで構成される図２や図３に示したような階層構造は、スキーマ記憶部８に、例えば図４に示すように、各分類項目の分類識別子と分類項目名と、当該分類項目の親ノードである分類項目の分類識別子とで記憶されている。また、各分類項目の属性は、スキーマ記憶部８に、例えば図５に示すように、分類項目の分類識別子と当該分類項目がもつ固有の属性の属性識別子と属性名と当該属性の値のデータ型とで記憶されている。
【００４６】
図４や図５では、各分類項目の分類識別子が、当該分類項目が属するスキーマのスキーマ識別子を含む構成となっているので、分類識別子からそれが属するスキーマが何であるかを識別することができる。
【００４７】
また、図６は、スキーマ記憶部８に記憶されているスキーマのバージョン情報の記憶例を示したもので、ここでは、各スキーマに属する階層構造の先頭ノードに対応する分類項目の分類識別子に、当該分類項目以下の階層構造に対応するスキーマのバージョン情報を記憶するようになっている。
【００４８】
図４、図５、図６に示したデータが上記スキーマデータに対応するものである。
【００４９】
なお、バージョン情報は、バージョン（ｖｅｒｓｉｏｎ）とリビジョン（ｒｅｖｉｓｉｏｎ）からなり、元のスキーマから大幅に改正された場合には、ｖｅｒｓｉｏｎの値が１つインクリメントされ、元のスキーマからわずかに改正された場合にはｖｅｒｓｉｏｎの値は更新されずに、ｒｅｖｉｓｉｏｎの値が１つインクリメントされるものとする。
【００５０】
スキーマは、スキーマ識別子とバージョン情報から一意に特定することができる。
【００５１】
図３に示した各分類項目には、当該分類項目がもつ属性（当該分類項目に固有の属性と、当該分類項目の上位階層の分類項目から承継した属性）のそれぞれに対応する値で構成されたコンテンツデータが登録されている。コンテンツ記憶部９には、スキーマ記憶部８に記憶されている各分類項目に対応付けられているコンテンツデータが記憶されている。
【００５２】
図７〜図９に、コンテンツ記憶部９に記憶されているコンテンツデータの記憶例を示す。図７は、分類項目「Ｃａｒ」（分類識別子「ＡＡＡ＿Ｃ０１」）と、分類項目「Ｓｅｄａｎ」（分類識別子「ＡＡＡ＿Ｃ０２」）と、分類項目「Ｓｐｏｒｔｓ  Ｃａｒ」（分類識別子「ＡＡＡ＿Ｃ０３」）のそれぞれに対応付けられているコンテンツデータを対応付けるためのテーブルを示したものである。ここではコンテンツデータは、テーブル形式で記憶しているため、図７に示すテーブルでは、各分類識別子と、当該分類識別子に対応する分類項目に対応付けられたコンテンツデータを記憶するテーブル名との対応関係が記憶されている。
【００５３】
図８は、分類項目「Ｃａｒ」（分類識別子「ＡＡＡ＿Ｃ０１」）に対応付けられたコンテンツデータを記述したテーブル（Ｃ０１＿ＴＢＬ）の記憶例を示し、図９は、分類項目「Ｓｅｄａｎ」（分類識別子「ＡＡＡ＿Ｃ０２」）に対応付けられたコンテンツデータを記述したテーブル（Ｃ０１＿ＴＢＬ）の記憶例を示している。
【００５４】
分類項目「Ｃａｒ」や分類項目「Ｓｅｄａｎ」は、それぞれ「製造会社名」（属性識別子ＴＯＰ＿ＰＴ００００３）、「販売価格」（属性識別子ＴＯＰ＿ＰＴ００００４）、「製品コード」（属性識別子ＴＯＰ＿ＰＴ００００５）という属性をもつので、図８，図９に示すように、１つのレコードデータは、これら３つの各属性に対応する値から構成されている。
【００５５】
ここで、図１に示した構成のデータ交換装置間でのデータ転送について、簡単に説明する。
【００５６】
本実施形態では、データ交換装置２１ａの階層型データベース１０に格納されているデータを（コンテンツデータと、当該コンテンツデータに対応するスキーマデータ）をデータ交換装置２１ｂに転送して、そこの階層型データベース１０に格納する（移植する）ために、まず、データ交換装置２１ａの階層型データベースから検索されたコンテンツデータをデータ交換装置２１ｂへ送信する。その際、作成される送信データ（第１の送信データ）には、当該コンテンツデータに対応するスキーマの識別子（スキーマ識別子）とバージョン情報が含まれている。また、各コンテンツデータは、それが属する分類項目別に、各コンテンツデータを構成する各属性値間をコンマで区切り、各コンテンツデータ間は改行コードで区切る単純なテキスト形式（いわゆるＣＳＶ（ｃｏｍｍａ  ｓｅｐａｒａｔｅｄ  ｖａｌｕｅ））で含まれている。なお、ここでは、コンテンツデータを構成する各属性値間を区切り区切りコード（第１の区切りコード）としてコンマを用い、コンテンツデータ間を区切る区切りコード（第２の区切りコード）として改行コードを用いたが、この場合に限らない。例えば、第１の区切りコードとして、例えば、コンマ以外にも、コロン（：）、セミコロン（；）、タブコードなどであってもよい。また、第２の区切りコードとして、改行コード以外にも、例えば、ピリオド（．）コードや、さらに、第１の区切りコードとして用いたコードより区切りが強くなるものであれば、コロン（：）、セミコロン（；）、タブコードなどであってもよい。
【００５７】
従来ならコンテンツデータとスキーマデータの両方を送るべきところを、コンテンツデータとスキーマを完全に分類して、まずコンテンツデータのみを送信する。しかも送信データ中のコンテンツデータは上記のような単純なＣＳＶ形式であるため、送信データを作成するための処理時間を短縮することができるとともに、送信データのデータ量そのものを削減することができるのである。
【００５８】
また、受信側のデータ交換装置２１ｂでは、上記第１の送信データを受信すると、その中に含まれるスキーマ識別子とバージョン情報とから、それらで特定されるスキーマデータが自分のスキーマ記憶部８に格納されているかを調べ、なければ、そのようなスキーマをデータ交換装置２１ａへ要求する。この要求を受けたときに、データ交換装置２１ａでは、スキーマデータを第２の送信データとしてデータ交換装置２１ｂへ送信する。その際、スキーマデータはＣＳＶ形式で送信する。すなわち、第２の送信データでは、スキーマデータを各分類項目に関するデータ（図４参照）と、分類項目に定義されている属性に関するデータ（図５参照）とに分けて、それらを構成する各項目間をコンマ、コロン（：）、セミコロン（；）、タブコードやピリオド（．）、改行コードなどの区切りコードで区切るだけのテキストデータとして送信している。
【００５９】
スキーマデータもこのようにＣＳＶ形式で送信するため、やはり、送信データを作成するための処理時間を短縮することができるとともに、送信データのデータ量そのものを削減することができる。
【００６０】
コンテンツデータと階層構造を切り離して、最初にコンテンツデータのみを送信し、コンテンツデータやスキーマデータはＣＳＶ形式で送信するということは、送信側と受信側のデータ交換装置２１ａ、２１ｂが、それぞれ同じスキーマを解釈することができるという仮定に基づくものであり、受信側で受け取ったコンテンツデータを理解できないときに（第１の送信データに含まれるスキーマ識別子とバージョン情報に対応するスキーマをもたないとき）に、初めてスキーマデータを送信する。もっとも、送信側にて、最初から受信側のデータ交換装置２１ｂがこれから送ろうとするコンテンツデータに対応するスキーマを持たないことがわかっているのなら、コンテンツデータとともに、スキーマを一緒に送るようにしてもよい。この場合においてもコンテンツデータとスキーマデータは、それぞれＣＳＶ形式で送るので、やはり、送信データを作成するための処理時間を短縮することができるとともに、送信データのデータ量そのものを削減することができる。
【００６１】
ここで、スキーマデータのバージョンについて説明する。前述したように、スキーマはスキーマ識別子をバーション情報（ｖｅｒｓｉｏｎとｒｅｖｉｓｉｏｎの値の組合せ）から一意に特定することができる。また、バージョン情報から互換可能性を判断することができる。
【００６２】
すなわち、あるスキーマ識別子のスキーマについて、送信先であるデータ交換装置２１ｂのスキーマ記憶部８に記憶されているスキーマのバージョン情報が送信元であるデータ交換装置２１ａのスキーマ記憶部８に記憶されているスキーマのバージョン情報（データ交換装置２１ａからデータ交換装置２１ｂへコンテンツデータとともに送られてきたスキーマのバージョン情報）と同じかあるいは新しいならば（ｖｅｒｓｉｏｎとｒｅｖｉｓｉｏｎの値が同じか、ｖｅｒｓｉｏｎの値が大きい、あるいはｖｅｒｓｉｏｎの値が同じでｒｅｖｉｓｉｏｎの値が大きい場合）、データ交換装置２１ａから送信されるコンテンツデータに、当該スキーマ記憶部８に記憶されているスキーマを適用することができる。すなわち互換可能である。しかし、データ交換装置２１ｂのスキーマ記憶部８に記憶されているスキーマのバージョン情報が、データ交換装置２１ａからデータ交換装置２１ｂへコンテンツデータとともに送られてきたスキーマのバージョン情報より古い場合（ｖｅｒｓｉｏｎの値が小さい、あるいはｖｅｒｓｉｏｎの値が同じでｒｅｖｉｓｉｏｎの値が小さい場合）、データ交換装置２１ａから送信されるコンテンツデータに、当該スキーマ記憶部８に記憶されているスキーマを適用することができない。なぜなら、データ交換装置２１ａから送信される新しいバージョンのスキーマに対応するコンテンツデータには、古いバージョンでは定義されていない分類項目や属性が追加されている、あるいは古いバージョンで定義されている分類項目や属性が削除されている等の可能性があり、この新しいバージョンのスキーマに対応するコンテンツデータを正確に解釈することができないからである。
【００６３】
例えば、送信側のデータ交換装置２１のスキーマ記憶部８には、スキーマ識別子「ＡＡＡ」のスキーマがバージョンアップして、図１０に示すように、「ＴＲＵＣＫ」という分類項目が分類項目「Ｃａｒ」の子ノードとして追加され、また、分類項目「Ｓｅｄａｎ」に「属性ｘ」という新たな属性が追加されたとする。この時の階層型データベースの状態を図１１に示す。図１１に示すように、スキーマ識別子「ＡＡＡ」のスキーマのバージョン情報は、「ｖｅｒｓｉｏｎ２、ｒｅｖｉｓｉｏｎ１」であり、これが「ＡＡＡ  ｓｃｈｅｍａ  ｒｏｏｔ」ノードに記憶されている。また、「Ｓｅｄａｎ」ノードには、「属性ｘ（属性識別子ＡＤ０１）」が追加されている。
【００６４】
受信側のデータ交換装置２１ｂのスキーマ記憶部８に記憶されているスキーマ識別子「ＡＡＡ」のスキーマも同様にバージョンアップされているならば（バージョン情報が「ｖｅｒｓｉｏｎ２、ｒｅｖｉｓｉｏｎ１」であるスキーマに更新されているならば）、このスキーマに対応するコンテンツデータを受け取っても、それをコンテンツ記憶部９に登録することができる。
【００６５】
しかし、受信側のデータ交換装置２１ｂのスキーマ記憶部８では、スキーマ識別子「ＡＡＡ」のスキーマが更新されず、図２に示す構造のスキーマが記憶されているとする。すなわち、スキーマ識別子「ＡＡＡ」のスキーマのバージョン情報は、「ｖｅｒｓｉｏｎ１、ｒｅｖｉｓｉｏｎ１」であるとする。このときの階層型データベースの状態は図３に示すとおりである。
【００６６】
この場合には、データ交換装置２１ａから送信されるスキーマ識別子「ＡＡＡ」のスキーマに対応するコンテンツデータを受信しても（例えば、図２４に示すような内容の構造化文書の送信データを受信する）、データ交換装置２１ｂでは、それを解釈することができず（図２４に含まれている「ＴＲＵＣＫ」という分類項目や、「Ｓｅｄａｎ」という分類項目に新たに追加された、「属性ｘ（属性識別子ＡＤ０１）」や、それに対応するコンテンツデータ中の値（図２４の５行目から７行目の「ａｂｃ」「ｄｅｆ」「ｇｈｉ」）をそれが何であるかを識別することができない）、コンテンツ記憶部９には、それを登録することができない。この場合、データ交換装置２１ｂは、データ交換装置２１ａに対し、新たなバージョンのスキーマを要求する必要がある。この要求を受けたときに、データ交換装置２１ａは、スキーマ識別子「ＡＡＡ」のスキーマであって、バージョン情報が「ｖｅｒｓｉｏｎ２、ｒｅｖｉｓｉｏｎ１」であるバージョンをスキーマ記憶部８から読み出して、データ交換装置２１ｂへ送信することとなる。
【００６７】
次に、図１２に示すフローチャートを参照して、図１に示したデータ交換装置２１ａ、２１ｂとの間のデータ転送について、より詳細に説明する。ここでは、データ交換装置２１ａの階層型データベース１０が図３に示す状態であるとする。
【００６８】
まず、送信側のデータ交換装置２１ａの処理動作について説明する。データ交換装置２１へ送信すべきコンテンツデータを取得すべく、ユーザは、検索条件を入力部２に入力する。これを受けて、データ検索部３は、入力された検索条件を満たすコンテンツデータを検索する（ステップＳ１）。
【００６９】
検索条件としては、例えば、単純にキーワードをのみであってもよいが、階層型データベース１０内の分類項目を指定するものであってもよい。また、属性と、その属性の値に含まれているような文字列を検索条件として与えるようにしてもよい。また、検索範囲を指定することもでできる。ここでは、説明の簡単のため、検索範囲と、属性と、その値に含まれる文字列を検索条件として与える場合を例にとり説明する。
【００７０】
例えば、「分類項目「Ｃａｒ」に対応するノード以下から属性「製造会社名」の値が「Ａ社」であるコンテンツデータを検索する旨の検索条件が入力されたとする。この検索条件では、検索範囲として「分類項目「Ｃａｒ」に対応するノードの子孫ノード」が指定され、属性として「製造会社名」が指定され、その値として「Ａ社」が指定されている。
【００７１】
この検索条件を基に、データ検索部３は、スキーマ記憶部８に記憶されたスキーマと、コンテンツ記憶部９に記憶されたコンテンツデータを検索して、分類項目「Ｃａｒ」に対応するノード以下から属性「製造会社名」の値が「Ａ社」であるコンテンツデータを検索する。すなわち、図３に示したように、分類項目「Ｃａｒ」の子ノードとして「Ｓｅｄａｎ」、「Ｓｐｏｒｔｓ  Ｃａｒ」「Ｗａｇｏｎ」があるので、これら４つ分類のそれぞれに属するコンテンツデータの中から属性「製造会社名」が「Ａ社」であるコンテンツデータを検索する。
【００７２】
なお、検索条件を基に、当該検索条件を満足するコンテンツデータを検索する手法は、公知公用の技術を用いればよく、本願発明の要旨ではないので、説明は省略する。
【００７３】
検索の結果、図１３に示すように、５つのコンテンツデータが得られたとする。この検索結果は、表示部１によりディスプレイ装置に表示される。
【００７４】
なお、図１２のステップＳ１におけるデータ検索処理のより詳細な処理動作を図１４に示す。ここでは、検索条件を入力するための入力画面を表示するために、まず、スキーマ記憶部８からスキーマデータを読込み（ステップＳ１ａ）、その読み込んだスキーマデータに不整合がないかどうか確認し（ステップＳ１ｂ）、不整合がなければステップＳ１ｃへ進み、不整合があればステップＳ１ｅへ進み、エラーメッセージを表示部１に表示して、検索処理を中止する。ステップＳ１ｃでは、読み込んだスキーマデータを基に表示された、検索条件の入力画面上にユーザにより入力された検索条件を基に、コンテンツデータを検索する。そして、検索結果を表示部１から所定のディスプレイ装置に表示する。
【００７５】
なお、データ検索部３での検索は、入力された検索条件を満たすコンテンツデータを検索するとともに、当該コンテンツデータに対応するスキーマデータを取得している。例えば、ここでは、検索範囲として分類項目「Ｃａｒ」以下のノードが指定されているから、スキーマもこの分類項目を含むスキーマであり、これは、図３に示す階層構造からも明らかなように、スキーマ識別子「ＡＡＡ」のスキーマである。また、このとき、当該スキーマのバージョン情報も取得する。
【００７６】
さて、図１２の説明に戻り、表示部１で表示された検索結果をユーザが確認し、例えば、この検索結果として得られた全てのコンテンツデータが送信すべきデータとして指定されたとする（ステップＳ２）。
【００７７】
次に、送信データ作成部４は、指定されたコンテンツデータを送信すべく、送信データの作成を行う（ステップＳ３）。ここで作成する送信データ（コンテンツデータを送信するための送信データであって、ここではこれを第１の送信データと呼ぶ）は、前述したように、データ検索部３で検索した結果得られたスキーマの識別子とバージョン情報と、ＣＳＶ形式で書き表された、送信すべきコンテンツデータとを含むものである。
【００７８】
ここで、図１５に示すフローチャートに従って、送信データ作成部４の送信データ作成処理について詳細に説明する。図１６、図１７は、送信データ作成部４で作成された第１の送信データの具体例を示したもので、図１６はコンテンツデータを圧縮せずに作成された第１の送信データであり、図１７は、コンテンツデータを圧縮して作成された第１の送信データを示している。図１６，図１７に示すように、送信データは、例えば、構造化文書であり、ここではその一例としてＸＭＬで記述されたＸＭＬ文書である場合について説明する。
【００７９】
以下、図１６、図１７を参照して送信データ作成処理について説明する。
【００８０】
ステップＳ３−１：まず、送信データのヘッダ情報を作成する。図１６に示すように、ヘッダ情報として、１行目のタグ＜？ｘｍｌ  ｖｅｒｓｉｏｎ＝”１．０”  ｅｎｃｏｄｉｎｇ＝”Ｓｈｉｆｔ＿ＪＩＳ”？＞を作成する。ここには、シフトＪＩＳコードでエンコードされている旨が記述されている。次に、図１６に示すように、ヘッダ情報として２行目のタグ＜ｄｉｃｔｉｏｎａｒｙ  ｄｉｃ＝”ＡＡＡ”  ｓｕｐｐｌｉｅｒ＿ｂｓｕ＿ｃｏｄｅ＝”ＴＯＰＡＳ／０１４０”＞を作成する。ここには、これから送信するコンテンツデータに対応するスキーマの識別子「ＡＡＡ」と、当該スキーマのバージョン情報「ｖｅｒｓｉｏｎ１、ｒｅｖｉｓｉｏｎ１」が記述されている。なお、２行目のタグには「ｓｕｐｐｌｉｅｒ＿ｂｓｕ＿ｃｏｄｅ」とあるが、これは、スキーマの発行に責任をもつ団体（以後、サプライヤと呼ぶ）に対する識別コードである。図２や図３などに示した階層型データベース１０上では、サプライヤに関するデータを省略しているが、スキーマ情報にはもちろんサプライヤに関する情報も含まれる。
【００８１】
ステップＳ３−２：データ検索部３で検索された結果得られたスキーマから、送信すべきコンテンツデータの属する分類項目を取出す。ここでは、送信すべきコンテンツデータは、図１３に示したように、「Ｓｅｄａｎ」と「ＳｐｏｒｔｓＣａｒ」の２種類の分類項目に属するものであるから、この２つの分類項目をスキーマ識別子「ＡＡＡ」のスキーマから取得する。なお、ここでは、分類項目別に送信すべきコンテンツデータをまとめて、それを送信データであるＸＭＬ文書を構成する１つの要素として記述する。この分類項目別の要素をユニットとも呼ぶ。
【００８２】
ステップＳ３−３：ステップＳ３−２で取得した分類項目のそれぞれから送信データであるＸＭＬ文書を構成する１つの要素（ユニット）のタグ（ユニット開始タグ）を１つずつ作成する。ここでは、まず、１つ目の分類項目「Ｓｅｄａｎ」の分類識別子「ＡＡＡ＿Ｃ０２」を用いて、図１６の３行目に示すように＜ｃｏｎｔｅｎｔ  ｃｌａｓｓｂｓｕ＝”ＡＡＡ＿Ｃ０２”＞というタグを作成する。
【００８３】
ステップＳ３−４：ユニット毎にデータの圧縮を行う場合には、ステップＳ３−９へ進み、圧縮しない場合には、ステップＳ３−５へ進む。
【００８４】
ステップＳ３−５：ステップＳ３−３で作成されたユニット開始タグから開始するユニットの値として、当該ユニット開始タグに対応する分類項目に属するコンテンツデータをＣＳＶ形式で記述する。図１３から、分類項目「Ｓｅｄａｎ」に属するコンテンツデータは、「製品コード」、「販売価格」、「製造会社」という３つの属性の値から構成されるものである。まず、要素値として、この各属性の識別子をコンマで区切りながら記述していき、最後に改行コードをつける。その結果が図１６の４行目に対応する。次に、各コンテンツデータ（ここでは、３つののコンテンツデータ）について、その各属性値をコンマで区切りながら記述していき、各コンテンツデータの最後の属性値を記述した後に改行コードを付ける（改行する）。その結果、図１６の５行目〜７行目に示すように、各コンテンツデータが各１行に記述される。このようにして、全てのコンテンツデータについて記述し終えると、ステップＳ３−６へ進み、図１６の６８行目に示すように、当該ユニットの終了タグを記述する。次に、ステップＳ３−３に戻り、次のユニット開始タグを作成する。
【００８５】
ステップＳ３−３：２つ目の分類項目「Ｓｐｏｒｔｓ  Ｃａｒ」の分類識別子「ＡＡＡ＿Ｃ０３」を用いて、図１６の９行目に示すように、＜ｃｏｎｔｅｎｔｃｌａｓｓｂｓｕ＝”ＡＡＡ＿Ｃ０３”＞というタグを作成する。上記同様圧縮しない場合には、ステップＳ３−５へ進み、当該ユニットの値として、当該ユニット開始タグに対応する分類項目に属するコンテンツデータをＣＳＶ形式で記述する。図１３から、分類項目「Ｓｐｏｒｔｓ  Ｃａｒ」に属するコンテンツデータは、上記同様「製品コード」、「販売価格」、「製造会社」という３つの属性の値から構成されるものである。従って、要素値として、この各属性の識別子をコンマで区切りながら記述していき改行した後、各コンテンツデータ（ここでは、２つののコンテンツデータ）について、その各属性値をコンマで区切りながら記述していき、各コンテンツデータの最後の属性値を記述した後に改行する。その結果を、図１６の１０目〜１２行目に示す。全てのコンテンツデータについて記述し終えると、ステップＳ３−６へ進み、図１６の１３行目に示すように当該ユニットの終了タグを記述する。
【００８６】
ステップＳ３−７：全てのユニットの作成と記述が終了すると、ステップＳ３−８へ進み、図１６の１４行目に示すように、終了タグを記述して、送信データ（ここでは、第１の送信データ）の作成が終了する。
【００８７】
なお、図１５のステップＳ３−４において、各ユニットの値を圧縮する場合について、図１７に示す送信データを参照して説明する。この場合は、ます、ステップＳ３−９へ進み、ユニット開始タグ（図１７の３行目）の次に、圧縮開始タグ（図１７の４行目）を記述する。この圧縮開始タグ＜ｃｏｍｐｒｅｓｓ＞には、それに適用する圧縮形式を記述する。そして、ステップＳ３−５と同様にして、当該ユニットについて要素値をＣＳＶ形式でテンポラリファイルに記述した後、そのファイルに対し所定の圧縮処理を行った結果得られた当該ファイルの内容をバイナリ形式で記述して（ステップＳ３−１１、ステップＳ３−１２）、圧縮終了タグ＜ｃｏｍｐｒｅｓｓ＞を記述した後に（ステップＳ３−１３）、当該ユニットの終了タグを記述する（ステップＳ３−６）。
【００８８】
このようにして、図１６や図１７に示したようにして第１の送信データが作成されると、図１２のステップＳ４において、ユーザにより当該第１の送信データの送信先（転送先）が指定される。
【００８９】
この送信先の指定は、例えば、ＧＵＩ画面上で上記第１の送信データをシンボル化して表示し、当該シンボルを同じくＧＵＩ画面上に表示されている送信先（データ交換装置２１ｂ）のシンボル上にドラッグ＆ドロップすることによって転送先を指定する。
【００９０】
転送先が指定されると、当該転送先（データ交換装置２１ｂ）に向けて、上記第１の送信データが通信部５から送信される（ステップＳ５）。
【００９１】
ここで、図１８に示すフローチャートを参照して、ステップＳ５のデータ転送処理についてより詳細に説明する。
【００９２】
データ交換装置２１ａは、ユーザからのデータ転送指示を（入力部２）から受けると、当該ユーザにログイン情報の入力を要求する。その結果、入力部２から入力された当該ユーザのログイン情報を取得する（ステップＳ５−１）。データ交換装置２１ａ、２１ｂには、図１には、図示していないが、当該装置を使用する各ユーザについて、データ転送処理の実行が可能な権限を有するか否かを表す情報を所定の記憶手段に記憶するようになっている。このような情報を検索するために、ユーザにログイン情報の入力を要求するのである。入力部２から入力されたログイン情報から当該記憶手段に記憶されている情報を検索した結果、当該ユーザがデータ転送処理の実行が可能な権限を有する者であることが確認されたときは（ステップＳ５−２）、当該送信データを通信部５から送信するために、一時記憶用のメモリ領域内に、当該送信データを保存する（ステップＳ５−３）。すると、通信部５は、当該メモリ領域から送信データを読み取って、指定された送信先（データ交換装置２１ｂ）へと送信を開始する。
【００９３】
図１２の説明に戻り、上記のようにして、第１の送信データがデータ交換装置２１ａから送信されて、データ交換装置２１ｂの通信部５が、当該第１の送信データを受信すると、データ交換装置２１ｂの処理動作が開始する（ステップＳ６）。受信した第１の送信データは、受信データ解析部６へ渡される。
【００９４】
受信データ解析部６では、受け取った第１の送信データ中のヘッダ情報に含まれているスキーマ識別子（ここでは「ＡＡＡ」）と、当該スキーマのバージョン情報（ここでは、「ｖｅｒｓｉｏｎ１、ｒｅｖｉｓｉｏｎ１」）を取出し、これらに対応するスキーマデータ（互換可能なスキーマデータを含む）が自身のスキーマ記憶部８に格納されているかを確認する（ステップＳ７）。前述したように、▲１▼スキーマ記憶部８にスキーマ識別子が「ＡＡＡ」のスキーマデータが記憶されていないとき、あるいは▲２▼スキーマ記憶部８にスキーマ識別子が「ＡＡＡ」のスキーマデータが記憶されているが、そのバージョン情報が上記第１の送信データ中に含まれていたバージョン情報より古い場合には、当該スキーマデータの転送をデータ交換装置２１ａへ要求すべく、スキーマ要求メッセージを通信部５から送信する（ステップＳ８）。
【００９５】
一方、ステップＳ７において、スキーマ記憶部８に、バージョン情報が上記第１の送信データ中に含まれていたバージョン情報と同じかあるいは新しい、スキーマ識別子が「ＡＡＡ」のスキーマデータが記憶されているときには、ステップＳ１３へ進み、当該受信した第１の送信データに含まれているコンテンツデータをコンテンツ記憶部９に登録するための処理を開始する。
【００９６】
ここで、図１２のステップＳ６〜ステップＳ８のデータ受信処理について、図１９に示すフローチャートを参照して、より詳細に説明する。
【００９７】
通信部５で、図１６に示した第１の送信データを受信すると、上記ステップＳ７で説明したように、当該第１の送信データに含まれるスキーマ識別子とバージョン情報を取出す。すなわち、図１６に示した送信データの場合、２行目の＜ｄｉｃｔｉｏｎａｒｙ＞タグの属性「ｄｉｃ」に記述されているスキーマ識別子「ＡＡＡ」と、属性「ｖｅｒｓｉｏｎ」，「ｒｅｖｉｓｉｏｎ」のそれぞれに記述されている値を取り出す。
【００９８】
スキーマ記憶部８を検索して、スキーマ識別子が「ＡＡＡ」であるスキーマが記憶されているか検索する。記憶されている場合に、その「ｖｅｒｓｉｏｎ」と「ｒｅｖｉｓｉｏｎ」の値が第１の送信データ中のものと同じであるとき、あるいは異なるが受信側の方が新しい場合には、互換可能と判定する（ステップＳ１０２）。ただし、個々の分類においてコンテンツの登録時に再度エラーチェックは必要となる。ここで、互換スキーマが存在した場合は、ステップＳ１０３の圧縮解凍へ進む。互換スキーマが存在しない場合には（ステップＳ１０２）、ステップＳ１０５へ進む。
【００９９】
ステップＳ１０５では、データ交換装置２１ｂのユーザに対し、現在スキーマ記憶部８にはない当該スキーマデータを新たに登録するか、あるいは更新するか否かを確認する。新たに登録する、あるいは更新する旨の指示が入力されたときには、ステップＳ１０６へ進み、新たに登録しない、あるいは更新しない旨の入力がされたときには、ステップＳ１２０へ進み、エラー処理後終了する。
【０１００】
ステップＳ１０６では、受信した第１の送信データのヘッダ情報に含まれていたスキーマ識別子とバージョン情報に一致するスキーマデータが当該第１の送信データ中に含まれているか否か確認する。
【０１０１】
図１５では、スキーマデータは送らずに、コンテンツデータを送る場合を示しているが、送信側にて、最初から受信側のデータ交換装置２１ｂがこれから送ろうとするコンテンツデータに対応するスキーマを持たないことがわかっているのなら、最初からコンテンツデータとともに、スキーマを一緒に送ることもあり得るからである。受信した第１の送信データのヘッダ情報に含まれていたスキーマ識別子とバージョン情報に一致するスキーマデータが当該第１の送信データ中に含まれているときには、ステップＳ１０３へ進み、含まれていないときには、ステップＳ１０７へ進み、データ交換装置２１ａに対し、スキーマの要求メッセージを送信する。
【０１０２】
一方、ステップＳ１０３では、受信した第１の送信データ中の各ユニット内のコンテンツデータが圧縮されているか否か確認する。ユニット内に圧縮開始タグ＜ｃｏｍｐｒｅｓｓ＞が含まれているときには、当該ユニット内のコンテンツデータは圧縮されているので、そのような各ユニット内のデータに対し所定の解凍処理を行う（ステップＳ１０４）。なお、圧縮方式は図１７の４行目に示したように、＜ｃｏｍｐｒｅｓｓ＞タグの「ｔｙｐｅ」属性として記述されているので、これに対応する解凍処理を行えばよい。
【０１０３】
解凍処理後の各ユニット内のコンテンツデータや、もともと圧縮されていないコンテンツデータを、受信データ登録部７へ渡し、ここで、データ登録処理が開始される。
【０１０４】
図１９のステップＳ１０７（図１２のステップＳ８）において、データ交換装置２１ｂがデータ交換装置２１ａに対して、スキーマ要求メッセージを送信した場合について、図１２を参照して説明する。
【０１０５】
データ交換装置２１ａがデータ交換装置２１ｂから送信されたスキーマ要求メッセージを受信すると（ステップＳ９）、送信データ作成部４では、先にデータ検索処理で得られたスキーマ識別子「ＡＡＡ」でバージョン情報が「ｖｅｒｓｉｏｎ１、ｒｅｖｉｓｉｏｎ１」であるスキーマデータを送信するための送信データ（第２の送信データ）を作成する（ステップＳ１０）。
【０１０６】
第２の送信データの作成処理動作は、前述の第１の送信データの作成処理動作をほぼ同様であり、以下、図１５のフローチャートを参照して、図２０に示す、スキーマ識別子「ＡＡＡ」でバージョン情報が「ｖｅｒｓｉｏｎ１、ｒｅｖｉｓｉｏｎ１」であるスキーマデータを送信するための第２の送信データの作成処理動作について説明する。なお、第１の送信データの作成処理と異なる部分を中心に説明する。
【０１０７】
ステップＳ３−１：まず、第１の送信データを作成する場合と同様、第２の送信データのヘッダ情報を作成する。図２０に示すように、ヘッダ情報として、まず１行目のタグ＜？ｘｍｌ  ｖｅｒｓｉｏｎ＝”１．０”  ｅｎｃｏｄｉｎｇ＝”Ｓｈｉｆｔ＿ＪＩＳ”？＞と、２行目のタグ＜ｄｉｃｔｉｏｎａｒｙ  ｄｉｃ＝”ＡＡＡ”  ｓｕｐｐｌｉｅｒ＿ｂｓｕ＿ｃｏｄｅ＝”ＴＯＰＡＳ／０１４０”＞を作成する。
【０１０８】
ステップＳ３−２：データ検索部３で検索された結果得られたスキーマ（スキーマ識別子「ＡＡＡ」というスキーマ）の各分類項目に関する図４に示したデータと、属性に関する図５に示したデータをスキーマ記憶部８から読み出す。なお、ここでは、スキーマデータをスキーマの分類項目に関するデータ（図４に示したデータ）と属性に関するデータ（図５に示したデータ）とに分けて、それぞれを送信データであるＸＭＬ文書を構成する１つの要素として記述する。このスキーマの分類項目に関するデータと属性に関するデータのそれぞれに対応する要素をユニットとも呼ぶ。
【０１０９】
ステップＳ３−３：まず、図２０の３行目に示すように、スキーマであることを表すタグ＜ｄｉｃ＿ｅｌｅｍｎｔ＞を記述した後、ステップＳ３−２で取得したスキーマの分類項目に関するデータと属性に関するデータのそれぞれに対応するタグ（ユニット開始タグ）を１つずつ作成する。ここでは、まず、１つ目の、スキーマの分類項目に関するデータを記述するためのユニットの開始タグ、＜ｃｌａｓｓ＞タグ（図２０の４行目）を作成する。
【０１１０】
ステップＳ３−４：ユニット毎にデータの圧縮を行う場合には、ステップＳ３−９へ進み、圧縮しない場合には、ステップＳ３−５へ進む。
【０１１１】
ステップＳ３−５：ステップＳ３−３で作成されたユニット開始タグから開始するユニットの値として、図４に示したような分類項目に関するデータをＣＳＶ形式で記述する。図４に示すように、スキーマ「ＡＡＡ」を構成する各分類項目については、「分類識別子」と「分類項目名」と「上位分類識別子」と「定義」というフィールド毎にデータが記述されているので、まず、これら各フィールド名をコンマで区切りながら記述していき、最後に改行コードをつける。その結果が図２０の５行目に対応する。次に、各分類項目について、その各フィールドのデータをコンマで区切りながら記述していき、各分類項目の最後のフィールドのデータを記述した後に改行コードを付ける（改行する）。その結果、図２０の６行目〜９行目に示すように、各分類項目に関するデータが各１行に記述される。このようにして、「ＡＡＡ」スキーマを構成する全ての分類項目に関するデータについて記述し終えると、ステップＳ３−６へ進み、図２０の１０行目に示すように、当該ユニットの終了タグを記述する。次に、ステップＳ３−３に戻り、次のユニット開始タグを作成する。
【０１１２】
ステップＳ３−３：２つ目の、属性に関するデータを記述するためのユニットの開始タグ、＜ｐｒｏｐｅｒｔｙ＞タグ（図２０の１１行目）を作成する。上記同様圧縮しない場合には、ステップＳ３−５へ進み、当該ユニットの値として、図５に示したような属性に関するデータをＣＳＶ形式で記述する。図４に示したように、スキーマ「ＡＡＡ」を構成する各分類項目の属性については、当該属性が定義されている「分類識別子」と当該属性の「属性識別子」と「属性名」と「データ型」というフィールド毎にデータが記述されているので、まず、これら各フィールド名をコンマで区切りながら記述していき、最後に改行コードをつける。
【０１１３】
その結果が図２０の１２行目に対応する。次に、各属性について、その各フィールドのデータをコンマで区切りながら記述していき、各属性の最後のフィールドのデータを記述した後に改行コードを付ける（改行する）。その結果、図２０の１３行目〜１５行目に示すように、各属性に関するデータが各１行に記述される。このようにして、「ＡＡＡ」スキーマを構成する分類項目のもつ全ての属性に関するデータについて記述し終えると、ステップＳ３−６へ進み、図２０の１６行目に示すように、当該ユニットの終了タグを記述する
ステップＳ３−７：全てのユニットの作成と記述が終了すると、ステップＳ３−８へ進み、図２０の１７行目、１８行目に示すように、終了タグ＜／ｄｉｃ＿ｅｌｅｍｅｎｔ＞、＜／ｄｉｃｔｉｏｎａｒｙ＞を記述して、送信データ（ここでは、第２の送信データ）の作成が終了する。
【０１１４】
なお、図１５のステップＳ３−４において、各ユニットの値を圧縮する場合は、前述の第１の送信データの場合と同様に、そのユニットの開始タグ次に＜ｃｏｍｐｒｅｓｓ＞タグを記述して圧縮すればよい。
【０１１５】
このようにして、図１２のステップＳ１０において第２の送信データが作成されると、当該第２の送信データは、データ交換装置２１ｂへ送信される（ステップＳ１１）。
【０１１６】
第２の送信データがデータ交換装置２１ａから送信されて、データ交換装置２１ｂの通信部５が、当該第２の送信データを受信すると、データ交換装置２１ｂの処理動作が開始する（ステップＳ１２）。受信した第２の送信データは、受信データ解析部６へ渡される。
【０１１７】
図１２のステップＳ１２は、図１９のステップＳ１０８に対応し、以下、図１９を参照して説明する。すなわち、図１９のステップＳ１０８で、データ交換装置２１ｂが第２の送信データを受信すると、受信データ解析部６では、当該第２の送信データに含まれるスキーマデータを取出し、当該スキーマデータが先に受け取ったコンテンツデータに適用可能なスキーマデータであるかを確認する。
【０１１８】
例えば、図２０には示していないが、第２の送信データ中に当該スキーマデータのスキーマ識別子やバージョン情報が記述されていてもよく、これを基に、先に受け取ったコンテンツデータに対応するスキーマデータであるか否かをチェックするようにしてもよい。また、実際にコンテンツデータに適用して、その妥当性を確認するようにしてもよい。ここで受け取ったスキーマデータが、要求したスキーマデータでないときは、エラー処理を行って処理を終了し、要求したスキーマデータであるときは、データ登録処理を行う（図１２のステップＳ１３）。
【０１１９】
次に、図１２のステップＳ１３における、データ交換装置２１ｂにおいて、受信したコンテンツデータやスキーマデータを階層型データベース１０に登録するための受信データ登録部７におけるデータ登録処理について、図２１に示すフローチャートを参照して説明する。
【０１２０】
受信データ登録部７では、階層型データベース１０に対し、スキーマ記憶部８やコンテンツ記憶部９にスキーマデータやコンテンツデータを記憶するためのコマンドを作成する。そして、このコマンドを階層型データベース１０へ渡して、ここで、各記憶部８，９に対し実際のデータ登録を行うようになっている。
【０１２１】
ステップＳ２０１：第１の送信データにより、データ交換装置２１ａから転送されてきたコンテンツデータと、データ交換装置２１ｂのスキーマ記憶部８に記憶されている、あるいはデータ交換装置２１ａから第２の送信データとして送信されたスキーマデータから、コンテンツデータを階層型データベースに登録するための、図２２に示すようなコマンドを作成する。このコマンドには、３行目に、コンテンツデータを一時格納しているテンポラリファイルのファイル名（当該田イル名の位置情報であるパス名を含む）が記述され、さらに、同じ３行目にある「ｃｏｍｍａｎｄ」属性にて階層型データベース１０で実行可能なコマンドが記述されている。４行目から８行目には「ＡＡＡ」スキーマを構成する各分類項目に関するデータが記述されている。
【０１２２】
ステップＳ２０２：このコマンドは、階層型データベース１０に渡され、ここで、当該コマンドが実行されて、当該コマンドに含まれる、あるいは指定されたコンテンツデータやスキーマをコンテンツ記憶部９やスキーマ記憶部８に格納する。
【０１２３】
ステップＳ２０３：階層型データベース１０にこれらコンテンツデータやスキーマデータを登録した結果を履歴として記録するとともに、処理を終了する。
【０１２４】
以上説明したように、上記実施形態によれば、データ交換装置２１ａの複数の（例えば、ここでは、スキーマ識別子が「ＡＡＡ」であるスキーマと、スキーマ識別子が「ＢＢＢ」であるスキーマといった２つのスキーマ）階層構造をもつ階層型データベース１０に格納されている、当該複数個の階層構造のうちの１つである第１の階層構造（例えば、スキーマ識別子が「ＡＡＡ」であるスキーマ）に登録されている複数の属性値からなる複数のコンテンツデータをデータ交換装置２１ｂに転送する際には、当該第１の階層構造についての識別子とバージョン情報と、当該複数のコンテンツデータをテキストデータとして含む図１６に示したような第１の送信データ（この第２の送信データは構造化文書であってもよい）を作成し、それをデータ交換装置２１ｂへ転送する。
【０１２５】
一方、第１の送信データを受信したデータ交換装置２１ｂでは、受信した第１の送信データに含まれているスキーマ識別子とバージョン情報に対応するスキーマ（互換可能なスキーマを含む）がスキーマ記憶部８に存在しないときには、そのようなスキーマを送信元のデータ交換装置２１ａへ要求する。受信した第１の送信データに含まれているスキーマ識別子とバージョン情報に対応するスキーマ（互換可能なスキーマを含む）がスキーマ記憶部８に存在するとき、第１の送信データに含まれるコンテンツデータは、そのまま、自身の階層型データべースに登録することができるので、その後は、当該受信したコンテンツデータの登録処理を行う。
【０１２６】
送信したコンテンツデータに適用されるスキーマ（第１の階層構造）は、データ交換装置２１ｂから上記のように要求があったときに別途転送する。すなわち、当該スキーマのテキストデータを含む、図２０に示したような第２の送信データを作成し、これをデータ交換装置２１ｂへ転送する。
【０１２７】
このように、送信側では、コンテンツデータを送信する際には、階層構造と分離して、スキーマの識別子やバージョン情報以上の詳細なスキーマ情報は通常添付せずに送信する。スキーマ、すなわち、先に送信したコンテンツデータに対応する階層構造は、送信先から要求のあったときだけ送信する。しかも、コンテンツデータやスキーマは、単純なテキストデータとして送信する。
【０１２８】
従って、送信データを作成するための処理時間を短縮することができるとともに、送信データのデータ量そのものを削減することができる。
【０１２９】
さらに、コンテンツデータを送信する際に、当該コンテンツデータをテキストデータにした後、更に圧縮することで、よりデータ量を削減することができる。
【０１３０】
このように、送信側と受信側の双方において、スキーマ情報を記述するモデルであるメタスキーマが、ＩＳＯ１３５８４のような国際標準の規格に従っているとするならば、上記実施形態は有効なデータ交換手法といえる。
【０１３１】
また、容易に新環境に以降しにくいレガシーシステムが存在する場合、例えば、受信側で、現在稼働中のスキーマ記憶部８とコンテンツ記憶部９を含む階層型データベース１０があり、これに、後に上記実施形態を適用する場合、受信データ登録部７では、図２２に示したような階層型データベース１０に解釈可能なコマンドを含むコマンドを作成するので、これにより、本実施形態は容易に適用可能となる。
【０１３２】
ところで、上記実施形態では、ます、コンテンツデータのみを送信するようになっているが、送信側にて、最初から受信側のデータ交換装置２１ｂがこれから送ろうとするコンテンツデータに対応するスキーマを持たないことがわかっているのなら、コンテンツデータとともに、スキーマを一緒に送るようにしてもよい。その場合の送信データ作成部４の送信データの作成処理動作を図２３に示す。なお、図２３において、図１５と同一部分には同一符号を付し、異なる部分についてのみ説明する。すなわち、図２３では、各ユニット内に、当該ユニットに対応する分類項目と属性に関するスキーマデータを上記のようにテキスト形式にて書き込むべく、ステップＳ３−３とステップＳ３−４の間に、ステップＳ３―１５、ステップＳ３―１６を追加している。この２つのステップにより、スキーマ識別子「ＡＡＡ」のスキーマデータのうち、当該ユニットに対応する分類項目に関するデータと、属性に関するデータがテキストデータとして挿入されることになる。
【０１３３】
このようなスキーマデータが添付されたコンテンツデータを含む送信データを受信した場合のデータ交換装置２１ｂの処理動作について、既に述べた通りである。
【０１３４】
また、上記実施形態では、送信側主導で動作するようになっているが、受信側主導で、例えば、データ交換装置２１ｂが、所望のスキーマ識別子とバージョン情報をデータ交換装置２１ａに通知し、データ交換装置２１ａでは、通知されたスキーマ識別子のスキーマに対応する階層構造上の分類項目に登録されているコンテンツデータを前述したように、テキストデータにして送信するとともに、そのスキーマが更新されて、通知されたバージョン情報よりも新しくなっているときには、その新たなバージョンのスキーマデータも一緒に送信するようにしてもよい。
【０１３５】
さらに、送信側主導で動作する場合にも、コンテンツデータの送信に先立って、これから送信しようとするコンテンツデータに対応するスキーマ識別子とバージョン情報を、まず、データ交換装置２１ｂへ通知して、データ交換装置２１ｂが当該スキーマ識別子で、互換性のあるバージョンのスキーマデータをもつか確認し、そのようなスキーマを持っている旨のレスポンスを受け取ったときには、コンテンツデータのみを送信し、そのようなスキーマを持っていない旨のレスポンスを受けたときには、コンテンツデータとともに、スキーマデータも送信するようにしてもよい。
【０１３６】
いずれの場合であっても、コンテンツデータや、スキーマデータは、階層構造のないテキストデータとして送信されるので、送信データのデータ量そのものを削減できることはいうまでもない。
【０１３７】
本発明の実施の形態に記載した本発明の手法（図１２参照）は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フレキシブルディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、半導体メモリなどの記録媒体に格納して頒布することもできる。
【０１３８】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【０１３９】
【発明の効果】
以上説明したように、本発明によれば、階層構造を有するデータベースに格納されたコンテンツデータを送信する際の送信データのデータ量を削減して、送信データの作成と送信を効率よく行える。
【図面の簡単な説明】
【図１】本発明の実施形態に係るデータ交換装置の概略構成例を示した図。
【図２】階層型データベースの階層構造を概略的に示した図。
【図３】階層型データベースの階層構造を示した図。
【図４】スキーマ記憶部に記憶されるスキーマデータのうち、分類項目に関するデータの記憶例を示した図。
【図５】スキーマ記憶部に記憶されるスキーマデータのうち、属性に関するデータの記憶例を示した図。
【図６】スキーマ記憶部に記憶されるスキーマデータのうち、各スキーマの分類識別子とバージョン情報の記憶例を示した図。
【図７】コンテンツ記憶部に記憶されるコンテンツデータの記憶例を示した図。
【図８】コンテンツ記憶部に記憶されるコンテンツデータの記憶例を示した図。
【図９】コンテンツ記憶部に記憶されるコンテンツデータの記憶例を示した図。
【図１０】階層型データベースの更新された階層構造を概略的に示した図。
【図１１】階層型データベースの更新された階層構造を示した図。
【図１２】データ交換装置の処理動作を説明するためのフローチャート。
【図１３】データ交換装置での検索結果として得られたコンテンツデータの一例を示した図。
【図１４】データ検索処理動作を説明するためのフローチャート。
【図１５】送信データ作成処理動作を説明するためのフローチャート。
【図１６】第１の送信データの一例を示した図。
【図１７】第１の送信データの他の例を示した図。
【図１８】データ転送処理動作を説明するためのフローチャート。
【図１９】データ受信処理動作を説明するためのフローチャート。
【図２０】第２の送信データの一例を示した図。
【図２１】受信データ登録処理動作を説明するためのフローチャート。
【図２２】受信データ登録部で作成されるコマンドの一例を示した図。
【図２３】送信データ作成処理動作の他の例を示したフローチャート。
【図２４】第１の送信データのさらに他の例を示した図。
【符号の説明】
１…表示部、２…入力部、３…データ検索部、４…送信データ作成部、５…通信部、６…受信データ解析部、７…受信データ登録部、８…スキーマ記憶部、９…コンテンツ記憶部、１０…階層型データベース、２１ａ、２１ｂ…データ交換装置。
【図１】
2004326583.tif 000003
【図２】
2004326583.tif 000004
【図３】
2004326583.tif 000005
【図４】
2004326583.tif 000006
【図５】
2004326583.tif 000007
【図６】
2004326583.tif 000008
【図７】
2004326583.tif 000009
【図８】
2004326583.tif 000010
【図９】
2004326583.tif 000011
【図１０】
2004326583.tif 000012
【図１１】
2004326583.tif 000013
【図１２】
2004326583.tif 000014
【図１３】
2004326583.tif 000015
【図１４】
2004326583.tif 000016
【図１５】
2004326583.tif 000017
【図１６】
2004326583.tif 000018
【図１７】
2004326583.tif 000019
【図１８】
2004326583.tif 000020
【図１９】
2004326583.tif 000021
【図２０】
2004326583.tif 000022
【図２１】
2004326583.tif 000023
【図２２】
2004326583.tif 000024
【図２３】
2004326583.tif 000025
【図２４】
2004326583.tif 000026