Meeting minutes
Meeting minutes: https://
purl for this meeting: https://
MAJOR Changes
The three issues will be implemented together as they represent major changes.
Non-personal data in scope
<ghurlbot> Issue 99 Proposal to change DPV scope to include Non-Personal Data (by coolharsh55) [scope] [concepts] [question]
No further comments have been made on the acceptance of this since the last meeting.
Repo restructuring
No further comments have been made on the acceptance of this since the last meeting.
<ghurlbot> Issue 107 Restructure repo layout (by coolharsh55) [documentation] [question]
RDFS/SKOS default serialisation
<ghurlbot> Issue 113 Make RDFS+SKOS the default serialisation, remove 'DPV/SKOS' concepts (by coolharsh55) [adoption] [documentation] [scope] [review]
No further comments have been made on the acceptance of this since the last meeting.
Categories of Data Subjects
<ghurlbot> Issue 116 Add Intended and Active Data Subject categories (by coolharsh55) [concepts] [question]
From the discussion on the mailing list, we have 6 concepts across 3 categories - Active/Passive, Intended/Unintended, and Informed/Uninformed. Question is whether these should be categories or statuses?
The group discussed, and agreed that these concepts are also useful for other concepts, such as Controllers, Processing, Recipients. Therefore, how to represent them efficiently is an open question.
The arguments made were - categories allow expressing something as a type and thus can be explicit e.g. Active Data Subject , whereas status allows indicating something contextually and can change e.g. Informed.
Both approaches have their uses, however it is unclear as to how these should be expressed e.g. using what relation? And whether using these as statuses requires complex uses such as blank nodes to indicate e.g. data subject is informed?
The group will deliberate on these questions and discuss this within the next meeting. Aim is to try out the different models and see what their pros and cons are for modelling this information.
Latest Consent State
<ghurlbot> Issue 90 Provide guidance for implementing ISO/IEC 27560 Consent Records using DPV (coolharsh55) documentation, use-case, application
work in progress is here - https://
<ghurlbot> Issue 114 In 27560-records, how to identify the latest consent state? #114 (coolharsh55) application, concepts, question, review
Question on how to point to the latest consent event or state i.e. how to quickly know whether consent has been given or not without requiring interpretation of the entire record. Option 3 was preferred in the last meeting.
Pat via GitHub issue has discussed provenance - the question being how to keep a record of all consent events, and then how to point to the latest consent status.
An option to indicate the latest state is use of sioc:latest_version - http://
Another option is to use dpv:hasRecord to store instances of ConsentStatus with timestamps and other information, and to then use hasConsentStatus to indicate the latest status. The issue with this is that the record cannot be immutable or append-only as the consent status would have to be updated with every iteration.
After discussion, the group agrees that it is best left to implementation for storing the latest consent state, and that 27560 itself does not have a field for the 'latest consent state' - if no suitable options are found.
Next Meeting
The next meeting will be in 1 week on WED OCT-18 15:00 WEST / 16:00 CEST. Agenda includes discussions on: 1) Data Subject categories (now extended to other concepts); 2) Automation and Human Involvement concepts (w3c/