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:
- 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.
- 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:
- a collection of ODRL Policies;
- a formal description of the state of the world, that includes the performed actions;
- for the access control scenario,
a formal description of the action attempted by a given user located in a given place;
the objective of the ODRL Evaluator is to determine:
- which Permissions, Prohibitions, and Obligations (collectively named Rules)
are active. A Rule is said to be active if it is in effect;
- which Permissions have been used;
- which Prohibitions and Obligations have been violated or fulfilled.
This document describes the expected behaviour of this ODRL Evaluator, with a textual description, a formal semantics and a collection of examples.
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:
- 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
to be active 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.
Here follows a list of properties (with their possible values) needed by the ODRL Evaluator:
- Permission, Prohibition, and Obligation, have a property called
activation state, which can take the values of active or inactive.
- Prohibition and Obligation 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.
- 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.
- In the access control scenario, the value of the satisfaction state of a Refinement
is computed according to the action that an agent attempts to perform on digital resources.
- In the monitoring scenario, the value of the satisfaction state of a Refinement is
computed according to the actual actions that are performed by the agents and that are
represented in the state of the world.
- Action (connected to the Rule with the odrl:action property) has a property called performance state
which initially takes the values not-performed and
can become performed when an action with all the properties values (i.e.
type
,
performer
, object
,...) that matches with the values
described in the Rule (i.e. action
, assignee
, target
)
is actually performed at a given instant of time and its performance is represented
in the state of the world.
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:
- all the existing constraints of the Rule are satisfied;
- all the existing duties of the Rule are fulfilled or inactive;
- (only for the access control scenario) all the existing refinements of the
Action, AssetCollection, PartyCollection are satisfied by the attempted action.
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)
Example 13
(Differences from the example in the ODRL specification: its type is odrl:Set
)
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 the Permission
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 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 |
Permission.Constraint |
Permission.activation state |
E13-1 |
satisfied |
active |
E13-2 |
not-satisfied |
inactive |
Acces control scenario.
Given a formal description of the attempted action.
- (E-13-1) If such an action belongs to the class of actions regulated by the Permission
(its
type
is distribute
and its object
is equal to http://example.com/document:1234
)
and the Permission is active then the action can be performed.
- (E-13-2) If such an action belongs to the class of actions regulated by the Permission, but the
Permission is inactive, assuming that only such Permission is considered
(this is because other permissions could regulate this action), the action is blocked and it cannot be performed.
- If such an action does not belong to the class of actions regulated by the Permission it means that the Permission is not relevant.
ID |
Permission.activation state |
Permission.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.
- If such an action belongs to the class of actions regulated by the Permission and the Permission is active,
then the action is permitted and the Permission is used by the performed action.
- If such an action belongs to the class of actions regulated by the Permission and the Permission is inactive,
then nothing can be deduced.
Example 14
(Differences from the example in the ODRL specification: its type is odrl:Set
)
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: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.
{
"@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 the Permission.
Acces control scenario: Given a formal description of the attempted action.
- (E14-1) If such an action belongs to the class of actions regulated by the Permission
(its
type
is print
,
its object
is equale to http://example.com/document:1234
) and
its resolution
is less than or equal to 1200 dpi (it satisfies the refinement))
then the Permission is active and the attempted action can be performed.
- (E14-2) If such an action belongs to the class of actions regulated by the Permission,
but the refinement of the action is not satisfied, then the Permission is inactive.
Assuming that only this Permission is considered (this is because other permissions could regulate this action),
then the action is blocked and it cannot be performed.
ID |
Permission.action.all_attributes |
Permission |
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.
If such an action belongs to the class of actions regulated by the Permission then the permission is used by the performed action.
ID |
Permission |
Permission.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:
- 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).
- 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
(Differences from the example in the ODRL specification: its type is odrl:Agreement
and it has an odrl:assignee
)
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": "Agreement",
"uid": "http://example.com/policy:88",
"profile": "http://example.com/odrl:profile:09",
"permission": [{
"assigner": "http://example.com/assigner:sony",
"assignee": "http://example.com/party:person:billie",
"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.
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
, 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 http://example.com/assigner:sony
.
ID |
Duty.Action.all_attributes |
Duty |
E22-1 |
not satisfied by performed actions |
active |
E22-2 |
satisfied by one of the performed actions |
fulfilled by the action |
Time evolution of the Permission
The Permission is active if its Duty is fulfilled, otherwise it is inactive.
Acces control scenario:
Given a formal description of the attempted action. If such an action belongs to the class of actions regulated by the Permission
(i.e. its type
is play
, its object
is equal to http://example.com/music/1999.mp3
, and its performer
is
http://example.com/party:person:billie
) and the Permission is active, then the action is performed, otherwise it is blocked.
ID |
Duty |
Permission |
Attempted Action.performance state |
E22-1-ac |
active |
inactive |
not-performed |
E22-2-ac |
fulfilled |
active |
performed |
Monitoring scenario:
Given a formal description a performed action. If such an action belongs to the class of actions regulated by the Permission and the Permission is active
then the permission is used by the performed action.
ID |
Duty |
Permission |
E22-1-m |
active |
inactive |
E22-2-m |
fulfilled |
active |
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:
- not violated when the regulated action with all refinements satisfied has not been executed;
- violated when the regulated action with all refinements satisfied has been executed;
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:
- fulfilled or not violated when the regulated action with all refinements satisfied is executed;
- violated when the regulated action with all refinements satisfied can no longer be executed;
- unknown when the regulated action with all refinements satisfied can be executed but has not been so far;
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# |
|