-
Notifications
You must be signed in to change notification settings - Fork 25
/
index.html
1246 lines (989 loc) · 82.6 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 digital 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>
<b>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></b>
</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 digital 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 digital 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 digital 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 digital 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 digital 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 digital 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 digital content in general. These permission and obligation statements are employed to describe the terms of use and reuse of digital 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 digital 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>Resource</dfn></dt>
<dd>An item of interest that may be identified by an URI.</dd>
<dt><dfn>Digital content</dfn></dt>
<dd>Any type of content that exists in the form of digital data.</dd>
<dt><dfn>Policy</dfn></dt>
<dd>A set of rules defining what is allowed, disallowed or obligatory over a resource.</dd>
<dt><dfn>Rule</dfn></dt>
<dd>A set of actions defining the precise Permissions, Prohibitions and Obligations over a resource.</dd>
<dt><dfn>Action</dfn></dt>
<dd>A set of operations that can be allowed by Permissions, disallowed by Prohibitions, or made obligatory by Duties.</dd>
<dt><dfn>Permission</dfn></dt>
<dd>A set of actions that are allowed to be performed over a resource.</dd>
<dt><dfn>Prohibition</dfn></dt>
<dd>A set of actions that are forbidden to be performed over a resource.</dd>
<dt><dfn>Duty</dfn></dt>
<dd>A set of actions that are obliged to be performed over a resource.</dd>
<dt><dfn>Asset</dfn></dt>
<dd>The subject of a Policy that permissions and prohibitions are applied to.</dd>
<dt><dfn>Party</dfn></dt>
<dd>Any form of identifiable entity that is the object of a Policy, e.g., a person, a group of people, an organisation, or an agent.</dd>
<dt><dfn>Constraint</dfn></dt>
<dd>The limits and restrictions to the Permissions, the Prohibitions and the Duties expressed in the Policy. </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 digital 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 class. These Rules have common relationships to the other key classes (specifcially, 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>
<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>
<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 contains the following attributes:</p>
<ul>
<li><code>uid</code>: the unique identification of the Policy entity (REQUIRED)</li>
<li><code>type</code>: indicates the semantics of the Policy entity (REQUIRED). These are further described in the ODRL vocabulary [[!vocab-odrl]] and ODRL Profiles.</li>
<li><code>conflict</code>: indicates how to handle Policy conflicts (OPTIONAL)</li>
<li><code>undefined</code>: indicates how to handle undefined Actions (OPTIONAL)</li>
<li><code>inheritAllowed</code>: indicates if the Policy entity can be inherited (OPTIONAL)</li>
<li><code>profile</code>: the identifier of the ODRL Profile that this Policy conforms to (OPTIONAL)</li>
</ul>
<p>The <code>uid</code> attribute MUST be a unique identifier.</p>
<p>The range of values for the Policy entity’s <code>type</code> attribute will be described in the ODRL vocabulary [[!vocab-odrl]] or in ODRL Profiles. This value MAY also impose further constraints on the Information Model. It is important that the <code>type</code> attribute be clearly understood in policy expressions as the semantics MAY impose restrictions on the expression language constructs such as cardinalities between entities. For example, the ODRL Agreement Policy Type stipluates that it must contain two Parties (an Assigner and Assignee).</p>
<p><b>Example Use Case</b>: A Policy of type Set states that the Asset http//example.com/asset:9898 is the target of the Permission read and the Prohibition reproduce. No Parties or other elements are involved.</p>
<pre class="example highlight 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">"uid"</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>
<p><b>Example Use Case</b>: A Policy of type Set states that the Asset http//example.com/asset:9898 is the target of the Permission reproduce, the Duty attribute to http://example.com/owner:9898, and the Prohibition translate. Two Parties are involved, namely the Assigner of the Permissions and the Party to be attributed.</p>
<pre class=" example highlight 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">"uid"</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="structure">
<h4>Policy Structures</h4>
<p>The ODRL Information Model supports flexibility in the information structures 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 apply to all of the enclosing Rules in the Policy.</p>
<p>At the core <i>atomic</i> level, an ODRL Rule (Permission and/or Prohibition) would typically contain one Asset, one or more Parties, one Action, and potentially one Constraint and/or Duty, as shown in the example below:</p>
<pre class="example highlight hljs xquery">
{
"@context": {
"odrl": "http://www.w3.org/ns/odrl/2/"
}
"type": "odrl:Agreement",
"uid": "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 are support for each Rule, then the following (snippet) example with two Assets:</p>
<pre class="example highlight 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>Would then be mapped to two <i>atomic</i> Rules:</p>
<pre class="example highlight 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>The processing model for Permission/Prohibition Rules with multiple Assets, Parties, and Actions to generate <i>atomic</i> Rules includes:</p>
<ol>
<li>If there are multiple Assets (with the same Relation), then create new Rules (one for each Asset) and include one Asset relation, and all the other (non-Asset) entities.</li>
<li>If there are multiple Parties (with the same Role), then create new Rules (one for each Party) and include one Party Role, and all the other (non-Party Role) entities.</li>
<li>If there are multiple Actions, then create new Rules (one for each Action) and include one Action, and all the other (non-Action) entities.</li>
</ol>
<p>An ODRL Policy MAY also declare multiple Assets, Parties, and Actions at the Policy level. This indicates that these are all common to all the enclosing Rules, as shown in the below example:</p>
<pre class="example highlight hljs xquery">
{
"@context": {
"odrl": "http://www.w3.org/ns/odrl/2/"
}
"type": "odrl:Agreement",
"uid": "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 highlight hljs xquery">
{
"@context": {
"odrl": "http://www.w3.org/ns/odrl/2/"
}
"type": "odrl:Agreement",
"uid": "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 includes:</p>
<ol>
<li>Replicate all Policy-level Assets in the enclosing Permission/Prohibition Rules.</li>
<li>Replicate all Policy-level Parties in the enclosing Permission/Prohibition Rules.</li>
<li>Replicate all Policy-level Actions in the enclosing Permission/Prohibition Rules.</li>
<li>Follow the processing model (defined above) to create <i>atomic</i> Rules.</li>
</ol>
</section>
<section id="provenace">
<h4>Policy Provenance</h4>
<p>Provenance attributes MAY be added to the Policy entity to support additional authenticity, integrity, and interpretation. Typically, these will be from external community vocabularies. </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: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 <B>dc:isReplacedBy</B> property, then the identified Policy MUST be retrieved and processed.</li>
</ol>
<p><b>Example Use Case:</b>The below Policy contains provenace properties that indicate who created it, when it was issued, which jurisdiction is relevant, and an older version of the Policy it replaces.</p>
<pre class="example highlight hljs xquery">
{
"@context": [{ "odrl": "http://www.w3.org/ns/odrl/2/",
"dc": "http://purl.org/dc/terms/ }],
"type": "odrl:Agreement",
"uid": "http://example.com/policy:8888",
"dc:creator": "billie@example.com",
"dc:issued": "2017-01-01:12:00",
"dc:jurisiction: "Queensland, Australia",
"dc:replaces: "http://example.com/policy:8887",
"permission": [{ ... }]
}
</pre>
</section>
<section id="conflict">
<h4>Policy Conflict</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. For example, one Policy stated that Assignee Fred had been granted an "exclusive" distribution Permission, and the other Policy said the same for Assignee Mary. In the same Policy, conflicts can also arise when the same Action is used in a Permission and a Prohibition. </p>
<p>The <code>conflict</code> attribute MUST take one of the following values:</p>
<ul>
<li><code>perm</code>: the <code>Permission</code>s MUST override the Prohibitions</li>
<li><code>prohibit</code>: the <code>Prohibition</code>s 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, its default value of <code>invalid</code> will be used.</p>
<p>The processing model for Policies conflict strategies includes:</p>
<ol>
<li>If a Policy has the <code>conflict</code> attribute of <code>perm</code> and there are detected conflicts between a Permission and a Prohibition, then the Permission MUST overide the Prohibition.</li>
<li>If a Policy has the <code>conflict</code> attribute of <code>prohibit</code> and there are detected conflicts between a Permission and a Prohibition, then the Prohibition MUST overide the Permission.</li>
<li>If a Policy has the <code>conflict</code> attribute of <code>invalid</code> and there are detected conflicts between a Permission and a Prohibition, then the entire Policy MUST be processed as invalid .</li>
<li>If a Policy has multiple <code>conflict</code> attribute values (for example, after a Policy merge) AND there are detected conflicts between a Permission and a Prohibition, then the entire Policy MUST be processed as invalid .</li>
</ol>
<p><b>Example Use Case</b>: 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>
<pre class="example highlight 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">"uid"</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 highlight 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">"uid"</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>
<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 <b>supported</b> as part of the Policy – and the Policy remains valid</li>
<li><code>ignore</code>: the undefined Action is to be <b>ignored</b> 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 <b>invalid</b></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 <b>supported</b>, or <b>ignored</b>, or the entire Policy is <b>invalid</b>. </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>
<p><b>Example Use Case</b>: A Policy of type Set states that the Asset can be <i>recorded</i>. The processing system does not understand this Action, and since the <b>undefined</b> attribute is <b>invalid</b>, then the entire Policy is deemed invalid.</p>
<pre class="example highlight hljs xquery">
{
"@context": {
"odrl": "http://www.w3.org/ns/odrl/2/"
}
"type": "odrl:Set",
"uid": "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 structures of another (parent) Policy. The inheritance is aimed at <i>including</i> data structures between 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 of this inheritance structure</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. For example, 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. 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>
<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>
<p><b>Example Use Case:</b>Consider the below (parent) Policy that has been expressed primarly for inheritance purposes:</p>
<pre class="example highlight hljs xquery">
{
"@context": {
"odrl": "http://www.w3.org/ns/odrl/2/"
}
"type": "odrl:Set",
"uid": "http://example.com/policy:3333",
"target": "http://example.com/asset:3333",
"assigner": "http://example.com/boss:0001",
"permission": [{
"action": "odrl:use"
}]
}
</pre>
<p>The below (child) Policy includes the inheritFrom attribute pointing to the above (parent) Policy. The (child) Policy also includes its own specific policy-level asset, and two Permission Rules.</p>
<pre class="example highlight hljs xquery">
{
"@context": {
"odrl": "http://www.w3.org/ns/odrl/2/"
}
"type": "odrl:Agreement",
"uid": "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 structures are added to the (child) Policy - the resultant Policy is shown below:</p>
<pre class="example highlight hljs xquery">
{
"@context": {
"odrl": "http://www.w3.org/ns/odrl/2/"
}
"type": "odrl:Agreement",
"uid": "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>inhertiAllowed</code> attribute with the value "false".</li>
<li>The (child) Policy MUST access the (parent) Policy and replicate the following in the (child) Policy:</li>
<ul>
<li>All policy-level Assets, Parties, Actions.</li>
<li>All Permission and Prohibition Rules.</li>
</ul>
<li>The (child) Policy can then be further expanded (into <i>atomic</i> Rules) by following the processing models defined in the <a href="#structure">Policy Structure</a> section.</li>
</ol>
</section>
</section>
<section id="asset">
<h3>Asset</h3>
<p>The Asset entity is the subject of an ODRL policy expression that Permissions and Prohibitions are applied to. 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 contains the following attribute:</p>
<ul>
<li><code>uid</code>: the unique identification of the Asset (REQUIRED)</li>
<li><code>scope</code>: defines how the Asset shall be interpreted under different contexts. (OPTIONAL)</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 for the Asset. There MAY also be other alternative identifers, 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. <p>
<p>There are some use cases where the ODRL Policy expression MAY be embedded inside the target Asset. In these cases, it MAY be more appropriate to provide, or infer, a link to the Asset entity (as the complete Asset <code>uid</code> may not be known at the time) through the local context. Use of such inference and context MUST be documented in the relevant ODRL Profile.</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 can be used to link to an Asset from either Permission, Duty or Prohibition, indicating how the Asset SHOULD be utilised in respect to the entity that links to it.</p>
<p>The Relation entity contains the following attribute:</p>
<ul>
<li><code>relation</code>: indicates the relationship of the Asset to the linked entity (REQUIRED)</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 Permission, Duty or Prohibition actions apply.</p>
<p>Other values for the Relation entity SHOULD be defined in the ODRL Vocabulary [[!vocab-odrl]] and ODRL Profiles.</p>
</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 which 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>
<p><b>Example Use Case</b>: The Party http//example.com/guest:0001 needs to display the target Asset http://example.com/asset:3333, but she needs to be granted with the Permission to do so. 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>
<pre class="example highlight 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">"uid"</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>
<p><b>Example Use Case</b>: The Party needs to define a Policy exploiting multiple Asset entities. The index Permission is granted to the target Asset http://example.com/archive1011. The x:collection Asset http://example.com/x/database specifies
which database the index outcome should be stored in.</p>
<pre class="example highlight 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">"uid"</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>
<p><b>Example Use Case</b>: The Policy includes 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>
<pre class="example highlight 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">"uid"</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">"uid"</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 is the object of an ODRL Policy and can be any form of identifiable entity, 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 contains the following attributes:</p>
<ul>
<li><code>uid</code>: the unique identification of the Party (REQUIRED)</li>
<li><code>function</code>: defines the Roles fulfilled by a Party in relation to a Rule (REQUIRED)</li>
<li><code>scope</code>: defines how the Role shall be interpreted under different contexts. (OPTIONAL)</li>
</ul>
<p>The ODRL Information Model does not provide additional metadata for the Party element. It is recommended to use already existing metadata standards, such as the W3C vCard Ontology [[vcard-rdf]] or FOAF [[foaf]], that are appropriate to the Party type or purpose.</p>
<p>The Role entity is used to associate the Party entity with the relevant Permission, Prohibition, and Duty entities.</p>
<section id="role">
<h4>Role</h4>
<p>The Role entity is an association class and can be used to link to a Party from either Permission, Duty or Prohibition, indicating which Role the Party takes with respect to the entity that links to it.</p>
<p>The Role entity contains the following attributes:</p>
<ul>
<li><code>function</code>: the functional role the Party takes (REQUIRED)</li>
</ul>
<p>The <code>function</code> attribute MUST support the following values:</p>
<ul>
<li><code>assigner</code>: indicates that the Party has assigned the associated Permission, Duty, or Prohibition. In other words, the Party grants a Permission or requires a Duty to be performed or states a Prohibition.</li>
<li><code>assignee</code>: indicates that the Party has been assigned the associated entity, i.e., they are granted a Permission or required to perform a Duty or have to adhere to a Prohibition.</li>
</ul>
<p>Other values for the <code>function</code> attribute SHOULD be defined in the ODRL vocabulary [[!vocab-odrl]] and ODRL Profiles.</p>
</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 limit that to only 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>
<p><b>Example Use Case</b>: The target Asset http://example.com/myPhotos:BdayParty are photos posted to a Social Network site by the Assigner and owner 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. The scope of the Assignee(s) has been set to http://example.com/people/age/18+ (which, in this case provides additional context on what characteristics the Assigee MUST hold).</p>
<pre class="example highlight 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">"uid"</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">"uid"</span>: <span class="hljs-string">"http://example.com/user44/friends"</span>,
<span class="hljs-string">"scope"</span>: <span class="hljs-string">"http://example.com/people/age/18+"</span>
}]
}]
}</pre>
</section>
<section id="permission">
<h3>Permission</h3>
<p>The Permission entity indicates the Actions permitted to be performed on the Asset.</p>
<p>An ODRL policy expression MAY contain at least one Permission. It is important to verify the semantics of the Policy <code>type</code> attribute as this SHOULD indicate additional constraints on the Policy expression semantics.</p>
<p>The Permission entity has the following relations:</p>
<ul>
<li><code>Asset</code>: the Permission entity MUST refer to an Asset (where at least one, and only one, <code>relation</code> value is <code>target</code>) on which the linked Action SHOULD be performed (REQUIRED)</li>
<li><code>Action</code>: the Permission entity MUST refer to <em>exactly one</em> Action that indicates the granted operation on the target Asset (REQUIRED) (Note: this is after the Rule has folowed the processing models defined in the <a href="#structure">Policy Structure</a> section.)</li>
<li><code>Party</code>: the Permission MAY refer to one or more Party entities linked via the Role entity (OPTIONAL)</li>
<li><code>Constraint</code>: the Permission MAY refer to one or more Constraints which affect the validity of the Permission - it only becomes effective if all of the referred Constraints are true (OPTIONAL). For example; the Action play is only permitted for a certain period of time.</li>
<li><code>Duty</code>: the Permission MAY refer to one or more Duty entities that indicate a requirement that SHOULD be fulfilled in return for receiving the Permission (OPTIONAL)</li>
</ul>
<p><b>Example Use Case</b>: 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 2016. Any valid holder of this ticket may exercise this Permission.</p>
<pre class="example highlight 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">"uid"</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">"2016-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 relations:</p>
<ul>
<li><code>Asset</code>: the Prohibition entity MUST refer to an Asset (where at least one, and only one, <code>relation</code> value is <code>target</code>) on which the Action is prohibited (REQUIRED) (Note: this is after the Rule has folowed the processing models defined in the <a href="#structure">Policy Structure</a> section.)</li>
<li><code>Action</code>: the Prohibition entity MUST refer to <em>exactly one</em> Action that is prohibited (REQUIRED)</li>
<li><code>Party</code>: the Prohibition MAY refer to one or more Party entities linked via the Role entity (see Section 2.3.1) (OPTIONAL)</li>
<li><code>Constraint</code>: the Prohibition MAY refer to one or more Constraints which affect the validity of the Prohibition - it only becomes effective if all of the referred Constraints are true (OPTIONAL). For example; the Action display is only prohibited for a certain country.</li>
</ul>
<p><b>Example Use Case</b>: 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 conflict between Permissions and Prohibitions, the conflict attribute is set to <code>perm</code> indicating that the Permission entity will take precedence.</p>
<pre class="example highlight 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">"uid"</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 include a Duty entity that indicates a requirement that MUST be satisfied in order to undertake the Permission. A Duty MUST only be associated with a Permission. </p>
<p>The Duty entity contains the following attributes:</p>
<ul>
<li><code>uid</code>: a unique identification for this Duty. Used to refer a single Duty to multiple Permission entities (OPTIONAL)</li>
</ul>
<p>The <code>Duty</code> entity has the following relations:</p>
<ul>
<li><code>Action</code>: indicates the requirement that MUST be performed (REQUIRED). Note: It is assumed that the assigned Party has the appropriate permissions to perform this action.</li>
<li><code>Party</code>: a Duty MAY refer to Party entities with different Roles. If no explicit Party is linked to as Assignee or Assigner, the Parties with the respective Roles are taken from the referring Permission. (OPTIONAL)</li>
<li><code>Asset</code>: a Duty entity MAY refer to an Asset (where at least one, and only one, <code>relation</code> value is <code>target</code>) related to satisfying the Duty. (OPTIONAL) For example, a <code>nextPolicy</code> Action must be linked to the identifier of a target Policy Asset.</li>
<li><code>Constraint</code>: a Duty MAY refer to one or more Constraints which affect the fulfillment of the Duty - it is only fulfilled if all of the referred Constraints are true (OPTIONAL). For example; the Duty Action payAmount is only fulfilled if a specific amount is paid.
</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>
<p><b>Example Use Case</b>: The Party http://example.com/assigner:sony makes and 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>
<pre class="example highlight hljs xquery">
{
"@context": {
"odrl": "http://www.w3.org/ns/odrl/2/"
}
"type": "odrl:Offer",
"uid": "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": "http://cvx.iptc.org/iso4217a/AUD"
}],
"constraint": [{
"name": "odrl:event",
"operator": "odrl:lt",
"rightOperand": "odrl:policyUsage"
}]
}]
}]
}
</pre>
<p><b>Example Use Case</b>: 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>
<pre class="example highlight 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">"uid"</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">"name"</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 (when related to a Permission entity) indicates the operations (e.g., <code>play</code>, <code>copy</code>, etc.) that the Assignee (i.e., the consumer) is <em>permitted</em> to perform on the related Asset linked to by Permission. When related to a Prohibition, the Action entity indicates the operations that the Assignee (again the consumer) is <em>prohibited</em> to perform on the Asset linked to by Prohibition. Analogously, when related to a Duty, it indicates the operation to be performed.</p>
<p>Action contains the following attribute:</p>
<ul>
<li><code>name</code>: indicates the Action entity term (REQUIRED)</li>
</ul>
<p>As its value, the <code>name</code> attribute SHOULD take one of a set of Action <em>names</em> which are formally defined in Profiles. The ODRL vocabulary [[!vocab-odrl]] defines a standard set of potential terms that MAY be used. Communities will develop new (or extend existing) Profiles to capture additional and refined semantics.</p>
<p><b>Example Use Case</b>: The Party needs to define an Offer policy granting a Permission about the target Asset http://example.com/music:1012, namely the permission to play the Asset.</p>
<pre class="example highlight 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">"uid"</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>,
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:play"</span>
}]
}</pre>
</section>
<section id="constraint">
<h3>Constraint</h3>
<p>The Constraint entity indicates limits and restrictions to the Permission, the Prohibition and the Duty entities. Constraints are a logical expression for comparing two operands by one operator. If the logical expression evalutes to <b>true</b> the result of the Constraint is satisfied.</p>
<p>
Constraints can express limitations with logical comparisions. For example, the number of usages (<code>leftOperand</code>) must be smaller than (<code>operator</code>) the number 10 (<code>rightOperand</code>). Constraints can also be used for complex Constraint Relations expressions that use two constraint objects as the left and right operand. For example, constraint #1 (<code>leftOperand</code>) must be satisfied or (<code>operator</code>) constraint #2 (<code>rightOperand</code>) must be satisfied.</p>
<p>The constraint <code>leftOperand</code> MUST clearly be defined to indicate which entity is the subject of the constraint, and MAY include how the value for comparison has to be retrieved or generated. For example, the <code>count</code> constraint applies to the <code>action</code> and the <code>language</code> constraint applies to the <code>asset</code>.</p>
<p>If multiple Constraint entities are linked to the same Permission, Prohibition, or Duty entity, then all of the Constraint entities MUST be satisfied. That is, all the Constraint entities are (boolean) <em>and</em>ed together. In the case where the same Constraint is repeated, then these MUST be represented as a single Constraint entity using an appropriate <code>operator</code> value (for example, <code>isAnyOf</code>).</p>
<p>The <code>Constraint</code> entity contains the following attributes:</p>
<ul>
<li><code>leftOperand</code>: the left operand of the operation (REQUIRED)</li>
<li><code>operator</code>: an operator function (REQUIRED)</li>
<li><code>rightOperand</code>: the right operand of the operation (REQUIRED if no rightOperandReference)</li>
<li><code>rightOperandReference</code>: the right operand of the operation (REQUIRED if no rightOperand)</li>
<li><code>dataType</code>: the datatype of the rightOperand (OPTIONAL)</li>
<li><code>unit</code>: the units of the rightOperand (OPTIONAL)</li>
<li><code>status</code>: the current value of the right operand (OPTIONAL)</li>
</ul>
<p>In case of a Constraint expression, the <code>leftOperand</code> identifies the left operand of the logic expression for the Constraint. The <code>leftOperand</code> MAY be one of the Constraint Left Operands defined in the ODRL Vocabulary [[!vocab-odrl]] or from an ODRL Profile. In case of a Constraint Relations expression, the <code>leftOperand</code> MUST refer to an complete Constraint object (see <a href="#constraint-relations">Constraint Relations</a> for further requirements).
</p>
<p>In case of a Constraint expression, the <code>operator</code> identifies the logical operation such as “greater than” or “equal to” between the left and right operand. In case of a Constraint Relations expression the operator identifiers the logic relationship of two constraints using operators like 'and' or 'exclusive or'.</p>
<p>In case of a Constraint expression, the <code>rightOperand</code> identifies the right operand of the logic expression for the Constraint. The <code>rightOperand</code> MAY be the value of the constraint that is to be compared to the <code>leftOperand</code>. The <code>rightOperand</code> represents the literal value (such as "10" or "http://example.com/c100") and <code>rightOperandReference</code> represents a URI that MUST be dereferenced to obtain the actual value. Only one of these MUST appear in the Constraint. In case of a Constraint Relations expression, the <code>rightOperand</code> MUST refer to an complete Constraint object (see <a href="#constraint-relations">Constraint Relations</a> for further requirements).</p>
<p>In case of a Constraint expression, the <code>dataType</code> indicates the type of the <code>rightOperand/Reference</code>, such as “decimal” or “datetime” and the <code>unit</code> indicates the unit value of the <code>rightOperand/Reference</code>, such as “EU dollars”. In case of a Constraint Relations expression, the <code>dataType</code> attribute MUST NOT be used.</p>
<p>In case of a Constraint expression, the <code>status</code> provides the current value of the <code>rightOperand</code>. For example, a <code>count</code> constraint could have a <code>rightOperand</code> value of 10, and the <code>status</code> of 5. This means that the action has alread been exercised 5 times. In case of a Constraint Relations expression, the <code>status</code> attribute MUST NOT be used.</p>
<p><b>Example Use Case</b>: The Party http://example.com/myPix:6161 wants to assign the Permission distribute directly to the potential buyer of the Permission who will pay 100 EUR for this grant. The distribute Permission is also constrained to a specific country, i.e., Italy. The potential Assignee may then distribute the target Asset http://example.com/wallpaper:1234 according to the nextPolicy target Asset linked directly from this Duty. In this case, the next Policy Asset stipulates that the potential Assignee may only offer the display Permission to downstream consumers.</p>
<pre class="example highlight 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">"uid"</span>: <span class="hljs-string">"http://example.com/policy:6161"</span>,
<span class="hljs-string">"permission"</span>: [{
<span class="hljs-string">"target"</span>: <span class="hljs-string">"http://example.com/wallpaper:1234"</span>,
<span class="hljs-string">"assigner"</span>: <span class="hljs-string">"http://example.com/myPix:6161"</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:spatial"</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.itu.int/tML/tML-ISO-3166:it"</span>
}],
<span class="hljs-string">"duty"</span>: [
{
<span class="hljs-string">"action"</span>: <span class="hljs-string">"odrl:compensate"</span>,
<span class="hljs-string">"constraint"</span>: [{
<span class="hljs-string">"leftOperand"</span>: <span class="hljs-string">"odrl:payAmount"</span>,
<span class="hljs-string">"operator"</span>: <span class="hljs-string">"odrl:eq"</span>,