Abstract

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.

Status of This Document

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.

1. Introduction

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.

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

1.2 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]. For normative serialisations, please refer to the ODRL Vocabulary and Expression [vocab-odrl].

1.3 Conformance

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

1.4 Terminology

Policy
A set of Rules defining what is allowed, disallowed or obligatory over an Asset.
Rule
A set of Actions defining the precise Permissions, Prohibitions and obligations over an Asset.
Action
An operation that can be allowed by Permissions, disallowed by Prohibitions, or made obligatory by Duties.
Permission
A set of Actions that are allowed to be performed over an Asset.
Prohibition
A set of Actions that are forbidden to be performed over an Asset.
Duty
A set of Actions that are obliged to be performed for Permissions.
Asset
The subject of a Policy that Rules are applied to.
Party
An identifiable entity who undertakes a role in the Policy. e.g., a person, a group of people, an organisation, or an agent.
Constraint
The limits and restrictions to Actions in Rules.

2. Relationship to the W3C ODRL Community Group Reports

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.

3. 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 entity that holds an ODRL policy together.

ODRL Information Model
Fig. 1 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 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″.

3.1 Policy

The Policy entity has the following attributes:

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.

Example 1
{
"@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"
    }]
}
Note

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.

Example 2
{
"@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"
    }]
}

3.1.1 Policy Composition

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.

Example 3
{
    "@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:

Example 4
"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:

Example 5
"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:

  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:

Example 6
{
    "@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:

Example 7
{
    "@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:

  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.

3.1.2 Policy Provenance

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:

  • dc:creator - the individual, agent, or organisation that authored 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.

Example 8
{
    "@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": [{ ... }]
}  

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

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

  1. If a Policy has the conflict attribute of perm then any conflicting Permission Rule MUST overide 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 overide 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.

Example 9
{
"@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"
    }]
}
Example 10
{
"@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.

3.1.4 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 values:

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

Example 11
{
    "@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"
        }]
    }]
}  

3.1.5 Policy Inheritance

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 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 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 from
  • inheritRelation: the identifier of the relationship context for this inheritance

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

  • 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:

Example 12
{
    "@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.

Example 13
{
    "@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:

Example 14
{
    "@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:

  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.

3.2 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 has the following attributes:

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.

3.2.1 Relation

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:

  • The Relation entity MUST refer to the 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.

Example 15
{
 "@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"
    }]
}
Note

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

Example 16
{
 "@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"
    }]
}

3.2.2 Scope

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

Example 17
{
"@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"
    }]
}

3.3 Party

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:

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.

3.3.1 Role

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:

  • The Role entity MUST refer to the 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.

Example 18
{
    "@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"
    }]
}  
Note

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.

3.3.2 Scope

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

Example 19
{
"@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+"]	
        }]
    }]
}

3.4 Permission

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:

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.

Example 20
{
 "@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"
        }]
    }]
}

3.5 Prohibition

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

The Prohibition entity 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.

Example 21
{
"@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"
    }]
}

3.6 Duty

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:

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

Example 22
{
   "@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.

Example 23
{
"@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"
            }]
        }]
    }]
}

3.7 Action

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:

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.

Example 24
{
"@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"
     }]
}

3.8 Constraint

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:

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.

Example 25
{
"@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"
        }]
    }

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

Example 26
{
   "@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 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.)

Example 27
{
   "@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"
   }
}  

4. ODRL Profiles

This section is non-normative.

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

4.2 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. In addition, the W3C ODRL Community Group may host the ODRL Profile documents on their website.

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

5. Privacy Considerations

This section is non-normative.

Note

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

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

B. Changes from the ODRL Community Group Reports

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

C. References

C.1 Normative references

[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[dcterms]
DCMI Metadata Terms. Dublin Core metadata initiative.14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dcmi-terms/
[uml]
OMG Unified Modeling Language. Open Management Group. OMG. 1 March 2015. Normative. URL: http://www.omg.org/spec/UML/
[vocab-odrl]
ODRL Vocabulary & Expression. Renato Iannella; Michael Steidl; Mo McRoberts; Stuart Myles; James Birmingham; Víctor Rodríguez-Doncel. W3C. 21 July 2016. W3C Working Draft. URL: https://www.w3.org/TR/vocab-odrl/

C.2 Informative references

[foaf]
FOAF Vocabulary Specification 0.99 (Paddington Edition). Dan Brickley; Libby Miller. FOAF project. 14 January 2014. URL: http://xmlns.com/foaf/spec
[json-ld]
JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/
[media-frags]
Media Fragments URI 1.0 (basic). Raphaël Troncy; Erik Mannens; Silvia Pfeiffer; Davy Van Deursen. W3C. 25 September 2012. W3C Recommendation. URL: https://www.w3.org/TR/media-frags/
[odrl]
Open Digital Rights Language (ODRL) Version 1.1. Renato Iannella. W3C. 19 September 2002. W3C Note. URL: https://www.w3.org/TR/odrl
[odrl2-req]
ODRL Version 2 Requirements. Susanne Guth; Renato Iannella. ODRL Initiative. 13 February 2005. Working Draft. URL: https://www.w3.org/2012/09/odrl/archive/odrl.net/2.0/v2req.html
[odrl21-json]
ODRL Version 2.1 JSON Encoding. Jonas Öberg; Stuart Myles; Lu Ai. W3C. 5 March 2015. W3C Community Group Final Specification. URL: https://www.w3.org/community/odrl/json/2.1/
[odrl21-model]
ODRL Version 2.1 Core Model. Renato Iannella; Susanne Guth; Daniel Paehler; Andreas Kasten. W3C. 5 March 2015. W3C Community Group Final Specification. URL: https://www.w3.org/community/odrl/model/2.1/
[odrl21-onto]
ODRL Version 2.1 Ontology. Mo McRoberts; Víctor Rodríguez Doncel. W3C. 5 March 2015. W3C Community Group Final Specification. URL: https://www.w3.org/ns/odrl/2/ODRL21
[odrl21-vocab]
ODRL Version 2.1 Common Vocabulary. Renato Iannella; Michael Steidl; Susanne Guth. W3C. 5 March 2015. W3C Community Group Final Specification. URL: https://www.w3.org/community/odrl/vocab/2.1/
[odrl21-xml]
ODRL Version 2.1 XML Encoding. Renato Iannella. W3C. 5 March 2015. W3C Community Group Final Specification. URL: https://www.w3.org/community/odrl/xml/2.1/
[oma-profile]
OMA Digital Rights Management V2.2. Open Mobile Alliance (OMA). 2011. Candidate Enabler. URL: http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/drm-v2-2
[powder-primer]
Protocol for Web Description Resources (POWDER): Primer. Kai Scheppe. W3C. 1 September 2009. W3C Note. URL: https://www.w3.org/TR/powder-primer/
[rfc3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986
[rfc6570]
URI Template. J. Gregorio; R. Fielding; M. Hadley; M. Nottingham; D. Orchard. IETF. March 2012. Proposed Standard. URL: https://tools.ietf.org/html/rfc6570
[rights-ml]
RightsML. International Press Telecommunications Council. IPTC. 2013. Version 1.1 Experimental Phase 2. URL: http://dev.iptc.org/RightsML
[vcard-rdf]
vCard Ontology - for describing People and Organizations. Renato Iannella; James McKinney. W3C. 22 May 2014. W3C Note. URL: https://www.w3.org/TR/vcard-rdf/