Semantics

This document assumes the reader is familiar with DPV through the [[[PRIMER]]], 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-OWL]]] 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 [[[SKOS-OWL]]], 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.

Scope Change in v2.0

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.

Core Concepts

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:

Taxonomies

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.

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

Services

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 Roles

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.

Authorities

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.

Organisation

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.

Human/Data Subjects

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

Profiling & Tracking

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.

Processing & Storage Conditions

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

Automation

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

Entity/Human Involvement

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.

Data Source

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.

Monitoring, Scoring, Decision Making

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

Scale of Processing

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.

Technology

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 [[[TECH]]] extension provides additional concepts to describe the technology such as involved actors, intended use, capabilities and functions, and documentation.

Duration, Frequency, Necessity

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

Status

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

Technical Measures

Organisational Measures

Legal Measures

Physical Measures

Contract

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

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

Statuses for Other Legal Basis

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 (PD)

[[[PD]]] 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

Locations (LOC)

[[[LOC]]] 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 Management (RISK)

[[[RISK]]] 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.

Technologies (TECH)

[[[TECH]]] 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'.

Artificial Intelligence (AI)

The [[[AI]]] 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.

Justifications

[[[JUSTIFICATIONS]]] 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 Concepts (LEGAL)

[[[LEGAL]]] 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]]]
• [[[EU-DGA]]]
• [[[EU-NIS2]]]
• [[[EU-AIAct]]]
• [[[EU-EHDS]]]
• [[[EU-RIGHTS]]]

Sector

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

Standards

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-P7012]]]

Classes