Data Privacy Vocabulary (DPV)

This document assumes the reader is familiar with DPV through the Primer for Data Privacy Vocabulary, and thus focuses on providing a topically structured documentation of concepts defined by DPV.

DPV's terms are defined using [RDFS] & [SKOS] semantics where all 'classes' and 'properties' are defined as skos:Concept in addition to rdfs:Class and rdf:Property respectively. For taxonomies or hierarchies, concepts are defined as 'instances' of a top-concept, and relationships within the hierarchy are defined using skos:broader/skos:narrower. For example, Purpose is the top concept within the purposes taxonomy, and all concepts in the purpose taxonomy are instances of it, and are related to each other using skos:broader/narrower relations, such as ServiceProvision and its more specific form RequestedServiceProvision are both instances of Purpose while being related to each other using skos:broader/narrower.

DPV serialised in OWL2 is an alternate serialisation of DPV that contains the same concepts but is provided under a different namespace with the semantics defined using [OWL]. The conversion from SKOS to OWL follows the best practices and concerns outlined in Using OWL and SKOS, e.g. by replacing skos:Concept with owl:Class, and using rdfs:subClassOf instead of skos:broader/skos:narrower. See the example showing implications of using SKOS vs OWL in the [PRIMER].

DPV consists of certain 'core concepts' that are intended to be independent representations of specific information, and are distinct from other core concepts. For example, the Purpose refers only to the purpose of why personal data is processed and is independent as a concept from the other concepts (e.g. PersonalData or LegalBasis). The structuring of DPV is based on providing rich and comprehensive taxonomies that group concepts together based on each core concept, e.g. taxonomy of purposes, taxonomy of legal basis. 'Extensions' are a separate group of concepts that expand the 'core' vocabulary to represent specific information e.g. [PD] for personal data categories and [RISK] for risk management.

In DPV v1.0, the scope of the DPV and the DPVCG was limited to 'privacy', 'data protection', and the 'processing of personal data', including technologies used to perform it. Under this scope, the DPVCG discussed and modelled regulations such as the [EU-GDPR] which also share the same scope. Newer laws such as the [EU-DGA] and [EU-AIAct] share a significant overlap with this scope and necessitate their inclusion in DPVCG activities. However, such laws utilise the same legal framework to model both personal and non-personal data (for DGA) or regulate a technology that goes beyond 'personal data' (DGA and AI Act). To enable their inclusion and representation as extensions to the DPV, and to enable adopters to utilise a single consistent framework to represent information, the scope of DPVCG and the DPV was expanded in v2.0 as follows:

1. Expansion of scope to include 'data' and 'technologies' instead of only 'personal data' - this means concepts such as Purpose which were defined as purpose associated with 'personal data' are now defined as purpose associated with 'data or technologies'.
2. Creation of concepts to represent expanded scope - such as Data as the broader concept for both PersonalData and NonPersonalData.
3. Changing the scope of associated extensions such as [TECH] and [RISK] to be useful for any technology and activities and not just personal data related technologies and activities.
4. Creating [AI] as a new extension to specifically provide concepts associated with AI technologies.
5. Creating extensions to represent concepts from laws regarding 'data and technologies' based on the new concepts and extensions created e.g. [EU-DGA] and [EU-AIAct] extensions.
6. Creating new namespaces such as /legal/eu/gdpr instead of /dpv-gdpr to enable consisting and unambiguous representation of legal extensions
7. Restructuring the GitHub repository to accommodate the changed structure of DPV extensions

In addition to the above, the v2.0 scope change also includes removal of the bespoke 'DPV serialisation' which was based on a custom extension of [SKOS]. Instead, the RDFS+SKOS serialisation has been made the default serialisation, and the alternate OWL2 serialisation is continued as before.

The 'Core' concepts and relationships in DPV represent and associate relevant information regarding the what, how, where, who, why of personal data and its processing. These are:

The rest of the document expands on the core concepts through the following taxonomies.

