Contributors: (ordered alphabetically) Arthit Suriyawongkul(ADAPT Centre, Trinity College Dublin),
Axel Polleres(Vienna University of Economics and Business),
Beatriz Esteves(IDLab, IMEC, Ghent University),
Bud Bruegger(Unabhängige Landeszentrum für Datenschutz Schleswig-Holstein),
Damien Desfontaines(No affiliation provided),
Danielle Welter(University of Luxembourg),
David Hickey(Dublin City University),
Delaram Golpayegani(ADAPT Centre, Trinity College Dublin),
Elmar Kiesling(Vienna University of Technology),
Fajar Ekaputra(Vienna University of Technology),
Georg P. Krog(Signatu AS),
Harshvardhan J. Pandit(AI Accountability Lab (AIAL), Trinity College Dublin),
Iain Henderson(JLINC Labs),
Javier Fernández(Vienna University of Economics and Business),
Julian Flake(University of Koblenz),
Julio Hernandez(Dublin City University),
Mark Lizar(OpenConsent/Kantara Initiative),
Maya Borges(Danish Agency for Digitisation),
Paul Ryan(Uniphar PLC),
Piero Bonatti(Università di Napoli Federico II),
Rana Saniei(Universidad Politécnica de Madrid),
Rob Brennan(University College Dublin),
Rudy Jacob(Proximus),
Simon Steyskal(Siemens),
Steve Hickman(Epistimis LLC),
Tytti Rintamaki(ADAPT Centre, Dublin City University).
NOTE: The affiliations are informative, do not represent formal endorsements, and may be outdated as this list is generated automatically from existing data.
This document provides additional details and examples for process and service concepts in the Data Privacy Vocabulary [[DPV]], and is a companion to the [[DPV]] specification.
DPV Specifications: The [[DPV]] is the core specification that is extended by specific extensions. A [[PRIMER]] introduces the concepts and modelling of DPV specifications, and [[GUIDES]] describe application of DPV for specific applications and use-cases. The Search Index page provides a searchable hierarchy of all concepts. The Data Privacy Vocabularies and Controls Community Group (DPVCG) develops and manages these specifications through GitHub. For meetings, see the DPVCG calendar.
Contributing: The DPVCG welcomes participation to improve the DPV and associated resources, including expansion or refinement of concepts, requesting information and applications, and addressing open issues. See contributing guide for further information.
Introduction
In legal terminology, it is common to refer to all information about how personal data is being processed using the colloquial term processing. This results in confusion between the use of processing as a concept referring to all information (i.e. purposes, personal data, collection, storage, etc.), and processing as a concept referring to (only) the specific actions or operations (e.g. collect, use).
To avoid this ambiguity and enable clarity of information, DPV defines a new concept called [=Process=] for representing how the core concepts are combined and applied for a particular use-case, and the relation [=hasProcess=] to associate processes with other processes, services, or any relevant concept. The association of a concept to Process is made using the relationships or properties provided for each concept. For example, to indicate a Process includes personal data, the relationship hasPersonalData is used along with the concept PersonalData.
dpv:NonPersonalDataProcess: An action, activity, or method involving non-personal data, and asserting that no personal data is involved
go to full definition
dpv:PersonalDataHandling: An abstract concept describing 'personal data handling'
go to full definitiondeprecated in next version
dpv:PersonalDataProcess: An action, activity, or method involving personal data
go to full definition
dpv:Service: A service is a process where one entity provides some benefit or assistance to another entity
go to full definition
Nesting Processes
Instances of Process can be nested, which means one instance can contain other instances, much like a box with several smaller boxes inside. This permits breaking down complex or dense use-cases into more granular ones and representing them in a more precise and modular fashion. Such a representation also facilitates reuse of the granular or modular processes, or in defining 'templates' and 'patterns', for example to craft a single process representing collecting and storing email addresses and using it in different processes for different purposes.
From the earlier example, consider the situation where a single Process instance consists of two additional instances representing: (i) data is stored using a data processor, (ii) data is used for Marketing. While it is certainly possible to represent all of this information within one single instance of Process, the adopter may decide to create separate instances of Process based on requirements such as reflecting similar separations for legal documentation or accountability purposes.
Interpretation of Process
Where multiple concepts such as purposes and data are present in the same process, the interpretation is that they all apply e.g. each purpose applies to each personal data, and so on. If this is not the case, then nested processes should be used to separate the groups so that only those concepts are present within the same process which occur or are associated with each other.
Such arrangements can also be used to separate necessary and optional parts of a process, and can aid in avoiding duplication of processes where only a few elements need to be distinguished. For example, if a purpose has necessary and optional data associated with it, it is possible to create two nested processes containing the purpose and the necessary data in one process, and the process and optional data in another. However, such duplication is not necessary, the 'parent' or 'outer' process can contain the purpose and the nested processes can contain only the differentiating elements i.e. one nested process contains the necessary data and the other contains the optional data.
Processes are also be useful to indicate separation of responsibilities - for example where some processing is conducted by one processor and another by a different processor, with each nested process corresponding to the processing activities of one processor.
Alternative Models
Process is intended to provide a convenient concept for tying the core concepts together, and DPV does not make its use binding, nor does it constrain the relationships to only be defined between Process and the other core concepts. This is so as to permit using DPV in alternate or differing models. For example, where a central concept already exists, such as when describing relevant information for a smartphone app, the concept for App can be a replacement for Process based on statements such as <App> hasPurpose <SomePurpose>. Even in such cases, Process can provide granular expression thereby enabling description of different contexts within which the app uses personal data, such as for registration or complaint resolution. Therefore unless necessary for the use-case, DPV recommends using Process or its subtype/subclass as a central concept for ensuring interoperability.
An example of where the adopter or use-case wants to use another concept in a way which is not compatible with Purpose is the use of Purpose to indicate it involves some data i.e. <SomePurpose hasPersonalData SomePersonalData>, or to indicate which legal basis is used for that purpose by using the hasLegalBasis relationship. While not explicitly prohibited by DPV, the implications of using Purpose in this manner is that the personal data and processing and other associated concepts are now strictly tied to the purpose instance (and implementation). Changing any of these would mean changing the purpose, and in addition to these, it is not possible to combine multiple purposes together or have nested purposes with different details in the same manner as with a Process. Therefore, DPVCG recommends the use of Process to ensure compatibility between use-cases as well as to ensure the use of concepts does not create ambiguity or restrict further use-cases from reusing existing information.
Process with/without Personal Data
Regulations such as the [[EU-GDPR]] apply when personal data is involved. To provide a convenient way to represent whether a process involves personal data or not, and therefore will be subject to requirements such as those related to privacy or from regulations such as the GDPR, the concepts [=PersonalDataProcess=] and [=NonPersonalDataProcess=] are provided. In providing these concepts, DPV does not dictate how these processes indicate the involvement of personal or non-personal data, for example by mandating the use of properties such as `hasPersonalData`.
These concepts are also a convenient way to represent which parts of the process involve personal data and which don't. For example, a process can specify constituent or granular processes using the properties [=hasPersonalDataProcess=] and [=hasNonPersonalDataProcess=] to represent where exactly personal data is or isn't involved.
Service
TThe concept [=Service=] is a general concept that represents the legal and social notion of 'service', similar to provided 'product' or 'application' or 'process', and does not represent the technical notion of services such as those associated with operating systems or 'cloud services'. In this sense, a 'Service' is _a process where one entity provides some benefit or assistance to another entity_. Service is useful to indicate a logical grouping of processes into a single 'unit' which has legal relevance - such as a contract covering the service or the provision of a service. To indicate a service is associated or involved, the relation [=hasService=] is provided. Services are regualted by law, and are also subject to specific requirements and obligations, such as regarding contractual arrangements, provision of benefits, fiduciary duties, and satisfaction of involved parties. While DPV currently does not provide modelling for these aspects, indicating how services are governed, implemented, and provided -- especially in relation to personal data and impacts -- is supported through the use of this concept.
Broadly, a service can be represented as a group of processes which do different but related things in order to achieve the successful provision of the service. Other relevant concepts from the [[DPV]] modules, such as entities, purposes, and context are helpful here to indicate how this happens. Similarly, extensions such as [[TECH]] enable representing the technical implementation of services, including who develops and provides them, and the involvement of specific hardware, software, or provision models such as through cloud and subscriptions.
To indicate the entities involved in services, the concepts `ServiceProvider` and `ServiceConsumer` are defined along with the relations `hasServiceProvider` and `hasServiceConsumer` (these are described in the `entity` module). Entities acting as providers and consumers can also be controllers or processors or data subjects. For example, a controller or processor may be the service provider for another controller who is the service consumer. Similarly, a processor may be the service provider for data subjects under the instructions of a data controller.
An abstract concept describing 'personal data handling'
Usage Note
This concept will be deprecated in future updates. It is recommended to use dpv:Process as the equivalent alternative which is better aligned with legal and operational terminology.
A service is a process where one entity provides some benefit or assistance to another entity
Usage Note
Service Provider and Service Consumer reflect the roles associated with a service. 'Service' as a process is a distinct concept from the use of 'service' as a provision method in Tech extension
DPV uses the following terms from [[RDF]] and [[RDFS]] with their defined meanings:
rdf:type to denote a concept is an instance of another concept
rdfs:Class to denote a concept is a Class or a category
rdfs:subClassOf to specify the concept is a subclass (subtype, sub-category, subset) of another concept
rdf:Property to denote a concept is a property or a relation
The following external concepts are re-used within DPV:
External
External
Funding Acknowledgements
Funding Sponsors
The DPVCG was established as part of the SPECIAL H2020 Project, which received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No. 731601 from 2017 to 2019. Continued developments have been funded under: RECITALS Project funded under the EU's Horizon program with grant agreement No. 101168490.
Harshvardhan J. Pandit was funded to work on DPV from 2020 to 2022 by the Irish Research Council's Government of Ireland Postdoctoral Fellowship Grant#GOIPD/2020/790.
The ADAPT SFI Centre for Digital Media Technology is funded by Science Foundation Ireland through the SFI Research Centres Programme and is co-funded under the European Regional Development Fund (ERDF) through Grant#13/RC/2106 (2018 to 2020) and Grant#13/RC/2106_P2 (2021 onwards).
Funding Acknowledgements for Contributors
The contributions of Harshvardhan J. Pandit have been made with the financial support of Science Foundation Ireland under Grant Agreement No. 13/RC/2106_P2 at the ADAPT SFI Research Centre; and the AI Accountability Lab (AIAL) which is supported by grants from following groups: the AI Collaborative, an Initiative of the Omidyar Group; Luminate; the Bestseller Foundation; and the John D. and Catherine T. MacArthur Foundation.
