- From: Harshvardhan J. Pandit <me@harshp.com>
- Date: Thu, 29 Jul 2021 11:18:50 +0100
- To: Data Privacy Vocabularies and Controls Community Group <public-dpvcg@w3.org>
Hello. As DPV continues to grow, we're reaching a stage where there is a noticeable impact in terms of personal data categories and other concepts. The approach to rename personal data category or other non-data concepts can only work so many times, and will eventually cause confusion in adopters. What are potential solutions for this? For example, (i) Certification as Personal Data and (ii) Certification as Organisational Measure. We resolved this by renaming (i) to ProfessionalCertification. This measure cannot always be used. Another example, (i) Location as personal data category, and (ii) Location for indicating personal data storage. We resolved this by avoiding (i) in not providing hasStorage property with any range and defining StorageLocation. Problem if we define both concepts using same label or IRI: Any time someone wants to specify a Certification or Location for data storage or transfer, it is defined as personal data as well, or the label causes confusion and they use the wrong concept. Not a good design IMHO. Solutions: 1) Keep only the 'top-tier' personal data taxonomy in DPV and move others outside into a dpv-personal-data extension. This is my preferred approach because it keeps concepts in other modules (E.g. technical measures) with the commonly used words without overlap with personal data. AFAIK the issue only exists with overlap between personal data categories and other concepts. 2) Keep only the 'top-tier' concepts for all modules and move other concepts outside into specific taxonomies. Not my preferred option because it means adopters need to import a lot of vocabularies to get commonly used concepts e.g. technical measures. 3) Keep concepts as they are, with same label for multiple concepts in different modules, but different IRI. E.g. pd_Location for personal data categories and Location for the generic concept. 4) Something else you propose. IMHO Backward compatibility is not as important as effective design and correctness for real-world usage. We're still figuring out what things are needed and how we should provide them. When we reach v1, it means milestone and stability. FYI SPECIAL had modular vocabularies: https://specialprivacy.ercim.eu/vocabs/ with distinct IRIs. Regards, -- --- Harshvardhan J. Pandit, Ph.D Research Fellow ADAPT Centre, Trinity College Dublin https://harshp.com/
Received on Thursday, 29 July 2021 10:19:08 UTC