The Data Privacy Vocabulary [DPV] enables expressing machine-readable metadata about the use and processing of personal data based on legislative requirements such as the General Data Protection Regulation [GDPR]. This document describes the DPV-OWL specification that provides the DPV as an OWL2 ontology.
For a general overview of the Data Protection Vocabularies and Controls Community Group [DPVCG], its history, deliverables, and activities - refer to DPVCG Website.
The peer-reviewed article “Creating A Vocabulary for Data Privacy” presents a historical overview of the DPVCG, and describes the methodology and structure of the DPV along with describing its creation. An open-access version can be accessed here, here, and here.
Contributing to the DPV and its extensions The DPVCG welcomes participation regarding the DPV, including expansion or refinement of its terms, addressing open issues, and welcomes suggestions on their resolution or mitigation. For further information, please see the contribution section.
GitHub Issues are preferred for
discussion of this specification.
DPV-OWL's terms are defined using OWL2 semantic, where concepts are expressed using owl:Class, subtypes are expressing using rdfs:subClassOf, instances using owl:NamedIndividual, and relations using owl:ObjectProperty. The taxonomies are expressed as hierarchies through subclass mechanisms.
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.
1.2 Base Vocabulary
Issue 1: Base vocabulary diagram
Figure 1 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:
DPV provides taxonomies for all core concepts except the ones specified below:
PersonalDataHandling: DPV defines the concept of for representing a 'policy' or 'grouping' that associates the top-level concepts with one another. The relation hasPersonalDataHandling provides a relation to associate a PersonalDataHandling with other concepts, including like itself.
Right: The concept Right represents a generic rights provided or recognised by some law or convention. The relation hasRight provides the relation to associate a Right with concepts.. In addition, DataSubjectRight refers to rights specifically available to applicable for Data Subjects.
1.3 Taxonomies
The rest of the document expands on the core concepts through the following taxonomies.
Risk & Impacts for risk assessment, management, and expressino 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.
Further to these, there are separate extensions that provide additional concepts. These are:
DPV relies on existing well-founded interpretations for its concepts, which in this case relate to Entity as a generic universal concept and LegalEntity specifically referring to roles defined legally or within legal norms. Expanding on these, DPV provides a taxonomy of entities based on their application within laws and use-cases in the form of Legal roles, such as DataController, DataSubject, and Authority. Later, these concepts are expanded into taxonomies for different kinds of entities categorised under a common concept. For example, categories of Data Subjects such as Adult, User, or Employee; or kinds of Authorities, or categories of Organisations.
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 EU, in particular the EDPB, uses data exporter the context of cross-border data transfers/flows. These concepts are not bound by jurisdictional or geopolitical scopes within DPV and can thus be used for any notion of exporting
The EU, in particular the EDPB, uses data importing the context of cross-border data transfers/flows. These concepts are not bound by jurisdictional or geopolitical scopes within DPV and can thus be used for any notion of importing
An entity within or authorised by an organisation to monitor internal compliance, inform and advise on data protection obligations and act as a contact point for data subjects and the supervisory authority.
A recipient of personal data can be used to indicate any entity that receives personal data. This can be a Third Party, Processor (GDPR), or even a Controller.
A ‘third party’ means a natural or legal person, public authority, agency or body other than the data subject, controller, processor and people who, under the direct authority of the controller or processor, are authorised to process personal data.
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.
An organisation and its subordinate bodies governed by public international law, or any other body which is set up by, or on the basis of, an agreement between two or more countries
The legality of age defining a child varies by jurisdiction. In addition, 'child' is distinct from a 'minor'. For example, the legal age for consumption of alcohol can be 21, which makes a person of age 20 a 'minor' in this context. In other cases, 'minor' and 'child' are used interchangeably to refer to a person below some legally defined age.
This concept denotes a Data Subject or a group are vulnerable, but not what vulnerability they possess or its context. This information can be provided additionally as comments, or as separate concepts and relations. Proposals for this are welcome.
Georg P Krog,
Harshvardhan J. Pandit,
Julian Flake,
Paul Ryan
3. Purposes
Figure 3 Overview of Purpose taxonomy in DPV (click to open in new window)
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.
Purposes associated with conducting advertising i.e. process or artefact used to call attention to a product, service, etc. through announcements, notices, or other forms of communication
Customer Care Communication refers to purposes associated with communicating with customers for assisting them, resolving issues, ensuring satisfaction, etc. in relation to services provided
Communication Management refers to purposes associated with providing or managing communication activities e.g. to send an email for notifying some information
This purpose by itself does not sufficiently and clearly indicate what the communication is about. As such, it is recommended to combine it with another purpose to indicate the application. For example, Communication of Payment.
Created:
Contributor(s):
David Hickey,
Georg P Krog,
Harshvardhan J. Pandit,
Paul Ryan
Customer Care refers to purposes associated with purposes for providing assistance, resolving issues, ensuring satisfaction, etc. in relation to services provided
Customer Order Management refers to purposes associated with managing customer orders i.e. processing of an order related to customer's purchase of good or services
HR is a broad concept. Its management includes, amongst others - recruiting employees and intermediaries e.g. brokers, independent representatives; payroll administration, remunerations, commissions, and wages; and application of social legislation.
This purpose only refers to processing that is additionally required in order to fulfill the obligations and requirements associated with a law. For example, the use of consent would have its own separate purposes, with this purpose addressing a legal requirement for maintaining consent record (along with RecordManagement). This purpose will typically be used with Legal Obligation as the legal basis.
Created:
Modified:
Contributor(s):
Beatriz Esteves,
Georg P Krog,
Harshvardhan J. Pandit
The term optmisation here refers to the efficiency of the service in terms of technical provision (or similar means) with benefits for everybody. Personalisation implies making changes that benefit the current user or persona.
Created:
Contributor(s):
Axel Polleres,
Elmar Kiesling,
Fajar Ekaputra,
Harshvardhan J. Pandit,
Javier Fernandez,
Simon Steyskal
Note that this concept relates to internal organisational compliance. The concept LegalCompliance should be used for external legal or regulatory compliance.
Created:
Contributor(s):
David Hickey,
Georg P Krog,
Harshvardhan J. Pandit,
Paul Ryan
This term is a blanket purpose category for indicating personalisation of some other purpose, e.g. by creating a subclass of the other concept and Personalisation
Purposes associated with manage creation, storage, and use of records relevant to operations, events, and processes e.g. to store logs or access requests
This purpose relates specifiaclly for record creation and management. This can be combined or used along with other purposes to express intentions such as records for legal compliance or vendor payments.
Created:
Contributor(s):
David Hickey,
Georg P Krog,
Harshvardhan J. Pandit,
Paul Ryan
Purposes associated with identifying, rectifying, or otherwise undertaking activities intended to fix or repair impairments to existing functionalities
The use of 'request' here includes where an user explicitly asks for the service and also when an established contract requires the provision of the service
Created:
Contributor(s):
Beatriz Esteves,
Georg P Krog,
Harshvardhan J. Pandit
Sector describes the area of application or domain that indicates or restricts scope for interpretation and application of purpose e.g. Agriculture, Banking
Note:
There are various sector codes used commonly to indicate the domain of an organisation or business. Examples include NACE (EU), ISIC (UN), SIC and NAICS (USA).
Created:
Contributor(s):
Axel Polleres,
Elmar Kiesling,
Fajar Ekaputra,
Harshvardhan J. Pandit,
Javier Fernandez,
Simon Steyskal
Sell here means exchange, submit, or provide in return for direct or indirect compensation. Was subclass of commercial interest, changed to reflect selling something
Created:
Contributor(s):
Axel Polleres,
Elmar Kiesling,
Fajar Ekaputra,
Harshvardhan J. Pandit,
Javier Fernandez,
Simon Steyskal
Sell here means exchange, submit, or provide in return for direct or indirect compensation. Was subclass of commercial interest, changed to reflect selling something
Created:
Contributor(s):
Axel Polleres,
Elmar Kiesling,
Fajar Ekaputra,
Harshvardhan J. Pandit,
Javier Fernandez,
Simon Steyskal
Sell Products here refers to processing necessary to provide and complete a sale to customers. It should not be confused with providing services with a cost based on an established agreement.
Created:
Contributor(s):
Axel Polleres,
Elmar Kiesling,
Fajar Ekaputra,
Harshvardhan J. Pandit,
Javier Fernandez,
Simon Steyskal
Purposes associated with creating and providing pesonalised advertisement where the personalisation is targeted to a specific individual or group of individuals
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.
to irreversibly alter personal data in such a way that an unique data subject can no longer be identified directly or indirectly or in combination with other data
Infer indicates data that is derived without it being present or obtainable from existing data. For data that is presented, and is 'extracted' or 'obtained' from existing data, see Derive.
Axel Polleres,
Bud Bruegger,
Harshvardhan J. Pandit,
Javier Fernández,
Mark Lizar
5. Personal Data
Figure 5
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: Extension providing Personal Data Categories 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.
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, PseudonymisedData for when data has only been partially anonymised or de-anonymisation is possible, which is a subtype of PersonalData.
It is advised to carefully consider indicating data is fully or completely anonymised by determining whether the data by itself or in combination with other data can identify a person. Failing this condition, the data should be denoted as PseudonymisedData. To indicate data is anonymised only for a specified entity (e.g. within an organisation), the concept ContextuallyAnonymisedData (as subclass of PseudonymisedData) should be used instead of AnonymisedData.
Derived Data is data that is obtained through processing of existing data, e.g. deriving first name from full name. To indicate data that is derived but which was not present or evident within the source data, InferredPersonalData should be used.
Inferred Data is derived data generated from existing data, but which did not originally exist within it, e.g. inferring demographics from browsing history.
The term NonPersonalData is provided to distinguish between PersonalData and other data, e.g. for indicating which data is regulated by privacy laws. To specify personal data that has been anonymised, the concept AnonymisedData should be used.
This definition of personal data encompasses the concepts used in GDPR Art.4-1 for 'personal data' and ISO/IEC 2700 for 'personally identifiable information (PII)'.
Personal Data that has undergone a pseudonymisation process or a partial (incomplete) anonymisation process such that it is still considered Personal Data
Sensitivity' is a matter of context, and may be defined within legal frameworks. For GDPR, Special categories of personal data are considered a subset of sensitive data. To illustrate the difference between the two, consider the situation where Location data is collected, and which is considered 'sensitive' but not 'special'. As a probable rule, sensitive data require additional considerations whereas special category data requires additional legal basis / justifications.
The term 'special category' is based on GDPR Art.9, but should not be considered as exlusive to it. DPV considers all Special Categories to also be Sensitive, but whose use is either prohibited or regulated and therefore requires additional legal basis for justification.
Synthetic data reffers to artificially created data such that it is intended to resemble real data (personal or non-personal), but does not refer to any specific identified or identifiable individual, or to the real measure of an observable parameter in the case of non-personal data
Figure 6 Overview of Technical & Organisational Measures taxonomy in DPV (click to open in new window)
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).
Anonymisation is the process by which data is irreversibly altered in such a way that a data subject can no longer be identified directly or indirectly, either by the entity holding the data alone or in collaboration with other entities and information sources
Pseudonymisation means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person;
An agreement outlining conditions, criteria, obligations, responsibilities, and specifics for carrying out processing of personal data between a Data Controller and a Data Processor
An agreement outlining conditions, criteria, obligations, responsibilities, and specifics for carrying out processing of personal data between Controllers within a Joint Controllers relationship
A scheme within the risk management framework specifying the approach, the management components, and resources to be applied to the management of risk
An agreement outlining conditions, criteria, obligations, responsibilities, and specifics for carrying out processing of personal data between a Data Processor and a Data (Sub-)Processor
An agreement outlining conditions, criteria, obligations, responsibilities, and specifics for carrying out processing of personal data between a Data Controller or Processor and a Third Party
DPV provides the following categories of legal bases based on [GDPR] Article 6: consent of the data subject, contract, compliance with legal obligation, protecting vital interests of individuals, legitimate interests, public interest, and official authorities. Though derived from GDPR, these concepts can be applied for other jurisdictions and general use-cases. The legal bases are represented by the concept LegalBasis and associated using the relation hasLegalBasis.
When declaring a legal basis, it is important to denote under what law or jurisdiction that legal basis applies. For instance, using Consent as a legal basis has different obligations and requirements in EU (i.e. [GDPR]) as compared to other jurisdictions. Therefore, unless the information is to be implicitly interpreted through some specific legal lens or jurisdictional law, DPV recommends indicating the specific law or legal clause associated with the legal basis so as to scope its interpretation. This can be done using the relation hasJurisdiction or hasApplicableLaw.
For GDPR, DPVCG provides the DPV-GDPR: Extension providing GDPR concepts which defines the legal bases within [GDPR] by extending them from relevant concepts within the DPV. We welcome similar contributions for extending the GDPR extension as well as creating extensions for other laws and domains.
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 Relations - to enable association of relevant information with consent, such as the notice used or provided, status of consent, or who indicated it.
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 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.
Note: Deprecated concepts
The concepts/relations for consent added in DPV v0.1 and later have been deprecated or removed from the DPV in favour of the newer set of concepts based on advances in legislative requirements as well as standardisation efforts such as ISO/IEC TS 27560 Privacy technologies — Consent record information structure. The list of deprecated concepts is provided in Appendix and a note on converting existing implementations to use newer concepts is provided in [DPV-GUIDE-Consent].
Explicitly expressed consent is a more specific form of Expressed consent where the action taken must 'explicitly' relate to only the consent decision. Expressed consent where the consenting is part of other matters therefore cannot satisfy the requirements of explicitly expressed consent. An example of explicit action expressing the consenting decision is a button on a web form where the form only relates to consent, or it is accompanied with suitable text that reiterates what the consenting decision is about
Created:
Contributor(s):
Georg P Krog,
Harshvardhan J. Pandit,
Julian Flake,
Paul Ryan
Expressed consent requires the individual take a specific and unambigious action that directly indicates their consent. This action may be a part of other processes such as setting preferences, or agreeing to a contract, or other matters not relating to consent. An example of expressed consent is interacting with a checkbox within a dashboard or clicking a button on a web form
Created:
Contributor(s):
Georg P Krog,
Harshvardhan J. Pandit,
Julian Flake,
Paul Ryan
Implied consent is expected to also be Informed Consent. An example is a CCTV notice outside a monitored area that informs the individuals that by walking in they would be consenting to the use of camera for surveillance.
Created:
Contributor(s):
Georg P Krog,
Harshvardhan J. Pandit,
Julian Flake,
Paul Ryan
An example of this state is when the obtained consent has been assigned a duration - which has lapsed or 'expired', making it invalid to be used further for processing data
An example of this state is when the individual clicks on a button, ticks a checkbox, verbally agrees - or any other form that communicates their decision agreeing to the processing of data
An example of this state is where an investigating authority or a court finds the collected consent did not meet requirements, and 'invalidates' both prior and future uses of it to carry out processing
An example of this state is when the individual closes or dismisses a notice without making a decision. This state is intended for making the distinction between a notice being provided (as a consent request) and the individual interacting with the notice without making a decision - where the 'ignoring of a notice' is taken as consent being neither given nor refused
States are useful as information artefacts to implement them in controlling processing, and to reflect the process and flow of obtaining and maintaining consent. For example, a database table that stores consent states for specific processing and can be queried to obtain them in an efficient manner. States are also useful in investigations to determine the use and validity of consenting practices
This state can be considered a form of 'revocation' of consent, where the revocation can only be performed by the data subject. Therefore we suggest using ConsentRevoked when it is a non-data-subject entity, and ConsentWithdrawn when it is the data subject
An example of this state is when a previously given consent has expired, and the individual is presented a notice regarding continuing associated processing operations - to which they agree. This state can be useful to keep track of 'reconfirmed' or 'refreshed' consent within consent records, assist notices and contextual agents to create better consenting dialogues, and assist with specific legal obligations related to subsequent consenting
Georg P Krog,
Harshvardhan J. Pandit,
Julian Flake,
Paul Ryan
8. Context of Processing
Figure 11
8.1 Storage Conditions, Automation
This taxonomy provides concepts for representing information about storage conditions, e.g. how long the data will be stored for, its erasure, or its restoration. It also enables representing the source(s) of data, the use of automation, and the extent of human involvement within the automation.
The processing taxonomy uses the concept Store to indicate data is being stored. To specify additionally information such as its location, erasure or deletion, the generic concepts and relations associated with processing (i.e. location and duration) can be used. However, to emphasise that information about storage - such as policies, conditions, rules, or documentation - are critical on considerations of data protection and privacy as well as legal compliance, DPV provide specific concepts related to these.
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. This enables a document to directly specify information such as: "storage duration is 6 months" or "storage restoration uses 3 geo-distinct backup servers".
For declaring the source of data, the DataSource concept along with hasDataSource relationship is provided to indicate where the data is collected or acquired from. For example, data can be obtained from the data subject directly (e.g. given via forms) or indirectly (e.g observed from activity, or inferred from existing data), or from another entity such as a third party.
To indicate more specific applications: DecisionMaking and AutomatedDecisionMaking refer to use of processing to make decisions, AlgorithmicLogic for explaining the use of algorithms and specifics of processing logic, EvaluationScoring to indicate the processing evaluates or assigns scores (or metrics), InnovativeUseOfNewTechnologies to indicate there are innovative uses of novel technologies, and SystematicMonitoring to indicate the processing performs a systematic (or systemic) monitoring. These additional concepts are intended to model areas or topics that are considered sensitive or high-risk or require caution.
Algorithmic Logic is intended as a broad concept for explaining the use of algorithms and automated decisions making within Processing. To describe the actual algorithm, see the Algorithm concept.
Automated decision making can be defined as “the ability to make decisions by technological means without human involvement.” (“Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679 (wp251rev.01)”, 2018, p. 8)
It is difficult to provide a formal definition of automation since any and all processing may be considered automation. This concept instead is intended to explicitly signal the utilisation of automation and its extent towards some context - such as decision making, and to indicate the involvement of humans.
This refers to where that data was made publicly available by the data subject. An example of this would be a social media profile that the data subject has made publicly accessible.
Human Involvement here broadly refers to any involvement by a human in the context of carrying out processing. This may include verification of outcomes, providing input data for making decisions, or overseeing activities.
The term 'Public' is used here in a broad sense. Actual consideration of what is 'Public Data' can vary based on several contextual or jurisdictional factors such as definition of open, methods of access, permissions and licenses.
Created:
Contributor(s):
Beatriz Esteves,
Georg P Krog,
Harshvardhan J. Pandit,
Julian Flake,
Paul Ryan
Axel Polleres,
Harshvardhan J. Pandit,
Mark Lizar,
Rob Brennan
8.2 Scale of Processing
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 exact definition of what constitutes "large scale" depends on use of jurisdictional, domain-specific, or other forms of externally defined criterias. Where possible, this should be reflected by extending this term with the appropriate context.
The exact definition of what constitutes "scale" depends on use of jurisdictional, domain-specific, or other forms of externally defined criterias. Where possible, this should be reflected by extending the scales provided with the appropriate context.
Scales are subjective concepts that need to be defined and interpreted within the context of their application. For example, what would be small within one context could be large within another.
To express the duration of events or operations, such as how long processing will take or the validity of consent, the concept Duration can be used. Duration is indicated using the relation hasDuration, and has the following subtypes:
TemporalDuration - indicating a relative temporal duration, e.g. 6 months.
UntilTimeDuration - indicating duration that occurs until the end of specified time, e.g. until 31 DEC 2022.
UntilEventDuration - indicating duration that occurs until the end of specified event, e.g. until account is closed.
FixedOccurencesDuration - a duration that is based on number of occurences, e.g. until you view it 3 times
EndlessDuration - indicating a duration without an end condition or temporal notation.
3.1.71 Social Media Marketing
https://w3id.org/dpv/dpv-owl#SocialMediaMarketing