Meeting minutes
Privacy / Policy concepts
Last time we stopped discussion at discussing DPA and property hasAuthority
Concepts for indicating Policy - Properties hasPolicy and isPolicyFor have been added
Concepts for indicating applicability of PersonalDataHandling - property hasPersonalDataHandling has been added
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
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.
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.
Concept for indicating JointDataController has been added. To indicate membership, the JointDataController should be associated with member controllers using hasDataController property.
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.
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
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.
Proposed subclasses of DataProcessingAgreement include - DataProcessorAgreement to indicate Controller - Processor or Processor - Processor agreements; and JointDataControllersAgreement to indicate Joint Data Controllers agreement (Controller - Controller)
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.
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.
Discussing benefits and recipient of benefits i.e. beneficiary
DPV currently contains the concepts Benefit (hasBenefit) and Beneficiary (hasBeneficiary)
Proposal to add corresponding concepts related to Detriment (hasDetriment), Harm (hasHarm) - though it is unclear how to express who this impacts/affects.
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.
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'.
Consequences (and its specialisation as benefits, detriments, and harms) are important when considering balancing tests, legitimate interests, and impact assessments.
Discussing how to indicate some personal data is optional.
Options presented were - create sub-properties for optional (hasOptionalPersonalDataCategory) and mandatory (hasMandatoryPersonalDataCategory) to express their necessity.
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.
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 <<PDH hasPersonalDataCategory PDC>> isOptional True
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)
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.
Discussing Data Sources being public. Proposal is to add two subclasses regarding PublicDataSource and NonPublicDataSource.
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.
Consensus that a note is needed when adding this concept stating the need to consider definition of public where the concept is used.
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.
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)
For Jurisdiction, harsh proposes adding Country, SupraNationalUnion (e.g. EU), and EconomicUnion (e.g. EEA) as subclasses.
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://
Next Meeting
We will meet in +1 week on NOV-10 13:00 WET / 14:00 CET
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