This document specifies the expected behaviour of an ODRL Evaluator, a piece of software that performs computations based on a set of policies and a certain state of the world.

Introduction

The Open Digital Rights Language (ODRL) is a policy expression language that can be used to represent permitted, prohibited, and obligated actions over a certain asset.

The ODRL Information Model formally defines the core abstract concepts of the model and their properties by means of an OWL 2 Ontology (available at https://www.w3.org/ns/odrl/2/), which is described in the ODRL Vocabulary & Expression specification.

The ODRL ontology can be used as a data model to represent machine-readable Policies and associate them with digital or analog assets. By using a machine-readable language to represent policies, ODRL implementations can provide useful functionalities such as those of a policy search engine, a policy compatibility checker, an access control system, a monitoring system, or a policy planning system, among others.

• which Permissions, Prohibitions, and Obligations (collectively named Rules) are active in a given instant of time. A Rule is said to be active if it is in effect;
• which Prohibitions and Obligations have been violated or fulfilled.

When the ODRL Evaluator evaluates Permissions, it is expected to work in at least one of these two scenarios:

1. Access control scenario: the ODRL Evaluator determines the access by users or software agents to digital resources considering a set of policies, the state of the world, and the description of the action that a user requests to perform on certain digital resources. It is possible to distinguished between requested and attempted action. When an agent attempts to perform an action, e.g. an agent double-clicks on a picture, if the action is not permitted the attempt is recorded and if it is the case sanctioned. In the case of a request, only the answer is generated: either the action is permitted or the action is denied.
2. Policy monitoring scenario (or compliance checking): given a set of policies and the description of the state of the world that includes the actions actually performed, the ODRL Evaluator has to determine whether obligations or prohibitions have been fulfilled or violated by the performance of certain actions, and which permissions are active.

More precisely, the ODRL Evaluator uses as input:

• a collection of ODRL Policies;
• a formal description of the state of the world;
• a formal description of the requeted or performed action by a given user who is located in a given place.

The ODRL Evaluator requires a formal representation of the state of the world. This state of the world may include current date, current location of the agents, or the history of performed actions. This document does not formally specify how to represent the necessary entities (e.g. country codes). The formal representation of the world can be a set of RDF triples. The existence of these triples does not entail their represented world is a reality: the factuality of the class instances is not entailed, and hypothetical computations are possible. The implementor of the ODRL Evaluator may want to describe the factuality of relevant class instances. RDF triples to represent the state of the world may be generated as observations from the world generated by third parties (extrinsic), by the ODRL Evaluator user or by any other source (intrinsic).
For example it is crucial to represent in the state of the world:

• the current time of the state of the world;
• temporal entities, like instants or intervals with a start and end time that can be represented by re-using the Time Ontology in OWL;
• a list of languages from a taxonomy (e.g. iso639);
• the parties involved in a given state that have a odrl:function within the policies.
• actions are described in RDF by specifying at least:
  • the type (a list of actions types is available in the ODRL Common Vocabulary);
  • the agent who is the performer of the action;
  • the object upon which the action is carried out;
  • the instant of time at which the action occurs or begins, which is represented with the atTime property.

Semantics of Policies

There are three ODRL Policy subclasses (Agreement, Offer, Set), plus four non-normative ODRL Policy subclasses (Assertion, Privacy, Request, Ticket). Direct instances of the odrl:Policy class must be understood as policy odrl:Set policies. This subsection describes how are these policies to be understood in relation to semantics.

• A odrl:Set policy must be considered by an ODRL Evaluator. The odrl:Set is not necessarily linked to odrl:Offer nor odrl:Agreement.
  
• An odrl:Offer policy must not be considered by an ODRL Evaluator. It is created by an odrl:Assigner as a mere proposition.
• An odrl:Agreement policy must be considered by an ODRL Evaluator as any other odrl:Set policy. It represents the accord between (at least) one odrl:Assigner and a odrl:Assignee. An instance of odrl:Agreement may have a way for the odrl:Assigner to trace to its related odrl:Offer.

Semantics of Permissions, Prohibitions, and Obligations

The deontic modalities of permissions, prohibitions and obligations can be represented in ODRL as instances of the classes odrl:Permission, odrl:Prohibition and odrl:Duty.

Instances of the class odrl:Duty may have the following different meanings in ODRL:

• An instance of the class odrl:Duty is an Obligation of a odrl:Policy when the odrl:Policy refers to it by means of the odrl:obligation property.
• An instance of the class odrl:Duty represents a Condition for a odrl:Permission when the odrl:Permission refers to it by means of the odrl:duty property.
• An instance of the class odrl:Duty represents a Consequence for a odrl:Duty when the odrl:Duty refers to it by means of the odrl:consequence property.
• An instance of the class odrl:Duty represents a Remedy for a odrl:Prohibition when the odrl:Prohibition refers to it by means of the odrl:remedy property.

In addition to this:

• An instance of the class odrl:Constraint is a Constraint of a odrl:Rule when the rule refers to it by means of the odrl:constraint property.
• An instance of the class odrl:Constraint is a Refinement when an odrl:Action, odrl:AssetCollection or odrl:PartyCollection refers to it by means of the odrl:constraint property.

The concepts (objects) to be understood by an ODRL Evaluator therefore include: Policy, Permission, Prohibition, Obligation, Condition (Duty), Consequence, Remedy, Refinement, Constraint, State of the World, and actions. Here follows a list of properties (with their possible values) needed by the ODRL Evaluator:

• Permission, Prohibition, Obligation, and Condition (Duty) have a property called activation state, which can take the values of active or inactive.
• Prohibition, Obligation, and Condition (Duty) have a property called deontic state, which can take the values of not-set, or violated, or fulfilled. They can become violated or fulfilled only when they are active.
  An active prohibition can be violated many times by different actions, therefore when a prohibition is violated it is required to register the action that brings to the violation.
  
• Permission has a property called control state, which can take the values of permit or deny of a specific action.
• Constraint (connected to the Rule using the odrl:constraint property) has a property called satisfaction state which can take the values of satisfied or not-satisfied. A not-satisfied constraint may become satisfied and return to being not-satisfied. The value of the satisfaction state of a Constraint is calculated according to the state of the world. Constraints directly defined at policy level are not directly considered.
• Refinement (connected to an Action, to an AssetCollection, or to a PartyCollection using the odrl:refinement property) has a property called satisfaction state which can take the values of satisfied or not-satisfied.

The mechanisms for computing the activation of Permissions, Prohibitions, and Obligations and the violation or fulfillment of Prohibitions and Obligations are all different. Therefore we continue by discussing the semantics of Permissions, Prohibitions, and Obligations in separated sections.

Semantics of Permissions

In ODRL 2.2 a Permission can be limited by duties, like making a payment, we call these Conditions. It can also be limited by Constraints (in time, in space, etc.). In addition, the definition of the permitted action, the asset, and the party collection can be refined with Refinements. The evaluation of these Conditions (duties) and Constraints determine whether the Permission is active (i.e., it permits the performance of an action that belongs to the class of action regulated by the permission and that satisfies all the refinements) or not. Permissions can be evaluated in two different scenarios: access control or monitoring.

In the access control scenario: when an action is requested, the activation of permissions is computed. If there is an active permission that permits such an action with all refinements satisdied, then action is permitted. If there is not an active permission that permits such an action with all refinements satisdied, then action is denied.

In the monitoring scenario: when an action is performed, it is represented in the state of the world. When the performace of the action has to be evaluated with respect to the permissions. If the performed action belongs to class of actions (with all refinements satisfied) regulated by an active permission, then the action is permitted. if there is no active permission to do such an action (with all refinements satisfied) and the default setting for the ODRL Evaluator is set to "everything is prohibited unless explicitly permitted" a violation should be generated.

Expected behaviour of the ODRL Evaluator

The ODRL Evaluator computes that a Permission is active if:

1. all the existing Constraints of the Rule are satisfied and;
2. all the existing Conditions (duties of the Rule) are fulfilled or inactive;

If one of those conditions is not met, the Permission is inactive.

In the following examples of permissions, as we will analyse one permission at a time, we will not deal with the generation of violations for permissions.

Evaluation of Constraints and Refinements

Please note that in the following examples namespaces are used, so that http://example.com/constraint/ is simplified by "constraint:", http://example.com/policy/ is simplified by "policy:", etc.

Example of a constrained permission

Example description

A permission may have its action limited (in time, in space, etc.) without any Condition (Duty) or Refinement. This is the situation of the following case, similar to Example 13 in the ODRL Information Model 2.2. The permission below allows the target asset document:1234 to be distributed, it includes the constraint that the permission may only be exercised until 2018-01-01. The permission is granted by the organization party:16.

            {
            "@context": "http://www.w3.org/ns/odrl.jsonld",
            "@type": "Set",
            "uid": "http://example.com/policy/13",
            "permission": [{
               "target": "http://example.com/document/1234",
               "assigner": "http://example.com/party/16",
               "action": "distribute",
               "constraint": [{
                   "@id": "http://example.com/constraint/1",
                   "leftOperand": "dateTime",
                   "operator": "lt",
                   "rightOperand":  { "@value": "2018-01-01", "@type": "xsd:date" }
               }]
            }]
            }
            

Expected behaviour of the Evaluator

The ODRL Evaluator has to calculate first the activation state of the permission. The constraint must be evaluated on the state of the world, which must include a representation of the current time. As long as the current time is before the first day of 2018, the Permission is active. When the first day of 2018 is passed, the Permission is inactive.
The class of actions regulated by this Permission has type equal to distribute and object equal to the target of the permission, i.e. document:1234.

• (E-13-1) If the requested or perfomed action belongs to the class of actions regulated by the Permission and the Permission is active then the action is permitted.
• (E-13-2) If the requested or perfomed action belongs to the class of actions regulated by the Permission, but the Permission is inactive, then, assuming that only this Permission is considered (this is because other permissions could regulate this action), the action is denied.
• If the requested or perfomed action does not belong to the class of actions regulated by the Permission then assuming that only this Permission is considered (this is because other permissions could regulate this action), the action is denied.

The table below shows the input (blue) and the output (red) of the ODRL Evaluator in different cases.

Example of a permission whose permitted action is refined

Example description

The example below is similar to Example 14 in the ODRL Information Model 2.2. It allows the target asset document:1234 to be printed and also include a refinement indicating that the resolution of the printing action must be less than or equal to 1200 dpi. The permission is granted by the organization party:616.

        {
             "@context": "http://www.w3.org/ns/odrl.jsonld",
             "@type": "Set",
             "uid": "http://example.com/policy/14",
             "permission": [{
                "target": "http://example.com/document/1234",
                "assigner": "http://example.com/party/616",
                "action": [{
                   "rdf:value": { "@id": "odrl:print" },
                   "refinement": [{
                      "@id": "http://example.com/refinement/14"
                      "leftOperand": "resolution",
                      "operator": "lteq",
                      "rightOperand": { "@value": "1200", "@type": "xsd:integer" },
                      "unit": "http://dbpedia.org/resource/Dots_per_inch"
                    }]
                }]
              }]
        }
        

Expected behaviour of the Evaluator
The class of actions regulated by this Permission has type equal to print and its object is equal to the target of the permission, i.e. document:1234.

Access control or monitoring scenario:

The Permission is always active because it has neither Constraints nor Conditions (Duties). Given a formal description a performed action.

• (E14-1) If the requested or performed action belongs to the class of actions regulated by the Permission and the action satisfies the Refinement, then the permission permits the action.
• (E14-2) If the requested or performed actions belongs to the class of actions regulated by the Permission but it does not satisfy the Refinement, then the permission does not permit the action.

Evaluation of Conditions (Duties)

When a Permission contains Conditions (duties), they have to be evaluated first.

A Condition (duty) is fulfilled if all its constraints are satisfied and if its action, with all refinements satisfied, has been performed.

1. The initial state of a Condition (duty) is inactive.
2. If at least one of the Constraints of the Condition (duty) is not satisfied, then the duty is inactive. (For example, the duty to pay a ticket to get an active permission to enter in a museum may be active only on Sundays and inactive the other days).
3. If the Constraints of the Condition (duty) are all satisfied or there are no Constraints, then the duty is active.
4. If the Condition (duty) is active and an action that belongs to the class of actions regulated by the Condition with all refinements satisfied is performed, then Condition (duty) is fulfilled.

The life cycle of a Condition (duty) is depicted in the figure below:

Once the Condition (duty) has been evaluated, the Permission can be evaluated.
If the Condition is active but it is not fullfilled then the Permission is inactive.
If the Condition is fulfilled then the Permission is active.

Example of a conditioned permission

Example description

The example below (similar to Example 22 in the ODRL Information Model 2.2) is a Permission that is constrained by a Condition (Duty). The Condition does not have Constraints, but its action has a refinement. This permission is granted by party:sony for party:billie to play the target asset music:1999. The permission includes the Condition to perform the compensate action that has a refinement of payAmount of euro 5.00. The semantics of Permission requires that the compensate action (included in the duty) must be performed before the play action in order to get an active permission to perform the play action.

        {
        "@context": "http://www.w3.org/ns/odrl.jsonld",
        "@type": "Agreement",
        "uid": "http://example.com/policy/22",
        "permission": [{
            "assigner": "http://example.com/party/sony",
            "assignee": "http://example.com/party/billie",
            "target": "http://example.com/music/1999.mp3",
            "action": "play",
            "duty": [{
               "@id" : "http://example.com/condition/1",
               "action": [{
                  "rdf:value": { "@id": "odrl:compensate" },
                  "refinement": [{
                     "@id" : "http://example.com/refinement/1",
                     "leftOperand": "payAmount",
                     "operator": "eq",
                     "rightOperand": { "@value": "5.00", "@type": "xsd:decimal" },
                     "unit": "http://dbpedia.org/resource/Euro"
                  }]
                }]
            }]
        }]
        }  
        

Expected behaviour of the Evaluator

The class of actions regulated by this Permission has type equal to play, object equal to the target of the permission, i.e. music:1999.mp3, and performer equal to the assignee of the permission, i.e. party:billie.

The condition (duty) have to be evaluated first. condition:1 does not have Constraints, so it is never inactive. It starts to be active and it is fulfilled when in the state of the world there is a representation of a performed action that matches with the the class of actions described in the condition:1.

The class of actions regulated by condition:1 has type equal to compensate, its payAmount is equal to 5 euro, and (given that the odrl:compensatedParty of the odrl:compensate action is not specified) its beneficiary is the assigner of the permission party:sony. It is not required that the agent who performs the compensate action is party:billie because, for example, a company can pay for its employees (feature for an ODRL profile: it would be useful for actions of compensation or payment to contain a reference to a policy or a rule and to the party for whom they are performed).

Access control or monitorin scenario:

Given a formal description of the requested or performed action, if such an action belongs to the class of actions regulated by the Permission and the Permission is active, then the action is permitted, otherwise it is denied.

Example of a permission whose condition has constraints

Example description

This policy contains a Permission constrained by a Condition (duty) (like in policy:22) with the difference that such Condition has constraints, it is only activated on Sundays.

        {
        "@context": "http://www.w3.org/ns/odrl.jsonld",
        "@type": "Agreement",
        "uid": "http://example.com/policy/88",
        "permission": [{
            "assigner": "http://example.com/party/sony",
            "assignee": "http://example.com/party/billie",
            "target": "http://example.com/music/1999.mp3",
            "action": "play",
            "duty": [{
                "@id" : "http://example.com/condition/1",
                "action": [{
                    "@id" : "http://example.com/action/payment",
                    "rdf:value": { "@id": "odrl:compensate" },
                    "refinement": [{
                        "@id" : "http://example.com/refinement/1",
                        "leftOperand": "payAmount",
                        "operator": "eq",
                        "rightOperand": { "@value": "5.00", "@type": "xsd:decimal" },
                        "unit": "http://dbpedia.org/resource/Euro"
                    }]
                }],
                "constraint": [{
                    "@id" : "http://example.com/constraint/1",
                    "leftOperand": "ex:dayOfWeek",
                    "operator": "eq",
                    "rightOperand": { "@value": "Sunday", "@type": "xsd:string" }
                }]
            }]
        }]
        }  
        

Expected behaviour of the Evaluator

The class of actions regulated by this Permission has type equal to play, object equal to the target of the permission, i.e. music:1999.mp3, and performer equal to the assignee of the permission, i.e. party:billie.

The class of actions regulated by condition:1 has type equal to compensate, its payAmount is equal to 5 euro, and (given that the odrl:compensatedParty of the odrl:compensate action is not specified) its beneficiary is the assigner of the permission party:sony.

condition:1 has to be evaluated first. Given that condition:1 has constraints it starts to be inactive and it becomes active when its Constraints are all satisfied (the state of the world satisfies its Constraints, i.e. the current date is a Sunday. For expressing this constraint an external vocabulary with the leftOperand ex:dayOfWeek is used). An active Constraint, it is also fulfilled when in the state of the world there is a representation of an performed action that matches with the class of actions described in the Constraint.

The permission can be evaluated as follows:
If the Condition is inactive (its Constraint is not satisfied), the Permission is active.
If the Condition is active but it is not fullfilled, the Permission is inactive.
If the Condition is fulfilled the Permission is active.

Access control or monitoring scenario:

Semantics of Prohibitions

• not-set when the regulated action with all refinements satisfied has not been performed;
• violated when the regulated action with all refinements satisfied has been performed;

Evaluation of a prohibition with constraints

Example description

This is example is similar to Example 19 in the Information Model, with the differences that it has not a related permission and it has a Constraint. In this case, there is a prohibition that is constrained by a constraint. The policy below is a formal Agreement between two parties (the assigner and the assignee) that the action of archiving the specified digital asset is prohibited. The prohibition is specifically active before the first day of 2025.

        {
        "@context": "http://www.w3.org/ns/odrl.jsonld",
        "@type": "Agreement",
        "uid": "http://example.com/policy/55",
        "prohibition": [{
            "@id" : "http://example.com/prohibition/1",
            "target": "http://example.com/photoAlbum:55",
            "action": "archive",
            "assigner": "http://example.com/MyPix:55",
            "assignee": "http://example.com/assignee:55",
            "constraint": [{
               "@id" : "http://example.com/constraint/1",
               "leftOperand": "dateTime",
               "operator": "lt",
                "rightOperand":  { "@value": "2025-01-01", "@type": "xsd:date" }
           }]
        }]
        }
        

Expected behaviour of the Evaluator

The prohibition has an activation state and a deontic state that have to be calculated.

In this example, the Constraint must be evaluated on the state of the world. As long as the current time is before the first day of 2025 the Prohibition is active. After that date the Prohibition is inactive. When the prohibition is active, a violation occurs if the prohibited action is performed.

Sematics of Obligations

• fulfilled when the regulated action with all refinements satisfied is performed;
• violated when the regulated action with all refinements satisfied can no longer be performed;
• not-set when the regulated action with all refinements satisfied can be performed but has not been so far.

Evaluation of an obligation without constraints

Example description

This example of derived from Example 20 in the Information Model. It describes an obligation that is not constrained by a Constraint. The policy below is a formal Agreement between two parties (the assigner and the assignee) that the action to compensate the assigner for a payment amount of EU500.00 is obliged.

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

Expected behaviour of the Evaluator

The Evaluator must determine the activation state and the deontic state of the obligation. The Obligation is always active. If the obliged action is performed then the obligation is fulfilled.

Previous efforts

Documents on "formal semantics" in W3C specifications

The RDF1.1. Semantics defines a model-theoretic semantics to determine the validity of RDF inference processes. A similar approach is followed by the OWL Semantics, a recommendation providing the direct model-theoretic semantics for OWL 2 and definingthe most common inference problems.

XPath (XML Path Language) is a language that can be used to navigate through elements and attributes in an XML document, and it also has formal semantics. XQuery (XML Query) is a query and functional programming language to query XML data. The "XQuery and XPath Formal Semantics" intends to complement the specification by defining the meaning of XQuery/XPath expressions with mathematical rigor; thus clarifying the intended meaning of the English specification, and ensuring that no corner cases are left out. For that regard grammar productions are given.

The POWDER specification provides a mechanism to describe and discover Web resources, and it also includes a Formal Semantics document. POWDER documents are XML documents which can be automatically converted, through a GRDDL transform, into a semantically rich version in RDF (POWDER-S). The "semantics" document describes how to make such transformation.

The PROV Ontology Working Group has produced 12 specifications to facilitate the interchange of provenance information in the Web (where provenance is …information about entities, activities, and people involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness"). Besides having published a PROVO Ontology to facilitate the expression of provenance as RDF, the family of documents also define an EBNF notation "which allows serializations of PROV instances to be created in a compact manner", a set of constraints to "ensure that a PROV instance represents a consistent history of objects and their interactions that is safe to use for the purpose of logical reasoning" and statements in the PROV Data Model are seen "as atomic formulas in the sense of first-order logic […and…] the constraints and inferences specified in PROV-CONSTRAINTS as a first-order theory".

ODRL Formalization

ODRL was created in in the early 2000's as an XML dialect to represent rights expressions to be used in the framework of Digital Rights Management systems; and its version 1.1 gained much spread [ODRL02]. Different ODRL profiles extended the vocabulary to satisfy the needs in different sectors. In 2011, an ODRL W3C Community Group was established, publishing soon after a new version 2.1 with major changes which included a new information model [Ianella15], a vocabulary [Ianella15b] and an Ontology [McRoberts15]. ODRL 2.1 became then a policy language.Other specifications in XML and similar to ODRL were MPEG-21 Rights Expression Language [Wang94], XACML or MPEG-21 Contracts Expression Language [Rodríguez15]. The MPEG-21 Media Contracts Ontology [Rodriguez16] defines an ontology to guide the generation of contracts as RDF, with a similar philosophy to that of the ODRL Ontology.

RDF documents instantiating the "Policy" class of the ODRL Ontology or using the XML or JSON syntaxes are called simply "ODRL Policies". The ODRL Ontology is already a formalization of the ODRL information model and vocabulary. The ontology of the version 2.1 consists of 1111 axioms with low complexity, but a comprehensive definition of each element (classes and relations) and a systematic definition of domains and ranges for the properties. Some ODRL concepts are represented as SKOS concepts ordered in SKOS collection. Reasoning with the ontology would be computationally inexpensive, but the usefulness of the possible reasoning tasks with the ontology is very limited.

The ODRL 2.1 Ontology is not the first ODRL Ontology and other ontologies had been proposed before [García05][Kasten10]. However, neither these ontologies nor the ODRL 2.1 Ontology directly supported any reasoning tasks of practical use. Other more generic rights ontologiesexist, claiming tocomprise the concepts of ODRL, with the ambition of facilitating interoperability. Thus, Delgado (2003) and Nadah (2007) have proposed ontologies as a bridge to make transformation between rights expression languages like ODRL and MPEG-21 REL, whereas Rodríguez (2013) underlined the similarities of seven policy languages with an ontology design pattern. Other alternative means of achieving interoperability do not require ontologies, as Guth did (2003) defining an abstract object model.

Some other formalizations of ODRL have been proposed with the purpose of determining whether a request is permitted given a set of policies and a certain history of events:we can name this task as theauthorisation decision.With that purpose, Gunter and Pucella had defined general logics for rights (2001 and 2002 respectively). Pucella then extended his work to model ODRL1.1 statements (2004) as formulas in a many-sorted first-order logic with equality,to determinewhether a permission was implied by a set of ODRL statements. Holzer et al. (2004) also enriched the authorisation decision modelling the dynamic aspects of licenses with finite-automata like structures (useful when the property of an asset is transferred, or when the number of plays is limited to a certain number of times). Chong et al. (2006) modelled licenses with multiset rewritingand logic programming (Prolog), including the ability to evaluate and merge licenses and to track the dynamic aspects of the rights evolution. Barth and Mitchell (2006) observed that the authorisation decision of a sequence of actions given a set of ODRL licenses is NP-complete because of the interval constraints, and proposed using propositional linear logic to grant efficient computability. Sheppard and Sfavi(2009) defined an algorithm for the authorisation decision with some of the most common ODRL elements, giving the pseudo-code for a virtual machine. Steyskal and Polleres (2015) defined an abstract syntax for expressing ODRL policies, where the dependencies among ODRL actions and the different conflict resolution strategies were explicitly considered in the rules for taking the authorisation decision.

Besides the problems of facilitating interoperability and making the authorisation decision, other problems of interest have been modeled with formalizations of ODRL. One of them is how to evaluate the compatibility and composition of licenses, useful when handling with differently licensed content or data. In this line, Gangadharan et al. (2007)proposed a matchmaking algorithm to analyze the compatibility of licenses and make license compositions; Jamkhedkarand Heileman (2008) showed how the combination of ODRL, CreativeCommons REL and the XrML (embryo of the MPEG-21 REL) licenses was possible with an abstract model and several rules. Villata and Gandon (2012) also defined a framework with algorithms to validate compatibility and to obtain composite licenses. Rotolo et al. (2013) defined a deontic logic system for the composition of licenses, with strict rules, defasible rules and defeater rules.

It is evident that some policies can be used to grant automated access to resources. For example, verifying the execution of a payment can be automatically done. However, the satisfaction of some constraints cannot be digitally evaluated. Policies then play a double role, as automatable expressions in a computer system and as constracts with a certain legal value. Steyskal and Kirrane (2015) show how to use ODRL to specify access requests, data offers and agreements, distinguishing between enforceable and non-enforceable access policies, proposing an algorithm to auto-generate contracts for the latter.

In more recent efforts, de Vos et al. (2019) transforms ODRL expressions into Answer Set Programming to model policies and check compliance – specifically in the area of personal data processing, where ODRL has also been recently used (Esteves et al. 2021). Other profiles and initiatives have been proposed (Kim et al. 2020), on despite of several limitations found by Kebede at al. (2020).

In Fornara and Colombetti (2019) the ODRL 2.2 policy language has been extended in two directions. Firstly, by inserting in the model the notion of activation event, secondly, by considering the temporal aspects of obligations, permissions, and prohibitions (e.g. expiration dates and deadlines) as part of the application independent model of policies.