diff --git a/documentation-generator/jinja2_resources/template_dpv.jinja2 b/documentation-generator/jinja2_resources/template_dpv.jinja2 index d8ce2d344..779480d10 100644 --- a/documentation-generator/jinja2_resources/template_dpv.jinja2 +++ b/documentation-generator/jinja2_resources/template_dpv.jinja2 @@ -192,106 +192,121 @@ {{ sotd() }} -
-

Base Vocabulary

-
- DPV base vocabulary -
Base Vocabulary
-
-

DPV's terms are defined using abstract semantic notions Concept and Relation derived from SKOS concepts and semantic relations respectively. The use of relations is bounded using hasDomain and hasRange. This is to permit its interpretation in various semantic expressions, such as a vocabulary (collection of concepts), or as ontologies in OWL2 or RDFS or something else. The DPV Family of Documents provides an overview of such semantic interpretations provided by the DPVCG.

-

The 'Base' or 'Core' concepts in DPV represent the most relevant concepts for representing information regarding the what, how, where, who, why of personal data and its processing. Each of these concepts is further elaborated as a taxonomy of concepts in a hierarchical fashion. The DPV provides the following as 'top-level' concepts and relations to associate them with other concepts:

- - - - - - - - - - - - - - - +
+

Introduction

+
This document assumes the reader is familiar with DPV through the [[[DPV-Primer]]], and provides a specification documenting the concepts defined by DPV, structured as topical sections.
+ +
+

Semantics

+

DPV's terms are defined using abstract semantic notions Concept and Relation derived from SKOS concepts and semantic relations respectively. The use of relations is bounded using hasDomain and hasRange. These enable representing DPV's concepts as a thesauri, i.e. a list of concepts using SKOS, without any inherent semantics of their own.

+

The interpretation of DPV's concept can be done through serialisation. DPV provides two such serialisations: [[DPV-OWL]] that uses OWL2 and [[DPV-SKOS]] that uses RDFS+SKOS. The DPV Family of Documents provides an overview of all serialisations related to the DPV.

+ +

DPV consists of certain 'core concept' that are intended to be independent representations of specific information, and are distinct from other core concepts. For example, the [=Purpose=] (e.g. Optimisation) refers only to the purpose of why personal data is processed and is independent as a concept from the [=PersonalData=] (e.g. [=Location=]) or the [=Processing=] activities (e.g. [=collect=], [=store=]) involved to carry out that purpose.

+ +

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, which is reflected in the serialisation and documentation (e.g. this document). Other extentions provide additional concepts that expand DPV's concept or complement them with separation and optionality through namespaces. For a list of all DPV related documents, see document family section.

+ +
+ +
+

Base Vocabulary

+
+
+ DPV base vocabulary +
Base Vocabulary
+
+ +

DPV can be viewed as a hierarchical taxonomy of concepts where each core concept represents the top-most abstract concept in a tree and each of its children provide a lesser abstract or more concrete concept. For example, consider the concept of [=PersonalData=] which is the abstract representation of personal data. It can be further refined or extended as [=SensitivePersonalData=], and further as [=SpecialCategoryPersonalData=] and then as GeneticData and so on.

+

From this perspective, the top-most abstract concepts are collectively referred to as the core vocabulary within DPV. The goal of the DPV is to provide a rich collection of concepts for each of top concepts so as to enable their application within real-world use-cases. The identification of what constitutes a core concept is based on the need to represent information about it in a modular and independent form, such as that required for legal compliance.

+ +

The 'Base' or 'Core' concepts in DPV represent the most relevant concepts for representing information regarding the what, how, where, who, why of personal data and its processing. Each of these concepts is further elaborated as a taxonomy of concepts in a hierarchical fashion. The DPV provides the following as 'top-level' concepts and relations to associate them with other concepts:

+
ClassPropertyDescription
[=Concept=][=Relation=]Semantics of Concepts and Relationships
+ + + + + - - - - + + + - - - + + - - - + + - - - + + - - - + + - - - + + - - - + + - - - + + - - - + + - - - + + - - - -
ConceptRelevant Section
[=PersonalData=][=hasPersonalData=]Personal data categories
link
[=Purpose=] [=hasPurpose=]Purpose of Processing
[=Processing=] [=hasProcessing=]Category or type of processing of personal data
[=DataController=] [=hasDataController=]Data Controller responsible for processing
[=DataSubject=] [=hasDataSubject=]Data Subject or Individual whose data is being processing
[=Recipient=] [=hasRecipient=]Recipient of personal data
[=TechnicalOrganisationalMeasure=] [=hasTechnicalOrganisationalMeasure=]Technical and/or Organisational measures associated with processing
[=LegalBasis=] [=hasLegalBasis=]Legal bases or justifications for processing
[=Right=] [=hasRight=]Rights applicable or provided
[=Risk=] [=hasRisk=]Risks applicable or probable regarding processing
[=PersonalDataHandling=] [=hasPersonalDataHandling=]A concept for associating the other core concepts as a 'group, 'policy', or 'set' - so as to express different use-cases and combinations
-

DPV provides taxonomies for all core concepts except the ones specified below:

+ + +

DPV provides taxonomies for all core concepts except the ones specified below:

+ +
+ +
+

Taxonomies

+

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

+

Further to these, there are separate extensions that provide additional concepts. These are:

+ - - {% if core_classes %} -
- {{ table_classes(core_classes, 'base') }} -
- {% endif %} - {% if core_properties %} -
- {{ table_properties(core_properties, 'base') }}
- {% endif %}

Entities

+
+

DPV distinguishes between Entity and Legal Entity based on the use of roles defined legally or within legal norms. To support this, DPV first provides a taxonomy of entities (see below), and then specialises them for Legal Roles (e.g. [=DataController=] and [=DataSubject=]). Further sections provide taxonomies for Organisations, Authorities, and Data Subjects.

{% if entities_classes %}
{{ table_classes(entities_classes) }} @@ -305,6 +320,7 @@

Legal Roles

+

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.

{% if entities_legalrole_classes %}
{{ table_classes(entities_legalrole_classes) }} @@ -319,6 +335,7 @@

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 and isAuthorityFor are provided.

{% if entities_authority_classes %}
{{ table_classes(entities_authority_classes) }} @@ -347,6 +364,7 @@

Data Subjects

+

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 age-based roles: Adult and Child, ParentOfDataSubject, GuardianOfDataSubject; 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.

{% if entities_datasubject_classes %}
{{ table_classes(entities_datasubject_classes) }} @@ -362,6 +380,8 @@

Purposes

+
+

DPV’s taxonomy of purposes is used to represent the reason or justification for processing of personal data. For this, purposes are organised within DPV based on how they relate to the processing of personal data in terms of several factors, such as: management functions related to information (e.g. records, account, finance), fulfilment of objectives (e.g. delivery of goods), providing goods and services (e.g. service provision), intended benefits (e.g. optimisations for service provider or consumer), and legal compliance.

{% if purpose_classes %}
{{ table_classes(purpose_classes) }} @@ -376,6 +396,10 @@

Processing

+
+

DPV’s taxonomy of processing concepts reflects the variety of terms used to denote processing activities or operations involving personal data, such as those from [GDPR] Article.4-2 definition of processing. Real-world use of terms associated with processing rarely uses this same wording or terms, except in cases of specific domains and in legal documentation. On the other hand, common terms associated with processing are generally restricted to: collect, use, store, share, and delete.

+

DPV provides a taxonomy that aligns both the legal terminologies such as those defined by GDPR with those commonly used. For this, concepts are organised based on whether they subsume other concepts, e.g. Use is a broad concept indicating data is used, which DPV extends to define specific processing concepts for Analyse, Consult, Profiling, and Retrieving. Through this mechanism, whenever an use-case indicates it consults some data, it can be inferred that it also uses that data.

+

For concepts related to expressing contextual information associated with processing, such as storage conditions, automation, scale, see Processing Context and Processing Scale sections.

{% if processing_classes %}
{{ table_classes(processing_classes) }} @@ -390,6 +414,12 @@

Personal Data

+
+

DPV provides the concept [=PersonalData=] and the relation [=hasPersonalData=] to indicate what categories or instances of personal data are being processed. The DPV specification only provides a structure for describing personal data, e.g. as being sensitive. For specific categories of personal data for use-cases, [[[DPV-PD]]] provides additional concepts that extend the DPV's personal data taxonomy. 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.

+

In addition to Personal Data, there may be a need to represent Non-Personal Data within the same contextual use-cases. For this, DPV provides the concepts [=Data=], [=NonPersonalData=] and [=SyntheticData=].

+

To indicate data categorised based on [=DataSource=], e.g. as "collected personal data", DPV provides: [=CollectedPersonalData=], [=DerivedPersonalData=], [=InferredPersonalData=], [=GeneratedPersonalData=], and [=ObservedPersonalData=].

+

For indicating personal data which is sensitive, the concept [=SensitivePersonalData=] is provided. For indicating special categories of data, the concept [=SpecialCategoryPersonalData=] is provided. In this, the concept sensitive indicates that the data needs additional considerations (and perhaps caution) when processing, such as by increasing its security, reducing usage, or performing impact assessments. Special categories, by contrast, are a 'special' type of sensitive personal data requiring additional considerations or obligations defined in laws (or through other forms) that regulate how they should be used or prohibit their use until specific obligations are met.

+

To specify data is anonymised, DPV provides two concepts. [=AnonymisedData=] for when data is completely anonymised and cannot be de-anonymised, which is a subtype of [=NonPersonalData=]. And, [=PseudoAnonymisedData=] for when data has only been partially anonymised or de-anonymisation is possible, which is a subtype of [=PersonalData=].

{% if personaldata_classes %}
{{ table_classes(personaldata_classes) }} @@ -404,6 +434,9 @@

Tech/Org Measures

+
+

DPV's taxonomy of tech/org measures are structured into two groups representing and [=TechnicalMeasure=] and [=OrganisationalMeasure=] along with specific properties for each. Each term has a dedicated taxonomy that expands upon the core idea to provide a rich list of technial and organisational measures that are intended to protect personal data (and its associated entities and consequences).

+

This taxonomy also includes relations that are associated with measures, such as [=hasNotice=] or [=hasPolicy=], which are generic and can be applied to other contexts (e.g. notice for consent, policy for data storage).

{% if technical_organisational_measures_classes %}
{{ table_classes(technical_organisational_measures_classes) }} @@ -414,8 +447,9 @@ {{ table_properties(technical_organisational_measures_properties) }}
{% endif %} -
+

Technical Measures

+
{% if technical_measures_classes %} {{ table_classes(technical_measures_classes, skip_heading=True) }} {% endif %} @@ -423,8 +457,9 @@ {{ table_properties(technical_measures_properties, skip_heading=True) }} {% endif %}
-
+

Organisational Measures

+
{% if organisational_measures_classes %} {{ table_classes(organisational_measures_classes, skip_heading=True) }} {% endif %} @@ -434,78 +469,165 @@
-
-

Contextual Info

- {% if context_classes %} -
- {{ table_classes(context_classes) }} +