JP2006507554A - 多数コンテンツ管理データ・モデルのサポート - Google Patents

Abstract

【課題】マルチメディア・コンテンツを管理するための方法、システム、およびプログラム・プロダクトを提供する。
【解決手段】これらは、特定のマルチメディア・コンテンツ・タイプの高レベル・コンテンツ・モデルおよびデータ・エンジンにマッピングするための低レベル物理の組み合わせの上に構築される。この方法、システム、およびプログラム・プロダクトは、リレーショナル・データベースにおいてマルチメディア・コンテンツ管理オブジェクトを表現し、そのオブジェクトを管理することを含む。リレーショナル・データベースは、複数のリレーショナル・データベース・テーブルにおいてデータを表現するために適合され、リレーショナル・データベース・テーブルの各々は、複数の列を有する少なくとも１つの行を有する。コンテンツは、第１のリレーショナル・データベース・テーブルにおいてオブジェクトをアイテムとして行に関連付け、もしあればオブジェクトの追加コンポーネントを追加リレーショナル・データベース・テーブルに関連付けることによって管理される。

Description

本発明は、マルチメディア・データ構造モデルを含むデータ構造モデルに関し、コンテンツ管理アプリケーションのためのアクセス、検索、およびデータ変換を容易にする。データ構造モデルは、とりわけ、関連、ネットワーク、階層、およびエンティティ関連モデルを含むデータおよびファイル、ならびにグラフィック、テキスト、およびウエブ・ページ・ファイルを構成し、相互に関連付け、アクセスするために用いられる。

マルチメディア・データ管理および配信は、複雑で、コンピュータおよびメモリを多く用いる作業である。本明細書中で用いる場合、「マルチメディア」データとは、音、グラフィック、アニメーション、テキスト、およびビデオ・データの組み合わせを指し、これを、記憶および検索の関連システムにリンクしたり、インタラクティブとしたり、他のメディアにリンクしたりすることができる。

マルチメディア・コンテンツ管理システムは、未構成データ（unstructured data）および構成済みデータ（structureddata）を含む大量の異種データを管理する必要がある。構成済みデータは、多くの場合「メタデータ（metadata）」を含み、これは、未構成データが、様々な方法で組織化され、グループ化され、相関付けられ、探索、検索、および管理することができるように、未構成データを記述する。コンテンツ管理システム内で、多くの場合、リレーショナル・データベース管理システム（ＲＤＢＭＳ：relational database management system）を用いて、これらの構成済みデータを管理し、既製のＲＤＢＭＳデータ管理技術を使用可能とする。しかしながら、未構成データすなわちマルチメディア・コンテンツのタイプは、アプリケーションごとに異なる。

データ（そのスキーマ（schema）、メタデータ、適用可能エクステンダ（extender）等を含む）のタイプは、アプリケーションおよびコンテンツ・データ・モデル（ストリーム、グラフィック、ビジュアル、ビデオ、オーディオ、テキスト、数字のように）ごとに異なるので、各アプリケーションおよびデータ・モデルのメタデータおよびスキーマ・データベースをサポートするために、異なるデータベース設計が必要である。以前は、単一の汎用コンテンツ管理システムによって異なるコンテンツ・データ・モデルを用いて異なるコンテンツ管理アプリケーションをサポートすることは不可能であった。かかるシステムは、予め設計された、すなわち「１つのサイズが全てに合う」データベース管理システムを有することができなかった。逆に、コンテンツ管理システムは、アプリケーション開発者に必要な構成済みデータを記述させる機能を備えて、そのアプリケーションのために適切な設計を有するデータベースを生成可能としなければならなかった。この記述は、通常はアプリケーション・プログラミング・インタフェース（ＡＰＩ：application programming interface）またはグラフィカル・ユーザ・インタフェース（ＧＵＩ：graphical user interface）によって、コンテンツ管理システムがサポートする高レベル・データ・モデルの抽象化において一般的に表現された。この高レベルのデータ・モデルが２つ以上のアプリケーションをサポートするための柔軟性を提供したが、これによって、適用範囲は、その特定の高レベルのモデルにおいて表現可能なアプリケーションのみに限定された。

データ・モデルは、コンテンツ管理システムの不可欠な側面である。なぜなら、これは、システムの潜在的な機能およびその限界を決定するからである。しかしながら、データ・モデルは、時に、いくぶん拡張することができるが、かかる拡張は通常、極めて限定され、異なるパラダイム、特にインコンパチブルまたは衝突さえする概念を有するものを取り込むことはできない。

