Re: Proposal for expressing Rules, Permissions, Prohibitions in DPV

Hi.
I forgot to mention yesterday that I had also looked at LegalRulemL [1] 
which specifically models "legal norms, guidelines, policies and 
reasoning", including defeasibility. DPV has a lot of overlap with its 
concepts such as Rights, Jurisdictions, Temporality. So that is also 
another option to specify "rules" alongside/extending DPV.

[1] 
https://docs.oasis-open.org/legalruleml/legalruleml-core-spec/v1.0/os/legalruleml-core-spec-v1.0-os.html

Regards,
Harsh

On 31/05/2022 18:51, Harshvardhan J. Pandit wrote:
> 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 Wednesday, 1 June 2022 09:05:03 UTC