- From: <besteves@delicias.dia.fi.upm.es>
- Date: Tue, 18 Oct 2022 10:34:26 +0000
- To: Data Privacy Vocabularies and Controls Community Group <public-dpvcg@w3.org>, "Harshvardhan J. Pandit" <me@harshp.com>
- Cc:
- Message-ID: <20221018103426.Horde.CjIpAtN-8bj78n1nr3pwvRj@delicias.dia.fi.upm.es>
Hi all,
In our previous meeting we discussed how to represent rules with DPV and
some of you wanted to see how ODRL can specify similar rules.
I believe this can be the first step to have a document where we convert
DPV to other "languages".
Below you can see a mapping to ODRL of the examples we discussed.
If something is not clear let me know. Also more examples are welcome.
> # 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 .
>
ex:policy1 a odrl:Policy ;
odrl:profile odrl-dpv: ;
odrl:uid <https://example.com/policy:1> ;
odrl:permission [
odrl:action odrl-dpv:Use ;
odrl:target odrl-dpv:Email ;
odrl:constraint [
odrl:leftOperand odrl-dpv:Purpose ;
odrl:operator odrl:isA ;
odrl:rightOperand dpv:ServiceProvision
]
] .
> # 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 ;
>
> ] .
ex:policy2 a odrl:Policy ;
odrl:profile odrl-dpv: ;
odrl:uid <https://example.com/policy:2> ;
odrl:action odrl-dpv:Use ;
odrl:target odrl-dpv:Email ;
odrl:permission [
odrl:constraint [
odrl:leftOperand odrl-dpv:Purpose ;
odrl:operator odrl:isA ;
odrl:rightOperand dpv:ServiceProvision
]
] ;
odrl:prohibition [
odrl:constraint [
odrl:leftOperand odrl-dpv:Purpose ;
odrl:operator odrl:isA ;
odrl:rightOperand 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 .
ex:policy1 a odrl:Policy ;
odrl:profile odrl-dpv: ;
odrl:uid <https://example.com/policy:1> ;
odrl:permission [
odrl:action odrl-dpv:Use ;
odrl:target odrl-dpv:Email ;
odrl:constraint [
odrl:leftOperand odrl-dpv:Purpose ;
odrl:operator odrl:isA ;
odrl:rightOperand dpv:ServiceProvision
]
] .
> # Rules can be associated directly with concepts
>
> ex:SensitiveRecords dpv:hasRule dpv:Prohibition .
ex:policy3 a odrl:Policy ;
odrl:profile odrl-dpv: ;
odrl:uid <https://example.com/policy:3> ;
odrl:prohibition [
odrl:action odrl-dpv:Use ;
odrl:target ex:SensitiveRecords ;
] .
> # 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 .
ex:policy4 a odrl:Policy ;
odrl:profile new-profile: ;
odrl:uid <https://example.com/policy:4> ;
new-profile:ruleX [
odrl:action new-profile:Use ;
odrl:target new-profile:Email ;
odrl:constraint [
odrl:leftOperand new-profile:Purpose ;
odrl:operator odrl:isA ;
odrl:rightOperand dpv:ServiceProvision
]
] .
> # Rules can be what DPV defines
>
> ex:SomeRuleA a dpv:Obligation ; dct:title "you MUST obey!"@en .
ex:policy5 a odrl:Policy ;
odrl:profile new-profile: ;
odrl:uid <https://example.com/policy:5> ;
odrl:permission [
odrl:action new-profile:SomeAction ;
odrl:duty [
odrl:action new-profile:MustDoAction
]
] .
> # Or be specific custom types
>
> ex:SomeRuleB a ex:Requirement ; dct:title "checks something"@en .
>
> ex:SomeRuleC a ex:MyCustomRule .
new-profile:SomeRuleB rdfs:subClassOf odrl:Rule ;
owl:disjointWith odrl:Prohibition, odrl:Duty, odrl:Permission .
"Harshvardhan J. Pandit" me@harshp.com – October 1, 2022 5:42 PM
> Hi. In our previous meeting (SEP-28
> www.w3.org/2022/09/28-dpvcg-minutes.html[1]), 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.
>
>
Links:
------
[1] https://www.w3.org/2022/09/28-dpvcg-minutes.html#t03
Received on Tuesday, 18 October 2022 10:34:42 UTC