## 5 Extending the Mediator-Wrapper Architecture  
It is evident that currently, in the MW architectural pattern, the responsibility of representing data, schemas, and queries cannot be assigned to any of the existing component types without assigning too much responsibility onto them. For this reason, the system designer is forced to decide whether to assign this responsibility to the highest mediator layer or a user application. Due to the nature of the problem being the assignment of a system functionality to a component type, and all existing component types being finely utilized via their given rules, it has become obvious that there is a component gap in the upper layer of the MW architecture. In other words, due to RMe3, there is a task that no component type is adequate to additionally handle. Hence, there is a requirement for another type of system component that could take on the responsibility of representing system data. Therefore, in this article, we propose a new theoretical component, which we name a mask. A mask masks the system at a certain point in the schema hierarchy into a representational form that can be easily handled by users, effectively taking on the responsibility of representing the system. The mask should be placed at the top of the architectural hierarchy, positioned between the users and highest mediator layer. Placing the masks on top of the architectural hierarchy effectively creates a mask layer. Consequently, this extended variant of the MW architecture is called a MMW architecture (Figure 7 displays the positioning and relationship of the mask components and layer with other components in the architecture). Using the mask, the system's representational logic is decoupled from the system's mediation logic and the user's application logic. Furthermore, by adding the mask as a system component type, the system has a finer separation of responsibility and gains benefits that help expand and simplify its usability. If a mask supporting a form of standardized technological access to data is implemented, then access to the system becomes available to a wide variety of applications implemented over that standard of access. \begin{table}
\begin{tabular}{c c} \hline
**Reference (Project)** & **Data Representation and Access** \\ \hline
[13] & \\
[15] & graph \\
[14] & \\ \hline
[44] & JDBC \\ \hline
[41] & Web application \\ \hline
[43] & \\
[44] & \\
[38] & \\
[20] & tabular data \\
[45] & \\
[21] & \\
[47] & \\ \hline
[23] & \\
[22] & key-value \\
[19] & \\ \hline
[17] & semantic web \\
[18] & plain text \\ \hline \end{tabular}
\end{table} 
Table 1: _Cont._Observing the mask with an implementation example, one could implement a mask in the form of a REST service with requests over uniform resource locators (URLs) returning resources in JSON, akin to the system access shown in [40]. In this way, any application built to send requests to a REST service and receive its responses can now be used as a client application. Another interesting way to look at a mask component is to imagine it as an inversed wrapper, as illustrated by the flow and dissemination of data in Figure 8. While the wrappers concern themselves with adapting the source data from the outside world to accommodate the data source integration system's standard, the masks concern themselves with adapting the standardized data to accommodate the outside world. Additionally, wrappers import data from multiple sources, while masks export data to multiple destinations. Hence, the data source integration system can now be seen as a single logical point of collecting, transforming and providing data in various formats. As was the case with wrappers and mediators, the rules for masks are set as follows:  
**RMa1**: A mask should be positioned at the top of the architecture. **RMa2**: A mask only connects to a single mediator. **RMa3**: A mask is used for representational purposes, representing a schema, querying data, and representing the result data.