vodafone.comnicta.com.au vodafone.comnicta.com.au Copyright ODRL Initiative 2005-2009. All Rights Reserved.
This document describes the ODRL Version 2.0 Core Model Specification. The model incorporates new features and requirements for the ODRL rights expression language.
This is the first public Draft Specification of the ODRL V2.0 Core Model Specification document produced by the ODRL Version 2.0 Working Group.
The ODRL Initiative publishes a Draft Specification to indicate that the document is believed to be stable and to encourage implementation by the wider community. The ODRL Version 2.0 Working Group expects to advance this document to Specification once the Working Group has developed Working Drafts for the ODRL Version 2.0 Core Profile and at least one Encoding and demonstrated at least two interoperable implementations.
Comments on this document should be sent to editors and discussion of this document takes place on the public working group mailing list odrl-version2@odrl.net archived at http://odrl.net/pipermail/odrl-version2_odrl.net/.
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than "work in progress". Publication as a Draft Specification does not imply endorsement by the ODRL Initiative.
This document uses the following visual indicators for substantial differences from the previous version:
1. Overview
2. ODRL Core Model
3. Expression Semantics
4. Scenarios (Informative)
5. Profiles (Informative)
Acknowledgements
References
The ODRL rights expression language (REL) 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.[ODRL11]
The ODRL Core Model is designed to be independent from implementation mechanisms and is focussed on the optimal model and semantics to represent rights-based information.
The following documents are planned for ODRL Version 2.0:
The new 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 [ODRL-REQ] and will be directly referenced in this document to ensure that they have been adequately addressed (where applicable).
The model shall be formally specified using UML notation [UML] [ODRL-REQ#6] and shall utilise the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in accordance to [RFC2119].
Figure 2.1 below shows the complete version 2.0 ODRL Core Model. The subsequent sections describes each entity of the Core Model in greater detail.
|
Figure 2.1 - ODRL Core Model Version 2.0 |
The Rights entity is the top-level entity and must contain the following attributes:
The uid attribute must follow the URI specifications and be globally unique.
The range of values for the rights expression type attribute will be described in the Core Profile document or other community profiles. This value may also impose further constraints on the expression language constructs, such as offer, agreement and inherit.
The conflict attribute is used to resolve conflicts arising from the merging of licenses, specifically when there are conflicting actions in the Permissions and Prohibitions. The range of values are:
The default value for the conflict attribute is invalid.
The undefined attribute is used to indicate how to support actions that are not part of any known Profile to the rights expression system. The range of values are:
In the support case, even though the action is unknown, the license still is valid and the consuming parties or system of the license must be made aware of the unknown action. This maybe via a user interface that displays the unknown action for human readability.
In the ignore case, even though the action is unknown, the license still is valid and the consuming parties or system of the license may be made aware of the unknown action
In the invalid case with the unknown action, the license is invalid and the consuming parties or system of the license must be made aware of this.
The default value for the undefined attribute is invalid.
The Asset entity is aimed at identifying the content that is the subject of the rights expression. The Asset entity is the Target of the Permission and/or Prohibition entities, and possibly, indirectly of the Duty entity (via Object).
The Asset entity may contain the following information:
The ODRL Core Model does not provide additional descriptive metadata for the Asset element. It is recommended to use already existing metadata standards, such as Dublin Core, LOM, or MPEG 7 that are appropriate to the content type or purpose.
The inherit attribute in the Asset entity indicates an inheritance of rights information between rights expressions [ODRL-REQ#1.20]. The inherit item in the asset (Child Asset) will uniquely identify another asset (Parent Asset) which has an associated rights expression instance.
The following restrictions apply when using inheritance:
The inherit attribute in the Rights entity is used to indicate if the Rights expression can be used in any inheritance relationship. The range of values are:
The default value for the inherit attribute is true.
The Party entity is aimed at identifying a person, group of people, or organisation. The Party must identify a (legal) entity that can participate in rights transactions [ODRL-REQ#1.5].
The Party entity must contain the following information:
The ODRL Core Model does not provide additional metadata for the party element. It is recommended to use already existing metadata standards, such as vCard or CIQ.
The Party entity undertakes the same three roles with both the Permission and Prohibition entities:
The Party entity undertakes three roles with the Duty entity:
Finally the Party entity undertakes an additional role with the Asset entity:
The Permission entity indicates the actions that the Assignee/s is permitted to perform on the Target asset. In other words, what the Assigner (supplier) has granted to the Assignee (consumer).
The Permission entity may contain the following:
The Action entity (when related to a Permission entity) indicates the operations (e.g. play, copy, etc.) that the Assignee/s (i.e. the consumer) is permitted to perform on the Target asset. The Action entity (when related to a Prohibition entity) indicates the operations that the Assignee/s (again the consumer) is prohibited to perform on the Target asset.
The Action entity contains a set of Action Names which are formally defined in Profiles. The ODRL Core Profile defines a standard set of potential terms that may be used. Communities will develop new or extension Profiles to capture additional/refined semantics.
The Constraint entity indicates limits and restriction to the Permission, the Prohibition and the Duty entity [ODRL-REQ#1.9]. Constraints express mathematical terms with two operands and one operator. For example, the "number of usages" (name) must be "smaller than" (operator) the "number 10" (right operand).
The Constraint entity may contain the following attributes:
Note: Each Constraint entity must contain only one Constraint Name.
The name identifies the left operand of the mathematical operation for the constraint such as "Number of Usages" and "Expiration Date" etc. The operator identifies the comparative operation such as "greater than" or "equal to". The right operand identifies the value that is being compared. When processing rights expressions, these constraint names shall 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 name and operator would be defined in the Core Profile or community Profiles.
The status provides the current value of the constraint variable (i.e. current value of name) [ODRL-REQ#1.3]. This is useful in cases where the current status of constraints needs to be captured an expressed in the ODRL Core Model.
The Duty entity indicates a requirement that must be fulfilled in return for being entitled to the containing Permission entity [ODRL-REQ#1.8]. The Duty entity is related to a Party entity via the role Assignee who is responsible for fulfilling the Duty, and to an optional Assigner entity who is entitled to receive the outcomes of the Duty. If there is no direct Assignee, then the Assignee of the linked Permission is responsible for fulfilling the Duty (and may be the same Party). The Assigner can be indicated directly between Party and Duty, if not, then the Assigner will be assumed as the same as the Permission Assigner.
The Duty entity contains the following:
The Object entity MUST contain the following:
The Object of a Duty may also be an Asset entity.
The Duty entity contains a set of Action Names which are formally defined in Profiles. The ODRL Core Profile defines a standard set of potential terms that may be used. Communities will develop extension Profiles to capture additional/refined semantics.
The Duty entity may contain the relax boolean that indicates if the duty may be fulfilled at anytime, including after the containing Permission has been utilised by the Assignee/s. The default Relax boolean setting for all Duty entities is false meaning that the Duties must be fulfilled before the rights can be exercised. If the value is false then the Duty can be fulfilled at anytime, but still must be fulfilled.
The Prohibition entity indicates the actions that the Assignee/s (or consumer/s) is/are prohibited to perform on the Target asset [ODRL-REQ#1.7]. Prohibitions are issued by the supplier of the asset - the Assigner.
The Prohibition entity contains the following:
A number of normative rights expressions features supported by the ODRL Core Model are discussed in this section.
The NextRights association allows for the specification of downstream (or transfer) rights to subsequent assignee/s. The NextRights is expressed as a direct relationship between the pertinent Action and a rights expression (that is the set of rights that the assignee/s must only use for downstream assignment).
The Container entity may tie Permission, Prohibition, Duty, and Constraint entities together with an AND, OR or XOR relationship. Only entities of the same type can be linked with the containers. For example, a Permission and Prohibition cannot be linked together within this model. The Container Model supports the following attribute:
The values AND, OR and XOR take the strict mathematical definitions:
The following table outlines the semantics of the Container Operation with respect to each of the main entity types.
| Permission | Prohibition | Duty | Constraint | |
| OR | The related party MAY perform ANY (AT LEAST) one of the actions | The related party MAY NOT perform AT LEAST one of the actions | The related party MUST perform AT LEAST one of the actions | The related permission/prohibition/duty is restricted by AT LEAST one of the constraints | AND | The related party MUST perform All of the actions | The related party MAY NOT perform ALL of the actions | The related party MUST perform ALL of the actions | The related permission/prohibition/duty is restricted by ALL of the constraints | XOR | The related party MAY perform only ONE of the actions | The related party MAY NOT perform only ONE of the actions | The related party MUST perform only ONE of the actions | The related permission/prohibition/duty is restricted by only ONE of the constraints. |
Figure 3.1 shows a possible use of the Container entity. In this case, two Permission Actions are linked via an XOR (exclusive or) Container (related to a common Asset. This indicates that one of the Actions, and only one, can be used for the Permission.
|
Figure 3.1 - Container Model Example |
Note that containers are not needed to assign two or more permissions to a Party entity. In this case simply use as many Assignee relations between Party and Permission as needed. For a container example please refer to Section 4 Scenarios.
This section shows a number of rights expression scenarios. In these examples, the different rights expression types that are used are for illustrative purposes only and are not part of this normative specification. Also, the specific Action and Constraint names (etc) used in these examples are for illustrative purposes only. Please note that formal rights expression types and other entities will be defined in the ODRL Core Profile specification, or other community Profiles.
The following shows an instance of a Set. The Set shows a rights expression, stating that the Asset urn:asset:9898 is target of the Permissions publish and the Prohibition to modify. No parties or other elements are involved. This Set could be used, for example, as a rights template or an instant license.
|
Figure 4.1 - An instance of a Set |
The following shows the instance of an Offer. The Offer contains the music file urn:music:4545 that is offered by the Party urn:sony:10 with the Permissions to play and copy the file. The Permission copy is only granted once. The two permissions are Offered for a payment of AUD$0.50
|
Figure 4.2 - An instance of an Offer |
The following shows the instance of an Agreement. The Agreement contains all entities shown in the Offer scenario above. A new Party element urn:billie:888 has been added. This Party accepted the previous Offer and thus is now the buyer of the Permissions play and copy, i.e. is related as assignee of the Permissions and Duty elements.
|
Figure 4.3 - An instance of an Agreement |
The following shows the instance of a Request. The Party urn:guest:0589 Requests the Permission to display the Asset urn:news:0099.
|
Figure 4.4 - An instance of a Request |
The following shows the instance of a Ticket. The Ticket expresses the Permission for the party urn:player:9876 to play the game urn:game:4589. The Ticket is valid until the end of the year 2010.
|
Figure 4.5 - An instance of a Ticket |
The following shows the instance of an Offer with NextRights. The party urn:sony:99 assigns the Permission distribute directly to the potential buyer of the permission who will pay $EU1,000. The distribute permission is also constrained to the country Italy. The potential assignee may then distribute the asset according to the NextRights linked directly from this action. In this case, the linked asset may only be displayed to downstream consumers.
|
Figure 4.6 - An instance of an Offer and Transfer Rights |
The following shows the instance of an Offer with a Permission Container. The Offer includes two Permissions copy and print that are tied together by a logical XOR operator, i.e. either the permission print or the permission copy may be performed but not both. The print permission may only performed 5 times. Note that each of the permissions may have their individual constraints, target, etc.
|
Figure 4.7 - An instance of a Container |
The following shows the instance of an Agreement with both a Permission and a Prohibition. The party urn:sony:10 assigns the Permission play to the Party billie:888 at the same time they are Prohibited from utilising the Asset as a ringtone. Additionally, in case of any conflict, the conflict attribute is set to perm indicating that the Permissions will take precedence.
|
Figure 4.8 - An instance of an Permission and Prohibition Right |
The following shows the instance of an Child Agreement urn:exp:9999 inheriting from a Parent Agreement urn:exp:5531. The inherit attribute of the Asset of the Child Agreement has the same identifier as the Asset in the Parent Agreement (linked via the dashed line). In this inheritance example, the Parent Agreement allows the Billie Party to print the parent Asset and the Child Agreement allows the Class:IT01 Party (a group of people) to print the child Asset and for the Billie Party to print the parent Asset. That is, the Child Agreement includes all the entities of the Parent Agreement.
|
Figure 4.9 - An instance of an Inheritance Rights |
The ODRL Core Model represents a broad need for rights 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:
The editors gratefully acknowledge feedback and contributions to this document from:
| [ODRL11] | R. Iannella (ed). Open Digital Rights Language (ODRL),
Version 1.1. Technical Specification, ODRL Initiative, 8 August
2002. http://odrl.net/1.1/ODRL-11.pdf |
| [ODRL-REQ] | S. Guth & R. Iannella (eds). Open Digital Rights
Language (ODRL) Version 2.0 Requirements (Working Draft), ODRL
Initiative, http://odrl.net/2.0/v2req.html,
24 November 2004. |
| [RFC2119] | Key words for use in RFCs to Indicate Requirement
Levels, S. Bradner. The Internet Society, March 1997. ftp://ftp.rfc-editor.org/in-notes/rfc2119.txt
|
| [UML] | Unified Modeling Language (UML), Management Group,
2003. http://www.omg.org/technology/documents/formal/uml.htm
|
