Workshop20201104

DPVCG Workshop 04-NOV-2020

• Dates: 04-NOV-2020
• Time: 09:00 -- 16:00 CET
• Resolution of date: Meeting Call 07-OCT-2020
• Poll to participate: https://framadate.org/dpvcg-workshop-4NOV20
• Meeting link and Call details: see internal mailing list
• Minutes: see below
• Notes: see below

Agenda

Given the virtual setting, we will have a short break at the end of every hour or on request.

1. 09:00 - 10:00 Resolution on DPV correctness and suggested usage with OWL/RDFS
   • relevant emails in mailing list: OWL2-DL incompatiblity, possible use of SKOS, specifying suitability of encodings, 4 approaches for expressions, DPV uses RDFS, not OWL classes, consequence of creating instances, issues with blank nodes, starting email in thread
2. 10:00 - 11:00
   1. DPV term-addition and documentation process: GitHub repository used for generating serialisations and documentation
   2. DPV Use-Cases and Examples: GitHub repository for collecting use-cases
   3. Specifying 'examples' of DPV usage based on use-cases: starting with some use-cases
   4. DPV Primer document: DPV Primer - Google Docs
3. 11:00 - 13:00 Deciding on terms proposed for adoption to DPV (see spreadsheet used to collect terms and relevant emails below)
4. 13:00 - 14:00 Lunch / Break
5. 14:00 - 15:30 Deciding on terms proposed for adoption to DPV (see spreadsheet used to collect terms and relevant emails below)
6. 16:00 - wrap up meeting, decide on future items

spreadsheet used to collect terms: https://docs.google.com/spreadsheets/d/11bjy424zwC_j4bj9pnhmmI8o7RgrJfX4NgsZ31iR3Wo/

relevant emails:

• Legal basis for transfer of personal data
• Representation of GDPR rights
• Concepts for privacy policy generation
• Personal data categories in the online context
• Purpose categories in the online context
• Missing concepts in dpv from GDPR Art 13 and 14, Treaty 108 and ISO/IEC 29184
• DPV to map the GDPR Register of Processing Activities

Attendees / Participants

1. Harshvardhan J. Pandit (chair)
2. Fajar J. Ekaputra
3. Nishad Thalhath
4. Piero Bonatti
5. Beatriz Esteves
6. Paul Ryan
7. Georg Krogg
8. George Lioudakis
9. Rana Sanei

Meeting minutes, notes

Resolution on DPV suggested usage

• Piero: RDF treats terms as instances and compliance checking (with OWL) requires classes
• Piero shared screen: (summary of emails) consent as expression which is then converted to OWL ‘policy’ which can then be converted to other forms
• Property domain and range restrictions are the ones causing issues since they have incompatibilities such as classes as instances of themselves
• Agreement: remove property assertions to ‘free up the vocabulary’, make note that additional assertions/restrictions can be added with caveat emptor about implications from ‘mixing contexts’
• isExplicit as a boolean property: two issues - (i) how to express additional attributes such as ‘freely given’ (ii) what happens if there is no information about isExplicit (open-world)
• Possible solutions: ExplicitConsent as class ; ConsentType as class with property hasType → discussion on mailing list

DPV term-addition and documentation process

• https://github.com/coolharsh55/dpv-documentation
• Agreement: Move to DPVCG github (transfer ownership)

DPV Use-Cases and Examples

• What do group members prefer or wish to see in terms of use-cases and examples?
• Start with simple use-cases e.g. controller uses processor OR processing uses personal data category ; and work up towards the consent policy (as more complex example)
• TRAPEZE (follow-up) to SPECIAL project, will be developing the technology to a higher maturity level ; and the use-cases can be shared with the group for discussion
• Agreement: have different use-cases and examples (not necessarily one for each) for simple and complex use-cases (some of each at the minimum)
• Specifying 'examples' of DPV usage based on use-cases
• Agreement: Specify examples in RDFS and OWL for each
• Should we also specify in JSON-LD? Piero: JSON-LD is missing a good way to express the OWL assertions (e.g. union)

DPV Primer document

• We have a primer document https://docs.google.com/document/d/1FrPFTRUAreEipvM5hTPPqfnhOl0rBjXpXCMicw9me30/
• Harsh volunteers to author/edit, Beatriz volunteers to help with writing

Resolution on Proposed Terms

• Discussing rights: GDPR rights in spreadsheet
  • Agreement: Namespace in dpv-gdpr; Name term IRI as per legal clause reference, label as legal clause + mnemonic ; Create base class ‘Rights’
• Data subject identity: already exists (as IRI)
• Data Controller identity: legal requirements require name, address, contact
  • Agreement: we create properties for name, address, contact with no granularity and specify how to use and how to extend these as needed
• Automated decision making
  • Agreement: remove the boolean properties in Processing and add them as classes so that more information can be associated with it
  • Agreement: add properties for Automated Decision Making regarding decision consequences, logic, human involvement
• Data transfers and legal basis (adequacy decision in GDPR)
  • Agreement: For data transfers we can reuse (repurpose) the existing location property (associated currently with storage) to specify location as destination or jurisdiction of the recipient and transfer
  • Agreement: accept the legal basis for adequacy definitions and legal basis for transfers ; add them to the GDPR namespace
  • in the next iteration we have action to identify concepts from these legal bases and see whether we want to add them and where they fit in DPV
• Concluding remarks and resolutions

The following terms are to be added/modified:

• dpv:Rights as a top-level concept for the expression of Rights afforded to an individual
• GDPR rights added to DPV-GDPR namespace
  • A13
  • A14
  • A15
  • A16
  • A17
  • A18
  • A19
  • A20
  • A21
  • A22
  • A7-3
  • A77
• GDPR legal basis based on data transfers and adequacy decision added to DPV-GDPR namespace
  • A46
  • A49
• The following properties in TechnicalOrganisationMeasure are to be ‘relaxed’ in terms of assertions on domain and range so as to allow their reuse in other contexts
  • Storage
  • Location
  • Duration
• Single Sign-on added as subclass of dpv:AuthenticationProtocols in TechnicalOrganisationalMeasure
• DataSource concept and related properties hasDataSource added to Processing to indicate the source of data.
• Following classes added to Processing for identification and expression of information associated with them:
  • DataSource
  • SystematicMonitoring
  • EvaluationScoring
  • MatchingCombining
  • AutomatedDecisionMaking along with its related properties hasLogicInvolved, hasConsequences, and hasHumanInvolvement
• Following list of purposes added:
  • DirectMarketing
  • Advertising
  • PersonalisedAdvertising
  • TechnicalServiceProvision
  • RequestedServiceProvision; with the existing dpv:DeliveryOfGoods modified to be a subclass of it
  • UsageAnalytics
  • Communication
  • LegalCompliance
  • Marketing
  • Payment
  • SocialMediaMarketing
  • Registration
• Following general properties added for expressing information about legal entities
  • hasName
  • hasAddress
  • hasContact
• Added DPO (Data Protection Officer) and Supervisory Authority as a legal entity
• Added Representative as a generic concept and related property hasRepresentative to associate it with a legal entity

The following terms are to be removed:

• Boolean attributes for processing remove (see their additions as classes above)
  • isSystematicMonitoring
  • isEvaluationScoring
  • isMatchingCombining
  • isAutomatedDecisionMaking
  • isLargeScale
  • innovativeUseOfNewSolutions

Next Meeting / Continuation

Next meeting: Wednesday 2020-11-18 14:00 CET in the usual time-slot. Continuation of resolving terms proposed for DPVCG.