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, 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's 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 has been expanded 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 unambigious representation of legal extensions
7. Restructuring the GitHub repository to accommodate the changed structure of DPV extensions

In addition to the above, the v2 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 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 Invovlement, 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.

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 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 criterias 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.

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 and isAuthorityFor 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 data subject types to assist with describing what kind of individuals or groups are associated with an use-case. Some examples of such types are agency-based roles: Adult and Child, ParentOfDataSubject, GuardianOfDataSubject; those associated with vulnerability: VulnerableDataSubject, ElderlyDataSubject, 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.

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

DPV provides (qualitative) scales for expressing Data Volume, Data subjects, and Geographical Coverage of processing. Along with these, DPV also provides a Processing Scale to express combinations of these. NOTE: The actual meaning or quantified amounts for each concept are not defined due to their interpretation based on contextual factors such as legislations, guidelines, domains, and variations across industries.

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.

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.

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

AI Technology concepts for DPV is an extension under development which will further extend the [TECH] extension to represent concepts associated with AI. These will include representation 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
• Actors such as AI Developer and AI Deployer
• Status associated with AI development

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 concepts for Germany (DE)
• Legal concepts for European Union (EU)
• Legal concepts for United Kingdom of Great Britain and Northern Ireland (UK)
• Legal concepts for Ireland (IE)
• Legal concepts for India (IN)
• Legal concepts for United States of America (USA)

At the moment, the following EU laws are defined: