A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://www.asahi-net.or.jp/~ax2s-kmtn/internet/rights/REC-odrl-model-20180215.html below:

ODRLæƒ…å ±ãƒ¢ãƒ‡ãƒ«2.2

【注意】 このドキュメントは、W3CのODRL Information Model 2.2 W3C Recommendation 15 February 2018の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。

訳注： Policy、Rule等、頭文字が大文字になっている語句が本文中に多く出現しますが、基本的にそれらは大文字・小文字を区別せずに訳しました。また、一般的にobligationとdutyは「義務」と訳されますが、ここでは便宜的に、前者を「責務」、後者を「義務」と訳し分けました。

First Update: 2018年2月20日

要約

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プロセス・ドキュメントによって管理されています。

目次
  1. 1. はじめに
    1. 1.1 モデルの目的
    2. 1.2 適合性
    3. 1.3 用語
  2. 2. ODRL情報モデル
    1. 2.1 方針クラス
      1. 2.1.1 集合クラス
      2. 2.1.2 提案クラス
      3. 2.1.3 合意クラス
    2. 2.2 資産クラス
      1. 2.2.1 関係プロパティー
      2. 2.2.2 ～の部分プロパティー
      3. 2.2.3 ターゲット方針プロパティー
    3. 2.3 当事者クラス
      1. 2.3.1 機能プロパティー
      2. 2.3.2 ～の部分プロパティー
      3. 2.3.3 譲渡方針プロパティー
    4. 2.4 行為クラス
    5. 2.5 制約
      1. 2.5.1 制約クラス
      2. 2.5.2 論理制約クラス
      3. 2.5.3 規則と制約プロパティー
      4. 2.5.4 行為と精緻化プロパティー
      5. 2.5.5 資産コレクションと精緻化プロパティー
      6. 2.5.6 当事者コレクションと精緻化プロパティー
    6. 2.6 規則クラス
      1. 2.6.1 許可クラス
      2. 2.6.2 禁止クラス
      3. 2.6.3 義務クラス
      4. 2.6.4 方針と責務プロパティー
      5. 2.6.5 許可と義務プロパティー
      6. 2.6.6 許可/責務義務と結果プロパティー
      7. 2.6.7 禁止と救済プロパティー
    7. 2.7 方針規則の合成
      1. 2.7.1 コンパクトな方針
    8. 2.8 方針メタデータ
    9. 2.9 方針の継承
    10. 2.10 方針衝突時の対策
  3. 3. ODRLプロファイル
    1. 3.1 ODRLプロファイルの目的
    2. 3.2 ODRLプロファイルの適合性
    3. 3.3 ODRLプロファイルのメカニズム
    4. 3.4 ODRLコア・プロファイル
  4. 4. プライバシーに関する留意点
  5. A. 謝辞
  6. B. 勧告候補終了基準
  7. C. W3C ODRLコミュニティ・グループ報告との関係
  8. D. 旧バージョンからの変更
  9. E. 参考文献
    1. E.1 規範的な参考文献
    2. E.2 参考情報の参考文献
1. はじめに

この項は非規範的です。

一部のビジネス・シナリオでは、資源に関してどのような行為が許可・禁止されているかを表す必要があります。通常、これらの許可/禁止されている行為は、方針という形、つまり、既存の規則またはオーナーが指定した制約に適合するコンテンツの利用および再利用を示す表現で表されます。方針は、追加情報、つまり、その方針の定義を担っているエンティティーは誰で、それに従う必要があるエンティティーは誰なのか、方針で表されている許可、禁止、義務に関連する追加の制約は何なのか、によって充実させることもできます。 これらの概念と関係を表す能力は、コンテンツの製作者にとって重要である(悪用を防止するために何が許可・禁止されているかを明確に述べることができる)とともに、消費者にとっても重要です(規則、法律やオーナーの制約に違反することを避けるためにどの資源の利用・再利用が認められているかを正確に知ることができる)。この仕様は、これらの方針の概念を表すための一般的な方法を記述しています。

ODRL情報モデルは、コンテンツの利用方法を表す許可、禁止、義務ステートメントの基礎となるセマンティック・モデルを定義します。この情報モデルは、コンテンツ利用ステートメントの基礎モデルを提供する中心的な概念、エンティティー、関係をカバーします。これらの機械可読の方針は、消費者がこの情報を容易に検索できるように、関連するコンテンツと直接リンクさせることができます。

1.1 モデルの目的

ODRL情報モデルの主な目的は、一般的に、許可、禁止、責務のステートメントをコンテンツに関連付けて表すための標準的な記述モデルと形式を提供することです。このステートメントは、資源の利用・再利用の条件を記述するために用いられます。モデルは、複雑なケースを扱う場合であっても、方針のモデル化の容易さを維持しつつ、できる限り多くの許可、禁止、責務のユースケースをカバーすべきです。

ODRL情報モデルは、あらゆる当事者が利用できる、1つの整合性のあるモデルです。ユースケースを満たすためには、既存の標準に適応する必要がある場合や、1つの方法のみの採用に重大なコストが伴う場合を除き、複数の方法よりも、1つの方法の方が強く推奨されます。ODRL情報モデルは、リンクト・データの原則を用いて構築されていますが、非グラフ・ベースの実装を可能とすることを目指して設計されています。

1.2 適合性

非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。この仕様のその他の部分はすべて規範的です。

「することができる／してもよい(MAY)」、「しなければならない(MUST)」、「してはならない(MUST NOT)」、「推奨される(RECOMMENDED)」、「すべきである／する必要がある(SHOULD)」、「すべきでない／する必要がない(SHOULD NOT)」というキーワードは、[RFC2119]で記述されているように解釈されるべきです。

