図面 (/)

技術 電子的にアクセス可能なリソース及び/又はリソースの記述の処理方法

出願人 キヤノン株式会社
発明者 アーネストイューチャンワンアリソンジョアンレノン
出願日 2000年1月28日 (20年10ヶ月経過) 出願番号 2000-020137
公開日 2000年12月19日 (19年11ヶ月経過) 公開番号 2000-353120
状態 拒絶査定
技術分野 検索装置 計算機におけるファイル管理
主要キーワード 移送コスト 空間的レイアウト 発明家 対話型ツール しぼられ パターン文字 推論情報 参照要素
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2000年12月19日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

電子的にアクセス可能リソースについて記述を生成する方法。

解決手段

この方法はまず記述スキーム(702A)を読み込む。記述スキームはリソースに関する記述における記述子要素の定義を有する。リソース属性属性を表す表現値とリソース属性とを関連づけるように各記述子要素は定義され、記述子要素の定義は記述子要素の定義と関連して処理用コードの参照を有する。次いで、この方法は前記処理用コード(708A)を実行してリソースに関する記述を生成する。本発明の別の実施形態は処理用コードをこのような生成された記述(708B)に適用する。

概要

背景

ネットワークの接続が爆発的に増加し続け、デジタル記憶装置がより小型になり、高速になり、また安価になるにつれて、電子的にアクセス可能リソース量が非常に増大しつつある。このため利用可能なリソース発見所在位置が決定的に重要な問題になっている。これらの電子的にアクセス可能なリソースは、ネットワークを介して入手可能な(デジタル画像ビデオおよび音声などの)デジタルコンテンツウェブベースのリソース(例えば、HTML/XML文書)並びに電子装置(例えばプリンタディスプレイなど)である。さらに、他のリソースの電子的にアクセス可能なカタログがある。このカタログの中には電子的にアクセス可能でないもの(例えば書籍アナログフィルムメディアなど)もある。必要なことは、電子的にアクセス可能なものであれ、そうでないものであれ、リソースの所在場所を容易に得ることができるようにするためのリソースについての一貫した記述方法である。

一貫したリソースについての問題は2重になっている。第一に、リソース記述ついての標準的(整合的)方法の容認という問題がある。第2の問題は記述の生成に関連する。この生成過程コストが重要であることが多い。例えば、デジタル写真の利用は一貫して増加しているが、検索を容易にするためにデジタル写真について手書きで注釈をつけたり、記述したりする一般的傾向はないことがしばしば認められている。必要な方法で関心のあるリソースを検索することができなければ、人々は自分のリソースについて記述したり注釈をつけることをしない。

多くの場合、人々は与えられた例との類似性に基づいてリソースの検索を行うことを望む。必要とする類似性が記述のテキスト構成要素に基づくものである場合には、単純な文字列の類似性を測定することによって有益な結果を得ることができる。しかし、多くの場合、必要とする類似性は記述の非テキスト構成要素に基づくものである。例えば、カラーヒストグラムや領域隣接(region adjacency)グラフの類似性に基づいてデジタル画像リソースの検索を望んでいるグラフィックアーティストの場合を考えてみよう。記述の非テキスト構成要素間の類似性を計算する多くの方法があり、多くの場合類似性の計算方法には従うべき定義された処理が必要となる。

リソース記述に関するもう1つの重要な考慮事項として、記述が様々な電子的プラットフォームから且つ人間によって容易に可読可能でなければならないということがある。この可読性要件については、記憶と移送に関しては不適当費用を引き起こさずに達成可能であることが要求される。一方この可読性はセキュリティという問題を提起する。

概要

電子的にアクセス可能なリソースについて記述を生成する方法。

この方法はまず記述スキーム(702A)を読み込む。記述スキームはリソースに関する記述における記述子要素の定義を有する。リソース属性属性を表す表現値とリソース属性とを関連づけるように各記述子要素は定義され、記述子要素の定義は記述子要素の定義と関連して処理用コードの参照を有する。次いで、この方法は前記処理用コード(708A)を実行してリソースに関する記述を生成する。本発明の別の実施形態は処理用コードをこのような生成された記述(708B)に適用する。

目的

従来技術の1つまたはそれ以上の問題点を改良することが本発明の目的である。

効果

実績

技術文献被引用数
1件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

電子的にアクセス可能リソース記述方法であって、記述スキームを読み込むステップであって、前記記述スキームが、リソースに関する記述中に記述子要素の定義を含む宣言型記述定義言語を使用し、リソース属性をその属性を表す表現値と関連付けるように前記記述子要素の各々を定義し、少なくとも1つの前記記述子要素の定義が、リソースに関する記述中の関連する記述子要素のインスタンス生成を行うための処理用コードの参照を前記記述子要素の定義と関連付けるように成されるステップと、前記処理用コードを実行することによって前記リソースに関する記述を生成するステップと、を有することを特徴とする方法。

請求項2

前記記述は、人間と機械の双方によって解釈することができることを特徴とする請求項1記載の方法。

請求項3

前記電子的にアクセス可能なリソースがデジタルコンテンツから成るマルチメディアアイテムであることを特徴とする請求項1記載の方法。

請求項4

前記電子的にアクセス可能なリソースがワールドワイドウェブ入手可能な電子文書またはリソースであることを特徴とする請求項1記載の方法。

請求項5

前記電子的にアクセス可能なリソースが電子装置であることを特徴とする請求項1記載の方法。

請求項6

前記記述子のインスタンス生成のための処理用コードが、関連する記述子ハンドラによって与えられることを特徴とする請求項1記載の方法。

請求項7

前記記述子が前記処理用コードによってオプションとしてインスタンス生成されることを特徴とする請求項1記載の方法。

請求項8

記述子要素のインスタンス生成のための前記処理用コードがデジタル信号処理技術を用いて前記電子的にアクセス可能なリソースを解釈することを特徴とする請求項1記載の方法。

請求項9

クロスプラットフォーム計算言語を用いて前記記述子ハンドラが実行されることを特徴とする請求項6記載の方法。

請求項10

記述子ハンドラによって所定のプログラミングインターフェースが達成されることを特徴とする請求項6記載の方法。

請求項11

所定のプログラミング用インターフェースが前記記述スキームで指定されることを特徴とする請求項10記載の方法。

請求項12

所定のプログラミング用インターフェースが前記記述スキームで参照されることを特徴とする請求項10記載の方法。

請求項13

前記記述子ハンドラがオブジェクト指向プログラミング言語によって定義されるクラスであることを特徴とする請求項6記載の方法。

請求項14

前記関連する記述スキームと同じ記憶場所に記述子ハンドラが格納されることを特徴とする請求項6記載の方法。

請求項15

電子的にアクセス可能なリソースについて記述する方法において、前記リソースと関連する記述スキームを読み込むステップであって、前記記述スキームがリソースに関する記述中に記述子要素の定義を有し、さらに1つまたはそれ以上の前記記述子要素の定義が1つまたはそれ以上の処理用コードとつながる1つまたはそれ以上の記述ハンドラを前記記述子要素の定義と関連させるように成される前記読み込みステップと、前記1つまたはそれ以上の記述子要素の定義と関連する前記1つまたはそれ以上の記述ハンドラを特定するステップと、前記1つまたはそれ以上の記述ハンドラと関連する前記1つまたはそれ以上の処理用コードを特定するステップと、前記リソースの属性と関連する表現値を各々が持っている1つまたはそれ以上の前記記述子要素を生成するステップであって、前記リソースに対して、前記1つまたはそれ以上の処理用コードを適用し、前記処理用コードの各々が前記リソースの前記属性を表す前記表現値を生成するステップと、前記表現値の各々を前記リソース属性と関連させるステップとを有して成る前記記述子要素を生成するステップと、前記1つまたはそれ以上の生成された記述子要素を有する前記記述を出力するステップと、を有することを特徴とする方法。

請求項16

前記記述がツリーベースオブジェクトモデルの形を成していることを特徴とする請求項15記載の方法。

請求項17

前記ツリーベースのオブジェクト・モデルをマークアップ言語文書に対してシリアル化することを特徴とする請求項15記載の方法。

請求項18

記述子要素のインスタンス生成のための処理用コードがデジタル信号処理技術を用いて前記電子的にアクセス可能なリソースを解釈することを特徴とする請求項15記載の方法。

請求項19

前記クロス・プラットフォーム計算言語を用いて前記記述子ハンドラが実行されることを特徴とする請求項15記載の方法。

請求項20

前記記述子ハンドラによって所定のプログラミング用インターフェースが達成されることを特徴とする請求項15記載の方法。

請求項21

前記所定のプログラミング用インターフェースが前記記述スキームで指定されることを特徴とする請求項20記載の方法。

請求項22

前記所定のプログラミング用インターフェースが前記記述スキームで参照されることを特徴とする請求項20記載の方法。

請求項23

前記記述子ハンドラがオブジェクト指向プログラミング言語によって定義されるクラスであることを特徴とする請求項15記載の方法。

請求項24

前記関連する記述スキームとして同じ記憶場所に前記記述子ハンドラが格納されることを特徴とする請求項15記載の方法。

請求項25

電子的にアクセス可能なリソースについて記述するための装置において、記述スキームを読み込む手段であって、前記記述スキームが、リソースに関する記述中に記述子要素の定義を含む宣言型記述定義言語を使用し、リソース属性をその属性を表す表現値と関連付けるように前記記述子要素の各々を定義し、少なくとも1つの前記記述子要素の定義が、リソースに関する記述中の関連する記述子要素のインスタンス生成を行うための処理用コードの参照を前記記述子要素の定義と関連付けるように成される前記記述スキームを読み込む手段と、前記処理用コードを実行することによって前記リソースに関する記述を生成する手段と、を有することを特徴とする装置。

請求項26

電子的にアクセス可能なリソースについて記述する装置において、前記リソースと関連する記述スキームを読み込む手段であって、前記記述スキームがリソースに関する記述中に記述子要素の定義を有し、さらに1つまたはそれ以上の前記記述子要素の定義が1つまたはそれ以上の処理用コードとつながる1つまたはそれ以上の記述ハンドラを前記記述子要素の定義と関連させるように成される前記読み込み手段と、前記1つまたはそれ以上の記述子要素の定義と関連する前記1つまたはそれ以上の記述ハンドラを特定する手段と、前記1つまたはそれ以上の記述ハンドラと関連する前記1つまたはそれ以上の処理用コードを特定する手段と、前記リソースの属性と関連する表現値を各々が持っている1つまたはそれ以上の前記記述子要素を生成する手段であって、前記リソースに対して、前記1つまたはそれ以上の処理用コードを適用し、前記処理用コードの各々が前記リソースの前記属性を表す前記表現値を生成する手段と、前記表現値の各々を前記リソース属性と関連させる手段とを有して成る前記記述子要素を生成する手段と、前記1つまたはそれ以上の生成された記述子要素を有する前記記述を出力する手段と、を有することを特徴とする装置。

請求項27

電子的にアクセス可能なリソースについて記述するためのコンピュータプログラムを有するコンピュータ可読メディアにおいて、記述スキームを読み込むコードであって、前記記述スキームが、リソースに関する記述中に記述子要素の定義を含む宣言型記述定義言語を使用し、リソース属性をその属性を表す表現値と関連付けるように前記記述子要素の各々を定義し、少なくとも1つの前記記述子要素の定義が、リソースに関する記述中の関連する記述子要素のインスタンス生成を行うための処理用コードの参照を前記記述子要素の定義と関連付けるように成される前記記述スキームを読み込むコードと、前記処理用コードを実行することによって前記リソースに関する記述を生成するコードと、を有することを特徴とするコンピュータ可読メディア。

請求項28

電子的にアクセス可能なリソースについて記述するためのコンピュータ・プログラムを有するコンピュータ可読メディアにおいて、前記リソースと関連する記述スキームを読み込むコードであって、前記記述スキームがリソースに関する記述中に記述子要素の定義を有し、さらに1つまたはそれ以上の前記記述子要素の定義が1つまたはそれ以上の処理用コードとつながる1つまたはそれ以上の記述ハンドラを前記記述子要素の定義と関連させるように成される前記読み込みコードと、前記1つまたはそれ以上の記述子要素の定義と関連する前記1つまたはそれ以上の記述ハンドラを特定するコードと、前記1つまたはそれ以上の記述ハンドラと関連する前記1つまたはそれ以上の処理用コードを特定するコードと、前記リソースの属性と関連する表現値を各々が持っている1つまたはそれ以上の前記記述子要素を生成するコードであって、前記リソースに対して、前記1つまたはそれ以上の処理用コードを適用し、前記処理用コードの各々が前記リソースの前記属性を表す前記表現値を生成するコードと、前記表現値の各々を前記リソース属性と関連させるコードとを有して成る前記記述子要素を生成するコードと、前記1つまたはそれ以上の生成された記述子要素を有する前記記述を出力するコードと、を有することを特徴とするコンピュータ可読メディア。

請求項29

リソースの記述に対して処理を適用する方法において、前記リソースと関連する記述を読み込むステップであって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を有し、少なくとも1つの記述子要素が、前記記述子要素の定義と関連して前記記述に対して操作を行うための処理用コードの参照を行うようになっている前記読み込みステップと、前記処理用コードを実行することによって前記記述に対して操作を行うステップと、を有することを特徴とする方法。

請求項30

請求項29記載の方法において、前記記述が前記1つまたはそれ以上の記述子要素の定義を含む記述スキームに基づき、前記1つまたはそれ以上の記述子要素の前記定義が前記処理用コードの前記参照を更に含み、前記読み込みステップが、前記記述を読み込むサブステップと、前記記述スキームを読み込むサブステップと、を有することを特徴とする方法。

請求項31

前記処理用コードを用いて1つまたはそれ以上のリソースの記述の類似性を計算することを特徴とする請求項29記載の方法。

請求項32

前記処理用コードを用いてリソースに関する記述から成る記述子要素を符号化または復号化することを特徴とする請求項29記載の方法。

請求項33

前記符号化と復号化を用いてリソースに関する記述から成る記述子要素をそれぞれ圧縮解凍することを特徴とする請求項32記載の方法。

請求項34

前記符号化と復号化を用いてリソースに関する記述から成る記述子要素をそれぞれ暗号化し解読することを特徴とする請求項32記載の方法。

請求項35

関連する記述子ハンドラによって前記処理用コードが出力されることを特徴とする請求項32記載の方法。

請求項36

クロス・プラットフォーム計算言語を用いて前記記述子ハンドラが実行されることを特徴とする請求項35記載の方法。

請求項37

前記記述子ハンドラが所定のプログラミング用インターフェースを実装することを特徴とする請求項35記載の方法。

請求項38

前記所定のプログラミング用インターフェースが前記記述スキームで指定されることを特徴とする請求項37記載の方法。

請求項39

前記所定のプログラミング用インターフェースが前記記述スキームで参照されることを特徴とする請求項37記載の方法。

請求項40

前記記述子ハンドラがオブジェクト指向プログラミング言語によって定義されるクラスであることを特徴とする請求項35記載の方法。

請求項41

前記記述子ハンドラが前記関連する記述スキームと同じ記憶場所に格納されることを特徴とする請求項35記載の方法。

請求項42

2つの電子的にアクセス可能なリソース間の類似性の計算方法において、前記リソースと関連する記述を読み込むステップであって、前記記述の各々が1つまたはそれ以上の記述子要素を有し、各々の記述子要素が前記リソースの属性と関連する表現値を有し、さらに、少なくとも1つの前記記述子要素が前記記述子要素の定義と前記記述子に対して操作を行うための処理用コードの参照を関連させるようになっている前記読み込みステップと、前記処理用コードを実行することによって前記2つのリソース間の類似性を計算するステップであって、前記コードが、前記2つのリソースの前記2つの記述子要素の表現値の類似性をそれぞれ計算するようになっている前記類似性の計算ステップと、を有することを特徴とする方法。

請求項43

請求項42記載の方法であって、前記記述が各々前記1つまたはそれ以上の記述子要素の定義を有する記述スキームに基づき、さらに前記1つまたはそれ以上の記述子要素の前記定義が前記処理用コードの前記参照を更に有するようになっている前記方法において、前記記述スキームを読み込むステップを更に有することを特徴とする方法。

請求項44

同じ記述スキームを用いて前記2つのリソースが記述されることを特徴とする請求項42記載の方法。

請求項45

前記2つの電子的にアクセス可能なリソースがデジタル・コンテンツから成るマルチメディア・アイテムであることを特徴とする請求項42記載の方法。

請求項46

前記2つの電子的にアクセス可能なリソースがワールド・ワイド・ウェブを介して入手可能な電子文書またはリソースであることを特徴とする請求項42記載の方法。

請求項47

前記2つの電子的にアクセス可能なリソースが電子装置であることを特徴とする請求項42記載の方法。

請求項48

前記類似性の計算を行うための前記処理用コードが、関連する記述子ハンドラによって出力されることを特徴とする請求項42記載の方法。

請求項49

前記クロス・プラットフォーム計算言語を用いて前記記述子ハンドラが実行されることを特徴とする請求項48記載の方法。

請求項50

関連する記述子ハンドラによって前記処理用コードが出力され、前記記述スキームによって参照されるインターフェースによって前記記述子ハンドラが指定されることを特徴とする請求項42記載の方法。

請求項51

リソースの記述の1つまたはそれ以上の記述子要素を符号化または復号化する方法において、前記リソースと関連する記述を読み込むステップであって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、少なくとも1つの記述子要素が、前記記述子要素の定義と関連して前記記述に対して操作を行うための処理用コードの参照を行うようになっている前記読み込みステップと、前記処理用コードを実行することによって前記記述の1つまたはそれ以上の記述子要素を符号化または復号化するステップと、を有することを特徴とする方法。

請求項52

請求項51記載の方法であって、前記記述が前記1つまたはそれ以上の記述子要素の定義を有する記述スキームに基づき、前記1つまたはそれ以上の記述子要素の前記定義が前記処理用コードの前記参照を更に含むようにして成る方法において、前記記述スキームを読み込むステップを更に有することを特徴とする方法。

請求項53

関連する記述子ハンドラによって前記処理用コードが出力されることを特徴とする請求項51記載の方法。

請求項54

リソースの記述に対して処理を適用する方法において、前記リソースと関連する記述を読み込むステップであって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、前記記述が前記1つまたはそれ以上の記述子要素の定義を含む記述スキームに基づき、さらに1つまたはそれ以上の前記記述子要素の定義が、前記記述に対して操作を行うための1つまたはそれ以上の処理用コードを持っている1つまたはそれ以上の記述子ハンドラを該記述子要素の定義と関連させるようになっている前記読み込みステップと、前記記述スキームを読み込み、前記1つまたはそれ以上の記述子要素の定義と関連する前記1つまたはそれ以上の記述子ハンドラを特定するステップと、前記1つまたはそれ以上の記述子ハンドラと関連する前記1つまたはそれ以上の処理用コードを特定するステップと、前記1つまたはそれ以上の処理用コードを実行するステップと、を有することを特徴とする方法。

請求項55

リソースの記述に対して処理を適用する装置において、前記リソースと関連する記述を読み込む手段であって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、少なくとも1つの記述子要素が、前記記述子要素の定義と関連して前記記述に対して操作を行うための処理用コードの参照を行うようになっている前記読み込み手段と、前記処理用コードを実行することによって前記記述に対して操作を行う手段と、を有することを特徴とする装置。

請求項56

請求項55記載の装置において、前記記述が前記1つまたはそれ以上の記述子要素の定義を含む記述スキームに基づき、前記1つまたはそれ以上の記述子要素の前記定義が前記処理用コードの前記参照を更に含み、前記読み込み手段が、前記記述を読み込む手段と、前記記述スキームを読み込む手段と、を有することを特徴とする装置。

請求項57

前記処理用コードを用いて1つまたはそれ以上のリソースの記述の類似性を計算することを特徴とする請求項55記載の装置。

請求項58

前記処理用コードを用いてリソースに関する記述から成る記述子要素を符号化または復号化することを特徴とする請求項55記載の装置。

請求項59

前記符号化と復号化を用いてリソースに関する記述から成る記述子要素をそれぞれ圧縮/解凍することを特徴とする請求項58記載の装置。

請求項60

前記符号化と復号化を用いてリソースに関する記述から成る記述子要素をそれぞれ暗号化し解読することを特徴とする請求項58記載の装置。

請求項61

記述子要素のインスタンス生成のための処理用コードがデジタル信号処理技術を用いて前記電子的にアクセス可能なリソースを解釈することを特徴とする請求項55記載の装置。

請求項62

関連する記述子ハンドラによって前記処理用コードが出力されることを特徴とする請求項55記載の装置。

請求項63

クロス・プラットフォーム計算言語を用いて前記記述子ハンドラが実行されることを特徴とする請求項62記載の装置。

請求項64

前記記述子ハンドラによって所定のプログラミング用インターフェースが達成されることを特徴とする請求項62記載の装置。

請求項65

前記所定のプログラミング用インターフェースが前記記述スキームで指定されることを特徴とする請求項64記載の装置。

請求項66

前記所定のプログラミング用インターフェースが前記記述スキームで参照されることを特徴とする請求項64記載の装置。

請求項67

前記記述子ハンドラがオブジェクト指向プログラミング言語によって定義されるクラスであることを特徴とする請求項62記載の装置。

請求項68

前記記述子ハンドラが前記関連する記述スキームと同じ記憶場所に格納されることを特徴とする請求項62記載の装置。

請求項69

2つの電子的にアクセス可能なリソース間の類似性の計算装置において、前記リソースと関連する記述を読み込む手段であって、前記記述の各々が1つまたはそれ以上の記述子要素を有し、各々の記述子要素が前記リソースの属性と関連する表現値を持っていて、さらに、少なくとも1つの前記記述子要素が前記記述子要素の定義と前記記述子に対して操作を行うための処理用コードの参照を関連させるようになっている前記読み込み手段と、前記処理用コードを実行することによって前記2つのリソース間の類似性を計算する手段とを有し、前記コードが、前記2つのリソースの前記2つの記述子要素の表現値の類似性をそれぞれ計算するようになっていることを特徴とする装置。

請求項70

リソースの記述の1つまたはそれ以上の記述子要素を符号化または復号化する装置において、前記リソースと関連する記述を読み込む手段であって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、少なくとも1つの記述子要素が、前記記述子要素の定義と関連して前記記述に対して操作を行うための処理用コードを参照するようになっている前記読み込み手段と、前記処理用コードを実行することによって前記記述の1つまたはそれ以上の記述子要素を符号化または復号化する手段と、を有することを特徴とする装置。

請求項71

リソースの記述に対して処理を適用する装置において、前記リソースと関連する記述を読み込む手段であって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、前記記述が前記1つまたはそれ以上の記述子要素の定義を含む記述スキームに基づき、さらに1つまたはそれ以上の前記記述子要素の定義が、前記記述に対して操作を行うための1つまたはそれ以上の処理用コードを持っている1つまたはそれ以上の記述子ハンドラを該記述子要素の定義と関連させるようになっている前記読み込み手段と、前記記述スキームを読み込み、前記1つまたはそれ以上の記述子要素の定義と関連する前記1つまたはそれ以上の記述子ハンドラを特定する手段と、前記1つまたはそれ以上の記述子ハンドラと関連する前記1つまたはそれ以上の処理用コードを特定する手段と、前記1つまたはそれ以上の処理用コードを実行する手段と、を有することを特徴とする装置。

請求項72

リソースの記述に対して処理を適用するコンピュータ・プログラムを有するコンピュータ可読メディアにおいて、前記リソースと関連する記述を読み込むためのコードであって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、少なくとも1つの記述子要素が、前記記述子要素の定義と関連して前記記述に対して操作を行うための処理用コードの参照を行うようになっている前記読み込み用コードと、前記処理用コードを実行することによって前記記述に対して操作を行うためのコードと、を有することを特徴とするコンピュータ可読メディア。

請求項73

2つの電子的にアクセス可能なリソース間の類似性を計算するためのコンピュータ・プログラムを有するコンピュータ可読メディアにおいて、前記リソースと関連する記述を読み込むためのコードであって、前記記述の各々が1つまたはそれ以上の記述子要素を有し、各々の記述子要素が前記リソースの属性と関連する表現値を持っていて、さらに、少なくとも1つの前記記述子要素が前記記述子要素の定義と前記記述子に対して操作を行うための処理用コードの参照を関連させるようになっている前記読み込み用コードと、前記処理用コードを実行することによって前記2つのリソース間の類似性を計算するためのコードであって、前記コードが、前記2つのリソースの前記2つの記述子要素の表現値の類似性をそれぞれ計算するようになっている前記類似性の計算用コードと、を有することを特徴とするコンピュータ可読メディア。

請求項74

リソースの記述の1つまたはそれ以上の記述子要素を符号化または復号化するためのコンピュータ・プログラムを有するコンピュータ可読メディアにおいて、前記リソースと関連する記述を読み込むためのコードであって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、少なくとも1つの記述子要素が、前記記述子要素の定義と関連して前記記述に対して操作を行うための処理用コードの参照を行うようになっている前記読み込み用コードと、前記処理用コードを実行することによって前記記述の1つまたはそれ以上の記述子要素を符号化または復号化するコードと、を有することを特徴とするコンピュータ可読メディア。

請求項75

リソースの記述に対して処理を適用するコンピュータ・プログラムを有するコンピュータ可読メディアにおいて、前記リソースと関連する記述を読み込むためのコードであって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、前記記述が前記1つまたはそれ以上の記述子要素の定義を含む記述スキームに基づき、さらに1つまたはそれ以上の前記記述子要素の定義が、前記記述に対して操作を行うための1つまたはそれ以上の処理用コードを持っている1つまたはそれ以上の記述子ハンドラを該記述子要素の定義と関連させるようになっている前記読み込み用コードと、前記記述スキームを読み込み、前記1つまたはそれ以上の記述子要素の定義と関連する前記1つまたはそれ以上の記述子ハンドラを識別するためのコードと、前記1つまたはそれ以上の記述子ハンドラと関連する前記1つまたはそれ以上の処理用コードを特定するためのコードと、前記1つまたはそれ以上の処理用コードを実行するためのコードと、を有することを特徴とするコンピュータ可読メディア。

請求項76

複数のデータベース検索方法であって、各データベースが複数のリソースと、関連する記述スキームに基づく前記リソースについての関連する記述とを有し、前記記述の各々が、前記関連するリソースの属性と関連する表現値を持っている少なくとも1つの記述子要素を有し、さらに、前記記述スキームの各々が、前記少なくとも1つの記述子要素の定義と、前記関連する記述を生成するための第1の処理用コードの参照と、前記リソースの類似性を計算するための第2の処理用コードの参照と、を有するようになっている前記検索方法において、問合せとしてリソースを選択するステップと、前記データベースの前記関連する記述スキームの第1の処理用コードを実行することによって、前記データベースの各々について、前記選択されたリソースの記述を生成するステップであって、前記選択されたリソースの属性と関連する表現値を持っている前記少なくとも1つの記述子要素を前記記述が有するようになっている前記生成ステップと、前記データベースについての前記関連する記述スキームの前記第2の処理用コードを実行することによって、前記選択されたリソースと前記データベースの前記複数のリソースの各々との間の類似性を前記データベースの各々について計算を行うステップとを有し、前記コードが、前記選択されたリソースの表現値と、前記データベースの前記複数のリソースの中の前記それぞれのリソースとの類似性をそれぞれ計算するようになっていることを特徴とする方法。

請求項77

前記複数のデータベースが遠隔地に配置されることを特徴とする請求項76記載の方法。

請求項78

前記電子的にアクセス可能なリソースがデジタル・コンテンツから成るマルチメディア・アイテムであることを特徴とする請求項76記載の方法。

請求項79

前記電子的にアクセス可能なリソースがワールド・ワイド・ウェブを介して入手可能な電子文書またはリソースであることを特徴とする請求項76記載の方法。

請求項80

処理用コードの第1と第2の参照が記述子ハンドラによって行われることを特徴とする請求項76記載の方法。

請求項81

前記リソースが画像であり、前記第2の処理用コードがカラーヒストグラムの類似性を計算することを特徴とする請求項76記載の方法。

請求項82

前記リソースがデジタル信号を有し、前記第2の処理用コードが、デジタル信号処理手段を用いて前記2つのリソースの類似性を計算することを特徴とする請求項76記載の方法。

請求項83

複数のデータベースの検索システムであって、各データベースが複数のリソースと、関連する記述スキームに基づく前記リソースについての関連する記述とを有し、前記記述の各々が、前記関連するリソースの属性と関連する表現値を持っている少なくとも1つの記述子要素を有し、さらに、前記記述スキームの各々が、前記少なくとも1つの記述子要素の定義と、前記関連する記述を生成するための第1の処理用コードの参照と、前記リソースの類似性を計算するための第2の処理用コードの参照と、を有するようになっている前記システムにおいて、問合せとしてリソースを選択する手段と、前記データベースの前記関連する記述スキームの第1の処理用コードを実行することによって、前記データベースの各々について、前記選択されたリソースの記述を生成する手段であって、前記選択されたリソースの属性と関連する表現値を持っている前記少なくとも1つの記述子要素を前記記述が有するようになっている前記生成手段と、前記データベースについての前記関連する記述スキームの前記第2の処理用コードを実行することによって、前記選択されたリソースと前記データベースの前記複数のリソースの各々との間の類似性を前記データベースの各々について計算を行う手段とを有し、前記コードが、前記選択されたリソースと、前記データベースの前記複数のリソースの中の前記それぞれのリソースとの表現値の類似性をそれぞれ計算するようになっていることを特徴とするシステム。

請求項84

前記複数のデータベースが遠隔地に配置されることを特徴とする請求項83記載のシステム。

請求項85

前記電子的にアクセス可能なリソースがデジタル・コンテンツから成るマルチメディア・アイテムであることを特徴とする請求項83記載のシステム。

請求項86

前記電子的にアクセス可能なリソースがワールド・ワイド・ウェブを介して入手可能な電子文書またはリソースであることを特徴とする請求項83記載のシステム。

請求項87

処理用コードの第1と第2の参照が記述子ハンドラによって行われることを特徴とする請求項83記載のシステム。

請求項88

前記リソースが画像であり、前記第2の処理用コードがカラーヒストグラムの類似性を計算することを特徴とする請求項83記載のシステム。

請求項89

複数のデータベースを検索するコンピュータ・プログラムを有するコンピュータ可読メディアであって、各データベースが複数のリソースと、関連する記述スキームに基づく前記リソースについての関連する記述とを有し、前記記述の各々が、前記関連するリソースの属性と関連する表現値を持っている少なくとも1つの記述子要素を有し、さらに、前記記述スキームの各々が、前記少なくとも1つの記述子要素の定義と、前記関連する記述を生成するための第1の処理用コードの参照と、前記リソースの類似性を計算するための第2の処理用コードの参照と、を有するようになっている前記コンピュータ可読メディアにおいて、前記コンピュータ・プログラムが、問合せとしてリソースを選択するためのコードと、前記データベースの前記関連する記述スキームの第1の処理用コードを実行することによって、前記データベースの各々について、前記選択されたリソースの記述を生成するためのコードであって、前記選択されたリソースの属性と関連する表現値を持っている前記少なくとも1つの記述子要素を前記記述が有するようになっている前記生成用コードと、前記データベースについての前記関連する記述スキームの前記第2の処理用コードを実行することによって、前記選択されたリソースと前記データベースの前記複数のリソースの各々との間の類似性を前記データベースの各々について計算するためのコードとを有し、前記コードが、前記選択されたリソースと、前記データベースの前記複数のリソースの中の前記それぞれのリソースとの表現値の類似性をそれぞれ計算するようになっていることを特徴とするシステム。

--

(i) 含まれる項目を見せるために展開されたもの、あるいは含まれる項目を見せないようにするために隠されたもの

技術分野

0001

著作権についての告知>本文書には著作権保護に係わる事項が含まれる。著作権者は特許ファイルにおける本文書の転載あるいはの関係資料に対しては意義を申立てない。但し、それ以外に関してはすべての著作権を留保する。

背景技術

0002

本発明は電子的にアクセス可能リソース及び/又はリソースの記述に対して処理を適用するための方法及び装置に関する。また本発明は該装置及び方法を実現するためのコンピュータプログラム成果物に関する。

0003

ネットワークの接続が爆発的に増加し続け、デジタル記憶装置がより小型になり、高速になり、また安価になるにつれて、電子的にアクセス可能なリソース量が非常に増大しつつある。このため利用可能なリソースの発見所在位置が決定的に重要な問題になっている。これらの電子的にアクセス可能なリソースは、ネットワークを介して入手可能な(デジタル画像ビデオおよび音声などの)デジタルコンテンツウェブベースのリソース(例えば、HTML/XML文書)並びに電子装置(例えばプリンタディスプレイなど)である。さらに、他のリソースの電子的にアクセス可能なカタログがある。このカタログの中には電子的にアクセス可能でないもの(例えば書籍アナログフィルムメディアなど)もある。必要なことは、電子的にアクセス可能なものであれ、そうでないものであれ、リソースの所在場所を容易に得ることができるようにするためのリソースについての一貫した記述方法である。

0004

一貫したリソースについての問題は2重になっている。第一に、リソース記述ついての標準的(整合的)方法の容認という問題がある。第2の問題は記述の生成に関連する。この生成過程コストが重要であることが多い。例えば、デジタル写真の利用は一貫して増加しているが、検索を容易にするためにデジタル写真について手書きで注釈をつけたり、記述したりする一般的傾向はないことがしばしば認められている。必要な方法で関心のあるリソースを検索することができなければ、人々は自分のリソースについて記述したり注釈をつけることをしない。

0005

多くの場合、人々は与えられた例との類似性に基づいてリソースの検索を行うことを望む。必要とする類似性が記述のテキスト構成要素に基づくものである場合には、単純な文字列の類似性を測定することによって有益な結果を得ることができる。しかし、多くの場合、必要とする類似性は記述の非テキスト構成要素に基づくものである。例えば、カラーヒストグラムや領域隣接(region adjacency)グラフの類似性に基づいてデジタル画像リソースの検索を望んでいるグラフィックアーティストの場合を考えてみよう。記述の非テキスト構成要素間の類似性を計算する多くの方法があり、多くの場合類似性の計算方法には従うべき定義された処理が必要となる。

発明が解決しようとする課題

0006

リソース記述に関するもう1つの重要な考慮事項として、記述が様々な電子的プラットフォームから且つ人間によって容易に可読可能でなければならないということがある。この可読性要件については、記憶と移送に関しては不適当費用を引き起こさずに達成可能であることが要求される。一方この可読性はセキュリティという問題を提起する。

課題を解決するための手段

0007

従来技術の1つまたはそれ以上の問題点を改良することが本発明の目的である。

0008

本発明の1つの局面によれば、電子的にアクセス可能なリソースについて記述する方法が提供される。前記方法は、記述スキームを読み込むステップであって、前記記述スキームが、リソースに関する記述中に記述子要素の定義を含む宣言型記述定義言語を使用し、リソース属性をその属性を表す表現値と関連付けるように前記記述子要素の各々を定義し、少なくとも1つの前記記述子要素の定義が、リソースに関する記述中の関連する記述子要素のインスタンス生成を行うための処理用コードの参照を前記記述子要素の定義と関連付けるように成される前記記述スキームの読み込みステップと、前記処理用コードを実行することによって前記リソースに関する記述を生成するステップと、を有する。

0009

本発明の別の局面によれば電子的にアクセス可能なリソースについて記述する方法が提供される。前記方法は、前記リソースと関連する記述スキームを読み込むステップであって、前記記述スキームがリソースに関する記述中に記述子要素の定義を有し、さらに1つまたはそれ以上の前記記述子要素の定義が1つまたはそれ以上の処理用コードとつながる1つまたはそれ以上の記述ハンドラを前記記述子要素の定義と関連させるように成される前記読み込みステップと、前記1つまたはそれ以上の記述子要素の定義と関連する前記1つまたはそれ以上の記述ハンドラを特定するステップと、前記1つまたはそれ以上の記述ハンドラと関連する前記1つまたはそれ以上の処理用コードを特定するステップと、前記リソースの属性と関連する表現値を各々が持っている1つまたはそれ以上の前記記述子要素を生成するステップであって、前記リソースに対して、前記1つまたはそれ以上の処理用コードを適用し、前記処理用コードの各々が前記リソースの前記属性を表す前記表現値を生成するステップと、前記表現値の各々を前記リソース属性と関連させるステップとを有して成る前記記述子要素を生成するステップと、前記1つまたはそれ以上の生成された記述子要素を有する前記記述を出力するステップと、を有する。

0010

本発明のさらに別の局面によれば、電子的にアクセス可能なリソースについて記述するための装置が提供される。前記装置は、記述スキームを読み込む手段であって、前記記述スキームが、リソースに関する記述中に記述子要素の定義を含む宣言型記述定義言語を使用し、リソース属性をその属性を表す表現値と関連付けるように前記記述子要素の各々を定義し、少なくとも1つの前記記述子要素の定義が、リソースに関する記述中の関連する記述子要素のインスタンス生成を行うための処理用コードの参照を前記記述子要素の定義と関連付けるように成される前記記述スキームを読み込む手段と、前記処理用コードを実行することによって前記リソースに関する記述を生成する手段と、を有する。

0011

本発明のさらに別の局面によれば、電子的にアクセス可能なリソースについて記述するための装置が提供される。前記装置は、前記リソースと関連する記述スキームを読み込む手段であって、前記記述スキームがリソースに関する記述中に記述子要素の定義を有し、さらに1つまたはそれ以上の前記記述子要素の定義が1つまたはそれ以上の処理用コードとつながる1つまたはそれ以上の記述ハンドラを前記記述子要素の定義と関連させるように成される前記読み込み手段と、前記1つまたはそれ以上の記述子要素の定義と関連する前記1つまたはそれ以上の記述ハンドラを特定する手段と、前記1つまたはそれ以上の記述ハンドラと関連する前記1つまたはそれ以上の処理用コードを特定する手段と、前記リソースの属性と関連する表現値を各々が持っている1つまたはそれ以上の前記記述子要素を生成する手段であって、前記リソースに対して、前記1つまたはそれ以上の処理用コードを適用し、前記処理用コードの各々が前記リソースの前記属性を表す前記表現値を生成する手段と、前記表現値の各々を前記リソース属性と関連させる手段とを有して成る前記記述子要素を生成する手段と、前記1つまたはそれ以上の生成された記述子要素を有する前記記述を出力する手段と、を有する。

0012

本発明のさらに別の局面によれば、電子的にアクセス可能なリソースについて記述するためのコンピュータ・プログラムを有するコンピュータ可読メディアが提供される。前記コンピュータ・プログラムは、記述スキームを読み込むコードであって、前記記述スキームが、リソースに関する記述の中で記述子要素の定義を含む宣言型記述定義言語を使用し、リソース属性をその属性を表す表現値と関連付けるように前記記述子要素の各々を定義し、少なくとも1つの前記記述子要素の定義が、リソースに関する記述中の関連する記述子要素のインスタンス生成を行うための処理用コードの参照を前記記述子要素の定義と関連付けるようになっている、前記記述スキームを読み込むコードと、前記処理用コードを実行することによって前記リソースに関する記述を生成するコードと、を有する。

0013

