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.

The ODRL permissions and obligations expression language provides a flexible and interoperable information model, vocabulary, and encoding mechanisms for describing statements about digital content usage. The ODRL Information Model describes the underlying concepts, entities, and relationships that form the foundational basis for the semantics of the ODRL statements.

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 digital 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 digital 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 digital 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 digital 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 permissions and obligations statements describing digital 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 digital 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 digital content in general. These permission and obligation statements are employed to describe the terms of use and reuse of digital 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 digital 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 ODRL Information Model is formally specified using UML notation [[!uml]].

The examples throughout the document are serialized as [[JSON-LD]].

Terminology

Relationship to the W3C ODRL Community Group Reports

The basis for the deliverables for the Permissions & Obligations Expression Working Group are the reports created by the W3C ODRL Community Group. The ODRL Community Group has developed a family of specifications to support innovative expression of digital asset usage for the publication, distribution and consumption of content services. The final outputs of the ODRL Community Group were the 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 basic context of an ODRL Policy is that only an explicitly permitted use may be executed. Any use not explicitly permitted is prohibited by default. An ODRL Policy only permits the action explicitly specified in a Permission and all other actions are implicitly prohibited. An action defined in a Prohibition should only refine (or directly relate to) the semantics of an action defined in one of the Permissions in the ODRL Policy.

For example, an ODRL Policy that has the action “present” Permission and may also have the action “print” Prohibition (as these actions are related hierarchically in the ODRL Vocabulary [[!vocab-odrl]]).

Note that ODRL Profiles can be developed and used to refine the basic context of an ODRL Policy. Hence, the application of an ODRL Profile must be understood by the consuming community and systems.

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

ODRL Information Model
ODRL Information Model

As the Information Model diagram shows the key Permission, Prohibition and Duty entities are subtypes of the abstract Rule class and they have the same relationships to the other key entities (Action, Constraint, Asset, and Party). The core difference is in their semantics:

The Rule class also makes it possible to easily extend the Information Model in Profiles by adding policy expressions (as subclasses of Rule) that are not possible by default.

The cardinalities shown in the ODRL Information Model allow for the greatest flexibility in expressing associations between the key entities. However, Policy Types and ODRL Profiles may express narrower and/or specific cardinalities on these entities.

A Permission MAY allow a particular Action to be executed on a related Asset, e.g. “play the audio file abc.mp3”. A Constraint like “at most 10 times” might be added to specify the Permission more precisely. The Party that grants this Permission is linked to it with the Role assigner, the Party that is granted the Permission is linked to it with the Role assignee, e.g. “assigner VirtualMusicShop grants the Permission to assignee Alice”. Additionally, a Permission MAY be linked to Duty entities.

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 EUR in order to get the Permission to play abc.mp3″.

The Prohibition entity is used in the same way as Permission, with the difference that it MUST NOT refer to Duties and that the Action MUST NOT be exercised, e.g. “Alice is forbidden to use abc.mp3 commercially”.

The following sections describes each entity of the Information Model in greater detail.

Policy

The Policy entity is the top-level entity and contains the following attributes:

The uid attribute MUST be a unique identifier.

The range of values for the Policy entity’s type attribute will be described in the ODRL Vocabulary [[!vocab-odrl]] or in ODRL Profiles. This value MAY also impose further constraints on the Information Model, such as are exemplified in the Scenarios for types Offer and Agreement. It is important that the type attribute be clearly understood in policy expressions as the semantics MAY impose restrictions on the expression language constructs such as cardinalities between entities.

The conflict attribute is used either to resolve conflicts arising from the merging of policies, specifically when there are conflicting Actions in the Permissions and Prohibitions, or to set priorities over the Permissions/Prohibitions in the same policy. If present, the conflict attribute MUST take one of the following values:

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

Need to clarify conflicting values of the conflict attribute. That is, one policy says perm and the other prohibit.

The undefined attribute is used to indicate how to support Actions that are not part of any profile in the policy expression system. If present, the undefined attribute MUST take one of
the following values:

In the support case, even though the Action is unknown, the policy still is valid and the consuming parties or system of the policy MUST be made aware of the unknown Action. This MAY be via a user interface that displays the unknown Action for human readability.

In the ignore case, even though the Action is unknown, the policy still is valid and the consuming parties or system of the policy MAY be made aware of the unknown Action.

In the invalid case with the unknown Action, the policy is invalid and the consuming parties or system of the policy MUST be made aware of this.

If the undefined attribute is not explicitly set, its default value will be used instead. The default value of the undefined attribute is invalid.

Other attributes MAY be added to the Policy entity to support additional functions and requirements. Typically, these will be from different community vocabularies. For example, to indicate the issued date or valid dates of the Policy entity, use of the Dublin Core Metadata Terms would be recommended.

Inheritance

We need to make clear exactly what gets inherited and what gets overriden (if anything)

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 inheritance
  • false: the Policy expression can not be used for inheritance

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

Only if the inheritAllowed attribute has the value true MAY the following be used:

  • inheritFrom: the identifier from which this Policy inherits from it’s parent Policy (OPTIONAL)
  • inheritRelation: the identifier for the relationship type of this inheritance structure (OPTIONAL)

The 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 type of inheritance from the (parent) Policy. For example, this may indicate the business scenario, such as subscription, or prior arrangements between the parties (that are not machine representable). Such terms MAY 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:

  • 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 cannot be circular.
  • The Child Policy MUST override the Parent Policy. i.e.: If the same Action appears in the Parent, then it is replaced by the Child version, otherwise the Parent Actions are added to the Child’s Actions.
  • No state information is transferred from the policy in the Parent Policy to the Child Policy

Asset

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 contains the following attribute:

The identification of the Asset entity is a key foundation of the ODRL Policy language. However, there are some use cases where the ODRL Policy expression MAY be embedded inside the target Asset. In these cases, it MAY be more appropriate to provide, or infer, a link to the Asset entity (as the complete Asset uid may not be known at the time) through the local context. Use of such inference and context MUST be documented in the relevant ODRL Profile.

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 used to associate the Asset entity with the relevant Permission, Prohibition, and Duty entities

Relation

The Relation entity is an association class and can be used to link to an Asset from either Permission, Duty or Prohibition, indicating how the Asset MAY be utilised in respect to the entity that links to it.

The Relation entity contains the following attribute:

  • relation: indicates the relationship of the Asset to the linked entity (REQUIRED)

The default value for the relation attribute is target which indicates that the Asset is the primary object to which the Permission, Duty or Prohibition actions apply.

Target is formally defined in the ODRL Vocabulary [[!vocab-odrl]]

Other values for the Relation entity MAY be defined in the ODRL Vocabulary [[!vocab-odrl]] and ODRL Profiles.

Party

The Party entity is the object of an ODRL policy and can be any form of identifiable entity. 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 can be any form of identifiable entity, such as a person, group of people, organisation, or agent. An agent is a person or thing that takes an active role or produces a specified effect.

The Party entity contains the following attributes:

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

The Role entity is used to associate the Party entity with the relevant Permission, Prohibition, and Duty entities.

Role

The Role entity is an association class and can be used to link to a Party from either Permission, Duty or Prohibition, indicating which role the Party takes with respect to the entity that links to it.

The Role entity contains the following attributes:

  • function: the functional role the Party takes (REQUIRED)

The function attribute MUST support the following values:

  • assigner: indicates that the Party has assigned the associated Permission, Duty, or Prohibition. In other words, the Party grants a Permission or requires a Duty to be performed or states a Prohibition.
  • assignee: indicates that the Party has been assigned the associated entity, i.e. they are granted a Permission or required to perform a Duty or have to adhere to a Prohibition.

Assignee and Asignee are formally defined in the ODRL Vocabulary [[!vocab-odrl]]

Other values for the function attribute MAY be defined in the ODRL Vocabulary [[!vocab-odrl]] and ODRL Profiles.

The scope attribute MAY be used to indicate the context under which to interpret the Party entity. If present, the scope attribute MAY 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 (constrained) 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 values for the scope attribute MAY be defined in the ODRL Vocabulary [[!vocab-odrl]] and ODRL Profiles.

Permission

The Permission entity indicates the Actions that the assignee is permitted to perform on the associated Asset. In other words, what the assigner (supplier) has granted to the assignee (consumer).

An ODRL policy expression MAY contain at least one Permission. It is important to verify the semantics of the Policy type attribute as this MAY indicate additional constraints on the Policy expression structure.

If several Permission entities are referred to by a Policy, then all of them are valid.

The Permission entity has the following relations:

Duty

The Duty entity indicates a requirement that MUST be fulfilled in return for being entitled to the referring Permission entity. A Duty MUST only be associated with a Permission.

While implying different semantics, the Duty entity is similar to Permission in that it is an Action that can be undertaken. If a Permission refers to several Duty entities, all of them MUST be fulfilled for the Permission to become valid. If several Permission entities refer to one Duty, then the Duty only has to be fulfilled once for all the Permission entities to become valid.

The Duty entity contains the following attributes:

The Duty entity has the following relations:

A Duty entity does not by default specify any conditions on when the Duty Action MUST be performed in order for the Permission to be exercised. Such temporal conditions MAY be expressed through additional Constraints.

For example, to support cases where the Duty MUST be performed for each Action on an Asset before it is exercised (for example, a pay-per-view scenario) then the use of a Constraint (e.g. count=1) on the Permission (e.g. play) and a temporal (or event) Constraint on the Duty can express this semantics.

Prohibition

The Prohibition entity indicates the Actions that the assignee is prohibited to perform on the related Asset. Prohibitions are issued by the supplier of the Asset – the Party with the Role assigner. If several Prohibition entities are referred to by a Policy, all of them must be satisfied.

The Prohibition entity has the following relations:

Action

The Action entity (when related to a Permission entity) indicates the operations (e.g. play, copy, etc.) that the assignee (i.e. the consumer) is permitted to perform on the related Asset linked to by Permission. When related to a Prohibition, the Action entity indicates the operations that the assignee (again the consumer) is prohibited to perform on the Asset linked to by Prohibition. Analogously, when related to a Duty, it indicates the operation to be performed.

Action contains the following attribute:

As its value, the name attribute MAY take one of a set of Action names which are formally defined in profiles. The ODRL Vocabulary [[!vocab-odrl]] defines a standard set of potential terms that MAY be used. Communities will develop new (or extend existing) profiles to capture additional and refined semantics.

Constraint

The Constraint entity indicates limits and restrictions to the Permission, the Prohibition and the Duty entity. Constraints express mathematical terms with two operands and one operator. For example, the “number of usages” (name) must be “smaller than” (operator) the “number 10” (rightOperand).

If multiple Constraint entities are linked to the same Permission, Prohibition, or Duty entity, then all of the Constraint entities MUST be satisfied. That is, all the Constraint entities are (boolean) anded. In the case where the same Constraint is repeated, then these MUST be represented as a single Constraint entity using an appropriate operator value (for example, isAnyOf).

The Constraint entity contains the following attributes:

The name identifies the left operand of the mathematical operation for the Constraint such as “Number of Usages” and “Expiration Date” etc. The operator identifies the comparative operation such as “greater than” or “equal to”. The rightOperand identifies the value that is being compared. The dataType indicates the type of the rightOperand, such as “decimal” or “datetime” and the unit indicates the unit value of the rightOperand, such as “EU dollars”.

When processing policy expressions, these Constraint names MAY be directly linked to a procedure that can determine the outcome of the operations, such as the number of already performed usages and the current date. The name and operator are defined in the ODRL Vocabulary [[!vocab-odrl]] or ODRL Profiles.

The status provides the current value of the Constraint variable (i.e. current value of name). This is useful in cases where the current status of Constraints needs to be captured and expressed in the ODRL Information Model.

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

Requirements

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.

Profile Example

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:

Scenarios

This section shows a number of policy expression scenarios. In these examples, the different policy expression types that are used are for illustrative purposes only and are not part of this normative specification. Also, the specific Action and Constraint names (etc.) used in these examples are for illustrative purposes only. Please note that formal policy expression types and other entities are defined in the ODRL Vocabulary specification, or in community profiles.

Need to clarify if these Scenarios need to be udated.

Set

An instance of a Set Policy
An instance of a Set Policy
See this scenario in supported encodings.

Offer

An instance of an Offer Policy
An instance of an Offer Policy
See this scenario in supported encodings.

Agreement

An instance of an Agreement Policy
An instance of an Agreement Policy
See this scenario in supported encodings.

Request

An instance of an Request Policy
An instance of an Request Policy
See this scenario in supported encodings.

Ticket

An instance of an Ticket Policy
An instance of an Ticket Policy
See this scenario in supported encodings.

Offer and Next Policy

An instance of an Offer and Next Policy
An instance of an Offer and Next Policy
See this scenario in supported encodings.

Privacy

An instance of an Privacy Policy
An instance of an Privacy Policy
See this scenario in supported encodings.

Permission and Prohibition

An instance of an Permission and Prohibition Policy
An instance of an Permission and Prohibition Policy
See this scenario in supported encodings.

Inheritance

Is this last statement true?

An instance of an Inheritance Policy
An instance of an Inheritance Policy
See this scenario in supported encodings.

Social Network

An instance of an Social Network Policy
An instance of an Social Network Policy
See this scenario in supported encodings.

Multiple Assets

An instance of an Multiple Assets Policy
An instance of an Multiple Assets Policy
See this scenario in supported encodings.

Experimental Features

Should this section be included in a W3C REC?

This section contains advanced ODRL features. Although not part of the normative specification, they provide an opportunity for communities to experiment with and provide feedback on experiences that may be included in future ODRL versions.

Extended Relations

Extended Relations may tie Permission, Prohibition, Duty, and Constraint entities together with an AND, OR or XOR relationship. Only entities of the same type can be linked with this model. For example, a Permission and Prohibition cannot be linked together within this model. The Extended Relations model supports the following attribute:

The following table outlines the semantics of Extended Relations with respect to each of the main entity types.

Permission Prohibition Duty Constraint
OR The related party may perform any (at least) one of the Actions The related party MAY NOT perform at least one of the Actions The related party MUST perform at least one of the Actions The related Permission/Prohibition/Duty is restricted by at least one of the Constraints
AND The related party MUST perform all of the Actions The related party MAY NOT perform all of the Actions The related party MUST perform all of the Actions The related Permission/Prohibition/Duty is restricted by all of the Constraints
XOR The related party MAY perform only one of the Actions The related party MAY NOT perform only one of the Actions The related party MUST perform only one of the Actions The related Permission/Prohibition/Duty is restricted by only one of the Constraints.

Note that Extended Relations are not needed to assign two or more Permissions to a Party entity. In this case simply use as many Assignee relations between Party and Permission as needed.

Remedies

This section will be removed from the next release.

In the ODRL Information Model, Duties are only directly related to Permissions, meaning that for a Permission to become effective, the related Duty should be performed. For some use cases though, it might be useful to attach a Duty to a Prohibition, meaning that if a Prohibition is violated, the Duty has to be performed as a kind of remedy or consequence for the violation.

Not only can a Prohibition have a Duty attached to it as a remedy, even Duties themselves may have remedies, e.g. “For the Permission to play audio file xyz to become effective, you have to perform the Duty ‘pay 2€’. If you don’t perform this Duty (even though you’ve played yxz), you have to remedy this by performing the Duty ‘pay 5€'”.

In order to distinguish between a Duty that has to be fulfilled as a requirement and one that has to be fulfilled as a remedy, different relation names are introduced as shown in the Figure below.

Remedy Model
Remedy Model

The relation between Permission and Duty, which was unnamed before, is now named hasRequirement. This is needed not only to make the different semantics clearer, but also because a Duty can refer to yet another Duty as a requirement, e.g. “If you want to print this written article, you have the Duty to attach a particular image of the author, and if you do that, you have the Duty to attribute the image to the photographer”.

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. The output of the ODRL Community Group was fundamental to the current model.

In particular the editors would like to thank:

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: