Meeting minutes
Repository: w3c/dpv
Meeting minutes: https://
purl for this meeting: https://
Noted AOB item: Tytti to discuss DPIA work
Intro
prinonDas: Masters research in Aachen, Germany ; proposed mapping between GDPR and DPV
Legal Basis
<ghurlbot> Issue 111 Model information about legal bases (by coolharsh55)
Consolidating Contract concepts
harshPandit: following last week's discussion, we agreed that the different kinds of contracts and agreements are all legal bases and should be consolidated into a coherent and consistent vocabulary. To reflect this, I have moved the contract concepts from Legal Measures to create a single set of concepts. However, there is now duplicacy in the concepts e.g. DataProcessorContract and ControllerProcessorAgreement reflect the same concept. The name commonly used in industry is ...Agreement, therefore we should keep these concepts and remove the other ones.
paulRyan: agree on this, and also that Agreement is the preferred term in use for such concepts
harshPandit: instead of immediately removing the old concepts we can sunset them so as to give time to make changes if needed
ACTION: consolidate contract taxonomy and sunset the not required concepts
Contract Taxonomy
harshPandit: should we keep the the B2C etc. concepts? Are they useful? I also added in G2B and other relevant government concepts - except C2G which seems to not be well adopted and defined as compared to the others.
georgKrog: yes, these would be useful to have and we should add them
agreed to add these
harshPandit: Other contract concepts include contract clause types, contract statuses, contract controls, and contract/clause fulfilment states.
agreed to add these
ACTION: add contract clause types, contract statuses, contract controls, and contract/clause fulfilment states
Standard Form Contract
harshPandit: From the IEEE P7012 perspective of modelling contracts, we have Negotiated contract and non-negotiated contract which is called Standard Form Contract. For non-negotiated contract, which entity drafted the terms is relevant - typically it is the controller or service provider, but with P7012 it can also be the individual or consumer. To reflect these, two new concepts are proposed as subclasses of Standard Form Contract - ProviderStandardFormContract to indicate the provider drafted it and ConsumerStandardFormContract to indicate the consumer drafted it.
iainHenderson: would prefer to use individual instead of consumer to indicate the onus or burden is not on the person to do everything and to highlight that the work is done in an individual capacity
harshPandit: agreed, though in this case it is consumer because the entity may or may not be a person e.g. an organisation receiving the service
agreed to add these
Statuses
harshPandit: for the other legal bases other than consent and contract, no further concepts are needed to model them as the required concepts are present in DPV already e.g. for Legal Obligation there is dpv:hasApplicableLaw. Should we model statuses to keep track of the fulfilment of these other legal bases?
georgKrog: yes, these would be essential to model the legal bases
harshPandit: okay, so we have the statuses for Legitimate Interest. For others, they can be as follows: Legal Obligation - fulfilled, not fulfilled, being fulfilled. Official Authority - exercised, not exercised, being exercised. Vital Interest - (vital interest) identified, protected, not protected, being protected, objected. Public Interest - (benefit) identified, being provided, provided, not provided, objected.
ACTION: create statuses for other legal bases
Fee
<ghurlbot> Issue 185 [Concept]: Add Fee concept to DPV, remove it from RISK (by coolharsh55)
harshPandit: as discussed in the last meeting, Fee is not a kind of risk or impact, and we discussed moving it to DPV. Instead of directly moving the concept Fee, it would be better to have the concept as a context - FeeRequirement with two concepts representing whether fee applies FeeRequired and doesn't appy FeeNotRequired. To indicate the value of the fee, rdf:value is used or another way of representing this.
harshPandit: the advantage of creating a separate concept instead of directly specifying the value is that the concept enables attaching other information to it e.g. specific currencies or duration within which fee must be paid or to whom and when
georgKrog: we should indicate who should pay it? when? etc.?
harshPandit: this might be property for who pays the fee e.g. dpv:hasFeePayer and we can reuse dpv:hasRecipient here to indicate who receives the fee. Duration, Frequency, etc. can be used to indicate more information about the fee.
georgKrog: we should also have statuses to keep track of whether fee is paid e.g. fee paid, fee unpaid
agree to add these
ACTION: create Fee concepts
Rights Impact
<ghurlbot> Issue 184 Add Rights Impact concepts for each Right (by coolharsh55)
harshPandit: to model impacts on rights, we have the concept RightsImpact. To model specific categories of impacts, we will need different kinds of impacts - should we create specific kinds of impacts? For each specific right?
georg and tytti agree that this would be helpful
ACTION: Create rights impact categories and create rights impact concepts for each right
Mapping between GDPR and DPV
<ghurlbot> Issue 186 Create Mapping between GDPR and DPV (by coolharsh55)
harshPandit: Prinon proposed that we do a mapping between GDPR and DPV concepts i.e. for which GDPR clause which concept in DPV is relevant. Through this exercise, we can see where we lack concepts, and also for GDPR practioners this will give useful information on how to use DPV. The idea is to put this as a table in the EU-GDPR extension.
georgKrog: this would be a good idea, we should also show which concepts are required in which process e.g. what is needed for a ROPA, what is needed for a DPIA
paulRyan: for ROPA - there is the DPCat work that does this
georgKrog: good start with ROPA by paul and harsh - we can start with that
agree to do this
prinonDas: what would be the timeline for this? Would prefer to get this done by 9th October.
harshPandit: okay, that's doable
georgKrog: interested in participating in this
ACTION: Create a mapping from GDPR to DPV
DPIA
<ghurlbot> Issue 183 Represent activities where DPIA is required in EU-GDPR (by coolharsh55)
tyttiRintamaki: proposing 76 concepts to be added to EU-GDPR extension for conducting DPIA based on analysis of DPIA guidelines; will share the list by email for feedback. Each concept is derived from a DPIA requirement i.e. what processing activities require a DPIA based on DPIA guideline. On github, there will be an example for how to represent the activity in RDF using DPV.
harshPandit: We created a new concept called eu-gdpr:DPIARequiredProcess which will be a subclass of dpv:Process and represents the cases where a DPIA is required based on GDPR, EDPB, or a DPA guideline. The idea is that the process concepts is used to match processes, e.g. purpose and personal data - and if there is a match, then it means a DPIA is required.
AI Bias
<ghurlbot> Issue 182 Adding AI bias concepts (by DelaramGlp)
danielDoherty: added the RDF for the AI Bias concept - though there is an error in the ISO standard being noted - it should be 2021 for the final published document and not 2020 as noted in the RDF. The version I used was the CD draft. Will update the definitions to the final published version - the concepts are the same as verified through the table of concepts.
Next Meeting
next meeting will be in 1 week on TUESDAY 03 September at 13:30 WEST / 14:40 CEST. Agenda will be continuation of today's topics with any updates on github/mailing list and AOB. Harsh will be away at the Annual Privacy Forum presenting the ISO 27560 DPV paper.