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

Hi Harsh,

I welcome your proposal.
However, I want to discuss your choice of words.

Best regards,
Georg

On Tue, May 31, 2022 at 7:51 PM Harshvardhan J. Pandit <me@harshp.com>
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/
>
>

-- 
Georg Philip Krog

signatu <https://signatu.com>