odrl.netnicta.com.au odrl.netnicta.com.au Copyright ODRL Initiative 2005-2008. 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 fouth public Working Draft of the ODRL V2.0 Core Model Specification document produced by the ODRL Version 2.0 Working Group.
NOTE: This version is a major change from the previous version. The Core Model has been significantly simpified to address the need for a more basic model that can be further extended to address specific business and communities needs in seperate profile specifications in the future. This decision was ratified by the Version 2.0 Working at their Koblenz meeting on 10 Oct 2007.
This is a Working Draft for review by working group members and other interested parties. 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@lists.odrl.net archived at http://lists.odrl.net/pipermail/odrl-version2/.
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 Working Draft does not imply endorsement by the ODRL Initiative.
1. Overview
2. ODRL Core Model
3. Expression Semantics
4. Scenarios (Informative)
Acknowledgements
Change History
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 must follow the URI specifications and be globally unique.
The range of values for the rights expression type 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 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 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 caputred 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 fulfiled before the rights can be exercised. If the value is false then the Duty can be fulfilled at anytime, but still must be fulfiled.
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 Transfer Rights entity allows for the specification of downstream (or next) rights to subsequent assignee/s. The Transfer Rights is expressed as a Permission with a unique identifier for the Action (see the ODRL Core Profile for details). The assignee/s must only use these rights for downsream assignment. The Transfer Rights permissions and prohibitions must not contain any Party entities or any Asset entities as these are assumed to be the same as in the current rights expression.
The Rights Exclusivity entity indicates that the Permission is being made exclusively to the Assignee/s. The Rights Exclusivity is expressed as a Duty with a unique identifier for the Action (see the ODRL Core Profile for details). The Object of the Duty will identify the Permissions that are exclusive rights.
The Container entity may tie Permission, Prohibition, Duty, and Constraint entities together with an AND, OR or XOR relationship. Only enities of the same type can be linked with the containers. For example, a Permission and Prohibition cannot be linked togeher within this model. The Container Model supports the following attribute:
Figure 3.1 shows a possible use of the Container entity. In this case, two Actions are inside an XOR (exclusive or) Container linked to a Permission. 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 Assingee relations between Party and Permission as needed. For a container example please refer to Section 4 Scenarios.
Unlike ODRL Version 1.1, the Version 2.0 Model make no assumptions about which rights have been assigned or not assigned to parties. The Permission model states which actions the assignee is allowed to perform. The Prohibition model states which actions the assignees is not allowed to perform. In either case, there are no assumptions outside of these. For example, if the "print" Permission was assigned, then the assigner may "print" the asset. Conversely, if the "print" Prohibition was assigned, then the assigner may not "print" the asset. No other assumptions are implictly or explcitly made for any other actions.
A conflict should be raised in the case of the same Permission actions and Prohibition actions appearing in the same expression.
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 Set
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 Offer
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 Permisson 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 Agreement
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 Request
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 Ticket
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 Offer and Transfer Rights
The following shows the instance of an Offer with Next Rights. The party urn:sony:99 assigns the two Permissions distribute and transferRights directly to the potential buyer of the permissions 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 Permissions linked from the transferRights. 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 Container
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 editors gratefully acknowledge feedback and contributions to this document from:
Changes since the last public release:
| Section | Issue | Changes | Comment | |||
| All | Towards Simplier Model | Remove the following classes and attributes:
- Legal
- Communication
- Signature
- Encryption
- Tradeable
- WEMI, Metadata, Parts (from Asset)
- Non Performed (from Duty)
Reviewed how these can be best represented in the model: - Transfer Rights - Exclusive - Inherit - Container Updated all the Scenarios. |
Decided at Koblenz Meeting (11 Oct 2007) | |||
| [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
|
