TR-Model. A Metadata Profile Application for Personal Data Transparency

People’s usage of social networks, mobile applications, websites, sensor networks and other computer systems leads to a massive production of personal data about their behaviors and preferences. Personal data are used by organizations in business and marketing tasks. However, details about personal data usage are often not accessible or clear to data subject, raising concerns about privacy and security. Presentation of information about personal data usage needs improvement towards Personal Data Transparency. Thus, this paper aims to present the TR-Model, a Metadata Application Profile guideline that intends to propose a standardization on information to be considered minimally necessary to Personal Data Transparency as well as a set of specifications to guide developers on how to present this data. TR-Model elements are focused providing Personal Data Transparency in a user-friendly and high quality format. TR-Model presents a set of specification based on entities, metadata, metaevents and descriptions. The model evaluation was based on user testing in several scenarios of usage of personal data in a gym application tool. The information presented was created based on the TR-Model metadata, metaevents and descriptions. Participants evaluated transparency considering dimensions of Human-Computer Interaction and Information Quality. Participants’ opinions were recorded in surveys and analyzed with descriptive statistics; the results indicate that the TR-Model was effective in supporting the production of friendly, understandable and relevant Transparency for data subjects, in compliance with regulations like GDPR.


I. INTRODUCTION
The use of Personal Data produced as a result of interaction between people and hardware/software resources has become common practice [1]. According to General Data Protection Regulation (GDPR) [2], Personal Data are any information relating to an identified or identifiable natural person ('data subject '). An identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as name, identification number, location data, online identifier or one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.
The associate editor coordinating the review of this manuscript and approving it for publication was You Yang .
The interest in Personal Data had increased significantly as the use of social media and mobile applications based on the internet had grown significantly the last few years [3], [4]. So, the use of technological resources is responsible for data generation that, some how, reflect the behavior, preferences or data subject' features. Examples include: being part of a community on a social network can tell about a person's interest in a particular subject; the repeated e-commerce portals access may indicate the desire for buying specific products; or even the use of credit card in a region or type of commerce may define buying interests and profiles [5], [6].
Many companies monetize Personal Data as they can provide important insights about existing ad potential consumers [1]. These insights can be used by companies to obtain advantages for increasing financial gains such as: (1) understand the data subjects' profiles; (2) know / understand routine behaviors; and (3) process text messages to obtain a strategic information for a purpose.
These actions (among many others) are carried out even if, sometimes, they are done without data subject's knowledge and / or prior authorization; this may cause concerns about privacy, freedom and security of the data subject's personal life [5], [7], [8]. According to the GDPR, Art. 4, Alinea 1, Data Subject is an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.
The abusive and unauthorized use of Personal Data is already a reality and is discussed by [9]. In this context, the concept of Personal Data Transparency arises as a resource to allow Data Subjects visualizing and understanding events and agents involved in the use of their Personal Data and thus, acting to ensure their privacy, freedom and security.
Personal Data Transparency (Transparency) is the ability to enable data subject to access and understand information about why, how and by whom their Personal Data are used [3], [5]. Bellamy and Allonso [10] explain Transparency as a fundamental concept and requirement in many data privacy laws around the globe. It requires organization handling Personal Data to be open with and inform data subjects of their data uses and practices. And Murmann and Fischer-Hubner [11] highlight that Transparency is an important factor to ensure confidence in the application and its controllers.
Some initiatives to work with Transparency are being conducted by companies and researchers in order to provide data owners with the ability to know what happens to their data. As an example, Transparency Enhancing Tools (TETs) are software or browsers plugins that provide PD information such as recipient Internet IP, or allow data subject to manage who is able to access his/her data in social network [12] and [13].
Companies that use Personal Data seek to review their Transparency strategies as discussed in [10]. Specifically, scientific innovations such as [14], which the authors discussed about how developers usually access and work with personal data and how they have difficulties to offer transparency to make their apps more privacy friendly. Aiming to provide a more user-friendly Transparency, the authors propose the PrivacyStream, a function programming frameworks that transform raw data from source as sensors and database in a standard-format stream. The output information can be used to be analyze with single processing methods (avoiding external states and complex croos reference) and using flow graphs to describe how personal data process is conducted in a app.
Also, Patrick [6] presented a set of privacy principles with it respective HCI requirements. With this parameter, the author proposed possible solutions, for example, for transparency privacy principle, the HCI requirement describe as: data subject must be aware of the transparency options, and feel empowered to comprehend and control how their data are handled. As possible solution, the author proposed the transparency information explanation through examples and tutorials. The author prototype and modeled with UML a software as a concept proof to exemplify the solutions and to be used for future works in meeting data subject's privacy needs.
Also, Privacy and Security Policies (PSP) are usually used by several companies to inform their costumers about the use of data. However, PSP are complex, written in legal language as a long, verbose contract, making it difficult for data subjects to read and understand [10].
Different strategies encourage and/or enforce provision of clear and understandable information for Data Subjects about the use of his/her Personal Data, in different levels of demand. Examples are • (1) Personal Data Regulations as the General Data Protection Regulation (GDPR) created by the European Union [2]; the Brazilian General Law for Data Protection (LGPD) [15]; the Personal Information Protection and Electronic Documents Act (PIPEDA) from Canada [16]; • and (2) the Privacy and Security Policies (PSP) is a document that describes how a company handle the Personal Data regarding the privacy, security and usage [10], [17]. However, all the presented strategies should be focused on providing legible and relevant information, thus allowing the analysis and understanding by data subjects in order to support their personal data monitoring. Thus, they have issues calling for improvements: 1) The standardization of Transparency, by the definition of metadata that can be used by data subjects to understand the use of their data and that allows analysis whether the process is in compliance with the national regulation; 2) Transparency Information that can present meaningful information for data subject, once presented strategies can provide information that are difficult to use or useless for data subject; and 3) User-friendly presentation of Transparency resources, to allow the data subject performing the correct analysis of the processing and usage of their Personal Data as well as actions in case he/she identifies any unwanted action. The first improvement, towards standardization of transparency metadata was discussed by [18], who sees advantages like providing a relationship between the data subject and applications and also in reducing costs to provide transparency. Transparency metadata can be considered as a set of information about agents and processes involved in the use of personal data for a purpose.
Standardization is a challenge because Transparency metadata are significantly heterogeneous and can be applicationcontext driven. Work by different researchers point to this heterogeneity. For example, Transparency metadata can include: • programming level information: technical information about low-level systems' processes, such as services, methods, data storage data encryption and the usage of hardware resources like microphones or cameras as presented by Li et al. [14] and Rieder et al. [19]. These data are usually available in computer-readable formats and the abstraction for human-readable formats can be complex; • information about the collection and the use of behavior data that are usually collected from smartphones devices as GPS location, contact agenda, telephone call records, sensors working in houses and cars and can provide [20], [21]. These information could provide valuable inputs to support controllers to know about people common tasks.
• knowledge obtained by data subject with personal data processing: describes how personal data are processed and which information are created and how the information is applied in data subject daily life [22]; • information about the commercial use of personal data: the purpose of use, sharing and disclose details, data recipients, controllers and processors that access data [23]; • data subject rights information: information about how they can exercise their rights in order to request data copy, cancel or update permission of use, report misuse of their data, access data protection office. Thus, it is assumed that differences in information between applications may cause Data Subject to have difficulty in using and understanding Transparency, since it can allow to be considered that the information is being concealed intentionally. In this way, the need for a standard is justified once all systems can display a minimum set of Transparency satisfies that the data owners' needs, reduces implementation costs, is relevant to the understanding of the data and is in accordance with some use of Personal Data regulation.
The second improvement, which to some extent is a consequence of the diversity of metadata, refers to the relevance of information. An issue may arise when a data subject requests an unavailable Transparency Information but also, when he/she is required to analyze Transparency Information irrelevant to their needs. The effort to understand irrelevant information is detrimental to Transparency for it may lead the data owner to an attitude of lack of interest and disengagement.
The third improvement aims to provide information that is easily comprehensible by data subjects. Li's cited proposal of presenting data processing details as a graph [14], for example, may result in serious difficulties for people with low educational level. Alternatives such as using symbols and plain language can facilitate the comprehension of data events, even if they are technical actions.
Addressing these issues, this paper presents the TR-Model. TR-Model was aimed to be used to support the development of tools to provide Transparency in a understandable and practical strategy for data owner. We claim that TR-Model promotes Transparency by solving issues inherent to the lack of usable information about personal data usage by final data subjects and providing resources to address the three presented lines of improvements: • Standardized model of Transparency, with entities, metadata and relations that can be used to provide Transparency in applications and websites. The Transparency domain model and its features can support different purposes of Personal Data usage, in compliance with GDPR and according to data subjects expectations. The metadata and relations may be considered relevant to support Data Subject to understand and act about his/her personal data; • Provide a metadata description based on data subject experience design and information quality assets, to provide usable Transparency, by providing Controllers with guidance on developing usable Transparency tools and understandable Transparency information for Data Subjects. TR-Model was created based on Metadata Application Profile (MAP), that is an Information Science approach to provide a set of elements, strategies, guidelines and vocabulary that are defined for a specific domain to guarantee that the application achieves its functional requirements [24], [25].
The activities for developing TR-Model were performed in five phases.
1) The analysis of artifacts (papers, regulations, technical reports etc) regarding to Transparency, which were used to identify Transparency issues focused on delivery information for Data Subject is presented in Section II; 2) Definition of a Domain Model for Transparency; 3) Definition of a set of relevant Transparency attributes to be analyzed by data owners; 4) Proposition of a set of specifications to guide the development of Transparency Visualization Tools; and 5) Validation of TR-Model that aimed to verify whether TR-Model was able to provide relevant and understandable Transparency information for Personal Data owner. We believe that the TR-Model model can be used as Metadata Profile Application (MAP) to support the development and/or the evaluation of Transparency software. We believe that the use of TR-Model to support software development can improve the interaction capacity between Data Subjects and Transparency Data regarding the quality and reliability of the information, as the Data Subject can access a set of standardized information and describe the ones that may make easier to understand the Transparency and also ensure that the minimum Transparency information is displayed. Also, for evaluation processes, we consider TR-Model useful to support Transparency inspection guidelines and parameters for evaluating user experience in users testing.
In order to present TR-Model as well as the basis for its development, we structure this paper in five sections. Section II is dedicated to presenting the fundamental concepts related to Personal Data Transparency and its regulation. Also, the foundations of the Metadata Application Profile are also presented. Section III presents the literature review on Personal Data Transparency which provided information on requirements for TR-Model. Section IV is the core of this paper, in which we detail the TR-Model specification, which includes its requirements, its domain model and main concepts definitions. Section V is dedicated to presenting our work on assessing the effectiveness of TR-Model, which we performed using two methods -a Transparency coverage inspection and a user experience evaluation. Section VI presents our conclusions and future work. Personal data are created by the several ways of interaction among people and computational resources and it changed the way of human lifestyle significantly [26]. Mostafa et al. highlights that technology companies identified that, processing personal data, it can obtain valuable insights about people and use it to guide commercial tasks such as creating customer profiles or developing intelligent software tools.

II. CONCEPTS AND DEFINITIONS
The massive personal data exploration occurs frequently after years 2000, but there is no deadline for it. Schneier [27] reports that Personal Data usage limits are pointed as computational or internet accesses options and there are no well defined variables that can make this usage difficult.
As mentioned, personal data are created for devices as smartphones and sensors. The personal data can have different data type and formats according to controller's purpose of use. One of the main features that influence Personal Data usage is the level of detail for the collecting and processing phases. The level of detail can determinate which information the controller are able to produce and what kind of knowledge about the data subject can be obtained [14]. In this paper, the detail level are named as granularity.
For example, it can be considered the scenario in which a company wants any specifically/individual information related to credit card purchases. So, it can be said that the Personal Data is the card payment record, whereas the level of detail (graininess) may vary according to the need for the TABLE 1. Personal data granularity example. Adapted by [14]. information. Example of granularity is shown in Figure 1 based on [14].
Thus, it can be stated that data granularity is strongly related to the type of Personal Data that will be collected and, consequently, used by the controller. This is because the granularity will define the Personal Data level of detail and therefore what information can be produced about the data subject [28].
The widely use of Personal Data for several purposes made arise the concern with Transparency in order to provide software with easy and access to information about the use of personal data. Transparency is presented in next subsection.

B. PERSONAL DATA TRANSPARENCY (TRANSPARENCY)
Personal Data Transparency, shortened as Transparency in this paper, can be defined as the quality of a computer system that means the degree with which the system provides data owners privacy, security and control over their data processing, allowing the data subject to exercise his/her rights and to act on the use of data. Transparency has become a requirement for systems that collect and manage Personal Data [11].
Efforts towards Personal Data Transparency are usually concerned with making data and analytic algorithms both visible and comprehensible to data subjects [5]. Providing such information is not considered a trivial action, since certain events are technical / computational in nature and are complex to be translated into a simple information visualization mechanism [5].
Mortier et al. [29] highlight the fact that Transparency has a strong relationship with other qualities of Human-Computer Interaction, since providing Transparency directly depends VOLUME 8, 2020 on techniques for mapping/translating computational processes into understandable information. The difficulty in achieving this balance is often one reason why processes with Personal Data are unclear to data subjects [30].
Aiming to provide the minimum information about data use, websites usually insert information about this usage into a knowledge document such as Privacy and Security Policy (PSP). PSPs are not efficient strategies for Transparency because they are often long and complex texts, presented to the data subject at the time of acquisition, download or execution of an action and its content refers to practices of collection, use and disclosure of Personal Data [31].
Filgueiras et al. [32] observed that the complexity of PSP have not encourage people to read it once, they not want to look or may not have the means to look or may not have the ability to see the truth regarding their data. Due to this reason, Data Subject are often aware of data collection and processing, but they do not know when, how or where they happen, and they do not give due importance to examining terms of use and privacy policies of digital services before consenting.
Transparency also appears as a prerequisite for a data subject to exercise his/her rights knowingly about the use of his/her Personal Data [5]. The exercise of rights refers to his/her ability to restrict or cancel a usage permission, to request a report and/or copy of the collected data. These actions are encouraged and guaranteed by the EU GDPR and other national regulations.

C. TRANSPARENCY IN THE EUROPEAN UNION GENERAL DATA PROTECTION REGULATION
The EU GDPR is the result of an effort by the European Union bodies to provide a data protection regulation for those living in the EU, while also providing greater uniformity to existing data laws [33]. The GDPR came into force in 2018 to regulate and control the use of Personal Data in any field involving the European Union [2].
The regulation is strongly based on the need to defend the freedom and privacy of the data subject who produces Personal Data frequently and has such records used by companies for a wide range of purposes. Considering that the acquisition of data is usually done in a black box strategy, in which data subject do not know how their data will be manipulated, the GDPR proposes a set of guidelines that aims to guarantee the Transparency of processes for the people.
The GDPR presents a set of regulations that comprise principles, rights and issues related to organizations that are responsible for protection and control, cooperation, penalties, among others features. There are 11 chapters, 99 articles and 173 considerations on the use of Personal Data [2].
It is important to highlight that the GDPR aims to protect the data subject who holds the data; it is possible to notice its focus on their freedom, privacy and rights. Thus, Transparency must be considered as a mean to ensure that Data Subject can achieve these items.
Transparency is an important concept in the GDPR. In a significant number of articles, the regulation requests that companies that use Personal Data pay attention to providing Transparency. Also, in chapters 13, 14 and 15, the GDPR presents a list of items that must be considered to provide Transparency. Among the items for Transparency in GDPR are: • identification data of controllers, processors and control entities; • processing purposes, data used, period of use, controllers' interests and legal basis for the use of the data; • information on the origin of data, if obtained from third parties; • information on information sharing with third parties; • processing information and computer-based decision making; and • information on the means through which data subjects may exercise their rights to request actions upon their data, such as usage restriction or copy of data. The beneficiaries of Transparency required by the GDPR include all data subjects of companies located in the European Union or those that may have any kind of link with them, such as: subsidiary of an EU company or the ones that exchange information with any EU company. After the GDPR has been deployed, fines were established and offenders were effectively charged, the use of Personal Data tends to be controlled. Data subjects may have a clear protection from this regulation, but protection depends also on data subjects accessing data usage information and on acting if data misuse is identified.

