Ontological Approach for Information Discovery in Internet Databases.
The Internet has solved the age-old problem of network connectivity and thus enabling the potential access to, and data sharing among large numbers of databases. However, enabling users to discover useful information requires an adequate metadata infrastructure that must scale with the diversity and dynamism of both users' interests and Internet accessible databases. In this paper, we present a model that partitions the information space into a distributed, highly specialized domain ontologies. We also introduce inter-ontology relationships to cater for user-based interests across ontologies defined over Internet databases. We also describe an architecture that implements these two fundamental constructs over Internet databases. The aim of the proposed model and architecture is to eventually facilitate data discovery and sharing for Internet databases.
Introduction
The emergence of the Internet [?] and the World Wide Web (WWW) [?] have been
among the most important developments in the computer industry. Particularly,
the Web has brought a wave of new users and service providers to the Internet. It
is now the most popular distributed information repository. This globalization has
also spurred the development of tools and aids to navigate and share information
in corporate intranets that previously were only accessible on-line at prohibitive
costs.
Organizations all over the world rely on a wide variety of databases to conduct
their everyday business. Databases are usually designed from scratch if none is
found to meet their requirements. This has led to a proliferation of databases
obeying different sets of requirements modeling the same situations. In many in-
stances, and because of a lack of any organized conglomeration of databases, users
create their own pieces of information that may exist in current databases.
Though it may be known where a certain piece of information is stored, locating it
may be prohibitive in terms of cost and effort. There was also a renewed interest in
* This work was done when the first and third authors were at Queensland University of Technology

sharing information across heterogeneous platforms because of the readily available
and relatively cheap network connectivity. Although one may potentially access all
participating databases, in reality this is an almost intractable task due to various
fundamental problems [?, ?]. The challenge is to give a user the sense that he or
she is accessing a single database that contains almost everything he or she needs.
To allow effective and efficient data sharing on the Web, there is a need for an
infrastructure that can support flexible tools for information space organization,
communication facilities, information discovery, content description, and assembly
of data from heterogeneous sources (conversion of data, reconciliation of incompatible
syntax and semantics, integration of distributed information, etc). Old
techniques for manipulating these sources are not appropriate and efficient. Users
must be provided with tools for the logical scalable exploration of such systems
in a three step process involving: (i) Location of appropriate information sources;
(ii) Searching of these sources for relevant information items; (iii) Understanding of
the structure, terminology and patterns of use of these information items for data
integration, and ultimately, querying.
An approach for achieving interoperation in the context of large and dynamic environments
was to use a common global ontology shared by users and information
sources [?]. This ontology can capture the structure and semantics of the information
space. This can be achieved, for example, using the Entity-Relationship or
Frame-based models [?]. In general, in existing work, the global ontology acts as a
global conceptual schema that is used to formulate queries as if the user has to deal
with one single database schema. It is however difficult to create and maintain such
common global ontology because of the autonomy and heterogeneity aspects of the
underlying repositories. In the case of a large numbers of autonomous databases, a
meaningful organization and segmentation of databases, based on simple ontologies
that describe coherent slices of the information space, need to be introduced. These
would filter interactions, accelerate information search, and allow for the sharing of
data in a tractable manner.
In order to address problems of information discovery and data sharing for Internet
databases, the WebFINDIT prototype has been developed [?] [?]. We base
our design on previous work on the FINDIT project [?, ?], an information brokering
system that addresses issues of interoperability in very large multidatabases.
The fundamental premise is that in a dynamic environment such as the Web, users
would have to be incrementally made aware of what is available in terms of both
information and information repositories.
In our approach, ontologies of information repositories are established through a
simple domain ontology. This meta-information represents the domain of interest of
the underlying information repositories. For example, collection of databases that
store information about the same topic are grouped together. Individual databases
join and leave the formed ontologies at their own discretion. Ontology formation
and maintenance, as well as exploration of the relationship structure, occurs via a
special-purpose language called WebTassili.
The WebFINDIT prototype provides a scalable and portable architecture using
the latest in distributed object and Web technologies, including CORBA as a
distributed computing platform, Java, and connectivity gateways to access native
information sources. CORBA provides support for communication between software
components of a distributed environment, dynamic location and integration
of information sources while maintaining their autonomy. Java allows our system
to be deployed dynamically over the Web and provides users with sophisticated,
system-independent, and interactive interface.
The remainder of this paper is organized as follows. Related work is discussed
in Section 2. In Section 3, we present the WebFINDIT's approach for information
space organization and modeling. In Sections 4 and 5 respectively, we overview the
metadata and language support for WebFINDIT. Details of the implementation
are given in Section 6 along with a scenario describing the use of WebFINDIT in a
healthcare application. We provide some concluding remarks in Section 7.
2. Background
We describe here some projects that make use of ontologies or domain models for
data sharing in the context of heterogeneous information sources.
Multidatabases (e.g., UniSQL [?] and Pegasus [?]) have traditionally investigated
static approaches to sharing data among small numbers of component databases.
This has involved finding solutions to data heterogeneity and facets of autonomy.
These solutions usually rely on centralized database administrators to document
database semantics or to develop translators that hide differences in query languages
and database structures. However, in the context of intranets and Internet
environments, users should have a way to locate information in large spaces of
information. Also, users have a need to be educated about the information of in-
terest. Any static solution to such a problem is bound to fail as the information
space in environments like the Internet has a staggeringly rapid evolution [?]. In
multidatabase systems, the emphasis has been more on conflict resolution among
different schemas and data models in small networks of heterogeneous databases.
Multiple ontologies and scalability issues are usually not explicitly addressed.
In most information retrieval systems, the emphasis is usually on how to build
indexing schemes to efficiently access information given some hints about the resource
[?]. A similar approach to information retrieval systems is taken in Internet
information gathering systems (e.g., GlOSS [?]), WWW search tools [?] (e.g., Lycos
and MetaCrawler), and database-like languages for the WWW (e.g., W3QL [?]
and WebSQL [?]). In general, in this area the emphasis is on the improvement of
indexing techniques. Issues like the information space organization, terminological
problems, and semantic support for users requests are not addressed. In addition,
text search techniques are inadequate in the context of structured data (e.g., no
support for complex queries that involve operations like join).
The Carnot project [?] addresses the integration of distributed and heterogeneous
information sources (e.g., database systems, expert systems, business work-
flows, etc). It uses a knowledge base, called Cyc, to store information about the
global schema. The InfoSleuth project [?] is the successor of Carnot and presents an
approach for information retrieval and processing in a dynamic Web-based environ-
4ment. It integrates agent technology, domain ontologies, and information brokering
to handle the interoperation of data and services over information networks. Different
types of agents are proposed to represent users, information sources and the
system itself. These agents communicate with each other by using the Knowledge
Query and Manipulation Language (KQML). Users specify queries over specified
ontologies via an applet-based user interface. Although this system provides an
architecture that deals with scalable information networks, it does not provide facilities
for user education and information space organization. InfoSleuth supports
the use of several domain ontologies, however, inter-ontology relationships are not
considered. Also, this system overburdens the network resources by transmitting all
requests to a central server that provides an overall knowledge of system ontologies.
Information Manifold (IM) [?] is a system that provides uniform access to collections
of heterogeneous information sources on the Web. This system was the
first that used a mechanism to describe declaratively the contents and query capabilities
of information sources. Sources descriptions are used to efficiently prune
the set of information sources for a given query and to generate executable query
plans. The main components of IM are the domain model, the plan generator, and
the execution engine. The domain model is the knowledge base that describes the
browsable information space including the vocabulary of a domain, the contents of
information sources and the capability of querying. The plan generator is used to
compute an executable query plan based on the descriptions of information sources.
The domain model constitutes the global ontology shared by users and information
sources. Such ontologies are difficult to create and maintain due to the variety and
characteristics of the underlying Web repositories.
The DIOM system architecture [?] achieves interoperability in heterogeneous
information systems by matching the consumer's query profile and the information
producer's source profiles. Both are described in terms of the DIOM interface
definition language (DIOM IDL). The consumer's query profile captures the querying
interests of the consumer and the preferred query result representation. The
producer's source profiles describe the content and query capabilities of individual
information sources. A wrapper controls and facilitates external access to the
wrapped source by using local metadata. The focus on DIOM is more on pruning
irrelevant sources when resolving a query. A similar approach to Information Manifold
is used to describe information sources. The use of multiple ontologies is not
considered.
OBSERVER [?] [?] is a multi-purpose architecture for information brokering.
One of the major issues addressed is the vocabulary differences across the components
systems. OBSERVER features the use of pre-existing domain specific ontologies
(ontology server) to describe the terms used for the construction of domain
specific metadata. Relationships across terms in different ontologies are supported.
In addition, OBSERVER performs brokering at the metadata and vocabulary levels.
OBSERVER does not provide a straightforward approach for information brokering
in defining mappings from the ontologies to the underlying information sources. It
should be noted that OBSERVER does not provide facilities to help or train users
during query processing.
The SIMS project aims to achieve the integration of multiple information sources
(databases or knowledge bases) [?]. The integration is based on the Loom knowledge
representation language. The architecture is similar to the tightly coupled federated
databases. SIMS transforms information sources of any data model into SIMS
domain model which is a declarative knowledge base. Thus, SIMS domain model
is equivalent to the common data model in the federated databases. The main
contribution of SIMS is on query processing over one single ontology [?]. Issues
related to the use of multiple ontologies and their relationships are not considered.
The COntext INterchange (COIN) project [?] aims at providing intelligent semantic
integration among heterogeneous sources such as relational databases, Web
documents and receivers. The proposed approach is based on the unambiguous description
of the assumptions made at each component (how information should be
interpreted). The assumptions pertaining to a source or receiver form its context.
COIN architecture is context mediator based. The context mediator is responsible
for the detection of semantic conflicts between the contexts of the information
sources and receivers and the conversion needed to resolve them. A user query
is reformulated into subqueries that can be forwarded to appropriate information
sources for execution. The results obtained from the component systems are combined
and converted to the context of the receiver that initiated the query. COIN
uses shared ontologies (conceptualization of the underlying domains) as the basis
for context comparisons and interoperation. The issues of information discovery
and information space organization are not considered.
There are major differences between WebFINDIT and systems described above.
WebFINDIT aims to provide a single interface to access all Web-accessible databases.
This interface is based on an architecture that organizes the information space into
simple distributed ontologies and provides relationships among them. Users are incrementally
educated about the available information space in order to allow them
to query the underlying databases. One of the greatest strengths of our approach
is extensibility. Compared to the approaches that use ontologies for information
brokering, the addition of new information is simpler in WebFINDIT. While the
mappings between sources and domain models require great efforts in these ap-
proaches, our underlying distributed ontology design principles make it easier to
construct and manage ontologies. In WebFINDIT, an information source can be
associated with many classes in different clusters via instantiation relationships as
we use object oriented stratification of clusters. More importantly, we provide a
seamless Internet-based implementation of the WebFINDIT infrastructure.
3. Information Space Organization and Modeling
The WebFINDIT approach is mainly motivated by the fact that in a highly dynamic
and constantly growing network of databases accessible through the Web,
there is a need for a meaningful organization and segmentation of the information
space. We adopt an ontology-based organization of the diverse databases to filter
interactions, accelerate information searches, and allow for the sharing of data in a
tractable manner. Key criteria that have guided our approach are: scalability, design
simplicity, and easy to use structuring mechanisms based on object-orientation.
The information space is organized through distributed domain ontologies. Information
sources join and leave a given ontology based on their domain of interest
which represent some portion of the information space. For example, information
sources that share the topic Medical Research are linked to the same ontology.
This topic-based ontology provides the terminology for formulating queries involving
a specific area of interest. Such organization aims to reduce the overhead of
locating and querying information in large networks of databases. As an information
source may contain information related to more than one domain of interest,
it may be linked to more than one ontology at the same time.
The different ontology formed on the above principle are not isolated entities but
they can be related to each other by inter-ontology relationships. These relationships
are created based on the users' needs. They allow a user query to be resolved
by information sources in remote ontologies when it cannot be resolved locally.
We do not intend to achieve an automatic "reconciliation" between heterogeneous
ontologies. In our system, users are incrementally educated about the available
information space by browsing the local ontology and by following the inter-ontology
relationships. In this way, they have sufficient information to query actual data.
3.1. Domain Models
Each ontology is specialized to a single common area of interest. It provides domain
specific information and terms for interacting within the ontology and its underlying
databases. That is providing an abstraction of a specific domain. This abstraction
is intended to be used by users and other ontologies as a description of the specific
domain. Ontologies dynamically clump databases together based on common areas
of interest into a single atomic unit. This generates a conceptual space which has
a specific content and a scope. The formation, dissolution and modification of an
ontology is a semi-automatic process. Privileged users (e.g., the database admin-
are provided with tools to maintain the different ontologies mainly on a
negotiation basis.
Instead of considering a simple membership of information sources to an ontology,
intra-ontology relationships between these sources are considered. This allows a
more flexible and precise querying within an ontology. These relationships form a
hierarchy of classes (an information type based classification hierarchy) inside an
ontology. In that respect, users can refine their queries by browsing the different
classes of an ontology.
3.2. Inter-ontology Relationships
When a user submits a query to the local ontology, it might be not resolvable locally.
In this case, the system try to find remote ontologies that can eventually resolve
the query. In order to allow such query "migration", inter-ontology relationships
are dynamically established between two ontologies based on users' needs. Inter-ontology
relationships can be viewed as a simplified way to share information with
low overhead. The amount of sharing in an inter-ontology relationship will typically
involve a minimum amount of information exchange.
Although the above relationships involve basically only ontologies, they are extended
to databases as well. This allows more flexibility in the organization and
querying of the information space. Inter-ontology relationships are of three types
(see

Figure

??). The first type involves a relationship between two ontologies to exchange
information. The second type involves a relationship between two databases.
The third type involves a relationship between an ontology and a database. An
inter-ontology relationship between two ontologies involves providing a general description
of the information that is to be shared. Likewise, an inter-ontology relationship
between two databases also involves providing a general description of
information that databases would like to share. The third alternative is a relationship
between an ontology and a database. In this case, the database (or the
ontology) provides a general description of the information it is willing to share
with the ontology (or database). The difference between these three alternatives
lies in the way queries are resolved. In the first and third alternative (when the
information provider is an ontology), the providing ontology takes over to further
resolve the query. In the second case, however, the user is responsible for contacting
the providing database in order to gain knowledge about the information.
Our dynamic distributed ontologies make information accessing more tractable
by limiting the number of databases which must interact. Databases join and
leave ontologies and inter-ontology relationships based upon local requirements and
constraints. At any given point in time a single database may partake in several
ontologies and inter-ontology relationships.
We believe that a complete reconciliation between all the information sources
accessible through the Web is not a tractable problem. In our approach, there is
no automatic translation between different ontologies. The users are incrementally
educated about the available information space. They discover and become familiar
with the information sources that are effectively relevant. They can submit precise
queries which guarantee that only relevant answers are returned. On the other
hand, information sources join simply our distributed ontologies by providing some
local information and choosing one or more ontologies that meet their interests.
In addition, this join does not involve major modifications in the overall system -
we only need to made some changes at the metadata level related to the involved
ontologies. This allows our system to scale easily and to be queried in a simple and
flexible way.
3.3. Information Sources Modeling
When a database decides to join WebFINDIT, it has to define which areas are of
interest for it. Links are then established to ontologies implementing these concepts
if any, otherwise a negotiation may be engaged with other databases to form new
ontologies. The database administrator must provide an object-oriented view of the
CentreLink
ATO
Prince Charles
Ambulance
ATO_to_Medicare
QUT
Qld Cancer Fund
RMIT
RBH
MBF
Medibank
RBH Workers Union
Research Ontology
State Govt. Funding
Medical Workers
Union Ontology
CentreLink_to_Medical
Medicare
SGF_to_Medicare
WorkersUnion_to_Medical
Medical Ontology
Medical Insurance Ontology
Superannuation Ontology
SGF_to_Medical
Medical_to_MedicalInsurance
Ambulance_to_Medical
Super_to_Medical
ATO_to_Medical

Figure

1. Distributed Ontologies in the Medical World.
underlying database. This view contains the terms of interest available from that
database. These terms provide the interface that can be used to communicate with
the database. More specifically, this view consists of one or several types (called
access interface of a database) containing the exported operations (attributes and
functions) and a textual description of these operations. The membership of a
database to an ontology is materialized by the fact that the database is an instance
of one or many classes in the same or different ontologies. We should also note that
other useful information are provided by the database administrator (see Section
??).
To illustrate how a database is modeled in WebTassili and how it is related to the
domain model, consider the Queensland Cancer Fund database which is member
of the ontology Research (see Figure ??). Let us assume that this database is an
instance of a class in the ontology Research. It represents, for example, an mSQL
database that contains the following relations:
CancerClassify(Cancer Id, Scientific Name, Common Name,
Infection Area, Cause Known, Hereditary,
ResearchGroup(Group Id, Cancer Id, Start Date, Supervisor Id)
Staff(Staff Id, Title, Name, Location, Phone, Research Field)
GroupOwnership(Ownership Id, Group Id, Staff Id,
Date Commenced, Date Completed)
Funding(Funding Id, Group Id, Provider Name, Amount,
Conditions)
If the database administrator decides to make public some information related to
some of the above relations, they have to be advertised by specifying the information
type to be published as follows:
Type Funding f
attribute string CancerClassify.CommonName;
function real Amount(string CancerClassify.CommonName);
Type Results f
attribute string Staff.Name;
attribute int GroupOwnership.DateCommenced;
function string Description(string Staff.Name,
int Date GroupOwnership.Datecommenced);
Note that the textual explanations of the attributes and operations are left out of
the description for clarity. Each attribute denotes a relation field and each function
denotes an access routine to the database. The implementation of these features
is transparent to the user. For instance, the function Description() denotes the
access routine that returns the description of all results obtained by a staff member
after a given date. This routine is written in mSQL's C interface. In the case of
an object-oriented database, an attribute denotes a class attribute and a function
denotes either a class method or an access routine. Using WebFINDIT, users
can locate the database, then investigate its exported interface and fetch useful
attributes and functions to access the database.
3.4. Documentations
In addition to the information types that represent the domains of interest of the
database, WebFINDIT documents the database in a way that users can understand
its contents and behavior. This provides a richer and understandable description
of the database. The documentation mainly consists of a set of demonstrations
about what an information type is and what it offers. This demonstration may
be textual or graphical depending on the information being exported. Even if
two databases contain the same information, the information may exhibit different
behaviors depending on the selected database. This is to be expected as a product
may display different properties depending on who the exporter is.
One of the major problems that research solutions to heterogeneity have not adequately
addressed is the problem of understanding the structure and behavior of
different types of information as represented in various databases. Research in this
area has largely been concerned with the static aspects of schema integration. The
idea has been to present users with one uniform view or schema, built on top of
several other schemas [?, ?]. Database administrators are responsible for understanding
the different schemas and then translating them into a schema understood
by local users. It is important to note that this process is a reasonable solution
only if there is a small number of schemas that are fairly similar. In fact, there is a
problem of understanding information even if the data model is the same across all
participating databases. The problem is not acute when the number of databases
is small, as it would be reasonable to assume that enough interaction between designers
would solve the problem of understanding information. This could not work
in an environment like Internet databases.
4. Metadata Support - Co-databases
Co-databases are introduced as a means for implementing our distributed ontology
concept and as an aid to inter-site data sharing. These are metadata repositories
that surrounds each local DBMS, and which know a system's capability and
functionality. Formation of information space relationships (i.e, ontologies and
inter-ontology relationships) and maintenance as well as exploration of these relationships
occur via a special-purpose language called WebTassili. An overview of
the WebTassili language is presented in Section ??.
Locating a set of databases that fits user queries requires detailed information
about the content of each database in the system. To avoid the problem of centralized
administration of information, meta-information repositories are distributed
over information networks. In our approach, each participating database has a co-
database attached to it. A co-database (meta-information repository) is an object-oriented
database that stores information about its associated database, ontologies
and inter-ontology relationships of this database. A set of databases exporting a
certain type of information is represented by a class in the co-database schema.
This also means that an ontology is represented by a class or a hierarchy of classes
(i.e., information type based on a classification hierarchy).
A typical co-database schema contains subschemas that represent ontologies and
inter-ontology relationships that deal with specific types of information (see Figure
??). The first sub-schema consists of a tree of classes where each class represents
a set of databases that can answer queries about a specialized type of information.
This subschema represents ontologies. The class Ontologies Root forms the root
of the ontologies tree. Every subclass of the class Ontologies represent the root
of an ontology tree. Every node in that tree represents a specific information type.
An ontology is hierarchically organized in the form of a tree, so that an information
1type has a number of subordinate information types and at most one superior
information type. This organization allows an ontology to be structured according
to a specialization relationship. For instance, the class Research could have two
Cancer Research and Child Research. The classes joined in the ontology
tree support each other in answering queries directed to them. If a user query
conforms better with the information type of a given subclass, then the query will
be forwarded to this subclass. If no classes are found in the ontology tree while
handling a user query, then either the user simplifies the query or the query is
forwarded to other ontologies (or databases) via inter-ontology relationships. The
splitting of an ontology into smaller units increase the efficiency when searching
information types.
Database-Database Class
Co-database Root Class
Ontologies Root Class
Ontology n Root Class
Ontology 1 Root Class
Ontology-Ontology Class Ontology-Database Class
Ontologies Relationships Root Class Database Relationships Root Class
Inter-Ontology Root Class

Figure

2. The outline of a typical co-database schema
The co-database also contains another type of subschema. This subschema consists
on the one hand, of a subschema of inter-ontology relationships that involve
the ontology the database is member of; and on the other hand of a subschema
of inter-ontology relationships that involve the database itself. Each of these subschemas
consists in turn of two subclasses that respectively describe inter-ontology
relationships with databases and inter-ontology relationships with other ontologies.
In particular, every class in an ontology tree contains a description about the
participating databases and a description about the type of information they con-
tain. Description of the databases will include information about the data model,
operating system, query language, etc. Description of the information type will
include its general structure and behavior. We should also mention that the documentation
(demo) associated with each information instance is stored in actual
databases. This is done for two reasons: (1) Database autonomy is maintained and,
(2) documentations can be modified with little or no overhead on the associated
co-databases.
The class Ontology Root contains the generic attributes that are inherited by all
classes in the ontology tree. A subset of the attributes of the class Ontology Root
is:
Class Ontology Root f
attribute string Information-type;
attribute set(string) Synonyms;
attribute string DBMS;
attribute string Operating-system;
attribute string Query-language;
attribute set(string) Sub-information-types;
attribute set(Inter-ontology Root)
Inter-ontology Relationships;
attribute set(Ontology Root) Members;
The attribute Information-type represents the name of the information-
type (e.g., "Research" for all instances of the class Research). The attribute
Synonyms describes the set of alternative descriptions of each information-
type. Users can use these descriptions to the effect of obtaining databases
that provide information about the associated information type. The attribute
Sub-information-types describes specialization relationship. The other attributes
are self-explained.
Every sub-class of the class Ontology Root has some specific attributes that describe
the domain model of the related set of underlying databases. These attributes
do not necessarily correspond directly to the objects described in any particular
database. For example, a subset of the attributes of the class Research (Project
and Grant are two types defined elsewhere) is:
Class Research Isa Ontology Rootf
attribute string Subject;
attribute set(Project) Projects;
attribute set(Grant) Fundings;
In the

Figure

??, the class Inter-Ontology Root contains the generic attributes
that are relevant to all types of inter-ontology relationships. These relationships
can be used to answer queries when the local ontology cannot answer them. An
inter-ontology relationship can be seen as an intersection (or overlap) relationship
between the related entities. Synonyms and generalization/specialization can be
seen as intra-ontology relationships compared to the inter-ontology relationships.
A subset of attributes of the class Inter-Ontology Root is:
Class Inter-Ontology Root f
attribute set(string) Description;
attribute string Point-of-entry;
attribute string Source;
attribute string Target;
The attribute Description contains the information type that can be provided
using the inter-ontology relationship. Assume that the user queries the ontology
Medical about Medical Insurance. The use of the synonyms and generaliza-
tion/specialization relationships fails to answer the user query. However, the ontology
Medical has an inter-ontology relationship with the ontology Insurance where
the value of the attribute Description is f"Health Insurance", "Medical
Insurance"g. It is clear that this inter-ontology relationship provides the answer
to the user query. The attribute Point-of-entry represents the name of the co-
database that must be contacted to answer the query. The attribute Source and
Target are self-explained.
So far, we presented the metadata model used to describe the ontologies and
their relationships. In what follows we will present how a particular database is
described and linked to its ontologies. For example, the co-database attached to
the Royal Brisbane Hospital contains information about all related ontologies
and inter-ontology relationships. As the Royal Brisbane Hospital is member
of two ontologies Research and Medical, it stores information about these two
ontologies. This co-database contains also information about other ontologies and
databases that have a relationship with these two ontologies and the database itself.
The co-database stores information about the inter-ontology relationships State
Government Funding and Medical Insurance. It stores also access information
of the Royal Brisbane Hospital database, which includes the exported interface
and the Internet address. The interface of a database consists of a set of types
containing the exported operations and a textual description of these types. The
database will be advertised through the co-database by specifying the information
type, the documentation (a file containing multimedia data or a program that plays
a product demonstration), and the access information which includes its location,
the wrapper (a program allowing access to data in the database), and the set of
exported types.
Information Source Royal Brisbane Hospital f
Information Type "Research and Medical"
Documentation "http://www.medicine.qut.edu.au/RBH"
Location "dba.icis.qut.edu.au"
Wrapper "dba.icis.qut.edu.au/WebTassiliOracle"
Interface ResearchProjects, PatientHistory
The URL "http://www.medicine.qut.edu.au/RBH" contains the documentation
about Royal Brisbane Hospital database. It contains any type of presentation
accessible through the Web (e.g., a Java applet that plays a video clip).
WebTassiliOracle is the wrapper needed to access data in the Oracle database using
a WebTassili query. The exported interface contains two types that will be
advertised as explained in the previous section for the Queensland Cancer Fund
database.
The interface of a database can be used to query data stored in this database.
This is possible only after locating this database as a relevant information source.
As pointed out before each sub-class of the class Ontology Root has a set of attributes
that describe the domain model of the underlying databases. In fact, these
attributes can also be used to query data stored in the underlying databases. How-
ever, these attributes do not correspond directly to attributes in database interfaces.
For this reason, we define the relationships between information source types and
ontology domain model attributes. We call these relationships mappings. More
specifically, there exists one mapping for each type in the interface of a database.
The mappings are used to translate an ontology query into a set of queries to the
relevant databases. Note that an attribute (or a function) in the type of a database
may be related to different attributes (or functions) in different ontologies. For
example, the attribute Patient.name of the type PatientHistory may be related
to two domain attributes, one (a1) in the ontology Medical and another (a2) in
the ontology Research. This can be described as follows:
Mapping PatientHistory f
attribute string Patient.Name Is ! Research.a1,
Information sharing is achieved through co-databases communicating with each
other. As mentioned above, a database may belong to more than one ontology. In
this case, its co-database will contain information about all ontologies it belongs
to. Two databases can belong to the same ontology and still have different co-
databases. This is true because these databases might belong to different ontologies
and be involved with different inter-ontology relationships. This is one reason it is
desirable that each database has one co-database attached to it instead of having
one single co-database for each ontology. Database autonomy and high information
availability are other reasons why it is not desirable to physically centralize the
co-database.
5. Language Support - WebTassili
SQL and extensions thereof works best when the database schemas are known to
the user. In that respect, it is not concerned with discovering metadata. Querying
with SQL is done in one single step to get the data. In contrast, access to Internet
databases will happen in two steps and iteratively. In addition, the nature of the
ontology architecture calls for a special handling of ontology and inter-ontology
relationships management. To our knowledge, no language has been developed
to support the access and management of ontologies in the context of Internet
databases.
In what follows, we introduce the main features of the WebTassili language. We
focus on the novel aspects designed specifically for user education and information
source location in distributed ontologies. The language was first introduced in [?].
Subsection ?? demonstrates how WebTassili is used to educate users about the
available information. Subsection ?? shows the power of WebTassili in providing
interaction and communication between ontologies.
WebTassili has been designed to address issues related to the use, design and
evolution of WebFINDIT. The world of users is partitioned into privileged users
and general users. Queries are resolved through an interactive process. Privileged
users, such as administrators, can issue both data definition and data manipulation
operations. The formation of ontologies and inter-ontology relationships, as
well as co-database schema evolution, is achieved through the WebTassili data definition
operations. An ontology is bootstrapped after formal negotiation between
privileged users takes place. The ontology/inter-ontology schema is stored and
maintained in individual co-databases. As co-databases contains replicated data,
schema updates are then propagated to the appropriate co-databases using a pre-defined
set of protocols. This data is then accessed by the component information
repository to provide users with information regarding the structure of the system
and the nature of information sources. General users may issue read-only queries.
The distributed updating and querying of co-databases is achieved via an interface
process which allows interactions with remote sites.
WebTassili consists of both data definition and manipulation constructs. As for
data definition features, it is used to define the different schemas and their intrinsic
relationships. It provides constructs to define classes of information types and their
corresponding relationships. In conventional object-oriented databases, the behavior
of a class is the same for all its instances. WebTassili also provides mechanisms
for defining constraints and firing triggers for evolution purposes. This feature is
used to evolve schemas as well as propagate changes to related schemas. Data definition
queries are only accessible to a selected number of users (administrators).
The formation of a schema is achieved through a negotiation process. In that re-
spect, WebTassili provides features for administrators to form and evolve schemas.
More specifically, WebTassili provides the following data definition operations:
ffl Define classes and objects (structure and behavior).
ffl Define operations for schema evolution.
ffl Define operations for negotiation for schema creation and instantiation.
WebTassili is also used to manipulate the schema states. Users use WebTassili
to query the structure and behavior of meta-information types. Users also use
this query language to query information about participating databases. The manipulation
in WebTassili is on both meta data and actual data. More specifically,
WebTassili provides the following manipulation operations:
ffl Search for an information type.
ffl Search for an information type while providing its structure.
ffl Search for an information type while providing its structure and/or information
about the host databases.
ffl Query remote databases
5.1. User Education and Information Discovery
We consider an example from the distributed ontologies that represent the medical
information domain represented in Figure ??. Assume that physicists in the Royal
Brisbane Hospital are interested in gathering some information about the cancer
disease in Queensland (Research, treatment, costs, insurance, etc.) For that pur-
pose, they will use WebFINDIT in order to gather needed information. They will
go through an interactive process using the WebTassili language.
Suppose now that one of the physicists at Royal Brisbane Hospital queries
WebFINDIT for medical research related to cancer disease. For this purpose, he
or she can starts his or her investigation by submitting the following WebTassili
query:
Find Ontologies With Information Medical Research;
In order to resolve this query, WebFINDIT starts from the ontologies the Royal
Brisbane Hospital is member of and checks if they hold the information. The
system found that one of the local ontologies, the Research ontology, deals with
this type of information. Refinement (if needed) is performed until the specific
information type is found. As the user is interested in more specific information
i.e., medical research on cancer, he or she submit a refinement query (find more
specific information type) as follows:
Display SubClasses of Class Medical Research;
The ontology or class Medical Research shows that it contains the subclasses:
Cancer Research, Child Research and AIDS Research. The user can then decide
to query one of the displayed classes or continue the refinement process. As the
user is interested in the first subclass, she or he issues the following query to display
instances of this subclass:
Display Instance of Class Cancer Research;
The user is then faced with two many instances of the subclass Cancer Research
contained in many databases. Assume that she or he decides to query the Prince
Charles Hospital database which is a instance of that subclass. Before that,
the user can become more knowledgeable about this database using a WebTassili
construct that displays the documentation of this information. WebTassili provides
a construct for displaying the documentation of this information. An example of
this query is:
Display Document of Instance Prince Charles Hospital
Of Class Cancer Research;
Assuming the user finds a database that contains the requested information, attributes
and functions are provided to directly access the database for an instance of
this information type. WebTassili provides users with primitives to manipulate data
drawn from diverse information sources. Users use local functions to directly access
the providing databases to get the actual data. In our example, if the user is interested
in querying the database Queensland Cancer Fund from the class Cancer
Research of the ontology Research, he or she uses the following WebTassili query
to display the interface exported by the database:
Display Access Information of Instance Queensland Cancer Fund
Of Class Cancer Research;
At this point, the user is completely aware of this database. She or he knows
the location of this database and how to access it to get actual data and some
other useful information. The database Queensland Cancer Fund is located at
"nicosia.icis.qut.edu.au" and exports several types. Below is as an example
of an exported type:
Type Funding f
attribute string CancerClassify.CommonName;
function real Amount(string CancerClassify.CommonName);
The function Amount() returns the total budget of a given research project. For
instance, if we are interested in the budget of the research project Lung Cancer,
we use the function Amount("Lung Cancer"). This function is translated to the
following SQL query (the native query language of the underlying database):
Select c.Amount
From CancerClassify a, ResearchGroup b, Funding c
Where
and
and
In the above scenario, the user was involved in a browsing session to discover
the databases of interest inside the ontology Research. If this ontology contains a
large number of databases, then browsing the description (documentation or access
information) of the underlying databases may be unrealistic. In such a case, the user
may be interested to query the data stored in these databases using the domain
attributes of the ontology. For example, to the effect of obtaining the name of
projects related to Cancer, the user can type the following WebTassili query:
Select r.Projects.name
Ontologies Research r
Where r.Subject = "Cancer"
This query is expressed using the domain model of the ontology Research. The
system uses the mappings (as defined in Section ??) to translate this query into a
set of queries to the relevant databases that are members of the ontology.
Assume now that another physicist is interested in querying the system about
private medical insurance. The following query is submitted to the system.
Find Ontologies With Information Medical Insurance;
As usually, WebFINDIT first checks the ontologies the Royal Brisbane
Hospital is member of. The two local ontologies Research and Medical fail to answer
the query. WebFINDIT finds that there is an inter-ontology relationship with
another ontology Insurance that appears to deal with the requested information
type. A point of entry is provided for this ontology. In this way, an inter-ontology
relationship contains the resources that are available to an ontology to answer requests
when they cannot be handled locally. To establish a connection with a
remote ontology, a user uses the following WebTassili query:
Connect To Ontology Insurance;
The user is now able to investigate this ontology looking for more relevant infor-
mation. After some refinements, a database is selected and queried as in the first
part of the example.
5.2. Ontologies Interaction and Negotiation
Ontologies and inter-ontology relationships provide the means for dynamically synchronizing
information source interactions in a decentralized manner. By joining an
ontology, databases implicitly agree to work together. Information sources retain
control, and join or leave ontologies/inter-ontology relationships based upon local
considerations. The forming, joining, and leaving of ontologies and inter-ontology
relationships is controlled by privileged users (database administrators).
In some instances, users may ask about information that is not in the local domain
of interest. If these requests are small, a mapping between a set of information
meta types to an ontology via an inter-ontology relationships is enough to resolve
the query. If the number of requests remains high the database administrator may,
for efficiency reasons, investigate the formation of an ontology with the "popular"
remote databases or join a pre-existing ontology. Alternatively, the database administrator
may initiate a negotiation with other database members to establish an
inter-ontology relationship with an existing ontology or database.
Assume that the Medibank database of the ontology Medical Insurance wants
to establish an inter-ontology relationship with the ontology Medical. To initiate
a negotiation with this ontology, the following WebTassili query is used:
Inquire at Ontology Medical;
To send the requested information (i.e., remote structural information) to the servicing
Medical, the representative (administrator site) database uses the following
query:
Send to Medibank
Object Medical.template;
The negotiation process ends (establishment of an inter-ontology relationship or
not) whenever the involved entities decide so. Other primitives exist to remove
methods and objects when an information source relinquishes access to local in-
formation. There are also more basic primitives which are used to establish an
ontology and propagate and validate changes. Each operation must be validated
by all participating administrators. The instantiation operation is an exception. In
this case the information resource described by an object is the one that decides
what the object state should be. If there is disagreement in the validation process,
the administrator who instigated the operation will choose the course of action to
be taken.
A joining information source must provide some information about the data it
would like to share, as well as information about itself. If the new information
repository is accepted as a member, the administrator of the ontology will then
decide how the ontology schema is to be changed. During this informal exchange,
many parameters need to be set. For instance, a threshold for the minimum and
maximum number of ontology members is negotiated and set. Likewise, a threshold
on the minimum and maximum number of inter-ontology relationships with
information sources and ontologies is also set.
Initially, an administrator is selected to create the root class of the ontology
schema. Once this is done, the root of the schema is sent to every participating
information repository for validation. Based on feedback from the group, the creator
will decide whether to change the object or not. This process will continue until
there is a consensus. Changes are only made at a single site until consensus is
achieved - at which time the change is made persistent and propagated to the
appropriate databases. If existing classes/methods are to be updated, responsibility
lies with the information repository that "owns" it.
An ontology is dismantled by deleting the corresponding subschema in every
participating co-database schema. In addition, all objects that belong to the classes
of that ontology are also deleted. The update of co-databases resulting from inter-ontology
relationship changes is practically the same as defined for ontologies. The
only difference being that changes in ontologies obey a stricter set of rules.
6. Implementation of WebFINDIT
This section presents the overall architecture which supports the WebFINDIT
framework. This architecture adopts a client-server approach to provide services
for interconnecting a large number of distributed, autonomous and heterogeneous
databases. It is based on CORBA and Java technologies. CORBA provides a robust
object infrastructure for implementing distributed applications including multidatabase
systems [?]. These applications are constructed seamlessly from their
components (e.g., legacy systems or new developed systems) that are hosted on
different locations on the network and developed using different programming languages
and operating systems [?]. Interoperability across multi-vendor CORBA
ORBs is provided by using IIOP (Internet Inter-ORB Protocol). The use of IIOP
allows objects distributed over the Internet and connected to different ORBs to
communicate. Java allows user interfaces to be deployed dynamically over the Web.
Java applets can be downloaded onto the user machine and used to communicate
with WebFINDIT components (e.g., CORBA objects). In addition, JDBC can be
used to access SQL relational databases from Java applications. Java and CORBA
offer complementary functionalities to develop and deploy distributed applications.
It should be noted that there are other types of middleware technologies besides
Java/CORBA [?] [?]. Other technologies such as HTTP/CGI approach and
ActiveX/DCOM [?] [?] are also used for developing intranet- and Internet-based
applications. It is recognized that the HTTP/CGI approach may be adequate when
there is no need for sophisticated remote server capabilities and no data sharing
among databases is required. Otherwise, Java/CORBA approach offers several advantages
over HTTP/CGI [?]. We note also that the CORBA's IIOP and HTTP
can run on the same network as both of them uses the Internet as the backbone.
Also, the interoperability between CORBA and ActiveX/DCOM is already a reality
with the beta-version of Orbix COMet Desktop [?]. Thus, the access to Internet
databases interfaced using the CGI/HTML or ActiveX/DCOM will be possible at
a minimal cost.
6.1. System Architecture
The WebFINDIT components are grouped in four layers that interact among themselves
to query a large number of heterogeneous and distributed databases using
a Web-based interface (see Figure ??). The basic components of WebFINDIT are
the query layer, the communication layer, the metadata layer, and the data layer.
The query layer: provides users' access to WebFINDIT services. It has two com-
ponents: The browser and the query processor. The browser is the user's interface
to WebFINDIT. It uses the metadata stored in the co-databases to educate users
about the available information space, locate the information source servers, send
query to remote databases and display their results. The browser is implemented
using Java applets. The query processor receives queries from the browser, coordinates
their execution and returns their results to the browser. The query processor
Query Layer
Communication
Layer
Metadata
Data Layer
Layer
Browser
Query Processor
CORBA
IIOP
IIOP
Co-database
Servers
Database
Servers
Information Source
Interfaces

Figure

3. WebFINDIT Layers
interacts with the communication layer (next layer) which dispatches WebTassili
queries to the co-databases (metadata layer) and databases (data layer). The query
processor is written in Java.
The communication layer: manages the interaction between WebFINDIT
components. It mediates requests between the query processor and co-
database/database servers. The communication layer locates the set of servers
that can perform the tasks. This component is implemented using a network of
IIOP compliant CORBA ORBs, namely, VisiBroker for Java, OrbixWeb, and Or-
bix. By using CORBA, it is possible to encapsulate services (i.e., co-database and
database servers) as sets of distributed objects and associated operations. These
objects provide interfaces to access servers. The query processor communicates
with CORBA ORBs either directly when the ORB is a client/server Java ORB
(e.g., VisiBroker) or via another Java ORB (e.g., using OrbixWeb to communicate
with Orbix).
The metadata layer: consists of a set of co-database servers that store meta-data
about the associated databases (i.e, information type, location, ontologies,
inter-ontology relationships, and so on). Co-databases are designed to respond
to queries regarding available information space and locating sources of an information
type. All co-databases are implemented in ObjectStore (C++ interface).
WebTassili primitives are implemented using methods of ObjectStore schema of the
co-database.
The data layer: has two components: databases and Information Source Interfaces
(ISIs). The current version of WebFINDIT supports relational (mSQL, Oracle,
Sybase, DB2) and object oriented (ObjectStore) databases. An information source
interface provides access to a specific database server. The current implementation
of WebTassili provides : (1) translation of WebTassili queries to the native local
language (e.g., SQL), (2) translation of results from the format of the native system
to the format of WebTassili.
6.2. Hardware and Software Environment
The current implementation of our system is based on Solaris (v2.6), JDK (v1.1.5)
which includes JDBC (v2.0) (used to access the relational databases), three CORBA
products that are IIOP compliant, namely Orbix (v2), OrbixWeb (v3), and VisiBroker
(v3.2) for Java (see Figure ??). These ORBs connect 26 databases (databases
and their co-databases). Each database is encapsulated in a CORBA server object
(a proxy). These databases are implemented using four different DBMSs (rela-
tional and object-oriented systems): Oracle, mSQL, DB2, and ObjectStore. The
user interface is implemented as Java applets that communicate with CORBA ob-
jects. ObjectStore databases are connected to Orbix. Relational databases (stored
in Oracle, mSQL, and DB2) are connected to a Java-interfaced CORBA. Oracle
databases are connected to VisiBroker, whereas mSQL and DB2 are connected to
OrbixWeb. CORBA server objects use:
ffl JDBC to communicate with relational databases. In this case, the CORBA
objects are implemented in Java (OrbixWeb or VisiBroker for Java server ob-
jects).
ffl C++ method invocation to communicate with C++ interfaced object-oriented
databases from C++ CORBA servers (both Orbix and ObjectStore support
6.3. Using a Healthcare Application
In order to illustrate the viability of this architecture and show how to
query global information system using WebFINDIT, we have used a Health-care
application. Healthcare applications provide a very relevant context
where tools such as WebFINDIT can be used. The application supports
Database
DBMS
Co-database DBMS
connection to Orbix
ORB not shown.
Java
Browser
Query Processor
User interface Level
IIOP
Orbix
OrbixWeb
VisiBroker
State Govt.
Funding Brisbane
Royal Medibank
CentreLink
RMIT Qld Cancer
Fund
ATO
Charles
Prince
Ambulance
ORBs
CORBA object with
granularity of a
database
Source Level
mSQL mSQL ObjectStore ObjectStore ObjectStore
JDBC JDBC C++ method
invocation
Oracle Oracle Oracle Oracle DB2
Java
OrbixWeb
Medicare
mSQL DB2
Ontos
RBH Workers
Union
QUT MBF

Figure

4. Detailed Implementation.
queries about healthcare related services and enables a large number of heterogeneous
and autonomous healthcare providers to communicate with each
other. In this application, 13 databases are used: State Government Funding,
RBH - Royal Brisbane Hospital, Centre Link, Medibank, MBF, RMIT Medical
Research, Queensland Cancer Fund, Australian Taxation Office, Medicare,
QUT Research, Ambulance, AMP, and Prince Charles Hospital (see Figure ??).
Typically, a user of this application starts by submitting a query about specific
area in the healthcare domain. Assume that the user submits the WebTassili query
"Display Ontologies With Information Medical Research". The system finds that
both ontologies Medical and Research provide information about Medical and
Research. Assume that the user wishes to display all members of the Research
ontology. This can be done by clicking on the Research ontology. The user can
view the result in the lower half of the left hand side window of the Figure ??.

Figure

5. Display Document on RBH Co-Database
To know more on a particular database, the user can click on the corresponding
icon. For example, when the user clicks on the Royal Brisbane Hospital
database, the available formats of documentation is displayed (e.g., text, HTML)
in the right hand side window of the Figure ??. If the user decides to read the documentation
using HTML, he/she clicks on the HTML button. Figure ?? displays
the content of the HTML file containing the documentation of Royal Brisbane
Hospital database.
After locating and understanding the content of the Royal Brisbane Hospital
database, the user decides to query some actual data in this database. Querying
actual data can alternatively be done with embedded queries using native query
languages of the underlying databases. The user now wants to know about the
Medical Students who are doing internships in the hospital (Medical Students
is a type exported by the database Royal Brisbane Hospital). As the underlying
database support SQL, the user can use the SQL statement "select * from
medical students" to get the required information. Once the definition of the
Figure

6. RBH HTML document displayed
query is accomplished, the query is submitted for execution by clicking on the
Fetch button. Figure ?? shows the result of the query. Note that querying actual
data can be done with WebTassili queries. In this case, the query is decomposed
(if necessary) and mapped to queries in the underlying databases.

Figure

7. Query Result on RBH Database
7. Conclusion
We presented an extensible, dynamic and distributed ontological architecture to
support information discovery in Internet databases. The fundamental constructs
ontologies, inter-ontology relationships, and co-databases provide a flexible infrastructure
for both users and Internet databases to discover and share information in
a seamless fashion. A working prototype has been developed. This prototype was
implemented using popular standards in distributed object computing (CORBA)
and the Web (Java). Several commercial and research databases have been been
used in our testbed. We are currently in the process of assessing the performance
of the prototype.

Acknowledgments

The third author would like to acknowledge the support of the Australian Research
Council (ARC) through a Large ARC Grant number 95-7-191650010.



--R


Retrieving and Integrating Data from Multiple Information Sources.
Query Processing in the SIMS Information Medi- ator
Using Bridging Boundaries: CORBA in perspective.
A comparative analysis of methodologies for database schema integration.
Helaland
Data sharing on the web.
An Overview of Mutlidatabase Systems: Past and Present
The world-wide-web
Large multidatabases: Beyond federation and global schema integra- tion
Large multidatabases: Issues and directions.
Using Java and CORBA for Implementing Internet Databases.

Using Java Applets and CORBA for Multi-User Distributed Ap- plications
Information retrieval on the world wide web.
Agents on the web.
Classifying schematic and data heterogeneity in multi-base systems
A query system for the world wide web.
Querying heterogeneous information sources using source descriptions.
Data model and query evaluation in global information systems.
Dynamic Query Processing in DIOM.
OBSERVER: An Approach for Query Processing in Global Information Systems based on Interoperation across Pre-existing On- tologies
Domain Specific Ontologies for Semantic Information Brokering on the Global Information Infrastructure.
Querying the world wide web.
Relationship merging in schema integration.
Client/Server Programming with JAVA and CORBA.
Dynamic Query Optimization in Multidatabases.
Notable computer networks.

Data structures for efficient broker implementation.
Using Carnot For Enterprise Information Integration.
--TR

--CTR
Chara Skouteli , George Samaras , Evaggelia Pitoura, Concept-based discovery of mobile services, Proceedings of the 6th international conference on Mobile data management, May 09-13, 2005, Ayia Napa, Cyprus
Ahmad Kayed , Robert M. Colomb, Using BWW model to evaluate building ontologies in CGs formalism, Information Systems, v.30 n.5, p.379-398, July 2005
Mourad Ouzzani , Athman Bouguettaya, Query Processing and Optimization on the Web, Distributed and Parallel Databases, v.15 n.3, p.187-218, May 2004
internet databases;distributed ontologies;information discovery