Closed GeertThijs closed 2 years ago
Simplified class diagram to illustrate the proposed solution:
To maintain a maximal granularity when referring to the personal data, the PersonalData class is changed to a metaclass. This means that the metaclass PersonalData can be any class that is personal data. This was shown and approved in the 4rd thematic workshop.
Description OSLO::PersonalData is based on GConsent::PersonalData. In OSLO it is modeled as a regular class, meant to describe the category and type (and even the format) of PersonalData. In GConsent however this class is a metaclass, its a class of classes ie the class of all possible classes of PersonalData. An instance of this class is a class description, eg of the class Accountinfo. It has attributes and associations, everything a real class has. This phenomenon, that the same data-element can be a class (Accountinfo) and an instance of a class (of the class PersonalData) is called "punning". Advantage in this case is that at the same time you say what type of PersonalData you are dealing with and you describe the actual details of the class (for Accountinfo eg name, contactinfo, registration number... ). Disadvantage is that maybe you do not have such a description (but you will at least always have a definition and some other info if you resolve the uri of the concept). Worth mentioning is that how OSLO describes PersonalData resembles more the way DPV does it: DPV::PersonalDataHandling has an attribute hasPersonalDataCategory to describe what kind of PersonalData that will be processed. So both methods could be made available to describe PersonalData by also adding the attribute hasPersonalDataCategory to PersonalDataHandling and at the same time staying with the metaclass approach for PersonalData.
Solution Make Personaldata a metaclass + add the attribute hasPersonalDataCategory to PersonalDataHandling.