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 comform 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.

Serialization of the Model

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 [[!vocab-odrl]].

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 an Asset
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.
ODRL Processor
A system that provides services that creates, manipulates, and validates ODRL Policy expressions.

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.

ODRL Information Model

The ODRL Information Model enables Policies to express Permissions and Prohibitions related to the usage of Assets. In essence, this explicitly expresses what is allowed and what is not allowed by the Policy, as well as other requirements and parties involved. The aim of the ODRL Information Model is to support flexible Policy expressions by allowing the author to include as much, or as little, expressive detail.

The figure below shows the ODRL Information Model. The Policy is the central class that holds an ODRL policy together.

ODRL Information Model
ODRL Information Model

The ODRL Information Model diagram shows the Permission, Prohibition, and Duty classes as subclasses of the abstract Rule concept. These Rules have common relationships to the other key concepts (specifically, Action, Asset, Party, and Constraint). However, there are core differences in their semantics:

As an example, a Permission in a Policy MAY allow a particular Action to be applied to an Asset, e.g., “play the audio file abc.mp3”. A Constraint, such as “at most 10 times”, MAY be added to express limitations to the Actions. The Party "VirtualMusicShop" that granted this Permission MAY be included with the Role Assigner, and the Party "Alice" that is granted the Permission MAY be included with the Role Assignee.

Similar to Permissions, a Duty states that a certain agreed Action MUST be executed by the Party with the Role Assignee for the Permission to be valid, e.g. “Alice must pay 5 Euros in order to get the Permission to play abc.mp3″.

Policy

A Policy has the following attributes:

The values for the Policy type attribute are described in the ODRL vocabulary [[!vocab-odrl]] or in ODRL Profiles. The Policy type describes the context of use of the Policy and MAY include additional constraints that processing systems MUST understand.

For example, the "Agreement" Policy type stipulates minimal cardinalities for some for the Policy classes, which are different than the "Offer" Policy type. In addition, and more importantly, the "Agreement" Policy type expresses that the Permissions/Prohibitions have been granted, but the "Offer" Policy type does not.

To illustrate the concepts described in the Information Model, we will start from basic examples to come to more sophisticated ones when concepts are discussed in more details.

Example Use Case: The below "Set" Policy type grants the Permission to read and the Prohibition to reproduce the target Asset http//example.com/asset:9898. No Parties or other elements are involved.

{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Set",
    "@id": "http://example.com/policy:1010",
    "permission": [{
        "target": "http://example.com/asset:9898",
        "action": "odrl:read"
    }],
    "prohibition": [{
        "target": "http://example.com/asset:9898",
        "action": "odrl:reproduce"
    }]
}

For the examples in this document, the ODRL Information Model uid and type attributes are mapped to the JSON-LD @id and @type tokens.

Example Use Case: The below "Set" Policy type states that the Asset http//example.com/asset:9898 is the target of the Permission to perform the action reproduce, the Duty to perform the action attribute to http://example.com/owner:9898, and the Prohibition to perform the action translate. Two Parties are involved, namely the Assigner of the Permission and the Party to be attributed.

{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Set",
    "@id": "http://example.com/policy:1010",
    "permission": [{
        "target": "http://example.com/asset:9898",
        "action": "odrl:reproduce",
        "assigner": "http://example.com/assigner:88",
        "duty": [{
                "action": "odrl:attribute",
                "attributedParty": "http://example.com/owner:9898"
        }]
    }],
    "prohibition": [{
        "target": "http://example.com/asset:9898",
        "action": "odrl:translate"
    }]
}

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 basic level, an ODRL Rule would refer to 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 an irreducible and unambiguous Rule.

{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Agreement",
    "@id": "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": "odrl:play",
        "constraint": "...",
        "duty": "..."
    }]
} 

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

{    "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": "odrl:play",
        "constraint": "...",
        "duty": "..."
        }]
}

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

{    "permission": [{
        "target": "http://example.com/music/1999.mp3",
        "assigner": "http://example.com/org/sony-music",
        "assignee": "http://example.com/people/billie",
        "action": "odrl:play",
        "constraint": "...",
        "duty": "..."
        },
        {
        "target": "http://example.com/music/PurpleRain.mp3",
        "assigner": "http://example.com/org/sony-music",
        "assignee": "http://example.com/people/billie",
        "action": "odrl: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 one Asset relation, and include all other (non-Asset) entities.
  2. Where there are multiple Parties (with the same Role), then create new Rules (one for each of these Parties) and include one Party Role, and ainclude all other (non-Party Role) entities.
  3. Where there are multiple Actions, then create new Rules (one for each of these Actions) and include one Action, and include all other (non-Action) entities.

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

{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Agreement",
    "@id": "http://example.com/policy:8888",
    "target": "http://example.com/music/1999.mp3",
    "assigner": "http://example.com/org/sony-music",
    "action": "odrl: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": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Agreement",
    "@id": "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": "odrl:play"
        },
        {
        "assignee": "http://example.com/people/murphy"
        "target": "http://example.com/music/1999.mp3",
        "assigner": "http://example.com/org/sony-music",
        "action": "odrl: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 attributes 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:

  • dc:creator - the individual, agent, or organisation that authored the Policy.
  • dc:description - a human-readable representation or summary of the Policy.
  • dc:issued - the date (and time) the Policy was first issued.
  • dc:modified - the date (and time) the Policy was updated.
  • dc:coverage - the jurisdiction under which the Policy is relevant.
  • dc:replaces - the identifier (uid) of a Policy that this Policy supersedes.
  • dc:isReplacedBy - the identifier (uid) of a Policy that supersedes this Policy.

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

  1. If a Policy contains the dc:isReplacedBy property, then the identified Policy MUST be retrieved and processed.

Example Use Case:The below example contains provenace 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": { 
        "odrl": "http://www.w3.org/ns/odrl/2/",
        "dc": "http://purl.org/dc/terms/"
    },
    "@type": "odrl:Agreement",
    "@id": "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 Conflict Strategy

The conflict attribute 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 about the same Asset and the resultant Actions are inconsistent.

The conflict attribute MUST take one of the following:

  • perm: the Permissions MUST override the Prohibitions
  • prohibit: the Prohibitions MUST override the Permissions
  • invalid: the entire Policy MUST be invalid if any conflict is detected

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

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 attribute 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 attribute 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 attribute of invalid then processing MUST not continue and the entire Policy MUST be invalid.
  4. If a Policy has multiple conflict attribute 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 attribute being set to perm. Hence the Permissions will always override any Prohibitions. In this use case, since the print Action is a subset 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": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Set",
    "@id": "http://example.com/policy:0001",
    "conflict": "perm",
    "permission": [{
        "target": "http://example.com/asset:1212",
        "action": "odrl:use",
        "assigner": "http://example.com/owner:181"
    }]
}
{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Set",
    "@id": "http://example.com/policy:0002",
    "conflict": "perm",
    "permission": [{
        "target": "http://example.com/asset:1212",
        "action": "odrl:display",
        "assigner": "http://example.com/owner:182"
    }],
    "prohibition": [{
        "target": "http://example.com/asset:1212",
        "action": "odrl: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.

Undefined Actions

The detection of undefined actions is viewed to be implementation-specific, and too vague to be part of the Information Model. This feature maybe removed in future versions.

The undefined attribute is used to indicate how to process unsupported Actions. That is, if an ODRL expression contains an Action that is not from a known (or supported) ODRL vocabulary, how should the Action be treated in the context of the whole ODRL Policy?

The undefined attribute MUST take one of the following:

  • support: the undefined Action is to be supported as part of the Policy – and the Policy remains valid
  • ignore: the undefined Action is to be ignored and is not part of the Policy – and the Policy remains valid
  • invalid: the undefined Action is unknown – and the entire Policy is invalid

In all cases, systems that process ODRL expressions SHOULD provide mechanisms that adequately address these three outcomes. That is, how the Action can be supported, or ignored, or the entire Policy is invalid.

If the undefined attribute is not explicitly set, its default of invalid SHALL be used.

The processing model for undefined actions includes:

  1. If a Policy has the undefined attribute of support and there are actions in the Policy now known to the processing system, then the processing system MUST support these actions as part of the valid Policy.
  2. If a Policy has the undefined attribute of ignore and there are actions in the Policy now known to the processing system, then the processing system MUST disregard these actions as part of the valid Policy.
  3. If a Policy has the undefined attribute of invalid and there are actions in the Policy now known to the processing system, then the processing system MUST process the entire Policy as invalid.
  4. If a Policy has multiple undefined attribute values (for example, after a Policy merge) AND there are actions in the Policy now known to the processing system, then the entire Policy MUST be processed as invalid.

Example Use Case: A Policy of type Set states that the Asset can be recorded. The processing system does not understand this Action, and since the undefined attribute is invalid, then the entire Policy is deemed invalid.

{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Set",
    "@id": "http://example.com/policy:8888",
    "undefined": "odrl:invalid",
    "permission": [{
        "target": "http://example.com/music/1999.mp3",
        "action": "http://example.com/ns/recorded"
        }]
}  

Policy Inheritance

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

The inheritAllowed attribute 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 attribute MUST take one of the following:

  • true: the Policy expression can be used for inheritance
  • false: the Policy expression can not be used for inheritance

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

The following attribute 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 attribute) :

  • inheritFrom: the identifier of the parent Policy from which this child Policy inherits from

The inheritFrom association in the (child) Policy will uniquely identify (via a UID) the (parent) Policy from which the inheritance will be performed.

The following restrictions apply when using inheritance:

  • Single inheritance is only supported. (One parent Policy to one or more child Policy entities. No child Policy can inherit from two or more parent Policy entities.)
  • Inheritance can be to any depth. (Multiple levels of children Policy entities.)
  • Inheritance MUST NOT be circular.
  • No state information is transferred from the parent Policy to the child Policy.

Example Use Case: Consider the parent Policy http://example.com/policy:3333 that has been expressed primarly for inheritance purposes:

{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Set",
    "@id": "http://example.com/policy:3333",
    "target": "http://example.com/asset:3333",
    "assigner": "http://example.com/boss:0001",
    "permission": [{
        "action": "odrl:use"
    }]
}  

The child Policy http://example.com/policy:4444 includes the inheritFrom attribute pointing to the parent Policy http://example.com/policy:3333. The child Policy also includes its own specific policy-level asset, and two Permission Rules.

{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Agreement",
    "@id": "http://example.com/policy:4444",
    "inheritFrom": "http://example.com/policy:3333",
    "target": "http://example.com/asset:5555",
    "permission": [{
        "assignee": "http://example.com/guest:0001",
        "action": "odrl:display"
    },
    {
        "assignee": "http://example.com/guest:0002",
        "action": "odrl:print"
    }]
}  

After the inheritance is performed - where the (parent) Policy atomic Rules are added to the (child) Policy - the resulting Policy is as follows:

{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Agreement",
    "@id": "http://example.com/policy:4444",
    "target": [
       "http://example.com/asset:5555",
       "http://example.com/asset:3333" ]
    "assigner": "http://example.com/boss:0001",
    "permission": [{
        "assignee": "http://example.com/guest:0001",
        "action": "odrl:display"
    },
    {
        "assignee": "http://example.com/guest:0002",
        "action": "odrl:print"
    },
    {
        "action": "odrl:use"
    }]
}  

The processing model for ODRL Policy Inheritance includes:

  1. A (child) Policy with an inheritFrom attribute MUST first verify that the (parent) Policy does not contain the inheritAllowed attribute 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.

Asset

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

An Asset has the following attributes:

The identification of a Asset is a key foundation of the ODRL Policy language. In general, the uid SHOULD be a URI [[rfc3986]] representing the identifier of the Asset. There MAY also be other alternative identifiers, or identification mechanisms that could be used. For example, to identify specific parts of an Asset, Media Fragments URI [[media-frags]] may be utilised. To identify groups or a range of Assets, then POWDER [[powder-primer]], URI Templates [[rfc6570]], or URI wildcards may be utilised. To identify inline/indirect Assets, then URI fragments may be used.

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

Relation

The Relation class is used to link to an Asset from either Rule, indicating how the Asset SHOULD be utilised in respect to the Rule that links to it.

A Relation has the following attribute:

  • A Relation MUST refer to a relation indicating the associated link between the Asset and the Rule.

The relation link of target MUST be supported which indicates that the Asset is the primary object to which the Rule actions apply.

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

Example Use Case: The Party http//example.com/guest:0001 wants to display the target Asset http://example.com/asset:3333, but she needs to be granted with the Permission to do so first. This request can be implemented through a Policy of the type Request asking for the Permission to display Asset http://example.com/asset:3333.

{
    "@context": {
         "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Request",
    "@id": "http://example.com/policy:3333",
    "permission": [{
        "target": "http://example.com/asset:3333",
        "action": "odrl:display",
        "assignee": "http://example.com/guest:0001"
    }]
}

In the above example, the JSON-LD representation for Relation directly uses target as the token, as this has been mapped as a sub-property of the relation property.

Example Use Case: The below Policy shows the index action Permission on the target Asset http://example.com/archive1011. Another Asset relation (x:collection) is also expressed to indicate the Asset (http://example.com/x/database) the indexing outcome should be stored in. (These semantics would be defined by the community who created the x:collection relation.)

{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Set",
    "@id": "http://example.com/policy:1011",
    "permission": [{
        "target": "http://example.com/archive1011",
        "x:collection": "http://example.com/x/database",
        "action": "odrl:index"
    }]
}

Scope

The scope attribute SHOULD be used to indicate the context under which to interpret an Asset. The purpose of scope is to provide additional information about the Asset. For example, the Asset identifier may refer to a resource with many characteristics, but the scope may limit that to only one specific characteristic.

The scope attribute URI values SHOULD be defined in the ODRL vocabulary [[!vocab-odrl]] and ODRL Profiles.

Example Use Case: The Policy defines a target Asset http://example.com/media-catalogue that has a scope of http://example.com/imt/jpeg (which, in this case, provides additional context on what characteristics the Asset MUST hold).

{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Offer",
    "@id": "http://example.com/policy:4444",
    "permission": [{
        "target": [{
                "@id": "http://example.com/media-catalogue",
                "scope": "http://example.com/imt/jpeg"	
        }],
        "action": "odrl:use",
        "assigner": "http://example.com/user88"
    }]
}

Party

A Party can be any form of identifiable entity who undertakes a role in the Policy, 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 Role it plays in the Rule).

A Party has the following attributes:

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

Role

A Role is an association that is used to link a Party from a Rule, to indicate what Role the Party takes with respect to the Rule that links to it.

A Role has the following attributes:

  • A Role MUST refer to the function role the Party is undertaking.

The function attribute MUST support the following roles:

  • 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 roles for the function attribute MAY be defined in the ODRL vocabulary [[!vocab-odrl]] 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. In additiion, both parties are further described with properties from an external vocabulary and their types are clearly indicated.

{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/",
        "vCard": "http://www.w3.org/2006/vcard/ns#"
    },
    "@type": "odrl:Agreement",
    "@id": "http://example.com/policy:8888",
    "permission": [{
        "target": "http://example.com/music/1999.mp3",
        "assigner": {
            "@type": [ "odrl:Party", "vcard:Organization" ],
            "@id":  "http://example.com/org/sony-music",
            "vcard:fn": "Sony Music LCC",
            "vcard:hasEmail": "sony-contact@example.com" },
        "assignee": {
            "@type": [ "odrl:Party", "vcard:Individual" ],
            "@id":  "http://example.com/people/billie",
            "vcard:fn": "Billie Zhan",
            "vcard:hasEmail": "billie@example.com"},
        "action": "odrl:play"
    }]
}  

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

Scope

The scope attribute SHOULD be used to indicate the context under which to interpret a Party. The purpose of scope is to provide additional information about the Party that may also reduce the extent of the Party identifier. For example, the Party identifier may refer to all users at a University, but the scope may contextualise that to only fulltime staff members at the University.

The scope attribute SHOULD be one of the following:

  • individual: indicates that a Party is a single individual. The linked Permission, Duty or Prohibition is applicable for that individual only.
  • group: indicates that a Party represents a group. The group consisting of many individual members. The linked Permission, Duty or Prohibition is applicable for each member of that group. For example, a Permission to play a movie 5 times is valid for each Party member or the Duty to pay 3 EUR has to be fulfilled by each Party member.

Other URI values for the scope attribute SHOULD be defined in the ODRL vocabulary [[!vocab-odrl]] and ODRL Profiles.

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 Party http://example.com/user44/friends, and represents all the friends of the Assigner. Since this is a collection of individuals, then the group scope is declared. In addtion, the scope of the Assignee has been also be declared as http://example.com/people/age/18+ (which, in this case, provides additional context on what characteristics the Assignee MUST hold).

{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Agreement",
    "@id": "http://example.com/policy:4444",
    "permission": [{
        "target": "http://example.com/myPhotos:BdayParty",
        "action": "odrl:display",
        "assigner": "http://example.com/user44",
        "assignee": [{
                "@id": "http://example.com/user44/friends",
                "scope": [ "http://www.w3.org/ns/odrl/2/Group", 
                           "http://example.com/people/age/18+"]	
        }]
    }]
}

Permission

A Permission specifies the Actions permitted to be performed on an Asset. An ODRL policy expression MAY contain at least one Permission.

A Permission has the following attributes:

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

Example Use Case: The ticket Policy expresses the play Permission for the target Asset http//example.com/game:9090, stating that the ticket is valid until the end of the year 2017. Any valid holder of this ticket may exercise this Permission.

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

Prohibition

A Prohibition indicates the Actions that are prohibited to be performed on the Asset.

A Prohibition has the following attributes:

Example Use Case: The owner and Assigner of a target Asset http://example.com/photoAlbum:55 needs an Agreement Policy expressing with both a Permission and a Prohibition. Then Assigner Party http://example.com/MyPix:55 assigns the Permission display to the Assignee Party http://example.com/assignee:55 at the same time they are prohibited from archiving the target Asset. Additionally, in case of any conflicts between Permissions and Prohibitions, the conflict attribute is set to perm indicating that the Permissions will take precedence.

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

Duty

A Permission MAY refer to one or more Duties which indicate obligations that MUST be fulfilled in order for the Permission to be valid. A Duty is in effect as long as its associated permission is valid (i.e., the Permission's constraints are alll satisfied). A Duty MUST only be associated with a Permission.

A Duty has the following attributes:

If a Permission refers to several Duty entities, all of them MUST be agreed to be satisfied for the Permission to be undertaken. If several Permission entities refer to one Duty, then the Duty only has to be satisfied once for all the Permission entities.

Even though a Duty is mandatory (ie agreed to be undertaken by the parties), the ODRL 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 montly invoicing.

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 this http://www.w3.org/ns/odrl/2/policyUsage must not have occured yet.

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

Example Use Case: The Party http://example.com/assigner:77 needs to set a Privacy Policy for some data about it. The target Asset http://example.com/personal-data:77 of this Policy is personal data, and the Assignee http://example.com/gov:health:au is allowed to distribute the Asset only for the purpose of contacting the subject of the Personal Data. Additionally, the Party has stipulated that the Assignee must delete the Asset after a 30 day period, i.e., a retention policy.

{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Privacy",
    "@id": "http://example.com/policy:7777",
    "permission": [{
        "target": "http://example.com/personal-data:77",
        "action": "odrl:distribute",
        "constraint": [{
            "leftOperand": "odrl:purpose",
            "operator": "odrl:eq",
            "rightOperand": "http://example.com/privacy/contact"
        }],
        "assigner": "http://example.com/assigner:77",
        "assignee": "http://example.com/gov:health:au",
        "duty": [{
            "action": "odrl:delete",
            "target": "http://example.com/personal-data:77",
            "constraint": [{
                "leftOperand": "odrl:dateTime",
                "operator": "odrl:eq",
                "rightOperand": "P30D"
            }]
        }]
    }]
}

Action

An Action indicates an operation that is applicable to an Asset. The 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 perform on the target Asset. When related to a Duty, the Action indicates the operation that is obligatory to be performed.

An Action has the following attribute:

The ODRL vocabulary [[!vocab-odrl]] defines a standard set of common Action names that MAY be used.

Example Use Case: The Party expresses an Offer policy for the target Asset http://example.com/music:1012, namely the Permission to play the Asset.

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

Constraint

A Constraint can be used to define the context in which to process Actions in Rules, such as limitations, restrictions, or interpretations that must be applied to the Actions. Constraints are a logical expression for comparing two operands by one operator. If the logical expression evalutes to true the result of the Constraint is satisfied.

Constraints can express these contexts with logical comparisions. For example, the number of usages (leftOperand) must be smaller than (operator) the number 10 (rightOperand). Constraints can also be used for complex Constraint Relations expressions that use two constraint objects as the left and right operand. For example, Constraint #1 (leftOperand) must be satisfied or (operator) Constraint #2 (rightOperand) must be satisfied.

Constraints MUST be checked by processings system at the time of executing the relevant action. If the constraint is satisfied (ie the logical expression is true) 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.

The constraint 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.

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

A Constraint has the following attributes:

In case of a Constraint expression, the leftOperand identifies the left operand of the logic expression for the Constraint. The leftOperand MAY be one of the Constraint Left Operands defined in the ODRL Vocabulary [[!vocab-odrl]] or from an ODRL Profile. In case of a Constraint Relations expression, the leftOperand MUST refer to a complete Constraint object (see Constraint Relations for further requirements).

In case of a Constraint expression, the operator identifies the logical operation such as “greater than” or “equal to” between the left and right operand. In case of a Constraint Relations expression the operator identifiers the logic relationship of two constraints using operators like 'and' or 'exclusive or'.

In case of a Constraint expression, the rightOperand identifies the right operand of the logic expression for the Constraint. 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 a URI that MUST be dereferenced to obtain the actual value. Only one between rightOperand and rightOperandReference MUST appear in the Constraint. In case of a Constraint Relations expression, the rightOperand MUST refer to an complete Constraint object (see Constraint Relations for further requirements).

In case of a Constraint expression, 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 dollars”. In case of a Constraint Relations expression, the dataType attribute MUST NOT be used.

In case of a Constraint expression, 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 alread been exercised 5 times. In case of a Constraint Relations expression, the status attribute MUST NOT be used.

Example Use Case: The Party http://example.com/myPix:6161 wants to assign the Permission distribute directly to the potential buyer of the Permission who will pay 100 EUR to be granted with the Permission. The distribute Permission is constrained to a specific country. The potential Assignee may then distribute the target Asset http://example.com/wallpaper:1234 according to the nextPolicy target Asset linked directly from this Permission. The next Policy Asset http://example.com/policy:7171 stipulates that the potential Assignee may only offer the display Permission to downstream consumers.

{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Offer",
    "@id": "http://example.com/policy:6161",
    "permission": [{
        "target": "http://example.com/wallpaper:1234",
        "assigner": "http://example.com/myPix:6161",
        "action": "odrl:distribute",
        "constraint": [{
            "leftOperand": "odrl:spatial",
            "operator": "odrl:eq",
            "rightOperand": "https://www.iso.org/obp/ui/#iso:code:3166:IT"
        }],
        "duty": [
            {
                "action": "odrl:compensate",
                "constraint": [{
                    "leftOperand": "odrl:payAmount",
                    "operator": "odrl: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": "odrl:nextPolicy",
                "target": "http://example.com/policy:7171"
            }
        ]
    }]
}
 
{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
        "@type": "odrl:Set",
        "@id": "http://example.com/policy:7171",
        "permission": [{
            "target": "http://example.com/wallpaper:1234",
            "action": "odrl:display"
        }]
    }

Constraint Relations

Constraint objects MAY also be used as both of the values for the leftOperand and rightOperand of a Constraint expression. This supports more complex Constraint Relations and allows for two constraints to be compared and processed accordingly. The two constraints MUST be atomic Constraints, that is, not a constraint that includes other Constraint Relations.

The applicable operators that can be used for Constraint Relations are:

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

The andSequence operator is an example where there are temporal conditional requirements between atomic Constraint expressions. This may lead to situations where the outcome is unresolvable, such as "deadlock" if a Constraint expression is unable to be satisfied. Processing systems SHOULD plan for these scenarios and implement mechanisms to resolve them.

The processing model for Constraint Relations includes:

  1. If the Constraint leftOperand refers to a Constraint object, then the rightOperand MUST also refer to a Constraint object.
  2. The Constraint objects both MUST be atomic Constraint expressions.
  3. The Constraint objects MUST not be the same atomic Constraint expression.
  4. The Constraint operator MUST only be of the values; or, xor, and, andSequence. Other values MAY be defined in ODRL Profiles exclusively for the use of Constraint Relations.
  5. The Constraint MUST not use the rightOperandReference, dataType, unit, or status attributes.
  6. If the Constraint operator is or then at least one of the Constraints (in the left or right operands) MUST be satisfied for the entire Constraint to be satisfied.
  7. If the Constraint operator is xor then at only one of the Constraints (in the left or right operands) MUST be satisfied for the entire Constraint to be satisfied.
  8. If the Constraint operator is and then both of the Constraints (in the left and right operands) MUST be satisfied for the entire Constraint to be satisfied.
  9. If the Constraint operator is andSequence then the left operand Constraint MUST return a satisfied result then the right operand 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": {
       "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Offer",
    "@id": "http://example.com/policy:88",
    "permission": [{
        "target": "http://example.com/book/1999.mp3",
        "assigner": "http://example.com/org/paisley-park",
        "action": "odrl:play",
        "constraint": [{
                "leftOperand": "http://example.com/policy:88/C1",
                "operator": "odrl:xor",
                "rightOperand": "http://example.com/policy:88/C2"
            }],
    }],
   "constraint": [{
       "@id": "http://example.com/policy:88/C1"
       "leftOperand": "odrl:count",
       "operator": "odrl:lteq",
       "rightOperand": "100"
   },
   {
       "@id": "http://example.com/policy:88/C2"
       "leftOperand": "odrl:dateTime",
       "operator": "odrl:lteq",
       "rightOperand": "2017-12-31"
   }]
}  

Example Use Case: The Policy below shows a Permission to distribute photos in which the first constraint (the event "football/game/2017") has concluded (the operator odrl:gt indicating this), then the second constraint (wait for 60 minutes) has passed. The operator andSequence requires that first the 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 excercised. (Note: The operator value of andSequence is not the same as and as for the latter, both operand Constraints must be satisfied, but could be processed at the same time.)

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

ODRL Profiles

Motivation

The ODRL Information Model serves as a framework to express Policies and the ODRL vocabulary [[!vocab-odrl]] provides a broad range of common actions for Permissions, Prohibition, Duties as well as Policy Types, Constraint names, Asset relations, and Party roles. For communities that implement ODRL, the entire ODRL Information Framework and the entire Vocabulary would be too onerous when they will typically have very specific needs, as well as needs not covered by the ODRL vocabulary.

In these common cases, it is strongly recommended that a community create and formally document an ODRL Profile. An ODRL Profile will directly serve the communities needs by excluding features of the ODRL Information Model that they do not require (for example, inheritance) and specifying only the terms of the ODRL Vocabulary they wish to support. In addition, the ODRL Profile may include additional vocabulary terms specific to their community.

The ODRL Profile may also include specific implementation details on how to determine the status and processing of Rules and Constraints. For example, the ODRL Profile may require the use of a thrid-party time-service to ensure temporal constraints are meet correctly (and will document the API details etc), or document the API to access values that need to be compared to the ODRL expression values (such as what location is the asset currently being used in).

Requirements

The profile attribute in a Policy is used to indicate the identifier (URI) of the ODRL Profile for which the Policy expression conforms to. This attribute is OPTIONAL, but if the attribute appears, then any consuming system MUST understand the identified ODRL Profile and all the constraints in the ODRL Profile MUST apply to the Policy expression. If a consuming system does not understand the ODRL Profile URI, then it MAY continue processing the Policy expression, but it SHOULD NOT assume it has interpreted the Policy expression correctly.

If multiple ODRL Profiles are required, then it is recommended that a new identifier SHOULD be created to identify the combination of Profiles (and document the combined Profiles).

The requirements for communities developing ODRL Profiles MUST document the following:

The community SHOULD also create a machine-readable schema for their ODRL Profile following the appropriate serialisations options outlined in the ODRL Vocabulary and Expression specification [[!vocab-odrl]]. In this case, the ODRL Profile URI MUST also be used as the serialisation namespace URI.

It is also recommended to share the ODRL Profile with the W3C ODRL Community Group for feedback and comments. In addition, the W3C ODRL Community Group may host the ODRL Profile documents on their website.

Profile Examples

An example ODRL Profile - called RightsML [[rights-ml]] was developed by the International Press and Telecommuncations Council for the communication of usage policies, primarily in association with the licensed distribution and use of news content by news gathering agencies, publishers, licensing organisations, business intermediaries and business consumers in the online news market-place. The RightsML ODRL Profile clearly documented:

The Open Mobile Alliance (OMA) developed a comprehensive ODRL Profile for the mobile community. Although it was based on the ODRL Version 1.1 specification [[odrl]], the documentation included detailed specifications on the ODRL vocabulary to be supported, new and refined terms, a protocol to exchange ODRL Expressions (over mobile phones), and the relevant encoding schemas. The documentation is available here [[oma-profile]].

Privacy Considerations

An ODRL policy can be of type "Privacy".

Need to add this section for the W3C Horizontal Review on Privacy Considerations.

Need to address the W3C PING Privacy Questions

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.

Changes from the ODRL Community Group Reports

Significant changes in this specification from the ODRL Community Group's draft include: