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

Hi. In our previous meeting (SEP-28 
https://www.w3.org/2022/09/28-dpvcg-minutes.html#t03), we discussed 
rules and Paul asked to see an example. So here it is.

---
Rule
---

DPV provides relation `hasRule` to associate concept `Rule` with a 
context. The domain of hasRule is left blank, so it can be associated 
with any thing. The range of hasRule is Rule, so it always specifies a 
rule. DPV provides three categories of rules: Permission, Prohibition, 
and Obligation.

---
Scope
---

DPV does not define additional semantics or criteria for interpretation. 
So how to interpret rules beyond the above is not defined (for now), and 
not in scope for us. We provide guidance that you are trying to do 
something that is beyond the scope and capabilities of DPV, and you 
should look into other resources to complement DPV. We can provide 
guides to show how (volunteers please!)

E.g. If A has rule permission, and A also has rule prohibition - we do 
not clarify what should happen. Because again this is a question of 
legality as much as semantics. The implied state of 'ambiguity' may also 
have its own implications - such as this may not constitute valid 
consent, please ask the user again.

E.g. we do not (yet) clarify for the case where a permission is 
expressed for a PDH with two purposes - whether the permission applies 
for purposes individually (union) or only when both occur together 
(intersection). This is also a matter of legality as much as of 
semantics e.g. "When the processing has multiple purposes, consent 
should be given for all of them" vs "consent should be ... specific".

E.g. whether M as an obligation should occur before/after/during some 
purpose implementation - not in scope as this would mean we need to 
express ordering and dependencies between rules. There are other 
languages that can do this.

E.g. If A has rule permission, and B is part of A and has rule 
prohibition, then whether A is permitted to occur so as long as B does 
not occur.

This is what I think we discussed at the W3C TPAC with ODRL CG: 
interpretations can come later as part of how to provide a convenient 
and lightweight method for converting DPV into other languages for 
implementation, e.g. code, ODRL, SHACL, RuleML...

The general aim is to not reinvent the wheel in DPV, but to also provide 
some simple way to indicate what is permitted, prohibited,

---
Examples
---

```
# This can indicate permission: use email for service provision
ex:PDH1 a dpv:PersonalDataHandling ;
     dpv:hasRule dpv:Permission ;
     dpv:hasPurpose dpv:ServiceProvision ;
     dpv:hasPersonalData dpv:Email .

# This can indicate prohibition: use email for Service Provision, but do 
not use for Analytics
ex:PDH1 a dpv:PersonalDataHandling ;
     dpv:hasRule dpv:Permission ;
     dpv:hasPurpose dpv:ServiceProvision ;
     dpv:hasPersonalData dpv:Email .
     dpv:hasPersonalDataHandling [
         a dpv:PersonalDataHandling
         dpv:hasRule dpv:Prohibition ;
         dpv:hasPurpose dpv:Analytics ;
     ] .

# A PDH can be a rule, thereby providing declarative policies
# This PDH1 is directly declared as a permission
ex:PDH1 a dpv:PersonalDataHandling, dpv:Permission ;
     dpv:hasPurpose dpv:ServiceProvision ;
     dpv:hasPersonalData dpv:Email .

# Rules can be associated directly with concepts
ex:SensitiveRecords dpv:hasRule dpv:Prohibition .

# This indicates an external rule is associated with a PDH
ex:PDH1 a dpv:PersonalDataHandling ;
     dpv:hasRule ex:SomeRuleX ;
     dpv:hasPurpose dpv:ServiceProvision ;
     dpv:hasPersonalData dpv:Email .

# Rules can be what DPV defines
ex:SomeRuleA a dpv:Obligation ; dct:title "you MUST obey!"@en .

# Or be specific custom types
ex:SomeRuleB a ex:Requirement ; dct:title "checks something"@en .
ex:SomeRuleC a ex:MyCustomRule .

# Or use external vocabularies
ex:SomeRuleD a dpv:Rule, odrl:Policy .
# Such as ODRL to specify details about payment, duties, etc.
ex:SomeRuleE a dpv:Rule, odrl:Offer .
```

On 20/07/2022 18:16, Harshvardhan J. Pandit wrote:
> Hi. Some updates on my thoughts about this.

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

Received on Saturday, 1 October 2022 16:41:30 UTC