D. METADATA APPLICATION PROFILE
Metadata is the data that represents the information about the data [34]. In essence, it describes what, who, when, where, and how about each facet of the information, assisting the organization in its publication and support [35].
Metadata articulates the context of a resource such as a picture, a text file or any digital register providing description that allow analyzing, understanding and exchanging data among different operators [36]. The concept of metadata is not new, but modern applications that are called as ''computing-oriented'' has gained space since the mid-1990s in conjunction with the growth of the Internet [36], [37]. This situation is due to factors such as the Internet placing a large number of documents which requires a structured way to provide meaningful content and context to the data subject [37].
The need to build web-based metadata that would adapt to specific domain needs gave rise, in the early 2000s, to the concept of Metadata Application Profile [38]. Metadata Application Profile (MAP) is a set of guidelines that specifies which metadata is used in a domain as well as its usage rules, data format and other specifications that allow the use of MAP [36].
The main justification for using MAPs was the ability to use a combination of different metadata patterns by extracting the best in each to meet the specific domain [24]. Still, a MAP does not necessarily have to be a combination of several patterns, but it can have its structure designed specifically for a domain, if other patterns cannot be tapped [38].
Dublin Core Application Profile [36] 1 and also Tennis [38] highlight that a MAP can contain the following document set: • Functional Requirements: describes the set of actions that the MAP should allow to conduct; • Domain Model: specifies the entities, agents, relations, attributes of the domain; • Description Set Profile: describes the terms of the metadata and the rules to use it; and • Syntax Guidelines and Data Formats: defines coding rules for computer systems to use to read / process data. Morgana and Baptista [24] and Malta and Baptista [39] highlight several examples of MAPs that have sought to address a wide range of application domains. Examples cited by the authors are: Scholarly Work Application Profile (SWAP) [40] used to describe academic work and the Virtual Open Access Agriculture -Aquaculture Repository (VOA3R) [41] developed by the Food and Agriculture Organization (FAO).
A widely known MAP is the Dublin Core that contains fifteen metadata elements to identify and sort documents within a specific context [42]. Dublin Core usage allows its terms to be refined through the Qualified Dublin Core and this possibility allows the refinement of content specifications to improve interoperability and web semantic accuracy, considering that semantics should be the main focus [36], [42]. Interoperability is the ability to exchange information in a large and heterogeneous system environment distributed in several areas [43] while Web Semantic is the ability to classify the data based on different context and assign meaning to it in order to be better human understanding, but also in enhancing the understanding of the machines [44].
Another well-known application of metadata is to meet the demand for data sharing in a fast, reliable and quality way. So, the Darwin Core metadata standard can be used as the standard for biodiversity data sharing [45]. Darwin Core also contains a set of terms and categories that can be understood by humans or processed by machines. These terms allow to treat biodiversity occurrence data with metadata on location, biome, context, taxonomy and identification of species. 2 The amount of existing MAPs is still relatively small as discussed by [24]. However, it is possible to identify various initiatives for using application profiling in domains such as libraries, data collections, encoding mechanisms for transmission, open data and multimedia content [24], [25].
It is believed that the development of other MAPs might make grow the possibilities for application domains that could require the correct use of metadata and their rule descriptions shall increase. In the context of this research, the use of Personal Data is considered a domain with wide possibility for using MAPs [25].

III. WORK RELATED TO PERSONAL DATA TRANSPARENCY
This section presents some specific work related to this research. The related works were selected because they focus on defining some kind of strategy for identifying, classifying or modeling privacy and Personal Data usage information in meaningful features to be used in software application, formal methods or user-friendly interfaces.
In the related works, the researchers discussed specific issues similar to those presented by [46], who discussed the difficulty of working with Transparency once it usually requires presentation an excessive amount of biased, subjective and sometimes inaccessible information. Also, it may still provide unwanted disclosure of information (trade secrets) from a company to a potential competitor.
In Patrick and Kenny's research [6], the authors mapped GDPR's Personal Data usage requirements to a set of Highlevel Principles. The principles were applied to guide the development of software interfaces usable by data subjects to track the use of their Personal Data.
The principles were used to support specification of user interface requirements and also to propose possible interface solutions for Transparency. For example, for the Transparency principle, it is presented as the requirement of: resource to data subjects access, understand and manipulate how their personal information is used. As an example of an interface, the authors report that interfaces should exemplify and explain based on tutorials how Personal Data is used. A second example is that the interface components and content used to obtain consent may be unambiguous and obvious for data subject and controllers.
However, the authors do not highlight what information should be shown and how it should be presented to data subjects.
The paper presented by Guarda et al. [47] proposed a methodology and a set of techniques for integrating Personal Data security with compliance with Personal Data usage regulations. The methodology aimed to support the abstraction of complex security actions and deliver friendly information to be analyzed and support the decision about the security of their data.
Guarda et al. [47] presented a set of categories that organized the information to be protected in the followed categories: 1) Classes: Personal Data refers to the data that allow identifying a personal; Sensitive Data (SD) which refers to Personal Data that includes information on ethnicity, gender, religion and political opinion; and Non-Persoal Data (NPD) that was information that could not be associated with a person; 2) Legal Roles: refers to actions that could be performed by agents within the Personal Data life cycle such as: VOLUME 8, 2020 Data Controllers, Data Processor and the Data Producing Individual; 3) Auxiliary Notions: characteristics regarding to the access features to Personal Data such as: Purpose; Consent and Data Quality.
The authors replaced the natural language specified by the presented categories in order to derive the formal rules of the template access control policies. They used standard Boolean connectives to combine them in Boolean algebra, once it were considered an expressive technique to reduce the complex privacy specification in a formal language to support software development,.
The third paper is presented by Hosseini et al. [46] which highlights the fact that Transparency has become a necessity for software applications. However, there are few well-defined conceptual models or strategies for support developers in understanding, specifying, and implementing Transparency requirements. Hosseini et al. [46] discussed that Transparency is often seen as part of other non-functional requirements such as security or privacy.
Hosseini et al. [46] identified a set of facets as important be used in a Transparency project. For Transparency information, the Transparency facets describe groups of information considered relevant in a scenario where data subject needs to know about the use of his/her data. The facet was classified into the groups: • Transparency Stakeholders: All actors in the use of Personal Data may be identifiable in order to make possible to understand where the information originates and, which data subject produces the information, who process and/or received it; • Transparency Meaningfulness: Stakeholders may know about information of data, actions and purposes behind the use of personal data; • Transparency Usefulness: Information must support the stakeholders actions and their decisions-making or change their perceptions of information provider; • Information Quality: Describes the importance of quality information features such as free-of-errors, concise, timeliness, understandability, objectivity and reputation.
We also analyzed two researches that aimed to create a GDPR-based class model for Personal Data usage: [48] and [49]. The researches focused on mapping GDPR guidelines into UML Class Diagram and thus provide an approach to support application development in accordance with the regulation. Classes such as: Purpose, Consent, Data Processing, Technical Measures among others were identified. Attributes such as: Free consent, Legal basis and public interest are part of the identified information.
Although the modeling presented by [48] and [49] did not have a specific focus on Transparency, we assumed that the class information could be used as a basis for Transparency metadata. It seems to be out of the scope of these authors concerns about data subject' ability to understand the information and user-friendly ways to present it.
The works presented in this section were initiatives to improve how to provide Personal Data Transparency. Formal languages, UML modeling and information quality facets are elements that could be used to make information more userfriendly.
However, none of the related works performed the improvements suggested in this paper. First, although Transparency metadata could be similar to the classes defined in [48] and [49] work, the authors were not concerned with information metadata standardization. Also, the cited research did not present guidelines to information presentation, although discussions about quality aspects for Transparency metadata that could be used in a presentation strategy were presented by [46].

IV. TR-MODEL -SPECIFICATION TO PROVIDE USER-FRIENDLY PERSONAL DATA TRANSPARENCY
This section presents TR-Model, a set of specifications to provide user-friendly Personal Data Transparency.
TR-Model represents three relevant concepts, which are briefly described here and analyzed in further detail in the following sections: the concept entities model information on actors involved in Personal Data Transparency. The concept metadata is associated to all information used to describe Personal Data Transparency. The concept metaevents represents situations which are relevant to Personal Data Transparency. These concepts are presented in three layers of abstraction: the Domain Model, the Definition and the Specification.
In order to present TR-Model, subsection A present the methodology used to develop the model and the basis upon which the model lays its foundations. Subsection B presents the Domain Model, that defines the entities that compose the model. Subsection C contains the definition of metadata and metaevents for TR-Model entities, similar to attributes and operations in object orientation modelling. Section D ellaborate on metadata and metaevents representation in software tools, focusing on the model's quality in use. Sections E, F, G, H and I respectively bring detailed description of metadata and metaevents (where applicable) for entities Actors, Personal Data, Purpose of Use, Access and Agency.
In next section we present the requirements definition for TR-Model.

