Meeting minutes
Repository: w3c/dpv
Meeting minutes: https://
purl for this meeting: https://
Noted AOB item from delaram
delaramGolpayegani: what is the connection between data in DPV and dataset in DCAT?
harsh: they are similar concepts and you can use both of them together e.g. something is an instance of dpv:Data and dcat:Dataset, but not good to combine them in terms of relationships e.g. subclass relationship as differen datasets can contain same data, or data can contain multiple datasets.
Legal Basis
<ghurlbot> Issue 111 Model information about legal bases (by coolharsh55)
Contract
no comments or changes identified - accepted the concepts as discussed in previous minutes
Other Legal Basis
no comments or changes identified - accepted the concepts
For legal basis concepts, they are accepted in principle.
ACTION: Add legal basis concepts to DPV
Rules
concepts to model rule fulfilment as statuses, aligned with concepts from contract clause fulfilment
georgKrog: PermissionObligation and Obligation in contract law are different, how to express that? For example, to express that you have permission to use a book, but if you read beyond certain pages then you have to pay?
harsh: that is an obligation within a permission, which can be done with DPV concepts - but we don't define the interpretation of nested rules. Also its better to look towards ODRL for this use-case as it has defined interpretations and also because it specifically models contracts.
agreed - okay to continue with Rules concepts
ACTION: Add rules concepts to DPV
Risk Taxonomy
<ghurlbot> Issue 181 Refine RISK taxonomy into a single consistent hierarchy (by coolharsh55)
recap: single hierarchy of concepts grouped based on different topics, adopter picks the concept and the role it plays in the use-case e.g. whether it is a consequence or an impact
delaramGolpayegani: this is an issue where some concepts do not make sense for a chosen role e.g. violence against children as a risk source doesn't make a lot of sense. Not necessarily a blocking problem, but something to think about.
harsh: Indeed, but don't know another solution that will allow flexibility while also providing clarity regarding roles. The previous model had us assert something is always a risk source or impact - which is not true. So in this case, we ask the adopter to choose the concept and the role.
delaramGolpayegani: for specific AI related risks it is not possible to pick from this list, and we would have to have an extension or another way to distinguish these
harsh: this is something we discussed earlier, so yes, the consensus as I remember it as was to put the AI specific risks in the AI extension
paul: are you trying to make it more flexible?
harsh: yes, the goal is to keep things flexible
georg: can be explained in an example
mark: communicate risk and liability - who is responsible for the risk
delaram: this could be modelled with ODRL e.g. with the AI use profile which expresses the liability if something happens
consensus - okay to move ahead with the risk taxonomy and to provide sufficient guidance and examples in the documentation to clarify how the concepts work. For AI specific risks, we have the AI extension.
harsh: of note, the Spanish DPA (AEPD) had a paper at APF where they created a threat taxonomy where they extended the LINDDUN privacy threats taxonomy with data protection relevant concepts Implications of Age Assurance on Privacy and Data Protection: A Systematic Threat Model https://
ACTION: Continue with Risk taxonomy model, consolidate taxonomy, create risk concepts in AI extension
Sector
<ghurlbot> Issue 177 [Concept]: Sectors should be defined in DPV (main spec) (by coolharsh55)
harsh: question is whether we should model Sector taxonomy in DPV or we suggest use of authoritative taxonomies such as NACE and NAICS
paul: official source is important
delaram: for the AI Act checked the sectors mentioned and they map quite well with NACE, wording is not the same but they are mostly covered so no need for duplicates
georg: there are different regulations such as emission of carbon, digital products where ID must be declared, which all require a standardised way to document the sector in which they are active in - so the one in DPV would need too much work and shouldn't be done
agreed with consensus - not to model sector in DPV
Fee
<ghurlbot> Issue 185 [Concept]: Add Fee concept to DPV, remove it from RISK (by coolharsh55)
paulRyan: real concepts required in GDPR where they are required, so they have sufficient granularity to do what we need to do
georgKrog: yes, agreed it is useful
accepted with consensus
ACTION: Add Fee concepts to DPV
Updates
<ghurlbot> Issue 183 Represent activities where DPIA is required in EU-GDPR (by coolharsh55)
tyttiRintamaki: for DPIA concepts in DPV, will have updates next week with the concepts and examples
<ghurlbot> Issue 182 Adding AI bias concepts (by DelaramGlp)
harshPandit: for the AI Bias concepts, Daniel sent an email with updates - will go through and have a proposed resolution next week.
<ghurlbot> Issue 186 Create Mapping between GDPR and DPV (by coolharsh55)
harshPandit: for the mapping of GDPR with DPV, Prinon informed that he is busy and will have updates possibly next week.
Annual Privacy Forum
harsh: DPV work on consent won the best paper award at APF, and was visible/presented in front of DPAs https://
harsh: notes from APF available on website https://
Next Meeting
next meeting will be in 1 week on TUESDAY 17 September at 13:30 WEST / 14:40 CEST. Agenda will be updates on resolutions from today with any updates on github/mailing list and AOB.