ドキュメント内のすべての例は、[json-ld]としてシリアル化されています。JSONコンテキストを含む規範的なシリアル化に関しては、ODRL語彙および表現[odrl-vocab]を参照してください。

1.3 用語
方針(Policy)
1つ以上の規則の集まり
規則(Rule)
許可、禁止、義務に共通する特徴を表す抽象概念
行為(Action)
資産に対する操作
許可(Permission)
資産に対して行為を行う能力
禁止(Prohibition)
資産に対して行為を行う能力がないこと
義務(Duty)
合意した行為を行う責務
資産(Asset)
規則の対象となる1つの資源または資源のコレクション(集合)
当事者(Party)
規則内の役割を担う1つのエンティティーまたはエンティティーのコレクション(集合)
制約(Constraint)
行為および当事者/資産コレクションまたは規則に適用可能な条件を精緻化するブール/論理式
ODRL検証システム(ODRL Validator)
プロパティーのカーディナリティー、ODRL情報モデルで定義されている値の型と関連付けられているか否か、情報モデルの検証要件を含むODRL方針表現の適合性をチェックするシステム
ODRL評価システム(ODRL Evaluator)
ODRL方針表現の規則が、意図されている行為の実行を満たしているか否かを判断するシステム
ODRLコア語彙(ODRL Core Vocabulary)
ODRL情報モデルにより表される用語の集合
ODRLプロファイル(ODRL Profile)
方針を表すために新しい用語でODRLコア語彙を拡張するコミュニティまたは分野固有の語彙
ODRL共通語彙(ODRL Common Vocabulary)
ODRLプロファイルで再利用できる汎用的な用語の集合
2. ODRL情報モデル

ODRL情報モデルは、資産資源の利用に関連する許可、禁止、義務を表現する方針を表します。情報モデルは、方針によって何が許可され、何が許可されないかのほか、関係するその他の条件、要件、当事者を明示的に表します。ODRL情報モデルの目的は、方針の作成者が、方針に多くの(または、少ない)詳細を含むことができるようにすることで、柔軟な方針表現を可能とすることです。

下記の図は、ODRL情報モデルを示します。

図1 ODRL情報モデル(SVG形式でも入手可能)

ODRL情報モデルには次のクラスがあります。

ODRL情報モデルには、クラス間のプロパティー関係が含まれています。ほとんどは明示的な名前を持つプロパティーで、一部が抽象的なプロパティー(具体的には、関係、機能、オペランド、失敗)です。抽象的なプロパティーとは、明示的なセマンティクスを有する子プロパティー(サブタイプ)で表すように設計された汎用的な親プロパティーです。

例えば、図1の関係、機能という2つのプロパティーは、規則と資産と当事者のクラスの間の概念関係を表すように設計されています。図では、サブタイプtargetを有する関係プロパティーを示し、資産が規則の主要な対象であることを表しています。機能プロパティーは、規則を発行している当事者を表すためにサブタイプassigner(譲渡人)を持ち、規則の受容当事者を表すためにサブタイプassignee(譲受人)を持っています。

注

ODRL情報モデルは、方針モデルの構成要素の論理ビューを提供します。ODRL情報モデルの実装可能なビューは、ODRL語彙および表現ドキュメント[odrl-vocab]で規範的に記述されているとおり、様々なエンコーディングのシリアル化により提供されます。論理的な情報モデル構成要素を実装可能なシリアル化にマッピングするためには、シリアル化言語でサポートされている機能に応じて、何らかのトレードオフおよび/または相違が必要かもしれません。

以下の項では、ODRL情報モデルに関するより詳細な情報を提供します。

2.1 方針クラス

方針(Policy)クラスには次のプロパティーがあります。

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)。

2.1.1 集合クラス

サブクラスSet(集合)のODRL方針は、規則の任意の組み合わせを表します。Set方針サブクラスは、(何も指定されていない場合)方針のデフォルトのサブクラスでもあります。

ユースケースの例: 下記のSet方針は、ターゲット資産http//example.com/asset:9898.movieをuse(利用する)許可を表します。

例1

{
    "@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プロパティーを用いていません。

2.1.2 提案クラス

サブクラスOffer(提案)のODRL方針は、譲渡当事者から提案される規則を表します。一般的に、Offerは、より広い利用者が利用できる方針を作るために用いられますが、規則は許可しません。

サブクラスOfferのODRL方針は次のとおりです。

注: 機能的役割の詳細は、機能プロパティーの項を参照してください。

注: 上記のプロパティーのカーディナリティーは、規範的なODRL情報モデルを反映しています。場合によっては、一部のプロパティーの繰り返し出現もサポートされていますが(方針規則の合成とコンパクトな方針で記述しているとおり)、規範的でアトミックな方針は、上記のプロパティーのカーディナリティーと整合性があります。

ユースケースの例: 下記のOffer方針(以前の例に基づく)は、譲渡当事者http://example.com/party:org:abcからの、ターゲット資産http//example.com/asset:9898.movieをplay(再生する)許可を表します。

例2

{
    "@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プロファイルの項を参照してください。

2.1.3 合意クラス

サブクラスAgreement(合意)のODRL方針は、譲渡当事者から譲受当事者に与えられている規則を表します。一般的に、Agreementは、当事者間で規則の条件を付与するために用いられます。

サブクラスAgreementのODRL方針は次のとおりです。

注: 機能的役割の詳細は、機能プロパティーの項を参照してください。

注: 上記のプロパティーのカーディナリティーは、規範的なODRL情報モデルを反映しています。場合によっては、一部のプロパティーの繰り返し出現もサポートされていますが(方針規則の合成とコンパクトな方針で記述しているとおり)、規範的でアトミックな方針は、上記のプロパティーのカーディナリティーと整合性があります。

ユースケースの例: 下記のAgreement方針(以前の例に基づく)は、譲渡当事者http://example.com/party:org:abcから譲受当事者http://example.com/party:person:billieに、ターゲット資産http//example.com/asset:9898.movieをplay(再生する)許可を与えることを表します。

例3

{
    "@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"
    }]
}
2.2 資産クラス

資産(Asset)クラスは、規則の対象である1つの資源または資源のコレクションです。資産は、データ/情報、コンテンツ/メディア、アプリケーション、サービス、物理的人工物などの、任意の形式の識別可能な資源でありえます。さらに、それは、義務の付与など、方針表現を担うために必要なその他のAssetクラスを表すために使用できます。資産は、許可および/または禁止によって参照され、義務によっても参照されます。

資産クラスには次のプロパティーがあります。

注

資産がuidプロパティーを用いて識別子を言明していない場合は、ODRL方針のODRL検証システムと評価システムへの影響など、完全な意味が理解されていなければなりません。

資産クラスには次のサブクラスがあります。

資産コレクション・クラスには次のプロパティーがあります。

ODRL方針はあらゆる種類の資産を扱うことができるため、ODRL情報モデルは、特定のメディア・タイプの資産を記述するための追加のメタデータを提供しません。資産の型や目的に適したダブリン・コア・メタデータ用語などの既存のメタデータ標準を用いることをお勧めします。

2.2.1 関係プロパティー

抽象的なrelation(関係)プロパティーは、行為と資産との間に明示的なリンクを作成するために用いられ、リンクされている規則に関してどのように資産を利用しなければならない(MUST)かを示します。

関係のODRL検証システムは、次のrelationのサブプロパティーをサポートしなければなりません(MUST)。

追加のrelationサブタイプ・プロパティーは、ODRL共通語彙[odrl-vocab]とODRLプロファイルで定義できます(MAY)。

ユースケースの例: 譲渡当事者http//example.com/party:0001は、target資産http://example.com/asset:3333を表示することを提案します。

例4

{
   "@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は、関係のこの新しいサブプロパティーを定義します。

例5

{
   "@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"
   }]
}
2.2.2 ～の部分プロパティー

partOf(～の部分)プロパティーは、資産資源をメンバーとして持つ資産コレクションを識別するために用います。その目的は、資産と資産コレクションの間のメンバーシップ関係を明示的に表すことです。これにより、資産コレクションに関連付けられている規則は、どの資産に規則が個々に適用されているかを知ることができます。さらに、資産/資産コレクションのメンバーシップ関係により、規則内の衝突を検出できる可能性があります。

ユースケースの例: 下記の断片は、ドキュメントを記述しているあるダブリン・コア・メタデータを表します。odrl:partOfプロパティーは、資源http://example.com/asset:111.docが、上記の例における方針で用いられているhttp://example.com/archive1011資産コレクションのメンバーであると言明しています。これは、http://example.com/asset:111.docが方針内のターゲット資産のうちの1つであり、インデキシングできることを意味します。

例6

{
   "@type": "dc:Document",
   "@id": "http://example.com/asset:111.doc",
   "dc:title": "Annual Report",
   ...
   "odrl:partOf": "http://example.com/archive1011",
   ...
}
2.2.3 ターゲット方針プロパティー

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の許可に対するターゲット資産にもなりました。この方針に追加の規則があれば、同じ資産が各規則のターゲット資産となるでしょう。

例7

{
   "@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",
   ...
}
2.3 当事者クラス

当事者(Party)クラスは、人、人のコレクション、組織、エージェントなど、規則内の機能的役割を担う1つのエンティティーまたはエンティティーのコレクションです。エージェントは、積極的な役割を果たす、または特定の効果を生み出す人または物です。当事者は、行為を行う(または、実行しない)か、義務において機能を持っています(つまり、規則内で担う機能に関連付けることにより、当事者を規則に割り当てる)。

当事者クラスには次のプロパティーがあります。

注

当事者がuidプロパティーを用いて識別子を言明していない場合は、ODRL方針のODRL検証システムと評価システムへの影響など、完全な意味が理解されていなければなりません。

当事者クラスには次のサブクラスがあります。

当事者コレクション・クラスには次のプロパティーがあります。

ODRL情報モデルは、当事者クラスに追加のメタデータを提供しません。W3C vCardオントロジー[vcard-rdf]やFOAF語彙[foaf]などの既存のメタデータ標準を用いることをお勧めします。

2.3.1 機能プロパティー

function(機能)プロパティーは、規則を当事者にリンク付けるために用いられ、リンクされている規則に関して当事者が担っている機能を示します。functionプロパティー自身は抽象的で、サブプロパティーが、当事者と規則の間の機能的役割の明示的なセマンティクスを表します。

ODRL検証システムは、functionの次のサブプロパティーをサポートしなければなりません(MUST)。

追加のfunctionサブタイプ・プロパティーは、ODRL共通語彙[odrl-vocab]とODRLプロファイルで定義できます(MAY)。

ユースケースの例: この方針は、assignerとassigneeの機能的役割を持つ2つの当事者との合意を示します。assignerは、assigneeにターゲット資産に対する再生行為の実行を許可しています。

例8

{
    "@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として識別されるすべてのエンティティーが、それぞれ同じ許可された行為を持っているということを意味します。

例9

{
    "@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"
    }]
}
2.3.2 ～の部分プロパティー

partOf(～の部分)プロパティーは、当事者エンティティーをメンバーとして持つ当事者コレクションを識別するために用いられます。その目的は、当事者と当事者コレクションの間のメンバーシップ関係を明示的に表すことです。これにより、当事者コレクションに関連付けられている規則は、どの当事者に個々に規則が適用されているかを知ることができます。さらに、当事者/当事者コレクションのメンバーシップ関係により、規則内の衝突を検出できる可能性があります。

ユースケースの例: 下記の断片は、当事者を記述しているあるvCardメタデータを表しています。odrl:partOfプロパティーは、当事者http://example.com/person/murphyが、上記の例の方針で用いられているhttp://example.com/team/A当事者コレクションのメンバーであると言明しています。これは、http://example.com/person/murphyが譲受人であり、方針のターゲット資産を使用できることを意味します。

例10

{
   "@type": "vcard:Individual",
   "@id": "http://example.com/person/murphy",
   "vcard:fn": "Murphy",
   "vcard:hasEmail": "murphy@example.com",
   ...
   "odrl:partOf": "http://example.com/team/A",
   ...
}
2.3.3 譲渡方針プロパティー

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の許可の譲受人にもなりました。この方針に追加の規則があれば、同じ当事者が各規則の譲受人となるでしょう。

例11

{
   "@type": "vcard:Individual",
   "@id": "http://example.com/person/billie",
   "vcard:fn": "Billie",
   "vcard:hasEmail": "billie@example.com",
   ...
   "odrl:assigneeOf": "http://example.com/policy:1011",
   ...
}
2.4 行為クラス

行為(Action)クラスは、資産に対して行える操作を示します。行為は、規則内の行為プロパティーにより資産に関連付けられます。

規則は、行為の具体的な解釈を提供します。例えば、行為が許可に関連付けられていれば、ターゲット資産に対する実行が許可されています。禁止に関連付けられていれば、行為は、ターゲット資産に対して行うことが禁止されている操作を示します。義務と関連付けられていれば、行為は、当事者による履行が義務付けられている合意された操作を示します。

ODRL情報モデルは、次のトップレベルの行為を定義します。

行為クラスには次のプロパティーがあります。

行為の用語は、包含行為を指す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用語であると定義されている)。

例12

{
    "@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"
     }]
}
2.5 制約

制約は、行為および当事者/資産コレクションのセマンティクスを精緻化したり、規則に適用可能な条件を宣言したりするために使用できるブール/論理式です。制約は、制約クラスまたは論理制約クラスとして表現できます。論理制約は、既存の制約をオペランドとして参照します。複数の制約が同じ規則、行為、当事者/資産コレクションに適用されている場合、それらは論理積として解釈され、すべてが満たされなければなりません(MUST)。

制約および論理制約のクラスは、当事者コレクション、資産コレクション、行為、規則のクラスとのセマンティック関係および条件関係を形成します。下記の図でプロパティー関係を要約しています。

図2 ODRL制約関係(SVG形式でも入手可能) 2.5.1 制約クラス

制約(Constraint)クラスは、2つのオペランド(制約ではない)を1つの関係演算子で比較する式に用いられます。比較によって一致が返された場合は制約が満たされ、そうでない場合は満たされません。制約クラスは、利用数(leftOperand)は10(rightOperand)よりも小さくなければならない(operator)などの比較式を作成します。

制約クラスには下記のプロパティーがあります。

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回行われ、比較により現在の行為とステータス値を比較しなければならないことを意味します。

2.5.2 論理制約クラス

論理制約(Logical Constraint)クラスは、既存の制約である2つ以上のオペランドを1つの論理演算子で比較する式に用いられます。比較によって論理的一致が返された場合は論理制約が満たされ、そうでない場合は満たされません。例えば、3つの制約に論理積を行うことができ、論理制約が満たされるためには3つすべてが真でなければならないことを示します。

論理制約クラスには次のプロパティーがあります。

ODRL評価システムは、operandの次のサブプロパティーをサポートしなければなりません(MUST)。

追加のoperandサブプロパティーは、ODRLプロファイルで定義できます(MAY)。

論理制約のODRL検証要件には次が含まれます。

  1. operandは、or、xone、and、andSequenceというサブプロパティーのみでなければなりません(MUST)。operandの追加のサブプロパティーは、論理制約の使用のためだけに、ODRLプロファイで定義できます(MAY)。
  2. すべてのオペランド値は、一意の制約インスタンスでなければなりません(MUST)。

制約インスタンスを評価し、その結果によって、(operandサブプロパティーのセマンティクスに基づいて)論理関係が満たされているかどうかを判定しなければなりません(MUST)。

注

andSequenceなどの、順番に評価する必要がある論理オペランドを用いる場合、シリアル化は、リストのメンバーの順序を保持しなければなりません(MUST)。JSON-LDでは、@listキーワードを用いて順序付きコレクションを表さなければなりません(MUST)。

2.5.3 規則と制約プロパティー

規則(許可、禁止、義務など)には、規則の条件を示すために、constraint(制約)プロパティーを含むことができます(MAY)。この条件を満たすためには、constraintプロパティーにより参照されているすべての制約/論理制約が満たされなければなりません(MUST)。

ユースケースの例: 下記の方針の提案の例では、許可によりターゲット資産をdistribute(配信する)ことが許されており、その許可は2018-01-01までしか行使できないというdateTime条件の制約が含まれています。

例13

{
    "@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" }
       }]
   }]
}
2.5.4 行為と精緻化プロパティー

