The Open Digital Rights Language (ODRL) provides a flexible and interoperable information model, vocabulary, and encoding mechanisms for describing statements about the usage of content and services. 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, as well as the obligations required to be meet by stakeholders. In addition, policies may be integrated with constraints (e.g., time constraints) which apply to such actions to impose further restrictions to the uses of the resource.

This is a work in progress. No section should be considered final, and the absence of any content does not imply that such content is out of scope, or may not appear in the future. If you feel something should be covered, please tell us.

Introduction

Several business scenarios require expressing what are the permitted and prohibited actions over resources. These permitted/prohibited actions are usually expressed under the form of policies, i.e., expressions that indicate those uses and re-uses of the content which are conformant with 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 misuse, and for the consumers, i.e., they may know precisely what resources they are allowed to use and re-use to avoid breaking any rules, laws or the owner's constraints. This specification describes a common approach to expressing these policy concepts.

The ODRL Information Model defines the underlying semantic model for permission, prohibition, 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 this 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, prohibition, and obligation statements to be associated to content in general. These statements are employed to describe the terms of use and reuse of resources. The model should cover as many permission, prohibition, and obligation use cases as possible, while keeping the policy modeling easy even when dealing with complex cases.

The ODRL Information Model is a single, consistent model that can be used by all interested parties. 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 ODRL Information Model is built using Linked Data principles, the design is intended to allow non-graph-based implementations.

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

Terminology

Policy
A group of one or more Rules
Rule
An abstract concept that represents the common characteristics of Permissions, Prohibitions, and Duties.
Action
An operation on an Asset
Permission
The ability to perform an Action over an Asset
Prohibition
The inability to perform an Action over an Asset
Duty
The obligation to perform an Action
Asset
A resource or a collection of resources that are the subject of a Rule
Party
An entity or a collection of entities that undertake Roles in a Rule
Constraint
A boolean/logical expression that refines the applicability of a Rule, or the context of a Party or Asset collection.
ODRL Validator
A system that checks the conformance of ODRL Policy expressions with respect to the ODRL Information Model requirements.
ODRL Evaluator
A system that determines whether the permissions and prohibitions of an ODRL Policy expression are in effect.
ODRL Common Vocabulary
A set of generic terms that may be used with the ODRL core vocabulary to express Policies.
ODRL Profile
A community or sector specific vocabulary that extends the ODRL core vocabulary with new terms and/or ODRL Common Vocabulary terms to express Policies

ODRL Information Model

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

The figure below shows the ODRL Information Model.

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

The ODRL Information Model has the following classes:

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

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

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

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

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

Policy Class

The Policy class has the following properties:

The Policy class MAY also include other direct properties to support Compact Policy serialisations and references to common Constraints. These are not to be considered as direct properties of the Policy but as an intermediate step, that after applying atomic processing rules will create a Policy consistent with the normative ODRL Informantion Model.

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

Set Class

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

An ODRL Policy of subclass Set:

  • MUST have one and MAY have many relationships to a Rule.

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

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

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

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

Offer Class

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

An ODRL Policy of subclass Offer:

  • MUST have one and MAY have many relationships to a Permission or Prohibition.
  • MUST have one and MAY have many assigner property functional roles in the same Permission or Prohibition.

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

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

Agreement Class

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

An ODRL Policy of subclass Agreement:

  • MUST have one and MAY have many relationships to a Permission or Prohibition.
  • MUST have one and MAY have many assigner property functional roles in the same Permission or Prohibition.
  • MUST have one and MAY have many assignee property functional roles in the same Permission or Prohibition.

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

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

Asset Class

An Asset class is a resource or a collection of resources that are the subject of a Rule. The Asset can be any form of identifiable resource, such as data/information, content/media, applications, or services. Furthermore, it can be used to represent other Asset classes that are needed to undertake the Policy expression, such as with a Duty. An Asset is referred to by the Permission and/or Prohibition, and also by the Duty.

The Asset class has the following subclass:

The Asset class has the following properties:

If an Asset does not assert an identifier using the uid property, then the full implications must be understood, such as the impact on ODRL Validators and Evaluators of ODRL Policies.

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

Relation Property

The abstract relation property is used to create an explicit link between an Action and an Asset, indicating how the Asset MUST be utilised in respect to the Rule that links to it.

An ODRL validator MUST support the following sub-properties of relation:

  • target: indicates that the Asset is the primary subject to which the Rule action directly applies.

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

Example Use Case: The assigner Party http//example.com/party:0001 offers to display the target Asset http://example.com/asset:3333.

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

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

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

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

Part Of Property

The partOf property is used to identify an AssetCollection that an Asset resource is a member of. The purpose is to explicitly express membership relationships between Assets and AssetCollections. This enables a Rule that is related to an AssetCollection to understand which individual Assets the Rule may apply to. In addition, the Asset/AssetCollection membership relationships may potentially detect conflicts in Rules.

Example Use Case: The below snippet shows some Dublin Core metadata describing a document. The odrl:partOf property asserts that the Asset http://example.com/asset:111.doc is a member of the http://example.com/archive1011 AssetCollection which is used in the Policy in the example above. This means that http://example.com/asset:111.doc is one of the target Assets in the Policy and can my indexed.

{
   "@type": "dc:Document",
   "@id": "http://example.com/asset:111.doc",
   "dc:title": "Annual Report",
   ...
   "odrl:partOf": "http://example.com/archive1011",
   ...
}

Target Policy Property

An ODRL Policy class MAY also be referenced by the hasPolicy property. This supports ODRL Policy Rules being the object of external metadata expressions (that identifies an Asset). When hasPolicy has been asserted between a metadata expression and an ODRL Policy, the Asset being identified MUST be inferred to be the target Asset of all the Rules of that Policy. If there are multiple Rules in the Policy, then the inferred Asset will be the target Asset to every Rule in the Policy.

Example Use Case: The below snippet shows some Dublin Core metadata describing a movie Asset. The odrl:hasPolicy property links to the ODRL Policy http://example.com/policy:1010 (this is the Set Policy described above). In this case, the Asset http://example.com/asset:9999.movie is now also the target Asset for the Permission in Policy http://example.com/policy:1010. If there were additional Rules in this Policy, then the same Asset would be the target Asset to each Rule.

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

Party Class

A Party Class is an entity or a collection of entities that undertake functional roles in a Rule, such as a person, collection of people, organisation, or agent. An agent is a person or thing that takes an active role or produces a specified effect. The Party performs (or does not perform) Actions or has a function in a Duty (i.e., assigns the Party to the Rule by associating it with the function it plays in the Rule).

The Party class has the following subclass:

The Party class has the following properties:

If a Party does not assert an identifier using the uid property, then the full implications must be understood, such as the impact on ODRL Validators and Evaluators of ODRL Policies.

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

Function Property

A function property is used to link a Rule to a Party, indicating the function undertaken by the Party in respect to the Rule that links to it. The function property itself is abstract; sub-properties represent explicit semantics of the functional role between the Party and the Rule.

An ODRL validator MUST support the following sub-properties of function:

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

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

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

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

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

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

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

Part Of Property

The partOf property is used to identify a PartyCollection that a Party entity is a member of. The purpose is to explicitly express membership relationships between Parties and PartyCollections. This enables a Rule that relates to a PartyCollection to understand which individual Parties the Rule may apply to. In addition, the Party/PartyCollection membership relationships may potentially detect conflicts in Rules.

Example Use Case: The below snippet shows some vCard metadata describing a Party. The odrl:partOf property asserts that the Party http://example.com/person/murphy is a member of the http://example.com/team/A PartyCollection which is used in the Policy in the example above. This means that http://example.com/person/murphy is an assignee and can use the target asset in the Policy.

{
   "@type": "vcard:Individual",
   "@id": "http://example.com/person/murphy",
   "vcard:fn": "Murphy",
   "vcard:hasEmail": "murphy@example.com",
   ...
   "odrl:partOf": "http://example.com/team/A",
   ...
}

Assigned Policy Properties

An ODRL Policy class MAY also be referenced by the assignerOf and assigneeOf properties. This supports ODRL Policy Rules being the object of external metadata expressions (that identifies a Party). When assignerOf has been asserted between a metadata expression and an ODRL Policy, the Party being identified MUST be inferred to undertake the assigner functional role of all the Rules of that Policy. When assigneeOf has been asserted between a metadata expression and an ODRL Policy, the Party being identified MUST be inferred to undertake the assignee functional role of all the Rules of that Policy. If there are multiple Rules in the Policy, then the inferred Party will undertake the functional role to every Rule in the Policy.

Example Use Case: The below snippet shows some vCard metadata describing an individual Party. The odrl:assigneeOf property links to the ODRL Policy http://example.com/policy:1011 (this is the Offer Policy described above). In this case, the Party http://example.com/person/billie is now also the assignee of the Permission in Policy http://example.com/policy:1011. If there were additional Rules in this Policy, then the same Party would the assignee for each Rule.

{
   "@type": "vcard:Individual",
   "@id": "http://example.com/person/billie",
   "vcard:fn": "Billie",
   "vcard:hasEmail": "billie@example.com",
   ...
   "odrl:assigneeOf": "http://example.com/policy:1011",
   ...
}

Action Class

An Action class indicates an operation that can be applied to an Asset. An Action is associated with the Asset via the action property in a Rule.

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

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

The Action class has the following properties:

Action terms MUST be defined using the includedIn property referring to an encompassing Action and either use or transfer as the top-level parent term by transitive means. The purpose of the includedIn property is to explicitly assert that the semantics of the referenced instance of an other Action encompasses (includes) the semantics of this instance of Action. The includedIn property is transitive, and as such, the Actions form ancestor relationships.

The implication of the includedIn property is that a Permission or Prohibition of an encompassing Action is inherited by all Actions with an includedIn relationship. For example, if the play Action is defined as includedIn with use then if play is permitted in a Policy and use is prohibited in the same Policy - and both Actions apply to the same target Asset - then because of this asserted relationship between the two, there is conflict in the Policy. (See Policy Conflict Strategy for more details.)

The implies property asserts that an instance of Action entails that the other instance of Action is not prohibited. The implies property can be used for Action instances which have no includedIn relationship. For example, if a share Action implies explicitly the distribute Action, then if share is permitted in a Policy and distribute is prohibited in the same Policy - and both Actions apply to the same target Asset - this would cause a conflict in the Policy. If an implied other action is not prohibited then this will not cause a conflict. (See Policy Conflict Strategy for more details.)

See ODRL Profiles for usage details on the includedIn and implies properties.

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

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

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

Rule Class

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

The Rule class has the following properties:

Explicit sub-properties of the abstract relation and function properties must be used, the choice depending on the subclass of Rule in question.

