Context

This document assumes the reader is familiar with DPV through the Primer for Data Privacy Vocabulary, and thus focuses on providing a topically structured documentation of concepts defined by DPV.

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.
• FixedOccurrencesDuration - a duration that is based on number of Occurrences, e.g. until you view it 3 times
• EndlessDuration - indicating a duration without an end condition or temporal notation.

Frequency indicates how frequently something occurs. Statistically, this can be expressed as the combination of number of Occurrences and a time period, which can further be expressed as a probabilitic value or a percentage. For example, for something occuring once every year, the frequency is: 1 or 100% for 1 year. While such quantified representations are important for determining metrics and performing operations, DPV focuses on the qualitative labelling of such representations within a specific context.

The relation hasFrequency associates a frequency with a context, and can be expressed using the following subtypes:

• ContinuousFrequency - indicates things occuring Continuously, e.g. location collection happens Continuously.
• SporadicFrequency - indicates things occuring sporadically or rarely or not often, e.g. collecting system usage logs every month.
• OftenFrequency - indicates things happen often or regularly or commonly, e.g. online status is reported every 5 mins.
• SingularFrequency - indicates things happen only once.

DPV provides two subtypes of concepts to denote contextual - Importance and Necessity, which can be applied to specific contexts such as dpv:Process, dpv:Purpose, dpv:PersonalData.

Necessity enables specifying whether the contextual information is Required, is Optional, or is NotRequired. These can be used to indicate, for example, which parts of processing operations (e.g. purposes, personal data) are optional, and whether a particular processing operation is required to be carried out.

Importance is similar in application to Necessity, and provides a way to indicate how central or significant the indicated operation(s) are to the context (e.g. to the Controller). Subtypes of importance are PrimaryImportance to indicate 'main' or 'central' or 'primary' importance, and SecondaryImportance to indicate 'auxiliary' or 'peripheral' or 'secondary' importance.

Scope, associated using the relation hasScope, indicates the extent or range or boundaries associated with(in) a context. For example, where processing only takes place for a specific service or within a jurisdictional framework.

Justification enables providing a reason or 'justification' within the context. For example, why a particular activity is taking place, or for when a request could not be fulfilled - such as when exercising a right. Justifications can be indicated using the hasJustification relation. The Concepts representing Justifications for DPV extension provides a taxonomy of such justifications based on practical use-cases and requirements. (examples for justifications are provided with status concepts later in this document)

Applicability concepts enable expressing conditions where the information is not available, or is not applicable, or it is unknown. The concepts provided to represent these are: NotApplicable, NotAvailable, and UnknownApplicability. These concepts are useful for 'closed world' interpretations where information _must_ be provided e.g. when filling out a form a human may write "N/A" in the text field instead of providing the requested information.

To assist with expressing the state or status associated with various activities, DPV provides the Status concept that can be associated contextually using the hasStatus relation. Types of statuses included in DPV are: ActivityStatus, ComplianceStatus including Lawfulness, AuditStatus, ConformanceStatus, RequestStatus, EntityInformedStatus, IntentionStatus, ExpectationStatus, InvolvementStatus, and NotificationStatus. The corresponding relations provided are: hasActivityStatus, hasComplianceStatus, hasLawfulness, hasAuditStatus, hasConformanceStatus, hasRequestStatus, hasInformedStatus, hasIntention, hasExpectation, hasInvolvement, and hasNotificationStatus.

ActivityStatus represents a state or status of an activity's operations and lifecycle, which includes ActivityProposed, ActivityOngoing, ActivityHalted, ActivityCompleted, and ActivityNotCompleted. These are associated using the hasActivityStatus relation. Here, the concept 'Activity' is broadly defined and can refer to a process, a processing operation, or any other type of activity.

ComplianceStatus represents status associated with compliance with some norms, objectives, or requirements. Types include Compliant, PartiallyCompliant, NonCompliant, ComplianceViolation, ComplianceUnknown, ComplianceIndeterminate. These are indicated using the hasComplianceStatus relation. The association with a law or objective can be specified using hasApplicableLaw or hasPolicy directly for the status or indirectly through the concept whose status is being represented.

Lawfulness represents a special type of ComplianceStatus which relates to legal compliance, or lawfulness, and has types Lawful, Unlawful, and LawfulnessUnkown. It is indicated with the relation hasLawfulness. When using status associated with laws, we recommend using compliance status to refer to whether the specific activities being considered are according to the requirements of law, and lawfulness to refer to the overall nature of the activity being lawful or unlawful. Note that non-compliance may not necessary lead to unlawfulness e.g. there are exceptions or additional obligations to be carried out for non-compliance within the framework of the law.

AuditStatus represents the state or status of an audit, where the term audit is loosely defined, and may or may not relate to legal compliance - for e.g. for impact assessments, or as part of certification, or to assess compliance (in combination with above), or for organisational quality assurance processes. Types of audits include AuditApproved, AuditConditionallyApproved, AuditRejected, AuditRequested, AuditNotRequired, and AuditRequired. The audit status is indicated by using the relation hasAuditStatus.

ConformanceStatus represents the status of conformance, which is defined distinctly from compliance by considering voluntary association or following of a guideline, requirement, standard, or policy, and where compliance is related to the (legal or other systematically defined) conformity of a given system or use-case with rules which may dictate obligations and prohibitions that must be followed. To provide an illustrative example, consider conformance with a standard on best practices regarding security may assist in the demonstration of compliance with a legal norm requiring organisational measures of security. Types of conformance defined are: Conformant and NonConformant.

RequestStatus represents the state or status of requests, which can be between entities such as data subjects and controllers regarding exercising of rights, or between controllers and processors regarding processing operations, or between authorities and controllers regarding compliance related communications. Types of request statues are: RequestInitiated, RequestAcknowledged, RequestAccepted, RequestRejected, RequestFulfilled, RequestUnfulfilled, RequestRequiresAction, RequestRequiredActionPerformed, RequestActionDelayed, and RequestStatusQuery.

To represent location, the concept Location along with relations hasLocation is provided. For geo-political locations, the concepts such as Country and SupraNationalUnion are subtyped, with hasCountry and ThirdCountry with hasThirdCountry provided for convenience in common uses (e.g. data storage, transfers).

To define contextual location concepts, such as there being several locations, or that the location is 'local' to an event, DPV provides two concepts. LocationFixture specifies whether the location is 'fixed' or 'deterministic', and is extended with concepts FixedLocation, FederatedLocations, DecentralisedLocations, RandomLocation, and VariableLocation. LocationLocality specifies whether the location is 'local' within the context, and is extended as LocalLocation and RemoteLocation. Local locations provided include PrivateLocation, PublicLocation, WithinDevice, WithinPhysicalEnvironment, and WithinVirtualEnvironment. Remote location is extended to represent CloudLocation.

To represent locations as jurisdictions, the relation hasJurisdiction is provided. The concept Law represents an official or authoritative law or regulation created by a government or an authority. To indicate applicability of laws within a jurisdiction, the relation hasApplicableLaw is provided.

Legal Jurisdiction-relevant concepts for DPV provides taxonomies extending these concepts, such as to represent specific countries, their laws, authorities, memberships, adequacy decisions, and other information.