本発明のさらに別の局面によれば、電子的にアクセス可能なリソースについて記述するためのコンピュータ・プログラムを有するコンピュータ可読メディアが提供される。前記コンピュータ・プログラムは、前記リソースと関連する記述スキームを読み込むコードであって、前記記述スキームがリソースに関する記述中に記述子要素の定義を有し、さらに1つまたはそれ以上の前記記述子要素の定義が1つまたはそれ以上の処理用コードとつながる1つまたはそれ以上の記述ハンドラを前記記述子要素の定義と関連させるように成される前記読み込みコードと、前記1つまたはそれ以上の記述子要素の定義と関連する前記1つまたはそれ以上の記述ハンドラを特定するコードと、前記1つまたはそれ以上の記述ハンドラと関連する前記1つまたはそれ以上の処理用コードを特定するコードと、前記リソースの属性と関連する表現値を各々が持っている1つまたはそれ以上の前記記述子要素を生成するコードであって、前記リソースに対して、前記1つまたはそれ以上の処理用コードを適用し、前記処理用コードの各々が前記リソースの前記属性を表す前記表現値を生成するコードと、前記表現値の各々を前記リソース属性と関連させるコードとを有して成る前記記述子要素を生成するコードと、前記1つまたはそれ以上の生成された記述子要素を有する前記記述を出力するコードと、を有する。

0014

本発明のさらに別の局面によれば、リソースの記述に対して処理を適用する方法が提供される。前記方法は、前記リソースと関連する記述を読み込むコードであって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、少なくとも1つの記述子要素が、前記記述子要素の定義と関連して前記記述に対して操作を行うための処理用コードの参照を行うようになっている前記読み込みステップと、前記処理用コードを実行することによって前記記述に対して操作を行うステップと、を有する。

0015

本発明のさらに別の局面によれば、2つの電子的にアクセス可能なリソース間の類似性の計算方法が提供される。前記方法は、前記リソースと関連する記述を読み込むステップであって、前記記述の各々が1つまたはそれ以上の記述子要素を有し、各々の記述子要素が前記リソースの属性と関連する表現値を持っていて、さらに、少なくとも1つの前記記述子要素が前記記述子要素の定義と前記記述子に対して操作を行うための処理用コードの参照を関連させるようになっている前記読み込みステップと、前記処理用コードを実行することによって前記2つのリソース間の類似性を計算するステップであって、前記コードが、前記2つのリソースの前記2つの記述子要素の表現値の類似性をそれぞれ計算するようになっている前記類似性の計算ステップと、を有する。

0016

本発明のさらに別の局面によれば、リソースの記述の1つまたはそれ以上の記述子要素を符号化または復号化する方法が提供される。前記方法は、前記リソースと関連する記述を読み込むステップであって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、少なくとも1つの記述子要素が、前記記述子要素の定義と関連して前記記述に対して操作を行うための処理用コードの参照を行うようになっている前記読み込みステップと、前記処理用コードを実行することによって前記記述の1つまたはそれ以上の記述子要素を符号化または復号化するステップと、を有する。

0017

本発明のさらに別の局面によればリソースの記述に対して処理を適用する方法が提供される。前記方法は、前記リソースと関連する記述を読み込むステップであって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、前記記述が前記1つまたはそれ以上の記述子要素の定義を含む記述スキームに基づき、さらに1つまたはそれ以上の前記記述子要素の定義が、前記記述に対して操作を行うための1つまたはそれ以上の処理用コードを持っている1つまたはそれ以上の記述子ハンドラを該記述子要素の定義と関連させるようになっている前記読み込みステップと、前記記述スキームを読み込み、前記1つまたはそれ以上の記述子要素の定義と関連する前記1つまたはそれ以上の記述子ハンドラを特定するステップと、前記1つまたはそれ以上の記述子ハンドラと関連する前記1つまたはそれ以上の処理用コードを特定するステップと、前記1つまたはそれ以上の処理用コードを実行するステップと、を有する。

0018

本発明のさらに別の局面によれば、リソースの記述に対して処理を適用する装置が提供される。前記装置は、前記リソースと関連する記述を読み込む手段であって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、少なくとも1つの記述子要素が、前記記述子要素の定義と関連して前記記述に対して操作を行うための処理用コードの参照を行うようになっている前記読み込み手段と、前記処理用コードを実行することによって前記記述に対して操作を行う手段と、を有する。

0019

本発明のさらに別の局面によれば、2つの電子的にアクセス可能なリソース間の類似性の計算装置が提供される。前記装置は、前記リソースと関連する記述を読み込む手段であって、前記記述の各々が1つまたはそれ以上の記述子要素を有し、各々の記述子要素が前記リソースの属性と関連する表現値を持っていて、さらに、少なくとも1つの前記記述子要素が前記記述子要素の定義と前記記述子に対して操作を行うための処理用コードの参照を関連させるようになっている前記読み込み手段と、前記処理用コードを実行することによって前記2つのリソース間の類似性を計算する手段とを有し、前記コードが、前記2つのリソースの前記2つの記述子要素の表現値の類似性をそれぞれ計算するようになっている。

0020

本発明のさらに別の局面によれば、リソースの記述の1つまたはそれ以上の記述子要素を符号化または復号化する装置が提供される。前記装置は、前記リソースと関連する記述を読み込む手段であって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、少なくとも1つの記述子要素が、前記記述子要素の定義と関連して前記記述に対して操作を行うための処理用コードの参照を行うようになっている前記読み込み手段と、前記処理用コードを実行することによって前記記述の1つまたはそれ以上の記述子要素を符号化または復号化する手段と、を有する。

0021

本発明のさらに別の局面によれば、リソースの記述に対して処理を適用する装置が提供される。前記装置は、前記リソースと関連する記述を読み込む手段であって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、前記記述が前記1つまたはそれ以上の記述子要素の定義を含む記述スキームに基づき、さらに1つまたはそれ以上の前記記述子要素の定義が、前記記述に対して操作を行うための1つまたはそれ以上の処理用コードを持っている1つまたはそれ以上の記述子ハンドラを該記述子要素の定義と関連させるようになっている前記読み込み手段と、前記記述スキームを読み込み、前記1つまたはそれ以上の記述子要素の定義と関連する前記1つまたはそれ以上の記述子ハンドラを特定する手段と、前記1つまたはそれ以上の記述子ハンドラと関連する前記1つまたはそれ以上の処理用コードを特定する手段と、前記1つまたはそれ以上の処理用コードを実行する手段と、を有することを特徴とする装置。

0022

本発明のさらに別の局面によれば、リソースの記述に対して処理を適用するコンピュータ・プログラムを有するコンピュータ可読メディアが提供される。前記コンピュータ・プログラムは、前記リソースと関連する記述を読み込むためのコードであって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、少なくとも1つの記述子要素が、前記記述子要素の定義と関連して前記記述に対して操作を行うための処理用コードの参照を行うようになっている前記読み込み用コードと、前記処理用コードを実行することによって前記記述に対して操作を行うためのコードと、を有する。

0023

本発明のさらに別の局面によれば、2つの電子的にアクセス可能なリソース間の類似性を計算するためのコンピュータ・プログラムを有するコンピュータ可読メディアが提供される。前記コンピュータ・プログラムは、前記リソースと関連する記述を読み込むためのコードであって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、少なくとも1つの記述子要素が、前記記述子要素の定義と関連して前記記述に対して操作を行うための処理用コードの参照を行うようになっている前記読み込み用コードと、前記処理用コードを実行することによって前記記述に対して操作を行うためのコードと、を有する。

0024

本発明のさらに別の局面によれば、リソースの記述の1つまたはそれ以上の記述子要素を符号化または復号化するためのコンピュータ・プログラムを有するコンピュータ可読メディアが提供される。前記コンピュータ・プログラムは、前記リソースと関連する記述を読み込むためのコードであって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、少なくとも1つの記述子要素が、前記記述子要素の定義と関連して前記記述に対して操作を行うための処理用コードの参照を行うようになっている前記読み込み用コードと、前記処理用コードを実行することによって前記記述の1つまたはそれ以上の記述子要素を符号化または復号化するコードと、を有する。

0025

本発明のさらに別の局面によれば、リソースの記述に対して処理を適用するコンピュータ・プログラムを有するコンピュータ可読メディアが提供される。前記コンピュータ・プログラムは、前記リソースと関連する記述を読み込むためのコードであって、前記記述が1つまたはそれ以上の記述子要素を有し、各記述子要素が前記リソースの属性と関連する表現値を持っていて、少なくとも1つの記述子要素が、前記記述子要素の定義と関連して前記記述に対して操作を行うための処理用コードの参照を行うようになっている前記読み込み用コードと、前記処理用コードを実行することによって前記記述の1つまたはそれ以上の記述子要素を符号化または復号化するコードと、を有する。

0026

本発明のさらに別の局面によれば、複数のデータベース検索方法が提供される。各データベースが複数のリソースと、関連する記述スキームに基づく前記リソースについての関連する記述とを有し、前記記述の各々が、前記関連するリソースの属性と関連する表現値を持っている少なくとも1つの記述子要素を有し、さらに、前記記述スキームの各々が、前記少なくとも1つの記述子要素の定義と、前記関連する記述を生成するための第1の処理用コードの参照と、前記リソースの類似性を計算するための第2の処理用コードの参照と、を有するようになっている前記方法において、問合せとしてリソースを選択するステップと、前記データベースの前記関連する記述スキームの第1の処理用コードを実行することによって、前記データベースの各々について、前記選択されたリソースの記述を生成するステップであって、前記選択されたリソースの属性と関連する表現値を持っている前記少なくとも1つの記述子要素を前記記述が有するようになっている前記生成ステップと、前記データベースについての前記関連する記述スキームの前記第2の処理用コードを実行することによって、前記選択されたリソースと前記データベースの前記複数のリソースの各々との間の類似性を前記データベースの各々について計算を行うステップとを有し、前記コードが、前記選択されたリソースと、前記データベースの前記複数のリソースの中の前記それぞれのリソースとの表現値の類似性をそれぞれ計算するようになっている。

0027

本発明のさらに別の局面によれば、複数のデータベースの検索システムが提供される。各データベースが複数のリソースと、関連する記述スキームに基づく前記リソースについての関連する記述とを有し、前記記述の各々が、前記関連するリソースの属性と関連する表現値を持っている少なくとも1つの記述子要素を有し、さらに、前記記述スキームの各々が、前記少なくとも1つの記述子要素の定義と、前記関連する記述を生成するための第1の処理用コードの参照と、前記リソースの類似性を計算するための第2の処理用コードの参照と、を有するようになっている前記システムにおいて、問合せとしてリソースを選択する手段と、前記データベースの前記関連する記述スキームの第1の処理用コードを実行することによって、前記データベースの各々について、前記選択されたリソースの記述を生成する手段であって、前記選択されたリソースの属性と関連する表現値を持っている前記少なくとも1つの記述子要素を前記記述が有するようになっている前記生成手段と、前記データベースについての前記関連する記述スキームの前記第2の処理用コードを実行することによって、前記選択されたリソースと前記データベースの前記複数のリソースの各々との間の類似性を前記データベースの各々について計算を行う手段とを有し、前記コードが、前記選択されたリソースと、前記データベースの前記複数のリソースの中の前記それぞれのリソースとの表現値の類似性をそれぞれ計算するようになっている。

0028

本発明のさらに別の局面によれば、複数のデータベースを検索するコンピュータ・プログラムを有するコンピュータ可読メディアが提供される。各データベースが複数のリソースと、関連する記述スキームに基づく前記リソースについての関連する記述とを有し、前記記述の各々が、前記関連するリソースの属性と関連する表現値を持っている少なくとも1つの記述子要素を有し、さらに、前記記述スキームの各々が、前記少なくとも1つの記述子要素の定義と、前記関連する記述を生成するための第1の処理用コードの参照と、前記リソースの類似性を計算するための第2の処理用コードの参照と、を有するようになっている前記コンピュータ可読メディアにおいて、前記コンピュータ・プログラムが、問合せとしてリソースを選択するためのコードと、前記データベースの前記関連する記述スキームの第1の処理用コードを実行することによって、前記データベースの各々について、前記選択されたリソースの記述を生成するためのコードであって、前記選択されたリソースの属性と関連する表現値を持っている前記少なくとも1つの記述子要素を前記記述が有するようになっている前記生成するためのコードと、前記データベースについての前記関連する記述スキームの前記第2の処理用コードを実行することによって、前記選択されたリソースと前記データベースの前記複数のリソースの各々との間の類似性を前記データベースの各々について計算を行うためのコードとを有し、前記コードが、前記選択されたリソースと、前記データベースの前記複数のリソースの中の前記それぞれのリソースとの表現値の類似性をそれぞれ計算するようになっている。

0029

添付図面を参照しながら本発明の実施形態について解説する。1つまたはそれ以上のいずれの添付図面においてもステップ及び/又は特性について参照を行う場合、同じ参照番号を持つステップ及び/又は特性は、異なる意図が表明されない限り、本解説の目的のために同じ機能乃至操作を表すものとする。

0030

本発明の実施形態については付属書類も参照しながら解説を行う。付属書類AはコアDDF要素定義を示す。付属書類Bはオーストラリアフットボールリーグ試合サンプル記述スキームを示す。付属書類Cは付属書類Bの記述スキームから生成されたサンプル記述を示す。付属書類Dはデジタルビデオ・リソース記述スキームを示す。付属書類Eは付属書類Dのビデオ記述スキームから生成されたサンプル記述を図示する。付属書類Fは付属書類Dのビデオ記述スキームの表現ルールを示す。付属書類Gはデジタルビデオ・ライブラリ記述スキームを示す。付属書類Hは付属書類Gのデジタルビデオ・ライブラリ記述スキームから生成されたサンプル記述を示す。付属書類Iはビデオ表現用記述スキームを示す。付属書類Jは付属書類Iのビデオ表現用記述スキームから生成されたサンプル記述を示す。付属書類KはDOM要素ノードを示す。
目次
1 序論
1.1術語
1.1.1コンテンツ
1.1.2リソース
1.1.3 特性
1.1.4記述子(ディスクリプタ
1.1.5記述
1.1.6 記述スキーム
1.2 記述子関係
1.3 方法の実施概要
2. 動的記述の枠組
2.1 概要
2.2オブジェクトモデル
2.2.1 概要
2.2.2 記述子・クラ
2.2.3アトミック記述子値クラス
2.2.4 記述子ハンドラ・クラス
2.2.5 記述クラス
2.3 記述処理用API
2.4シリアル化シンタックス
2.4.1 記述子関係表現
2.4.1.1一般化特殊化関係
2.4.1.1.1 コンテンツ・モデル継承
2.4.1.1.2属性継承
2.4.1.1.3 実施細目
2.4.1.2同値関係
2.4.1.3関連付け関係
2.4.1.4 空間的、時間的、概念的関係
2.4.1.5ナビゲーション関係
2.4.2 特定・特有データ型を示す表現
2.5 実施上の問題点
3. シリアル化シンタックス仕様
3.1.1 要素定義
3.1.2 コアDDF要素定義
3.1.2.1 記述子定義
3.1.3 空間的、時間的、概念的関係を表す記述子
3.1.4 ナビゲーション関係を表す要素
4. DESOM API仕様
4.1.1インターフェース・記述子
4.1.2 インターフェース・記述子ハンドラ(DescriptorHandler)
4.1.3 インターフェース・アトミック・デスクリプタ値(AtomaticDescriptorvValue)
5. 記述スキームの例
6. 処理の適用方法
6.1電子的にアクセス可能なリソースの記述生成方法
6.2 記述に対する処理の適用方法
6.3 記述生成及び記述に対する処理の適用方法の例
7. DESOMを用いるルール依存処理
8. リソースの記述拡張方法
9. リソースの記述の呈示方法
10. リソース記述の選択方法
11. リソースの記述の翻訳方法
12. 装置の第1の実施形態
13. 装置−デジタルビデオ・ブラウザ・システムの第2の実施形態
14. 装置−遠隔デジタルビデオ・ブラウザ装置の第3及び第4の実施形態
15. 装置−メディア・ブラウザ・システムの第5の実施形態
1. 序論
実施形態をよく理解するために、術語(第1章1項)についての簡単なレビューを含む序論(第1章)からまず始め、次いで記述構成要素間の関係(第1章2項)、DDF(第2章)、シリアル化シンタックス仕様(第3章)、実施形態で使用されるDesOMAPI仕様(第4章)の解説を行う。次いで実施形態についてのさらに詳細な解説は第6章から第15章の中で行う。

0031

以下に続く詳細な解説の一部はアルゴリズムおよびコンピュータ・メモリ内のデータに関する操作を表す記号的表現に関するものであることが明白にあるいは暗黙に示されている。これらのアルゴリズム的記述と表現は、自分の仕事中身を他の当業者に最も効率良く伝えるためにデータ処理に係わる当業者が使用している手段である。本明細書では、アルゴリズムとは、自己矛盾のない一続きの所望の結果へ導くステップであると一般に考えられているものである。これらのステップは物理量の物理的操作を必要とするものである。必ずしもそうというわけではないが通常これらの量は、記憶、転送、合成、比較また他の方法で操作可能な電気信号磁気信号の形をとる。ビット、値、要素、記号、文字、用語、数字あるいはこれらと同種のものとしてこれらの信号を考えることが主として共通利用という理由のために好都合であることが判っている。

0032

しかし、上記および類似する用語のすべては、適切な物理量と関連するものであり、これらの量に適用するための都合の良いラベルにすぎないということを覚えておくべきである。以下の解説から明らかなように、特に別途言明されないかぎり、本発明を通じて、“処理する”“計算する”“生成する”“作成する”“操作する”“通信する”“描画する(rendering)”“出力する(providing)”“リンクする”という用語あるいはこれらと同種の用語が用いられる記載は、コンピュータ・システムあるいは類似の電子計算装置アクションと処理について述べるものである。このシステムあるいはアクションによって、コンピュータ・システムのレジスタとメモリ内の(電子的)物理量として表されるデータが操作され、コンピュータ・システムのメモリまたはレジスタまたは他のそのような情報の記憶、伝送あるいは表示装置内の物理量として同様に表される他のデータへこのデータが変換されるものと理解すべきである。

0033

本発明はまた本発明で動作する装置に関する。本装置は、必要な目的のために特に構成したり、選択的に起動したり、コンピュータに記憶されたコンピュータ・プログラムによって再構成される汎用コンピュータを有することができる。本明細書に示されているアルゴリズムと表現は、特定のコンピュータや他の装置に固有のものとして関連づけられているものではない。本明細書の教示に従うプログラムを用いて種々の汎用機械を使用することもできる。あるいは必要な方法ステップを行うためにもっと特殊な装置を構成する方が好都合であることが判明する場合もある。従来型の汎用コンピュータの構造は以下の解説から明らかになる。

0034

さらに、本発明はまたこれらの好ましい方法を実行するためのコンピュータ・プログラムを含むコンピュータ可読メディアを有するコンピュータ・プログラム成果物に関する。本明細書では、コンピュータ可読メディアとはソースと宛先との間でコンピュータ・プログラムを伝送するための任意の伝送メディアを含むものとする。この伝送メディアには、磁気ディスク光ディスク、メモリ・チップ、あるいは汎用コンピュータとのインターフェースに適した他の記憶装置のような記憶装置が含まれる。伝送メディアはインターネット・システムで例示されるようなハードウェアにより実現されるメディアやGSM移動電話システムで例示されるような無線メディアも含むことができる。このコンピュータ・プログラムは、特定のプログラム言語やその実行への限定を意図するものではない。様々なプログラム言語とその実行を利用して、本明細書で解説するように本発明の教示を実現することができる。
1.1術語
1.1.1コンテンツ
コンテンツとは、記憶、符号化、表現、伝送、メディア、技術のいずれにかかわらず情報であると定義することができる。コンテンツの例には、デジタルビデオとアナログビデオ(MPEG-4ストリームビデオテープのような)あるいはフィルム音楽、紙に印刷された書籍及びウェッブページが含まれる。
1.1.2リソース
リソースとは上述のコンテンツの特定の単位である。リソースの例にはビデオ・ストリーム、JPEG-2000画像、WAVEオーディオ・ファイルが含まれる。
1.1.3 特性
特性とはリソースの特色のある部分すなわち特質であり、この特性はある人にとって何らかの点で意味のあるものを表す。特性は、コンテンツ(例えば画像の支配的カラー)から直接得る(すなわち取り出す)こともできるし、あるいはコンテンツの関連する特質である場合もある。特性の例には、画像を録画した人の氏名、画像の色、ビデオのスタイル映画タイトル、書籍の著作者音楽作品作曲者、オーディオ・セグメントピッチ、映画に出演している俳優が含まれる。
1.1.4記述子
記述子は、表現値をある特性と関連づけるものであり、表現値がアトミック・タイプまたは複合タイプのいずれかを持つようにすることができる。表現値はアトミック・タイプまたは複合タイプのいずれかを持つようにすることができる。アトミック・タイプは、所定のデータ型の基本セット(例えば、整数、文字列、日付など)の中の1つとして定義される。複合タイプは1つまたはそれ以上の記述子のコレクションであると定義される。記述子は特性−表現値のペアを有する。この場合表現値はその特性と関連付けられる。アトミック・タイプを持っているサンプル・記述子には以下が含まれる:
特性=著作者;表現値(文字列)=“John Smith”;
特性=作成日付(DateCreated); 表現値(日付)=“1998-08-08”
複合タイプを持っているサンプル・記述子は、
特性=色;表現値=カラーヒストグラム・記述子(ColorHistogramDescriptor)
1.1.5記述
記述とは単一リソースに属する複合タイプを持っている記述子である。
1.1.6記述スキーム
記述スキームとは1セットの記述子定義とそれらの関係(関連付け、同値、特殊化、一般化)である。これらの記述子関係を利用してコンテンツの構造を直接表現したり、より高レベルコンセプトを示すもっと豊富な表現を形成する記述子の組合せを作成することができる。記述スキームにはその範囲内に1セットの記述スキームが含まれる。
1.2 記述子関係
記述スキームに必要な情報を表現するために、DDFによって、最小1セットの記述子関係が好適に与えられる。この最小セットには以下の関係が含まれる:
* 一般化/特殊化関係
*関連付け関係
*同値関係
* 空間的、時間的、概念的関係
*ナビゲーション関係
一般化/特殊化関係は、ある特別の記述子が別の記述子を示すもっと特定のあるいはもっと一般的な形であることを指定するものであり、従ってこれらの関係は処理用アプリケーションによってその様なものとみなすことができる。例えば動物一種であり、従って動物記述子の発生を検索する検索エンジンは“猫”記述子を含む記述を選択することになる。

0035

関連付け関係は記述子包含(containment)と発生のシーケンス基数性(cardinality)を含むように定義される。これらの関係は所定の記述子に対して文脈上の情報を与え、アプリケーションが特定の記述子を解釈することができる文脈を与えるために必要である。例えば、ビデオ記述スキームの中の“ビデオシーン(VideoScene)”記述子内に含まれる“Shot(ショット)”記述子は音響効果記述スキームにおける別の文脈の“Shot(ショット)”記述子から様々に解釈されることになろう。

0036

同値関係とは類別関係の1つの形である。この関係は必ずしも一般化/特殊化を示す性質の関係ではない。同値関係は言語の間で(すなわち言語間)及び言語の範囲内(すなわち言語内)で望ましい。一般に同値は同意語の定義(2つの記述子が同値である)と準同意語(2つの記述子がある特定の程度まで同値である)を必要とする。また非テキスト値(例えば画像中の平均R、G、B値)とテキスト表現値(例えば赤、緑など)間の同値関係およびその逆の同値関係を定義する必要性がある。

0037

ある記述における記述子間の空間的、時間的、概念的関係を利用することもできる。これらの関係は、画像中の隣接するオブジェクト、ビデオ場面中のシーケンシャル・セグメント、記述中の類似コンセプトの記述をサポートする。

0038

記述子間のナビゲーション関係もまた望ましい。記述の利用には記述の構成要素と(ビデオ・リソース中のキーフレームのような)リソース中の関連する時空の範囲間のナビゲーションを伴うことが多い。

0039

これらの関係を一緒に考察して、異なる記述スキーム間のあるレベルの意味論的インターオペラビリティをある程度まで示すことができる。更に、意味論的インターオペラビリティのレベルもアプリケーション・レベルで達成することもできよう。
1.3 方法の実施概要
本明細書で解説する方法は、動的記述の枠組み(DDF)を利用してリソースの記述を生成し処理する方法についての一般化した形式を示す特定の例である。オブジェクト・モデル、プラットフォーム−中立的及び言語−中立的アプリケーション・プログラミング用インターフェース(API)及び、リソースの記述で、特に視聴覚リソースの記述で使用するためのシリアル化シンタックス・リソースがこの枠組みによって与えられる。好ましいDDFは、作成と記述処理と記述構成要素とのための処理方法とコンテンツの宣言型記述の利益を一体化するものである。

0040

図1Aは電子的にアクセス可能なリソースについての記述を生成する方法の概要を示す。本方法では、記述スキーム(DS)100Aが記述生成装置106Aによって読み込まれ、該記述生成装置によってメモリの中のリソースの記述107Aの表現108Aが順次生成される。この表現108AはDDFの記述オブジェクト・モデル(DesOM)の1つのインスタンスである。記述107Aの表現108Aは、記憶と移送を目的としてXML文書110Aとしてシリアル化することができる。好適には記述スキーム100Aとシリアル化された記述110Aの双方はテキストであり、機械と人間とによって双方とも可読であることが望ましい。記述スキーム100AはDescriptorHandlerと呼ばれる関連する処理用コードを備えて、記述情報やリソース104Aに対する他のアクションを曖昧性の無いように提供し生成することができる動作/処理を行えるようになっていることが更に望ましい。例えば、オペレーティング・モードにおける1つの方法によってリソース104Aの記述107Aを自動的に生成することができる。このオペレーティング・モードで、これらDescriptorHandlerの処理によってリソース104Aに対する操作が行われ、特定のリソース104Aの記述107Aが生成される。これらの記述スキーム100Aと記述107Aとは上述のDDFの観点から定義される。

0041

図1Bはリソースの記述を処理する方法の概要を示すものである。本方法では、メモリ中の記述の表現104Bを順次生成するプロセッサ102Bによってシリアル化された記述100Bの構文解析が行われる。表現104BはDDFのDesOMの1つのインスタンスである。このようなシリアル化された記述100Bを図1Aの方法に従って生成することもできる。好適にはプロセッサ102Bと記述生成装置106A(図1A)とを1つのユニットとして組み入れることが望ましい。シリアル化された記述100Bは、いくつかの記述ハンドラ108Bを順次参照することもできる記述スキーム106Bを指す。またシリアル化された記述100Bはこの記述が記述するリソース110Bも参照する。本方法では、1セットのルールを記述(D)104BのDesOM表現に適用して記述112Bの修正されたDesOM表現を行うこともできる。[用語D+を用いて図1Bの記述112Bの修正されたDesOM表現を示す]記述112Bの修正されたDesOM表現をXML文書としてシリアル化することができる。この1セットのルールは記述スキーム106Bによって定義される。DescriptorHandler108Bによって、記述114BのDesOM表現あるいは記述116Bの修正されたDesOM表現の更なる処理が行われる。1つのオペレーティング・モードでは、この処理方法によってリソース110B間の類似性の計算を行うことができる。このモードで、DescriptorHandlerによってリソースの記述間の類似性を計算するための処理が行われる。この処理方法では、記述104BのDesOM表現に対して1セットのルール118Bが更に適用されるようになっている。1セットのルール118Bが、シリアル化された記述100Bの所定の構成要素の存在に依存して、記述104Bに対する1つまたはそれ以上の関連するアクションが与えられる。この結果得られるこれらのアクションの出力はそれ自体DesOM112Bに従う記述を表現したものである。更に、ある記述スキームをメモリ中へ読み込むこともでき、次いで、記述スキーム自体に対して1つまたはそれ以上の関連するアクションを行うための1セットのルールを設けることができる。これらのセットのルールによって、リソース記述の拡張、リソース記述の変換、問合せに応じた1つまたはそれ以上の特定の記述の選択、リソース記述と多くの他のアクションの視覚呈示を行うことができる。

0042

図1Cはリソースの記述を符号化する方法の概要を示す。本方法では、記述スキーム(DS)104Cが記述生成装置108Cによって読み込まれ、該記述生成装置によってメモリ中のリソースに関する記述の表現110Cが順次生成される。この表現110CはDDFのDesOMの1つのインスタンスである。記述スキーム104Cは関連する処理用コードを備え、DescriptorHandler(DH)によって、DesOM表現110Cに対して符号化処理114Cが行われるようになっている。これらの符号化処理によってDesOM表現110Cは符号化され、符号化されたDesOM112Cが与えられる。この記述の符号化されたDesOM表現112Cは記憶と移送を行うためにXML文書としてシリアル化することができる。この符号化処理を好適に利用して圧縮及び/又は暗号化が行われる。

0043

図1Dは符号化されたリソース記述の復号化を行う方法の概要を示す。本方法はその入力としてシリアル化された記述104Dを有し、該記述は図1Cの方法によってすでに符号化されている。本方法では、メモリ中の記述の符号化された表現112Dを順次生成するプロセッサ110Dによって、シリアル化された記述104Dの構文解析が行われる。表現112Dは符号化されたDesOMの1つのインスタンスである。記述スキーム106Dは、関連する処理用コード(記述子ハンドラと呼ばれる)を備え、復号化操作114Dを行えるようになっている。該復号化操作は、符号化されたDesOM表現112Dを復号化してメモリ中に記述の復号化された表現116Dを出力することができるようになっている。表現116DはDDFのDesOMの1つのインスタンスである。
2. 動的記述の枠組み
2.1 概要
好ましいDDFは、コンテンツの宣言型記述の利点を記述子の作成と処理を行うための処理方法と一体化することを企図するものである。好ましいDDFは、オブジェクト・モデル、記述処理用APIおよびシリアル化シンタックスを備えている。DDFを利用して、上記構成要素を用いるコンテンツについて適切な記述を行うことができる。

0044

上記オブジェクト・モデルは記述の核となる意味論を与え、記述子・エンティティ構成要素に基づくものである。このモデルは、包含関係がモデルにおいて固有であるという利点を有する。この包含関係は、2つの理由で視聴覚リソースの記述において特に重要である。まず第一に、多くの視聴覚リソースの構造には固有の階層構造(例えばビデオクリップにはキー・フレームなどを含むショットが含まれる)がある。第2に、多くの記述子の表現値は階層的方法(例えばヒストグラムは周波数を含むビン(bin)が含まれる)で表すことができる複雑なデータ型となることがある。好ましいDDFのオブジェクト・モデルは記述オブジェクト・モデル(DesOM)と呼ばれる。第2章.2でこのモデルについて解説する。

0045

好ましいDDFはまた記述処理用としてAPIを使用する。これによってアプリケーション用ツールがシリアル化された記述に対して更なる処理(例えば変換、表現など)を行うことが可能になる。第2章.3で更に説明する好ましいAPIは文書オブジェクト・モデル(DOM呼ばれる)に基づく。このモデルはXML文書に関して使用されるW3Cによって標準化されている。

0046

DesOMAPIによってルール依存処理の適用も可能になり、このルール依存処理を利用して以下の事項が可能になる。
* 記憶された記述子の存在または非存在に基づいて追加記述子の存在を推論することにより記述を拡張すること
* 記述の表現に対する影響/制御を行うこと
* 記述または記述構成要素を選択すること
* 記憶された記述を要件に基づいて別の言語へ変換すること
* 記述を変換して新しい記述スキームを使用すること
このルール依存処理については第7章から第11章で更に詳細に解説する。

0047

DesOMのツリーベースの構造(そしてさらにつけ加えるならばDOM)は好ましいデータ・モデルのような階層的に構造化されたデータを適切に表現したものである。

0048

DDFは記述および記述スキームの記憶と移送を行うためにシリアル化シンタックスを好適に利用する。シリアル化された記述は構文解析を行ってDesOMの1つのインスタンスに変えることができる。さらに、シリアル化シンタックスによって、第1章.2で詳述する記述子関係を表現する手段が与えられる。XML文書タイプ定義(DTD)のシンタックスを用いて記述スキームとXML文書を表現して個々の記述のシリアル化が行われる。記述スキームと個々の記述の双方の表現シンタックスはシリアル化シンタックスと呼ばれる。

0049

XMLはシリアル化シンタックスとして利用されているが、その理由は、包含関係を表現するXML固有の能力およびXMLの構造化電子データの伝送形式としてますますXMLが受け入れられていることに因るものである。記述スキームは、XML-DTDの文法を用いて表すことができ、このXML-DTDの文法で個々の要素定義が、記述子の定義及び記述スキームにおける記述子の関係を示す定義を表す。個々の記述は、適切な記述スキームを含むDTDに従うXML文書としてシリアル化することができる。好ましいオブジェクト・モデルと必要な記述子関係とをシリアル化シンタックスを用いてどのように表現するかについては第2章.4に述べられている。

0050

シリアル化シンタックスとしてXMLを使用することにより、DDF準拠の記述の可能性を理論的に2つのレベルで解釈することが可能になる。まず第一に、任意のシリアル化された記述をXMLシンタックス・レベルで解釈することができる。このレベルで、記述の構文解析を行い、DOMのようなオブジェクト・モデルに変換し、DDFについての知識を持たない検索/フィルタエンジンでもそのテキスト内容の点から記述を解釈することができる(すなわち、DDFのオブジェクト・モデルの意味論は記述の解釈に使用されない)。或いは、DOMの代わりにDDFオブジェクト・モデル(DesOM)を使用することによりもっと意味論的レベルで記述の構文解析を行うこともできる。

0051

しかしながら、実際問題として、XML-DTDシンタックスを用いて表現された記述スキームの構文解析を行って、このスキームをXML-DTDに変える必要があり、そこで、記述子特殊化/一般化関係が検証され、実際に創り出されることになる(更なる詳細については第2章.4.1.1参照)。XMLのバージョン1.0ではクラスの下位分類すなわち継承が行われないのでこのステップが必要となる。このステップはDDF解釈と呼ばれ、このステップを行う処理はDDFインタプリタである。記述スキームのDDF定義を含むDTDと、記述(すなわちXMLバージョン1.0文書)が準拠するDTDとを区別するために、XML-DTD用として一般に使用されている“dtd”の代わりに拡張子“ddf”を使用するDDFをDTDと命名することにする。

0052

次いで、標準的XMLプロセッサによって、シリアル化された記述の構文解析を行い、その準拠するDTD(すなわち拡張“dtd”を使用して記憶されたDTD)から得たDOMを用いてこの記述を表すことができる。このプロセッサはDDFと記述内容についての知識を必要とせず、テキストレベルでアクセスすることができる。[記述へのテキスト・アクセスは、記述(XML文書)に目を通したり、DOM(例えばSAX)に基づかないXMLプロセッサを使用するだけで行うこともできる]或いは、DDFプロセッサはシリアル化された記述の構文解析を行って、DDF(すなわち拡張子“ddf”を用いて記憶されたDTD)を用いて表現された記述スキームを含むDTDから得られるDesOMを用いてこの記述を表すことができる。後者の処理の第1のステップはDDF解釈の中の1つである。

0053

この2つのレベルの解釈の処理が図2Aと2Bに描かれている。この2つの図は、異なる意味論的レベルのアクセスをどのようにしてXMLシンタックスを用いてシリアル化された(DDF)記述から得ることができるかを示す図である。DesOMとDOMは双方ともツリー・ベースの構造であるという点では類似している。しかし、DesOMは、DesOMが要素ノードに含まれるという点でDOMとは異なる。この要素ノードはDOM中の対応する要素ノードより豊富なインターフェースを備えている。さらに、DesOMの要素ノードは該要素と関連する処理を行う関連するDescriptorHandler(H)を有することができる。
2.2オブジェクト・モデル
2.2.1概要
好ましいDDF用として採用されるオブジェクト・モデルはコア・記述子・オブジェクトの定義に基づくものである。第1章.1.4に定義されているように、記述子は“特性表現値”を示す対と見なすことができる。表現値はアトミック・タイプ(例えば、整数、文字列、日付など)あるいは複合タイプのいずれかにすることができる。複合タイプとは1つまたはそれ以上の記述子のコレクションである。オブジェクト・モデルは図3のUMLクラス図によって表される。[記述子及び記述中の大文字の使用は第1章.1.4.で定義されている一般的用語の代わりに図3で定義されたオブジェクトであることを意味することに留意されたい]記述オブジェクトは記述子の特殊化として定義される。この記述子では、含まれるすべての記述子は単一リソースに属する。記述スキームには記述子と記述の定義が含まれ、この記述子と記述の定義とは、それぞれコア・記述子と記述オブジェクトの特殊化である。

0054

好ましいオブジェクト・モデルでは、記述子はそれらの親記述子の属性と関係を表すことができる。例えば、ある画像の隣接領域グラフエリア・記述子は(テキスト表現値を含む)ラベル・記述子及び(他のエリア・記述子への参照リストを有する表現値を含む)近傍記述子を含むこともできる。この例では、ラベル・記述子はある領域の属性を表すものと見なすことができ、また、近傍記述子はその領域を含む空間的関係を表すものと見なすことができる。(例えば空間的、時間的、概念的)関係を表す記述子は記述中の他の記述子に対して1つまたはそれ以上の参照を行う表現値を一般に持っている。第2章.4.1.4に、1セットの標準的記述子が空間的、時間的、概念的関係を表現するために提案されている。
2.2.2 記述子・クラス
各記述子は関連するID、言語コード及びデータ型列挙を備えている。ID属性は、各記述子に唯一識別番号を与えるものである。この識別番号を利用してある記述の他の記述子・オブジェクトを参照することができる。言語コード属性は、記述子の表現値の中で任意のテキストの言語を指定するものである。データ型列挙は、その表現値がアトミック(すなわち他の記述子から構成されるものではない;第2章.2.3参照)である場合、表現値のデータ型を与える。各記述子・オブジェクトは、記述子と関連する処理方法を与える記述子ハンドラと関連させることもできる(第2章.2.4参照)。

0055

好ましいDDFオブジェクト・モデルを実施することによって第1章.2に詳述する記述子関係を様々な程度まで実現することができる。このアプローチは、異なる実施が、採用された特定のシリアル化シンタックスの属性を利用することができることを意味する。第1章.5で詳述する記述子関係が、XMLシリアル化シンタックスを用いてどのように実現されるかについては第2章.4.1に詳述されている。
2.2.3アトミック・記述子値クラス
記述子の表現値はアトミックか複合(すなわち他の記述子・オブジェクトから構成される)かのいずれかにすることができる。表現値がアトミックの場合、その値はアトミック・記述子値オブジェクト中に文字列オブジェクトとして記憶される。このアトミック値のデータ型は親記述子・オブジェクトのデータ型属性を用いて解釈される。したがってデータ種別化が行われる範囲はこのデータ・モデルの特定的実現を表すデータ型属性に依存する。例えば、好ましいXMLシリアル化シンタックスを利用するデータ種別化の実施詳細については第2章.4.2を参照されたい。

0056

アトミック・記述子値は記述子・クラスのデータ属性によって表すこともできる。本明細書では、DOMにおけるこのエンティティのテキスト・ノードに対する1対1対応に起因してアトミック・記述子値は1つのクラスとして表される(DesOM中のアトミック・記述子値ノード;第4章.1.3参照)。
2.2.4 記述子ハンドラ・クラス
好ましいDDFでは、記述子ハンドラは、記述子に適用される処理方法を与えるクラスである。前記記述子ハンドラの方法は指定されたインターフェースを好適に満すものである。記述子ハンドラ・クラスは記述子の表現値(すなわちコンテンツ)の作成と、同じタイプの2つの記述子(すなわち同じ記述子定義、従って記述子ハンドラを用いる)間の類似性の計算方法を与えることができる。必要な場合処理のこのセットを拡張できない理由はない。図3はDDFの好ましい実現例で与えられる記述子ハンドラ方法のいくつかの例を詳細に示すものである。

0057

上記の方法は、指定されたインターフェースを満す静的な(クラス)方法として好適に実現される(例えば第4章.1.2参照)。記述子ハンドラの役割は記述子の生成と処理を行うための無曖昧処理を提供することである。記述子ハンドラ方法へパラメータを渡す能力については、シリアル化シンタックスとしてのXMLの利用に関する第3章.1.2.1で解説する。

0058

好適には記述子ハンドラ用のプログラム・インターフェースが固定されていることが望ましい。他の実施形態では、インターフェースを記述子・クラスの属性として指定することもできるし、あるいは記述スキーム用として指定することもできる。これらの代替実施形態によって、記述子ハンドラ・インターフェースを特定の記述スキーム用としてカスタマイズすることが可能になる。

0059

記述子ハンドラ法は記述子の表現値の符号化と復号化を行うために設けることもできる。シリアル化された記述を圧縮(すなわちサイズの減少)し、したがってさらに効率的に記述を記憶し移送するため、或いは記述子の表現値を暗号化するためのいずれかの目的のために符号化方法を設けることもできる。

0060

圧縮のために符号化を行う場合、符号化方法は符号化を行う対象データのタイプに依存して変ることもあり得る。例えば、テキスト表現値を持つ記述子はテキスト圧縮方法(例えばLZW)を使用することもできる。その一方で画像リソースのカラー・ヒストグラム構造を表した記述子はエントロピー符号化の形を用いてヒストグラムのビン(bin)周波数を符号化することもできる(すなわち、最も一般的に生じる周波数はより少ないビットしか必要としないコードワード(codeword)によって表される)。暗号化のための符号化を利用して、特権ユーザーのみが記述子にアクセスすることを可能にすることもできる。標準的暗号化(例えば公開鍵暗号方式)を使用することもできる。
2.2.5記述クラス
記述は記述子の属性に対するいくつかの追加属性を有する。記述は、記述されているコンテンツの項目のURIまたはエンティティのいずれかを含む関連するリソースを有する。記述には、そのリソースが最後に修正されたときの日付への参照、及び、数セットのその記述に適用することができるルールのURIまたはエンティティを含む属性も含まれる。ルール依存記述処理については第7章で更に解説する。

0061

記述オブジェクトが記述子・オブジェクトの特殊化として定義されるので、記述オブジェクトを他の記述の中で記述子・オブジェクトとして処理することができる(すなわち記述の属性は無視される)。代替データ・モデルでは、記述オブジェクトは記述子と記述オブジェクトの双方を含むことができる。このデータ・モデルに関して、その記述オブジェクトは記述子の別のツリー中に存在し、ルート記述のリソース以外のリソースの参照を含むことができる。

0062

別の代替的実施形態では、記述が複合表現タイプを有する記述子とほぼ同じなので、記述オブジェクトを含まなかったデータ・モデルを使用することもできる。この場合、記述の追加属性(すなわちリソース、最後に修正されたリソース日付(dateResourceLastModified)およびルールセット(ruleSets))は記述子の属性として処理されることになる。このデータ・モデルに関しては、リソースが重要な関係を有する記述子・ツリーのトップにリソースを指定する必要があるだけである。
2.3 記述処理用API
コア・記述子・オブジェクトの固有の包含属性はツリー・ベースの処理モデル(すなわち親−子データ・モデル)によって表される。その場合、ツリーの各ノードは、記述子かアトミック・記述子値オブジェクトのいずれかになる。[アトミック・記述子値オブジェクトはツリーの葉(外点)ノードとしてのみ存在することができる]DesOMにはツリー中のノード間の参照とナビゲーションリンクも含まれる。参照は、(例えば記述子・オブジェクト間の空間的、時間的及び/又は概念的)関係を示すために一般に使用される。ナビゲーションリンクは、記述のためのブラウジング属性を与えるために利用され、リソース中の記述と時空の範囲(例えば記述されているビデオ・ストリーム中の特定のフレーム)における記述子・オブジェクト間の連結を可能にする。記述処理モデルを描く概略図が図4に図示されている。

0063

好ましいDDFに従って記述を行うために、DesOMのルート(root)は記述オブジェクトでなければならない。言い換えれば、このルートは記述が参照しているリソースを指定するものでなければならない。記述オブジェクトは記述子・オブジェクトの特殊化にすぎないので、任意の記述オブジェクトは別の記述オブジェクトのサブツリーになることができる。換言すれば、新しい記述オブジェクトは1セットの関連する記述オブジェクトから作成することができる。この処理は図5に図示されている。

0064

DesOMは、記述子のための必要な一般化/特殊化関係、記述子のためのアトミック表現値のためのデータ種別化、DescriptorHandler(DH)及び参照とリンクとナビゲーションリンクを与えることによってDOMを拡張するものである。XML文書を表すための1セットの標準的オブジェクトと、これらのオブジェクトをどのように組み合わせることができるかを示す標準的モデルと、これらのオブジェクトにアクセスし、操作するための標準的なプラットフォーム上中立でかつ言語的に中立なインターフェースがDOMによって提供される。XML文書のDOM表現は、要素のコンテンツが要素の子ノードとして表されるツリー構造である。DOMは、XML文書を処理するために使用することができるインターフェースを指定する。換言すれば、DOMは、任意の(またはほとんどすべてに共通の)プログラミング言語で実行することができる。

0065

同様に、DesOMに対してはインターフェースのみが指定される。これらのインターフェースを使用してDDFに準拠するXML文書を処理することができる。ちょうどXML(DOM)プロセッサがDOMインターフェースを設けなければならないように、DDFプロセッサはDesOMインターフェースを設けなければならない(図2参照)。第2章.1で述べたように、DDFプロセッサはまず解釈ステップを実行する。このステップで、記述子の一般化/特殊化関係が検証され、バージョン1.0のXML-DTD形式で処理される。[XML-DTDのDDFとシンタックスを用いて記述スキームで表現された無効クラスの下位分類は記述スキームの構文解析エラーという結果になる]DDFプロセッサは、この記述の構文解析を行ってDOMに変換して、その構造をDesOMに変換するか、直接記述の構文解析を行ってDesOMに変換するかのいずれかを行うことができる。

0066

本質的にDesOMは、要素とテキスト・ノードとが記述子とアトミック・記述子値ノードとから成るさらに豊富なインターフェースによっ交換されるという点でDOMとは異なる。これらのノード用インターフェースについては第4章と第6章.3で解説する。基本的DesOMの実行によって単にそのインターフェースのみを与えることもできる。しかしさらに拡張的な実行によって、参照とナビゲーション関係についてのあるレベルの解釈を行うことができるかもしれない。例えば1セットの空間的、時間的、概念的関係をDDFに対して定義する(第3章.1.3参照)こともできるし、これらの関係をDesOMレベルで解釈することもできる。

0067

DesOMの実行によって、オプションとして記述子ハンドラ法を実行して記述子を作成したり、符号化したりあるいは処理することもできる。例えばDesOMの実行は、そのコンテンツが既に存在しない場合、記述子用としてコンテンツを作成する記述子ハンドラの方法を実行できるかもしれない。

0068

DesOMは更なる記述処理を行うための基礎を提供するものである。ルールがパターン及び関連するアクションとから成る場合、DesOMのツリー構造によってDesOMはルール依存処理を行い易くなる。このような処理は、DesOMインターフェースを実装してDDF記述を処理するツールによって行うこともできる。ルール依存処理については、セクション第7章から第11章で更に解説する。
2.4シリアル化シンタックス
記述と記述スキームとの記憶と移送とを行うために好適に利用されるシリアル化シンタックスはXMLバージョン1.0である。XML規格は、標準一般化マークアップ言語(Standard Generalised Markup Language)(SGML)のサブセットとして発展したものである。XML文書には1つまたはそれ以上の要素、開始タグ終了タグか空要素タグかのいずれかによって境界が定められる要素の境界が含まれる。各要素は、その“ジェネリック識別子”(GI)と呼ばれることもあるその名称によって識別され、1セットの属性仕様を有する場合もある。各属性仕様は名称と値を持っている。XMLバージョン1.0規格に関する更なる詳細については、W3Cウェブサイトhttp://www.w3.org/tr/1998/rec-XML-19980210を参照されたい。

0069

好ましいDDFでは、DDFコアDTDの中で定義することができる1セットのコア要素が使用される。SGML様DTDシンタックスを用いて、(XML規格バージョン1.0で指定されているように)要素タイプとそれら要素タイプの関連する属性とが定義される。各記述はXML文書によって表すことができる。この文書(すなわち記述)は記述が従っているDTD(すなわち記述スキーム)を参照する。換言すればこの記述はDTDによって指定されたタイプの記述である(図6参照)。

0070

DDFコアDTDはオブジェクト・モデルの表現に必要なコア要素の定義を与えることを必要とする。DDFに対して最重要の要素定義は記述子要素の定義である。すべての記述子はこのコア要素のサブクラス(特殊化)として定義される。例えば、記述は、単一リソースに属する記述子のコレクションであると定義されるものの、記述子要素のサブクラスとして記述を定義することもできる。記述子要素の他のサブクラスを用いて記述子と記述されているリソースと間の連結機能が与えられる(第3章.1.4参照)。

0071

DDFのデータ・モデル要件はXML仕様バージョン1.0によって設けられている要件より費用がかかる。特にDDFのシリアル化シンタックスは以下の事項を行うことができる。すなわち、
* 必要な記述子関係の表現(第2章参照)
* 記述子の(アトミック)表現値のためのデータ種別化
これらの要件については、シリアル化シンタックスとしてのXML規格のバージョン1.0の利用に関してセクション2.4.1と2.4.2の中で論じている。
2.4.1 記述子関係表現
2.4.1.1一般化/特殊化関係
XML仕様のバージョン1.0は一般化/特殊化関係の仕様を与えるものではない。さらに、マークアップ文書におけるクラスの下位分類と継承は十分に定義されていない。要素タイプが代替可能である場合、スーパークラス要素が発生しスーパークラスのサブクラスであると定義される場合はいつでも、要素タイプは別の要素タイプすなわちスーパークラスのサブクラス(特殊化)である。別の要素のサブクラスとして要素を定義することは本質的な問題ではない。スーパークラスはサブクラスの一般化と見なすことができる。継承という概念はコード節減メカニズムと見なすことができる。この節減メカニズムによって1つの要素タイプが別の要素タイプの属性を得る(継承する)ことが可能になる。

0072

単一クラスの下位分類/継承のための好ましいクラスの下位分類/継承のガイドラインについては以下の第2章.4.1.1.1〜第2章.4.1.1.3で解説する。複数の継承を単一クラスの下位分類/継承から拡張することができる。
2.4.1.1.1コンテンツ・モデル継承
サブクラスにはベース・クラスのインターフェースを忠実に設けるべきである。したがって、ベース・クラスが“任意(ANY)”のコンテンツ・モデルを持っている場合、サブクラスは“任意(ANY)”のコンテンツ・モデルか、もっと限定されたコンテンツ・モデルのいずれかを持つことができる。これはサブクラスを親クラスと代替可能にするために必要なことである。これは、サブクラスがそのスーパー(親)クラスが受け入れることができるどのような入力でも受け入れなければならないオブジェクト指向プログラミング(OOP)とは多少異なるシナリオである。要素のコンテンツ・モデルは“入力”ではなく“出力”と見なすべきである。各要素がそのコンテンツを検索する方法を持っているオブジェクトと考えられる場合、サブクラスはこれらの方法を満すことができなければならない。コンテンツ・モデル中の各要素タイプはある役割を持っているものと見なすことができる。サブクラスのコンテンツ・モデルの役割はその親クラスの役割に一致しなければならない。サブクラスは、その親クラスのコンテンツ・モデルの構成要素をより柔軟なものにしたり、拡張したりすることはできない。しかしその要素がその親クラスとして処理される場合には無視できる新しい子要素を設けることはできる。

0073

例えば、AA、BB、CCがそれぞれA、B、Cのサブクラスで、かつAが(B、C)のコンテンツ・モデルを持っている場合、以下はAA;(BB、CC)、(B、C)、(BB、C)、(B、CC)のすべての有効なコンテンツ・モデルである。コンテンツ・モデル(B、C、D)、(BB、CC、D)、(D、B、C)は、それらが(B)、(C)、(B、C)の“役割”に一致するという理由で、AAの有効なコンテンツ・モデルでもある。さらに要素AAは、要素AAが要素Aの1つのインスタンスとして処理される場合不可視となる子要素Dを含むことができる。コンテンツ・モデル(B)と(C)は、Aのコンテンツ・モデル中の(B、C)の“役割”が一致しないので無効である。

0074

サブクラスのためのコンテンツ・モデルを未指定のままにすることを許すことが可能となろう。その場合、サブクラスのコンテンツ・モデルがスーパークラスのモデルのデフォルトになる。好適には、未指定のコンテンツ・モデルはXML/SGML-DTDシンタックスを用いる有効な構成を表さないので、そのようなモデルを許さないようにすることが望ましい。
2.4.1.1.2属性継承
同じサブクラスと継承という概念は属性に対して適用される。しかし属性というものは、OOPにおける方法がそうであるようにある意味で“ランダム・アクセス”なものであるため、コンテンツという概念よりクラスの下位分類というコンセプトの方を本質的に受けやすい。サブクラスは、サブクラスがその親クラスとして処理されるとき本質的に無視される新しい属性を宣言することができる。しかし、サブクラスは、親クラスの属性を拡張したり、より柔軟なものにすることはできない。

0075

これらの属性デフォルトは属性定義がその親クラスの属性定義を拡張したものであるかないかを評価する際考慮されるにすぎない。その結果、サブクラスとその指定されたスーパークラスとは同じ属性タイプを持つことになり、属性デフォルトのみをさらにサブクラスで限定することが可能となる。属性デフォルト定義に対する有効な制限は表1に示す通りである。さらに、スーパークラスが“#FIXED”のデフォルト宣言を持っている場合、デフォルトの値は要素名と解釈することができ、次いで好適には、デフォルトの値を要素名のサブクラスに更に限定できることが望ましい。

0076

表1.サブクラス中の属性デフォルト宣言に対する許容される制限

0077

ID=000003HE=030 WI=096 LX=0570 LY=2000
2.4.1.1.3 実施細目
XML仕様のバージョン1.0とDOMとを用いてこのクラスの下位分類/継承モデルを実現するために、ある要素のスーパークラス(すなわちスーパーエレメント[superElement])が要素の定義された属性リスト中の属性として指定される。この指定は理想的なものではなく、また、クラスの下位分類情報は要素の定義の一部であると考えられている。例えばキーワード"TYPEOF"はクラスの下位分類情報(すなわち<!ELEMENTCat TYPEOF Animal>)を表す手段であること示唆する。

0078

superElement属性の使用によって示唆されるクラスの下位分類/継承は、クラスの下位分類/継承用に設けられたガイドラインに対して解釈し、検証する必要がある。これらのガイドラインに従わない場合記述スキーム構文解析エラーが結果として生じる。また、シリアル化されたDDF記述が有効なXML文書であるためには、この記述は有効なXML-DTDに従う必要がある。したがって、XML-DTDのシンタックスを用いて表現されたDDF記述スキームの構文解析を行って、クラスの下位分類関係の継承側面のすべてを処理するXML-DTDを作成する必要がある。これには以下の処理が含まれる。すなわち、
* クラスの下位分類に依存するコンテンツ・モデルを明白にすること(この処理には、クラスの下位分類意味論が非存在のとき、有効なXML-DTDコンテンツ・モデルを表すためにコンテンツ・モデルの拡張を含むこともできる)
*サブクラス化された記述子定義への継承された属性定義の追加
2.4.1.2同値関係
記述されたリソースの所在場所は、記述スキームに直接基づく要求を形式化する方法によって、あるいは、記述スキームのコンテンツが知られていないさらに構造化されていない問合せによって得ることができる。通常、前者のアプローチは、問合せが記述という形式に従って特に形式化されるのでより良好な結果が得られる。しかし、場合によっては、記述スキームについての(完全な)知識を持たずに(従って記述スキームで使用される用語とは異なる用語を使用して)、あるいは特定の記述が使用する以外の言語で問合せを形式化することができるかもしれない。第1章.2で強調されているように3つのタイプの同値が存在する。すなわち、
* 言語内同値(すなわち同意語や準同意語)
*言語間同値(すなわち翻訳)
*テキストと非テキスト表現値間の推論された同値要素に対する別名すなわちsameAs属性を用いて記述子の定義の中へ既知の言語内同値を組み入れることもできる。しかし、あるレベルの言語内同値解釈を行うアプリケーション用ツールが存在するので、この機能を設ける必要はないと考えられる。別個の検索/問合せ/フィルタエンジンによって最終的にあるレベルの言語内同値解釈を行うことができる。

0079

問合せは、記述と同じ言語で明確に述べられるとは必ずしもかぎらないので言語間同値のための手段を与えることが望ましい。記述スキーム中のある程度の冗長性については大に見ることができる(すなわち異なる言語の記述子を定義することもできる)とはいえ、複数の言語で記述を表現することは一般に容認されない。この方法は、記述スキームのために定義された1セットのルールを処理することによって、構文解析が行われた記述を問合せの言語に翻訳することができる。この1セットのルールによって、DesOM中の記述子は問合せと同じ言語の同値記述子と効率的に交換される。検索/問合せ/フィルタエンジン中の翻訳能力によってマッピング推定が可能にならずに、この方法によって異なる言語で記述子間の制御されたマッピングが行われる。

0080

非テキストとテキスト・記述子間の同値を同様の方法で出力することができる。例えば、画像中のオブジェクトのカラーが(R、G、B)値として記憶されている場合、あるルールによって、テキスト文字列(例えばred、green、blue、orangeなど)として表現された特定の色に特定の(R、G、B)値をマップするDesOM中に別の記述子をインスタンス生成することもできる。

0081

これらのルールは記述の一部として指定することができるルールセットとして記憶される。特別なまたは翻訳された記述子はシリアル化されず、必要な場合にのみ生成される。言い換えればそれらの記述子はDesOMの中に存在するだけで、記述を表すXML文書中には存在しない。ルールセットは、冗長な情報を記憶する費用を増加させることなく処理を行う記述の時点でより豊富な、より柔軟な記述を行う方法である。
2.4.1.3関連付け関係
関連付け関係は定義された記述子が発生し得る文脈を指定するものである。この文脈には、包含(例えば記述子Aは記述子Bの範囲内に生じなければならない)のような関係、シーケンス(例えば記述子A、B、Cは順序に従って生じなければならない)、基数性(cardinality)(例えば記述子Bは記述子Aの1つのインスタンスの中で1回だけ生じることができる)が含まれる。

0082

これらの関連付け関係の大部分は要素のコンテンツ・モデルを用いてXML-DTDで指定することができる。コンテンツ・モデルは、子要素の許されたタイプ(すなわち包含)と子要素の許された出現順序とを統御する単純な文法である。グループコネクタ[及び(コンマ)あるいは(垂直バー)]を用いて子要素が要素の範囲内で出現することができる順序が指定される。発生インジケータ[1つまたはそれ以上を示す(+)、ゼロまたはそれ以上を示す(*)、あるいはゼロまたは1を示す(?)]を用いて基数性(cardinality)すなわち要素のコンテンツ中での子要素の発生が指定される。要素コンテンツ・モデルについては第7章3.2.1に記載されている]XMLコンテンツ・モデル1.0は特定のノンゼロ(non-zero)基数性(cardinality)を定義する(例えばある画像の中に0〜20のオブジェクトを含み得る)ことを可能にするものではないので、この関連付け属性は好ましいDDFの実施の際に出力されるものではない。
2.4.1.4 空間的、時間的、概念的関係
多くの記述子は関連付け関係に加えて、空間的、時間的、概念的関係をしばしばモデル化することができることを必要とする。例えば、ある画像について記述する隣接領域グラフは1セットの領域を含むグラフ・オブジェクトを有する。オブジェクトグラフの一部であることに加えて、各領域はまた1セットの隣接領域(すなわち空間的関係)も有する。これらの関係は、その記述で関連する記述子への参照を用いて記述することができる。

0083

この方法では、これらの関係はIDREFまたはIDREFデータ型を備えたアトミック・記述子値を持っている記述子として表される。1セットのコア関係記述子がDDFコアDTDの中で定義され、DesOMの実行によってより広い範囲の意味論的解釈を実現することが可能になる。含まれる記述子定義のタイプの例は第3章.1.3で提供される。
2.4.1.5ナビゲーション関係
多くのアプリケーションでは、リソース中の空間的及び/又は時間的に局在化した範囲と記述子を明白にリンクさせることを可能にする必要がある場合がある。一般にリソースは記述されるものであるとはいえ、これは必ずしも実状ではない。リンクは、記述子からリソース中に示された所在場所(例えば記述子からデジタルビデオ・ストリーム中の空間的におよび時間的に局在化した範囲)へのナビゲーションを可能にする。

0084

これらのリンクを表現するための手段はこの問題への現行のアプローチ、すなわち所在場所参照要素すなわちロケータを用いるHyTime規格から得られる。この方法はこの記述中での外部エンティティとしてリソースを宣言しなければならないことを必要とする。次いでリンク要素が宣言され、宣言されたエンティティ中の記述と範囲において、記憶場所の間に文脈上の(単一リンク端を有する)及び独立の(1つまたはそれ以上のリンク端を有する)リンクが作成される。記述されているリソース中の範囲を参照する手段はロケータによって設けられる。

