ODRL V2.0 - Model Semantics

Working Draft: 16th May 2005

This version:

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

Latest version:

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

Editors:

Renato Iannella ODRL Initiative - renatoodrl.net

Susanne Guth ODRL Initiative - susanneodrl.net

Copyright ODRL Initiative 2005. 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 first 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
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 the communities. The ODRL Model is free of implementation restrictions and is focussed on the optimal mechanism to represent rights-based information.

ODRL Version 2.0 is a major update for ODRL and will supersede Version 1.1 [ODRL11]. 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 Class Model

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 a Context that supports the following information:

• unique identification of the rights expression (optional)
• jurisdiction (optional)
• physical/digital location (optional)
• date of issuance (optional)
• textual comments/remarks (optional)
• human readable formulation of the rights expression (optional)

Where do we define these terms formally?

The Rights entity is the parent to the following children entities:

• Statement. The Statement entity supports rights expressions that consists of any number of (or none of) entities from the complete model. This is aimed at scenarios where there is no fixed criteria for the content of the rights expressions as this may not be known or may be determined by other systems that process the information at a later time.
• Offer. The Offer entity supports rights expressions that are proposing content under various terms and conditions to any consuming party from the owner party. The Offer entity must contain an Asset entity, one or both Permission and Prohibition entities, and a Party entity with Assigner (rights holder) role. The Offer entity must not contain a Party entity with Assignee or Assignees (consumer/s) roles.
• Agreement. The Agreement entity 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 entity must contain an Asset entity, 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 entity supports rights expressions that are soliciting the terms and conditions of usage over content from a consuming party [ODRL-REQ#1.4]. The Request entity must contain an Asset entity, one or both Permission and Prohibition entities, and at least one Party entity with Assignee or Assignees (consumer/s) roles. The Request entity 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 an Asset entity, one or both Permission and Prohibition entities, and at least one Party entity with Assigner role. The Ticket entity must not contain a Party entity with Assignee or Assignees roles.
• Next Rights. The Next Rights entity supports rights expressions that consist of the terms and conditions of subsequent content usage [ODRL-REQ#1.1]. That is, what the consuming party is allowed to offer to its downstream consuming parties, if they have the allowed Transfer Rights. Within an existing Statement or Offer or Agreement expression, the Transfer Rights permission must link to a Next Rights entity. The Next Rights entity must only contain one or both Permission and Prohibition entities. The Next Rights entity must not contain any Party entities and any Asset entities as these are assumed to be the same as the parent rights expression class.

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 Model

The Asset entity is aimed at identifying and providing additional 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 a Context that supports the following information:

• unique identification of the asset (required)
• metadata describing the asset (optional) [ODRL-REQ#5]

The ODRL Core Profile does not provide additional metadata for the Asset element. It is recommended to use already existing metadata standards, such as Dublin Core, LOM, or MPEG 7.

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 that the rights assigned to the asset pointed to by the Inherit entity are also assigned to the Asset entity [ODRL-REQ#1.20]. In these cases, the rights to be assigned are all of the Permissions and Prohibitions directly linked to the asset identified in the Inherit entity. There are no limits to the inheritance levels an asset may have.

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 Model

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 a Context that supports the following information:

• unique identification of the party (required)
• metadata describing the party (optional) [ODRL-REQ#5].

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.

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

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 ONE Action that indicates the grated operation on the Target Asset.
• Asset (required). The Permission entity MUST also contain ONE Asset which is the Target of the permission.
• Constraints (optional). One or more Constraints can 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.

2.4.1 Action Model

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 extension Profiles to capture additional or more refined semantics.

The Transfer Rights entity is a type of Action that indicates that any additional rights that can be further allocated as part of the containing Permission must not exceed those identified in the Next Rights entity. The Transfer Rights entity is used to allow the Assigner Party to clearly indicate to the Assignee/s Party what the "Next Rights" include 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 Model

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

Each Constraint entity 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 operand 1) must be 'smaller than' (operator) the 'maximum allowed number of usages' (operand 2). 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.

The Constraint entity may contain an Status indicator that shows the current value of the constraint variable (operand 1) [ODRL-REQ#1.3].

2.4.3 Duty 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 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 fulfill 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 contains an unlimited set of Object Names which are formally defined as 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.
• Constraints (optional). A Duty may contain one or more Constraints [ODRL-REQ#1.10].

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.

2.5 Prohibition Model

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.

3. Scenarios

This section shows one scenario for each of the 6 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 NextRights

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.

References