行為には、行為の操作のセマンティクスを直接限定する制約/論理制約を示すために、refinement(精緻化)プロパティーを含むことができます(MAY)。行為のより限定的なセマンティクスというこの条件を満たすためには、満足状態を生成する際に、refinementプロパティーにより参照されているすべての制約/論理制約を用いなければなりません(MUST)。

注: 行為に精緻化を適用した結果は、ヌル(null)の操作になるべきではありません(SHOULD NOT)。

ユースケースの例: 下記の方針の提案の例では、許可によりターゲット資産をprint(印刷する)ことが許されており、1200dpi以下の解像度という精緻化の制約も含まれています。精緻化は、印刷のセマンティクをより限定したものとなり、このケースでは、特定の最大解像度での印刷です。

例14

{
    "@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オペランドによる)として表されています。

例15

{
    "@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キーとして言明しなければならなりません。

2.5.5 資産コレクションと精緻化プロパティー

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で定義されていることに注意してください。

例16

{
  "@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"
  }]
}
2.5.6 当事者コレクションと精緻化プロパティー

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(表示)の許可(プロファイルで定義されている)が与えられることを示す精緻化も持っています。

例17

{
  "@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" }
  }]
}
2.6 規則クラス

規則(Rule)クラスは、許可、禁止、義務のクラスの親です。規則クラスは、これらの3つのクラスに共通する特性を表します。規則クラスは、すべてのその他の規則サブクラスと素でなければなりません(MUST)。

規則クラスには次のプロパティーがあります。

注: 上記のプロパティーのカーディナリティーは、規範的なODRL情報モデルを反映しています。場合によっては、一部のプロパティーの繰り返し出現もサポートされていますが(方針規則の合成とコンパクトな方針で記述しているとおり)、規範的でアトミックな方針は、上記のプロパティーのカーディナリティーと整合性があります。

抽象的なrelation、relation、failureのプロパティーの明示的なサブプロパティーを用いなければならず、その選択は、該当する規則のサブクラスによって異なります。

規則の3つのクラスは、義務の規則との重要な関係も形成します。下記の図でプロパティー関係を要約しています。

図3 ODRL規則関係(SVG形式でも入手可能) 2.6.1 許可クラス

許可(Permission)は、すべての制約が満たされ、すべての義務が履行されていれば、すべての精緻化を満たしつつ、資産に対して行為を行うことを許します。

許可クラスは、規則クラスのサブクラスであり、そのすべてのプロパティーを継承し、次の追加のプロパティーのセマンティクスを持っています。

注: 上記のプロパティーのカーディナリティーは、規範的なODRL情報モデルを反映しています。場合によっては、一部のプロパティーの繰り返し出現もサポートされていますが(方針規則の合成とコンパクトな方針で記述しているとおり)、規範的でアトミックな方針は、上記のプロパティーのカーディナリティーと整合性があります。

義務プロパティーは、履行しなければならない(MUST)合意された責務を表します。つまり、義務プロパティーは、許可と義務の間の前提条件を言明します。詳細は、許可と義務の項を参照してください。

ユースケースの例: 譲渡人http://example.com/org:xyzからの方針のOfferは、ターゲット資産http//example.com/game:9090の再生行為を表し、その許可は2017年末まで有効です。

例18

{
   "@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" }
       }]
   }]
}
2.6.2 禁止クラス

禁止(Prohibition)は、すべての制約が満たされていれば、すべての精緻化を満たしつつ、資産に対して行為を行うことを許しません。行われた行為によって禁止が侵害された場合、禁止の状態を侵害されていない状態にするために、すべての救済が履行されなければなりません(MUST)。

禁止クラスは、規則クラスのサブクラスであり、そのすべてのプロパティーを継承し、次の追加のプロパティーのセマンティクスを持っています。

注: 上記のプロパティーのカーディナリティーは、規範的なODRL情報モデルを反映しています。場合によっては、一部のプロパティーの繰り返し出現もサポートされていますが(方針規則の合成とコンパクトな方針で記述しているとおり)、規範的でアトミックな方針は、上記のプロパティーのカーディナリティーと整合性があります。

remedy(救済)プロパティー(failureプロパティーのサブプロパティー)は、禁止が侵害された場合に履行されなければならない(MUST)合意された責務を表します。つまり、救済プロパティーは、禁止の行動が行われた場合に履行されなければならない義務を言明します。詳細は、禁止と救済の項を参照してください。

ユースケースの例: このターゲット資産http://example.com/photoAlbum:55の譲渡人は、許可および禁止により合意方針を表します。譲渡当事者http://example.com/MyPix:55は、ターゲット資産のdisplay(表示)の許可と同時に、archive(アーカイブ)の禁止を譲受当事者http://example.com/assignee:55に与えます。さらに、方針に任意の衝突(例えば、許可と禁止の間に)がある場合のために、Policyのconflictプロパティーを、許可が優先することを示すpermに設定しています。

例19

{
    "@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"
    }]
}
2.6.3 義務クラス

義務(Duty)は、すべての精緻化を満たしつつ、行為を行う責務です。義務は、すべての制約が満たされ、すべての精緻化を満たしつつ、その行為が行われる場合に履行されます。その行為が行われていない場合は、義務を履行するために、すべてのconsequence(結果)も履行されなければなりません。つまり、結果は、同様に履行しなければならない追加の義務です。(注：義務または責務のプロパティーにより参照されている義務のみが、結果プロパティーを使用できます。)

義務クラスは、規則クラスのサブクラスであり、そのすべてのプロパティーを継承し、次の追加のプロパティーのセマンティクスを持っています。

