Skip to toolbar

Community & Business Groups

ODRL Version 2.1 Common Vocabulary

Final Specification: 5 March 2015

This Version: http://www.w3.org/community/odrl/vocab/2.1/

Latest Version: http://www.w3.org/community/odrl/vocab/2/

Editors:
Renato Iannella, Semantic Identity, riATsemanticidentity.com
Michael Steidl, IPTC, mdirectorATiptc.org
Susanne Guth, Vodafone, susanne.guthATvodafone.com

Status of this document

This specification was published by the W3C ODRL Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

The W3C ODRL Community Group publishes a Final Specification to indicate that the document is believed to be mature and stable for implementation by the wider community. This Final Specification is now endorsed by the W3C ODRL Community Group as appropriate for widespread deployment and that promotes the Community Groups’s mission.

Discussion and feedback of this document takes place on the W3C ODRL Community Group mailing list (see Contributor Archive). Feedback from the public is encouraged and can be send to public-odrl@w3.org (see Public Archive).


Copyright © 2015 the Contributors to the Final Specification, published by the W3C ODRL Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available.

Table of contents


1. Overview

The W3C ODRL Community Group’s aim is to develop and promote an open international specification for Policy Language expressions. The ODRL Policy Language provides a flexible and interoperable information model to support transparent and innovative use of digital assets in the publishing, distribution and consumption of content, applications, and services across all sectors and communities. The ODRL Policy model is targeted to support the business models of open, educational, government, and commercial communities through Profiles that enhance the model to align to their requirements whilst providing a common semantic layer for interoperability

The Common Vocabulary specifies terms (vocabulary) used by the Core Model [ODRL-MODEL] for policy expression needs.

The requirements for the Version 2 Model and Vocabulary are documented [ODRL-REQ].

This specification utilises the key words “MUST”, “MAY”, “REQUIRED”, and “OPTIONAL” in accordance to [RFC-2119]. These words are used in lowercase in this document.

2. ODRL Common Vocabulary

The Common Vocabulary offers a wide range of vocabulary terms for the expression of Types, Permissions, Prohibitions, Constraints, and Duties over assets. Additional and/or different semantics may be defined in ODRL Profiles (see Section 2.1.2 in the ODRL Core Model [ODRL-MODEL] specification) for particular ODRL application areas defined by industry and community sectors.

All terms of the Common Vocabulary are related to specific entities of the Core Model [ODRL-MODEL]:

  • Types for Polices
  • Actions for Permissions, Prohibitions, and Duties
  • Names and Operators for Constraints
  • Functions and Scope for Roles played by Parties
  • Relations for Assets

The URI identifying the ODRL Version 2 Common Vocabulary is defined as:

   http://www.w3.org/ns/odrl/2/

This URI must be used in all encodings of ODRL policies to refer to the ODRL Common Vocabulary.
A URI identifying an ODRL Common Vocabulary term is created by appending the identifier of that term to the URI of the vocabulary.

For example, below are the target and play terms:

   http://www.w3.org/ns/odrl/2/target
   http://www.w3.org/ns/odrl/2/play

2.1 Policy Types

Vocabulary terms in this section may be used as the “type” of the Policy Entity.

Table 2.1: Terms for the entity Type of the Policy Entity
Identifier Semantics Comment
Agreement Policy expressions that are formal contracts (or licenses) stipulating all the terms of usage and all the parties involved. Must contain at least the Party entity with Assigner role and a Party with Assignee role. The latter being granted the terms of the Agreement from the former.
Offer Policy expressions that propose terms of usage from an Asset owner Must contain a Party entity with Assigner role. The Offer may contain a Party entity with Assignee role, but does not grant any privileges to that Party.
Privacy Policy expressions that stipulate the terms of usage over personal information. Must contain at least the Party entity with Assigner role and a Party with Assignee role. Must also contain a Duty on the assignee related to obligations towards managing the assigner’s Asset containing personal information. The Assignee is being granted the terms of the Privacy policy from the Assigner.
Request Policy expressions that propose terms of usage to an Asset owner Must contain a Party entity with Assignee role. The Request may also contain the Party entity with Assigner role if this is known. No privileges are granted to any Party.
Set Policy expressions that consists of entities from the complete model The Set is aimed at scenarios where there is an open criteria for the semantics of the policy expressions and typically refined by other systems/profiles that process the information at a later time. No privileges are granted to any Party.
Ticket Policy expressions that stipulate the terms of usage and is redeemable by any Party who currently holds the Ticket in their possession May contain the Party entity with Assigner role and the Party entity with Assignee role. A Ticket (or Voucher) may be anonymous or personalised, where the holder of that Ticket may remain unknown or has to be identified. The holder, or if known, the Assignee, is being granted the terms of the Ticket from the Assigner (in known).

2.2 Actions

Vocabulary terms in this section may be used as the “name” of the Action entity for Permissions, Prohibitions , and Duties.

Actions can be used with Permission or Prohibition or with Duty. This split is reflected by sections 2.2.1 and 2.2.2 below.

2.2.1 Actions for Permission or Prohibition

Action Hierarchy Overview

Actions towards third-parties only

Table 2.2.1: Terms for the entity Action used with Permission or Prohibition
Identifier
+ BT Broader Term
Semantics Comment
aggregate
BT: use
The Assigner permits/prohibits the Assignee(s) to use the Asset or parts of it as part of a composite collection.
annotate
BT: use
The Assigner permits/prohibits the Assignee(s) to add explanatory notations/commentaries to the Asset without modifying the Asset in any other way.
anonymize
BT: use
The Assigner permits/prohibits the Assignee(s) to anonymize all or parts of the Asset. For example, to remove identifying particulars for statistical or for other comparable purposes, or to use the asset without stating the author / source
archive
BT: use
The Assigner permits/prohibits the Assignee(s) to store the Asset (in a non-transient form). Constraints may be used for temporal conditions.
concurrentUse
BT: use
The Assigner permits/prohibits the Assignee(s) to create multiple copies of the Asset that are being concurrently used.
derive
BT: use
The Assigner permits/prohibits the Assignee(s) to create a new derivative Asset from this Asset and to edit or modify the derivative. A new asset is created and may have significant overlaps with the original Asset. (Note that the notion of whether or not the change is significant enough to qualify as a new asset is subjective.) To the derived Asset a next policy may be applied.
digitize
BT: use
The Assigner permits/prohibits the Assignee(s) to produce a digital copy of (or otherwise digitize) the Asset from its analogue form.
display
BT: present
The Assigner permits/prohibits the Assignee(s) to display the visual media Asset to an audience or the public. For example, displaying an image on a screen.
distribute
BT: use
The Assigner permits/prohibits the Assignee(s) to distribute the Asset.
execute
BT: use
The Assigner permits/prohibits the Assignee(s) to run the computer program Asset. For example, machine executable code or Java such as a game or application.
extract
BT: reproduce
The Assigner permits/prohibits the Assignee(s) to extract parts of the Asset and to use it as a new Asset. A new asset is created and may have very little in common with the original Asset. (Note that the notion of whether or not the change is significant enough to qualify as a new asset is subjective.) To the extracted Asset a next policy may be applied.
give
BT: transfer
The Assigner permits/prohibits the Assignee(s) to transfer the ownership of the Asset to a third party without compensation and while deleting the original asset.
grantUse
BT: use
The Assigner permits/prohibits the Assignee to grant the use the Asset to third parties. This action enables the Assignee to create policies for the use of the Asset for third parties. nextPolicy is recommended to be agreed with the third party. Use of temporal constraints is recommended.
index
BT: use
The Assigner permits/prohibits the Assignee(s) to record the Asset in an index. For example, to include a link to the Asset in a search engine database.
install
BT: use
The Assigner permits/prohibits the Assignee(s) to load the computer program Asset onto a storage device which allows operating or running the Asset.
modify
BT: use
The Assigner permits/prohibits the Assignee(s) to update existing content of the Asset. A new asset is not created by this action. This action will modify an asset which is typically updated from time to time without creating a new asset like a database. If the result from modifying the asset should be a new asset the actions derive or extract should be used. (Note that the notion of whether or not the change is significant enough to qualify as a new asset is subjective.)
move
BT: use
The Assigner permits/prohibits the Assignee(s) to move the Asset from one digital location to another including deleting the original copy. After the Asset has been moved, the original copy must be deleted.
play
BT: present
The Assigner permits/prohibits the Assignee(s) to perform an audio Asset to an audience.
present
BT: use
The Assigner permits/prohibits the Assignee(s) to perform or exhibit an Asset to an audience.
print
BT: present
The Assigner permits/prohibits the Assignee(s) to print an Asset onto paper or to create a hard copy. For example, creating a permanent, fixed (static), and directly perceivable representation of the Asset.
read
BT: use
The Assigner permits/prohibits the Assignee(s) to obtain data from the Asset. For example, the ability to read a record from a database (the Asset).
reproduce
BT: use
The Assigner permits/prohibits the Assignee(s) to make (an) exact reproduction(s) of the Asset.
sell
BT: transfer
The Assigner permits/prohibits the Assignee(s) to transfer the ownership of the Asset to a third party with compensation and while deleting the original asset.
textToSpeech
BT: present
The Assigner permits/prohibits the Assignee(s) to have a text Asset read out loud to an audience.
transfer The Assigner transfers/does not transfer the ownership in perpetuity to the Assignee(s).
transform
BT: use
The Assigner permits/prohibits the Assignee(s) to make a digital copy of the digital Asset in another digital format. Typically used to convert the Asset into a different format for consumption on/transfer to a third party system.
translate
BT: use
The Assigner permits/prohibits the Assignee(s) to translate the original natural language of an Asset into another natural language. A new derivative Asset is created by that action.
use The Assigner permits/prohibits the Assignee to use the Asset as agreed. More details may be defined in the applicable agreements or under applicable commercial laws. Refined types of actions can be expressed by the narrower actions.

 

2.2.2 Actions for Duty

Action Hierarchy Overview

Table 2.2.2: Terms for entity Action used with Duty
Identifier Semantics Comment
acceptTracking The Assigner requires that the Assignee(s) accepts that the use of the Asset may be tracked The collected information may be tracked by the Assigner, or may link to a Party with the role function “trackingParty”.
attribute The Assigner requires that the Assignee(s) attributes the Asset to the Assigner or an attributed Party. May link to an Asset with the attribution information. May link to a Party with the role function “attributedParty”.
compensate The Assigner requires that the Assignee(s) compensates the Assigner (or other specified compensation Party) by some amount of value, if defined, for use of the Asset. The compensation may use different types of things with a value:
– the  thing is expressed by the value (term) of the Constraint name
– the value is expressed by operator, rightOperand, dataType and unit
delete The Assigner requires that the Assignee(s) permanently removes all copies of the Asset. Use a constraint to define under which conditions the Asset should be deleted.
ensureExclusivity The Assignee requires that the Assigner(s) ensure(s) that the permission on the Asset is exclusive to the Assignee.
include The Assigner requires that the Assignee(s) include(s) other related assets in the Asset. For example; Bio picture must be included in the attribution. Use of the Asset relation attribute is required
inform The Assigner requires that the Assignee(s) inform(s) the Assigner or an informed Party that an action has been performed on or in relation to the Asset. May link to a Party with the role function “informedParty”.
nextPolicy The Assigner requires that the Assignee(s) grants the specified Policy to a third party for their use of the Asset.
obtainConsent The Assigner requires that the Assignee(s) obtains explicit consent from the Assigner or a consenting Party to perform the requested action in relation to the Asset. Used as a Duty to ensure that the Assigner or a Party is authorized to approve such actions on a case-by-case basis. May link to a Party with the role function “consentingParty”.
reviewPolicy The Assigner requires that the Assignee(s) has(ve) a person review the Policy applicable to the Asset. Used when human intervention is required to review the Policy. May link to an Asset which represents the full Policy information.
uninstall The Assigner requires that the Assignee(s) unload(s) and delete(s) the computer program Asset from a storage device and disable(s) its readiness for operation. The Asset is no longer accessible to the Assignee(s).
watermark The Assigner requires that the Assignee(s) apply(ies) a watermark as provided by the Assigner to the Asset. It is recommended to embed a link to the watermark.

2.3 Constraints

The Constraint entity has three mandatory attributes: name, operator, rightOperand and three optional attributes: dataType, unit, status. For example, to express that a Print Permission is constraint by a maximum of 10 times, create a Constraint entity where:

name = count
operator = lteq
rightOperand = 10

For the attribute rightOperand the values should be represented by standard data types such as Integer, Real, String, URI, etc which may be expressed by the dataType attribute. The unit attribute may provide additional information about the rightOperand value, such as currency types. The status attribute represents the current value of the constraint value, such as 5 for the current value of print outputs (from the above example).

2.3.1 Names for Constraint

Vocabulary terms in the below table may be used as the attribute “name” of the Constraint Entity.

Table 2.3.1: Terms for the attribute “name” of the entity Constraint
Identifier Semantics Comment
absolutePosition A point defined with absolute coordinates For example, JPEG image must be positioned at 100×100 pixel location. This may be used to express [PLUS] semantics.
absoluteSize The absolute dimension that the Asset may be resized For example, JPEG image must be reproduced onto an area no larger than A0. This may be used to express [PLUS] semantics.
count The numeric count indicating the number of times the corresponding entity may be exercised Should be a positive integer.
dateTime The date (and optional time and timezone) representing a point in time or period Date and Time value must conform to [ISO-8601] as represented in [W3CXMLSCHEMA]. The use of Timezone information is strongly recommended.
fileFormat The file format applicable to the Asset For example, this may be used to express [PLUS] semantics; only JPEG image may be distributed.
industry The defined industry sector applicable to the asset usage For example, publishing, financial.
language The natural language applicable to the asset usage For example, this may be used to express [PLUS] semantics; JPEG image may only be reproduced with Spanish text. Must use [BCP-47] codes.
deliveryChannel The delivery channel used for storing or communicating the asset For example, the asset may be distributed only on mobile networks.
elapsedTime A period of time in which the policy action can be exercised. The start of the period is when the action is first exercised.
event Specification of a defined event applicable to the asset usage For example, asset may be used at the “FIFA World Cup” only. To express events related to undertaking Duties, a specific event value has been defined:

  • policyUsage – the time period whilst the policy is being exercised

This will enable constraints to be expressed such as “event lt o:policyUsage” indicating before the policy is exercised.

media The media type in which the asset may be used For example, electronic, print, advertising, marketing. This may be used to express [PLUS] semantics.
meteredTime The maximum period of metered usage time Value must conform to [ISO-8601] as represented in [W3CXMLSCHEMA]. For example “P30H” indicates a 30 hour period.
payAmount The value of the financial payment The dataType attribute may be used to indicate the type of the value (eg decimal) and the unit attribute to indicate the currency. May be used for compensation duties.
percentage The amount (as a percentage) of the action applicable to the asset A numeric value from 0 to 100. For example, extract a maximum of 50% of the asset
product The specified Product or Service name For example, this may be used to express [PLUS] semantics; images may only be reproduced in the XYZ Magazine.
purpose Specification of a defined purpose applicable to the asset usage For example, educational use. [P3P] Purpose values may also be used.
recipient The party that receives the result of the Action on the Asset The right operand must identify one or more specific parties or categories of party
relativePosition A point defined with reference to another position For example, this may be used to express [PLUS] semantics; JPEG image must be positioned at the Top of the Page.
relativeSize The relative dimension that the Asset may be resized For example, this may be used to express [PLUS] semantics; JPEG image resized to maximum of 200%.
resolution The resolution at which the asset may be used For example, may be printed at 1200dpi.
spatial A code representing a geospatial area The code value and code source must be represented. For example, the ISO-3166 Country Codes and the Getty Thesaurus of Geographic Names. A URI should be used to represent this value.
timeInterval Recurring period of time in which the usage may be exercised Interval value must conform to [ISO-8601] as represented in [W3CXMLSCHEMA]. For example, “P7D” indicates a 7 day period.
systemDevice An identifiable computing system For example, identifiable via the CPU or unique hardware address.
version The scope of versions for the asset For example, Single Paperback, or Multiple Issues. This may be used to express [PLUS] semantics.
virtualLocation Specification of a digital locale For example, an Internet domain or IP address range

2.3.2 Operators for Constraints

Vocabulary terms in the below table may be used as attribute in the attribute “operator” of the Constraint Entity.

Table 2.3.2: Terms for the attribute “operator” of the entity Constraint
Identifier Semantics
eq The “Equals” operator indicating that a given value equals the rightOperand of the Constraint
gt The “Greater Than” operator indicating that a given value is greater than the rightOperand of the Constraint
gteq The “Greater Than or Equal To” operator indicating that a given value is greater than or equal to the rightOperand of the Constraint
hasPart The “Has Part” operator indicating that a given value contains the rightOperand of the Constraint
isA The “Is A” operator indicating that a given value is an instance of the rightOperand of the Constraint
isAllOf The “Is All Of” operator indicating that a given value is all of the rightOperand of the Constraint
isAnyOf The “Is Any Of” operator indicating that a given value is any of the rightOperand of the Constraint
isNoneOf The “Is None Of” operator indicating that a given value is none of the rightOperand of the Constraint
isPartOf The “Is Part Of” operator indicating that a given value is contained by the rightOperand of the Constraint
lt The “Less Than” operator indicating that a given value is less than the rightOperand of the Constraint
lteq The “Less Than or Equal To” operator indicating that a given value is less than or equal to the rightOperand of the Constraint
neq The “Not Equal To” operator indicating that a given value is not equal to the rightOperand of the Constraint

2.4 Role of a Party

For the Role entity, the Function and Scope attributes may be used for specific details undertaken by the identified Party in the policy.

2.4.1 Functions of the Role of a Party

Vocabulary terms in the below table may be used as the attribute “function” of the Role Entity.

Table 2.4.1: Terms for the attribute “function” of the entity Role
Identifier Semantics Comment
assigner The Party is the issuer of the policy statement Must be supported.
assignee The Party is the recipient of the policy statement Must be supported.
attributedParty The Party to be attributed May be specified as part of the attribute action.
consentingParty The Party to obtain consent from May be specified as part of the obtainConsent action.
informedParty The Party to be informed of all uses May be specified as part of the inform action.
compensatedParty The Party is the recipient of the compensation May be specified as part of the compensate duty action.
trackingParty The Party is the usage tracker May be specified as part of the acceptTracking action.

The scope attribute indicates how to interpret the identified Party and provides contextual information in determining the extent of the policy statement. For example, if a Party is identified as a member of the Acme Social Network (using identifier urn:acme:user:billie) and they are the assignee with “allConnections” scope, then the group of individuals that have actually been assigned the permission consists of all the first-level connections (eg friends) that the identified Party has on that social network. That is, the social graph of the party starting from urn:acme:user:billie.

2.4.2 Scopes of the Role of a Party

Vocabulary terms in the below table may be used as the attribute “scope” of the Role Entity.

Table 2.4.2: Terms for the attribute “scope” of the entity Role
Identifier Semantics Comment
Individual The Party is a single individual Must be supported.
Group The Party represents a defined group with multiple individual members Must be supported.
All All the collective individuals within a context For example, may be used to indicate all the users of a specific social network the party is a member of. Note that “group” scope is also assumed.
AllConnections All the first-level connections of the Party For example, may be used to indicate all “friends” of the Party. Note that “group” scope is also assumed.
All2ndConnections All the second-level connections of the Party For example, may be used to indicate all “friends of friends” of the Party. Note that “group” scope is also assumed.
AllGroups All the group connections of the Party For example, may be used to indicate all groups that the Party is a member of. Note that “group” scope is also assumed.

For the entity Party, it is recommended to use established standards for the party description such as [VCARD].

2.5 Relation of an Asset

For the Asset entity, the Relation attributes must be used to specify the relationship of the Asset the the Policy.

Vocabulary terms in the below table may be used as the attribute “relation” of the Relation Entity.

Table 2.5: Terms for the attribute “relation” of the entity Relation
Identifier Semantics Comment
target The Asset upon which the Action is performed This is the default value and must be supported. Only one target can be specified.
output The Asset which is created from the output of the Action For example, can indicate that a Translated Asset uses a specific UID. This UID of the newly created Asset can then be used in other Policy expressions.

For the entity Asset, it is recommended to use established standards for the asset description such as [DC] or other standards relevant for the asset type.

Change History

The following terms of the  have been added since Version 2.0:

  • Action use
  • Action grantUse
  • Action compensate
  • Action modify

The following terms have been renamed since Version 2.0:

  • Constraint systemDevice (was system device)
  • Party compensatedParty (was payeeParty)

The following terms have been deprecated since Version 2.0:

  • Action appendTo (was append) – use modify
  • Action writeTo (was write) – use modify
  • Action adHocShare (see OMA vocabulary)
  • Action extractChar (see ONIX vocabulary)
  • Action extractWord (see ONIX vocabulary)
  • Action extractPage (see ONIX vocabulary)
  • Action attachPolicy (see CC vocabulary)
  • Action attachSource (see CC vocabulary)
  • Action shareAlike (see CC vocabulary)
  • Action commercialize (see CC vocabulary)
  • Action share (see CC vocabulary)
  • Action lease
  • Action lend
  • Action preview (use action plus appropriate constraint)
  • Action pay (use compensate action)
  • Action secondaryUse
  • Constaint proximity (see OMA vocabulary)
  • Constraint timedCount (see OMA vocabulary)

Acknowledgements

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

  • All members of the Version 2.0 + 2.1 Group
  • Especially, Alapan Arnab, Rüdiger Grimm, Steven Rowat, Eetu Louma, Myles Stuart, Francis Cave, Helge Hundacker, Daniel Pahler, Andreas Kasten, Jonas Zitz, Jean-Noel Colin, Hassan Abdel-Rahman

References

[ODRL-MODEL] R. Iannella & S. Guth & D. Paehler & A. Kasten (eds). Open Digital Rights Language (ODRL) Version 2.1 – Core Model. Final Specification, W3C ODRL Community Group. http://www.w3.org/community/odrl/model/2.1/
[ODRL-11] R. Iannella (ed). Open Digital Rights Language (ODRL) Version 1.1. W3C Note, 19 Sept 2002. http://www.w3.org/TR/odrl/
[ODRL-REQ] S. Guth & R. Iannella (eds). Open Digital Rights Language (ODRL) Version 2.0 Requirements (Working Draft), ODRL Initiative, http://www.w3.org/2012/09/odrl/archive/odrl.net/2.0/v2req.html, 24 November 2004.
[RFC-2119] 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
[VCARD] F. Dawson & T. Howes, vCard MIME Directory Profile, IETF, RFC 2426,September 1998. http://www.ietf.org/rfc/rfc2426.txt
[DC] The Dublin Core Metadata Intitiative http://dublincore.org
[PLUS] Picture Licensing Universal System (PLUS) Technical Specification http://ns.useplus.org
[ISO-4217] ISO 4217 currency and funds name and code elements http://www.currency-iso.org/iso_index/iso_tables.htm
[BCP-47] Tags for Identifying Languages. IETF Best Current Practice, September 2009 http://www.rfc-editor.org/rfc/bcp/bcp47.txt
[ISO-8601] ISO 8601 – Representation of dates and times http://www.iso.org/iso/date_and_time_format
[P3P] The Platform for Privacy Preferences 1.0 (P3P1.0) Specification. W3C Recommendation 16 April 2002http://www.w3.org/TR/P3P/
[W3CXMLSCHEMA] XML Schema Part 2: Datatypes Second Edition. W3C Recommendation 28 October 2004http://www.w3.org/TR/xmlschema-2/