This document discusses the importance of providing a formal semantics for ODRL.

Introduction

• a prohibition has been infringed by an action being exercised;
• an obligation is fulfilled by an action being exercised or it is violated by an action not being performed;
• a permission is valid and allows an action to be exercised.

1. Prohibition: A Prohibition disallows an action, with all refinements satisfied, to be exercised on an Asset if all constraints are satisfied.
2. Duty: A Duty is the obligation to exercise an action, with all refinements satisfied. A Duty is fulfilled if all constraints are satisfied and if its action, with all refinements satisfied, has been exercised.
3. Permission: A Permission allows an action, with all refinements satisfied, to be exercised on an Asset if all constraints are satisfied and if all duties are fulfilled.

Scenarios

Policy Monitoring

Various autonomous agents interact in an open interaction system and perform various types of actions. These actions, with their type (e.g. a payment), various parameters (who paid, how much they paid, etc.) and the time instant at which they are done, are digitally represented in a 'world state' or 'system state'.
(What model of data (ontology) is used for representing the state of the world?)

A set of ODRL policies (P) regulate the behaviour of those agents, every policy contains some rules (R) that are prohibitions, duties, or permissions.

Policy monitoring (or compliance checking) is a continuous process that consists of computing at every instant of time:

• the set of permissions that are valid (i.e. check if all constraints are satisfied and if all duties are fulfilled);
• the set of obligations or prohibitions that are active (i.e. checking if all constraints are satisfied);
• the set of active obligations or prohibitions that are fulfilled or violated by the performance of certain actions (i.e. check if the performance of an action matches the action regulated by an active obligation or a active prohibition taking into account all the refinements used for describing the action in the policy;

Monitoring or compliance checking are useful, for example, for being able to:

• Check if I am compliant with the policies in which I am involved as a debtor. For example, a company needs to check if the behaviour of its employees is compliant with the policies attached to the digital assets used inside the company.
• Check if the policies in which I am involved as a creditor are violated. For example, I can attach to a picture the prohibition to sell it and I would like to automatically monitor if the actions performed on that picture are compliant with such a prohibition.

Simulation may be used by consumers for a what-if analysis and evaluate if the performance of an action on a digital asset will I violate one of its policies.
In this scenario, it is assumed that agents are free to perform all actions, even prohibited ones. A permission is interesting when it is an exception to a prohibition.

Access Control

Goal: Match access requests with ODRL policies determining access control to stored digital resources

Access control policies can be used to determine access by users or software agents to digital resources.

This is particularly important in decentralised systems where the users are the entities responsible to grant or deny access to the data and are responsible to define or adhere to a set of policies that satisfy their preferences.

By using these policies in an algorithm to match incoming access requests for data, a system can provide a fine-grained access control mechanism to its users.

In this scenario, if an agent does not have permission to access certain data, it will not access the data, the prohibition is regimented and cannot be violated.

Typically in this scenario, the entities responsible to grant or deny access to the data would write odrl:Offer policies (or new types of policies can be created, e.g., preference, requirement). The agent trying to access the data would write odrl:Request policies and the final agreement between the parties can be stored as an odrl:Agreement (associated with the odrl:Offer and odrl:Request policies).

License composition

Two resources differently licensed ("policed") need to be integrated in a new work. Which range of policies will be compatible with these two previous policies? Are these two policies compatible at all? The works of Governatori, Villata et al., DALICC and many others addressed this problem, but their results and ideas were never incorporated into ODRL.

Validation

ODRL is being used in a Language Resource Data Portal. Anybody can freely upload a resource, and anybody can post ODRL policies associated to them. The ids of the content resources and the assigners are verified, but the rest is left to the users. However, if they upload broken or malicious policies, they could break the system (e.g. a policy with 1 million rules). How to validate the ODRL policies so that they are conformant with a limited subset of them? ODRL Validator and Evaluator Sandbox

Planning

I want to do an action, I don't have permission to do it, what do I have to do to get permission to do it? Which is the sequence of messages to be exchanged within a protocol?

Semantics of Permission, Prohibition, and Obligation

Constraint, Refinement, Duty

• the Constraint of an ODRL Rule;
• the Refinement of the action (range Action class), of the target (range Asset class), of the assigner/assignee (range Party class) of a Rule;
• the Duty of an ODRL Permission.

• The Constraint of a Rule is a property of the Rule and must be used to express conditions for the activation or validity (when the Rule expresses a Permission) of the rule. It is crucial that the satisfaction of the constraint of a Rule can be evaluated independently from the evaluation of the action regulated by the Rule. When an ODRL rule is a permit, its validity also depends on the fulfilment of its duties.
• The Refinement of an Action, Asset, Party must be used to describe the action regulated by the Rule.

Sematics of Permission

1. Evaluate the satisfaction of the constraints on the state of the world, output: satisfied, not satisfied;
2. Evaluate the duties on the state of the world, output: fulfilled, not fulfilled (see below)
3. If the constraints are satisfied AND the duties are fullilled then the permission is valid otherwise is invalid.

1. When an action is performed (or planned or requested);
2. For every valid permission (computed as above), evaluate if the action performed satisfies its refinements (output: satisfied, not satisfied). This means to check the value of the action, target, and assigner properties.
3. If all the refinements are satisfied the permission is used (this may be important for those permissions that can only be used a limited number of times)(it is also possible that the action is prohibited by another Rule, we dicuss the semantics of Prohibitions below);
4. If one of the refinements is not satisfied the action is not permitted by the permission under examination;
5. If the action is not permitted by at least one of the permissions then there is a violation;

Sematics of Duty used as a validity condition of Permission

1. Evaluate the satisfaction of the constraints (output: satisfied, not satisfied) on the state of the world;
2. Evaluate if the action of the duty, with all refinements satisfied, has been performed (output: satisfied, not satisfied) on the state of the world.
3. If the constraints are satisfied AND the action has been performed the duty is fulfilled otherwise remains not fulfilled.
4. Once a duty has been fulfilled, it cannot become not fullilled.

Sematics of Prohibition

Sematics of Obligation

In ODRL 2.2., an Obligation

1. is active (it starts to oblige someone to do something) if all the constraints of the Rule are satisfied (the constraints of the Rule represent an activation condition see below);
2. an active Obligation becomes fulfilled when the regulated action (with all refinements satisfied) being exercised; Given that there is not a deadline the active obligation cannot become violated;
3. an obligation may have one or many consequence property values of type Duty (is it a Duty or an obligation?)

1. It is impossible to reason about deadline.

1. An activation condition is a condition that when is satisfied results in a change in the state (deontic state) of the policy/norm.
2. The satisfaction of the activation condition of a policy has to be evaluated on the state of the world (or state of the environment) where the interactions among agents are represented using a suitable notation.
3. The satisfaction of the activation condition of a policy must be evaluated independently from the action regulated by the policy and it is the first component of a policy that must be evaluated.
4. In some policy/norms models the satisfaction of the activation condition of a policy bounds some variables contained in the activation condition to the values that caused the activation condition to be satisfied. These bounded values are used also in other components of the active policy/norm.

1. Meaning of the constraint of a rule: a constraint of a Rule is expressed as 'leftOperand operator rightOperand' (for example: spatial eq Germany) where the leftOperand is a property, what is the domain of the property? For example is spatial a property having as domain the class Agent?
2. How is it possible to verify that the constraints of a Rule can be evaluated independently of the action regulated by the Rule?

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. More recent critics

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.