An approach for semantic integration of heterogeneous data sources

Introduction

The large availability of data within the enterprise context and even in any inter-enterprise context, the problem arises of managing information sources that do not use the same technology, do not have the same data representation, or that have not been designed according to the same approach. Thus, in general, gathering information is a hard task, and one of the main reasons is that data sources are designed to support specific applications. Very often their structure are unknown to the large part of users. Moreover, the stored data is often redundant, mixed with information only needed to support enterprise processes, and incomplete with respect to the business domain. Collecting, integrating, reconciling and efficiently extracting information from heterogeneous and autonomous data sources is regarded as a major challenge. Over the years, several data integration solutions have been proposed:

• Distributed databases can be considered the first attempt to integrate databases. Data, instead of being stored on a single machine, is stored on different machines. Compared to the centralized case, database schema are more complicated by the need to physically distribute data over multiple machines. Distributed databases require the complete integration of existing systems into a single homogeneous database. This is difficult to achieve due to technical issues (prohibitive conversion costs) and organizational difficulties (existing DBMSs belong to different organizations).

• Federated databases have been proposed to address these limits. They are a set of multiple independent sources each of which can exchange information with the others. A connection is established for each pair of sources, and such architecture is particularly suitable when communications in the system occur predominantly between pairs of sources.

The solution often adopted consists of the cooperative information systems (Fig. 1), in which there are two types of components: mediator and wrapper. The mediator coordinates the data flow between local sources and user applications. The mediator is not responsible for storing data, since it only stores a virtual and global view of real data (or global schema) and the mappings between the global and local views. In this way, applications will run queries over the virtual view. It will then be the mediator to build queries for individual sources of information. Instead, wrappers are software components that interact directly with their respective local sources as follows:

• to translate the conceptual schema of the local source into a global language;

• to submit queries to local sources;

• to retrieve results by sending them to the mediator, which will provide the user with a unified result.

This approach allows provide users with a unified interface (called mediated schema or global schema or global view) of sources, freeing them from manually managing each source. The open research problem is the need of a not statically constructed mediator, but the need of querying mediator responsible of accessing heterogeneous and dynamic data sources trough a global view without integrating or migrating the local data source. To overcome this research problem, this paper proposes an ontology based framework to support the analysis, acquisition and processing of data from heterogeneous sources, Data Integration Framework (DIF). It exploits domain ontology and provides a generalization of both global view and local view approaches, based on data virtualization. The proposed framework addresses this issue by providing access to the data layer, consisting of autonomous data sources (e.g., DBs, spreadsheets), through the mediation of a global domain view, given in terms of an ontology, and the use of a semiautomatic mapping between the data layer and the ontology. Users do not have to know details of the data sources and can express their information needs as queries over the conceptual domain model. The proposes framework uses the ontology and mapping to reformulate the user queries into standard DB queries that are executed directly by the database management systems (DBMSs) of the sources. The global view provides a unified view of real data, so that applications and users who use data will have the perception of accessing a single data source rather than multiple sources. In this context, the work faced aspects of acquisition, integration and processing of heterogeneous data sources.

The paper is organized as follows. ‘Aspects of a Data Integration Process’, ‘Related Work’ presents, respectively, problems that characterize data integration and proposed solutions in the state of the art. ‘Data Integration Framework’ presents in detail the approach and architecture of the software system developed to support the integration of heterogeneous sources. ‘DIF Supporting Tool’ presents the DIF tool design and the main algorithms implemented. ‘Case Study’ presents a case study in order to show the results of the proposed solution. Finally, ‘Conclusion’ concludes this paper by submitting concluding remarks and mentioning some research issues related to data integration that are not addressed in this paper.

Aspects of a data integration process

Data integration systems using the mediation approach are characterized by an architecture (Fig. 1) based on a global schema and a set of sources schema. The sources contain real data, while the global scheme provides a unified, integrated and reconciled view of local sources. The main components are: the mediator, which coordinates data flow between local sources and user applications, and wrappers, which directly interact with their respective local sources. Designing a data integration system is a complex task, which involves dealing with different issues.

The first issue is related to the heterogeneity of the sources, as sources adopt different models and data storage systems. This poses problems in defining the schema/global view. The purpose is to provide a view with an appropriate level of abstraction for all data in the sources.

The second issue is how to define mappings between global schema and local sources: in literature, in order to model the correspondences between the schemes, different approaches (Lenzerini, 2002) have been proposed as global-as-view and local-as-view. With global-as-view (GaV) approach the global schema is expressed in terms of views over data sources. With local-as-view (LaV) approach the global schema is specified independently of the sources, and the relationships between global schema and sources are established by defining each source as a view built over the global schema. Differences between the two approaches are discussed in Lenzerini (2002). In order to overcome the limits of GaV and LaV approaches, techniques that combine the benefits of these approaches have also been proposed, mitigating their disadvantages in order to provide an alternative to data integration that is more flexible and scalable. The most interesting techniques are GLaV (Global and Local as View) (Katsis & Papakonstantinou, 2009; Arens et al., 1993) and BGLaV (BYU Global Local as View) (Xu & Embley, 2004).

Once the mapping approach is defined, it is necessary to define the methods and techniques to be used to generate mappings between the global and the local schema. This activity is called Schema Matching. The set of mappings is called alignment. A matching process (Shvaiko & Euzenat, 2005) (Fig. 2) defines an alignment (A′) for each pair of schemas (o₁, o₂), making use of input parameters p if necessary (for example, thresholds, weights), a previously generated input alignment (A) and additional external resources r.

We can now generate the global schema based on mappings defined in the schema matching activity. This activity is called Schema Merging. A merging process (Fig. 3) consists of integrating several existing schemes (o₁, o₂, …, o_n) into a single global schema (O) based on the correspondences generated by the schema matching process A, any input parameters p and external resources r. Different techniques and methodologies about schema merging have been proposed in the literature (Lee & Ling, 2003; Fong et al., 2000; Chiticariu, Kolaitis & Popa, 2008; Kong, Hwang & Kim, 2005).

Another issue is related to data storage: compared to managed data there are two approaches, called materialization and virtualization. With materialization, data is also present in the global schema. On the opposite, in the virtualization approach, data that resides in sources is only available when query processing activity is executed.

Once we merged local views into one unified global view, we can process a query posed over the global schema. This activity is called Query Processing, that is how to express it in terms of a set of queries that can be processed by the sources acquired. In the LaV approach the proposed solutions consist of query rewriting (or view-based query rewriting) and query answering (or view-based query answering). In the GAV approach query unfolding techniques are used. The differences between the two approaches are discussed in Lenzerini (2002).

Once the query processing activity is performed, data from different sources need to be interpreted, that is, transformed into a common representation. Therefore, they must be converted, reconciled and combined.

Table 1 summarizes the approaches used in mappings definition between the global schema and local ones.

Based on the comparison approaches in Table 1 it is possible to observe that:

• The LaV approach involves a priori presence of a global schema, which must be well-built in terms of concepts and relationships between them. If it is not well-built, or the integrated schemas differ greatly from each other, the global schema must be continually modified, also taking into account the previously integrated data sources. If not, the changes affect only the global schema.

• With GaV approach, the global schema is incrementally built: it is modified every time a new data source is integrated, adding and/or modifying concepts and relationships based on current and previously integrated data sources. Conversely, in the LaV case, changes do not impact previous integrated data sources (if the overall schema is well-built).

• The LaV approach offers greater scalability when the number of integrated data sources increases, but when that number is relatively small, and the global schema is not well-built, the GaV approach increases the quality of global schema.

Moreover, in the context of semantic integration, the hybrid approach is surely the best solution but it reduces the reuse of local ontologies, since they have to refer to a common vocabulary. Therefore, considering a possible future reuse of local the ontologies, it is possible to combine the presented approaches differently in order to support different cases and to present a data integration approach in order to provide different solutions as needed. The proposed approach, called DIF is based on these observations and seeks to combine the GaV and LaV approaches, exploiting ontologies to reach the goals.