0085

DDFコアDTDで定義されるロケータと範囲要素はHyTime規格で指定されるものよりずっと単純である。これは後者の方が連結についてのDDF要件に要求される以上のものが与えられているからである。また、異なるメディアタイプに必要なすべてのロケータのあり得る異なる形に適用することは困難なので、記述スキームの設計者は必要なロケータの設計範囲を限定すべきではないということが考えられた。
2.4.2 特定のデータ型を示す表現
ある要素のコンテンツ・モデルによって指定できることとして、許された子要素の順序と基数性(cardinality)(第2章.4.1.3参照)、要素が空のコンテンツを有することすなわちコンテンツを持っていないこと、要素が構文解析された文字データ(すなわち#PCDATA)を有すること、あるいは、構文解析が行われた文字データと子要素(または“任意の”要素)との混合物を有することがある。[要素の許されたコンテンツ・モデルについてはXML1.0WC3勧告について述べる第3章.2.1で詳述する]ある要素のコンテンツを用いてある特性(例えば“作成日付(DateCreated)”)を示す表現値を記憶する場合、対応する記述子のコンテンツ・モデルは“#PCDATA”(すなわち“任意(ANY)”)であることを必要とし、そのコンテンツは文字列として表されることになる。これは、記述のテキスト解釈を行うために受け入れることができるものではあるが、この表現形式はより高度の問合せを可能にするものではない。なぜならそのような高度の問合せでは、例えば、“作成日付(DateCreated)”特性がある出力された日付より遅れた表現値を示している場合に記述の選択を行う必要がある場合もあるからである。言い換えれば、記述子の文字コンテンツ(すなわちアトミック・記述子値)の構文解析を行う必要がある。

0086

DDFのシリアル化シンタックスによって、要素を表すデータ型属性を利用することによるある要素のコンテンツのデータ種別化が行われる。バージョン1.0のXML(DOM)プロセッサについては明白ではないものの、DDFプロセッサはデータ型属性を利用して要素のコンテンツを適切に解釈することができる。要素コンテンツのデータ種別化はXML作業グループの検討事項の一部であると考えられてきた。従ってDDFはXML規格に今のまま準拠できることが望ましい。

0087

基本データ型(例えば整数、浮動小数点値、文字列、日付、時刻など)に加えて、データ型属性はID、IDREF、エンティティのようなタイプを許可し、アトミック・記述子値が、他の記述子への参照と、記述外のエンティティとのリンクとを表すことが可能になるようになっている。エンティティ・タイプによって、URIがエンティティ(例えばJPEG画像Javaクラスなど)のタイプとリンクすることが可能になるという点で、エンティティのXMLコンセプトはURIデータ型を使用することが好ましい。
2.5 実施上の問題点
実装されるDDFプロセッサは公に入手可能なソフトウェア(IBMのXMLパーサーなど)を利用し、記述の構文解析を行ってDOM構造に変え、次いでこの方法によってDOM構造はDesOM構造に変換される。Java言語を好適に使用してそのクロス・プラットフォーム属性に起因する記述子ハンドラ・クラスが設けられる。

0088

DDFプロセッサの現実の実装は中間ステップとしてDOMを作成する必要はなく、XML文書の構文解析を行って、記述スキームを用いて直接DDFDesOM構造に変換することもできる。そのようなプロセッサはまずDDF記述スキームでクラスの下位分類情報を解釈する必要がある(図2A参照)。

0089

DDFプロセッサの実行によって他のコア関係記述子の利点を利用して記述についてより豊富な意味論的解釈を与えることもできる(第2章.4.1.4参照)。上記解釈の実施によって、記述のグラフィック表現を行うとき、連結要素を解釈し、ルールエンジンを組み込んで、DesOMに適用できる可能性のあるルールを処理することもできる。
3.シリアル化シンタックス仕様
3.1.1要素定義
好ましいDDFにはXML/SGML-DTDシンタックスを用いる1セットのコア要素の定義が含まれる。このセットは、1つのコアDTDまたは1セットのコアDTDの中に好適に記憶される。付属書類AにはこのようなDTD(Core.ddf)の一例が含まれる。通常拡張子“dtd”を有するXML-DTDとこの文書を区別するために本明細書では拡張子“ddf”を使用することに留意されたい。DDFセットの定義はそのクラスの下位分類/継承属性(例えばスーパー要素からの属性継承)を持つことが必要となる。この下位分類/継承属性は1セットのDDF定義に関して記述が解釈される前に処理が行われる。アプリケーションDTDの定義または記述スキームの定義の基礎として1セットのコア要素を利用することができる。Core.ddf中の要素定義によって、記述スキームの基礎とすることができる1セットの“基礎(foundation)”要素が効率的に与えられる。

0090

提案されたDDFのコア要素定義に関するこの仕様はXML仕様のバージョン1.0に基づくものである。この提案されたCore.ddfに含まれる要素はJavaクラスに用いられる命名ルールに準拠して命名される(すなわち名前の中のすべての語は大文字で書かれ連接する)。
3.1.2コアDDF要素定義
3.1.2.1記述子定義
記述子要素とは第2章.2で詳述するデータ・モデル化属性を与える基本要素である。これらの属性中の任意の属性を必要とする任意の要素定義はこの要素のサブクラスとして表される。この要素は、マークアップ手法を用いるオブジェクト指向プログラミング言語のオブジェクト・クラスと同等のものである。

0091

記述子要素のコンテンツ・モデルは、文字データ(アトミック表現値)の構文解析を行うか、1つまたはそれ以上の記述子要素(複合表現値)の構文解析を行うかのいずれかを考慮する必要がある。記述子要素のコンテンツ・モデルは“任意(ANY)”であると定義され、必要なコンテンツが可能となり、有効なXML-DTDシンタックス構文となる。しかし、コンテンツ・モデルをより緊密に制御するために、記述子の2つのサブクラスすなわちアトミック・記述子と複合記述子とを定義することも可能である。その場合、これらのサブクラスのコンテンツ・モデルを#PCDATAと(記述子+)それぞれから成るさらに限定されたコンテンツ・モデルを持つようにすることもできる。

0092

基本複合記述子要素の特殊化を行う際に、1つまたはそれ以上の記述子または記述子要素のサブクラスとしてDDFインタプリタによって“記述子+”を解釈する必要がある。デフォルトでこのコンテンツ・モデルを利用する記述子要素の特殊化は、DDF解釈処理中“任意(ANY)”に拡張されたコンテンツ・モデルを持つようにし、記述スキーム用として有効なXML-DTDを形成するようにすることもできる(第2章.4.1.1.3参照)。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
<!ENTITY % DataTypes "(Int|Float|Double|String|Date|Time|ID|IDREF|
IDREFS|ENTITY|ENTITIES)">
<!ELEMENT Descriptor (ANY)>
<!ATTLIST Descriptor
id ID #IMPLIED
xml:lang CDATA "en"
dataType %DataTypes; "String"
superElement NMTOKEN #IMPLIED
handler ENTITY #IMPLIED

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
属性ID
この属性を示す値によって(例えば参照中の)特定の要素を参照する自然な方法が与えられる。この属性は文書用として唯一のものでなければならない。
属性XML:lang
属性 XML:langはXML仕様のバージョン1.0の中に含まれる。この属性は(要素の)コンテンツが書かれる自然言語あるいは形式言語を指定するものである。記述子要素によって使用されるデフォルトの言語は英語である。例えば記述スキームがフランス語で定義されていた場合、1つのアプローチはフランス語記述子を定義することであろう。その場合、xml:langの値は“fr”に固定され、次いでフランス語記述子要素からすべてのアプリケーション・記述子が得られる。
属性データ型
好適には多くの記述子の定義はある要素の文字データ・コンテンツのデータ型に対するある制御を必要とすることが望ましい。

0093

文字データ・コンテンツ用として許されるデータ型は(XML)内部パラメータエンティティデータ型(DataTypes)によって指定される(上記参照)。#PCDATAとこの記述子が含まれる文字データを表す出力されたコンテンツが記述子のコンテンツ・モデルに含まれる場合にだけデータ型属性が利用される。言い換えれば、記述子のコンテンツが子要素(すなわち複合表現値)を含むように指定された場合、データ型属性は使用されない。代替実現例では、許容可能なデータ型にはその定義で複合記述子の用途をより明白にする“複合”型が含まれる。

0094

記述子の文字データ・コンテンツは、DOMプロセッサによって使用されるようなテキスト・ノードの代わりに、アトミック・記述子値(AtomicDescriptorValue)ノード(インターフェース仕様について第4章.1.3参照)を用いてDDFプロセッサによって表される。

0095

属性データ型(dataType)のデフォルト値は“文字列(String)”である。このことは、要素のコンテンツを文字列として処理する場合、記述子要素の定義の中にデータ型属性を含む必要がないということを意味する。好適にはDDFプロセッサ日付と時刻とがISO8601のプロファイルに基づくことが望ましい。このタイプ、ENTITY/ENTITIES/ID/IDREFはXMLバージョン1規格として定義されているように構文解析を行うとよい。

0096

記述子要素の文字データ・コンテンツのデータ型をXMLバージョン1.0とDOMバージョン1.0仕様によって直接使用することはできないものの、記述へのテキスト・アクセスを何らかの方法で助けることはできるかもしれない。また、文字データ・コンテンツのデータ型をある属性の中に入れることは、XMLにおけるデータ種別化のための多くの現在の提案と一致してしている。

0097

記述子の中には可能な値のリスト(すなわち列挙)にその表現値を限定することを要求するものもある。これらの場合、列挙された値の各々について(空のコンテンツ・モデルを持っている)記述子要素を構成し、次いで親記述子のコンテンツ・モデルの中で列挙を指定することが望ましい。代替のアプローチには列挙データ型が含まれ、#PCDATAコンテンツ・モデルが使用される。
属性スーパー要素
この属性値は記述子要素の親(すなわちスーパー)要素である要素名である。親要素の定義が存在しなければならない。第2章.4.1.1に記述したようにクラスの下位分類が設けられる。

0098

この属性の中の情報はDDF解釈処理(図2参照)によって使用され、定義されたクラスの下位分類を検証し属性の継承が処理される。DOMレベルでアクセスされたとき、この属性によって、要素の即座の一般化に関する記述情報のみが出力される。DesOMレベルで処理されたとき、要素のクラスの下位分類関係がノード・リストまたは継承ツリーとして表される(第4章.1.1参照)。
属性ハンドラ
この属性値は、記述子要素に方法を与えるために利用される記述子ハンドラ用として外部エンティティを指定するものである。記述子ハンドラとは、指定された記述子ハンドラ・インターフェースに従う方法が含まれるクラスである(第4章.1.2参照)。

0099

記述子ハンドラは、記述スキームで定義することができるエンティティを用いて指定される(好適にはこのスキームの要素が定義される前であることが望ましい)。エンティティ宣言は、外部エンティティのタイプと、エンティティを処理するのに必要なヘルパー・アプリケーションとを宣言する表記法を使用することができる。以下の例では、表記法がJavaクラス・タイプで宣言され、このタイプは“Java”ヘルパー・アプリケーション(すなわちJavaバーチャルマシーン)とリンクされる。次いで、Javaクラス表記法を使用するエンティティ宣言を用いて個々のJavaクラスが宣言される。

0100

<!NOTATION JavaClass SYSTEM"Java">
<!ENTITY MyDescHandler SYSTEM "MyDescHandler.class" NDATA JavaClass>好適には、記述子ハンドラによって提供される方法は、DesOM(例えば記述要素からのリソース)から入手できないパラメータを必要とするものではないことが仮定されていることが望ましい。記述子ハンドラの方法によって、個々の記述からパラメータの設定が要求された場合、記述子要素の特殊化属性を使用してパラメータ値を保持するようにすることができる。記述子ハンドラは、DesOM中の属性値からパラメータを設定する方法を持つようにすることもできる。
3.1.2.2 記述定義
記述要素は記述子要素のサブクラスとして定義される。この記述要素はDesOMの1つのインスタンスのルート(root)ノードを表し、シリアル化された記述(すなわちXML文書)のルート(root)要素となる。

0101

この要素のコンテンツ・モデルは1つまたはそれ以上の記述子として定義される。これは記述子要素のコンテンツ・モデルに対する制限である。記述子要素の場合と同じように、この要素の特殊化の定義は1つまたはそれ以上の記述子または記述子・サブクラス要素としてDDFインタプリタによって解釈される必要がある。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
<!ELEMENTDescription (Descriptor+)>
<!ATTLIST Description
superElement NMTOKEN #FIXED "Descriptor"
resource ENTITY #REQUIRED
dateResourceLastModified CDATA #IMPLIED
ruleSets ENTITIES #IMPLIED

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
属性スーパー要素(superElement)
属性スーパー要素(superElement)は記述子要素の定義から継承されるものではあるが、記述要素は再定義され、記述子要素のサブクラスであると宣言される。る。記述要素のインスタンスによってスーパー要素値が再定義されることがないように、デフォルトのスーパー要素は#FIXEDとして宣言される。この記述要素の特殊化は、記述子要素のサブクラスである要素名を指定することによってこのデフォルト属性値を更に限定することができることに留意されたい(第2章.4.1.1.2参照)。
属性リソース
この属性を示すこの値にはこの記述によって記述されているリソースを参照するエンティティが含まれる。このリソースは、記述が宣言される前に記述中のエンティティとして宣言されなければならない。エンティティのタイプを記述する記述スキームかCore.ddfかのいずれかで定義された表記法を用いることによってリソース・タイプを得ることができる:
例:<!NOTATIONMPEG-2 SYSTEM"MPEG-2Player">
次いでこの表記法は記述のDOCTYPE宣言の中で外部エンティティ宣言によって使用することができる:
例:<!ENTITY MyVideo SYSTEM "MyVideo.mpg" NDATA MPEG-2>.
記述されているリソースを参照するこの方法はMPEG-2リソースとしてこのリソースを特定するだけでなく、リソース・タイプに対してプロセッサ名(ヘルパー・アプリケーション)を与えることでもあることに留意されたい。
属性リソース最終修正日付
この属性値はリソースが最後に修正された日付を示す文字列表現である。(文字列比較によって)この日付が変った場合任意の段階で処理をチェックし、必要な場合には記述を更新することができる。
属性ルールセット
この属性値には1つまたはそれ以上の外部エンティティが含まれる。各エンティティは、記述に適用可能な1セットのルールが含まれるXML文書を参照する(第7章参照)。
3.1.3 空間的、時間的、概念的関係を表す記述子
記述子間の空間的、時間的、概念的関係を与えるために1セットの記述子要素が含まれている。これらの要素は、記述の意味論的解釈を改良するために、個々のアプリケーション記述スキーム中で指定されるよりも好適にはコアDDF要素であることが望ましい。これらの関係記述子要素はアトミック表現値か複合表現値かのいずれかを持つようにすることができる。以下の要素セットは例によって含まれ、モデル化を必要とする関係を示すタイプの完全なリストをはっきりと示すことを企図するものではない。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
<!ELEMENT ParallelSequence (Descriptor+)>
<!ATTLIST ParallelSequence
superElement NMTOKEN #FIXED "Descriptor"

<!ELEMENT SerialSequence (Descriptor+)>
<!ATTLIST SerialSequence
superElement NMTOKEN #FIXED "Descriptor"

<!ELEMENT Neighbours (#PCDATA)>
<!ATTLIST Neighbours
superElement NMTOKEN #FIXED "Descriptor"
dataType %DataTypes; #FIXED "IDREFS"

<!ELEMENT Before (#PCDATA)>
<!ATTLIST Before
superElement NMTOKEN #FIXED "Descriptor"
dataType %DataTypes; #FIXED "IDREFS"

<!ELEMENT After (#PCDATA)>
<!ATTLIST After
superElement NMTOKEN #FIXED "Descriptor"
dataType %DataTypes; #FIXED "IDREFS"

<!ELEMENT InFrontOf (#PCDATA)>
<!ATTLIST InFrontOf
superElement NMTOKEN #FIXED "Descriptor"
dataType %DataTypes; #FIXED "IDREFS"

<!ELEMENT Behind (#PCDATA)>
<!ATTLIST Behind
superElement NMTOKEN #FIXED "Descriptor"
dataType %DataTypes; #FIXED "IDREFS"

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
3.1.4ナビゲーション関係を表す要素
好ましいDDFには、記述されているコンテンツの時空の範囲との記述の連結を可能にするコア要素もまた含まれる。時空の範囲は、空間的に及び/又は時間的に局在化しているコンテンツのセクションであると定義される。例えば、デジタルビデオ信号の時空の範囲はいくつかのフレームにわたって拡がる矩形領域と表すことができよう。文脈上のリンク(Clink)は共通相互参照すなわちナビゲーションリンクを表すものと定義される。Clinkは、リンクが生じる記述中の記憶場所を別の記憶場所と接続する。換言すれば、Clinkは単一のリンクされた属性を持っている。独立リンク(Ilink)は、3つ以上のロケーションを接続するか、あるいは記述中のリンクの記憶場所から別個に格納されたリンクを必要とするアプリケーション用として定義される。これらの要素は基本記述子要素のサブクラスとして定義され、DDFによって解釈され、DesOM中のノードとして表されるようになっている。これらの要素は第2章.2の中で記述されたデータ・モデル化属性のいずれをも必要としないので、以下に定義されるセットのような要素が記述子要素に基づかずに、DDFプロセッサによって依然として解釈されることが許される場合があるかもしれない。

0102

これらの連結要素の定義はCore.ddfの中に含まれる。別個の(ddf)DTDの中にコア時空の連結要素の定義を含むことが望ましい場合もあることに留意されたい。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
<!ELEMENTCLink (#PCDATA)>
<!ATTLIST CLink
superElement NMTOKEN #FIXED "Descriptor"
dataType %DataTypes; #FIXED "IDREF"

<!ELEMENTILink (#PCDATA)>
<!ATTLIST Ilink
superElement NMTOKEN #FIXED "Descriptor"
dataType %DataTypes; #FIXED "IDREFS"

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
コアロケータ要素は、特定のリソースの範囲内で1つまたはそれ以上の範囲要素の記憶場所のアドレスを単に提供するものにすぎない。リソース属性の値によって、記述の中で以前に宣言されたエンティティを用いるリソースが特定される。この特定によって、Core.ddfが十分に豊富な1セットの表記法も含むことが要求される。この表記法は、エンティティ(例えばJPEG、TIFF、MPEG-1、MPEG-2など)によって参照されることになるリソースのタイプを含むものである。ロケータの1つのインスタンスは、ある範囲の1つまたはそれ以上のインスタンスを含まなければならない。たとえリソースが記述用として指定された同じリソースであるとしてもリソースを指定することが望ましい。

0103

範囲要素のいくつかのサブクラスはCore.ddfで定義される。これらの要素の定義には以下のものが含まれる。これらの要素定義は必要なものになり得るロケータ要素と範囲要素のタイプの一例を与える。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
<!ELEMENTLocator (Extent+)>
<!ATTLIST Locator
superElement NMTOKEN #FIXED "Descriptor
resource ENTITY #REQUIRED

<!ELEMENT Extent (Descriptor+)>
<!ATTLIST Extent
superElement NMTOKEN #FIXED "Descriptor"

<!ELEMENT ImageExtent (Descriptor+)>
<!ATTLIST ImageExtent
superElement NMTOKEN #FIXED "Extent"

<!ELEMENT RectImageExtent (RectImageExtentX0, RectImageExtentY0,
RectImageExtentHeight, RectImageExtentWidth)>
<!ATTLIST RectImageExtent
superElement NMTOKEN #FIXED "ImageExtent"

<!ELEMENT RectImageExtentX0 (#PCDATA)>
<!ATTLIST RectImageExtentX0
superElement NMTOKEN #FIXED "Descriptor"
dataType %DataTypes; #FIXED "Int"

<!ELEMENT RectImageExtentY0 (#PCDATA)>
<!ATTLIST RectImageExtentY0
superElement NMTOKEN #FIXED "Descriptor"
dataType %DataTypes; #FIXED "Int"

<!ELEMENT RectImageExtentHeight (#PCDATA)>
<!ATTLIST RectImageExtentHeight
superElement NMTOKEN #FIXED "Descriptor"
dataType %DataTypes; #FIXED "Int"

<!ELEMENT RectImageExtentWidth (#PCDATA)>
<!ATTLIST RectImageExtentWidth
superElement NMTOKEN #FIXED "Descriptor"
dataType %DataTypes; #FIXED "Int"

<!ELEMENT VideoExtent (VideoExtentStart, VideoExtentEnd, ImageExtent?)
> <!ATTLIST VideoExtent
superElement NMTOKEN #FIXED "Extent"

<!ELEMENT VideoExtentStart (#PCDATA)>
<!ATTLIST VideoExtentStart
superElement NMTOKEN #FIXED "Descriptor"
dataType %DataTypes; #FIXED "Int"

<!ELEMENT VideoExtentEnd (#PCDATA)>
<!ATTLIST VideoExtentEnd
superElement NMTOKEN #FIXED "Descriptor"
dataType %DataTypes; #FIXED "Int"

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
4. DesOMAPI仕様
DesOMインターフェースは現行のDOMオブジェクト・モデル(DOM)インターフェース仕様を拡張するものである。DOMは、プラットフォーム上中立で且つ言語的に中立なインターフェースであり、このインターフェースによってプログラムとスクリプトが動的にアクセスし、XMLとHTML文書のコンテンツ、構造とスタイルを更新することが可能になる。HTMLとXML文書、これらのオブジェクトをどのように組み合わせることができるかを示す標準的モデル、及び、これらのオブジェクトにアクセスし操作するための標準的インターフェースを表すための標準的1セットのオブジェクトがDOMによって提供される。ベンダーは、それらの専有データ構造とAPIとつながるインターフェースとしてDOMをサポートすることができる。そしてコンテンツ著作者は、製品特有のAPI、したがってウェブ上のインターオペラビリティを増加させる代わりに標準的DOMインターフェースに対して書き込むことが可能になる。

0104

DOMインターフェースはその関連する方法をどのように実現すべきかを規定するものではない。例えば、getElementsByTagName()(付属書類K)法はDOMインターフェースを満さなければならないが、開発者がそのように選択するような任意の方法で実行することができる。DesOMとDOMインターフェースと関連する方法の実現は、本発明にとって必須なものではないのでこれについてはこれ以上解説しない。

0105

DOMレベル1仕様は現在公に入手可能である。このレベルはW3Cのメンバー及びその他の関係当事者によって吟味され、W3C勧告としてDirectorによって是認されている。DOMバージョン1.0規格に関する更なる詳細については、W3Cウェブ・サイトhttp://www.w3.org/tr/1998/rec-DOM-level-1-199810001を参照することができる。

0106

上述のように、DesOMはDOMに対する拡張を必要とする。これらの拡張は追加インターフェース仕様の形を成すものである。これらの仕様について、オブジェクト管理グループ(OMG)インターフェース定義言語(IDL)を用いてこの章で詳述する。指定されたインターフェースはDesOM用の最低限のインターフェースを表す。
4.1.1 インターフェース・記述子
DesOM中の記述子・ノード・オブジェクトはDOM要素ノード・オブジェクトのサブクラスである(付属書類K参照)。要素ノード・オブジェクトのように、記述子・ノード・オブジェクトは記述子要素並びに中に含まれる任意の要素の双方を表す。
IDL定義
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
interface Descriptor : Element {
void setHandler(in DescriptorHandler handler);
DescriptorHandler getHandler();
NodeIterator getSuperElements();
};
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
setHandler()法
この記述子・ノード・オブジェクト用DescriptorHandlerをセットこのハンドラは、記述子要素のハンドラ属性値として指定されるハンドラ・エンティティに基づいてインスタンス生成することができる。

0107

パラメータ
ハンドラこの記述子・ノードに割り当てられたDescriptorHandler
返し値 無効
例外この方法には例外はない。
getHandler()法
返し値 この記述子・ノード・オブジェクトのためのDescriptorHandler
パラメータ none
返し値 記述子・ノード・オブジェクト用DescriptorHandler
例外 この方法には例外はない。
getSuperElements()法
記述子一般化のリストまたは記述子・ノード・オブジェクトためのスーパー要素を返す
パラメータ なし
返し値 ノード繰返し子
例外 この方法には例外はない。
4.1.2インターフェースDescriptorHandler
DescriptorHandlerオブジェクトは記述子・ノードのクラスのための方法を与えるDescriptorHandlerは記述子の2つ以上のタイプのための方法を与えることができる。例えば、記述子のコレクションは同じ類似性メトリックを利用することができる場合もある。

0108

好適にはDescriptorHandler用インターフェースが固定されていることが望ましい。他の実施形態では、このインターフェースを記述子用か記述スキーム用かのいずれかに指定することができる。

0109

DescriptorHandlerの方法は一般にクラス(静的な)方法として実現される。
IDL定義
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
interface DescriptorHandler {
boolean canCreateDescriptorContent();
void createDescriptorContent(Descriptor descriptor, Entit
y resource);
void removeDescriptorContent(Descriptor descriptor);
double getSimilarity(Descriptor descriptor1, Descriptor
descriptor2);
};
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
canCreateDescriptorContent()法
DescriptorHandlerが記述子用コンテンツを作成することができる実行方法を含む場合真を返す。

0110

返し値 ある方法が実行された場合は真、されなかった場合はを返す
createDescriptorContent()法
指定されたリソース用いて指定された記述子・ノード・オブジェクトのコンテンツ(すなわち子ノード)を生成する。

0111

パラメータ
記述子コンテンツ(すなわち子ノード)をリソースから作成する対象となる記述子・ノード・オブジェクト
リソースエンティティとして表される、コンテンツを得る源であるリソース
返し値 無効
例外リソースを得ることができなかった場合この方法によって、ResourceNotFoundExceptionが生み出されるか、リソースがこの方法と互換性がない場合IllegalResourceExceptionが生み出される。
removeDescriptorContent()法
指定された記述子・ノードのコンテンツ(すなわち子ノード)を除去するこの方法は、記憶のための記述の複雑さを少なくするために呼び出すこともできる。また、DescriptorHandlerが指定された記述子のコンテンツを再作成することが可能な場合に呼び出すことができる。

0112

パラメータ
記述子コンテンツ(すなわち子ノード)を除去べき対象となる記述子・ノード・オブジェクト
返し値 無効
getSimilarity()法
2つの指定された記述子・ノード・オブジェクト間の類似性を示す測定値を与える[0、1.0]の範囲で類似性メトリックを返す
パラメータ
記述子1 比較の対象とする2つの記述子・ノード・オブジェクトのうちの第1のオブジェクト
記述子2 比較の対象とする2つの記述子・ノード・オブジェクトのうちの第2のオブジェクト
返し値倍精度
例外2つの記述子・ノード・オブジェクトが両立不可能なタイプのものである場合この方法は不一致記述子例外(UnmatchedDescriptorException)を生成する。
4.1.3 AtomicDescriptorValueインターフェース
AtomicDescriptorNodeオブジェクトはDOMの一部として指定されるテキスト(ノード)オブジェクトのサブクラスである[テキスト・オブジェクトにはある要素の非マークアップコンテンツが含まれる]。このAtomicDescriptorNodeは、テキスト・オブジェクトへの追加的方法を与えるものであり、この方法によってテキスト・オブジェクトの文字列データ・コンテンツがその他のデータ型として解釈される(すなわちAtomicDescriptorNodeは本質的に種別化されたテキスト・ノードである)。利用可能なデータ型は記述子要素のデータ型属性について指定されたものである(第3章.1.2.1参照)。XMLデータ型(すなわちID、IDREF、エンティティ、エンティティズ)はアトミック・記述子値ノードの文字列値から解釈されるものと本明細書では仮定する。

0113

ISO8601のプロファイルによって指定された日付及び時刻フォーマットを用いて日付と時刻が表される。アトミック・記述子値オブジェクトの実施は特別な日付関数(例えばgetDataAsDateYear()、getDataAsDateMonth()など)を出力する更なる方法を与えることができる。
IDL定義
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
interface AtomicDescriptorValue : Text {
int getDataAsInt();
float getDataAsFloat();
double getDataAsDouble();
Date getDataAsDate();
Time getDataAsTime();
};
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
getDataAsInt()法
整数としてテキスト・ノードの値を返す
パラメータなし
返し値 整数
例外この方法は、整数として文字列の構文解析を行うことができなかった場合にDDFdataFormatExceptionを生成する。
getDataAsFloat()法
浮動小数点値としてテキスト・ノードの値を返す。

0114

パラメータなし
返し値浮動小数点
例外この方法は、浮動小数点値として文字列の構文解析を行うことができなかった場合DDFDataFormatExceptionを生成する。
getDataAsDouble()法
倍精度数値としてテキスト・ノードの値を返す。

0115

パラメータなし
返し値倍精度数
例外この方法は、文字列の構文解析を行うことができなかった場合倍精度数値としてDDFDataFormatExceptionを生成する。
getDataAsDate()法
ISO8601日付としてテキスト・ノードの値を返す。

0116

パラメータなし
返し値 ISO8601日付
例外この方法は、文字列の構文解析を行うことができなかった場合ISO8601日付としてDDFDataFormatExceptionを生成する。
Method getDataAsTime()法
ISO8601時刻としてテキスト・ノードの値を返す。

0117

パラメータなし
返し値 ISO8601時刻
例外この方法は、ISO8601時刻として文字列の構文解析を行うことができなかった場合DDFDataFormatExceptionを生成する。
5.記述スキームの例
DDFに表現された記述スキームの一例が付属書類Bに含まれている。記述スキームはオーストラリア・フットボール・リーグ(AFL)試合のデジタルビデオのクリップを表す記述の出力を目的とするものである。この記述スキームでは付属書類Aに含まれるいくつかのコア要素定義が利用される。Core.ddfは内部パラメータ・エンティティB1として宣言され、次いで、%演算子を用いて記述スキーム中に包含される(B2参照)。記述スキームの示されたラインB1とB2は、結果として付属書類Aに含まれるすべての要素定義がサンプル記述スキームに利用可能であることを示す。

0118

記述子AFLGameDescription-B3の定義で記述子ハンドラB4が指定される。この例では、記述子ハンドラはJavaクラス(付属書類Bに含まれる例の中のAFLGameGen.クラス)として実現される。このJavaクラスは、記述されているゲームのクリップを含むデジタルビデオ信号を分析することによってAFLGameDescription記述子の(記述)コンテンツを自動的に生成する所定の処理方法を持っている。

0119

ここで注意すべきことは、AFLGameDescription要素は記述要素の特殊化として定義されるとはいえ、記述要素は記述子要素の特殊化にすぎないので、記述子としてもAFLGameDescriptionを処理することができるという点である。

0120

付属書類B中の記述スキームから生成されたサンプル記述が付属書類Cに示されている。このサンプル記述は、AFLGameDescription記述子用として通常記述子によって最初に生成される。しかし注釈者がそのように望むのであれば手による作成も可能である。記述子AFLGameDescriptionのためのコンテンツを生成するための処理方法は、一般に、記述の対象となる試合のクリップを含むデジタルビデオ・リソース信号を分析し、競技の4つのクォーターの開始と終了を特定し、可能であれば各クォータートラックの範囲内で個々の追跡対象選手を特定するものである。選手のジャージーから得られる選手番号の認識を試みることによって選手識別を行い、デジタルビデオ・リソースのモーション分析を利用して上記追跡を行うことができる。記述のコンテンツの生成方法を指定することは本発明の目的ではない。

0121

明らかに、記述スキームによって指定されるような、デジタルビデオ・リソース信号の分析から記述に必要なすべての情報を自動的に生成することはできそうではない。情報(例えば日付と試合の場所)が入手可能でない場合、コンテンツ生成方法は空の記述子を生成するか、単に記述から記述子を省くかのいずれかを行うことができる。後日、注釈者は必要であればこの情報を手入力によって追加することができる。同様に、自動分析によって各々の追跡対象の選手のアクションを類別することはとても困難であるかもしれない。例えば、選手が試合中のマークキックタックルに巻き込まれているかどうかの自動分析を行うことは難しい。この情報も後日設けることができる。実際、注釈者は第1章3に記載されているようにデジタルビデオ・ブラウザ・システムを利用してデジタルビデオ・リソースをブラウズし必要なものとして注釈をつけることもできる。注釈の完了時にデジタルビデオ・ブラウザ・システムを利用して、特定の選手が含まれているデジタル・ビデオ・リソースのすべてのセクションや試合中のマークが行われたすべてのセクションを選択し再生することもできる。換言すれば、デジタルビデオ・ブラウザ・システムを利用して任意の注釈タスクを完成し記述されたデジタルビデオ・リソースをブラウズすることもできる。

0122

記述子のコンテンツの作成方法を示す別の例として、別の記述スキームを用いて記述対象のリソースが既に記述されている例がある。例えば、デジタルビデオカメラは、(ビデオキャプチャ記述スキームなどを用いて)デジタルビデオ・リソースが取り込んでいるときそのリソースの記述を生成することもできる。この自動生成された記述には露光焦点注視場所、ショット境界などのような情報が含まれる。全ての情報ではなくてもソース記述スキームを用いて自動的に記録された情報の一部が保持されることが望ましい。しかし別のもっと一般的に受け入れられる記述スキーム、この場合宛先記述スキームを用いてデジタルビデオ・リソースについて記述することが望ましい。この場合宛先記述スキーム中の記述子ハンドラは、ソースから宛先記述への記述子のマッピングを行うこともできる。このマッピングは、宛先記述スキームの記述要素用の記述子ハンドラのコンテンツ作成方法で通常行われる。1つの記述スキームから別の記述スキームへのこの変換はDesOMに対してルールを適用することによって行うこともできる(第7章参照)。
6. 処理の適用方法
6.1電子的にアクセス可能なリソースの記述生成方法
図7Aを見ると、電子的にアクセス可能なリソースの記述を生成する方法が示されている。この方法はステップ700Aから始まり、プロセッサ(すなわち記述生成装置)によって記述スキームが読み込まれるステップ702Aに続く。次のステップ704Aで、記述スキーム中の1つまたはそれ以上のDescriptorHandlerがプロセッサによって特定され、その後この方法はステップ706Aへと続く。ステップ706Aで、プロセッサは以前に特定したDescriptorHandlerに対応する処理を特定する。これらの処理は、DescriptorHandlerの中に含まれる処理用コードの形を成している。次のステップ708Aでこれらの処理はリソースに適用される。この処理によってリソースの属性(すなわち特性)と関連する表現値が生成される。次いで、この方法によって、ステップ710Aで処理のアプリケーションの結果が出力される。この方法はステップ712Aで終了する。好適にはこれらの処理によって、その後XML文書としてシリアル化することもできるDesOMの形での、リソースに関する記述の自動生成という結果が得られることが望ましい。しかし他の処理または処理を適用することもできる。更にこの結果得られる記述は人間と機械の双方によって好適に解釈可能であることが望ましい。
6.2 記述に対する処理の適用方法
図7Bを見ると、リソースの記述に処理を適用する方法を示す流れ図が示されている。この方法はステップ700Bから始まり、DDFプロセッサによって記述の構文解析を行うステップ702Bに続く。次のステップ704BでDDFプロセッサは関連する記述スキーム内に1つまたはそれ以上のDescriptorHandlerを特定する。この方法の次のステップ706Bで前に特定されたDescriptorHandlerと関連する1つまたはそれ以上の処理がDFFプロセッサによって特定される。これらの処理はDescriptorHandler中に含まれる処理用コードの形を成している。次のステップ708Bで、処理は記述に対応するDesOMに適用される。次いでこの方法によって処理のアプリケーションの結果がステップ710Bで出力される。方法はステップ712Bで終了する。この方法は、この方法の中で使用可能な多くの異なるタイプの処理に適用できる。1つの実施形態では、この方法によって同じタイプの2つの記述子間の類似性が計算される。この実施形態では、DDFプロセッサによって記述の構文解析が行われ、共通の記述子定義がプロセッサによって特定される。次いで、共通記述子定義を含む記述スキームの範囲内に関連するDescriptorHandlerがDDFプロセッサよって特定される。この記述子ハンドラには2つの記述子間の類似性を計算するための処理用コードが含まれる。次いでこの方法によってこの記述と関連するDesOMに対して処理用コードが適用され、記述子の類似性、従って2つのリソースの類似性が決定される。次いでこの方法によって類似性計算の結果が出力される。この実施形態には検索用/問合せ用リソースを記述した特定のアプリケーションがある。別の実施形態では、この方法の処理用コードはリソースの記述の1つまたはそれ以上の記述子要素を符号化及び/又は復号化することができる。この実施形態には、リソースの記述の記述子要素の効率的な及び/又は安全な移送または記憶を行うための特定のアプリケーションがある。
6.3 記述生成及び記述への処理の適用方法の例
記述を生成し処理基準を適用する方法によって、記述子と記述スキームを定義する方法は標準化されている。これらの記述子と記述スキームを用いて種々のタイプのマルチメディア情報について記述することができる。この記述子と記述スキームを用いて、高速で効率的な検索を可能にする記述を作成しマルチメディアコンテンツと関連させることができる。この推奨実施形態によって記述子の自動抽出が行われる。しかし、一般に、この抽出は低レベル特性についてのみ可能である。より高レベルの要約を表す特性は通常手入力であるいは少なくとも半自動的に設定しなければならない。

0123

またこの方法によって、記述子を生成する処理用コードと関連する記述子のための標準的メカニズムが与えられる。これによって記述スキームの展開を容易にすることができる。例えばこのような関連付けによってマルチメディアデータベースサーバーのような非常に汎用的アプリケーションの発達が可能になる。このような汎用的アプリケーションは処理用コードを利用して新しい記述のための記述子あるいは記述を比較するための記述子が生成される。記述子を生成するための処理とは別に、記述子を検証するための、同じタイプの2つの記述子間の類似性を計算するための、並びに、記述子の符号化と復号化を行うための処理を、標準的インターフェースを介してアプリケーションを利用することができる。

0124

例えば上記のような処理用コードを利用して以下の例示的アプリケーションが可能である。
* あるメロディ口笛で吹いてを見つけること
*キーボード数個音符演奏してお返しに音楽作品のリストを得ること
*スクリーン上に数本の線を引いて、類似したグラフィック、ロゴ表意文字が含まれる1セットの画像をお返しに得ること
*カラー・パッチテキスチャを含めて、オブジェクトを定義してお返しにサンプルを得ること
* パバロッチ(Pavarotti)の声の抜粋を使ってパバロッチのレコードのリストを得ること
上記シナリオには、ユーザーがユーザーの問合せを持つ何らかのコンテンツ・サンプルを与えることが含まれる。(DSSの露光のための言語に加えて)記述スキームの標準化によって複数の遠隔マルチメディア・データベースにわたる問合せが容易になるであろう。

0125

記述子と記述スキームの標準化に関連するいくつかの問題がある。例えば、比較的単純なカラー・ヒストグラム・記述子に関する問題がある。たとえ2つの記述プロバイダが同じカラー・ヒストグラム・記述子を用いていたとしても、異なる量子化を用いるような異なる方法でカラー・ヒストグラム・記述子が使用されているかもしれない。このことは、異なる記述プロバイダにとってはヒストグラム・ビンiが異なるものを意味する可能性があるということを意味する。一例として複数の画像データベースを検索するために、画像のヒストグラムを使用するとき異なるヒストグラム間で比較及び/又は変換のいずれかを行わなければならない。これらの選択肢の双方とも達成が難しくエラーが生じる傾向がある。また、ヒストグラム・サンプルが生成されたのと同じ方法ですべてのデータベース・サーバーにその画像のヒストグラムを再計算させることは実際的でない。

0126

本発明の発明家たちは記述スキームの標準化を行うための2つの可能なアプローチを提案する。
1.カラー空間、カラー・ヒストグラムのためのカラー量子化(bins)、従ってビン間の(cross-bin)類似性マトリックスを最後の細部まで完全に標準化する。
2.サンプルとして画像自体を利用する。この場合、各データベースは、受信された問合せ画像のヒストグラムを計算するためにそれ自身の抽出方法を利用し、次いでこのヒストグラムをそのデータベースの残りと比較する。

0127

第1の選択は、ヒストグラムの仕様のすべての細部について同意が得られることは決してないのであまり実際的ではない。選択2は、ヒストグラム及びその他の画像問合せの大部分についてより実際的でより単純である。選択2は、各データベースが記述子についての各データベース自身の特有のパラメータを利用することができ、また、記述間の類似性を計算する各データベース自身の方法も利用できることを意味する。

0128

コンテンツから生成することができる低レベルの記述子−カラー・ヒストグラム−のみがこれらのアプローチでは一例として考慮された。実際に、問合せにはユーザーが入力するテキスト記述またはキーワードを含むことができる。このテキスト記述またはキーワードを写真家の氏名、画像の見出しなどのようないくつかの高レベルの記述子にマップすることができる
前に解説したように、すべての記述子と記述の基礎となるベース・記述子・クラスが定義され、記述は複合記述子として処理される。このベース・記述子・クラスには記憶対象の記述子の処理を実施するハンドラのURIを可能にする属性が含まれる。このベース・記述子・クラスによって記述子を処理用コードと関連させるための標準的メカニズムが設けられる。このハンドラは記述子ハンドラと呼ばれる。記述子ハンドラのための標準的API(アプリケーション・プログラム・インターフェース)はDescriptorHandlerクラスに基づく。DescriptorHandlerは、記述子のコンテンツ(すなわち値)を生成する(createDescriptorContent())方法と、同じタイプの2つの記述子間の類似性を計算する(getSimilarity())方法とを与える(第4章参照)。

0129

DesOMインターフェースの代替実施形態について以下解説する。DescriptorHandlerクラスのDesOMインターフェースの詳細な定義はコード定義Aの中で得ることができる。要するに、DescriptorHandlerクラスのDesOMインターフェースは以下の方法を指定するものである。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
指定された方法と関連するパラメータのリストを得るためのParameterList ge
tParameterList(文字列methodName中の)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
パラメータ値を得るためのString getParameter(文字列parameterName中の)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
パラメータ値を設定するための無効setParameter(文字列parameterName中の、
文字列parameterValue中の)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
リソースの記述子を作成するためのcreateDescriptorContent記述子(URIリソ
ス)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
同じタイプの2つの記述子間の類似性を計算するための倍精度数getSimiliari
ty(記述子descriptor1Object中の、記述子descriptor2Object中の)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
記述子のコンテンツを検証するためのブール検証(descriptorObjectの中で)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
伝送やアーカイブ用として記述子を符号化するためのByteArray符号化(記述子
descriptorObject中で)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
符号化された記述子を復号化するための記述子復号化(ByteArray encodedStri
ngの中で)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
さらに、記述子・クラスによって以下の方法が与えられる:
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
XMLフォーマットされた文字列を構文解析して記述子・オブジェクトの中に入
れるためのparseDescriptorString記述子(文字列XMLString中で)(この場合、構
解析は形式が整っているかどうか(well-formedness)をチェックするだけであ
ることに留意されたい)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
その開始タグおよび終了タグを含む記述子のXMLシリアル化を返すための文字
列 getXML()
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
性能、機能および複雑さの間で様々なトレードオフ(trade-off)を行って、任意の記述子用として異なる記述子ハンドラを(通常異なる開発者によって)設けることができる。しかし、記述子のすべての記述子ハンドラは記述子の定義に従わなければならない。すなわち記述子ハンドラは記述子の定義に従う記述子値を生成することができるにすぎない。同時に、記述子ハンドラは任意の入力記述子が記述子の定義に従っていると仮定することができる。

0130

記述子設計者はデフォルト・記述子ハンドラを記述子に割り当てることもできる。しかし、記述子のユーザーは自由に別のハンドラを選ぶことができるし、全くハンドラを選ばないこともできる。

0131

必ずしもすべての記述子が記述子ハンドラを持つ必要はない。実際、より高レベルの抽象を示す多くの記述子はハンドラを持っていないことが予期される。それにもかかわらず、低レベルの記述子でさえハンドラを持っていない場合がある。例えば、ハンドラがヒストグラム・記述子用として存在する場合がある一方、文書の作成日付を保持する記述子用ハンドラが必要になることを我々は予期していない。

0132

たとえ記述子が記述子ハンドラを持っていても記述がハンドラを使用したり参照する必要はない。さらに、同じ記述子・クラスの異なるインスタンスは異なる記述子ハンドラを参照することもできる。例えば、画像の異なるクラスの異なる特性に起因して、画像の各クラスについてより効率的なセグメンテーション・アルゴリズムを持つ異なるハンドラが使用されそのエリア・記述子が作成される。さらに、アプリケーションは限定されるものではなく、また、記述子のインスタンスが参照する記述子ハンドラを使用する必要もない。

0133

同時に、必ずしもすべての記述子ハンドラ(DescriptorHandlerクラスのサブクラスである)がベース記述ハンドラ・クラスのすべての方法のデフォルトの実行を無視するというわけではない。すなわちベース・クラスのすべての方法をサポートするというわけではない。例えば、検証方法を設けてISBNが正しいフォーマットを有することをチェックすることもできる。しかし、ISBNを生成する方法を設けることはできない。別のサンプルとして、記述子ハンドラが非電子的にアクセス可能なリソース用としてある一定の記述子を示すgetSimilarity()法をサポートすることができながら、この記述子ハンドラは対応するcreateDescriptorContent()法をサポートしないという例がある。

0134

関連する適切な記述子ハンドラと記述子ハンドラのための標準的インターフェースを参照する記述(すなわち記述スキーム中のデフォルトハンドラ)を備えることによって、非常に汎用的なアプリケーションを構成することが可能になる。例えば、上記の選択2のデータベース・サーバー・アプリケーションはリンクされた処理の定義済みセットを持つことを必要としない。実際、以下に記述されているように、異なる1セットのオプションの記述子と、すべての記述プロバイダが使用した異なる記述子・パラメータとにもかかわらず、上記の選択2の中のすべての記述プロバイダは同じデータベース・サーバー・アプリケーションを使用することができる。
コード定義A
DescriptorHandlerインターフェースのIDL定義:
//File: DescHdlr.idl
//Descriptor Handler IDL
#ifndef _DescHdlr_idl_
#define _DescHdlr_idl_
#pragma prefix "canon.com"
#include <Descriptor.idl>
#include <URI.idl>
module DescriptorHandler {
interface DescriptorHandler;
typedef sequence<octet> ByteArray;
typedef sequence<string> ParameterList;
typedef sequence<string> MetricList;
enum ExceptionType { INVALID_METHOD_NAME,
METHOD_NOT_SUPPORTED,
INVALID_PARAMETER_NAME,
INVALID_PARAMETER_VALUE,
XML_NOT_WELLFORMED,
NO_ACCESS_PRIVILEGE,
RESOURCE_UNAVAILABLE,
RESOURCE_NOT_FOUND,
FORMAT_NOT_SUPPORTED,
READ_ERROR,
WRITE_ERROR,
INVALID_DESCRIPTOR_CLASS,
INVALID_DESCRIPTOR_ATTRIBUTE,
INVALID_DESCRIPTOR_CONTENT,
INVALID_METRIC,
INVALID_ENCODED_STRING,
OUT_OF_MEMORY,
UNKNOWN_EXCEPTION };
// Exceptions
exception DescriptorHandlerException {
ExceptionType error;
wstring description;
};
interface DescriptorHandler
{
// Get the list of parameters used by the descriptor.
ParameterList getParameterList()
raises (DescriptorHandlerException);
// Get/set the specified parameters.
string getParameter(in string parameterName)
raises (DescriptorHandlerException);
void setParameter(in string parameterName, in string
parameterValue)
raises (DescriptorHandlerException);
// The method creates the content of the descriptor using
// the specified resource based on the current value of the
// parameter attributes. If not supported, a METHOD_NOT_SUPPORTE
D
// exception is raised.
Descriptor createDescriptorContent(in URI resource)
raises (DescriptorHandlerException);
// The methodscompute the similarity between the two
// descriptors passed in. The similarity measure computed
// is returned. If not supported, a METHOD_NOT_SUPPORTED
// exception is raised.
double getSimilarity(in Descriptor descriptor1,
in Descriptor descriptor2)
raises (DescriptorHandlerException);
// Get the list of metrics supported for computing similarity.
// The first in the list is the default metric used.
MetricList getSimilarityMetrics()
raises (DescriptorHandlerException);
// Set the metric to be used for computing similarity.
string setSimilarityMetric(in string metricName)
raises (DescriptorHandlerException);
// Validate the content of the descriptor. If the content
// is valid, return true;otherwise, return false. The
// default implementation always return true.
boolean validate(in Descriptor descriptor)
raises (DescriptorHandlerException);

// Encode (compress) the descriptor for transmission or
// for archiving. If not supported, a METHOD_NOT_SUPPORTED
// exception is raised.
ByteArray encode(in Descriptor descriptor)
raises (DescriptorHandlerException);
// Decode (decompress) the encoded descriptor. If not
// supported, a METHOD_NOT_SUPPORTED exception is raised.
Descriptor decode(in ByteArray encodedStr)
raises (DescriptorHandlerException);
};
};
#endif
// _DescHdlr_idl_
記述子(すなわち特性)のデータ(値)は通常いくつかのパラメータに依存する。例えば、カラー・ヒストグラムのデータは使用されるカラー空間スペースと量子化に依存する。一般に、記述子ハンドラが存在する場合これらのパラメータは対応する記述子ハンドラによっても使用される。DescriptorHandlerインターフェースの中で関連するパラメータのリストを得るための、及び、パラメータ値を設定するための方法が与えられる。パラメータの設定は、記述子・サンプルの特性を制御するが、記述子のインスタンスが記述した実際のコンテンツとは関連しないことに留意されたい。

0135

DDFがXMベースであるという事実に照らして、XML属性としてパラメータを指定し、リソース(コンテンツ)について記述するデータ(値)をコンテンツ・モデルの一部とするのがよい。例えば、カラー・ヒストグラム・記述子の1つのインスタンスは以下のようになるかもしれない。
<!-- rgbHistogram: 各ビン(bin)(<frequency>タグ対によってマークされた)は、(r、g、b)と(r+binsize-1、g+binsize-1、b+binsize-1)を含む間の値を持つ画素数を格納する-->
<rgbHistogram binSize="32">.
<frequency r=“0” g=“0” b=“0”>14009</frequency>
<frequency r=“32” g=“32” b=“32”>21015</frequency>
...
<frequency r=“224” g=“224” b=“224”>12434</frequency>
</rgbhistogram>
ビン(bin)サイズは、ヒストグラムのパラメータであるが、(周波数)ビン(bin)のパラメータである各ビン(bin)の開始rgb値はXML属性として指定される。これと対照的に、コンテンツ中のrgb値の範囲の発生数について記述するビン(bin)周波数は、コンテンツ・モデルの値として出現する。それにもかかわらず、記述子・パラメータについてXML属性を使用する原理は好適な記述子設計のためのガイドラインとして処理することができるだけで、この原理をDDFプロセッサによって検証することはできない。

0136

DescriptorHandlerクラスについて定義されるインターフェースから明らかなように、記述子ハンドラは、低レベル記述の自動作成、データベースを検索するためのサンプル・記述子の生成、同じクラスの記述子間の類似性の計算、記述子・コンテンツの検証、記述子・コンテンツの符号化と復号化の際を行う。

0137

多くの低レベル・記述子をコンテンツから自動的に抽出することを予期することが可能であるし、実際に予期されている。コンテンツが取り込まれている最中にリアルタイムで低レベル・記述子を作成することさえ可能であることが予期されている。例えば、ビデオの録画中もしくは次に続く処理で、何らかの一般的なビデオ・セグメント記述スキーム用記述子ハンドラは、ビデオカメラによって出力されたメタデータを使用してビデオを時間的にセグメントしてクリップ(セグメント)中へ入れ、ビデオの構造について記述する記述を生成することができる。非標準化記述スキームの記述子ハンドラを使用することもできることに留意されたい。例えば、図8はビデオとカメラ・メタデータ804とを利用するビデオ・セグメント記述802を生成するビデオ処理用アプリケーション808を示す図である。ビデオ処理用アプリケーション808は、記述802を生成する際標準的ライブラリ806からビデオ・セグメント・記述子ハンドラ800を利用する。図示のように、記述802は記述子ハンドラ800を参照する。

0138

記述が生成される際、処理用アプリケーションによって記述子ハンドラの以下の方法が呼び出される:
関連するパラメータリストを得るためのgetParameters()法
必要なパラメータを設定するためのsetParameterValue()法
記述子を生成するためのcreateDescriptorContent()法
必要な場合、アプリケーションは記述子・ノードのXMLシリアル化を得るために記述子のgetXML()法を呼び出すこともできる。自動抽出が難しいビデオの他の構造的構成要素と、構造的構成要素の意味論について記述する更に高レベルの記述子とは、対話型ツール補助によって後で追加記述されることが予期される。

0139

記述子ハンドラ・アプローチによって、開発者が(低レベル)特性の記述を生成するための様々な抽出アルゴリズムを開発し、ある種の“プラグイン”として、そのアルゴリズムを売り出したり配布したりすることが可能になる。

0140

個々のデータベース・サーバーは、記憶した記述が参照する同じ1セットの記述子ハンドラを使用して、問合せで指定する任意のサンプル・オブジェクト用の、類似したあるいは互換性のある記述子を生成することができる。次いでデータベース・サーバーは記述子ハンドラのgetSimilarity()法を用いて、記憶した記述の記述子とサンプル・オブジェクトの記述子を比較することができる。例えば上記選択2で、クライアントはその問合せと共に複数の遠隔画像データベースへサンプル画像を送信することができる。次いで、その画像の記述が参照する記述子ハンドラと、その画像の記述が使用する同じパラメータ設定値とを用いて、各データベースは画像のヒストグラム・記述子を生成する。

0141

例えば図9は、記述子ハンドラをどのように使用して複数の遠隔画像データベースにわたるサンプルによる問合せ検索をサポートすることができるかを示す図である。クライアント900はその問合せと共にサンプル画像902を記述/コンテンツ・プロバイダA〜Zへ送信する。各記述/コンテンツ・プロバイダA〜Zは、画像を記憶するための画像データベース904と、記憶された画像のカラー・ヒストグラムを記憶するための記述データベース906と、データベース検索エンジン908とを有する。記述/コンテンツ・プロバイダAは、問合せを受信すると、その記述データベース906に記憶されている画像カラー・ヒストグラム914Aが参照するカラー・ヒストグラムハンドラ912Aを利用する対応するヒストグラム・記述子911Aを生成する910A。記述/コンテンツ・プロバイダB〜Zは対応するヒストグラム・記述子911B、...、911Zを同様の方法で生成する。すなわち、その画像の記述が参照する記述子ハンドラと、その記述が使用する同じパラメータ設定とを用いて、各プロバイダによってサンプル画像のヒストグラム・記述子が生成される。次いで、その記述データベース906に記憶されている画像カラー・ヒストグラム914Aとサンプル・ヒストグラム911Aとの類似性がプロバイダAによって計算される。プロバイダB〜Zは、同様の方法で対応する画像カラー・ヒストグラム914B、...、914Zとサンプル・ヒストグラム911B、...、911Zとの類似性を計算する。次いで、同様のカラー・ヒストグラムを持つ画像及び/又は記述がデータベース904、906から検索され、プロバイダA、...、Zによって問合せの結果としてクライアント900へ伝送される。この様にして、各プロバイダはカラー・ヒストグラムを生成する異なる処理を使用すると同時に一貫した問合せ結果を出力することもできる。記述子ハンドラ・アプローチによって、単一データベースがが記憶している画像の異なるクラスについての異なるパラメータを持つヒストグラムを単一データベースが利用することも可能になる。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 富士ゼロックス株式会社の「 データ管理システム」が 公開されました。( 2020/09/24)

    【課題】階層構造になっている管理システムにおいて、管理対象データの実体を最上位の装置が全て管理する場合と比較して、管理対象データがユーザの意図しない装置に提供されないシステムを提供する。【解決手段】管... 詳細

  • ソニー株式会社の「 情報処理装置、情報処理方法、およびプログラム」が 公開されました。( 2020/09/24)

    【課題・解決手段】本技術は、複数人のユーザが皆満足できる空間を提供することができるようにする情報処理装置、情報処理方法、およびプログラムに関する。分析部は、複数人のユーザが存在する環境におけるセンシン... 詳細

  • アルテリックス インコーポレイテッドの「 並列処理を使用したハッシュ結合の実行」が 公開されました。( 2020/09/24)

    【課題・解決手段】データレコードは、コンピュータを使用して結合される。第1の複数のデータレコードおよび第2の複数のデータレコード内のデータレコードがハッシュされる。第1の複数のデータレコードおよび第2... 詳細

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