注: 上記のプロパティーのカーディナリティーは、規範的なODRL情報モデルを反映しています。場合によっては、一部のプロパティーの繰り返し出現もサポートされていますが(方針規則の合成とコンパクトな方針で記述しているとおり)、規範的でアトミックな方針は、上記のプロパティーのカーディナリティーと整合性があります。

義務クラスにはこれらの追加要件もあります。

consequenceプロパティー(failureプロパティーのサブプロパティー)は、許可に対する合意された方針の責務または義務が履行されなかった場合の影響を表すために用います。これらのいずれかが履行されなかった場合、その結果の義務が新たな要件にもなり、元の責務または義務ならびに結果の義務をすべて履行しなければならない(MUST)ことになります。

注

場合によっては、元の義務/責務に対する一部の制約および/または精緻化を満たせなくなった場合には、結果を生じさせた元の義務/責務を履行するために、それらを緩和する必要があるかもしれません(MAY)。

例えば、指定期日までにデータを提供するという責務が履行されなければ、$100の罰金という結果を支払うことも可能性です。しかし、日付が過ぎてしまえば、元の義務は技術的に履行できなくなります(日付の制約を満たせないため)。

そのような場合のために、ODRLの実装では、結果が生じた後に元の義務/責務を満たすことができる方法を提供すべきです(SHOULD)。

結果のプロパティーは、既に許可の義務または方針の責務の結果である義務に用いてはならない(MUST NOT)ことに注意してください。

2.6.4 方針と責務プロパティー

方針には、義務を履行する責務(obligation)を含むことができます(MAY)。責務は、すべての制約が満たされ、すべての精緻化を満たしつつ、その行為が行われる場合に履行されます。

ユースケースの例: 下記の合意には、譲渡人にEU500.00の支払金額を補償するという、譲渡人http://example.com/org:43から譲受人http://example.com/person:44に対する責務が含まれています。

例20

{
  "@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)という結果となります。

例21

{
    "@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"
         }]
    }]
}
2.6.5 許可と義務プロパティー

義務(Duty)は、許可から義務までの義務プロパティー関係を用いて履行を要求する前提条件として指定できます(MAY)。

許可にいくつかの義務がある場合、すべての義務の履行が合意されなければなりません(MUST)。くつかの許可が同じ義務を参照(uidプロパティーにより)している場合、義務は1回だけ履行されなければなりません。

義務でfunctionサブプロパティーが宣言されていない場合、その機能的役割は、参照している許可で宣言されたものと同じです。

ユースケースの例: 当事者http://example.com/assigner:sonyは、ターゲット資源http://example.com/music/1999.mp3を再生する提案を行います。許可には、$EU5.00のpayAmountという精緻化を含むcompensate(補償)行為の義務が含まれています。義務には、eventはpolicyUsageよりも小さいという制約も含まれています。つまり、許可の規則を行う前に義務の規則（つまり、補償)を行わなければなりません。

例22

{
    "@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" }
            }]
        }]
    }]
}
2.6.6 許可/責務義務と結果プロパティー

許可の義務、および方針の責務には、その義務や責務を履行しなかった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にも追跡されることになるでしょう。

例23

{
    "@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"
            }]
        }]
    }]
}
2.6.7 禁止と救済プロパティー

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)という救済になるでしょう。

例24

{
    "@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"
        }]
    }]
}
2.7 方針規則の合成

ODRL情報モデルは、規則に対するプロパティー関係の規範的なカーディナリティーを提供します。コア・レベルでは、ODRL規則は、1つの資産、1つ以上の当事者の機能的役割、1つの行為(そして、潜在的に、制約および/または義務)に関連付けられるでしょう。

方針規則の合成により、複数の資産、当事者、行為に関連する規則をサポートするために、個々の規則でODRL情報モデルのカーディナリティー要件を拡張できます。その目的は、共通するプロパティーを(1つの規則に)組み合わせて、より複合的な方針を表すことです。その後に、方針を処理して規範的でアトミックな相当物にすべきです(SHOULD)。

下記の例は、削減できない規則である(つまり、分解したり、それ以上簡素化できない)アトミックなレベルの方針を示します。

例25

{
  "@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つの行為が含まれています。

例26

{
    "@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つの行為が含まれています。

例27

{
    "@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検証要件には次が含まれます。

  1. 複数の資産(同じ関係を持つ)がある場合は、既存の規則を新しく作成された規則で置き換え(資産ごとに1つ)、1つの資産関係のみを含め、個々の規則に他のすべての(資産でない)プロパティーを含めます。
  2. 複数の当事者(同じ機能を持つ)がある場合は、既存の規則を新しく作成された規則で置き換え(当事者ごとに1つ)、1つの当事者機能のみを含め、個々の規則に他のすべての(当事者でない)プロパティーを含めます。
  3. 複数の行為がある場合は、既存の規則を新しく作成された規則で置き換え(行為ごとに1つ)、1つの行為のみを含め、個々の規則に他のすべての(行為ではない)プロパティーを含めます。
2.7.1 コンパクトな方針

ODRL方針には、方針レベルで宣言された、その規則のすべてに共通するプロパティーを保持できます(MAY)。これは、よりコンパクトなシリアル化をサポートするための省略化方式となることのみを目的としています。これらの共通プロパティーを、(方針クラスの項で定義しているような)方針レベルのプロパティーと解釈してはなりません(MUST NOT)。

(下記の図で示しているとおり)共有できる(MAY)プロパティーには次のものが含まれます。

方針の省略形を拡張するためのODRL検証要件は次のとおりです。

  1. 方針の規則ごとに、
  2. 方針レベルで宣言された共通プロパティーを削除します。

さらに、ODRL検証要件に従って、方針にアトミックな規則を作成します(前項で定義しているとおり)。

適合性のための処理を行う際には、コンパクトなODRL方針をアトミックな方針に拡張することが推奨されます(RECOMMENDED)。

下記の例は、そのような方針に適用される共通プロパティーを示しています。

例28

{
    "@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検証要件に従った方針の許可に拡張する方法を示しています。

例29

{
    "@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",
        }]
}
2.8 方針メタデータ

さらなる信頼性と完全性の目的をサポートするために、外部の語彙から追加のメタデータ・プロパティーを方針に追加できます(MAY)。ODRL情報モデルでは、ODRL方針にダブリン・コア・メタデータ用語[dcterms]の使用を推奨します。

次のダブリン・コア・メタデータ用語[dcterms]プロパティーを用いるべきです(SHOULD)。

上記のメタデータ・プロパティーを持つ方針のODRL検証要件には次が含まれます。

  1. 方針にdc:isReplacedByプロパティーがある場合、プロセッサは最初の方針を無効とみなさねばならず(MUST)、識別された方針を取得し処理しなければなりません(MUST)。

ユースケースの例: 下記の例は、方針の作成者、内容記述、方針の発行日、方針が適用される管轄区(オーストラリアのクイーンズランドの識別子)、それが置き換える古いバージョンの方針の識別子を示すメタデータ・プロパティーを示しています。

例30

{
    "@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": [ { } ]
}

注: ダブリン・コア・メタデータ・プロパティーで用いられる文字列値は、正規化されていない可能性があり、方針メタデータの比較向けに設計されていません。

2.9 方針の継承

ODRLは、(子の)方針が1つ以上の(親の)方針のすべてのアトミックな規則を継承できる継承メカニズムをサポートしています。inheritFromプロパティーは、親の方針から継承する子の方針で用いなければならず(MUST)、親の方針の複数の識別子を含むことができます(MAY)。

継承を用いる場合、次が適用されます。

ユースケースの例: 下記の(親の)方針http://example.com/policy:defaultを見てみましょう。これには、(方針レベルの)譲渡人とターゲット資産の方針ドキュメントをレビューする責務が含まれます。

例31

{
    "@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プロパティーを示します。子の方針は、ターゲット資産、(資産を表示する)行為、および合意の譲受当事者を示します。

例32

{
    "@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"
    }]
}

継承が行われた後の - 親の方針規則と方針レベルのプロパティーが子の方針に追加され、かつ、規則がアトミックになった場合 - その結果の方針を下記に示します。元の子の許可の規則には、親の方針の(方針レベルの)譲受人が含まれました。親の責務の規則は、更新された子の方針に、元の子の(方針レベルの)譲受人を含んで出現するようになりました。

例33

{
    "@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検証要件には次が含まれます。

  1. 子の方針は、親の方針にアクセスし、更新された子の方針に次を複製しなければなりません(MUST)。
  2. 識別された親の方針ごとに上記を繰り返します。
  3. そして、最後に更新された子の方針は、方針の合成の項で定義しているODRL検証要件に従うことで、さらに(アトミックな規則に)拡張できます(MAY)。
2.10 方針衝突時の対策

conflict(衝突)プロパティーは、方針の統合に起因する衝突または同じ方針の許可と禁止の間の衝突を解決するための対策を確立するために用います。衝突は、方針の継承の結果として方針を統合した結果の規則に矛盾がある場合に生じる可能性があります。

conflictプロパティーは、次の衝突対策プレファレンスの値(ConflictTermクラスのインスタンス)のうちの1つを取るべきです(SHOULD)。

conflictプロパティーが明示的に設定されていない場合は、invalidというデフォルトが用いられるでしょう。

追加のconflictプロパティー値は、ODRLプロファイルで定義できます(MAY)。

衝突対策要件には次が含まれます。

  1. 方針にpermというconflictプロパティーが含まれている場合、衝突している許可の規則により、禁止の規則が無効にならなければなりません(MUST)。
  2. 方針にprohibitというconflictプロパティーが含まれている場合、衝突している禁止の規則により、許可の規則が無効にならなければなりません(MUST)。
  3. 方針にinvalidというconflictプロパティーが含まれている場合、衝突している規則により、方針全体が無効にならなければなりません(MUST)。
  4. 方針に複数のconflictプロパティー値があり(例えば、方針の統合または継承の後に)、衝突している規則がある場合、方針全体が無効にならなければなりません(MUST)。

ユースケースの例: 2つの方針が同じターゲット資産http://example.com/asset:1212に関連付けられています。最初の方針http://example.com/policy:0001は、資産のuse(利用)を認めています。2番目の方針http://example.com/policy:0002は、資産の表示を認めていますが、print(印刷)は禁止しています。どちらの方針も、conflictプロパティーをpermに設定することにより、衝突の処理方法を明示的に述べています。したがって、許可は常にあらゆる禁止を無効にします。このユースケースでは、printの行為はuseの行為を特殊化したものであるため、衝突がありえます。しかし、permという衝突対策は、useの許可がprintの禁止を無効にすることを意味します。

例34

{
    "@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"
    }]
}

例35

{
    "@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という衝突の値があれば、その結果は直接的な矛盾であり、結果として無効な方針になるでしょう。

3. ODRLプロファイル 3.1 ODRLプロファイルの目的

ODRL情報モデルは、方針を表すためのコアとなる枠組みおよび語彙として機能します。ODRLコア語彙[odrl-vocab]は、この語彙用語の集合を明確に示します。ODRL方針は、ODRLコア語彙を用いて表現でき、これは、最小限にサポートされた方針表現を表します。

追加のセマンティクスを必要とするODRL方針で使用できる語彙用語を提供するためには(ODRLプロファイルのメカニズムの項で詳述しているとおり)、ODRLプロファイルを定義しなければなりません(MUST)。ODRLプロファイルは、ODRL方針表現でサポートする必要がある語彙用語を指定することにより、コミュニティのニーズに明確に対応します。これらの用語は、明示的に定義するか、ODRL共通語彙を採用することができます。

ODRL共通語彙[odrl-vocab]は、許可、禁止、義務に加え、方針のサブクラス、制約の左オペランドと演算子、資産関係、当事者の機能に関する汎用的な範囲の共通の行為を提供します。

3.2 ODRLプロファイルの適合性

ODRL方針がODRLプロファイルに準拠するには、profileプロパティーを指定してODRLプロファイルの識別子(IRI)を示さなければなりません(MUST)。ODRL方針が複数のODRLプロファイルに準拠していることを示すために複数の識別子が存在しても構いません(MAY)。

ODRL方針でODRLプロファイルが用いられている場合、ODRL処理システムは、識別されたODRLプロファイルのセマンティクスを理解しなければなりません(MUST)。ODRL処理システムがODRLプロファイル識別子を認識しない場合、方針の処理を停止しなければなりません(MUST)。

3.3 ODRLプロファイルのメカニズム

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を用いた、新しい用語ごとの人間が読める文書も推薦されます。

3.4 ODRLコア・プロファイル

ODRLコア・プロファイルを識別する必要がある状況、つまり、方針がODRLコア語彙にのみ準拠している状況では、次の識別子をコア・プロファイルを使用できます(MAY): http://www.w3.org/ns/odrl/2/core

4. プライバシーに関する留意点

この項は非規範的です。

ODRL情報モデルは、当事者に関するデータを含んでいる資産の存在の識別情報などの機密の個人情報を直接表しません。しかし、ODRL語彙(ODRL共通語彙[odrl-vocab]やODRLプロファイルなど)は、個人情報と関連しえる用語を定義することができます。これらの仕様は、そのようなODRL表現を作成または利用する実装に、方針がどのような方法で用いられているか、その方針が他のどのような当事者と共有されているか、方針が他の当事者と共有されている理由をすべての関連するユーザに伝えるための措置を取ることを知らせるべきです。

A. 謝辞

POEワーキンググループは、ODRLコミュニティ・グループおよび以前のODRLイニシアチブの貢献に謝意を表します。特に、編集者は、過去の編集上の貢献に対し、Susanne Guth、Daniel Paehler、Andreas KastenAndreas Kastenに謝意を表します。

B. 勧告候補終了基準

この仕様を勧告案に進めるためには、下記の各機能の少なくとも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ワーキンググループの成果物を用いることが期待されています。

D. 旧バージョンからの変更

2016年7月21日の最初の公開草案からの変更:

2017年2月23日の草案からの変更:

2017年9月26日の勧告候補からの変更:

2018年1月4日の勧告案からの変更:

E. 参考文献 E.1 規範的な参考文献
[odrl-vocab]
ODRL Vocabulary & Expression 2.2. Renato Iannella; Michael Steidl; Stuart Myles; Victor Rodriguez-Doncel. W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-vocab/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[rfc3987]
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987
E.2 参考情報の参考文献
[dcterms]
DCMI Metadata Terms. Dublin Core metadata initiative.14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dcmi-terms/
[foaf]
FOAF Vocabulary Specification 0.99 (Paddington Edition). Dan Brickley; Libby Miller. FOAF project. 14 January 2014. URL: http://xmlns.com/foaf/spec
[json-ld]
JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/
[odrl]
Open Digital Rights Language (ODRL) Version 1.1. Renato Iannella. W3C. 19 September 2002. W3C Note. URL: https://www.w3.org/TR/odrl
[odrl2-req]
ODRL Version 2 Requirements. Susanne Guth; Renato Iannella. ODRL Initiative. 13 February 2005. Working Draft. URL: https://www.w3.org/2012/09/odrl/archive/odrl.net/2.0/v2req.html
[odrl21-json]
ODRL Version 2.1 JSON Encoding. Jonas Oberg; Stuart Myles; Lu Ai. W3C. 5 March 2015. W3C Community Group Final Specification. URL: https://www.w3.org/community/odrl/json/2.1/
[odrl21-model]
ODRL Version 2.1 Core Model. Renato Iannella; Susanne Guth; Daniel Paehler; Andreas Kasten. W3C. 5 March 2015. W3C Community Group Final Specification. URL: https://www.w3.org/community/odrl/model/2.1/
[odrl21-onto]
ODRL Version 2.1 Ontology. Mo McRoberts; Victor Rodriguez Doncel. W3C. 5 March 2015. W3C Community Group Final Specification. URL: https://www.w3.org/ns/odrl/2/ODRL21
[odrl21-vocab]
ODRL Version 2.1 Common Vocabulary. Renato Iannella; Michael Steidl; Susanne Guth. W3C. 5 March 2015. W3C Community Group Final Specification. URL: https://www.w3.org/community/odrl/vocab/2.1/
[odrl21-xml]
ODRL Version 2.1 XML Encoding. Renato Iannella. W3C. 5 March 2015. W3C Community Group Final Specification. URL: https://www.w3.org/community/odrl/xml/2.1/
[vcard-rdf]
vCard Ontology - for describing People and Organizations. Renato Iannella; James McKinney. W3C. 22 May 2014. W3C Note. URL: https://www.w3.org/TR/vcard-rdf/

↑

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4