Proposal for expressing Rules, Permissions, Prohibitions in DPV

Hi.

In a previous DPVCG meeting 
(https://www.w3.org/2021/10/13-dpvcg-minutes.html), we discussed whether 
there is interest regarding providing permissions / prohibitions as 
concepts in DPV. The rationale or motivating behind this was to 
explicitly indicate something must (not) be done.

---

tldr; Below is a more detailed analysis of why I propose these specific 
concepts, what else I've looked at, and that the end result is based on 
terms as per RFC 2119 while trying to not deviate too much from ODRL.

Rule: Parent class specifying how associated information should be 
interpreted or performed

Requirement: MUST happen
Prohibition: MUST NOT happen
Permission: SHOULD or MAY happen, implied assumption it will, but if it 
doesn't, nothing is violated by itself
Avoidance: SHOULD NOT or MAY NOT happen, implied assumption it will not, 
but if it does, nothing is violated by itself, i.e. this says preferably 
should not take place, if permission is interpreted as "I'm okay if this 
happens", then this is its opposite as "I'm okay if this doesn't 
happen". This is required because we don't have a NOT concept/operator 
to negate/invert other concepts.

Constraint: Segue to more information or rules that restrict or specify 
conditions for above concepts

---

# ODRL

During the discussion, we did look at ODRL concepts (Rule -> Permission, 
Prohibition, Duty). Using these (as is) would mean importing the entire 
semantics of ODRL into DPV, something that is neither necessary nor 
desirable in all uses of DPV. In an ideal situation, one may choose to 
use DPV and ODRL together to express a "policy", and for which we may 
provide some nice alignment, but there are other cases where such mixing 
may not be needed or feasible.

Which brings the proposal for how to express such concepts with two 
goals. First, we do not want to redefine the wheel here - ODRL already 
has a lot of nice structure on what concepts are relevant and how they 
are use. Whatever we end up with would be good to be as close to that as 
possible.

Second, we should not delve too deep here and model the specifics of 
rules and their consequences and duties (etc.) within DPV - that's what 
ODRL is exactly intended for. We should also not be rigid in how rules 
or constraints are applied, for e.g. in ODRL only policies can express 
these, whereas for our use-cases, we may want to express these also on 
specific non-policy concepts such as legal basis (e.g. legitimate 
interest has duty to notify data subject), personal data (e.g. 
prohibition on processing of special categories with constraint that A.9 
be used), and so on.

While we may not explicitly model such conditions, DPV should enable 
their expression (in other mechanisms, including ODRL). Through this, 
there rises the possibility to create a helpful knowledge base where a 
concept can have a guideline or a requirement specified without turning 
that concept into a policy (as under ODRL).

# Deontic vs Epistemic terms

So the proposal is to provide a lightweight series of concepts that are 
just enough to specify something is permitted or prohibited or has a 
rule or a constraint.

Top concept: Rule (Parent: dpv:Concept) with the definition "A principle 
or method or procedure". Note: The description is intentionally as broad 
as possible to accommodate any potential concepts that relate to rules, 
and to enable use its beyond ODRL's deontological concepts (e.g. 
permissions, duty) to also express epistemological concepts (e.g. 
principles, guidelines). The existing concept dpv:Law will be a subclass 
of Rule following the interpretation of a law as a set/system of rules.

The following concepts are commonly encountered regarding data 
protection / privacy. I've tried to group them with descriptions.

Deontic Concepts:
- Permission (to permit or enable), e.g. permission to process data
- Prohibition (to prohibit or to forbid), e.g. prohibition to not 
process data
- note that permissions and prohibitions may not be obligations, merely 
indication or preferences as well
- Requirement (a necessity), e.g. necessity to perform processing
- Obligation (to compel or promise), e.g. provision of a notice
- Duty (subclass of obligation, imposition of a requirement or 
obligation based on specific context), e.g. provision of a notice by a 
Data Controller
- Promise (subclass of obligation, a self-proclaimed acceptance of an 
obligation), e.g. not to perform analytics or profiling
- Agreement (subclass of obligation, acceptance of obligation between 
entities), e.g. terms and conditions
- Law (a societal set of rules as an obligation)

Epistemic Concepts:
- Principle (a rule that expresses how something should happen)
- Guideline (a rule that suggests what is desirable)
- Preference (a rule that places one choice above another)
- Norm (a rule that is considered typical or common or acceptable)

Of note: ODRL mixes Duty and Requirement together, specifies Obligation 
as applicability of a Duty, does not represent Promise or Law. I'm not 
saying it is incorrect, just that there may be an argument to make 
regarding not all obligations being duties or vice-versa, I'm not sure. 
ODRL also provides Request, Offer, and Assertion which I've skipped in 
above list. Maybe the above concepts are also of use for ODRL.

# Even more terms

As the list above makes clear, this can be a complex topic with a lot of 
navel gazing and endless discussions on what each specific concept 
actually means. Within DPV, we might want to focus on what is 
practically needed i.e. the ability to specify whether something is 
happening or not happening, and a way to enable other 
vocabularies/languages to express more complex rules over this information.

The choice of "Permission" and "Prohibition" is more common because 
that's what we've been used to, but there are other also options: 
allow/deny, enable/prevent, approve/decline, and so on. Each concept 
(pair) comes loaded with interpretation that varies from that of 
permit/prohibit.

RFC 2119 (https://www.ietf.org/rfc/rfc2119.txt) specifies similar 
interpretations for documents by using words like MUST, MUST NOT, etc. 
which ultimately boil down to: (a) something is a requirement; (b) 
something is prohibited; (c) something may happen; (d) something may not 
happen.

# Deciding on *something*

Since this entire exercise (and rabbit hole) started because I wanted to 
find a way to indicate something happens or doesn't happen, I suggest 
the following, based on RFC 2119 and ODRL.

Parent class: Rule

Requirement: MUST happen
Prohibition: MUST NOT happen
Permission: SHOULD or MAY happen, implied assumption it will
Avoidance: SHOULD NOT or MAY NOT happen, implied assumption it will not

Regards,
-- 
---
Harshvardhan J. Pandit, Ph.D
Research Fellow
ADAPT Centre, Trinity College Dublin
https://harshp.com/

Received on Tuesday, 31 May 2022 17:51:11 UTC