A. REQUIREMENTS DEFINITION FOR TR-MODEL
The TR-Model represents a concept in which Transparency metadata are information with about events, agents and relationship involved in the use of Personal Data. Therefore, we considered the Personal Data Transparency as an information about data usage organized in a domain model with entities, metadata and descriptions.
One concern in the construction of the TR-Model was its standardization, consistency, use, understanding and the need to avoid ambiguity and subjectivity to assist data subjects in analyzing the use of his/her Personal Data and act to ensure their rights. To avoid the problems, it was decided to use the Metadata Application Profiling (MAP) approach to support the development of TR-Model as, according to [25], the MAP strategy makes it possible to identify functional and technical requirements for metadata, address issues of ambiguity and generalization, and facilitate testing.
Thus, TR-Model was created considering the Dublin Core Metadata Initiative (DCMI) 3 specification once, we intend to provide a group of specifications to support the deployment of software tools to provide Transparency for data subjects. DCMI provides a process to be followed in order to created a MAP to support a specific domain. The Figure 1 base on DCMI presents the TR-Model was organized in a set of entities, metadata, events and usage specifications. Events are occurrences that interfere in the use of Personal Data and may be presented for Data Subject. Thus, in this paper we will refer for event as metaevents. Details about the meaning and reason to use the metaevents are presented in Section IV-C.
The TR-Model was defined to be a pattern for Personal Data Transparency (Transparency) focused on the Data Subjects' interests concerning information and its comprehension capacity. To achieve this goal, in the development process, we focused on the needs of non-experienced/novice users regarding data transparency, that is, those who do not have advanced skills in computing or information science to understand the implications of personal data processing, even though they are regular users of a computer application. This model was designed to be viewed in a high level in which technical information is considered to be of little interest to the data subject and consequently must be supplied by metadata that relevant information in an understandable language and at the same time conveying the full concept of Transparency efficiently.
In the development of the TR-Model, the understanding of the Transparency domain was developed using the Pressman's Domain Analysis [50]. This technique does not consider the active presence of the end user, but uses documents, articles and other means to obtain details of domain requirements. The use of sources other than the user was necessary since users' incipient knowledge about Transparency provided few and sometimes divergent inputs to the model. Thus, the following resources were used to understand the Transparency domain: • The GDPR was the main source of knowledge.
It presents a well-defined set of Transparency requirements that must be applied to computer systems. The requirements are clear and understandable to support the model development, although some of them still require some interpretation by the reader; • Technical and scientific articles provided information on the context of usage of Transparency, in a number of distinct areas. This enabled us to identify applicable forms of Transparency in tools such as TETs or initiatives to implement Transparency and ensure what was called data subject-centric transparency. Also, it allowed the comparison of the concepts of GDPR with the applications that occur in the TETs; • Scientific Papers have several contributions to Transparency. The articles showed that the concept of Transparency is being discussed in several research centers, but its concepts, structures and application forms still have many open points for discussion, including the definition of a set of structured and described information about agents and events involved in the use of Personal Data. We highlight the work in [5], [11], [29] and [6].
• Websites leaded to technical content and research groups on HDI and Transparency studies that provided information on concerns, challenges, TETs and perspectives regarding the implementation of Transparency. Accessing the http://hdiresearch.org/ website we identified materials that encouraged the study about the relationship between IHC areas and Personal Data.
• Users: even though they do not have advanced Transparency knowledge to contribute in the requirements elicitation activity, they significantly contributed with the model validation once the information was subjected to critical evaluation of the data subjects through scenarios simulations. Such analysis has fostered discussions to refine TR-Model in order to provide more understandable and interesting Transparency. In the first stage of the TR-Model conceptualization and development the needs of Transparency were highlighted. So, we tried to understand what kind of information would be relevant to Transparency and how software tools would provide this information in such a way that they could be understandable. For this, the regulations and scientific technical articles that analyzed the main challenges arising from the use of Personal Data and mainly (how) about Personal Data can generate problems of privacy, security and freedom were analyzed.
People who presented themselves as potential data producers were also interviewed and consulted. We interacted with participants through workshops. Workshops were conducted in universities and educational institutes which the researcher presented the concepts, challenges and features of the Personal Data usage. Participants with different expertise such as computing, law, marketing, administration, education and logistic attended the workshops. The workshop's tasks were: presentation about Personal Data usage; resolution of questionnaires; and PSP analysis and discussion. It was common some participants required a talk face-to-face. Although this kind of discussion was informal, it provided relevant data that support the TR-Model development as well as the result of questionnaires and PSP analysis.
Based on the cited previous work, we define the Functional Requirement for TR-Model as: Support the development of software tools to provide Transparency about the Personal Data usage with information and events about actors, purpose of use, personal data, transfer/disclose and agency in a way that information may be readable, relevant and To accomplish the functional requirement, we assume that TR-Model considers the following individuals' needs: 1) the individual must know what data is collected and how they are collected. Thus, a minimally necessary Transparency information to provide understanding about what Personal Data are collected and about Personal Data collection strategies. Also, data origin and data security preservation strategies must be considered; 2) Data subject must be informed about the Stakeholders involved in the data usage, their roles and how to access / identify them. This information is required in Personal Data regulations in order to ensure to provide knowledge about stakeholders identification to support any kind of individual analysis or action; 3) Data subject must be informed on the purpose of using the Personal Data and on the legal document that legitimates this usage; 4) Data subject must know the means to exercise their rights in case the usage turns to be against their interests or principles; 5) Data subject should be provided minimum processing and events information; and 6) Data subject should be informed on Personal Data transfers, sharing and / or disclosure. Defined the Functional Requirement, the next step in building the TR-Model is to organize the entities, attributes and relationships to assemble the TR-Model's Domain Model. Domain Model is presented in the next subsection.

B. DOMAIN MODEL
The TR-Model domain was structured as presented in Figure 2.
The TR-Model domain was proposed based on GPDR's Articles 13 and 14 and respective sections and paragraphs. The domain model presents the follow entities: Entity Actors (Controllers, Processors, Recipients and Protection Office): this entity represents persons and legally established companies that participate in the production, collection, processing, sharing or using of Personal Data. Actors is an important entity because every other entity is related to at least one Actor. The focus of GDPR regarding to actors is related with identified/contact details for individuals. The actors are classified in GDPR as: • Data Subject: Person who uses any device and who produces a Personal Data; • Controller: A private or public person or company that determines the purposes of using the data and must comply with laws and regulations regarding the use of Personal Data; • Processor: Private or public person or company that conduct events under controller control; • Protection Office: An independent public entity established in a country or specific area that is responsible for oversee and enforcing regulations on the use of Personal Data; and • Recipient: Person or company that receives any Personal Data for use or that is the subject of any claim, complaint or action of the individual. Recipient can also be any of other type of actors that receive a request of actions to ensure data subject rights and freedom.
Entity Purpose: This entity is aimed to support transparency information about the purpose of use for Personal Data. The purpose is always defined by the controller or by a group of controllers called as ''Jointly''. Information on purpose is relevant for transparency because it is the basis for legitimisation of collection and usage of personal data.
Entity Personal Data: This entity represents the description of the pieces of information that are collected from the data subject and used by Controllers. The Personal Data entity is justified by the fact that the variety and data of interest of the controllers is very large and the data owner may not be properly informed on what data need to be collected. Depending on what data are collected, the generation of information about the data subject can seriously affect their privacy, security and/or freedom.
Also, Personal Data Transparency Information allow data subjects to exercise their rights on canceling, restricting or denouncing the unwanted or misuse of their data. For such actions, it is necessary to have information about the collected data.
Entity Transfer: This entity is responsible to support Transparency about the data transference, sharing or disclosing. So, the Recipient information must be enforced, by a data protection regulation, that can be the GDPR or any local other one, to verify and ensure the correct use of the obtained data.
The transfer of Personal Data is a primary concern of data subjects and it is strongly related to privacy and data security. There are specific techniques, such as the use of log files, maps and graphs seek to show the path taken by the data after being produced and / or collected, but the information provided may not meet the data subject's needs or regulations for using Personal Data.
The GDPR is emphatic in affirming the need and concern to observe the legality of actions aimed at the disclosure and sharing of Personal Data. It requires that information on what data are shared and with which recipient(s), what is the legal basis for sharing and what is the justification of the transfer.
Entity Agency: This entity is responsible to support software tools for presenting information on how the data subject may exercise his or her rights to report irregular use of the data, cancellation and restriction of use and / or request for a copy of the data.
This entity of Transparency aims to make clear to the data subject how he/she can guarantee their rights to actions such as: Request access to the data, report an irregular use of data, restrict access to the data or others data subjects' rights.
Considering that each controller can provide different mechanisms to guarantee data subject' rights, a set of metadata focused on presenting the existing path(s) to carry out the action was proposed and will be presented in Table 7. The mechanism that the controller must present to allow data subjects to argue about their data use can be a website, a phone number, an email address or any other type of resource that allows the insertion of the complains.
With the presented entities, we assumed that TR-Model is able to provide a set of agent information and events related to the use of Personal Data.
As TR-Model was created to support software tools to provide Transparency, a set of descriptive metadata was also developed to explain how each entity should be used as well as its attributes and events. This description can be applied to both controllers at the time of filling Transparency data as the data subject can use them to understand the information transmitted.
Next section presents the Description Set Profile for TR-Model.

C. METADATA AND METAEVENTS DEFINITION
In this section we are presenting the definition of the metadata and metaevents for TR-Model's entities. These specifications were created to be used as a guideline for providing the Transparency Information Visualization.
The concept used to create metadata and metaevents was similar to object oriented modeling proposed by Pressman [50] that establishes a set of attributes and operations for each domain entity. In this approach, metadata are equivalent to attributes, describing the entities' characteristics and their meaning in the domain. Metaevents are then elementary actions that take place upon metadata in the context of an entity, and thus are similar to operations. Metaevents are also meaningful information for Data Subjects to understand how their data are used.
All TR-Model entities have metadata to describe their characteristics in the context of Personal Data usage. All TR-Model entities have elementary metaevents of creation, retrieval, update and deletion, however, they are not significant from the Data Subject perspective. Thus, only the entities Purpose, Personal Data and Transfer had their metaevents represented in the model.
The Domain model presented in the preceding sections was created according to the DCMI strategy for MAP creation. Because the TR-Model's main goal is to be a guide for development or software tool for Transparency with user-friendly and information quality content, other particular strategies that are considered common in a MAP creation were not adopted: (1) reusing attributes and definitions of other MAPs once we did not identified metadata from other MAPs that could be reused; and (2) create and specify usage syntax in order to support interoperability once TR-Model did not aimed to work with it.
TR-Model metadata and metaevents are presented in Figure 3.
The next subsection presents the metadata, metaevents and descriptions for TR-Model Entity.

D. METADATA/METAEVENTS TRANSPARENCY DESCRIPTION
The metadata and metaevents descriptions show how metadata or metaevents must be deployed in software tools to presented Transparency to Data Subject. The descriptions were created based on HCI Features [51] and Information Quality Dimensions [52] as we considered techniques used to provide appropriated information visualization for the data subject. Concepts as Readability, Presentation Format and Information Quality were also applied.
The concept of Readability refers to the ability to produce more readable and understandable texts to the data subject and considers aspects such as text size, number of words and focus on the audience [53], [54]. It must be applied to information which is believed to be best presented in textual format. The readability features selected for Transparency were: (1) use short sentences to be more attractive to readers; (2) focus on the readers considering that the information's users are not experts in computing or data analysis; and (3) avoid complex words making the use of words with few syllables and that are popular for readers.
Also, the concept of InfoVis (Presentation Format) is the study/application of visual resources such as graphs, info-graphics or interactive resources for abstract data representation [55]. This approach was considered to propose a Transparency mechanism that could be better applied with visual elements, as they would represent the information in a more interactive and easy to assimilate manner.
The Information Quality (IQ) is a multidimensional concept that aims to support the development and delivery of appropriated information for data subjects [56].
Concern about IQ has grown due to the widespread use of the Internet by people who use information presented for their decision making [56]. In this way, people's decision is increasingly tied to their ability to understand, analyze and also in information accessed confidence [52]. According to [57] information with quality is the information that fits the concept of fit for user.
IQ is related to information delivery considering dimensions such as Contextual Quality (relevance, completeness and value added) and Representational Quality (ease of understanding, ability to interpret and concise representation) [58]. It is also considered for Transparency specification since data subjects access, analyzed and understand the information provided in order to analyze how his/her Personal Data is used (and by whom) and, thus, decide on any intervention. The dimensions considered for metadata and metaevents specification in TR-Model are shown in Table 2 based on [52], [58], [59].
In the following subsections we will present the Metadata and Metaevents Description Set for each one of the Personal Data Transparency Entity in TR-Model.

V. METADATA, METAEVENTS AND DESCRIPTIONS FOR ENTITIES
In this section, Metadata and metaevents list is presented as well as it descriptions.  [52], [58], [59].

A. METADATA AND DESCRIPTION FOR ACTORS
The definition of attributes of this entity was strongly based on the GDPR section 1 paragraphs a, b, and f for both articles 13 and 14. These sections require that systems must present a list of items for the actors identification. Among them must be a contact information. Considering that the term ''contact data'' allows a certain subjectivity, we decided to establish some metadata/description that allows the data owner to locate the actor by maps, phones or internet.
Actors are all individuals or organizations involved in the Personal Data life cycle. The people involved can present at least the following responsibilities: determining data usage rules, performing processing, sharing data, receiving shared data, and monitoring / supervising actions.
The actors metadata and description are presented in Table 3.   The Personal Data metadata was developed to present information about which data was collected, how it was collected, and how it would be stored / protected. This entity aims to comply with the Transparency principles discussed by Bellamy and Alonso [10] that states that the use of Personal Data should be open to the Data Subject.
The Personal Data metadata and metaevents aimed to specify issues related to which Personal Data are collected. It includes data structure, collecting features and devices used to collected data. Three events describe since the moment when data subject grant the use of Personal Data until the tasks conducted with a data. The Personal Data metadata are described and specified in Table 4.
We assumed that, with the metadata and metaevents presented, the data subject will be able to know and understand which of their data is collected, how it is collected and how it is used. This information can be used by the data producer for better understanding of interactions made by the software such as: suggesting a product or service, anticipating a person's action or presenting certain knowledge about people's actions.
In the next subsection the Purpose usage metadata and metaevents will be presented.

C. METADATA AND METAEVENTS AND DESCRIPTIONS FOR PURPOSE OF USE
Purpose-of-use metadata and metaevents intend to support software to provide for Data Subjects Transparency information to answer one of the most common questions regarding to the use of Personal Data: ''What do you want my Personal Data for?''. The entity's metadata is focused on the reason of use, responsible for the use and the legality. The data subject will also be able to understand what data will be used for the purpose and whether any decision will be made solely by computer.
A relation with Actors entity provide for Purpose of use information about the actor as a Controller. The Purpose of use metadata named as Controller has information that allow Data Subject to access contact data about who define how Personal Data may be used.
Regarding to metaevents, it support to understand the purpose of use by providing information about the beginning and the end (period of time or event trigger) of the purpose's execution. Thus, the Data Subject can identify whether the execution of the purpose of use (and the consequent use of his data) is momentary, temporary or while he is using an application or service.
And finally, knowing about the purpose of use for Personal Data, we believe that the data subject can develop more confidence in the data controller organization, besides having information that can support an eventual complaint or denunciation of abuse in the use of the data.
The Purpose of use metadata and its description set is presented in Table 5.
The next subsection will display the Transfer/Sharing/ Disclose metadata and metaevents   users' concern. Due to this concern we decided to create a set of Transparency information that could support the knowledge about which data are being disclose and who are accessing Personal Data besides the app/website controller.
The information about data are provided by Personal Data entity and the relation with Transfer entity. Who access Personal Data are presented through two relations between entities Transfer and Actors. Two different actors are involved in the Personal Data disclose: Recipient: Other controller that receive Personal Data; and Recipient regulation: Protection Office that supervise the Recipient.
As complementary information for identification of irregularities in data disclosure, we proposed a metadata set related to laws/regulation description as well as metadata about how and who are regulating the data usage in the recipient context. The proposed metadata are in compliance with GDPR Article 13 and 14 Item 1(f) and with LGPD's V that discuss international data sharing/transfer.
Regarding to metaevents, TR-Model proposes two information related to transfer events: (1) the moment when the Data Subject authorize the data transfer, disclosure or sharing; and (2) which occurrences trigger the distribution of the data, once a controller can send data in different context of use in different interval or packages.
Based in this needs the Transfer metadata and description were defined as presented in the table 6. It is also important to highlight the metadata named Type that shows which type of data distribution action with third parties. The definitions of each word were created after analyze how Personal Data could be used by several controllers in partnership and searching in dictionary which would be most appropriate to represent it.
This metadata can help the data subject to identify whether data distribution is beneficial to the him/her, because in partnership with other controllers, the primary controller can improve the quality of information to achieve the purpose which Personal Data was collected. The Type metadata can also support the identification of actions that is not in compliance with data subject authorization since the data recipient could use data for some action for which the data subject has no interest.
Thus, TR-Model Transfer entity proposed Transparency that may allow the data subject to identify the destination of their Personal Data as well as the legality of the actions. With this knowledge, he/she can make decisions about continuing to use the service or application and consequently having your data distributed to third parties.
Next section presents the metadata for Action and Negotiation (Agency).

E. ACTIONS AND NEGOTIATION METADATA (AGENCY)
To provide Agency metadata, the followed features must be considered: 1) This entity's metadata should work as a tutorial/informative-style to guide Data Subject how he/she may acts to intervene in the use of their Personal Data; (2) Each controller can provide different mechanisms to ensure data subjects' rights; and (3) TR-Model is not aimed to make any kind of pattern for these mechanisms.
The name Agency refers to any action or negation that can (may) be performed by Data Subjects to ensure their rights in the Personal Data usage.
To meet these factors we assumed that this entity would need just three metadata: (1) Agency title; (2) The recipient of the action (Who will receive the message, report or request) that may be an actor with type as Controller, Processor or Protection Office; and (3) A metadata with the flexibility specification to allow the controller to present several kinds of information on how the Data Subject may acts. Thus, the tutorial information presented can be according to Controller preferences since it guide the Data Subjects in their actions.
The metadata for agency are shown in the Table 7.
Next section presents the TR-Model validation.

