12:55:39 <RRSAgent> RRSAgent has joined #dpvcg
12:55:39 <RRSAgent> logging to https://www.w3.org/2022/01/05-dpvcg-irc
12:55:42 <harsh> ScribeNick: harsh
12:55:44 <harsh> Meeting: DPVCG Meeting Call
12:55:47 <harsh> chair: harsh
12:55:52 <harsh> Date: 05 JAN 2022
12:56:02 <harsh> Agenda: https://lists.w3.org/Archives/Public/public-dpvcg/2022Jan/0001.html
13:02:22 <harsh> Present: harsh, paul, janL, julian, georg
13:02:57 <harsh> Topic: DPV Primer draft for review
13:03:04 <harsh> See https://lists.w3.org/Archives/Public/public-dpvcg/2022Jan/0000.html
13:03:44 <harsh> Proposal is to have this finalised by month-end JAN-31
13:03:59 <harsh> Present+: mark
13:04:28 <harsh> Regrets: beatriz
13:07:02 <harsh> Topic: Decision on Personal Data Categories renaming
13:08:14 <harsh> Last meeting we agreed to the proposal for changing Personal Data Category to Personal Data and move categories to extension
13:08:59 <harsh> No comments/objections; accepted and to be integrated into next iteration DPV
13:22:57 <harsh> Topic: DataSubject subclasses - awaiting proposal from members
13:23:10 <harsh> No updates or proposals from members. Topic postponed to next meeting.
13:23:16 <harsh> Topic: Jurisdictions
14:39:39 <harsh> 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)
14:41:41 <harsh> 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.
14:41:58 <harsh> Jan: How to specify what Laws apply? e.g. GDPR
14:42:07 <harsh> s/Jan/jan
14:44:59 <harsh> georg: Is this regarding specifying Jurisdiction and Laws for a data processing argument? jan: Yes
14:45:44 <harsh> harsh: Proposal - we have a concept 'Law' with property 'hasLaw'. Applied as - < GDPR a Law > . < EU hasLaw GDPR > .
14:46:17 <harsh> georg: There needs to be nuance in how 'law' is represented and applied since there is also private law, contract law, and others.
14:47:03 <harsh> 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.
14:47:56 <harsh> 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 > .
14:48:34 <harsh> julian: Modelling just Jurisdiction should be sufficient without Country and Region because these are not relevant in specifying or inferring what laws are applicable.
14:49:42 <harsh> 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.
14:50:17 <harsh> 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.)
14:50:23 <harsh> julian: The term 'Region' can be confusing as there are states, provinces, cantones and other terms associated in different countries
14:51:52 <harsh> 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.
14:53:14 <harsh> 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.
14:53:51 <harsh> 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'.
14:54:25 <harsh> 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.
14:55:18 <harsh> 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.
14:55:49 <harsh> georg: At what granularity can location be expressed? For example a shop wants to denote its CCTV's location coverage.
14:56:16 <harsh> 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
14:57:07 <harsh> 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.
14:57:28 <harsh> Topic: Use of Jurisdictions
14:58:13 <harsh> 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.
14:58:48 <harsh> 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.
14:59:07 <harsh> harsh: Work for this could look like, e.g. https://github.com/coolharsh55/dpv-x/blob/master/dpv-jurisdictions/juris.ttl
14:59:41 <harsh> harsh: This graph models each country as a Jurisdiction and indicates its DPA and models Adequacy Decisions between countries/EU.
15:00:17 <harsh> 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.
15:00:43 <harsh> 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.
15:00:50 <harsh> Topic: Actions
15:01:22 <harsh> harsh to share meeting notes and summary of final proposal from today's discussion regarding jurisdictions and locations
15:01:38 <harsh> ; others to share use-cases and comments for above email
15:01:49 <harsh> ; we will take up this discussion in next week's meeting
15:01:53 <harsh> Topic: Next Meeting
15:02:12 <harsh> We will reconvene in 1 week, JAN-12 at 13:00 WET / 14:00 CET
15:02:13 <harsh> zakim, bye
15:02:13 <Zakim> leaving.  As of this point the attendees have been harsh, paul, janL, julian, georg, :, mark
15:02:13 <Zakim> Zakim has left #dpvcg
15:02:18 <harsh> rrsagent, publish minutes v2
15:02:18 <RRSAgent> I have made the request to generate https://www.w3.org/2022/01/05-dpvcg-minutes.html harsh
15:02:20 <harsh> rrsagent, set logs world-visible
15:40:38 <harsh> rrsagent, bye
15:40:38 <RRSAgent> I see no action items