Difference between revisions of "Project:Vocabulary/GDPR"

From Wikibase Personal data
Jump to navigation Jump to search
 
(17 intermediate revisions by 2 users not shown)
Line 12: Line 12:
 
* {{Q|2409}}
 
* {{Q|2409}}
 
* {{Q|2350}}
 
* {{Q|2350}}
−
 
+
* {{Q|253}}
  
 
=== Core snaks===
 
=== Core snaks===
 
* {{P|3}} - {{Q|96}}
 
* {{P|3}} - {{Q|96}}
 +
** Both GDPR generators will not pop up if this is not present.
 
* {{P|17}} - "mailto:johnny@example.com"
 
* {{P|17}} - "mailto:johnny@example.com"
 
** {{Q|1062}} - {{Q|96}}
 
** {{Q|1062}} - {{Q|96}}
−
** qualifier is not currently checked but it should be, as there may be a general support email as well as a data protection officer specific email address.
+
*** This qualifier is not currently checked but it should be, as there may be a general support email as well as a data protection officer specific email address and we need to pick the correct one.
 
* {{P|282}} - "https://company/privacy/contact"  
 
* {{P|282}} - "https://company/privacy/contact"  
 
** This is necessary where there is no known email address for contacting the data protection officer, only a form. In these cases you probably still need to add {{P|17}} but with a dummy email address (and a comment qualifier making clear it is not a real address). The generated email then has to be manually pasted into the contact form for submission. For example see {{Q|3424}}
 
** This is necessary where there is no known email address for contacting the data protection officer, only a form. In these cases you probably still need to add {{P|17}} but with a dummy email address (and a comment qualifier making clear it is not a real address). The generated email then has to be manually pasted into the contact form for submission. For example see {{Q|3424}}
 
* {{P|10}} - the points of data known to be collected/stored by this company.
 
* {{P|10}} - the points of data known to be collected/stored by this company.
 
** {{P|27}} - "alternative string name"
 
** {{P|27}} - "alternative string name"
−
*** This qualifier allows existing items to be re-used. The idea is that the 'named as' value is the display name that is used in the GDPR request letter. So if we already have 'location' but want to include 'geolocation info' because that is the term used for this concept from the company's privacy policy, we can include {{Q|1078}} in the {{P|10}} list but add {{P|27}} - 'geolocation info' as a qualifier. This is important to allow the eventual unification of different data concepts into one model despite companies describing them differently.  
+
*** This qualifier allows existing items to be re-used. The idea is that the 'named as' value is the display name that is used in the GDPR request letter. So if we already have 'location' but want to include 'geolocation info' because that is the term used for this concept from the company's privacy policy, we can include {{Q|1078}} in the {{P|10}} list but add {{P|27}} - 'geolocation info' as a qualifier. This is important to allow the eventual unification of different data concepts into one model despite companies describing them differently. This is currently only used in Alex Bowyer's GDPR Generator ([[User:Alexbfree/Code:GDPRMailAccess.js]]). It is recommended this be merged to the Le Temps generator. Another use of this field is to convert the pronoun to the correct form for the letter - for example the stored data point might be "information about your journeys". You can add a {{P|27}} to change this to "information about my journeys" in the generated GDPR letter.  
 
** {{Q|1117}} - {{Q|29}} or {{Q|1117}} - {{Q|3732}}
 
** {{Q|1117}} - {{Q|29}} or {{Q|1117}} - {{Q|3732}}
 
*** This qualifier is especially important where other data points have already been added to the {{P|10}} list from different sources. This is used to distinguish things we have learnt from different sources. We should update our GDPR generators to only include the {{P|10}} items from the sources we want to use (which may differ per project).
 
*** This qualifier is especially important where other data points have already been added to the {{P|10}} list from different sources. This is used to distinguish things we have learnt from different sources. We should update our GDPR generators to only include the {{P|10}} items from the sources we want to use (which may differ per project).
Line 32: Line 33:
 
** {{Q|467}} - 'https://companyname.com/privacy/policy.html'
 
** {{Q|467}} - 'https://companyname.com/privacy/policy.html'
 
** This snak and qualifier are the standard way to specify the company's privacy policy URL. Note this should be added as a qualifier not a reference.
 
** This snak and qualifier are the standard way to specify the company's privacy policy URL. Note this should be added as a qualifier not a reference.
 +
* {{P|122}} - any item that is required by the company
 +
** Currently all items in the {{P|122}} list will be included at the end of the GDPR letter as possible things that the data subject will provide to identify themself. We probably need to refine this - to differentiate between things that are needed to even identify a customer to kick off a request (account number, username etc.) vs things that may be asked for by the company after a GDPR request has started (e.g. security checks, copies of proof of address etc).
 +
** {{P|27}} - "alternative string name"
 +
*** In Alex Bowyer's GDPR Generator ([[User:Alexbfree/Code:GDPRMailAccess.js]]) this has been updated to make use of {{P|27}} as in the {{P|10}} list above. This is important to allow re-use of semantic concepts but with different names. It is recommended this be merged to the Le Temps generator.
 +
 +
===Issues/Clashes===
 +
* Use of {{Q|1048}} qualifier
 +
** Currently the Le Temps GDPR generator ([[MediaWiki:Access.js]]) uses the {{Q|1048}} qualifier when attached to a {{P|10}} snak and prints that text in brackets after each data point in the generated GDPR letter. Originally Alex Bowyer's GDPR Generator ([[User:Alexbfree/Code:GDPRMailAccess.js]]) used {{Q|1048}} qualifier to contain a policy excerpt but these are being migrated to {{P|287}} as we do not want these printed in the letter (also many of them are too long and break the generator. Alex's generator has switched to never print the {{Q|1048}} and he would recommend Le Temps do the same. {{Q|1048}} should be free for use by wiki users to add detail about a snak. For example see the {{P|10}} list usage in {{Q|281}}.
 +
* Figuring out how to display a {{P|10}} item's {{P|27}} string if it has one, or its main {{P|10}} item text otherwise.
 +
** This is a future To Do for @alexbfree or anyone else who wants to have a go. @podehaye has provided an idea for this, detailed here:
 +
{| class="wikitable" style="margin-left: 50px;|-
 +
| [[https://wiki.personaldata.io/wiki/Template:For Template:For]] is a template that essentially applies one template in succession to a bunch of parameters, with a separator (ignore the named variables)
 +
|-
 +
| this is based on the module [[https://wiki.personaldata.io/w/index.php?title=Module:For Module:For]]
 +
|-
 +
| do you understand why the template is limited to five named parameters while Module:For does not explicitly implement such limitation?
 +
|-
 +
| in any case what you want to solve your problem is a module TwoVariableFor, which takes a bunch of parameters and feeds them two at a time into a rendering function that takes a pair of arguments, the second one being possibly empty
 +
|-
 +
| then you want to have something like <nowiki>{{#invoke:TwoVariableFor|call=MyRenderingTemplateInPairs|firstitem|firstqualifier|seconditem||thirditem|thirdqualifier}}</nowiki> (( for instance the second qualifier was missing)
 +
|-
 +
| now the question is how you generate the list of parameters, but you can use an invoke:Wd for this
 +
|-
 +
| so: <nowiki>{{#invoke:TwoVariableFor|call=MyRenderingTemplateInPairs|{{#invoke:wd|...what you already know how to do...}}}}</nowiki>
 +
|-
 +
| it would be awesome if you managed to duplicate and modify <nowiki>Module:For</nowiki> into <nowiki>Module:TwoVariableFor</nowiki>
 +
|}
 +
 +
* Until this is done, the current workaround in Alex Bowyer's GDPR Generator ([[User:Alexbfree/Code:GDPRMailAccess.js]]) is to show <pre><named as> / <collects-text></pre> if there is a {{P|27}}, or <pre><collects-text></pre> otherwise. The latter part can be manually deleted from the generated letter on {{P|27}} items.
  
 
===FAQ===
 
===FAQ===

Latest revision as of 22:45, 11 February 2020

Use cases

The Ontology need to be suitable for data entries and the usages of those data. We need to identify use case and test the ontology against those.


Examples

Core snaks

  • instance of (P3) - data controller (Q96)
    • Both GDPR generators will not pop up if this is not present.
  • e-mail address (P17) - "mailto:johnny@example.com"
    • for (Q1062) - data controller (Q96)
      • This qualifier is not currently checked but it should be, as there may be a general support email as well as a data protection officer specific email address and we need to pick the correct one.
  • contact page (P282) - "https://company/privacy/contact"
    • This is necessary where there is no known email address for contacting the data protection officer, only a form. In these cases you probably still need to add e-mail address (P17) but with a dummy email address (and a comment qualifier making clear it is not a real address). The generated email then has to be manually pasted into the contact form for submission. For example see Apple (Q3424)
  • collects (P10) - the points of data known to be collected/stored by this company.
    • named as (P27) - "alternative string name"
      • This qualifier allows existing items to be re-used. The idea is that the 'named as' value is the display name that is used in the GDPR request letter. So if we already have 'location' but want to include 'geolocation info' because that is the term used for this concept from the company's privacy policy, we can include location (Q1078) in the collects (P10) list but add named as (P27) - 'geolocation info' as a qualifier. This is important to allow the eventual unification of different data concepts into one model despite companies describing them differently. This is currently only used in Alex Bowyer's GDPR Generator (User:Alexbfree/Code:GDPRMailAccess.js). It is recommended this be merged to the Le Temps generator. Another use of this field is to convert the pronoun to the correct form for the letter - for example the stored data point might be "information about your journeys". You can add a named as (P27) to change this to "information about my journeys" in the generated GDPR letter.
    • source (Q1117) - privacy policy (Q29) or source (Q1117) - privacy hub (Q3732)
      • This qualifier is especially important where other data points have already been added to the collects (P10) list from different sources. This is used to distinguish things we have learnt from different sources. We should update our GDPR generators to only include the collects (P10) items from the sources we want to use (which may differ per project).
    • policy excerpt (P287) - "Extract from privacy policy which shows why this data point is believed to be stored."
      • Add more than once if a long extract is needed. Take care to remove spaces from end of string or you will get a `Malformed text` error.
  • official website (P15) - URL (optional really)
  • states compliance (P32) - privacy policy (Q29)
  • requires (P122) - any item that is required by the company
    • Currently all items in the requires (P122) list will be included at the end of the GDPR letter as possible things that the data subject will provide to identify themself. We probably need to refine this - to differentiate between things that are needed to even identify a customer to kick off a request (account number, username etc.) vs things that may be asked for by the company after a GDPR request has started (e.g. security checks, copies of proof of address etc).
    • named as (P27) - "alternative string name"

Issues/Clashes

[Template:For] is a template that essentially applies one template in succession to a bunch of parameters, with a separator (ignore the named variables)
this is based on the module [Module:For]
do you understand why the template is limited to five named parameters while Module:For does not explicitly implement such limitation?
in any case what you want to solve your problem is a module TwoVariableFor, which takes a bunch of parameters and feeds them two at a time into a rendering function that takes a pair of arguments, the second one being possibly empty
then you want to have something like {{#invoke:TwoVariableFor|call=MyRenderingTemplateInPairs|firstitem|firstqualifier|seconditem||thirditem|thirdqualifier}} (( for instance the second qualifier was missing)
now the question is how you generate the list of parameters, but you can use an invoke:Wd for this
so: {{#invoke:TwoVariableFor|call=MyRenderingTemplateInPairs|{{#invoke:wd|...what you already know how to do...}}}}
it would be awesome if you managed to duplicate and modify Module:For into Module:TwoVariableFor

FAQ

Q: how do we refer to privacy policy? there are a few different ways to do it.

  • A: The correct one is privacy policy (Q29) though we have previously used Q3405 and some usages of this still need to be migrated. Q3667 and Q173 are erroneous and should be deleted.

Data rights snaks

Multiple choice between different options

References

PREFIX pdio: <https://wiki.personaldata.io/entity/>
PREFIX pdiot: <https://wiki.personaldata.io/prop/direct/>
PREFIX pdiop: <https://wiki.personaldata.io/prop/>
PREFIX pdiops: <https://wiki.personaldata.io/prop/statement/>
PREFIX pdiopq: <https://wiki.personaldata.io/prop/qualifier/>
SELECT ?item ?itemLabel ?link WHERE {
  ?item pdiot:P110 pdio:Q3006. #P110 <-concerns Q3006 <-ontology model	
  OPTIONAL {?item pdiot:P15 ?link.}
  SERVICE wikibase:label {
    bd:serviceParam wikibase:language "en" . 
  }
}
LIMIT 100

sources on (GDPR) ontology modeling (embedded)

Retrieved from "https://wiki.personaldata.io/w/index.php?title=Project:Vocabulary/GDPR&oldid=80260"