従って、幅広い範囲の異種コンテンツ・データ・モデルを容易にサポートし、システムまたはプログラム・プロダクトにおいて容易に実施可能な、拡張可能かつスケーラブルな（scalable）データ・モデルに対する明らかな要望がある。
更に、拡張可能かつスケーラブルなコンテンツ管理ＲＤＢＭＳのため、異種コンテンツ・スキーマおよびメタデータのリレーショナル・データベースを生成し移植する（populate）ためのツール、ツール・キット、ツール・セットまたはウイザードに対する要望がある。

従って、本発明は、データベースにおいてマルチメディア・コンテンツ管理オブジェクトを表す方法を提供する。本発明の方法によれば、マルチメディア・コンテンツ・データの１つ以上の高レベル・コンテンツ・モデルおよび低レベル物理モデルを備えるデータベースを用いる。低レベル物理モデルは、データ・エンジンへのマッピングを提供する。この方法は、低レベル物理表現にマルチメディア・データ・メタデータおよびスキーマを入力するステップと、メタデータおよびスキーマをデータ・エンジンにマッピングするステップとを含む。データ・エンジンは、好ましくは、リレーショナル・データベース管理システム、オブジェクト指向データベース管理システム、またはＸＭＬデータ・レポジトリ（data repository）である。

この方法は、好ましくは、１つ以上のリレーショナル・データベース・テーブルにおいてマルチメディア・コンテンツ管理データを表すために適合されたリレーショナル・データベースにおいてマルチメディア・コンテンツ管理オブジェクトをアイテムとして表す方法を更に備えるデータ・エンジンに対するマッピングを提供する。リレーショナル・データベース・テーブルの各々は、複数の列を有する少なくとも１つの行を有する。この方法は、第１のリレーショナル・データベース・テーブルにおいてオブジェクトのルート・コンポーネントをアイテムとして行に関連付けるステップと、第１のリレーショナル・データベース・テーブルの対応する列にルート・コンポーネントの属性を関連付けるステップと、追加のリレーショナル・データベース・テーブルにおいて、もしあればオブジェクトの追加コンポーネントを行に関連付けるステップと、アイテムを構築ブロックとして用いて複数の高レベル・コンテンツ管理データ・モデルを構築するステップとを備える。

従って、本発明は、更に、不揮発性メモリ記憶デバイスを有するデータ処理システム上で実行されるとシステムに上述の方法を実行させる命令を備えたコンピュータ・プログラム・プロダクトを提供する。

従って、本発明は、更に、マルチメディア・データ・オブジェクト・アイテムを管理し、マルチメディア・データ・オブジェクト・コンテンツ・サーバを介してマルチメディア・データ・オブジェクト・コンテンツ・レポジトリからクライアントに配信するためのシステムを提供する。マルチメディア・データ・オブジェクトは、マルチメディア・データ・オブジェクト・アイテムを備え、その各々は、マルチメディア・データ・オブジェクト属性およびコンポーネントを備える。マルチメディア・データ・オブジェクト・コンテント・サーバは、制御され構成されて、第１のリレーショナル・データベース・テーブルにおいてオブジェクトのルート・コンポーネントを行に関連付け、第１のリレーショナル・データベース・テーブルの対応する列にルート・コンポーネントの属性を関連付け、追加のリレーショナル・データベース・テーブルにおいて、もしあればオブジェクトの追加コンポーネントを対応する行に関連付ける。アイテムは、構築ブロックとして用いて、複数の高レベル・コンテンツ管理データ・モデルを構築する。

本発明の好適な実施形態を、以下の図面を参照して、一例としてのみ詳細に説明する。

図１に示すように、マルチメディア・システムは、複雑なクライアント−サーバ・システムであり、多数クライアント１１ａ、１１ｂ、サーバ１３、および１つ以上のコンテンツ・サーバ１７ａ、１７ｂを有し、これは各々、１つ以上のコンテンツ記憶装置１９ａ、１９ｂ、１９ｃ、１９ｄを有する。コンテンツ記憶装置は、コンテンツのメタデータ等の構成済みデータ、またはテキスト・データ、画像データ、ストリーミング・オーディオ、またはストリーミング・ビデオ等の未構成データを含むことができることに留意すべきである。これらのデータは、様々な異種フォーマットとすることができ、典型的にはそうである。

サーバ１３は、ウエブ・サーバを含むことができ、コンテンツ・マネージャ・サーバも含む。コンテンツ・マネージャ・サーバは、本明細書中に記載するコンテンツ管理ＲＤＢＭＳのレポジトリである。本発明は、リレーショナル・データベース管理システムに関して例示するが、オブジェクト指向データベース管理システムまたはＸＭＬデータ・レポジトリ等の代替的なデータ・レポジトリも使用可能である。

高レベル・データ・モデルにおいて２つ以上のコンテンツ・データ・モデルに対応するため、拡張可能コンテンツ管理システムを用いて、適切なメタデータおよびスキーマおよび新しいＡＰＩを導入して、新しい高レベル・データ・モデルをサポートすることができる。この拡張性は、低レベルのインフラストラクチャの周囲に構築されたアーキテクチャによって可能となり、これは、物理データ・モデルをサポートし、アイテム、コンポーネント、サブコンポーネント、および属性のようなコンテンツおよびコンテンツ・メタデータのＲＤＢＭＳテーブルの階層構造によって実施され、行内に対応する行および列（属性）を有する。アーキテクチャおよび関連インフラストラクチャおよび物理データ・モデルは、高レベル・データ・モデルをサポートする構築ブロックとして用いられる。この物理データ・モデルは、アプリケーションに固有の意味とは独立し、ＲＤＢＭＳ機能を利用するように設計されたリレーショナル・データベースに直接かつ効率的にマッピングされ、時間をかけて強化されて、その機能を拡張しおよび／または新しいＲＤＢＭＳ機能を利用することができる。

この物理データ・モデルのための設計ポイントは、アプリケーション開発者に露呈される高レベル・データ・モデルのものとは異なる。高レベル・データ・モデルは、その論理的な側面を非常に重要視する（アプリケーションのクラスに対するその有用性および表現性）のに対し、物理データ・モデルは、その物理的な側面を非常に重要視し（ＲＤＢＭＳ機能を利用するための記憶アクセス効率および能力）、多くのコンテンツ管理アプリケーションに広く有用な一般的な基本機能を提供する。この物理データ・モデル、またはそのいずれかの部分は、高レベル・データ・モデルによってユーザに露呈される場合もあるし、そうでない場合もある。

概念的には、図２に示すように、本発明の方法、システム、およびプログラム・プロダクトは、高レベル・コンテンツ・モデルを利用し、これは、多種多様なオープン・セットのコンテンツ・アプリケーション要求および複数の高レベル・データ・モデル、ならびに、新しい技術、新しい標準、および新しい要求に対処するように拡張可能なデータ・コンテンツの低レベル物理モデルをサポートすることができ、データ・エンジンに対する効率的なマッピングを提供する（リレーショナル・データベース管理システムまたはオブジェクト指向データベース管理システムとしてのデータベース管理システムは、一例であり限定ではない）。各高レベル・データ・モデルは、データ構造および制約の表現を具現化するアプリケーション・プログラム・インタフェース（ＡＰＩ：Application Program Interface）の形態であることに留意すべきである。また、低レベル・データ・モデルまたはインフラストラクチャ２５は、多数の高レベル・モデル２１、２２、２３をサポートすることができることに留意しなければならない。本発明の拡張可能かつスケーラブルなコンテンツ管理システムは、異種の高レベル・データ・モデルをサポートする１つ以上のＡＰＩ２１、２２、２３を含み、これらは一般的な低レベル・インフラストラクチャ２５すなわち物理データ・モデルによってサポートされ、これはリレーショナル・データベース管理システム（ＲＤＢＭＳ）２７によってサポートされる。

図３、４、５、および６は、ＲＤＢＭＳ環境における物理モデルとその表現との間の関係を示す。リレーショナル・データベースでは、データはテーブルとして表される。リレーショナル・データベース・テーブルの構築ブロックは、行および列（属性）のテーブルである。具体的には、１つのテーブルは、データ値のゼロ以上の行と共に列見出しの行から成る。所与のテーブルでは、（１）列見出しは、１つ以上の列を既定し、（２）各データ行は、列見出し行において既定された列の各１つごとに正確に１つの値（またはヌル値）を含む。

本発明のコンテンツ管理システムの物理層が管理するコンテンツの基本独立ユニットは、「アイテム（Item）」である。図３は、アイテム・データベース３０を示し、ルート・コンポーネント３１は、アイテム行３２ａおよび３２ｂを有する。アイテムは、コンポーネント３５および１つ以上のレベルのサブコンポーネント３８ａ、３８ｂの典型的な階層構造から成り、属性３３ａ、３３ｂ、３３ｃ、３３ｄ、３４ａ、３４ｂ、３４ｃを有し、一意の識別子「ＩｔｅｍＩＤ」を有する。

各コンポーネント３５は、親コンポーネントに対する参照３６ａを含む。参照は、外部のキーによる。

サブコンポーネント・テーブル３８ａおよび３８ｂは、更にサブコンポーネントまたは属性を参照することができる。サブコンポーネント・テーブル３８ｂは、コンテンツ・データ・レポジトリ３９ａおよび３９ｂに対する参照ポインタとして示される。

図４は、図３に示すモデルの更に一般的な高レベルの図を表す。高レベル・データ・モデルによって、またはアプリケーション内で、「アイテム」すなわちマルチメディア・コンテンツ管理オブジェクト・アイテムを用いて、実オブジェクトを、文書、フォルダ、メディア資産、または他の実世界コンテンツ・エンティティとして表すことができる。図４は、階層物理アイテムおよびその属性のマッピング４１ｂを右に示し、階層ＲＤＢＭＳ表現すなわちＲＤＢＭＳアイテム・タイプ４１ａを左に示す。「ＩｔｅｍＴｙｐｅ」は、ＲＤＢＭＳテーブルのユーザ規定スキーマおよび名付けられた階層構造であり、その各々は、「ＩｔｅｍＴｙｐｅ」の「ＣｏｍｐｏｎｅｎｔＴｙｐｅ」３５と呼ばれる。各「ＣｏｍｐｏｎｅｎｔＴｙｐｅ」は、ユーザ特定属性（複数の属性）およびあるシステム属性を含む。
ユーザ特定属性は、ＲＤＢＭＳがサポートするいずれかのデータ・モデルとすることができ、あるいはコンテンツ管理システムがサポートする特別なデータ・モデルとすることができる。「Ｉｔｅｍ」は、「Ｉｔｅｍ」に含まれる子の行の親も「Ｉｔｅｍ」に含まれなければならないという条件で、論理的には、各「ＩｔｅｍＴｙｐｅ」のルート・テーブルにおける行および「ＩｔｅｍＴｙｐｅ」の各子テーブルにおけるいずれかの数の行から成る。「Ｉｔｅｍ」は、テーブルの階層に格納される行の階層である。これらの行の各々は、「Ｉｔｅｍ」の「Ｃｏｍｐｏｎｅｎｔ」と呼ばれ、各「ＣｏｍｐｏｎｅｎｔＴｙｐｅ」内の「Ｃｏｍｐｏｎｅｎｔ」を一意に識別する「ＣｏｍｐｏｎｅｎｔＩＤ」を有する。

基数（カーディナリティー）の制約は、各子の「ＣｏｍｐｏｎｅｎｔＴｙｐｅ」ごとに規定して、それらの親の行の各々のもとで、そのタイプの行の最小および／または最大数を保証することができる。デフォルトの最少数はゼロであり、デフォルトの最大数は無限である。また、「ＩｔｅｍＴｙｐｅ」は、順序付けするかまたは順序付けしないのいずれかとすることができる。順序付けた「ＩｔｅｍＴｙｐｅ」の「Ｉｔｅｍ」では、各親の行の下の子の行は順序付けられ、順序付けはシステムによって維持される。

「ＩｔｅｍＴｙｐｅ」は、バージョンを付けることができる。その場合、「ＩｔｅｍＴｙｐｅ」における全ての「Ｉｔｅｍ」に、「Ｉｔｅｍ」の多数のバージョンを維持する。それらは同じ「ＩｔｅｍＩＤ」を共有するが、各々は異なるバージョン番号を有する。「Ｉｔｅｍ」に保持される最新のバージョンの番号は、各バージョン「ＩｔｅｍＴｙｐｅ」ごとに特定することができる。デフォルトは無限である、すなわち、システムによって古いバージョンの自動消去は行われない。

１つの好適な実施形態では、「ＩｔｅｍＴｙｐｅ」内の２つの「ＣｏｍｐｏｎｅｎｔＴｙｐｅｓ」間の親−子関係は、親の「ＣｏｍｐｏｎｅｎｔＴｙｐｅ」を参照する子の「ＣｏｍｐｏｎｅｎｔＴｙｐｅ」（またはサブコンポーネント）に生成されるＲＤＢＭＳの外部キーによって維持される。このため、その親の「Ｃｏｍｐｏｎｅｎｔ」に対する各子の「Ｃｏｍｐｏｎｅｎｔ」（またはサブコンポーネント）の参照の一貫性は、ＲＤＢＭＳによって保証される。この実施形態では、「Ｉｔｅｍ」における各「Ｃｏｍｐｏｎｅｎｔ」は、少なくとも以下のシステム属性を含む。すなわち、「ＩｔｅｍＩＤ」、「ＣｏｍｐｏｎｅｎｔＩＤ」、およびＰａｒｅｎｔＩＤ、および任意選択として、「Ｉｔｅｍ」バージョン番号およびＡＣＬコード（Access Control List code）を含む場合がある。「ＩｔｅｍＩＤ」、「Ｉｔｅｍ」バージョン番号、およびＡＣＬコードは、ルート「Ｃｏｍｐｏｎｅｎｔ」のためだけに必要であるが、それらはアクセスを容易にするために全ての「Ｃｏｍｐｏｎｅｎｔ」に含ませることも可能である。また、他のシステム属性を含ませて、アクセスまたは保守を容易にすることができる。例えば「ＣｏｍｐｏｎｅｎｔＴｙｐｅ」、「Ｃｏｍｐｏｎｅｎｔ」の下の直接の子のコンポーネント数、等である。また、「ＩｔｅｍＴｙｐｅ」に規定された各「ＣｏｍｐｏｎｅｎｔＴｙｐｅ」ごとに別個のＲＤＢＭＳテーブルを生成する。すなわち、テーブルは、２つの「ＩｔｅｍＴｙｐｅｓ」間で共有されない。この設計は、論理を簡略化し、また、データベースのスケーラビリティを向上させる。異なる実施形地では、テーブルをいくつかの「ＩｔｅｍＴｙｐｅｓ」間で共有し、これらのいくつかの「ＩｔｅｍＴｙｐｅｓ」のために同様に規定したＣｏｍｐｏｎｅｎｔＴｙｐｅｓのコンポーネント（行）を格納することができる。この場合、「ＩｔｅｍＴｙｐｅ」をシステム属性としてこの共有テーブルに含ませて、アクセスを容易にすることができる。このようにテーブルを共有すると、サーチ範囲が、探索されている共通の属性（複数の属性）を含む多数の「ＩｔｅｍＴｙｐｅｓ」を含む場合、より高速なサーチが可能である。

図５に示すように、アイテム（子コンポーネント、孫コンポーネント、および属性を含む）は、リンクを用いて、例えばシステム・テーブルによって関係するかまたは互いに関連付けることができる。リンクは、「外部」関係であり、ＬｉｎｋＴｙｐｅ５５および任意選択のリンク「アイテム」５７と共に、ソース「アイテム」５１をターゲット「アイテム」５３に結び付ける。ソースまたはターゲット「アイテム」のいずれかに埋め込まれていないので、この関係は「外部」である。ＬｉｎｋＴｙｐｅは、カテゴリ化ラベルであり、アプリケーションが選択的に特定のタイプのリンクを横切るか探索することができるようになっている。リンク「アイテム」は、第３の「アイテム」であり、これを用いて、必要な場合にこの関係を記述することができる。リンクを用いて、集約関係および包含関係を含む、１対多および多対多の関係をサポートすることができる。

各関係の意味論は、高レベル・データ・モデルによって規定される。１例は、「フォルダリング」であり、この場合、フォルダを表す「アイテム」は、このフォルダに「含まれる」アイテム（文書または他のフォルダを表す）にリンクされる。例えば、ソース・アイテム５１は、ターゲット・アイテム５３のためのコンテナとして機能する。ソースまたはターゲット「アイテム」に対するリンクの結合は、バージョンに固有かまたはバージョン独立のいずれかとすることができる。前者は、アイテムの特定のバージョンを結合するのに対し、後者は、「アイテム」のいずれか／全てのバージョンを結合する。１実施形態では、リンクは、少なくとも以下の属性を含む１つ以上の専用ＲＤＢＭＳテーブルにおいて、行として維持される。すなわち、ソース「ＩｔｅｍＩＤ」、ソース「アイテム」バージョン番号、ターゲット「ＩｔｅｍＩＤ」、ターゲット「アイテム」バージョン番号、ＬｉｎｋＴｙｐｅ、リンク「ＩｔｅｍＩＤ」、およびリンク「アイテム」バージョン番号である。

