Data integration of heterogeneous data sources plays a major role in the development of modern knowledge management systems. Additional enrichment of this data with the use of ontologies opens up completely new possibilities in leveraging the use of semantic technologies, and combining information from existing information systems. This paper presents the architecture and prototype implementation of a semantic integration layer for transparent access to relational data sources through the use of Topic Maps.
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
Semantic Integration of Relational Data Sources With Topic Maps
1. Semantic Integration of Relational Data Sources with Topic Maps Use case providers: Rani Pinchuk, Thomas Neidhart, Bernard Valentin The research was done within the SATOPI Project, a co-funded activity with the European Space Agency ( ESA Contract N°: 21520/08/I/OL)
2.
3.
4.
5.
6. Why Topic Maps ? Merging Data Reusing Data Processing Data Navigating Data Accessing Data
The Ontology (1) During the project definition phase of SATOPI, one of the tasks has been to design an ontology . That ontology had to match with the domain of activity of the researchers working at ICIMOD. This has been done by discussing with those researchers . We received from them a detailed description of their domain of activity and a description of the available data . They also provided us with some concrete examples . The one represented here is about the Imja Tsho lake which is located next to the base camp of the Everest. The size of this lake is growing fast those last years and there is a high risk of GLOF happening in a near future. It is thus a lake the researchers are watching closely. This kind of representation is created in collaboration with the researchers . The diagram shows the subjects (here: the Imja Tsho lake, the Imja glacier, which is feeding the lake, and the Koshi river basin where the glacier and the lake are located). We also represent the relations between those subjects as well as their types and even some hierarchy between those types (like here between glacial lake and lake). This is an interactive process . At the time everybody agrees with the graphical representations of the concrete examples, we can extract the ontology . -------------------- Here we can see only a fragment of the ontology . We can see all the types of entities having a geographical position . Of course this hierarchy of entity types alone does not constitute the ontology ...
The Ontology (2) … We need to go deeper and define the different types of values that can be associated to each of these entities. Also, we need to specify which relations may exist between which entity types . In this diagram, we can see a detailed representation of the "glacier" entity type . In the first half, we specified the different types of values that can be given to a glacier : its width, height, thickness, ice reserve, etc. These are not values but types of values, as we are at the ontology level. Below the value types, are represented the possible relations a glacier can have with other entities. Or between a glacier and another glacier but there is no such thing in the example. On the other hand, a lake can be linked to another lake, for example when two lakes grow and eventually merge into a single lake, lake entities can be linked to express that the new lake is a combination of two others. In this diagram, we can see for example, that a glacier is located in a sub-basin , can feed a lake or a river ... or multiple lakes or multiple rivers. There is no constraint at this level. Practically, we find links between the different domain terms identified before.
Connectors currently are prototypes . They work only on one table.
![[object Object],[object Object],[object Object],[object Object],The Problem](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)