Proposed Update to Common Vocabulary that includes changes to Constraint model and Payment action
New terms added: license
For detailed changes from Final Specification, see the HTML Differences Report
Draft Specification: 18 Feb 2013
- Renato Iannella, Semantic Identity, risemanticidentity.com
- Susanne Guth, Vodafone, susanne.guthvodafone.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 firstname.lastname@example.org (see Public Archive).
Copyright © 2012 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.
- 1. Overview
- 2. ODRL Common Vocabulary
- 3. Profiles (Informative)
The ODRL policy language has benefited from a robust underlying information model that has captured its semantics and provided extensibility paths for various communities. The Common Vocabulary specifies the terms (vocabulary) used by the Core Model [ODRL-MODEL] for policy expression needs.
The Common Vocabulary includes additional semantics and meets requirements gathered from the wider community, the latest research on access control, obligation management, privacy, social networks, publishers, as well as the past experiences in implementations and research of ODRL. The complete requirements for the Version 2.0 Model 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 also Section 3 Profiles ) 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 Namespace URI for the ODRL Version 2.0 Common Vocabulary is defined as:
This Namespace URI must be used in all encodings of ODRL policies to refer to the ODRL Common Vocabulary terms. The Namespace URI uniquely identifies the ODRL Common Vocabulary term by appending the identifier of that term. In some cases the vocabulary term may have two (or more) identifiers in which case they are considered semantically equivalent (ie synonyms).
For example, below are the target and play terms:
2.1 Policy Types
Vocabulary terms in this section may be used as the “type” of the Policy Entity.
|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.|
|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).|
Vocabulary terms in this section may be used as the “name” of the Action entity for Permissions, Prohibitions , and Duties.
|acceptTracking||The act of accepting that the use of the asset may be recorded||The collected information may be tracked by the assigner, or may link to a Party with role function “trackingParty”.|
|adhocShare||The act of sharing the asset to parties in close proximity to the owner||This action may be used to express [OMA] Sharing semantics.|
|aggregate||The act of using the asset (or parts of it) as part of a composite collection|
|annotate||The act of adding notations/commentaries to the asset||A new asset is created including the annotations.|
|anonymize||The act of anonymising the asset||For example, to remove identifying particulars for statistical or other purposes.|
|append||The act of adding to the end of an asset||For example, the ability to add record to a database (the asset)|
|archive||The act of persistently storing the asset||Constraints may be used for temporal conditions.|
|attachPolicy||The act of keeping the policy notice with the asset||May link to an Asset which is the Policy to attach. This action may be used to express [CC] Sharing semantics.|
|attachSource||The act of attaching the source of the asset and its derivatives||May link to an Asset which represents the source of the asset. This action may be used to express [CC] Source Code semantics.|
|attribute||The act of attributing the asset to a party.||Typically used as a Duty. May link to an Asset with the attribution information. May link to a Party with role function “attributedParty”.|
|concurrentUse||The act of multiple concurrent use of the asset||This action may be used to express [ONIX] Concurrent Users semantics.|
|commercialize||The act of using the asset in a business environment||The asset may be traded for profit.|
|The act of making an exact reproduction of the asset||This action may be used to express [CC] Reproduction semantics.|
|delete||The act of permanently removing the asset||When used as a Duty means all copies removed.|
|The act of creating a new derivative asset from the asset||This action may be used to express [CC] Derivative works semantics.|
|digitize||The act of digitizing the asset from its original form||Typically, the original asset would be in analogue form.|
|The act of making a transient visible rendering of the asset||For example; displaying an image on a screen.|
|distribute||The act of publicly distributing, displaying and/or performing the asset||This action may be used to express [CC] Distribution semantics.|
|ensureExclusivity||The act of requiring the Assigner to ensure the Permission on the asset is unique to the Assignee||Typically used as a Duty in which the Assigner is the same as the Assignee and is obliged to ensure the Permission granted is exclusive.|
|The act of executing the asset||For example; machine executable code or Java such as a game or application.|
|The act of transforming the asset into a new form||Typically used to convert the asset into a different format for consumption/transfer on a third-party system and may also include the conversion of the policy.|
|extract||The act of extracting (replicating) unchanged parts of the asset||For reuse along with, or within, another asset, or to stand alone.This action may be used to express [ONIX] Copy/Paste semantics.|
|extractChar||The act of extracting (replicating) unchanged character(s) from the asset||This action may be used to express [ONIX] CopyPaste Character semantics.|
|extractWord||The act of extracting (replicating) unchanged word(s) from the asset||This action may be used to express [ONIX] CopyPaste Word semantics.|
|extractPage||The act of extracting (replicating) unchanged page(s) from the asset||This action may be used to express [ONIX] CopyPaste Page semantics.|
|give||The act of giving away the asset in perpetuity without exchange of value||Ownership is transferred to the recipient. The original asset must be deleted by the owner.|
|include||The act of including other related assets to fulfill the function||For example; Bio picture must be included in the attribution. Use of the Asset relation attribute is required.|
|index||The act of indexing the asset into a collection of assets||For example; to include the asset in a search engine database.|
|inform||The act of informing a party that an action has been performed on the asset||Typically used as a Duty. May link to a Party with role function “informedParty”.|
|install||The act of loading the asset onto storage device ready for operation|
|lease||The act of making available the asset to a third-party for a fixed period of time with exchange of value||During this period, the asset is only available by the third-party. Temporal constraints may be used. Next Policy is recommended for the third-party.|
|lend||The act of making available the asset to a third-party for a fixed period of time without exchange of value||During this period, the asset is only available by the third-party. Temporal constraints may be used. Next Policy is recommended for the third-party.|
|license||The act of granting the right to use the asset to a third-party||This action enables the assignee to create policies for the use of the asset for third-parties. Use of Next Policy to express any downstream constraints is recommended.|
|move||The act of moving the asset||After the asset has been moved, the original copy must be deleted.|
|nextPolicy||The act of specifying an asset (which must be a Policy) as the Policy terms for third-party use of the asset||Typically used as a Duty to indicate the policy terms for downstream use of the asset. If the asset is modified (eg translated) as an outcome of the original Policy, then the Next Policy applies to the derived asset.|
|obtainConsent||The act of requiring explicit consent from a party to perform the action on the asset||Typically used as a Duty for the asset owners to decide on a case-by-case basis. May link to a Party with role function “consentingParty”.|
|pay||The act of paying a financial amount to a party for use of the asset||The payAmount constraint may be used to indicate the amount of the payment. The Payer is the Assignee and the Payee is the Assigner of the policy or, if specified, a new Party with role function “payeeParty”.|
|The act of rendering the asset into audio and/or video form||For example; playing a movie file.|
|preview||The act of providing a short preview of the asset||For example; the first 5 minutes of a movie.|
|The act of rendering the asset onto paper or hard copy form||For example; creating a permanent, fixed (static), and directly perceivable representation of the asset.|
|read||The act of obtaining data from the asset||For example, the ability to read a record from a database (the asset)|
|reviewPolicy||The act of performing a manual review of the terms associated with the asset||Used when human intervention is required to review the policy. May link to an Asset which represents the policy information.|
|secondaryUse||The act of using the asset for a purpose other than the purpose it was intended for||For example, for marketing or profiling purposes.|
|shareAlike||The act of distributing any derivative asset under the same terms as the original asset||This action may be used to express [CC] Share-a-like semantics.|
|sell||The act of trading the asset in exchange of value||Next Policy is recommended for the third-party|
|share||The act of the non-commercial reproduction and distribution of the asset to third-parties||This action may be used to express [CC] Sharing semantics.|
|textToSpeech||The act of a system reading the text of the asset out loud||This action may be used to express [ONIX] Text to Speech semantics.|
|translate||The act of translating the asset into a new natural language||A new asset is created.|
|uninstall||The act of unloading the asset from storage device||The asset is not longer accessible.|
|watermark||The act of applying a watermark to the asset||A linked asset may indicate the watermark to apply.|
|write||The act of writing to the asset||For example, the ability to write a record to a database (the asset)|
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).
Vocabulary terms in the below table may be used as the attribute “name” of the Constraint Entity.
|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 This action may be used to express [ONIX] Times semantics.|
|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:
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.|
|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.|
|proximity||An value indicating the closeness or nearness||This may be used to express [OMA] Proximity semantics.|
|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.|
|timedCount||The number of seconds after which timed metering use of the asset begins||The default value is 0 seconds. This may be used to express [OMA] Timed-Count semantics.|
|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.|
|system device||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|
Vocabulary terms in the below table may be used as attribute in the attribute “operator” of the Constraint Entity.
|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 Party and Role
For the Role entity, the Function and Scope attributes may be used for specific details undertaken by the identified Party in the policy.
Vocabulary terms in the below table may be used as the attribute “function” of the Role Entity.
|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.|
|payeeParty||The Party is the recipient of the payment||May be specified as part of the pay 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.
Vocabulary terms in the below table may be used as the attribute “scope” of the Role Entity.
|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 Asset and Relation
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.
|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.
3. Profiles (Informative)
The ODRL Core Model and Common Vocabulary represent the basic needs for policy expressibility. As a result, different communities will require less or more terms from the Common Vocabulary. Community Profiles that extend the ODRL Core Model or Common Vocabulary are expected to be developed that adequately document these changes in respect to the Common Vocabulary. Some requirements of this process include:
- Document any additions to the Core Model and Common Vocabulary.
- Document which aspects of the Core Model or Common Vocabulary are not being used (deprecated)
- Declare your communities namespace (see Encoding specifications)
- Share the Community Profile with the ODRL Initiative for feedback and comments
The editors gratefully acknowledge feedback and contributions to this document from:
- All members of the Version 2.0 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
|[ODRL-MODEL]||R. Iannella & S. Guth & D. Paehler & A. Kasten (eds). Open Digital Rights Language (ODRL) Version 2.0 – Core Model. Final Specification, W3C ODRL Community Group. http://www.w3.org/community/odrl/two/model/|
|[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|
|[OMA]||Open Mobile Alliance (OMA) Digital Rights Management V2.1 http://www.openmobilealliance.org/Technical/release_program/drm_v2_1.aspx|
|[CC]||Creative Commons Initiative Licenses http://creativecommons.org/about/licenses/|
|[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/|
|[ONIX]||ONIX for Books – Release 3.0. EDItEUR, April 2009http://www.editeur.org/93/Release-3.0-Downloads/|
- 12 April, 2013 @ 4:19 [Current Revision] by Renato Iannella
- 12 April, 2013 @ 4:17 by Renato Iannella
- 18 March, 2013 @ 0:11 by Renato Iannella
- 18 March, 2013 @ 0:10 by Renato Iannella
- 18 March, 2013 @ 0:09 by Renato Iannella
- 18 February, 2013 @ 1:23 by Renato Iannella
- 18 February, 2013 @ 0:46 by Renato Iannella
- 18 February, 2013 @ 0:32 by Renato Iannella
- 22 January, 2013 @ 4:44 by Renato Iannella
- 22 January, 2013 @ 3:08 by Renato Iannella
- 22 January, 2013 @ 3:08 by Renato Iannella