ODRL V2.0 - Core Metadata

Working Draft: 24th May 2009

This version:
http://odrl.net/2.0/WD-ODRL-Core-Metadata-20090524.html
Latest version:
http://odrl.net/2.0/WD-ODRL-Core-Metadata.html
Previous version:
http://odrl.net/2.0/WD-ODRL-Core-Metadata-20090212.html
Editors:
Susanne Guth, Vodafone, susanne.guthATvodafone.com
Renato Iannella, National ICT Australia (NICTA), renatoATnicta.com.au

Abstract

This document contains the ODRL Version 2.0 Core Metadata Specification. The core metadata provides basic vocabulary and its semantics for the ODRL rights expression language Version 2.0.

Status of this document

This is the first public Working Draft of the ODRL V2.0 Core Metadata Specification document produced by the ODRL Version 2.0 Working Group.

The ODRL Initiative publishes a Working Draft for review by working group members and other interested parties. The ODRL Version 2.0 Working Group expects to advance this document to a Draft Specification once the Working Group has finalised the Working Draft for the ODRL Version 2.0 Core Metadata 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.

Table of contents

1. Overview
2. ODRL Core Metadata
3. Profiles (Informative)
Acknowledgements
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. The Core Metadata Profile will specify the terms (vocabulary) used by the Core Model for basic rights expression needs. (This was called the "data dictionary" previously.)[ODRL11]

The following documents are planned for ODRL Version 2.0:

The new profile includes additional semantics and meets 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].

2. ODRL Core Metadata

The table below shows the complete version 2.0 ODRL Core Metadata. The Core Metadata offers a basic vocabulary for the expression of terms and conditions over assets. Additional semantics can be defined in ODRL Extension Profiles (see also Section 3 Profiles ) for particular ODRL application areas, such as contracts, service level agreements, or certain industry sectors. All terms of the Core Metadata are related to one specific entity of the Core Model, e.g. Asset, Party, Permission, Action, Duty, etc. and SHALL only be used for that particular entity. [ODRL-Model].

2.1 Actions

Terms in this section may be used as attribute in the field "name" of the Action Entity.

2.2 Constraints

Terms in this section may be used as attribute in the field "name" of the Constraint Entity.

Table 1: Terms for the entity Action of the ODRL Core Profile
Name Identifier  Semantics  Application recommended for  Comment/Example 
Print  print  The act of rendering the asset onto paper or hard copy form, i.e. of creating a fixed (i.e., static), directly perceivable representation of the content.   Permission, Prohibition    
Play  play  The act of rendering the asset into audio/video form.   Permission, Prohibition    
Display  display  The act of making a transient visible rendering of the content (for example, image/gif or image/jpeg) on a visual device.   Permission, Prohibition    
Execute  execute  The act of executing the asset.  Permission, Prohibition, Duty  For example, machine executable code or Java such as a game or application.  
Export  export  The act of exporting rights over DRM Content and corresponding Rights Objects. The export element has the semantics of exporting the DRM Content and corresponding Rights Objects to a target system other than the current DRM system.   Permission, Prohibition    
View  view  The act of consuming something that is shown to the customer in an video format, e.g. an advertisement.   Permission, Prohibition, Duty   
Install  install  The act of allowing for the operation of loading, verification, installation and certification of an asset into a data storage device.   Permission    
Uninstall  uninstall  The act of allowing for the removal from or disabling of an asset in a data storage device.   Permission, Prohibition    
Sell  sell  The act of allowing the asset to be sold commercially.   Permission, Prohibition    
Copy  copy  The act of making an exact copy of a digital asset between data storage devices. Permission, Prohibition    
Move  move  The act of allowing a digital asset to move between data storage devices.  Permission, Prohibition   After the asset has been moved, the original copy needs to be deleted.  
Modify  modify  The act of changing parts of the asset creating a new asset. Permission, Prohibition    
Extract  extract  The act of extracting (replicating) unchanged parts (or all) of the asset for reuse into another asset. Permission, Prohibition    
Annotate  annotate  The act of adding notations/commentaries to the asset creating a new asset. Duty    
Aggregate  aggregate  The act of using an asset (or parts of it) as part of a composite work or collection. Permission, Prohibition    
Tracked  tracked  The act of recording Metering Information of the content. The element indicates that DRM Agent is required to record Metering Information.The Metering Information SHALL consist of the number of times that the DRM Content has been consumed and the accumulated usage time that the DRM Content has been consumed for. Duty    
Give  give  The act of giving some asset to a third party via next rights  Permission, Prohibition, Duty   Respective constraints and duties can be defined, e.g. to state wheather revenue shall flow to a party.  
Pay  pay  The act of paying an amount to a party. Both, amount an party need to be specified separately, with the party element, duty element, and object element.  Duty    
Commercialise  Commerce  The act of giving away the asset to third parties in a commercial way.   Permission, Prohibition   Respective constraints and duties can be defined, e.g. to state whether revenue shall flow to a party.  
adhoc-share  ashare  The act of ad-hoc sharing an RO and its corresponding DRM-protected content with other DRM Agents.   Permission, Prohibition   Respective constraints and duties can be defined, e.g. to state whether the permission shall be constraint by number and time to a certain network range (proximity).  
lend  lend  The act of lending an RO and its corresponding DRM-protected content with other DRM Agents.   Permission, Prohibition   Respective constraints and duties can be defined, e.g. to state whether the permission shall be constraint by number and time to a certain network range (proximity).  
Table 2: Terms for the field "name" of the entity Constraint of the ODRL Core Profile
Name Identifier  Semantics  Comment/Example 
Count  count  A positive Integer. A numeric count indicating the number of times the corresponding permission/prohibition/duty may be exercised.   For example, a Print permission shall be constraint by 10 times. To express this, create a Constraint entity, where name = count; operator = SMALLEROREQUAL; and rightOperand = 10.  
Spatial  spatial  spatial is a placeholder for the specification of a geographic area with codes specified from a controlled vocabulary (eg [ISO3166] for country codes)..  
Date Time   datetime   Date and Time value must conform to [ISO8601].   
Timed   timed   The timed constraint contains a non-negative integer value in the rOperant attribute. Operator is GTOET. It is used for example together with a count constraint (former timed-count) or the tracked action. It specifies the number of seconds after which the access to the DRM Content SHALL be considered a meterable or countable event. The default value is 0 seconds which implies that the DRM Agent MUST immediately record Metering Information for the DRM Content being consumed; or must immediately count down the integer value of the count constraint.    
Range  range  Datatype tbd   
Accumulated  accumulated  Value must conform to [ISO8601].  For example "P30H" indicates a 30 hour period. 
Interval  interval  Interval value must conform to [ISO8601].  For example "P7D" indicates a 7 day period. 
Water Mark   watermark  Specification of watermarking constraint for the asset.   
Purpose  purpose  May be used to constraint the permission/prohibition to a certain purpse.  E.g. commercial use. 
CPU  cpu  An identifiable computing system with a central processing unit (CPU).    
System  system  An identifiable computing system that is not identifiable by a central processing units (CPUs).    
Proximity  proximity  Proximity is a placeholder for an identifiable proximity detection method name, e.g. ”urn:oma:proximity:pm042_iph:3.14”.    

Terms in this section may be used as attribute in the field "operator" of the Constraint Entity.

Table 3: Terms for the field "operator" of the entity Constraint of the ODRL Core Profile
Name Identifier  Semantics  Comment/Example 
Greater than  GREATERTHAN  An operator indicating that a given value is greater than the rightOperand of the Constraint.    
Less than  LESSTHAN  An operator indicating that a given value is less than the rightOperand of the Constraint.    
Equals  EQUALS  An operator indicating that a given value equals the rightOperand of the Constraint.    
Not equal to  NOTET  An operator indicating that a given value is not equal to the rightOperand of the Constraint.   
Less than or equal to  LTOET  An operator indicating that a given value is less than or equal to the rightOperand of the Constraint.    
Greater than or equal to  GTOET  An operator indicating that a given value is greater than or equal to the rightOperand of the Constraint.    
Is part of   is part of  An operator indicating that a given value is part of the defined set defined by the rightOperand of the Constraint.    

In the field "rightOperand" of the Constraint Entity, data types such as INTEGER, REAL, STRING, etc. may be used

2.3 Object

Terms in this section may be used as attribute in the field "measure" of the Object Entity.

Table 4: Terms for the entity Object of the ODRL Core Profile
Name Identifier  Semantics  Comment/Example 
Currency  cur  cur is a placeholder for any 3-letter currency code as specified in ISO 4217 (e.g. EUR, USD, GBP). The number given in the 'value' field of the Object Entity represents an amount in the respectice currency.  For example: value = 20, measure = EUR; represent an amount of 20 EUR. If a party receives or pays 20 EUR depends on the action that is related to the object. 
Add  add  View Adds defines the act of a party to view a commercial advertisement.   For example value = 3, measure = viewadds; represents the amount of three advertisements by the party this object is related to e.g. by a duty entity. An action that makes semantical sense would be e.g. "view".  

2.4 Party

For the entity Party, it is recommended to use established stardards for the description such as vCard.

2.5 Asset

For the entity Asset, it is recommended to use established stardards for the description such as Dublin Core.

3. Profiles (Informative)

The ODRL Core Model and Metadata represent the basic needs for rights expressibility. As a result, different communities will require less or more terms from the Core Metadata. Community Profiles that extend the ODRL Core Model or Metadata are expected to be developed that adequately document these changes in respect to the Core Profile. Some requirements of this process include:

Acknowledgements

The editors gratefully acknowledge feedback and contributions to this document from:

References

[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

Valid HTML 4.0 Strict