Meeting minutes
Meeting minutes: https://
purl for this meeting: https://
DPV maintainence
art is looking into managing issues in the GitHub repo, but cannot manage the labels; harsh will check how to give access to issue management to art
harsh suggested to look at labels later from the new year as a lot of issues are expected to be resolved in the coming days with the documentation updates
SPDX AI documentation
art shared the SPDX work on providing metadata documentation for AI as software - spdx/
From DPV, the use of controlled vocabulary and more specific fields such as different types of assessments or providing links to relevant information would be helpful to share back e.g. to find specific assessments regarding safety, security, technical attributes for performance, as well as jurisdictional / legal concepts.
art has highlighted that SPDX is from security community so they care about software/security risks and assessments rather than other forms of risk assessments
Process concept
<ghurlbot> Issue 121 dpv:Process as a superclass of dpv:PersonalDataHandling to describe any data processing (by coolharsh55)
From the previous meetings, the conclusion were to accept option 3 which is creating the new Process concept with existing PersonalDataHandling as the subclass. Harsh suggested a new option (4) with creating PersonalDataProcess as the name to use the more commonly used Process instead of Handling which no one else uses. This also makes it easier to align the vocabulary to others. The existing concept PersonalDataHandling will be retained and marked for depreciation in the future.
Group agreed with the proposal, this will be discussed later to ensure consensus.
Service new concept
<ghurlbot> Issue 124 Add dpv:Service as a concept (by coolharsh55)
Question about distinction from 'technology as service' concept in Tech extension and when used e.g. for cloud terminology (PaaS)
From the previous meetings, the group has agreed that providing this concept would be useful as it comes up in several contexts e.g. to represent the products and services associated with a purpose so as to provide context for their interpretation.
The ambiguity with technology as a service, e.g. cloud offerrings such as SaaS, can be resolved by calling those concepts as TechnologyProvision and with names that assist in documenting how the technology is being obtained and operated i.e. whether it is a subscription, remote/cloud service, or on-premises installation, etc.
The dpv:Service concept would be more aligned with business terminology rather than technical ones (e.g. OS services), and its use would be to support legal implications that rely on 'service' as a term - such as Digital Services Act.
DPV documentation
harsh has been working on DPV documentation modifications, and has new features that show broader/narrower concepts for a given concept, with a path (/parent grandparent/) for broader concept where relevant e.g.
In EU-GDPR documentation, the legal basis and rights mappings have been added, and there is a gap for Art.17 regarding Right to Rectification which is not associated with any legal basis - see https://
Next Meeting
The next meeting will be in 1 week on WED DEC-20 15:00 WET / 16:00 CET.
harsh will be working on documentation and updating issues
<ghurlbot> Issue 63 Add Right Non-fulfilment Justifications for GDPR’s rights (by besteves4)
beatriz suggested adding justifications from Art.17-1 regarding why the right is being exercised; harsh has agreed with this being in scope and to be modelled; For these concepts a new class of justifications would be modelled to represent the individual using them to exercise their right, something like RightExerciceJustification
tytti is looking into guidelines on DPIA and AI from DPAs, which relate to DPV in terms of information required for assessments