VI. VALIDATION
This section presents the TR-Model validation carried to verify whether it could support software development in order to provide Transparency information focused on Data Subjects. TR-Model must support software tools to assist in the visualization, understanding and analysis of the Personal VOLUME 8, 2020 Data usage by Data Subject. Also, it should support the compliance with the Personal Data regulations such as GDPR.
Due to the fact that TR-Model cover different aspects, we decided to perform the validation based on the following approaches: 1) Transparency coverage: Personal Data Transparency is one the main request provided by GDPR and LGPD in order to ensure the correct Personal Data usage. Considering this request, we decided to verify whether the proposed information about data usage were in compliance with these regulations. The choice of GDPR was due to the fact that it is a regulation already in force and with its well-defined texts. The LGPD was chosen because the origin of this research takes place in Brazil and there is the expectation of use of this model in the country; 2) User Evaluation: TR-Model was created to support Transparency information for the data subject usage. It aimed to abstract the complexity of events involved in the use of Personal Data in user-friendly and relevant information. Therefore, testing with data subject was necessary to verify the effectiveness of information from the user's point of view. Validation with participants was performed using a combination of controlled tests and questionnaires resolution. The data collected were analyzed on two approaches: (1) quality of HCI elements; and (2) IQ dimensions. The next subsection presents the coverage validation of the activities performed during this research.

A. INFORMATION COVERAGE VALIDATION
In this validation task we analyzed whether TR-Model covered Transparency requirements proposed by regulations are attended with its metadata and metaevents. For GDPR, we considered the Articles 13, 14 and 15 because these articles present the data subject' right regarding to access to information about the use of their Personal Data. For LGDP we did not considered a specific article or chapter, because Transparency is not discussed in a specific article as GPDR, but the Transparency requirements are discussed during in text topics that need to address Transparency.
The inspection was performed listing the Transparency requirements presented by the regulations and for each requirement (or group of requirements) it was indicated how the information could be made available by TR-Model entities, metadata and metaevents.
The GDPR analysis is presented in Table 8. This table presents the Articles, section and items that request Transparency information and the related contribution made by TR-Model. Important to highlight that, there are TR-Model's contribution that are applied in more than one Transparency request.
The LGPD analysis were consucted similarly and is presented in Table 9.  Tables 8 and 9 allow to conclude that TR-Model provide compliance with GDPR and LGPD in the feature: ''what information to provide as Transparency. In fact, these regulations were the main requirement artifact used to support the construction of TR-Model, and, in a certain way, we expected that it suitability were achieved.

The information presented in
Although regulations have some differences in Transparency requirements such as: (1) greater emphasis on one Transparency requirement in one regulation than in another; or (2) certain Transparency information may be required with more details in one regulation than another, all the requirements are accomplished by the TR-Model.
Next subsections presents the validations conducted with users participation.

B. TR-MODEL VALIDATION WITH USERS
In order to verify whether the TR-Model guidelines are effective in guiding the production of satisfactory Transparency information for data subjects, we have performed some user tests. User tests were based on a physical-activity data-collection application, which collects and processes data about running, walking and gym activities. Using this application, we developed five scenarios, in which the user was presented to usual situations of Personal Data Transparency relevance. In this application, we simulated information using TR-Model metadata and metaevents specifications.
Additional to user testing, we applied attitudinal verification through surveys. Results are presented using descriptive statistics and qualitative analysis.
We designed a questionnaire to gather each participant's opinion about the quality of transparency presented by the TR-Model. The validation of this model was based on the Qualitative Approach [60] in order to identify each participant's experience with Transparency and also to identify issues that could be improved with the TR-Model. The instrument is presented in Table 11. The participant answered all questions for each scenario.
Closed questions were used to assess interface elements features as Readability and presentation format, and Information Quality features as discussed in the previous sections.
Some Those dependent questions were descriptive and aimed to collect participants' suggestions or justification regarding answers of other questions. The answers of these questions provided insights for corrections and/or improvements in TR-Model.

C. VALIDATION PARTICIPANTS PROFILE
A total of 121 (one hundred and twenty-one) participants participated in the validation tests. The demographic profile of the participants is shown in Table 12.
Participants were invited to participate voluntarily in the activity. Invitations were distributed via email and social networks. Before starting the testing, they were advised that the purpose of validation was the TR-Model and that their performance was not being evaluated at all. They were also informed that no personal data would be collected, and their actions and opinions would be used solely and exclusively for the purpose of this research.
Also, the participants were told that they could give up anytime if they wanted to or felt embarrassed. They received researchers' phones and contact emails for any questions or complaints. Tests only started after the participant agreed to participate.
We assumed that the participants' profile represented a significant sample of users of websites and mobile applications. Limitations due to the sample were due to a larger number of participants from the STEM areas due to the fact that many participants were students, teachers and / or employees of educational institutions in the area of computing, mathematics and physics. Also, we had no participants over 50 years old.
Before the evaluation, participants answered a questionnaire intended to assess their previous experience with this subject, their awareness about the use of their Personal Data by applications, and the level of concern associated. Regarding to prior knowledge about the use of Personal Data by applications, the result was almost unanimous: 97 % of the participants indicated previous knowledge about the subject and only 3 % (4 participants) answered that they did not know about the use of Personal Data. For identification of VOLUME 8, 2020  participants in this section we will name participants who had prior knowledge as Profile A and those who did not know as Profile B.
Profile B participants also showed little or no concern about mechanisms that could provide Transparency. These participants answered that they never read the PSP; 75 % of them never worried about the use of their Personal Data and 25 % had only some concern. This behavior was expected because if they ignore the use of their data, there is no reason to be concerned and no reason to read PSPs in order to find information about this. We expect concern to rise after knowledge.
For Profile A participants, the results presented subtle change as 64 % of participants also answered that they had never read the PSP and 36 % who had done some reading. Similar to Profile B, no participants indicated that they read PPS frequently.
The Profile A answers regarding to the considerations about the use of Personal Data are presented in Figure 4. . Responses related to concern with the use of personal data.
Another question asked the participants was: how often they seek information about the use of their Personal Data. This question will be discussed only for the respondents of Profile A, because the others naturally answered that they never seek such information. The answers to this question were: (1) Never: 34.2 %; (2) Rarely: 54.7%; Often: 10.3 %; and Always: 0.8 %.
For participants who responded that Never or Rarely search for information, they were asked to describe why they provided these answers. The essay question was answered by 104 respondents who presented answers that included elements such as: • Lack of interest in information; • Lack of time, for one must read a lot of information; • Difficulty in identifying and / or finding information; • Lack of choice, since denying access to data implies in no access to the service; • Confidence in application providers; • Little knowledge about the subject; and • Long, technical, legal and subjective texts; For participants that answered that they do search for information about the use of Personal Data, they were asked to describe the strengths (S) and weaknesses (W) of the resources / information provided by the applications. Thirteen participants marked one of these options and their answers described the issues such as: • (W) Information is not restrictive and gives scope for interpretation; • (W) Inaccurate information on how and for what data will be used; • (W) Too much content to review; and • (W) Complexity of terms and words used to present information. The presented information corroborates a previous discussion in which the lack of a user-friendly pattern as well as the use of inaccessible means make Transparency information difficult to be accessed, found or understood by the data subject. Consequent data subjects' detachment in verifying the use of Personal Data leaves a clear path for companies to promote a black box approach in which either the user accepts the company's terms or the user does not use the application.
When companies provide information, the content is too complex to be analyzed. Information can be written to provide a margin of interpretation favorable to the company and to hinder possible actions by data subjects.
Thus, even when the participant has a concerned profile about the use of Personal Data and searches for information about it, problems related to information quality affect the content and lead to serious difficulties for data subjects. Although much of the use of data may be positive and beneficial to the data subject, difficulties reported by the data subject can create ways for the misuse.
Finally, we concluded that people are not uninterested or silent about the use of Personal Data, but instead, the way information is disposed leads to lenient behaviors as people usually respond better to quick, objective, simplified, simple-language content. The next subsection analyzes participants' expectations regarding the Transparency information versus the information proposed by the TR-Model.

