W3C

– DRAFT –
DPVCG Meeting Call

15 JUN 2022

Attendees

Present
georg, harsh, paul
Regrets
beatriz
Chair
harsh
Scribe
harsh

Meeting minutes

Previous minutes

DPV Technology extension

In the previous meeting we discussed the technology concepts. Since then there have been no further comments on them, there we consider an agreement has been reached and accept them for inclusion in the next iteration of DPV.

The extension will be published with the namespace https://w3id.org/dpv/dpv-tech# and prefix dpv-tech

Discussion of DPIA concepts to be added to (main) DPV

The concept `Scope` and relation `hasScope` enables expression of information related to determination or indication of scope within some context.

The use of /Scope/ as a concept is important in assessments and investigations and can relate to many things - such as notion of compliance, processing operations, data subject rights, etc.

*Frequency*

DPV currently has the concept `dpv:Frequency` which has been expanded to indicate some commonly utilised frequencies as `ContinousFrequency`, `OftenFrequency`, `SporadicFrequency`, `SingularFrequency`

*Duration*

Similar to frequency, the following commonly used durations are provided - `EndlessDuration`, `TemporalDuration`, `UntilEventDuration`, `UntilTimeDuration`, `FixedOccurencesDuration`

The specifics of these, such as temporal or until-time can be expressed as required, e.g. using the TIME ontology

*Justification*

Often times a note or textual description or documentation of statement is required alongside descriptions of processing operations as the "justification" for why something is done or not done in a particular way. Examples of this include Register of Processing activities and DPIAs

By providing this concept within DPV, the justifications can be associated with specific concepts or graphs as necessary or required.

The relation `hasJustification` provides this capability.

*Processing*

Additional processing operations have been added as follows

`Access` and `Assess` as subtypes of `Use`

`Filter` as subtype of `Transform`

`Monitor` and `Query` as subtype of `Consult`

`Observe` as subtype of `Obtain` and `Screen` as subtype of `Transform`

These operations were relevant in the DPIA documents and investigations (e.g. EDPB guidelines) and therefore represent information to be represented as part of DPV.

*Automation of/in Processing*

DPV has the concept `AutomatedDecisionMaking` which is important because of the obligations and risks it carries.

However, this is not detailed enough to represent where the automation happens, or how humans are involved. The concept `HumanInvolvement` and `hasHumanInvolvement` were created to assist with specifying how humans are involved, but this still did not capture the specifics of automated processing present in real-world uses and guidelines.

For this reason, the concept `AutomationOfProcessing` is created as the top concept for any automation, and is itself a subtype of `ProcessingContext`

Its specialisations include `AutomatedDecisionMaking`, and additionally specific concepts referring to human involvement with specific roles as `FullyAutomatedProcessing`, `AutomatedProcessingWithHumanVerification`, `AutomatedProcessingWithHumanOversight`, `AutomatedProcessingWithHumanInput`, `PartiallyAutomatedProcessing`, `CompletelyManualProcessing`

*Scale of Data, Data Subjects, and Processing*

The concept `Scale` refers to some (qualitative in this case) measurement or indication of metrics. Note the relevance to earlier concept `Scope` in terms of similarity, where scope is a much broader concept that encompasses scale but can also include other aspects such as conditionality or possibilities or plans.

To keep this ambiguity about the two concepts to a minimum, all general questions about scope in terms of scale of data (volume), data subjects, or its geographic converage are considered as scales instead, with scope retained for provided details other than these as relevant.

The concepts `DataVolume`, `DataSubjectScale`, and `GeographicCoverage` are the three subtypes or scales.

`DataVolumeScale` and `DataSubjectScale` are further refined with concepts using the prefix /Huge/, /Large/, /Medium/, /Small/, /Sporadic/, and /Singular/ to refer to scales from highest or largest value to smallest or lowest.

The prefix /Massive/ was removed due to not being specific enough as compared to /Huge/ and /Large/.

Legal obligations relate specifically to /Large/ scale and the other concepts have been created to balance expression of things that are not large scale.

The resulting concepts represent the specific scales of their type, for example `LargeDataVolume` refers to amount of data that is considered large within that context, and similar `LargeScaleOfDataSubjects` refers to amount of data subjects that is considered large scale within that context.

The concept `GeographicCoverage` refers to scale (e.g. processing) in terms of geographic areas it covers or relates to. Specific concepts for this are `GlobalScale`, `NearlyGlobalScale`, `MultiNationalScale`, `NationalScale`, `RegionalScale`, `LocalityScale`, `LocalEnvironmentScale` (from largest to narrowest).

The single relation `hasScale` is to be used to indicate any of these types of scales.

*Location*

DPV provides a way to express locations using `Location` and `hasLocation`. This is not to be confused with `GeographicCoverage` as one relates to specifics whereas the other relates to scales.

For further specifying the exactness of location in additional details, the following concepts are provided -

`LocationFixture` refers to the state of that location being /fixed/, with specific types of fixtures provided as `FixedLocation`, `FixedSingularLocation`, `FixedMultipleLocations`, `VariableLocation`, `FederatedLocations`, `DecentralisedLocations`, `RandomLocation`

These are useful to more accurately specify things such as locations where personal data will be stored, for example by creating an instance of decentralised storage as the fixture with multiple specific locations

`LocationLocality` refers to the state of that location being /local/ in the technical sense, such as whether it is on a device or on a server somewhere remote

This information is relevant for accurately specifying whether some processing takes place locally or remotely, for example

Concepts for this are `LocalLocation`, `RemoteLocation`, `WithinDevice`, `CloudLocation`, `ServerLocation`, `ServerlessLocation`

The location concepts also provide a connecting point with the Technology extension for expressing additional information

*Other concepts*

Other concepts to be added include -

`MaintainCreditCheckingDatabase`, `MaintainCreditRatingDatabase`, `MaintainFraudDatabase` as specific purposes related to credit checking and fraud prevention

Personal data categories for `UserAgent`, `Identifier`, `DigitalFingerprint`, `PerformanceAtWork`, `FinancialStatus`, `Reliability`, `Profile`, `WorkEnvironment`, `BrowserHistory`, `VehicleData`, `VehicleUsageData`, `VehicleLicense`, `VehicalLicenseNumber`, `VehicalLicenseRegistration`, `FacialPrint`, `PersonalDocuments`, `HouseholdData`, `SocialMediaData`, `PubliclyAvailableSocialMediaData`

Tech/org measures `ConsultationWithDPO`, `ConsultationWithDataSubject`, `CredentialManagement`, `DataBackupProtocols`, `PhysicalAccessControlMethod`

Data subject categories `MentallyVulnerableDataSubject`, `AsylumSeeker`, `ElderlyDataSubject`

Next Meeting

We will meet again next week, WED 22 JUN 14:00 CEST

Topic will be going over pending proposals for rights, rules, and associating ISO standards with DPV concepts

Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).

Diagnostics

Succeeded: s/Within/Local/