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

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.

However, neither the specification of the model (in a text form) nor the vocabulary (in an OWL ontology) accurately describes the behaviour of an ODRL implementation. Therefore this specification defines the expected behaviour of an ODRL Evaluator. (A previous proposal of an ODRL evaluator is available here: https://www.w3.org/2016/poe/wiki/Evaluator.)

The ODRL Evaluator is expected to work in at least one of these two scenarios:

  1. Access control scenario: the 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 attempts to perform on certain digital resources.
  2. Policy monitoring scenario (or compliance checking): given a set of policies and the description of the state of the world that includes the performed actions, the evaluator has to determine whether obligations or prohibitions have been fulfilled or violated by the performance of certain actions, and which permissions have been used.
We assume that (attempted or performed) actions are described in RDF by specifying at least: its type (a list of actions types is available in the ODRL Common Vocabulary), the agent that is the performer of the action, the object upon which the action is carried out, the atTime when the action happens or starts.

More precisely, given: the objective of the ODRL Evaluator is to determine:

This document describes the expected behaviour of this ODRL Evaluator, with a textual description, a formal semantics and a collection of examples.

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.

  • The ODRL Evaluator requires a formal representation of the state of the world to perform computations on both the access control and the policy monitoring scenarios. This state of the world may include current date, current location of the assignee 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).
    Some examples of these state of the world RDF triples are:

    Semantics of Permission, Prohibition, and Obligation

    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:
    Here follows a list of properties (with their possible values) needed by the ODRL Evaluator: The process for computing the satisfaction state of Constraints, the satisfaction state of Refinement, and the performance state of an Action is left to individual implementations. But given these values, all ODRL Evaluators should agree on the value of the activation state and deontic states of the rules.

    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.

    Sematics of Permission

    In ODRL 2.2., a Rule that belongs to the odrl:Permission class is active (the action is permitted) if: If one of those conditions is not met, the Permission is inactive.

    When an action (with all the refinements satisfied) regulated by an active permission is performed the permission is used.

    In the access control scenario: When an action is attempted, if one of its property values does not satisfy the refinements of the permission, and there is not another active permission that permits such an action, it means that the action is not permitted and it is blocked.

    In the monitoring scenario: When an action is performed (and it is represented in the state of the world), if there is no active permission to do so (i.e. there is no active permission regulating a class of action to which the executed action belongs) and the default setting for the ODRL Evaluator is set to "everything is prohibited unless explicitly permitted" a violation is generated. This evaluation is not exemplified below.

    Examples (Permission without duties)

    The ODRL policy examples used below to exemplify the semantics of Permission are partially taken from the examples in the ODRL Information Model.

    Example 13
    Type of Permission: Permission only constrained by Constraint(s).
    The permission below allows the target asset http://example.com/document:1234 to be distributed, it includes the constraint that the permission may only be exercised until 2018-01-01.
    {
        "@context": "http://www.w3.org/ns/odrl.jsonld",
        "@type": "Set",
        "uid": "http://example.com/policy:6163",
        "profile": "http://example.com/odrl:profile:10",
        "permission": [{
           "target": "http://example.com/document:1234",
           "assigner": "http://example.com/org:616",
           "action": "distribute",
           "constraint": [{
               "leftOperand": "dateTime",
               "operator": "lt",
               "rightOperand":  { "@value": "2018-01-01", "@type": "xsd:date" }
           }]
       }]
    }
    

    Time evolution of Permission P6163
    The constraint must be evaluated on the state of the world, which must include a representation of the current time (for example by using the Time Ontology in OWL). As long as the current time is before the first day of 2018, the permission P6163 is active. When the first day of 2018 is passed, the permission becomes inactive. (The activation of this type of permission does not depend on the actions attempted by the agents).

    ID P6163.Constraint P6163.activation state
    E13-1 satisfied active
    E13-2 not-satisfied inactive

    Acces control scenario. Given a formal description of the attempted action.
    ID P6163.activation state P6163.action.all_attributes Attempted Action.performance state
    E13-1 active satisfied by the attempted action performed
    E13-2 inactive satisfied by the attempted action not-performed


    Monitoring scenario. Given a formal description of a performed action.
    1. If such an action belongs to the class of actions regulated by the permission P6163 (its type is distribute and its object is equale to http://example.com/document:1234) and the permission is active, then the action is permitted by P6163 and it is used by the performed action.
    2. If such an action belongs to the class of actions regulated by the permission P6163 and the permission is inactive, then nothing can be deduced.

    Example 14
    Type of Permission: Permission that regulates an action that is refined by Refinement(s).
    The permission below allows the target asset http://example.com/document:1234to be printed and also include a refinement indicating that the resolution of the printing action must be less than or equal to 1200 dpi.
     {
             "@context": "http://www.w3.org/ns/odrl.jsonld",
             "@type": "Set",
             "uid": "http://example.com/policy:6161",
             "profile": "http://example.com/odrl:profile:10",
             "permission": [{
                "target": "http://example.com/document:1234",
                "assigner": "http://example.com/org:616",
                "action": [{
                   "rdf:value": { "@id": "odrl:print" },
                   "refinement": [{
                      "leftOperand": "resolution",
                      "operator": "lteq",
                      "rightOperand": { "@value": "1200", "@type": "xsd:integer" },
                      "unit": "http://dbpedia.org/resource/Dots_per_inch"
                    }]
                }]
              }]
     }
    	

    Time evolution of Permission P6161.
    Acces control scenario: Given a formal description of the attempted action.
    ID P6161.action.all_attributes P6161 Attempted Action.performance state
    E14-1-ac satisfied by the attempted action active performed
    E14-2-ac not-satisfied by the attempted action inactive not-performed

    Monitoring scenario: The above Permission is always active because it has neither constraints nor duties. Given a formal description a performed action.
    ID P6161 P6161.action.all_attributes
    E14-1-m active satisfied by the performed action
    E14-2-m active not-satisfied by the performed action

    Semantics of Duty when it is used as an activation Condition of a Permission

    Goal: determine if a Duty is fulfilled.
    In ODRL 2.2., a Rule that belongs to the Duty class is fulfilled if all its constraints are satisfied and if its action, with all refinements satisfied, has been performed.
    The initial state of a duty is inactive.
    In order to evaluate if a Duty is fulfilled, it is necessary to perform the following steps:
    1. Evaluate the satisfaction of its Constraints (output: satisfied, not satisfied) on the state of the world;
      - if its Constraints are all satisfied the duty is active.
      - if one of its Constraints is not satisfied the duty is inactive. (For example, the duty to pay a ticket to get an active permission enter a museum may be active only on Sundays).
    2. If the Duty is active and its action with all refinements satisfied, is performed the duty becomes fulfilled.
    The life cycle of a duty is depicted in the figure below (states with the double outline are terminal states):

    Examples (Permission with duties)

    Example 22
    Type of Permission: Permission that is constrained by a Duty. The Duty has not Constraints. The Duty regulates an Action that is refined by Refinement(s).
    The Permission below is granted by the Party http://example.com/assigner:sony. It allows the target asset http://example.com/music/1999.mp3 to be played. The permission includes a duty 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": "Set",
        "uid": "http://example.com/policy:88",
        "profile": "http://example.com/odrl:profile:09",
        "permission": [{
            "assigner": "http://example.com/assigner:sony",
            "target": "http://example.com/music/1999.mp3",
            "action": "play",
            "duty": [{
               "action": [{
                  "rdf:value": { "@id": "odrl:compensate" },
                  "refinement": [{
                     "leftOperand": "payAmount",
                     "operator": "eq",
                     "rightOperand": { "@value": "5.00", "@type": "xsd:decimal" },
                     "unit": "http://dbpedia.org/resource/Euro"
                  }]
                }]
            }]
        }]
    }  
    
    Time evolution of the Duty of P88.
    The Duty has not Constraints, so it is never inactive. It starts to be active and can become 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 duty, i.e. its type is compensate and its payAmount is equal to 5 euro its target is equal to the assigner of the permission (?).
    Question: Is the performer of the compensate action that gets an active permission to play the file?
    ID Duty.Action.all_attributes Duty
    E22 not satisfied by performed actions active
    E22 satisfied by one of the performed actions fulfilled by the action


    Time evolution of permission P88
    The Permission P88 is active if its Duty is fulfilled, otherwise it is inactive.
    Acces control scenario: Given a formal description of the attempted action. if its type is play and its object is equale to http://example.com/music/1999.mp3 and the Permission P88 is active then the action is performed, otherwise it is blocked.
    ID Duty P88 Attempted Action.performance state P88.usage state
    E22-1-ac active inactive not-performed
    E22-2-ac fulfilled active performed used by the attempted action

    Monitoring scenario: Given a formal description of a performed action. If its type is play and its object is equale to http://example.com/music/1999.mp3 and the Permission P88 is active then the Permission is used.
    ID Duty P88 P88.Action P88.usage state
    E22-1-m active inactive performed
    E22-2-m fulfilled active performed used

    Sematics of Prohibition

    In ODRL 2.2., a Rule that belongs to the odrl:Prohibition class is active (its action, with all refinements satisfied cannot be exercised) if all constraints of the Rule are satisfied, otherwise it is inactive.
    In order to evaluate if a prohibition is active, it is necessary to evaluate the satisfaction of its constraints on the state of the world (constraints are either satisfied or unsatisfied).
    Duties on prohibitions have no defined meaning.
    An ODRL Evaluator will determine that a violation has been produced if the action on an active prohibition is executed. If multiple actions are related to a single prohibition, the execution of a single action will result in a violation. The ODRL Evaluator will calculate the state of an active prohibition to be within one of these possibilities: A prohibition may include an odrl:consequence for its violation.

    Sematics of Obligation

    In ODRL 2.2., an Obligation that belongs to the odrl:Duty class (it would be better to have an odrl:Obligation class) is active (its action, with all refinements satisfied, should be perfomed) if all constraints of the Rule are satisfied, otherwise it is inactive.
    An active Obligation becomes: An obligation may include an odrl:consequence of not fulfilling that obligation.
    Problem: reasoning about deadline.

    Previous efforts

    Section authored by Víctor. This section does not pretend to be part of a spec, but may serve as reference

    Documents on "formal semantics" in W3C specifications

    The W3C has produced several "Semantics" documents each of them with a different objective.

    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.

    References

    [Wieringa93] Wieringa, R. J., & Meyer, J. J. C. (1993). Applications of deontic logic in computer science: A concise overview. Deontic logic in computer science, pp. 17-40 John Wiley & Sons.
    [Gunter01] Gunter, C. A., Weeks, S. T., & Wright, A. K. (2001, January). Models and languages for digital rights. In System Sciences, 2001. Proceedings of the 34th Annual Hawaii International Conference on (pp. 5-pp). IEEE.
    [ODRL02] Ianella, R. Open Digital Rights Language (ODRL) Version 1.1. Formerly available online.
    [Pucella02] Pucella, R., &Weissman, V. (2002). A logic for reasoning about digital rights. In Computer Security Foundations Workshop, 2002. Proceedings. 15th IEEE (pp. 282-294). IEEE.
    [XACML03] Anderson, A., Nadalin, A., Parducci, B., Engovatov, D., Lockhart, H., Kudo, M., ... & Moses, T. (2003). extensible access control markup language (xacml) version 1.0. OASIS.
    [Delgado03] Delgado, J., Gallego, I., Llorente, S., & García, R. (2003, December). IPROnto: An ontology for digital rights management. In 16th Annual Conference on Legal Knowledge and Information Systems, JURIX (Vol. 106).
    [Guth03] Guth, S., Neumann, G., &Strembeck, M. (2003, October). Experiences with the enforcement of access rights extracted from ODRL-based digital contracts. In Proceedings of the 3rd ACM workshop on Digital rights management (pp. 90-102). ACM.
    [Pucella04] RiccardoPucella , Vicky Weissman. A formal foundation for ODRL, In Proc. of the Workshop on Issues in the Theory of Security (WIST’04)
    [Wang04] Wang, X. (2004). MPEG-21 rights expression language: Enabling interoperable digital rights management. IEEE MultiMedia, 11(4), 84-87.
    [García05] García, R., Gil, R., Gallego, I., & Delgado, J. (2005, July). Formalising ODRL semantics using web ontologies. In Proc. 2nd Intl. ODRL Workshop (pp. 1-10).
    [Barth06] Adam Barth and John C. Mitchell. Managing digital rights using linear logic. In LICS ’06: Proceedings of the 21st Annual IEEE Symposium on Logic in Computer Science, pages 127–136,Washington, DC, USA, 2006. IEEE Computer Society
    [Chong06] Chong, C. N., Corin, R., Doumen, J., Etalle, S., Hartel, P., Law, Y. W., &Tokmakoff, A. (2006). LicenseScript: a logical language for digital rights management. Annals of Telecommunications, 61(3), 284-331.
    [Nadah07] Nadia Nadah, Melanie Dulong de Rosnay, Bruno Bachimont. Licensing Digital Content With A Generic Ontology: Escaping From The Rights Expression Language Jungle. ACM. ICAIL2007 - 11th international conference on Articial intelligence and law, Jun 2007, Stanford, United States. pp.65-69, 2007, Proceedings of the 11th international conference on Articial intelligence and law
    [Gangadharan07] Gangadharan G.R., Weiss M., D’Andrea V., Iannella R. (2007) Service License Composition and Compatibility Analysis. In: Krämer B.J., Lin KJ., Narasimhan P. (eds) Service-Oriented Computing – ICSOC 2007. ICSOC 2007. Lecture Notes in Computer Science, vol 4749. Springer, Berlin, Heidelberg
    [Jamkhedkar08] Pramod Arvind Jamkhedkar, Gregory L. Heileman. Conceptual Model For Rights. Proceedings of the 8th ACM workshop on Digital rights management Pages 29-38, 2008
    [Sheppard09] Sheppard, N. P., &Safavi-Naini, R. (2009, November). On the operational semantics of rights expression languages. In Proceedings of the nineth ACM workshop on Digital rights management (pp. 17-28). ACM.
    [Kasten10] Andreas Kasten and Rüdiger Grimm. Making the Semantics of ODRL and URM Explicit Using Web Ontologies. Virtual Goods, pages 77–91, 2010.
    [Villata12] Serena Villata and FabienGandon. Licenses compatibilityand composition in the web of data. In The 2ndInternational Workshop on Consuming Linked Data.2012.
    [Rodriguez13] Rodríguez-Doncel, V., Suárez-Figueroa, M. C., Gómez-Pérez, A., & Poveda-Villalón, M. (2013, October). License linked data resources pattern. In Proceedings of the 4th International Conference on Ontology and Semantic Web Patterns-Volume 1188 (pp. 84-87). CEUR-WS. org.
    [Rotolo13] Antonino Rotolo, Serena Villata, and Fabien Gandon. A deontic logic semantics for licenses composition in the web of data. In Int’l Conf. on Artificial Intelligence and Law ICAIL, pages 111–120, 2013.
    [Steyskal14] Simon Steyskal and Axel Polleres. Defining expressive access policies for linked data using the ODRL ontology 2.0. In Proceedings of the 10th International Conference on Semantic Systems, SEMANTICS 2014, Leipzig, Germany, September 4-5, 2014, pages 20–23, 2014
    [Cabrio14] Elena Cabrio, Alessio Palmero Aprosio, and Serena Villata. These are your rights - A natural language processing approach to automated RDF licenses generation. In The Semantic Web: Trends and Challenges - 11th International Conference, ESWC 2014, Anissaras, Crete, Greece, May 25-29, 2014. Proceedings, pages 255– 269, 2014
    [Ianella15b] R. Iannella, M. Steidl, S. Guth (eds). Open Digital Rights Language (ODRL) Version 2.1 – Common Vocabulary. Final Specification, W3C ODRL Community Group http://www.w3.org/community/odrl/vocab/2.1/
    [Ianella15] R. Iannella& S. Guth& D. Paehler& A. Kasten (eds). Open Digital Rights Language (ODRL) Version 2.1 – Core Model. Final Specification, W3C ODRL Community Group. http://www.w3.org/community/odrl/model/2.1/
    [McRoberts15] M. McRoberts, V. Rodríguez Doncel. Open Digital Rights Language (ODRL) Version 2.1 – Ontology. Final Specification, W3C ODRL Community Group http://www.w3.org/ns/odrl/2/
    [Rodriguez15] Rodríguez, E., Delgado, J., Boch, L., & Rodríguez-Doncel, V. (2015). Media Contract Formalization Using a Standardized Contract Expression Language. IEEE multimedia, 22(2), 64-74.
    [Steyskal15] Steyskal, S., &Kirrane, S. (2015). If you can't enforce it, contract it: Enforceability in Policy-Driven (Linked) Data Markets. In SEMANTiCS (Posters & Demos) (pp. 63-66).
    [Steyskal15b] Steyskal, S., &Polleres, A. (2015, August). Towards formal semantics for ODRL policies. In International Symposium on Rules and Rule Markup Languages for the Semantic Web (pp. 360-375). Springer International Publishing.
    [Rodriguez16] Rodríguez-Doncel, V., Delgado, J., Llorente, S., Rodríguez, E., & Boch, L. (2016). Overview of the MPEG-21 Media Contract Ontology. Semantic Web, 7(3), 311-332.
    [DeVos19] De Vos, M., Kirrane, S., Padget, J., & Satoh, K. (2019, September). ODRL policy modelling and compliance checking. In International Joint Conference on Rules and Reasoning (pp. 36-51). Springer, Cham.
    [Kebede20] Kebede, M. G., Sileno, G., & van Engers, T. (2020). A critical reflection on ODRL. Springer Lecture Notes Artificial Intelligence, AICOL2021, to appear.
    [Kim20] Kim, J. M., & Chung, H. S. (2020). ODRL Ontology Extention Model and Prototype Design for the Specification of the Rights to use Digital Contents. Journal of Convergence for Information Technology, 10(1), 13-21.
    [Esteves21] Esteves, B., Pandit, H. J., & Rodrıguez-Doncel, V. ODRL Profile for Expressing Consent through Granular Access Control Policies in Solid. To appear, proc. of the Workshop on Consent Management in Online Services, Networks and Things (COnSeNT) - co-located with IEEE European Symposium on Security and Privacy (EuroS&P 2021)
    [Fornara19] N. Fornara and M. Colombetti. Using Semantic Web Technologies and Production Rules for Reasoning on Obligations, Permissions, and Prohibitions. AI Communications, vol. 32, no. 4, pp. 319-334, 2019.

    Document Conventions

    Prefix Namespace Description
    odrl http://www.w3.org/ns/odrl/2/ [[odrl-vocab]] [[odrl-model]]
    rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# [[rdf11-concepts]]
    rdfs http://www.w3.org/2000/01/rdf-schema# [[rdf-schema]]
    owl http://www.w3.org/2002/07/owl# [[owl2-overview]]
    xsd http://www.w3.org/2001/XMLSchema# [[xmlschema11-2]]
    skos http://www.w3.org/2004/02/skos/core# [[skos-reference]]
    dcterms http://purl.org/dc/terms/ [[dcterms]]
    vcard http://www.w3.org/2006/vcard/ns# [[vcard-rdf]]
    foaf http://xmlns.com/foaf/0.1/ [[foaf]]
    schema http://schema.org/ schema.org
    cc https://creativecommons.org/ns# creativecommons.org
    ex http://example.com/ns#