13:00:33 RRSAgent has joined #dpvcg 13:00:33 logging to https://www.w3.org/2021/11/03-dpvcg-irc 13:01:36 ScribeNick: harsh 13:01:39 Meeting: DPVCG Meeting Call 13:01:41 Chair: harsh 13:01:54 Present: harsh, paul, georg 13:02:12 Date: 03 NOV 2021 13:02:20 Agenda: https://lists.w3.org/Archives/Public/public-dpvcg/2021Nov/0000.html 13:02:53 Present+: julian 13:04:40 Present+: beatriz 13:06:59 Topic: Privacy / Policy concepts 13:07:22 Last time we stopped discussion at discussing DPA and property hasAuthority 13:41:26 Present+ InahOmoronyia 14:20:07 Concepts for indicating Policy - Properties hasPolicy and isPolicyFor have been added 14:20:28 Concepts for indicating applicability of PersonalDataHandling - property hasPersonalDataHandling has been added 14:21:14 Concepts for indicating Jurisdiction - the classes Jurisdiction and Country (pending resolution of clash with personal data category of same name) have been added along with properties hasJurisdiction and hasCountry respectively 14:21:53 Note that hasCountry is indicative only of relating a country to some concept, it can be used for indicating has country of - operation, location, headquartered, etc. We do not delve into such granularity at this time. 14:22:43 Concepts for indicating applicability of authority - property hasAuthority has been added to indicate an authority is applicable or related to some concept. Intention is to associate DPA with a jurisdiction, but this can be used for other concepts and authorities as well. 14:23:36 Concept for indicating JointDataController has been added. To indicate membership, the JointDataController should be associated with member controllers using hasDataController property. 14:24:59 JointDataController is a subclass of Controller to ensure the same applicability of obligations and requirements. Semantically, this is okay since a Controller would be an instance and a JointController could be an instance representing the collective group or representing the set of controllers, though strictly interpreting it as saying a JointDataController(s) instance is a singular data controller is not correct. 14:25:50 Concept for DataProcessingAgreement has been added as subclass of LegalAgreement. This can be any agreement between any party regarding the processing of personal data, e.g. Controller - Controller or Controller - Processor or Controller - Third Party 14:26:55 Note that 'Agreement' and 'Contract' can be interpreted as two separate terms even though they may be used as synonyms in many places. Here, a contract is more formal and legally regularised as compared to an agreement, and therefore DPV models the agreement. To represent a 'Data Processing Contract' the term DataProcessingAgreement is suitable and sufficient. 14:30:53 Proposed subclasses of DataProcessingAgreement include - DataProcessorAgreement to indicate Controller - Processor or Processor - Processor agreements; and JointDataControllersAgreement to indicate Joint Data Controllers agreement (Controller - Controller) 14:32:33 Proposed subclasses of DataSubject include - Adult (to contract with Child in DPV), WebsiteVisitors, Customers, Clients (isSameAs Customers?), Patients, Employees, Members, Users, Applicants, JobApplicants, Visitors, Students, Citizens, NonCitizens, Immigrants, Tourists, Trainees. 14:33:07 These will be discussed later based on need to provide a subclass e.g. governments or banks require employees, universities require staff and students, and so on. 14:33:23 Discussing benefits and recipient of benefits i.e. beneficiary 14:33:55 DPV currently contains the concepts Benefit (hasBenefit) and Beneficiary (hasBeneficiary) 14:34:28 Proposal to add corresponding concepts related to Detriment (hasDetriment), Harm (hasHarm) - though it is unclear how to express who this impacts/affects. 14:36:20 Instead, separate proposal to abstract these (benefits, detriments) into 'Consequence' and associate them using 'hasConsequence' (DPV already contains this property in Processing module). Then, by adding Benefit, Detriment, and Harm as subclasses of Consequence it is possible to represent them uniformly. 14:37:40 To indicate whom the consequence affects, the property 'isConsequenceAffecting' can be used, with the target being any entity. This permits specifying a consequence of type 'benefit' affects the 'data controller' in the same model as stating a consequence of type 'harm' affects the 'data subject'. 14:38:13 Consequences (and its specialisation as benefits, detriments, and harms) are important when considering balancing tests, legitimate interests, and impact assessments. 14:38:36 Discussing how to indicate some personal data is optional. 14:39:11 Options presented were - create sub-properties for optional (hasOptionalPersonalDataCategory) and mandatory (hasMandatoryPersonalDataCategory) to express their necessity. 14:39:47 However, issues as to how to indicate other concepts are optional e.g. optional purpose or optional processing or optional technical measure then arise, and creating such properties for each concept is not desirable. 14:40:36 Instead, discussion focused around whether the 'relation' or 'property' could be annotated to express that it is optional within that context. In RDF-star, this is something akin <> isOptional True 14:41:24 RDF-star and Neo4J' style property annotations are two candidates for how this can be expressed. However, a way to indicate optionality is still needed, and investigation whether this can work for other models (e.g. OWL, SKOS) 14:42:32 One idea is to create 'contexts' for Optional and Necessary/Mandatory and use them using the RDF-star annotation model (or others). This can enable someone not wanting property-level annotations to have a way to incorporate that same concept for optionality e.g. by subclassing or another property. 14:43:00 Discussing Data Sources being public. Proposal is to add two subclasses regarding PublicDataSource and NonPublicDataSource. 14:43:42 Discussion on what it means for source to be 'public' - does it have to be accessible, does it have to be publicly available, open, licenced? There are no globally accepted definitions of this. 14:44:03 Consensus that a note is needed when adding this concept stating the need to consider definition of public where the concept is used. 14:45:08 ISO 29184 mentions four categories of data sources based on relation to person: external (e.g. third party), directly provided (e.g. in a form), observed (e.g. fingerprint location), inferred (e.g. correlation). Consensus that representing these will be valuable in DPV. 14:47:03 So with the public data source and ISO 29184, the categorisation of sources is as follow - DataSubjectAsDataSource (ProvidedByDataSubject, ObservedFromDataSubject, InferredFromDataSubject) and ExternalDataSource (PublicDataSource, NonPublicDataSource, ProcessorDataSource, ThirdPartyDataSource) 14:47:50 For Jurisdiction, harsh proposes adding Country, SupraNationalUnion (e.g. EU), and EconomicUnion (e.g. EEA) as subclasses. 14:48:53 Using this as an proposal, harsh has created an example file for countries, their DPAs, EU and EEA membership, and ISO codes. See here - https://github.com/coolharsh55/dpv-x/blob/master/dpv-jurisdictions/juris.ttl (note this link may not work in future depending on changes to that repo) 14:48:57 Topic: Next Meeting 14:50:14 We will meet in +1 week on NOV-10 13:00 WET / 14:00 CET 14:52:17 We will be discussing the following concepts next week - DataSubject subclasses, modelling of benefits and detriments, representing optionality of personal data and other concepts, data sources, and jurisdictions 14:53:43 zakim, bye 14:53:43 leaving. As of this point the attendees have been harsh, paul, georg, :, julian, beatriz, InahOmoronyia 14:53:43 Zakim has left #dpvcg 14:53:51 rrsagent, publish minutes v2 14:53:51 I have made the request to generate https://www.w3.org/2021/11/03-dpvcg-minutes.html harsh 14:53:53 rrsagent, set logs world-visible 14:55:27 rrsagent, bye 14:55:27 I see no action items