ODRL Version 2.0 Core Model

You are viewing an old revision of this post, from 26 September, 2011 @ 3:58. See below for differences between this version and the current revision.

Post Revisions:

Changes:

26 September, 2011 @ 3:58Current Revision
Content
  <h3>Final Specification: 24 April 2012</h3>
  <h4>Location: http://www.w3.org/ community/odrl/ two/model/</h4>
  <p>&nbsp;</p>
  <dl>
   <dt>Editors:</dt>
   <dd>Renato Iannella, Semantic Identity, ri<img src="https:// www.w3.org/community/odrl/ files/2011/11/at.gif" alt="AT">semanticidentity.com</dd>
   <dd>Susanne Guth, Vodafone, susanne.guth<img src="https:// www.w3.org/community/odrl/ files/2011/11/at.gif" alt="AT">vodafone.com</dd>
   <dd>Daniel Paehler, University of Koblenz, tulkas<img src="https:// www.w3.org/community/odrl/ files/2011/11/at.gif" alt="AT">uni- koblenz.de</dd>
   <dd>Andreas Kasten, University of Koblenz, andreas.kasten<img src="https:// www.w3.org/community/odrl/ files/2011/11/at.gif" alt="AT">uni- koblenz.de</dd>
  </dl>
  <hr>
  <h2>Status of this document</h2>
  <p>This specification was published by the <a href="//www.w3.org/ community/odrl/">W3C ODRL Community Group</a>. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the <a href="//www.w3.org/ community/about/agreements/ cla/”">W3C Community Contributor License Agreement (CLA)</a> there is a limited opt-out and other conditions apply. Learn more about <a href="//www.w3.org/ community/”">W3C Community and Business Groups</a>.</p>
  <p>The <a href="//www.w3.org/ community/odrl/">W3C ODRL Community Group</a> publishes a Final Specification to indicate that the document is believed to be mature and stable for implementation by the wider community. This Final Specification is now endorsed by the <a href="//www.w3.org/ community/odrl/">W3C ODRL Community Group</a> as appropriate for widespread deployment and that promotes the Community Groups's mission.
  </p>
  <p>
  Discussion and feedback of this document takes place on the W3C ODRL Community Group mailing list (see <a href="http:// lists.w3.org/ Archives/Public/ public-odrl-contrib/ ">Contributor Archive</a>). Feedback from the public is encouraged and can be send to <a href="mailto: public-odrl@w3.org">public- odrl@w3.org</a> (see <a href="http:// lists.w3.org/ Archives/Public/ public-odrl/">Public Archive</a>).</p>
  <blockquote><p>
  <strong><br />
  Copyright © 2012 the Contributors to the Final Specification, published by the <a href="//www.w3.org/ community/odrl/">W3C ODRL Community Group</a> under the <a href="http:// www.w3.org/community/about/ agreements/final/">W3C Community Final Specification Agreement (FSA)</a>. A human-readable <a href="http:// www.w3.org/community/about/ agreements/fsa- deed/">summary</a> is available.</strong>
  </p></blockquote>
  <h2><a name="contents">Table of contents</a></h2>
  <ul>
  <li><a href="#section-1">1. Overview</a> </li>
  <li><a href="#section-2">2. ODRL Core Model</a> </li>
   <ul>
   <li><a href="#section-21">2.1 Policy</a> </li>
   <li><a href="#section-22">2.2 Asset</a> </li>
   <ul><li><a href="#section-221">2.2.1 Relation</a></li></ul>
   <li><a href="#section-23">2.3 Party</a> </li>
   <ul><li><a href="#section-231">2.3.1 Role</a></li></ul>
   <li><a href="#section-24">2.4 Permission</a> </li>
   <li><a href="#section-25">2.5 Duty</a> </li>
   <li><a href="#section-26">2.6 Prohibition</a> </li>
   <li><a href="#section-27">2.7 Action</a> </li>
   <li><a href="#section-28">2.8 Constraint</a> </li>
   </ul>
  <li><a href="#section-3">3. Scenarios (Informative)</a> </li>
  <li><a href="#section-4">4. Profiles (Informative)</a> </li>
  <li><a href="#section-5">5. Experimental Features (Informative)</a></li>
  <li><a href="#section- Acknowledgements" >Acknowledgements</a> </li>
  <li><a href="#section- References">References</a> </li>
  </ul>
  <hr>
  <h2><a name="section-1"></a>1. Overview</h2>
  <p>The ODRL policy expression language has benefited from a robust underlying information model that has captured its semantics and provided extensibility paths for various communities. ODRL Version 2.0 is a major update for ODRL and will supersede Version 1.1.<a href="#section- References">[ODRL11]</a></p>
  <p>The ODRL Core Model is designed to be independent from implementation mechanisms and is focussed on the optimal model and semantics to represent policy-based information.</p>
  <p>The following documents are part of the ODRL Version 2.0 series:</p>
  <ul>
   <li>ODRL V2.0 - Requirements <a href="#section- References">[ODRL-REQ].</a> The Requirements document represents requirements for the language that have been gathered since ODRL Version 1.1 has been released. Not all requirements are aimed to be met.</li>
   <li>ODRL V2.0 - Core Model <em>(this document)</em></li>
   <li>ODRL V2.0 - Common Vocabulary. This document specifies the terms (vocabulary) used by the Core Model for policy expression needs across communities <a href="#section- References">[ODRL-VOCAB]</a>. (This was called the "data dictionary" previously.)</li>
   <li>ODRL V2.0 - XML Encoding. The XML Encoding document specifies the serialisation of the Core Model in XML <a href="#section- References">[ODRL- XML]</a>.</li>
   <li>ODRL V2.0 - RDF Encoding. The RDF Encoding document will specify the serialisation of the Core Model in W3C Semantic Web languages.</li>
  </ul>
  <p>The updated model is based on additional semantics and requirements gathered from the DRM community, the latest research on security, access control, obligation management as well as the past experiences in implementations and research of ODRL. The requirements for Version 2.0 are documented <a href="#section- References">[ODRL-REQ]</a> and will be directly referenced in this document to ensure that they have been adequately addressed (where applicable).</p>
  <p>The model shall be formally specified using UML notation <a href="#section- References">[UML]</a> <a href="#section- References">[ODRL-REQ-6]</a> and shall utilise the key words "MUST", "MAY", "REQUIRED", and "OPTIONAL" in accordance to <a href="#section- References">[RFC2119]</a>.
  </p>
  <p>To make keywords easily distinguishable, this document uses syntax highlighting (formatted coded typeface) to indicate Core Model entities, the entities' attributes, and concrete values for the attributes.</P>
  <h2><a name="section-2"></a>2. ODRL Core Model</h2>
  <p>Figure 2.1 below shows the complete version 2.0 ODRL Core Model. <code>Policy</code> is the central entity that holds an ODRL policy together. In its encoded form, e.g. in an XML document, it makes the policy addressable from the outside word via its <code>uid</code> attribute. <code>Policy</code> can refer to <code>Permission</code>s and <code>Prohibition</code>s.
  </p>
  <p>
  A <code>Permission</code> <em>allows</em> a particular <code>Action</code> to be executed on a related <code>Asset</code>, e.g. "play the audio file abc.mp3". A <code>Constraint</code> like "at most 10 times" might be added to specify the <code>Permission</code> more precisely. The <code>Party</code> that grants this <code>Permission</code> is linked to it with the <code>Role</code> <code>assigner</code>, the <code>Party</code> that is granted the <code>Permission</code> is linked to it with the <code>Role</code> <code>assignee</code>, e.g. "<code>assigner</code> VirtualMusicShop grants the <code>Permission</code> to <code>assignee</code> Alice". Additionally, a <code>Permission</code> MAY be linked to <code>Duty</code> entities.
  </p>
  <p>
  Similar to <code>Permission</code>s, a <code>Duty</code> states that a certain <code>Action</code> MAY be executed by the <code>Party</code> with the <code>Role</code> <code>assignee</code> for the <code>Permission</code> to be valid, e.g. "Alice must pay 5 EUR in order to get the <code>Permission</code> to play abc.mp3". </p>
  <p>The <code>Prohibition</code> entity is used in the same way as <code>Permission</code>, with the two differences that it does not refer to <code>Duties</code> and (obviously) that it <em>forbids</em> the <code>Action</code>, e.g. "Alice is forbidden to use abc.mp3 commercially".
  </p>
  <table align="center">
   <tbody>
   <tr align="center">
   <td>
   <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ core-model.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ core-model.png" alt="ODRL Core Model" width="640" class="aligncenter size-full wp-image-244" /></a></p>
   </td>
   </tr>
   <tr align="center">
   <td>
   <p><b>Figure 2.1 - ODRL Core Model Version 2.0</b></p>
   </td>
   </tr>
   </tbody>
  </table>
  <p>The following sections describes each entity of the Core Model in greater detail.</p>
  <h3><a name="section-21"></a>2.1 Policy</h3>
  <p>The <code>Policy</code> entity is the top-level entity and contains the following attributes:</p>
  <ul>
   <li><code>uid</code>: the unique identification of the <code>Policy</code> entity (REQUIRED)</li>
   <li><code>type</code>: indicates the semantics of the <code>Policy</code> entity (REQUIRED). These are further described in the Common Vocabulary and ODRL Profiles.</li>
   <li><code>conflict</code>: indicates the precedence between <code>Permission</code>s and <code>Prohibition</code>s (OPTIONAL)</li>
   <li><code>undefined</code>: indicates how to handle undefined <code>Action</code>s (OPTIONAL)</li>
   <li><code>inheritAllowed</code>: indicates if the <code>Policy</code> entity can be inherited (OPTIONAL)</li>
   <li><code>inheritFrom</code>: the identifier from which this <code>Policy</code> inherits from it's parent <code>Policy</code> (OPTIONAL) </li>
   <li><code>inheritRelation</code>: the identifier for the relationship type of this inheritance structure (OPTIONAL) </li>
  </ul>
  <p>The <code>uid</code> attribute MUST be a unique identifier.</p>
  <p>The range of values for the <code>Policy</code> entity's <code>type</code> attribute will be described in the Common Vocabulary document or in community profiles. This value MAY also impose further constraints on the Core Model, such as are exemplified in the Scenarios for types <code>Offer</code> and <code>Agreement</code>. It is important that the <code>type</code> attribute be clearly understood in policy expressions as the semantics MAY impose restrictions on the expression language constructs such as cardinalities between entities. </p>
  <p>The <code>conflict</code> attribute is used to resolve conflicts arising from the merging of policies, specifically when there are conflicting <code>Action</code>s in the <code>Permission</code>s and <code>Prohibition</code>s. If present, the <code>conflict</code> attribute MUST take one of the following values:</p>
  <ul>
   <li><code>perm</code>: the <code>Permission</code>s will always takes precedence</li>
   <li><code>prohibit</code>: the <code>Prohibition</code>s will always takes precedence</li>
   <li><code>invalid</code>: the policy is not valid</li>
  </ul>
  <p>If the <code>conflict</code> attribute is not explicitly set, its default value will be used instead. The default value of the <code>conflict</code> attribute is <code>invalid</code>.</p>
  <p>The <code>undefined</code> attribute is used to indicate how to support <code>Action</code>s that are not part of any known profile in the policy expression system. If present, the <code>undefined</code> attribute MUST take one of
  the following values:</p>
  <ul>
   <li><code>support</code>: the <code>Action</code> is to be supported as part of the policy - and the policy remains valid</li>
   <li><code>ignore</code>: the <code>Action</code> is to be ignored and not part of the policy - and the policy remains valid</li>
   <li><code>invalid</code>: the <code>Action</code> is unknown - and the policy is invalid</li>
  </ul>
  <p>In the <code>support</code> case, even though the <code>Action</code> is unknown, the policy still is valid and the consuming parties or system of the policy MUST be made aware of the unknown <code>Action</code>. This MAY be via a user interface that displays the unknown <code>Action</code> for human readability.</p>
  <p>In the <code>ignore</code> case, even though the <code>Action</code> is unknown, the policy still is valid and the consuming parties or system of the policy MAY be made aware of the unknown <code>Action</code>.</p>
  <p>In the <code>invalid</code> case with the unknown <code>Action</code>, the policy is invalid and the consuming parties or system of the policy MUST be made aware of this.</p>
  <p>If the <code>undefined</code> attribute is not explicitly set, its default value will be used instead. The default value of the <code>undefined</code> attribute is <code>invalid</code>.</p>
  <p>Other attributes MAY be added to the <code>Policy</code> entity to support additional functions and requirements. Typically, these will be from different community vocabularies. For example, to indicate the issued date or valid dates of the <code>Policy</code> entity, use of the <a href="http:// dublincore.org/documents/ dcmi-terms/">Dublin Core Metadata Terms</a> would be recommended.
  </p>
  <h4><a name="section- 211"></a>2.1.1 Inheritance</h4>
  <p>The <code>inheritAllowed</code> attribute in the <code>Policy</code> entity is used to indicate if the <code>Policy</code> expression can be used in any inheritance relationship [ODRL-REQ-1.20]. If present, the value of the <code>inheritAllowed</code> attribute MUST take one of the following values:</p>
  <ul>
   <li><code>true</code>: the <code>Policy</code> expression can be used for inheritance</li>
   <li><code>false</code>: the <code>Policy</code> expression can not be used for inheritance</li>
  </ul>
  <p>If the <code>inheritAllowed</code> attribute is not explicitly set, its default value will be used instead. The default value of the <code>inherit</code> attribute is <code>true</code>.</p>
  <p>Only if the <code>inheritAllowed</code> attribute has the value <code>true</code> can the <code>inheritFrom</code> and <code>inheritRelation</code> attributes be specified.</p>
  <p> The <code>inheritFrom</code> attribute in the (child) <code>Policy</code> will uniquely identify (via a UID) the (parent) <code>Policy</code> from which the inheritance will be performed.</p>
  <p> The <code>inheritRelation</code> attribute in the (child) <code>Policy</code> will uniquely identify (via a UID) the type of inheritance from the (parent) <code>Policy</code>. For example, this may indicate the business scenario, such as <em>subscription</em>. Such terms MAY be defined in the Common Vocabulary or community Profiles.</p>
  <p>The following restrictions apply when using inheritance:</p>
  <ul>
   <li>Single inheritance is only supported. (One Parent <code>Policy</code> to one or more Child <code>Policy</code> entities. No Child <code>Policy</code> can inherit from two or more Parent <code>Policy</code> entities.)</li>
   <li>Inheritance can be to any depth. (Multiple levels of Children <code>Policy</code> entities.)</li>
   <li>Inheritance cannot be circular.</li>
   <li>The Child <code>Policy</code> MUST override the Parent <code>Policy</code>. i.e.: If the same <code>Action</code> appears in the Parent, then it is replaced by the Child version, otherwise the Parent <code>Action</code>s are added to the Child's <code>Action< /code>s.</li>
   <li>No state information is transferred from the policy in the Parent <code>Policy</code> to the Child <code>Policy</code></li>
  </ul>
  <h3><a name="section-22"></a>2.2 Asset</h3>
  <p>The <code>Asset</code> entity is aimed at identifying the content that is the subject of an ODRL policy, e.g. a media file or ebook. Furthermore, it can be used to represent other <code>Asset</code> entities that are needed to undertake the Policy expression, such as with the <code>Duty</code> entity. The <code>Asset</code> entity is referred to by the <code>Permission</code> and/or <code>Prohibition</code> entities, and also by the <code>Duty</code> entity.</p>
  <p>The <code>Asset</code> entity contains the following attribute:</p>
  <ul>
   <li><code>uid</code>: the unique identification of the <code>Asset</code> (REQUIRED)</li>
  </ul>
  <p>
  The identification of the <code>Asset</code> entity is a key foundation of the ODRL Policy language. However, there are some use cases where the ODRL Policy expression MAY be embedded inside the target <code>Asset</code>. In these cases, it MAY be more appropriate to provide, or infer, a link to the <code>Asset</code> entity (as the complete <code>Asset</code> <code>uid</code> may not be known at the time) through the local context. Use of such inference and context MUST be documented in the relevant ODRL community Profile.
  </p>
  <p>Since ODRL policies could deal with any kind of asset, the ODRL Core Model does not provide additional metadata to describe <code>Asset</code> entities of particular media types. It is recommended to use already existing metadata standards, such as <a href="http:// dublincore.org/documents/ dcmi-terms/">Dublin Core Metadata Terms</a> that are appropriate to the <code>Asset</code> type or purpose.</p>
  <p>
  The <code>Relation</code> entity is used to associate the <code>Asset</code> entity with the relevant <code>Permission</code>, <code>Prohibition</code>, and <code>Duty</code> entities
  </p>
  <h4><a name="section- 231"></a>2.2.1 Relation</h4>
  <p>The <code>Relation</code> entity is an association class and can be used to link to an <code>Asset</code> from either <code>Permission</code>, <code>Duty</code> or <code>Prohibition</code>, indicating how the <code>Asset</code> MAY be utilised in respect to the entity that links to it. </p>
  <p>The <code>Relation</code> entity contains the following attribute:</p>
  <ul>
   <li><code>relation</code>: indicates the relationship of the <code>Asset</code> to the linked entity (REQUIRED)</li>
  </ul>
  <p>The default value for the <code>relation</code> attribute is <code>target</code> which indicates that the <code>Asset</code> is the primary object to which the <code>Permission</code>, <code>Duty</code> or <code>Prohibition</code> actions apply.</p>
  <p>Other values for the <code>Relation</code> entity MAY be defined in the Common Vocabulary and community Profiles.</p>
  <h3><a name="section-23"></a>2.3 Party</h3>
  <p>The <code>Party</code> entity is aimed at identifying a person, group of people, or organisation. The <code>Party</code> MUST identify a (legal) entity that can participate in policy transactions [ODRL-REQ-1.5].</p>
  <p>The <code>Party</code> entity contains the following attribute:</p>
  <ul>
   <li><code>uid</code>: the unique identification of the party (REQUIRED)</li>
   <li><code>scope</code>: defines how the role shall be interpreted under different contexts. (OPTIONAL)</li>
  </ul>
  <p>The ODRL Core Model does not provide additional metadata for the <code>Party</code> element. It is recommended to use already existing metadata standards, such as <a href="http:// tools.ietf.org/html/draft- ietf-vcarddav- vcardrev">IETF vCard</a> that are appropriate to the <code>Party</code> type or purpose.</p>
  <p>The <code>Role</code> entity is used to associate the <code>Party</code> entity with the relevant <code>Permission</code>, <code>Prohibition</code>, and <code>Duty</code> entities.</p>
  <h4><a name="section- 231"></a>2.3.1 Role</h4>
  <p>The <code>Role</code> entity is an association class and can be used to link to a <code>Party</code> from either <code>Permission</code>, <code>Duty</code> or <code>Prohibition</code>, indicating which role the <code>Party</code> takes with respect to the entity that links to it.</p>
  <p>The <code>Role</code> entity contains the following attributes:</p>
  <ul>
   <li><code>function</code>: the functional role the <code>Party</code> takes (REQUIRED)</li>
  </ul>
  <p>The <code>function</code> attribute MUST take one of the following values:</p>
  <ul>
   <li><code>assigner</code>: indicates that the <code>Party</code> has assigned the associated <code>Permission</code>, <code>Duty</code>, or <code>Prohibition</code>. In other words, the <code>Party</code> grants a <code>Permission</code> or requires a <code>Duty</code> to be performed or states a <code>Prohibition< /code>.</li>
  
   <li><code>assignee</code>: indicates that the <code>Party</code> has been assigned the associated entity, i.e. they are granted a <code>Permission</code> or required to perform a <code>Duty</code> or have to adhere to a <code>Prohibition< /code>.</li>
  </ul>
  <p>Other values for the <code>function</code> attribute MAY be defined in the Common Vocabulary and community Profiles.</p>
  <p>The <code>scope</code> attribute MAY be used to indicate the context under which to interpret the <code>Party</code> entity. If present, the <code>scope</code> attribute MAY take one of the following values:</p>
  <ul>
   <li><code>individual</code>: indicates that the <code>Party</code> entity is a single individual. The linked <code>Permission</code>, <code>Duty</code> or <code>Prohibition</code> is applicable for that individual only.
   </li>
   <li><code>group</code>: indicates that the <code>Party</code> entity represents a group. The group consisting of many individual members. The linked <code>Permission</code>, <code>Duty</code> or <code>Prohibition</code> is applicable for each member of that group. For example, a (constrained) <code>Permission</code> to play a movie 5 times is valid for each <code>Party</code> member or the <code>Duty</code> to pay 3 EUR has to be fulfilled by each <code>Party</code> member.
   </li>
  </ul>
  <p>Other values for the <code>scope</code> attribute MAY be defined in the Common Vocabulary and community Profiles.</p>
  <h3><a name="section-24"></a>2.4 Permission</h3>
  <p>The <code>Permission</code> entity indicates the <code>Action</code>s that the <code>assignee</code> is permitted to perform on the associated <code>Asset</code>. In other words, what the <code>assigner</code> (supplier) has granted to the <code>assignee</code> (consumer). </p>
  <p>An ODRL policy expression MAY contain at least one <code>Permission</code>. It is important to verify the semantics of the <code>Policy</code> <code>type</code> attribute as this MAY indicate additional constraints on the Policy expression structure.
  If several <code>Permission</code> entities are referred to by a <code>Policy</code>, then <em>all of them</em> are valid.</p>
  <p>The <code>Permission</code> entity has the following relations:</p>
  <ul>
   <li><code>Asset</code>: the <code>Permission</code> entity MUST refer to an <code>Asset</code> (where at least one, and only one, <code>relation</code> value is <code>target</code>) on which the linked <code>Action</code> MAY be performed (REQUIRED)</li>
   <li><code>Action</code>: the <code>Permission</code> entity MUST refer to <em>exactly one</em> <code>Action</code> that indicates the granted operation on the target <code>Asset</code> (REQUIRED)</li>
  
   <li><code>Party</code>: the <code>Permission</code> MUST refer to one or more <code>Party</code> entities linked via the <code>Role</code> entity (see Section 2.3.1) (OPTIONAL) </li>
 
  
   <li><code>Constraint</code>: the <code>Permission</code> MAY refer to one or more <code>Constraint</code>s which affect the validity of the <code>Permission</code>, e.g. if the <code>Action</code> <code>play</code> is only permitted for a certain period of time (OPTIONAL)</li>
  
   <li><code>Duty</code>: the <code>Permission</code> MAY refer to one or more <code>Duty</code> entities that indicate a requirement that MAY be fulfilled in return for receiving the <code>Permission</code> (OPTIONAL)</li>
  </ul>
  <h3><a name="section-25"></a>2.5 Duty</h3>
  <p>The <code>Duty</code> entity indicates a requirement that MAY be fulfilled in return for being entitled to the referring <code>Permission</code> entity [ODRL-REQ-1.8]. While implying different semantics, the <code>Duty</code> entity is similar to <code>Permission</code> in that it is an Action that can be undertaken. If a <code>Permission</code> refers to several <code>Duty</code> entities, <em>all of them</em> have to be fulfilled for the <code>Permission</code> to become valid. If several <code>Permission</code> entities refer to one <code>Duty</code>, then the Duty only has to be fulfilled <em>once</em> for all the <code>Permission</code> entities to become valid.
  </p>
  <p>The <code>Duty</code> entity contains the following attributes:</p>
  <ul>
   <li><code>uid</code>: a unique identification for this <code>Duty</code>. Used to refer a single <code>Duty</code> to multiple <code>Permission</code> entities (OPTIONAL)</li>
  </ul>
  <p>The <code>Duty</code> entity has the following relations:</p>
  <ul>
   <li><code>Action</code>: indicates the operation (e.g. <code>pay</code>) that MAY be performed (REQUIRED). Note: It is assumed that the assigned Party has the appropriate permissions to perform this action.
   </li>
   <li><code>Party</code>: a <code>Duty</code> MAY refer to <code>Party</code> entities with different <code>Role</code>s (see Section 2.3.1). If no explicit <code>Party</code> is linked to as <code>assignee</code> or <code>assigner</code>, the <code>Parties</code> with the respective <code>Role</code>s are taken from the referring <code>Permission</code>. (OPTIONAL)</li>
   <li><code>Asset</code>: a <code>Duty</code> entity MAY refer to an <code>Asset</code> (where at least one, and only one, <code>relation</code> value is <code>target</code>) related to fulfilling the <code>Duty</code>. For example, a <code>pay</code> <code>Action</code> must be linked to a target <code>Asset</code> that indicates the amount to pay. The mechanisms to perform this linking/packaging are defined by community Profiles. (OPTIONAL)</li>
  
   <li><code>Constraint</code>: a <code>Duty</code> MAY link to one or more <code>Constraint</code>s [ODRL-REQ-1.10] (OPTIONAL)</li>
  </ul>
  <p>
  A <code>Duty</code> entity does not, by itself, specify any conditions on when the <code>Duty</code> <code>Action</code> MUST or MAY be performed, such as to <code>pay</code> before viewing the movie. Such conditions MAY be expressed through <code>Constraint</code> entities.
  </p>
  <p>
  To support cases where the <code>Duty</code> MAY be performed for each <code>Action</code> on an <code>Asset</code> (for example, pay-per-view) then the use of a <code>Constraint</code> (e.g. count=1) on the <code>Permission</code> (e.g. play) can express these semantics.
  </p>
  <h3><a name="section-26"></a>2.6 Prohibition</h3>
  <p>The <code>Prohibition</code> entity indicates the <code>Action</code>s that the <code>assignee</code> is prohibited to perform on the related <code>Asset</code> [ODRL-REQ-1.7]. <code>Prohibition</code>s are issued by the supplier of the <code>Asset</code> - the <code>Party</code> with the <code>Role</code> <code>assigner</code>. If several <code>Prohibition</code> entities are referred to by a <code>Policy</code>, <em>all of them</em> are valid.</p>
  <p>The <code>Prohibition</code> entity has the following relations:</p>
  <ul>
   <li><code>Asset</code>: the <code>Prohibition</code> entity MUST refer to an <code>Asset</code> (where at least one, and only one, <code>relation</code> value is <code>target</code>) on which the <code>Action</code> is prohibited (REQUIRED)</li>
   <li><code>Action</code>: the <code>Prohibition</code> entity MUST refer to <em>exactly one</em> <code>Action</code> that is prohibited (REQUIRED)</li>
   <li><code>Party</code>: the <code>Prohibition</code> MAY refer to one or more <code>Party</code> entities linked via the <code>Role</code> entity (see Section 2.3.1) (OPTIONAL) </li>
   <li><code>Constraint</code>: the <code>Prohibition</code> MAY refer to one or more <code>Constraint</code> entities (OPTIONAL)</li>
  </ul>
  <h3><a name="section-27"></a>2.7 Action</h3>
  <p>The <code>Action</code> entity (when related to a <code>Permission</code> entity) indicates the operations (e.g. <code>play</code>, <code>copy</code>, etc.) that the <code>assignee</code> (i.e. the consumer) is <em>permitted</em> to perform on the related <code>Asset</code> linked to by <code>Permission</code>. When related to a <code>Prohibition</code>, the <code>Action</code> entity indicates the operations that the <code>assignee</code> (again the consumer) is <em>prohibited</em> to perform on the <code>Asset</code> linked to by <code>Prohibition</code>. Analogously, when related to a <code>Duty</code>, it indicates the operation to be performed.</p>
  <p><code>Action</code> contains the following attribute:</p> <ul> <li><code>name</code>: indicates the <code>Action</code> entity term (REQUIRED)</li> </ul>
  <p>As its value, the <code>name</code> attribute MAY take one of a set of <code>Action</code> <em>names</em> which are formally defined in profiles. The ODRL Common Vocabulary defines a standard set of potential terms that MAY be used. Communities will develop new (or extend existing) profiles to capture additional and refined semantics. </p>
  <h3><a name="section-28"></a>2.8 Constraint</h3>
  <p>The <code>Constraint</code> entity indicates limits and restrictions to the <code>Permission</code>, the <code>Prohibition</code> and the <code>Duty</code> entity [ODRL-REQ-1.9]. <code>Constraint</code>s express mathematical terms with two operands and one operator. For example, the "number of usages" (<code>name</code>) must be "smaller than" (<code>operator</code>) the "number 10" (<code>rightOperand</code>).
  </p>
  <p> If multiple <code>Constraint</code> entities are linked to the same <code>Permission</code>, <code>Prohibition</code>, or <code>Duty</code> entity, then all of the <code>Constraint</code> entities MUST be satisfied. That is, all the <code>Constraint</code> entities are (boolean) <em>and</em>ed. In the case where the same <code>Constraint</code> is repeated, then these MUST be represented as a single <code>Constraint</code> entity using an appropriate <code>operator</code> value (for example, <code>isAnyOf</code>). </p>
  <p>The <code>Constraint</code> entity contains the following attributes:</p> <ul> <li><code>name</code>: a name that identifies the the left operand of the operation (REQUIRED)</li> <li><code>operator</code>: an operator function (REQUIRED)</li> <li><code>rightOperand</code>: the right operand of the operation (REQUIRED)</li> <li><code>status</code>: the current value of the left operand (OPTIONAL) </ul>
  <p>The <code>name</code> identifies the left operand of the mathematical operation for the <code>Constraint</code> such as "Number of Usages" and "Expiration Date" etc. The <code>operator</code> identifies the comparative operation such as "greater than" or "equal to". The <code>rightOperand</code> identifies the value that is being compared. When processing policy expressions, these <code>Constraint</code> names MAY be directly linked to a procedure that can determine the outcome of the operations, such as the number of already performed usages and the current date. The <code>name</code> and <code>operator</code> are defined in the ODRL Common Vocabulary or community profiles.</p>
  <p>The <code>status</code> provides the current value of the <code>Constraint</code> variable (i.e. current value of <code>name</code>) [ODRL-REQ-1.3]. This is useful in cases where the current status of <code>Constraint</code>s needs to be captured and expressed in the ODRL Core Model.</p>
  <h2><a name="section-3"></a>3. Scenarios (Informative)</h2>
  <p>This section shows a number of policy expression scenarios. In these examples, the different policy expression <code>type</code>s that are used are for illustrative purposes only and are not part of this normative specification. Also, the specific <code>Action</code> and <code>Constraint</code> names (etc.) used in these examples are for illustrative purposes only. Please note that formal policy expression <code>type</code>s and other entities are defined in the ODRL Common Vocabulary specification, or in community profiles.</p>
  <h3>3.1 Set</h3>
  <p>The following shows an instance of a <code>set</code> <code>Policy</code>. The <code>Set</code> shows a policy expression, stating that the <code>Asset</code> <code>http//example.com/ asset:9898</code> is the <code>target</code> of the <code>Permission</code> <code>reproduce</code> and the <code>Prohibition</code> to <code>modify</code>. No parties or other elements are involved. This <code>set</code> could be used, for example, as a template or an <em>instant license</em>.</p>
  <table align="center"> <tbody> <tr align="center">
  <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-set.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-set.png" alt="Set Instance" width="640" class="aligncenter size-full wp-image-255" /></a></p> </td>
   </tr>
  <tr align="center">
   <td> <p><b>Figure 3.1 - An instance of a Set Policy</b></p> </td> </tr> </tbody> </table>
  <h3>3.2 Offer</h3>
  <p>The following shows the instance of an <code>offer</code> <code>Policy</code>. The <code>offer</code> contains the music file <code>http//example.com/ music:4545</code> that is offered by the <code>Party</code> <code>http//example.com/ sony:10</code> with the <code>Permission</code>s to <code>play</code> and <code>copy</code> the file. The <code>Permission</code> <code>copy</code> is only granted once. The two <code>Permission</code>s are offered for a payment of AUD$0.50.</p>
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-offer.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-offer.png" alt="Offer Instance" width="640" class="aligncenter size-full wp-image-250" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.2 - An instance of an Offer Policy</b></p> </td> </tr> </tbody> </table>
  <h3>3.3 Agreement</h3>
  <p>The following shows the instance of an <code>agreement</code> <code>Policy</code>. The <code>agreement</code> contains all entities shown in the <code>offer</code> scenario above. A new <code>Party</code> element <code>http//example.com/ billie:888</code> has been added. This <code>Party</code> accepted the previous <code>offer</code> and thus is now the buyer of the <code>Permission</code> <code>play</code> and <code>copy</code>, i.e. is now linked as <code>assignee</code> of the <code>Permission</code>s and <code>Duty</code> entities.</p>
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-agreement.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-agreement- 1024x824.png" alt="Agreement Instance" width="640" height="515" class="aligncenter size-large wp-image-247" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.3 - An instance of an Agreement Policy</b></p> </td> </tr> </tbody> </table>
  <h3>3.4 Request</h3>
  <p>The following shows the instance of a <code>request</code> <code>Policy</code>. The <code>Party</code> <code>http//example.com/ guest:0589</code> has requested the <code>Permission</code> to <code>display </code> the <code>target</code> <code>Asset</code> <code>http//example.com/ news:0099</code>.</p>
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-request.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-request.png" alt="Request Instance" width="640" class="aligncenter size-full wp-image-254" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.4 - An instance of a Request Policy</b></p> </td> </tr> </tbody> </table>
  <h3>3.5 Ticket</h3>
  <p>The following shows the instance of a <code>ticket</code> <code>Policy</code>. The <code>ticket</code> expresses the <code>play</code> <code>Permission</code> for the <code>target</code> <code>Asset</code> <code>http//example.com/ game:4589</code>. The <code>Ticket</code> is valid until the end of the year 2010. Any valid holder of this ticket may exercise this <code>Permission</code>.</p>
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-ticket.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-ticket.png" alt="Ticket Instance" width="640" class="aligncenter size-full wp-image-257" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.5 - An instance of a Ticket Policy</b></p> </td> </tr> </tbody> </table>
  <h3>3.6 Offer and Next Policy</h3>
  <p>The following shows the instance of an <code>offer</code> <code>Policy</code> showing the <code>nextPolicy</code> structure. The party <code>http//example.com/ sony:99</code> assigns the <code>Permission</code> <code>distribute</code> directly to the potential buyer of the permission who will pay $EU1,000. The <code>distribute</code> <code>Permission</code> is also constrained to the country Italy. The potential <code>assignee</code> may then <code>distribute</code> the <code>target</code> <code>Asset</code> according to the <code>nextPolicy</code> <code>target</code> <code>Asset</code> linked directly from this <code>Duty</code>. In this case, the next Policy <code>Asset</code> stipulates that the potential <code>assignee</code> may only offer the <code>display</code> <code>Permission</code> to downstream consumers.</p>
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-offernextpolicy.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-offernextpolicy- 1024x586.png" alt="Offer Next Policy Instance" width="640" class="aligncenter size-large wp-image-251" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.6 - An instance of an Offer and Next Policy Policy</b></p> </td> </tr> </tbody> </table>
  <h3>3.7 Privacy</h3>
  <p>The following shows the instance of an <code>privacy</code> <code>Policy</code>.
  The <code>target</code> <code>Asset</code> is Personal Data and the <code>assignee</code> is allowed to <code>distribute</code> the <code>Asset</code> only for the <code>purpose</code> of contacting the subject of the Personal Data. The purpose value is taken from the <a href="http:// www.w3.org/TR/ P3P11/#PURPOSE">P3P privacy purpose vocabulary</a>.
  Additionally, the <code>assigner</code> (the <code>Party</code> who the personal data is about) has stipulated that the <code>assignee</code> must <code>delete</code> the <code>Asset</code> after a 30 day period (retention policy).
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-privacy.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-privacy- 1024x607.png" alt="Privacy Instance" width="640" class="aligncenter size-large wp-image-253" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.7 - An instance of an Privacy Policy</b></p> </td> </tr> </tbody> </table>
  <h3>3.8 Permission and Prohibition</h3>
  <p>The following shows the instance of an <code>agreement</code> <code>Policy</code> with both a <code>Permission</code> and a <code>Prohibition</code>. The party <code>http//example.com/ sony:10</code> assigns the <code>Permission</code> <code>play</code> to the <code>Party</code> <code>http//example.com/ billie:888</code> at the same time they are <em>prohibited</em> from utilising the <code>target</code> <code>Asset</code> as a <code>mobile: ringtone</code>. Additionally, in case of any conflict, the <code>conflict</code> attribute is set to <code>perm</code> indicating that the <code>Permission</code> entity will take precedence.</p>
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-permprohibit.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-permprohibit.png" alt="Permission Prohibition Instance" width="640" class="aligncenter size-full wp-image-252" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.8 - An instance of an Permission and Prohibition Policy</b></p> </td> </tr> </tbody> </table>
  <h3>3.9 Inheritance</h3>
  <p>The following shows the instance of a (child) <code>Policy</code> <code>http//example.com/ policy:9999</code> inheriting from another (parent) <code>Policy</code> <code>http//example.com/ policy:5531</code>. The <code>inheritFrom</code> attribute of the (child) <code>Policy</code> has the same identifier as the (parent) <code>Policy</code>. In this inheritance example, the (parent) <code>Policy</code> allows the <code>Party</code> <code>http//example.com/ billie:888</code> to <code>print</code> the (parent's) <code>target</code> <code>Asset</code>. The (child) <code>Policy</code> allows the <code>Party</code> <code>http//example.com/ class:IT01</code> (a group of people) to <code>display</code> the (child's) <code>target</code> <code>Asset</code>. Since the (child) <code>Policy</code> also inherits from the (parent) <code>Policy</code>, then the <code>Party</code> <code>http//example.com/ class:IT01</code> can also <code>print</code> the (parent's) <code>target</code> <code>Asset</code>.
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-inherit.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-inherit- 1024x513.png" alt="Inheritance Instance" width="640" class="aligncenter size-large wp-image-248" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.9 - An instance of an Inheritance Policy</b></p> </td> </tr> </tbody> </table>
  <h3>3.10 Social Network</h3>
  <p>The following shows the instance of an <code>agreement</code> <code>Policy</code> for a Social Network scenario.
  The <code>target</code> <code>Asset</code> are photos posted to a Social Network site and the <code>assigner</code> is the owner of the photos. The <code>assignee</code> is a <code>Party</code> <code>group</code> and represents the <em>football network members</em> on the social network, who are each allowed to <code>display</code> the photos.
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-socialnetwork.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-socialnetwork.png" alt="Social Networks Instance" width="640" class="aligncenter size-full wp-image-256" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.10 - An instance of an Social Network Policy</b></p> </td> </tr> </tbody> </table>
  <h3>3.11 Multiple Assets</h3>
  <p>The following shows an instance of a <code>set</code> <code>Policy</code> utilising multiple <code>Asset</code> entities.
  The <code>index</code> <code>Permission</code> is granted to the <code>target</code> <code>Asset</code>. As well, the <code>x:collection</code> <code>Asset</code> specifies which database the <code>index</code> outcome should be stored in.</p>
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-multipleassets.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-multipleassets.png" alt="Multiple Assets Instance" width="640" class="aligncenter size-full wp-image-249" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.11 - An instance of an Multiple Assets Policy</b></p> </td> </tr> </tbody> </table>
  <h2><a name="section-4"></a>4. Profiles (Informative)</h2>
  <p>The ODRL Core Model represents a broad need for policy expressibility. As a result, different communities will require less or more elements from the Core Model. Community profiles of the ODRL model are expected to be developed that adequately document these changes in respect to the Core Model. Some requirements of this process include:</p>
   <ul>
   <li>Document any additions to the Core Model</li>
   <li>Document any aspects of the Core Model that will have different default values</li> <li>Document which aspects of the Core Model are not being used (deprecated)</li>
  <li>Document Vocabulary terms</li>
   <li>Declare your communities namespace (see Encoding specifications)</li>
   <li>Share the Community profile with the ODRL community for feedback and comments</li> </ul>
  <h2><a name="section-5"></a>5. Experimental Features (Informative)</h2> <p>This section contains advanced ODRL features. Although not part of the normative specification, they provide an opportunity for communities to experiment with and provide feedback on experiences that may be included in future ODRL versions.</p>
  <h3><a name="section-51"></a>5.1 Extended Relations</h3>
  <p><code>Extended Relations</code> may tie <code>Permission</code>, <code>Prohibition</code>, <code>Duty</code>, and <code>Constraint</code> entities together with an <code>AND</code>, <code>OR</code> or <code>XOR</code> relationship. Only entities of the same type can be linked with this model. For example, a <code>Permission</code> and <code>Prohibition</code> cannot be linked together within this model. The Extended Relations model supports the following attribute:</p>
  <ul> <li><code>operation</code>: may be set with <em>one</em> of the mathematical values <code>AND</code>, <code>OR</code> and <code>XOR</code>. (<code>OR</code> is the default if not specified.)</li> </ul>
  <p>The following table outlines the semantics of Extended Relations with respect to each of the main entity types.</p>
  <table border="1" cellspacing="2" cellpadding="5" width="100%"> <tr> <td>&nbsp;</td> <td><code>Permission</code></td> <td><code>Prohibition</code></td> <td><code>Duty</code></td> <td><code>Constraint</code></td> </tr> <tr> <td><code>OR</code></td> <td>The related party may perform <em>any</em> (<em>at least</em>) one of the <code>Action< /code>s</td> <td>The related party MAY NOT perform <em>at least</em> one of the <code>Action< /code>s</td> <td>The related party MUST perform <em>at least</em> one of the <code>Action< /code>s</td> <td>The related <code>Permission< /code>/<code> Prohibition< /code>/<code>Duty</code> is restricted by <em>at least</em> one of the <code>Constraint< /code>s</td> </tr> <tr> <td><code>AND</code></td> <td>The related party MUST perform <em>all</em> of the <code>Action< /code>s</td> <td>The related party MAY NOT perform <em>all</em> of the <code>Action< /code>s</td> <td>The related party MUST perform <em>all</em> of the <code>Action< /code>s</td> <td>The related <code>Permission< /code>/<code> Prohibition< /code>/<code>Duty</code> is restricted by <em>all</em> of the <code>Constraint< /code>s</td> </tr> <tr> <td><code>XOR</code></td> <td>The related party MAY perform only <em>one</em> of the <code>Action< /code>s</td> <td>The related party MAY NOT perform only <em>one</em> of the <code>Action< /code>s</td> <td>The related party MUST perform only <em>one</em> of the <code>Action< /code>s</td> <td>The related <code>Permission< /code>/<code> Prohibition< /code>/<code>Duty</code> is restricted by&nbsp;only <em>one</em> of the <code>Constraint< /code>s.</td> </tr> </table>
  <p>Note that Extended Relations are not needed to assign two or more <code>Permission</code>s to a <code>Party</code> entity. In this case simply use as many <code>Assignee</code> relations between <code>Party</code> and <code>Permission</code> as needed.</p>
  <h3><a name="section-52"></a>5.2 Abstract Policy Expression</h3>
  <p> As the Core Model diagram shows (see Figure 5.1), the key <code>Permission</code>, <code>Prohibition</code> and <code>Duty</code> entities are very similar since they have (more or less) the same relationships to the other entities. They core difference is in their semantics:</p> <ul> <li><code>Permission</code> says that the <code>assignee </code> <em>may</em> do something, </li> <li><code>Duty</code> says that the <code>assignee</code> <em>should</em> do something, and </li> <li> <code>Prohibition</code> says that they <em>should not</em> do it. </li> </ul> <p>In an implementation that interprets ODRL, it may make sense to introduce a common superclass <code><i>Rule</i></code>, as shown in the (abbreviated) Model in Figure 5.1. </p>
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ exp-abstractmodel.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ exp-abstractmodel.png" alt="Abstract Policy Expression" width="640" class="aligncenter size-full wp-image-245" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 5.1 - ODRL Abstract Policy Model</b></p> </td> </tr> </tbody> </table>
   <p> By implementing <code>Permission</code>, <code>Prohibition</code> and <code>Duty</code> as subclasses of <code><i>Rule</i></code>, the redundancy of having very similar, but separately developed classes in an application's source code can be avoided. Furthermore, <code><i>Rule</i></code> makes it possible to easily extend the Core Model in Profiles by adding policy expressions (as subclasses of <code><i>Rule</i></code>) that are not possible by default. </p>
  <h3><a name="section-53"></a>5.3 Remedies</h3>
  <p> In the ODRL Core Model, <code>Duties</code> are only directly related to <code>Permission</code>s, meaning that for a <code>Permission</code> to become effective, the related <code>Duty</code> should be performed. For some use cases though, it might be useful to attach a <code>Duty</code> to a <code>Prohibition</code>, meaning that if a <code>Prohibition</code> is violated, the <code>Duty</code> has to be performed as a kind of remedy or consequence for the violation. </p>
  <p> Not only can a <code>Prohibition</code> have a <code>Duty</code> attached to it as a remedy, even <code>Duties</code> themselves may have remedies, e.g. "For the <code>Permission</code> to play audio file xyz to become effective, you have to perform the <code>Duty</code> 'pay 2&euro;'. If you don't perform this <code>Duty</code> (even though you've played yxz), you have to remedy this by performing the <code>Duty</code> 'pay 5&euro;'". </p>
  <p> In order to distinguish between a <code>Duty</code> that has to be fulfilled as a requirement and one that has to be fulfilled as a remedy, different relation names are introduced as shown in the Figure 5.2. </p>
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ exp-remedy.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ exp-remedy.png" alt="Remedy" width="640" class="aligncenter size-full wp-image-246" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 5.2 - Remedy Model</p> </td> </tr> </tbody> </table>
   <p> The relation between <code>Permission</code> and <code>Duty</code>, which was unnamed before, is now named <code>hasRequirement</code>. This is needed not only to make the different semantics clearer, but also because a <code>Duty</code> can refer to yet another <code>Duty</code> as a requirement, e.g. "If you want to print this written article, you have the <code>Duty</code> to attach a particular image of the author, and if you do that, you have the <code>Duty</code> to attribute the image to the photographer". </p>
  <h2><a name="section- Acknowledgements" ></a>Acknowledgements</h2>
  <p>The editors gratefully acknowledge feedback and contributions to this document from:</p> <ul> <li>Vicky Weissman, Mark Strembeck, Alapan Arnab, Steven Rowat, Eetu Luoma, Jaime Delgado, Ruediger Grimm, Helge Hundacker, Stuart Myles, Francis Cave, Rigo Wenning, Hassan Abdel-Rahman, Jonas Zitz</li> <li>Members of the W3C ODRL Community Group</li> </ul>
  <h2><a name="section- References">< /a>References</h2>
  <table border="0" cellspacing="0" cellpadding="5" width="100%"> <tbody>
  <TR class="r0"> <TD vAlign="top" align="right" ><B>[ODRL-11]</B></TD> <TD>R. Iannella (ed). Open Digital Rights Language (ODRL) Version 1.1. W3C Note, 19 Sept 2002. <A href="http:// www.w3.org/TR/odrl/"> http://www.w3.org/ TR/odrl/</A></TD></TR>
  <tr class="r0">
  <td colspan="1" valign="top" align="right" ><b>[ODRL-REQ]</b></td>
   <td colspan="1">S. Guth &amp; R. Iannella (eds). Open Digital Rights Language (ODRL) Version 2.0 Requirements (Working Draft), ODRL Initiative, <a href="http:// odrl.net/2.0/ v2req.html"> http://odrl.net/ 2.0/v2req.html</a>, 24 November 2004. <br> </td> </tr>
   <tr>
   <TD vAlign="top" align="right" ><B>[ODRL-VOCAB]</B></TD>
   <TD>S. Guth &amp; R. Iannella (eds). Open Digital Rights Language (ODRL) Version 2.0 - Common Vocabulary. Final Specification, W3C ODRL Community Group, 19 April 2012.<BR><A href="http:// www.w3.org/community/odrl/ two/vocab/">http: //www.w3.org/ community/odrl/ two/vocab/</A></TD>
   </TR>
   <tr>
   <tr>
   <TD vAlign="top" align="right" ><B>[ODRL-XML]</B></TD>
   <TD>R. Iannella (ed). Open Digital Rights Language (ODRL) Version 2.0 - XML Encoding. Final Specification, W3C ODRL Community Group, 19 April 2012.<BR><A href="http:// www.w3.org/community/odrl/ two/xml/">http: //www.w3.org/ community/odrl/ two/xml/</A></TD>
   </TR>
   <tr>
  <tr class="r0"> <td colspan="1" valign="top" align="right" ><b>[RFC2119]</b></td> <td colspan="1">Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. The Internet Society, March 1997. <a href="http:// tools.ietf.org/ html/rfc2119" >http://tools.ietf.org/ html/rfc2119</a> <br> </td> </tr>
  <tr class="r0"> <td colspan="1" valign="top" align="right" ><b>[UML]</b></td> <td colspan="1">Unified Modeling Language (UML), Object Management Group, 2003. <a href="http:// www.omg.org/technology/documents/ formal/uml.htm" >http://www.omg.org/ technology/documents/ formal/uml.htm</a> <br> </td> </tr> </tbody> </table>

Note: Spaces may be added to comparison text to allow better line wrapping.