View source for Workshop20201104

= DPVCG Workshop 04-NOV-2020 =

* Dates: 04-NOV-2020
* Time: 09:00 -- 16:00 CET
* Resolution of date: [https://www.w3.org/2020/10/07-dpvcg-minutes.html Meeting Call 07-OCT-2020]
* Poll to participate: https://framadate.org/dpvcg-workshop-4NOV20
* Meeting link and Call details: see [https://lists.w3.org/Archives/Member/internal-dpvcg/2020Sep/0000.html 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.

# 09:00 - 10:00 Resolution on DPV correctness and suggested usage with OWL/RDFS
#* relevant emails in mailing list: [https://lists.w3.org/Archives/Public/public-dpvcg/2020Sep/0009.html OWL2-DL incompatiblity], [https://lists.w3.org/Archives/Public/public-dpvcg/2020Sep/0001.html possible use of SKOS], [https://lists.w3.org/Archives/Public/public-dpvcg/2020May/0011.html specifying suitability of encodings], [https://lists.w3.org/Archives/Public/public-dpvcg/2020Apr/0018.html 4 approaches for expressions], [https://lists.w3.org/Archives/Public/public-dpvcg/2020Apr/0010.html DPV uses RDFS, not OWL classes], [https://lists.w3.org/Archives/Public/public-dpvcg/2020Apr/0005.html consequence of creating instances], [https://lists.w3.org/Archives/Public/public-dpvcg/2020Apr/0003.html issues with blank nodes], [https://lists.w3.org/Archives/Public/public-dpvcg/2020Apr/0000.html starting email in thread]
# 10:00 - 11:00
## DPV term-addition and documentation process: [https://github.com/coolharsh55/dpv-documentation GitHub repository] used for generating serialisations and documentation
## DPV Use-Cases and Examples: [https://github.com/dpvcg/use-cases GitHub repository] for collecting use-cases
## Specifying 'examples' of DPV usage based on use-cases: starting with some use-cases
## DPV Primer document: [https://docs.google.com/document/d/1FrPFTRUAreEipvM5hTPPqfnhOl0rBjXpXCMicw9me30/edit?usp=sharing DPV Primer - Google Docs]
# 11:00 - 13:00 Deciding on terms proposed for adoption to DPV (see spreadsheet used to collect terms and relevant emails below)
# 13:00 - 14:00 Lunch / Break
# 14:00 - 15:30 Deciding on terms proposed for adoption to DPV (see spreadsheet used to collect terms and relevant emails below)
# 16:00 - wrap up meeting, decide on future items

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

relevant emails: 
* [https://lists.w3.org/Archives/Public/public-dpvcg/2020Mar/0004.html Legal basis for transfer of personal data]
* [https://lists.w3.org/Archives/Public/public-dpvcg/2020May/0003.html Representation of GDPR rights]
* [https://lists.w3.org/Archives/Public/public-dpvcg/2020Jun/0021.html Concepts for privacy policy generation]
* [https://lists.w3.org/Archives/Public/public-dpvcg/2020Jun/0017.html Personal data categories in the online context]
* [https://lists.w3.org/Archives/Public/public-dpvcg/2020Jun/0018.html Purpose categories in the online context]
* [https://lists.w3.org/Archives/Public/public-dpvcg/2020Jun/0020.html Missing concepts in dpv from GDPR Art 13 and 14, Treaty 108 and ISO/IEC 29184]
* [https://lists.w3.org/Archives/Public/public-dpvcg/2020Aug/0001.html DPV to map the GDPR Register of Processing Activities]

== Attendees / Participants ==
# Harshvardhan J. Pandit (chair)
# Fajar J. Ekaputra
# Nishad Thalhath
# Piero Bonatti
# Beatriz Esteves
# Paul Ryan
# Georg Krogg
# George Lioudakis
# 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.