Meeting minutes
Decision on Personal Data Categories naming and extension
harsh: Consensus seems to be on moving personal data categories to an extension as it allows using categories as they are, but also keeping them separate i.e. cleaner and modular design
harsh: Another related issue is that the name `PersonalDataCategory` is not appropriate to indicate an instance of personal data, e.g. me@example.com
inah: is the concept of a 'category' exhaustive enough to indicate what personal data is involved
Current proposal is to move personal data categories to a separate extension (dpv-pd) and keep the core concepts within the main DPV
Proposal accepted, no objections or reservations
Some concerns about backwards compatibility and what the changes will imply for users/adopters
However, this change permits evolving personal data vocabulary separately from rest of DPV, and also prevents confusion about concepts (e.g. Location) common to both
Renaming PersonalDataCategory to PersonalData
Github issue#27https://
Reason is that PersonalDataCategory (PDC) is indicative of categories, not instances of personal data
So, for indicating a particular personal data instance, such as me@example.com is involved, is not possible
doing hasPDC 'me@example.com' is incorrect as it declares it as an 'instance of category'
Hence, proposal is to rename PDC to just PersonalData (PD)
With PD, instances can be represented correctly as hasPD X where X is an instance of PD
With PD, categories or groups or sets can also be represented using the semantics of classes, such as hasPD X where X is a subclass of PD
Proposal accepted without objections or reservations other than backwards compatibility and indicating change to users/adopters
A note on real-world usage of PD - both instances and classes/categories are used interchangeably as required within use-cases. For e.g., "your email me@example.com is collected..." for instance, and "your location is collected..." for category
Group agrees on need to provide examples and guidance on usage of PD in such manner to indicate both instances and categories, such as through the primer or additional documentation
Dicussion on Christmas break and reconvening in new year
We will be meeting again on JAN-05 at 13:00 WET / 14:00 CET
Topics for discussion will be continuation of agenda, i.e. data subject categories and (later discussed) jurisdiction
Multi-language support within DPV
jan: is there any work on expressing concepts using multiple languages (e.g. EN, FR, DE)
jan: Paul Knowles has expressed interest in taking up this work to provide translations
georg: Signatu has a GDPR lexicon which provides concepts in multiple languages, see https://
harsh: IATE is EU's official language-based concept thesauri offering translations in several languages. See https://
Group notes that contributions to express DPV in languages other than EN are welcome
Jurisdiction expression in DPV
harsh: The proposal is to have the concept Jurisdiction and property hasJurisdiction to denote the applicable jurisdiction within information
Jurisdiction can be further refined as Country, SupraNationalUnion (EU), EconomicUnion (EEA), and so on
This allows expression of jurisdiction, e.g. to storage location or to entity
harsh: See example of countries, authorities, and adequacy decisions denoted using Jurisdiction concept here as Turtle/RDF - https://
georg: When referring to jurisdiction, which interpretation is to be taken (e.g. legislative, enforcement)
harsh: No specific interpretation, except indicating which obligations apply or what/where can enforcement happen in terms of laws.
jan: How to express trans-border agreements or flows based on agreements?
harsh: Yes, this is possible by modeling adequacy decisions or agreements between two jurisdictions (see example file in notes), but the actual logic for checking sufficiency is based on implementation and use-case
inah: Jurisdictions can be regional, cities, etc. ?
harsh: Yes, though there is confusion between what further terms to use since there is no common agreement on what is a 'region' in terms of jurisdiction (i.e. governance or geographical). Needs further input.
julian: for Germany, if in a region, then do three jurisdictions need to be defined, e.g. as region, DE, and EU? Or does specifying the region suffice since the others can be inferred from it?
harsh: Based on use-case, if there is a need to indicate all jurisdictions, then that can be done by declaring all three. If only the applicable or relevant needs to be declared, then the region is declared, and the interpretation of applicable jurisdiction is done using the knowledge of membership between jurisdictions.
inah: if Jurisdiction is left open (as in self-declarative), then what does this imply? Can someone declare the company as a jurisdiction?
harsh: Possibly, though it would not be correct to use it as such because jurisdiction as a concept has meaning within law(s) and therefore should be used in accordance with that
jan: For use of DPV, e.g. Jurisdiction, how does it ensure compatibility and interoperability between two different implementations if there no schema or template or profile?
harsh: It is difficult to get an agreement on a profile because of the vast differences in technologies, regions, and requirements. DPV foremost provides a vocabulary, where even if two different implementations use a different set of jurisdiction terms (e.g. regions of USA and EU respectively), then by declaring them as Jurisdiction using DPV it is clear and interoperable that they are jurisdictions, and use specific vocabularies.
harsh: Further schemas or profiles can be created, but need agreement between use-cases and domains, which is difficult to achieve within the group at this point.