コンテンツ参照識別子

コンテンツ参照識別子（CRID）は、 TV-Anytimeフォーラムによる標準化作業から生まれた概念です。これは、ワールドワイドウェブ（WWW ）で使用されるUniform Resource Locator （URL）の概念とほぼ一致しています。

ブロードキャスト ストリーム内のコンテンツの単位は、Webページが Web 上でグローバルに一意の URL によって参照されるのと同じように、グローバルに一意の CRID によって参照できます。

CRID の概念により、コンテンツの場所に関わらず、つまり、特定の放送情報 (時間、日付、チャンネル) や、ストリーミング サービスやインターネット サーバーからのファイルのダウンロードなど、ネットワーク経由でコンテンツを取得する方法を知らなくても、コンテンツを明確に参照できるようになります。

受信機は、これらの明確な参照を解読する、つまりコンテンツを取得するためにその場所を特定できる具体的なデータに変換できる必要があります。これにより、これらの情報を知らなくても、さらには録画するコンテンツの時間を事前に知らなくても、録画プロセスを実行できるようになります。例えば、クリックするだけでシリーズ全体を録画したり、まだ予約されていない番組を録画したり、特定の基準でグループ化された番組セットを録画したりといったことが可能です。

このフレームワークは、特定のコンテンツへの参照（CRID）と、そのコンテンツを取得するために必要な情報（「ロケータ」と呼ばれる）を分離することを可能にします。各CRIDは、同じコンテンツの異なるコピーを表す1つ以上のロケータにつながる場合があります。それらは、異なるチャンネルや日付で放送された、あるいは異なる価格の同一のコピーである可能性があります。また、フォーマットや品質などの技術的パラメータが異なる、異なるコピーである可能性もあります。

また、CRID の解決プロセスによって、結果として別の CRID (たとえば、別のオペレータによって割り当てられた代替識別子を持つ別のネットワークでの参照) や CRID のセット (たとえば、元の CRID が TV シリーズを表す場合、解決プロセスによって各エピソードを表す CRID のリストが生成される) が提供される場合もあります。

以上のことから、あるコンテンツが複数のグループ（それぞれが独自の特性によって定義される可能性がある）に属する場合、複数のCRIDが同じコンテンツを持つ可能性があると結論付けることができます。つまり、複数のCRIDが同じロケータに解決される可能性があります。

CRIDは、特定のコンテンツに対する普遍的かつ一意で排他的な識別子ではありません。CRIDは、それを作成した機関、解決サービスプロバイダー、そしてコンテンツプロバイダーと密接に関連しており、同じコンテンツであっても、利用分野に応じて異なるCRIDが付与される場合があります（例えば、コンテンツの放送権を持つテレビ事業者ごとに異なるCRIDが付与される場合があります）。

形式

CRIDの指定方法はURLとほぼ同じです。実際、CRIDはいわゆるURIです。通常、コンテンツ制作者、放送局、または第三者は、DNS名と製品固有の名前を組み合わせて、グローバルに一意のCRIDを作成します。つまり、CRIDの構文は以下のとおりです。 

crid://authority/data

権限フィールドはCRIDを作成したエンティティを表し、その形式はDNS名です。データフィールドは、権限スコープ内のコンテンツを明確に識別する文字列を表します（権限自身によって割り当てられた文字列です）。

例えば、BBCが中国オリンピックの全番組のCRIDを作成したいとします。おそらく次のような形式になるでしょう。 

参照：://bbc.co.uk/olympics/2008/

これはグループCRID、つまりコンテンツのグループを表すCRIDです。そして、女子砲丸投げ決勝など特定のイベントを参照するには、メタデータ内で次のように記述します。 

参照：bbc.co.uk/olympics/2008/final/shotput/women

現在、一部の単方向テレビネットワークでは、番組CRID、シリーズCRID、グループCRID、そしてレコメンデーションCRIDの4種類のCRIDが主要な役割を果たしています。CRIDの最も重要な用途の一つは、最新のデジタルビデオレコーダー（ DVR、PVR ）のいわゆるシリーズリンク録画機能（SL）です。

一方、ロケータとは、受信機が特定のコンテンツを検索して取得するために必要なすべての情報を含む文字列です。コンテンツは、トランスポートストリーム経由で受信されるか、ローカルストレージに保存されるか、インターネットサーバーからファイルとしてダウンロードされるか、ストリーミングサービス経由で受信されるかに関係なく、受信機がコンテンツを検索して取得するために必要なすべての情報を含みます。例えば、DVBロケータには、トランスポートストリーム内の特定のコンテンツを識別するために必要なすべてのパラメータ（ネットワーク、トランスポートストリーム、サービス、テーブル、イベント識別子など）が含まれます。

TV-Anytime で確立されたロケータの形式は非常に汎用的かつシンプルで、次のようになります。 

[トランスポートメカニズム]:[特定のデータ]

ロケータ形式の最初の部分（トランスポートメカニズム）は、各メカニズム（トランスポートストリーム、ローカルファイル、HTTPインターネットアクセスなど）ごとに一意の文字列でなければなりません。2番目の部分は、特定のトランスポートメカニズムの範囲内でのみ一意でなければならず、メカニズム自体の規制を担当する組織によって標準化されます。例えば、この標準に準拠するネットワークのトランスポートストリーム内のコンテンツを識別するDVBロケータは次のようになります。 

dvb://112.4a2.5ec;2d22~20121212T220000Z—PT01H30M

これは、アドレス「112.4a2.5ec」（ネットワーク「112」、トランスポート ストリーム「4a2」、サービス「5ec」）で識別される DVB ネットワーク上の利用可能なチャンネルで、2012 年 12 月 12 日午後 10 時に 90 分間放送されるコンテンツ（文字列「2d22」で識別される）を示します。

位置解決プロセス

ロケーション解決プロセスとは、特定のコンテンツのCRIDから、そのコンテンツの1つまたは複数のロケータを取得する手順です。CRIDの解決は、1つまたは複数のロケータに即座につながる直接的なプロセスである場合もあれば、最初に1つまたは複数の中間CRIDが返され、最終的に1つまたは複数のロケータを取得するために同じ手順を踏まなければならない場合もあります。

この手順にはいくつかの情報要素が関与しており、その中にはそれぞれ解決権限レコード（RAR）とContentReferencingTableと呼ばれる2つの構造があります。これらを繰り返し参照することで、受信者はCRIDからコンテンツを取得するための1つまたは複数のロケータへと移動します。

RARテーブル

RARテーブルは、CRIDを送信する各認証局について、対応する解決サービスプロバイダに関する情報を受信者に提供する1つまたは複数のデータ構造です。特に、各認証局からのCRIDを解決するための情報を提供するためにどのメカニズムが使用されるかに関する情報を提供します。つまり、各認証局ごとに、受信者がその認証局のCRIDを解決するためにどこへアクセスすべきかを示す1つまたは複数のRARレコードが存在する必要があります。

たとえば、図のレコード（TV-Anytime で定義された XML スキーマに従って XML 構造で表現）には、「tve.es」と呼ばれる機関があり、その解決サービス プロバイダーはエンティティ「rtve.es」であり、URL「http://tva.rtve.es/locres/tve」で利用可能であるため、その URL に解決情報があることを意味します。

XML形式のRARテーブル
XML形式のRARテーブル

これらのRARレコードは、TV-Anytime仕様にとって重要ではない不定形式で受信機に届きます。TV-Anytime仕様は、受信機が接続されているネットワークの特定のトランスポートメカニズムに依存します。配信ネットワークを規制する各規格群（DVB、ATSC、ISDB、IPTVなど）では、このような手順が事前に定義されており、各規格に準拠した認証デバイスで使用されます。

ContentReferencingTableテーブル

位置解決プロセスに関係する 2 番目の構造は、コンテンツの CRID が指定されると、受信者がそのコンテンツのインスタンスにアクセスできるようにする 1 つまたは複数のロケータ、または解決プロセスを進めることができる 1 つまたは複数の CRID を返す適切な解決テーブルです。

図は、TV-Anytimeで定義されたXMLスキーマの仕様に準拠したXML文書である、この2番目の構造の例を示しています。この文書には、各解決ケースを記述する情報を構造化する複数のセクション（<Result>要素）が含まれています。

ContentReferencingTableの例
ContentReferencingTableの例

最初のコードは、「フレンズ」シリーズの複数のエピソード（2つ）を含むグループコンテンツに対応するCRID（crid://tv.com/Friends/all）がどのように解決されるかを宣言しています。解決プロセスの結果として、2つのエピソードのそれぞれに対応する2つの新しいCRIDが生成されます。

2番目の<Result>要素は、シーズン1の最初のエピソードのCRIDを解決します。解決処理の結果、2つのDVBロケータが返されます。「acquire」属性の値が「any」であることは、いずれのロケータも有効であることを示しています（2番目のロケータは1週間後に再放送されるものです）。

3番目の<Result>要素は、2番目のエピソードに関する情報を提供します。これは、まだ解決できないことを示しています（「status」属性の値が「cannot yet resolve」）。これは、解決情報の要求を再度行う必要がある日付を示しています。

プロセス

ユーザーが特定のコンテンツ（対応する CRID によって識別される）を選択して何らかのアクションを実行すると、受信機は位置解決プロセスを開始し、コンテンツのコピーへのアクセスを可能にする特定の位置情報を取得します。

この手順は主に受信者の接続性に依存します。受信者がブロードキャストチャネル経由でのみ情報を受信できる単方向ネットワークと、受信者が外部（通常はインターネットアクセス）と通信できる戻りチャネルも存在する双方向ネットワークという、基本的な区別が可能です。

放送チャンネルのみに接続された受信機の場合、解像度情報はそのチャンネルから直接取得するか、既存のローカルストレージシステムから何らかの方法で取得する必要があることは明らかです。CRIDを選択した後、受信機が最初に行う必要があるのは、解像度テーブルがどこにあるかの情報を確認することです。そのためには、選択したCRIDの権限に関連付けられたRARレコードを見つける必要があります。

その機関に対応する RAR レコードが見つかると、受信者は URL フィールドを参照して、解決情報を取得するためにアクセスする場所 (または、この場合は、リッスンする場所) を認識します。

そのアクセス ポイントを通じて受信される情報は、参照された各 CRID のメッセージ (たとえば、ContentReferencingTable の <Result> 要素) で構成されます。

ウェブキャストでは

CRIDをさらにグローバルに利用できるようにするために、IETFはWeb上でのCRIDの利用に関するコメント募集（RFP）を公開します。これにより、消費者向けデバイスは、現在のブラウザがWebサーバーを検索し、CRIDでコンテンツをリクエストするのと同様に、コンテンツプロバイダーのサーバーに接続できるようになります。

2005 年 5 月に、この作業の開始として、 Informational RFC No 4078が公開されました。

長期的な目標は、携帯電話、PDA、デジタル TV受信機、その他の消費者向けデバイスで、放送ストリームまたはIP ネットワーク経由でコンテンツを取得するために CRID を使用できるようにすることです。

参照

参考文献

「 https://en.wikipedia.org/w/index.php?title=Content_reference_identifier&oldid=1277552374」より取得