/
index.html
1321 lines (1062 loc) · 85 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en">
<head>
<title>ODRL Information Model</title>
<meta content="text/html; charset=utf-8" http-equiv="content-type" />
<meta content="width=device-width,initial-scale=1" name="viewport" />
<script class="remove" src="https://www.w3.org/Tools/respec/respec-w3c-common"></script>
<script class="remove" src="config.js"></script>
</head>
<body>
<section id="abstract">
<p>The Open Digital Rights Language (ODRL) provides a flexible and interoperable information model, vocabulary, and encoding mechanisms for describing statements about content usage. The ODRL Information Model describes the underlying concepts, entities, and relationships that form the foundational basis for the semantics of the ODRL statements. </p>
<p>Policies are used to explicitly state what are the permitted and prohibited actions over a certain resource. In addition, policies may be integrated with complex constraints (e.g., time constraints) which apply to such actions to impose further restrictions to the uses of the resource. </p>
</section>
<section id="sotd">
<p>
<strong>This is a work in progress. No section should be considered final, and the absence of any content does not imply that such content is out of scope, or may not appear in the future. If you feel something should be covered, please <a href="mailto:public-poe-comments@w3.org">tell us.</a></strong>
</p>
</section>
<section class="informative" id="intro">
<h2>Introduction</h2>
<p>Several business scenarios require to express what are the permitted and prohibited actions over content. These permitted/prohibited actions are usually expressed under the form of policies, i.e., entities that allow to indicate those uses and re-uses of the content which are comform with the existing regulations or to the constraints assigned by the owner. Policies may also be enriched with additional information, i.e., who are the entities in charge of the definition of such Policy and those who are required to conform to it, what are the additional constrains to be associated with the Permissions, Prohibitions and Duties expressed by the Policy. The ability to express these concepts and relationships is important both for the producers of content, i.e., they may state in a clear way what are the permitted and the prohibited actions to prevent misuses, and for the consumers, i.e., they may know precisely how they are allowed to use and re-use the content to avoid breaking the law or the owner's constraints. This specification describes a common approach to expressing these concepts, and more.</p>
<p>The ODRL Information Model defines the underlying semantic model for permission and obligation statements describing content usage. The information model covers the core concepts, entities and relationships that provide the foundational model for content usage statements. These machine-readable policies may be linked directly with the content they are associated to with the aim to allow consumers to easily retrieve those information.</p>
<section id="aimsModel">
<h3>Aims of the Model</h3>
<p>The primary aim of the ODRL Information Model is to provide a standard description model and format to express permission and obligation statements to be associated to content in general. These permission and obligation statements are employed to describe the terms of use and reuse of resources. The model should cover as many Permission and Obligation use cases as possible, while keeping the policy modeling easy even when dealing with complex uses.</p>
<p>The ODRL Information Model is a single, consistent model that can be used by all interested parties. All efforts have been made to keep the implementation costs for both content producers and consumers to a minimum. A single method of fulfilling a use case is strongly preferred over multiple methods, unless there are existing standards that need to be accommodated or there is a significant cost associated with using only a single method. While the Information Model is built using Linked Data principles, the design is intended to allow non-graph-based implementations also. </p>
</section>
<section id="serialization">
<h3>Serialization of the Model</h3>
<p>The ODRL Information Model is formally specified using UML notation [[!uml]].</p>
<p>The examples throughout the document are serialized as [[json-ld]]. For normative serialisations, please refer to the ODRL Vocabulary and Expression [[!vocab-odrl]].</p>
</section>
<section id="conformance"></section>
<section id="terminology">
<h3>Terminology</h3>
<dl class="termlist">
<dt><dfn>Policy</dfn></dt>
<dd>A Rule expressing what Action is allowed and/or disallowed over an Asset.</dd>
<dt><dfn>Rule</dfn></dt>
<dd>A Permission, Prohibition or Duty that expresses an Action that may, must not, or must be performed (respectively)</dd>
<dt><dfn>Action</dfn></dt>
<dd>An operation that is applicable to an Asset</dd>
<dt><dfn>Permission</dfn></dt>
<dd>An Action that may be performed over an Asset.</dd>
<dt><dfn>Prohibition</dfn></dt>
<dd>An Action that must not be performed over an Asset.</dd>
<dt><dfn>Duty</dfn></dt>
<dd>An Action that must be performed as a requirement for the applicable Permission to become valid.</dd>
<dt><dfn>Asset</dfn></dt>
<dd>An identifiable resource that is the subject of the Rule</dd>
<dt><dfn>Party</dfn></dt>
<dd>An identifiable entity who may undertake a Role in the Policy</dd>
<dt><dfn>Constraint</dfn></dt>
<dd>The context, such as limitations, restrictions, or interpretations, that must be applied to an Action.</dd>
</dl>
</section>
</section>
<section id="cgrel" class="informative">
<h2>Relationship to the W3C ODRL Community Group Reports</h2>
<p>The basis for the deliverables for the Permissions & Obligations Expression Working Group are the reports created by the <a href="https://www.w3.org/community/odrl/">W3C ODRL Community Group</a>. The ODRL Community Group has developed a family of specifications to support innovative expression of asset usage for the publication, distribution and consumption of content services.
The final outputs of the ODRL Community Group were the ODRL Version 2.1 specifications that were a major update for ODRL and superseded the original ODRL Version 1.1 [[odrl]] (published as a W3C NOTE).</p>
<p>The following documents are part of the ODRL Community Group report series:</p>
<ul>
<li>ODRL V2 Requirements [[odrl2-req]]</li>
<li>ODRL V2.1 Core Model [[odrl21-model]]</li>
<li>ODRL V2.1 Common Vocabulary [[odrl21-vocab]]</li>
<li>ODRL V2.1 XML Encoding [[odrl21-xml]]</li>
<li>ODRL V2.1 Ontology [[odrl21-onto]]</li>
<li>ODRL V2.1 JSON Encoding [[odrl21-json]]</li>
</ul>
<p>
The ODRL Information Model was derived from the ODRL V2.1 Core Model Community Group report. Details of the differences between the W3C Working Group deliverables and the ODRL Community Group Reports are maintained in the <a href="#community">Appendix</a>. All new ODRL implementations are expected to use the deliverables of the Permissions & Obligations Expression Working Group. </p>
</section>
<section id="infoModel">
<h2>ODRL Information Model</h2>
<p>The ODRL Information Model enables Policies to express Permissions and Prohibitions related to the usage of Assets. In essence, this explicitly expresses what is allowed and what is not allowed by the Policy, as well as other requirements and parties involved. The aim of the ODRL Information Model is to support flexible Policy expressions by allowing the author to include as much, or as little, expressive detail.</p>
<p>The figure below shows the ODRL Information Model. The Policy is the central entity that holds an ODRL policy together. </p>
<figure>
<img src="fig/00Model.svg" alt="ODRL Information Model" width="800"/>
<figcaption>ODRL Information Model</figcaption>
</figure>
<p>The ODRL Information Model diagram shows the Permission, Prohibition and Duty classes as subclasses of the abstract Rule concept. These Rules have common relationships to the other key concepts (specifically, Action, Asset, Party, and Constraint). However, there are core differences in their semantics:</p>
<ul>
<li>A Permission indicates that the Policy expresses an Action that MAY be performed,</li>
<li>A Prohibition indicates that the Policy expresses an Action that MUST NOT be performed, and</li>
<li>A Duty indicates that the Policy expresses an Action that MUST be performed (as a requirement to be granted a Permission). </li>
</ul>
<blockquote>
<p>As an example, a Permission in a Policy MAY allow a particular Action to be applied to an Asset, e.g., “play the audio file abc.mp3”. A Constraint, such as “at most 10 times”, MAY be added to express limitations to the Actions. The Party "VirtualMusicShop" that granted this Permission MAY be included with the Role Assigner, and the Party "Alice" that is granted the Permission MAY be included with the Role Assignee.</p>
</blockquote>
<p>Similar to Permissions, a Duty states that a certain Action MUST be executed by the Party with the Role Assignee for the Permission to be valid, e.g. “Alice must pay 5 Euros in order to get the Permission to play abc.mp3″.</p>
<section id="policy">
<h3>Policy</h3>
<p>The Policy entity has the following attributes:</p>
<ul>
<li>The Policy entity MUST refer to the <code>uid</code> identification of the Policy entity.</li>
<li>The Policy entity MUST refer to the <code>type</code> indicating the specific type of Policy entity.</li>
<li>The Policy entity MAY refer to the <code>conflict</code> attribute indicating how to handle Policy conflicts.</li>
<li>The Policy entity MAY refer to the <code>undefined</code> attribute indicating how to handle undefined Actions.</li>
<li>The Policy entity MAY refer to the <code>inheritAllowed</code> attribute indicating the Policy entity can be inherited by other Policies.</li>
<li>The Policy entity MAY refer to the ODRL <code>profile</code> identifier that this Policy conforms to.</li>
</ul>
<p>The values for the Policy entity’s <code>type</code> attribute are described in the ODRL vocabulary [[!vocab-odrl]] or in ODRL Profiles. The Policy <code>type</code> describes the context of use of the Policy and MAY include additional constraints that processing systems MUST understand.</p>
<blockquote>
<p> For example, the "Agreement" Policy type stipulates minimal cardinalities for some for the Information Model entities, which are different than the "Offer" Policy type. In addition, and more importantly, the "Agreement" Policy type expresses that the Permissions/Prohibitions have been granted, but the "Offer" Policy type does not. </p>
</blockquote>
<p>To illustrate the concepts described in the Information Model, we will start from basic examples to come to more sophisticated ones when concepts are discussed in more details. </p>
<blockquote>
<p>Example Use Case: The below "Set" Policy type grants the Permission to read and the Prohibition to reproduce the target Asset http//example.com/asset:9898. No Parties or other elements are involved.</p>
</blockquote>
<pre class="example hljs xquery">{
<span class="hljs-string">"@context"</span>: {
<span class="hljs-string">"odrl"</span>: <span class="hljs-string">"http://www.w3.org/ns/odrl/2/"</span>
},
<span class="hljs-string">"@type"</span>: <span class="hljs-string">"odrl:Set"</span>,
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"http://example.com/policy:1010"</span>,
<span class="hljs-string">"permission"</span>: [{
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/asset:9898"</span>,
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:read"</span>
}],
<span class="hljs-string">"prohibition"</span>: [{
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/asset:9898"</span>,
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:reproduce"</span>
}]
}
</pre>
<div class="note">
<P>For the examples in this document, the ODRL Information Model <code>uid</code> and <code>type</code> attributes are mapped to the JSON-LD <code>@id</code> and <code>@type</code> tokens.</P>
</div>
<blockquote>
<p>Example Use Case: The below "Set" Policy type states that the Asset http//example.com/asset:9898 is the target of the Permission to perform the action reproduce, the Duty to perform the action attribute to http://example.com/owner:9898, and the Prohibition to perform the action translate. Two Parties are involved, namely the Assigner of the Permission and the Party to be attributed.</p>
</blockquote>
<pre class=" example hljs xquery">{
<span class="hljs-string">"@context"</span>: {
<span class="hljs-string">"odrl"</span>: <span class="hljs-string">"http://www.w3.org/ns/odrl/2/"</span>
},
<span class="hljs-string">"@type"</span>: <span class="hljs-string">"odrl:Set"</span>,
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"http://example.com/policy:1010"</span>,
<span class="hljs-string">"permission"</span>: [{
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/asset:9898"</span>,
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:reproduce"</span>,
<span class="hljs-string">"assigner"</span>: <span class="hljs-string">"http://example.com/assigner:88"</span>,
<span class="hljs-string">"duty"</span>: [{
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:attribute"</span>,
<span class="hljs-string">"attributedParty"</span>: <span class="hljs-string">"http://example.com/owner:9898"</span>
}]
}],
<span class="hljs-string">"prohibition"</span>: [{
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/asset:9898"</span>,
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:translate"</span>
}]
}
</pre>
<section id="composition">
<h4>Policy Composition</h4>
<p>The ODRL Information Model supports flexibility in the composition of the information entities used to declare ODRL expressions. A Policy MAY contain multiple Rules, and each Rule MAY contain multiple Assets, Parties, Actions, Constraints, and Duties. A Policy MAY also contain Assets, Parties, and Actions at the Policy level, and these entities apply to all of the enclosing Rules in the Policy.</p>
<p>At the basic level, an ODRL Rule would refer to one Asset, one or more Parties, one Action, and potentially one Constraint and/or Duty, as shown in the example below. This example shows the <em>atomic</em> level of a Policy where it is <em>irreducible</em> and <em>unambiguous</em>.</p>
<pre class="example hljs xquery">
{
"@context": {
"odrl": "http://www.w3.org/ns/odrl/2/"
},
"@type": "odrl:Agreement",
"@id": "http://example.com/policy:8888",
"permission": [{
"target": "http://example.com/music/1999.mp3",
"assigner": "http://example.com/org/sony-music",
"assignee": "http://example.com/people/billie",
"action": "odrl:play",
"constraint": "...",
"duty": "..."
}]
}]
}
</pre>
<p>As multiple Assets, Parties, and Actions can be expressed for each Rule, then the following (snippet) example shows two Assets defined for the policy:</p>
<pre class="example hljs xquery">
"permission": [{
"target": "http://example.com/music/1999.mp3",
"target": "http://example.com/music/PurpleRain.mp3",
"assigner": "http://example.com/org/sony-music",
"assignee": "http://example.com/people/billie",
"action": "odrl:play",
"constraint": "...",
"duty": "..."
}]
</pre>
<p>The above example could then be reduced to two <em>atomic</em> Rules, with the two target assets appearing individually in each:</p>
<pre class="example hljs xquery">
"permission": [{
"target": "http://example.com/music/1999.mp3",
"assigner": "http://example.com/org/sony-music",
"assignee": "http://example.com/people/billie",
"action": "odrl:play",
"constraint": "...",
"duty": "..."
}]
"permission": [{
"target": "http://example.com/music/PurpleRain.mp3",
"assigner": "http://example.com/org/sony-music",
"assignee": "http://example.com/people/billie",
"action": "odrl:play",
"constraint": "...",
"duty": "..."
}]
</pre>
<p>In order to create the <em>atomic</em> Rules in a Policy, the processing model for policies with multiple Assets, Parties, and Actions includes:</p>
<ol>
<li>Where there are multiple Assets (with the same Relation), then create new Rules (one for each of these Assets) and include one Asset relation, and include all other (non-Asset) entities.</li>
<li>Where there are multiple Parties (with the same Role), then create new Rules (one for each of these Parties) and include one Party Role, and ainclude all other (non-Party Role) entities.</li>
<li>Where there are multiple Actions, then create new Rules (one for each of these Actions) and include one Action, and include all other (non-Action) entities.</li>
</ol>
<p>An ODRL Policy MAY also declare multiple Assets, Parties, and Actions at the Policy level (not just within a Rule). This implies that these entities are all common to all the Rules in the Policy, as shown in the below example:</p>
<pre class="example hljs xquery">
{
"@context": {
"odrl": "http://www.w3.org/ns/odrl/2/"
},
"@type": "odrl:Agreement",
"@id": "http://example.com/policy:8888",
"target": "http://example.com/music/1999.mp3",
"assigner": "http://example.com/org/sony-music",
"action": "odrl:play",
"permission": [{
"assignee": "http://example.com/people/billie"
},
{
"assignee": "http://example.com/people/murphy"
}]
}]
}
</pre>
<p>To fully expand the Rules, the Policy-level Assets, Parties, and Actions MUST be added to all the Rules in the Policy. As shown below, the policy-level Target, Assigner, and Action are added to the two permission Rules:</p>
<pre class="example hljs xquery">
{
"@context": {
"odrl": "http://www.w3.org/ns/odrl/2/"
},
"@type": "odrl:Agreement",
"@id": "http://example.com/policy:8888",
"permission": [{
"target": "http://example.com/music/1999.mp3",
"assigner": "http://example.com/org/sony-music",
"action": "odrl:play",
"assignee": "http://example.com/people/billie"
},
{
"assignee": "http://example.com/people/murphy"
"target": "http://example.com/music/1999.mp3",
"assigner": "http://example.com/org/sony-music",
"action": "odrl:play",
}]
}]
}
</pre>
<p>The processing model for Policies with multiple Assets, Parties, and Actions declared at the Policy-level includes:</p>
<ol>
<li>Replicate all Policy-level Assets in each and all Permission/Prohibition Rules.</li>
<li>Replicate all Policy-level Parties in each and all Permission/Prohibition Rules.</li>
<li>Replicate all Policy-level Actions in each and all Permission/Prohibition Rules.</li>
<li>Follow the processing model (defined above) to create <em>atomic</em> Rules in the Policy.</li>
</ol>
</section>
<section id="provenace">
<h4>Policy Provenance</h4>
<p>Provenance attributes MAY be added to the Policy entity to support additional authenticity, and integrity purposes from external vocabularies. The ODRL Information Model recommends the use of Dublin Core Metadata Terms [[!dcterms]] for ODRL Policies.</p>
<p>The following Dublin Core Metadata Terms [[!dcterms]] SHOULD be used:</p>
<ul>
<li>dc:creator - the individual, agent, or organisation that authored the Policy.</li> <li>dc:description - a human-readable representation or summary of the Policy.</li>
<li>dc:issued - the date (and time) the Policy was first issued.</li>
<li>dc:modified - the date (and time) the Policy was updated.</li>
<li>dc:coverage - the jurisdiction under which the Policy is relevant.</li>
<li>dc:replaces - the identifier (uid) of a Policy that this Policy supersedes.</li>
<li>dc:isReplacedBy - the identifier (uid) of a Policy that supersedes this Policy.</li>
</ul>
<p>The processing model for Policies with the above provenance properties include:</p>
<ol>
<li>If a Policy contains the <strong>dc:isReplacedBy</strong> property, then the identified Policy MUST be retrieved and processed.</li>
</ol>
<blockquote>
<p>Example Use Case:The below example contains provenace properties that indicate who created the Policy, when the Policy was issued, which jurisdiction (Queensland, Australia) the Policy applies to, and an older version of the Policy it replaces.</p> </blockquote>
<pre class="example hljs xquery">
{
"@context": [{ "odrl": "http://www.w3.org/ns/odrl/2/",
"dc": "http://purl.org/dc/terms/" }],
"@type": "odrl:Agreement",
"@id": "http://example.com/policy:8888",
"dc:creator": "billie@example.com",
"dc:issued": "2017-01-01:12:00",
"dc:coverage": "https://www.iso.org/obp/ui/#iso:code:3166:AU-QLD",
"dc:replaces": "http://example.com/policy:8887",
"permission": [{ ... }]
}
</pre>
</section>
<section id="conflict">
<h4>Policy Conflict Strategy</h4>
<p>The <code>conflict</code> attribute is used to establish strategies to resolve conflicts that arise from the merging of Policies or conflicts between Permissions and Prohibitions in the same Policy. Conflicts may arise when merging Policies about the same Asset and the resultant Actions are inconsistent.</p>
<p>The <code>conflict</code> attribute MUST take one of the following values:</p>
<ul>
<li><code>perm</code>: the Permissions MUST override the Prohibitions</li>
<li><code>prohibit</code>: the Prohibitions MUST override the Permissions</li>
<li><code>invalid</code>: the entire Policy MUST be invalid if any conflict is detected</li>
</ul>
<p>If the <code>conflict</code> attribute is not explicitly set, the default value of <code>invalid</code> will be used.</p>
<p>If an ODRL processor does not detect any conflicts in the Rules, then the ODRL Policy is valid, otherwise the ODRL processor MUST follow these processing rules:</p>
<ol>
<li>If a Policy has the <code>conflict</code> attribute of <code>perm</code> then any conflicting Permission Rule MUST override the Prohibition Rule and continue with the Policy as valid.</li>
<li>If a Policy has the <code>conflict</code> attribute of <code>prohibit</code> then any conflicting Prohibition Rule MUST override the Permission Rule and continue with the Policy as valid.</li>
<li>If a Policy has the <code>conflict</code> attribute of <code>invalid</code> then processing MUST not continue and the entire Policy MUST be invalid.</li>
<li>If a Policy has multiple <code>conflict</code> attribute values (for example, after a Policy merge or inheritance) then processing MUST not continue and the entire Policy MUST be invalid.</li>
</ol>
<blockquote>
<p>Example Use Case: Two Policies are associated to the same target Asset http://example.com/asset:1212. The first Policy http://example.com/policy:0001 allows to use the Asset. The second Policy http://example.com/policy:0002 allows for the display of the Asset, but it prohibits print. Both policies explicitly state how to deal with conflicts through the <code>conflict</code> attribute being set to <code>perm</code>. Hence the Permissions will always override any Prohibitions. In this use case, since the print Action is a subset of the use Action, there could be a conflict. However, the <code>perm</code> conflict strategy means that the use Permission will override the print Prohibition.</p>
</blockquote>
<pre class="example hljs xquery">{
<span class="hljs-string">"@context"</span>: {
<span class="hljs-string">"odrl"</span>: <span class="hljs-string">"http://www.w3.org/ns/odrl/2/"</span>
},
<span class="hljs-string">"@type"</span>: <span class="hljs-string">"odrl:Set"</span>,
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"http://example.com/policy:0001"</span>,
<span class="hljs-string">"conflict"</span>: <span class="hljs-string">"perm"</span>,
<span class="hljs-string">"permission"</span>: [{
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/asset:1212"</span>,
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:use"</span>,
<span class="hljs-string">"assigner"</span>: <span class="hljs-string">"http://example.com/owner:181"</span>
}]
}
</pre>
<pre class="example hljs xquery">{
<span class="hljs-string">"@context"</span>: {
<span class="hljs-string">"odrl"</span>: <span class="hljs-string">"http://www.w3.org/ns/odrl/2/"</span>
},
<span class="hljs-string">"@type"</span>: <span class="hljs-string">"odrl:Set"</span>,
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"http://example.com/policy:0002"</span>,
<span class="hljs-string">"conflict"</span>: <span class="hljs-string">"perm"</span>,
<span class="hljs-string">"permission"</span>: [{
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/asset:1212"</span>,
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:display"</span>,
<span class="hljs-string">"assigner"</span>: <span class="hljs-string">"http://example.com/owner:182"</span>
}]
<span class="hljs-string">"prohibition"</span>: [{
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/asset:1212"</span>,
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:print"</span>
}]
}</pre>
<p>In the above use case, if the second Policy had the conflict value of <code>prohibit</code>, then the outcome would be a direct contradiction, and the result will be an invalid Policy.</p>
</section>
<section id="undefined">
<h4>Undefined Actions</h4>
<div class="issue" data-number="105">
<p>The detection of undefined actions is viewed to be implementation-specific, and too vague to be part of the Information Model. This feature maybe removed in future versions.</p>
</div>
<p>The <code>undefined</code> attribute is used to indicate how to process unsupported Actions. That is, if an ODRL expression contains an Action that is not from a known (or supported) ODRL vocabulary, how should the Action be treated in the context of the whole ODRL Policy?</p>
<p>The <code>undefined</code> attribute MUST take one of the following values:</p>
<ul>
<li><code>support</code>: the undefined Action is to be <strong>supported</strong> as part of the Policy – and the Policy remains valid</li>
<li><code>ignore</code>: the undefined Action is to be <strong>ignored</strong> and is not part of the Policy – and the Policy remains valid</li>
<li><code>invalid</code>: the undefined Action is unknown – and the entire Policy is <strong>invalid</strong></li>
</ul>
<p>In all cases, systems that process ODRL expressions SHOULD provide mechanisms that adequately address these three outcomes. That is, how the Action can be <strong>supported</strong>, or <strong>ignored</strong>, or the entire Policy is <strong>invalid</strong>. </p>
<p>If the <code>undefined</code> attribute is not explicitly set, its default value of <code>invalid</code> SHALL be used.</p>
<p>The processing model for undefined actions includes:</p>
<ol>
<li>If a Policy has the <code>undefined</code> attribute of <code>support</code> and there are actions in the Policy now known to the processing system, then the processing system MUST support these actions as part of the valid Policy.</li>
<li>If a Policy has the <code>undefined</code> attribute of <code>ignore</code> and there are actions in the Policy now known to the processing system, then the processing system MUST disregard these actions as part of the valid Policy.</li>
<li>If a Policy has the <code>undefined</code> attribute of <code>invalid</code> and there are actions in the Policy now known to the processing system, then the processing system MUST process the entire Policy as invalid.</li>
<li>If a Policy has multiple <code>undefined</code> attribute values (for example, after a Policy merge) AND there are actions in the Policy now known to the processing system, then the entire Policy MUST be processed as invalid.</li>
</ol>
<blockquote>
<p>Example Use Case: A Policy of type Set states that the Asset can be <em>recorded</em>. The processing system does not understand this Action, and since the <strong>undefined</strong> attribute is <strong>invalid</strong>, then the entire Policy is deemed invalid.</p>
</blockquote>
<pre class="example hljs xquery">
{
"@context": {
"odrl": "http://www.w3.org/ns/odrl/2/"
},
"@type": "odrl:Set",
"@id": "http://example.com/policy:8888",
"undefined": "invalid",
"permission": [{
"target": "http://example.com/music/1999.mp3",
"action": "http://example.com/ns/recorded"
}]
}]
}
</pre>
</section>
<section id="inhertiance">
<h4>Policy Inheritance</h4>
<p>ODRL supports a simple inheritance mechanism in which a (child) Policy may inherit all the information entities that the (parent) Policy is composed of. ODRL inheritance is aimed at <em>including</em> information entities from parent to child Policies.</p>
<p>The <code>inheritAllowed</code> attribute in the Policy entity is used to indicate if the Policy expression can be used in any inheritance relationship. If present, the value of the <code>inheritAllowed</code> attribute MUST take one of the following values:</p>
<ul>
<li><code>true</code>: the Policy expression can be used for inheritance</li>
<li><code>false</code>: the Policy expression can not be used for inheritance</li>
</ul>
<p>If the <code>inheritAllowed</code> attribute is not explicitly set, its default value of <code>true</code> will be used.</p>
<p>The following attributes SHOULD be used in a child Policy that is inheriting from a parent Policy in which that parent Policy MUST allow inheritance (via the <code>inheritAllowed</code> attribute) :</p>
<ul>
<li><code>inheritFrom</code>: the identifier of the parent Policy from which this child Policy inherits from</li>
<li><code>inheritRelation</code>: the identifier of the relationship context for this inheritance</li>
</ul>
<p>The <code>inheritFrom</code> association in the (child) Policy will uniquely identify (via a UID) the (parent) Policy from which the inheritance will be performed.</p>
<p>The <code>inheritRelation</code> attribute in the (child) Policy will uniquely identify (via a UID) the context of inheritance from the (parent) Policy. This may indicate the business scenario, such as <em>subscription</em>, or prior arrangements between the Parties (that are not machine representable). Such terms SHOULD be defined in the ODRL vocabulary [[!vocab-odrl]] or ODRL Profiles.
<blockquote>
<p>For example, an Assigner and Assignee may have a historical arrangement related to the specific use of content they make available to each other. The business model (identified with a URI) is used in the <code>inheritRelation</code> attribute in their subsequent ODRL Policies they exchange. This will require the ODRL Policy to be interpreted with the additional information identified by the URI. For example, this may include additional permission Actions or constraints (etc) that is documented in their business model arrangement.</p>
</blockquote>
<p>Both the <code>inheritFrom</code> association and <code>inheritRelation</code> attribute may be used independently.</p>
<p>The following restrictions apply when using inheritance:</p>
<ul>
<li>Single inheritance is only supported. (One parent Policy to one or more child Policy entities. No child Policy can inherit from two or more parent Policy entities.)</li>
<li>Inheritance can be to any depth. (Multiple levels of children Policy entities.)</li>
<li>Inheritance MUST NOT be circular.</li>
<li>No state information is transferred from the parent Policy to the child Policy.</li>
</ul>
<blockquote>
<p>Example Use Case: Consider the parent Policy http://example.com/policy:3333 that has been expressed primarly for inheritance purposes:</p>
</blockquote>
<pre class="example hljs xquery">
{
"@context": {
"odrl": "http://www.w3.org/ns/odrl/2/"
},
"@type": "odrl:Set",
"@id": "http://example.com/policy:3333",
"target": "http://example.com/asset:3333",
"assigner": "http://example.com/boss:0001",
"permission": [{
"action": "odrl:use"
}]
}
</pre>
<p>The child Policy http://example.com/policy:4444 includes the inheritFrom attribute pointing to the parent Policy http://example.com/policy:3333. The child Policy also includes its own specific policy-level asset, and two Permission Rules.</p>
<pre class="example hljs xquery">
{
"@context": {
"odrl": "http://www.w3.org/ns/odrl/2/"
},
"@type": "odrl:Agreement",
"@id": "http://example.com/policy:4444",
"inheritFrom": "http://example.com/policy:3333",
"target": "http://example.com/asset:5555",
"permission": [{
"assignee": "http://example.com/guest:0001",
"action": "odrl:display"
}],
"permission": [{
"assignee": "http://example.com/guest:0002",
"action": "odrl:print"
}]
}
</pre>
<p>After the inheritance is performed - where the (parent) Policy information compositions are added to the (child) Policy - the resulting Policy is as follows:</p>
<pre class="example hljs xquery">
{
"@context": {
"odrl": "http://www.w3.org/ns/odrl/2/"
},
"@type": "odrl:Agreement",
"@id": "http://example.com/policy:4444",
"target": [
"http://example.com/asset:5555",
"http://example.com/asset:3333" ]
"assigner": "http://example.com/boss:0001",
"permission": [{
"assignee": "http://example.com/guest:0001",
"action": "odrl:display"
}],
"permission": [{
"assignee": "http://example.com/guest:0002",
"action": "odrl:print"
}],
"permission": [{
"action": "odrl:use"
}]
}
</pre>
<p>The processing model for ODRL Policy Inheritance includes:</p>
<ol>
<li>A (child) Policy with an <code>inheritFrom</code> attribute MUST first verify that the (parent) Policy does not contain the <code>inheritAllowed</code> attribute with the value "false".</li>
<li>The (child) Policy MUST access the (parent) Policy and replicate the following in the (child) Policy:
<ul>
<li>All policy-level Assets, Parties, Actions.</li>
<li>All Permission and Prohibition Rules.</li>
</ul>
</li>
<li>The (child) Policy can then be further expanded (into <em>atomic</em> Rules) by following the processing models defined in the <a href="#composition">Policy Composition</a> section.</li>
</ol>
</section>
</section>
<section id="asset">
<h3>Asset</h3>
<p>The Asset entity is a resource that is the subject of an ODRL Rule. The Asset entity can be any form of identifiable resource, such as data/information, content/media, applications, or services. Furthermore, it can be used to represent other <code>Asset</code> entities that are needed to undertake the Policy expression, such as with the Duty entity. The Asset entity is referred to by the Permission and/or Prohibition entities, and also by the Duty entity.</p>
<p>The Asset entity has the following attributes:</p>
<ul>
<li>The Asset entity MUST refer to <code>uid</code> identification of the Asset</li>
<li>The Asset entity MAY refer to the <code>scope</code> defining how the Asset shall be interpreted under different contexts.</li>
</ul>
<p>The identification of the Asset entity is a key foundation of the ODRL Policy language. In general, the <code>uid</code> SHOULD be a URI [[rfc3986]] representing the identifier of the Asset. There MAY also be other alternative identifiers, or identification mechanisms that could be used. For example, to identify specific parts of an Asset, Media Fragments URI [[media-frags]] may be utilised. To identify groups or a range of Assets, then POWDER [[powder-primer]], URI Templates [[rfc6570]], or URI wildcards may be utilised. To identify inline/indirect Assets, then URI fragments may be used. <p>
<p>Since ODRL Policies could deal with any kind of asset, the ODRL Information Model does not provide additional metadata to describe Asset entities of particular media types. It is recommended to use already existing metadata standards, such as <a href="http://dublincore.org/documents/dcmi-terms/" rel="external nofollow">Dublin Core Metadata Terms</a> that are appropriate to the Asset type or purpose.</p>
<section id="relation">
<h4>Relation</h4>
<p>The Relation entity is an association class and is used to link to an Asset from either Rule, indicating how the Asset SHOULD be utilised in respect to the entity that links to it.</p>
<p>The Relation entity has the the following attribute:</p>
<ul>
<li>The Relation entity MUST refer to the <code>relation</code> indicating the relationship of the Asset to the Rule.</li>
</ul>
<p>The default value for the <code>relation</code> attribute is <code>target</code> which indicates that the Asset is the primary object to which the Rule actions apply.</p>
<p>Other values for the Relation entity SHOULD be defined in the ODRL Vocabulary [[!vocab-odrl]] and ODRL Profiles.</p>
<blockquote>
<p>Example Use Case: The Party http//example.com/guest:0001 wants to display the target Asset http://example.com/asset:3333, but she needs to be granted with the Permission to do so first. This request can be implemented through a Policy of the type Request asking for the Permission to display Asset http://example.com/asset:3333.</p>
</blockquote>
<pre class="example hljs xquery">{
<span class="hljs-string">"@context"</span>: {
<span class="hljs-string">"odrl"</span>: <span class="hljs-string">"http://www.w3.org/ns/odrl/2/"</span>
},
<span class="hljs-string">"@type"</span>: <span class="hljs-string">"odrl:Request"</span>,
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"http://example.com/policy:3333"</span>,
<span class="hljs-string">"permission"</span>: [{
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/asset:3333"</span>,
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:display"</span>,
<span class="hljs-string">"assignee"</span>: <span class="hljs-string">"http://example.com/guest:0001"</span>
}]
}</pre>
<div class="note">
<p>In the above example, the JSON-LD representation for Relation directly uses <code>target</code> as the token, as this has been mapped as a sub-property of the <code>relation</code> property.</p>
</div>
<blockquote>
<p>Example Use Case: The below Policy shows the index action Permission on the target Asset http://example.com/archive1011. Another Asset relation (x:collection) is also expressed to indicate the Asset (http://example.com/x/database) the indexing outcome should be stored in. (These semantics would be defined by the community who created the x:collection relation.)</p>
</blockquote>
<pre class="example hljs xquery">{
<span class="hljs-string">"@context"</span>: {
<span class="hljs-string">"odrl"</span>: <span class="hljs-string">"http://www.w3.org/ns/odrl/2/"</span>
},
<span class="hljs-string">"@type"</span>: <span class="hljs-string">"odrl:Set"</span>,
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"http://example.com/policy:1011"</span>,
<span class="hljs-string">"permission"</span>: [{
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/archive1011"</span>,
<span class="hljs-string">"x:collection"</span>: <span class="hljs-string">"http://example.com/x/database"</span>,
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:index"</span>
}]
}</pre>
</section>
<section id="asset-scope">
<h4>Scope</h4>
<p>The <code>scope</code> attribute SHOULD be used to indicate the context under which to interpret the Asset entity. The purpose of <code>scope</code> is to provide additional information about the Asset. For example, the Asset identifier may refer to a resource with many characteristics, but the scope may limit that to only one specific characteristic.</p>
<p>The <code>scope</code> attribute URI values SHOULD be defined in the ODRL vocabulary [[!vocab-odrl]] and ODRL Profiles.</p>
</section>
<blockquote>
<p>Example Use Case: The Policy defines a target Asset http://example.com/media-catalogue that has a scope of http://example.com/imt/jpeg (which, in this case, provides additional context on what characteristics the Asset MUST hold).</p>
</blockquote>
<pre class="example hljs xquery">{
<span class="hljs-string">"@context"</span>: {
<span class="hljs-string">"odrl"</span>: <span class="hljs-string">"http://www.w3.org/ns/odrl/2/"</span>
},
<span class="hljs-string">"@type"</span>: <span class="hljs-string">"odrl:Offer"</span>,
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"http://example.com/policy:4444"</span>,
<span class="hljs-string">"permission"</span>: [{
<span class="hljs-string">"target"</span>: [{
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"http://example.com/media-catalogue"</span>,
<span class="hljs-string">"scope"</span>: <span class="hljs-string">"http://example.com/imt/jpeg"</span>
}],
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:use"</span>,
<span class="hljs-string">"assigner"</span>: <span class="hljs-string">"http://example.com/user88"</span>
}]
}</pre>
</section>
<section id="party">
<h3>Party</h3>
<p>The Party entity can be any form of identifiable entity who undertakes a role in the Policy, such as a person, group of people, organisation, or agent. An agent is a person or thing that takes an active Role or produces a specified effect. The Party performs (or does not perform) Actions or has a function in a Duty (i.e., assigns the Party to the Rule by associating it with the Role it plays in the Rule).</p>
<p>The Party entity has the following attributes:</p>
<ul>
<li>The Party entity MUST refer to <code>uid</code> identification of the Party</li>
<li>The Party entity MUST refer to the <code>function</code> role fulfilled by a Party.</li>
<li>The Party entity MAY refer to the <code>scope</code> defining how the role shall be interpreted under different contexts.</li>
</ul>
<p>The ODRL Information Model does not provide additional metadata for the Party element. It is recommended to use existing metadata standards, such as the W3C vCard Ontology [[vcard-rdf]] or FOAF [[foaf]], that are appropriate to the Party type.</p>
<section id="role">
<h4>Role</h4>
<p>The Role entity is an association class that is used to link a Party from a Rule, to indicate what Role the Party takes with respect to the entity that links to it.</p>
<p>The Role entity has the following attributes:</p>
<ul>
<li>The Role entity MUST refer to the <code>function</code> role the Party is undertaking.</li>
</ul>
<p>The <code>function</code> attribute MUST support the following role values:</p>
<ul>
<li><code>assigner</code>: indicates the Party that is issuing the Policy. For example, the Party granting a Permission or requiring a Duty to be performed.</li>
<li><code>assignee</code>: indicates that the Party that is the recipient the Policy. For example, the Party being granted a Permission or required to perform a Duty.</li>
</ul>
<p>Other values for the <code>function</code> role attribute MAY be defined in the ODRL vocabulary [[!vocab-odrl]] and ODRL Profiles.</p>
<blockquote>
<p>Example Use Case: The Policy shows an Agreement with two parties with the functional roles of the assigner and the assignee. The assigner grants the assignee the play action over the target asset. In additiion, both parties are further described with properties from an external vocabulary and their types are clearly indicated.</p>
</blockquote>
<pre class="example hljs xquery">
{
"@context": [{ "odrl": "http://www.w3.org/ns/odrl/2/",
"vCard": "http://www.w3.org/2006/vcard/ns#" }],
"@type": "odrl:Agreement",
"@id": "http://example.com/policy:8888",
"permission": [{
"target": "http://example.com/music/1999.mp3",
"assigner": {
"@type": [ "odrl:Party", "vcard:Organization" ],
"@id": "http://example.com/org/sony-music",
"vcard:fn": "Sony Music LCC",
"vcard:hasEmail": "sony-contact@example.com" },
"assignee": {
"@type": [ "odrl:Party", "vcard:Individual" ],
"@id": "http://example.com/people/billie",
"vcard:fn": "Billie Zhan",
"vcard:hasEmail": "billie@example.com"},
"action": "odrl:play"
}]
}
</pre>
<div class="note">
<p>In the above example, the JSON-LD representation for Role directly uses <code>assigner</code> and <code>assignee</code> as the token, as this has been mapped as sub-properties of the <code>function</code> property.</p>
</div>
</section>
<section id="party-scope">
<h4>Scope</h4>
<p>The <code>scope</code> attribute SHOULD be used to indicate the context under which to interpret the Party entity. The purpose of <code>scope</code> is to provide additional information about the Party that may also reduce the extent of the Party identifier. For example, the Party identifier may refer to all users at a University, but the scope may contextualise that to only fulltime staff members at the University.</p>
<p>The <code>scope</code> attribute SHOULD take one of the following values:</p>
<ul>
<li><code>individual</code>: indicates that the Party entity is a single individual. The linked Permission, Duty or Prohibition is applicable for that individual only.</li>
<li><code>group</code>: indicates that the Party entity represents a group. The group consisting of many individual members. The linked Permission, Duty or Prohibition is applicable for each member of that group. For example, a Permission to play a movie 5 times is valid for each Party member or the Duty to pay 3 EUR has to be fulfilled by each Party member.</li>
</ul>
<p>Other URI values for the <code>scope</code> attribute SHOULD be defined in the ODRL vocabulary [[!vocab-odrl]] and ODRL Profiles.</p>
</section>
<blockquote>
<p>Example Use Case: The target Asset http://example.com/myPhotos:BdayParty are a set of photos posted to a social network site by the Assigner of the photos http://example.com/user44. The Assignee is a Party http://example.com/user44/friends, and represents all the friends of the Assigner. Since this is a collection of individuals, then the group scope is declared. In addtion, the scope of the Assignee has been also be declared as http://example.com/people/age/18+ (which, in this case, provides additional context on what characteristics the Assignee MUST hold).</p>
</blockquote>
<pre class="example hljs xquery">{
<span class="hljs-string">"@context"</span>: {
<span class="hljs-string">"odrl"</span>: <span class="hljs-string">"http://www.w3.org/ns/odrl/2/"</span>
},
<span class="hljs-string">"@type"</span>: <span class="hljs-string">"odrl:Agreement"</span>,
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"http://example.com/policy:4444"</span>,
<span class="hljs-string">"permission"</span>: [{
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/myPhotos:BdayParty"</span>,
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:display"</span>,
<span class="hljs-string">"assigner"</span>: <span class="hljs-string">"http://example.com/user44"</span>,
<span class="hljs-string">"assignee"</span>: [{
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"http://example.com/user44/friends"</span>,
<span class="hljs-string">"scope"</span>: <span class="hljs-string">[ "http://www.w3.org/ns/odrl/2/Group",
"http://example.com/people/age/18+"]</span>
}]
}]
}</pre>
</section>
<section id="permission">
<h3>Permission</h3>
<p>The Permission entity specifies the Actions permitted to be performed on an Asset. An ODRL policy expression MAY contain at least one Permission.</p>
<p>The Permission entity has the following attributes:</p>
<ul>
<li>The Permission entity MUST refer to a <code>target</code> Asset on which the identified Action MAY be performed. Other <code>relation</code> values for Asset MAY be used.</li>
<li>The Permission entity MUST refer to an instance of an Action that indicates the operation allowed on the target Asset.</li>
<li>The Permission entity MAY refer to one or more assigner and/or assignee <code>role</code> functions undertaken by Party entities. Other <code>role</code> function values for Party MAY be used.</li>
<li>The Permission entity MAY refer to one or more <code>constraint</code>s. The Permission becomes effective if all of the constraints are satisfied.</li>
<li>The Permission entity MAY refer to one or more <code>duty</code>/ies. The Duty expresses an obligation that MUST be fulfilled in order for the Permission to be valid.</li>
</ul>
<blockquote>
<p>Example Use Case: The ticket Policy expresses the play Permission for the target Asset http//example.com/game:9090, stating that the ticket is valid until the end of the year 2017. Any valid holder of this ticket may exercise this Permission.</p>
</blockquote>
<pre class="example hljs xquery">{
<span class="hljs-string">"@context"</span>: {
<span class="hljs-string">"odrl"</span>: <span class="hljs-string">"http://www.w3.org/ns/odrl/2/"</span>
},
<span class="hljs-string">"@type"</span>: <span class="hljs-string">"odrl:Ticket"</span>,
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"http://example.com/policy:9090"</span>,
<span class="hljs-string">"permission"</span>: [{
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/game:9090"</span>,
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:play"</span>,
<span class="hljs-string">"constraint"</span>: [{
<span class="hljs-string">"leftOperand"</span>: <span class="hljs-string">"odrl:dateTime"</span>,
<span class="hljs-string">"operator"</span>: <span class="hljs-string">"odrl:lteq"</span>,
<span class="hljs-string">"rightOperand"</span>: <span class="hljs-string">"2017-12-31"</span>
}]
}]
}</pre>
</section>
<section id="prohibition">
<h3>Prohibition</h3>
<p>The Prohibition entity indicates the Actions that are prohibited to be performed on the Asset.
<p>The Prohibition entity has the following attributes:</p>
<ul>
<li>The Prohibition entity MUST refer to a <code>target</code> Asset on which the identified Action MUST NOT be performed. Other <code>relation</code> values for Asset MAY be used.</li>
<li>The Prohibition entity MUST refer to an instance of an Action that indicates the operation NOT allowed on the target Asset.</li>
<li>The Prohibition entity MAY refer to one or more assigner and/or assignee <code>role</code> functions undertaken by Party entities. Other <code>role</code> function values for Party MAY be used.</li>
<li>The Prohibition entity MAY refer to one or more <code>constraint</code>s. The Prohibition becomes effective if all of the constraints are satisfied.</li>
</ul>
<blockquote>
<p>Example Use Case: The owner and Assigner of a target Asset http://example.com/photoAlbum:55 needs an Agreement Policy expressing with both a Permission and a Prohibition. Then Assigner Party http://example.com/MyPix:55 assigns the Permission display to the Assignee Party http://example.com/assignee:55 at the same time they are prohibited from archiving the target Asset. Additionally, in case of any conflicts between Permissions and Prohibitions, the conflict attribute is set to <code>perm</code> indicating that the Permissions will take precedence.</p>
</blockquote>
<pre class="example hljs xquery">{
<span class="hljs-string">"@context"</span>: {
<span class="hljs-string">"odrl"</span>: <span class="hljs-string">"http://www.w3.org/ns/odrl/2/"</span>
},
<span class="hljs-string">"@type"</span>: <span class="hljs-string">"odrl:Agreement"</span>,
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"http://example.com/policy:5555"</span>,
<span class="hljs-string">"conflict"</span>: <span class="hljs-string">"odrl:perm"</span>,
<span class="hljs-string">"permission"</span>: [{
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/photoAlbum:55"</span>,
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:display"</span>,
<span class="hljs-string">"assigner"</span>: <span class="hljs-string">"http://example.com/MyPix:55"</span>,
<span class="hljs-string">"assignee"</span>: <span class="hljs-string">"http://example.com/assignee:55"</span>
}],
<span class="hljs-string">"prohibition"</span>: [{
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/photoAlbum:55"</span>,
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:archive"</span>,
<span class="hljs-string">"assigner"</span>: <span class="hljs-string">"http://example.com/MyPix:55"</span>,
<span class="hljs-string">"assignee"</span>: <span class="hljs-string">"http://example.com/assignee:55"</span>
}]
}</pre>
</section>
<section id="duty">
<h3>Duty</h3>
<p>A Permission entity MAY refer to a Duty entity that indicates a requirement that MUST be satisfied for Permissions to become valid. A Duty MUST only be associated with a Permission. </p>
<p>The Duty entity has the following attributes:</p>
<ul>
<li>The Duty entity MUST refer to an instance of an Action that indicates the operation that MUST be performed. Note: It is assumed that the assigned Party has the appropriate permissions to perform this action.</li>
<li>The Duty entity MAY refer to one or more assigner and/or assignee <code>role</code> functions to be undertaken by Party entities. Note: If no explicit role is specified as Assignee or Assigner, the Parties with the respective Roles are taken from the referring Permission. Other <code>role</code> function values for Party MAY be used.</li>
<li>The Duty entity MAY refer to a <code>target</code> Asset on which the identified Action MUST be performed. Other <code>relation</code> values for Asset MAY be used. For example, a <code>nextPolicy</code> Action MUST be linked to the identifier of a target Policy asset.</li>
<li>The Duty entity MAY refer to one or more <code>constraint</code>s. The Duty becomes effective if all of the constraints are satisfied.</li>
<li>The Duty entity MAY refer to a identifier for this Duty instance. Note: this is used to refer the same Duty to multiple Permission entities.</li>
</ul>
<p>If a Permission refers to several Duty entities, <em>all of them</em> MUST be satisfied for the Permission to be undertaken. If several Permission entities refer to one Duty, then the Duty only has to be satisfied <em>once</em> for all the Permission entities.</p>
<p>Even though a Duty entity is mandatory, the ODRL model does not specify any conditions on <em>WHEN</em> the Duty Action MUST be performed. Such business rules MAY be expressed through additional Constraints. For example, a Policy may state that you can play a music file for a payment of $5.00. This does not indicate when the $5.00 should be paid, as different business rules may apply such as montly invoicing.</p>
<blockquote>
<p>Example Use Case: The Party http://example.com/assigner:sony makes an Offer to play the music file http://example.com/music/1999.mp3. There are two Duties that both must be satisfied for the <code>compensate</code> requirement. The first is the <code>payAmount</code> of $AUD5.00 and the second is the <code>event</code> of this http://www.w3.org/ns/odrl/2/policyUsage must not have occured yet.
</p>
</blockquote>
<pre class="example hljs xquery">
{
"@context": {
"odrl": "http://www.w3.org/ns/odrl/2/"
},
"@type": "odrl:Offer",
"@id": "http://example.com/policy:88",
"permission": [{
"assigner": "http://example.com/assigner:sony",
"target": "http://example.com/music/1999.mp3",
"action": "odrl:play",
"duty": [{
"action": "odrl:compensate",
"constraint": [{
"leftOperand": "odrl:payAmount",
"operator": "odrl:eq",
"rightOperand": "5.00",
"unit":
"https://www.currency-iso.org/dam/downloads/lists/list_one.xml#AUD"
}],
"constraint": [{
"leftOperand": "odrl:event",
"operator": "odrl:lt",
"rightOperand": "odrl:policyUsage"
}]
}]
}]
}
</pre>
<blockquote>
<p>Example Use Case: The Party http://example.com/assigner:77 needs to set a Privacy Policy for some data about it. The target Asset http://example.com/personal-data:77 of this Policy is personal data, and the Assignee http://example.com/gov:health:au is allowed to distribute the Asset only for the purpose of contacting the subject of the Personal Data. The purpose value is taken from the P3P privacy purpose vocabulary. Additionally, the Party has stipulated that the Assignee must delete the Asset after a 30 day period, i.e., retention policy.</p>
</blockquote>
<pre class="example hljs xquery">{
<span class="hljs-string">"@context"</span>: {
<span class="hljs-string">"odrl"</span>: <span class="hljs-string">"http://www.w3.org/ns/odrl/2/"</span>
},
<span class="hljs-string">"@type"</span>: <span class="hljs-string">"odrl:Privacy"</span>,
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"http://example.com/policy:7777"</span>,
<span class="hljs-string">"permission"</span>: [{
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/personal-data:77"</span>,
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:distribute"</span>,
<span class="hljs-string">"constraint"</span>: [{
<span class="hljs-string">"leftOperand"</span>: <span class="hljs-string">"odrl:purpose"</span>,
<span class="hljs-string">"operator"</span>: <span class="hljs-string">"odrl:eq"</span>,
<span class="hljs-string">"rightOperand"</span>: <span class="hljs-string">"http://www.w3.org/2002/01/P3Pv1#contact"</span>
}],
<span class="hljs-string">"assigner"</span>: <span class="hljs-string">"http://example.com/assigner:77"</span>,
<span class="hljs-string">"assignee"</span>: <span class="hljs-string">"http://example.com/gov:health:au"</span>,
<span class="hljs-string">"duty"</span>: [{
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:delete"</span>,
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/personal-data:77"</span>,
<span class="hljs-string">"constraint"</span>: [{
<span class="hljs-string">"leftOperand"</span>: <span class="hljs-string">"odrl:dateTime"</span>,
<span class="hljs-string">"operator"</span>: <span class="hljs-string">"odrl:eq"</span>,
<span class="hljs-string">"rightOperand"</span>: <span class="hljs-string">"P30D"</span>
}]
}]
}]
}</pre>
</section>
<section id="action">
<h3>Action</h3>
<p>The Action entity indicates an operation that is applicable to an Asset. The Action is <em>permitted</em> to be performed on the target Asset when related to a Permission entity. When related to a Prohibition, the Action entity indicates the operation that is <em>prohibited</em> to be perform on the target Asset. When related to a Duty, the Action entity indicates the operation that is obligatory to be performed.</p>
<p>The Action entity has the following attribute:</p>
<ul>
<li>The Action entity MUST refer to an instance of an Action <code>name</code>.</li>
</ul>
<p>The ODRL vocabulary [[!vocab-odrl]] defines a standard set of common Action names that MAY be used.</p>
<blockquote>
<p>Example Use Case: The Party expresses an Offer policy for the target Asset http://example.com/music:1012, namely the Permission to play the Asset.</p>
</blockquote>
<pre class="example hljs xquery">{
<span class="hljs-string">"@context"</span>: {
<span class="hljs-string">"odrl"</span>: <span class="hljs-string">"http://www.w3.org/ns/odrl/2/"</span>
},
<span class="hljs-string">"@type"</span>: <span class="hljs-string">"odrl:Offer"</span>,
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"http://example.com/policy:1012"</span>,
<span class="hljs-string">"permission"</span>: [{
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/music:1012"</span>,