This document provides additional details and examples for legal bases used in the Data Privacy Vocabulary [DPV], and is a companion to the [DPV] specification.
Contributing: The DPVCG welcomes participation to improve the DPV and associated resources, including expansion or refinement of concepts, requesting information and applications, and addressing open issues. See contributing guide for further information.
GitHub Issues are preferred for
discussion of this specification.
1. DPV and Related Resources
Data Privacy Vocabulary (DPV) Specification: is the base/core specification for the 'Data Privacy Vocabulary', which is extended for Personal Data [PD], Locations [LOC], Risk Management [RISK], Technology [TECH], and [AI]. Specific [LEGAL] extensions are also provided which model jurisdiction specific regulations and concepts - see the complete list of extensions. To support understanding and applications of [DPV], various guides and resources [GUIDES] are provided, including a [PRIMER]. A Search Index of all concepts from DPV and extensions is available.
[DPV] and related resources are published on GitHub. For a general overview of the Data Protection Vocabularies and Controls Community Group [DPVCG], its history, deliverables, and activities - refer to DPVCG Website. For meetings, see the DPVCG calendar.
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. The article Data Privacy Vocabulary (DPV) - Version 2, accepted for presentation at the 23rd International Semantic Web Conference (ISWC 2024), describes the changes made in DPV v2.
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
. The list of available laws and their representation as extensions in DPV can be seen in the [LEGAL] extension.
dpv:Contract: Creation, completion, fulfilment, or performance of a contract involving specified processing of data or technologies
go to full definition
dpv:ContractPerformance: Fulfilment or performance of a contract involving specified processing of data or technologies
go to full definition
dpv:DataControllerContract: Creation, completion, fulfilment, or performance of a contract, with Data Controllers as parties being Joint Data Controllers, and involving specified processing of data or technologies
go to full definition
dpv:DataProcessorContract: Creation, completion, fulfilment, or performance of a contract, with the Data Controller and Data Processor as parties, and involving specified processing of data or technologies
go to full definition
dpv:DataSubjectContract: Creation, completion, fulfilment, or performance of a contract, with the Data Controller and Data Subject as parties, and involving specified processing of data or technologies
go to full definition
dpv:EnterIntoContract: Processing necessary to enter into contract
go to full definition
dpv:ThirdPartyContract: Creation, completion, fulfilment, or performance of a contract, with the Data Controller and Third Party as parties, and involving specified processing of data or technologies
go to full definition
dpv:LegalBasis: Legal basis used to justify processing of data or use of technology in accordance with a law
go to full definition
dpv:Consent: Consent of the Data Subject for specified process or activity
go to full definition
dpv:DataTransferLegalBasis: Specific or special categories and instances of legal basis intended for justifying data transfers
go to full definition
dpv:LegalObligation: Legal Obligation to conduct the specified activities
go to full definition
dpv:LegitimateInterest: Legitimate Interests of a Party as justification for specified activities
go to full definition
dpv:LegitimateInterestOfController: Legitimate Interests of a Data Controller in conducting specified activities
go to full definition
dpv:LegitimateInterestOfDataSubject: Legitimate Interests of the Data Subject in conducting specified activities
go to full definition
dpv:LegitimateInterestOfThirdParty: Legitimate Interests of a Third Party in conducting specified activities
go to full definition
dpv:OfficialAuthorityOfController: Activities are necessary or authorised through the official authority granted to or vested in the Data Controller
go to full definition
dpv:PublicInterest: Activities are necessary or beneficial for interest of the public or society at large
go to full definition
dpv:VitalInterest: Activities are necessary or required to protect vital interests of a data subject or other natural person
go to full definition
dpv:VitalInterestOfNaturalPerson: Activities are necessary or required to protect vital interests of a natural person
go to full definition
dpv:VitalInterestOfDataSubject: Activities are necessary or required to protect vital interests of a data subject
go to full definition
Note
When using legal bases, we advise careful consideration whether the information to be represented is regarding a specific instance (e.g. consent of a specific individual) or a general category (e.g. contract with service consumer/users), and to utilise DPV concepts accordingly.
Currently, only the Consent legal basis has additional information (e.g. status, types) modelled within the taxonomy. Similar concepts should be added for other legal bases.
(Update 2024-05-17) The legal bases in DPV based on GDPR are:
Consent
Contract
Data Subject Contract
Data Processor Contract
Data Controller Contract
Third Party Contract
Contract Performance
Enter Into Contract
Data Transfer Legal Basis
Legal Obligation
Legitimate Interest
Legitimate Interest of Controller
Legitimate Interest of Third Party
Legitimate Interest of Data Subject
Official Authority of Controller
Public Interest
Vital Interest
Vital Interest of Data Subject
Vital Interest of Natural Person
3. Contract
Contract as a legal basis covers activities associated with creation of the contract (EnterIntoContract) and the performance of the contract ContractPerformance. Metadata associated with the contract such as date, time, subject, etc. can be represented using DCMI Metadata Terms (DCT).
Contracts are also a dpv:LegalMeasure that can be used by organisations to enforce obligations e.g. by a controller on a processor. Similarly, contracts can also be 'agreements' e.g. between a controller and a processor, where the processor uses this agreement as a legal basis to process personal data.
Note: Extending the contract concepts in DPV
4. Legal Obligation
LegalObligation represents using the justification of an obligation to perform the activity as defined in law or required by a legal procedure such as a court or authority order. When using legal obligations as the legal basis, it is good practice (and necessary for its legality) to also define the specific law or legal mechanism under which the obligation is defined. This can be done using dpv:hasApplicableLaw.
Consent is an important legal basis given its emphasis on individual empowerment and control, as well as the attention and relevance it receives from being part of direct interactions with individuals. 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". DPV provides concepts for representing information about how consent, as a legal basis, is utilised (by the Controller), provided or given (by the Data Subject), how long it is considered to be valid (its duration), and how it can be withdrawn. It also provides concepts related to management of information, such as keeping track of whether the consent has been requested, was refused, or has been given. This information can be utilised in applications associated with consent, such as creating a ‘record’ of consent or building and executing rules for compliance.
Given the reliance of consent as a legal basis whose validity is associated with requirements and obligations based on jurisdictional laws, DPV does not explicitly provide constraints on what should be considered a ‘valid’ consent. Instead, it focuses on providing declaration of information about consent so as to aid in the determination of its validity, and to record its use and changes over time. Further information concerning compliance obligations and requirements related to consent are considered within the scope of the DPVCG, and we welcome contributions on how this can be represented in a coherent manner that is compatible with the rest of DPV.
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 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 dpv:hasDuration along with specific forms of dpv:Duration can be used. For example, to indicate consent is valid until a specific event such as account closure, the duration subtype dpv:UntilEventDuration can be used with additional instantiation or annotation to indicate more details about the event (in this case the closure of account). Similarly, dpv:UntilTimeDuration indicates validity until a specific time instance or timestamp (e.g. 31 December 2022), and dpv:TemporalDuration indicates a relative time duration (e.g. 6 months). To indicate validity without an end condition, dpv:EndlessDuration can be used. To indicate the notice used for informed consent, the concept dpv:ConsentNotice is provided, which can be used with the relation dpv:hasNotice.
To specify consent provided by delegation, such as in the case of a parent or guardian providing consent for/with a child, the dpv: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 dpv:hasDataSubject, the additional information provided by dpv: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 dpv:EntityInvolvement concepts dpv:OptingIntoProcess and dpv:WithdrawingFromProcess.
Note: Guide on implementing consent records as per ISO/IEC TS 27560:2023
This is a companion issue along with #90 Implementing ISO/IEC 27560 Consent Records.
5.1 Consent Types
By default, consent is expected to adhere to several requirements such as being informed, freely given, and so on - typically defined within law or other relevant guidelines, that determine how it is requested, expressed, and evaluated for validity. In DPV, these are referred to as types of consent.
DPV provides InformedConsent and UninformedConsent as two distinct concepts related to whether the consent is informed or not. For more types of informed consent, the concept ImpliedConsent specifies when consent is indirectly expressed or is assumed, and ExpressedConsent for when the individual specifically takes an action to (only) express their consent. The difference between the two can be better understood as follows: if the individual performs an action, and that action only relates to consent, then it is said to be expressed consent, whereas if that action also relates to other matters in addition to being about consent, then the interaction is said to be implied (form of) consent. Clicking a button on a consent notice is a direct action and is thus a form of expressed consent. Assuming consent based on continued scrolling of a web page is an indirect or assumed action, and is thus implied consent.
Note: Implied Consent in DPV is not the same as Medical Implied Consent
In medical terminology, "implied consent" is an assumption that the person's consent is present so as to avoid the restrictions of collecting consent prior to any (emergency)treatment. This is not the case with privacy and data protection perspectives, where 'implied consent', no matter how well intentioned the purpose may be, should not be considered 'assumed' without any specific action.
Therefore, we welcome well reasoned arguments and concrete proposals to express other types of consent, including justifications for where concepts such as AssumedConsent may be useful and have a basis in a law or other authoritative source.
When the expressed action for consent only (and only) refers to matters related to consent, then such consent is represented by ExplicitlyExpressedConsent. For example, if a button for expressing consent relates to conveying decisions about consent, but also other things such as to navigate to the next page, then this is a clear and specific action for expressing consent. However, if such a button only relates to indicating consent, then it is explicitly about consent, and is thus an instance of Explicitly Expressed Consent.
Note: Explicit consent in DPV, ISO, and GDPR
The term explicit consent is present in both ISO as well as GDPR and other laws. However, definitions differ significantly and are incompatible with each other. For example, what ISO considers 'explicit' would be 'expressed' (or regular) under GDPR. The approach taken by DPV is intentional towards enabling such variations to be expressed in specific extensions by building on top of the core vocabulary concepts. For example, the [EU-GDPR] extension defines A6-1-a-explicit-consent and A9-2-a as subtypes of ExplicitlyExpressedConsent based on the specific requirements and criteria defined by GDPR.
dpv:InformedConsent: Consent that is informed i.e. with the requirement to provide sufficient information to make a consenting decision
go to full definition
dpv:ExpressedConsent: Consent that is expressed through an action intended to convey a consenting decision
go to full definition
dpv:ExplicitlyExpressedConsent: Consent that is expressed through an explicit action solely conveying a consenting decision
go to full definition
dpv:ImpliedConsent: Consent that is implied indirectly through an action not associated solely with conveying a consenting decision
go to full definition
dpv:UninformedConsent: Consent that is uninformed i.e. without requirement to provide sufficient information to make a consenting decision
go to full definition
5.2 Consent Status
The state or status of consent refers to the stage of information about a particular consent instance within its lifecycle. For example, (given) consent first starts with the identification of need to ask consent, then issuing a request (to the individual), making a decision (by the individual), and then following it up with further actions such as the individual withdrawing it. Keeping track of such information is necessary in order to determine whether the current stage of consent information is suitable for its use in justifying processing of personal data governed by that consent, as well as to fulfil obligations such as to keep records of consent. To assist with such consent information management, DPV provides Consent Status as a way to represent the lifecycle and usefulness of an instance towards processing personal data.
DPV's Consent Statuses are represented by ConsentStatus and indicated using hasConsentStatus relation. The statuses are segregated into two categories based on their interpretation towards processing: ConsentStatusValidForProcessing and ConsentStatusInvalidForProcessing. There are (currently) only two statuses that are valid for processing: ConsentGiven representing the individual has consented, and RenewedConsentGiven where an earlier given consent is renewed, refreshed, or reaffirmed.
The rest of (currently) 8 statuses refer to various stages that are considered invalid for processing. These are: ConsentUnknown for when information about the status is unknown or unconfirmed, ConsentRequested for when a request to obtain or give consent has been made, ConsentRequestDeferred for when the request was opted to be dismissed or delayed without a decision, ConsentRefused for when consent was refused, ConsentExpired for when the validity (temporal or otherwise) associated with a given consent instance has lapsed, ConsentInvalidated for when a given consent instance is found invalid e.g. by a court, ConsentRevoked for when a given consent instance is revoked or terminated such as when a service provider stops providing the service, and ConsentWithdrawn for when the individual withdraws a previously given consent.
dpv:ConsentStatusInvalidForProcessing: States of consent that cannot be used as valid justifications for processing data
go to full definition
dpv:ConsentExpired: The state where the temporal or contextual validity of consent has 'expired'
go to full definition
dpv:ConsentInvalidated: The state where consent has been deemed to be invalid
go to full definition
dpv:ConsentRequestDeferred: State where a request for consent has been deferred without a decision
go to full definition
dpv:ConsentRequested: State where a request for consent has been made and is awaiting a decision
go to full definition
dpv:ConsentRevoked: The state where the consent is revoked by an entity other than the data subject and which prevents it from being further used as a valid state
go to full definition
dpv:ConsentUnknown: State where information about consent is not available or is unknown
go to full definition
dpv:ConsentWithdrawn: The state where the consent is withdrawn or revoked specifically by the data subject and which prevents it from being further used as a valid state
go to full definition
dpv:ConsentStatusValidForProcessing: States of consent that can be used as valid justifications for processing data
go to full definition
dpv:RenewedConsentGiven: The state where a previously given consent has been 'renewed' or 'refreshed' or 'reaffirmed' to form a new instance of given consent
go to full definition
5.3 Consent Indication
To indicate which entity is responsible for a specific consent stage (e.g. individual for given consent, requestor for consent requested), the relation isIndicatedBy is provided. It can be used with any Entity such as DataSubject or its subtypes such as User or specific instances of these to record information regarding who was responsible for the indicated status and consent action. To indicate the method by which an entity has indicated the specific consent, the relation hasIndicationMethod is provided. To indicate the time (or similar temporal information), the relation isIndicatedAtTime is provided.
Note: Common legal concepts/properties
The concepts and relations mentioned here regarding consent, such as isIndicatedBy, are also applicable and suitable for use with other legal bases or actions, such as contracts, legal requests, or exercising rights. Therefore, these can also be used in other contexts as deemed suitable. We are working on providing specific concepts and guidance for more detailed representation of information for such other legal bases and actions.
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.
To indicate how consent is to be provided or withdrawn e.g. how should an individual express or withdraw their consent, DPV provides Consent Controls as: ProvideConsent for the individual to provide or give their consent, ObtainConsent for the organisation to obtain or collect consent from the individual, WithdrawConsent for the individual to withdraw their given consent, and ReaffirmConsent for entities to re-affirm their previously provided or obtained consent. To indicate how to implement the action e.g. provide consent, the relation isExercisedAt should be used.
5.4 Duration of 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.
While the above information considered duration as determining the validity of given consent, there are also other uses of duration associated with consent. For example, the duration information is intended to be a trigger to confirm or renew consent instead of rendering it invalid immediately. Or, the duration associated with ConsentRequested could be used to indicate when consent should be requested again.
LegitimateInterest represents a 'legitimate' reason for the entity to carry out an activity. This reason can be about benefits to the entity, or risks/harms to another entity. Where such benefits or risks/harms can be considered to be of 'vital interest', the legal basis VitalInterest should be used. Where this benefit or risks/harms pertains to the wider society or general public, the legal basis PublicInterest should be used. Legitimate interests can be associated with the controller, or data subject, or third party, or other entities. As good practice (and for their legality), the relevant entity must always be specified. We recommend using a relevant property such as dpv:hasDataController for data controller's legitimate interest to specify this. If a relevant property is not present in DPV, dpv:hasEntity can be used.
LegitimateInterestOfController represents a legitimate interest of the controller - such as carrying out dpv:FraudPreventionDetection. LegitimateInterestOfDataSubject represents a legitimate interest of the data subject - such as having a copy of the transaction (data or agreement) that it is providing or keeping their own records. LegitimateInterestOfThirdParty represents a legitimate interest of a third party - for example to investigate dpv:CounterTerrorism activities.
7. Official Authority of Controller
OfficialAuthorityOfController represents the legal basis where the official authority vested in the controller (by law) is used as the justification for carrying out activities. Such official authority is provided to specific departments to enable them to carry out their duties - such as maintainence of tax records, or provision of postal serviecs. The relevant law should be indicated as part of the legal basis if needed by using dpv:hasApplicableLaw.
8. Public Interest
PublicInterest represents activities carried out because they are 'in the interest of the general public' or are necessary to 'provide benefit to the public', where such benefit might be actual benefits (e.g. archiving data of cultural importance) or prevention of harms (e.g. identify relevant medical conditions quickly to prevent an outbreak). We strongly recommend providing a description of the relevant 'benefits' when using this legal basis e.g. by using dpv:hasJustification for contextual justifications associated with the benefit.
9. Protecting Vital Interests
VitalInterest represents activities that are necessary or required to protect vital interests of a data subject or other natural person. For more specific indication, VitalInterestOfNaturalPerson refers to vital interests of (any or a specific) natural person, and VitalInterestOfDataSubject represents vital interests of (any or a specific) data subject. As with PublicInterest and LegitimateInterest, we strongly recommend specifying relevant information - the vital interest in this case - by using dpv:hasJustification.
The state where the temporal or contextual validity of consent has 'expired'
Usage Note
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
The state where consent has been deemed to be invalid
Usage Note
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
State where a request for consent has been deferred without a decision
Usage Note
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
The state or status of 'consent' that provides information reflecting its operational status and validity for processing data
Usage Note
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
The state where the consent is withdrawn or revoked specifically by the data subject and which prevents it from being further used as a valid state
Usage Note
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
Creation, completion, fulfilment, or performance of a contract, with Data Controllers as parties being Joint Data Controllers, and involving specified processing of data or technologies
Creation, completion, fulfilment, or performance of a contract, with the Data Controller and Data Processor as parties, and involving specified processing of data or technologies
Creation, completion, fulfilment, or performance of a contract, with the Data Controller and Data Subject as parties, and involving specified processing of data or technologies
Consent that is expressed through an explicit action solely conveying a consenting decision
Usage Note
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
Consent that is expressed through an action intended to convey a consenting decision
Usage Note
Expressed consent requires the individual take a specific and unambiguous 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
Consent that is implied indirectly through an action not associated solely with conveying a consenting decision
Usage Note
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.
Date Created
2022-06-21
Contributors
Georg P. Krog, Harshvardhan J. Pandit, Paul Ryan, Julian Flake
Legal basis used to justify processing of data or use of technology in accordance with a law
Usage Note
Legal basis (plural: legal bases) are defined by legislations and regulations, whose applicability is usually restricted to specific jurisdictions which can be represented using dpv:hasJurisdiction or dpv:hasLaw. Legal basis can be used without such declarations, e.g. 'Consent', however their interpretation will require association with a law, e.g. 'EU GDPR'.
The state where a previously given consent has been 'renewed' or 'refreshed' or 'reaffirmed' to form a new instance of given consent
Usage Note
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
Creation, completion, fulfilment, or performance of a contract, with the Data Controller and Third Party as parties, and involving specified processing of data or technologies
DPV uses the following terms from [RDF] and [RDFS] with their defined meanings:
rdf:type to denote a concept is an instance of another concept
rdfs:Class to denote a concept is a Class or a category
rdfs:subClassOf to specify the concept is a subclass (subtype, sub-category, subset) of another concept
rdf:Property to denote a concept is a property or a relation
The following external concepts are re-used within DPV:
11. Contributors
The following people have contributed to this vocabulary. The names are ordered alphabetically. The affiliations are informative do not represent formal endorsements. Affiliations may be outdated. The list is generated automatically from the contributors listed for defined concepts.
Arthit Suriyawongkul (ADAPT Centre, Trinity College Dublin)
Axel Polleres (Vienna University of Economics and Business)
Beatriz Esteves (IDLab, IMEC, Ghent University)
Bud Bruegger (Unabhängige Landeszentrum für Datenschutz Schleswig-Holstein)
Damien Desfontaines ()
David Hickey (Dublin City University)
Delaram Golpayegani (ADAPT Centre, Trinity College Dublin)
Elmar Kiesling (Vienna University of Technology)
Fajar Ekaputra (Vienna University of Technology)
Georg P. Krog (Signatu AS)
Harshvardhan J. Pandit (ADAPT Centre, Dublin City University)
Javier Fernández (Vienna University of Economics and Business)
Julian Flake (University of Koblenz)
Mark Lizar (OpenConsent/Kantara Initiative)
Maya Borges ()
Paul Ryan (Uniphar PLC)
Piero Bonatti (Università di Napoli Federico II)
Rana Saniei (Universidad Politécnica de Madrid)
Rob Brennan (University College Dublin)
Rudy Jacob (Proximus)
Simon Steyskal (Siemens)
Steve Hickman ()
Funding Acknowledgements
Funding Sponsors
The DPVCG was established as part of the SPECIAL H2020 Project, which received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No. 731601 from 2017 to 2019.
Harshvardhan J. Pandit was funded to work on DPV from 2020 to 2022 by the Irish Research Council's Government of Ireland Postdoctoral Fellowship Grant#GOIPD/2020/790.
The ADAPT SFI Centre for Digital Media Technology is funded by Science Foundation Ireland through the SFI Research Centres Programme and is co-funded under the European Regional Development Fund (ERDF) through Grant#13/RC/2106 (2018 to 2020) and Grant#13/RC/2106_P2 (2021 onwards).
Funding Acknowledgements for Contributors
The contributions of Harshvardhan J. Pandit have been made with the financial support of Science Foundation Ireland under Grant Agreement No. 13/RC/2106_P2 at the ADAPT SFI Research Centre.
