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

Hi,

Thanks Harsh for the dissemination of this meeting!

Víctor

El 20/07/2022 a las 19:16, Harshvardhan J. Pandit escribió:
> Hi. Some updates on my thoughts about this.
> Also, ODRL group and DPVCG are having a joint session at W3C TPAC. See 
> event details: 
> https://www.w3.org/events/meetings/845fa609-cc65-414f-8960-3fff0c4c0467 - 
> Please let us know if you plan to join.
>
> ---
>
> Q. What do we want to express here?
> Ans. We want the ability to specify something is permitted to take 
> place, prohibited to take place, required to take place, or to be 
> avoided. Here this "something" can be an entire graph, a specific 
> PersonalDataHandling instance, or something else. Examples:
>
> 1. "We WILL NOT share your data with third parties"
> Condition: Recipient is ThirdParty
> Rule: Prohibited
>
> 2. "We WILL keep your data within EU"
> Condition: StorageLocation is EU
> Rule: Requirement
>
> 3. "You have given us permission to process your data for Security but 
> not for Marketing"
> Condition: Purpose is Enforce Security
> Rule: Permission
> Condition: Purpose is Marketing
> Rule: Prohibition
>
> 4. "We will try not to keep your data beyond 6 months, but definitely 
> not beyond 2 years"
> Condition: StorageDuration is 6 months to 2 years
> Rule: Avoidance
> Condition: StorageDuration is more than 2 years
> Rule: Prohibition
>
> ---
>
> Q. Why not use ODRL?
>
> ODRL is a standardised vocabulary with a rigid semantics of how 
> classes and properties are used, and requirements for specific 
> combinations to occur for a valid expression. For example, Prohibition 
> class instances MUST be expressed using prohibition property and MUST 
> contain a 'target' property with type 'Asset'.
>
> When considering dpv:PersonalData as an odrl:Asset - this seems fine. 
> However, when we get to expressing things such as #1 above, a 
> ThirdParty or PersonalDataHandling instance representing the data 
> sharing is not an 'Asset' per se, even though semantically it can be 
> considered a 'resource'.
>
> The bigger question arises from use of ODRL, where the "policies" are 
> a separate graph on their own. For example, for expressing #1, one 
> would have to write a DPV graph and a separate ODRL graph expressing 
> the condition that Third Party should not be a recipient.
>
> This is fine in itself, ODRL being a standard and interoperable and 
> all that, but it means to express permissions, prohibitions, etc. - 
> you MUST use ODRL. This means DPVCG must assist with the incorporation 
> / alignment of its concepts with ODRL.
>
> ---
>
> Q. ODRL is complex, how to simplify it for someone to express stuff?
>
> That is what the original proposal was - to create a concept called 
> `Rule` under `Context` and populate it with `Requirement`, 
> `Prohibition`, `Permission`, `Avoidance`, and `Constraint` to give a 
> taxonomy. For anything more expressive, clear indication to use ODRL 
> with examples.
>
> The intention is to simplify flagging some processing operations are 
> prohibited or mandatory or permitted. Examples could be outputs of a 
> DPIA, a DPA consultancy, consent (permit some, prohibit some), etc. 
> The intention is to limit the scope to this, and point to other things 
> (i.e. ODRL) for anything more complex.
>
> ---
>
> Regards,
> Harsh
>
> On 01/06/2022 10:04, Harshvardhan J. Pandit wrote:
>> 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,
>>
>


-- 
Víctor Rodríguez-Doncel
D3205 - Ontology Engineering Group (OEG)
Departamento de Inteligencia Artificial
ETS de Ingenieros Informáticos
Universidad Politécnica de Madrid

Campus de Montegancedo s/n
Boadilla del Monte-28660 Madrid, Spain
Tel. (+34) 910672914
Skype: vroddon3
http://cosasbuenas.es

Received on Wednesday, 20 July 2022 19:57:34 UTC