The Open Digital Rights Language (ODRL) provides a flexible and interoperable information model, vocabulary, and encoding mechanisms for describing statements about content usage. The ODRL Information Model describes the underlying concepts, entities, and relationships that form the foundational basis for the semantics of the ODRL statements.

Policies are used to explicitly state what are the permitted and prohibited actions over a certain resource. In addition, policies may be integrated with complex constraints (e.g., time constraints) which apply to such actions to impose further restrictions to the uses of the resource.

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.

Introduction

Several business scenarios require to express what are the permitted and prohibited actions over content. These permitted/prohibited actions are usually expressed under the form of policies, i.e., entities that allow to indicate those uses and re-uses of the content which are conformant with the existing regulations or to the constraints assigned by the owner. Policies may also be enriched with additional information, i.e., who are the entities in charge of the definition of such Policy and those who are required to conform to it, what are the additional constrains to be associated with the Permissions, Prohibitions and Duties expressed by the Policy. The ability to express these concepts and relationships is important both for the producers of content, i.e., they may state in a clear way what are the permitted and the prohibited actions to prevent misuses, and for the consumers, i.e., they may know precisely how they are allowed to use and re-use the content to avoid breaking the law or the owner's constraints. This specification describes a common approach to expressing these concepts, and more.

The ODRL Information Model defines the underlying semantic model for permission and obligation statements describing content usage. The information model covers the core concepts, entities and relationships that provide the foundational model for content usage statements. These machine-readable policies may be linked directly with the content they are associated to with the aim to allow consumers to easily retrieve those information.

Aims of the Model

The primary aim of the ODRL Information Model is to provide a standard description model and format to express permission and obligation statements to be associated to content in general. These permission and obligation statements are employed to describe the terms of use and reuse of resources. The model should cover as many Permission and Obligation use cases as possible, while keeping the policy modeling easy even when dealing with complex uses.

The ODRL Information Model is a single, consistent model that can be used by all interested parties. All efforts have been made to keep the implementation costs for both content producers and consumers to a minimum. A single method of fulfilling a use case is strongly preferred over multiple methods, unless there are existing standards that need to be accommodated or there is a significant cost associated with using only a single method. While the Information Model is built using Linked Data principles, the design is intended to allow non-graph-based implementations also.

The examples throughout the document are serialized as [[json-ld]]. For normative serialisations, including the JSON context, please refer to the ODRL Vocabulary and Expression [[!odrl-vocab]].

Terminology

Policy
A Rule expressing what Action is allowed and/or disallowed over an Asset.
Rule
A Permission, Prohibition, or Duty that expresses an Action that may, must not, or must be performed (respectively)
Action
An operation that is applicable to a Rule
Permission
An Action that may be performed over an Asset.
Prohibition
An Action that must not be performed over an Asset.
Duty
An Action that has been agreed to be performed as a requirement for the applicable Permission to become valid.
Asset
An identifiable resource that is the subject of a Rule
Party
An identifiable entity who may undertake a Role in a Policy
Constraint
The context, such as limitations, restrictions, or interpretations, that must be applied to an Action, Party, or Asset
ODRL Processor
A system that provides services that creates, manipulates, and validates ODRL Policy expressions.
ODRL Common Vocabulary
A set of generic terms that may be used with the ODRL core vocuabyulary to express Policies.
ODRL Profile
A community or sector specific vocabulary that extends the ODRL core vocabulary with new terms and/or ODRL Common Vocabulary terms to express Policies

ODRL Information Model

The ODRL Information Model represents Policies that express Permissions, Prohibitions and Duties related to the usage of Assets. The Information Model explicitly expresses what is allowed and what is not allowed by the Policy, as well as other terms, requirements, and parties involved. The aim of the ODRL Information Model is to enable flexible Policy expressions by allowing the policy author to include as much, or as little, detail in the Policies.

The figure below shows the ODRL Information Model.

ODRL Information Model
ODRL Information Model (Also available in PNG format)

The ODRL Information Model includes the following classes:

The ODRL Information Model includes two abstract properties between Rule and the Asset and Party class. These two properties (relation and function) are designed to represent the conceptual relation between the two classes. In serialised ODRL expressions, they MUST be realised as subtypes of their respective parent property. The figure below shows the ODRL Properties Model with subtypes.

ODRL Properties Model
ODRL Properties Model (Also available in PNG format)

The figure shows the relation property with subtype target to express that the Asset is the primary subject of the Rule. The function property has subtype assigner to express the Party issuing the Rule, and subtype assignee to express the recipient Party of the Rule.

The ODRL Information Model provides a logical view of the components of the Policy model. The implementable view of the ODRL Information Model is provided by various encoding serialisations as normatively described in the ODRL Vocabulary & Expression document [[odrl-vocab]]. The mapping of the logical Information Model components to the implementable serialisations may require some trade-offs and/or differences depending on the features supported by the serialisation language.

The following sections provide further details on the ODRL Information Model.

Policy Class

The Policy class has the following properties:

An ODRL Policy MAY be subclasssed to more precisely describe the context of use of the Policy that MAY include additional constraints that ODRL processors MUST understand. The Policy subclasses may be documented in the ODRL Common Vocabulary [[!odrl-vocab]] or in ODRL Profiles.

Set

An ODRL Policy of subclass Set represents any combination of Rules. The Set Policy subclass is also the default subclass of Policy (if none is specified).

An ODRL Policy of type Set MUST include at least one Rule.

Example Use Case: The below Set Policy includes the Permission to play the target Asset http//example.com/asset:9898.movie.

{
    "@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": "play"
    }]
}

For the examples in this document, the ODRL Policy subclasses are mapped to the JSON-LD @type tokens.

The above example could have also used Policy instead of Set.

Offer

An ODRL Policy of subclass Offer represents Rules that are being offered from assigner Parties. An Offer is typically used to make available Policies to a wider audience, but does not grant any Rules.

An ODRL Policy of type Offer:

  • MUST include at least one Permission or Prohibition.
  • MUST include at least one Party with assigner functional role.

Example Use Case: The below Offer Policy (based on the previous example) includes offering the Permission to play the target Asset http//example.com/asset:9898.movie from the assigner Party http://example.com/party:org:abc.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:1011",
    "permission": [{
        "target": "http://example.com/asset:9898.movie",
        "assigner": "http://example.com/party:org:abc",
        "action": "play"
    }]
}

Agreement

An ODRL Policy of subclass Agreement represents Rules that have been granted from assigner to assignee Parties. An Agreement is typically used to grant the terms of the Rules between the Parties.

An ODRL Policy of type Agreement:

  • MUST include at least one Permission or Prohibition.
  • MUST include at least one Party with assigner functional role.
  • MUST include at least one Party with assignee functional role.

Example Use Case: The below Agreement Policy (based on the previous example) includes granting the Permission to play the target Asset http//example.com/asset:9898.movie from the assigner Party http://example.com/party:org:abc for the assignee Party http://example.com/party:person:billie.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:1012",
    "permission": [{
        "target": "http://example.com/asset:9898.movie",
        "assigner": "http://example.com/party:org:abc",
        "assignee": "http://example.com/party:person:billie",
        "action": "play"
    }]
}

Has A Policy

The Policy class MAY also be referenced by the hasPolicy property. This supports ODRL Policies being the object of external metadata expressions (that describe an Asset). When hasPolicy has been asserted between a metadata expression and an ODRL Policy, the Asset being described/identified is then assumed to be the target Asset of the Policy.

Example Use Case: The below snippet shows some Dublin Core metadata describing a movie Asset. The odrl:hasPolicy property has been included to link to the ODRL Policy http://example.com/policy:1010 (this is the Set Policy described above). In this case, the Asset http://example.com/asset:9999.movie is now also the target Asset for the Policy http://example.com/policy:1010.

{
   ...
   "dc:publisher": "ABC Pictures",
   "dc:creator": "Allen, Woody",
   "dc:issued": "2017",
   "dc:subject": "Musical Comedy",
   "dc:identifier": "http://example.com/asset:9999.movie",
   "odrl:hasPolicy": "http://example.com/policy:1010",
   ...
}

Asset

An Asset is a resource that is the subject of a Rule. The Asset 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 classes that are needed to undertake the Policy expression, such as with a Duty. An Asset is referred to by the Permission and/or Prohibition, and also by the Duty.

The Asset class has the following properties:

The Asset class has two subclasses:

The AssetIndividual subclass is the default subclass of Asset (if none is specified).

Since ODRL Policies could deal with any kind of Asset, the ODRL Information Model does not provide additional metadata to describe Assets of particular media types. It is recommended to use existing metadata standards, such as Dublin Core Metadata Terms that are appropriate to the Asset type or purpose.

Relation

The abstract relation property is used to link a Rule to an Asset, indicating how the Asset MUST be utilised in respect to the Rule that links to it. The relation property is represented by explicit subtypes that indicate the semantics of the relationship between the Asset and the Rule.

The relation subtype of target MUST be supported. The target relation indicates that the Asset is the primary subject to which the Rule action directly applies.

Other relation subtype properties SHOULD be defined in the ODRL Common Vocabulary [[!odrl-vocab]] and ODRL Profiles.

Example Use Case: The assigner Party http//example.com/party:0001 offers to display the target Asset http://example.com/asset:3333. In this example, the Asset is assumed to be an AssetIndividual.

 {
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:3333",
    "permission": [{
        "target": "http://example.com/asset:3333",
        "action": "display",
        "assigner": "http://example.com/party:0001"
    }]
}

In the above example, the JSON-LD representation for the relation property directly uses target as the token, as this has been defined as a subtype of the parent relation property.

Example Use Case: The below Policy shows the index action Permission on the target Asset http://example.com/archive1011. The target asset is also declared as an AssetCollection to indicate the resource is a collection of resources. Another Asset relation ex:summary is also expressed to indicate the Asset http://example.com/x/database that the indexing ouput should be stored in. (These semantics would be defined by the community who created the ex:summary relation.)

 {
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:1011",
    "permission": [{
        "target": {
            "@type": "AssetCollection",
            "uid":  "http://example.com/archive1011" },
        "action": "index",
        "ex:collection": "http://example.com/x/database"
    }]
}

Party

A Party can be any form of identifiable entity who undertakes a role in a Rule, 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. The Party performs (or does not perform) Actions or has a function in a Duty (i.e., assigns the Party to the Rule by associating it with the function it plays in the Rule).

The Party class has the following properties:

The Party class has two subclasses:

The PartyIndividual subclass is the default subclass of Party (if none is specified).

The ODRL Information Model does not provide additional metadata for the Party class. It is recommended to use existing metadata standards, such as the W3C vCard Ontology [[vcard-rdf]] or FOAF Vocabulary [[foaf]].

Function

The abstract function property is used to link a Rule to a Party, indicating the function undertaken by the Party in respect to the Rule that links to it. The function property is represented by explicit subtypes that indicate the semantics of the functional role between the Party and the Rule.

The function property MUST support the following subtypes:

  • assigner: indicates the Party that is issuing the Policy. For example, the Party granting a Permission or requiring an agreed Duty to be performed.
  • assignee: indicates that the Party that is the recipient the Policy. For example, the Party being granted a Permission or required to perform an agreed Duty.

Other function subtype properties SHOULD be defined in the ODRL Common Vocabulary [[!odrl-vocab]] and ODRL Profiles.

Example Use Case: The Policy shows an Agreement with two Parties with the functional roles of the assigner and the assignee. The assigner grants the assignee the play action over the target asset.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:8888",
    "permission": [{
        "target": "http://example.com/music/1999.mp3",
        "assigner": "http://example.com/org/sony-music",
        "assignee": "http://example.com/people/billie",
        "action": "play"
    }]
}  

In the above example, the JSON-LD representation for function directly uses assigner and assignee as the token, as this has been defined as sub-properties of the parent function property.

Example Use Case: The Policy shows an Agreement with two Parties with the functional roles of the assigner and the assignee. The assigner grants the assignee the use of the target asset. In this case, the assigner is explicitly declared as a PartyIndividual as well as a vcard:Organisation and some additional external properties. The assignee is explicitly declared as a PartyCollection as well as a vcard:Group and some additional external properties. This implies that all the entities that are identifed as http://example.com/team/A will each have the same granted action

{
    "@context": [
        "http://www.w3.org/ns/odrl.jsonld",
        { "vcard": "http://www.w3.org/2006/vcard/ns#" }
    ],
    "@type": "Agreement",
    "uid": "http://example.com/policy:777",
    "permission": [{
        "target": "http://example.com/looking-glass.ebook",
        "assigner": {
            "@type": [ "PartyIndividual", "vcard:Organization" ],
            "uid":  "http://example.com/org/sony-books",
            "vcard:fn": "Sony Books LCC",
            "vcard:hasEmail": "sony-contact@example.com" },
        "assignee": {
            "@type": [ "PartyCollection", "vcard:Group" ],
            "uid":  "http://example.com/team/A",
            "vcard:fn": "Team A",
            "vcard:hasEmail": "teamA@example.com"},
        "action": "use"
    }]
}  

Action

The Action is an operation that is associated with a Rule.

The Rule provides the specific interpretations of the Action. For example; an Action is permitted to be performed on the target Asset when related to a Permission. When related to a Prohibition, the Action indicates the operation that is prohibited to be performed on the target Asset. When related to a Duty, the Action indicates the agreed operation that is obligatory to be performed by a Party

The ODRL Information Model defines the following top-level Actions:

All ODRL core and common terms are defined with either use or transfer as the parent term. See ODRL Profiles for more details.

The ODRL Common Vocabulary [[!odrl-vocab]] defines a standard set of generic Actions that MAY be used and ODRL Profiles MAY also define Actions.

Example Use Case: The Policy expresses an Offer for the target Asset http://example.com/music:1012 with the Action to play the Asset (play is defined as a narrower term of use).

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:1012",
    "permission": [{
            "target": "http://example.com/music:1012",
            "assigner": "http://example.com/org:abc",
            "action": "play"
     }]
}

Rule

The Rule class is the parent of the Permission, Prohibition, and Duty classes. The Rule class represents the common characteristics of these three classes.

The Rule class has the following properties:

The abstract relation and function properties MUST be represented as explicit types of these properties in the subclasses of a Rule.

For a Rule to become effective, it MUST be valid (ie all it's constraints MUST be satisfied).

Permission

A Permission class is a subclass of Rule that specifies the Actions that MAY be performed on an Asset. The Permission class inherits all the properties from the Rule class.

In addition to the Rule properties, the Permission class has the following:

  • A Permission MUST have an Asset via the target relation property. Other types of relation properties for Asset MAY be used.
  • A Permission MAY have one or more assigner and/or assignee function roles undertaken by Party entities. Other types of function properties for Party MAY be used.
  • A Permission MAY have one or more Duties via the duty property. The Duty expresses an agreed obligation that MUST be fulfilled in order for the Permission to be valid.

For a Permission to become effective, it MUST be valid (ie all it's constraints MUST be satisfied) and all of the Permission's Duties MUST be fulfilled.

Example Use Case: The Policy Offer from assigner http://example.com/org:xyz expresses the play Permission for the target Asset http//example.com/game:9090 and the permission is valid until the end of the year 2017.

 {
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:9090",
    "permission": [{
        "target": "http://example.com/game:9090",
        "assigner": "http://example.com/org:xyz",
        "action": "play",
        "constraint": [{
            "leftOperand": "dateTime",
            "operator": "lteq",
            "rightOperand": "2017-12-31"
        }]
    }]
}

Prohibition

A Prohibition class is a subclass of Rule that specifies the Actions that MUST NOT be performed on an Asset. The Prohibition class inherits all the properties from the Rule class.

In addition to the Rule properties, the Prohibition class has the following:

  • A Prohibition MUST have an Asset via the target relation property. Other types of relation properties for Asset MAY be used.
  • A Prohibition MAY have one or more assigner and/or assignee function roles undertaken by Party entities. Other types of function properties for Party MAY be used.

For a Prohibition to become effective, it MUST be valid (ie all it's constraints MUST be satisfied).

Example Use Case: The assigner of a target Asset http://example.com/photoAlbum:55 expresses an Agreement Policy with both a Permission and a Prohibition. The assigner Party http://example.com/MyPix:55 assigns the Permission display to the assignee Party http://example.com/assignee:55 at the same time a Prohibition to archive the target Asset. Additionally, in case of any conflicts between Permissions and Prohibitions, the conflict property is set to perm indicating that the Permissions will take precedence.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:5555",
    "conflict": "perm",
    "permission": [{
        "target": "http://example.com/photoAlbum:55",
        "action": "display",
        "assigner": "http://example.com/MyPix:55",
        "assignee": "http://example.com/assignee:55"
    }],
    "prohibition": [{
        "target": "http://example.com/photoAlbum:55",
        "action": "archive",
        "assigner": "http://example.com/MyPix:55",
        "assignee": "http://example.com/assignee:55"
    }]
}

Duty

A Duty class is a subclass of Rule that specifies agreed Actions that are obligatory and MUST be fulfilled in order to be granted the associated Permission. A Duty MUST only be associated with a Permission. The Permission is valid (including the Permission's constraints all being satisfied) if and only if the Duty has been fulfilled. The Duty class inherits all the properties from the Rule class.

In addition to the Rule properties, the Duty class has the following:

  • A Duty MUST only be associated with a Permission.
  • A Duty MAY have an Asset via the target relation property on which the agreed Action MUST be performed. Other types of relation properties for Asset MAY be used.
  • It is assumed that any assigned Party has the appropriate permissions to perform the Duty Action.
  • A Duty MAY have one or more assigner and/or assignee function roles undertaken by Party entities. If the functional roles are not specified in the Duty, then the respective functions are assumed to be the same as in the referring Permission. Other types of function properties for Party MAY be used (for example, Compensated Party or Tracking Party).

If a Permission has several Duty entities then all of the Duties MUST be agreed to be satisfied for the Permission to be valid. If several Permissions refer to a single Duty, then the Duty only has to be satisfied once for all the Permissions to be valid.

Even though a Duty is mandatory (ie agreed to be undertaken by the Parties), the ODRL Information Model does not specify any specific temporal conditions on WHEN the Duty Action MUST be performed. Such business rules MAY be expressed through additional Constraints. For example, a Policy may state that you can play a music file for a payment of $5.00. This does not indicate when the $5.00 should be paid as different business rules may apply, such as monthly invoicing or streaming.

Example Use Case: The Party http://example.com/assigner:sony makes an Offer to play the music file http://example.com/music/1999.mp3. There are two Duties that both must be satisfied for the compensate requirement. The first is the payAmount of $AUD5.00 and the second is the event of policyUsage must not have occurred yet (that is, the payment is made before the policy is exercised).

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:88",
    "permission": [{
        "assigner": "http://example.com/assigner:sony",
        "target": "http://example.com/music/1999.mp3",
        "action": "play",
        "duty": [{
            "action": "compensate",
            "constraint": [{
                "leftOperand": "payAmount",
                "operator": "eq",
                "rightOperand": "5.00",
                "unit": 
                  "https://www.currency-iso.org/dam/downloads/lists/list_one.xml#AUD"
            },
            {
                "leftOperand": "event",
                "operator": "lt",
                "rightOperand": "policyUsage"
            }]
        }]
    }]
}  

Example Use Case: The below Agreement between assigner http://example.com/person:88 and assignee http://example.com/gov/dept:99 allows the assignee to distribute the Asset http://example.com/data:77 under the condition they attribute the asset to Party http://australia.gov.au/.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:66",
    "permission": [{
        "target": "http://example.com/data:77",
        "assigner": "http://example.com/person:88",
        "assignee": "http://example.com/gov/dept:99",
        "action": "distribute",
        "duty": [{
            "action": "attribute",
            "attributedParty": "http://australia.gov.au/"
        }]
    }]
}

Constraint

A Constraint can be used to define the context in which to process an Action, Asset, or Party in Rules, such as limitations, restrictions, or interpretations that are applied to these classes. Constraints can be represented as Atomic Constraints - in which the left and right operands are logically compared - or as Compound Constraints in which the left and right operands are existing Atomic Constraints.

ODRL Processors MUST check all constraints at the time of processing the relevant Action, Asset, and Party. If the constraint is satisfied then the action becomes valid for the enclosing Rule. If the constraint is not satisfied, then the action is not valid for the enclosing Rule.

When multiple Constraints apply to the same Rule they are interpreted as conjunction. A Rule becomes effective if all of its Constraints are satisfied.

Atomic Constraint

Atomic Constraints are logical expressions for comparing two operands by one operator. If the logical expression evaluates to true the result of the Constraint is satisfied. Atomic Constraints can express these contexts with logical comparisons. For example, the number of usages (leftOperand) must be smaller than (operator) the number 10 (rightOperand).

The Atomic Constraint class has the following properties:

  • An Atomic Constraint MUST have a leftOperand - the left operand
  • An Atomic Constraint MUST have an operator- the logical operation
  • An Atomic Constraint MUST have a rightOperand - the right operand (only REQUIRED if no rightOperandReference appears)
  • An Atomic Constraint MUST have a rightOperandReference - a reference to a right operand (only REQUIRED if no rightOperand appears)
  • An Atomic Constraint MAY have a dataType - the type of the rightOperand/Reference
  • An Atomic Constraint MAY have a unit - the unit value of the rightOperand/Reference
  • An Atomic Constraint MAY have a status - the current value generated from the leftOperand action

The leftOperand MAY be one of the Constraint Left Operands defined in the ODRL Common Vocabulary [[!odrl-vocab]] or from an ODRL Profile. The leftOperand MUST clearly be defined to indicate the subject of the constraint, and MAY include how the value for comparison has to be retrieved or generated. For example, the count constraint applies to the action and the language constraint applies to the asset.

The operator identifies the logical operation such as “greater than” or “equal to” between the left and right operands.

The rightOperand identifies the right operand of the logic expression. The rightOperand MAY be the value of the Constraint that is to be compared to the leftOperand. The rightOperand represents the literal value (such as 10 or http://example.com/c100) and rightOperandReference represents an IRI that MUST be dereferenced first to obtain the actual value of the rightOperand. A rightOperandReference is used in cases where the value of the rightOperand MUST be obtained from dereferencing an IRI. Only one of rightOperand and rightOperandReference MUST appear in the Atomic Constraint.

The dataType indicates the type of theĀ rightOperand/Reference, such as xsd:decimal or xsd:datetime and the unit indicates the unit value of the rightOperand/Reference, such as “EU currency”.

The status provides the current value generated from the leftOperand action. For example, a count constraint could have a rightOperand value of 10, and the status of 5. This means that the action has already been exercised 5 times.

Example Use Case: In the first example below, the Party http://example.com/myPix:6161 wants to offer the distribute Permission for a specific country for the target Asset. The offer has two Duties to compensate the assigner and a nextPolicy. The potential assignee may distribute the target Asset http://example.com/wallpaper:1234 according to the Policy target Asset. The second exmaple shows that the Policy http://example.com/policy:7171 stipulates the potential assignee may only offer the display Permission to other parties.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:6161",
    "permission": [{
        "target": "http://example.com/wallpaper:1234",
        "assigner": "http://example.com/myPix:6161",
        "action": "distribute",
        "constraint": [{
            "leftOperand": "spatial",
            "operator": "eq",
            "rightOperand": "https://www.iso.org/obp/ui/#iso:code:3166:IT"
        }],
        "duty": [
            {
                "action": "compensate",
                "constraint": [{
                    "leftOperand": "payAmount",
                    "operator": "eq",
                    "rightOperand": "100.00",
                    "dataType": "http://www.w3.org/2001/XMLSchema#decimal",
                    "unit": 
                      "https://www.currency-iso.org/dam/downloads/lists/list_one.xml#EUR"
                }]
            },
            {
                "action": "nextPolicy",
                "target": "http://example.com/policy:7171"
            }
        ]
    }]
}
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Set",
    "uid": "http://example.com/policy:7171",
    "permission": [{
        "target": "http://example.com/wallpaper:1234",
        "action": "display"
    }]
}

Compound Constraint

Compound Constraints refer to two exisiting Atomic Constraints as the left and right operand. For example, Atomic Constraint #1 (leftOperand) must be satisfied or (operator) Atomic Constraint #2 (rightOperand) must be satisfied. The Compound Constraint operator identifiers the logical relationship between the two Atomic Constraints using operators such as and or exclusive or.

The Compound Constraint class has the following properties:

  • A Compound Constraint MUST have a leftOperand - the left operand
  • A Compound Constraint MUST have a operator- the logical relationship
  • A Compound Constraint MUST have a rightOperand - the right operand

The applicable operator that MAY be used for Compound Constraint are:

  • or - at least one of the Atomic Constraints (in the left or right operand) MUST be satisfied
  • xor - only one of the Atomic Constraints (in the left or right operand) MUST be satisfied
  • and - both of the Atomic Constraints (in the left and right operand) MUST be satisfied
  • andSequence - the left operand Atomic Constraint must deliver a satisfied result before the right operand Atomic Constraint is evaluated.

Other operator values MAY be defined in the ODRL Common Vocabulary [[!odrl-vocab]] or ODRL Profiles.

The andSequence operator is an example where there are temporal conditional requirements between the two left and rigt operands. This may lead to situations where the outcome is unresolvable, such as deadlock if one of the Atomic Constraints is unable to be satisfied. ODRL Processing systems SHOULD plan for these scenarios and implement mechanisms to resolve them.

The processing model for Compound Constraints includes:

  1. The left and right operands MUST both be Atomic Constraints.
  2. The left and right operands MUST NOT be the same Atomic Constraint.
  3. The operator MUST only be of the values; or, xor, and, andSequence. Other values MAY be defined in ODRL Profiles exclusively for the use of Compound Constraints.
  4. If the operator is or then at least one of the Atomic Constraints (in the left or right operands) MUST be satisfied for the entire Compound Constraint to be satisfied.
  5. If the operator is xor then at only one of the Atmomic Constraints (in the left or right operands) MUST be satisfied for the entire Compound Constraint to be satisfied.
  6. If the operator is and then both of the Atmoic Constraints (in the left and right operands) MUST be satisfied for the entire Compound Constraint to be satisfied.
  7. If the operator is andSequence then the left operand Atomic Constraint MUST return a satisfied result then the right operand Atomic Constraint MUST be evaluated and be satisfied.

Example Use Case:The Policy below shows a Permission to play the target asset that can either be a maximum of 100 times, or unlimited play until the end of 2017 but not both.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:88",
    "permission": [{
        "target": "http://example.com/book/1999.mp3",
        "assigner": "http://example.com/org/paisley-park",
        "action": "play",
        "constraint": [{
                "leftOperand": "http://example.com/policy:88/C1",
                "operator": "xor",
                "rightOperand": "http://example.com/policy:88/C2"
            }],
    }],
   "constraint": [{
       "uid": "http://example.com/policy:88/C1",
       "leftOperand": "count",
       "operator": "lteq",
       "rightOperand": "100"
   },
   {
       "uid": "http://example.com/policy:88/C2",
       "leftOperand": "dateTime",
       "operator": "lteq",
       "rightOperand": "2017-12-31"
   }]
}  

Example Use Case: The Policy below shows a Permission to distribute photos in which the first atomic constraint (the event http://example.com/football/game/2017) has concluded (the operator gt indicating this), then the second atomic constraint (wait for 60 minutes) has passed. The operator andSequence requires that first the atomic constraint in the leftOperand is satisfied - the event has closed - and this triggers the Action Delay Period after which the action of the permission may be exercised. (Note: The operator value of andSequence is not the same as and as for the latter, both operand Atomic Constraints must be satisfied, but could be processed at the same time.)

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:88",
    "permission": [{
        "target": "http://example.com/photo.jpg",
        "assigner": "http://example.com/org/fifa",
        "action": "distribute",
        "constraint": [{
                "leftOperand": "http://example.com/policy:88/C1",
                "operator": "andSequence",
                "rightOperand": "http://example.com/policy:88/C2"
            }],
    }],
   "constraint": [{
       "uid": "http://example.com/policy:88/C1",
       "leftOperand": "event",
       "operator": "gt",
       "rightOperand": "http://example.com/football/game/2017"
   },
   {
       "uid": "http://example.com/policy:88/C2",
       "leftOperand": "delayPeriod",
       "operator": "gteq",
       "rightOperand": "P60M"
   }]
}  

Asset Constraint

Atomic constraints MAY be applied to Assets to indicate the context under which to identify the Asset(s) that are applicable to the Rule. If an Asset is a AssetIndividual then the constraint logical expressions applies to the whole Asset as a single resource. If an Asset is a AssetCollection then the constraint logical expressions applies to each of the resources identified by the Asset.

Example Use Case: The Policy defines a target Asset http://example.com/media-catalogue that is an AssetCollection of multimedia images. The target Asset also has a constraint that specifies further context on the characteristics of the target Asset items. In this case, the target Assets will be no more than 50 resources from the media catalogue, and each of those may be printed.

The ex:set leftOperand is defined in the ODRL Profile http://example.com/profiles/01. It is considered good practice that the profile URIs are not mere identifiers but dereference to human- and machine-readable documentation. See ODRL Profiles for further information.

 {
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:4444",
    "profile": "http://example.com/profiles/01",
    "permission": [{
        "assigner": "http://example.com/org88",
        "target": {
            "@type": "AssetCollection",
            "uid":  "http://example.com/media-catalogue",
            "constraint": [{
                "leftOperand": "ex:set",
                "operator": "lteq",
                "rightOperand": "50"
            }],
        },
        "action": "print"
    }]
}

Party Constraint

Atomic constraints MAY be applied to Party to indicate the context under which to identify the Parties(s) that are applicable to the Rule. If a Party is a PartyIndividual then the constraint logical expressions applies to the whole Party as a single entity. If a Party is a PartyCollection then the constraint logical expressions applies to each of the entities identified by the Party.

Example Use Case: The target Asset http://example.com/myPhotos:BdayParty are a set of photos posted to a social network site by the assigner of the photos http://example.com/user44. The assignee is a PartyCollection http://example.com/user44/friends and represents all the friends of the assigner. The assignee also has a constraint that indicates only members of the group over the foaf:age of 18 will be assigned the display permission.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:4444",
    "permission": [{
        "target": "http://example.com/myPhotos:BdayParty",
        "assigner": "http://example.com/user44",
        "assignee": {
            "@type": "PartyCollection",
            "uid":  "http://example.com/user44/friends",
            "constraint": [{
                "leftOperand": "foaf:age",
                "operator": "gt",
                "rightOperand": "17"
            }],
        },
        "action": "display"
    }]
}

Policy Composition

A Policy MAY contain multiple Rules, and each Rule MAY contain multiple Assets, Parties, Actions, Constraints, and Duties. A Policy MAY also contain Assets, Parties, and Actions at the Policy level, and these entities apply to all of the enclosing Rules in the Policy.

At the core level, an ODRL Rule would include one Asset, one or more Parties, one Action, and potentially one Constraint and/or Duty, as shown in the example below. This example shows the atomic level of a Policy where it is a irreducible Rule (that is, not able to be reduced or further simplified).

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:7777",
    "permission": [{
        "target": "http://example.com/music/1999.mp3",
        "assigner": "http://example.com/org/sony-music",
        "assignee": "http://example.com/people/billie",
        "action": "play",
        "constraint": "...",
        "duty": "..."
    }]
} 

As multiple Assets, Parties, and Actions can be expressed for each Rule, the following example shows two Assets defined for the policy:

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:8888",
    "permission": [{
        "target": [ "http://example.com/music/1999.mp3",
                    "http://example.com/music/PurpleRain.mp3"],
        "assigner": "http://example.com/org/sony-music",
        "assignee": "http://example.com/people/billie",
        "action": "play",
        "constraint": "...",
        "duty": "..."
    }]
}

The above example could then be reduced to two atomic Rules, with the two target assets appearing individually in each:

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:8888",
    "permission": [{
        "target": "http://example.com/music/1999.mp3",
        "assigner": "http://example.com/org/sony-music",
        "assignee": "http://example.com/people/billie",
        "action": "play",
        "constraint": "...",
        "duty": "..."
    },
    {
        "target": "http://example.com/music/PurpleRain.mp3",
        "assigner": "http://example.com/org/sony-music",
        "assignee": "http://example.com/people/billie",
        "action": "play",
        "constraint": "...",
        "duty": "..."
    }]
}

In order to create the atomic Rules in a Policy, the processing model for policies with multiple Assets, Parties, and Actions includes:

  1. Where there are multiple Assets (with the same relation), then create new Rules (one for each of these Assets) and include only one Asset relation, and include all other (non-Asset) properties, in each Rule
  2. Where there are multiple Parties (with the same function), then create new Rules (one for each of these Parties) and include only one Party function, and include all other (non-Party) properties, in each Rule.
  3. Where there are multiple Actions, then create new Rules (one for each of these Actions) and include only one Action, and include all other (non-Action) properties, in each Rule.

An ODRL Policy MAY also declare multiple Assets, Parties, and Actions at the Policy level (not just within a Rule). This implies that these classes are all common to all the Rules in the Policy, as shown in the below example:

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:8888",
    "target": "http://example.com/music/1999.mp3",
    "assigner": "http://example.com/org/sony-music",
    "action": "play",
    "permission": [{
        "assignee": "http://example.com/people/billie"
        },
        {
        "assignee": "http://example.com/people/murphy"
        }]
}  

To fully expand the Rules, the Policy-level Assets, Parties, and Actions MUST be added to all the Rules in the Policy. As shown below, the policy-level target, assigner, and action are added to the two permission Rules:

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:8888",
    "permission": [{
        "assignee": "http://example.com/people/billie",
        "target": "http://example.com/music/1999.mp3",
        "assigner": "http://example.com/org/sony-music",
        "action": "play"
        },
        {
        "assignee": "http://example.com/people/murphy",
        "target": "http://example.com/music/1999.mp3",
        "assigner": "http://example.com/org/sony-music",
        "action": "play",
        }]
}  

The processing model for Policies with multiple Assets, Parties, and Actions declared at the Policy-level includes:

  1. Replicate all Policy-level Assets in each and all Permission/Prohibition Rules.
  2. Replicate all Policy-level Parties in each and all Permission/Prohibition Rules.
  3. Replicate all Policy-level Actions in each and all Permission/Prohibition Rules.
  4. Follow the processing model (defined above) to create atomic Rules in the Policy.

Policy Provenance

Provenance properties MAY be added to a Policy to support additional authenticity, and integrity purposes from external vocabularies. The ODRL Information Model recommends the use of Dublin Core Metadata Terms [[dcterms]] for ODRL Policies.

The following Dublin Core Metadata Terms [[dcterms]] SHOULD be used:

The processing model for Policies with the above provenance properties include:

  1. If a Policy contains the dc:isReplacedBy property, then a processor MUST consider the first Policy invalid and MUST retrieve and process the identified Policy.

Example Use Case: The below example contains provenance properties that indicate who created the Policy, when the Policy was issued, which jurisdiction (Queensland, Australia) the Policy applies to, and an older version of the Policy it replaces.

{
    "@context": [
        "http://www.w3.org/ns/odrl.jsonld",
        { "dc": "http://purl.org/dc/terms/" }
    ],
    "@type": "Policy",
    "uid": "http://example.com/policy:8888",
    "dc:creator": "billie@example.com",
    "dc:issued": "2017-01-01:12:00",
    "dc:coverage": "https://www.iso.org/obp/ui/#iso:code:3166:AU-QLD",
    "dc:replaces": "http://example.com/policy:8887",
    "permission": [{...}]
}  

Policy Inheritance

ODRL supports a simple inheritance mechanism in which a (child) Policy may inherit all the atomic Rules of the (parent) Policy.

The inheritAllowed property in the Policy is used to indicate if the Policy expression can be used in any inheritance relationship. If present, the value of the inheritAllowed property MUST take one of the following values:

If the inheritAllowed property is not explicitly set, its default value of true will be used.

The following property SHOULD be used in a child Policy that is inheriting from a parent Policy in which that parent Policy MUST allow inheritance (via the inheritAllowed property) :

The following restrictions apply when using inheritance:

Example Use Case: Consider the parent Policy http://example.com/policy:default below that has been expressed primarily for inheritance purposes (the assinger wishes to provide default permissions for all Policies). It does not include any target Asset and allows the archive and annotate Permissions and the aggregate Prohibition.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:default",
    "inheritAllowed": "true",
    "permission": [{
        "assigner": "http://example.com/org-01",
        "action": [ "archive", "annotate" ]
    }],
    "prohibition": [{
        "assigner": "http://example.com/org-01",
        "action": "aggregate"
    }]
}  

The child AgreementPolicy http://example.com/policy:4444 below includes the inheritFrom property pointing to the parent Policy http://example.com/policy:default (above). The child Policy also includes the Asset, the actions (to display and print the Asset) and the assignee Party for the Agreement.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:4444",
    "inheritFrom": "http://example.com/policy:default",
    "permission": [{
        "target": "http://example.com/asset:5555",
        "action": [ "display", "print" ],
        "assignee": "http://example.com/user:0001"
    }]
}  

After the inheritance is performed - where the (parent) Policy atomic Rules are added to the (child) Policy - the resulting Policy is shown below. As this is an Agreement Policy, the assignee also becomes part of the inherited Prohibition.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:4444",
    "inheritFrom": "http://example.com/policy:default",
    "permission": [{
        "target": "http://example.com/asset:5555",
        "action": [ "archive", "annotate", "display", "print" ],
        "assigner": "http://example.com/org-01",
        "assignee": "http://example.com/user:0001"
    }],
    "prohibition": [{
        "action": "aggregate",
        "assigner": "http://example.com/org-01",
        "assignee": "http://example.com/user:0001"
    }]
}

The processing model for ODRL Policy Inheritance includes:

  1. A (child) Policy with an inheritFrom property MUST first verify that the (parent) Policy does not contain the inheritAllowed property with the value false.
  2. The (child) Policy MUST access the (parent) Policy and replicate the following in the (child) Policy:
    • All policy-level Assets, Parties, Actions.
    • All Permission and Prohibition Rules.
  3. The (child) Policy can then be further expanded (into atomic Rules) by following the processing models defined in the Policy Composition section.

Policy Conflict Strategy

The conflict property is used to establish strategies to resolve conflicts that arise from the merging of Policies or conflicts between Permissions and Prohibitions in the same Policy. Conflicts may arise when merging Policies as a result of Policy Inheritance and the resultant Rules are inconsistent.

The conflict property SHOULD take one of the following values:

If the conflict property is not explicitly set, the default of invalid will be used.

Other conflict property values MAY be defined in the ODRL Common Vocabulary [[!odrl-vocab]] and ODRL Profiles.

If an ODRL processor does not detect any conflicts in the Rules, then the ODRL Policy is valid, otherwise the ODRL processor MUST follow these processing rules:

  1. If a Policy has the conflict property of perm then any conflicting Permission Rule MUST override the Prohibition Rule and continue with the Policy as valid.
  2. If a Policy has the conflict property of prohibit then any conflicting Prohibition Rule MUST override the Permission Rule and continue with the Policy as valid.
  3. If a Policy has the conflict property of invalid then processing MUST not continue and the entire Policy MUST be invalid.
  4. If a Policy has multiple conflict property values (for example, after a Policy merge or inheritance) then processing MUST not continue and the entire Policy MUST be invalid.

Example Use Case: Two Policies are associated to the same target Asset http://example.com/asset:1212. The first Policy http://example.com/policy:0001 allows to use the Asset. The second Policy http://example.com/policy:0002 allows for the display of the Asset, but it prohibits print. Both policies explicitly state how to deal with conflicts through the conflict property being set to perm. Hence the Permissions will always override any Prohibitions. In this use case, since the print Action is a specialisation of the use Action, there could be a conflict. However, the perm conflict strategy means that the use Permission will override the print Prohibition.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:0001",
    "conflict": "perm",
    "permission": [{
        "target": "http://example.com/asset:1212",
        "action": "use",
        "assigner": "http://example.com/owner:181"
    }]
}
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:0002",
    "conflict": "perm",
    "permission": [{
        "target": "http://example.com/asset:1212",
        "action": "display",
        "assigner": "http://example.com/owner:182"
    }],
    "prohibition": [{
        "target": "http://example.com/asset:1212",
        "action": "print"
    }]
}

In the above use case, if the second Policy had the conflict value of prohibit, then the outcome would be a direct contradiction, and the result will be an invalid Policy.

ODRL Profiles

ODRL Profile Purpose

The ODRL Information Model serves as a core framework and vocabulary to express Policies. The ODRL Common Vocabulary [[!odrl-vocab]] provides a generic range of common actions for Permissions, Prohibition, and Duties as well as Policy subclasses, Constraint left operands and operators, Asset relations, and Party functions. For some communities, this flexibility and wide-range of terms supports their requirements for policy expression. Other communities may wish to have a more focussed and specific set of terms that meets their sector's requirements more precisley.

In this latter case, it is recommended that a community create and document an ODRL Profile. An ODRL Profile directly and explicitly serves their communities needs by specifying only the terms they wish to support in ODRL expressions. These terms may come from the ODRL Common Vocabulary or may be created as new terms.

ODRL Profile Mechanism

In an ODRL Policy, the profile property is used to indicate the identifier (IRI) of the ODRL Profile for which the Policy expression conforms to. This property is OPTIONAL, but if the property appears, then any ODRL consuming system that supports/implements the given profile MUST understand the identified ODRL Profile. If an ODRL consuming system does not understand the ODRL Profile, then it MAY continue processing the Policy expression, but it SHOULD NOT assume it has interpreted the Policy expression correctly.

An ODRL Profile extends the ODRL Information Model classes and properties in the following ways:

Additional Policy Subclasses - create a subclass the ODRL Policy class:

Additional Asset Relationships - create a subproperty of the abstract relation property:

Additional Party Functional roles - create a subproperty of the abstract fuction property:

Additional Actions for Rules - create an instance of a Action and define its narrower parent Action:

Additional Constraint left operards - create an instance of the LeftOperand class:

Additional Constraint right operards - create an instance of the RightOperand class:

Additional Constraint operators - create an instance of the Operator class:

Additional Policy Conflict strategies - create an instance of the ConflictTerm class:

Additional Rule class - create a suclass of the Rule class and define it as disjoint with the other Rule subclasses:

  • :myRule rdfs:subClassOf :Rule ;
  • owl:disjointWith :Prohibition, :Duty :Permission ;
  • Human-readable documenation is also recommened for each new term using rdfs:label for the name, skos:defintion for the formal defintion, and skos:note for additional comments on its use.

    Privacy Considerations

    The ODRL Information Model does not directly express sensitive personal information such as the the identity of the existence of assets containing such data related to parties. However, ODRL vocabularies (such as the ODRL Common Vocabulary [[!odrl-vocab]] and ODRL Profiles) may define terms that may relate to personal information. These specifications should inform implementations that produce or consume such ODRL expressions to take steps to communicate to all relevant users the manner in which the policy is being used, the identity of any other party with whom that policy is being shared, and the reason the policy is being shared with other parties.

    Acknowledgements

    The POE Working Group gratefully acknowledges the contributions of the ODRL Community Group and the earlier ODRL Initiative. In particular the editors would like to thank Susanne Guth, Daniel Paehler, and Andreas Kasten for their past editorial contributions.

    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 asset usage for the publication, distribution and consumption of content services. The final outputs of the ODRL Community Group were the ODRL 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 Information Model was derived from the ODRL V2.1 Core Model Community Group report. 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 Permissions & Obligations Expression Working Group.

    Changes from Previous Versions

    Changes from the First Public Working Draft 21 July 2016:

    Changes from the Working Draft 23 February 2017: