W3C

– DRAFT –
DPVCG Meeting Call

15 DEC 2021

Attendees

Present
:, beatriz, georg, harsh, inah, janL, julian, mark
Regrets
paul
Chair
harsh
Scribe
harsh

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://github.com/w3c/dpv/issues/27

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://gdprlexicon.com/ ; However, this is prorprietary and needs to be discussed internally for contribution to DPV

harsh: IATE is EU's official language-based concept thesauri offering translations in several languages. See https://iate.europa.eu/ ; such concepts span several laws and need a professional or fluent speaker who knows legalese to identify the correct term in their language

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://github.com/coolharsh55/dpv-x/blob/master/dpv-jurisdictions/juris.ttl

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.

Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).

Diagnostics

Succeeded: s/#/#

Maybe present: jan