ODRL V2.0 - Model Semantics

Working Draft: 4th May 2006

This version:

http://odrl.net/2.0/WD-ODRL-Model-20060504.html

Latest version:

http://odrl.net/2.0/WD-ODRL-Model.html

Previous version:

http://odrl.net/2.0/WD-ODRL-Model-20050516.html

Editors:

Renato Iannella National ICT Australia (NICTA) - renatonicta.com.au

Susanne Guth ODRL Initiative - susanneodrl.net

Copyright ODRL Initiative 2005-2006. All Rights Reserved.

Abstract

This document describes the ODRL Version 2.0 Model Semantics Recommendation. The model incorporates new features and requirements for the ODRL rights expression language.

Status of this document

This is the second public Working Draft of the ODRL V2.0 Model Semantics Recommendation document. It has been produced by the ODRL Version 2.0 Working Group. 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@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.

Table of contents

1. Overview
2. Model
3. Scenarios
Acknowledgements
Change History
References

1. Overview

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 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:

• ODRL V2.0 - Requirements [ODRL-REQ]
• ODRL V2.0 - Model - Semantics (this document)
• ODRL V2.0 - Model - XML Encoding
• ODRL V2.0 - Core Profile - Semantics
• ODRL V2.0 - Core Profile - XML Encoding

The new model is based on additional semantics and requirements gathered from the community as well as the past experiences in implementations and research of the ODRL REL. 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.

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].

2. ODRL Model

Figure 1 below shows the complete version 2.0 ODRL Model. The follow sections describes the model semantics in detail [ODRL-REQ#4].

2.1 Rights

The ODRL Model consist of a number of predetermined classes of rights expressions which inherit from the Rights entity [ODRL-REQ#1.11]

The Rights entity may contain the following attributes:

• uid:unique identification of the rights expression (mandatory)
• rights expression type: This attribute indicates the actual semantics of the rights expression. The possible values for this attribute are "statement", "offer", "agreement", "request", and "ticket" (mandatory)

The rights expression types are defined as:

• Statement. The statement supports rights expressions that consists of any number of entities from the complete model. The combination of these entities is not formally defined by this specification. This is aimed at scenarios where there are no fixed criteria for the semantics of the rights expressions as this may not be known or may be determined by other systems, profiles, or communities that process the information at a later time. The objective of the statement is to act as a collection of rights entities without implied semantics of that collection grouping.
• Offer. The offer supports rights expressions that are proposing content under various terms and conditions to any consuming party from the owner party. The offer must contain at least one Asset entity, at least one or both Permission and Prohibition entities, and at least one Party entity with Assigner (rights holder) role. The offer must not contain a Party entity with Assignee or Assignees (consumer/s) roles.
• Agreement. The agreement supports rights expressions that are formal contracts stipulating the content, terms and conditions of usage, and all the parties involved in the agreement [ODRL-REQ#1.4]. The agreement must contain at least one Asset entity, at least one or both Permission and Prohibition entities, and at least one Party entity with Assigner role and at least one Party with Assignee or Assignees (consumer/s) roles.
• Request. The request supports rights expressions that are soliciting the terms and conditions of usage over content from a consuming party [ODRL-REQ#1.4]. The request must contain at least one Asset entity, at least one or both Permission and Prohibition entities, and at least one Party entity with Assignee or Assignees (consumer/s) roles. The request may also contain the Party entity with Assigner role if this is known. The former party being responsible for requesting a set of terms and conditions for use over content owned by the latter party.
• Ticket. The ticket entity supports rights expressions that are contracts stipulating the content, terms and conditions of usage, and the owning parties involved. The consuming party is not known at the time the ticket is issued and is redeemable by anyone who currently holds the ticket in their possession. The ticket entity must contain at least one Asset entity, at least one or both Permission and Prohibition entities, and at least one Party entity with Assigner role. A ticket can be anonymous or personalised, where the executer of that ticket can remain unknown or has to be identified. The anonymous ticket does not contain a Party entity with Assignee or Assignees roles.

All of the Rights Class models may contain digital Signature information. The digital signature provides a trusted mechanism to ensure the integrity, authenticity and non-repudiation of the entire rights expression [ODRL-REQ#1.16].

2.2 Asset

The Asset entity is aimed at identifying and providing information about the content and its structure. 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 must contain the following information:

• unique identification of the asset (mandatory)

The ODRL Core Profile 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 Asset entity may contain a Part entity that indicates that the parent asset contains a number of subparts or is a collection of assets. There are no limits to the level of parts an asset may have. If a parent Asset with child Parts is referenced as the Target of a rights expression, then all the Parts are considered also to be the Target of the same rights expression.

The Asset entity may contain an Inherit entity that indicates an inheritance of rights information from a Parent Asset to a Child Asset [ODRL-REQ#1.20]. In this case, the current Asset is the Child Asset and will inherit all the rights information from the identified Parent Asset. This results in the final set of rights that includes all the Parent Asset rights and the Child Asset rights. In these cases, the rights to be inherited are all of the Permissions and Prohibitions directly linked to the Parent Asset. There are no limits to the inheritance levels an asset may have. In the case where the Parent Asset rights contains stateful expressions, then the inheritance relationship can indicate if the state values are also inherited or not. The default case is not to inherit the state values for stateful expressions.

The Asset entity may contain a WEMI indicator (as defined by [IFLA]) that supports the following information to be captured about the asset [ODRL-REQ#1.21]:

• Work (an abstract intellectual or artistic creation)
• Expression (the intellectual or artistic realization of a work)
• Manifestation (the digital or physical embodiment of an expression of a work)
• Item (a single exemplar instantiation of a manifestation)

All Asset entities may contain digital Encryption information. The digital encryption provides a trusted mechanism to ensure the confidentiality of the entire asset [ODRL-REQ#1.16].

2.3 Party

The Party entity is aimed at identifying and providing additional information about 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:

• unique identification of the party (mandatory).

The ODRL Core Profile 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:

• A Party entity can transfer Permissions and Prohibitions by being the Assigner (rights holder) of such.
• A Party entity can receive Permissions and Prohibitions by being the Assignee (consumer) of such.
• A Party entity can receive Permissions and Prohibitions by being the Assignees (consumers) of such. In this case, the Party entity must identify a group of people and/or legal entities. Each member of the group receives the same set of Permissions and Prohibitions [ODRL-REQ#1.13].

The Party entity undertakes two roles with the Duty entity:

• A Party entity can be responsible for undertaking a Duty by being the Assignee (debitor) of such.
• A Party entity can be entitled to receive the outcomes a Duty by being the Beneficiary (creditor) of such.

2.4 Permission

The Permission entity indicates the actions that the Assignee/s is permitted to perform on the Target asset, respectively that the Assigner (rights holder) has granted to the Assignee (consumer) .

The Permission entity contains the following:

• Actions (required). The Permission entity MUST contain exactly ONE Action that indicates the grated operation on the Target Asset.
• Asset (required). The Permission entity MUST also contain exactly ONE Asset which is the Target of the permission.
• Constraints (optional). One or more Constraints MAY optionally constrain Permissions, e.g. if the Action copy is only permitted for a certain period of time.
• Duties (optional). The Permission MAY refer to one or more Duty entities that indicate a requirement that must be fulfilled in return for receiving the Permission.

Furthermore, the Permission entity may contain

• a Tradeable flag (boolean) that states if the Permission is subject to negotiations.

2.4.1 Action

The Action entity (as part of 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 (as part of 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 an unlimited 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 or more refined semantics.

The Transfer Rights entity is a type of Action that indicates rights that can be further allocated as part of the containing Permission must not exceed those identified in the rights expression statement. With an existing rights expression of the type "statement", "offer", or "agreement", the Transfer Rights permission must link to a rights expression with the type "satement". Furthermore, this statement must only contain one or both Permission and Prohibition entities and must not contain any Party entities and any Asset entities as these are assumed to be the same as the parent rights expression class. The Transfer Rights entity is used to allow the Assigner Party to clearly indicate to the Assignee/s Party what the "Next Rights" are for the latter to assign to other parties (i.e. the consumers of consumers).

The Action entity may contain an Exclusive boolean flag that indicates that the Action is unique and only one is being made available as part of the containing Permission entity [ODRL-REQ#1.12]. The default Exclusive boolean flag setting for all Actions is false.

2.4.2 Constraint

The Constraint entity indicates limits and restriction to the Permission, the Prohibition and the Duty entity [ODRL-REQ#1.9].

Each Constraint entity must contains ONE Constraint Name. Constraint Names are formally defined in Profiles. Constraints express mathematical terms with two operands and one operator, e.g. the 'number of usages' (Name or left operand) must be 'smaller than' (Operator) the 'maximum allowed number of usages' (Right Operand). The ODRL Core Profile defines a standard set of potential (operand) terms and operators that may be used. Communities will develop extension Profiles to capture additional or more refined semantics.

Furthermore, the Constraint entity may contain

• a Status indicator that shows the current value of the constraint variable (operand 1) [ODRL-REQ#1.3].
• a Tradeable flag (boolean) that states if the Constraint is subject to negotiations.

2.4.3 Duty

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 fulfill the Duty, and to an optional Beneficiary 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 the same as the Permission Assigner.

The Duty entity contains the following:

• Action (required). The Action indicates the operation that must be performed on the Object entity.
• Object (required). The Object of a Duty may also be an Asset entity.

  The Object entity MUST contain

  • Value: For example 50, 10 or 0,5 and
  • Measure: Indicates a measure, such as a currency (AUD, EUR) or a weight measure (kg, ounces).
• Constraints (optional). A Duty may contain one or more Constraints [ODRL-REQ#1.10].

The Duty entity contains an unlimited 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 or more refined semantics.

Furthermore, the Duty entity may contain

• a Relax boolean flag 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 flag setting for all Duty entities is false meaning that the Duties must be fulfiled before the rights can be exercised.
• a Tradeable flag (boolean) that states if the Duty is subject to negotiations.

2.5 Prohibition

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 rights holder of the asset - the Assigner.

The Prohibition entity contains the following:

• Action (required). The Prohibition must refer to ONE Action, for example "copy".
• Asset (required). The Prohibition entity must also refer to ONE Assets which are the Target of the prohibitions.
• Constraints (optional). One or more Constraints can optionally constrain Prohibitions, e.g. if the Action copy is prohibited only for a certain period of time.

Furthermore, the Prohibition entity may contain

• a Tradeable flag (boolean) that states if the Prohibition is subject to negotiations.

2.6 Legal

The Legal entity may add legal attributes to a Rights entity. The Legal entity includes:

• jurisdiction jurisdiction details the courts that will have the jurisdiction in connection with all legal proceedings arising from the agreement.
• dispute resolution Dispute resolution details the arbitration process in the case of a contract dispute arising after the conclusion of the contract..
• liabilities: The licensor details the extent of the liabilities incurred by the licensor in case the product does not meet the licensee's expectations or causes damages etc.
• expiration: Indicates the date and time, the rights expression expires.
• date issued: Indicates the date and time the rights expression was issued.
• exceptions policy: Gives details about the copyright exceptions policy (eg fair use), that applies to the digital assets referred to in the rights expression.
• customer residence: Indicates town, country and state of the customer.
• tax: The tax rate that applies to the contract's liabilities.
• notes: Human readable comments about the rights expression

2.7 Communication

The Communication entity may add negotiation aspects to a Rights entity. The Negotation entity includes:

• acceptance: The previously (identified) rights expression has been accepted by the party
• rejection: The previously (identified) rights expression has been rejected by the party
• notes: human readable remarks related to the communication

2.8 Container

The Container entity may tie Permission, Prohibition, Duty, and Constraint entities together with an AND, OR or XOR relationship. The Container entity includes:

• Operation: Operation may be set with ONE of the mathematical value AND, OR and XOR.

2.9 Model Conflicts

The ODRL model may involve the resolution of conflicts due to its broad scope.

Permissions and Constraints

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 statements. 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.

3. Scenarios

This section shows a number of scenarios for each of the rights classes.

The Statement

The following shows the instance of an Statement. The Statement shows a rights expression, stating that the Asset urn:assetgroup:9898 is target of the Permissions publish and the Prohibition to modify. No parties or other elements are involved. This Statement could be used, for example, as a rights template.

The Offer

The following shows the instance of an Offer. The Offer contains the music file urn:music:01 that is offered by the Party urn:fred:454545 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 0,50 AUD.

The Agreement

The following shows the instance of an Agreement. The Agreement contains all entities shown in the Offer scenario. A new Party element urn:mary:45455 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.

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.

The Ticket

The following shows the instance of an 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 2005.

The Offer and Transfer Rights

The following shows the instance of an Offer with Next Rights. The party urn:rich:5656 assigns the two Permissions transfer and modify directly to the potential buyer of the permissions. The potential buyer himself may then sell the Permissions aggregate and reformat to his/her customers, whereas the Asset urn:wallpaper:888 may only be reformatted into a secure container.

Acknowledgements

• IPR Systems (Australia)
• Vienna University of Economics and Business Administration (Austria)
• National ICT Australia (NICTA)
• University of Cape Town (South Africa)

• Vicky Weissman, Cornell University, USA
• Mark Strembeck, Vienna University of Economics and Business Administration, Austria
• Alapan Arnab, University of Cape Town, South Africa
• Steven Rowat

Change History (Informative)

Changes since the last public release:

References