W3C

– DRAFT –
DPVCG Meeting Call

05 JAN 2022

Attendees

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

Meeting minutes

DPV Primer draft for review

See https://lists.w3.org/Archives/Public/public-dpvcg/2022Jan/0000.html

Proposal is to have this finalised by month-end JAN-31

Decision on Personal Data Categories renaming

Last meeting we agreed to the proposal for changing Personal Data Category to Personal Data and move categories to extension

No comments/objections; accepted and to be integrated into next iteration DPV

DataSubject subclasses - awaiting proposal from members

No updates or proposals from members. Topic postponed to next meeting.

Jurisdictions

The proposal is to have a concept called Jurisdiction, with sub-categories for Country (e.g. IE), SupraNationalUnion (e.g. EU), EconomicUnion (e.g. EEA), and Region (e.g. California)

Jurisdictions are relevant for where data is stored, where Data Subjects and Controllers are located and so on. Jurisdictions are different from Location (i.e. specific interpretation of Location) to mean that location applies as a legal jurisdiction in terms of its law.

jan: How to specify what Laws apply? e.g. GDPR

georg: Is this regarding specifying Jurisdiction and Laws for a data processing argument? jan: Yes

harsh: Proposal - we have a concept 'Law' with property 'hasLaw'. Applied as - < GDPR a Law > . < EU hasLaw GDPR > .

georg: There needs to be nuance in how 'law' is represented and applied since there is also private law, contract law, and others.

harsh: Yes, and also whether that law is associated with a jurisidiction because it was passed by the governing body, or is applicable there, its territorial scope, and other nuances.

harsh: Proposal - instead of hasLaw, we have the property hasApplicableLaw to indicate some law is the be considered applicable or applied in the context of a concept. For example, indicating the data processing operations consider GDPR to be the applicable law < Policy hasApplicableLaw GDPR > .

julian: Modelling just Jurisdiction should be sufficient without Country and Region because these are not relevant in specifying or inferring what laws are applicable.

harsh: It is necessary to indicate a location is a country, and that it is interpreted as a jurisdiction. For example, to state that a City is within a Region is within a Country is within EU.

harsh: We do not model all granular levels, we can model Region and leave it to the use-cases and regions to decide what they want to call their specific regions (state, city, etc.)

julian: The term 'Region' can be confusing as there are states, provinces, cantones and other terms associated in different countries

harsh: for Jurisdiction, we remove the concept 'Jurisdiction' and use 'Location' categories (e.g. Country). And when it is necessary to indicate a certain location is to be interpreted as an 'applicable jurisdiction' i.e. laws apply, then the property hasApplicableJurisdiction can be used.

harsh: to indicate a specific Law is applied, we have the proposal 'hasApplicableLaw'. For example, to indicate a policy adheres to GDPR, use as < Policy hasApplicableLaw GDPR > . This enables use-cases to explicitly acknowledge what law they are adhering to.

julian: The applicable laws can be inferred from Jurisdiction, so this property is not needed. For example, < Policy hasApplicableJurisdiction Bavaria > . can be used to identify GDPR is applicable 'law'.

harsh: The property also exists to express explicitly a law is applicable - if needed. In other cases, one could infer the laws, but it would need the entire chain of information to be present in the KG.

harsh: For example, < Bavaria a Region > . < Bavaria insideLocation Germany > . < Germany insideLocation EU > . < EU hasApplicableLaw GDPR > . are all the triples needed to infer Bavaria has GDPR applicable.

georg: At what granularity can location be expressed? For example a shop wants to denote its CCTV's location coverage.

harsh: For that there are various vocabularies that exist to specify location and region. E.g. geo-semantic-web vocabs, X,Y co-ordinate based ones

harsh: So the shop can specify < Shop hasLocation LOC > < LOC hasXY "(100,200)" > < LOC hasCountry Switzerland > to denote both exact location and country, or the country could be inferred from XY.

Use of Jurisdictions

harsh: The Jurisdictions/Locations are helpful because the Country is needed to be specified for data storage, collection, transfer, etc. And this is necessary to determine legal basis e.g. for data transfers. Therefore, Countries, Adequacy Decisions should be provided by DPV.

harsh: Additionally, DPAs are relevant to a region to indicate authorities, and region-specific laws can also be provided (e.g. EU has GDPR) to assist choosing the correct legal bases.

harsh: Work for this could look like, e.g. https://github.com/coolharsh55/dpv-x/blob/master/dpv-jurisdictions/juris.ttl

harsh: This graph models each country as a Jurisdiction and indicates its DPA and models Adequacy Decisions between countries/EU.

harsh: Once the jurisdiction concepts are finalised within the DPV, this is where they would be useful. E.g. ensuring correct data locations, legal basis in ROPA documents.

harsh: A 'checklist' for what concepts and resources are needed for DPV v1 is provided here: https://harshp.com/dev/dpv/dpv-v1-checklist.html Feedback and Suggestions are welcome.

Actions

harsh to share meeting notes and summary of final proposal from today's discussion regarding jurisdictions and locations

; others to share use-cases and comments for above email

; we will take up this discussion in next week's meeting

Next Meeting

We will reconvene in 1 week, JAN-12 at 13:00 WET / 14:00 CET

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

Diagnostics

Succeeded: s/Jan/jan

Maybe present: jan