ODRL Best Practices

Prefix	Namespace	Description
odrl	http://www.w3.org/ns/odrl/2/	ODRL Vocabulary
rdf	http://www.w3.org/1999/02/22-rdf-syntax-ns#	[[!rdf11-concepts]]
rdfs	http://www.w3.org/2000/01/rdf-schema#	[[!rdf-schema]]
owl	http://www.w3.org/2002/07/owl#	[[!owl2-overview]]
xsd	http://www.w3.org/2001/XMLSchema#	[[!xmlschema11-2]]
skos	http://www.w3.org/2004/02/skos/core#	[[!skos-reference]]
dcterms	http://purl.org/dc/terms/	[[dcterms]]
vcard	http://www.w3.org/2006/vcard/ns#	[[vcard-rdf]]
foaf	http://xmlns.com/foaf/0.1/	[[foaf]]
schema	http://schema.org/	schema.org
cc	https://creativecommons.org/ns#	creativecommons.org
ex	http://example.com/ns#

Examples of use

ODRL is a structured language to express rhat something is permitted, forbidden or obliged, possibly limited by some constraints. ODRL is of particular interest for representing computer policies, licenses and any document where deontic modalities need to have a digital form. ODRL was specified considering 27 use cases, nonetheless a few examples of use follow.

Example 1: Representation of common licenses

The use of common licenses has become popular among those publishing software, data, photographs and other resources online. These text licenses describe under which conditions the resource can be used. Examples of licenses are the GNU General Public License, the Creative Commons CC-BY 4.0 license, or the UK Open Government License. The key information in these text documents (waived rights, constraints, prohibitions and obligations) can be represented in a structured language (they have been actually represented in RDF, for example see the latter). ODRL can also be used to describe the core information in the licenses. Having the licensing information in a digital form enables:

Search-by-license. If resources are published along with an ODRL license, applications can be developed that perform a search-by-license, where one of the fields in a search form is the type of license of the resource, or the presence of a specific right or obligation (e.g. give me photos of Rome that I can publish in commercial applications ).
License compatibility. Some works are created as a derivation of two existing works. The licenses of the reused works can limit the license of the composite work, and even certain licenses are incompatible cannot be used in resources bundled together. The digital expression of rights favours smart applications to reason on license compatibility.
Reducing the impact of license proliferation. Even if the number of licenses has not stopped growing, having an ODRL version of non-famous licenses would enable their renderization using visual elements to make the license understandable in a glimpse.

Example 2: Representation of access policies to digital resources

Computer policies govern the access to digital resources. Whereas ODRL provides no mechanism whatsoever to implement any access control logic, ODRL policies can describe how an external access control system should behave. Advantages of having an ODRL representation of access policies:

Neutrality. ODRL is completely neutral about the technology used (if any) to grant access to a certain resource.
Extendability. New allowed actions and new constraints can be created. They can be arranged in a hierarchical form.

Example 3: Representation of rights in rules

Even if ODRL is not capable of accessing the subtleties of legislation, the actions that are forbidden in a certain sorts of noms can be represented in ODRL and act as a summary. See UC4. Advantages of an ODRL representation:

Summarization. Key actions that are prohibited or permitted are captured in an ODRL policy hance favoring summarization.
Compliance checking. Business processes can be determined as compliant or non-compliant.

While ODRL can represent elements of a license or regulation for machine consumption, it cannot replace them in court! It is best practice to explicitly point to the license or regulation that a policy models using the dc:terms property provided by the Dublin Core Metadata Initiative.

Sample policies

1 How to Represent a General Permission

The following ODRL policy might be read as "Movie 9898 can be used".

Example 1.0

00  {
01	 "@context": "http://www.w3.org/ns/odrl.jsonld",
02	 "@type": "Set",
03	 "uid": "http://example.com/policy:1010",
04	 "permission": [{
05 		"target": "http://example.com/asset:9898.movie",
06 		"action": "use"
07	 }]
08  }

Explanation line by line:

An ODRL policy is represented as a JSON Object (lines 00 and 08). In particular, ODRL policies can be represented in JSON-LD -a lightweight Linked Data format.
The context of the JSON-LD policy is, as in every ODRL policy, http://www.w3.org/ns/odrl.jsonld (see line 01).
Type odrl:Set means this is positive assertion. Somebody affirms that Movie 9898 can be used (line 02).
The policy is identified as http://example.com/policy:1010. ODRL policies are best identified with URIs (see line 03).
ODRL policies have one or more rules: permissions, obligations, prohibitions (line 04). You may want to see the main ODRL diagram.
The target of the policy is the resource referenced by http://example.com/asset:9898.movie, probably a movie (line 05). Assets are best identified with URIs.
The permitted action on the asset is use (line 06). You may want to read its definition, or browse other possible actions predefined by the ODRL specs.

1.1 How to restrict the permission to a specified party

If the example above permitted the general use of Movie 9898, this permission permits only John to play the movie.

Example 1.1

{
 "@context": "http://www.w3.org/ns/odrl.jsonld",
 "@type": "Set",
 "uid": "http://example.com/policy:1010",
 "permission": [{
 	"target": "http://example.com/asset:9898.movie",
	"assignee": "John",
	"action": "play"
 }]
}

1.2 How to restrict the validity of a permission to a specific circumstance or set of circumstances

Photographs are often licensed on a geographic basis: global rights will likely be more expensive than a country-specific permission. Such conditions are frequently modelled in ODRL by Constraints.

Example 1.2A

{
 "@context": "http://www.w3.org/ns/odrl.jsonld",
 "@type": "Set",
 "uid": "http://example.com/policy:1010",
 "permission": [{
 	"target": "http://example.com/asset:9898.movie",
	"action": "display",
	"constraint": [{
           "leftOperand": "spatial",
           "operator": "eq",
           "rightOperand":  "https://www.wikidata.org/wiki/Q183",
	   "comment": "i.e Germany"
       }]
 }]
}

Photographs for the news media can sometimes be "embargoed" - only publishable after a certain data. We can achieve this by putting a time-Constraint on the Permission.

The following permission can only be exercised after the turn of the New Year in 2019.

Example 1.2B

{
 "@context": "http://www.w3.org/ns/odrl.jsonld",
 "@type": "Set",
 "uid": "http://example.com/policy:1010",
 "permission": [{
 	"target": "http://example.com/asset:9898.movie",
	"action": "display",
	"constraint": [{
           "leftOperand": "dateTime",
           "operator": "gt",
           "rightOperand":  { "@value": "2019-01-01", "@type": "xsd:date" }
       }]
 }]
}

We can easily create a permission that only allows the picture to be displayed in Germany after 2018 by adding both Constraints. In this simple scenario ODRL insists both Constraints are satisfied before the Permission becomes active.

Example 1.2C

{
 "@context": "http://www.w3.org/ns/odrl.jsonld",
 "@type": "Set",
 "uid": "http://example.com/policy:1010",
 "permission": [{
 	"target": "http://example.com/asset:9898.movie",
	"action": "display",
	"constraint": [{
           "leftOperand": "dateTime",
           "operator": "gt",
           "rightOperand":  { "@value": "2019-01-01", "@type": "xsd:date" }
	   }, {
           "leftOperand": "spatial",
           "operator": "eq",
           "rightOperand":  "https://www.wikidata.org/wiki/Q183",
	   "comment": "i.e Germany"
       }]
 }]
}

2 How to refine the specification of an Action, Asset, or Party

Constraints can also be used to 'inject' additional semantics into the definition of an Action, Asset, or Party

2.1 Narrowing the applicability of an Action

The following Permission allows the distribution of a video but resticts the delivery channel to mobile networks only. This video cannot be distributed from a website under this Permission.

Example 2.1

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Set",
    "uid": "http://example.com/policy:6161",
    "permission": [{
       "target": "http://example.com/asset:9898.movie",
       "assigner": "http://example.com/org:616",
       "action": [{
          "action": "distribute",
          "refinement": [{
             "leftOperand": "deliveryChannel",
             "operator": "eq",
             "rightOperand": "http://example.com/cv/audMedia/MOBILE"
          }]
      }]
   }]
}

2.2 Further specifying an Asset

In financial markets the value of a piece of data is sometimes proportional to its timeliness. 15-minute delayed stock price is often much cheaper than real-time. We'd probably want different permissions to reflect this. How would we specify the 15 minute delay?

We could model them as two different Assets. Or we could use Constraints on the same Asset, the stock price:

2 How to represent an obligation

Example 3 shows how to oblige John to play the movie.

Example 3

{
 "@context": "http://www.w3.org/ns/odrl.jsonld",
 "@type": "Set",
 "uid": "http://example.com/policy:1010",
 "obligation": [{
	"target": "http://example.com/asset:9898.movie",
	"assignee": "John",
	"action": "play"
 }]
}

3 How to represent a prohibition

Example 4 shows how to prohibit John playing the movie.

Example 4

{
 "@context": "http://www.w3.org/ns/odrl.jsonld",
 "@type": "Set",
 "uid": "http://example.com/policy:1010",
 "prohibition": [{
	"target": "http://example.com/asset:9898.movie",
	"assignee": "John",
	"action": "play"
 }]
}

4 How to represent a permission and a prohibition

An ODRL can represent one or more rules. For example, the following ODRL policiy might be read as "Alice can use Asset 1, but Bob can't".

Example 5

{
	"@context": "http://www.w3.org/ns/odrl.jsonld",
	"@type": "Set",
	"uid": "http://example.org/policy/5",
	"permission": [{
		"target": "http://example.com/asset/1",
		"assignee": "http://example.com/party/Alice",
		"action": "use"
	}],
	"prohibition": [{
		"target": "http://example.com/asset/1",
		"assignee": "http://example.com/party/Bob",
		"action": "use"
	}]
}

5 How to simplify policies with more than one rule

ODRL policies with more than one rule can be simplified (Section 2.7.1 in the Information Model). Elements common to every rule can be expressed at root lovel. Policies making use of this feature are called compact policies, an example of them follows.

Example 6

{
	"@context": "http://www.w3.org/ns/odrl.jsonld",
	"@type": "Set",
	"uid": "http://example.org/policy/5",
	"action": "use",
	"target": "http://example.com/asset/1",
	"permission": [{
		"assignee": "http://example.com/party/Alice",
	}],
	"prohibition": [{
		"assignee": "http://example.com/party/Bob",
	}]
}

6 How to represent an agreement and an offer

All the examples above declared that there existed a certain permission, prohibition or obligation. Example 7 shows ....

Example 7

{
 "@context": "http://www.w3.org/ns/odrl.jsonld",
 "@type": "Set",
 "uid": "http://example.com/policy:1010",
 "prohibition": [{
	"target": "http://example.com/asset:9898.movie",
	"assignee": "John",
	"action": "play"
 }]
}

7 How to generalize actions

Permitting (or prohibiting) some general actions entail permitting (or prohibitting) other specific actions. In the example below, permitting display is redundant because having permitted play also implies permitting display.

Example 8

{
	"@context": "http://www.w3.org/ns/odrl.jsonld",
	"@type": "Set",
	"uid": "http://example.org/policy/5",
	"permission": [{
		"assignee": "http://example.com/party/Alice",
		"action": [ "play", "display" ],
		"target": "http://example.com/asset/1"
	}]
}

The figure represents these dependencies.

Actions in the ODRL Core Vocabulary (and how they are dependant) Also, one action in the profile may declare that some other actions are necessary for their execution (using :implies), hence if the former is permitted the latter cannot be prohibited. Although the actions in the ODRL Core Vocabulary do not have these implications, and although the actions in the ODRL Core Vocabulary are hardly dependent from each other, this may be of interest if you some day want to define your own actions.

92. Representing ODRL with RDF Turtle (I)

JSON-LD is only one of the possible serializations of ODRL a policy. The following example shows the same policy as in Example 1 but in RDF Turtle. It can also be XML. An ODRL policy is an instance of the class odrl:Policy, which is defined in the ODRL Ontology. No knowledge on the ODRL Ontology is needed if you want to use ODRL. Example 1 and Example 2 have the same meaning.

Example 2

@prefix odrl: <http://www.w3.org/ns/odrl/2/>

<http://example.org/policy/1> a odrl:Policy, odrl:Set ;
  odrl:permission [
    odrl:target <http://example.com/asset/1> ;
    odrl:assignee <http://example.com/party/Alice> ;
    odrl:action odrl:use
  ] ;

93. Representing ODRL with RDF Turtle (II)

As per RDFS entailment rule rdfs2, the class of the policy resource odrl:Policy can be inferred, hence its specification is not necessary. As per the ODRL Information Model (2.1.1 Set Class), Set is the default type of policy, hence its specification is not necessary. The policy shown in Example 3 is also equivalent to the policies in Example 1 and Example 2 (odrl prefix declaration has also been removed for clarity).

Example 3a

<http://example.com/policy:1010> odrl:permission [
  odrl:target <http://example.com/asset:9898.movie> ;
  odrl:action odrl:use
] ;

Alternative forms for the same policy are also possible. For example, one might want to attribute a certain policy to a certain asset. As specified in the ODRL Information Model, the following code would be equivalent. The RDF triple in line 02 of Example 3b may be stored in a content repository, whereas lines 03 through 06 may be stored in a license repository.

Example 3b

01 @prefix dct: <http://purl.org/dc/terms/> 
02 <http://example.com/asset:9898.movie> odrl:hasPolicy <http://example.com/policy:1010> .
03 <http://example.com/policy:1010> odrl:permission [
04   odrl:target <http://example.com/asset:9898.movie> ;
05   odrl:action odrl:use
06 ] ;

94. Representing ODRL with RDF Turtle (III)

Example XXX shows a second example, equivalent to Example 2.

Example XXX

<http://example.org/policy/5> odrl:permission [
  odrl:target <http://example.com/asset/1> ;
  odrl:assignee <http://example.com/party/Alice> ;
  odrl:action odrl:use
 ];
 odrl:prohibition [
   odrl:target <http://example.com/asset/1> ;
   odrl:assignee <http://example.com/party/Bob> ;
   odrl:action odrl:use
 ].

Example XXX shows a second example, equivalent to Example 3.

Example XXX

<http://example.org/policy/5> 
  odrl:target <http://example.com/asset/1> ;
  odrl:action odrl:use ;
  odrl:permission [
    odrl:assignee <http://example.com/party/Alice> ;
  ];
  odrl:prohibition [
   odrl:assignee <http://example.com/party/Bob> ;
  ].

Sample ODRL policies

This section provides some sample ODRL policies.

The policies in this file has been used to evaluate some test cases.

ODRL policies can represent the key content in instance licenses. As an example, the representation of the W3C Software and Document Notice and License follows. Please do note that the W3C Consortium does not endorse nor recommend this representation, which is only an effort of the editors of this document to illustrate how ODRL policies could represent textual licenses.

Example 1

@prefix cc: <http://creativecommons.org/ns#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix odrl: <http://www.w3.org/ns/odrl/2/> .

<http://purl.org/NET/rdflicense/W3C1.0>
a odrl:Policy ;
rdfs:label "W3C Software Notice and License" ;
dct:source <https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document> ;
dct:hasVersion "1.0" ;
dct:language <http://www.lexvo.org/page/iso639-3/eng> ;
dct:publisher "W3C" ;
odrl:permission
[
odrl:action odrl:distribute , odrl:modify , odrl:reproduce
odrl:duty
[
odrl:action cc:Notice , cc:ShareAlike
] ;
] ;
cc:legalcode """
License
By obtaining and/or copying this work, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions.

Permission to copy, modify, and distribute this work, with or without modification, for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the work or portions thereof, including modifications:

The full text of this NOTICE in a location viewable to users of the redistributed or derivative work.
Any pre-existing intellectual property disclaimers, notices, or terms and conditions. If none exist, the W3C Software and Document Short Notice should be included.
Notice of any changes or modifications, through a copyright statement on the new code or document such as "This software or document includes material copied from or derived from [title and URI of the W3C document]. Copyright © [YEAR] W3C® (MIT, ERCIM, Keio, Beihang)."
Disclaimers
THIS WORK IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE OR DOCUMENT WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE SOFTWARE OR DOCUMENT.

The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to the work without specific, written prior permission. Title to copyright in this work will at all times remain with copyright holders.

Notes
This version: http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document

Previous version: http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231

This version makes clear that the license is applicable to both software and text, by changing the name and substituting "work" for instances of "software and its documentation." It moves "notice of changes or modifications to the files" to the copyright notice, to make clear that the license is compatible with other liberal licenses.
"""@en .

Introduction

Document Conventions