Objectives and deliverables

The DPVCG came together in May 2018 with an idea about the objectives and deliverables it wanted to achieve. 2 years later, we intend to update the objectives deliverables based on what has been achieved, the work we've done so far, and additional areas of interest suggested by the members. To this end, the current page acts as a draft of the aims, objectives, and deliverables we are currently considering. The page can be edited by any member to add their voice and support to an existing proposition, link to other pages/resources, or voice objections. The discussion will be undertaken on the mailing list and meeting calls, with the final resolution taken on a meeting call as conveyed on the mailing list.

Future Deliverables

DPVCG should be working towards these deliverables:

1. Data Privacy Vocabulary (DPV) v0.2+: The DPV v0.1 is the current iteration of the vocabulary, and includes a core model of concepts necessary for representing handling of personal data. DPVCG should work towards extending the vocabulary with more (top-level) concepts as well as add commonly used terms to the existing taxonomies. Currently we have some proposed concepts in the Wiki taxonomy section.
2. Collection of use-cases, case studies, and requirements: We need a set of simpler use-cases which act as points of discussion, justify the vocabulary, and also allow us to assess how the vocabulary could be applied. They also show us which concepts are missing and need to be added. This will allow more practical applications and development of the work, and also expose practical requirements and technologies such as querying, validation, and evaluation related to information.

Internal Activities for the Group

The DPVCG should work towards these activities in order to achieve the existing and future deliverables, invite wider adoption, and ease the process of contribution to the DPVCG.

Documentation

1. Primer: a simple guide for understanding DPV that is aimed for non-specialists and introduces the motivation and concepts of DPV at a high and abstract level. Primers regarding RDF, OWL2, PROV, and SHACL can be considered as model examples.
2. Examples: documentated examples of using DPV for some common use-cases that allow adopters and curious individuals to look at how the DPV can be used for some use-cases. This is an evolving deliverable, but we need some common items to start this. We can work on this based on the use-cases and case-studies as we collect them.
3. FAQ: questions arise regarding usage, concepts, etc. The FAQ section is an area to collect such questions and the discussions surrounding it. This is also an evolving deliverable.
4. Maintain collection of concepts proposed to the group: we have some concepts proposed to us on the mailing list e.g. safeguards for data transfer, GDPR ROPA, references - which need to be collected in one place for easier access and overlook for everyone. This will also help in keeping track of concepts as they are proposed and either accepted or rejected for inclusion. We last used a spreadsheet in the Vienna F2F (2018) with a simple format - we can continue to use a similar format.
5. DPVCG contributors guide: a guide for contributors to refer regarding how to propose concepts for DPV, how to look for existing concepts either accepted or proposed, and how to contribute to the group an idea, application, or use-case in general. Ideally - we have a wiki page that specifies this information.

Code/Application

1. Re-implement ontology documentation generation (e.g. R2RML -> W3C ReSpec): The current implementation is based on a hack that is not fit for continued use. If we create a good pipeline for automatic ontology documentation we can implenent it and forget it. I would propose having the process take a CSV file (like we currently have) and generate the corresponding documentation using W3C ReSpec (also what we currently use. Other reasonable methods are also welcome based on available expertise.
2. Quality Assurances: some basic checks and balances to ensure the DPV we generate is correct both semantically and programmatically. Things such as rudimentary SHACL constraints, or consistency checkers can be useful here.
3. Better layout and diagrams for DPV documentation: Currently, we have one diagram regarding the overview of the core model (i.e. personal data handling and properties). We need to provide additional diagrams, especially for the rich hierarchical taxonomies we have and plan to develop. The process should ideally be programmatic, so that new concepts can be automatically included as the vocabulary is updated.