The ODRL permissions and obligations expression language provides a flexible and interoperable information model, vocabulary, and encoding mechanisms for describing statements about digital content usage. The ODRL Vocabulary and Expression describes the terms used in such statements and how to encode them.
Status of This Document
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a work in progress. No section should be considered final, and the absence of any content does not imply that such content is out of scope, or may not appear in the future. If you feel something should be covered, please tell us.
Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. 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.
The ODRL Vocabulary and Expression defines a set of concepts and terms (the vocabulary) and encoding mechanism (the expression) for permissions and obligations statements describing digital content usage based on the ODRL Information Model [odrl-w3c-model].
2. Relationship to the W3C ODRL Community Group Reports
The basis for the deliverables for the Permissions & Obligations Expression Working Group are the reports created by the W3C ODRL Community Group. The ODRL Community Group has developed a family of specifications to support innovative expression of digital asset usage for the publication, distribution and consumption of content services. The final outputs of the ODRL Community Group were the Version 2.1 specifications that were a major update for ODRL and superseded the original ODRL Version 1.1 [odrl] (published as a W3C NOTE)
The following documents are part of the ODRL Community Group report series:
The ODRL Vocabulary and Expression was derived from the combination and merger of four of the ODRL Community Group's outcomes; ODRL V2.1 Common Vocabulary, ODRL V2.1 XML Encoding, ODRL V2.1 Ontology, and ODRL V2.1 JSON Encoding. Details of the differences between the W3C Working Group deliverables and the ODRL Community Group Reports are maintained in the Appendix. All new ODRL implementations are expected to use the deliverables of the W3C Permissions & Obligations Expression Working Group.
3. Conformance
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MUST, OPTIONAL, and REQUIRED are to be interpreted as described in [RFC2119].
4. Vocabulary
The Namespace URI to identify the ODRL model and vocabulary terms is: http://www.w3.org/ns/odrl/2/
Above figure will be updated to match the vocabulary term groupings.
The detail for each ODRL Vocabulary term is shown below in the two tables. The left table shows the normative semantic description of the concept, and the right table the ontological description and relationships.
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.
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.
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.
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.
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).
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.
Use is the most generic action for all non-third-party usage. 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.
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.
For example, to remove identifying particulars for statistical or for other comparable purposes, or to use the asset without stating the author/source.
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.
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.
The Assigner permits/prohibits the Assignees to transfer the ownership of the Asset to a third party without compensation and while deleting the original asset.
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).
The Assigner permits/prohibits the Assignees to transfer the ownership of the Asset to a third party with compensation and while deleting the original asset.
The Assigner requires that the Assignees 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: (i) the thing is expressed by the value (term) of the Constraint name; (b) the value is expressed by operator, rightOperand, dataType and unit
The Assigner requires that the Assignees 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”.
Do not use the right-operand property directly within a Constraint. Instead, a Constraint instance must contain exactly one triple which makes use of one of the sub-properties of right-operand.
For example, asset may be used at the “FIFA World Cup” only. To express events related to undertaking Duties, specific event values may be defined (eg see policyUsage).
For example, JPEG image may only be reproduced with Spanish text. May be used to express [[plus] semantics. Must use [bcp47] codes for language values.
Maybe used for compensation duties. The dataType attribute may be used to indicate the type of the value (eg decimal) and the unit attribute to indicate the currency.
The code value and code source must be represented. For example, the [iso3166] Country Codes or the Getty Thesaurus of Geographic Names. A URI should be used to represent this value.
The Party entity can be any form of identifiable entity, such as a person, group of people, organisation, or agent. An agent is a person or thing that takes an active role or produces a specified effect. To describe more details about the Party, it is recommened to use vCard [vcard-rdf] or [foaf] metadata.
The Asset entity can be any form of identifiable resource, such as data/information, content/media, applications, or services. Furthermore, it can be used to represent other Asset entities that are needed to undertake the Policy expression, such as with the Duty entity. To describe more details about the Asset, it is recommened to use Dublin Core [dcterms] elements or other content metadata.
The ODRL statements can be encoded in XML [xml] defined by XML Schema [xmlschema11-1] and XML Datatypes [xmlschema11-2]. All of the URIs used in ODRL XML instances MUST follow those defined in the ODRL Vocabulary.
The complete ODRL XML Schema is shown in the Appendix. and can be downloaded.
To enable compact URIs, this encoding also supports the use of Qualified Names (QNames) [xml-names] for the specification of the value identifiers. In addition, Qualified Codes (QCodes) [news-ml] may also be used for vocabulary values. QCodes are similar to QNames but also allow a digit as the first character of the value.
Each of the core entities (UML Classes) from the ODRL Information Model [odrl-w3c-model] will be represented by an XML element of the same name. Additionally, each entity attribute will be represented as an XML attribute of the parent element. The fixed values defined in the Model are represented as enumerated types. Cardinalities are also represented with XML Schema occurrence rules. Attributes are optional unless explicitly noted as REQUIRED.
The Policy element contains the following attributes:
uid – a URI/Qname/Qcode (REQUIRED)
type – a URI/Qname/Qcode (REQUIRED)
conflict – fixed enumeration (defined in XML Schema)
undefined – fixed enumeration (defined in XML Schema)
inheritAllowed – a boolean
inheritFrom – a URI/Qname/Qcode
inheritRelation – a URI/Qname/Qcode
profile – a URI/Qname/Qcode
The Policy element may contain the following elements:
permission, and/or
prohibition
Note that under the ODRL Information Model context rules there MUST be at least one Permission in the complete ODRL Policy taking into account any Profile and Inheritance requirements.
The Asset and Relation association class are merged into a single Asset element to represent both the Asset and how it is related to the Permission/Prohibition/Duty. The Asset element contains the following attributes:
uid – a URI/Qname/Qcode
relation – a URI/Qname/Qcode
id – an local identifier for this element
idref – a reference to an Asset element
Asset element attributes MUST be used as defined by one of the sets of attributes and their cardinalities below:
uid (REQUIRED), relation (REQUIRED), id (OPTIONAL), or
idref (REQUIRED)
The Party and Role association class are merged into a single Party element to represent both the Party and the role to the Permission/Prohibition/Duty. The Party element contains the following attributes:
uid – a URI/Qname/Qcode
function – a URI/Qname/Qcode
scope – a URI/Qname/Qcode
id – an local identifier for this element
idref – a reference to a Party element
Party element attributes MUST be used as defined by one of the sets of attributes and their cardinalities below:
uid (REQUIRED), function (REQUIRED), scope (OPTIONAL), id (OPTIONAL), or
idref (REQUIRED)
The Permission element contains the following elements:
asset – (REQUIRED)
action – (REQUIRED)
constraint
party
duty
The Prohibition element contains the following elements:
asset – (REQUIRED)
action – (REQUIRED)
constraint
party
The Duty element contains the following elements:
action – (REQUIRED)
constraint
asset
party
The Duty element contains the following attributes:
uid – a URI/Qname/Qcode
id – an local identifier for this element
idref – a reference to an Duty element
Duty element attributes MUST be used as defined by one of the sets of attributes and their cardinalities below:
uid (OPTIONAL), or
id (REQUIRED), or
idref (REQUIRED)
The Action element contains the following attribute:
name – a URI/Qname/Qcode
id – an local identifier for this element
idref – a reference to an Action element
Action element attributes MUST be used as defined by one of the sets of attributes and their cardinalities below:
name (REQUIRED), id (OPTIONAL), or
idref (REQUIRED)
The Constraint element contains the following attributes:
name – a URI/Qname/Qcode
operator – a URI/Qname/Qcode
rightOperand – string, space separated list for set values
dataType – a URI/Qname/Qcode
unit – a URI/Qname/Qcode
status – string
id – an local identifier for this element
idref – a reference to an Constraint element
Constraint element attributes MUST be used as defined by one of the sets of attributes and their cardinalities below:
name (REQUIRED), operator (REQUIRED), rightOperand (REQUIRED), dataType (OPTIONAL), unit (OPTIONAL), status (OPTIONAL), id (OPTIONAL), or
idref (REQUIRED)
In some cases where Duties refer to (external) Assets, it will be necessary to package the ODRL XML expression with the representation of that (external) Asset. This XML Encoding specification does not mandate any specific packaging mechanism as communities will utilise their preferred options for data interoperability.
5.2.1 XML Linking
To support repeating the same element content across Permissions and Prohibitions, the Asset, Party, Constraint, Action, and Duty elements support the xml id and idref attributes. Any of these element that has been identified using the id attribute can then be referred to by an element with the same name using the idref attribute. In this case, the referring element must have no other content.
As shown in the below example, the Prohibition refers to elements defined in the Permission, except for the Constraint element. In this case, the assignee can play the music asset in Italy but not in France.
Note that there is an important distinction when using this feature with the Duty element which also has the uid attribute. The uid attribute is used to refer to the same Duty from multiple Permissions. In this case the Duty has to be performed only once to gain access to all the Permissions. When using the id and idref attributes then the semantics change as in this case the Duty must be performed for each time it is referenced (potentially, many times). Note that the use of the uid and id attribute for the same Duty element is not permitted.
5.2.2 Inline Assets
In some scenarios, the Asset of an ODRL Policy maybe also be XML or HTML markup. In these specific cases, it makes sense to enable the ODRL Policy to be articulated as part of the Asset and to support abbreviated expressions. All default values should be assumed. The preferred method of linking is to utilise the XML ID attribute. The source Asset markup may be identified with an ID attribute and the ODRL Asset element can then refer to this ID as the UID (as a URI hash fragment). An example is shown below.
Example 2
<rnews:Articlexml:id="item8HEX"><rnews:title>Allies are Split<rnews:title><rnews:description>Rebel fighters take control...<rnews:description>
...
<o:Policyxmlns:o="http://www.w3.org/ns/odrl/2/"type="http://www.w3.org/ns/odrl/2/Set"uid="http://example.com/policy:ABAABA"><o:permission><o:assetuid="#item8HEX"/><o:actionname="http://w3.org/ns/odrl/vocab#distribute"/><o:constraintname="http://www.w3.org/ns/odrl/2/dateTime"operator="http://www.w3.org/ns/odrl/2/gteq"rightOperand="2011-11-11"/></o:permission></o:policy>
...
</rnews:Article>
5.3 JSON Encoding
This section describes how to encode both the ODRL Model and Vocabulary, including any community developed Profiles, using the JSON syntax [rfc4627] and using a JSON Schema [json-schema].
The complete ODRL JSON Schema is shown in the Appendix. and can be downloaded.
ODRL can express complex contracts and policies which may require quite sophisticated systems to evaluate contractual permissions, restrictions and duties. However, the ODRL in JSON encoding is designed to be lightweight and requires only standard JSON software to generate or parse the representation.
In order to make the JSON encoding of ODRL as natural as possible, certain terms which are represented in the ODRL Vocabulary as values become JSON properties. For example, both assigner and assignee are Role controlled vocabulary values of Party. However, in the JSON encoding, they are expressed as fully-fledged Properties. This contrasts with the XML encoding which has a Party element and a Role attribute.
Similarly, the Asset object has a Relation controlled vocabulary with values of target and output. The JSON encoding directly represents these as first-class properties.
The ODRL Model and Vocabulary is designed in this manner, in part, to allow for extensibility. In other words, it is possible to add additional types of Party or other kinds of Asset. The JSON ODRL Encoding allows for this by using patternProperties – for example, for additional types of Party or Scope.
Unlike XML, JSON doesn’t support the concept of namespaces. This means that property values need to be expressed using globally unique identifiers, in order to be unambiguous. Therefore, one key implementation decision for ODRL in JSON is to require that terms drawn from the ODRL Vocabulary or any ODRL profile (such as RightsML [rights-ml]) must be expressed using complete URLs. (This differs from the XML encoding of ODRL, which allows various short forms of URLs to be used, like QNames [xml-names] or QCodes [news-ml]).
All of the URIs used in ODRL JSON instances MUST follow those defined in the ODRL Vocabulary. This includes URIs for policy types, actions, operators, operands, functions, scopes, conflict handling terms, and unsupported action-handling terms.
5.3.1 A Note on JSON-LD
JSON-LD [json-ld] (JSON for Linked Data) is a method to convey Linked Data using JSON. It is a W3C Recommendation and it is a JSON syntax for RDF (similar to the RDF/XML and Turtle syntaxes for RDF). If you would prefer to use JSON-LD, it is recommended that you use the ODRL Ontology and appropriate software to parse and serialize the RDF triples using JSON-LD.
6. Scenarios - Encoding Examples
This section is non-normative.
6.1 Set
The following shows an instance of a setPolicy. The Set shows a policy expression, stating that the Assethttp//example.com/asset:9898 is the target of the Permissionreproduce and the Prohibition to modify. No parties or other elements are involved. This set could be used, for example, as a template or an instant license.
The following shows the instance of an offerPolicy. The offer contains the music file http//example.com/music:4545 that is offered by the Partyhttp//example.com/sony:10 with the Permissions to play and copy the file. The Permissioncopy is only granted once. The two Permissions are offered for a payment of AUD$0.50.
The following shows the instance of an agreementPolicy. The agreement contains all entities shown in the offer scenario above. A new Party element http//example.com/billie:888 has been added. This Party accepted the previous offer and thus is now the buyer of the Permissionplay and copy, i.e. is now linked as assignee of the Permissions and Duty entities.
The following shows the instance of a requestPolicy. The Partyhttp//example.com/guest:0589 has requested the Permission to display the targetAssethttp//example.com/news:0099.
The following shows the instance of a ticketPolicy. The ticket expresses the playPermission for the targetAssethttp//example.com/game:4589. The Ticket is valid until the end of the year 2010. Any valid holder of this ticket may exercise this Permission.
The following shows the instance of an offerPolicy showing the nextPolicy structure. The party http//example.com/sony:99 assigns the Permissiondistribute directly to the potential buyer of the permission who will pay $EU1,000. The distributePermission is also constrained to the country Italy. The potential assignee may then distribute the targetAsset according to the nextPolicytargetAsset linked directly from this Duty. In this case, the next Policy Asset stipulates that the potential assignee may only offer the displayPermission to downstream consumers.
The following shows the instance of an privacyPolicy.
The targetAsset is Personal Data and the assignee is allowed to distribute the Asset only for the purpose of contacting the subject of the Personal Data. The purpose value is taken from the P3P privacy purpose vocabulary.
Additionally, the assigner (the Party who the personal data is about) has stipulated that the assignee must delete the Asset after a 30 day period (retention policy).
The following shows the instance of an agreementPolicy with both a Permission and a Prohibition. The party http//example.com/sony:10 assigns the Permissionplay to the Partyhttp//example.com/billie:888 at the same time they are prohibited from utilising the targetAsset as a mobile:ringtone. Additionally, in case of any conflict, the conflict attribute is set to perm indicating that the Permission entity will take precedence.
The following shows the instance of a (child) Policyhttp//example.com/policy:9999 inheriting from another (parent) Policyhttp//example.com/policy:5531. The inheritFrom attribute of the (child) Policy has the same identifier as the (parent) Policy. In this inheritance example, the (parent) Policy allows the Partyhttp//example.com/billie:888 to print the (parent’s) targetAsset. The (child) Policy allows the Partyhttp//example.com/class:IT01 (a group of people) to display the (child’s) targetAsset. Since the (child) Policy also inherits from the (parent) Policy, then the Partyhttp//example.com/class:IT01 can also print the (parent’s) targetAsset.
The following shows the instance of an agreementPolicy for a Social Network scenario.
The targetAsset are photos posted to a Social Network site and the assigner is the owner of the photos. The assignee is a Partygroup and represents the football network members on the social network, who are each allowed to display the photos.