This document lists the use-cases and requirements that motivate the development and provision of resources within the [[[DPVCG]]]. Specifically, it lists the background information that feeds into the continued development of the [[[DPV]]] and its associated resources. It draws inspiration (and methodology) from [[[SHACL-UseCases]]]. The vocabulary, and instances of use-cases and requirements are available in DPVCG GitHub repo under ./use-cases path.

Call for Comments/Feedbacks for DPV v1.0 release

Please provide your comments by 15-OCT-2022 via GitHub or [email protected] (mailing list).

While v0.8.1 is a regular 0.x style release, it also acts as the v1.0 release candidate. This means if there are no major issues raised and unable to be resolved, including missing parts, errors or bugs, or requirements that must be added, then after 15-OCT-2022, this version will be re-released as DPV v1.0 along with any further enhancements, fixes, minor additions, or documentations that have been developed until then.

DPV Family of Documents

Related Links

This document is published by the Data Privacy Vocabularies and Controls Community Group (DPVCG) as a deliverable and report of its work in creating and maintaining the Data Privacy Vocabulary (DPV).

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 contributions to the DPV, please see the section on GitHub. The current list of open issues and their discussions to date can be found at GitHub issues.

The namespaces used in this document are as follows:

: <<>



skos:definitionAn UseCase provides a description where information within the scope of DPVCG is expected to be relevant or applied, and acts as the basis for identifying requirements (including but not limited to creation of concepts). Use cases can contain descriptions of systems, their operations, actors and entities involved, restrictions or constraints, or any other pertinent detail. They can be a simple textual paragraph or elaborative structured documents (in which case we prefer to reference them here as an URL).
  1. An UseCase MUST have a title (provided using dct:title)
  2. An UseCase MUST have a description (provided using dct:description)
  3. An UseCase MUST have an identifier with prefix 'U' (provided using dct:identifier)
  4. An UseCase MAY have one or more contributors (specified using dct:contributor)
  5. An UseCase MAY have a date (e.g. creation or modification) (specified using dct:date)
  6. An UseCase MAY specify the source of its information (using dct:source)
  7. An UseCase MAY specify its primary subject or concept (using dct:subject)
  8. An UseCase MAY specify relevant requirements derived from it (using dct:references)


skos:definitionA Requirement is a functional or non-functional requirement desirable to provided by or implemented within DPVCG's outputs, primarily the DPV and its extensions. Requirements can relate to the design of the resource, specific concepts and relations within it, provision of a resource and its documentation, or any other pertinent usage or behaviour exhibited by resources developed within the scope of the DPVCG.
  1. A Requirement MUST have a title (provided using dct:title)
  2. A Requirement MUST have a description (provided using dct:description)
  3. A Requirement MUST have an identifier with prefix 'R' (provided using dct:identifier)
  4. A Requirement MUST specify the relevant UseCases used to derive it (using dct:references)
  5. A Requirement MAY have one or more contributors specified (using dct:contributor)
  6. A Requirement MAY specify the source of its information (using dct:source)
  7. A Requirement MAY specify its primary subject or concept (using dct:subject)

Use Cases

U1: Example - An Information Title

Description of the use-case - a short summary of what/who/how/where/when etc. goes here. This can be as detailed as you want.

Related Requirements: R1

U2: Example #2 Dictionary of Concepts

There are a vast number of concepts associated with data processing, with differences and variations across jurisdictions, domains, and sectors. A common dictionary of concepts with information on how they relate to other concepts across such differences would be an invaluable resource on its own. This could be a simple list, a dictionary, or a thesauri.

Related Requirements: R2

U3: Example Automating DPVCG usage

The concepts associated with a particular task can be considered the vocabulary necessary for representing information for that particular task. For example choosing the appropriate legal basis requires the concept associated with legal basis as well as the specific legal bases that can be utilised. In order to assist in providing the appropriate contextual vocabulary, the concepts should be encoded in a form that can be automatically queried or retrieved depending on the context.

Related Requirements: R2, R3


R1: Dummy Requirement

This requirement does not entail anything

Motivation: U1

R2: Provide concepts in standardised, consistent, machine-readable form

The encapsulation of concepts must be in a form that is machine-readable, consistent, and using a formal specification - ideally a standard. This will ensure the concepts are correctly parsed, interpreted, and used by machines across use-cases, and will assist in the automation of information and information-based tasks.

Motivation: U2, U3

Relevant Concepts: dpv:Concept, dpv:Relation

R3: Provide concepts as a dictionary or thesauri with contextual parts

The concepts should be bundled together and provided as a vocabulary or thesauri with distinct parts or sections (or sub-vocabularies) that relate to specific contextual details. For example, providing purposes as a separate taxonomy enables use of only purposes elsewhere.

Motivation: U3

Concept Mappings