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.

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 further information, please see the contribution section.

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

Relevant Concepts: dpv:Concept

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

Relevant Concepts: dpv:Concept

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

Relevant Concepts: dpv:Concept

U4: Tagging personal data categories present in digital resources

Digital resources, e.g., resources stored in Solid pods, might contain multiple types of personal data categories, including sensitive personal data categories. For instance, in the Solid ecossystem, tagging the resources, or their metadata, with the personal data categories they contain will assist in the matching of personal data categories and the access control policies expressed for those particular categories of data.

Relevant Concepts: dpv:PersonalData

U5: Access control policies

DPV can be used to define access control policies over digital resources, independently or together with other languages, e.g., ODRL.

Relevant Concepts: dpv:Entity, dpv:LegalBasis, dpv:PersonalData, dpv:Processing, dpv:Purpose, dpv:TechnicalOrganisationalMeasure


R1: Dummy Requirement

This requirement does not entail anything

Motivation: U1

Relevant Concepts: dpv:Concept, dpv:Relation

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

Relevant Concepts: dpv:Concept, dpv:Relation

Concept Mappings