【注意】 このドキュメントは、W3CのODRL Information Model 2.2 W3C Recommendation 15 February 2018の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。
訳注： Policy、Rule等、頭文字が大文字になっている語句が本文中に多く出現しますが、基本的にそれらは大文字・小文字を区別せずに訳しました。また、一般的にobligationとdutyは「義務」と訳されますが、ここでは便宜的に、前者を「責務」、後者を「義務」と訳し分けました。
First Update: 2018年2月20日
公開以後に報告されたエラーや問題がないか正誤表を確認してください。
翻訳版も参照してください。
Copyright © 2018 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
ODRL(Open Digital Rights Language、オープン・デジタル権利言語)は、コンテンツとサービスの利用に関するステートメントを表すための柔軟で、相互運用可能な情報モデル、語彙、およびエンコード方法を提供する方針表現言語です。ODRL情報モデルは、ODRL方針のセマンティクスの基礎となる基本的な概念、エンティティー、および関係を記述しています。
方針は、ある資産に対して許可・禁止されている行為とともに、ステークホルダーが満たす必要のある義務を表すために用いられます。さらに、方針は制約(例えば、時間的または空間的な制約)によリ制限でき、許可には義務(例えば、支払い)を課すことができます。
この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、http://www.w3.org/TR/のW3C技術報告インデックスにあります。
このドキュメントは、Permissions & Obligations Expressionワーキンググループによって勧告として公開されました。本ドキュメントに関するコメントを歓迎します。コメントはpublic-poe-comments@w3.org(購読、アーカイブ)にお送りください。
ワーキンググループの実装報告書を参照してください。
このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用したりすることができます。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。
このドキュメントは、W3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。
このドキュメントは、2018年2月1日のW3Cプロセス・ドキュメントによって管理されています。
この項は非規範的です。
一部のビジネス・シナリオでは、資源に関してどのような行為が許可・禁止されているかを表す必要があります。通常、これらの許可/禁止されている行為は、方針という形、つまり、既存の規則またはオーナーが指定した制約に適合するコンテンツの利用および再利用を示す表現で表されます。方針は、追加情報、つまり、その方針の定義を担っているエンティティーは誰で、それに従う必要があるエンティティーは誰なのか、方針で表されている許可、禁止、義務に関連する追加の制約は何なのか、によって充実させることもできます。 これらの概念と関係を表す能力は、コンテンツの製作者にとって重要である(悪用を防止するために何が許可・禁止されているかを明確に述べることができる)とともに、消費者にとっても重要です(規則、法律やオーナーの制約に違反することを避けるためにどの資源の利用・再利用が認められているかを正確に知ることができる)。この仕様は、これらの方針の概念を表すための一般的な方法を記述しています。
ODRL情報モデルは、コンテンツの利用方法を表す許可、禁止、義務ステートメントの基礎となるセマンティック・モデルを定義します。この情報モデルは、コンテンツ利用ステートメントの基礎モデルを提供する中心的な概念、エンティティー、関係をカバーします。これらの機械可読の方針は、消費者がこの情報を容易に検索できるように、関連するコンテンツと直接リンクさせることができます。
ODRL情報モデルの主な目的は、一般的に、許可、禁止、責務のステートメントをコンテンツに関連付けて表すための標準的な記述モデルと形式を提供することです。このステートメントは、資源の利用・再利用の条件を記述するために用いられます。モデルは、複雑なケースを扱う場合であっても、方針のモデル化の容易さを維持しつつ、できる限り多くの許可、禁止、責務のユースケースをカバーすべきです。
ODRL情報モデルは、あらゆる当事者が利用できる、1つの整合性のあるモデルです。ユースケースを満たすためには、既存の標準に適応する必要がある場合や、1つの方法のみの採用に重大なコストが伴う場合を除き、複数の方法よりも、1つの方法の方が強く推奨されます。ODRL情報モデルは、リンクト・データの原則を用いて構築されていますが、非グラフ・ベースの実装を可能とすることを目指して設計されています。
非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。この仕様のその他の部分はすべて規範的です。
「することができる／してもよい(MAY)」、「しなければならない(MUST)」、「してはならない(MUST NOT)」、「推奨される(RECOMMENDED)」、「すべきである／する必要がある(SHOULD)」、「すべきでない／する必要がない(SHOULD NOT)」というキーワードは、[RFC2119]で記述されているように解釈されるべきです。
ドキュメント内のすべての例は、[json-ld]としてシリアル化されています。JSONコンテキストを含む規範的なシリアル化に関しては、ODRL語彙および表現[odrl-vocab]を参照してください。
ODRL情報モデルは、資産資源の利用に関連する許可、禁止、義務を表現する方針を表します。情報モデルは、方針によって何が許可され、何が許可されないかのほか、関係するその他の条件、要件、当事者を明示的に表します。ODRL情報モデルの目的は、方針の作成者が、方針に多くの(または、少ない)詳細を含むことができるようにすることで、柔軟な方針表現を可能とすることです。
下記の図は、ODRL情報モデルを示します。
ODRL情報モデルには次のクラスがあります。
Policy(方針) - 許可(許可プロパティーによる)および/または禁止(禁止プロパティーによる)および/または義務(責務プロパティーによる)の空でない集まり。方針クラスは、下記の集合、提案、合意のサブクラスに対する親のクラスです。
Set(集合) - 汎用的な規則の表現をサポートする方針のサブクラスOffer(提案) - 譲渡当事者からの規則の提案をサポートする方針のサブクラスAgreement(合意) - 譲渡当事者から譲受当事者への規則の譲渡をサポートする方針のサブクラスAsset(資産) - 規則の対象となる1つの資源または資源のコレクション(抽象的な関係プロパティーによる)。資産クラスは、下記に対する親のクラスです。
AssetCollection(資産コレクション) - 資源のコレクションを識別する資産のサブクラスParty(当事者) - 規則内の役割を担う1つのエンティティーまたはエンティティーのコレクション(抽象的な機能プロパティーによる)。当事者クラスは、下記に対する親のクラスです。
PartyCollection(当事者コレクション) - エンティティーのコレクションを識別する当事者のサブクラスAction(行為) - 資産に対する操作Rule(規則) - 許可、禁止、義務に共通する特徴を表す抽象概念
Permission(許可) - 資産に対して行為を行う能力。許可は、(許可を与えるための前提条件として)行われなければならない(MUST)合意された行為を表す義務プロパティーを持つこともできます(MAY)。Prohibition(禁止) - 資産に対して行為を行う能力がないことDuty(義務) - 行為を行う責務Constraint/LogicalConstraint(制約/論理制約) - 行為および当事者/資産コレクションまたは規則に適用可能な条件を精緻化するブール/論理式ODRL情報モデルには、クラス間のプロパティー関係が含まれています。ほとんどは明示的な名前を持つプロパティーで、一部が抽象的なプロパティー(具体的には、関係、機能、オペランド、失敗)です。抽象的なプロパティーとは、明示的なセマンティクスを有する子プロパティー(サブタイプ)で表すように設計された汎用的な親プロパティーです。
例えば、図1の関係、機能という2つのプロパティーは、規則と資産と当事者のクラスの間の概念関係を表すように設計されています。図では、サブタイプtargetを有する関係プロパティーを示し、資産が規則の主要な対象であることを表しています。機能プロパティーは、規則を発行している当事者を表すためにサブタイプassigner(譲渡人)を持ち、規則の受容当事者を表すためにサブタイプassignee(譲受人)を持っています。
ODRL情報モデルは、方針モデルの構成要素の論理ビューを提供します。ODRL情報モデルの実装可能なビューは、ODRL語彙および表現ドキュメント[odrl-vocab]で規範的に記述されているとおり、様々なエンコーディングのシリアル化により提供されます。論理的な情報モデル構成要素を実装可能なシリアル化にマッピングするためには、シリアル化言語でサポートされている機能に応じて、何らかのトレードオフおよび/または相違が必要かもしれません。
以下の項では、ODRL情報モデルに関するより詳細な情報を提供します。
方針(Policy)クラスには次のプロパティーがあります。
uidプロパティー値がなければなりません(MUST)。permission、prohibition、またはobligationのプロパティー値がなければなりません(MUST)。(詳細は、許可、禁止、責務の項を参照してください。)profileプロパティー値を持つことができます(MAY)。(詳細は、ODRLプロファイルの項を参照してください。)inheritFromプロパティー値を持つことができます(MAY)。(詳細は、ODRL継承の項を参照してください。)conflictプロパティー値を持つことができます(MAY)。(詳細は、方針衝突時の対策の項を参照してください。)ODRL方針は、すべてのその規則に共通するプロパティーを宣言することもできます(MAY)。具体的には、actionプロパティー、relationのサブプロパティー(targetなど)、およびfunctionのサブプロパティー(assignerやassigneeなど)です。これらの共通プロパティーの検証要件に関しては、コンパクトな方針を参照してください。
ODRL方針は、次のいずれかを行わなければなりません。
後者の場合、ODRLプロファイルのIRIを示すために、プロファイル・プロパティーを用いなければなりません(MUST)。ODRLプロファイルおよび適合性要件を定義する方法に関する詳細は、ODRLプロファイルの項を参照してください。(このドキュメントの例では、説明に役立つことのみを目的として、ODRLプロファイル識別子を用いています。)
ODRL方針は、ODRLプロセッサが理解しなければならない(MUST)追加の制約を含めることができる(MAY)方針の利用のコンテキストをより正確に記述するためにサブクラス化することができます(MAY)。追加の方針サブクラスは、ODRL共通語彙[odrl-vocab]またはODRLプロファイルでドキュメント化できます(MAY)。方針クラスは、すべての方針サブクラス(集合を除く)と素でなければなりません(MUST)。
サブクラスSet(集合)のODRL方針は、規則の任意の組み合わせを表します。Set方針サブクラスは、(何も指定されていない場合)方針のデフォルトのサブクラスでもあります。
ユースケースの例: 下記の
Set方針は、ターゲット資産http//example.com/asset:9898.movieをuse(利用する)許可を表します。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Set",
"uid": "http://example.com/policy:1010",
"permission": [{
"target": "http://example.com/asset:9898.movie",
"action": "use"
}]
}
このドキュメントの例では、ODRL方針サブクラスはJSON-LD @typeトークンにマッピングされています。上記の例では、Set型の代わりにPolicy型を用いることもできました(それらが同等であるため)。
すべての用語がODRLコア語彙[odrl-vocab]で定義されているため、上記の例ではprofileプロパティーを用いていません。
サブクラスOffer(提案)のODRL方針は、譲渡当事者から提案される規則を表します。一般的に、Offerは、より広い利用者が利用できる方針を作るために用いられますが、規則は許可しません。
サブクラスOfferのODRL方針は次のとおりです。
assignerプロパティー値がなければなりません(MUST)。注: 機能的役割の詳細は、機能プロパティーの項を参照してください。
注: 上記のプロパティーのカーディナリティーは、規範的なODRL情報モデルを反映しています。場合によっては、一部のプロパティーの繰り返し出現もサポートされていますが(方針規則の合成とコンパクトな方針で記述しているとおり)、規範的でアトミックな方針は、上記のプロパティーのカーディナリティーと整合性があります。
ユースケースの例: 下記の
Offer方針(以前の例に基づく)は、譲渡当事者http://example.com/party:org:abcからの、ターゲット資産http//example.com/asset:9898.movieをplay(再生する)許可を表します。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:1011",
"profile": "http://example.com/odrl:profile:01",
"permission": [{
"target": "http://example.com/asset:9898.movie",
"assigner": "http://example.com/party:org:abc",
"action": "play"
}]
}
上記の例では、用いている用語がhttp://example.com/odrl:profile:01で識別されるODRLプロファイルで定義されていることを示すために、profileプロパティーを用いています。詳細は、ODRLプロファイルの項を参照してください。
サブクラスAgreement(合意)のODRL方針は、譲渡当事者から譲受当事者に与えられている規則を表します。一般的に、Agreementは、当事者間で規則の条件を付与するために用いられます。
サブクラスAgreementのODRL方針は次のとおりです。
assignerプロパティー値がなければなりません(MUST)。assigneeプロパティー値がなければなりません(MUST)。注: 機能的役割の詳細は、機能プロパティーの項を参照してください。
注: 上記のプロパティーのカーディナリティーは、規範的なODRL情報モデルを反映しています。場合によっては、一部のプロパティーの繰り返し出現もサポートされていますが(方針規則の合成とコンパクトな方針で記述しているとおり)、規範的でアトミックな方針は、上記のプロパティーのカーディナリティーと整合性があります。
ユースケースの例: 下記の
Agreement方針(以前の例に基づく)は、譲渡当事者http://example.com/party:org:abcから譲受当事者http://example.com/party:person:billieに、ターゲット資産http//example.com/asset:9898.movieをplay(再生する)許可を与えることを表します。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Agreement",
"uid": "http://example.com/policy:1012",
"profile": "http://example.com/odrl:profile:01",
"permission": [{
"target": "http://example.com/asset:9898.movie",
"assigner": "http://example.com/party:org:abc",
"assignee": "http://example.com/party:person:billie",
"action": "play"
}]
}
資産(Asset)クラスは、規則の対象である1つの資源または資源のコレクションです。資産は、データ/情報、コンテンツ/メディア、アプリケーション、サービス、物理的人工物などの、任意の形式の識別可能な資源でありえます。さらに、それは、義務の付与など、方針表現を担うために必要なその他のAssetクラスを表すために使用できます。資産は、許可および/または禁止によって参照され、義務によっても参照されます。
資産クラスには次のプロパティーがあります。
uidプロパティー値を持っているべきです(SHOULD)。partOfプロパティー値を持つことができます(MAY)。資産がuidプロパティーを用いて識別子を言明していない場合は、ODRL方針のODRL検証システムと評価システムへの影響など、完全な意味が理解されていなければなりません。
資産クラスには次のサブクラスがあります。
AssetCollection(資産コレクション) - メンバー資源の集合を表す1つの資源である資産。これは、集合のすべてのメンバーが規則の対象となることを示します。資産コレクション・クラスには次のプロパティーがあります。
sourceプロパティー値を持つことができます(MAY)。refinementプロパティー値を持つことができます(MAY)。詳細は、資産コレクションと精緻化プロパティーを参照してください。ODRL方針はあらゆる種類の資産を扱うことができるため、ODRL情報モデルは、特定のメディア・タイプの資産を記述するための追加のメタデータを提供しません。資産の型や目的に適したダブリン・コア・メタデータ用語などの既存のメタデータ標準を用いることをお勧めします。
抽象的なrelation(関係)プロパティーは、行為と資産との間に明示的なリンクを作成するために用いられ、リンクされている規則に関してどのように資産を利用しなければならない(MUST)かを示します。
関係のODRL検証システムは、次のrelationのサブプロパティーをサポートしなければなりません(MUST)。
target(ターゲット): 資産が、規則の行為が直接適用される主な対象であることを示します。追加のrelationサブタイプ・プロパティーは、ODRL共通語彙[odrl-vocab]とODRLプロファイルで定義できます(MAY)。
ユースケースの例: 譲渡当事者
http//example.com/party:0001は、target資産http://example.com/asset:3333を表示することを提案します。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:3333",
"profile": "http://example.com/odrl:profile:02",
"permission": [{
"target": "http://example.com/asset:3333",
"action": "display",
"assigner": "http://example.com/party:0001"
}]
}
上記の例では、relationプロパティーのJSON-LD表現は、親のrelationプロパティーのサブタイプとして定義されているため、targetをトークンとして直接用いています。
ユースケースの例: 下記の方針は、ターゲット資産
http://example.com/archive1011におけるindex(インデキシングを行う)行為の許可を表します。ターゲット資産は、資源が資源のコレクションに属することを示すために、AssetCollectionとしても宣言されています。追加の資産関係であるsummaryは、インデキシングの出力が蓄積されるべき資産http://example.com/x/databaseを示します。ODRLプロファイルhttp://example.com/odrl:profile:03は、関係のこの新しいサブプロパティーを定義します。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Policy",
"uid": "http://example.com/policy:1011",
"profile": "http://example.com/odrl:profile:03",
"permission": [{
"target": {
"@type": "AssetCollection",
"uid": "http://example.com/archive1011" },
"action": "index",
"summary": "http://example.com/x/database"
}]
}
partOf(～の部分)プロパティーは、資産資源をメンバーとして持つ資産コレクションを識別するために用います。その目的は、資産と資産コレクションの間のメンバーシップ関係を明示的に表すことです。これにより、資産コレクションに関連付けられている規則は、どの資産に規則が個々に適用されているかを知ることができます。さらに、資産/資産コレクションのメンバーシップ関係により、規則内の衝突を検出できる可能性があります。
ユースケースの例: 下記の断片は、ドキュメントを記述しているあるダブリン・コア・メタデータを表します。
odrl:partOfプロパティーは、資源http://example.com/asset:111.docが、上記の例における方針で用いられているhttp://example.com/archive1011資産コレクションのメンバーであると言明しています。これは、http://example.com/asset:111.docが方針内のターゲット資産のうちの1つであり、インデキシングできることを意味します。
{
"@type": "dc:Document",
"@id": "http://example.com/asset:111.doc",
"dc:title": "Annual Report",
...
"odrl:partOf": "http://example.com/archive1011",
...
}ODRL方針クラスは、hasPolicy(方針を持つ)プロパティーで参照することもできます(MAY)。これにより、ODRL方針規則を(資産を識別する)外部メタデータ表現の目的語にすることができます。メタデータ表現とODRL方針の間でhasPolicyが言明されている場合、識別されている資産は、その方針のすべての規則のtarget資産であると推論されなければなりません(MUST)。方針内に複数の規則がある場合、この推論された資産が方針内のすべての規則のターゲット資産となるでしょう。
ユースケースの例: 下記の断片は、映画の資産を記述しているあるダブリン・コア・メタデータを表します。
odrl:hasPolicyプロパティーが、ODRL方針http://example.com/policy:1010(これは、上記の集合方針)にリンクされています。このケースでは、資産http://example.com/asset:9999.movieは、方針http://example.com/policy:1010の許可に対するターゲット資産にもなりました。この方針に追加の規則があれば、同じ資産が各規則のターゲット資産となるでしょう。
{
"@type": "dc:MovingImage",
"@id": "http://example.com/asset:9999.movie",
"dc:publisher": "ABC Pictures",
"dc:creator": "Allen, Woody",
"dc:issued": "2017",
"dc:subject": "Musical Comedy",
...
"odrl:hasPolicy": "http://example.com/policy:1010",
...
}
当事者(Party)クラスは、人、人のコレクション、組織、エージェントなど、規則内の機能的役割を担う1つのエンティティーまたはエンティティーのコレクションです。エージェントは、積極的な役割を果たす、または特定の効果を生み出す人または物です。当事者は、行為を行う(または、実行しない)か、義務において機能を持っています(つまり、規則内で担う機能に関連付けることにより、当事者を規則に割り当てる)。
当事者クラスには次のプロパティーがあります。
uidプロパティー値を持っているべきです(SHOULD)。partOfプロパティー値を持つことができます(MAY)。当事者がuidプロパティーを用いて識別子を言明していない場合は、ODRL方針のODRL検証システムと評価システムへの影響など、完全な意味が理解されていなければなりません。
当事者クラスには次のサブクラスがあります。
PartyCollection(当事者コレクション) - メンバー・エンティティーの集合を表す1つのエンティティーである当事者。これは、集合のすべてのメンバーが、規則内の同じ機能的役割を担うことを示します。当事者コレクション・クラスには次のプロパティーがあります。
sourceプロパティー値を持つことができます(MAY)。refinementプロパティー値を持つことができます(MAY)。詳細は、当事者コレクションと精緻化プロパティーを参照してください。ODRL情報モデルは、当事者クラスに追加のメタデータを提供しません。W3C vCardオントロジー[vcard-rdf]やFOAF語彙[foaf]などの既存のメタデータ標準を用いることをお勧めします。
function(機能)プロパティーは、規則を当事者にリンク付けるために用いられ、リンクされている規則に関して当事者が担っている機能を示します。functionプロパティー自身は抽象的で、サブプロパティーが、当事者と規則の間の機能的役割の明示的なセマンティクスを表します。
ODRL検証システムは、functionの次のサブプロパティーをサポートしなければなりません(MUST)。
assigner(譲渡人): 規則を発行する当事者を示します。例えば、許可を与えたり、合意した義務の履行を要求する当事者。assignee(譲受人): 規則の受容者である当事者を示します。例えば、許可が与えられたり、合意した義務の履行を要求される当事者。追加のfunctionサブタイプ・プロパティーは、ODRL共通語彙[odrl-vocab]とODRLプロファイルで定義できます(MAY)。
ユースケースの例: この方針は、
assignerとassigneeの機能的役割を持つ2つの当事者との合意を示します。assignerは、assigneeにターゲット資産に対する再生行為の実行を許可しています。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Agreement",
"uid": "http://example.com/policy:8888",
"profile": "http://example.com/odrl:profile:04",
"permission": [{
"target": "http://example.com/music/1999.mp3",
"assigner": "http://example.com/org/sony-music",
"assignee": "http://example.com/people/billie",
"action": "play"
}]
}
上記の例では、functionのJSON-LD表現は、親のfunctionプロパティーのサブプロパティーとして定義されているため、assignerとassigneeをトークンとして直接用いています。
ユースケースの例: この方針は、
assignerとassigneeの機能的役割を持つ2つの当事者との合意を示します。assignerは、assigneeにターゲット資産の利用を許可しています。このケースにおいて、assignerは、Partyとしても、vcard:Organisationや一部の追加の外部プロパティーとしても明示的に宣言されています。assigneeは、PartyCollectionとしても、vcard:Groupや一部の追加の外部プロパティーとしても明示的に宣言されています。これは、http://example.com/team/Aとして識別されるすべてのエンティティーが、それぞれ同じ許可された行為を持っているということを意味します。
{
"@context": [
"http://www.w3.org/ns/odrl.jsonld",
{ "vcard": "http://www.w3.org/2006/vcard/ns#" }
],
"@type": "Agreement",
"uid": "http://example.com/policy:777",
"profile": "http://example.com/odrl:profile:05",
"permission": [{
"target": "http://example.com/looking-glass.ebook",
"assigner": {
"@type": [ "Party", "vcard:Organization" ],
"uid": "http://example.com/org/sony-books",
"vcard:fn": "Sony Books LCC",
"vcard:hasEmail": "sony-contact@example.com" },
"assignee": {
"@type": [ "PartyCollection", "vcard:Group" ],
"uid": "http://example.com/team/A",
"vcard:fn": "Team A",
"vcard:hasEmail": "teamA@example.com"},
"action": "use"
}]
}
partOf(～の部分)プロパティーは、当事者エンティティーをメンバーとして持つ当事者コレクションを識別するために用いられます。その目的は、当事者と当事者コレクションの間のメンバーシップ関係を明示的に表すことです。これにより、当事者コレクションに関連付けられている規則は、どの当事者に個々に規則が適用されているかを知ることができます。さらに、当事者/当事者コレクションのメンバーシップ関係により、規則内の衝突を検出できる可能性があります。
ユースケースの例: 下記の断片は、当事者を記述しているあるvCardメタデータを表しています。
odrl:partOfプロパティーは、当事者http://example.com/person/murphyが、上記の例の方針で用いられているhttp://example.com/team/A当事者コレクションのメンバーであると言明しています。これは、http://example.com/person/murphyが譲受人であり、方針のターゲット資産を使用できることを意味します。
{
"@type": "vcard:Individual",
"@id": "http://example.com/person/murphy",
"vcard:fn": "Murphy",
"vcard:hasEmail": "murphy@example.com",
...
"odrl:partOf": "http://example.com/team/A",
...
}
ODRL方針クラスは、assignerOf(～の譲渡人)とassigneeOf(～の譲受人)のプロパティーで参照することもできます(MAY)。これにより、ODRL方針規則を(当事者を識別する)外部メタデータ表現の目的語にすることができます。メタデータ表現とODRL方針の間でassignerOfが言明されている場合、識別されている当事者は、その方針のすべての規則のassignerの機能的役割を担うと推論されなければなりません(MUST)。メタデータ表現とODRL方針の間でassigneeOfが言明されている場合、識別されている当事者は、その方針のすべての規則のassigneeの機能的役割を担うと推論されなければなりません(MUST)。方針内に複数の規則がある場合、この推論された当事者が方針内のすべての規則の機能的役割を担うでしょう。
ユースケースの例: 下記の断片は、個々の当事者を記述しているあるvCardメタデータを表しています。
odrl:assigneeOfプロパティーが、ODRL方針http://example.com/policy:1011(これは、上記の提案方針)にリンクされています。このケースでは、当事者http://example.com/person/billieは、方針http://example.com/policy:1011の許可の譲受人にもなりました。この方針に追加の規則があれば、同じ当事者が各規則の譲受人となるでしょう。
{
"@type": "vcard:Individual",
"@id": "http://example.com/person/billie",
"vcard:fn": "Billie",
"vcard:hasEmail": "billie@example.com",
...
"odrl:assigneeOf": "http://example.com/policy:1011",
...
}
行為(Action)クラスは、資産に対して行える操作を示します。行為は、規則内の行為プロパティーにより資産に関連付けられます。
規則は、行為の具体的な解釈を提供します。例えば、行為が許可に関連付けられていれば、ターゲット資産に対する実行が許可されています。禁止に関連付けられていれば、行為は、ターゲット資産に対して行うことが禁止されている操作を示します。義務と関連付けられていれば、行為は、当事者による履行が義務付けられている合意された操作を示します。
ODRL情報モデルは、次のトップレベルの行為を定義します。
use(利用する) - 当事者による一般的な利用に関する行為transfer(譲渡する) - 第三者への所有権の譲渡に関する行為行為クラスには次のプロパティーがあります。
refinementプロパティー値を持つことができます(MAY)。詳細は、制約の項を参照してください。includedInプロパティー値がなければなりません(MUST)。impliesプロパティー値を持つことができます(MAY)。行為の用語は、包含行為を指すincludedInプロパティーを用い、useまたはtransferのいずれかを推移的な手段によってトップレベルの親の用語として用いて定義しなければなりません(MUST)。includedInプロパティーの目的は、他の行為の参照されているインスタンスのセマンティクスがこの行為のインスタンスのセマンティクスを包含して(含んで)いることを明示的に言明することです。includedInプロパティーは推移的であり、したがって、行為は先祖関係を形成します。
includedInプロパティーは、includedIn関係により、包含行為の許可または禁止がすべての行為に継承されるということを暗示します。例えば、playの行為がuseにincludedIn(含まれる)と定義されている場合、ある方針でplayが許されていて、同じ方針でuseが禁止されていれば - そして、両方の行為が同じターゲット資産に適用されていれば - 2つの間のこの言明関係のため、方針には衝突があります。(詳細は、方針衝突時の対策を参照してください。)
impliesプロパティーは、行為のインスタンスには、行為のその他のインスタンスが禁止されてないことが含意されていることを言明します。impliesプロパティーは、2つの行為のインスタンスにincludedIn関係がない場合でも、それらの間にそのような言明を確立できます。例えば、明らかにshareの行為にdistributeの行為が暗示されている場合、ある方針でshareが許されていて、同じ方針でdistributeが禁止されていれば - そして、両方の行為が同じターゲット資産に適用されていれば - 方針に衝突が生じます。暗示されている他の行為が禁止されていなければ、衝突は生じません。(詳細は方針衝突時の対策を参照してください。)
includedInおよびimpliesのプロパティーの利用方法の詳細は、ODRLプロファイルを参照してください。
ODRL共通語彙[odrl-vocab]は、ODRLプロファイルに採用できる(MAY)汎用的な行為の標準セットを定義します。
ユースケースの例: この方針は、資産を
play(再生する)行為を伴うターゲット資産http://example.com/music:1012に対する提案を表します(playは、useのincludedIn用語であると定義されている)。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:1012",
"profile": "http://example.com/odrl:profile:06",
"permission": [{
"target": "http://example.com/music:1012",
"assigner": "http://example.com/org:abc",
"action": "play"
}]
}
制約は、行為および当事者/資産コレクションのセマンティクスを精緻化したり、規則に適用可能な条件を宣言したりするために使用できるブール/論理式です。制約は、制約クラスまたは論理制約クラスとして表現できます。論理制約は、既存の制約をオペランドとして参照します。複数の制約が同じ規則、行為、当事者/資産コレクションに適用されている場合、それらは論理積として解釈され、すべてが満たされなければなりません(MUST)。
制約および論理制約のクラスは、当事者コレクション、資産コレクション、行為、規則のクラスとのセマンティック関係および条件関係を形成します。下記の図でプロパティー関係を要約しています。
制約(Constraint)クラスは、2つのオペランド(制約ではない)を1つの関係演算子で比較する式に用いられます。比較によって一致が返された場合は制約が満たされ、そうでない場合は満たされません。制約クラスは、利用数(leftOperand)は10(rightOperand)よりも小さくなければならない(operator)などの比較式を作成します。
制約クラスには下記のプロパティーがあります。
uidプロパティー値を持つことができます(MAY)。leftOperandプロパティー値がなければなりません(MUST)。operatorプロパティー値がなければなりません(MUST)。dataTypeプロパティー値を持つことができます(MAY)。unitプロパティー値を持つことができます(MAY)。statusプロパティー値を持つことができます(MAY)。leftOperandプロパティー値は、左オペランド・クラスのインスタンスであると定義されています。leftOperandインスタンスは、制約のセマンティクスを示すために明確に定義されなければならず(MUST)、比較のための値をどのように取得または生成しなければならないかを宣言できます(MAY)。ODRL共通語彙[odrl-vocab]は、ODRLプロファイルが使用できる(MAY)leftOperandを定義しています。
operatorプロパティー値は、演算子クラスのインスタンスであると定義されています。operatorインスタンスは、左右のオペランドの間の「～より大きい」や「～と等しい」などの関係演算を識別します。
rightOperandプロパティー値は、右オペランド・クラス、またはIRI、またはリテラル値のインスタンスであると定義されています。rightOperandは、leftOperandと比較される制約の値です。rightOperandReferenceは、rightOperandの実際の値を取得するために最初に逆参照しなければならない(MUST)IRIを表します。rightOperandReferenceは、IRIを最初に逆参照することによりrightOperandの値を取得しなければならない(MUST)場合に用いられます。rightOperandまたはrightOperandReferenceのうちの1つのみが制約に出現しなければなりません(MUST)。
rightOperandは値を表し、rightOperandReferenceは、その値を取得するために逆参照しなければならないIRIを表します。rightOperandがhttp://example.com/c100であった場合、それは、式で比較される値として解釈されます。rightOperandReferenceがhttp://example.com/c100の同じ値であった場合、最初にそのIRIを逆参照しなければならず、返されるデータを、式で比較される値として解釈しなければなりません。
dataTypeは、xsd:decimalやxsd:datetimeなどのrightOperand/Referenceの型を示し、unitは、「EU通貨」などのrightOperand/Referenceの単位の値を示します。
statusは、比較式で用いなければならない(MUST)leftOperand行為から生成された値を提供します。例えば、count制約は、10というrightOperand値、5というstatusを持つことができます。これは、行為が既に5回行われ、比較により現在の行為とステータス値を比較しなければならないことを意味します。
論理制約(Logical Constraint)クラスは、既存の制約である2つ以上のオペランドを1つの論理演算子で比較する式に用いられます。比較によって論理的一致が返された場合は論理制約が満たされ、そうでない場合は満たされません。例えば、3つの制約に論理積を行うことができ、論理制約が満たされるためには3つすべてが真でなければならないことを示します。
論理制約クラスには次のプロパティーがあります。
uidプロパティー値を持つことができます(MAY)。operandサブプロパティーがなければなりません(MUST)。その値は既存の制約インスタンスのリストです。ODRL評価システムは、operandの次のサブプロパティーをサポートしなければなりません(MUST)。
or(和) - 少なくとも1つの制約が満たされてなければなりません(MUST)。xone(排他的1) - 制約のうち1つのみ(2以上でない)が満たされていなければなりません(MUST)。and(積) - すべての制約が満たされていなければなりません(MUST)。andSequence(順次積) - すべての制約が - 順番に- 満たされていなければなりません(MUST)。追加のoperandサブプロパティーは、ODRLプロファイルで定義できます(MAY)。
論理制約のODRL検証要件には次が含まれます。
operandは、or、xone、and、andSequenceというサブプロパティーのみでなければなりません(MUST)。operandの追加のサブプロパティーは、論理制約の使用のためだけに、ODRLプロファイで定義できます(MAY)。制約インスタンスを評価し、その結果によって、(operandサブプロパティーのセマンティクスに基づいて)論理関係が満たされているかどうかを判定しなければなりません(MUST)。
andSequenceなどの、順番に評価する必要がある論理オペランドを用いる場合、シリアル化は、リストのメンバーの順序を保持しなければなりません(MUST)。JSON-LDでは、@listキーワードを用いて順序付きコレクションを表さなければなりません(MUST)。
規則(許可、禁止、義務など)には、規則の条件を示すために、constraint(制約)プロパティーを含むことができます(MAY)。この条件を満たすためには、constraintプロパティーにより参照されているすべての制約/論理制約が満たされなければなりません(MUST)。
ユースケースの例: 下記の方針の提案の例では、許可によりターゲット資産を
distribute(配信する)ことが許されており、その許可は2018-01-01までしか行使できないというdateTime条件の制約が含まれています。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:6163",
"profile": "http://example.com/odrl:profile:10",
"permission": [{
"target": "http://example.com/document:1234",
"assigner": "http://example.com/org:616",
"action": "distribute",
"constraint": [{
"leftOperand": "dateTime",
"operator": "lt",
"rightOperand": { "@value": "2018-01-01", "@type": "xsd:date" }
}]
}]
}
行為には、行為の操作のセマンティクスを直接限定する制約/論理制約を示すために、refinement(精緻化)プロパティーを含むことができます(MAY)。行為のより限定的なセマンティクスというこの条件を満たすためには、満足状態を生成する際に、refinementプロパティーにより参照されているすべての制約/論理制約を用いなければなりません(MUST)。
注: 行為に精緻化を適用した結果は、ヌル(null)の操作になるべきではありません(SHOULD NOT)。
ユースケースの例: 下記の方針の提案の例では、許可によりターゲット資産を
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:6161",
"profile": "http://example.com/odrl:profile:10",
"permission": [{
"target": "http://example.com/document:1234",
"assigner": "http://example.com/org:616",
"action": [{
"rdf:value": { "@id": "odrl:print" },
"refinement": [{
"leftOperand": "resolution",
"operator": "lteq",
"rightOperand": { "@value": "1200", "@type": "xsd:integer" },
"unit": "http://dbpedia.org/resource/Dots_per_inch"
}]
}]
}]
}
ユースケースの例: 下記の方針は、ターゲット資産を、オンライン・メディアまたは印刷メディアのいずれかにより複製できるけれども、両方はできないという許可を表します。これは、他の場所で宣言されている2つの既存の制約を参照した論理制約(
xoneオペランドによる)として表されています。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:88",
"profile": "http://example.com/odrl:profile:10",
"permission": [{
"target": "http://example.com/book/1999",
"assigner": "http://example.com/org/paisley-park",
"action": [{
"rdf:value": { "@id": "odrl:reproduce" },
"refinement": {
"xone": {
"@list": [
{ "@id": "http://example.com/p:88/C1" },
{ "@id": "http://example.com/p:88/C2" }
]
}
}
}]
}]
}
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Constraint",
"uid": "http://example.com/p:88/C1",
"leftOperand": "media",
"operator": "eq",
"rightOperand": { "@value": "online", "@type": "xsd:string" }
}
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Constraint",
"uid": "http://example.com/p:88/C2",
"leftOperand": "media",
"operator": "eq",
"rightOperand": { "@value": "print", "@type": "xsd:string" }
}
行為にrefinementプロパティーを用いる場合、名前空間識別子(例えば、odrl)を用いなければならない(MUST)行為のインスタンスであることを表すためにrdf:valueプロパティーを用い、それが@idキーであると言明します。さらに、制約インスタンスの識別子(論理制約オペランドに対する)は、それらを@idキーとして言明しなければならなりません。
AssetCollectionには、完全なコレクションの個々の資産を識別する精緻化のコンテキストを示すために、refinement(精緻化)プロパティーを含むことができます(MAY)。refinementプロパティーは、コレクションの個々のメンバー(資源全体ではない)の特性に適用されます。完全なAssetCollectionの個々の資産を識別するというこの条件を満たすためには、refinementプロパティーにより参照されているすべての制約/論理制約が満たされなければなりません(MUST)。
注: 資産コレクションに精緻化を適用した結果は、ヌル(null)の集合になるべきではありません(SHOULD NOT)。
refinementプロパティーを用いる場合、AssetCollectionを識別するために、uidプロパティーを用いてはならない(MUST NOT)ことに注意してください。代わりに、sourceプロパティーを用いてAssetCollectionを参照しなければなりません(MUST)。
ユースケースの例: この方針は、マルチメディア動画の資産コレクションであるターゲット情報源
http://example.com/media-catalogueを定義しています。ターゲットには資産コレクションのメンバーの特性を規定する精緻化も含まれています。このケースでは、資産のターゲット・サブセットは、実行時間が60分未満のものであり、それぞれが再生される可能性があります。runningTimeが、playの行為とともにODRLプロファイルhttp://example.com/odrl:profile:11で定義されていることに注意してください。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:4444",
"profile": "http://example.com/odrl:profile:11",
"permission": [{
"assigner": "http://example.com/org88",
"target": {
"@type": "AssetCollection",
"source": "http://example.com/media-catalogue",
"refinement": [{
"leftOperand": "runningTime",
"operator": "lt",
"rightOperand": { "@value": "60", "@type": "xsd:integer" },
"unit": "http://qudt.org/vocab/unit/MinuteTime"
}]
},
"action": "play"
}]
}
PartyCollectionには、完全なコレクションの個々の当事者を識別する精緻化のコンテキストを示すために、refinement(精緻化)プロパティーを含むことができます(MAY)。refinementプロパティーは、コレクションの個々のメンバー(資源全体ではない)の特性に適用されます。完全なPartyCollectionの個々の当事者を識別するというこの条件を満たすためには、refinementプロパティーにより参照されているすべての制約/論理制約が満たされなければなりません(MUST)。
注: 当事者コレクションに精緻化を適用した結果は、ヌル(null)の集合になるべきではありません(SHOULD NOT)。
refinementプロパティーを用いる場合、PartyCollectionを識別するために、uidプロパティーを用いてはならない(MUST NOT)ことに注意してください。代わりに、sourceプロパティーを用いてPartyCollectionを参照しなければなりません(MUST)。
ユースケースの例: このターゲット資産
http://example.com/myPhotos:BdayPartyは、写真の譲渡人http://example.com/user44によりソーシャル・ネットワークのサイトに投稿された写真の集合です。譲受人の情報源は、当事者コレクションhttp://example.com/user44/friendsであり、譲渡人のすべての友人を表します。譲受人は、foaf:ageが18歳以上のコレクションのメンバーのみに、ex:view(表示)の許可(プロファイルで定義されている)が与えられることを示す精緻化も持っています。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Agreement",
"uid": "http://example.com/policy:4444",
"profile": "http://example.com/odrl:profile:12",
"permission": [{
"target": "http://example.com/myPhotos:BdayParty",
"assigner": "http://example.com/user44",
"assignee": {
"@type": "PartyCollection",
"source": "http://example.com/user44/friends",
"refinement": [{
"leftOperand": "foaf:age",
"operator": "gt",
"rightOperand": { "@value": "17", "@type": "xsd:integer" }
}]
},
"action": { "@id": "ex:view" }
}]
}
規則(Rule)クラスは、許可、禁止、義務のクラスの親です。規則クラスは、これらの3つのクラスに共通する特性を表します。規則クラスは、すべてのその他の規則サブクラスと素でなければなりません(MUST)。
規則クラスには次のプロパティーがあります。
actionプロパティー値がなければなりません(MUST)。relationサブプロパティー値を持つことができます(MAY)。functionサブプロパティー値を持つことができます(MAY)。failureサブプロパティー値を持つことができます(MAY)。constraintプロパティー値を持つことができます(MAY)。uidプロパティー値を持つことができます(MAY)。注: 上記のプロパティーのカーディナリティーは、規範的なODRL情報モデルを反映しています。場合によっては、一部のプロパティーの繰り返し出現もサポートされていますが(方針規則の合成とコンパクトな方針で記述しているとおり)、規範的でアトミックな方針は、上記のプロパティーのカーディナリティーと整合性があります。
抽象的なrelation、relation、failureのプロパティーの明示的なサブプロパティーを用いなければならず、その選択は、該当する規則のサブクラスによって異なります。
規則の3つのクラスは、義務の規則との重要な関係も形成します。下記の図でプロパティー関係を要約しています。
許可(Permission)は、すべての制約が満たされ、すべての義務が履行されていれば、すべての精緻化を満たしつつ、資産に対して行為を行うことを許します。
許可クラスは、規則クラスのサブクラスであり、そのすべてのプロパティーを継承し、次の追加のプロパティーのセマンティクスを持っています。
targetプロパティー値がなければなりません(MUST)。(他のrelationサブプロパティーも使用できます(MAY)。)assignerおよび/またはassigneeプロパティー値を持つことができます(MAY)。(他のfunctionサブプロパティーも使用できます(MAY)。)dutyプロパティー値を持つことができます(MAY)。注: 上記のプロパティーのカーディナリティーは、規範的なODRL情報モデルを反映しています。場合によっては、一部のプロパティーの繰り返し出現もサポートされていますが(方針規則の合成とコンパクトな方針で記述しているとおり)、規範的でアトミックな方針は、上記のプロパティーのカーディナリティーと整合性があります。
義務プロパティーは、履行しなければならない(MUST)合意された責務を表します。つまり、義務プロパティーは、許可と義務の間の前提条件を言明します。詳細は、許可と義務の項を参照してください。
ユースケースの例: 譲渡人
http://example.com/org:xyzからの方針のOfferは、ターゲット資産http//example.com/game:9090の再生行為を表し、その許可は2017年末まで有効です。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:9090",
"profile": "http://example.com/odrl:profile:07",
"permission": [{
"target": "http://example.com/game:9090",
"assigner": "http://example.com/org:xyz",
"action": "play",
"constraint": [{
"leftOperand": "dateTime",
"operator": "lteq",
"rightOperand": { "@value": "2017-12-31", "@type": "xsd:date" }
}]
}]
}
禁止(Prohibition)は、すべての制約が満たされていれば、すべての精緻化を満たしつつ、資産に対して行為を行うことを許しません。行われた行為によって禁止が侵害された場合、禁止の状態を侵害されていない状態にするために、すべての救済が履行されなければなりません(MUST)。
禁止クラスは、規則クラスのサブクラスであり、そのすべてのプロパティーを継承し、次の追加のプロパティーのセマンティクスを持っています。
targetプロパティー値がなければなりません(MUST)。(他のrelationサブプロパティーも使用できます(MAY)。)assignerおよび/またはassigneeプロパティー値を持つことができます(MAY)。(他のfunctionサブプロパティーも使用できます(MAY)。)remedyプロパティー値を持つことができます(MAY)。注: 上記のプロパティーのカーディナリティーは、規範的なODRL情報モデルを反映しています。場合によっては、一部のプロパティーの繰り返し出現もサポートされていますが(方針規則の合成とコンパクトな方針で記述しているとおり)、規範的でアトミックな方針は、上記のプロパティーのカーディナリティーと整合性があります。
remedy(救済)プロパティー(failureプロパティーのサブプロパティー)は、禁止が侵害された場合に履行されなければならない(MUST)合意された責務を表します。つまり、救済プロパティーは、禁止の行動が行われた場合に履行されなければならない義務を言明します。詳細は、禁止と救済の項を参照してください。
ユースケースの例: このターゲット資産
http://example.com/photoAlbum:55の譲渡人は、許可および禁止により合意方針を表します。譲渡当事者http://example.com/MyPix:55は、ターゲット資産のdisplay(表示)の許可と同時に、archive(アーカイブ)の禁止を譲受当事者http://example.com/assignee:55に与えます。さらに、方針に任意の衝突(例えば、許可と禁止の間に)がある場合のために、Policyのconflictプロパティーを、許可が優先することを示すpermに設定しています。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Agreement",
"uid": "http://example.com/policy:5555",
"profile": "http://example.com/odrl:profile:08",
"conflict": "perm",
"permission": [{
"target": "http://example.com/photoAlbum:55",
"action": "display",
"assigner": "http://example.com/MyPix:55",
"assignee": "http://example.com/assignee:55"
}],
"prohibition": [{
"target": "http://example.com/photoAlbum:55",
"action": "archive",
"assigner": "http://example.com/MyPix:55",
"assignee": "http://example.com/assignee:55"
}]
}
義務(Duty)は、すべての精緻化を満たしつつ、行為を行う責務です。義務は、すべての制約が満たされ、すべての精緻化を満たしつつ、その行為が行われる場合に履行されます。その行為が行われていない場合は、義務を履行するために、すべてのconsequence(結果)も履行されなければなりません。つまり、結果は、同様に履行しなければならない追加の義務です。(注：義務または責務のプロパティーにより参照されている義務のみが、結果プロパティーを使用できます。)
義務クラスは、規則クラスのサブクラスであり、そのすべてのプロパティーを継承し、次の追加のプロパティーのセマンティクスを持っています。
targetプロパティー値を持つことができます(MAY)。(他のrelationサブプロパティーも使用できます(MAY)。)assignerおよび/またはassigneeプロパティー値を持つことができます(MAY)。(他のfunctionサブプロパティーも使用できます(MAY)。)consequenceプロパティー値を持つことができます(MAY)。注: 上記のプロパティーのカーディナリティーは、規範的なODRL情報モデルを反映しています。場合によっては、一部のプロパティーの繰り返し出現もサポートされていますが(方針規則の合成とコンパクトな方針で記述しているとおり)、規範的でアトミックな方針は、上記のプロパティーのカーディナリティーと整合性があります。
義務クラスにはこれらの追加要件もあります。
consequenceプロパティー(failureプロパティーのサブプロパティー)は、許可に対する合意された方針の責務または義務が履行されなかった場合の影響を表すために用います。これらのいずれかが履行されなかった場合、その結果の義務が新たな要件にもなり、元の責務または義務ならびに結果の義務をすべて履行しなければならない(MUST)ことになります。
場合によっては、元の義務/責務に対する一部の制約および/または精緻化を満たせなくなった場合には、結果を生じさせた元の義務/責務を履行するために、それらを緩和する必要があるかもしれません(MAY)。
例えば、指定期日までにデータを提供するという責務が履行されなければ、$100の罰金という結果を支払うことも可能性です。しかし、日付が過ぎてしまえば、元の義務は技術的に履行できなくなります(日付の制約を満たせないため)。
そのような場合のために、ODRLの実装では、結果が生じた後に元の義務/責務を満たすことができる方法を提供すべきです(SHOULD)。
結果のプロパティーは、既に許可の義務または方針の責務の結果である義務に用いてはならない(MUST NOT)ことに注意してください。
方針には、義務を履行する責務(obligation)を含むことができます(MAY)。責務は、すべての制約が満たされ、すべての精緻化を満たしつつ、その行為が行われる場合に履行されます。
ユースケースの例: 下記の合意には、譲渡人にEU500.00の支払金額を補償するという、譲渡人
http://example.com/org:43から譲受人http://example.com/person:44に対する責務が含まれています。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Agreement",
"uid": "http://example.com/policy:42",
"profile": "http://example.com/odrl:profile:09",
"obligation": [{
"assigner": "http://example.com/org:43",
"assignee": "http://example.com/person:44",
"action": [{
"rdf:value": {
"@id": "odrl:compensate"
},
"refinement": [
{
"leftOperand": "payAmount",
"operator": "eq",
"rightOperand": { "@value": "500.00", "@type": "xsd:decimal" },
"unit": "http://dbpedia.org/resource/Euro"
}]
}]
}]
}
方針には、責務を履行しなかった結果も含むことができます(MAY)。
ユースケースの例: 下記の合意には、ターゲット資産を削除するという、譲渡人
http://example.com/org:43から譲受人http://example.com/person:44に対する責務が含まれています。責務が履行されなければ、譲渡人は、EU10.00の支払を伴う指定された慈善活動の補償も(責務の義務の履行も)行わなければならない(MUST)という結果となります。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Agreement",
"uid": "http://example.com/policy:42B",
"profile": "http://example.com/odrl:profile:09",
"assigner": "http://example.com/org:43",
"assignee": "http://example.com/person:44",
"obligation": [{
"action": "delete",
"target": "http://example.com/document:XZY",
"consequence": [{
"action": [{
"rdf:value": { "@id": "odrl:compensate" },
"refinement": [{
"leftOperand": "payAmount",
"operator": "eq",
"rightOperand": { "@value": "10.00", "@type": "xsd:decimal" },
"unit": "http://dbpedia.org/resource/Euro"
}]
}],
"compensatedParty": "http://wwf.org"
}]
}]
}
義務(Duty)は、許可から義務までの義務プロパティー関係を用いて履行を要求する前提条件として指定できます(MAY)。
許可にいくつかの義務がある場合、すべての義務の履行が合意されなければなりません(MUST)。くつかの許可が同じ義務を参照(uidプロパティーにより)している場合、義務は1回だけ履行されなければなりません。
義務でfunctionサブプロパティーが宣言されていない場合、その機能的役割は、参照している許可で宣言されたものと同じです。
ユースケースの例: 当事者
http://example.com/assigner:sonyは、ターゲット資源http://example.com/music/1999.mp3を再生する提案を行います。許可には、$EU5.00のpayAmountという精緻化を含むcompensate(補償)行為の義務が含まれています。義務には、eventはpolicyUsageよりも小さいという制約も含まれています。つまり、許可の規則を行う前に義務の規則（つまり、補償)を行わなければなりません。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:88",
"profile": "http://example.com/odrl:profile:09",
"permission": [{
"assigner": "http://example.com/assigner:sony",
"target": "http://example.com/music/1999.mp3",
"action": "play",
"duty": [{
"action": [{
"rdf:value": { "@id": "odrl:compensate" },
"refinement": [{
"leftOperand": "payAmount",
"operator": "eq",
"rightOperand": { "@value": "5.00", "@type": "xsd:decimal" },
"unit": "http://dbpedia.org/resource/Euro"
}]
}],
"constraint": [{
"leftOperand": "event",
"operator": "lt",
"rightOperand": { "@id": "odrl:policyUsage" }
}]
}]
}]
}
許可の義務、および方針の責務には、その義務や責務を履行しなかったconsequence(結果)の義務を含むことができます(MAY)。このケースでは、許可/責務義務の最終状態が履行済みとなるためには、すべての結果義務も履行済みにならなければなりません(MUST)。
consequenceプロパティーは、failureプロパティーのサブプロパティーです。結果プロパティーに関する詳細は、義務クラスの項を参照してください。
ユースケースの例: 下記の譲渡人
http://example.com/org:99と譲受人http://example.com/person:88の間の合意により、資産を当事者http://australia.gov.au/に帰属させるという前提条件の下で、譲受人は資産http://example.com/data:77を配信できるようになります。譲受人が義務を履行しなかったり、義務を履行せずに資産を配信した場合、http://example.com/dept:100にも追跡されることになるでしょう。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Agreement",
"uid": "http://example.com/policy:66",
"profile": "http://example.com/odrl:profile:09",
"permission": [{
"target": "http://example.com/data:77",
"assigner": "http://example.com/org:99",
"assignee": "http://example.com/person:88",
"action": "distribute",
"duty": [{
"action": "attribute",
"attributedParty": "http://australia.gov.au/",
"consequence": [{
"action": "acceptTracking",
"trackingParty": "http://example.com/dept:100"
}]
}]
}]
}
remedy(救済)プロパティーは、行使によって禁止が侵害された場合に履行しなければならない(MUST)合意された義務を表します。禁止行動が行われた場合、禁止の侵害に対処し、侵害されていない状態にするために、すべての救済義務が履行されなければなりません(MUST)。remedyプロパティーは、failureプロパティーのサブプロパティーです。
救済は、結果の義務が含まれている義務を参照してはなりません(MUST NOT)。
ユースケースの例: 下記の譲渡人
http://example.com/person:88と譲受人http://example.com/org:99の間の合意では、譲受人が資産http://example.com/data:77をインデキシングすることが禁止されています。譲受人が実際にターゲット資産をインデキシングした場合には、ターゲット資産http://example.com/data:77を匿名化しなければならない(MUST)という救済になるでしょう。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Agreement",
"uid": "http://example.com/policy:33CC",
"profile": "http://example.com/odrl:profile:09",
"prohibition": [{
"target": "http://example.com/data:77",
"assigner": "http://example.com/person:88",
"assignee": "http://example.com/org:99",
"action": "index",
"remedy": [{
"action": "anonymize",
"target": "http://example.com/data:77"
}]
}]
}
ODRL情報モデルは、規則に対するプロパティー関係の規範的なカーディナリティーを提供します。コア・レベルでは、ODRL規則は、1つの資産、1つ以上の当事者の機能的役割、1つの行為(そして、潜在的に、制約および/または義務)に関連付けられるでしょう。
方針規則の合成により、複数の資産、当事者、行為に関連する規則をサポートするために、個々の規則でODRL情報モデルのカーディナリティー要件を拡張できます。その目的は、共通するプロパティーを(1つの規則に)組み合わせて、より複合的な方針を表すことです。その後に、方針を処理して規範的でアトミックな相当物にすべきです(SHOULD)。
下記の例は、削減できない規則である(つまり、分解したり、それ以上簡素化できない)アトミックなレベルの方針を示します。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Policy",
"uid": "http://example.com/policy:7777",
"profile": "http://example.com/odrl:profile:20",
"permission": [{
"target": "http://example.com/music/1999.mp3",
"assigner": "http://example.com/org/sony-music",
"action": "play"
}]
}
下記の方針の例では、同じ許可の規則に2つのターゲット資産と2つの行為が含まれています。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Policy",
"uid": "http://example.com/policy:8888",
"profile": "http://example.com/odrl:profile:20",
"permission": [{
"target": [ "http://example.com/music/1999.mp3",
"http://example.com/music/PurpleRain.mp3" ],
"assigner": "http://example.com/org/sony-music",
"action": [ "play", "stream" ]
}]
}
そして、上記の例は、4つのアトミックな許可の規則に分解できます。許可の規則にはそれぞれ1つのターゲットと1つの行為が含まれています。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Policy",
"uid": "http://example.com/policy:8888",
"profile": "http://example.com/odrl:profile:20",
"permission": [{
"target": "http://example.com/music/1999.mp3",
"assigner": "http://example.com/org/sony-music",
"action": "play"
},
{
"target": "http://example.com/music/1999.mp3",
"assigner": "http://example.com/org/sony-music",
"action": "stream"
},
{
"target": "http://example.com/music/PurpleRain.mp3",
"assigner": "http://example.com/org/sony-music",
"action": "play"
},
{
"target": "http://example.com/music/PurpleRain.mp3",
"assigner": "http://example.com/org/sony-music",
"action": "stream"
}]
}
方針でアトミックな規則を作成するために、複数の資産、当事者、行為が含まれている規則のODRL検証要件には次が含まれます。
ODRL方針には、方針レベルで宣言された、その規則のすべてに共通するプロパティーを保持できます(MAY)。これは、よりコンパクトなシリアル化をサポートするための省略化方式となることのみを目的としています。これらの共通プロパティーを、(方針クラスの項で定義しているような)方針レベルのプロパティーと解釈してはなりません(MUST NOT)。
(下記の図で示しているとおり)共有できる(MAY)プロパティーには次のものが含まれます。
actionプロパティーrelationの1つまたは多くのサブプロパティー(targetなど)functionの1つまたは多くのサブプロパティー(assignerやassigneeなど)
方針の省略形を拡張するためのODRL検証要件は次のとおりです。
さらに、ODRL検証要件に従って、方針にアトミックな規則を作成します(前項で定義しているとおり)。
適合性のための処理を行う際には、コンパクトなODRL方針をアトミックな方針に拡張することが推奨されます(RECOMMENDED)。
下記の例は、そのような方針に適用される共通プロパティーを示しています。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Policy",
"uid": "http://example.com/policy:8888",
"profile": "http://example.com/odrl:profile:21",
"target": "http://example.com/music/1999.mp3",
"assigner": "http://example.com/org/sony-music",
"action": "play",
"permission": [{
"assignee": "http://example.com/people/billie"
},
{
"assignee": "http://example.com/people/murphy"
}]
}
下記の例は、これらの共通プロパティーを上記のODRL検証要件に従った方針の許可に拡張する方法を示しています。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Policy",
"uid": "http://example.com/policy:8888",
"profile": "http://example.com/odrl:profile:21",
"permission": [{
"assignee": "http://example.com/people/billie",
"target": "http://example.com/music/1999.mp3",
"assigner": "http://example.com/org/sony-music",
"action": "play"
},
{
"assignee": "http://example.com/people/murphy",
"target": "http://example.com/music/1999.mp3",
"assigner": "http://example.com/org/sony-music",
"action": "play",
}]
}
さらなる信頼性と完全性の目的をサポートするために、外部の語彙から追加のメタデータ・プロパティーを方針に追加できます(MAY)。ODRL情報モデルでは、ODRL方針にダブリン・コア・メタデータ用語[dcterms]の使用を推奨します。
次のダブリン・コア・メタデータ用語[dcterms]プロパティーを用いるべきです(SHOULD)。
dc:creatorプロパティー値 - 方針を作成した個人、エージェント、または組織dc:descriptionプロパティー値 - 人間が読める方針の表現または要約dc:issuedプロパティー値 - 方針が最初に発行された日付(および時間)dc:modifiedプロパティー値 - 方針が変更された日付(および時間)dc:coverageプロパティー値 - 方針が関係している管轄区dc:replacesプロパティー値 - この方針の方が優先する方針の識別子dc:isReplacedByプロパティー値 - この方針よりも優先される方針の識別子上記のメタデータ・プロパティーを持つ方針のODRL検証要件には次が含まれます。
dc:isReplacedByプロパティーがある場合、プロセッサは最初の方針を無効とみなさねばならず(MUST)、識別された方針を取得し処理しなければなりません(MUST)。ユースケースの例: 下記の例は、方針の作成者、内容記述、方針の発行日、方針が適用される管轄区(オーストラリアのクイーンズランドの識別子)、それが置き換える古いバージョンの方針の識別子を示すメタデータ・プロパティーを示しています。
{
"@context": [
"http://www.w3.org/ns/odrl.jsonld",
{ "dc": "http://purl.org/dc/terms/" }
],
"@type": "Policy",
"uid": "http://example.com/policy:8888",
"profile": "http://example.com/odrl:profile:22",
"dc:creator": "Billie Enterprises LLC",
"dc:description": "This policy covers...",
"dc:issued": "2017-01-01T12:00",
"dc:coverage": { "@id": "https://www.iso.org/obp/ui/#iso:code:3166:AU-QLD" },
"dc:replaces": { "@id": "http://example.com/policy:8887" },
"permission": [ { } ]
}
注: ダブリン・コア・メタデータ・プロパティーで用いられる文字列値は、正規化されていない可能性があり、方針メタデータの比較向けに設計されていません。
ODRLは、(子の)方針が1つ以上の(親の)方針のすべてのアトミックな規則を継承できる継承メカニズムをサポートしています。inheritFromプロパティーは、親の方針から継承する子の方針で用いなければならず(MUST)、親の方針の複数の識別子を含むことができます(MAY)。
継承を用いる場合、次が適用されます。
status情報は、親の方針から子の方針に移転されません。つまり、親の方針に値を持つstatusプロパティーが含まれている場合、これらの値はヌル(null)になるでしょう。ユースケースの例: 下記の(親の)方針
http://example.com/policy:defaultを見てみましょう。これには、(方針レベルの)譲渡人とターゲット資産の方針ドキュメントをレビューする責務が含まれます。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Policy",
"uid": "http://example.com/policy:default",
"profile": "http://example.com/odrl:profile:30",
"assigner": "http://example.com/org-01",
"obligation": [{
"target": "http://example.com/asset:terms-and-conditions",
"action": "reviewPolicy"
}]
}
下記の子のAgreement方針http://example.com/policy:4444は、親の方針http://example.com/policy:default(上記)に向けたinheritFromプロパティーを示します。子の方針は、ターゲット資産、(資産を表示する)行為、および合意の譲受当事者を示します。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Agreement",
"uid": "http://example.com/policy:4444",
"profile": "http://example.com/odrl:profile:30",
"inheritFrom": "http://example.com/policy:default",
"assignee": "http://example.com/user:0001",
"permission": [{
"target": "http://example.com/asset:5555",
"action": "display"
}]
}
継承が行われた後の - 親の方針規則と方針レベルのプロパティーが子の方針に追加され、かつ、規則がアトミックになった場合 - その結果の方針を下記に示します。元の子の許可の規則には、親の方針の(方針レベルの)譲受人が含まれました。親の責務の規則は、更新された子の方針に、元の子の(方針レベルの)譲受人を含んで出現するようになりました。
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Agreement",
"uid": "http://example.com/policy:4444",
"profile": "http://example.com/odrl:profile:30",
"inheritFrom": "http://example.com/policy:default",
"permission": [{
"target": "http://example.com/asset:5555",
"action": "display",
"assigner": "http://example.com/org-01",
"assignee": "http://example.com/user:0001"
}],
"obligation": [{
"target": "http://example.com/asset:terms-and-conditions",
"action": "reviewPolicy",
"assigner": "http://example.com/org-01",
"assignee": "http://example.com/user:0001"
}]
}
ODRL方針継承のODRL検証要件には次が含まれます。
conflict(衝突)プロパティーは、方針の統合に起因する衝突または同じ方針の許可と禁止の間の衝突を解決するための対策を確立するために用います。衝突は、方針の継承の結果として方針を統合した結果の規則に矛盾がある場合に生じる可能性があります。
conflictプロパティーは、次の衝突対策プレファレンスの値(ConflictTermクラスのインスタンス)のうちの1つを取るべきです(SHOULD)。
perm: 許可は禁止を無効にしなければならない(MUST)。prohibit: 禁止は許可を無効にしなければならない(MUST)。invalid: 何かの衝突が検出された場合、方針全体が無効にならなければならない(MUST)。conflictプロパティーが明示的に設定されていない場合は、invalidというデフォルトが用いられるでしょう。
追加のconflictプロパティー値は、ODRLプロファイルで定義できます(MAY)。
衝突対策要件には次が含まれます。
permというconflictプロパティーが含まれている場合、衝突している許可の規則により、禁止の規則が無効にならなければなりません(MUST)。prohibitというconflictプロパティーが含まれている場合、衝突している禁止の規則により、許可の規則が無効にならなければなりません(MUST)。invalidというconflictプロパティーが含まれている場合、衝突している規則により、方針全体が無効にならなければなりません(MUST)。conflictプロパティー値があり(例えば、方針の統合または継承の後に)、衝突している規則がある場合、方針全体が無効にならなければなりません(MUST)。ユースケースの例: 2つの方針が同じターゲット資産
http://example.com/asset:1212に関連付けられています。最初の方針http://example.com/policy:0001は、資産のuse(利用)を認めています。2番目の方針http://example.com/policy:0002は、資産の表示を認めていますが、conflictプロパティーをpermに設定することにより、衝突の処理方法を明示的に述べています。したがって、許可は常にあらゆる禁止を無効にします。このユースケースでは、useの行為を特殊化したものであるため、衝突がありえます。しかし、permという衝突対策は、useの許可が
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Policy",
"uid": "http://example.com/policy:0001",
"profile": "http://example.com/odrl:profile:40",
"conflict": "perm",
"permission": [{
"target": "http://example.com/asset:1212",
"action": "use",
"assigner": "http://example.com/owner:181"
}]
}
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Policy",
"uid": "http://example.com/policy:0002",
"profile": "http://example.com/odrl:profile:40",
"conflict": "perm",
"permission": [{
"target": "http://example.com/asset:1212",
"action": "display",
"assigner": "http://example.com/owner:182"
}],
"prohibition": [{
"target": "http://example.com/asset:1212",
"action": "print"
}]
}
上記のユースケースでは、2番目の方針にprohibitという衝突の値があれば、その結果は直接的な矛盾であり、結果として無効な方針になるでしょう。
ODRL情報モデルは、方針を表すためのコアとなる枠組みおよび語彙として機能します。ODRLコア語彙[odrl-vocab]は、この語彙用語の集合を明確に示します。ODRL方針は、ODRLコア語彙を用いて表現でき、これは、最小限にサポートされた方針表現を表します。
追加のセマンティクスを必要とするODRL方針で使用できる語彙用語を提供するためには(ODRLプロファイルのメカニズムの項で詳述しているとおり)、ODRLプロファイルを定義しなければなりません(MUST)。ODRLプロファイルは、ODRL方針表現でサポートする必要がある語彙用語を指定することにより、コミュニティのニーズに明確に対応します。これらの用語は、明示的に定義するか、ODRL共通語彙を採用することができます。
ODRL共通語彙[odrl-vocab]は、許可、禁止、義務に加え、方針のサブクラス、制約の左オペランドと演算子、資産関係、当事者の機能に関する汎用的な範囲の共通の行為を提供します。
ODRL方針がODRLプロファイルに準拠するには、profileプロパティーを指定してODRLプロファイルの識別子(IRI)を示さなければなりません(MUST)。ODRL方針が複数のODRLプロファイルに準拠していることを示すために複数の識別子が存在しても構いません(MAY)。
ODRL方針でODRLプロファイルが用いられている場合、ODRL処理システムは、識別されたODRLプロファイルのセマンティクスを理解しなければなりません(MUST)。ODRL処理システムがODRLプロファイル識別子を認識しない場合、方針の処理を停止しなければなりません(MUST)。
ODRLプロファイルを作成するために、ODRLコア語彙クラス、プロパティー、およびインスタンスへの直接的な拡張は、次の方法で定義されます。
| ODRLプロファイルの定義 | 例 |
|---|---|
| 追加の方針サブクラス: ODRL方針クラスのサブクラスを作成し、他のすべての方針サブクラス(集合を除く)と素であると定義します。 |
ex:myPolicyType rdfs:subClassOf odrl:Policy .owl:disjointWith :Agreement :Offer, :Privacy, :Request, :Ticket, :Assertion . |
| 追加の資産関係: 抽象的な関係プロパティーのサブプロパティーを作成します。 |
ex:myRelation rdfs:subPropertyOf odrl:relation . |
| 追加の当事者の機能的役割: 抽象的な機能プロパティーのサブプロパティーを作成します。 |
ex:myFunctionRole rdfs:subPropertyOf odrl:function . |
| 規則に対する追加の行為: 行為のインスタンスを作成し、そのincludedInの親の行為を定義します。 新しい行為は、既存の行為に対してincludedInであると定義できます(MAY)。 新しい行為が別の新しい行為または既存の行為との依存関係を形成する場合は、impliesプロパティーを持つ2つの行為を定義します。 |
ex:myAction a odrl:Action .ex:myAction odrl:includedIn odrl:use .ex:myAction odrl:implies odrl:distribute . |
| 追加の制約左オペランド: 左オペランド・クラスのインスタンスを作成します。 |
ex:myLeftOperand a odrl:LeftOperand . |
| 追加の制約右オペランド: 右オペランド・クラスのインスタンスを作成します。 |
ex:myRightOperand a odrl:RightOperand . |
| 追加の制約関係演算子: 演算子クラスのインスタンスを作成します。 |
ex:myOperator a odrl:Operator . |
| 追加の論理制約オペランド: 抽象的なオペランド・プロパティーのサブプロパティーを作成します。 |
ex:myLogicalOp rdfs:subPropertyOf odrl:operand . |
| 追加の方針衝突時の対策: ConflictTermクラスのインスタンスを作成します。 |
ex:myStrategy a odrl:ConflictTerm . |
| 追加の規則クラス: 規則クラスのサブクラスを作成し、他のすべての規則サブクラスと素であると定義します。 |
ex:myRule rdfs:subClassOf odrl:Rule ;owl:disjointWith odrl:Prohibition, odrl:Duty, odrl:Permission . |
すべての新しいクラス(rdfs:Class、owl:Class)、プロパティー(rdf:Property、owl:ObjectProperty)、インスタンス(owl:NamedIndividual)は、skos:Conceptとしても定義しなければなりません。クラスには、適切なrdfs:domainとrdfs:rangeも定義すべきです。
名前にrdfs:labelを、形式的な定義にskos:definitionを、利用に関する追加コメントにskos:noteを用いた、新しい用語ごとの人間が読める文書も推薦されます。
ODRLコア・プロファイルを識別する必要がある状況、つまり、方針がODRLコア語彙にのみ準拠している状況では、次の識別子をコア・プロファイルを使用できます(MAY): http://www.w3.org/ns/odrl/2/core
この項は非規範的です。
ODRL情報モデルは、当事者に関するデータを含んでいる資産の存在の識別情報などの機密の個人情報を直接表しません。しかし、ODRL語彙(ODRL共通語彙[odrl-vocab]やODRLプロファイルなど)は、個人情報と関連しえる用語を定義することができます。これらの仕様は、そのようなODRL表現を作成または利用する実装に、方針がどのような方法で用いられているか、その方針が他のどのような当事者と共有されているか、方針が他の当事者と共有されている理由をすべての関連するユーザに伝えるための措置を取ることを知らせるべきです。
POEワーキンググループは、ODRLコミュニティ・グループおよび以前のODRLイニシアチブの貢献に謝意を表します。特に、編集者は、過去の編集上の貢献に対し、Susanne Guth、Daniel Paehler、Andreas KastenAndreas Kastenに謝意を表します。
この仕様を勧告案に進めるためには、下記の各機能の少なくとも2つの独立した実装がなければなりません。各機能は、異なる製品に実装でき、1つの製品がすべての機能を実装するという要件はありません。
機能終了基準を評価する目的で、下記を機能とみまします。
特定の機能の有無によってその動作を変更しないソフトウェアは、勧告候補段階を終了する目的でその機能を実装しているとはみなされません。
Permissions & Obligations Expressionワーキンググループの成果物の基礎はW3C ODRLコミュニティ・グループが作成したリポートです。ODRLコミュニティ・グループは、コンテンツ提供の公開、配信、利用に関する資産の利用方法の革新的な表現をサポートするために、一連の仕様を開発しました。ODRLコミュニティ・グループの最終的なアウトプットは、ODRLの主要な更新であり、元のODRLバージョン1.1[odrl](W3Cノートとして公開された)に取って代ったODRLバージョン2.1の仕様でした。
下記のドキュメントは、ODRLコミュニティ・グループ報告シリーズの一部です。
ODRL情報モデルはODRL V2.1コア・モデル・コミュニティ・グループ報告から派生したものです。W3Cワーキンググループの成果物とODRLコミュニティ・グループ報告の違いに関する詳細は、付録に記載しています。すべての新しいODRL実装では、Permissions & Obligations Expressionワーキンググループの成果物を用いることが期待されています。
2016年7月21日の最初の公開草案からの変更:
2017年2月23日の草案からの変更:
2017年9月26日の勧告候補からの変更:
2018年1月4日の勧告案からの変更: