model/index.html

<!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>
    <style type="text/css">
    .Rule {
      margin-left:2em;
      border-left:thick solid black;
      padding-left:0.5em;
      background-color:#ddd;
    }
    </style>

  </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 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 statements. </p>
        <p>Policies are used to explicitly state what are the permitted and prohibited actions over a certain resource, as well as the obligations required to be meet by stakeholders. In addition, policies may be integrated with constraints (e.g., time constraints) which apply to such actions to impose further restrictions to the uses of the resource. </p>

    </section>
    
<section id="sotd">
<p>
  <strong>This is a work in progress. No section should be considered final, and the absence of any content does not imply that such content is out of scope, or may not appear in the future. If you feel something should be covered, please <a href="mailto:public-poe-comments@w3.org">tell us.</a></strong>
</p>
</section>
    
    
<section class="informative" id="intro">
<h2>Introduction</h2>   

<p>Several business scenarios require 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 modeling 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. If a Rule is <strong>effective</strong> if it has satisfied its Constraints and fulfilled its Duties.</dd>
	       <dt><dfn>Action</dfn></dt>
	          <dd>An operation on an Asset</dd>
            <dt><dfn>Permission</dfn></dt>
                  <dd>The ability to perform an Action over an Asset</dd>
            <dt><dfn>Prohibition</dfn></dt>
                  <dd>The inability to perform an Action over an Asset</dd>
            <dt><dfn>Duty</dfn></dt>
	          <dd>The obligation to perform an Action. If the obligation is meet, then the Duty is <strong>fulfilled</strong>.</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 the applicability of a Rule, or the context of a Party or Asset collection. If the expression is true or the collection context is valid, then the Constraint is <strong>satisfied</strong>.</dd>
           <dt><dfn>ODRL Validator</dfn></dt>
	          <dd>A system that checks the conformance of ODRL Policy expressions with respect to the ODRL Information Model requirements.</dd>
           <dt><dfn>ODRL Evaluator</dfn></dt>
	          <dd>A system that determines whether the permissions and prohibitions of an ODRL Policy expression are in effect.</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.svg" alt="ODRL Information Model" width="800"/>
    <figcaption>ODRL Information Model (Also available in <a href="00Model.png">PNG 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:</li>
        <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><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:</li>
         <ul>
        <li><code>AssetCollection</code> - a subclass of Asset that identifies a collection of resources.</li>
        </ul>
        <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:</li>
         <ul>
        <li><code>PartyCollection</code> - a subclass of Party that identifies a collection of entities.</li>
        </ul>
    <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.</li>
        <ul>
    <li><code>Permission</code> - The ability to perform an Action over an Asset. The Permission MAY also have the <strong>duty</strong> property that expresses an agreed Action that MUST be performed (as a pre-condition to be granted the Permission).</li>
    <li><code>Prohibition</code> - The inability to perform an Action over an Asset.</li>
    <li><code>Duty</code> - The obligation to perform an Action.</li>
    </ul>
    <li><code>Constraint/LogicalConstraint</code> - A boolean/logical expression that refines the applicability of a Rule, or the context of a Party or Asset collection.</li>
    </ul>

<p>The ODRL Information Model has two abstract properties between Rule and the Asset and Party class. These two properties (<em>relation</em> and <em>function</em>) are designed to represent the <em>conceptual</em> relation between the two classes. In serialised ODRL expressions, they MUST be realised as subtypes of their respective parent property.   The figure below shows the ODRL Properties Model with subtypes.</p>

<figure>
	<img src="01Properties.svg" alt="ODRL Properties Model" width="800"/>
    <figcaption>ODRL Properties Model (Also available in <a href="01Properties.png">PNG format</a>)</figcaption>
</figure>

<p>The figure shows the <em>relation</em> property with subtype <strong>target</strong> to express that the Asset is the primary subject of the Rule. The <em>function</em> property has subtype <strong>assigner</strong> to express the Party issuing the Rule, and subtype <strong>assignee</strong> 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 &amp; 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 to identify (via a IRI [[!rfc3987]]) of the Policy.</li>
<li>A Policy MUST have one and MAY have many <code>permission</code>, <code>prohibition</code>, or <code>obligation</code> properties for Rules.  (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> properties to identify (via a IRI [[!rfc3987]]) 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> properties 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 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 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>The Policy class MAY also include other direct properties to support <a href="#composition-compact">Compact Policy</a> serialisations and references to common <a href="#constraint">Constraints</a>. These are not to be considered as direct properties of the Policy but as an intermediate step, that after applying <a href="#composition">atomic processing rules</a> will create a Policy  consistent with the normative ODRL Information Model.
	</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>

     <p>An ODRL Policy of subclass <code>Set</code>:</p>
    <ul>
        <li>MUST have one and MAY have many permission, prohibition, or obligation properties for Rules.</li>
    </ul>
	

<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 and MAY have many permission, prohibition, or obligation properties for Rules.</li>
        <li>MUST have one <code>assigner</code> property 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>

<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 and MAY have many permission, prohibition, or obligation properties for Rules.</li>
        <li>MUST have one <code>assigner</code> property functional role in the same Rules.</li>
		 <li>MUST have one <code>assignee</code> property 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>
	
<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, or services. 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 subclass:</p>
    
<ul>
    <li><code>AssetCollection</code> - an Asset that is a collection of resources. This indicates that all the items in the collection will be the subject of the Rule.</li>
</ul>
    
<p>The Asset class has the following properties:</p>
    
<ul>
<li>An Asset SHOULD have one <code>uid</code> property to identify the Asset using an IRI [[!rfc3987]].</li>
	
	<li>An Asset MUST have one and MAY have many <code><em>relation</em></code> sub-properties for Asset indicating the link to the Asset.</li>
	
    <li>An Asset MAY have none, one, or many <code>partOf</code> properties to identify (IRI [[!rfc3987]]) an AssetCollection that this Asset is in a collection of.</li>
<li>An AssetCollection MAY have none, one, or many <code>constraint</code> properties for Constraint. See <a href="#constraint-asset">Asset Constraints</a> for more details.</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>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 subclass:</p> 
<ul>
    <li><code>PartyCollection</code> - a Party that is a collection of entities. This indicates that all the entities in the collection will undertake the same functional role in the Rule.</li>
</ul>
    
<p>The Party class has the following properties:</p>
<ul>
<li>A Party SHOULD have one <code>uid</code> property to identify the Party using an IRI [[!rfc3987]].</li>
<li>A Party MUST have one and MAY have many <code><em>function</em></code> sub-properties for Party indicating the role undertaken by the Party.</li>
      <li>A Party MAY have none, one, or many <code>partOf</code> properties to identify (IRI [[!rfc3987]]) a PartyCollection that this Party is a member of.</li>
<li>A PartyCollection MAY have none, one, or many <code>constraint</code> properties for Constraint. See <a href="#constraint-party">Party Constraints</a> for more details.</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 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 performed.</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 perform 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 applied to 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 performed 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 performed on the target Asset. When related to a Duty, the Action indicates the agreed operation that is <em>obligatory</em> to be performed 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 (except for use and transfer) MUST have one <code>includedIn</code> property for an Action to transitively assert this Action that encompasses its operational semantics.</li>
<li>An Action MAY have none, one or more <code>implies</code> properties for an 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="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 for Action.</li>
	<li>A Rule MAY have none or one <code><em>relation</em></code> sub-properties for Asset.</li>
	<li>A Rule MAY have none, one or many <code><em>function</em></code> sub-properties for Party.</li>
<li>A Rule MAY have none, one or many <code>constraint</code> properties for Constraint/LogicalConstraint.</li>
<li>A Rule MAY have none or one <code>uid</code> property identifier (IRI [[!rfc3987]]) to enable the Rule to 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> and <code><em>function</em></code> properties must be used, the choice depending on the subclass of Rule in question.</p>

<p>For a Rule to become effective, all of it's Constraints MUST be satisfied and any applicable relationship to a Duty MUST be fulfilled.</p>

    
<section id="permission">
<h3>Permission Class</h3>


<p>A Permission is the <strong>ability</strong> to perform an Action over an Asset. The Permission class inherits all the properties from the Rule class parent.</p>

<p>The Permission class is a subclass of Rule and has the following additional property semantics:</p>
<ul>
    <li>A Permission MUST have one <code>target</code> property for Asset. (Other <code><i>relation</i></code> sub-properties for Asset MAY be used.)</li>
    <li>A Permission MAY have none or one <code>assigner</code> and/or <code>assignee</code> property function roles for Parties. (Other <code><i>function</i></code> sub-properties for Party MAY be used.)</li>
    <li>A Permission MAY have none, one, or more <code>duty</code> properties for Duty.</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>The duty property expresses an agreed obligation that MUST be fulfilled in order for the Permission to be in effect. That is, the duty property asserts a <em>pre-condition</em> between the Permission and the Duty. See the <a href="#duty-perm">Duty with a Permission</a> section for more details.</p>
	
<p>For a Permission to become effective, all it's constraints MUST be satisfied and all of the Permission's duties MUST be fulfilled.</p>
    
<blockquote>   
<p>Example Use Case: The Policy <code>Offer</code> from assigner <code>http://example.com/org:xyz</code> expresses the play Permission for the target Asset <code>http//example.com/game:9090</code> and the permission is valid until the end of the year 2017.</p>
    </blockquote>
 <pre id="eg13" class="example hljs json">
 {
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:9090",
    "profile": "http://example.com/odrl:profile:07",
    "permission": [{
        "target": "http://example.com/game:9090",
        "assigner": "http://example.com/org:xyz",
        "action": "play",
        "constraint": [{
            "leftOperand": "dateTime",
            "operator": "lteq",
            "rightOperand": "2017-12-31"
        }]
    }]
}
</pre>

</section>

<section id="prohibition">
<h3>Prohibition Class</h3>

<p>A Prohibition is the <strong>inability</strong> to perform an Action over an Asset. The Prohibition class inherits all the properties from the Rule class parent.</p>
    
<p>The Prohibition class is a subclass of Rule and has the following additional property semantics:</p>
<ul>
	 <li>A Prohibition MUST have one <code>target</code> property for Asset. (Other <code><i>relation</i></code> sub-properties for Asset MAY be used.)</li>
    <li>A Prohibition MAY have none or one <code>assigner</code> and/or <code>assignee</code> property function roles for Parties. (Other <code><i>function</i></code> sub-properties for Party MAY be used.)</li>	
    <li>A Prohibition MAY have none, one, or more <code>remedy</code> properties for Duty.</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>The remedy property expresses an agreed obligation that MUST be fulfilled in the case that the Prohibition has been violated. That is, the remedy property asserts a Duty that must be fulfilled if the Prohibition is exercised.  See the <a href="#duty-prohib">Remedy with a Prohibition</a> section for more details.</p>
	
<p>	
	For a Prohibition to become effective, all it's constraints MUST be satisfied and all of the Prohibition's remedies MUST be fulfilled (if the Prohibition was violated).</p>

    <blockquote>
<p>Example Use Case: The assigner of a target Asset <code>http://example.com/photoAlbum:55</code> expresses an Agreement Policy with both a Permission and a Prohibition. The assigner Party <code>http://example.com/MyPix:55</code> assigns the Permission <code>display</code> to the assignee Party <code>http://example.com/assignee:55</code> at the same time a Prohibition to <code>archive</code> the target Asset. Additionally, in case of any conflicts in the Policy (e.g., between Permissions and Prohibitions), the <code>conflict</code> property of the <code>Policy</code> is set to <code>perm</code> indicating that the Permissions will take precedence.</p>
    </blockquote>
    
<pre id="eg14" class="example hljs json">
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:5555",
    "profile": "http://example.com/odrl:profile:08",
    "conflict": "perm",
    "permission": [{
        "target": "http://example.com/photoAlbum:55",
        "action": "display",
        "assigner": "http://example.com/MyPix:55",
        "assignee": "http://example.com/assignee:55"
    }],
    "prohibition": [{
        "target": "http://example.com/photoAlbum:55",
        "action": "archive",
        "assigner": "http://example.com/MyPix:55",
        "assignee": "http://example.com/assignee:55"
    }]
}
</pre>
	
</section>

<section id="duty">
<h3>Duty Class</h3>

<p>A Duty is the <strong>obligation</strong> to perform an Action. The Duty specifies agreed Actions that MUST be fulfilled. The Duty class inherits all the properties from the Rule class parent.</p>
	
<p>The Duty class is a subclass of Rule and has the following additional property semantics:</p>
<ul>
     <li>A Duty MAY have none or one <code>target</code> property for Asset to indicate the Asset that is the primary subject to which the Duty directly applies. (Other <code><i>relation</i></code> sub-properties for Asset MAY be used.)</li>
	  <li>A Duty MAY have none or one <code>assigner</code> and/or <code>assignee</code> property function roles for Parties. (Other <code><i>function</i></code> sub-properties for Party MAY be used.)</li> 
	  <li>A Duty MAY have none or one <code>consequence</code> properties for Duty.</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="">Policy Rule Composition</a> and <a href="">Compact Policy</a>) but the normative atomic Policy is consistent with the above property cardinalities.</p>
	
    
	<p>The Duty class also has these additional requirements:</p>
	<ul>
	   <li>The assignee MUST have the ability to perform the Duty Action.</li>
		<li>The assignee(s) of the Duty MUST satisfy the Duty.</li>
	</ul>
  
<p>The consequence property is utilised to express the repercussions of not fulfilling an agreed Policy obligation or duty for a Permission. If either of these fails to be fulfilled, then this will result in the consequence Duty <strong>also</strong> becoming a new requirement, meaning that the original obligation or duty, as well as the consequence Duty MUST all be fulfilled. For example, if an obligation to provide data by a certain date is not fullfilled, the a consequence of a $100 fine is payable as well.
</p>

<p>Note that the consequence property MUST NOT be used on a Duty that is already a consequence for a Permission duty or Policy obligation.</p>
	
<p>Even though a Duty is mandatory (eg, agreed as a pre-condition for a Permission or activated in violation of a Prohibition), the ODRL Information Model does not specify any specific temporal 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 compensation payment of $5.00. This does not indicate when the $5.00 should be paid as different business rules may apply, such as monthly invoicing or streaming.</p>

	</section>
	
<section id="duty-policy">
<h3>Obligation property with a Policy</h3>

<p>A Policy may include an obligation to fulfill a Duty. If the Duty rule has been fulfilled (that is, all its Constraints are satisfied), then the Duty rule is in effect. That is, the obligation has been meet.</p>
		
<blockquote>
<p>Example Use Case: The below Agreement includes an obligation from assigner <code>http://example.com/org:43</code> to assignee <code>http://example.com/person:44</code>  to compensate the assigner for a payment of EU500.00.</p>
    </blockquote>


<pre id="eg16b" class="example hljs json">
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:42",
    "profile": "http://example.com/odrl:profile:09",
    "obligation": [{
	"assigner": "http://example.com/org:43",
	"assignee": "http://example.com/person:44",
	"action": "compensate",
	"constraint": [{
		"leftOperand": "payAmount",
		"operator": "eq",
		"rightOperand": "500.00",
		"unit": "http://dbpedia.org/resource/Euro"
        }]
    }]
}
</pre>
	
	<p>A Policy may also include a consequence of not fulfilling an obligation. Note that if there is no consequence property for an obligation Duty, then the obligation MUST be fulfilled.</p>
	
	<blockquote>
<p>Example Use Case: The below Agreement includes an obligation from assigner <code>http://example.com/org:43</code> to assignee <code>http://example.com/person:44</code>  to delete the target Asset. If the obligation is not fulfilled, then a consequence is that the assigner MUST also compensate the nominated charity with a payment of EU10.00.</p>
    </blockquote>


<pre id="eg16b" class="example hljs json">
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:42B",
    "profile": "http://example.com/odrl:profile:09",
    "assigner": "http://example.com/org:43",
    "assignee": "http://example.com/person:44",
    "obligation": [{
	   "action": "delete",
	   "target": "http://example.com/document:XZY",
	   "consequence": [{
	      "action": "compensate",
	      "constraint": [{
	         "leftOperand": "payAmount",
	         "operator": "eq",
	         "rightOperand": "10.00",
	         "unit": "http://dbpedia.org/resource/Euro"
	      }],
	      "compensatedParty": "http://wwf.org"
	  }]
	}]
}
</pre>
	
</section>	

<section id="duty-perm">
<h3>Duty property with a Permission</h3>

	<p>A Duty MAY be specified as a pre-condition that requires fulfillment in order to make a Permission effective using the duty property from the Permission to the Duty. In this case the Permission is in effect (including the Permission's constraints all being satisfied) if and only if the Duty has been fulfilled.</p>
	
	<p>Since the Duty Rule is subordinate to a Permission Rule (related via the duty property) then 
		when the Duty has been fulfilled, the Permission rule is then in effect (not the Duty rule).</p>
	
	  <p>If there are no <code>assigner</code> and/or <code>assignee</code> properties declared in the Duty, then these functional roles will be the same as those declared in the referring Permission.</p>   
	
	<p>If a Permission has several Duties then all of the Duties MUST be agreed to be fulfilled for the Permission to be in effect. If several Permissions refer to the same Duty (via its <code>uid</code> property), then the Duty only has to be fulfilled <em>once</em> for all the Permissions to be effective.</p>


	<blockquote>
<p>Example Use Case: The Party <code>http://example.com/assigner:sony</code> makes an Offer to play the music file <code>http://example.com/music/1999.mp3</code>. There are two Duties that both must be fulfilled 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 <code>policyUsage</code> must not have occurred yet (that is, the payment is made before the policy is exercised).
</p>
</blockquote>


<pre id="eg15" 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:09",
    "permission": [{
        "assigner": "http://example.com/assigner:sony",
        "target": "http://example.com/music/1999.mp3",
        "action": "play",
        "duty": [{
            "action": "compensate",
            "constraint": [{
                "leftOperand": "payAmount",
                "operator": "eq",
                "rightOperand": "5.00",
                "unit": "http://dbpedia.org/resource/AUD"
            },
            {
                "leftOperand": "event",
                "operator": "lt",
                "rightOperand": "policyUsage"
            }]
        }]
    }]
}  
</pre>

	</section>
	
<section id="duty-conseq">
<h3>Consequence property with a Permission Duty</h3>

	<P>A duty of a Permission MAY include a consequence Duty of not fulfilling that duty, or the Permission exercised without fulfilling the duty. See the <a href="#duty">Duty Class </a> section for more about the consequence property.</P>
	
<blockquote>
<p>Example Use Case: The below Agreement between assigner <code>http://example.com/org:99</code> and assignee <code>http://example.com/person:88</code> allows the assignee to distribute the Asset <code>http://example.com/data:77</code> under the pre-condition they attribute the asset to Party <code>http://australia.gov.au/</code>. If the assignee does not fulfill the duty, or distributes the asset without fulfilling the duty, then the consequence will be that they will also be tracked by <code>http://example.com/dept:100</code>.</p>
    </blockquote>


<pre id="eg16" class="example hljs json">
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:66",
    "profile": "http://example.com/odrl:profile:09",
    "permission": [{
        "target": "http://example.com/data:77",
        "assigner": "http://example.com/org:99",
        "assignee": "http://example.com/person:88",
        "action": "distribute",
        "duty": [{
            "action": "attribute",
            "attributedParty": "http://australia.gov.au/",
            "consequence": [{
               "action": "acceptTracking",
               "trackingParty": "http://example.com/dept:100"
            }]
        }]
    }]
}
</pre>
	

</section>
	
<section id="duty-prohib">
<h3>Remedy property with a Prohibition</h3>
	
<p>The remedy property expresses an agreed Duty that MUST be fulfilled in case that a Prohibition has been violated by being exercised. If the Prohibition is exercised, then the remedy Duty MUST be fulfilled.</p>
	
	<p>Note that if there is no remedy property declared for a Prohibition, then the Prohibition MUST NOT be  exercised. A remedy MUST NOT refer to a Duty that includes a consequence Duty.</p>
	
	<p>Since the Duty Rule is subordinate to a Prohibition Rule (related via the remedy property) then when the Duty has been fulfilled, the Prohibition rule is then in effect (not the Duty rule).</p>
	
	
		<blockquote>
<p>Example Use Case: The below Agreement between assigner <code>http://example.com/person:88</code> and assignee <code>http://example.com/org:99</code> prohibits the assignee to modify the Asset <code>http://example.com/data:77</code>. If the assignee does actually modify the target asset, then the remedy will be that the MUST delete the target asset <code>http://example.com/data:77</code>.</p>
    </blockquote>


<pre id="eg16" class="example hljs json">
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:33CC",
    "profile": "http://example.com/odrl:profile:09",
    "prohibition": [{
        "target": "http://example.com/data:77",
        "assigner": "http://example.com/person:88",
        "assignee": "http://example.com/org:99",
        "action": "modify",
        "remedy": [{
            "action": "delete",
            "target": "http://example.com/data:77"
        }]
    }]
}
</pre>
	

	</section>
	
</section>

<section id="constraint">
<h3>Constraints</h3>
    
    <p>Constraints are boolean/logical expressions that refine the applicability of a Rule, or the context of a Party/Asset Collection. 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. The evaluation of a Constraint is treated as a <em>black box</em> outside of the ODRL Processor with the outcome of this evaluation determining if the Constraint has been <em>satisfied</em> or not.</p>
    
    <p>ODRL Processors MUST check if a Constraint is satisfied at the time of processing the relevant Rule, or Party/Asset Collection. For a Rule, if the Constraint is satisfied then the action becomes effective for the enclosing Rule. For a Party/Asset Collection, if the Constraint is satisfied, then the individual Asset or Party member or multiple members - a subset of the Collection - becomes effective for the enclosing Rule.</p>
 
    <p>When multiple Constraints apply to the same Rule, Party/Asset Collection then they are interpreted as conjunction. A Rule becomes effective if all of its Constraints are satisfied. Parties and Assets (members of the Collection) become effective is all of the Constraints on Party/Asset Collections are satisfied. </p>
    
<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  expression evaluates to <strong>true</strong> the Constraint is satisfied.
 The Constraint class formulates a comparison expressions, such as, the number of usages (<code>leftOperand</code>) must be smaller than (<code>operator</code>) the number 10 (<code>rightOperand</code>). 
</p>
       
<p>The Constraint class has the following properties:</p>
<ul>
<li>A Constraint MUST have one <code>leftOperand</code> property for a Left Operand.</li>
<li>A Constraint MUST have one <code>operator</code> property for a relational Operator.</li>
<li>A Constraint MUST have either one <code>rightOperand</code> property for a right operand value (literal or IRI [[!rfc3987]]) or one <code>rightOperandReference</code> property for an IRI [[!rfc3987]] reference to a right operand value.</li>
<li>A Constraint MAY have none or one <code>dataType</code> property for the data type of the rightOperand/Reference.</li>
<li>A Constraint MAY have none or one <code>unit</code> property for the unit value of the rightOperand/Reference.</li>
<li>A Constraint MAY have none or one <code>status</code> property for the current value generated from the leftOperand action.</li>
</ul>     
    
<p>The <code>leftOperand</code> MUST clearly be semantically <strong>defined</strong> to indicate the subject of the Constraint, and MAY declare 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>. The ODRL Common Vocabulary [[!odrl-vocab]] defines <code>leftOperand</code>'s that MAY be used by ODRL Profiles.</p>
    
<p>The <code>operator</code> identifies the relational operation such as &#8220;greater than&#8221; or &#8220;equal to&#8221 between the left and right operands.</p>

<p>The <code>rightOperand</code> identifies the right operand of the logic expression. The <code>rightOperand</code> is the value (a literal or IRI) 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><blockquote>
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.
  </blockquote> </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 &#8220;EU currency&#8221;.</p>

<p>The <code>status</code> provides the current value generated from the <code>leftOperand</code> action. 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.</p>

<blockquote>
<p>Example Use Case: In the first example below, the Party <code>http://example.com/myPix:6161</code> wants to offer the <code>distribute</code> Permission for a specific country for the target Asset. The offer has two Duties to <code>compensate</code> the assigner and a <code>nextPolicy</code>. The potential assignee may distribute the target Asset <code>http://example.com/wallpaper:1234</code> according to the Policy target Asset. The second example shows that the Policy  <code>http://example.com/policy:7171</code> stipulates  the potential assignee may only offer the <code>display</code> Permission to other parties.</p>
    </blockquote>
    
<pre id="eg17" 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/wallpaper:1234",
        "assigner": "http://example.com/myPix:6161",
        "action": "distribute",
        "constraint": [{
            "leftOperand": "spatial",
            "operator": "eq",
            "rightOperand": "https://www.iso.org/obp/ui/#iso:code:3166:IT"
        }],
        "duty": [
            {
                "action": "compensate",
                "constraint": [{
                    "leftOperand": "payAmount",
                    "operator": "eq",
                    "rightOperand": "100.00",
                    "dataType": "http://www.w3.org/2001/XMLSchema#decimal",
                    "unit": "http://dbpedia.org/resource/Euro"
                }]
            },
            {
                "action": "nextPolicy",
                "target": "http://example.com/policy:7171"
            }
        ]
    }]
}
</pre>
    
<pre id="eg18" class="example hljs json">
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Set",
    "uid": "http://example.com/policy:7171",
    "profile": "http://example.com/odrl:profile:10",
    "permission": [{
        "target": "http://example.com/wallpaper:1234",
        "action": "display"
    }]
}
</pre>
</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. 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 constraints to be compared.</li>
</ul>    
    
<p>An ODRL validator 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 processing model 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>
		<li>These 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).</li>
    </ol>

	<P>A Logical Constraint will reference existing Constraints that MAY appear at the Policy-level. These Constraints MUST NOT to be interpreted as Constraints on all the Rules in the Policy.
	</P>
	
   <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>. </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": "reproduce",
        "constraint": {
             "xone": ["http://example.com/p:88/C1", "http://example.com/p:88/C2"]
            },
    }],
   "constraint": [{
       "uid": "http://example.com/p:88/C1",
       "leftOperand": "media",
       "operator": "eq",
       "rightOperand": "online"
   },
   {
       "uid": "http://example.com/p:88/C2",
       "leftOperand": "media",
       "operator": "eq",
       "rightOperand": "print"
   }]
}  
</pre>

	<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-asset">
<h3>Asset Constraint</h3>
 
 <p>   
	  Constraints MAY be applied to an <code>AssetCollection</code> to indicate the context under which to identify the individual Asset(s) that are effective to the Rule. The constraint applies to the characteristics of each member of the collection (and not the resource as a whole). </p>
	 
	<p>Note that when using Constraints, the <code>uid</code> property MUST NOT be used to <strong>identify</strong> the <code>AssetCollection</code>. Instead, the <code>source</code> property MUST be used to <strong>reference</strong> 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 constraint that specifies further context on 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",
            "constraint": [{
                "leftOperand": "runningTime",
                "operator": "lt",
                "rightOperand": "60",
                "unit": "http://qudt.org/vocab/unit/MinuteTime"
            }],
        },
        "action": "play"
    }]
}
</pre>
    
</section>
    
<section id="constraint-party">
<h3>Party Constraint</h3>
 
	 <p>   
	  Constraints MAY be applied to a <code>PartyCollection</code> to indicate the context under which to identify the individual Parties that are effective to the Rule. The constraint applies to the characteristics of each member of the collection (and not the resource as a whole). </p>
	 
	<p>Note that when using Constraints, the <code>uid</code> property MUST NOT be used to <strong>identify</strong> the <code>PartyCollection</code>. Instead, the <code>source</code> property MUST be used to <strong>reference</strong> 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 constraint 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",
            "constraint": [{
                "leftOperand": "foaf:age",
                "operator": "gt",
                "rightOperand": "17"
            }],
        },
        "action": "display"
    }]
}
</pre>
    
</section>
    
</section>

    	
<section id="composition">
<h4>Policy Rule Composition</h4>
             
    <p>The ODRL Information Model provides the normative cardinalities for property relationships to Rules.  At the core level, an ODRL Rule would be related to one Asset, one or more Party functional roles, one Action (and potentially to Constraints and/or Duties)</p>

	<p>The Policy Rules Composition permits each Rule to extend the cardinality requirements of the ODRL Information Model to support a Rule being related to multiple Assets, Parties, and Actions. The purpose is to combine common properties (in a single Rule) to express a more compound Policy. The Policy SHOULD then be processed into its normative <em>atomic</em> equivalent.</p>

	  <blockquote>
		<p> The example below shows the <em>atomic</em> level of a Policy where it is an irreducible Rule (that is, not able to be reduced or further simplified).</p>
	</blockquote>    
<pre id="eg23" class="example hljs json">
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:7777",
    "profile": "http://example.com/odrl:profile:20",
    "permission": [{
        "target": "http://example.com/music/1999.mp3",
        "assigner": "http://example.com/org/sony-music",
        "action": "play",
    }]
} 
</pre>

  <blockquote>	
<p>The below example Policy includes two target Assets and two actions in the same permission Rule.</p>
	</blockquote>
<pre id="id24" class="example hljs json">
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:8888",
    "profile": "http://example.com/odrl:profile:20",
    "permission": [{
        "target": [ "http://example.com/music/1999.mp3",
                    "http://example.com/music/PurpleRain.mp3" ],
        "assigner": "http://example.com/org/sony-music",
        "action": [ "play", "stream" ]
    }]
}
</pre>
 <blockquote>	
<p>The above example can then be reduced to four <em>atomic</em> permission Rules. Each permission Rule will include a single target and a single action.</p>
	</blockquote>	  
<pre id="eg25" class="example hljs json">
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:8888",
    "profile": "http://example.com/odrl:profile:20",
    "permission": [{
        "target": "http://example.com/music/1999.mp3",
        "assigner": "http://example.com/org/sony-music",
        "action": "play"
    },
    {
        "target": "http://example.com/music/1999.mp3",
        "assigner": "http://example.com/org/sony-music",
        "action": "stream"
    },
	{
        "target": "http://example.com/music/PurpleRain.mp3",
        "assigner": "http://example.com/org/sony-music",
        "action": "play"
    },
	{
        "target": "http://example.com/music/PurpleRain.mp3",
        "assigner": "http://example.com/org/sony-music",
        "action": "stream"
    }]
}
</pre>
    
    <p>In order to create the <em>atomic</em> Rules in a Policy, the processing model for Rules with multiple Assets, Parties, and Actions includes:</p>
    <ol>
    <li>Where there are multiple Assets (with the same relation), then replace the existing Rule by newly created  Rules (one for each of these Assets) and include only one Asset relation, and include all other (non-Asset) properties, in each Rule</li>
    <li>Where there are multiple Parties (with the same function), then replace the existing Rule by newly created Rules (one for each of these Parties) and include only one Party function, and include all other (non-Party) properties, in each Rule.</li>
    <li>Where there are multiple Actions, then replace the existing Rule by newly created  Rules (one for each of these Actions) and include only one Action, and include all other (non-Action) properties, in each Rule.</li>
    </ol>
      
<section id="composition-compact">
<h4>Compact Policy</h4>
	
	
<p>An ODRL Policy MAY hold properties, declared at the Policy-level, which are shared and common to all its Rules. This is aimed only as a <em>short-cut</em> method to support more <strong>compact</strong> serialisations. These shared properties MUST NOT be interpreted as Policy-level properties (such as those defined in the <a href="#policy">Policy Class</a> section).
	
	<p>Properties that MAY be shared include:</p>
	<ul>
	<li>One or many <code>action</code> properties.</li>
	<li>One or many sub-properties of <code>relation</code> (such as <code>target</code>).
 </li>
	<li>One or many sub-properties of <code>function</code> (such as <code>assigner</code> and <code>assignee</code>).</li>
	
	</ul>

	<p>The processing model for expanding short-cuts in a Policy is:</p>
    <ol>
    <li>For each Rule in the Policy:</li>
		<ul>
        <li>Verify any relevant shared properties (at the Policy-level).</li>
    <li>Replicate these properties in the Rule.</li>
		</ul>
		<li>Remove the shared properties declared at the Policy-level</li>
    </ol>
       
	 <p>Further, follow the processing model to create <em>atomic</em> Rules in the Policy (defined in the previous section).</p> 
	
    <p>It is RECOMMENDED that compact ODRL Policies be expanded to atomic Policies when being processed for conformance.</p>
	
	<p>The example below shows such shared common properties applied to a Policy:</p>
             
<pre id="eg26" class="example hljs json">
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:8888",
    "profile": "http://example.com/odrl:profile:21",
    "target": "http://example.com/music/1999.mp3",
    "assigner": "http://example.com/org/sony-music",
    "action": "play",
    "permission": [{
        "assignee": "http://example.com/people/billie"
        },
        {
        "assignee": "http://example.com/people/murphy"
        }]
}  
</pre>

	<p>The example below shows how these shared properties are expanded to the Permissions of the Policy following the processing rules above.</p>
    
<pre id="eg27" class="example hljs json">
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:8888",
    "profile": "http://example.com/odrl:profile:21",
    "permission": [{
        "assignee": "http://example.com/people/billie",
        "target": "http://example.com/music/1999.mp3",
        "assigner": "http://example.com/org/sony-music",
        "action": "play"
        },
        {
        "assignee": "http://example.com/people/murphy",
        "target": "http://example.com/music/1999.mp3",
        "assigner": "http://example.com/org/sony-music",
        "action": "play",
        }]
}  
</pre>  
  
	</section>
	
    </section>
             
     <section id="metadata">
<h4>Policy Metadata</h4>
         
       <p>Additional metadata properties MAY be added to a Policy to support further authenticity, and integrity purposes from external vocabularies. The ODRL Information Model recommends the use of Dublin Core Metadata Terms [[dcterms]] for ODRL Policies.</p>
         
         <p>The following Dublin Core Metadata Terms [[dcterms]] properties SHOULD be used:</p>
            <ul>
         <li>none, one, or many <code>dc:creator</code> properties - the individual, agent, or organisation that authored the Policy.</li>
		<li>none, one, or many <code>dc:description</code> properties - a human-readable representation or summary of the Policy.</li>
         <li>none or one <code>dc:issued</code> property - the date (and time) the Policy was first issued.</li>
         <li>none or one <code>dc:modified</code> property -  the date (and time) the Policy was updated.</li>
        <li>none, one, or many <code>dc:coverage</code> properties -  the jurisdiction under which the Policy is relevant.</li>
        <li>none or one <code>dc:replaces</code> property -  the identifier (uid) of a Policy that this Policy supersedes.</li>
        <li>none or one <code>dc:isReplacedBy</code> property -  the identifier (uid) of a Policy that supersedes this Policy.</li>
         </ul>
         
    <p>The processing model for Policies with the above metadata properties include:</p>
    <ol>
    <li>If a Policy has the <code>dc:isReplacedBy</code> property, then a processor MUST consider the first Policy invalid and MUST retrieve and process the identified Policy.</li>
    </ol>

<blockquote>
<p>Example Use Case: The below example shows metadata properties that indicate who created the Policy, a description, when the Policy was issued, which jurisdiction (an identifier of Queensland, Australia) the Policy applies to, and an identifier of an older version of the Policy it replaces.</p>     </blockquote>
         
<pre id="eg28" class="example hljs json">
{
    "@context": [
        "http://www.w3.org/ns/odrl.jsonld",
        { "dc": "http://purl.org/dc/terms/" }
    ],
    "@type": "Policy",
    "uid": "http://example.com/policy:8888",
    "profile": "http://example.com/odrl:profile:22",
    "dc:creator": "Billie Enterprises LLC",
    "dc:description": "This policy covers...",
    "dc:issued": "2017-01-01T12:00",
    "dc:coverage": { "@id": "https://www.iso.org/obp/ui/#iso:code:3166:AU-QLD" },
    "dc:replaces": { "@id": "http://example.com/policy:8887" },
    "permission": [{...}]
}  
</pre>

<p>Note: The string values used in the Dublin Core metadata properties are not designed for comparison of Policy metadata, as they may not be normalised.</p>
	
	</section>
    
    
<section id="inhertiance">
<h4>Policy Inheritance</h4>

    <p>ODRL supports an inheritance mechanism in which a (child) Policy may inherit all the atomic Rules of one or more (parent) Policies.
       The <code>inheritFrom</code> property MUST be used in a child Policy that is inheriting from a parent Policy and MAY include multiple identifiers of parent Policies.</p>


<p>The following apply when using inheritance:</p>
<ul>
<li>Inheritance can be to any depth. (Multiple levels of children Policies.)</li>
<li>Inheritance MUST NOT be circular.</li>
<li>No constraint <code>status</code> information is transferred from the parent Policy to the child Policy. That is, if the parent Policy had <code>status</code> properties with values, then these values would be nulled.</li>
</ul>

    <blockquote>
<p>Example Use Case: Consider the (parent) Policy <code>http://example.com/policy:default</code> below (the assigner wishes to provide default permissions for all Policies). It does not refer to any target Asset and allows the archive and annotate Permissions and disallows the aggregate Prohibition.</p>    
</blockquote>
    
    <pre id="eg29" class="example hljs json">
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:default",
    "profile": "http://example.com/odrl:profile:30",
    "permission": [{
        "assigner": "http://example.com/org-01",
        "action": [ "archive", "annotate" ]
    }],
    "prohibition": [{
        "assigner": "http://example.com/org-01",
        "action": "aggregate"
    }]
}  
</pre>
    
<p>The child <code>Agreement</code>Policy <code>http://example.com/policy:4444</code> below shows the <code>inheritFrom</code> property pointing to the parent Policy <code>http://example.com/policy:default</code> (above). The child Policy also shows the Asset, the actions (to display and print the Asset) and the assignee Party for the Agreement.</p>    
    
<pre id="eg30" 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:30",
    "inheritFrom": "http://example.com/policy:default",
    "permission": [{
        "target": "http://example.com/asset:5555",
        "action": [ "display", "print" ],
        "assignee": "http://example.com/user:0001"
    }]
}  
</pre>
    

<p>After the inheritance is performed - where the (parent) Policy atomic Rules are added to the (child) Policy - the resulting Policy is shown below. As this is an Agreement Policy, the assignee also becomes part of the inherited Prohibition.</p>    
    
    <pre id="eg31" 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:30",
    "inheritFrom": "http://example.com/policy:default",
    "permission": [{
        "target": "http://example.com/asset:5555",
        "action": [ "archive", "annotate", "display", "print" ],
        "assigner": "http://example.com/org-01",
        "assignee": "http://example.com/user:0001"
    }],
    "prohibition": [{
        "action": "aggregate",
        "assigner": "http://example.com/org-01",
        "assignee": "http://example.com/user:0001"
    }]
}
</pre>
    
   
<p>The processing model for ODRL Policy Inheritance includes:</p>
    <ol>

        <li>The (child) Policy MUST access the (parent) Policy and replicate the following in the (child) Policy:
       <ul>
           <li>All policy-level Assets, Parties, Actions from the (parent) Policy.</li>
           <li>All Rules from the (parent) Policy.</li>
       </ul>
            </li>
		<li>Repeat the above for each identified (parent) Policy.</li>
      <li>The (child) Policy can then be further expanded (into <em>atomic</em> Rules) by following the processing models defined in the <a href="#composition">Policy Composition</a> section.</li>  
    </ol>
        
	
</section>
    
<section id="conflict">
<h4>Policy Conflict Strategy</h4>
        
<p>The <code>conflict</code> property 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 as a result of <a href="#inhertiance">Policy Inheritance</a> and the resultant Rules are inconsistent.</p>
      
    <p>The <code>conflict</code> property SHOULD take one of the following Conflict Strategy Preference values:</p>
<ul>
<li><code>perm</code>: the Permissions MUST override the Prohibitions</li>
<li><code>prohibit</code>: the Prohibitions MUST override the Permissions</li>
<li><code>invalid</code>: the entire Policy MUST be invalid if any conflict is detected</li>
</ul>
<p>If the <code>conflict</code> property is not explicitly set, the default of <code>invalid</code> will be used. <p>Additional <code>conflict</code> property values MAY be defined by ODRL Profiles.</p>

        
<p>If an ODRL processor does not detect any conflicts in the Rules, then the ODRL Policy is valid, otherwise the ODRL processor MUST follow these processing rules:</p>
   
<ol>
        <li>If a Policy has the <code>conflict</code> property of <code>perm</code> then any conflicting Permission Rule MUST override the Prohibition Rule and continue with the Policy as valid.</li>
 <li>If a Policy has the <code>conflict</code> property of <code>prohibit</code> then any conflicting Prohibition Rule MUST override the Permission Rule and continue with the Policy as valid.</li>
  <li>If a Policy has the <code>conflict</code> property of <code>invalid</code> then  processing MUST NOT continue and the entire Policy MUST be invalid.</li> 
 <li>If a Policy has multiple <code>conflict</code> property values (for example, after a Policy merge or inheritance) then processing MUST NOT continue and the entire Policy MUST be invalid.</li> 
        </ol>
       
        
<blockquote>
<p>Example Use Case: Two Policies are associated to the same target Asset <code>http://example.com/asset:1212</code>. The first Policy <code>http://example.com/policy:0001</code> allows to <code>use</code> the Asset. The second Policy <code>http://example.com/policy:0002</code> allows for the display of the Asset, but it prohibits <code>print</code>. Both policies explicitly state how to deal with conflicts through the <code>conflict</code> property being set to <code>perm</code>. Hence the Permissions will always override any Prohibitions. In this use case, since the <code>print</code> Action is a specialisation of the <code>use</code> Action, there could be a conflict. However, the <code>perm</code> conflict strategy means that the <code>use</code> Permission will override the <code>print</code> Prohibition.</p>
</blockquote>

        
<pre id="eg32" class="example hljs json">
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:0001",
    "profile": "http://example.com/odrl:profile:40",
    "conflict": "perm",
    "permission": [{
        "target": "http://example.com/asset:1212",
        "action": "use",
        "assigner": "http://example.com/owner:181"
    }]
}
</pre>

<pre id="eg33" class="example hljs json">
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:0002",
    "profile": "http://example.com/odrl:profile:40",
    "conflict": "perm",
    "permission": [{
        "target": "http://example.com/asset:1212",
        "action": "display",
        "assigner": "http://example.com/owner:182"
    }],
    "prohibition": [{
        "target": "http://example.com/asset:1212",
        "action": "print"
    }]
}
</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>

<section id="odre"><h2>ODRL Evaluator</h2>
<div class="issue" data-number="86">This is a suggestion for how such a (normative) section might be included.</div>

<p>The task of an ODRL Evaluator is to determine which Rule(s) are <em>in effect</em> for a given Asset and, if relevant, to which Party the Rule(s) apply. The method by which this is achieved is left to individual implementations but a key task is to determine whether or not constraints have been satisfied. Again, the processes by which this determination is made is not defined, however, it is expected that the result of such a determination is a binary <code>satisfied|not satisfied</code>.</p>
<p><a href="#eg1">Example 1</a> simply states that permission is granted to play the Asset http://example.com/asset:9898.movie. The output of an ODRL Evaluator SHALL therefore simply be:</p>
<p class="Rule">Permission to play http://example.com/asset:9898.movie</p>
<p><a href="#eg2">Example 2</a> extends this by including the assigner and so the output of the Evaluator SHALL be:</p>
<p class="Rule">http://example.com/party:org:abc grants Permission to play http://example.com/asset:9898.movie</p>
<p><a href="#eg3">Example 3</a> extends this further by defining a specific Party to which the Rule applies so the output SHALL be:</p>
<p class="Rule">http://example.com/party:org:abc grants Permission to http://example.com/party:person:billie to play http://example.com/asset:9898.movie</p>
<p>An Evaluator MUST have a means of evaluating constraints or passing such processing to some external process and receiving a <code>satisfied|not satisfied</code> response. If an Evaluator is unable to determine whether or not a constraint has been satisfied then the response SHALL be:</p>
<p class="Rule">Not Known</p>
<p><a href="#eg13">Example 13</a> includes the constraint that the assignee http://example.com/org:xyz gives permission to play http://example.com/game:9090 on or after 31 December 2017. Therefore, up to and including 30 December 2017, the output of an ODRL Evaluator SHALL be:</p>
<p class="Rule">No rules in effect</p>
<p>Where no rules are in effect, the policy is effectively silent on what actions may or may not be performed. Continuing with Example 13, from 31 December 2017 onwards, the output SHALL be:</p>
<p class="Rule">http://example.com/org:xyz gives permission to play http://example.com/game:9090</p>
<p><a href="#eg14">Example 14</a> introduces the <code>conflict</code> resolution property (and does not include any constraints). The output of an ODRL Evaluator SHALL be:</p>
<p class="Rule">http://example.com/MyPix:55 grants Permission to http://example.com/assignee:55 to display  http://example.com/photoAlbum:55. http://example.com/MyPix:55 Prohibits http://example.com/assignee:55 from Archiving http://example.com/photoAlbum:55. In the case of conflict, the Permission takes precedence.</p>
<p class="note">And so on. Note that an id attribute has been added to all examples in the doc for cross-referencing. ReSpec doesn't do this for you (surprisingly). Local CSS class of Rule defined for this - change at will, obviously.</p>
</section>


<section id="profile" >
<h2>ODRL Profiles</h2>

<section id="profile-motivation">
    <h3>ODRL Profile Purpose</h3>
        
	<p>The ODRL Information Model serves as the core framework and vocabulary to express policies. The ODRL Core Vocabulary [[!odrl-vocab]] articulates this set of vocabulary terms. An ODRL policy may be expressed using the ODRL Core Vocabulary, and this represents the minimally supported policy expression.</p>
	
	<p>To provide additional terms (beyond the ODRL Core Vocabulary), then an ODRL Profile MUST be used. An ODRL Profile explicitly serves community needs by specifying the vocabulary terms they require to be supported in ODRL policy expressions. These terms may be defined explicitly or may be adopted from the ODRL Common Vocabulary.</p>
	
	<p>The ODRL Common Vocabulary [[!odrl-vocab]] provides a generic range of common actions for Permissions, Prohibition, and Duties as well as Policy subclasses, Constraint left operands and operators, Asset relations, and Party functions.</p>
        
        
    </section>

	<section id="profile-conformance">
    <h3>ODRL Profile Conformance</h3>
		<p>
    In an ODRL Policy, the <code>profile</code> property MUST be specified to indicate the identifier (IRI) of the ODRL Profile for which the Policy expression conforms to. There MAY be multiple identifiers used to indicate that an ODRL Policy conforms to multiple ODRL Profiles.</p>
		<p>When an ODRL Profile(s) is used in an ODRL Policy, an ODRL Processing system MUST understand the semantics of the identified ODRL Profile(s). If the ODRL Processing system does not recognise the ODRL Profile identifier(s) then it MUST stop processing the policy. </p>
    
		
	</section>
	
    <section id="profile-mechanism">
    <h3>ODRL Profile Mechanism</h3>
 
<p>
To create an ODRL Profile, direct extensions to the ODRL Core Vocabulary classes, properties, and instances are defined in the following way:
   </p>


<table class="def">
 <tbody>
   <tr>
     <th style="width:40%">ODRL Profile Definition</th>
     <th>Example</th>
   </tr>
   <tr>
	   <td>Additional Policy Subclasses:<br/>Create a subclass the ODRL Policy class.</td>
     <td><code>ex:myPolicyType rdfs:subClassOf odrl:Policy ;</code></td>
   </tr>
   <tr>
     <td>Additional Asset Relationships:<br/>Create a sub-property of the abstract <em>relation</em> property.</td>
     <td><code>ex:myRelation rdfs:subPropertyOf odrl:relation ;</code></td>
   </tr>
   <tr>
     <td>Additional Party Functional roles:<br/>Create a sub-property of the abstract <em>function</em> property.</td>
     <td><code>ex:myFunctionRole rdfs:subPropertyOf odrl:function ;</code></td>
   </tr>
   <tr>
     <td>Additional Actions for Rules:<br/>
		 Create an instance of an Action and define its includedIn parent Action.<br/>
	     The new Action MAY be defined as <code>includedIn</code> to any existing Action. <br/>
        If the new Action forms a dependency with another new or existing Action, then define the two actions with the <code>implies</code> property
    </td>
     <td><code>ex:myAction a :Action ;</code><br/>
          <code>ex:myAction odrl:includedIn odrl:use ;</code>
		 <br/><br/><br/>
		 <code>ex:myAction odrl:implies odrl:distribute ;</code>
	  </td>
   </tr>
   <tr>
     <td>Additional Constraint left operands:<br/>Create an instance of the LeftOperand class.</td>
     <td><code>ex:myLeftOperand a odrl:LeftOperand ;</code></td>
	 </tr>
   <tr>
     <td>Additional Constraint right operands:<br/> Create an instance of the RightOperand class.</td>
     <td><code>ex:myRightOperand a odrl:RightOperand ;</code></td>
   </tr>
   <tr>
     <td>Additional Constraint relational operators:<br/>Create an instance of the Operator class.</td>
     <td><code>ex:myOperator a :Operator ;</code></td>
   </tr>
   <tr>
     <td>Additional Logical Constraint operands:<br/>Create a sub-property of the abstract <em>operand</em> property.</td>
     <td><code>ex:myLogicalOp rdfs:subPropertyOf odrl:operand ;</code></td>
   </tr>
   <tr>
     <td>Additional Policy Conflict strategies:<br/>Create an instance of the ConflictTerm class.</td>
     <td><code>:myStrategy a :ConflictTerm ;</code></td>
   </tr>
   <tr>
     <td>Additional Rule class:<br/>Create a subclass of the Rule class and define it as disjoint with the other Rule subclasses.</td>
     <td><code>:myRule	rdfs:subClassOf :Rule ; </code><br/>
	    <code>owl:disjointWith :Prohibition, :Duty :Permission ; </code></td>
   </tr>
</tbody>
</table>
		 

    <p>All new classes (<code>rdfs:Class</code>, <code>owl:Class</code>), properties (<code>rdf:Property</code>, <code>owl:ObjectProperty</code>), and instances (<code>owl:NamedIndividual</code>) must also be defined as a <code>skos:Concept</code>. Appropriate <code>rdfs:domain</code> and <code>rdfs:range</code> should also be defined for classes.</p>
    <p>Human-readable documentation is also recommended for each new term using  <code>rdfs:label</code> for the name, <code>skos:definition</code> for the formal definition, and <code>skos:note</code> for additional comments on its use.</p>
</section>
   
	    <section id="profile-core">
    <h3>ODRL Core Profile</h3>
			
			<p>
			In circumstances that require the ODRL Core Profile to be identified, that is the Policy <strong>only</strong> conforms to the ODRL Core Vocabulary, then the following identifier MAY be used for the Core Profile: <code>http://www.w3.org/ns/odrl/2/core</code>
			</p>
	</section>
	
</section>
 
    
<section id="privacyConsiderations" class="informative">

<h2>Privacy Considerations</h2>
  <p>
    The ODRL Information Model does not directly express sensitive personal information such as the identity of the existence of Assets containing such data related to Parties. However, ODRL vocabularies (such as the ODRL Common Vocabulary [[!odrl-vocab]] and ODRL Profiles) may define terms that may relate to personal information. These specifications should inform implementations that produce or consume such ODRL expressions to take steps to communicate to all relevant users the manner in which the policy is being used, the identity of any other party with whom that policy is being shared, and the reason the policy is being shared with other parties.

</p>
</section>

<section class="appendix">
<h3>Acknowledgements</h3>

<p>The POE Working Group gratefully acknowledges the contributions of the <a href="http://www.w3.org/community/odrl/">ODRL Community Group</a> and the earlier <a href="https://www.w3.org/2012/09/odrl/archive/odrl.net/index.html">ODRL Initiative</a>. In particular the editors would like to thank Susanne Guth, Daniel Paehler, and Andreas Kasten for their past editorial contributions.</p>
</section>

    
<section class="appendix" id="cgrel">
<h2>Relationship to the W3C ODRL Community Group Reports</h2>

    
<p>The basis for the deliverables for the Permissions &amp; Obligations Expression Working Group are the reports created by the <a href="https://www.w3.org/community/odrl/">W3C ODRL Community Group</a>. The ODRL Community Group has developed a family of specifications to support innovative expression of  asset usage for the publication, distribution and consumption of content services.
The final outputs of the ODRL Community Group were the ODRL Version 2.1 specifications that were a major update for ODRL and superseded the original ODRL Version 1.1 [[odrl]] (published as a W3C NOTE).</p>
    
<p>The following documents are part of the ODRL Community Group report series:</p>
<ul>
<li>ODRL V2 Requirements [[odrl2-req]]</li>
<li>ODRL V2.1 Core Model [[odrl21-model]]</li>
<li>ODRL V2.1 Common Vocabulary [[odrl21-vocab]]</li>
<li>ODRL V2.1 XML Encoding [[odrl21-xml]]</li>
<li>ODRL V2.1 Ontology [[odrl21-onto]]</li>
<li>ODRL V2.1 JSON Encoding [[odrl21-json]]</li>
</ul>

 <p>
The ODRL Information Model was derived from the ODRL V2.1 Core Model Community Group report. Details of the differences between the W3C Working Group deliverables and the ODRL Community Group Reports are maintained in the <a href="#changes">Appendix</a>. All new ODRL implementations are expected to use the deliverables of the Permissions &amp; Obligations Expression Working Group. </p>
</section>


<section class="appendix" id="changes">
    
  <h3>Changes from Previous Versions</h3>
    <p>Changes from the <a href="https://www.w3.org/TR/2016/WD-odrl-model-20160721/">First Public Working Draft 21 July 2016</a>:</p>
<ul>
<li>Added abstract Rule class to the Information Model <a href="https://github.com/w3c/poe/issues/24">(Issue#24)</a></li>
<li>Clarified Permission cardinality <a href="https://github.com/w3c/poe/issues/17">(Issue#17)</a></li>
<li>Clarified Duty obligations <a href="https://github.com/w3c/poe/issues/18">(Issue#18)</a></li>
<li>Clarified Duty only applicable to Permission  <a href="https://github.com/w3c/poe/issues/19">(Issue#19)</a></li>
<li>Clarified conflict of Permissions/Prohibitions may arise also within the same policy <a href="https://github.com/w3c/poe/issues/20">(Issue#20)</a></li>
<li>Clarified Party definition and its relation with role <a href="https://github.com/w3c/poe/issues/23">(Issue#23)</a></li>
    
<li>Additional description on the purpose and use of ODRL Profiles.<a href="https://github.com/w3c/poe/issues/49">(Issue#49)</a></li>
 
    <li>Modified UML model to have Inheritance as separate association class.<a href="https://github.com/w3c/poe/issues/51">(Issue#51)</a></li>

    <li>Added example use cases through-out the Model sections and have removed the Scenarios sections (as they are covered in the examples).<a href="https://github.com/w3c/poe/issues/50">(Issue#50)</a></li>

        <li>Updated the Scope for Parties (and new for Assets) to allow any URI to scope the characteristics of the entity. <a href="https://github.com/w3c/poe/issues/59">(Issue#59)</a></li>

       <li>Added rightOperandReference to Constraint. <a href="https://github.com/w3c/poe/issues/56">(Issue#56)</a></li>
    
      <li>Clarified Constraint related definitions. <a href="https://github.com/w3c/poe/issues/81">(Issue#81)</a></li>
    
         <li>Support multiple Assets, Parties, and Actions. <a href="https://github.com/w3c/poe/issues/73">(Issue#73)</a></li>
    
           <li>Support Policy-level Assets, Parties, and Actions. <a href="https://github.com/w3c/poe/issues/82">(Issue#82)</a></li>
    
       <li>Clarified and simplified Policy Inheritance.<a href="https://github.com/w3c/poe/issues/22">(Issue#22)</a></li>
    
     <li>Added Policy Provenance section. <a href="https://github.com/w3c/poe/issues/48">(Issue#48)</a></li>
    
    <li>Added Extended Relations to Constraints. <a href="https://github.com/w3c/poe/issues/63">(Issue#63)</a></li>
    
    <li>Added Constraint on Constraint support. <a href="https://github.com/w3c/poe/issues/62">(Issue#62)</a></li>
    
    </ul>
    
       <p>Changes from the <a href="https://www.w3.org/TR/2017/WD-odrl-model-20170223/">Working Draft 23 February 2017</a>:</p>
    
        <ul>
     <li>Removed inheritRelation attribute. <a href="https://github.com/w3c/poe/issues/22">(Issue#22)</a></li>
    
        
     <li>Replaced URI with IRI for I18N <a href="https://github.com/w3c/poe/issues/133">(Issue#133)</a></li>
    
    <li>Updated Information Model to be based on Class/Property concepts and removed UML requirements. <a href="https://github.com/w3c/poe/issues/128">(Issue#128)</a></li>
   
    
    <li>Removed the type property and replaced with subclasses of Policy. Added Set/Offer/Agreement to the IM. Set is now default for Policy. <a href="https://github.com/w3c/poe/issues/154">(Issue#154)</a></li>
    
     <li>Removed (deprecated) the Undefined Actions section. <a href="https://github.com/w3c/poe/issues/139">(Issue#139)</a></li>
            
    <li>Removed Scopes and replaced with Constraints on Asset and Party. <a href="https://github.com/w3c/poe/issues/183">(Issue#183)</a></li>
            
     <li>More clearly defined the scope of ODRL Profiles (addition only) and added how to create them. <a href="https://github.com/w3c/poe/issues/173">(Issue#173)</a></li>
            
    <li>Added use and transfer as the top-level actions <a href="https://github.com/w3c/poe/issues/140">(Issue#140)</a></li>
            
    <li>Added hasPolicy property <a href="https://github.com/w3c/poe/issues/184">(Issue#184)</a></li>
    
     <li>Added includedIn and implies properties for Action. Added partOf property for Asset and Party <a href="https://github.com/w3c/poe/issues/160">(Issue#160)</a></li>
			
	<li>Added assignerOf/assigneeOf properties <a href="https://github.com/w3c/poe/issues/190">(Issue#190)</a></li>
    
						
	<li>Added source property for Asset/PartyColection <a href="https://github.com/w3c/poe/issues/164">(Issue#164)</a></li>
    
    <li>Removed inheritAllowed property and support multiple inheritance <a href="https://github.com/w3c/poe/issues/204">(Issue#204)</a></li>
			
    <li>Updated constraint Model to support Logical Constraints with typed operands <a href="https://github.com/w3c/poe/issues/206">(Issue#206)</a></li>
	
	<li>Added support for Duty at Policy-level using new obligation property <a href="https://github.com/w3c/poe/issues/191">(Issue#191)</a></li>
			
	<li>Added Consequence and Remedy properties <a href="https://github.com/w3c/poe/issues/209">(Issue#209)</a></li>
			
	<li>Added mandatory use of ODRL Profiles <a href="https://github.com/w3c/poe/issues/210">(Issue#210)</a></li>
			
</ul>
</section>

</body>
</html>