-
Notifications
You must be signed in to change notification settings - Fork 25
/
index.html
1968 lines (1477 loc) · 107 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" />
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no" />
<script class="remove" src="https://www.w3.org/Tools/respec/respec-w3c-common" defer></script>
<script class="remove" src="config.js"></script>
</head>
<body>
<section id="abstract">
<p>The Open Digital Rights Language (ODRL) is a policy expression language that provides a flexible and interoperable information model, vocabulary, and encoding mechanisms for representing statements about the usage of content and services. The ODRL Information Model describes the underlying concepts, entities, and relationships that form the foundational basis for the semantics of the ODRL policies. </p>
<p>Policies are used to represent permitted and prohibited actions over a certain asset, as well as the obligations required to be meet by stakeholders. In addition, policies may be limited by constraints (e.g., temporal or spatial constraints) and duties (e.g. payments) may be imposed on permissions. </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 expressing what are the permitted and prohibited actions over resources. These permitted/prohibited actions are usually expressed under the form of policies, i.e., expressions that indicate those uses and re-uses of the content which are conformant with 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 misuse, and for the consumers, i.e., they may know precisely what resources they are allowed to use and re-use to avoid breaking any rules, laws or the owner's constraints. This specification describes a common approach to expressing these policy concepts.</p>
<p>The ODRL Information Model defines the underlying semantic model for permission, prohibition, 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 this 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, prohibition, and obligation statements to be associated to content in general. These statements are employed to describe the terms of use and reuse of resources. The model should cover as many permission, prohibition, and obligation use cases as possible, while keeping the policy modelling easy even when dealing with complex cases.</p>
<p>The ODRL Information Model is a single, consistent model that can be used by all interested parties. 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 ODRL Information Model is built using Linked Data principles, the design is intended to allow non-graph-based implementations. </p>
</section>
<section id="conformance">
<p>The examples throughout the document are serialized as [[json-ld]]. For normative serialisations, including the JSON context, please refer to the ODRL Vocabulary and Expression [[!odrl-vocab]].</p>
</section>
<section id="terminology">
<h3>Terminology</h3>
<dl class="termlist">
<dt><dfn>Policy</dfn></dt>
<dd>A group of one or more Rules</dd>
<dt><dfn>Rule</dfn></dt>
<dd>An abstract concept that represents the common characteristics of Permissions, Prohibitions, and Duties.</dd>
<dt><dfn>Action</dfn></dt>
<dd>An operation on an Asset</dd>
<dt><dfn>Permission</dfn></dt>
<dd>The ability to exercise an Action over an Asset</dd>
<dt><dfn>Prohibition</dfn></dt>
<dd>The inability to exercise an Action over an Asset</dd>
<dt><dfn>Duty</dfn></dt>
<dd>The obligation to exercise an agreed Action.</dd>
<dt><dfn>Asset</dfn></dt>
<dd>A resource or a collection of resources that are the subject of a Rule</dd>
<dt><dfn>Party</dfn></dt>
<dd>An entity or a collection of entities that undertake Roles in a Rule</dd>
<dt><dfn>Constraint</dfn></dt>
<dd>A boolean/logical expression that refines an Action and Party/Asset collection or the conditions applicable to a Rule.</dd>
<dt><dfn>ODRL Validator</dfn></dt>
<dd>A system that checks the conformance of ODRL Policy expressions, including the cardinality of properties and if they are related to types of values as defined by the ODRL Information Model, and the Information Model's validation requirements.</dd>
<dt><dfn>ODRL Evaluator</dfn></dt>
<dd>A system that determines whether the Rules of an ODRL Policy expression have meet their intended action performance.</dd>
<dt><dfn>ODRL Core Vocabulary</dfn></dt>
<dd>The set of terms that are represented by the ODRL Information Model.</dd>
<dt><dfn>ODRL Profile</dfn></dt>
<dd>A community or sector specific vocabulary that extends the ODRL Core Vocabulary with new terms to express Policies</dd>
<dt><dfn>ODRL Common Vocabulary</dfn></dt>
<dd>A set of generic terms that may be re-used by ODRL Profiles.</dd>
</dl>
</section>
</section>
<section id="infoModel">
<h2>ODRL Information Model</h2>
<p>The ODRL Information Model represents Policies that express Permissions, Prohibitions and Duties related to the usage of Asset resources. The Information Model explicitly expresses what is allowed and what is not allowed by the Policy, as well as other terms, requirements, and parties involved. The aim of the ODRL Information Model is to enable flexible Policy expressions by allowing the policy author to include as much, or as little, detail in the Policies.</p>
<p>The figure below shows the ODRL Information Model.</p>
<figure>
<img src="00Model.png" alt="ODRL Information Model" width="800"/>
<figcaption>ODRL Information Model (Also available in <a href="00Model.svg">SVG format</a>)</figcaption>
</figure>
<p>The ODRL Information Model has the following classes:
<ul>
<li><code>Policy</code> - A non-empty group of Permissions (via the permission property) and/or Prohibitions (via the prohibition property) and/or Duties (via the obligation property). The Policy class is the parent class to the Set, Offer, and Agreement subclasses:
<ul>
<li><code>Set</code> - a subclass of Policy that supports expressing generic Rules.</li>
<li><code>Offer</code> - a subclass of Policy that supports offerings of Rules from assigner Parties.</li>
<li><code>Agreement</code> - a subclass of Policy that supports granting of Rules from assigner to assignee Parties. </li>
</ul>
</li>
<li><code>Asset</code> - A resource or a collection of resources that are the subject of a Rule (via the abstract <em>relation</em> property). The Asset class is the parent class to:
<ul>
<li><code>AssetCollection</code> - a subclass of Asset that identifies a collection of resources.</li>
</ul>
</li>
<li><code>Party</code> - An entity or a collection of entities that undertake Roles in a Rule (via the abstract <em>function</em> property). The Party class is the parent class to:
<ul>
<li><code>PartyCollection</code> - a subclass of Party that identifies a collection of entities.</li>
</ul>
</li>
<li><code>Action</code> - An operation on an Asset.</li>
<li><code>Rule</code> - An abstract concept that represents the common characteristics of Permissions, Prohibitions, and Duties.
<ul>
<li><code>Permission</code> - The ability to exercise an Action over an Asset. The Permission MAY also have the <strong>duty</strong> property that expresses an agreed Action that MUST be exercised (as a pre-condition to be granted the Permission).</li>
<li><code>Prohibition</code> - The inability to exercise an Action over an Asset.</li>
<li><code>Duty</code> - The obligation to exercise an Action.</li>
</ul>
</li>
<li><code>Constraint/LogicalConstraint</code> - A boolean/logical expression that refines an Action and Party/Asset collection or the conditions applicable to a Rule.</li>
</ul>
<p>The ODRL Information Model includes property relationships between the classes. Most are explicitly named properties and some are abstract properties (specifically, <em>relation</em>, <em>function</em>, <em>operand</em>, and <em>failure</em>). The abstract properties are generic parent properties that are designed to be represented by child properties (sub-types) with explicit semantics. </p>
<p>For example, the two properties <em>relation</em> and <em>function</em> in Figure 1 are designed to represent the <em>conceptual</em> relation between the Rule and the Asset and Party classes.
The figure shows the <em>relation</em> property with subtype <code>target</code> to express that the Asset is the primary subject of the Rule. The <em>function</em> property has subtype <code>assigner</code> to express the Party issuing the Rule, and subtype <code>assignee</code> to express the recipient Party of the Rule.
</p>
<div class="note">
<p>The ODRL Information Model provides a <em>logical view</em> of the components of the Policy model. The <em>implementable view</em> of the ODRL Information Model is provided by various encoding serialisations as normatively described in the ODRL Vocabulary & Expression document [[odrl-vocab]]. The mapping of the logical Information Model components to the implementable serialisations may require some trade-offs and/or differences depending on the features supported by the serialisation language.</p>
</div>
<p>The following sections provide further details on the ODRL Information Model. </p>
<section id="policy">
<h3>Policy Class</h3>
<p>The Policy class has the following properties:</p>
<ul>
<li>A Policy MUST have one <code>uid</code> property value (of type IRI [[!rfc3987]]) to identify the Policy.</li>
<li>A Policy MUST have at least one <code>permission</code>, <code>prohibition</code>, or <code>obligation</code> property values of type Rule. (See the <a href="#permission">Permission</a>, <a href="#prohibition">Prohibition</a>, and <a href="#duty-policy">Obligation</a> sections for more details.)</li>
<li>A Policy MAY have none, one, or many <code>profile</code> property values (of type IRI [[!rfc3987]]) to identify the ODRL Profile that this Policy conforms to. (See the <a href="#profile">ODRL Profiles</a> section for more details.)</li>
<li>A Policy MAY have none, one, or many <code>inheritFrom</code> property values (of type IRI [[!rfc3987]]) to identify the parent Policy from which this child Policy inherits from. (See the <a href="#inheritance">ODRL Inheritance</a> section for more details.) </li>
<li>A Policy MAY have none or one <code>conflict</code> property values (of type ConflictTerm) for Conflict Strategy Preferences indicating how to handle Policy conflicts.(See the <a href="#conflict">Policy Conflict Strategy</a> section for more details.)</li>
</ul>
<p>
An ODRL Policy MAY also declare properties which are shared and common to all its Rules. Specifically; <code>action</code> properties, sub-properties of <code>relation</code> (such as <code>target</code>), and sub-properties of <code>function</code> (such as <code>assigner</code> and <code>assignee</code>).
See section <a href="#composition-compact">Compact Policy</a> for validation requirements on these shared properties.
</p>
<p>An ODRL Policy must either:</p>
<ul>
<li>Only use terms defined in the ODRL Core Vocabulary [[!odrl-vocab]], or</li>
<li>Use an ODRL Profile that declares the supported vocabulary used by expressions in the Policy.</li>
</ul>
<p>In the former case, the profile property MUST NOT be used. In the latter case, the profile property MUST be used to indicate the IRIs of the ODRL Profile(s).
See the <a href="#profile">ODRL Profiles</a> section for more details on mechanisms to define ODRL Profiles and conformance requirements. (The Examples in this document will use ODRL Profile identifiers for illustrative purposes only.) </p>
<p>An ODRL Policy MAY be subclassed to more precisely describe the <em>context</em> of use of the
Policy that MAY include additional constraints that ODRL processors MUST understand. Additional Policy subclasses MAY be documented in the ODRL Common Vocabulary [[!odrl-vocab]] or in ODRL Profiles.
<section id="policy-set">
<h3>Set Class</h3>
<p>An ODRL Policy of subclass <code>Set</code> represents any combination of Rules. The <code>Set</code> Policy subclass is also the default subclass of Policy (if none is specified).</p>
<blockquote>
<p>Example Use Case: The below <code>Set</code> Policy shows the Permission to <code>use</code> the target Asset <code>http//example.com/asset:9898.movie</code>.</p>
</blockquote>
<pre id="eg1" class="example hljs json">
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Set",
"uid": "http://example.com/policy:1010",
"permission": [{
"target": "http://example.com/asset:9898.movie",
"action": "use"
}]
}
</pre>
<div class="note">
<p>For the examples in this document, the ODRL Policy subclasses are mapped to the JSON-LD <code>@type</code> tokens. The above example could have also used <code>Policy</code> type instead of <code>Set</code> type (as they are equivalent).</p>
<p>The above example does not use the <code>profile</code> property as all the terms are defined by the ODRL Core Vocabulary [[!odrl-vocab]]. </p>
</div>
</section>
<section id="policy-offer">
<h3>Offer Class</h3>
<p>An ODRL Policy of subclass <code>Offer</code> represents Rules that are being offered from assigner Parties. An <code>Offer</code> is typically used to make available Policies to a wider audience, but does not grant any Rules.</p>
<p>An ODRL Policy of subclass <code>Offer</code>:</p>
<ul>
<li>MUST have one <code>assigner</code> property value (of type Party) to indicate the functional role in the same Rules.</li>
</ul>
<p>Note: See the <a href="#function">Function Property</a> section for details on the functional roles.</p>
<p>Note: The above property cardinalities reflect the normative ODRL Information Model. In some cases, repeat occurrences of some properties are also supported (as described in <a href="#composition">Policy Rule Composition</a> and <a href="#composition-compact">Compact Policy</a>) but the normative atomic Policy is consistent with the above property cardinalities.</p>
<blockquote>
<p>Example Use Case: The below <code>Offer</code> Policy (based on the previous example) shows the Permission to <code>play</code> the target Asset <code>http//example.com/asset:9898.movie</code> from the assigner Party <code>http://example.com/party:org:abc</code>.</p>
</blockquote>
<pre id="eg2" class="example hljs json">
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:1011",
"profile": "http://example.com/odrl:profile:01",
"permission": [{
"target": "http://example.com/asset:9898.movie",
"assigner": "http://example.com/party:org:abc",
"action": "play"
}]
}
</pre>
<div class="note">
<p>The above example uses the <code>profile</code> property to indicate that the terms used are defined by the ODRL Profile identified by <code>http://example.com/odrl:profile:01</code>. See the <a href="#profile">ODRL Profiles</a> section for more details.</p>
</div>
</section>
<section id="policy-agreement">
<h3>Agreement Class</h3>
<p>An ODRL Policy of subclass <code>Agreement</code> represents Rules that have been granted from assigner to assignee Parties. An <code>Agreement</code> is typically used to grant the terms of the Rules between the Parties.</p>
<p>An ODRL Policy of subclass <code>Agreement</code>:</p>
<ul>
<li>MUST have one <code>assigner</code> property value (of type Party) to indicate the functional role in the same Rules.</li>
<li>MUST have one <code>assignee</code> property value (of type Party) to indicate the functional role in the same Rules.</li>
</ul>
<p>Note: See the <a href="#function">Function Property</a> section for details on the functional roles.</p>
<p>Note: The above property cardinalities reflect the normative ODRL Information Model. In some cases, repeat occurrences of some properties are also supported (as described in <a href="#composition">Policy Rule Composition</a> and <a href="#composition-compact">Compact Policy</a>) but the normative atomic Policy is consistent with the above property cardinalities.</p>
<blockquote>
<p>Example Use Case: The below <code>Agreement</code> Policy (based on the previous example) shows granting the Permission to <code>play</code> the target Asset <code>http//example.com/asset:9898.movie</code> from the assigner Party <code>http://example.com/party:org:abc</code> for the assignee Party <code>http://example.com/party:person:billie</code>.</p>
</blockquote>
<pre id="eg3" class="example hljs json">
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Agreement",
"uid": "http://example.com/policy:1012",
"profile": "http://example.com/odrl:profile:01",
"permission": [{
"target": "http://example.com/asset:9898.movie",
"assigner": "http://example.com/party:org:abc",
"assignee": "http://example.com/party:person:billie",
"action": "play"
}]
}
</pre>
</section>
</section>
<section id="asset">
<h3>Asset Class</h3>
<p>An Asset class is a resource or a collection of resources that are the subject of a Rule. The Asset can be any form of identifiable resource, such as data/information, content/media, applications, services, or physical artefacts. Furthermore, it can be used to represent other <code>Asset</code> classes that are needed to undertake the Policy expression, such as with a Duty. An Asset is referred to by the Permission and/or Prohibition, and also by the Duty.</p>
<p>The Asset class has the following properties:</p>
<ul>
<li>An Asset SHOULD have one <code>uid</code> property value (of type IRI [[!rfc3987]]) to identify the Asset.</li>
<li>An Asset MAY have none, one, or many <code>partOf</code> property values (of type AssetCollection) to identify the AssetCollection that this Asset is in a collection of.</li>
</ul>
<p class="note">If an Asset does not assert an identifier using the <code>uid</code> property, then the full implications must be understood, such as the impact on ODRL Validators and Evaluators of ODRL Policies.</p>
<p>The Asset class has the following subclass:</p>
<ul>
<li><code>AssetCollection</code> - an Asset that is a single resource representing a set of member resources. This indicates that all the members of the set will be the subject of the Rule.</li>
</ul>
<p>An AssetCollection class has the following properties:</p>
<ul>
<li>An AssetCollection MAY have one <code>source</code> property value (of type IRI [[!rfc3987]]) to reference the AssetCollection.</li>
<li>An AssetCollection MAY have none, one, or many <code>refinement</code> property values of type Constraint. See <a href="#constraint-asset">Refinement property with an Asset Collection</a> for more details.</li>
</ul>
<p>Since ODRL Policies could deal with any kind of Asset, the ODRL Information Model does not provide additional metadata to describe Assets of particular media types. It is recommended to use existing metadata standards, such as <a href="http://dublincore.org/documents/dcmi-terms/">Dublin Core Metadata Terms</a> that are appropriate to the Asset type or purpose.</p>
<section id="relation">
<h4>Relation Property</h4>
<p>The abstract <code><em>relation</em></code> property is used to create an explicit link between an Action and an Asset, indicating how the Asset MUST be utilised in respect to the Rule that links to it.</p>
<p>An ODRL validator MUST support the following sub-properties of <code><em>relation</em></code>:</p>
<ul>
<li><code>target</code>: indicates that the Asset is the primary subject to which the Rule action directly applies.</li>
</ul>
<p>Additional <code><em>relation</em></code> subtype properties MAY be defined in the ODRL Common Vocabulary [[!odrl-vocab]] and ODRL Profiles.</p>
<blockquote>
<p>Example Use Case: The assigner Party <code>http//example.com/party:0001</code> offers to display the <code>target</code> Asset <code>http://example.com/asset:3333</code>.</p>
</blockquote>
<pre id="eg4" class="example hljs json">
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:3333",
"profile": "http://example.com/odrl:profile:02",
"permission": [{
"target": "http://example.com/asset:3333",
"action": "display",
"assigner": "http://example.com/party:0001"
}]
}
</pre>
<div class="note">
<p>In the above example, the JSON-LD representation for the <code><em>relation</em></code> property directly uses <code>target</code> as the token, as this has been defined as a subtype of the parent <code><em>relation</em></code> property.</p>
</div>
<blockquote>
<p>Example Use Case: The below Policy shows the <code>index</code> action Permission on the target Asset <code>http://example.com/archive1011</code>. The target asset is also declared as an <code>AssetCollection</code> to indicate the resource is a collection of resources. An additional Asset relation <code>summary</code> indicates the Asset <code>http://example.com/x/database</code> that the indexing output should be stored in. The ODRL Profile <code>ttp://example.com/odrl:profile:03</code> defines this new sub-property of relation.</p>
</blockquote>
<pre id="eg5" class="example hljs json">
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Policy",
"uid": "http://example.com/policy:1011",
"profile": "http://example.com/odrl:profile:03",
"permission": [{
"target": {
"@type": "AssetCollection",
"uid": "http://example.com/archive1011" },
"action": "index",
"summary": "http://example.com/x/database"
}]
}
</pre>
</section>
<section id="asset-partof">
<h3>Part Of Property</h3>
<p>The <code>partOf</code> property is used to identify an AssetCollection that an Asset resource is a member of. The purpose is to explicitly express membership relationships between Assets and AssetCollections. This enables a Rule that is related to an AssetCollection to understand which individual Assets the Rule may apply to. In addition, the Asset/AssetCollection membership relationships may potentially detect conflicts in Rules.</p>
<blockquote>
<p>Example Use Case: The below snippet shows some Dublin Core metadata describing a document. The <code>odrl:partOf</code> property asserts that the Asset <code>http://example.com/asset:111.doc</code> is a member of the <code>http://example.com/archive1011</code> AssetCollection which is used in the Policy in the example above. This means that <code>http://example.com/asset:111.doc</code> is one of the target Assets in the Policy and can my indexed.</p>
</blockquote>
<pre id="eg6" class="example hljs json">
{
"@type": "dc:Document",
"@id": "http://example.com/asset:111.doc",
"dc:title": "Annual Report",
...
"odrl:partOf": "http://example.com/archive1011",
...
}
</pre>
</section>
<section id="policy-has">
<h3>Target Policy Property</h3>
<p>An ODRL Policy class MAY also be referenced by the <code>hasPolicy</code> property. This supports ODRL Policy Rules being the object of external metadata expressions (that identifies an Asset). When <code>hasPolicy</code> has been asserted between a metadata expression and an ODRL Policy, the Asset being identified MUST be inferred to be the <code>target</code> Asset of all the Rules of that Policy. If there are multiple Rules in the Policy, then the inferred Asset will be the target Asset to <strong>every</strong> Rule in the Policy.</p>
<blockquote>
<p>Example Use Case: The below snippet shows some Dublin Core metadata describing a movie Asset. The <code>odrl:hasPolicy</code> property links to the ODRL Policy <code>http://example.com/policy:1010</code> (this is the Set Policy described above). In this case, the Asset <code>http://example.com/asset:9999.movie</code> is now also the target Asset for the Permission in Policy <code>http://example.com/policy:1010</code>. If there were additional Rules in this Policy, then the same Asset would be the target Asset to each Rule.</p>
</blockquote>
<pre id="eg7" class="example hljs json">
{
"@type": "dc:MovingImage",
"@id": "http://example.com/asset:9999.movie",
"dc:publisher": "ABC Pictures",
"dc:creator": "Allen, Woody",
"dc:issued": "2017",
"dc:subject": "Musical Comedy",
...
"odrl:hasPolicy": "http://example.com/policy:1010",
...
}
</pre>
</section>
</section>
<section id="party">
<h3>Party Class </h3>
<p>A Party Class is an entity or a collection of entities that undertake functional roles in a Rule, such as a person, collection 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 function it plays in the Rule).</p>
<p>The Party class has the following properties:</p>
<ul>
<li>A Party SHOULD have one <code>uid</code> property value (of type IRI [[!rfc3987]]) to identify the Party.</li>
<li>A Party MAY have none, one, or many <code>partOf</code> property values (of type PartyCollection) to identify the PartyCollection that this Party is a member of.</li>
</ul>
<p class="note">If a Party does not assert an identifier using the <code>uid</code> property, then the full implications must be understood, such as the impact on ODRL Validators and Evaluators of ODRL Policies.</p>
<p>The Party class has the following subclass:</p>
<ul>
<li><code>PartyCollection</code> - a Party that is a single entity representing a set of member entities. This indicates that all the members of the set will undertake the same functional role in the Rule.</li>
</ul>
<p>The PartyCollection class has the following properties:</p>
<ul>
<li>A PartyCollection MAY have one <code>source</code> property value (of type IRI [[!rfc3987]]) to reference the PartyCollection.</li>
<li>A PartyCollection MAY have none, one, or many <code>refinement</code> property values of type Constraint. See <a href="#constraint-party">Refinement property with a Party Collection</a> for more details.</li>
</ul>
<p>The ODRL Information Model does not provide additional metadata for the Party class. It is recommended to use existing metadata standards, such as the W3C vCard Ontology [[vcard-rdf]] or FOAF Vocabulary [[foaf]].</p>
<section id="function">
<h4>Function Property</h4>
<p>A <code><em>function</em></code> property is used to link a Rule to a Party, indicating the function undertaken by the Party in respect to the Rule that links to it. The <code><em>function</em></code> property itself is abstract; sub-properties represent explicit semantics of the functional role between the Party and the Rule.</p>
<p>An ODRL validator MUST support the following sub-properties of <code><em>function</em></code>:</p>
<ul>
<li><code>assigner</code>: indicates the Party that is issuing the Rule. For example, the Party granting a Permission or requiring an agreed Duty to be fulfilled.</li>
<li><code>assignee</code>: indicates that the Party that is the recipient the Rule. For example, the Party being granted a Permission or required to fulfil an agreed Duty.</li>
</ul>
<p>Additional <code><em>function</em></code> subtype properties MAY be defined in the ODRL Common Vocabulary [[!odrl-vocab]] and ODRL Profiles.</p>
<blockquote>
<p>Example Use Case: The Policy shows an Agreement with two Parties with the functional roles of the <code>assigner</code> and the <code>assignee</code>. The <code>assigner</code> grants the <code>assignee</code> the play action over the target asset.</p>
</blockquote>
<pre id="eg8" class="example hljs json">
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Agreement",
"uid": "http://example.com/policy:8888",
"profile": "http://example.com/odrl:profile:04",
"permission": [{
"target": "http://example.com/music/1999.mp3",
"assigner": "http://example.com/org/sony-music",
"assignee": "http://example.com/people/billie",
"action": "play"
}]
}
</pre>
<div class="note">
<p>In the above example, the JSON-LD representation for <code><em>function</em></code> directly uses <code>assigner</code> and <code>assignee</code> as the token, as this has been defined as sub-properties of the parent <code><em>function</em></code> property.</p>
</div>
<blockquote>
<p>Example Use Case: The Policy shows an Agreement with two Parties with the functional roles of the <code>assigner</code> and the <code>assignee</code>. The <code>assigner</code> grants the <code>assignee</code> the use of the target asset. In this case, the <code>assigner</code> is explicitly declared as a <code>Party</code> as well as a <em>vcard:Organisation</em> and some additional external properties. The <code>assignee</code> is explicitly declared as a <code>PartyCollection</code> as well as a <em>vcard:Group</em> and some additional external properties. This implies that all the entities that are identified as <code>http://example.com/team/A</code> will each have the same granted action</p>
</blockquote>
<pre id="eg9" class="example hljs json">
{
"@context": [
"http://www.w3.org/ns/odrl.jsonld",
{ "vcard": "http://www.w3.org/2006/vcard/ns#" }
],
"@type": "Agreement",
"uid": "http://example.com/policy:777",
"profile": "http://example.com/odrl:profile:05",
"permission": [{
"target": "http://example.com/looking-glass.ebook",
"assigner": {
"@type": [ "Party", "vcard:Organization" ],
"uid": "http://example.com/org/sony-books",
"vcard:fn": "Sony Books LCC",
"vcard:hasEmail": "sony-contact@example.com" },
"assignee": {
"@type": [ "PartyCollection", "vcard:Group" ],
"uid": "http://example.com/team/A",
"vcard:fn": "Team A",
"vcard:hasEmail": "teamA@example.com"},
"action": "use"
}]
}
</pre>
</section>
<section id="party-partof">
<h3>Part Of Property</h3>
<p>The <code>partOf</code> property is used to identify a PartyCollection that a Party entity is a member of. The purpose is to explicitly express membership relationships between Parties and PartyCollections. This enables a Rule that relates to a PartyCollection to understand which individual Parties the Rule may apply to. In addition, the Party/PartyCollection membership relationships may potentially detect conflicts in Rules.</p>
<blockquote>
<p>Example Use Case: The below snippet shows some vCard metadata describing a Party. The <code>odrl:partOf</code> property asserts that the Party <code>http://example.com/person/murphy</code> is a member of the <code>http://example.com/team/A</code> PartyCollection which is used in the Policy in the example above. This means that <code>http://example.com/person/murphy</code> is an assignee and can use the target asset in the Policy. </p>
</blockquote>
<pre id="eg10" class="example hljs json">
{
"@type": "vcard:Individual",
"@id": "http://example.com/person/murphy",
"vcard:fn": "Murphy",
"vcard:hasEmail": "murphy@example.com",
...
"odrl:partOf": "http://example.com/team/A",
...
}
</pre>
</section>
<section id="policy-assigned">
<h3>Assigned Policy Properties</h3>
<p>An ODRL Policy class MAY also be referenced by the <code>assignerOf</code> and <code>assigneeOf</code> properties. This supports ODRL Policy Rules being the object of external metadata expressions (that identifies a Party). When <code>assignerOf</code> has been asserted between a metadata expression and an ODRL Policy, the Party being identified MUST be inferred to undertake the <code>assigner</code> functional role of all the Rules of that Policy. When <code>assigneeOf</code> has been asserted between a metadata expression and an ODRL Policy, the Party being identified MUST be inferred to undertake the <code>assignee</code> functional role of all the Rules of that Policy.
If there are multiple Rules in the Policy, then the inferred Party will undertake the functional role to <strong>every</strong> Rule in the Policy.</p>
<blockquote>
<p>Example Use Case: The below snippet shows some vCard metadata describing an individual Party. The <code>odrl:assigneeOf</code> property links to the ODRL Policy <code>http://example.com/policy:1011</code> (this is the Offer Policy described above). In this case, the Party <code>http://example.com/person/billie</code> is now also the assignee of the Permission in Policy <code>http://example.com/policy:1011</code>. If there were additional Rules in this Policy, then the same Party would the assignee for each Rule.</p>
</blockquote>
<pre id="eg11" class="example hljs json">
{
"@type": "vcard:Individual",
"@id": "http://example.com/person/billie",
"vcard:fn": "Billie",
"vcard:hasEmail": "billie@example.com",
...
"odrl:assigneeOf": "http://example.com/policy:1011",
...
}
</pre>
</section>
</section>
<section id="action">
<h3>Action Class</h3>
<p>An Action class indicates an operation that can be exercised on an Asset. An Action is associated with the Asset via the action property in a Rule.</p>
<p>The Rule provides the specific interpretations of the Action. For example; an Action is <em>permitted</em> to be exercised on the target Asset when related to a Permission. When related to a Prohibition, the Action indicates the operation that is <em>prohibited</em> to be exercised on the target Asset. When related to a Duty, the Action indicates the agreed operation that is <em>obligatory</em> to be fulfilled by a Party</p>
<p>The ODRL Information Model defines the following top-level Actions:</p>
<ul>
<li><code>use</code> - actions that involve general usage by parties. </li>
<li><code>transfer</code> - actions that involve in the transfer of ownership to third parties.</li>
</ul>
<p>The Action class has the following properties:</p>
<ul>
<li>An Action MAY have none, one or more <code>refinement</code> property values (of type Constraint) that refine the semantics of the Action operation. See <a href="#constraint">Constraints</a> section for more details.</li>
<li>An Action (except for use and transfer) MUST have one <code>includedIn</code> property value (of type Action) to transitively assert this Action that encompasses its operational semantics.</li>
<li>An Action MAY have none, one or more <code>implies</code> property values (of type Action) to assert this Action is not prohibited to enable its operational semantics.</li>
</ul>
<p>
Action terms MUST be defined using the <code>includedIn</code> property referring to an encompassing Action and either <code>use</code> or <code>transfer</code> as the top-level parent term by transitive means.
The purpose of the <code>includedIn</code> property is to explicitly assert that the semantics of the referenced instance of an other Action encompasses (includes) the semantics of this instance of Action. The <code>includedIn</code> property is transitive, and as such, the Actions form ancestor relationships. </p>
<p>The implication of the <code>includedIn</code> property is that a Permission or Prohibition of an encompassing Action is inherited by all Actions with an <code>includedIn</code> relationship.
For example, if the <code>play</code> Action is defined as <code>includedIn</code> with <code>use</code> then if <code>play</code> is permitted in a Policy and <code>use</code> is prohibited in the same Policy - and both Actions apply to the same target Asset - then because of this asserted relationship between the two, there is conflict in the Policy. (See <a href="#conflict">Policy Conflict Strategy</a> for more details.)</p>
<p>
The <code>implies</code> property asserts that an instance of Action entails that the other instance of Action is not prohibited. The <code>implies</code> property can establish such an assertion between two Action instances if they don't have an <code>includedIn</code> relationship.
For example, if a <code>share</code> Action implies explicitly the <code>distribute</code> Action, then if <code>share</code> is permitted in a Policy and <code>distribute</code> is prohibited in the same Policy - and both Actions apply to the same target Asset - this would cause a conflict in the Policy. If an implied other action is not prohibited then this will not cause a conflict.
(See <a href="#conflict">Policy Conflict Strategy</a> for more details.)
<p>See <a href="#profile">ODRL Profiles</a> for usage details on the <code>includedIn</code> and <code>implies</code> properties.
</p>
<p>The ODRL Common Vocabulary [[!odrl-vocab]] defines a standard set of generic Actions that MAY be adopted by ODRL Profiles.</p>
<blockquote>
<p>Example Use Case: The Policy expresses an Offer for the target Asset <code>http://example.com/music:1012</code> with the Action to <code>play</code> the Asset (<code>play</code> is defined as an <code>includedIn</code> term of <code>use</code>).</p>
</blockquote>
<pre id="eg12" class="example hljs json">
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:1012",
"profile": "http://example.com/odrl:profile:06",
"permission": [{
"target": "http://example.com/music:1012",
"assigner": "http://example.com/org:abc",
"action": "play"
}]
}
</pre>
</section>
<section id="constraint">
<h3>Constraints</h3>
<p>Constraints are boolean/logical expressions that can be used to refine the semantics of an Action and Party/Asset Collection or declare the conditions applicable to a Rule. Constraints can be represented as a <strong> Constraint</strong> class or <strong>Logical Constraint</strong> class. A Logical Constraint will refer to existing Constraints as its operands. When multiple Constraints apply to the same Rule, Action, Party/Asset Collection, then they are interpreted as conjunction and all MUST be satisfied.</p>
<p>The Constraint and Logical Constraint classes form semantic and conditional relationships with the Party Collection, Asset Collection, Action, and Rule classes. The property relationships are summarised in the figure below.</p>
<figure>
<img src="01Constraint.png" alt="ODRL Constraint Relationships" width="800"/>
<figcaption>ODRL Constraint Relationships (Also available in <a href="01Constraint.svg">SVG format</a>)</figcaption>
</figure>
<section id="constraint-class">
<h3>Constraint Class</h3>
<p>A Constraint class is used for expressions which compare two operands (which are not Constraints) by one relational operator. If the comparison returns a match the Constraint is <strong>satisfied</strong>, otherwise it is <strong>not satisfied</strong>. The Constraint class formulates a comparison expression, such as, the number of usages (the <code>leftOperand</code>) must be smaller than (the <code>operator</code>) the number 10 (the <code>rightOperand</code>).
</p>
<p>The Constraint class has the following properties:</p>
<ul>
<li>A Constraint MUST have one <code>leftOperand</code> property value of type LeftOperand.</li>
<li>A Constraint MUST have one <code>operator</code> property value of type Operator.</li>
<li>A Constraint MUST have either:
<ul>
<li>one <code>rightOperand</code> property value of type:
<ul>
<li>literal, or IRI [[!rfc3987]], or RightOperand; or</li>
<li>for set-based operators; list of literals, or list of IRIs [[!rfc3987]], or list of RightOperands;</li>
</ul>
</li>
<li>one <code>rightOperandReference</code> property value of type:
<ul>
<li>IRI [[!rfc3987]]; or</li>
<li>for set-based operators; list of IRIs [[!rfc3987]];</li>
</ul>
for a reference to a right operand value.</li>
</ul>
<li>A Constraint MAY have none or one <code>dataType</code> property value for the data type of the rightOperand/Reference.</li>
<li>A Constraint MAY have none or one <code>unit</code> property value (of type IRI [[!rfc3987]]) to set the unit used for the value of the rightOperand/Reference.</li>
<li>A Constraint MAY have none or one <code>status</code> property value for a value generated from the leftOperand action or for a value related to the leftOperand set as the reference for the comparison.</li>
</ul>
<p>The <code>leftOperand</code> property values are defined as instances of the LeftOperand class. The <code>leftOperand</code> instances MUST clearly be <strong>defined</strong> to indicate the semantics of the Constraint, and MAY declare how the value for comparison has to be retrieved or generated. The ODRL Common Vocabulary [[!odrl-vocab]] defines <code>leftOperand</code>'s that MAY be used by ODRL Profiles.</p>
<p>The <code>operator</code> property values are defined as instances of the Operator class. The <code>operator</code> instances identify the relational operation such as “greater than” or “equal to” between the left and right operands.</p>
<p>The <code>rightOperand</code> property values are defined as instances of the RightOperand class, or IRIs, or Literal values. The <code>rightOperand</code> is the value of the Constraint that is to be compared to the <code>leftOperand</code>. The <code>rightOperandReference</code> represents an IRI that MUST be de-referenced first to obtain the actual value of the <code>rightOperand</code>. A <code>rightOperandReference</code> is used in cases where the value of the <code>rightOperand</code> MUST be obtained from dereferencing an IRI first. Only one of <code>rightOperand</code> or <code>rightOperandReference</code> MUST appear in the Constraint.</p>
<p>
The <code>rightOperand</code> represents a value and the <code>rightOperandReference</code> represents an IRI that must be de-referenced to obtain the value. If the <code>rightOperand</code> was <code>http://example.com/c100</code> then that is interpreted as the value to be compared in the expression. If the <code>rightOperandReference</code> was the same value of <code>http://example.com/c100</code>, then that IRI must be de-referenced first and the data returned must be interpreted as the value to be compared in the expression.
</p>
<p>The <code>dataType</code> indicates the type of the <code>rightOperand/Reference</code>, such as <code>xsd:decimal</code> or <code>xsd:datetime</code> and the <code>unit</code> indicates the unit value of the <code>rightOperand/Reference</code>, such as “EU currency”.</p>
<p>The <code>status</code> provides a value generated from the <code>leftOperand</code> action that MUST be used in the comparison expression. 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 already been exercised 5 times and the comparison must compare the current action to the status value.</p>
</section>
<section id="constraint-logical">
<h3>Logical Constraint Class</h3>
<p>
A Logical Constraint class is used for expressions which compare two or more operands which are existing Constraints by one logical operator. If the comparison returns a logical match, then the Logical Constraint is <strong>satisfied</strong>, otherwise it is <strong>not satisfied</strong>. For example, three Constraints could be logically <strong>and</strong>-ed indicating that all three must be true for the Logical Constraint to be satisfied.</p>
<p>The Logical Constraint class has the following properties:</p>
<ul>
<li>A Logical Constraint MUST have one <code><em>operand</em></code> sub-property indicating the logical relationship of the compared existing constraints; its value is a list of the existing Constraint instances.</li>
</ul>
<p>An ODRL evaluator MUST support the following sub-properties of <code><em>operand</em></code>:</p>
<ul>
<li><code>or</code> - at least one of the Constraints MUST be satisfied</li>
<li><code>xone</code> - only one, and not more, of the Constraints MUST be satisfied</li>
<li><code>and</code> - all of the Constraints MUST be satisfied</li>
<li><code>andSequence</code> - all of the Constraints - in sequence - MUST be satisfied</li>
</ul>
<p>Additional <code><em>operand</em></code> sub-properties MAY be defined by ODRL Profiles.</p>
<p>The ODRL validation requirements for Logical Constraints includes:</p>
<ol>
<li>The <code><em>operand</em></code> MUST only be of the sub-properties; <code>or</code>, <code>xone</code>, <code>and</code>, <code>andSequence</code>. Additional sub-properties of <code><em>operand</em></code> MAY be defined by ODRL Profiles exclusively for the use of Logical Constraints.</li>
<li>All of the operand values MUST be unique Constraint instances.</li>
</ol>
<p>The Constraint instances MUST be evaluated and the outcomes used to determine if the logical relationship is satisfied (based on the semantics of the <code><em>operand</em></code> sub-property).</p>
<p class="note">
When using a logical operand that needs to be evaluated in sequence, such as <code>andSequence</code>, the serialisations MUST preserve the order of the members of the list. In JSON-LD, the <code>@list</code> keyword MUST be used to represent an ordered collection.
</p>
</section>
<section id="constraint-rule">
<h3>Constraint property with a Rule</h3>
<p>An Rule (such as a Permission, Prohibition, or Duty) MAY include the <code>constraint</code> property to indicate a condition on the Rule.
To meet this condition, all of the the Constraints/Logical Constraints referenced by the <code>constraint</code> property MUST be <strong>satisfied</strong>.
</p>
<blockquote>
<p>Example Use Case: In the Policy Offer example below, the permission allows the target asset to be <code>distribute</code>d, and includes a constraint of a <code>dateTime</code> condition that the permission must be exercised before 2018-01-01.</p>
</blockquote>
<pre id="eg1799" class="example hljs json">
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:6163",
"profile": "http://example.com/odrl:profile:10",
"permission": [{
"target": "http://example.com/document:1234",
"assigner": "http://example.com/org:616",
"action": "distribute",
"constraint": [{
"leftOperand": "dateTime",
"operator": "lt",
"rightOperand": "2018-01-01"
}]
}]
}
</pre>
</section>
<section id="constraint-action">
<h3>Refinement property with an Action</h3>
<p>An Action MAY include the <code>refinement</code> property to indicate a Constraint/Logical Constraint that narrows the semantics of the Action operation directly.
To meet this condition of narrower semantics for the Action, all of the Constraints/Logical Constraints referenced by the <code>refinement</code> property MUST be <strong>satisfied</strong>. </p>
<p>Note: The outcome of applying refinements to an Action SHOULD NOT result in a null operation.</p>
<blockquote>
<p>Example Use Case: In the Policy Offer example below, the permission allows the target asset to be <code>print</code>ed, and also include a refinement Constraint that narrows the printing operation to not more than 50% of the asset.</p>
</blockquote>
<pre id="eg179" class="example hljs json">
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:6161",
"profile": "http://example.com/odrl:profile:10",
"permission": [{
"target": "http://example.com/document:1234",
"assigner": "http://example.com/org:616",
"action": [{
"rdf:value": { "@id": "odrl:print" },
"refinement": [{
"leftOperand": "percentage",
"operator": "lteq",
"rightOperand": "50.0"
}]
}]
}]
}
</pre>
<blockquote>
<p>Example Use Case:The Policy below shows a permission to reproduce the target asset <strong>either</strong> via online media or print media <strong>but not both</strong>. This is expressed as a Logical Constraint (with the <code>xone</code> operand) referring to two existing Constraints declared elsewhere. </p>
</blockquote>
<pre id="eg19" class="example hljs json">
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:88",
"profile": "http://example.com/odrl:profile:10",
"permission": [{
"target": "http://example.com/book/1999",
"assigner": "http://example.com/org/paisley-park",
"action": [{
"rdf:value": { "@id": "odrl:reproduce" },
"refinement": {
"xone": [ { "@id": "http://example.com/p:88/C1" },
{ "@id": "http://example.com/p:88/C2" } ]
}
}]
}]
}
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Constraint",
"uid": "http://example.com/p:88/C1",
"leftOperand": "media",
"operator": "eq",
"rightOperand": "online"
}
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Constraint",
"uid": "http://example.com/p:88/C2",
"leftOperand": "media",
"operator": "eq",
"rightOperand": "print"
}
</pre>
<p class="note">
When using the <code>refinement</code> property with an Action, the <code>rdf:value</code> property is used to represent the instance of the Action which MUST use its namespace identifier (eg <code>odrl</code>), and assert it is an <code>@id</code> key. In addition, identifiers of Constraint instances (for logical constraint operands) must assert them as an <code>@id</code> key.
</p>
</section>
<section id="constraint-asset">
<h3>Refinement property with an Asset Collection</h3>
<p>
An <code>AssetCollection</code> MAY include a <code>refinement</code> property to indicate the refinement context under which to identify individual Asset(s) of the complete collection. The <code>refinement</code> property applies to the characteristics of each member of the collection (and not the resource as a whole).
To meet this condition of identifying individual Asset(s) of the complete <code>AssetCollection</code>, all of the Constraints/Logical Constraints referenced by the <code>refinement</code> property MUST be <strong>satisfied</strong>. </p>
<p>Note: The outcome of applying refinements to an AssetCollection SHOULD NOT result in a null set.</p>
<p>Note that when using the <code>refinement</code> property, the <code>uid</code> property MUST NOT be used to <em>identify</em> the <code>AssetCollection</code>. Instead, the <code>source</code> property MUST be used to <em>reference</em> the <code>AssetCollection</code>. </p>
<blockquote>
<p>Example Use Case: The Policy defines a target source <code>http://example.com/media-catalogue</code> that is an AssetCollection of multimedia videos. The target also has a refinement that specifies the characteristics of the AssetCollection members. In this case, the target subset of Assets will be those that have a <em>running time</em> of less than 60 minutes, and each of those may be played. Note that the <code>runningTime</code> leftOperand is defined in the ODRL Profile <code>http://example.com/odrl:profile:11</code> together with the <code>play</code> action.
</p>
</blockquote>
<pre id="eg21" class="example hljs json">
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:4444",
"profile": "http://example.com/odrl:profile:11",
"permission": [{
"assigner": "http://example.com/org88",
"target": {
"@type": "AssetCollection",
"source": "http://example.com/media-catalogue",
"refinement": [{
"leftOperand": "runningTime",
"operator": "lt",
"rightOperand": "60",
"unit": "http://qudt.org/vocab/unit/MinuteTime"
}],
},
"action": "play"
}]
}
</pre>
</section>
<section id="constraint-party">
<h3>Refinement property with a Party Collection</h3>
<p>
A <code>PartyCollection</code> MAY include a <code>refinement</code> property to indicate the refinement context under which to identify individual Party(ies) of the complete collection. The <code>refinement</code> property applies to the characteristics of each member of the collection (and not the resource as a whole).
To meet this condition of identifying individual Party(ies) of the complete <code>PartyCollection</code>, all of the Constraints/Logical Constraints referenced by the <code>refinement</code> property MUST be <strong>satisfied</strong>. </p>
<p>Note: The outcome of applying refinements to a PartyCollection SHOULD NOT result in a null set.</p>
<p>Note that when using the <code>refinement</code> property, the <code>uid</code> property MUST NOT be used to <em>identify</em> the <code>PartyCollection</code>. Instead, the <code>source</code> property MUST be used to <em>reference</em> the <code>PartyCollection</code>. </p>
<blockquote>
<p>Example Use Case: The target Asset <code>http://example.com/myPhotos:BdayParty</code> is a set of photos posted to a social network site by the assigner of the photos <code>http://example.com/user44</code>. The assignee source is a PartyCollection <code>http://example.com/user44/friends</code> and represents all the friends of the assigner.
The assignee also has a refinement that indicates only members of the collection over the <code>foaf:age</code> of 18 will be assigned the <code>display</code> permission.
</p>
</blockquote>
<pre id="eg22" class="example hljs json">
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Agreement",
"uid": "http://example.com/policy:4444",
"profile": "http://example.com/odrl:profile:12",
"permission": [{
"target": "http://example.com/myPhotos:BdayParty",
"assigner": "http://example.com/user44",
"assignee": {
"@type": "PartyCollection",
"source": "http://example.com/user44/friends",
"refinement": [{
"leftOperand": "foaf:age",
"operator": "gt",
"rightOperand": "17"
}],
},
"action": "display"
}]
}
</pre>
</section>
</section>
<section id="rule">
<h3>Rule Class</h3>
<p>The Rule class is the parent of the Permission, Prohibition, and Duty classes. The Rule class represents the common characteristics of these three classes.
</p>
<p>The Rule class has the following properties:</p>
<ul>
<li>A Rule MUST have one <code>action</code> property value of type Action.</li>
<li>A Rule MAY have none or one <code><em>relation</em></code> sub-property values of type Asset.</li>
<li>A Rule MAY have none, one or many <code><em>function</em></code> sub-property values of type Party.</li>
<li>A Rule MAY have none, one or many <code><em>failure</em></code> sub-property values of type Rule.</li>
<li>A Rule MAY have none, one or many <code>constraint</code> property values of type Constraint/LogicalConstraint.</li>
<li>A Rule MAY have none or one <code>uid</code> property values (of type IRI [[!rfc3987]]) to identify the Rule so it MAY be referenced by other Rules.</li>
</ul>
<p>Note: The above property cardinalities reflect the normative ODRL Information Model. In some cases, repeat occurrences of some properties are also supported (as described in <a href="#composition">Policy Rule Composition</a> and <a href="#composition-compact">Compact Policy</a>) but the normative atomic Policy is consistent with the above property cardinalities.</p>
<p>Explicit sub-properties of the abstract <code><em>relation</em></code>, <code><em>relation</em></code> and <code><em>failure</em></code> properties must be used, the choice depending on the subclass of Rule in question.</p>
<p>The three classes of Rules also form important relationships with the Duty Rule. The property relationships are summarised in the figure below.</p>
<figure>
<img src="02Rule.png" alt="ODRL Rule Relationships" width="800"/>
<figcaption>ODRL Rule Relationships (Also available in <a href="02Rule.svg">SVG format</a>)</figcaption>
</figure>