Your SlideShare is downloading. ×
Semantic Integration of Relational Data Sources With Topic Maps
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Semantic Integration of Relational Data Sources With Topic Maps

1,254
views

Published on

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 …

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.

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,254
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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.
  • The User Interface
  • The User Interface
  • The User Interface
  • Transcript

    • 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.
      • We have more and more data
      • The data is spread across heterogeneous data sources.
      • The data is not self-explanatory.
      • Copying the data to a better organized data store is no option.
      The Problem
    • 3.
      • Create a Semantic Integration Layer that provides:
        • semantic annotation of existing data
        • a “live” view to data stored in heterogeneous data sources.
        • a merging of multiple data sources in a clean and understandable way
        • a common interface to different types of data.
      The Vision
    • 4.
      • Glacial Lake Outburst Flood (GLOF) happen when glaciers melt , and glacial lakes are formed next to them.
      • The glacial lakes are usually dammed by a natural dam made partly from ice . This dams are unstable.
      • When the water level goes up, the ice in the dams floats and causing the dam to break .
      • The resulted floods can be very intense. For example, in a GLOF event happened in 1985, the water from Dig Tsho Lake went downhill in a flood that lasted 4-6 hours, and with a flow of 1600 to 2350 cubic meters per second.
      The Use Case – GLOFs in the Himalayas
    • 5.
      • The phenomena of GLOF events depend on many factors such as weather, topography and characteristics of the glaciers, the glacier lake and its dam.
      • In order to identify precursors for a GLOF event the researcher has to collect data from different resources:
        • Different remote Earth Observation sensors each might have its own interface.
        • Data which is already collected about the glacier lake and similar glacier lakes
        • Weather data, etc.
      •  The process of accessing and collecting the data slows down the research.
      The Use Case – GLOFs in the Himalayas
    • 6. Why Topic Maps ? Merging Data Reusing Data Processing Data Navigating Data Accessing Data
    • 7.
      • Topic Maps technology provides the ability to represent knowledge in an informal, natural way – the way we, humans, grasp knowledge.
      • RDF/OWL is designed for being processed by machines, and therefore is much more formal, more machine-friendly and less human-friendly.
      Topic Maps versus The Semantic Web
    • 8. The Architecture (1)
      • The client accesses the data through a Topic Maps interface – using TMQL or TMAPI.
      • The Topic Maps Engine uses the Ontology Definition and the Mapping Definition files to find where from the data should be retrieved.
      • If the data is located in the external data stores, the Topic Maps Engine will retrieve this data.
    • 9. The Architecture (2)
      • The Ontology Definition is an ordinary topic map, containing well-defined topics and types -> reflects application logic.
      • For each attached data source, a separate connector is defined (with a mapping definition file).
      • Additionally, an arbitrary number of topic maps can be loaded.
      • Associations can be defined between any combination of attached connectors and pre-loaded topic maps.
      • The final topic map that is visible to the user through the available interfaces is the sum of all attached connectors + loaded topic maps + their defined associations.
    • 10. The Ontology (1)
    • 11. The Ontology (2)
    • 12. The Datastore Connectors Datastore Query Ontology (XTM) <topicMap xmlns=&quot;http://www.topicmaps.org/xtm/&quot; version=&quot;2.0&quot;> <itemIdentity href=&quot;http://spaceapps.com/satopi/tm&quot; /> <topic id=&quot;glacier&quot; > <name><value>Glacier</value></name> <occurrence> <type> <topicRef href=&quot;#local-id&quot; /> </type> <resourceData datatype=&quot;string&quot; /> </occurrence> Mapping Definition (CTM Template) %ctm 1.0 %prefix database <glaciers.db> %prefix tablename <gka> topic - &quot;${NAME}&quot;; isa glacier; ^ ${TMID}; local-id: &quot;${LOCAL_ID}&quot;; area: &quot;${AREA_KM2}&quot; . is-located-in(location: topic, host: &quot;${COUNTRY_TMID}&quot;) TMQL TMAPI TopiEngine TMAPI Datastore Connector
    • 13. The User Interface: Search Pages
    • 14. The User Interface: Search Result Lists
    • 15. The User Interface: Description Pages
    • 16.
      • Topic Maps is a useful data integration technology.
      • Modeling of application structure/logic using Topic Maps is efficient and straight-forward
        •  easily understood by domain experts.
      • Common interface for heterogeneous data greatly reduced complexity and amount of time for app. development.
        •  Focus on Application Logic rather than technical integration details
      Conclusion
    • 17.
      • Improve existing Topic Maps interfaces (like TMAPI) to better fit for specific use-cases:
        • Should we have TMAPI with sessions?
      Open Issues
    • 18. Thank you Questions?

    ×