Contributors: (ordered alphabetically) Arthit Suriyawongkul(ADAPT Centre, Trinity College Dublin),
Axel Polleres(Vienna University of Economics and Business),
Beatriz Esteves(IDLab, IMEC, Ghent University),
Bud Bruegger(Unabhängige Landeszentrum für Datenschutz Schleswig-Holstein),
Damien Desfontaines(No affiliation provided),
Danielle Welter(University of Luxembourg),
David Hickey(Dublin City University),
Delaram Golpayegani(ADAPT Centre, Trinity College Dublin),
Elmar Kiesling(Vienna University of Technology),
Fajar Ekaputra(Vienna University of Technology),
Georg P. Krog(Signatu AS),
Harshvardhan J. Pandit(AI Accountability Lab (AIAL), Trinity College Dublin),
Iain Henderson(JLINC Labs),
Javier Fernández(Vienna University of Economics and Business),
Julian Flake(University of Koblenz),
Julio Hernandez(Dublin City University),
Mark Lizar(OpenConsent/Kantara Initiative),
Maya Borges(Danish Agency for Digitisation),
Paul Ryan(Uniphar PLC),
Piero Bonatti(Università di Napoli Federico II),
Rana Saniei(Universidad Politécnica de Madrid),
Rob Brennan(University College Dublin),
Rudy Jacob(Proximus),
Simon Steyskal(Siemens),
Steve Hickman(Epistimis LLC).
NOTE: The affiliations are informative, do not represent formal endorsements, and may be outdated as this list is generated automatically from existing data.
This document provides additional details and examples for rules concepts for permission, prohibition, and obligation used in the Data Privacy Vocabulary [[DPV]], and is a companion to the [[DPV]] specification.
DRAFT RELEASE This is draft release intended for review.
DPV Specifications: The [[DPV]] is the core specification within the DPV family, with the following extensions: Personal Data [[PD]], Locations [[LOC]], Risk Management [[RISK]], Technology [[TECH]] and [[AI]], [[JUSTIFICATIONS]], [[SECTOR]] specific extensions, and [[LEGAL]] extensions modelling specific jurisdictions and regulations. A [[PRIMER]] introduces the concepts and modelling of DPV specifications, and [[GUIDES]] describe application of DPV for specific applications and use-cases. The Search Index page provides a searchable hierarchy of all concepts. The Data Privacy Vocabularies and Controls Community Group (DPVCG) develops and manages these specifications through GitHub. For meetings, see the DPVCG calendar.
Contributing: The DPVCG welcomes participation to improve the DPV and associated resources, including expansion or refinement of concepts, requesting information and applications, and addressing open issues. See contributing guide for further information.
Introduction
DPV provides the concept [=Rule=] to specify requirements, constraints, and other forms of 'rules' that are associated with specific contexts (e.g., processing activities) using the relation [=hasRule=]. DPV provides three forms of Rules to represent [=Permission=], [=Prohibition=] and [=Obligation=], and their corresponding relations [=hasPermission=], [=hasProhibition=] and [=hasObligation=], to indicate a Rule that specifies whether something is permitted, prohibited or an obligation, respectively.
[=Permission=] refers to the indicated context being allowed or approved to be carried out. Permissions are only a 'permissive signal' i.e. it is not necessary to carry out an activity just because it is permitted (see obligation for this). Permissions can be used to record what has been permitted or to distinguish the 'permissive' parts from other 'non-permissive' or prohibitive parts, such as in use-cases for policies, agreements, consent records, and risk assessments.
[=Prohibition=] represents the indicated context is not allowed or it is not approved to be carried out. If something is expressed as a prohibition - it explicitly indicates that it must not occur. Unlike permission, prohibition is a 'strong' rule i.e. if something is prohibited, then it is necessary that it not be carried out.
[=Obligation=] is the antipodal rule for prohibitions, which means if something is an obligation then it is necessary for it to be carried. It differs from permissions - which are a 'soft' rule i.e. a permitted activity is not necessary to be carried out.
DPV does not define additional semantics for rules and limits its scope and focus to provide a simple way to specify permissions, prohibitions, and obligations as common rules associated with activities, as well as recommendations and deterrence in assessments and guidelines. For a more extensive and richer set of semantics and concepts to represent rules, DPVCG suggests looking towards other languages, such as [[ODRL]], [[SHACL]], and [[RuleML]] that have been developed with the specific goal of representing and applying rules. We welcome contributions for aligning DPV with these, and for providing guidance on how to complement DPV's rule-based concepts with external languages.
dpv:Rule: A rule describing a process or control that directs or determines if and how an activity should be conducted
go to full definition
dpv:AcceptableRule: A rule that is acceptable where it is either desirable if it occurs or it is not unacceptable if it does
go to full definition
dpv:Obligation: A rule describing an obligation for performing an activity
go to full definition
dpv:Permission: A rule describing a permission to perform an activity
go to full definition
dpv:Recommendation: A rule describing a recommendation for performing an activity
go to full definition
dpv:UnacceptableRule: A rule that is unacceptable where it not desirable if it occurs
go to full definition
dpv:Deterrence: A rule describing a deterrence for performing an activity
go to full definition
dpv:Prohibition: A rule describing a prohibition to perform an activity
go to full definition
dpv:RuleFulfilmentStatus: Status associated with a rule for indicating whether it is applicable, or has been utilised, and whether the requirements of the rule have been fulfilled or violated
go to full definition
dpv:RuleFulfilled: Status indicating a rule has been fulfilled, completed, or satisfied
go to full definition
dpv:DeterrenceUtilised: Status indicating a deterrence has been utilised i.e. the activity stated as being deterred has not been carried out
go to full definition
dpv:ObligationFulfilled: Status indicating an obligation has been fulfilled i.e. the activity stated as being required to be carried out has been successfully completed
go to full definition
dpv:PermissionNotUtilised: Status indicating a permission has not been utilised i.e. the activity stated as being permitted has not been carried out
go to full definition
dpv:PermissionUtilised: Status indicating a permission has been utilised i.e. the activity stated as being permitted has been carried out
go to full definition
dpv:ProhibitionFulfilled: Status indicating a prohibition has been fulfilled i.e. the activity stated as being prohibited has not been carried out
go to full definition
dpv:RecommendationUtilised: Status indicating a recommendation has been utilised i.e. the activity stated as being recommended has been carried out
go to full definition
dpv:RuleUnfulfilled: Status indicating a rule has not been fulfilled nor violated
go to full definition
dpv:DeterrenceNotUtilised: Status indicating a deterrence has not been utilised i.e. the activity stated as being deterred has been carried out
go to full definition
dpv:ObligationUnfulfilled: Status indicating an obligation has not been fulfilled i.e. the activity stated as being required to be carried out has not been carried out but this is not considered as a violation e.g. there is still time to conduct the activity
go to full definition
dpv:RecommendationNotUtilised: Status indicating a recommendation has not been utilised i.e. the activity stated as being recommended has not been carried out
go to full definition
dpv:RuleViolated: Status indicating a rule has been violated, breached, broken, or infracted
go to full definition
dpv:ObligationViolated: Status indicating an obligation has been violated i.e. the activity stated as being required to be carried out has not been carried out and this is considered as a violation i.e. the activity can no longer be carried out to fulfil the obligation
go to full definition
dpv:ProhibitionViolated: Status indicating a prohibition has been violated i.e. the activity stated as being prohibited has been carried out
go to full definition
Rule Fulfilment Status
The DPVCG is exploring representing the state of rule fulfilment through concepts, for example to represent a prohibition has been violated, or an obligation has been fulfilled, or a permission has been utilised. The currently provided concepts for these, represented by the concept [=RuleFulfilmentStatus=] and its taxonomy, which are associated using the relation `dpv:hasStatus`, indicate the intent and scope of this work.
The DPVCG is working with ongoing efforts regarding similar modelling of concepts for ODRL implementations, in particular to ensure the concepts in DPV are in sync and compatible with those developed for ODRL. The below issue shows the progress for this.
Interpreting Rules
Default Interpretation
Though DPV provides concepts representing deontic logic, it does not specify what should be the 'default' interpretation in relation to rules, i.e. it does not provide an interpretation of whether some rules apply automatically unless otherwise declared. For example, in declaring an instance of Process, the assumption is that the activities are modelled for what is happening or what is intended/planned to happen. The explicit annotation using a Permission rule adds information about whether some activity is permitted (and its associated information). Instead, if the use-case is using DPV to only document activities that are permitted, there is no need to explicitly specify the permissions. Similarly, just because something is happening or planned to happen, it cannot be assumed to be permitted (e.g. pending evaluation of legal requirements).
This lack of default interpretation enables modularity in the use of DPV concepts. For example, an instance of `dpv:Process` which does not have a `dpv:hasRule` declared within it, can be made part of a rule to specify permissions, prohibitions, or obligations regarding the process. If instead the process had a default interpretation (e.g. permission), then it would require creating a separate instance with the same information - leading to duplicated efforts. While an apparent solution is to create a mechanism whereby the rule in the process is overridden with the intended 'outer' rule or context e.g. to specify the prohibition in one process overrules permission in another process, this prevents the combination of rules to describe situations such as a permission for a larger context within which specific parts are prohibited or obligated.
Mixing/Nesting Rules
In representing Rules, DPV only provides the concept and does not express any inherent semantics on what those rules mean in relation to each other. For example, DPV does not express Permission to be non-compatible or disjoint from Prohibition. This is to separate the interpretation and application of rules based on the necessities of a use-case. For example, in a legal investigation it may be prudent to specify permission and prohibition can never occur together, but this may not be true if there are different legal requirements that allow a prohibition to be resolved or deferred, such as through another permission that overrides the prohibition.
Further, as described earlier in the section on default interpretations, it is possible to mix or nest rules such as through processes. For example, if `ProcessA` is a permitted process and contains `ProcessB` which is a prohibited process, DPV does not dictate what should be default interpretation for this arrangement. The role of DPV concepts regarding rules, as of now, is to provide a simplified indication of whether something is permitted, prohibited, or obligated. Further interpretations require creation of a formal specification that dictates how rules should function together. For example, depending on the use-case, several interpretations are possible for the example described here:
Prohibitive interpretation: Both `ProcessA` and `ProcessB` are prohibited because through `ProcessA` is permitted, `ProcessB` is within it and is prohibited - thereby prohibiting both processes. Such interpretations prevent modularity - everything is prohibited because something is prohibited, or it is permitted because there are no prohibitions.
Permissive interpretation: `ProcessA` and `ProcessB` are both permitted since `ProcessA` gives permission for the entire process and overrides the prohibition in `ProcessB`. Such interpretations also prevent modularity - everything is permitted because the higher/broader processes are permitted even though there are specific prohibitions at a granular level.
Contextually Prohibitive interpretation: `ProcessB` is prohibited as declared, and the rest of `ProcessA` without `ProcessB` is permitted. If there was a further `ProcessC` that is permitted, and is present within `ProcessB`, then `ProcessC` would still be prohibited as the broader prohibition from `ProcessB` overrides it. Such interpretations permit modularity with permission granted for parts as long as there is no prohibition overriding it from a broader context. In this, a prohibition within a permission still allows the permitted parts to be carried out, whereas a permission within a prohibition would still be prohibited.
Contextually Permissive interpretation: This is the same as the contextually prohibitive interpretation, except permissions occurring within prohibitions are not overridden. This means, `ProcessA` is allowed through its permission, with `ProcessB` within it being prohibited, except for `ProcessC` within `ProcessB` - which is permitted.
The above example interpretations only concerned permissions and prohibitions, and did not include obligations - or other concepts such as duties, dispensations, exceptions, and defeasibility. From this, it should be clear how the specification and interpretation of rules can be quite complex and has a large impact on the intended activities and information being documented.
Triggering Rules
DPV does not define how rules are 'triggered' i.e. how to specify under what conditions a rule should become applicable or is exempted from being applied. Some common triggers for rules to be applied are provided here as examples:
Ex-ante: the rule is applied before the specified activity is carried out.
Ex-post: the rule is applied after the specified activity is carried out.
Real-time: the rule is applied during the specified activity being carried out.
Alignment with ODRL
[[ODRL]] provides a W3C standardised representation for expressing policies containing rules such as for permissions, prohibitions, obligations over 'assets' and the involved 'parties'. While ODRL focuses on providing a general structure for policies without jurisdictional concepts or modelling, it complements DPV by enabling declaration of policies, agreements, and other similar documents in a structured, interoperable, and standardised manner. The DPV concepts enable specifying the exact information within the structure provided by ODRL - which can be useful for two entities to exchange information. For example, in a controller-processor agreement, ODRL can be used to define the agreement in terms of involved parties, their roles, and which entity is responsible for performing which actions, as well as the expected ex-post consequences of those actions - such as for reporting from processor to controller, or to indicate what should be done should a particular requirement is violated.
The DPVCG is interested in formally authorising a shared specification with the ODRL Community Group that outlines the use of DPV concepts for/with ODRL. The current proposal for this is to create an ODRL profile that declares DPV concepts in context of ODRL's conceptual model and through which DPV concepts can be correctly declared and used in ODRL. The current draft guidance document for use of DPV and ODRL is available at [[[GUIDE-ODRL]]], and the mapping of concepts between DPV and ODRL is available at [[[MAPPING-ODRL]]].
A rule that is acceptable where it is either desirable if it occurs or it is not unacceptable if it does
Usage Note
Acceptable is a subjective concept that enables distinguishing with "unacceptable". By itself it does not signal any permission or obligation - for which further specific concepts are defined
Date Created
2025-06-19
Contributors
Arthit Suriyawongkul, Beatriz Esteves, Delaram Golpayegani, Georg P. Krog, Harshvardhan J. Pandit, Julian Flake, Paul Ryan
A rule describing a deterrence for performing an activity
Usage Note
Deterrences are aligned with the term SHOULD NOT in RFC2119 where specified activities should be avoided from being carried out but are not prohibitions
Date Created
2025-06-19
Contributors
Arthit Suriyawongkul, Beatriz Esteves, Delaram Golpayegani, Georg P. Krog, Harshvardhan J. Pandit, Julian Flake, Paul Ryan
Status indicating an obligation has not been fulfilled i.e. the activity stated as being required to be carried out has not been carried out but this is not considered as a violation e.g. there is still time to conduct the activity
Status indicating an obligation has been violated i.e. the activity stated as being required to be carried out has not been carried out and this is considered as a violation i.e. the activity can no longer be carried out to fulfil the obligation
Status associated with a rule for indicating whether it is applicable, or has been utilised, and whether the requirements of the rule have been fulfilled or violated
A rule that is unacceptable where it not desirable if it occurs
Usage Note
Unacceptable is a subjective concept that enables specifying something is to be avoided as compared to "acceptable". By itself it does not signal any deterrence or prohibition - for which further specific concepts are defined
Date Created
2025-06-19
Contributors
Arthit Suriyawongkul, Beatriz Esteves, Delaram Golpayegani, Georg P. Krog, Harshvardhan J. Pandit, Julian Flake, Paul Ryan
DPV uses the following terms from [[RDF]] and [[RDFS]] with their defined meanings:
rdf:type to denote a concept is an instance of another concept
rdfs:Class to denote a concept is a Class or a category
rdfs:subClassOf to specify the concept is a subclass (subtype, sub-category, subset) of another concept
rdf:Property to denote a concept is a property or a relation
The following external concepts are re-used within DPV:
External
Funding Acknowledgements
Funding Sponsors
The DPVCG was established as part of the SPECIAL H2020 Project, which received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No. 731601 from 2017 to 2019.
Harshvardhan J. Pandit was funded to work on DPV from 2020 to 2022 by the Irish Research Council's Government of Ireland Postdoctoral Fellowship Grant#GOIPD/2020/790.
The ADAPT SFI Centre for Digital Media Technology is funded by Science Foundation Ireland through the SFI Research Centres Programme and is co-funded under the European Regional Development Fund (ERDF) through Grant#13/RC/2106 (2018 to 2020) and Grant#13/RC/2106_P2 (2021 onwards).
Funding Acknowledgements for Contributors
The contributions of Harshvardhan J. Pandit have been made with the financial support of Science Foundation Ireland under Grant Agreement No. 13/RC/2106_P2 at the ADAPT SFI Research Centre.