Copyright © 2017 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
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 section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This is a work in progress. No section should be considered final, and the absence of any content does not imply that such content is out of scope, or may not appear in the future. If you feel something should be covered, please tell us.
This document was published by the Permissions & Obligations Expression Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-poe-comments@w3.org (subscribe, archives). All comments are welcome.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 September 2015 W3C Process Document.
This section is non-normative.
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.
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 ODRL Information Model is formally specified using UML notation [uml].
The examples throughout the document are serialized as [json-ld]. For normative serialisations, please refer to the ODRL Vocabulary and Expression [vocab-odrl].
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, OPTIONAL, SHALL, SHOULD, and SHOULD NOT are to be interpreted as described in [RFC2119].
This section is non-normative.
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.
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 entity that holds an ODRL policy together.
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 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″.
The Policy entity has the following attributes:
uid
identification of the Policy entity.type
indicating the specific type of Policy entity.conflict
attribute indicating how to handle Policy conflicts.undefined
attribute indicating how to handle undefined Actions.inheritAllowed
attribute indicating the Policy entity can be inherited by other Policies.profile
identifier that this Policy conforms to.The values for the Policy entity’s 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 Information Model entities, 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 Informatin 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"
}]
}
The ODRL Information Model supports flexibility in the composition of the information entities used to declare ODRL expressions. 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 irreducible and unambiguous.
{
"@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",
"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": "..."
}]
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": "..."
}]
"permission": [{
"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:
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": [{
"target": "http://example.com/music/1999.mp3",
"assigner": "http://example.com/org/sony-music",
"action": "odrl:play",
"assignee": "http://example.com/people/billie"
},
{
"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:
Provenance attributes MAY be added to the Policy entity 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:
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": [{ ... }]
}
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.
For example, one Policy stated that Assignee Fred had been granted an "exclusive" distribution Permission, and the other Policy said the same for Assignee Mary. In the same Policy, conflicts can also arise when the same Action is used in a Permission and a Prohibition.
The conflict
attribute MUST take one of the following values:
perm
: the Permissions MUST override the Prohibitionsprohibit
: the Prohibitions MUST override the Permissionsinvalid
: the entire Policy MUST be invalid if any conflict is detectedIf the conflict
attribute is not explicitly set, the default value 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:
conflict
attribute of perm
then any conflicting Permission Rule MUST overide the Prohibition Rule and continue with the Policy as valid.conflict
attribute of prohibit
then any conflicting Prohibition Rule MUST overide the Permission Rule and continue with the Policy as valid.conflict
attribute of invalid
then processing MUST not continue and the entire Policy MUST be invalid.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 toperm
. 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, theperm
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.
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 values:
support
: the undefined Action is to be supported as part of the Policy – and the Policy remains validignore
: the undefined Action is to be ignored and is not part of the Policy – and the Policy remains validinvalid
: the undefined Action is unknown – and the entire Policy is invalidIn 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 value of invalid
SHALL be used.
The processing model for undefined actions includes:
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.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.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.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": "invalid",
"permission": [{
"target": "http://example.com/music/1999.mp3",
"action": "http://example.com/ns/recorded"
}]
}]
}
ODRL supports a simple inheritance mechanism in which a (child) Policy may inherit all the information compositions of another (parent) Policy. The inheritance is aimed at including data compositions between Policies.
The inheritAllowed
attribute in the Policy entity 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 values:
true
: the Policy expression can be used for inheritancefalse
: the Policy expression can not be used for inheritanceIf the inheritAllowed
attribute is not explicitly set, its default value of true
will be used.
The following attributes 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 frominheritRelation
: the identifier of the relationship context for this inheritanceThe inheritFrom
association in the (child) Policy will uniquely identify (via a UID) the (parent) Policy from which the inheritance will be performed.
The inheritRelation
attribute in the (child) Policy will uniquely identify (via a UID) the context of inheritance from the (parent) Policy. This may indicate the business scenario, such as subscription, or prior arrangements between the Parties (that are not machine representable). Such terms SHOULD be defined in the ODRL vocabulary [vocab-odrl] or ODRL Profiles.
For example, an Assigner and Assignee may have a historical arrangement related to the specific use of content they make available to each other. The business model (identified with a URI) is used in the
inheritRelation
attribute in their subsequent ODRL Policies they exchange. This will require the ODRL Policy to be interpreted with the additional information identified by the URI. For example, this may include additional permission Actions or constraints (etc) that is documented in their business model arrangement.
Both the inheritFrom
association and inheritRelation
attribute may be used independently.
The following restrictions apply when using inheritance:
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"
}],
"permission": [{
"assignee": "http://example.com/guest:0002",
"action": "odrl:print"
}]
}
After the inheritance is performed - where the (parent) Policy information compositions 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"
}],
"permission": [{
"assignee": "http://example.com/guest:0002",
"action": "odrl:print"
}],
"permission": [{
"action": "odrl:use"
}]
}
The processing model for ODRL Policy Inheritance includes:
inheritFrom
attribute MUST first verify that the (parent) Policy does not contain the inheritAllowed
attribute with the value "false".The Asset entity is the subject of an ODRL policy expression that Permissions and Prohibitions are applied to. The Asset entity can be any form of identifiable resource, such as data/information, content/media, applications, or services. Furthermore, it can be used to represent other Asset
entities that are needed to undertake the Policy expression, such as with the Duty entity. The Asset entity is referred to by the Permission and/or Prohibition entities, and also by the Duty entity.
The Asset entity has the following attributes:
uid
identification of the Assetscope
defining how the Asset shall be interpreted under different contexts.The identification of the Asset entity 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.
The Relation entity is an association class and is used to link to an Asset from either Rule, indicating how the Asset SHOULD be utilised in respect to the entity that links to it.
The Relation entity has the the following attribute:
relation
indicating the relationship of the Asset to the Rule.The default value for the relation
attribute is target
which indicates that the Asset is the primary object to which the Rule actions apply.
Other values for the Relation entity 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"
}]
}
The scope
attribute SHOULD be used to indicate the context under which to interpret the Asset entity. 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"
}]
}
The Party entity 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).
The Party entity has the following attributes:
uid
identification of the Partyfunction
role fulfilled by a Party.scope
defining how the role shall be interpreted under different contexts.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.
The Role entity is an association class that is used to link a Party from a Rule, to indicate what Role the Party takes with respect to the entity that links to it.
The Role entity has the following attributes:
function
role the Party is undertaking.The function
attribute MUST support the following role values:
assigner
: indicates the Party that is issuing the Policy. For example, the Party granting a Permission or requiring a 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 a Duty.Other values for the function
role 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.
The scope
attribute SHOULD be used to indicate the context under which to interpret the Party entity. 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 take one of the following values:
individual
: indicates that the Party entity is a single individual. The linked Permission, Duty or Prohibition is applicable for that individual only.group
: indicates that the Party entity 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+"]
}]
}]
}
The Permission entity specifies the Actions permitted to be performed on an Asset. An ODRL policy expression MAY contain at least one Permission.
The Permission entity has the following attributes:
target
Asset on which the identified Action MAY be performed. Other relation
values for Asset MAY be used.role
functions undertaken by Party entities. Other role
function values for Party MAY be used.constraint
s. The Permission becomes effective if all of the constraints are satisfied.duty
/ies. The Duty expresses an obligation that MUST be fulfilled before the Permission being granted.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"
}]
}]
}
The Prohibition entity indicates the Actions that are prohibited to be performed on the Asset.
The Prohibition entity has the following attributes:
target
Asset on which the identified Action MUST NOT be performed. Other relation
values for Asset MAY be used.role
functions undertaken by Party entities. Other role
function values for Party MAY be used.constraint
s. The Prohibition becomes effective if all of the constraints are satisfied.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"
}]
}
A Permission entity MAY refer to a Duty entity that indicates a requirement that MUST be satisfied for Permissions to become valid. A Duty MUST only be associated with a Permission.
The Duty entity has the following attributes:
role
functions to be undertaken by Party entities. Note: If no explicit role is specified as Assignee or Assigner, the Parties with the respective Roles are taken from the referring Permission. Other role
function values for Party MAY be used.target
Asset on which the identified Action MUST be performed. Other relation
values for Asset MAY be used. For example, a nextPolicy
Action MUST be linked to the identifier of a target Policy asset.constraint
s. The Duty becomes effective if all of the constraints are satisfied.If a Permission refers to several Duty entities, all of them MUST 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 entity is mandatory, the ODRL model does not specify any 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 thepayAmount
of $AUD5.00 and the second is theevent
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"
}],
"constraint": [{
"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. The purpose value is taken from the P3P privacy purpose vocabulary. Additionally, the Party has stipulated that the Assignee must delete the Asset after a 30 day period, i.e., 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://www.w3.org/2002/01/P3Pv1#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"
}]
}]
}]
}
The Action entity indicates the operations that are permitted to be performed on the target Asset when related to a Permission entity. When related to a Prohibition, the Action entity indicates the operation that is prohibited to be perform on the target Asset. When related to a Duty, the Action entity indicates the operation that is obligatory to be performed.
The Action entity has the following attribute:
name
.The ODRL vocabulary [vocab-odrl] defines a standard set of common Action names that MAY be used.
Example Use Case: The Party needs to define an Offer policy granting a Permission 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"
}]
}
The Constraint entity can be used to define restrictions to the Permission, the Prohibition and the Duty 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 limitations 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 which entity is 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
.
If multiple Constraint entities are linked to the same Permission, Prohibition, or Duty entity, then all the Constraint entities within the Rule MUST be satisfied. That is, all the Constraint entities are (boolean) anded together. If the same Constraint is repeated within the same Rule, then these Constraints MUST be represented as a single Constraint entity using an appropriate operator
value (for example, isAnyOf
).
The Constraint entity has the following attributes:
leftOperand.
operator
function.rightOperand
(Note: only if no rightOperandReference appears.)rightOperandReference
(Note: only if no rightOperand appears.)dataType
of the rightOperand.unit
s of the rightOperand.status
of the current value generated from the leftOperand action.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 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 satisfiedxor
- only one of the Constraints (in the left or right operand) MUST be satisfiedand
- both of the Constraints (in the left and right operand) MUST be satisfiedandSequence
- 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:
leftOperand
refers to a Constraint object, then the rightOperand
MUST also refer to a Constraint object.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.rightOperandReference
, dataType
, unit
, or status
attributes.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.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.operator
is and
then both of the Constraints (in the left and right operands) MUST be satisfied for the entire Constraint to be satisfied.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.
{
"@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"
},
"constraint": {
"@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 passed) is statisfied, then the second constraint (wait for 60 minutes) is processed, and is then satisfied. (Note: The
operator
value ofandSequence
is not the same asand
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:gteq",
"rightOperand": "http://example.com/football/game/2017"
},
"constraint": {
"@id": "http://example.com/policy:88/C2"
"leftOperand": "odrl:delayPeriod",
"operator": "odrl:gteq",
"rightOperand": "P60M"
}
}
This section is non-normative.
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).
The profile
attribute in the Policy
entity 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.
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].
This section is non-normative.
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
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.
Significant changes in this specification from the ODRL Community Group's draft include: