【手続補正書】
【提出日】平成19年2月26日(2007.2.26)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
マルチメディア・コンテンツ・データの高レベル・コンテンツ・モデルと、データ・エンジンへのマッピングを提供する低レベル物理モデルを備えるデータベースにおいて、マルチメディア・コンテンツ管理オブジェクトを表現するための方法であって、
マルチメディア・コンテンツ・データのメタデータおよびスキーマの入力を低レベル物理モデルに受けるステップと、
前記メタデータおよびスキーマを前記データ・エンジンにマッピングするステップを備え、
前記低レベル物理モデルが、それぞれが異なるアプリケーションに対応する複数の高レベル・コンテンツ・モデルをサポートする、方法。
【請求項２】
前記高レベル・コンテンツ・モデルは、データ構造および制約の表現を具現化するアプリケーション・プログラム・インタフェースとして実装される、請求項１に記載の方法。
【請求項３】
前記データ・エンジンは、リレーショナル・データベース管理システム、オブジェクト指向データベース管理システム、オブジェクト・リレーショナル・データベース管理システム、およびＸＭＬデータ・レポジトリのいずれかである、請求項１に記載の方法。
【請求項４】
マルチメディア・コンテンツ管理オブジェクトをアイテムとして表現するために適合された複数の列を有する少なくとも１つの行を有するリレーショナル・データベース・テーブルを備えるリレーショナル・データベースにおいて、マルチメディア・コンテンツ管理オブジェクトをアイテムとして表現するための方法であって、
第１のリレーショナル・データベース・テーブルにおいて、マルチメディア・コンテンツ管理オブジェクトのルート・コンポーネントをアイテムとして行に関連付けるステップと、
前記第１のリレーショナル・データベース・テーブルの対応する列に前記ルート・コンポーネントの属性を関連付けるステップと、
前記マルチメディア・コンテンツ管理オブジェクトの追加のコンポーネントが存在することを条件に、追加のリレーショナル・データベース・テーブルにおいて、当該追加のコンポーネントを行に関連付けるステップと、
前記リレーショナル・データベース・テーブルにおけるアイテムを構築ブロックとして用いて、それぞれが異なるアプリケーションに対応する複数の高レベル・コンテンツ管理データ・モデルを構築するステップと、
を備える方法。
【請求項５】
前記追加のコンポーネントは、ルート・コンポーネントまたは他のコンポーネントの子コンポーネントをそれぞれ備える、請求項４に記載の方法。
【請求項６】
前記ルート・コンポーネントの属性は、別個のレポジトリに格納されたデータ・リソースに対するポインタとして実装される、請求項４に記載の方法。
【請求項７】
前記リレーショナル・テーブル内の行はソース・アイテムとターゲット・アイテム間のリンク情報を備える、請求項４に記載の方法。
【請求項８】
マルチメディア・コンテンツ・データの高レベル・コンテンツ・モデルと、データ・エンジンへのマッピングを提供する低レベル物理モデルを備えるデータベースにおいて、マルチメディア・コンテンツ管理オブジェクトを表現するためのプログラムであって、
マルチメディア・コンテンツ・データのメタデータおよびスキーマの入力を低レベル物理表現として受けるステップと、
前記メタデータおよびスキーマを前記データ・エンジンにマッピングするステップをコンピュータに実行させ、
前記低レベル物理モデルが、それぞれが異なるアプリケーションに対応する複数の高レベル・コンテンツ・モデルをサポートする、プログラム。
【請求項９】
マルチメディア・コンテンツ管理オブジェクトをアイテムとして表現するために適合された複数の列を有する少なくとも１つの行を有するリレーショナル・データベース・テーブルを備えるリレーショナル・データベースにおいて、マルチメディア・コンテンツ管理オブジェクトをアイテムとして表現するためのプログラムであって、
第１のリレーショナル・データベース・テーブルにおいて、マルチメディア・コンテンツ管理オブジェクトのルート・コンポーネントをアイテムとして行に関連付けるステップと、
前記第１のリレーショナル・データベース・テーブルの対応する列に前記ルート・コンポーネントの属性を関連付けるステップと、
前記マルチメディア・コンテンツ管理オブジェクトの追加のコンポーネントが存在することを条件に、追加のリレーショナル・データベース・テーブルにおいて、当該追加のコンポーネントを行に関連付けるステップと、
前記リレーショナル・データベース・テーブルにおけるアイテムを構築ブロックとして用いて、それぞれが異なるアプリケーションに対応する複数の高レベル・コンテンツ管理データ・モデルを構築するステップと、
をコンピュータに実行させる、プログラム。
【請求項１０】
マルチメディア・コンテンツ管理オブジェクトをアイテムとして表現するために適合された複数の列を有する少なくとも１つの行を有するリレーショナル・データベース・テーブルを備えるリレーショナル・データベースにおいて、マルチメディア・コンテンツ管理オブジェクトをアイテムとして表現するためのシステムであって、
マルチメディア・データ・オブジェクト・アイテムを管理し、マルチメディア・データ・オブジェクト・コンテンツ・サーバを介してマルチメディア・データ・オブジェクト・コンテンツ・レポジトリからクライアントに配信するためのシステムであって、マルチメディア・データ・オブジェクトは、マルチメディア・データ・オブジェクト・アイテムを備え、該マルチメディア・データ・オブジェクト・アイテムの各々は、マルチメディア・データ・オブジェクト属性およびコンポーネントを備え、前記マルチメディア・データ・オブジェクト・コンテンツ・サーバは、制御され構成されて、
第１のリレーショナル・データベース・テーブルにおいて、マルチメディア・コンテンツ管理オブジェクトのルート・コンポーネントを行に関連付ける手段と、
前記第１のリレーショナル・データベース・テーブルの対応する列に前記ルート・コンポーネントの属性を関連付け手段と、
追加のリレーショナル・データベース・テーブルにおいて、前記マルチメディア・コンテンツ管理オブジェクトの追加コンポーネントを対応する行に関連付ける手段を備え、
前記アイテムが、それぞれが異なるアプリケーションに対応する複数の高レベル・データ・モデルを構築するために構築ブロックとして用いられる、システム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【書類名】  明細書
【発明の名称】  マルチメディア・コンテンツ管理オブジェクトを表現するための方法、プログラム、及びシステム
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディア・データ構造モデルを含むデータ構造モデルに関し、コンテンツ管理アプリケーションのためのアクセス、検索、およびデータ変換を容易にする。データ構造モデルは、とりわけ、関連、ネットワーク、階層、およびエンティティ関連モデルを含むデータおよびファイル、ならびにグラフィック、テキスト、およびウエブ・ページ・ファイルを構成し、相互に関連付け、アクセスするために用いられる。
【背景技術】
【０００２】
マルチメディア・データの管理および配信は、多くのコンピュータおよびメモリを用いる複雑な作業である。なお、本明細書中で用いる場合、「マルチメディア」データとは、記憶および検索の関連するシステムにリンクしたり、インタラクティブなものとしたり、他のメディアにリンクしたりすることができる、音、グラフィック、アニメーション、テキスト、およびビデオ・データの組み合わせを指す。
【０００３】
マルチメディア・コンテンツ管理システムは、非構造化データ（unstructured data）および構造化データ（structured
data）を含む、大量の異なる種類のデータを管理する必要がある。構造化データは、非構造化データを、様々な方法で組織化し、グループ化し、相関付け、探索、検索、および管理をすることができるように、非構造化データを記述するための「メタデータ」を含む場合が多い。コンテンツ管理システムでは、多くの場合、リレーショナル・データベース管理システム（ＲＤＢＭＳ）を用いて、これらの構造化データを管理し、既存のＲＤＢＭＳデータ管理技術を使用可能とする。しかしながら、非構造化データすなわちマルチメディア・コンテンツのタイプは、アプリケーションごとに異なる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
データ（そのスキーマ、メタデータ、適用可能エクステンダ等を含む）のタイプは、アプリケーションおよびコンテンツ・データ・モデル（ストリーム、グラフィック、ビジュアル、ビデオ、オーディオ、テキスト、数字など）ごとに異なるので、各アプリケーションおよびデータ・モデルのメタデータおよびスキーマ・データベースをサポートするために、異なるデータベース設計が必要である。以前は、単一の汎用コンテンツ管理システムによって異なるコンテンツ・データ・モデルを用いて異なるコンテンツ管理アプリケーションをサポートすることは不可能であった。かかるシステムは、予め設計された「１つのサイズが全てに合う」データベース管理システムを有することができなかった。逆に、コンテンツ管理システムは、アプリケーション開発者に必要な構造化データを記述させる機能を備えて、そのアプリケーションのために適切な設計を有するデータベースを生成可能としなければならなかった。この記述は、通常はアプリケーション・プログラミング・インタフェース（ＡＰＩ）またはグラフィカル・ユーザ・インタフェース（ＧＵＩ）によって、コンテンツ管理システムがサポートする高レベル・データ・モデルの抽象化において一般的に表現された。この高レベルのデータ・モデルが２つ以上のアプリケーションをサポートするための柔軟性を提供したが、これによって、適用範囲は、その特定の高レベルのモデルにおいて表現可能なアプリケーションのみに限定された。
【０００５】
データ・モデルは、システムの潜在的な機能およびその限界を決定するので、コンテンツ管理システムの重要な側面である。しかしながら、データ・モデルは、拡張することができる場合もあるが、かかる拡張は通常、極めて限定され、異なるパラダイム、特に互換性を有しないかまたは矛盾する概念を有するものを取り込むことはできない。
【０００６】
従って、幅広い範囲の異種コンテンツ・データ・モデルを容易にサポートし、システムまたはプログラムにおいて容易に実施可能な、拡張可能かつスケーラブルなデータ・モデルに対する要望がある。更に、拡張可能かつスケーラブルなコンテンツ管理ＲＤＢＭＳのため、異種コンテンツ・スキーマおよびメタデータのリレーショナル・データベースを生成し移植するためのツール、ツール・キット、ツール・セットまたはウイザードに対する要望がある。
【課題を解決するための手段】
【０００７】
本発明は、データベースにおいてマルチメディア・コンテンツ管理オブジェクトを表現する方法を提供する。本発明の方法は、マルチメディア・コンテンツ・データの高レベル・コンテンツ・モデルと、低レベル物理モデルを備えるデータベースを用いる。低レベル物理モデルは、データ・エンジンへのマッピングを提供する。この方法は、マルチメディア・データ・メタデータおよびスキーマの入力を低レベル物理表現として受けるステップと、メタデータおよびスキーマをデータ・エンジンにマッピングするステップとを含み、低レベル物理モデルが、それぞれが異なるアプリケーションに対応する複数の高レベル・コンテンツ・モデルをサポートする。データ・エンジンは、好ましくは、リレーショナル・データベース管理システム、オブジェクト指向データベース管理システム、またはＸＭＬデータ・レポジトリのいずれかである。
【０００８】
本発明は、マルチメディア・コンテンツ管理オブジェクトをアイテムとして表現するために適合された複数の列を有する少なくとも１つの行を有するリレーショナル・データベース・テーブルを備えるリレーショナル・データベースにおいて、マルチメディア・コンテンツ管理オブジェクトをアイテムとして表現するための方法を提供する。本発明の方法は、第１のリレーショナル・データベース・テーブルにおいて、マルチメディア・コンテンツ管理オブジェクトのルート・コンポーネントをアイテムとして行に関連付けるステップと、第１のリレーショナル・データベース・テーブルの対応する列にルート・コンポーネントの属性を関連付けるステップと、マルチメディア・コンテンツ管理オブジェクトの追加のコンポーネントが存在することを条件に、追加のリレーショナル・データベース・テーブルにおいて、当該追加のコンポーネントを行に関連付けるステップと、リレーショナル・データベース・テーブルにおけるアイテムを構築ブロックとして用いて、それぞれが異なるアプリケーションに対応する複数の高レベル・コンテンツ管理データ・モデルを構築するステップを備える。
【０００９】
本発明は、マルチメディア・コンテンツ・データの高レベル・コンテンツ・モデルと、データ・エンジンへのマッピングを提供する低レベル物理モデルを備えるデータベースにおいて、マルチメディア・コンテンツ管理オブジェクトを表現するためのプログラムを提供する。本発明のプログラムは、マルチメディア・コンテンツ・データの高レベル・コンテンツ・モデルと、低レベル物理モデルを備えるデータベースを用いる。低レベル物理モデルは、データ・エンジンへのマッピングを提供する。本発明の方法は、マルチメディア・データ・メタデータおよびスキーマの入力を低レベル物理表現として受けるステップと、メタデータおよびスキーマをデータ・エンジンにマッピングするステップをコンピュータに実行させ、低レベル物理モデルが、それぞれが異なるアプリケーションに対応する複数の高レベル・コンテンツ・モデルをサポートする。
【００１０】
また、本発明は、マルチメディア・コンテンツ管理オブジェクトをアイテムとして表現するために適合された複数の列を有する少なくとも１つの行を有するリレーショナル・データベース・テーブルを備えるリレーショナル・データベースにおいて、マルチメディア・コンテンツ管理オブジェクトをアイテムとして表現するためのプログラムを提供する。このプログラムは、第１のリレーショナル・データベース・テーブルにおいて、マルチメディア・コンテンツ管理オブジェクトのルート・コンポーネントをアイテムとして行に関連付けるステップと、第１のリレーショナル・データベース・テーブルの対応する列にルート・コンポーネントの属性を関連付けるステップと、マルチメディア・コンテンツ管理オブジェクトの追加のコンポーネントが存在することを条件に、追加のリレーショナル・データベース・テーブルにおいて、当該追加のコンポーネントを行に関連付けるステップと、リレーショナル・データベース・テーブルにおけるアイテムを構築ブロックとして用いて、それぞれが異なるアプリケーションに対応する複数の高レベル・コンテンツ管理データ・モデルを構築するステップをコンピュータに実行させる。
【００１１】
マルチメディア・コンテンツ管理オブジェクトをアイテムとして表現するために適合された複数の列を有する少なくとも１つの行を有するリレーショナル・データベース・テーブルを備えるリレーショナル・データベースにおいて、マルチメディア・コンテンツ管理オブジェクトをアイテムとして表現するためのシステムを提供する。本発明のシステムは、第１のリレーショナル・データベース・テーブルにおいて、マルチメディア・コンテンツ管理オブジェクトのルート・コンポーネントを行に関連付ける手段と、第１のリレーショナル・データベース・テーブルの対応する列にルート・コンポーネントの属性を関連付け手段と、追加のリレーショナル・データベース・テーブルにおいて、マルチメディア・コンテンツ管理オブジェクトの追加コンポーネントを対応する行に関連付ける手段と、リレーショナル・データベース・テーブルにおけるアイテムを構築ブロックとして用いて、それぞれが異なるアプリケーションに対応する複数の高レベル・データ・モデルを構築する手段を備える。
【発明を実施するための最良の形態】
【００１２】
本発明の好適な実施形態を、添付図面を参照して、一例としてのみ詳細に説明する。図１に示すように、マルチメディア・システムは、それぞれが１つ以上のコンテンツ記憶装置１９ａ、１９ｂ、１９ｃ、１９ｄを有する、クライアント１１ａ、１１ｂ、サーバ１３、およびコンテンツ・サーバ１７ａ、１７ｂを含むクライアント−サーバ・システムである。コンテンツ記憶装置は、コンテンツのメタデータ等の構造化データ、またはテキスト・データ、画像データ、ストリーミング・オーディオ、またはストリーミング・ビデオ等の非構造化データを含むことができることに留意すべきである。これらのデータは、様々な異種フォーマットとすることができ、典型的にはそうである。
【００１３】
サーバ１３は、ウエブ・サーバおよびコンテンツ・マネージャ・サーバを含む。コンテンツ・マネージャ・サーバは、コンテンツ管理ＲＤＢＭＳのレポジトリである。本発明は、リレーショナル・データベース管理システムに関して例示するが、オブジェクト指向データベース管理システムまたはＸＭＬデータ・レポジトリ等の代替的なデータ・レポジトリも使用可能である。
【００１４】
高レベル・データ・モデルにおいて２つ以上のコンテンツ・データ・モデルに対応するため、拡張可能コンテンツ管理システムを用いて、適切なメタデータおよびスキーマおよび新しいＡＰＩを導入して、新しい高レベル・データ・モデルをサポートすることができる。この拡張性は、低レベルのインフラストラクチャの周囲に構築されたアーキテクチャによって可能となり、これは、物理データ・モデルをサポートし、アイテム、コンポーネント、サブコンポーネント、および属性のようなコンテンツおよびコンテンツ・メタデータのＲＤＢＭＳテーブルの階層構造によって実施され、行内に対応する行および列（属性）を有する。アーキテクチャおよび関連インフラストラクチャおよび物理データ・モデルは、高レベル・データ・モデルをサポートする構築ブロックとして用いられる。この物理データ・モデルは、アプリケーションに固有の意味とは独立し、ＲＤＢＭＳ機能を利用するように設計されたリレーショナル・データベースに直接かつ効率的にマッピングされ、時間をかけて強化されて、その機能を拡張しおよび／または新しいＲＤＢＭＳ機能を利用することができる。
【００１５】
この物理データ・モデルのための設計ポイントは、アプリケーション開発者に提供される高レベル・データ・モデルのものとは異なる。高レベル・データ・モデルが、その論理的な側面（アプリケーションのクラスに対するその有用性および表現性）を非常に重要視するのに対し、物理データ・モデルは、その物理的な側面（ＲＤＢＭＳ機能を利用するための記憶アクセス効率および能力）を非常に重要視し、多くのコンテンツ管理アプリケーションに広く有用な一般的な基本機能を提供する。この物理データ・モデルまたは部分は、高レベル・データ・モデルによってユーザに提供される場合もあるし、そうでない場合もある。
【００１６】
概念的には、図２に示すように、本発明の方法、システム、およびプログラムは、高レベル・コンテンツ・モデルを利用する。これは、多種多様なオープン・セットのコンテンツ・アプリケーション要求および複数の高レベル・データ・モデル、ならびに、新しい技術、新しい標準、および新しい要求に対処するように拡張可能なデータ・コンテンツの低レベル物理モデルをサポートすることができ、データ・エンジンに対する効率的なマッピングを提供する（リレーショナル・データベース管理システムまたはオブジェクト指向データベース管理システムとしてのデータベース管理システムは、一例であり限定ではない）。各高レベル・データ・モデルは、データ構造および制約の表現を具現化するアプリケーション・プログラム・インタフェース（ＡＰＩ）の形態であることに留意すべきである。また、低レベル・データ・モデルまたはインフラストラクチャ２５は、多数の高レベル・モデル２１、２２、２３をサポートすることができることに留意しなければならない。本発明の拡張可能かつスケーラブルなコンテンツ管理システムは、異種の高レベル・データ・モデルをサポートする１つ以上のＡＰＩ２１、２２、２３を含み、これらは一般的な低レベル・インフラストラクチャ２５すなわち物理データ・モデルによってサポートされ、これはリレーショナル・データベース管理システム（ＲＤＢＭＳ）２７によってサポートされる。
【００１７】
図３、４、５、および６は、ＲＤＢＭＳ環境における物理モデルとその表現との間の関係を示す。リレーショナル・データベースでは、データはテーブルとして表現される。リレーショナル・データベース・テーブルの構築ブロックは、行および列（属性）のテーブルである。具体的には、テーブルは、ゼロ以上のデータ値の行と列見出しの行から構成される。所与のテーブルでは、（１）列見出しは１つ以上の列を定義し、（２）各データ行は、列見出し行において既定された列ごとに１つの値（またはヌル値）を含む。
【００１８】
本発明のコンテンツ管理システムの物理層が管理するコンテンツの基本独立ユニットは、「アイテム」である。図３は、アイテム・データベース３０を示し、ルート・コンポーネント３１は、アイテム行３２ａおよび３２ｂを有する。アイテムは、コンポーネント３５および１つ以上のレベルのサブコンポーネント３８ａ、３８ｂの典型的な階層構造から成り、属性３３ａ、３３ｂ、３３ｃ、３３ｄ、３４ａ、３４ｂ、３４ｃを有し、一意の識別子「アイテムＩＤ（アイテムＩＤ）」を有する。
【００１９】
各コンポーネント３５は、親コンポーネントに対する参照３６ａを含む。参照は、外部のキーによる。
【００２０】
サブコンポーネント・テーブル３８ａおよび３８ｂは、更にサブコンポーネントまたは属性を参照することができる。サブコンポーネント・テーブル３８ｂは、コンテンツ・データ・レポジトリ３９ａおよび３９ｂに対する参照ポインタとして示される。
【００２１】
図４は、図３に示すモデルの更に一般的な高レベルの図を表す。高レベル・データ・モデルによって、またはアプリケーション内で、「アイテム」すなわちマルチメディア・コンテンツ管理オブジェクト・アイテムを用いて、実オブジェクトを、文書、フォルダ、メディア資産、または他の実世界コンテンツ・エンティティとして表すことができる。図４は、階層物理アイテムおよびその属性のマッピング４１ｂを右に示し、階層ＲＤＢＭＳ表現すなわちＲＤＢＭＳアイテム・タイプ４１ａを左に示す。「アイテム・タイプ（ＩｔｅｍＴｙｐｅ）」は、ＲＤＢＭＳテーブルのユーザ規定スキーマおよび名付けられた階層構造であり、その各々は、「アイテム・タイプ」の「コンポーネント・タイプ（ＣｏｍｐｏｎｅｎｔＴｙｐｅ）」３５と呼ばれる。各「コンポーネント・タイプ」は、ユーザ特定属性（複数の属性）およびあるシステム属性を含む。
ユーザ特定属性は、ＲＤＢＭＳがサポートするいずれかのデータ・モデルとすることができ、あるいはコンテンツ管理システムがサポートする特別なデータ・モデルとすることができる。「アイテム（ｉｔｅｍ）」は、「アイテム」に含まれる子の行の親も「アイテム」に含まれなければならないという条件で、論理的には、各「アイテム・タイプ」のルート・テーブルにおける行および「アイテム・タイプ」の各子テーブルにおけるいずれかの数の行から成る。「アイテム」は、テーブルの階層に格納される行の階層である。これらの行の各々は、「アイテム」の「コンポーネント（Ｃｏｍｐｏｎｅｎｔ）」と呼ばれ、各「コンポーネント・タイプ」内の「コンポーネント」を一意に識別する「コンポーネントＩＤ（ＣｏｍｐｏｎｅｎｔＩＤ）」を有する。
【００２２】
基数（カーディナリティー）の制約は、各子の「コンポーネント・タイプ」ごとに規定して、それらの親の行の各々のもとで、そのタイプの行の最小および／または最大数を保証することができる。デフォルトの最小数はゼロであり、デフォルトの最大数は無限である。また、「アイテム・タイプ」は、順序付けするかまたは順序付けしないかのいずれかとすることができる。順序付けた「アイテム・タイプ」の「アイテム」では、各親の行の下の子の行は順序付けられ、それらの順序付けはシステムによって維持される。
【００２３】
「アイテム・タイプ」にバージョンを付けることができる。その場合、「アイテム・タイプ」における全ての「アイテム」に、「アイテム」の多数のバージョンを維持する。それらは同じ「アイテムＩＤ」を共有するが、異なるバージョン番号を有する。「アイテム」に保持される最新のバージョンの数は、各バージョン「アイテム・タイプ」ごとに指定することができる。指定のデフォルトは無限であり、すなわち、システムによって古いバージョンの自動消去は行われない。
【００２４】
好適な実施形態では、「アイテム・タイプ」内の２つの「コンポーネント・タイプ」間の親−子関係は、親の「コンポーネント・タイプ」を参照する子の「コンポーネント・タイプ」（またはサブコンポーネント）に生成されるＲＤＢＭＳの外部キーによって維持される。このため、その親の「コンポーネント」に対する各子の「コンポーネント」（またはサブコンポーネント）の参照の一貫性は、ＲＤＢＭＳによって保証される。この実施形態では、「アイテム」における各「コンポーネント」は、少なくとも以下のシステム属性を含む。すなわち、「アイテムＩＤ」、「コンポーネントＩＤ」、および親ＩＤ（ＰａｒｅｎｔＩＤ）、および任意選択として、「アイテム」バージョン番号およびＡＣＬコードを含む場合がある。「アイテムＩＤ」、「アイテム」バージョン番号、およびＡＣＬコードは、ルート「コンポーネント」のためだけに必要であるが、それらはアクセスを容易にするために全ての「コンポーネント」に含ませることも可能である。また、他のシステム属性を含めることで、アクセスまたは保守を容易にすることができる。例えば「コンポーネント・タイプ」、「コンポーネント」の下の直接の子のコンポーネント数等である。また、「アイテム・タイプ」に規定された各「コンポーネント・タイプ」ごとに別個のＲＤＢＭＳテーブルを生成する。すなわち、テーブルは、２つの「アイテム・タイプ」間で共有されない。この設計は、論理を簡略化し、また、データベースのスケーラビリティを向上させる。他の実施形態では、テーブルをいくつかの「アイテム・タイプ」間で共有し、これらのいくつかの「アイテム・タイプ」のために同様に規定したコンポーネント・タイプのコンポーネント（行）を格納することができる。この場合、「アイテム・タイプ」をシステム属性としてこの共有テーブルに含ませて、アクセスを容易にすることができる。このようにテーブルを共有すると、サーチ範囲が、探索されている共通の属性（複数の属性）を含む多数の「アイテム・タイプ」を含む場合、より高速なサーチが可能である。
【００２５】
図５に示すように、アイテム（子コンポーネント、孫コンポーネント、および属性を含む）は、リンクを用いて、例えばシステム・テーブルによって関係するかまたは互いに関連付けることができる。リンクは、「外部」関係であり、リンク・タイプ５５および任意選択のリンク「アイテム」５７と共に、ソース「アイテム」５１をターゲット「アイテム」５３に結び付ける。ソースまたはターゲット「アイテム」のいずれかに埋め込まれていないので、この関係は「外部」である。リンク・タイプ（ＬｉｎｋＴｙｐｅ）は、カテゴリ化ラベルであり、アプリケーションが選択的に特定のタイプのリンクを横切るか探索することができるようになっている。リンク「アイテム」は、第３の「アイテム」であり、これを用いて、必要な場合にこの関係を記述することができる。リンクを用いて、集約関係および包含関係を含む、１対多および多対多の関係をサポートすることができる。
【００２６】
各関係の意味論は、高レベル・データ・モデルによって規定される。１例は、「フォルダリング」であり、この場合、フォルダを表す「アイテム」は、このフォルダに「含まれる」アイテム（文書または他のフォルダを表す）にリンクされる。例えば、ソース・アイテム５１は、ターゲット・アイテム５３のためのコンテナとして機能する。ソースまたはターゲット「アイテム」に対するリンクの結合は、バージョンに固有かまたはバージョン独立のいずれかとすることができる。前者は、アイテムの特定のバージョンを結合するのに対し、後者は、「アイテム」のいずれか／全てのバージョンを結合する。１実施形態では、リンクは、少なくとも以下の属性を含む１つ以上の専用ＲＤＢＭＳテーブルにおいて、行として維持される。すなわち、ソース「アイテムＩＤ」、ソース「アイテム」バージョン番号、ターゲット「アイテムＩＤ」、ターゲット「アイテム」バージョン番号、リンク・タイプ、リンク「アイテムＩＤ」、およびリンク「アイテム」バージョン番号である。
【００２７】
図６に示すように、アイテムは、「アイテム」に含まれる他の属性と同様に維持される「アイテム参照」属性を用いて互いに関連付けることができる。「アイテム参照」属性は、「アイテム・タイプ」３２内で「コンポーネント・タイプ」３６の一部として生成されるユーザ規定属性である。この属性は、コンテンツ管理システムによって維持される特別なデータ・モデルを有する。これは、ターゲット「アイテム」３２’を指し示す参照５８を含む。リンクと同様、（図５）ターゲット「アイテム」３２’に対する参照５８の結合は、バージョンに固有のものかまたはバージョン独立のいずれかとすることができる。「アイテム参照」５８属性を指定すると、参照したアイテムのために参照の範囲および削除意味構造を規定する。この範囲は、参照したアイテムがどの「アイテム・タイプ」（複数のアイテム・タイプ）に属することができるかを特定し、一方、削除意味構造は、参照した「アイテム」を削除する場合、参照の一貫性を保証するためにＲＤＢＭＳが維持する削除ルールと同様である。また、「アイテム参照」属性５８は、範囲指定なしとすることができ、その場合、参照した「アイテム」はいずれかの「アイテム・タイプ」に属することができる。好適な実施形態において、均一に範囲指定された「アイテム参照」属性（すなわち範囲が単一の「アイテム・タイプ」である場合）は、ＲＤＢＭＳ外部キーによってサポートされる。不均一に範囲指定された（すなわち範囲が多数の「アイテム」タイプを含む場合）および範囲指定なしの「アイテム参照」属性は、ＲＤＢＭＳトリガを用いてコンテンツ管理システムによって維持される。
【００２８】
この物理データ・モデルがサポートする別の特別なデータ・モデルは、これも図６に示すリソース参照属性５９のものである。図６に示すように、リソース参照５９は、コンテンツ管理システムのリソース・マネージャが管理するリソース６１に対する参照を含む。リソース・マネージャは、特定のタイプのリソースを管理する特殊用途サーバである。例は、大量の２進オブジェクトを管理するオブジェクト・サーバ、および、ストリーミング・オブジェクト（例えばオーディオおよびビデオ・コンテンツ）を管理し配信するストリーム・サーバである。拡張可能コンテンツ管理システムは、新しいリソース・マネージャに対応することができ、その各々は、特定タイプのリソースを管理するように特別に設計され、その特定の表現および方法は、必ずしもここに記載する物理データ・モデルによってモデル化する必要はない。コンテンツ管理システムが管理する非構造化データは、主として、これらのリソース・マネージャの１つ以上によって内部で管理される。リソース参照の一貫性は、コンテンツ管理システムによって維持される。
【００２９】
本明細書中に記載する物理データ・モデルは、幅広い範囲の高レベル・データ・モデルをサポートして多種多様なアプリケーション・ドメインをカバーすると共に、多くの業界標準（例えばＤｕｂｌｉｎＣｏｒｅ、ＸＭＬ）をサポートすることができる。同じく重要なのは、この物理データ・モデルが、高レベル・データ・モデルを効率的にサポートするようにデータベース最適化を可能とする十分な柔軟性も提供することである。１例では、高レベル・データ・モデルは、１つの「アイテム・タイプ」のアイテムを用いて、独立の共有可能画像を表し、その各々はそれ自身の属性、バージョン、およびＡＣＬを有する。実際の画像は、リソースとして格納される。次いで、別の「アイテム・タイプ」のアイテムを用いて文書を表現し、リンクを用いて、各文書をそれが含む画像に結合する。別の例では、高性能製品アプリケーションをサポートするため、単一の「アイテム」を用いて、文書に含まれる画像と共に文書を表現する。（また、実際の画像は、リソースとして格納する。）この場合、性能は重要であるが、画像を共有する必要は無い。
【００３０】
「アイテム・ビュー（複数のアイテム・ビュー）」は、「アイテム・タイプ」に関して規定することができる。「アイテム・ビュー」は、「アイテム・タイプ」に対するアクセスを、ある「コンポーネント」テーブルおよび属性に制限するために名付けられたテンプレートである。これは、本質的に、「アイテム・タイプ」における対応する「コンポーネント」テーブルのためのＲＤＢＭＳビュー集合である。
【００３１】
本発明の１つの応用は、例えば、磁気カード・セキュリティ・システム、クレジット・カード、またはデビット・カード、または現金自動預け払い機カード・システム、または航空頻度旅行システムにおいて用いられるような、分散型カード読み取り装置アクセスが行われるマルチメディア分散型データベース管理システムである。このシステムの１つのバージョンを、図７に示す。システム７０は、カード読み取り装置７０ａが読み取る、磁気または光カード７０ｂ上の識別指示、例えば暗号化データによって活性化される。
【００３２】
カード７０ｂを読み取った後、生物測定学的読み取りを行う。例示的な生物測定学的データは、とりわけ、指紋読み取り装置７０ｃにおける指紋、声紋およびサンプル、デジタル・カメラ７０ｄにおける顔画像、および眼の画像を含む。履歴、オーディオ、および画像データを、通常、別個のサーバ７２ａ、７３ａ、７４ａ、および７５ａによってアクセスおよび処理し、別個のデータベース７２ｂ、７３ｂ、７４ｂ、および７５ｂに格納し、例えば、指紋データ、音声データ、ならびに顔および眼の画像データを、マルチメディア・データ・オブジェクトとして、別個の指紋データ、音声データ、ならびに顔および眼の画像データベース上に格納し、かかる属性をデータ・モデルと（画像、画像データの数学的表現、オーディオ・データ、オーディオ・データの数学的表現）ならびにレポジトリ・アドレス（例えばＵＲＬまたはＩＰアドレス）とする。ここで、データはアイテムであり、データ・モデルのアドレスおよび定義は属性であり、検査官、警備員、会計係、航空代理店、または執行専門家に提示される画像はリソースである。
【００３３】
方法およびシステムは、プログラム製品において物理的に実施される。プログラム製品は、１以上のコンピュータまたは分散型サーバまたはディスクまたは複数のディスクまたはテープ上に存在することができる。プログラム自体は、分散型メディアまたは分散型サーバの場合のように、例えばインストールの前またはこれを１以上のコンピュータにインストールする前に暗号化および／または圧縮することができる。
【００３４】
本発明の更に別の応用は、コンテンツ・スキーマおよびメタデータをマルチメディア・コンテンツ管理システムに取り込むための、ウイザードに似た（すなわち、質問をし、その答えまたは選択を用いて結果を生成する、構成した一連のダイアローグ）方法およびプログラム製品であり、高レベル・コンテンツ・モデルおよび低レベル物理モデルを含む。これは、コンテンツ・アイテムに関連しエンド・ユーザの応答に基づいたクエリをユーザに提示し、コンテンツ・アイテムに関連し応答に基づいた１つ以上の後続のクエリを提示し、アイテムのサブコンポーネントおよび属性を決定することによって達成される。
【図面の簡単な説明】
【００３５】
【図１】多数クライアント、コンテンツ管理サーバ、および多数コンテンツ・サーバを有するマルチメディア・データベース・システムを示す。
【図２】本発明の方法、システム、およびプログラム・プロダクトの層構造を示し、ＡＰＩの構造を高レベル・データ・モデルとして、一般的な低レベル・インフラストラクチャを物理データ・モデルとして有し、更に基礎にあるリレーショナル・データベース管理システムを有する。
【図３】図２のリレーショナル・データベース管理システムの簡略化した全体像を示し、ルート・コンポーネントのための行を有するアイテム・テーブルを含むと共にコンポーネントおよび属性セル（列）を含む階層ＲＤＢＭＳテーブル、サブコンポーネントおよび属性セル（列）を有するコンポーネント・テーブル、サブコンポーネントおよび属性の双方のための孫テーブルを、適切なポインタと共に示す。
【図４】図３のＲＤＢＭＳテーブル間の関連を示し、ルート・コンポーネント、子コンポーネト、および孫コンポーネントを含むアイテム・タイプの一例として、マッピングされたルート・テーブル、子テーブル、および孫テーブルを含むアイテム・タイプの横並びのマッピングを例示する。各コンポーネントは対応するテーブル内の行である。
【図５】図２のＲＤＢＭＳのテーブルにおける行を示し、ソース・アイテム、ターゲット・アイテム、およびリンク・アイテムに関連している。
【図６】ターゲット・アイテムに対するリソース参照のアプリケーションを示す。
【図７】例えばセキュリティ・システムにおいて、端末で用いる様々なサーバに格納されたマルチメディア・コンテンツを有する個人識別アプリケーションを示す。