23c23 < This work was supported by the European Union's Horizon 2020 research and innovation programme under grant 73160 (SPECIAL), --- > This work was supported by the European Union's Horizon 2020 research and innovation programme under grant 731601 (SPECIAL), by the Austrian Research Promotion Agency (FFG) under the projects ``EXPEDiTE'' and ``CitySpin'', 25c25 < and by the ADAPT Centre for Digital Excellence funded by SFI Research Centres Programme (Grant 13/RC/2106) and co-funded by European Regional Development Fund. --- > by the ADAPT Centre for Digital Excellence funded by SFI Research Centres Programme (Grant 13/RC/2106), and co-funded by European Regional Development Fund. 41c41 < Eva Schlehan\inst{5} \and --- > Eva Schlehahn\inst{5} \and 54c54 < Unabhängige Landeszentrum für Datenschutz Schleswig-Holstein, Germany \and --- > Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein, Germany \and 164,173c164,175 < Following the collection of vocabularies, relevant terms were documented in the wiki\footnote{\url{https://www.w3.org/community/dpvcg/wiki/Taxonomy}}, and were used as the basis for further discussion for addressing the requirements. While initially working towards a taxonomy of terms, the necessity of representing relationships and logic led towards an RDF/OWL based ontology. < < The process of ontology development was (informally) loosely based on NeOn methodology scenarios \cite{suarez-figueroa_neon_2012}, with the CG using the SPECIAL Usage Policy Language \cite{bonatti_special_2018} as the base ontology combined with modular ontologies representing personal data categories, purposes, processing, technical and organisational measures, legal basis, and consent. < < The aim of the ontology was stated to provide an extendable mechanism for representing information by providing the necessary top-level concepts and relationships in a hierarchical structure. < To this end, an analysis of existing vocabularies was carried out to determine their suitability, which revealed a lack of top-level concepts which could be readily incorporated. < Therefore, the CG created the necessary concepts by inviting contributions and reviewing them through discussions. < < The agreement over how terms were proposed, discussed, and added was documented through a collaborative spreadsheet hosted on the Google Sheets platform\footnote{\url{https://www.google.com/sheets/about/}}. The spreadsheet contained separate tabs for each `modular' ontology and a base ontology representing combined their combined usage to represent personal data handling. The columns in the spreadsheet were mapped to semantic web representations, as depicted in Table \ref{table:spreadsheet}. The vocabulary was created by using the Google Drive API in a script\footnote{\url{https://github.com/dpvcg/extract-sheets/}} that extracted terms and generated RDF serialisations using rdflib\footnote{\url{https://github.com/RDFLib/rdflib}} and documentation using ReSpec\footnote{\url{https://github.com/w3c/respec}}. < --- > The process of vocabulary development was largely shaped by discussions and interactions between CG members, and was (informally) based on NeOn methodology scenarios \cite{suarez-figueroa_neon_2012}. > The CG decided to work towards creating a generic or top-level vocabulary rather than restricting it to a particular domain or use-case in order to facilitate universal application and adoption. > For this, existing work and approaches were analysed to identify terms relevant for describing specific categories of information, such as purposes of processing and personal data. > > The analysis of existing vocabularies revealed a lack of top-level or abstract concepts necessary to provide an extendable mechanism for representing information in a hierarchical structure. Therefore, the CG decided to work towards creating a vocabulary that provided the necessary top-level concepts and relationships in a hierarchical structure. Agreement over categories of terms to be included in the vocabulary and relevance of existing terms was carried out through discussions, and documented in the wiki\footnote{\url{https://www.w3.org/community/dpvcg/wiki/Taxonomy}}. > > While initially working towards a hierarchical taxonomy, the need for representing relationships and logic between terms led towards the creation of an ontology, with RDF/OWL being used to provide standardised serialisation. > A base vocabulary was created based on the SPECIAL Usage Policy Language \cite{bonatti_special_2018} to represent a policy, and additional terms were structured to extend them as modular (sub-)ontologies. Terms were then added in a top-down fashion, based on existing work or its identified absence. > > Documentation of how terms were proposed, discussed, and added was recorded through a collaborative spreadsheet hosted on the Google Sheets platform\footnote{\url{https://www.google.com/sheets/about/}}. The spreadsheet contained separate tabs for each `modular' ontology and a base ontology representing combined their combined usage to represent personal data handling. The columns in the spreadsheet were mapped to semantic web representations, as depicted in Table \ref{table:spreadsheet}. The vocabulary was created by using the Google Drive API in a script\footnote{\url{https://github.com/dpvcg/extract-sheets/}} that extracted terms to create documentation of the taxonomy. This was then modified to generate RDF serialisations using rdflib\footnote{\url{https://github.com/RDFLib/rdflib}} as RDF/OWL was later adopted\footnote{In hindsight, a better alternative was mapping languages such as R2RML https://www.w3.org/TR/r2rml/ for creating RDF data from spreadsheets.}. > and documentation using ReSpec\footnote{\url{https://github.com/w3c/respec}}. > Plans for additions and changes to the vocabulary will follow a similar approach, where the proposal is documented and agreed upon through the public mailing list or CG meetings. 215d216 < 414,415c415,416 < The SPECIAL project actually has demonstrated how the above-mentioned use case of automated compliance checking can be implemented based modeling privacy policies and log records of personal data handling in a manner compatible with DPV, cf.~\cite{kirrane_special_2018-1}. < The SPECIAL project~\footnote{http://www.specialpricacy.eu} with its industry use case partners may also be viewed as a set of early adopters of the DPV, where currently further tools and a scalable architecture for transparent and accountable personal data processing in accordance with GDPR is being developed. --- > The SPECIAL project\footnote{http://www.specialpricacy.eu} actually has demonstrated how the above-mentioned use case of automated compliance checking can be implemented based modeling privacy policies and log records of personal data handling in a manner compatible with DPV \cite{kirrane_special_2018-1}. > The SPECIAL project with its industry use case partners may also be viewed as a set of early adopters of the DPV, where currently further tools and a scalable architecture for transparent and accountable personal data processing in accordance with GDPR is being developed.