Add `Intended` and `Active` Data Subject categories about dpv HOT 8 CLOSED

Interesting concepts.

My comment thought is completely tangential(!) - but this seems a great example of why I try to 'left-justify' names of things generally. I'd rename all these terms as:

• DataSubjectIntended
• DataSubjectUnintended
• DataSubjectActive
• DataSubjectPassive

There are two main reasons I've been doing this for decades:

1. Related topics naturally sort together alphabetically (so they appear together in lists, or table-of-contents, or drop-down listboxes, etc.).
2. Code-completion editors (like IntelliJ, Eclipse, VSCode, etc.) can automatically show options as a developer types.So as I type 'DataSubj' (since I 'know' I want some category of 'DataSubject'), the editor will show me all my above options without me having to remember all the various sub-categories of DataSubject. Otherwise, I have to know in advance I mean 'IntendedDataSubject' and so I need to start typing 'Inten' before the IDE offers code-completion, but it can only offer me one choice!

from dpv.

Good points, I think going ahead DPV should use the concept-as-prefix style where possible. Existing concepts that don't follow this structure will stay as they are e.g. TemporalDuration.

from dpv.

Copying discussion summary from mailing list:

• Statuses: Intended / Unintended and Active / Passive
• Categories: Informed / Uninformed

(EDIT) concepts also applicable for Controllers, question on whether to use the same concepts or create different set - see mailing list

from dpv.

Discussed in meeting 11 OCT that this can be modelled as categories or as statuses - but their use is different. Also that the categories are broader and can be useful for other contexts e.g. Controllers, Processing, Recipients. To better understand how these concepts should be provided, the next meeting on 18 OCT will discuss examples and different models.

from dpv.

Summarising concepts based on thread https://lists.w3.org/Archives/Public/public-dpvcg/2023Oct/0018.html

Requirements: indicate whether an entity has active or passive or no involvement in the processing activities, where active involvement means the entity actively performs or participates in the processing e.g. a controller decides how processing is to be done, a processor performs the actual processing; and where passive involvement means the entity is passive in processing i.e. not actively involved. The definitions of 'active' and 'passive' are vague, and require interpreation in jurisdictional contexts.

• hasInvolvement Involvement (also see #108)
• hasActiveInvolvement EntityActivelyInvolved
• hasPassiveInvolvement EntityPassivelyInvolved
• hasNoInvolvement EntityNotInvolved

Requirement: indicate which entity 'determines' how the processing should be conducted or performed, where 'determination' includes determination of purpose, data, technologies, durations, etc. The definition of 'determination' is vague, and requires interpretation in jurisdictional contexts.

• isDeterminedByEntity Entity

This is too vague and confusing - what can active mean? what can passive mean? How does this work with isImplementedByEntity? Solution: isImplementedByEntity indicates which entity is specifically performing or 'implementing' the processing. isDeterminedBy means decision making - who decides. Active/Passive involvement means after determination who participates in the processing. The implementing entity will always have active participation, but other entities may also be actively involved e.g. to provide inputs as data subjects.

Requirement: indicate whether a data subject has an active or passive involvement in the processing activities, where active involvement means the data subject actively participates in the processing e.g. by providing the data in a filled out form; and where passive involvement means the data subject is passive in the processing e.g. by walking within a CCTV monitored zone.

• hasActiveDataSubject DataSubjectActivelyInvovled
• hasPassiveDataSubject DataSubjectPassivelyInvolved

Requirement: indicate whether an entity has been informed or is uninformed regarding the specific activites/context. (no changes from previous proposal)

• EntityInformedStatus: The status of the indicated entity being
  informed of the context.
• EntityInformed: The state of the entity being informed of the context.
• EntityUninformed: The state of the entity being informed of the
  context.

Specific variations for entities being informed or uninformed which are useful in legal context e.g. to indicate whether notice was provided, or a breach was reported

• DataSubjectInformed: The state of the data subject being informed
  of the context.
• DataSubjectUninformed: The state of the data subject being
  informed of the context.
• ControllerInformed: The state of the controller being informed of
  the context.
• ControllerUninformed: The state of the controller being informed
  of the context.
• RecipientInformed: The state of the recipient being informed of
  the context.
• RecipientUninformed: The state of the recipient being informed of
  the context.
• AuthorityInformed: The state of the authority being informed of
  the context.
• AuthorityUninformed: The state of the authority being informed of
  the context.

Requirement: indicate whether the specific activities/context were intended e.g. persons who were intended to be data subjects, data that was intended to be collected, or unintended e.g. persons who were not intended to be data subjects but whose data was collected, or data that was not supposed to be collected has been. Intent is an aspect of the entity implementing or determining the activities. (no changes from previous proposal)

• IntentionStatus: the status of whether the specified context
  is/was intended or unintended
• StatusIntended: the state where the specified context is/was
  intended to occur
• StatusUnintended: the state where the specified context is/was not
  intended to occur

Requirement: indicate whether the specific activities/context were expected e.g. data that was supposed to be collected has been collected, or unintended e.g. data that was not supposed to be collected has been. Expectation is an aspect of the entity not involved in implementing or determining the activities. (no changes from previous proposal)

• ExpecationStatus: the status of whether the specified context
  is/was expected or within expecations.
• StatusExpected: the state where the specified context is/was
  expected to occur or is/was within expectations
• StatusUnexpected: the state where the specified context is/was not
  expected to occur is/was not within expectations

from dpv.

Intention and Expectation are closely related terms (close synonyms, very easy to use interchangeably). Intend would mean there is a plan or process to make it happen. Expect means we are focusing on something happening without necessarily having a plan or process to do it. So I suggest we use Intention when the entity has the ability to control the implementation and Expectation for when the entity does not have control or for what happens after or beyond the exercise of control.

Example:

1. Controller intends for some data to be collected i.e. it has the ability to do this. Here saying controller expects for some data to be collected would imply that it is expecting someone else to do the collection or that there is a condition that it doesn't control for when the expectation would materialise.
2. Data Subject intends to provide some data - whereas data subject expects some data to be collected (by controller). If we instead say data subject expects to provide some data it means it is not controlled by the data subject and that provision of data will be triggered by something else (e.g. a service operation).

from dpv.

@DelaramGlp could you please check whether the above makes sense for your use-cases?

from dpv.

Discussed with Delaram, and agreed on the following:

• keep hasActiveDataSubject and hasPassiveDataSubject as proposed - pending clarity on where they would be useful in the future
• intent and expectation are to be provided as statuses (discuss whether this makes sense as compared to e.g. IntendedProcess
• other terms are okay to go ahead with

from dpv.