For a Rule to become effective, it MUST be valid (i.e., all it's Constraints MUST be satisfied).

Permission Class

A Permission is the ability to perform an Action over an Asset. The Permission class inherits all the properties from the Rule class parent.

The Permission class is a sublcass of Rule and has the following additional property semantics:

  • A Permission MUST have one target property for Asset. (Other relation sub-properties for Asset MAY be used.)
  • A Permission MAY have none, one, or more assigner and/or assignee property function roles for Parties. (Other function sub-properties for Party MAY be used.)
  • A Permission MAY have none, one, or more duty properties for Duty.

The Duty expresses an agreed obligation that MUST be fulfilled in order for the Permission to be valid. That is, the duty property assets a pre-condition between the Permission and the Duty. For a Permission to become effective, it MUST be valid (i.e., all it's constraints MUST be satisfied) and all of the Permission's Duties MUST be fulfilled.

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

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

Prohibition Class

A Prohibition is the inability to perform an Action over an Asset. The Prohibition class inherits all the properties from the Rule class parent.

The Prohibition class is a sublcass of Rule and has the following additional property semantics:

  • A Prohibition MUST have one target property for Asset. (Other relation sub-properties for Asset MAY be used.)
  • A Prohibition MAY have none, one, or more assigner and/or assignee property function roles for Parties. (Other function sub-properties for Party MAY be used.)

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

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

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

Duty Class

A Duty is the obligation to perform an Action. The Duty specifies agreed Actions that MUST be fulfilled. The Duty class inherits all the properties from the Rule class parent.

The Duty class is a sublcass of Rule and has the following additional property semantics:

  • A Duty MAY have none or one target property for Asset to indicate the Asset that is the primary subject to which the Duty directly applies. (Other relation sub-properties for Asset MAY be used.)
  • A Duty MAY have none, one, or more assigner and/or assignee property function roles for Parties. (Other function sub-properties for Party MAY be used.)

The Duty class also has these additional requirements:

  • The assignee MUST have the ability to perform the Duty Action.
  • The assignee(s) of the Duty MUST satisfy the Duty.

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

Example Use Case: The below Agreement includes an obligation from assigner http://example.com/org:43 to assignee http://example.com/person:44 to compensate the assigner for payment of EU500.00.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:42",
    "obligation": [{
	"assigner": "http://example.com/org:43",
	"assignee": "http://example.com/person:44",
	"action": "compensate",
	"constraint": [{
		"leftOperand": "payAmount",
		"operator": "eq",
		"rightOperand": "500.00",
		"unit": "http://dbpedia.org/resource/Euro"
        }]
    }]
}

Duty with a Permission

A Duty MAY be specified as a pre-condition that requires fulfillment in order to make a Permission effective using the duty property from the Permission to the Duty. In this case the Permission is valid (including the Permission's constraints all being satisfied) if and only if the Duty has been fulfilled.

If there are no assigner and/or assignee properties declared in the Duty, then these functional roles will be the same as those declared in the refering Permission.

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

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

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

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

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

Constraints

Constraints are boolean/logical expressions that refines the applicability of a Rule, or the context of a Party/Asset Collection. Constraints can be represented as a Constraint class or Logical Constraint class. A Logical Constraint will refer to existing Constraints as its operands. The evaluation of a Constraint is treated as a black box from an external system with the outcome of this evaluation determinig if the Constraint has been satisfied or not.

ODRL Processors MUST check if a Constraint is satisfied at the time of processing the relevant Action, or Party/Asset Collection. For a Rule, if the Constraint is satisfied then the action becomes effective for the enclosing Rule. For a Party/Asset Collection, if the Constraint is satisfied, then the (individual) Asset or Party member(s) - a subset of the Collection - becomes effective for the enclosing Rule.

When multiple Constraints apply to the same Rule, Party/Asset Collection then they are interpreted as conjunction. A Rule becomes effective if all of its Constraints are satisfied. Parties and Assets (members of the Collection) become effective is all of the Constraints on Party/Asset Collections are satisfied.

Constraint Class

A Constraint class is used for expressions which compare two operands by one operator. If the expression evaluates to true the Constraint is satisfied. The Constraint class can express these contexts with comparison expressions, such as, the number of usages (leftOperand) must be smaller than (operator) the number 10 (rightOperand).

The Constraint class has the following properties:

  • A Constraint MUST have one leftOperand property for Left Operands.
  • A Constraint MUST have one operator property for relational Operators.
  • A Constraint MUST have either one rightOperand property for right operand values (literal or IRI [[!rfc3987]]) or one rightOperandReference property for an IRI [[!rfc3987]] reference to a right operand value.
  • A Constraint MAY have none or one dataType property for the data type of the rightOperand/Reference.
  • A Constraint MAY have none or one unit property for the unit value of the rightOperand/Reference.
  • A Constraint MAY have none or one status property for the current value generated from the leftOperand action.

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

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

The rightOperand identifies the right operand of the logic expression. The rightOperand is the value (a literal or IRI) of the Constraint that is to be compared to the leftOperand. The rightOperandReference represents an IRI that MUST be de-referenced first to obtain the actual value of the rightOperand. A rightOperandReference is used in cases where the value of the rightOperand MUST be obtained from dereferencing an IRI first. Only one of rightOperand or rightOperandReference MUST appear in the Constraint.

The rightOperand represents a value and the rightOperandReference represents an IRI that must be de-referenced to obtain the value. If the rightOperand was http://example.com/c100 then that is interpreted as the value to be compared in the expression. If the rightOperandReference was the same value of http://example.com/c100, then that IRI must be de-referenced first and the data returned must be interpreted as the value to be compared in the 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 currency”.

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

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

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

Logical Constraint Class

A Logical Constraint class are expressions for logically comparing two or more operand values - with the operand values being a list of existing Constraints. For example, three Constraints could be logically and-ed indicatinfg that all three must be true for the Logical Constraint to be satisfied.

The Logical Constraint class has the following properties:

  • A Logical Constraint MUST have one operand sub-property indicating the logical relationship.

An ODRL validator MUST support the following sub-properties of operand:

  • or - at least one of the Constraints MUST be satisfied
  • xone - only one of the Constraints MUST be satisfied
  • and - all of the Constraints MUST be satisfied

Other operand sub-properties MAY be defined in the ODRL Common Vocabulary [[!odrl-vocab]] or defined by ODRL Profiles.

The processing model for Logical Constraints includes:

  1. The operand MUST only be of the sub-properties; or, xone, and. Other sub-properties of operand MAY be defined in the ODRL Common Vocabulary [[!odrl-vocab]] or by ODRL Profiles exclusively for the use of Logical Constraints.
  2. All of the operand values MUST be unique Constraint instances.
  3. The Constraint instances MUST be evaluated and the outcomes used to determine if the logical relationship is satisfied (based on the semantics of the operand sub-property).

Example Use Case:The Policy below shows a Permission to reproduce the target asset either via online media or print media but not both.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:88",
    "permission": [{
        "target": "http://example.com/book/1999",
        "assigner": "http://example.com/org/paisley-park",
        "action": "reproduce",
        "constraint": {
             "xone": ["http://example.com/p:88/C1", "http://example.com/p:88/C2"]
            },
    }],
   "constraint": [{
       "uid": "http://example.com/p:88/C1",
       "leftOperand": "media",
       "operator": "eq",
       "rightOperand": "online"
   },
   {
       "uid": "http://example.com/p:88/C2",
       "leftOperand": "media",
       "operator": "eq",
       "rightOperand": "print"
   }]
}  

When Constraints appear at the Policy-level then they MUST only be referenced by a Logical Constraint within an existing Rule. They MUST not to be interepreted as Constraints on all the Rules in the Policy.

Asset Constraint

Constraints MAY be applied to an AssetCollection to indicate the context under which to identify the individual Asset(s) that are effective to the Rule. The constraint applies to the characteristics of each member of the collection (and not the resource as a whole).

Note that when using Constraints, the uid property MUST NOT be used to identify the AssetCollection. Instead, the source property MUST be used to reference the AssetCollection.

Example Use Case: The Policy defines a target source http://example.com/media-catalogue that is an AssetCollection of multimedia videos. The target also has a constraint that specifies further context on the characteristics of the AssetCollection members. In this case, the target subset of Assets will be thoses that have a running time of less than 60 minutes, and each of those may be played.

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

 {
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:4444",
    "profile": "http://example.com/profiles/01",
    "permission": [{
        "assigner": "http://example.com/org88",
        "target": {
            "@type": "AssetCollection",
            "source":  "http://example.com/media-catalogue",
            "constraint": [{
                "leftOperand": "ex:runningTime",
                "operator": "lt",
                "rightOperand": "60",
                "unit": "http://qudt.org/vocab/unit/MinuteTime"
            }],
        },
        "action": "play"
    }]
}

Party Constraint

Constraints MAY be applied to a PartyCollection to indicate the context under which to identify the individual Parties that are effective to the Rule. The constraint applies to the characteristics of each member of the collection (and not the resource as a whole).

Note that when using Constraints, the uid property MUST NOT be used to identify the PartyCollection. Instead, the source property MUST be used to reference the PartyCollection.

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

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

Policy Rule Composition

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

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

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

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

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

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

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

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

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

Compact Policy

An ODRL Policy MAY hold properties, declared at the Policy-level, which are shared and common to all its Rules. This is aimed only as a short-cut method to support more compact serialisations. These shared properties MUST NOT be interpreted as Policy-level properties (such as those defined in the Policy Class section).

Properties that MAY be shared include:

  • The action property.
  • Any sub-properties of relation (such as target).
  • Any sub-properties of function (such as assigner and assignee).

The processing model for expanding short-cuts in a Policy is:

  1. For each Rule in the Policy:
    • Verify any relevant shared properties (at the Policy-level).
    • Replicate these properties in the Rule.
  2. Remove the shared properties declared at the Policy-level

Further, follow the processing model to create atomic Rules in the Policy (defined in the previous section).

It is RECOMMENDED that compact ODRL Policies be expanded to atomic Policies when being processed for conformance or exchanged for interoperability, to reflect the normative ODRL Information Model.

The example below shows such shared common properties applied to a Policy:

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

The example below shows how these shared properties are expanded to the Permissions of the Policy following the processing rules above.

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

Policy Metadata

Additional properties MAY be added to a Policy to support further 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]] properties SHOULD be used:

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

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

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

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

Policy Inheritance

ODRL supports an inheritance mechanism in which a (child) Policy may inherit all the atomic Rules of one or more (parent) Policies.

The following property MUST be used in a child Policy that is inheriting from a parent Policy: :

The following apply when using inheritance:

Example Use Case: Consider the (parent) Policy http://example.com/policy:default below (the assigner wishes to provide default permissions for all Policies). It does not refer to any target Asset and allows the archive and annotate Permissions and disallows the aggregate Prohibition.

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

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

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

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

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

The processing model for ODRL Policy Inheritance includes:

  1. The (child) Policy MUST access the (parent) Policy and replicate the following in the (child) Policy:
    • All policy-level Assets, Parties, Actions from the (parent) Policy.
    • All Rules from the (parent) Policy.
  2. Repeat the above for each identified (parent) Policy.
  3. The (child) Policy can then be further expanded (into atomic Rules) by following the processing models defined in the Policy Composition section.

Policy Conflict Strategy

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

The conflict property SHOULD take one of the following Conflict Strategy Preference values:

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

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

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

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

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

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

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

ODRL Evaluator

This is a suggestion for how such a (normative) section might be included.

The task of an ODRL Evaluator is to determine which Rule(s) are in effect for a given Asset and, if relevant, to which Party the Rule(s) apply. The method by which this is achieved is left to individual implementations but a key task is to determine whether or not constraints have been satisfied. Again, the processes by which this determination is made is not defined, however, it is expected that the result of such a determination is a binary satisfied|not satisfied.

Example 1 simply states that permission is granted to play the Asset http://example.com/asset:9898.movie. The output of an ODRL Evaluator SHALL therefore simply be:

Permission to play http://example.com/asset:9898.movie

Example 2 extends this by including the assigner and so the output of the Evaluator SHALL be:

http://example.com/party:org:abc grants Permission to play http://example.com/asset:9898.movie

Example 3 extends this further by defining a specific Party to which the Rule applies so the output SHALL be:

http://example.com/party:org:abc grants Permission to http://example.com/party:person:billie to play http://example.com/asset:9898.movie

An Evaluator MUST have a means of evaluating constraints or passing such processing to some external process and receiving a satisfied|not satisfied response. If an Evaluator is unable to determine whether or not a constraint has been satisfied then the response SHALL be:

Not Known

Example 13 includes the constraint that the assignee http://example.com/org:xyz gives permission to play http://example.com/game:9090 on or after 31 December 2017. Therefore, up to and including 30 December 2017, the output of an ODRL Evaluator SHALL be:

No rules in effect

Where no rules are in effect, the policy is effectively silent on what actions may or may not be performed. Continuing with Example 13, from 31 December 2017 onwards, the output SHALL be:

http://example.com/org:xyz gives permission to play http://example.com/game:9090

Example 14 introduces the conflict resolution property (and does not include any constraints). The output of an ODRL Evaluator SHALL be:

http://example.com/MyPix:55 grants Permission to http://example.com/assignee:55 to display http://example.com/photoAlbum:55. http://example.com/MyPix:55 Prohibits http://example.com/assignee:55 from Archiving http://example.com/photoAlbum:55. In the case of conflict, the Permission takes precedence.

And so on. Note that an id attribute has been added to all examples in the doc for cross-referencing. ReSpec doesn't do this for you (surprisingly). Local CSS class of Rule defined for this - change at will, obviously.

ODRL Profiles

ODRL Profile Purpose

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

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

ODRL Core Profile

In circumstances that require the ODRL Core Profile to be identified, that is the Policy only conforms to the ODRL Core Vocabulary, then the following identifier MAY be used: http://www.w3.org/ns/odrl/2/core

ODRL Profile Mechanism

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

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

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

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

Additional Party Functional roles - create a sub-property of the abstract function property:

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

The new Action MAY be defined as includedIn to any existing Action.

If the new Action forms a dependency with another new or existing Action, then define the two actions with the implies property:

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

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

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

Additional Logical Constraint operands - create a sub-property of the abstract operand property:

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

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

  • :myRule rdfs:subClassOf :Rule ;
  • owl:disjointWith :Prohibition, :Duty :Permission ;
  • All new classes, properties, and instances must also be defined as a skos:Concept. Appropriate rdfs:domain and rdfs:range should also be defined.

    Human-readable documentation is also recommended for each new term using rdfs:label for the name, skos:definition for the formal definition, and skos:note for additional comments on its use.

    Privacy Considerations

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

    Acknowledgements

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

    Relationship to the W3C ODRL Community Group Reports

    The basis for the deliverables for the Permissions & Obligations Expression Working Group are the reports created by the W3C ODRL Community Group. The ODRL Community Group has developed a family of specifications to support innovative expression of asset usage for the publication, distribution and consumption of content services. The final outputs of the ODRL Community Group were the ODRL Version 2.1 specifications that were a major update for ODRL and superseded the original ODRL Version 1.1 [[odrl]] (published as a W3C NOTE).

    The following documents are part of the ODRL Community Group report series:

    The ODRL Information Model was derived from the ODRL V2.1 Core Model Community Group report. Details of the differences between the W3C Working Group deliverables and the ODRL Community Group Reports are maintained in the Appendix. All new ODRL implementations are expected to use the deliverables of the Permissions & Obligations Expression Working Group.

    Changes from Previous Versions

    Changes from the First Public Working Draft 21 July 2016:

    Changes from the Working Draft 23 February 2017: