Issues in Ontology-based Information integration By Zhan Cui, Dean Jones and Paul O’Brien.

Slides:



Advertisements
Similar presentations
Dynamic Ontologies on the Web Jeff Heflin, James Hendler.
Advertisements

Chapter 2 Database Environment.
Visual Web Information Extraction With Lixto Robert Baumgartner Sergio Flesca Georg Gottlob.
Chapter 6 Methodology Conceptual Databases Design Transparencies © Pearson Education Limited 1995, 2005.
1 Draft of a Matchmaking Service Chuang liu. 2 Matchmaking Service Matchmaking Service is a service to help service providers to advertising their service.
A Review of Ontology Mapping, Merging, and Integration Presenter: Yihong Ding.
1 Lecture 13: Database Heterogeneity Debriefing Project Phase 2.
Lecture Fourteen Methodology - Conceptual Database Design
1 Lecture 13: Database Heterogeneity. 2 Outline Database Integration Wrappers Mediators Integration Conflicts.
Methodology Conceptual Database Design
Lecture Two Database Environment Based on Chapter Two of this book:
1 Chapter 2 Database Environment. 2 Chapter 2 - Objectives u Purpose of three-level database architecture. u Contents of external, conceptual, and internal.
MDC Open Information Model West Virginia University CS486 Presentation Feb 18, 2000 Lijian Liu (OIM:
Database Environment 1.  Purpose of three-level database architecture.  Contents of external, conceptual, and internal levels.  Purpose of external/conceptual.
Database System Concepts and Architecture Lecture # 3 22 June 2012 National University of Computer and Emerging Sciences.
Database System Development Lifecycle © Pearson Education Limited 1995, 2005.
Information storage: Introduction of database 10/7/2004 Xiangming Mu.
CSC271 Database Systems Lecture # 4.
CST203-2 Database Management Systems Lecture 2. One Tier Architecture Eg: In this scenario, a workgroup database is stored in a shared location on a single.
Database System Concepts and Architecture
Methodology - Conceptual Database Design Transparencies
Methodology Conceptual Databases Design
9/14/2012ISC329 Isabelle Bichindaritz1 Database System Life Cycle.
1 Chapter 15 Methodology Conceptual Databases Design Transparencies Last Updated: April 2011 By M. Arief
Introduction to MDA (Model Driven Architecture) CYT.
Interoperability in Information Schemas Ruben Mendes Orientador: Prof. José Borbinha MEIC-Tagus Instituto Superior Técnico.
2. Database System Concepts and Architecture
1 Technologies for distributed systems Andrew Jones School of Computer Science Cardiff University.
Entity Framework Overview. Entity Framework A set of technologies in ADO.NET that support the development of data-oriented software applications A component.
Methodology - Conceptual Database Design. 2 Design Methodology u Structured approach that uses procedures, techniques, tools, and documentation aids to.
1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.
Methodology: Conceptual Databases Design
Dimitrios Skoutas Alkis Simitsis
Methodology - Conceptual Database Design
Interoperability & Knowledge Sharing Advisor: Dr. Sudha Ram Dr. Jinsoo Park Kangsuk Kim (former MS Student) Yousub Hwang (Ph.D. Student)
Chapter 2 Database System Concepts and Architecture Dr. Bernard Chen Ph.D. University of Central Arkansas.
1 Chapter 1 Introduction to Databases Transparencies.
Information Integration BIRN supports integration across complex data sources – Can process wide variety of structured & semi-structured sources (DBMS,
Trustworthy Semantic Webs Dr. Bhavani Thuraisingham The University of Texas at Dallas Lecture #4 Vision for Semantic Web.
A Portrait of the Semantic Web in Action Jeff Heflin and James Hendler IEEE Intelligent Systems December 6, 2010 Hyewon Lim.
Chapter 2 Database Environment.
1 Database Environment. 2 Objectives of Three-Level Architecture u All users should be able to access same data. u A user’s view is immune to changes.
Semantic Data Extraction for B2B Integration Syntactic-to-Semantic Middleware Bruno Silva 1, Jorge Cardoso 2 1 2
© The ATHENA Consortium. CI3 - Practices of Interoperability in SMEs Proposed Solutions.
Copyright 2007, Information Builders. Slide 1 iWay Web Services and WebFOCUS Consumption Michael Florkowski Information Builders.
2) Database System Concepts and Architecture. Slide 2- 2 Outline Data Models and Their Categories Schemas, Instances, and States Three-Schema Architecture.
Of 24 lecture 11: ontology – mediation, merging & aligning.
26/02/ WSMO – UDDI Semantics Review Taxonomies and Value Sets Discussion Paper Max Voskob – February 2004 UDDI Spec TC V4 Requirements.
ISC321 Database Systems I Chapter 2: Overview of Database Languages and Architectures Fall 2015 Dr. Abdullah Almutairi.
Databases (CS507) CHAPTER 2.
Databases and DBMSs Todd S. Bacastow January 2005.
REV 00 Chapter 2 Database Environment DDC DATABASE SYSTEM.
REV 00 Chapter 2 Database Environment DDC DATABASE SYSTEM.
Methodology Conceptual Databases Design
Chapter 2: Database System Concepts and Architecture - Outline
Chapter 2 Database Environment.
Chapter 1: Introduction
Chapter 2 Database System Concepts and Architecture
Methodology Conceptual Database Design
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 2 Database System Concepts and Architecture.
 DATAABSTRACTION  INSTANCES& SCHEMAS  DATA MODELS.
Chapter 2 Database Environment.
Chapter 2 Database Environment Pearson Education © 2009.
Chapter 2 Database Environment.
Data, Databases, and DBMSs
Database Environment Transparencies
Methodology Conceptual Databases Design
Chapter 2 Database Environment Pearson Education © 2009.
Chapter 2 Database Environment Pearson Education © 2009.
Presentation transcript:

Issues in Ontology-based Information integration By Zhan Cui, Dean Jones and Paul O’Brien

E-commerce Requirement: Retrieve and Integrate information from multiple resources. Details of the resources are hided from users. Obstacles: Understand queries. Determine resources. Integrate information.

Four levels in interoperability problems 1.System level: incompatible hardware and operating system. 2.Syntactic level: different language and data representations. 3.Structural level: different data models. 4.Semantic level: the meaning of terms. e.g., synonyms. Many technologies address problems in first three levels, such as CORBA, DCOM, etc.

XML vs. Semantic Heterogeneity Problems XML: Can solve problems in schema level. Provide common syntax for exchanging heterogeneity information. Some standards for e-commerce: e.g., ebXML. XML: Cannot solve problems in semantic level. Terminology may not consistent in one file or in a set of files.

Solution Formally specify the meaning of the terminology of each system (Formal ontology) Define a translation between each system terminologies and an intermediate terminology. (Ontology mapping)

Outline Issues in Resolving Semantic Heterogeneity Description of DOME DOME Demonstrator Conclusion

Issues in Resolving Semantic Heterogeneity --- Developing ontologies Formal ontology: A formal ontology consists of definitions of terms. It usually includes concepts with associated attributes, relationships and constraints defined between the concepts and instances of concepts. Formal ontologies include different type of ontologies for different purposes: Resource ontologies: define the terminology used by specific information resources. Personal ontologies: define the terminology of a user or some group of users. Shared ontologies: the common terminology between a number of different systems.

Issues in Resolving Semantic Heterogeneity --- Developing ontologies The best approach to develop ontologies is usually determined by the eventual purpose of the ontologies. For example: Resource ontologies: bottom-up approach. Shared ontologies: top-bottom approach.

Issues in Resolving Semantic Heterogeneity --- Mapping Between Ontologies Human intervention is necessary. Some tools are helpful: mediator systems, mapping libraries and conversion functions. Mapping is not accurate. Information could be lost. This is unacceptable for e-commerce.

Issues in Resolving Semantic Heterogeneity --- Ontologies and Resource Information How to choose resources? It is necessary for resources to describe themselves: resource ontologies. Personal ontologies are important for the system to understand queries exactly. Many issues in locating resources: e.g., users prefer one resource over another;

Issues in Resolving Semantic Heterogeneity --- Ontologies and Database Schemas Schema vs. Ontology The main difference is their purposes. A schema is developed in order to model some data. A ontology is developed to define the meaning of the terms. A r esource has a formal ontology. Data are store in database based on schema. Mapping between formal ontology and resource schema is necessary.

Issues in Resolving Semantic Heterogeneity --- Entity Correspondence There may be a lot of resources related to one query. Information have to be integrated to answer query. Construct correspondence between entities across resources. Key attributes can be used to build correspondence. It is hard to determine whether information from different resources is same or not.

DOEM Overview Ontology-based techniques. Designed for data reuse and knowledge sharing. Retrieve information from multiple resources to answer queries. Present results in a consistent way. DOEM (Domain ontology Management Environment)

DOEM Overview Ontology server: manage the definitions of terms. Mapping server: manage the relationships between ontologies. Engineering client: develop and administrate a DOEM system. User client: support querying. Query engine: decompose queries to sub-queries.

The DOEM architecture

DOEM Overview Develop and administrate a DOEM system. Extract (semi-automated) ontologies from legacy system to define ontologies and mappings. Allow engineers to select best developing approach: top-down or bottom-up. Engineers: define mapping between resource ontologies and shared ontologies, resources and shared ontologies, database schemas and resource ontologies. --- Engineering client

DOEM Overview Store ontologies defined using the engineering client. Allow user to access: share ontologies, resource ontologies, application ontologies. Access through OKBC interface. Implement ontologies using the description logic CLASSIC which can store ontologies and make inference. --- Ontology server

DOEM Overview Interface to access system. Query information space. Load and browse ontologies. Queries and results use the same terminology. --- User client

DOEM Overview Store mappings between ontologies. Store generic conversion functions. Use a declarative syntax. Can be queried by query engine. --- Mapping server

DOEM Overview Most interaction between a resource and the DOME network occurs via wrappers. Translate queries between DOME and resources. Translate information that will be put into the terminology of the particular resource. --- Wrappers

DOEM Overview Let system know which resources are available and what these resources are. Store the directories and descriptions of resources. --- Resource Directory

Obtain a list of currently available and relevant resources from resource directory. Decompose the query into sub-queries. Send the sub-queries to the resources. Translate queries from the ontology of the query to that of the relevant resource. Integrate results. DOEM Overview --- Query engine

The DOEM architecture

DOME Demonstrator Based on a database of marketing scenario. DOME controls mapping and limits resources.

Conclusions Solve information query at semantic level with formal ontologies and ontology mappings. Provide an integrated view of networked heterogeneous databases. Allow a user to select and browse definitions of terminologies. DOME:

Comments General description. There is no details and experiments. No new technique is introduced.