ODRL 情報モデル 2.2

2.1.1 Set クラス

サブクラス Set の ODRL Policy は、Rules の任意の組み合わせを表す。Set Policy サブクラスは、Policy の既定のサブクラスでもある（何も指定されない場合）。

ユースケース例: 下の Set Policy は、対象 Asset http//example.com/asset:9898.movie を use する Permission を示している。

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

2.1.2 Offer クラス

サブクラス Offer の ODRL Policy は、assigner Parties から提示されている Rules を表す。Offer は通常、Policies をより広い対象に 利用可能にするために用いられるが、いかなる Rules も付与しない。

サブクラス Offer の ODRL Policy:

• 同じ Rules における機能的役割を示すために、1つの assigner プロパティ値（型は Party）を持たなければならない MUST。

注: 機能的役割の詳細については、Function Property の節を参照。

注: 上記のプロパティ・カーディナリティは、規範的な ODRL 情報モデルを反映している。場合によっては、 一部のプロパティの繰り返し出現もサポートされる（Policy Rule Composition および Compact Policy に記述される）が、規範的な原子的 Policy は上記のプロパティ・カーディナリティと一致する。

ユースケース例: 下の Offer Policy（前の例に基づく）は、 assigner Party http://example.com/party:org:abc から、対象 Asset http//example.com/asset:9898.movie を play する Permission を示している。

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

2.1.3 Agreement クラス

サブクラス Agreement の ODRL Policy は、 assigner から assignee Parties に付与された Rules を表す。Agreement は通常、 Parties 間の Rules の条件を付与するために用いられる。

サブクラス Agreement の ODRL Policy:

• 同じ Rules における機能的役割を示すために、1つの assigner プロパティ値（型は Party）を持たなければならない MUST。
• 同じ Rules における機能的役割を示すために、1つの assignee プロパティ値（型は Party）を持たなければならない MUST。

注: 機能的役割の詳細については、Function Property の節を参照。

注: 上記のプロパティ・カーディナリティは、規範的な ODRL 情報モデルを反映している。場合によっては、 一部のプロパティの繰り返し出現もサポートされる（Policy Rule Composition および Compact Policy に記述される）が、規範的な原子的 Policy は上記のプロパティ・カーディナリティと一致する。

ユースケース例: 下の Agreement Policy（前の例に基づく）は、 assigner Party http://example.com/party:org:abc から assignee Party http://example.com/party:person:billie に対して、対象 Asset http//example.com/asset:9898.movie を play する Permission を 付与することを示している。

{
    "@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.1 Relation プロパティ

抽象 relation プロパティは、Action と Asset の間に明示的なリンクを 作成するために用いられ、その Asset がそれにリンクする Rule に関してどのように利用されなければ ならないか MUST を示す。

ODRL validator は、relation の次のサブプロパティをサポートしなければならない MUST:

• target: Asset が、Rule の action が直接適用される主対象であることを示す。

追加の relation サブタイプ・プロパティは、ODRL Common Vocabulary [odrl-vocab] および ODRL Profiles において 定義できる MAY。

ユースケース例: assigner Party http//example.com/party:0001 が、 target Asset http://example.com/asset:3333 を display することを offer している。

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

ユースケース例: 下の Policy は、対象 Asset http://example.com/archive1011 に対する index action の Permission を示している。対象 asset は、そのリソースがリソースの集合であることを示すために、 AssetCollection としても宣言されている。追加の Asset relation summary は、インデックス作成の出力を格納すべき Asset http://example.com/x/database を示している。ODRL Profile ttp://example.com/odrl:profile:03 は、relation のこの新しいサブプロパティを 定義する。

{
   "@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 Part Of プロパティ

partOf プロパティは、Asset リソースがメンバーである AssetCollection を 識別するために用いられる。その目的は、Assets と AssetCollections の間のメンバーシップ関係を 明示的に表現することである。これにより、AssetCollection に関連する Rule が、どの個別 Assets にその Rule が適用され得るかを理解できる。さらに、Asset/AssetCollection の メンバーシップ関係は、Rules における競合を検出できる可能性がある。

ユースケース例: 下のスニペットは、文書を記述するいくつかの Dublin Core メタデータを示している。 odrl:partOf プロパティは、Asset http://example.com/asset:111.doc が、上の例の Policy で使用されている http://example.com/archive1011 AssetCollection のメンバーであることを表明する。 これは、http://example.com/asset:111.doc が Policy 内の target Assets の1つであり、 index され得ることを意味する。

{
   "@type": "dc:Document",
   "@id": "http://example.com/asset:111.doc",
   "dc:title": "Annual Report",
   ...
   "odrl:partOf": "http://example.com/archive1011",
   ...
}

2.2.3 Target Policy プロパティ

ODRL Policy クラスは、hasPolicy プロパティによって参照されることもできる MAY。これは、ODRL Policy Rules が 外部メタデータ表現（Asset を識別するもの）のオブジェクトとなることをサポートする。 hasPolicy がメタデータ表現と ODRL Policy の間に表明された場合、 識別されている Asset は、その Policy のすべての Rules の target Asset であると 推論されなければならない MUST。Policy 内に複数の Rules がある場合、推論された Asset は Policy 内のすべての Rule に対する target Asset となる。

ユースケース例: 下のスニペットは、movie Asset を記述するいくつかの Dublin Core メタデータを 示している。odrl:hasPolicy プロパティは、ODRL Policy http://example.com/policy:1010（これは上で記述した Set Policy）にリンクする。 この場合、Asset http://example.com/asset:9999.movie は、 Policy http://example.com/policy:1010 内の Permission に対する target Asset にもなる。この Policy に追加の Rules がある場合、同じ Asset が各 Rule の target Asset となる。

{
   "@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.1 Function プロパティ

function プロパティは、Rule を Party にリンクするために用いられ、 それにリンクする Rule に関して Party が担う function を示す。 function プロパティ自体は抽象的であり、サブプロパティは Party と Rule の間の機能的役割の明示的な意味論を表す。

ODRL validator は、function の次のサブプロパティをサポートしなければならない MUST:

• assigner: Rule を発行している Party を示す。例えば、Permission を付与する Party、または合意された Duty の履行を求める Party。
• assignee: Rule の受領者である Party を示す。例えば、Permission を付与される Party、または合意された Duty を履行することを求められる Party。

追加の function サブタイプ・プロパティは、ODRL Common Vocabulary [odrl-vocab] および ODRL Profiles において 定義できる MAY。

ユースケース例: この Policy は、assigner および assignee という 機能的役割を持つ2つの Parties による Agreement を示す。assigner は、 target asset に対する play action を 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"
    }]
}  

ユースケース例: この Policy は、assigner および assignee という 機能的役割を持つ2つの Parties による Agreement を示す。assigner は、 target asset の use を assignee に付与する。この場合、 assigner は Party として、また vcard:Organisation および いくつかの追加の外部プロパティとして明示的に宣言されている。assignee は、 PartyCollection として、また vcard:Group およびいくつかの追加の外部 プロパティとして明示的に宣言されている。これは、 http://example.com/team/A として識別されるすべてのエンティティが、 それぞれ同じ付与された action を持つことを意味する

{
    "@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 Part Of プロパティ

partOf プロパティは、Party エンティティがメンバーである PartyCollection を 識別するために用いられる。その目的は、Parties と PartyCollections の間のメンバーシップ関係を 明示的に表現することである。これにより、PartyCollection に関連する Rule が、どの個別 Parties にその Rule が適用され得るかを理解できる。さらに、Party/PartyCollection の メンバーシップ関係は、Rules における競合を検出できる可能性がある。

ユースケース例: 下のスニペットは、Party を記述するいくつかの vCard メタデータを示している。 odrl:partOf プロパティは、Party http://example.com/person/murphy が、上の例の Policy で使用されている http://example.com/team/A PartyCollection のメンバーであることを表明する。 これは、http://example.com/person/murphy が assignee であり、 Policy 内の target asset を使用できることを意味する。

{
   "@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 Assigned Policy プロパティ

ODRL Policy クラスは、assignerOf および assigneeOf プロパティに よって参照されることもできる MAY。これは、 ODRL Policy Rules が外部メタデータ表現（Party を識別するもの）のオブジェクトとなることを サポートする。assignerOf がメタデータ表現と ODRL Policy の間に表明された場合、 識別されている Party は、その Policy のすべての Rules の assigner 機能的役割を 担うと推論されなければならない MUST。 assigneeOf がメタデータ表現と ODRL Policy の間に表明された場合、 識別されている Party は、その Policy のすべての Rules の assignee 機能的役割を担うと推論されなければならない MUST。 Policy 内に複数の Rules がある場合、推論された Party は Policy 内のすべての Rule に対してその機能的役割を担う。

ユースケース例: 下のスニペットは、個人の Party を記述するいくつかの vCard メタデータを 示している。odrl:assigneeOf プロパティは、ODRL Policy http://example.com/policy:1011（これは上で記述した Offer Policy）にリンクする。 この場合、Party http://example.com/person/billie は、 Policy http://example.com/policy:1011 内の Permission の assignee にもなる。 この Policy に追加の Rules がある場合、同じ Party が各 Rule の assignee となる。

{
   "@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.5.1 Constraint クラス

Constraint クラスは、1つの関係演算子によって2つの operands（Constraints ではないもの）を 比較する式に用いられる。比較が一致を返す場合、Constraint は 満たされる。そうでない場合は満たされない。Constraint クラスは、 例えば、利用回数（leftOperand）が（operator）10 （rightOperand）より小さくなければならない、といった比較式を定式化する。

Constraint クラスには次のプロパティがある:

• Constraint は、その Constraint を識別するために、uid プロパティ値 （型は IRI [rfc3987]）を 0個または1個持つことができる MAY。
• Constraint は、LeftOperand 型の leftOperand プロパティ値を1つ持たなければならない MUST。
• Constraint は、Operator 型の operator プロパティ値を1つ持たなければならない MUST。
• Constraint は次のいずれかを持たなければならない MUST:
  • 次の型の rightOperand プロパティ値を1つ:
    • literal、または IRI [rfc3987]、または RightOperand、または
    • 集合ベースの演算子の場合、literals のリスト、または IRIs [rfc3987] のリスト、または RightOperands のリスト;
  • 次の型の rightOperandReference プロパティ値を1つ:
    • IRI [rfc3987]、または
    • 集合ベースの演算子の場合、IRIs [rfc3987] のリスト;
    right operand 値への参照として用いる。
• Constraint は、rightOperand/Reference のデータ型のために dataType プロパティ値を 0個または1個持つことができる MAY。
• Constraint は、rightOperand/Reference の値に使用される単位を設定するために、 unit プロパティ値（型は IRI [rfc3987]）を 0個または1個持つことができる MAY。
• Constraint は、leftOperand action から生成される値、または比較の参照として設定される leftOperand に関連する値のために、status プロパティ値を 0個または1個持つことができる MAY。

leftOperand プロパティ値は、LeftOperand クラスのインスタンスとして定義される。 leftOperand インスタンスは、Constraint の意味論を示すために明確に 定義されなければならず MUST、 比較のための値をどのように取得または生成しなければならないかを宣言できる MAY。ODRL Common Vocabulary [odrl-vocab] は、 ODRL Profiles が使用できる MAY leftOperand を定義する。

operator プロパティ値は、Operator クラスのインスタンスとして定義される。 operator インスタンスは、left および right operands の間の「より大きい」または 「等しい」などの関係操作を識別する。

rightOperand プロパティ値は、RightOperand クラスのインスタンス、または IRIs、または Literal 値として定義される。rightOperand は、 leftOperand と比較される Constraint の値である。 rightOperandReference は、rightOperand の実際の値を得るために まず参照解決されなければならない MUST IRI を表す。 rightOperandReference は、rightOperand の値を まず IRI の参照解決から取得しなければならない MUST 場合に使用される。Constraint には rightOperand または rightOperandReference のいずれか一方だけが現れなければならない MUST。

rightOperand は値を表し、rightOperandReference は値を取得するために参照解決しなければならない IRI を表す。rightOperand が http://example.com/c100 であった場合、それは式で比較される値として解釈される。 rightOperandReference が同じ値 http://example.com/c100 であった場合、その IRI はまず参照解決されなければならず、 返されたデータが式で比較される値として解釈されなければならない。

dataType は、xsd:decimal や xsd:datetime などの  rightOperand/Reference の型を示し、unit は 「EU currency」などの rightOperand/Reference の単位値を示す。

status は、比較式で使用されなければならない MUST、leftOperand action から生成された値を 提供する。例えば、count constraint は rightOperand 値 10 と status 5 を持つことができる。これは、その action がすでに5回実行されており、 比較は現在の action を status 値と比較しなければならないことを意味する。

2.5.2 Logical Constraint クラス

Logical Constraint クラスは、既存の Constraints である2つ以上の operands を、1つの論理演算子で 比較する式に用いられる。比較が論理的一致を返す場合、 Logical Constraint は満たされる。そうでない場合は満たされない。 例えば、3つの Constraints が論理的に and で結合され、3つすべてが true でなければ Logical Constraint が満たされないことを示せる。

Logical Constraint クラスには次のプロパティがある:

• Logical Constraint は、その Logical Constraint を識別するために、uid プロパティ値（型は IRI [rfc3987]）を 0個または1個持つことができる MAY。
• Logical Constraint は、比較される既存 constraints の論理関係を示す operand サブプロパティを1つ持たなければならない MUST。その値は既存の Constraint インスタンスのリストである。

ODRL evaluator は、operand の次のサブプロパティをサポートしなければならない MUST:

• or - Constraints の少なくとも1つが満たされなければならない MUST
• xone - Constraints のうち1つのみ、かつそれ以上ではなく、満たされなければならない MUST
• and - すべての Constraints が満たされなければならない MUST
• andSequence - すべての Constraints が、順番に、満たされなければならない MUST

追加の operand サブプロパティは、ODRL Profiles によって定義できる MAY。

Logical Constraints に関する ODRL 検証要件には次が含まれる:

1. operand は、サブプロパティ or、xone、 and、andSequence のみでなければならない MUST。 operand の追加サブプロパティは、Logical Constraints の使用に限り、ODRL Profiles によって定義できる MAY。
2. すべての operand 値は、一意の Constraint インスタンスでなければならない MUST。

Constraint インスタンスは評価されなければならず MUST、 その結果は、論理関係が満たされるかどうかを判断するために用いられる（ operand サブプロパティの意味論に基づく）。

2.5.3 Rule に伴う Constraint プロパティ

Rule（Permission、Prohibition、または Duty など）は、Rule に対する条件を示すために constraint プロパティを含むことができる MAY。 この条件を満たすには、constraint プロパティによって参照されるすべての Constraints/Logical Constraints が満たされなければならない MUST。

ユースケース例: 下の Policy Offer の例では、permission は target asset を distribute することを許可し、その permission が 2018-01-01 までしか 実行できないという dateTime 条件の constraint を含む。

{
    "@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 Action に伴う Refinement プロパティ

Action は、Action 操作の意味論を直接狭める Constraint/Logical Constraint を示すために refinement プロパティを含むことができる MAY。 Action に対するより狭い意味論のこの条件を満たすには、 refinement プロパティによって参照されるすべての Constraints/Logical Constraints が、満たされた状態を生成するものとして使用されなければならない MUST。

注: Action に refinement を適用した結果は、null 操作になってはならない SHOULD NOT。

ユースケース例: 下の Policy Offer の例では、permission は target asset を print することを許可し、1200 dpi 以下の解像度という refinement Constraint も 含んでいる。この refinement は printing のより狭い意味論であり、この場合は特定の最大解像度で printing することである。

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

ユースケース例: 下の Policy は、target asset を online media または print media の いずれか一方で reproduce する permission を示すが、 両方ではない。これは、他の場所で宣言された2つの既存 Constraints を 参照する Logical Constraint（xone operand を伴う）として表現される。

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

2.5.5 Asset Collection に伴う Refinement プロパティ

AssetCollection は、完全なコレクションの個別 Asset(s) を識別する際の refinement context を示すために、refinement プロパティを含むことができる MAY。refinement プロパティは、 コレクションの各メンバーの特性に適用される（リソース全体には適用されない）。 完全な AssetCollection の個別 Asset(s) を識別するというこの条件を満たすには、 refinement プロパティによって参照されるすべての Constraints/Logical Constraints が 満たされなければならない MUST。

注: AssetCollection に refinements を適用した結果は、null 集合になってはならない SHOULD NOT。

refinement プロパティを使用する場合、uid プロパティは AssetCollection を識別するために使用してはならない MUST NOT。代わりに、 AssetCollection を参照するために source プロパティを 使用しなければならない MUST。

ユースケース例: この Policy は、マルチメディア動画の AssetCollection である target source http://example.com/media-catalogue を定義する。 target には、AssetCollection メンバーの特性を指定する refinement もある。この場合、 Assets の target subset は、running time が60分未満のものとなり、それらの各々を再生できる。なお、 runningTime leftOperand は、play action とともに ODRL Profile 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"
  }]
}

2.5.6 Party Collection に伴う Refinement プロパティ

PartyCollection は、完全なコレクションの個別 Party(ies) を識別する際の refinement context を示すために、refinement プロパティを含むことができる MAY。refinement プロパティは、 コレクションの各メンバーの特性に適用される（リソース全体には適用されない）。 完全な PartyCollection の個別 Party(ies) を識別するというこの条件を満たすには、 refinement プロパティによって参照されるすべての Constraints/Logical Constraints が 満たされなければならない MUST。

注: PartyCollection に refinements を適用した結果は、null 集合になってはならない SHOULD NOT。

refinement プロパティを使用する場合、uid プロパティは PartyCollection を識別するために使用してはならない MUST NOT。代わりに、 PartyCollection を参照するために source プロパティを 使用しなければならない MUST。

ユースケース例: target Asset http://example.com/myPhotos:BdayParty は、 写真の assigner http://example.com/user44 によってソーシャルネットワークサイトに 投稿された写真の集合である。assignee source は PartyCollection http://example.com/user44/friends であり、assigner のすべての friends を表す。 assignee には、collection のうち foaf:age が18を超えるメンバーのみに、 ex:view permission（Profile によって定義される）が割り当てられることを示す refinement もある。

{
  "@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.1 Permission クラス

Permission は、すべての refinements が満たされ、すべての constraints が 満たされ、かつすべての duties が履行されている場合に、 Asset に対して action が実行されることを許可する。

Permission クラスは Rule クラスのサブクラスであり、Rule クラスからすべてのプロパティを継承する。 さらに、次の追加のプロパティ意味論を持つ:

• Permission は、Asset 型の target プロパティ値を1つ持たなければならない MUST。（他の relation サブプロパティを使用できる MAY。）
• Permission は、機能的役割のために、Party 型の assigner および／または assignee プロパティ値を 0個または1個持つことができる MAY。（他の function サブプロパティを使用できる MAY。）
• Permission は、Duty 型の duty プロパティ値を 0個、1個、または複数持つことができる MAY。

注: 上記のプロパティ・カーディナリティは、規範的な ODRL 情報モデルを反映している。場合によっては、 一部のプロパティの繰り返し出現もサポートされる（Policy Rule Composition および Compact Policy に記述される）が、規範的な原子的 Policy は上記のプロパティ・カーディナリティと一致する。

duty プロパティは、履行されなければならない MUST 合意された義務を表す。すなわち、duty プロパティは Permission と Duty の間の事前条件を表明する。詳細については Permission に伴う Duty の節を参照。

ユースケース例: assigner http://example.com/org:xyz からの Policy Offer は、target Asset http//example.com/game:9090 に対する play action を表し、その permission は 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" }
       }]
   }]
}

2.6.2 Prohibition クラス

Prohibition は、すべての refinements が満たされ、すべての constraints が 満たされている場合に、Asset に対して action が実行されることを 禁止する。Prohibition が action の実行によって侵害された場合、 Prohibition の状態を未侵害に設定するために、すべての remedies が MUST 履行されなければならない。

Prohibition クラスは Rule クラスのサブクラスであり、Rule クラスからすべてのプロパティを継承する。 さらに、次の追加のプロパティ意味論を持つ:

• Prohibition は、Asset 型の target プロパティ値を1つ持たなければならない MUST。（他の relation サブプロパティを使用できる MAY。）
• Prohibition は、機能的役割のために、Party 型の assigner および／または assignee プロパティ値を 0個または1個持つことができる MAY。（他の function サブプロパティを使用できる MAY。）
• Prohibition は、Duty 型の remedy プロパティ値を 0個、1個、または複数持つことができる MAY。

注: 上記のプロパティ・カーディナリティは、規範的な ODRL 情報モデルを反映している。場合によっては、 一部のプロパティの繰り返し出現もサポートされる（Policy Rule Composition および Compact Policy に記述される）が、規範的な原子的 Policy は上記のプロパティ・カーディナリティと一致する。

remedy プロパティ（failure プロパティのサブプロパティ）は、 Prohibition が侵害された場合に履行されなければならない MUST 合意された義務を表す。すなわち、remedy プロパティは、 Prohibition の action が実行された場合に履行されなければならない Duty を表明する。詳細については Prohibition に伴う Remedy の節を参照。

ユースケース例: target Asset http://example.com/photoAlbum:55 の assigner は、 Permission と Prohibition の両方を持つ Agreement Policy を表す。assigner Party http://example.com/MyPix:55 は、assignee Party http://example.com/assignee:55 に Permission display を割り当てると同時に、 target Asset を archive する Prohibition を割り当てる。さらに、Policy 内で競合 （例: Permissions と Prohibitions の間）が発生した場合、Policy の conflict プロパティは perm に設定され、Permissions が優先されることを示す。

{
    "@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 クラス

Duty は、すべての refinements が満たされた状態で action を 実行する義務である。Duty は、すべての constraints が 満たされ、かつ、その action がすべての refinements が満たされた状態で 実行されている場合に履行される。その action が実行されていない場合、 Duty を履行するには、すべての consequence も履行されなければならない。 すなわち、consequences は、同様に履行されなければならない追加の Duties である。 （注: duty または obligation プロパティによって参照される Duties のみが consequence プロパティを使用できる。）

Duty クラスは Rule クラスのサブクラスであり、Rule クラスからすべてのプロパティを継承する。 さらに、次の追加のプロパティ意味論を持つ:

• Duty は、その Duty が直接適用される主対象である Asset を示すために、Asset 型の target プロパティ値を 0個または1個持つことができる MAY。 （他の relation サブプロパティを使用できる MAY。）
• Duty は、機能的役割のために、Party 型の assigner および／または assignee プロパティ値を 0個または1個持つことができる MAY。 （他の function サブプロパティを使用できる MAY。）
• Duty は、その Duty が duty または obligation プロパティを持つ Rule によって参照される場合にのみ、 Duty 型の consequence プロパティ値を 0個、1個、または複数持つことができる MAY。

注: 上記のプロパティ・カーディナリティは、規範的な ODRL 情報モデルを反映している。場合によっては、 一部のプロパティの繰り返し出現もサポートされる（Policy Rule Composition および Compact Policy に記述される）が、規範的な原子的 Policy は上記のプロパティ・カーディナリティと一致する。

Duty クラスには、次の追加要件もある:

• duty を実行する義務を負う Party は、Duty Action を実行する能力を持たなければならない MUST。
• duty を実行する義務を負う Party は、Duty を満たさなければならない MUST。

consequence プロパティ（failure プロパティのサブプロパティ）は、 Permission に対する合意された Policy obligation または duty を履行しないことの影響を表すために 利用される。これらのいずれかが履行されない場合、その結果として consequence Duties も同様に新たな要件となり、元の obligation または duty に加えて、 consequence Duties もすべて MUST 履行されなければならないことを意味する。

なお、consequence プロパティは、Permission duty または Policy obligation の consequence で すでにある Duty には使用してはならない MUST NOT。

2.6.4 Policy に伴う Obligation プロパティ

Policy は、Duty を履行する obligation を含むことができる MAY。 その obligation は、すべての constraints が満たされ、かつ、その action が すべての refinements が満たされた状態で実行されている場合に 履行される。

ユースケース例: 下の Agreement は、assigner http://example.com/org:43 から assignee http://example.com/person:44 への、 EU500.00 の支払い額について assigner に compensate する obligation を含む。

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

Policy は、obligation を履行しないことの consequence を含むこともできる MAY。

ユースケース例: 下の Agreement は、assigner http://example.com/org:43 から assignee http://example.com/person:44 への、 target Asset を delete する obligation を含む。obligation が履行されない場合、consequence として、 assigner は指名された慈善団体にも EU10.00 の支払いを compensate しなければならない MUST（obligation Duty の履行に加えて）。

{
    "@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 Permission に伴う Duty プロパティ

Duty は、Permission から Duty への duty プロパティ関係を用いて履行を要求する事前条件として 指定できる MAY。

Permission が複数の Duties を持つ場合、すべての Duties が履行されることに 合意されなければならない MUST。複数の Permissions が 同じ Duty（その uid プロパティによる）を参照する場合、その Duty は一度だけ 履行されればよい。

Duty に function サブプロパティが宣言されていない場合、これらの 機能的役割は、参照元 Permission で宣言されたものと同じになる。

ユースケース例: Party http://example.com/assigner:sony は、 target asset http://example.com/music/1999.mp3 を play する Offer を行う。 permission は、payAmount が $EU5.00 である refinement を持つ compensate action の duty を含む。duty には、event が policyUsage より小さいという constraint もあり、permission rule を実行する前に duty rule（すなわち compensation）を実行しなければならないことを意味する。

{
    "@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 Permission/Obligation Duty に伴う Consequence プロパティ

Permission の duty、および Policy の obligation は、その duty または obligation を履行しないことに対する consequence Duty を含むことができる MAY。 この場合、Permission/Obligation Duty の最終状態を 履行済みに設定するために、すべての consequence Duties も MUST 履行されなければならない。

consequence プロパティは、failure プロパティのサブプロパティである。consequence プロパティの詳細については Duty クラス の節を参照。

ユースケース例: assigner http://example.com/org:99 と assignee http://example.com/person:88 の間の下の Agreement は、assignee が Asset http://example.com/data:77 を distribute することを、asset を Party http://australia.gov.au/ に attribute する事前条件の下で許可する。 assignee が duty を履行しない場合、または duty を履行せずに asset を distribute する場合、 consequence として、assignee は http://example.com/dept:100 によって track されることにもなる。

{
    "@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 Prohibition に伴う Remedy プロパティ

remedy プロパティは、Prohibition が実行されることによって 侵害された場合に履行されなければならない MUST 合意された Duty を表す。Prohibition action が実行された場合、 その Prohibition の侵害に対処して状態を未侵害に設定するために、すべての remedy Duties が MUST 履行されなければならない。 remedy プロパティは failure プロパティのサブプロパティである。

remedy は、consequence Duty を含む Duty を参照してはならない MUST NOT。

ユースケース例: assigner http://example.com/person:88 と assignee http://example.com/org:99 の間の下の Agreement は、assignee が Asset http://example.com/data:77 を index することを禁止する。 assignee が実際に target asset を index した場合、remedy として assignee は target asset http://example.com/data:77 を anonymize しなければならない 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"
        }]
    }]
}

2.7.1 コンパクト Policy

ODRL Policy は、そのすべての Rules に共有され共通する、Policy レベルで宣言されたプロパティを 保持できる MAY。これは、よりコンパクトな serialisations をサポートするためのショートカット方法としてのみ意図されている。 これらの共有プロパティは、Policy レベルのプロパティ（Policy クラス節で 定義されたものなど）として解釈してはならない MUST NOT。

共有できる MAY プロパティ（下の図に示す）には次が含まれる:

• 1つまたは複数の action プロパティ。
• relation の1つまたは複数のサブプロパティ（target など）。
• function の1つまたは複数のサブプロパティ（assigner および assignee など）。

Policy 内のショートカットを展開するための ODRL 検証要件は次のとおりである:

1. Policy 内の各 Rule について:
   • 関連する共有プロパティ（Policy レベル）を検証する。
   • これらのプロパティを Rule に複製する。
2. Policy レベルで宣言された共有プロパティを削除する。

さらに、前の節で定義された ODRL 検証要件に従い、Policy 内に原子的 Rules を 作成する。

コンパクトな ODRL Policies は、適合性のために処理される際に原子的 Policies へ展開されることが 推奨される RECOMMENDED。

下の例は、そのような共有共通プロパティを Policy に適用したものを示す:

{
    "@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 検証要件に従って Policy の Permissions に 展開される方法を示す。

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