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
harsh: 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
harsh: 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
harsh: 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
harsh: 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.