# Privacy Preservation and Analytical Utility of E-Learning Data Mashups in the Web of Data
## 4 Privacy-Preserving Vertical Data Mashup Protocol
### Setup Protocol
#### 4.1.2 Build the Mashup Data Schema  
Once the mashup coordinator has identified the data providers that can satisfy the data request, the mashup coordinator proceeds to build the final schema of the mashup dataset. This data schema should reflect the following: the identifier attribute that will be used as a connector in the integration process, the _aggregate_ (or join) _quasi-identifier_, i.e., the one resulting from joining the quasi-identifiers of the different data partitions, the privacy level that will be applied to the aggregate quasi-identifier, and the set of confidential attributes. Considering the problem of a large dimension in aggregate quasi-identifiers, we propose that these be divided into smaller quasi-identifiers [52], thereby allowing mashup coordinators to specify multiple aggregate quasi-identifiers. The division of quasi-identifiers prevents a significant loss of information during the masking process because as the number of attributes decreases, less perturbation may be required to achieve \(k\)-anonymity. Without loss of generality and for the sake of simplicity, we will describe the protocol for a single aggregate quasi-identifier. To fulfill most existent data providers' privacy requirements, the mashup coordinator must select the most restrictive \(k\) value--i.e., the highest \(k\)--from those specified in the data schemata of the providers to be applied to the aggregate quasi-identifier. In the following, we draw the suggested enactment of the setup protocol in a federated RDF view of an underlying relational data source. We use the RDF view materialization strategy described in [63] to build the linked data mashup. Although it was initially proposed to improve query performance and data availability, we applied it to implement the setup protocol on relational data sources. The mashup materialization depends on the federated schemata, the aggregate schema, the connector attribute, and the quasi-identifiers, as the setup protocol requires. Concerning the LDP 1.0 specification, two alternative implementations must be considered for the mashup. On the one hand, we can consider a single LDP instance consisting of several resource containers. On the other hand, we can consider several separate LDP instances, each managing their own triplestores. We may restrict the explanation of the implementation to the latter option without losing generality. Besides, it can be a more realistic privacy-preserving scenario, where semi-honest agents from independent LDP instances can be involved. The materialization of an RDF view is illustrated on OULAD [62]. As for illustrative purposes, we are limiting the description to mashup two data providers: the OULAD Student Demographics (\(A\)) and Student Activities (\(B\)) parts. We also define the oula namespace to map the linked data attributes of the OULAD schema, e.g., student or course, as long as convenient linked data vocabularies, e.g., foaf and schema.org, might not be easily found or mapped to OULAD data attributes. * Each tuple \(t\) in \(A.studentInfo\) produces the following set of RDF triples: [leftmargin=*]
* \(\texttt{oula:student\#.id\_student}\) rdf:type foaf:Person
* For each tuple \(t\) in \(A.studentInfo\) and each local QI attribute identifiable as such in \(A\), generate one RDF tuple depending on whether there is a corresponding term in a standard linked data vocabulary to map the local QI attribute, as explained next with the OULAD example. * If local QI attributes of the \(A.studentInfo\) table are considered to be _code_module_ and _region_, then generate the following RDF triples--note that, in the case of _code_module_ and _region_ attributes, no standard vocabulary terms are found or provided: [leftmargin=*]
* oula:student\#.id_student oula:registeredIn oula:course#.code_module_ oula:student\#.id_student oula:region \(t.studentRegion\)  
Thus, we can obtain a mashed-up dataset formed by all or part of the attributes of the previous list.