- From: Harshvardhan J. Pandit <me@harshp.com>
- Date: Sat, 1 Oct 2022 17:41:13 +0100
- To: Data Privacy Vocabularies and Controls Community Group <public-dpvcg@w3.org>
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