• Entities - different categories of entities (e.g. Organisations, Authorities, and Human/Data Subjects) and various Legal Roles they can take (e.g. DataController or DataProcessor).
• Purposes that justify the need or goal for which personal data is processed.
• Data and Personal Data categories.
• Processing operations over personal data.
• Contextual information about Processing (e.g. Processing and Storage Conditions, Automation, Entity and Human Involvement, Data Source, and Scale of Processing).
• General Contextual information (e.g. duration and frequency, and statuses associated with activities.
• Technical & Organisational Measures.
• Legal Bases that justify the processing (e.g. Consent).
• Locations & Jurisdictions providing relevance to laws, authorities, and location contexts.
• Risk & Impacts for risk assessment, management, and expression of consequences and impacts associated with processing.
• Rights and Rights Exercise for specifying what rights are applicable, how they can be exercised, and how to provide information associated with rights.
• Rules for expressing constraints, requirements, and other forms of rules that can specify or assist in interpreting what is permitted, prohibited, mandatory, etc.

In addition to these the Extensions section describes the available extensions which also provide additional taxonomies for specific concepts within the DPV.

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.

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.

The 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'. 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.

To indicate the entities involved in services, the concepts ServiceProvider and ServiceConsumer are defined along with the relations hasServiceProvider and hasServiceConsumer. 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.

Legal Role is the role taken on by a legal entity based on definitions or criteria from laws, regulations, or other such normative sources. Legal roles assist in representing the role and responsibility of an entity within the context of processing, and from this to determine the requirements and obligations that should apply, and their compliance or conformance. Concepts are also accompanied with relations to enable using or associating them within the context.

The concept Authority is a specific Governmental Organisation authorised to enforce a law or regulation. Authorities can be associated with a specific domain, topic, or jurisdiction. DPV currently defines regional authorities for NationalAuthority, RegionalAuthority, and SupraNationalAuthority, and DataProtectionAuthority represents authorities associated with data protection and privacy. To associate authorities with concepts, the relations hasAuthority to indicate an authority is applicable within a context and isAuthorityFor to indicate the authority's scope or applicability are provided.

DPV provides a taxonomy of organisations based on aspects such as whether they are non-profit, international, or governmental. These concepts are useful to accurately represent the nature of organisations.

DPV provides a taxonomy of HumanSubject categories to assist with describing what kind of individuals or groups are associated with an use-case. These can be indicated through the relation hasHumanSubject. Some examples of such types are agency-based roles: Adult and Child, ParentOfHuman, GuardianOfHuman; those associated with vulnerability: VulnerableHuman, ElderlyHuman, AsylumSeeker; domain-specific roles such as Patient, Employee, Student, jurisdictional roles such as Citizen, NonCitizen, Immigrant; and general roles such as User, Member, Participant, and Client.

DataSubject is a specific category of HumanSubject that indicates the person is the subject of (their personal) data. It can be associated through the relation hasDataSubject.

To indicate that the process involves profiling and tracking processing operations, the concepts Profiling and Tracking are provided. While profiling and tracking are more complex concepts as compared to collect or use or store as 'simple' operations, they are included in the processing operations taxonomy as they represent specific ways of using (personal) data, and by themselves do not provide sufficient indication of the purpose or intended objective for why they are being performed.

Tracking is further distinguished as TrackingByFirstParty and TrackingByThirdParty to reflect the commonly used terms for tracking performed by entities considered as 'first' and 'third' parties within a context. While the DPV itself does not (yet) model these first/third relations, these concepts reflect existing uses of the term and therefore the DPV relies on these existing definitions and uses to guide the usage of these concepts. For reference, see the Do Not Track terminology page. Similarly, DPV's definition of Profiling is a minimal representation of creating a profile of a person based on the use of (some) data. To indicate specific definitions of profiling, e.g. in a law like the EU's GDPR, this concept should be extended to reflect the specific definition, such as the eu-gdpr:Profiling concept defined in the [EU-GDPR] extension based on the definition in GDPR's Article 4-4.

To describe conditions associated with processing, such as its duration, or specific locations, the concept ProcessingCondition provided and extended as ProcessingDuration and ProcessingLocation along with the relation hasProcessingCondition. Storage, which is a specific form of processing, has additional dedicated concepts as StorageCondition as it is a commonly used concept. The concepts are useful to describe processing and storage conditions in policies, conditions, rules, or documentation - which are important tools for implementing and determining data protection and privacy considerations as well as legal compliance.

The concept StorageCondition and the relation hasStorageCondition represent the general or abstract conditions associated with storage of data. This is specialised to indicate StorageDuration, StorageDeletion, StorageRestoration, and StorageLocation.

To indicate processing involves automation, the concept AutomationLevel and relation hasAutomationLevel are provided to specify the extent to which automation is implemented or applies. These levels are defined based on ISO/IEC 22989:2022 Artificial intelligence concepts and terminology.

To specify how entities are involved in processing and technologies, including humans, the concept EntityInvolvement is provided along with the relation hasEntityInvolvement. Involvement of entities is categorised as 'permissive' for entities being able to perform an activity, and 'non-permissive' for when entities cannot perform an activity. A taxonomy of concepts is provided for permissive and non-permissive involvements to describe scenarios such as entity being able to opt-in or not being able to opt-out, or being able to reverse the output of a process. Involvement is also categorised as 'passive' and 'active' based on whether the entity passively or actively interacts with a 'process' or 'technology'.

To specifically indicate how humans are involved, the concept HumanInvolvement is provided with the relation hasHumanInvolvement. The existing terms used such as 'human in/on/out-of the loop' are not used directly as they have conflicting and ambiguous definitions and uses across different documents. Instead, the DPV concepts provide an explicit and unambiguous indication of human involvement - such as whether they are involved to provide inputs, make decisions, have oversight, or verify processes.

The concept DataSource and relation hasDataSource indicate the source of data. Here, it is important to note that 'source' is distinct from 'origin', where source is where the data came from and origin refers to where the data originated from. Data originated from a data subject can be collected and shared one entity to another, where each entity has as its source the previous entity it obtained the data from.

To indicate the processing or technology is performing some kind of decision making, the concept DecisionMaking is provided. If the processing or technology is automated, the concept AutomatedDecisionMaking is provided. To describe the logic involved in decision making, the concept AlgorithmicLogic is provided. If the processing or technology is performing some evaluation or scoring (e.g. of individuals), the concept EvaluationScoring is provided. If the processing or technologies are performing 'systematic monitoring' of individuals, the concept SystematicMonitoring is provided.

If the processing involves technologies that are being used 'innovatively', the concept InnovativeUseOfTechnology is provided. Innovative uses can be for existing technologies, described using InnovativeUseOfExistingTechnology or for new technologies which are described using InnovativeUseOfNewTechnologies.

These concepts can be associated within the process or context through the relation hasContext.

DPV provides the (qualitative) concept Scale, with further specialisations for expressing DataVolume, DataSubjectScale, and GeographicCoverage related to activities. Along with these, DPV also provides a ProcessingScale to express combinations of these (e.g. LargeScaleProcessing). The relation hasScale is used to indicate the scale, with specific relations hasDataVolume, hasDataSubjectScale, hasGeographicCoverage, and hasProcessingScale to indicate the different types of scales.

The concept Technology represents technologies involved e.g. those for processing of data, or for implementing technical and organisational measures. To indicate something is implemented using some technology, the relation isImplementedUsingTechnology is provided. To indicate which entity is implementing the specified context, the relation isImplementedByEntity is provided. The Technology concepts for DPV extension provides additional concepts to describe the technology such as involved actors, intended use, capabilities and functions, and documentation.

These concepts enable expressing information about Duration, Frequency, Applicability, Importance, and Necessity of a Context (which can be any other concept). In addition to these, the concept Justification is useful to provide justifications or reasons or explanations - such as for why something must take place or could not take place.

Each of these concepts has a corresponding relation to express them - hasDuration, hasFrequency, hasApplicability, hasImportance, hasNecessity with hasContext being the super-relation for these. Justifications are associated with using the relation hasJustification.

To assist with expressing the state or status associated with various activities, DPV provides the Status concept that can be associated contextually using the hasStatus relation. Specific subtypes are provided as ActivityStatus, ComplianceStatus including Lawfulness, AuditStatus, ConformanceStatus, RequestStatus, EntityInformedStatus, IntentionStatus, ExpectationStatus, InvolvementStatus, and NotificationStatus. The corresponding relations provided are: hasActivityStatus, hasComplianceStatus, hasLawfulness, hasAuditStatus, hasConformanceStatus, hasRequestStatus, hasInformedStatus, hasIntention, hasExpectation, hasInvolvement, and hasNotificationStatus.

The concept Contract represents a legal contract, which can be used as a legal basis through the hasLegalBasis relation to justify data processing or use of technologies.

Consent in DPV is a specific legal basis representing information associated with consent rather than only given consent. Common information associated with consent includes tasks such as keeping track of whether "consent has been given/obtained", "issuing a consent request", and "withdrawing consent", as well as expressing requirements through terms such as "informed" and "explicit". To assist with representing these concepts as well as keeping records about how they are being applied, DPV provides the following consent concepts.

• Consent - a type of legal basis representing consent of the individual.
• Consent Types - to represent criteria for consent, such as InformedConsent and ExplicitlyExpressedConsent.
• Consent Status - to represent and keep track of what state/status/stage the consenting process is at, for example indicating the journey or lifecycle from ConsentRequested to ConsentGiven and then ConsentWithdrawn.
• Consent Controls - to indicate information about how to obtain or provide or reaffirm consent.

To indicate the duration or validity of a given consent instance, the existing contextual relation hasDuration along with specific forms of Duration can be used. For example, to indicate consent is valid until a specific event such as account closure, the duration subtype UntilEventDuration can be used with additional instantiation or annotation to indicate more details about the event (in this case the closure of account). Similarly, UntilTimeDuration indicates validity until a specific time instance or timestamp (e.g. 31 December 2022), and TemporalDuration indicates a relative time duration (e.g. 6 months). To indicate validity without an end condition, EndlessDuration can be used. To indicate the notice used for informed consent, the concept ConsentNotice is provided, which can be used with the relation hasNotice.

To specify consent provided by delegation, such as in the case of a parent or guardian providing consent for/with a child, the isIndicatedBy relation can be used to associate the parent or guardian responsible for providing consent (or its affirmation). Since by default the consent is presumed to be provided by the individual, when such individuals are associated with their consent, i.e. through hasDataSubject, the additional information provided by isIndicatedBy can be considered redundant and is often omitted.

ConsentControl represents information about how to exercise a control regarding consent. To indicate how an organisation obtains consent, the concept ObtainConsent is provided. Its corresponding concept ProvideConsent specifies how a data subject can indicate their consent (decision). The concept ReaffirmConsent is used to indicate how to perform reaffirmation or confirmation of a previous control (e.g. provide or obtain consent). To associate consent controls, the relation hasConsentControl is provided. Consent controls are defined by extending relevant EntityInvolvement concepts OptingIntoProcess and WithdrawingFromProcess.

In addition to Contract and Consent, DPV also models other legal basis which include LegalObligation, LegitimateInterest, OfficialAuthorityOfController, PublicInterest, and VitalInterest. The following taxonomy provides statuses for modelling their use.

Personal Data categories for DPV provides additional concepts that extend the DPV's personal data taxonomy based on an opinionated structure contributed by R. Jason Cronk from EnterPrivacy. This separation is to enable adopters to decide whether the extension's concepts are useful to them, or to use other external vocabularies, or define their own.

Concepts within [PD] are broadly structured in top-down fashion by utilising their relevance and origin as:

• Internal (within the person): e.g. Preferences, Knowledge, Beliefs
• External (visible to others): e.g. Behavioural, Demographics, Physical, Sexual, Identifying
• Household: e.g. personal or household activities
• Social: e.g. Family, Friends, Professional, Public Life, Communication
• Financial: e.g. Transactional, Ownership, Financial Account
• Tracking: e.g. Location, Device based, Contact
• Historical: e.g. Life History

Location and Geo-Political Membership concepts for DPV provides additional concepts regarding locations such as countries and regions based on the ISO 3166 standards. It enables representing information such as processing takes place within Ireland, represented by loc:IE, or within European Union (EU) by using loc:EU. We are working on expanding this list to also specify regions, cities, and other pertinent location details, and welcome participation and contributions for this.

Risk Assessment and Management concepts for DPV builds on top of the lightweight risk framework within DPV by providing the following extensive concepts related to risk assessment and management. We are in the process of identifying additional concepts and taxonomies for the risk extension, such as for risk management procedures and the creation of a risk ontology based on ISO standards.

• Risk Controls - categories of measures such as those related to risk source, likelihood, consequence, vulnerability, as well as the intended effect in terms of monitoring, controlling, halting, removing, or reducing.
• Consequences and Impacts - list of consequences such as data breaches, costs, identity theft and several others that are categorised based on DPV's impact framework i.e. damage, harm, or detriment.
• Scale for Risk Levels, Severity, and Likelihood - a 7 point qualitative scale to express concepts associated with levels, severity, and likelihood of risk and its consequences.
• Risk Matrix - an encoded form of risk matrices based on combinations of severity and likelihood along with the resulting risk level. Risk matrix nodes and values are provided for dimensions 3x3, 5x5, and 7x7.
• Incidents, Reports, and Notices - specifying incidents such as security incidents or data breaches, documenting information about them, and notices used to communicate with other relevant entities such as authorities and data subjects.
• Risk Management - risk management concepts based on ISO 31000 series.

Technology concepts for DPV extends the DPV's terms to represent further specific details regarding technologies, their management, and relevance to actual real-world tools and systems. It provides concepts for the following:

• Provision method: System, Component, Algorithm, Service, Goods, Product, Subscription, Fixed Use
• Communication method: WiFi, Bluetooth, GPS, Cellular Network
• Actors: Developer, Provider, User, Subject, etc.
• Intended Use: what the technology was/is intended to be used for
• Documentation: technical and user manuals and other documentation
• Status: whether the technology has been released, has been provided, and other statuses
• Tools: databases, cookies, etc.

The intention and aim of developing the TECH extension is to describe real-world tools and services, such as a specific cloud storage provider, and provide categorisation and metadata to connect it to DPV's concepts, such as to indicate the cloud storage instance features encryption at rest as a technical measure. Through these, the management and documentation of use-cases can be made easier by providing the relationships between tools/services and technical measures as a 'knowledge graph'.

The AI Technology concepts for DPV extension provides concepts specifically regarding AI by extending the [TECH] extension. It consists of:

• Techniques such as machine learning and natural language programming
• Capabilities such as image recognition and text generation
• Lifecycle such as data collection, training, fine-tuning, etc.
• Risks such as data poisoning, statistical noise and bias, etc.
• Risk Measures to address the AI specific risks
• Documentation such as Data Sheets and Model Cards
• Data associated with AI development, training, validation, and use.
• Systems and Models such as General Purpose, Robotics, Expert Systems.

Concepts representing Justifications for DPV provides concepts for use as 'justifications' with DPV. For example, where a right cannot be fulfilled, a justification such as 'identity could not be verified' is represented using a specific concept.

Legal Jurisdiction-relevant concepts for DPV provides concepts to represent laws, authorities, and other legal concepts in various jurisdictions. It is structured to create a separate namespace for each country or jurisdiction by using the ISO 3166-2 code, for example IE represents Ireland and EU represents the European Union. Within this namespace, the specific laws and authorities for that jurisdiction are defined.

At the moment, the following jurisdictions are defined:

• [LEGAL-EU] representing (only) the European Union, with each Member State within the EU/EEA region being defined in its own separate namespace and extension to allow modelling both EU and Country-level laws and knowledge without conflicts:
  • [LEGAL-AT] for Austria
  • [LEGAL-BE] for Belgium
  • [LEGAL-BG] for Bulgaria
  • [LEGAL-CY] for Cyprus
  • [LEGAL-CZ] for Czech Republic
  • [LEGAL-DE] for Germany
  • [LEGAL-DK] for Denmark
  • [LEGAL-EE] for Estonia
  • [LEGAL-ES] for Spain
  • [LEGAL-FI] for Finland
  • [LEGAL-FR] for France
  • [LEGAL-GR] for Greece
  • [LEGAL-HR] for Croatia
  • [LEGAL-HU] for Hungary
  • [LEGAL-IE] for Ireland
  • [LEGAL-IS] for Iceland
  • [LEGAL-IT] for Italy
  • [LEGAL-LI] for Liechtenstein
  • [LEGAL-LT] for Lithuania
  • [LEGAL-LU] for Luxembourg
  • [LEGAL-LV] for Latvia
  • [LEGAL-MT] for Malta
  • [LEGAL-NL] for Netherlands
  • [LEGAL-NO] for Norway
  • [LEGAL-PL] for Poland
  • [LEGAL-PT] for Portugal
  • [LEGAL-RO] for Romania
  • [LEGAL-SE] for Sweden
  • [LEGAL-SI] for Slovenia
  • [LEGAL-SK] for Slovakia
• [LEGAL-GB] for Great Britain and Northern Ireland
• [LEGAL-IN] for India
• [LEGAL-US] for United States of America

Within the [LEGAL-EU] extension namespace, the following laws are defined as separate extensions with their own namespaces:

• EU GDPR concepts for DPV
• EU DGA concepts for DPV
• EU NIS2 concepts for DPV
• EU AI Act concepts for DPV
• EU Health Data Space (EHDS) concepts for DPV
• EU Fundamental Rights concepts for DPV

[SECTOR] provides extensions modelling specific sectors by using those sector-specific concepts, terms, and modelling which extends the concepts in other DPV extensions. At the moment, it only extends the Purpose taxonomy in [DPV]. In the future, we plan to provide more concepts such as Data and PersonalData categories.

The following sectorial extensions are currently provided:

• [SECTOR-EDUCATION] for Education Sector
• [SECTOR-FINANCE] for Finance Sector
• [SECTOR-HEALTH] for Health Sector
• [SECTOR-INFRA] for (Critical) Infrastructure Sector
• [SECTOR-LAW] for Law Enforcement & Justice Sector
• [SECTOR-PUBLICSERVICES] for Public Services Sector

The STANDARD extensions model specific concepts and processes along with the terminology defined and used within specific standards. The goal of this is to represent concepts and processes defined in standards produced in forums such as ISO, CEN/CENELEC, NIST, and IEEE so that they can be used with DPV. It is not intended to duplicate the existing standards, especially when they are already provided as semantic web representations.

The following standards are currently provided:

• [STANDARD-P7012] for IEEE Draft Standard for Machine Readable Personal Privacy Terms