ODRL V2.0 - Model Semantics

Working Draft: 13th January 2007

This version:

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

Latest version:

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

Previous version:

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

Editors:

Susanne Guth ODRL Initiative - susanneodrl.net

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

Copyright ODRL Initiative 2005-2007. 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 third 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 (Informative)
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] The Requirements document represents all requirements for the language ODRL, that have been gathered since ODRL Version 1.1 has been released.
• ODRL V2.0 - Model - Semantics (this document)
• ODRL V2.0 - Model - XML Encoding. The XML Encoding document will specify the serialisation of the Model Semantics in XML, i.e. there you will find the XML schema for the new Model and examples.
• ODRL V2.0 - Core Profile - Semantics. The Core Profile - Semantics document will specify the semantics of a very basic rights vocabulary, or "data dictionary".
• ODRL V2.0 - Core Profile - XML Encoding. In the Core Profile - XML Encoding document you will find the XML schema of the Core Profile and examples.

The new model is based on additional semantics and requirements gathered from the DRM community, the latest reasearch on security and access control, 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.

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 following 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: A 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 "set", "offer", "agreement", "request", and "ticket" (mandatory)

The rights expression types are defined as:

• Set. The Set 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 Set 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, 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, where a consuming party is asking for specific permissions. That means, it supports rights expressions that are solicitations from a consuming party of the terms and conditions of usage over content [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 Assingee(s) Party being responsible for Requesting a set of terms and conditions for use over content owned by the Assigner Party.
• Ticket. The Ticket entity supports rights expressions that stipulate the content, terms and conditions of usage, and the owning parties involved. The consuming party may not be 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 (possibly both) Permission and Prohibition entity, 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:

• uid: A 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 Parent Asset rights and Child Asset rights. In these cases, the rights to be inherited are all 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 (i.e. a Permission with Constraint, where "status" is not NULL) , the inheritance relationship can indicate if the status values are also inherited or not. The extra parameter of the inheritance relationship is stateful (boolean). The default case is not to inherit the status values for stateful expressions (i.e., stateful == FALSE).

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:

• uid: A 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. Note, the Assignee can also represent a group of people and/or legal entities, but only one member of the group receives the set of Permissions.
• 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 Permissionss and Prohibitionss [ODRL-REQ#1.13].

The Party entity undertakes three 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 Assigner (creditor) of such. Note, the Assignee can also represent a group of people and/or legal entities, but only one member of the group is the beneficiary of the Duty.
• A Party entity can be entitled to receive the outcomes a Duty by being the Assignees (creditors) of such. In this case, the Party entity must identify a group of people and/or legal entities. Each member of the group is the beneficiary of the Duty.

Finally the Party entity undertakes an additional role with the Asset entity:

• A Party entity can be related to an Asset by being the Rightsholder (owner) of such. This role allows to express that someone simply "owns" an asset.

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

• tradeable: A 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 subclass of Action. It identifies rights that can be assigned to secondary consumers (also called "Next Rights"). The Transfer Rights permission must link to a Rights entity with the type "Set". It may not contain any Party entities or any Asset entities as these are assumed to be the same as in the parent rights expression.

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

• name: A name that clearly identifies the Constraint type, and the left operand of the mathematical operation. Examples for constraint names are "# of permissed Usages", "role of user", "Expiration time", etc. When processing rights expressions these constraint names shall be directly linked to a procedure that, e.g. determines the Number of already performed usages, the role of the user, expiration date, etc.
• operator:An operator such as "greater than", "smaller than", "equal to", etc.
• rOperand:The (right) operand, of the mathematical operation, such as today's date, a fixed date, a static number, etc.

Each Constraint entity must contain 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' (ri(ght)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

• status: An indicator that the current value of the constraint variable (left operand, i.e. current value of "name") [ODRL-REQ#1.3].
• tradeable:A 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 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 the same as the Permission Assigner.

The Duty entity contains the following:

• Action (required). The Action indicates the operation (e.g. payment) 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].
• Duties (optional). A Duty may contain one or more additional Duties via the "Non-performed" relation if the original Duty was not fullfilled, and therefore results in new duties, e.g. a penalty of € 1,-. These duties can apply if the constraint of the original duty was not met. Note that in this case the "Relax" flag (see below) of the orginial Duty should be set to "FALSE".

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

• relax: (optional) A flag (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 flag setting for all Duty entities is false meaning that the Duties must be fulfiled before the rights can be exercised.
• tradeable:(optional) A 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

• tradeable: (optional) A 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 provides the following attributes:

• 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.
• human readable: Includes or refers to a human readable version of the rights expression

2.7 Communication

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

• state: This attribute indicates the actual state of the rights expression. When negociating the (initial) rights expression, trading partners can respond, accept, reject, and resubmit rights expression or make a (final) counter offer until an agreement is reached. Additionally, a party can indicate that s/he has acknowledged a rights expression or communicate his/her non-binding intention to submit a certain rights expression. The suggested values for state are "intentional", "initial", "respond", "accept", "reject", "resubmit", "final", "counteroffer", "acknowledge", "final", and "protocol error".

2.8 Container

The Container entity may tie Permission, Prohibition, Duty, and Constraint entities together with an AND, OR or XOR relationship. In Figure 2.8.1 three possible uses of the Container entity is shown. The Container entity may tie

• a) two Duties together, that are either related to a Permission or a Prohibition. Note that the two Duty entities MAY both have their own Constraint, Action, Object and further Duty entity(ies).
• b) two Permission or (exclusive) two Prohibition (i.e. not Permissions and Prohibitions at the same time) entities together that are related to a Rights entity. Note that the two Permissions/Prohibitions MAY both have their own Duty, Constraint, Action, Asset entity(ies).
• c) two Constraint entities together that are related to a Permission or (exclusive) a Prohibition or (exclusive) a Duty entity.

• 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 s. 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 (Informative)

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

The Set

The following shows an instance of a Set. The Set 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 Set 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.

The Container

The following shows the instance of an Offer with a Permission Container. The Offer Offer88 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.

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
• Eetu Luoma, Dr. Elma Ltd.

Change History (Informative)

Changes since the last public release:

References