Related Work

Several systems, methodologies and approaches have been proposed in literature to support data integration from heterogeneous sources, also based on ontologies (Calvanese, Lembo & Lenzerini, 2001).

To overcome problems due to semantic heterogeneity, it is useful to use ontologies (Wache et al., 2001). Depending on how ontologies are used, data integration systems can adopt different approaches, such as single ontology (adopted in SIMS (Arens et al., 1993; Arens, Hsu & Knoblock, 1996)), multiple ontology (adopted in OBSERVER (Mena et al., 1996b; Mena et al., 1996a)) and hybrid (adopted in KRAFT (Preece, Hui & Gray, 1999; Preece et al., 2000) and COIN (Goh et al., 1999)).

More recently in Civili et al. (2013) it is proposed Mastro Studio, a Java tool for ontology-based data access (OBDA). Mastro manages OBDA systems in which the ontology is specified in a logic specifically tailored to ontology-based data access and is connected to external data management systems through semantic mappings that associate SQL queries over the external data to the elements of the ontology.

TSIMMIS (The Stanford-IBM Manager of Multiple Information Sources) (Chawathe et al., 1994) is based on an architecture that exposes a wrapper hierarchy (called Translators) and mediators.

TSIMMIS approach is global-as-view. Wrappers convert data to a common data model called OEM (Object Exchange Model) and mediators combine and integrate them. The global scheme consists of a set of OEM objects exported by wrappers to mediators. Mediators are specified using a language called Mediator Specificaion Language (MSL). Queries are expressed in MSL or in a specific language called LOREL (Lightweight Object Repository Language), an object-oriented extension of SQL. Each query is processed by a module, the Mediator Specification Interpreter (MSI).

It should be emphasized that TSIMMIS does not implement a real integration, as each mediator performs integration independently of each other. It means that does not exist the concept of a unified global scheme. The result of a query could be seen inconsistent and completely different from other mediators. This form of integration is called query-based.

GARLIC integration system is based on an architecture with Data Repositories at lowest level, which represent the data sources. Above each data repository we find a wrapper (called Repository Wrapper), which is responsible for communication between a data repository and the rest of the system. In addition, each wrapper ensures the transformation of the local schema of a source into a unified schema and transforming user queries into queries executable by data source.

The global schema has an object-oriented data model, managed by the Query Services and Runtime System components, and stored in the Metadata Repository, based on the ODMG standard. ODMG objects are exported by wrappers using Garlic Data Language (GDL), based on the ODL (Object Definition Language) standard.

Unlike the TSIMMIS system, there is no mediator concept in GARLIC, and the integration of ODMG objects from different sources is performed by wrappers.

MOMIS (Mediator Environment for Multiple Information Sources) (Orsini et al., 2009; Beneventano & Bergamaschi, 2004) is a data integration system that manages structured and semistructured data sources. MOMIS is based on I³ architecture (Hull & King, 1995), consisting of several wrappers and a mediator.

The integration methodology starts with an extraction activity where user uses a wrapper that transforms the structure of a data source into a ODL_I3 (Object Definition Language) model based on descriptive logic. The integration process generates an integrated view of data sources using global-as-view approach, building the global schema incrementally. At the end of the MOMIS integration process, starting when the query is posed by the user over the global schema, the mediator generates a OQL_I3 query and sends it to wrappers, which translate it into a query executable from the corresponding data source.

Ontology-based data access is by now a popular paradigm which has been developed in recent years to overcome the difficulties in accessing and integrating legacy data sources (Xiao et al., 2018). In OBDA, users are provided with a high level conceptual view of the data in the form of an ontology that encodes relevant domain knowledge. The concepts and roles of the ontology are associated via declarative mappings to SQL queries over the underlying relational data sources. Hence, user queries formulated over the ontology can be automatically rewritten, taking into account both ontology axioms and mappings, into SQL queries over the sources.

Overall, the large part of the analysed approaches, use their own description language, for both local and global schemas, and queries. However, if a generic external application wants to communicate with one of the systems presented, it should know the specific query language and/or the specific language used to describe the schemas. The problem of translation between languages is widened if we consider interoperability with the Web. For this reason, the proposed approach, Data Integration Framework (DIF), exploits the use of ontologies supported by a semiautomatic mapping strategy.

Data Integration Framework

The proposed Data Integration Framework, is a generalization of both GaV and LaV approaches, based on data virtualization, and provides the possibility to define a mappings in both GaV approach (a correspondence between a view expressed in terms of the global schema and a view expressed in terms of the local schema) and LaV approach (correspondence between a view expressed in terms of the local schema and a view expressed in terms of the global schema). In addition, to overcome problems due to semantic heterogeneity and to support interoperability with external systems, ontologies are used as a conceptual schema to represent both data sources to be integrated and the global schema, and therefore each mapping is defined as a correspondence between elements of ontologies: concepts (or classes), datatype properties, and object properties. Since the data virtualization approach is also used to define local ontologies, the construction of an ontology to represent a local source is guided by additional mappings, called source-mappings, defined as correspondences between elements of local ontology and elements that characterize the source itself (for example, for a relational source a mappings will be defined as a correspondence between an ontology concept and the table that represents it).

In the proposed solution, the query rewriting is used to reformulate a query posed over the global ontology into a set of queries posed over the local ontologies. This is due to the choice of using ontologies also to describe data sources to be integrated. In this way, though, the mediation process is not completed yet, since local ontologies do not contain real data. To complete the mediation process, a second query translation task is required to reformulate a query posed over the local ontology into a set of queries posed over the corresponding source.

The framework must be able to handle both the integration process and the mediation process, which is shown in Fig. 4, making activities as automated as possible.

The integration process is divided into the following activities:

1. Source Wrapping: for each source you want to integrate, you build an ontology to describe it. In addition, source-mappings are defined between the ontology and the data source, which will be subsequently used during the mediation process.

2. Schema Matching: for each local ontology, mappings are generated between it and global ontology. The matching activity generates mappings between a source ontology and a target one. Therefore, considering as target ontology the local one, it is possible to generate LaV mappings. Conversely, the followed approach will be GaV. Mappings are eventually validated or modified by the integrator designer. If the number of data sources to be integrated is 1, global and local ontologies are the same.

3. Schema Merging: each local ontology, taking into account the set of mappings defined in the previous activity, is integrated into the global ontology and the mapping table is updated. At this stage, global ontology is built incrementally.

The mediation process, however, following a query submission, is divided into the following phases:

1. Global Query Processing: a query posed over the global ontology is reformulated, through rewriting, into a set of queries posed over local ontologies, using the mapping table generated at the end of the integration process;

2. Local Query Processing: each local query is reformulated into a set of queries over the corresponding data source, using source-mappings generated in the source wrapping activity. This set of queries, once executed, allows you to retrieve the real data.

3. Data Reconciliation: extracted data from the previous activity is reconciled and combined before being presented to the user.

Local and global ontologies are expressed in OWL-DL (https://www.w3.org/TR/owl-features/), whose basic elements are classes c, object properties op and datatype properties dp. Instances i are not considered mapping because the data management approach is virtualization rather than materialization.

DIF Supporting tool

The tool, designed and developed to support the DIF framework, presents the typical architecture of integration systems based on the mediation approach (Fig. 5), providing two main components: mediator and wrapper.

According to Definition 4.1 and the description of the activities to be performed during integration and mediation processes, the architecture is composed by Acquisition, Integration and Mediation subsystems.

 
 
<map> 
<Cell> 
   <entity1> 
     <edoal:Property  rdf:about="src#Name"/> 
   </entity1> 
   <entity2> 
     <edoal:Property> 
       <edoal:or rdf:parseType="Collection"> 
          <edoal:Property> 
            <edoal:and  rdf:parseType="Collection"> 
               <edoal:Property  rdf:about="trg#Name"/> 
               <edoal:PropertyDomainRestriction> 
                 <edoal:class> 
                   <edoal:Class  rdf:about="trg#Infirmary"/> 
                 </edoal:class> 
               </edoal:PropertyDomainRestriction> 
            </edoal:and> 
          </edoal:Property> 
       </edoal:or> 
     </edoal:Property> 
   </entity2> 
   <relation>=</relation> 
   <measure  rdf:datatype=’http://www.w3.org/2001/XMLSchema#float 
       ’>0.4</measure> 
</Cell> 
</map>    

 
_________________________________________________________________________________ 
Algorithm 1 SPARQL rewriting___________________________________________________________ 
Input: SPARQL query Qin, mapping table MT 
Output: SPARQL query Qout 
 1:  GPin ← graph pattern of Qin 
 2:  GPout ← GPin after replacing IRIs in FILTER, using 1:1 mappings MT 
 3:  GPout ← Triple pattern rewriting(GPout, MT, predicate) 
 4:  GPout ← Triple pattern rewriting(GPout, MT, object) 
 5:  GPout ← Triple pattern rewriting(GPout, MT, subject) 
 6:  Qout ← new query containing GPout_______________________________________________________________    

Case Study

In order to validate the proposed framework, a case study was conducted using three heterogeneous data sources (two relational data sources, and one semi-structured, specifically a spreadsheet) designed in different contexts, related to the health domain applications.

As initial step the first source is acquired, which entity-relationship diagram and local view are shown in Fig. 6. At this point its local view becomes the new virtual view. In this case the only steps that must be performed are those of source wrapping and annotation of the schema. The extraction of semantic information, through the schema annotation activity, is necessary as this information will be used to generate the mapping with the source schemes that will be acquired later. The output of the schema annotation activity is a set of annotations AN, one for each element e_i of the schema, where each annotation AN_i is a triple (tok_i, POS_i, sense_i) composed by:

• tok_i: the token of the element e_i;

• POS_i: the lexical category of the token tok_i;

• sense_i: the sense of the token tok_i for the lexical category POS_i, as output of the disambiguation process.

In Table 3 is shown an extracted of the output of the schema annotation activity performed over the first local view.

Then, the second source is acquired, which entity-relationship diagram and local view are shown in Fig. 7.

As in the first integration step, the source wrapping and schema annotation activities are performed. Subsequently, the schema matching activity is performed. To this aim, the following thresholds setting is adopted: ${\displaystyle {\alpha }_{\equiv }=0.2}$ ${\displaystyle {\alpha }_{⊑∕⊒}=0.3}$ ${\displaystyle {\alpha }_{idk}=0.8}$ ${\displaystyle \beta =0.8}$ Once the schema matching is completed the mappings are obtained. Some examples are: ${\displaystyle M\left(Hospital,Hospital,\equiv ,1,\left[\left(Address,Address,1\right),\left(Name,Name,1\right),\left(Code,Hosp\text{\_}Code,0.99\right)\right]\right)}$ ${\displaystyle M\left(Oerating\text{\_}Room,Surgery,⊒,1,\left[\left(Code,Surgery\text{\_}Code,0.99\right),\left(NumTables,NumberTables,0.84\right)\right]\right)}$ ${\displaystyle M\left(Supplier,Person,⊑,1,\left[\left(Name,Name,1\right),\left(Address,Address,1\right),\left(Code,Code,1\right),\left(City,CityBirth,0.99\right)\right]\right)}$ ${\displaystyle M\left(Office,Lab,idk,1,\left[\left(Type,TypeLab,0.99\right),\left(Name,NameLab,0.99\right),\left(Code,Code\text{\_}Lab,0.99\right)\right]\right)}$

During the validation step of the mappings, the user should to delete the mapping M(Office, Lab) and replace the semantic relationship of the mapping M(Operating_Room, Surgery) to (≡), as that relationship, in the Surgery class of the first scheme, refers to a room in which a doctor can be consulted, while in the second scheme to an operating room. He also should to delete the correspondence between properties City and CityBirth in the mapping M(Supplier, Person). The M(Office, Lab) mapping is returned because the two classes match all properties and, as a result, the contextual similarity measure is 1. This mapping must be deleted otherwise during the schema merging activity a wrong association relationship will be created between the two classes. The α_idk threshold was chosen at 0.8 to highlight this observation. If association relationships have no reason to be created, the schema matching activity should be performed with a high value for the α_idk threshold. The threshold value α_⊑∕⊒ was chosen equal to 0.3 because, if it was lower, the mapping M(Ward, Person) would be added a semantic relationship of hyponymy, but this mapping is wrong.

In the set of mappings should also to appear the mapping 1:n M(Hospital, {Hospital, Statistics}) but is not returned because of the threshold α_idk high. To take into account the representation of the hospital concept through the Hospital and Statistics classes, there are therefore two alternatives. The first one is to keep the threshold value of α_idk high and insert manually the mapping. The second one is to lower the threshold and eliminate the other mappings in which there is a idk relationship, except the mapping except the mapping mentioned above. However, the following mapping is also obtained: M(Hospital, {Hospital, Statistics}) = [M(Hospital, Hospital), M(Hospital, Statistics)] = [ M(Hospital, Hospital,  ≡ , 1, [ (Address, Address, 1),  (Name, Name, 1),  (Code, Hosp_Code, 0.99)]), M(Hospital, Statistics, idk, 0.21, [ (NumAdmission, NumberAdmission, 0.88),  (NumDead, NumberDead, 0.80),  (NumOperation, NumberOperation, 0.88)])] The global view is initially the local view of the first source. At this point the schema merging activity is performed. The new global view is shown in Fig. 8. As an example, considering the mapping M(Hospital, {Hospital, Statistics}). Assuming the prefix merged# to the global view, the prefix hospital_1# to the first local view and hospital_2# to the second local view, once the schema merging activity is performed, the representation of the mapping M(Hospital, {Hospital, Statistics}), will be as follows:

 
 
<map> 
   <entity1> 
     <edoal:Class  rdf:about="merged#Hospital"/> 
   </entity1> 
   <entity2> 
     <edoal:Class> 
       <edoal:or rdf:parseType="Collection"> 
          <edoal:Class  rdf:about="hospital_1#Hospital"/> 
          <edoal:Class  rdf:about="hospital_2#Hospital"/> 
       </edoal:or> 
     </edoal:Class> 
   </entity2> 
   <relation>=</relation> 
</map> 
<map> 
   <entity1> 
     <edoal:Class  rdf:about="merged#Statistics"/> 
   </entity1> 
   <entity2> 
     <edoal:Class> 
       <edoal:or rdf:parseType="Collection"> 
          <edoal:Class  rdf:about="hospital_2#Statistics"/> 
       </edoal:or> 
     </edoal:Class> 
   </entity2> 
   <relation>=</relation> 
</map>    

In a similar way the correspondences for the other elements of the schemes are defined.

The third source acquired is a composed of different spreadsheets. Some parts of the spreadsheets are shown in Fig. 9.

An extracted of the local view of the third source is shown in Fig. 10.

After source wrapping and schema annotation activities are performed, the schema matching activity is performed using the following threshold values: ${\displaystyle \begin{array}{ccc}\hfill {\alpha }_{\equiv }& \hfill =\hfill & 0.2\hfill \\ \hfill {\alpha }_{⊑∕⊒}& \hfill =\hfill & 0.3\hfill \\ \hfill {\alpha }_{idk}& \hfill =\hfill & 0.95\hfill \\ \hfill \beta & \hfill =\hfill & 0.1\hfill \end{array}}$

The threshold value of the contextual similarity β is equal to 0.1 because, although there are classes designed with different attributes, they represent the same concept of the real world and for which, therefore, the mappings must be returned. This situation is managed by lowering the value of β but not those of α_⊑∕⊒ and α_≡. The high value of α_idk is meant to filter almost all idk mappings, since they are not correct. It has been increased through tuning activities, in order to filter all those concepts with an empty set of mappings between their properties. In this way we can provide to the user just few mappings to be validated. An example of returned mappings to the user, are the following: ${\displaystyle M\left(Hospital,Hospital,\equiv ,1,\left[\left(Code,Hospital\text{\_}Code0.99\right),\left(Name,HospitalName,0.99\right),\left(Address,Street\text{\_}Address,0.99\right),\left(City,City,1\right)\right]\right)}$ ${\displaystyle M\left(Hospital,Rehabilitation\text{\_}Hospital,\equiv ,0.5,\left[\left(Code,Hospital\text{\_}Code,0.99\right),\left(Name,HospitalName,0.99\right),\left(Address,Street\text{\_}Address,0.99\right),\left(City,City,1\right)\right]\right)}$ ${\displaystyle M\left(Hospital,Children\text{\_}Specialt{y}_{H}ospital,\equiv ,0.33,\left[\left(Code,Hospital\text{\_}Code,0.99\right),\left(Name,HospitalName,0.99\right),\left(Address,Street\text{\_}Address,0.99\right),\left(City,City,1\right)\right]\right)}$ ${\displaystyle M\left(Hospital,Psychiatric\text{\_}Hospital,\equiv ,0.5,\left[\left(Code,Hospital\text{\_}Code,0.99\right),\left(Name,HospitalName,0.99\right),\left(Address,Street\text{\_}Address,0.99\right),\left(City,City,1\right)\right]\right)}$ ${\displaystyle M\left(Person,Contact\text{\_}Person,⊒,0.5,\left[\left(Address,Email\text{\_}Address,0.99\right),\left(Name,Name,1\right)\right]\right)}$ ${\displaystyle M\left(Person,Administrator,⊒,1,\left[\left(Address,Email\text{\_}Address,0.99\right),\left(Name,Name,1\right)\right]\right)}$

During the validation step of the mappings, the user should to insert a idk mapping between the Hospital and Specialized_Hospital_Characteristics classes, delete the correspondences between the Address and Email_Address properties in the mapping M(Person, Administrator) and replace the semantic relationship of the mapping M(Person, Contact_Person) to idk. He also should to insert a mapping ≡ between the Operating _Room and Surgery classes, as they both refer to an operating room. Besides, he should to replace the semantic relationship of the mappings M(Hospital, Rehabilitation_Hospital), M(Hospital, Psychiatric_Hospital) and M(Hospital, Children_Specialty_Hospital) to ⊒. Since the user has knowledge about the application domain, he is able to recognize which mappings must to be deleted or not. Once the schema matching activity has been completed, the next step is the schema merging activity. The new global view, in which all attributes are not shown, is shown in Fig. 11. After the third source is integrated, a lot of mappings are included, but many of them, as well as an example of the mapping table, are removed from the example, in order not to create confusion in the reader in understanding the full integration process.

 
 
SELECT ?x ?y 
WHERE  {?x rdf:type  merged#Hospital. ?x merged#Name ?y}    

 
 
SELECT   ?x ?y 
WHERE 
   { ?x   rdf:type  hospital_1#Hospital. 
         ?x hospital_1#Name   ?y ; 
               rdf:type  hospital_1#Hospital 
   }    

 
 
SELECT   ?x ?y 
WHERE 
   { ?x   rdf:type  hospital_2#Hospital. 
       ?x hospital_2#Name   ?y ; 
          rdf:type  hospital_2#Hospital 
   } 

 
 
SELECT   ?x ?y 
WHERE 
   { ?x   rdf:type  hospital_3#Hospital. 
      ?x   hospital_3#HospitalName   ?y ; 
               rdf:type  hospital_3#Hospital 
   } 

 
 
SELECT ?x ?name 
WHERE { ?x rdf:type  merged#Person. ?x merged#Name ?name}    

 
 
SELECT   ?x ?name 
WHERE 
   { ?x   rdf:type  hospital_1#Professional 
       { ?x hospital_1#Name   ?name ; 
               rdf:type  hospital_1#Supplier} 
     UNION 
       { ?x hospital_1#Name   ?name ; 
               rdf:type  hospital_1#Professional} 
   }    

 
 
SELECT   ?x ?name 
WHERE 
   { ?x rdf:type  hospital_2#Person. 
     ?x hospital_2#Name   ?name ; 
          rdf:type  hospital_2#Person 
   } 

 
 
SELECT   ?x ?name 
WHERE 
   { ?x rdf:type   hospital_3#Administrator. 
         ?x hospital_3#Name   ?name ; 
               rdf:type  hospital_3#Administrator 
   }    

 
 
SELECT ?person ?city 
   WHERE { ?person  rdf:type  merged#Person. ?person  merged#Address ? 
       city 
     FILTER  regex(?city, "Benevento", "i") }    

 
 
SELECT   ?person ?city 
WHERE 
   { { ?person  rdf:type  hospital_1#Professional 
     { ?person  hospital_1#Address ?city ; rdf:type  hospital_1# 
          Professional} 
       UNION 
     { ?person  hospital_1#Address ?city ; rdf:type  hospital_1# 
          Hospital} 
       UNION 
     { ?person  hospital_1#Address ?city ; rdf:type  hospital_1# 
          Supplier} 
     } 
     FILTER  regex(?city, "Benevento", "i") 
   }    

 
 
SELECT   ?person ?city 
WHERE 
   { { ?person  rdf:type  hospital_2#Person 
     { ?person  hospital_2#Address ?city ; rdf:type  hospital_2#Person 
          } 
       UNION 
     { ?person  hospital_2#Address ?city ; rdf:type  hospital_2# 
          Hospital} 
     } 
     FILTER  regex(?city, "Benevento", "i") 
   } 

 
 
SELECT   ?person ?city 
WHERE 
   { ?person  rdf:type  hospital_3#Administrator ; 
   hospital_3#Street_Address   ?city ; rdf:type  hospital_3#Hospital 
     FILTER  regex(?city, "Benevento", "i") 
   }    

Conclusions

The purpose of this paper is to allow unified access to heterogeneous and independent source data, offering a data integration approach that addresses all the issues discussed. The architecture adopted is that of mediation systems, which create a virtual view of the real data and allow to external applications to access data through that view in a transparent manner. Transparency is guaranteed by translating queries posed over the virtual view into queries that are directly executable from local sources.

The proposed approach allows unified access to heterogeneous sources through the following activities:

• Source wrapping: the initial activity is the construction of an ontology for each source you want to integrate, whose structure is subsequently refined by using information extraction techniques to improve the quality of ontology.

• Schema matching: ontologies are then put in a matching process in order to automatically search mappings between the elements of the structures, using both syntax-based and semantic-based techniques. Mappings are identified by combining both semantic and contextual characteristics of each element. These mappings are then validated and, if necessary, modified by the user.

• Schema merging: based on the generated mappings, a global ontology is created which is the virtual view of the system.

• Query reformulation: at this stage, a query posed over the virtual view is reformulated into a set of queries directly executable by local sources. The reformulation task is performed automatically, generating an execution plan of the reformulated queries, with the possibility for the user to modify each single query.

Overall, the approach is semi-automatic, but compared to existing systems, the user’s effort is minimized as he only intervenes in the matching configuration activity, by setting the threshold values for the mappings generation, and mappings validation. Both simple (1:1) and complex mappings (1:n, n:1 and n:m) are generated.

The outlined approach is supported by a specially designed and developed software system. The system provides a first level of abstraction of the activities and components involved in their execution and a second level of component specialization. Although the design of the system is aimed at covering all aspects of data integration described so far, implementation has some limitations. In particular, the acquisition of unstructured sources is not yet contemplated in development and the data reconciliation process requires the development of appropriate components. Except for such activities, integration and mediation processes are fully supported by the system.

Research activities that will be carried out in the future will have the goal of overcoming the limitations shown and consolidating, at the same time, the part of the system developed so far. In particular, accurate experimentation is required for validating the proposed approach, for ensuring high quality of mappings and local and global views, for optimizing the mediation process.