D. PARTICIPANTS' TRANSPARENCY EXPECTATIONS VERSUS TR-MODEL INFORMATION
A mandatory question was proposed to participants, which aimed to verify whether TR-Model was according their expectations regarding Transparency information: If you could choose any information to require in order to learn about the usage of your Personal Data, which information would you require?. The question required an essay answer.
The 119 responses received were analyzed using textual analysis and grouped in 14 categories that express users' expectations. Results are shown in Figure 5.
This chart shows that the participants' biggest concerns were what data is used, by whom they are accessed and purpose of using the data. Some concerns has also been identified such as how the data will be used which we assumed that would be a more technical information, for example, that the data are compared or summarized or classified by a specific algorithm.
The expectation on who will access the data was also evident. Among it, concerns about sharing or disclosing data among several organizations were considered by participants. They are more focused on the knowledge about who will receive the data (or whom the data will be shared with) than the concern about its usage by the Controller who collected the data.
More technical expectations such as resources used to collect data, frequency of collection, safety information, storage and details on how to cancel the permission to use data were presented, but in lower frequency. Security and storage information may be suggestions from people with computer knowledge, once this information is technical in nature. Expectations for information on how to cancel, change or restrict the use of data may be the need for those knowledgeable about the use of Personal Data and who are concerned about its consequences, as in the event of disagreement or disagreement they could cancel. permission to use the data.
Regarding the analysis of the suitability of the TR-Model to the participants' expectations, we concluded that the model supported directly 12 expectations, that is, participants' expectations were described in the metadata and metaevents description in the entities. The following expectations were not met or were not directly addressed: • List of processes conducted in the Personal Data: with just one indication, we assumed that the participant expected technical information about Personal Data processing history, something close to the concept of Data Provenance. Considering that this is a requirement that needs a specific support model, that information was not included in the present release of TR-Model; • Information about storage and data security: Although we considered including this information in TR-Model during its development, it was dropped because we assumed it to be too technical, and possibly might not be relevant for data subjects. However, the availability of this information will be considered in future VOLUME 8, 2020 releases of TR-Model once is necessary more studies to abstract storage and security technique in user-friendly information; • Usage justification: This information is included in the Transfer entity, but has not been entered in the Purpose of use entity. In Purpose of use entity, this information can be suited in Description metadata.
Therefore, considering the information provided by the participants, results allow us to conclude that the TR-Model usage provides 85% of the information expected by this sample of data subject. For information that presented higher frequency of expectations, TR-Model was effective in meeting 100% of participants' expectations in its entities, metadata and metaevents.
This positive result is due to the participation of data subjects (users) in the entire TR-Model development cycle. The engagement of users not only provided good user experience but an efficient set of specifications and metadata.
The next subsection presents the Transparency user experience and information quality evaluation.

E. USER EXPERIENCE AND INFORMATION QUALITY EVALUATION
This subsection presents the data analysis and results of the questionnaires answered by participants during the evaluation related to the Transparency User Experience and Information Quality.
Each Transparency scenarios were evaluated considering HCI features such as Readability, Infovis and also considering IQ elements. The analysis and discussions will be present first by HCI features and after, by IQ elements. For the discussions we analyzed the results using descriptive statistics to provide information considering all the evaluated scenarios. After, we discussed eventual situations that drew attention for their results. Also, we discussed the the analysis of essay questions answered to justify or describe a specific answers in a question.
Participants conducted 320 individual evaluations in all available scenarios. The amount of evaluation for each scenario is: Next, we discuss HCI features analysis.

1) HCI FEATURES ANALYSIS
The HCI features' evaluation aimed to verify the effectiveness of metadata descriptions that focused on the interface design. Although TR-Model was not designed to be an interface pattern, the Transparency metadata and metaevents also describe some HCI and Infovis specification to produce appropriate Transparency. In a certain way, TR-Model tried to support the friendly information design to data owners.
The questions used to collect the data for this analysis were: Q1, Q2, Q6, Q2a and Q6a presented in Table 11. The Figure 6 presents the graph with percentages for the answers to these questions, considering all scenarios evaluated.  Figure 6 presents that HCI features were satisfactorily evaluated by the users. The Q1 results were that 76 % of them considered it easy to find or identify Transparency information. We assumed that this result is due to the selection of the information presented and the labeling through the metadata titles. In contrast with texts in a Privacy and Security Policies (PSP) where the data subject needs to search information within large amount of texts usually without good labels, information created based on the TR-Model is labeled and displayed in order to make it easier to distinguish it from other content. The use of simple, small and straightforward labels (metadata titles) helped in identifying the information.
The answers related to amount of information (Q2) presented a similar result to the previous question, once 81% answered that the amount of information is appropriate. This result is justified by the fact that descriptions of metadata and metaevents stipulate a minimal set of information, with limited amount of words and that aimed to present only that can be used and manipulated by data subject in order to avoid access and analysis of unnecessary content.
Regarding to negative answers, 19 % (64 answers) indicated that there is too much or too little information. For these answers, the suggestions of respondents (question Q2a) were analyzed in order to apply future improvements in the amount of information. An initial analysis of the Q2a answers identified that the difficulty was in locating additional desired information in a specific scenario. The difficult occurred because the participant search for a kind of information that was not available in the evaluated scenario.
Assumed that the problems indicated in Q2a were caused by some respondents misunderstanding the tested scenarios that limited Transparency to information strongly related to the scenario context, once there was no access components for other Transparency beyond that contemplated in the scenario Q6: Some information are better visualized by text, others by images (photos, videos, etc.), colors, formats, etc. Regarding the format in which the information is displayed (texts, colors, images etc.) what is your opinion? that focused on Infovis had a considerable percentage of positive responses once 86 % considered the display format appropriate. Although the TR-Model does not clearly specify what interface components to use and which decision may have a direct bearing on design, we have considered some standards that were proposed in [61]. These standards were validated by several users in some usability testing, showing effectiveness in displaying information. The display format is an important feature as it aims to abstract the appropriate Transparency information to the data subject so that they can use it for decision making. Regarding negative answers or need for improvement, considerations made by respondents in Q6a provided some suggestions, such as: better use of colors; content organization (following a kind of sequence), improvements in images quality; better grouping and distinction of information; better use of icons; and use just one webpage. We concluded that the suggestions are all related to the information display adopted for the experiments in this research. No suggestions or criticism related to the metadata descriptions and meta-events existing in TR-Model were identified.
Analyzing the results, scenario by scenario, we noticed that there was a pattern of responses and that the numbers remained relatively similar to the values obtained in the general evaluation, as shown in Figure 7.
So, we could define some assumptions based on the related results: (1) The result of Q1 (Use the range of 1 -Very Bad to 5 -Very Good. How do you rate the ease of finding and/or identify information about the use of your Personal Data) in scenario 5: The scenario had a mostly appropriate opinion by the participants regarding the identification of the information. we considered that this situation occurred due to the scenario presenting a set of registration forms of the actors and such information is commonly used in the day to day personal and is simple. This result is due to the reason that the Transparency presented is based on popular information design for respondents. This scenario presented registration information of actors involved in the use of Personal Data. A design of registration information is already very common on websites and the information presented is equally routine for personal information. In addition, the TR-Model specifications did not present severe changes in the way of informing the registration data, but instead tried to make it as simple as possible. VOLUME 8, 2020 (2) The answers for Q2 (Regarding the amount of information presented in the Transparency of the evaluated scenario. Your opinion is:) in scenario 4: This assessment presented a result that had some divergence of opinions (little -40 %; appropriate -60 %). This scenario used a concept of photo album to display a sequence of images extracted from the application. The images highlighted with different colors the moment when the data subject granted permission to use or share his/her Personal Data. This scenario aimed to remind or indicate to the participant when the permission to use their Personal Data is granted.
The Transparency information was created following the specifications of the Permission of use metaevent from Personal Data entity and the meta-event Permission from Transfer entity. The index that 40 % pointing to little information was alarming, as it indicates that the application of the TR-Model did not supported the Transparency.
Analyzing the answers from the question Q2a (If your answer for the amount of information was Few or Exceeding, please describe what kind of information could be added or should be removed whether you thought there is too much information), we can assume that participants search for complementary information. For example: in the interface that highlighted the permission to share data, respondents also looked for information about who would be the recipient of the data. They also look for information about the purpose and the processor contact data in the image that presented the moment of granting permission to use the data.
In certain a way, this information could be available by the Controller in the software grant interface. The TR-Model may be improved to expand the access and sharing permission information to provide more information to data subjects, especially the information available from other TR-Model entities and related to grant information. Other forms of displaying this information than displaying information with images may also be considered even though it is not the purpose of TR-Model.
Finally, the results allow to conclude that the use of Readability and InfoVis were effective to support the development of Transparency for scenarios. We concluded this because the most of the respondents answered that they did not have difficulties to find information, the presentation formats were friendly and the amount of information was sufficient to provide understanding about the use of data.
The evaluations that presented results that can be considered as negative for Transparency disclosure were analyzed with the support of comments described by the respondents' essay questions. The information allowed the identification of points that must require improvement in the elements of HCI, mainly in the amount of information used for some types of Transparency. Specific improvements were also pointed out for a better distribution of interface information, specially for denser information such as Purpose of Use and Personal Data entities.
The next subsection presents the results and discussions of the Information Quality dimensions.