図６に示すように、アイテムは、「アイテム」に含まれる他の属性と同様に維持される「アイテム参照」属性を用いて互いに関連付けることができる。「アイテム参照」属性は、「ＩｔｅｍＴｙｐｅ」３２内で「ＣｏｍｐｏｎｅｎｔＴｙｐｅ」３６の一部として生成されるユーザ規定属性である。この属性は、コンテンツ管理システムによって維持される特別なデータ・モデルを有する。これは、ターゲット「アイテム」３２’を指し示す参照５８を含む。リンクと同様、（図５）ターゲット「アイテム」３２’に対する参照５８の結合は、バージョンに固有のものかまたはバージョン独立のいずれかとすることができる。「アイテム参照」５８属性を指定すると、参照したアイテムのために参照の範囲および削除意味構造を規定する。この範囲は、参照したアイテムがどの「ＩｔｅｍＴｙｐｅ」（複数のＩｔｅｍＴｙｐｅ）に属することができるかを特定し、一方、削除意味構造は、参照した「アイテム」を削除する場合、参照の一貫性を保証するためにＲＤＢＭＳが維持する削除ルールと同様である。また、「アイテム参照」属性５８は、範囲指定なしとすることができ、その場合、参照した「アイテム」はいずれかの「ＩｔｅｍＴｙｐｅ」に属することができる。好適な実施形態において、均一に範囲指定された「アイテム参照」属性（すなわち範囲が単一の「ＩｔｅｍＴｙｐｅ」である場合）は、ＲＤＢＭＳ外部キーによってサポートされる。不均一に範囲指定された（すなわち範囲が多数の「アイテム」タイプを含む場合）および範囲指定なしの「アイテム参照」属性は、ＲＤＢＭＳトリガを用いてコンテンツ管理システムによって維持される。

この物理データ・モデルがサポートする別の特別なデータ・モデルは、これも図６に示すリソース参照属性５９のものである。図６に示すように、リソース参照５９は、コンテンツ管理システムのリソース・マネージャが管理するリソース６１に対する参照を含む。リソース・マネージャは、特定のタイプのリソースを管理する特殊用途サーバである。例は、大量の２進オブジェクトを管理するオブジェクト・サーバ、および、ストリーミング・オブジェクト（例えばオーディオおよびビデオ・コンテンツ）を管理し配信するストリーム・サーバである。拡張可能コンテンツ管理システムは、新しいリソース・マネージャに対応することができ、その各々は、特定タイプのリソースを管理するように特別に設計され、その特定の表現および方法は、必ずしもここに記載する物理データ・モデルによってモデル化する必要はない。コンテンツ管理システムが管理する未構成データは、主として、これらのリソース・マネージャの１つ以上によって内部で管理される。リソース参照の一貫性は、コンテンツ管理システムによって維持される。

本明細書中に記載する物理データ・モデルは、幅広い範囲の高レベル・データ・モデルをサポートして多種多様なアプリケーション・ドメインをカバーすると共に、多くの業界標準（例えばＤｕｂｌｉｎ Ｃｏｒｅ、ＸＭＬ）をサポートすることができる。同じく重要なのは、この物理データ・モデルが、高レベル・データ・モデルを効率的にサポートするようにデータベース最適化を可能とする十分な柔軟性も提供することである。１例では、高レベル・データ・モデルは、１つの「ＩｔｅｍＴｙｐｅ」のアイテムを用いて、独立の共有可能画像を表し、その各々はそれ自身の属性、バージョン、およびＡＣＬを有する。実際の画像は、リソースとして格納される。次いで、別の「ＩｔｅｍＴｙｐｅ」のアイテムを用いて文書を表現し、リンクを用いて、各文書をそれが含む画像に結合する。別の例では、高性能製品アプリケーションをサポートするため、単一の「アイテム」を用いて、文書に含まれる画像と共に文書を表現する。（また、実際の画像は、リソースとして格納する。）この場合、性能は重要であるが、画像を共有する必要は無い。

「ＩｔｅｍＶｉｅｗ（複数のＩｔｅｍＶｉｅｗ）は、「ＩｔｅｍＴｙｐｅ」に関して規定することができる。「ＩｔｅｍＶｉｅｗ」は、「ＩｔｅｍＴｙｐｅ」に対するアクセスを、ある「コンポーネント」テーブルおよび属性に制限するために名付けられたテンプレートである。これは、本質的に、「ＩｔｅｍＴｙｐｅ」における対応する「コンポーネント」テーブルのためのＲＤＢＭＳビュー集合である。

本発明の１つの応用は、例えば、磁気カード・セキュリティ・システム、クレジット・カード、またはデビット・カード、または現金自動預け払い機カード・システム、または航空頻度旅行システムにおいて用いられるような、分散型カード読み取り装置アクセスが行われるマルチメディア分散型データベース管理システムである。このシステムの１つのバージョンを、図７に示す。システム７０は、カード読み取り装置７０ａが読み取る、磁気または光カード７０ｂ上の識別指示、例えば暗号化データによって活性化される。

カード７０ｂを読み取った後、生物測定学的読み取りを行う。例示的な生物測定学的データは、とりわけ、指紋読み取り装置７０ｃにおける指紋、声紋およびサンプル、デジタル・カメラ７０ｄにおける顔画像、および眼の画像を含む。履歴、オーディオ、および画像データを、通常、別個のサーバ７２ａ、７３ａ、７４ａ、および７５ａによってアクセスおよび処理し、別個のデータベース７２ｂ、７３ｂ、７４ｂ、および７５ｂに格納し、例えば、指紋データ、音声データ、ならびに顔および眼の画像データを、マルチメディア・データ・オブジェクトとして、別個の指紋データ、音声データ、ならびに顔および眼の画像データベース上に格納し、かかる属性をデータ・モデルと（画像、画像データの数学的表現、オーディオ・データ、オーディオ・データの数学的表現）ならびにレポジトリ・アドレス（例えばＵＲＬまたはＩＰアドレス）とする。ここで、データはアイテムであり、データ・モデルのアドレスおよび定義は属性であり、検査官、警備員、会計係、航空代理店、または執行専門家に提示される画像はリソースである。

この方法およびシステムは、プログラム・プロダクトにおいて物理的に実施される。プログラム・プロダクトは、１つのコンピュータまたはいくつかのコンピュータまたは分散型サーバまたはディスクまたは複数のディスクまたはテープ上に存在することができる。プログラム自体は、分散型メディアまたは分散型サーバの場合のように、例えばインストールの前またはこれを１つ以上のコンピュータにインストールすることができる前に暗号化および／または圧縮することができる。

本発明の更に別の応用は、コンテンツ・スキーマおよびメタデータをマルチメディア・コンテンツ管理システムに取り込むための、ウイザードに似た（すなわち、質問をし、その答えまたは選択を用いて結果を生成する、構成した一連のダイアローグ）方法およびプログラム・プロダクトであり、高レベル・コンテンツ・モデルおよび低レベル物理モデルを含む。これは、コンテンツ・アイテムに関連しエンド・ユーザの応答に基づいたクエリをユーザに提示し、コンテンツ・アイテムに関連し応答に基づいた１つ以上の後続のクエリを提示し、アイテムのサブコンポーネントおよび属性を決定することによって達成される。

多数クライアント、コンテンツ管理サーバ、および多数コンテンツ・サーバを有するマルチメディア・データベース・システムを示す。 本発明の方法、システム、およびプログラム・プロダクトの層構造を示し、ＡＰＩの構造を高レベル・データ・モデルとして、一般的な低レベル・インフラストラクチャを物理データ・モデルとして有し、更に基礎にあるリレーショナル・データベース管理システムを有する。 図２のリレーショナル・データベース管理システムの簡略化した全体像を示し、ルート・コンポーネントのための行を有するアイテム・テーブルを含むと共にコンポーネントおよび属性セル（列）を含む階層ＲＤＢＭＳテーブル、サブコンポーネントおよび属性セル（列）を有するコンポーネント・テーブル、サブコンポーネントおよび属性の双方のための孫テーブルを、適切なポインタと共に示す。 図３のＲＤＢＭＳテーブル間の関連を示し、ルート・コンポーネント、子コンポーネト、および孫コンポーネントを含むアイテム・タイプの一例として、マッピングされたルート・テーブル、子テーブル、および孫テーブルを含むアイテム・タイプの横並びのマッピングを例示する。各コンポーネントは対応するテーブル内の行である。 図２のＲＤＢＭＳのテーブルにおける行を示し、ソース・アイテム、ターゲット・アイテム、およびリンク・アイテムに関連している。 ターゲット・アイテムに対するリソース参照のアプリケーションを示す。 例えばセキュリティ・システムにおいて、端末で用いる様々なサーバに格納されたマルチメディア・コンテンツを有する個人識別アプリケーションを示す。

Claims (10)

1. データベースにおいてマルチメディア・コンテンツ管理オブジェクトを表す方法であって、前記データベースはマルチメディア・コンテンツ・データの１つ以上の高レベル・コンテンツ・モデルおよび低レベル物理モデルを備え、前記低レベル物理モデルはデータ・エンジンへのマッピングを提供し、前記方法は、
   ａ．低レベル物理表現にマルチメディア・コンテンツ・データ・メタデータおよびスキーマを入力するステップと、
   ｂ．前記メタデータおよびスキーマを前記データ・エンジンにマッピングするステップと、
   を備える、方法。
2. 前記１つ以上の高レベル・コンテンツ・モデルは、データ構造および制約の表現を具現化するアプリケーション・プログラム・インタフェースを備える、請求項１に記載の方法。
3. 前記データ・エンジンは、リレーショナル・データベース管理システム、オブジェクト指向データベース管理システム、オブジェクト・リレーショナル・データベース管理システム、およびＸＭＬデータ・レポジトリから成る群から選択される、請求項１に記載の方法。
4. 前記データ・エンジンへのマッピングは、１つ以上のリレーショナル・データベース・テーブルにおいてマルチメディア・コンテンツ管理データを表すために適合されたリレーショナル・データベースにおいてマルチメディア・コンテンツ管理オブジェクトをアイテムとして表す方法を更に備え、前記リレーショナル・データベース・テーブルの各々は、複数の列を有する少なくとも１つの行を有し、前記方法は、
   ａ．第１のリレーショナル・データベース・テーブルにおいてオブジェクトのルート・コンポーネントをアイテムとして行に関連付けるステップと、
   ｂ．前記第１のリレーショナル・データベース・テーブルの対応する列に前記ルート・コンポーネントの属性を関連付けるステップと、
   ｃ．追加のリレーショナル・データベース・テーブルにおいて、もしあれば前記オブジェクトの追加コンポーネントを行に関連付けるステップと、
   ｄ．アイテムを構築ブロックとして用いて複数の高レベル・コンテンツ管理データ・モデルを構築するステップと、
   を備える、請求項１に記載の方法。
5. 前記マルチメディア・コンテンツ管理オブジェクトおよび前記リレーショナル・データベースを備えたマルチメディア・コンテンツ管理システムを管理する方法を更に備えた、請求項４に記載の方法。
6. 前記追加コンポーネントの各々は、ルート・コンポーネントの子コンポーネントまたは別のコンポーネントの子コンポーネントを備える、請求項４または５に記載の方法。
7. 属性は、別個のレポジトリに格納されたデータ・リソースに対するポインタを備える、請求項４または５に記載の方法。
8. テーブル内の行はソース・アイテムとターゲット・アイテム間のリンクを備える、請求項４または５に記載の方法。
9. 不揮発性メモリ記憶デバイスを有するデータ処理システム上で実行されると、前記システムに、請求項１ないし８のいずれか１項に記載の方法を実行させる命令を備えたコンピュータ・プログラム・プロダクト。
10. マルチメディア・データ・オブジェクト・アイテムを管理し、マルチメディア・データ・オブジェクト・コンテンツ・サーバを介してマルチメディア・データ・オブジェクト・コンテンツ・レポジトリからクライアントに配信するためのシステムであって、マルチメディア・データ・オブジェクトは、マルチメディア・データ・オブジェクト・アイテムを備え、該マルチメディア・データ・オブジェクト・アイテムの各々は、マルチメディア・データ・オブジェクト属性およびコンポーネントを備え、前記マルチメディア・データ・オブジェクト・コンテンツ・サーバは、制御され構成されて、
    ａ．第１のリレーショナル・データベース・テーブルにおいてオブジェクトのルート・コンポーネントを行に関連付け、
    ｂ．前記第１のリレーショナル・データベース・テーブルの対応する列に前記ルート・コンポーネントの属性を関連付け、
    ｃ．追加のリレーショナル・データベース・テーブルにおいて、もしあれば前記オブジェクトの追加コンポーネントを対応する行に関連付け、
    前記アイテムを構築ブロックとして用いて、複数の高レベル・データ・モデルを構築する、システム。

Images