Meeting minutes
*Minutes from last call* => https://
Data Sources and Processing
As discussed in the last meeting, we have proposals for expanding the `DataSource` concept with `PublicDataSource` and `NonPublicDataSource` for indicating when data is obtained from a public source - which has implications on its use and justifications.
The previous discussions also brought up the issue of what is meant by /Public/ data source, and how it relates to availability of data, its /open/-ness, and whether the term is tied to permissible reuse e.g. /licenses/.
For now, we model these terms as high-level abstract concepts in order to provide the ability to indicate whether data is obtained from a /public source/ or otherwise. We invite more nuanced specialisations based on topics of open-ness, reusability, access, and licenses, with preference for authoritative definitions.
Concepts accepted for addition => `PublicDataSource`, `NonPublicDataSource` as sub-classes of `DataSource`.
The previous discussion regarding ISO/IEC 29184:2020 providing data sources as four conditions - direct from data subject, indirect from third party, observed, and inferred can be represented in DPV as follows.
For /Direct/, the `DataSubject` is specified as the data source.
For /Indirect/, the applicable `DataController` or `ThirdParty` is indicated as the data source.
For /observed/, the `DataSubject` or existing data (or entity holding it) is the source, and the /observe/ as a process is depicted using `Processing`.
For /inferred/, similar to /observed/, the `DataSubject` or existing data (or entity) is the source, and the /infer/ is depicted using `Processing`.
---
beatriz: In PROTECT, we are looking at modelling data sources and roles of data co-operatives. How would these be represented or modelled using DPV?
harsh: The term /data co-operative/ is not well defined in terms of law or process. For example, it could include an organisation collecting and holding the data, and sharing it with a controller or third party. It could also be an organisation acting as the middle-party or negotiator between data subject and data controller where the data is directly collected from Data Subject.
harsh: Until such roles are clarified in terms of roles under GDPR (e.g. Data Controller or Third Party), data co-operatives are difficult to model without specific use-cases.
Automated Processing
We have properties in processing section regarding `hasAlgorithmicLogic`, `hasHumanInvolvement`, and `hasConsequence` which were added based on GDPR's impact assessment criterias.
At the time, we indicated the use-case can specify the value of these as needed.
The proposal right now is to add corresponding concepts to provide a better way to represent information related to these properties i.e. their /range/.
The concepts are - `AlgorithmicLogicOfProcessing`, `ConsequenceOfProcessing`, `HumanInvolvement`
There is a concept for representing algorithmic decision making (as `AutomatedDecisionMaking`), which could be related to `AlgorithmicLogicOfProcessing` as follows - the actuall process of decision making is represented using `AutomatedDecisionMaking` and the explanation or logic of how it is implemented is depicted using `hasAlgorithmicLogic AlgorithmicLogic`.
Concepts are accepted for addition.
Data Processing Agreement
Proposal to add concept `DataProcessingAgreement` representing a generic agreement regarding processing of personal data as an organisational measure.
Specific categories of such agreements include `DataProcessorAgreement`, `JointDataControllersAgreement`.
The terms /DataProcessingAgreement/ and /DataProcessorAgreement/ can be confusing as they are often used interchangeably. For this, /DataProcessingAgreement/ is renamed to /ControllerProcessorAgreement/ to better reflect its purpose and function.
Similarly, an agreement for /Processor/ to /SubProcessor/ relations is added as well.
---
Discussion on whether these concepts should be in /LegalBasis/ took place, and was concluded with keeping them in organisational measure.
This is because these may not always constitute as a legal basis, and where they are used as a legal basis, they can be indicated using `hasLegalBasis DataProcessingAgreement` as needed.
---
Concepts accepted for addition => `DataProcessingAgreement` with subclasses `ControllerProcessorAgreement`, `SubProcessorAgreement`, `JointDataControllersAgreement`
Implementation Details
DPV has the property `isImplementedBy` to indicate how something is implemented i.e. the technology
Proposal to expand this definition to include methods, processes, entities, and agents so that it can also be indicated similarly.
beatriz: Instead of a single property, there can be two properties - one for entity and another one for technology
Concepts accepted for addition => `isImplementedByEntity` and `isImplementedUsingTechnology`
Here the labels also assist in ensuring the property is used to indicate entities and technologies respectively.
julian: Does the term /technology/ also include processes which are not technologies e.g. business processes?
harsh: The term /technology/ is quite broad, and includes what we think of as tools or software, but also methods and processes. So this use is fine.
harsh: Similarly, for entities we also include agents in the description of the property so as to enable /agents/ when needed to be specified either legally or technically.
---
Proposal to add properties `hasPolicy` and `isPolicyFor` as inverse relations for indicating policies applicable or applied, which is a common use-case
The property `hasPolicy` is a sub-property of `dpv:hasTechnicalOrganisationalMeasure`, and offers a more convenient method to specify policies being applied.
Concepts accepted for addition.
---
julian: Similar to policies, how to indicate what the technical or organisational measure is applied to achieve? For example, some legal obligation requiring something to be implemented.
julian: Proposal for relation `isRequiredFor` to indicate what a measure is required for (or why it is implemented)
harsh: This is taking us into modelling legal compliance and fulfilment of obligations and criterias. This can get quite complex and quickly include trying to model norms.
Concept is listed for future discussion.
---
Concept `Technology` has been previously proposed for inclusion, and is accepted for addition based on necessity to representing information corresponding to property `isImplementedUsingTechnology`.
For specific taxonomy of different kinds of /technologies/, a list from prior minutes and discussions includes - /database/, /server/, /cookies/, /device/, /algorithm/.
Upon discussion of these, the group has decided to first collect concepts and then to structure them to ensure suitable hierarchy is present, similar to how other concepts have their top-down hierarchies.
Such a /technology/ list could be provided directly in DPV or through an extension (e.g. /dpv-tech/).
Discussion on how /Technology/ differs from /TechnicalOrganisationalMeasure/, for example /AccessControl/ is a technical measure, but could also be a technology, e.g. ID cards.
To distinguish between these, we say that the technical measure provides a category of application (e.g. access control) but the technology provides concrete implementations (e.g. ID cards with photos or fingerprint scanner).
Thus, we have technical measure detailing the purpose of applying a technology.
This also assists in maintaining documentation of technological changes (e.g. different software vendors or versions) for the same measures.
Next DPV iteration
We currently have the option of producing the next iteration of DPV (v0.4) or waiting 2-3 weeks whilst the OWL / SKOS discussion happens.
Based on this, we either provide DPV v0.4 as an OWL vocab (as it is currently) or as a OWL+SKOS vocab.
As this includes a significant amount of work in producing the serialisations, specification, and documentation, we will wait until 9FEB for comments on OWL+SKOS.
We currently have ~5 supporting votes for SKOS, with no dissenting opinions on mailing list or otherwise. There has been a discussion previously on this topic without conclusion.
If we hear no objections by FEB-09, then we schedule DPV v0.4 to be provided as OWL+SKOS. Otherwise as OWL vocab.
---
We will have the next meeting on WED FEB-02 13:00 WET / 14:00 CEST.
We will continue discussion on proposed topics and an agenda will be circulated on MON JAN-31.