2) INFORMATION QUALITY (IQ) DIMENSIONS ANALYSIS
The IQ dimension evaluation aimed to verify the TR-Model effectiveness to provide appropriate content that could be used by data subject to analyze and understand the how his/her Personal Data are used.
The questions used to collect data (Table 11) for this analysis were: Q3, Q4, Q5, Q8, Q3a, Q4a and Q5a. The Figure 8 presents the graph with percentages for the answers to these questions, considering all scenarios evaluated.
The results presented in Figure 8 allowed to conclude that TR-Model was effective regarding to the quality of the content presented, since all responses had above 80% of responses for positive aspects. We highlight the dimension of the Objectivity had a positive evaluation above 90%.
The results that consider all scenarios allowed the assumption that the TR-Model was effective in supporting the IQ dimensions. Considerable percentages present that respondents considered the content of the information appropriated to use as information for analyzing the use of Personal Data.
Thus, considering the appropriated/positive answers for the evaluated dimensions we can consider: (1) That the Transparency in the scenarios was easy to understand which confirms that the metadata and metaevents present non-technical information and thus become known and understandable to data subjects in general; (2) that the Transparency is objective and presented the content without bias or unnecessary text and that it focused solely on providing the Transparency for the data subject to know the use of their data; (3) that the Transparency was complete, as it allowed the participants' to solve their possible doubts and so dispensed the need to search additional information from other sources; and (4) Transparency was relevant as presented information of their interests thus avoiding the analysis of unnecessary or non-value added information.
Although the TR-Model had positive evaluations, participants also presented not appropriated answers in the evaluations. Questions Q3, Q4 and Q5 were complemented with essay alternatives (Q3a, Q4a, Q5a) to justify / explain inadequate model evaluations. Suggestions, justifications, and criticisms had some similarity in the responses of questions Q3a (Understanding and Interpretation) and Q4a (Objectivity).
The negative assessment regarding the questions understanding and interpretation was justified by 54 respondents, while the negative assessment on Objectivity was explained by 29 respondents. The presented texts were not well detailed and their analysis required some degree of inference of the researchers. Thus, the following justifications were identified: (1) Design, (2) Lack of information or excess of information; (3) Information presentation; and (4) Extremely technical content.
The items 1 and 3 presented above are particular HCI features that may have interfered in the use of Transparency. The analysis of these elements was discussed in the previous section and we assumed the same considerations for IQ. The lack and excess of information may indicate the data subject's need for a specific information or the design of the information presented that may have left the environment ''polluted'' giving excess information the idea. Technical content is an issue to be reviewed in the TR-Model since this model aims to avoid this issue and, so, facilitate the information understanding.
The completeness dimension (Q5a) had negative evaluations justified by factors as: lack of information; and poorly presented information, which made it more difficult to understand. However, respondents did not explain whether they tried to find information in other sources. Another factor that influenced completeness was the personal need for TDP that led to the search for specific information that were not available in the evaluated scenario.
The lack of details about which scenario was informed by the respondents and the anonymization of the questionnaire makes it difficult to identify the specific scenario in which the evaluation occurred, but indicates the need for a general review, specially in two features: (1) identify whether the technical information was a design issue or metadata / metaevent description; and (2) verify Transparency needs that were not found by participants.
We also conducted an analysis to identify whether the overall results indicated are basically the same for each evaluations' specific situation. With this analysis, we tried to conclude whether there were any unique advantages or problems in any scenario that may not have been identified in the overall analysis and that may indicate any specific improvement in the TR-Model.
The results of the scenario IQ assessment are shown in Figure 9.
The chart in Figure 9 shows that respondents' opinions for each scenario and for each question had similar values when compared to the overall assessment in the scenario assessment. Thus, we assumed that the considerations already discussed can be applied to all evaluated scenarios.
Considering IQ evaluation, Scenario 4 presented a slightly unfavorable behavior in relation to the other scenarios in question Q5. Thus, the use of the photo album with static images may require improvements in the amount and list of information presented to avoid completeness issues.
Next section presents the considerations about TR-Model validation. VOLUME 8, 2020

F. TR-MODEL VALIDATION FINAL CONSIDERATIONS
The validation of the TR-Model aimed to verify the effectiveness of this model in the context of information coverage and friendly and quality Transparency information for the data subject. The TR-Model was developed concerning about the use of information by data subjects, but to provide such information, companies using Personal Data would need to use TR-Model to support their systems.
Regarding to TR-Model coverage, we assume that the TR-Model may be appropriate for users and therefore: • Comply with the Transparency requirements set in the GDPR, and LGPD texts. So, that the software application using the template can assure the data subject and Controller that the regulations are being met; • Meeting 90 % of validation participants' Transparency expectations informed by respondents in pre questionnaire through metadata and metaevents descriptions, thus ensuring that the user is effectively met by Transparency. The results related to the information coverage characteristics were very good. This was already expected as the regulations were observed during the requirements stage. Coverage validation was a way of checking whether it was possible to classify the TR-Model as a model in compliance with regulations.
The validation with the users had no pre-established expectations, because it was the first time the model, metadata, metaevents and descriptions were used. However, the scenario-based validation allowed to simulate interesting usage situations such as Scenario 01 -Purpose of use Transparency; and Scenario 02 -Personal Data Distribution, as well as Personal Data Transparency information that was created based on the TR-Model specifications.
The results showed that positive evaluations of HCI and IQ characteristics were predominant and allowed us to conclude that the TR-Model metadata, metaevents and descriptions were effective in providing information about the use of Personal Data focused on data subjects needs. The numbers, analyzing both the general and each one of the particular scenarios, show that a large majority of respondents considered the information presented as appropriate as they were able to understand, use and analyze it.
Some few suggestions and criticisms were made but they were not significant when compared to the amount of positive evaluations. These information focused on the need for more information than the information provided by the scenarios. This needs may be personal or unanticipated in test scenarios, but should be considered in future versions of TR-Model, as such needs may occur in other cases.
Next section presents the conclusions.

VII. CONCLUSION
This article presented the TR-Model, a Metadata Profile application intended to support the implementation of Personal Data Transparency information and to provide information about the use of Personal Data to data subjects. The main objective of this work was to provide data subjects with relevant, understandable, accessible and regulation-compliant information that allows them to understand how their Personal Data are used. TR-Model's main contribution is a set of specifications that determine what should be displayed for presenting Transparency Information and how/when it should be displayed in order to avoid ambiguity, misunderstandings or bias and present ease of understanding and relevant information to assure the user its rights for the Transparency. Thus, data subjects' main concerns regarding the use of their Personal Data are addressed as well as companies accomplishes their duties with regard to regulations.
The main objective of this research was then considered to be effectively achieved. Metadata Application Profile approach allowed the construction of a Domain Model: a set of entities, metadata, and metaevents. Specific descriptions of the metadata and metaevents use were proposed considering elements such as Readability, Infovis and Information Quality and mainly by the participation of data subjects in activities such as workshops, lectures and interviews in which Data Transparency issues were discussed.
Validations conducted through scenarios evaluation and user surveys showed that the TR-Model was very effective in supporting Transparency. This conclusion was done as: (1) the TR-Model met 90 % of the Transparency expectations presented by the data subjects in the surveys; and (2) evaluations performed related to the presentation form and the quality of the content information were evaluated positively by 85 % of the validation participants.
TR-Model was considered a model focused on the data subject, that can also be used by software development companies that use personal data.
From a software developer's point of view, it can also be assumed that applications and websites that adopt the TR-Model as the basis for their Transparency can provide a set of information of interest to their data subjects. Applications using TR-Model will also be compliant with the GDPR, as shown in Table 8, presented in Section V. We can also assure that the model presents, with its metadata and metaevents, the information required by the regulation.
With regard to data subjects, we believe that, by using TR-Model based Transparency software, they will be able to access a set of user-friendly and appropriate information on content, quantity and presentation. Consequently, data subjects' cognitive load usually required to analyze complex content, understand technical terms, classify information that might be considered as important or seek information from other sources will be decreased. It is also assumed that the data subjects will have more confidence in applications that disclose information about how their data will be used and, embedded in the data usage flow, can act to ensure the textit fair use of their personal data.
As the primary objective, we assumed that guidelines can be used effectively in applications and websites to provide data subjects with greater knowledge and trust.
In future works we intend to revise and improve the TR-Model metadata and meta-events to meet the needs and suggestions presented in the questionnaires and also to improve support to design patterns. We also intend to extend the model by including Personal Data traceability features so that TR-Model can also meet requirements of Personal Data Provenance. LUCIA VILELA LEITE FILGUEIRAS received the B.S., M.S., and Ph.D. degrees in electrical engineering from the Escola Politécnica, Universidade de São Paulo, in 1983Paulo, in , 1989, and 1996, respectively. She has been an Assistant Professor with the Computer Engineering Department, Escola Politécnica, Universidade de São Paulo, since 1990. Her research interests are in the areas of human-computer interaction, human-agent interaction, human-data interaction, and information visualization.
MARCELO MORANDINI received the master's degree in computer science from USP, in 1996, and the Ph.D. degree in systems engineering from the Federal University of Florianopolis, in 2002. He holds a postdoctoral position at The University of Tennessee, Knoxville, USA. He also works as a Ph.D. and master's degrees Supervisor in researches of the human-computer interaction in big data, data science and climate changes at the University of São Paulo. He is currently an Assistant Professor at the School of Arts, Sciences and Humanities (EACH), USP. His research interests include software engineering, requirements engineering, software architectures, usability, design, evaluation, and accessibility. VOLUME 8, 2020