Date post: | 30-Jun-2019 |
Category: |
Documents |
Upload: | trinhkhanh |
View: | 212 times |
Download: | 0 times |
Integrating Information from Disparate Contexts:A Theory of Semantic Interoperability
Jacob Lee
CISL WP# 96-02March 1996
The Sloan School of ManagementMassachusetts Institute of Technology
Cambridge, MA 02142
Integrating Information from Disparate Contexts:A Theory of Semantic Interoperability
by
Jacob L. Lee
Submitted to the Alfred P. Sloan School of Management on March 1996 in partial fulfillment of
the requirements for the degree of Doctor of Philosophy in Management
ABSTRACT
Current technology (e.g. the Internet) has provided vast opportunities to link many
information sources (e.g. databases) to many information receivers (e.g. users and applications).
This link, however, provides mainly for physical interoperability. There still remains major
difficulties in achieving semantic interoperability. Semantic interoperability means that sources
and receivers can exchange information in a meaningful manner. Ensuring semantic
interoperability is difficult when sources and receivers have different contexts. That is, receivers
have preferences, goals and assumptions about how to ask questions and interpret answers.
Sources, that have been independently created and maintained, can have a different set of
underlying assumptions, and which are reflected in the way their information is organized and
presented. Receivers may therefore encounter serious difficulties when interacting with the
variety and multiplicity of distributed, autonomous sources.
In general terms, this thesis is concerned with the development of intelligent systems that
will facilitate semantic interoperability between sources and receivers, without violating their
contexts, allowing them to continue functioning "as usual". More specifically, this thesis has three
components. The first component draws upon the philosophical disciplines of Semantics and
Ontology for insights into the nature of semantic interoperability. In the second component,
these insights are integrated into a formal definition of a semantically interoperable system based
on the Context Interchange Architecture. This definition is an abstract specification which
represents a conceptualization of semantic interoperability. It is a formal statement of what a
Context Interchange system should deliver and provides a rigorous basis for an implementation.
In the third and final part of this thesis, a system, which realizes this specification, is developed to
serve as a proof of concept and to illustrate various aspects of the theory developed in this thesis.
Thesis Committee: Professor Stuart E. Madnick (Chair)
Dr. Michael D. Siegel
Professor Yair Wand
Table of Contents
ABSTRACT .1
Table of Contents .................................................................... 2
1 Introduction and Overview ...................................................... 5
1.1 Semantic Interoperability ........................................................................................................ 6
1.2 The Context Interchange Approach ...................................................................................... 11
1.3 T h esis O verview ........................................................................................................................... 14
1.3.1 Ontological and Semantical Foundations .............................................................. 15
1.3.2 Formal Specification of Context Interchange......................................................... 16
1.3.3 Proof of Concept ........................................................................................................ 17
1.4 T hesis O rganization ..................................................................................................................... 18
2 L iterature R eview ....................................................................................................................................... 19
2.1 Obstacles to Semantic Interoperability.................................................................................. 19
2.2 Approaches to Interoperability ............................................................................................... 20
2.2.1 Schema Integration ...................................................................................................... 20
2.2.2 A Loosely Coupled Approach ................................................................................. 23
2.2.3 Implementations that use Ontologies ...................................................................... 24
2.3 The L ogic of C on texts .................................................................................................................. 26
2.3.1 LOC and BULLION .................................................................................................... 27
2.3.2 LOC is a Formal Language ........................................................................................ 27
2.3.3 L O C vs. FO L ................................................................................................................... 28
3 Semantics and Ontology: Philosophical Foundations for Context Interchange .......................... 29
3.1 Semantics and Semantic Interoperability ............................................................................... 30
3.2 Ontology and Semantic Interoperability .............................................................................. 32
3.3 Defining the Shared Ontology............................................................................................... 38
3.3.1 Defining Predicates and Arguments......................................................................... 39
3.3.2 Defining the Deductive Relationships among Propositions................................ 41
3.4 Context Definition Rules and Integrity Constraints............................................................. 44
3.5 Simplifying the task of Domain Definition .......................................................................... 46
4 BULLION: A Proof Theoretic Specification of Context Interchange.................................................. 48
4.1 The Knowledge Level: Background and Motivation ......................................................... 48
4.2 Features and Benefits of the Specification ............................................................................ 51
4.3 The Logical V iew of D atabases: A Review .............................................................................. 52
4.3.1 First O rder Languages .............................................................................................. 52
4.3.2 Relational Databases: The Model Theoretic View............................................... 53
4.3.3 Relational Databases: The Proof Theoretic View ................................................. 55
4.4 A Logical V iew of a C ontext ....................................................................................................... 57
4.5 Adding the Shared Ontology and Context Definition Rules ............................................. 62
4.6 D iscussion ...................................................................................................................................... 66
5 The BU LLIO N Prototype: Proof of Concept I........................................................................................ 68
5.1 Context Interchange for Exam ple A ...................................................................................... 68
5.1.1 Sources and Receivers ............................................................................................... 68
5.1.2 The Shared Ontology and Context Definitions ...................................................... 69
5.1.3 Sam ple Q ueries and A nsw ers ................................................................................. 70
5.2 C ontext Interchange for Exam ple B ....................................................................................... 72
5.2.1 Sources and Receivers ............................................................................................... 72
5.2.2 The Shared Ontology and Context Definitions ...................................................... 72
5.2.3 Sam ple Q ueries and A nsw ers ................................................................................. 74
5.3 C ontext Interchange for Exam ple C ...................................................................................... 75
5.3.1 Sources and Receivers ............................................................................................... 75
5.3.2 The Shared O ntology ................................................................................................ 76
5.3.3 C ontext D efinitions ................................................................................................... 77
5.3.4 Sam ple Q ueries and A nsw ers ................................................................................. 80
5.4 Where did the Data come from? -The Logic Behind the Logic ......................................... 84
5.5 W hat does the data m ean? - C ontext Explication ................................................................ 86
5.7 D iscussion ...................................................................................................................................... 89
6 The BU LLIO N Prototype: Proof of C oncept II ...................................................................................... 91
6.1 Refinem ent 1 ................................................................................................................................. 91
6.2 Refinem ent 2 ................................................................................................................................. 94
6.3 D iscussion .................................................................................................................................... 103
7 Logic as an Im plem entation Paradigm .................................................................................................. 104
7.1 Prolog and Relational D atabases.............................................................................................. 104
7.2 Prolog and Sem antic Q uery O ptim ization ............................................................................. 105
7.3 Prolog and Looping ................................................................................................................... 106
7.4 O ther Logic Program m ing Languages .................................................................................... 108
7.5 The Logic of Contexts Revisited............................................................................................... 109
8 Conclusions and Future W ork ................................................................................................................ 112
8.1 Thesis Sum m ary ......................................................................................................................... 112
8.2 Future W ork ................................................................................................................................ 113
References ................................................................................................................................................................ 115
1 Introduction and Overview
Current technology (e.g. the Internet, client-server systems) has provided vast
opportunities to link many distributed and autonomous information sources (e.g. relational
databases, legacy systems etc.) to many information receivers (e.g. applications, users etc.). This
link, however, provides mainly for physical interoperability. Physical interoperability is primarily
concerned with the connectivity of heterogeneous hardware and software platforms, different
underlying communication protocols etc. There remains, however, major difficulties in achieving
semantic interoperability.
Semantic interoperability means that sources and receivers can interact in a meaningful
manner. Ensuring semantic interoperability is difficult when sources and receivers have different
contexts. That is, receivers have preferences, goals and underlying assumptions about how to ask
questions and interpret data. Sources, which have been independently created and maintained
also have assumptions which may be implicit and which may not be consistent with those of the
receiver. As a simple example, a source may, implicitly, represent financial information of
companies in terms of US dollars, while a receiver assumes these amounts to be in Japanese yen.
Furthermore, a receiver might, tacitly, assume that the source contains financial information
pertaining to all and only companies being traded on the New York Stock Exchange. This might
not be the case. In such a situation, the statistics computed from the source might not be
appropriate for the receiver. Other real world examples of similar problems are described in [40,
56].
Hidden assumptions arise in a particular context because of the need to efficiently store
and communicate information. Usually, there is no need to explicitly state what is generally
assumed to be true by all concerned within a particular context, and source-receiver interactions
do not suffer from conflicting assumptions. However, as businesses increasingly see the need to
integrate information from various autonomous and distributed sources to facilitate business
decisions and operations, the problem of hidden and conflicting assumptions quickly becomes a
serious problem. This situation is aptly summarized by Ventrone and Heiler:
"In current database systems, most of the data semantics reside in the applications rather
than in the DBMS. Moreover, data semantics are often not represented directly in the application
code, but rather in the assumptions which the application -- or, more correctly, the programmer --
makes about the data. This situation is tolerated in local database environments largely because
the local applications work with a shared set of assumptions. However, serious problems are
likely to occur during a database integration...effort because sets of local assumptions clash and
local applications do not have access to the semantics represented in "foreign"
applications...When semantic information that is hidden in applications is made explicit and
accessible through the database, then the semantic problem becomes.. .much more tractable..." [71].
To exacerbate matters, over time, the goals and assumptions of sources and receivers can
change. Furthermore, new sources and receivers can enter an existing federation while existing
sources and receivers may leave. Receivers may therefore encounter serious difficulties when
interacting with the variety and multiplicity of distributed, autonomous sources. Therefore, the
increased access to and the proliferation of information resources are both a boon and a bane to
decision makers. The former because of the easy availability of information required for decision
making. The latter because decision makers are required to expend non-trivial cognitive effort in
order to filter off irrelevant information and to make sense of the relevant information that
remains. In the case where receivers are software programs, a non-trivial amount of maintenance
might be required for these programs to maintain semantic interoperability with sources in a
large scale and dynamic federation. Section 1.1 more concretely describes what we mean by
semantic interoperability between sources and receivers.
1.1 Semantic Interoperability
Consider Example A where two sources are shown in Fig. 1.1 and Fig 1.2. Source 1
contains a set of propositions about the names of companies and the cities in which their head
offices are located. Source 2 contains a set of propositions on the names of companies and the
countries in which they are incorporated. A receiver (Receiver 1) has a view with a schema
r1_country-of-incorporation (Companyname, Countryname). This means that the
receiver sees a virtual table against which it can issue queries. Furthermore, there is a domain
associated with each column in the schemas of the sources and receiver. In this example, the
domains of Company_name for Source 1, Source 2 and Receiver 1 are {cl, c2, c3, c4}, {c5, c6}
and {c2, c3, c4 and c5} respectively. Note that the domain of Companyname in the receiver's
schema can, and in this case does, differ from that of the sources. Besides domain constraints,
there can be other integrity constraints associated with a source schema and a receiver schema.
For the purpose of this example, however, we shall consider only domain constraints.
Now suppose that for all the companies X that the sources and receiver are concerned
with (i.e. c1 to c 6), it is generally known, or agreed upon, that if the head office of x is located in
a city Y, and if city Y is in country Z, then the country of incorporation of company X is country Z.
Knowledge of which cities are in which countries is also available. This knowledge is shown in
Fig. 1.3 and can be used to convert information in Source 1 to information meaningful to the
s1 head office
Companyname Cityname
cl ny
c2 tokyo
c3 london
c4 chicago
Fig. 1.1 Source 1
s2_country-ofincorporation
Companyname Countryname
c5 usa
c6 japan
Fig. 1.2 Source 2
receiver. Note that throughout this thesis, arguments with uppercase first letters represent
variables, otherwise, they represent constants. Thus, ideally, the receiver's view (Fig. 1.4) can be
populated with facts derived from both sources and the knowledge in Fig. 1.3. The companies c1
and c 6 have been excluded from the receiver's view because it is not within the receiver's domain
of interest. The receiver may then issue the following SQL query against this view:
select Companyname
from r1_countryof_incorporation
where Country-name= "usa"
The answer returned should, ideally, be <c 4> and <c 5>, which is consistent with the receiver
context. Observe that the companies named cI and c 6 were correctly excluded from the answer
without requiring the receiver to make the domain restriction explicit in the query. This simple
example illustrates the desired goal of achieving meaningful information exchange while
preserving the autonomy of receiver and source alike. That is, the receiver should be allowed to
issue queries and be presented with appropriate answers in terms it expects. Furthermore, a
receiver should not be required to explicitly state its assumptions that are normally 'taken for
granted' in its local environment within a query. In this particular example, domain assumptions
are taken for granted by the receiver. This is common practice because domain assumptions, like
most context assumptions, tend to be stable over time, and explicating them within a query may
require non-trivial effort. For example, the receiver should not be required to issue a query in
which domain assumptions are explicated i.e.:
select Company-name
from ricountry-of_incorporation
where Countryname= "usa"
and
Company-name= "c 2"
or
Company-name= " c3"
or
Companyname="c4"
or
Company-name=" c5"
VCompany-name, Cityname, Countryname
head_of f ice (Companyname, Cityname) A locatedin
(Cityname, Country-name) =>
country_ofjincorporat ion (Company-name, Countryname).
locatedin (ny, usa).
locatedin (tokyo, japan).
locatedin (london, uk).
locatedin (chicago, usa).
Fig. 1.3 General Domain Knowledge
r1_country-of_incorporation
Companyname Countryname
c2 japan
c3 uk
c4 usa
c5 usa
Fig. 1.4 View of Receiver 1
This does not mean, however, that the receiver need not state its context at all. Rather, we
are advocating that a receiver be allowed to state its context outside the confines of a query. As
the context tends to be stable over time, it can be reused to appropriately process queries during
the period in which the context applies. The receiver need not restate its context each time it
issues a query. Consequently, a consistent and convenient user interface is presented to the
receiver regardless of the source. Supporting receiver autonomy is the key to minimizing the
cognitive effort required by decision makers to interact with sources of data that are
independently created and maintained. And in the case where receivers are computer programs,
receiver autonomy means that the need to rewrite such programs as a result of changes to sources
is minimized, if not eliminated.
This simple example illustrates the fact that hidden assumptions can take the form of
constraints on explicit attributes. However, hidden assumptions can take the form of constraints
on implicit attributes. As a result, it might not be obvious what information is being represented
by the source, or what information is acceptable to a receiver. This makes achieving semantic
interoperability even more difficult. To illustrate this problem, consider Example B, in which the
relation, s3_closing price, of Source 3, is shown in Fig. 1.5.
s3 closing-price
Stock Price Exchange
55.00 ns
stk2 40.00 nyse
stk3 6330.00 tokyo
stk4 6531.00 tokyo
Fig. 1.5 Source 3
It contains information only on stocks traded on the New York and Tokyo stock exchanges, and
their closing prices for a particular date (say ti). The context of Source 3 restricts propositions
about the closing prices such that the currency of the closing prices of stocks traded on the nyse
and tokyo exchanges must be in US Dollars (usd) and Japanese Yen (yen) respectively. These
date and currency assumptions are "understood" in the local environment, but are not explicit in
the relation. This problem has been termed by Kent [41] as domain mismatch and which he claims
to be one of the important problems in semantic integration . Note the complexity of this
problem for Source 3. Not only are the currency values implicit, but they are not the same for all
tuples in the same relation! Thus, there is heterogeneity even for a single attribute!
Now consider Receiver 2, with a different context, whose schema is
r2_closingprice (Stock, Price, Exchange). The receiver is also interested in the closing
prices only of stocks that are traded on the New York and Tokyo stock exchanges at time t1.
However, the receiver expects the currency of all closing prices to be in usd. Let us assume that
Source 3 is used to populate the receiver view. Now, suppose the receiver issued the following
query
select Stock, Price
from r2_closing-price
where Price> 50.00 .
Assuming, for simplicity, that the conversion rate is 1 US dollar to 100 yen, the answer derived
from the source should be, ideally, <stkl, 55.00>,<stk3, 63.30>and<stk4, 65.31>.
These examples illustrate what we mean by semantic interoperability between sources and
receivers.
1.2 The Context Interchange Approach
The goal of the Context Interchange Approach [56, 68] is to achieve semantic
interoperability among sources and receivers. In this thesis, we focus exclusively on structured
data (e.g. relational databases). In order to better understand The Context Interchange Approach,
we shall first consider some alternative strategies which seem relatively "straightforward". One
such strategy is to insist that all sources and receivers adopt a standardized means of
representing and retrieving information. Clearly, a universal standard can result in semantic
interoperability. But achieving such a standard is difficult, if not impossible. This would mean
that existing sources and receivers must migrate to this standard, which is a potentially costly
process. Even a change due to the introduction of a single new European currency unit, the ECU,
can be expensive [30]. New systems must be designed according to this standard, reducing
flexibility and impose more constraints on the design process. Furthermore, a single
standardized representation may not be suitable for all situations or for all concerned. For
example, it may not be practical for a geographically distributed information system to adopt a
single currency for monetary amounts. It may be more convenient to represent money amounts
in terms of Yen for information systems in Japan and in US dollars for systems in the USA.
Therefore, one of the constraints imposed on Context Interchange systems is that the autonomy of
sources and receivers must be preserved.
Could semantic interoperability be achieved, while preserving autonomy, by
constructing translation procedures between sources and receivers? Certainly, if these translation
procedures can be constructed, semantic interoperability can be achieved. Unfortunately, if we
have M sources and N receivers, this might result in M x N sets of translation procedures. This
strategy breaks down when M and N approach large numbers. Furthermore, over time, sources
might modify the way they represent data and receivers might change the format in which they
expect to receive data. This means modifications must be made to existing translation
procedures. And as new sources and receivers are introduced, new translation procedures need
to be constructed. For each new receiver, potentially M sets of translations procedures are
required. Thus, another constraint imposed on Context Interchange systems is that it must be as
scalable andflexible as possible. By scalability, we mean that a Context Interchange system must
be able to accommodate a large number of sources and receivers. By flexibility, we refer to the
ability to easily cope with changes and evolution within a dynamic federation.
The Context Interchange Architecture (Fig. 1.6), which we propose, satisfy these constraints in
two ways. First, sources and receivers are required to explicitly declare their contexts, which
includes otherwise implicit assumptions (e.g. domains and currencies), with respect to a shared
ontology. Second, reusable "general knowledge" is specified at the global level, in the shared
ontology, as opposed to being encoded in local customized translation procedures that are
Shared Ontology
Source Context
Context Mediator
Source
Receiver
Fig. 1.6 Context Interchange Architecture
particular to a source-receiver pair. The shared ontology represents a shared agreement about a
particular domain of interest and forms the basis for the exchange of information among sources
and receiver with different contexts. Without a commitment to a shared ontology, information
exchange would be impossible. Knowledge in the shared ontology will be used by the context
mediator to identify relationships between the source contexts and receiver contexts. For example,
the shared ontology might contain knowledge of currency conversion rates (e.g. from US dollars
to Japanese Yen). Furthermore, since the underlying assumptions of sources and receivers are
explicitly represented, the appropriate conversion rules are automatically selected by the context
mediator to transform source data to appropriate answers for a receiver query. This conversion
knowledge need only be specified once but may be used and re-used to automatically select
conversion procedures for various sources and receivers. This reduces the effort to manually
construct and maintain translation procedures between sources and receivers. The explicit
declaration of contexts and the automatic selection of conversion procedures is, in fact, two key
distinguishing features of the Context Interchange Approach.
Preserving receiver autonomy means that a receiver issues queries as per normal even
though sources and their contexts might change. The receiver is shielded from the details of the
sources used and the transformations that take place "under the hood" in delivering an answer to
a query. Therefore, a third key distinguishing feature of the Context Interchange Approach is the
ability for the system to provide an explanation of the answers delivered to the user. This
explanation should describe
1. What the original data is,
2. Where it came from (i.e. which sources) and
3. How it was transformed to the final answer.
This feature is particularly important because the receiver might be interacting with a wide
variety of unfamiliar sources. Knowing which sources the original data comes from can help
determine the reliability of the answers. Furthermore, decision makers would feel more
comfortable if they were familiar with the assumptions and rules that were used to convert the
original data to the final answer. This capability is analogous to the explanation features which
are deemed to be an integral part of expert systems. Concern about where the original data comes
from motivated the development of a source tagging theory [77, 78]. Here, information retrieved is
"tagged" with the identifiers of original and intermediate sources used to derive the final answer.
However, the user is unable to ask questions about the original data itself or the transformation
rules used to obtain the final answer.
A fourth distinguishing feature of the Context Interchange Approach is that it should
allow users to browse or ask questions about the context of particular sources. This feature is
termed context explication. Context explication enables users to understand the underlying
assumptions of particular sources and to determine the suitability of a source for a particular
application. Once again, this is a very useful feature given the variety of unfamiliar sources a
user might potentially interact with.
In this thesis, a theory of semantic interoperability for the Context Interchange
Architecture is proposed. This model, which applies to multiple sources and receivers, will be
referred to as BULLION, which stands for the BUnge-Lee's Logic of IntegratiON. This theory
draws up on Bunge's Semantics and Ontology [9, 10, 11, 12] and First-Order Logic as its
foundations. We will show how this theory of semantic interoperability realizes the goal of
achieving a high level of semantic interoperability while preserving autonomy, scalability and
flexibility, within an elegant and general theoretical framework.
1.3 Thesis Overview
This thesis is divided into three parts. Each part of the thesis is aimed at achieving a set
of goals. A summary of the thesis goals is shown in Table 1. We will now briefly discuss each of
these parts in turn.
Part 1 Ontological and Semantical Foundations
la Identify the proposition as a basic unit of exchange.
lb Explicate the notion of a context.
1c Explicate the notion of an ontology.
1d Define conversion as deduction.le Develop a framework for defining a shared ontology.
Part 2 Formal Specification of Context Interchange
2a Integrate the notions of context, ontology, proposition andconversion into a proof theoretic specification of a ContextInterchange system.
2b Define what a "mediated" answer to a query is.
Part 3 Proof of Concept
3 Demonstrate proof of concept by means of a series of Prologprograms.
Table 1 Summary of Thesis Goals
1.3.1 Ontological and Semantical Foundations
The theory developed in this thesis proposes an approach for the formalization of semantic
interoperability within the framework of the Context Interchange Approach. Such a
formalization facilitates the identification and representation of the knowledge required to
instantiate a Context Interchange system. In the first part of this thesis, we draw upon Semantics
[2, 9, 10] and Ontology [11, 12] for insights into the nature of semantic interoperability. From
these disciplines, we
la. Identify the proposition as a basic unit of exchange.
1b. Explicate the notion of a context.
1c. Explicate the notion of an ontology.
id. Define conversion as deduction.
le. Develop a framework for defining a shared ontology.
A basic premise of this thesis is that ultimately, the basic unit of information exchange is
an "elementary" proposition. More specifically, propositions about a domain of interest. A source
context defines the set of propositions that are expressible by the source, while the receiver
context defines the set of propositions that are acceptable to the receiver. A context is a set of
constraints on both implicit attributes as well as regular attributes. Thus, traditional integrity
constraints are subsumed under this definition. This conceptualization is particularly useful for
both source and receiver. As we shall see, a source context definition can facilitate semantic
query optimization, while a receiver context definition allows the user to specify assumptions
about implicit as well as regular attributes.
A shared ontology is a shared agreement that defines the global set of propositions for
information exchange and the deductive relationships among these propositions. Finally,
conversions are construed as a chain of deductions. Such a conceptualization allows complex
conversion procedures to be constructed automatically from a set of simpler deductive rules in
the shared ontology. For example, a conversion procedure might comprise a schema translation,
multiple currency conversions, and other arithmetic operations. The ability to automatically
construct complex conversion procedures reduces the need for labor intensive effort. Knowledge
in the shared ontology can also be used to define the context of sources and receivers. This
promotes further re-use of shared knowledge. Finally, we present a framework for defining a
shared ontology.
Each of these ideas are relatively novel with respect to some other integration approaches
(more in Chapter 2). Yet by themselves, they do not appear to offer any significant additional
insight for achieving semantic interoperability. But together, this suite of ideas coalesce into an
elegant conceptualization of semantic interoperability, which results in systems that can achieve
the goals of Context Interchange just described. For this reason, the application of these ideas to
Context Interchange is considered to be the core contribution of this thesis.
1.3.2 Formal Specification of Context Interchange
The second part of my thesis is concerned with integrating these abstract and disparate
concepts into a coherent, formal specification of a Context Interchange System (i.e. BULLION).
A formal specification of Context Interchange is motivated by criticisms raised by a number of
leading academics. For example, in a landmark paper, Reiter criticized the proliferation of
proposals for data models which were "served up without the benefit of an abstract specification"
[62]. Similar sentiments were echoed by the philosopher Bunge with respect to the field of
Artificial Intelligence (Al): "Unfortunately von Neumann's tacit advice - Start by getting hold of a
precise description of the cognitive task you want to simulate on a machine - is all too forgotten.
In fact, AI is clogged by unanalyzed concepts and metaphors, resembling now poetry, now
advertising copy" [13: p2 70]. These sentiments serve to underscore the importance of and,
ironically, the virtually non-existent emphasis on abstract specification in these respective areas.
This is also a problem in the area of interoperable systems.
Furthermore, Newell [61] suggested that logic is ideally suited as a specification
language. Reiter also proposed logic as a specification language for data models, and showed
how the Relational data model [20] may be couched in proof theoretic terms [62]. A logical
specification is precise and explicit, and will aid the comparison, understanding, design and
analysis of system implementations. Therefore, following Reiter and Newell, the specification of
a Context Interchange system will be couched in proof theoretic terms. That is, we
2a. Integrate the notions of context, ontology, proposition and conversion into a
proof theoretic specification of a Context Interchange system.
This specification is important in order to understand, in formal terms, the components of a
Context Interchange system, their relationships and what a Context Interchange system should
deliver. Without such a definition, it will be difficult to proceed in a "scientific" manner.
The goal of Context Interchange is to achieve semantic interoperability while preserving
source and receiver autonomy. An important aspect of this goal is delivering answers that are
meaningful in the receiver's context. The premise of Context Interchange is that a
straightforward query evaluation may not suffice in the case where a source and receiver have
different contexts. The answer to a query must be mediated in some sense, in order to be
meaningful to the receiver. This mediated answer is expected to be different from an unmediated
answer in general. Just what is a mediated answer? If we do not have a formal definition of a
mediated answer, we will not have a rigorous basis for an implementation. With regards to
database research, Reiter has argued that defining an answer to a query is a fundamental step
[62]. Therefore, the specification proposed in this thesis also includes the definition of what a
mediated answer to a query should be, given the various contexts and the ontology (Fig. 1.7).
Given that this specification is to be couched in first order logic, the assumptions and semantics
underlying the Context Interchange approach will be very explicit, which facilitates
understanding and theoretical analysis. Furthermore, the specification will be independent of
idiosyncratic implementation details and limitations. However, various implementations of this
specification are possible, and can differ in terms of the choice of practical trade-offs being made
(e.g. completeness vs. efficiency). Therefore, we
2b. Define what a "mediated" answer to a query is.
(1) source data 0(2)source context 0(3) receiver context - Context Mediator (6) answer(4) shared ontology -O
(5) query 0
Fig. 1.7 Graphical View of the Specification
1.3.3 Proof of Concept
The final question that will be dealt with in this thesis is "Is this an appropriate
definition?". This will be demonstrated by means of a series of Prolog programs. Prolog is a logic
programming language whose relationship to first-order proof theory is well understood [55],
and can itself serve as a specification for lower level languages. In this thesis, the Prolog
programs will be used to demonstrate that this conceptualization of semantic interoperability
meets the expectations of what an answer should be in a Context Interchange system. Sources,
contexts, the shared ontology and queries are all modeled in terms of Prolog statements. These
programs will also be used to demonstrate all the desirable features of Context Interchange
systems including the capability for explanation as well as context explication. Thus, another
goal of this thesis is to
3. Demonstrate proof of concept by means of a series of Prolog programs.
These programs will be used to demonstrate how semantic interoperability can be achieved for
Examples A and B. However, these are relatively simple examples. To further demonstrate the
usefulness and versatility of a BULLION system, we shall show how various obstacles to semantic
integration that have been identified in the literature can be solved within this framework. We
will also argue why BULL ION systems are scalable and flexible, and show how sources and
receivers can be added over time with little effort.
One immediate consequence of this thesis is that it suggests logic programming as an
implementation paradigm for the semantic integration of information sources. This is a novel
application of logic programming and it provides a number of significant benefits, both
theoretical as well as practical, to the task of semantic integration. Thus, we claim that logic can
be used not only to conceptualize Context Interchange, but may be used to implement it as well.
This will be discussed in Chapter 7 of this thesis.
1.4 Thesis Organization
The thesis chapters are organized as shown in Table 2. In Chapter 2, we compare and
contrast other approaches to database integration with the Context Interchange Approach as
realized by BULLION. Chapters 3 and 4 deal with Parts 1 and 2 of Table 1 respectively. Chapter 5
and 6 correspond to Part 3. Chapter 7 discusses logic programming as an approach to the
semantic integration of information sources. The thesis concludes with Chapter 8.
Chapter Title
1 Introduction and Overview
2 Literature Review3 Semantics and Ontology: Philosophical Foundations for Context
Interchange4 BULLION: A Proof Theoretic Specification of Context Interchange
5 The BULLION Prototype: Proof of Concept I
6 The BULLION Prototype: Proof of Concept II
7 Logic as an Implementation Paradigm
8 Conclusions and Future Work
Table 2 Summary of Thesis Chapters
2 Literature Review
2.1 Obstacles to Semantic Interoperability
Various kinds of heterogeneities present obstacles to the achievement of semantic
interoperability. In order to characterize these heterogeneities, We will use the notions of a
symbol, a construct and a context. One of the most basic distinctions emphasized in Semantics is
the distinction between a symbol and a construct. A symbol is a physical object (e.g. a character
string) that is used to designate meaning. A construct, on the other hand, is the meaning
assigned to a symbol and has no physical existence apart from mental processes [9: pp. 21-23].
Finally, a context is a set of constructs [9].
For the purpose of this thesis, I will therefore classify heterogeneities as symbolic and
context heterogeneity. The most commonly cited forms of symbolic heterogeneity are homonyms
and synonyms which give rise to naming conflicts [8]. Homonyms refer to identical symbolic
items that designate different constructs. Synonyms refer to different symbolic items that
designate the same construct. Naming conflicts arise in databases not only at the schema level,
but also at the instance level. As an example of the former, an attribute name Revenue in a
relation might mean the same thing as an attribute name Rev in another relation (i.e. a synonym).
This is a naming conflict at the schema level. In Example A, if the company names c1 in Source 1
and c5 in Source 2 refer to the same company, then there is a naming conflict at the instance
level.
Another type of symbolic heterogeneity, known as schematic discrepancy, has been
identified by Krishnamurthy et al [44, 45]. To illustrate, they used three databases euter, chwab
and ource.
Database euter:
relation r : {(date, stkCode, clsPrice) ... }
Database chwab:
relation r : {(date, stkl, stk2,...)...}
Database ource:
relation stkl: {(date, clsPrice)...},
relation stk2: {(date, clsPrice)...},
Observe that the "same" information is encoded by each database. Furthermore, there are no
naming conflicts due to homonyms and synonyms per se. For example, the stock codes (i.e.
stkl, stk2 etc.) are consistent in all three sources. However, in one source, the stock codes are
instance values, in the second the codes are attribute names and in the third they are relation
names. Although the same information is conveyed in these databases, the values that may be
retrieved by means of a query language like SQL will vary for each database. This is because SQL
can only retrieve instance values. Thus, SQL can retrieve stock codes from euter but not from the
other two databases.
Assuming that symbolic heterogeneity has been resolved, there still remains the problem
of context heterogeneity. That is, different sources and receivers represent and accept different
sets of constructs. For example, one source is able only to represent the construct f ather while a
receiver might only accept parent. In this case, one construct is at a higher level of abstraction
than the other i.e. one is a generalization of the other [25].
Examples A and B of Chapter 1 also illustrate various context heterogeneities. Source 1
only represented information about the locations of head offices of various companies, whereas
Receiver 1 would like only information about the countries in which these companies are
incorporated. Another problem is presented in Example B where in Source 3, not only was the
currency of the closing prices implicit, but the currency was not the same for all tuples. The
receiver, however, expected all prices to be in a single currency! As another example, a source
might only have information about the Revenue and Expense of companies, whereas a receiver
might accept only information about the Prof it of these companies.
2.2 Approaches to Interoperability
In response to these various problems, there has been a proliferation of database
integration approaches. Some of these approaches involve the construction of global schemas [4,
46, 58] or federated schemas [36]. Other approaches are considered loosely coupled [44, 45, 53]. For
a survey of these various approaches, the reader may refer to [54, 67]. However, dissatisfaction
with the various inadequacies of these approaches has led to recent work that draw upon the
insights from the Artificial Intelligence and Knowledge Representation communities [3, 21, 33].
We will now describe each of these approaches in turn.
2.2.1 Schema Integration
One approach to achieving semantic interoperability that has been prevalent in literature
involves the integration of source schemas into a global schema or superview. Receivers are then
provided an integrated view of the underlying databases and can issue queries against the global
schema. Alternatively, local receiver views can be defined against this global view. We consider
the approaches described in [4, 25, 46, 58, 59] to be typical of schema integration approaches
although they may differ from each other in various respects. Therefore, we shall consider these
particular approaches for the purpose of our comparison.
A global schema primarily captures knowledge of aggregation and generalization as
discussed in [69]. Informally speaking, attributes A1,...,Am (as in the columns of a relation) of a
class of entities can be aggregated with attributes A m+1,...,An of another class to form a new class
with attributes A1,...,An. If every instance of a class C1 is also an instance of a class C2, then C2 is
a generalization of C1. Generalization can be used to resolve differences in levels of abstraction
[25,48]. In [4], aggregation and generalization are described in Entity-Relationship (ER) terms as
relationships and ISA respectively.
A global schema, as described in [4, 58, 59] "does not provide enough semantics" [67] and
is therefore limited in its ability to capture relationships among concepts. For example, a global
schema cannot capture the kind of knowledge described in Fig. 1.3, i.e. the rule
VCompanyname, Cityname, Countryname
headoffice (Company-name, City-name) A locatedin
(Cityname, Countryname) =
country-ofjincorporation (Company-name, Country-name).
cannot be encoded in a global schemas as defined in [4,58].
The conversion knowledge required to resolve various conflicts, such as naming conflicts,
scale conflicts and so on, are captured in the mappings between local schemas and the global
schema. However, the resolution of naming conflicts in schema integration, by definition, is
restricted to the schema level. Naming conflicts at the instance level are typically ignored. These
mappings are referred to as view definitions.
In an example used in the description of Multibase [46], some sources contained
HOURLYWAGE information while other sources contain YEARLYSALARY information.
However, the global schema cannot represent both at the same time. So, one attribute,
YEARLYSALARY, was chosen to be represented in the global schema. Functions to convert
HOURLYWAGE in different sources to YEARLYSALARY in the global schema are then encoded in
view definitions for the respective databases. Thus, for each database which contains
HOURLYWAGE information, one such conversion procedure is required. This conversion cannot
be expressed in the global schema itself. As another example described in [25], one source had Ht
(i.e. Height) information in inches (ins), while another had Ht information in centimeters (cms).
Only one of these can be represented, so Ht in cms was chosen as a unifying dimension. The
conversion of from ins to cms is then encoded in a view definition.
This strategy presents a problem because the same conversion rule may have to be
constructed many times for different sources. Furthermore, if there is a change in the rule (e.g.
the conversion from HOURLYWAGE to YEARLYSALARY changes), all the affected view
definitions need to be changed. This may be a non-trivial task if there are many sources involved.
Furthermore, conversion procedures embedded in view definitions can obscure the semantics of
the databases.
Thus, it is not surprising that the maintenance of a global schema is difficult [36, 52, 53].
For one thing, local schemas may change over time and the literature is "largely silent" [8] as to
how to manage the evolution of local schemas. To reduce the magnitude of this problem, a
strategy was proposed in [36], which involved "a selective and controlled integration of its
components" and "represents a compromise between no (schema) integration...and total (schema)
integration" [67]. In essence, this strategy reduces the degree of information sharing in order to
reduce the difficulty of maintaining a global schema. In contrast, the Context Interchange
Approach is expected to maintain a high degree of information sharing without the
corresponding degree of difficulty found in schema integration strategies.
In summary, the schema integration approach is not as scalable or flexible because
(1) the global schema is not able to accommodate richer forms of general knowledge that
might be reusable and
(2) does not offer a means to effectively explicate the underlying assumptions associated
with various schemas (e.g. implicit assumptions about currencies).
In contrast, the Context Interchange Architecture, as realized by the BULLION model,
allows richer forms of reusable general knowledge to be captured at the global level. Such
knowledge may be used for both conversion as well as for explicitly defining the underlying
assumptions of sources and receivers. Furthermore, as underlying assumptions of sources and
receivers are made explicit, the context mediator automatically selects the appropriate conversion
procedure if one exists. A universally agreed upon conversion procedure (e.g. ins to cms) need
only be encoded once at the global level. Moreover, this conversion can be used not only for the
attribute Ht, but also for any other attribute with a length dimension (e.g. Wais t_Si ze). Thus,
even a single database with more than one attribute with a length dimension can benefit from this
re-use. This minimizes the load on the local database administrators in constructing conversion
procedures and for adapting to change.
The work on schema integration has been further developed by assuming that a key issue
is the identification of attribute equivalence [47] in different schemas. The key idea is that there
may be various degrees of equivalences among various attributes from different databases. For
example, the attribute company-name in Source 1 may be equivalent to the attribute
Companyname in another source if they have identical domains. Along similar lines, Sheth and
Kashyap [66] proposed the notion of semantic proximity to define the relevance of one attribute to
another. This approach involves a form of uncertain reasoning.
However, this approach is narrow and limited for the purpose of achieving a high level
of semantic interoperability. For example, it does not matter whether or not City_name in
Source 1 is equivalent or semantically close to Country-name in Receiver 1. The important
thing is whether or not the country of incorporation of a company can be derived from its head
office location. Similarly, it matters not if Revenues, Prof its and Expenses are semantically
close. What matters is that knowing two of these attributes will enable us to deduce the third.
Finally, the classical techniques used in schema integration cannot solve the problem of
schematic discrepancies as pointed out in [44, 45]. It is for this reason that the loosely coupled
approach has been introduced.
2.2.2 A Loosely Coupled Approach
A radically different approach was proposed in [44,45,52,53] which involved no schema
integration. It is referred to as the loosely coupled approach [67]. The motivation for this approach
is due to existence of schematic discrepancies which cannot be resolved by schema integration.
In essence, users are provided with powerful query languages and tools that enable them to
retrieve information from various sources. Thus, even if schematic discrepancies exist, the user
can successfully retrieve information. The problem, of course, is that the burden of "integration"
is shifted to users who are then confronted with a multiplicity of autonomous sources with
varying semantics, some of which are not explicit. As the sources that users need to interact with
grow in number or change, more and more cognitive effort is demanded of users. This approach
violates the notion of receiver autonomy. Fortunately, there is a better alternative. In Chapter 5,
we will demonstrate how the problem of schematic discrepancies can be resolved by the
BULLION approach, without resorting to higher order query languages, and placing the burden
on the receiver.
2.2.3 Implementations that use Ontologies
Problems with the schema integration and the loosely coupled approaches have led to
another stream of research that rely on shared ontologies. Currently, there is a great deal of interest
in the development of ontologies to facilitate knowledge sharing in general [31, 32, 60], and
database integration in particular [21, 64]. We will present more detailed discussions on the
notion of an ontology in Chapter 3. For now, we focus on integration approaches that rely on the
use of a shared ontology.
The Carnot project [21, 37, 65] is an approach that tries to reduce the effort of constructing
a global schema by using an existing ontology, the Cyc ontology [34, 49], as the global schema.
Source and receiver schemas are then mapped to the Cyc ontology by means of articulation
axioms. Articulation axioms are analogous to view definitions in Multibase. The assumption here
is that the global schema already exists and can be used for integration. The portion of the
knowledge in Cyc used by Carnot is still fundamentally based on aggregation and generalization
[2 1:p 6O, 37:p295].
There was also no specific discussion in the references [21, 37, 65] of how incompatible
units and scales are resolved in Carnot. For example, how would the Carnot approach address
the problem discussed earlier about Ht in cms and ins? One possibility is to create two Cyc
concepts Ht_in_cms and Ht_inins, and then define the conversion relationship between
these concepts in the Cyc ontology. Such a conversion relationship however cannot be expressed
in terms of aggregation or generalization. Another way is the Multibase approach. That is,
represent Ht_incms (say) in the Cyc ontology and encode the conversion function in the
articulation axioms. As pointed out earlier however, this method limits reuse of such standard
conversion procedures. Carnot also does not address the issue of explicating underlying
assumptions of sources and receivers.
The SIMS project [3] deals primarily with planning and reformulating of queries for
retrieving data from multiple databases more efficiently. The ontology, which is represented in
LOOM, contains knowledge about the information various databases have on various classes of
entities (e.g. Commercial ships, naval ships etc.). This facilitates the selection of appropriate
sources for data retrieval. As in classical schema integration, key concepts used in SIMS are
generalization and specialization as manifested in the specialize-concept and generalize-
concept operators. However, SIMS is not intended, to deal with the problems of semantic
interoperability described in Chapter 1. Thus, for example, even if the SIMS query planner
selected the database with the right companies, it cannot convert heado f f ice information to
country-of_incorporation information. Furthermore, the SIMS approach does not deal
with issues of hidden semantics.
Another approach, the theory of semantic values [64], has been proposed as a means of
realizing the Context Interchange Architecture. This theory describes a means to explicitly and
non-intrusively represent meta-attribute values associated with various base (or application)
attributes. For example, consider a source with schema f inances (Company-name, Revenue,
Expense). The attributes Company-name, Revenue and Expense are base attributes. We
can then associate a meta-attribute Currency with base attributes Revenue and Expense for
example. Next, we can also associate conversion functions with meta-attributes. For example, let
us consider converting a Revenue of 10,000 US dollars to yen. This currency conversion is
specified as
cvtVal(10000{Currency=usd}), {Currency=yen})
and returns the value 1000,000 (assuming a conversion factor of 100). This approach is better
than the global schema approach in that conversion functions are centralized and a means for
specifying hidden assumptions explicitly is provided.
Although BULLION is based on the same architecture as the theory of semantic values,
there are significant points of departure in terms of the conceptualization of
(1) a conversion,
(2) a shared ontology and
(3) a context.
There are some limitations in the manner in which a conversion function is
conceptualized in the theory of semantic values. By definition, such conversion functions are
associated with meta-attributes. Conversions between base attributes therefore cannot be
specified. For example, we might want to derive a base attribute Profit from Revenue and
Expense. A conversion function, as defined in the theory of semantic values, does not
incorporate any knowledge of which base attributes are involved. Hence there is no way do
incorporate knowledge of the relationships among base attributes in conversion functions.
In BULLION, a conversion is a more general notion and is defined by means of a
deductive law. This allows us to specify conversions between attributes such as Profit,
Revenue and Expense. A set of deductive laws can be chained together to form more complex
conversion procedures.
Moreover, general knowledge in BULLION can be encoded at the global level in the
shared ontology, and can be used for both the definition of contexts and conversion. BULLION
does not distinguish knowledge used to define contexts from knowledge used for conversions.
This promotes greater re-use of knowledge. This is not the case for the theory of semantic values
where the shared ontology is distinct from the set of global conversions.
Finally, in the theory of semantic values, explicating hidden assumptions referred to
defining the values of meta-attributes associated with base attributes. In BULLION, the notion of
a context is more general. A context definition can include constraints on the values of base
attributes as well. This allows a receiver to express other kinds of assumptions, such as domain
assumptions, as part of its context definition. Furthermore, a source context defined in this
manner can facilitate semantic query optimization which we will discuss later in the thesis.
2.3 The Logic of Contexts
The notion of a context has been introduced in Al by John McCarthy in his Turing Award
lecture[57] to deal with the problem of generality in AI. R. V. Guha's thesis [33], which was
supervised by McCarthy, was an in-depth study of context. Guha's research primarily centered
around the Cyc system [34, 49]. Without the notion of contexts, it would have been virtually
impossible to manage a knowledge base the size of Cyc. The notion of a context makes the task
of managing a huge knowledge base like Cyc more manageable by partitioning the knowledge
base into smaller "chunks".
Guha's thesis represents the initial work on the Logic of Contexts (LOC). Further
development of LOC can be found in [14, 15]. Essentially, the LOC is a an extension of first-order
logic. More specifically, a second order predicate is t (c , p) is introduced, where c is a context
and p is a proposition that is true within this context c. LOC is primarily concerned with the
truth of propositions in various contexts.
Consequently, one of the strengths of LOC is the ability to express multiple, inconsistent,
theories in the same knowledge base. Thus, "Michael Jordan is tall" and "Michael Jordan is not
tall" are sentences that can coexist in the same knowledge base because the former sentence is
asserted in the context of people in general, while the latter is asserted in the context of basketball
players. A set of sentences associated with a context is termed a microtheory.
2.3.1 LOC and BULLION
The notion of a context defined by Guha differs from that used in BULLION. When
viewed from the perspective of LOC, the BULLION model, which includes sources, context
definitions and the shared ontology, would be considered a single consistent microtheory, i.e.
having a "single context". Thus, as far as BULLION is concerned, when a proposition is asserted
as true within a source or the shared ontology, it is viewed as true throughout the federation. To
resolve confusion with terminology, we will use the term microtheory instead of context when
referring to the concept as used in Cyc.
An in-depth treatment of a federation of sources and receivers with multiple inconsistent
theories is beyond the scope of this thesis. However, as a federation continues to grow, this
problem becomes unavoidable. Therefore, towards the end of this thesis, we will briefly consider
how the BULLION model might be extended, by means of LOC, to manage a large-scale and
dynamic federation. This is very much in the spirit of the Cyc knowledge base. And given that
BULLION is specified in first-order logic (FOL), making the conceptual leap to LOC, an extension
of FOL, is not too difficult as we shall see.
2.3.2 LOC is a Formal Language
Just as FOL is a formal language, so too is LOC. Therefore, just like any language, LOC
may be used to express various forms of knowledge without necessarily telling us what that
knowledge should be. In fact, Guha states that "Merely providing a syntax and semantics of a
new logic does not solve any problem. We need a better understanding of what contexts can be
used for and how they are to be used" [33:p2l]. In his thesis, Guha illustrated, with examples,
various possible applications of this formalism, including the integration of databases. In fact, the
Carnot project is the result of applying this formalism to the integration of databases. However,
in Carnot, LOC was used essentially for the purpose of schema integration, not very different
from the classical global schema approaches. The BULLION model, on the other hand, is not a
formal language but a theory about the identification, organization and use of knowledge needed
to realize the goals of the Context Interchange Approach. Nothing in the LOC tells us how to do
this.
Given that LOC is a very expressive formalism, it is amenable to a wide variety of
applications [33], including schema integration (as in the Carnot project), and can even be used
for the formalization of the BULLION model as well. Indeed, it was argued by Farquhar et al that
LOC can be used to express the global schema, federated or loosely coupled approach [27]. Thus
LOC offers a very powerful framework in which to understand and analyze various integration
strategies.
While it might be true that the LOC can be used to express these strategies, which differ
in fundamental respects from one another, Farquhar et al did not present any particular strategy
of their own. For instance, the loosely coupled approach hardly encodes any conversion
knowledge, leaving the problem for the user; the global schema approach encodes conversion
knowledge in view definitions; and BULLION advocates encoding appropriate knowledge at the
global level for the purpose of conversion as well as context explication. Farquhar et al, however,
did not say anything about how to manage and use conversion knowledge.
Furthermore, the notion of hidden assumptions described by Farquhar et al is essentially
the same as that described in the theory of semantic values, which in turn is subsumed by that
defined in BULLION. The notion of a query, described by Farquhar et al, is equated to theorem
proving. This is the same in BULLION except that we need not devise new theorem provers as
they already exist for FOL. The point is this, while LOC can say anything, Farquhar et al did not
say anything new with it.
2.3.3 LOC vs. FOL
Although LOC can also be used to formalize the BULLION model, FOL is sufficient for
our purposes and will be used to describe the BULLION model instead. The choice of FOL is due
to the fact that FOL has been around a much longer time and is well understood from a
theoretical standpoint, compared with the more recent theory of LOC [14, 15]. From a practical
standpoint, tools based on FOL such as logic programming languages (e.g. Prolog [191) are more
readily accessible. Thus, a BULLION prototype can easily be built using Prolog, for example.
Moreover, logic programming languages are based on well established theoretical foundations
[35, 38, 55]. Also, FOL's relationship to databases is well understood and documented [22, 29]. In
fact, towards the end of this thesis, we discuss logic programming as an implementation
paradigm for BULLION.
Finally, there is always a fundamental trade-off between expressiveness and efficiency of
a knowledge representation [51]. Computing with such an expressive formalism as LOC might
have some adverse consequences on the efficiency of query processing. Therefore, we should not
use a computational formalism that is more expressive than required. For the purpose of this
thesis, in which we do not deal with multiple inconsistent theories, FOL is sufficient. In the
future however, more general extensions to the BULLION model that are required to manage
multiple inconsistent theories might require a tool such as LOC.
3 Semantics and Ontology: Philosophical Foundationsfor Context Interchange
In this chapter, we present the philosophical foundations for Context Interchange. In
particular, we draw upon the disciplines of Semantics and Ontology. Our main source of insight
is from Treatise in Basic Philosophy by philosopher Mario Bunge [9, 10, 11, 12]. Wand and Weber
were the first to draw upon Mario Bunge's Ontology [11, 12] as a formal foundation for their
work in systems analysis and design [74]. The reader may also refer to [72, 73, 74, 75, 76] as
instances of other work by Wand and Weber that relied on Bunge's Ontology as a formal
foundation.
Wand and Weber found that concepts provided by Bunge's Ontology were "rich and
complete enough" to serve as a formal foundation for the phenomena they were trying to model.
They were then able to make predictions, based on this formal model, about the strengths and
weaknesses of various design methodologies. Finally, the formal model facilitated the
construction of computerized tools to support information systems analysis and design [74].
The work described in this thesis is similar to that of Wand and Weber's in that it draws
upon concepts from Bunge's Ontology such as the notion of a thing, a property, a state and a
system. However, Wand and Weber relied almost exclusively on Bunge's Ontology. For our
purposes, we also draw upon Bunge's work on Semantics [9, 10]. In particular, Bunge discusses
the notion of a context in Semantics. Together, Bunge's Ontology and Semantics provide a suite of
ideas that are particularly relevant to the achievement of semantic interoperability. These ideas
are then integrated into a coherent model of Context Interchange, which is a key contribution of
this thesis.
Generally speaking, agents (i.e. sources and receivers) communicate by exchanging
symbols. Symbols are assigned meaning (i.e. constructs) by these agents. Communication involves
the exchange of propositions or statements about a perceived reality. Without a shared perception
of reality, no meaningful communication can take place. We refer to the explicit description of a
shared perception of reality as the shared ontology.
The study of symbols and meaning falls within the realm of Semantics, while the study of
reality is the central concern of Ontology. Bunge describes the study of Semantics as '...concemed
not only with linguistic items but also, and primarily, with the constructs such items stand for
and their eventual relation to the real world' [9: p. 2]. Also, Bunge stated that '...an ontology is not
a set of things but a philosophical theory concerning the basic traits of the world' [9: p. 38].
Semantics and Ontology therefore 'far from being mutually exclusive, are complementary' [9:
p.4 2 ].
It is therefore not surprising that these disciplines together can provide important
fundamental insights to the problem of semantic interoperability. Semantics and Ontology
provide a basis for a formal description of a shared ontology, contexts, propositions and the
exchange of information across different contexts. Bunge's Ontology can be used to highlight
important aspects of the perception of reality that must be agreed upon by sources and receivers
in order to have meaningful communication. Semantics provides a framework for defining and
representing contexts and the translation of propositions.
Relevant concepts from Semantics and Ontology are discussed in Section 3.1 and 3.2
respectively. These ideas provide a framework for defining a shared ontology (Section 3.3) as
well as contexts (Section 3.4). A simple example is provided showing how the shared ontology
and contexts may be defined in practice.
3.1 Semantics and Semantic Interoperability
In [48], the situation was described in which groups had different local languages with no
language in common. For example, one group may speak English, another French, and yet
another Japanese. With no common language, pairwise translation rules have to be devised in
order to communicate across groups. However, the distinction between symbols and constructs
was not explicit in the analysis. Recall that a context is essentially a set of constructs. The context
of a language is the set of constructs associated with the symbols of the language. When groups
have different languages, their respective contexts might be disjoint, overlapping or in a subset-
superset relationship with one another. Without differentiating between symbols and constructs,
these conditions cannot be distinguished from one another. This prevents a finer level analysis of
the nature of "translation rules" required to achieve meaningful communication. Specifically, if
the contexts are overlapping or in a subset-superset relationship, then pairwise translation of
symbols can be useful in facilitating communication. Such symbolic translations involve
mapping different symbols that stand for the same construct to one another. If however, the
contexts are disjoint, such symbolic translations do not exist because there are no constructs in
common. What is needed is a means to resolve context heterogeneity, which implies the ability to
relate constructs in the one context to "equivalent" constructs in another context. Semantics offers
important insights into the issue of context heterogeneity.
We first distinguish between two classes of constructs, namely concepts and propositions
[9: p14]. Concepts are unit constructs such as "father". Propositions, unlike concepts, are
statements or facts to which we can attach a truth value e.g. "Jack is the father of Jill".
A basic premise of the BULLION model is that semantic interoperability is based on the exchange
of basic units of information that are "elementary" propositions. Thus, with reference to a
particular domain of discourse, the expression "The closing price of stkl traded on
the New York stock exchange is 55.00 US dollars at time tl1" is considered a
proposition and we can attach a truth value to it. Furthermore, this proposition is considered
"elementary" if it becomes ambiguous when any part of the proposition is omitted. This will be
the case, for example, if time is omitted from the proposition, and various times are possible in
the domain of discourse. Therefore, elementary propositions are propositions that are sufficiently
specific with respect to a universe of discourse. On the other hand, the proposition " cl ' s head
office is in New York and cl is incorporated in the USA" isnotanelementary
proposition as it says two things about c1. Thus, elementary propositions are "minimal" yet
"sufficient" in some sense. Whether or not a proposition is elementary is an empirical issue and
will depend on the particular universe of discourse.
In Semantics, there are various ways in which constructs can be related to one another.
More specifically, there are meaning relations [2] among concepts and among propositions which
can be exploited for the purposes of translation. Concepts are related to one another via meaning
inclusion. For example, the concept "parent" includes the meaning of "father". The reader will
quickly recognize this as the notion of generalization. Generalization is highlighted as an
important mechanism for achieving semantic interoperability [25], and is operationalized in [48]
as a type hierarchy. Thus the concept " f ather" can be translated to the more general concept
"parent" if the receiver understands the concept of "parent" but not "f ather".
Propositions, on the other hand, are related to one another by means of entailment or
logical deduction. Proposition A entails proposition B is written as A =: B. This means that the
truth of the proposition A necessitates the truth of proposition B. It seems logical, therefore, to
consider using entailment for the purposes of translating propositions. In fact, this was
illustrated in Example A. Furthermore, meaning inclusion can be viewed as a special case of
logical implication i.e. Vx father (x) =:> parent (x). Conversion rules based on logical
deduction, therefore, affords us a wider range of translations than is possible with rules based
solely on meaning inclusion. In BULLION, the conversion of propositions is based on entailment.
However, we do not necessarily mean to suggest that a translation must be computed using logical
implication, only that it ought to be conceptualized as such.
Another notion from Semantics that is of particular importance for our purposes is the
notion of a context defined by Bunge as C = (S, P, D) [9: p57]. D, the domain of the context, is a set
of individuals. There are no other individuals in C other than those in D. P is a set of predicates
that are meaningful in C, with well-defined arity (i.e. number of arguments in its argument list).
Woods [79] drew a distinction between the intension and extension of a predicate. For example the
extension of the predicate red is the set of all red things. The intension of red is the meaning of
the notion of redness. In this case, P corresponds to a set of predicate intensions or meanings. It
is important to distinguish between the extension and the intension of a predicate because the
same predicate may have different extensions in different contexts. Thus the extension of the
predicate red in the context of fruits, is different from the extension of red in the context of cars
for example. Conversely, predicates with different intensions can have the same extensions. For
example, the predicates big and heavy might refer to the same set of people. S is a set of
statements or propositions which contain only predicates from P and arguments from D, and can be
construed as the set of statements that are allowed within the context.
This notion of a context, therefore, highlights three important components. D is an
important component because it defines the set of all the individuals that a source knows about,
or all the individuals that a receiver is interested in. D defines the scope of universal
quantification (i.e. "for all x") which may vary from context to context. In the si head of f ice
relation described in Chapter 1, D contains companies and cities. Another important component
of contextual knowledge are the predicates in P. These predicates represent the attributes of
individuals in D.
The third component is S, the set of statements that is allowed within the context. Such
restrictions are an important part of the contexts of sources and receivers. This component of the
source context defines the set of propositions expressible by the source. In Example A, the source
can only express propositions pertaining to the location of the head offices of certain companies.
The corresponding component for the receiver context defines the set of propositions acceptable
to the receiver. So in Example A, the receiver accepts only propositions pertaining to the
countries in which certain companies are incorporated. As another example, in Source 3 of
Example B, the currency of closing prices must be in yen for a stock traded on tokyo. The
corresponding receiver, on the other hand, only accepts closing prices with currencies in usd.
3.2 Ontology and Semantic Interoperability
Gruber states that an ontology embodies a set of ontological commitments which is an idea
"based on the Knowledge-Level perspective" [32]. From this perspective, when an agent commits to
an ontology, its actions are consistent with the ontology. Gruber defines an ontology as a
statement of a logical theory. According to Gruber the definition of a shared ontology involves
the definition of:
"...vocabularies of representational terms - classes, relations, functions and object
constants-with agreed upon definitions ...Definitions may include restrictions on domains
and ranges, placement in subsumption hierarchies, class wide facts inherited to instances
and other axioms" [31].
Elsewhere [32], he states that:
"Ontologies are often equated with taxonomic hierarchies of classes, class definitions, the
subsumption relation, but ontologies need not be limited to these forms. Ontologies are
also not limited to conservative definitions, that is, definitions in the traditional logic sense
that only introduce terminology and do not add any knowledge about the world
[26] ...[but] one needs to state the axioms that do constrain the possible interpretations for
the defined terms".
Gruber has proposed several desirable characteristics of a representation of an ontology
[32], namely, clarity, coherence, minimal encoding bias, minimal ontological commitment and
extendibility. Clarity simply means that the shared ontology must be understandable to all
concerned. Coherence means that the ontology must be logically consistent. Minimal encoding
bias means that an ontology should contain knowledge about a universe of discourse, not of any
particular encoding scheme. Gruber gave an example of an encoding bias where a physical
quantity was constrained to represent double-float numbers. This is an encoding bias
because it reflects the precision of the encoding numbers which is an implementation detail.
Rather, an ontology should be specified "at the knowledge level" and reflect the "knowledge-level
commitments of parties to an ontology". So it is better to change the constraint from double-
float to real.
Minimal ontological commitment means that an ontology should be a basic or weak
theory of the universe of discourse. Thus, a set of agents who commit to the same ontology agree
on some basic facts but not necessarily on everything. Finally, extensions to an ontology should
be monotonic. That is, new facts added to the ontology should be consistent with the existing facts
in the ontology.
With respect to BULLION, a shared ontology defines (1) a global set of elementary
propositions and (2) the deductive relationships among these propositions, in terms of a global
language. The above guidelines given by Gruber, however, are relatively general and do not tell
us specifically how to organize a shared ontology in terms propositions and deductive
relationships.
In this thesis, we will rely on Bunge's Ontology to provide a fundamental framework for
organizing the shared ontology. Certainly other ontological theories may be employed for such a
purpose. In fact, towards the end of [32], Gruber surveys various examples of ontologies
including Mario Bunge's. Gruber also states that "the utility of an ontology ultimately depends
on the utility of the theory it represents".
On our part, however, there are various pragmatic reasons why we chose Bunge's
Ontology in particular. First, as we have used concepts from Bunge's Semantics, it makes sense
to also use Bunge's Ontology for consistency in theories and definitions. Second, as we
mentioned in the beginning of this chapter, Bunge's Ontology has been introduced, by Wand and
Weber, into the information systems literature and was found to be useful for modeling various
information systems concepts. Finally, we find that Bunge's Ontology indeed provides the utility
needed in describing the kinds of knowledge required for the purposes of Context Interchange.
This will be clear by the end of the thesis.
In Bunge's Ontology, the world is made up of substantial individuals or things. Things
possess properties. We perceive the properties of things via attributes or predicates [11:p59]. That
is, we only know properties as attributes. A property is a feature that a thing possesses even if
we are ignorant of this fact. On the other hand, an attribute is a feature we assign to a thing [11:
p. 58]. Therefore there is a distinction between an attribute and a property of a thing. Bunge then
states that as a result, we distinguish the statement
"Substantial individual b possesses property P"
from
"Attribute A holds for b"
where A is taken to represent P. The reason why Bunge is concerned about such a distinction is
"because some attributes represent no substantial properties.. .and some properties are
represented by no attributes...". In the case where we assume that there is a one-to-one
correspondence between properties and attributes, we may use them interchangeably.
An attribute, (e.g. weight) represents a property in general while an attribute value (e.g. 36
kilograms) represents a property in particular [11:pp.62-65]. A class is a set of things that possess a
common property in particular. A mutual property [11: p66] is a property of two or more things.
For example, Source 3 contains propositions about stocks and exchanges. A stock and an
exchange interact in that the former is traded on the latter. Furthermore, a stock may be traded on
more than one exchange. Moreover, the closing price of the stock depends on the exchange on
which it is traded. Thus, the closing price is construed as a mutual property between a stock and
an exchange. Since the closing price of a stock can vary depending on which exchange it is
trading on, identifying closing price as a mutual property is important for semantic
interoperability.
There are simple and complex things. A complex thing is made up of simpler things that
interact. Systems are examples of complex things. There is a part-whole relationship between a
system and its components. An example of a system is the computer which is made up of
simpler, interacting things such as the CPU, memory etc. (Fig. 3.1). This is called an aggregation
hierarchy. Systems have inherited and emergent properties, and hence, inherited and emergent
attributes. An inherited attribute is an attribute common to a system and one of its components
and share the same attribute value. For example, the clock speed of computer is an inherited
attribute because it is also the clock speed of the computer's CPU. An emergent attribute is an
attribute of a system but not of any of its components (e.g. the processing power of the
computer).
Computer
Keyboard Z j \ VDUMemory CPU Storage
Fig. 3.1 Aggregation Hierarchy
The state of a thing is represented by a combination of its attribute values. These ideas
are formalized by means of afunctional schema [11:p119]. A thing X of class T (e.g. Employee) is
construed via a functional schema defined as Xm = <M, F>, where F = <F1, F2,...Fn>. Each state
function Fi, defined over the set M called the manifold, corresponds to an attribute; and each value
of Fi corresponds to an attribute value [11:p125]. More precisely, Fi: M-+V where V is a set of
values. For example, F1 and F2 may correspond to the attributes T i t 1 e and Salary
respectively. The manifold M can, for example, be a set of time points e.g. dates. Obviously, over
time, the state of X can change i.e. the employee's title and salary can change.
To better understand the notion of a manifold, we first discuss the notion of a reference
frame [11:pp264-2 6 7 ]. First, a reference frame is a thing. Second, for a thing to qualify as a
reference frame for another thing, the two must not influence each other i.e. they must not
interact. Third, for a thing to qualify as a reference frame for another, its states must be utilizable
for parameterizing the states of the latter. For example, a clock can serve as a reference frame in
which each clock state is a particular combination of hour, minute, seconds and am/pm
indicators. We might then associate a stock price on any particular day with each state of this
clock. In other words, we can associate time as indicated by the clock with particular states of a
stock as indicated by its stock price. Thus, a manifold is really a set of states of the reference
frame.
Things, as defined in Bunge's Ontology, are governed by state laws which restrict the
combination of attribute values for a class of things. In other words, state laws interrelate the
attributes of things [11:p78]. Thus for example, the title of an employee will determine the range
of salary values that is legal. Finally, Bunge states that "The choice of state functions is not
uniquely determined by empirical data but depends partly on our available knowledge, as well
as upon our abilities, goals and even inclinations" [11: p127].
We note two important points in Bunge's statement. First, our view of the world (i.e. our
functional schemas) depend upon "available knowledge". This means that as more knowledge is
acquired, our functional schemas can change accordingly. Second, our view of the world is also
influenced by our "abilities, goals and even inclinations". Thus, there could be pragmatic reasons
why one party chooses to view the world in one manner, while another chooses a different
perspective.
This also implies that there is no absolute "right" standard in determining suitable state
functions for the conceptualization of a thing. Bunge's Ontology is an extremely basic theory and
does not dictate the choice of state functions, what things exist or what the state laws are. By
choosing a particular set of things to focus on, a corresponding set of state functions, a set of state
laws, we commit ourselves to a more specific point of view of the world i.e. a more specific
ontology. A set of ontological commitments is "in effect, a strong pair of glasses that determine
what we can see, bringing some part of the world into sharp focus at the expense of blurring
other parts" [23:p19].
The problem of context heterogeneity arises when sources and receivers attempt to share
information but adopt different local ontologies. In database terms, sources and receivers use
different relational schemas (which correspond to Bunge's functional schemas), use different
integrity constraints (i.e. state laws) and focus on different things. However, if sources and
receivers agree on a shared ontology which consists of a set of shared functional schemas and a set
of shared state laws that interrelate these functional schemas, information exchange is possible
without requiring sources and receivers to change their functional schemas or view of the world.
The set of state laws, in the shared ontology, which relate shared functional schemas will be used
as conversion rules or axioms. Moreover, rules are required to relate local functional schemas to the
shared set of functional schemas in the shared ontology. This is done by means of context
definition rules. We discuss this in more detail later in the chapter.
State functions, and therefore functional schemas, can alternatively be represented by
means of predicates [11:p116-11 7]. Thus for example the title of an employee a can be cast as
Title (a, Sales Rep, 12 /12 /94) where Sales Rep is an attribute value and 12 /12 /94
is a point in the manifold. Bunge further proposed that arguments of predicates can be classified
according to the following types (1) object, (2) property, (3) space, (4) time, (5) unit and (6) scale [9: p.
40]. Thus for example, Salary (a, 50, 1000, usd, 1994) means that an employee a (an
object argument) has a salary of 50 (a property argument) thousand (a scale argument) usd (a
unit argument) in 1994 (a time argument). Note that in this case, the property, scale and unit
arguments are combined to define the value of the employee's salary (i.e. 50,000 usd). The
proposition Title(a, Sales Rep, 12/12/94) is an elementary fact. So too is the
proposition Salary(a, 50, 1000, usd, 1994) . As we plan to use logic to define the
BULLION model, we shall view functional schemas and state functions in terms of predicates.
One useful characteristic of space-time variables not discussed by Bunge but which will
prove useful is the concept of granularity. Consider for example the day 4 July 1987. This date
refers to a 24-hour period within the month of July 1987 which is within the year 1987. This is an
example of a granularity hierarchy of time (Fig. 3a). The smallest granularity of time is an instant.
No time periods can therefore appear below an instant in a granularity hierarchy of time.
Similarly, Chicago is in the USA is an example of a granularity hierarchy of space (Fig. 3b). The
smallest granularity of space is a point. No space values can appear below a point in a granularity
hierarchy of space. The concept granularity hierarchies of space and time will prove useful for
the purpose of defining conversion knowledge as we shall see in the next section.
Finally, Bunge defines an event as a change in the state of a thing and is represented as an
ordered pair of states. For example, a promotion is an event where the title of an employee
changes.
USA1987
Jul 1987 New York Chicago
(a) (b)
Fig 3.2 Granularity Hierarchy of (a) Time and (b) Space
3.3 Defining the Shared Ontology
Semantic interoperability means that sources and receivers can exchange information in a
meaningful manner. Information is made up of propositions about a world of interest.
Propositions describe things, attributes and states etc. More specifically, our knowledge about
the world can be described in terms of the truth values we attach to such propositions.
The shared ontology represents the basis for the exchange of information among sources
and receivers within a Context Interchange system. It defines a common set of propositions in
which all relevant arguments are made explicit. Propositions within the ontology can be
converted to one another by means of deduction. Tuples in sources are mapped to propositions
of the shared ontology by means of context definition rules. Context definition rules for receivers
map propositions in the shared ontology to tuples in the receiver's view.
The process of transforming tuples in sources to tuples in a receiver's view, in a Context
Interchange system, can be briefly and intuitively described in the following manner. Tuples in
sources are first transformed, by means of context definition rules, to corresponding propositions
in the shared ontology. These propositions are then mapped to tuples in the receiver's view, also
by means of context definition rules. This might not always be possible because not all
propositions in the shared ontology can be mapped to tuples in a receiver's view. In this case,
these propositions must be converted, using deductive laws, to other propositions in the shared
ontology that might map to the tuples in the receiver's view. The details of this process will be
explained over the course of the remaining chapters of this thesis. In the remainder of this
chapter, we discuss the specification of a shared ontology, context definition rules and integrity
constraints.
A key task in the construction of Context Interchange systems is the definition of such a
shared ontology. In practice, we envision this task to be a collaborative process, involving
different parties interested in exchanging information about a common domain of interest. An
important point to understand about the specification of a shared ontology is that it need not, and
probably will not, be a "once and for all" process. This is because the definition of a shared
ontology also depends on "available knowledge". We cannot anticipate in advance all future
needs.
Furthermore, the definition of a shared ontology depends on our "abilities, goals and
even inclinations". So even if we did have all available knowledge about future needs, we may
not necessarily want to incorporate all the desired features into the ontology immediately for
pragmatic reasons. For example, even if we knew that we need to incorporate the new European
currency (i.e. ECU) and the respective conversions some time in the future, we may not want to
do so now since it will not be useful until then.
For these reasons, specifying the shared ontology will probably be an ongoing process in
which new knowledge is incrementally added "as needed". For example, new predicates can be
introduced into the shared ontology over time. In Context Interchange, the ability to anticipate
the needs of the federation is not as critical as the ability to adapt to future needs in a graceful
manner.
3.3.1 Defining Predicates and Arguments
The first step in defining the shared ontology is the definition of the global set of
elementary propositions for a universe of discourse. Sources and receivers must agree on this set
of definitions for the purpose of exchanging information. Defining the these propositions
essentially boils down to agreeing on attributes or predicates of things and the appropriate
argument list. As discussed above, predicate arguments can be of type (1) object, (2) property, (3)
space, (4) time, (5) unit and (6) scale.
Let us consider, as an example, the definition of the closing-price predicate in the
shared ontology so that we can make available, to the federation, information such as that
contained in Source 3. Sources and receivers must agree on the meaning (i.e. intension) of this
predicate or attribute.
Furthermore, when sources and receivers communicate, they must be communicating
about some population of things or objects. Therefore, there must also be agreement on the
things to which this attribute applies. In this case, the closingprice attribute applies to a
class of things called stocks. Without a clear agreement on the particular things that form the
subject of a communication, meaningful information exchange can be hindered.
Then, there is the attribute value of the closing price of the stock itself. Bunge's
framework suggests that this might be viewed in terms of a real number (i.e. a property value), a
currency (i.e. a unit) and a scale value. Sources and receivers must consider these argument types
as part of the definition of the clos ingprice attribute. If, for example, the currency argument
is not defined as an argument of the predicate, ambiguity can arise when more than one currency
value is possible. On the other hand, if the entire federation of sources and receivers agree on a
single currency for closing prices, then there is no necessity to explicitly include the currency
argument. For our example, let us assume that various currencies are possible and therefore we
require the currency argument to be an explicit part of the definition of c los ing-price. Let us
also assume that for the entire federation, the scale value of all closing prices is one. Therefore,
there is no need to explicitly include the scale argument. For purely pragmatic reasons, we may
therefore leave the scale argument implicit, saving us the trouble and effort of specifying
additional arguments.
Some time in the future however, we may encounter sources and receivers with different
scale assumptions. In this case, a scalable and flexible system should be able to easily
accommodate such sources and receivers. Towards the end of the thesis, we will show how two
federations with differing and implicit scale assumptions can be easily integrated. For now,
therefore, Stock, Price and Currency form part of the argument list of closingprice.
Based on the framework described in Section 3.2, there is yet another argument to
consider, Date, which is time argument. This is because closing prices of stocks vary with time.
If various dates are involved, we need to explicitly include the Date as part of the definition of
the closing price.
Finally, we note also that the same stock can be traded on different exchanges. For
example, IBM's stock is traded on the New York Stock Exchange as well as on the Tokyo Stock
Exchange. Depending on which exchange we are talking about, the closing price of IBM's stock
can differ. In Bunge's framework, the closing price attribute actually represents a mutual
property of two things, the stock and the exchange on which it is traded. Thus, we add an
argument Exchange to the closingprice predicate.
Note that this proposition is an elementary in that it represents a minimal unit of
information with respect to the domain of interest. An elementary proposition needs to be
unambiguously defined with respect to the sources and receivers within a federation. This is
done by specifying the appropriate argument list of the predicates. So, we have just seen how
Bunge's framework aided us in identifying and defining fundamental agreements necessary for
the meaningful exchange of information by means of propositions.
3.3.2 Defining the Deductive Relationships among Propositions
Agreeing on the global set of propositions, however, is not enough. This is because there
are constraints on what propositions a receiver is willing to accept and what propositions a
source can represent. For example, while a particular source might have information
representing some properties of a thing, the receiver might be interested in other properties of the
same thing. Hence, where sources and receivers with multiple contexts are involved, the
propositions represented by sources may not always be acceptable "as is" by receivers. Sources
and receivers must, as a result, also agree to some means of converting propositions. Since state
laws interrelate the attributes of things, they are the only mechanism for conversion.
In BULLION, these state laws are called conversion rules or axioms. We shall also see
later on that these conversion axioms can also facilitate the definition of contexts. There are a
number of conversions that are highlighted in the literature including unit conversions and scale
conversions. We will now present examples of conversion axioms that may be specified within
this framework. The following examples, by no means comprehensive, serve to illustrate the
range of conversion possibilities that can be expressed within this framework, and which go well
beyond what has been described in current database integration literature. For clarity, the
predicate names and arguments which are being converted are highlighted in bold. Arguments
with upper case first letters are variables, otherwise, they are constants. Furthermore, all
variables are assumed to be universally quantified. Each argument is followed by a slash (/) and
its corresponding type (in italics) as described within Bunge's framework.
(1) Conversion Axioms based on Generalization:
E.g. If trade-price is more general than nominaltradeprice,
nominaltrade-price (CompanyName/object, Price/ property,
Scale/scale, Currency/uni t, Time/ t i me ) = tradeprice
(CompanyName/object, Price/property, Scale/scale, Currency/unit,
Time/time).
(2) Conversion Axioms based on Unit conversions:
E.g. If 1 US dollar is 100 Yen,
revenue (CompanyName/ object, Rev/property, Scale! scale, usd/unit,
Yr / time) * revenue (CompanyName/ object, Rev*100/property,
Scale/scale, yen/unit, Yr/time).
Explanation: Observe that the unit conversion rules require that the predicate, object,
scale and time remain unchanged for this conversion to be valid.
(3) Conversion Axiom based on Scale conversions:
E.g. For differing scales,
revenue (CompanyName/object, Rev/property, Scalel/scale,
Currency/unit, Yr/time) t revenue (CompanyName/object,
Rev*Scalel/Scale2/property, Scale2/scale, Currency/unit, Yr/time).
Explanation: Observe that scale conversion rules require that the predicate, object, unit
and time remain unchanged for this conversion to be valid.
(4) Conversion Axioms based on an Aggregation Hierarchy:
E.g. For an aggregation such as that described in Fig. 3.1,
speed (computer/object, Speed/property, Scale/scale,
SpeedUnit/unit) (-* speed (cpu/object, Speed/property, Scale/scale,
SpeedUnit/unit).
Explanation: The cpu is a part of the computer in this aggregation hierarchy. In this
example, the speed of a computer is an inherited attribute from the cpu.
(5) Conversion Axioms going down the Time hierarchy:
E.g. For a time hierarchy such as that described in Fig. 3.2(a),
title (Employee/object, Title/property, 1987/time) -> title
(Employee/object, Title/property, jun 1987/time)
Explanation: "Employee possessed Title for all of 1987" means that "Employee
possessed Title for all of jun 1987".
(6) Conversion Axioms for going up the Time hierarchy:
E.g. For a time hierarchy such as that described in Fig. 3.2(a),
birth (Person/object, 4 jul
(Person/object, jul 1958/time,
1958/time, Place/space) -> birth
Place/space).
Explanation: Person was born at some instant within the day 4 Jul 1958, it is also true
that Person was born at some instant within the month Jul 1958.
(7) Conversion Axioms for going up the Space Hierarchy:
E.g. For a space hierarchy such as that described in Fig. 3.2(a),
birth (Person /object, Date/time, chicago/space) => birth
/object, Date/time, usa/space).
(Person
Explanation: Since Person was born at some point within Chicago, Person was
therefore born at some point in the USA.
(8) Conversion Axioms among different Quantitative Amounts
E.g. Those involving addition and subtraction,
revenue (CompanyName / o b j
Currency/unit, Yr/time)
Exp/property, Scale/scale,
(CompanyName/object,
Currency/unit, Yr/time).
ect, Rev/property, Scale/scale,
A expense (CompanyName/object,
Currency/unit, Yr/time) => profit
Rev-Exp/property, Scale/scale,
Observe that the last conversion rule not only expresses the arithmetic relationship among the
predicates revenue, expense and prof it, but also states that this relationship holds only if
these predicates refer to the same company and have the same currency, time period and scale
value. This ability to state the conditions under which a conversion holds is critical for the
context mediator to perform the correct conversions and conversion axioms allow us to do this.
Having defined the shared ontology, we need to relate propositions associated with
sources and receivers to propositions in the shared ontology. These is done by means of context
definition rules.
3.4 Context Definition Rules and Integrity Constraints
In contrast to the definition of a shared ontology, we envision the specification of context
definition rules to be a more localized process. That is, such a task will probably be performed by
the local database administrator. This task is analogous to the process of concept matching in
Carnot [21]. To understand, in principle, how a local database administrator would perform such
a task, let us consider defining the context of Source 3 as an example.
The local database administrator must first determine the predicates in the shared
ontology which accurately describes the information in Source 3. If such predicates do not exist,
they must then be introduced into the shared ontology. In this case, the appropriate predicate is
closing-price, which was described in Section 3.3. Recall that closing-price has five
arguments: Stock, Price, Exchange, Currency and Date. Remember also that the scale value
is implicitly assumed to be one.
We can now describe the context of Source 3 in Bunge's terms (i.e. (S,P,D)) using the
closing-price predicate of the shared ontology. The closing-price predicate belongs in P.
All the possible values of the arguments of closing_price are in D (i.e. D ={stkl,
stk2,...,nyse..., ti, 0. 00 ... 55. 0 0. . . , us d, yen}). Recall that all closing prices of stocks in
Source 3 are for the time t1. Furthermore, stocks traded on nyse must have currency in usd.
The proposition closingprice (stkl, 55. 0 0, nyse, usd, t1) is an example of a
proposition that satisfies all these restrictions. We say that this proposition is allowed within this
context. S represents the set of allowable propositions that can be expressed by a source, in this
case Source 3. Hence, the propositions represented as closing-price (Stock, Price,
nyse, usd, ti) , where the variable arguments Stock and Price range over the appropriate
values in D, are allowed in this context. The variable argument Stock, for example, ranges over
the values stkl, stk2 and so on.
The schema of Source 3 is s3_closingprice (Stock, Price, Exchange). The
local database administrator now determines that the three arguments in the local schema
correspond to the first three arguments in the closingprice predicate. However, two
remaining arguments of the closing-price predicate need to be instantiated i.e. Currency and
Date. In fact, these arguments have been implicit in Source 3 all along. The closing-price
predicate alerts the local database administrator to implicit assumptions that have to be made
explicit for meaningful information exchange. The context of the source can, therefore, be
conveniently defined by the local database administrator in terms of the following context
definition rule:
s3_closingprice (Stock, Price, nyse) -> closing-price (Stock,
Price, nyse, usd, t1).
A context definition rule maps tuples in sources to propositions in the shared ontology.
Similarly, the restriction that the closing prices for all stocks traded on tokyo is in yen can be
represented by another context definition rule
s3_closingprice (Stock, Price, tokyo) => closingprice (Stock,
Price, tokyo, yen, t1).
Note that since conversion of propositions takes place from the left hand side of the above rules
to the right hand side, the source proposition is on the left, while the corresponding proposition
of the shared ontology is on the right.
We have also indicated that traditional integrity constraints (e.g. domain constraints) are
subsumed by the notion of a context. Integrity constraints can be easily specified as part of a
context definition rule. For example, the above context definition rule can be modified as follows
(modification in bold)
s3_closingprice(Stock, Price, nyse) Y ((Stock=stk1) v
(Stock=stk2)) = closingprice(Stock, Price, nyse, usd, t1).
This rule restricts the domain of Stock to stk1 and stk2 for stocks traded on nyse. Now
suppose a tuple that violates this domain constraint is introduced into Source 3. This tuple
wrongly states that stk3 was traded on nyse (instead of tokyo). The above conversion rule,
however, will not fire and no conversion will take place. Thus specifying constraints can prevent
erroneous deductions.
If however, the constraints in Source 3 are satisfied, then the rule becomes
s3_closing-price(Stock, Price, nyse) Y t r u e ->
closing-price(Stock, Price, nyse, usd, t1).
which then reverts back to the original rule. Thus, if the constraints of sources are always
satisfied, specifying integrity constraints as part of a context definition rule makes no difference
from the point of view of logic. We might not, therefore, bother to specify the integrity
constraints of sources in context definition rules. From the efficiency point of view however,
specifying constraints is valuable because it facilitates semantic query optimization. We will
return to this topic later in the thesis.
Now consider Receiver 2 with schema r2_closing-price (Stock, Price
Exchange). Furthermore, Receiver 2 expects all closing prices to be in usd and for the time
period t 1. The context definition rule for the receiver is
closing-price(Stock, Price, Exchange, usd, ti) ->
r2_closing-price(Stock, Price, Exchange).
Since we are converting global propositions to receiver propositions, global propositions appear
of the left hand side of the rule while the receiver propositions are on the right.
Recall that Receiver 2 expects information only on stocks traded on nyse and tokyo. If
this assumption is violated, the receiver might compute erroneous statistics. For example, the
receiver might be using this information to calculate the total value of stocks on the two
exchanges. If stocks traded on other exchanges entered into the computation, the result will be
incorrect. In order to ensure that this expectation is satisfied, the above context definition rule
can be modified as follows (modification in bold)
closingprice(Stock, Price, Exchange, usd, t1) Y((Exchange=nyse)
v (Exchange=tokyo)) = r2_closing-price(Stock, Price, Exchange) .
Now, only information on closing prices of stocks traded on nyse and tokyo can be converted to
receiver propositions.
3.5 Simplifying the task of Domain Definition
We note that these domain restrictions have been defined by enumeration. That is, we
explicitly stated which elements were allowed in a particular domain. Enumeration can
cumbersome if this list of elements is very long! However, if a domain is stable, we need only
specify it once as part of a context definition. Since the context definition is specified outside the
confines of a query, a receiver need not restate domain restrictions each time a query is issued,
saving the receiver a lot of effort.
Furthermore, if a particular domain is considered "standard" knowledge throughout the
federation, it can be defined in one place and sources and receivers can re-use this definition. For
example, if stk1 and stk3 are stocks of computer companies, we can assert this as
computer-stock (stkl).
computer-stock (stk3).
By making these facts globally available to the federation (say by placing them in the shared
ontology), these definitions can be re-used to specify domains more conveniently. For example, if
Receiver 2 changes its context definition and accepts only closing prices of stocks of computer
companies, the new context definition becomes
closingprice(Stock, Price, Exchange, usd, t1) Y
computerstock(Stock) = r2_closing-price (Stock, Price, Exchange).
Note that no enumeration of individual stocks is required in this case.
In sum, we have described the process of context definition. Furthermore, the ability to
specify constraints as part of context definition rules ensures a higher integrity of the answers.
For sources, specifying constraints facilitates semantic query optimization. By making general
knowledge available to the federation through the shared ontology, the task of defining
constraints can be further simplified. Defining constraints outside the confines of a query also
makes life easier for a receiver.
In the next chapter, we integrate the notion of a shared ontology and context definition
rules into a proof theoretic specification of a Context Interchange system. More specifically, we
formalize these ideas in terms of a deductive database framework [29]. In such a framework, one
or more relations share a set of deductive laws. From the point of view of the BULLION model,
these laws take on special significance in that they are the laws from the shared ontology and the
context definition rules.
4 BULLION: A Proof Theoretic Specification ofContext Interchange
To date, there has been a proliferation of proposals for approaches (e.g. [3, 4, 21, 25, 36,
46, 64, 67]) to semantic interoperability. These proposals emphasize a focus on implementation.
The range of such dissimilar implementations is broad, emphasizing various aspects of the
problem of semantic interoperability. To complicate matters, the range of representation schemes
within each system is potentially broad too. This is because interoperable systems can contain
sources, receivers and global media (e.g. global schemas [4] and ontologies[21]) based on
different data models and representation schemes. Important assumptions made by these varied
representation schemes can affect meaningful data retrieval, and are often buried within the
structure and procedures of these representations. The problem is that we currently lack a means
with which to understand, analyze and compare these approaches. More specifically, we lack
abstract, formal descriptions of the cognitive task of semantic interoperation, independent of
idiosyncratic implementation details.
Therefore, an abstract specification of a model of semantic interoperability, based on the
Context Interchange Architecture, is presented in this chapter. This model, which incorporates
the various insights of the previous chapter, is referred to as the BULLION model. BULLION is a
model of what Context Interchange systems should do and represents a theoretical ideal.
BULLION should not be confused with an implementation which may fall short of the theoretical
ideal because of practical limitations. For example, a specification defines the set of all answers to
be returned in response to a query. However, for efficiency reasons, a particular implementation
may choose to sacrifice the completeness of the answers returned. BULLION is a model at the
knowledge level.
4.1 The Knowledge Level: Background and Motivation
The knowledge level is a concept first introduced by Newell [61]. Newell distinguishes the
knowledge level from the symbol level. The knowledge level is concerned with what knowledge is
being represented, not how. How knowledge is to be represented is a symbol level issue. A
(knowledge) representation is a structure at the symbol level. Knowledge serves as a specification
for what a symbol structure should do. The knowledge level is useful because it permits predicting
and understanding system behavior without an operational model of the processing that is
actually being done by the system. According to Newell, logic is a structure at the symbol level
uniquely fitted to the analysis of knowledge and representation. In the area of knowledge
representation, for example, Levesque used logic to provide a knowledge level analysis of a
fundamental trade-off in various knowledge representation schemes such as databases, semantic
nets, production systems and frames [51].
In his landmark paper where he proposed a proof theoretic view of relational databases
[62], Reiter also argued for the need for specification in the context of conceptual modeling of
databases. A chief factor which motivated his argument was the proliferation of proposals for
data models "served up without benefit of an abstract specification of the assumptions made by
that data model about the world being modeled". Without a precise specification, the semantics
of database operations may be unclear and there is no basis to prove the correctness of database
operations. He argued that first order logic, specifically proof theory, is ideal as a specification
language because it has precise and unambiguous semantics. It therefore provides a rigorous
specification of meaning. Moreover, it does so at a very high level of abstraction, in the sense that
the specification is entirely nonprocedural. It tells us what knowledge is being represented. A
logical data model is transparent in that all and only the knowledge being represented is open for
inspection, including assumptions that might otherwise be buried in data model operations (e.g.
the domain closure axiom and the completion axioms are embedded in the division and set difference
operator respectively of the relational model). First order proof theory also provides a conceptual
advantage in that it possesses representational and operational uniformity. Proof theory has
representational uniformity in that queries, integrity constraints and facts are represented by the
same first order language. Proof theory has operational uniformity in that first order proof
theory is the sole mechanism for query evaluation and the satisfaction of integrity constraints.
Proof theory provides a specification which can be realized by a variety of procedurally oriented
data models. Conversely, nonlogical data models can be given precise semantics by translating
them into logical terms. Furthermore, because of the uniformity of logic, different data models
can be compared and non proof theoretic query evaluation algorithms may be proven correct
with respect to the logical semantics of queries. The generality of proof theory as a specification
language is based on the observation that the sort of real world semantics data models attempt to
capture are first order definable. That is, various kinds of databases (e.g. those that contain
incomplete information and incorporate more real world semantics) can be characterized as
special types of first order theories.
One of Reiter's chief criticism of the proliferation of data models concerns the definition
of an answer to a query. "Insofar as the concept of an answer to a query is defined at all, it is
defined operationally, for example by a generalization of the relational algebra, or by some set of
retrieval routines which may or may not perform inferences. Now these data models are
complicated. Therefore these operational definitions for answers to queries are also complicated.
Why should one believe that these definitions are correct...(and) complete?" [62: p221]. Reiter's
main point is that "no matter how one extends data models...the definition of an answer to a query
remains the same...". Therefore, given an abstract definition of an answer, say in proof theoretic
terms, "we can prove the correctness of proposed query evaluation algorithms". However, this does not
mean that a query evaluation algorithm must resemble proof procedures. In fact, the relational
algebra is one such algorithm that has been proven complete and correct and yet it "looks nothing
like proof theory".
Levesque [50], referring to the proof theoretic view of relational databases, states that:
"The point of this translation exercise is not that we can sometimes reduce first order logic to
relational databases, but rather that we can explain the information content of simple databases
as a certain restricted type of first order theory in such a way that answers are to queries are
implicit in the theory (i.e. logical consequences of it). This is not to suggest that we might want to
answer a query by doing theorem proving of some sort; that would be like cracking an egg with a
hammer. Rather, it is precisely because first order theory is restricted in a certain way (namely,
that it is in what I have called "DB form") that something like resolution is not necessary, and
simple database retrieval is sufficient for sound and complete logical inference. What the first
order account gives us is what the answers to queries should be, not how to compute them (at least
in this case). In other words, we are interested in using first order logic at the knowledge level,
not at the symbol level. ...What counts here is using a sufficiently general knowledge
representation language. ...What we get from first order logic (and the only thing that concerns
us here) is a reasonably general and precise language of sentences and a clear way of understanding
the propositions expressed by complex sentences..."
The need for specification and the value of logic as a specification language clearly apply
to the goal of achieving semantic interoperability. The current proliferation of database
integration implementations, not unlike the "embarrassing" proliferation of data models observed
by Reiter, suffer from a lack of a rigorous specification. Unfortunately, a specification is often
equated or confused with the operational model of the computation itself. A specification is
especially needed and particularly difficult to achieve in complex and heterogeneous
environments where sources, receivers and global media are based on different representation
schemes. Knowledge within disparate sources are embodied not only by the data model
structure but also by data model operations. Meaningful integration of the knowledge of
disparate sources requires first an understanding of the knowledge contained within these
sources. Brachman and Levesque [7] observed that "A knowledge level analysis is especially
important when considering combining representation schemes. Indeed one can imagine
wanting to combine schemes with wildly different and incomparable implementation structures
on the one hand and organizational facilities on the other. In this case, the only common ground
between the schemes might be that they represent related kinds of knowledge about the world.
This might be true even for the integration of two databases, arguably the simplest kinds of
knowledge bases". Proof theory provides a general, uniform, explicit and precise means of
specifying varied elements of interoperable systems. Specifying interoperable systems in proof
theoretic terms will greatly aid understanding, evaluation, comparison and subsequent design of
such systems.
4.2 Features and Benefits of the Specification
Our specification of the BULLION model is cast in proof theoretic terms. More
specifically, we formalize BULLION within the theoretical framework of deductive databases [28,
29, 55, 62]. Within such a framework, one or more relations share a set of deductive laws. From
the point of view of BULLION, these deductive laws take on special significance. That is, these
laws are made up of the laws of the shared ontology (such as those described in Chapter 3), as
well as context definition rules. For each relation, there is an associated set of context definition
rules. Similarly, each receiver has its own set of context definition rules.
BULLION has a number of noteworthy features. First, it draws upon theories from
philosophy [9], Al [61] and Reiter's work on logic and databases [62]. The second feature is the
inclusion of the notion of a context as defined in [9]. This notion of a context incorporates
domains and traditional integrity constraints as an integral components. Third, our model allows
for heterogeneous contexts, in particular, different relations and receivers can have different
contexts. Fourth, our model incorporates the notion of a shared ontology thus clearly defining its
role in facilitating semantic interoperability. Fifth, our specification does not require the source
or receiver to sacrifice autonomy. Finally, this specification provides a formal definition of an
answer to a query in a Context Interchange system. As shown in Fig 1.7, this specification defines
the relationship between the output answer (6) and the inputs (1-5). As this specification is at the
knowledge level, it ignores issues at the symbol level. That is, this specification defines the
relationship between the knowledge embodied by the inputs and the knowledge embodied by the
output.
There are several key benefits of this work. The first is of course a specification which
serves to formalize and communicate the key ideas behind the Context Interchange Approach,
unencumbered by details, limitations, compromises and artifacts of idiosyncratic
implementations. Such a specification is valuable because it provides a rigorous basis and
reference for alternative implementations of Context Interchange systems by defining a
correctness criterion, as well as the semantics of such systems. In particular, it provides clear
definitions of what we mean by a context and an ontology and their roles in constructing answers
to a query.
Furthermore, because BULLION is couched in the formal framework of logic, we can
draw upon research developed by the logic and database community for the theoretical
understanding and analysis of BULLION systems. Gallaire et al claimed that "Logic, we believe,
provides a firm theoretical basis upon which one can pursue database theory in general." [29].
Finally, this work also contributes in two ways to database integration efforts in general.
First, we have provided an exemplar of how a logical specification for interoperable systems may
be achieved. Similar specifications may also be developed for other types of interoperable
systems. As a result, we have a rigorous means of understanding, comparing and evaluating
these systems. Second, as we have provided a precise and high level definition of certain key
elements, such as context and ontology. These concepts can subsequently be more easily
understood and adopted by other database integration approaches if desired and implemented
accordingly.
4.3 The Logical View of Databases: A Review
We now briefly review Reiter's reformulation [62] of a relational database in proof
theoretic terms. This reformulation is the foundation for the field of deductive databases. We
begin with a discussion of first order languages. Then, the model theoretic view of relational
databases, which is the view initially associated with the Relational data model, is presented.
Then, we present Reiter's reformulation of a relataional database in proof theoretic terms.
4.3.1 First Order Languages
Following Reiter [62], let F = (A, W) be a first order language, where A is an alphabet
containing constant symbols, predicate symbols, variable symbols, function symbols, punctuation
signs and logical constant symbols. For a relational database however, function symbols are not
permitted. W is a set of well-formed formulas (wffs) which obey the grammatical rules of first
order predicate calculus. Wffs are simply syntactically legal first-order logic sentences. A ground
formula is a wff that contains no variables.
There is a distinguished predicate symbol, =, in A which will function as the equality
predicate. There is also a distinguished subset in A, possibly empty, of predicate symbols that
stand for special unary predicates called simple types. For example, some constants such as s tkl
is of the type stock, i.e. stock (stk1 ).
Furthermore, if ti and t2 are types, then (T1 A T2), T1 v r2, and -, 1 I are also types. V x is a
universal quantifier and 3x is an existential quantifier. For a type restricted universal quantifier Vx/t
and a wff o, (Vx/t)(o) should be read as "For all x of type t, co is the case". For a type restricted
existential quantifier 3x/r, (3x/ t) (o) should be read as "There exists an x of type r such that o is
the case".
The interpretation I for the first order language F is (D, K, E). K is a one-one and onto
mapping from constant symbols of A into D. This is a logician's way of saying that the constant
symbols in A are assigned meanings, by the mapping K, from the domain D. Since K is a one-to-
one and onto mapping, each and every constant symbol has a unique meaning. E is a mapping
from the predicate symbols of A into sets of tuples of elements of D. That is, for an n-ary
predicate symbol p, E(p) c Dn is the extension of p in I.
4.3.2 Relational Databases: The Model Theoretic View
In the model theoretic view, a relational database DB is defined as (F, IC, I). The alphabet
A, of F, does not contain function symbols. IC c W is a set of integrity constraints. In particular,
it is required that for each n-ary predicate symbol p (distinct from = and type predicate symbols),
IC must contain a wff of the form
Vxi---.Vxn [p(x1- ---,xn) --> T1(x1) ^--^. An(xn)]-
Essentially, this wff defines the domains of the predicate p. The set of integrity constraints IC is
said to be satisfied if I is a model of IC, i.e. IC is true in I. Fig. 4.1 shows the corresponding model
theoretic view of Source 3.
Queries are defined with respect to a given language F. Specifically
Definition: A query Q for F = (AW) is any expression of the form <x 1/T 1,...,xn/Ta I W
(xl,...,xn)> where:
1. x1,..., xn are variables of A.
Alphabet A
Predicate symbols: s3_closing-price(,,), stock(), price(,
exchange().
Simple Types: stock(),price(),exchange().
Constant symbols:stkl,stk2,...,nyse,tokyo...
Integrity Constraints
(VxiVx2Vx 3Vx 4Vx 5 ) s3_closing-price
Aprice(x2) A exchange (x3);
Extension of type predicates
stock: stkl,...,stk4.
price: 40.00,55.00...
exchange: nyse,tokyo
Extension of s3 closing price
(stkl,
(stk2,
(stk3,
(stk4,
(xl,x2,x3) => stock(xi)
55.00, nyse),
40.00, nyse),
6330.00, tokyo),
6531.00, tokyo);
Fig. 4.1 Model Theoretic View of Source 3
2. Each ri is a type of A.
3. W (x1,...,xn) E W.
4. The only free variables are among x1,...,xn.
5. All quantifiers occurring in W (x1,...,xn) are type restricted.
For example, the query against Source 3
<Stock /stock s3_closing-price(Stock, Price,Exchange)
A(Exchange= nyse)>
is equivalent to the SQL query
select Stock
from s3_closing-price
where Exchange= "nyse".
Definition: A tuple of constants <c,..., cn> of F's alphabet is an answer to Q with respect
to DB= (F, IC, I) iff
1. ci(ci) is true in I for i=1,...,n.
2. W (c1 ,...,c) is true in I.
<stkl> and <stk2> are answers to the above query.
4.3.3 Relational Databases: The Proof Theoretic View
Unfortunately, the model theoretic view is limited in modeling databases such as those
that have incomplete information and those that incorporate more real world knowledge [62].
However, in the proof theoretic paradigm, which we are about to review, such databases can be
viewed as special kinds of first order theories. The prime advantage of the proof theoretic view,
over the model theoretic one, is therefore its capacity for generalization. The advantages of the
proof theoretic view are discussed in [55 p.147, 62]. For a relatively simpler and useful tutorial on
the model theoretic versus the proof theoretic view of databases, the reader may refer to [22:pp
641-682].
In the proof theoretic paradigm, there are two basic rules of inference: modus ponens and
generalization. In this paradigm, a relational database is defined as (F, IC, T) where F = (A,W) is a
first order language as defined above, IC is a set of integrity constraints and T c W is a first order
theory containing the following axioms:
1. Domain Closure Axiom (DCA):
Vx[=(x,c1) v... v =(x,c, )] where c 1,...,c , are all the constant symbols in A.
The domain closure axiom simply defines the set of all possible constant symbols that
may be used to instantiate a particular database. Equivalently, it defines the scope of
universal quantification. Thus, when we say "for all x", we are referring to all the
constant symbols in the domain closure.
2. Unique Name Axioms (UNA):
-, =(ci1c 2) A...A-,=(ic ).
These axioms state that different symbols have different meanings i.e. the constant
symbols in the alphabet A are pairwise distinct. This is consistent with the one-to-one
mapping K defined in the model theoretic view.
2. Equality Axioms (EA): Reflexivity, commutativity, transitivity and the principle of
substitution of equal terms.
These axioms give the equality predicate its usual meaning.
3. The set of all ground atomic axioms corresponding to the extensions of the predicates
(excluding =). Each tuple in an extension of a predicate corresponds to a ground fact
in proof theory.
4. Completion Axioms (CA) for each predicate symbol (excluding =): Suppose the
extension of an m-ary predicate p is {(c1(1)., cm( 1)),..., (c1(r),..., cm(r))}, then the
completion axiom for p is
Vx1,---, vxmlp(x1,---, xm) => [=(x1,c1(1) A ... A =(xmCm(1) v ...v [=(x1,c1(r)) A...A
=(xmcm(r)))
The set of completion axioms is a formalization of the closed world assumption. It allows us
to represent negative facts in a compact fashion. As a simple example, let p be a unary predicate
and the domain closure axiom be Vx[=(x,ai) v=(x,a 2 )v =(x,a 3 )]. Furthermore, let the positive
ground axioms of p be p (a 1 ) and p (a 2 ). The completion axiom for p is therefore Vx[p(x) =>
=(x,ai) v =(x,a 2 )]. Note that a3 is in the domain closure. By substituting a 3 for x in the
completion axiom (i.e. using the generalization inference rule), we get
p(a3 ) => =(a3 ,ai) v =(a3 ,a2 )
Then, by the contrapositive rule', we get
- p(a3 ) <=- =(a3 ,ai) A - =(a3 ,a 2 )
Then using modus ponens and the unique name axioms, we can prove -,p (a 3 ). Thus, since a3 is
in the domain closure but p(a3) is not asserted as true, we can show -,p (a 3 ).
The completion axiom for Source 3 is
VStock,VPrice,VExchange[s3_closingprice (Stock, Price, Exchange) ->
[=(Stock,stk1) A=(Price,55.00) A =(Exchange,nyse)] v
[=(Stock,stk2) A=(Price,40.00) A =(Exchange,nyse)] v
[=(Stock,stk3) A =(Price,6 33 0. 00) A =(Exchange,tokyo)] v
[=(Stock,stk4) A =(Price,6531. 00) A =(Exchange,tokyo)].
The set of integrity constraints IC is satisfied iff it is provable from T (i.e. T |-IC).
It is useful to note another advantage of the proof theoretic view over the model theoretic
view: it makes explicit the assumptions implicit in the model theoretic view (i.e. axioms in 1, 2,
and 4 above). Fig. 4.2 shows the corresponding proof theoretic view of Source 3.
The definition of a query for the proof theoretic view remains unchanged. The definition
of an answer to a query, however is modified and is given by:
Definition: A tuple of constants <ci,..., cn> of F's alphabet is an answer to query Q with
respect to DB = (F, IC, T) iff
1. TI-ti(ci) for i=1,...,n.
2. T|- W(ci,...,c a)
For the purpose of our specification, we will adopt the proof theoretic view of relational
databases.
4.4 A Logical View of a Context
We now present a formalization of Bunge's notion of a context, (S,P,D), in logical terms.
Let us first consider the context of Source 3. Let Cs3=(Ss3,Ps3,Ds3) be the context of Source 3
1 The contrapositive rule is a rule derived from modus ponens and generalization. It states that
we can infer -, B= -, A from A => B.
Alphabet A
Predicate symbols: s3_closingprice(,,), stock(), price(),
exchange (.
Simple Types: stock() ,price() ,exchange(.
Constant symbols:stkl,stk2, ... ,nyse,tokyo ...
Tntpaaritv Constraints
(VxiVx2Vx3Vx4Vx 5 ) s3_closing-price
A price (x2) A exchange (x3);
(xl,x2,x3) => stock(xi)
Domain Closure Axiom
Vx[= (x, stkl) v...v = (x, tokyo)]
Unique Name Axioms
-,=(stki,stk2) A...A-,=(nyse, tokyo)
Equality Axioms
Ground Axioms of type predicates
price(00.00),..., stock(stkl), stock(stk2), stock(stk3),
stock (stk4), exchange (nyse), exchange (tokyo);
Ground Axioms of s3 closing price
s3_closingprice (stkl,
s3_closingprice(stk2,
s3_closing-price(stk3,
s3_closing-price (stk4,
55.00, nyse),
40.00, nyse),
6330.00, tokyo),
6531.00, tokyo);
Completion Axioms
(As described in the text of Section 4.3.3.)
Fig. 4.2 Proof Theoretic View of Source 3
specified in terms a first order language Fs3. The symbols in Fs3 is a subset of the symbols used
in the language of the shared ontology called Fg. To formalize this, we introduce the following
Definition: Let F1 =(Ai, WI) and F2 = (A2, 'JV2) be two first order languages. Then F1
subsumes F2 iff A 2 c Al.
We therefore say that Fg subsumes Fs3.
The closingprice predicate as described in Chapter 3 is an element of Ps3. Recall
also that closing-price had five arguments i.e. Stock, Price, Exchange, Currency and Date.
These will be represented by the following type predicates respectively: stock, price,
exchange, currency and date respectively. These type predicates also belong in Ps3.
All the possible constants that can be represented in this context are in Ds3. This is
formalized by means of the domain closure axiom. Furthermore, there are no naming conflicts
among the constant symbols of Fs3. That is, different constant symbols stand for different
meanings and a constant symbol always has one meaning. This is formalized by the unique
name axioms and the equality axioms.
Moreover, each constant symbol is associated with a type predicate. Thus, stk1 is a
constant symbol of type stock. This is formalized by means of ground axioms of the type
predicates e.g. stock (stkl). The only constants that are of type stock are stkl, stk2, stk3
and s tk4. Other constants are not of type stock. This will be formalized by the completion
axioms for the stock predicate.
Ss3 is the set of propositions that are allowed within this context. The restrictions on S s3 is
formalized by means of a set of integrity constraints. For example, the restriction on the type of
arguments the closingprice predicate can take is represented as
(VxiVx2Vx3Vx 4Vx 5 ) closingprice (xl,x2,x3,x4,x5) => stock(xi ) A
price(x2) Aexchange(x3) Acurrency(x4) Adate(x5);
Recall also that the currency of the closing prices depended on the exchanges on which the stocks
are traded. This restriction is represented by the following two constraints.
(VxiVx2Vx 3 Vx4Vx5) closingprice (xl,x2,nyse,x4,x5) => =(x4,usd);
(VxiVx2Vx3Vx4Vx5) closing-price (xix 2 ,tokyo,x4,x5) => = (x4,yen);
The context of Source 3 defined in logical terms is shown in Fig. 4.3.
In general, a context is defined in logical terms by specifying a first order language F c,
and the following axioms in terms of this language:
1. Domain closure axiom (DCA).
2. Unique name axioms (UNA).
3. Equality axioms (EA).
4. Ground axioms of type predicates (TA).
5. Completion axioms of the type predicates (TCA).
6. A set of integrity constraints (IC).
Any fact asserted in terms of Fc within this context must be consistent with the above axioms.
For example, the fact closing-price (stkl, 55, nyse, yen, t1) violates one of the
constraints and is therefore not allowed in this context. This is because all closing prices of stocks
traded on nyse must be in usd.
Formally, a context can be defined in logical terms as follows
Definition: Let Fc be a first order language. A context C is defined as (Fc, Tc) where Tc =
DCAuUNAuEAuTAuTCA uIC.
Next, we define what we mean when we say that a proposition is allowed in a particular context.
Definition: Let C = (F c, Tc) be a context. Furthermore, let o be a wff of Fc. 0 is allowed
in the context C iff Tc u o is a consistent theory. Otherwise, w is not allowed in context C.
Context definition rules for a source must map tuples in the source to corresponding
propositions that are allowed in the source context. In specifying context definition rules, we
must ensure that the context we are concerned with should not be violated. Thus, the following
context definition rule for Source 3 from Chapter 3
Alphabet of Fs3
Predicate symbols: closingprice(,,,,), stock(),
price(),exchange(),currency(),date();
Simple Types: stock(), price() ,exchange() ,currency() ,date();
Constant symbols: stkl,..., stk4, nyse, tokyo,usd,yen,...;
Domain Closure Axiom
Unique Name Axioms
Equality Axioms
Ground Axioms of type predicates
price(OO.00),...,price(10000.00), date(tl), stock(stkl),
stock(stk2), stock(stk3), stock(stk4), currency(usd),
currency (yen), exchange (nyse), exchange (tokyo);
Completion Axioms of type Predicates
Integrity Constraints
(VxlVx2Vx3Vx4Vx5) closingprice (xl,x2,x3,x4,x5) -
stock(xl) Aprice(x2) Aexchange(x3) Acurrency(x4) A
date (x5);
(VxlVx2Vx3Vx4Vx5) closing-price (xi,x2,nyse,x4,x5) ->
=(x4,usd);
(VxlVx2Vx3Vx4Vx5) closing-price (xi,x2,tokyo,x4,x5) =
=(x4,yen);
Fig. 4.3 A Logical View of the Context of Source 3
VStockVPrice s3_closing-price(Stock, Price, nyse) =>
closingprice(Stock, Price, nyse, usd, t1).
will ensure that closing prices of stocks traded on nyse will be associated with the appropriate
currency i.e. usd.
The context for a receiver can be similarly defined. As an example, the logical
formulation of the context of Receiver 2 defined in terms of the language Fr2 is shown in Fig 4.5.
A receiver will only accept propositions that are allowed in its context. The proposition
closing-price (stk1, 55, nyse, yen, t1), for example, is not allowed in the context of the
receiver because the only currency in its context is usd. The following context definition rule for
Receiver 2 will ensure that only closing prices in usd will be converted to tuples in the receiver's
view.
VStock VPrice VExchange closing-price (Stock, Price, Exchange,
usd, t1) = r2_closingprice(Stock, Price, Exchange).
In sum, a context defines a set of allowable propositions in terms of the language of the
shared ontology. Context definition rules for a source should map tuples in a source only to
corresponding propositions allowed within its context. Context definition rules for a receiver
should only map propositions allowed within its context to a receiver's view.
4.5 Adding the Shared Ontology and Context Definition Rules
Reiter argued that the value of the proof theoretic view of a relational database is its
capacity for generalization. Reiter then showed how a such a view can be generalized to describe
databases with null values and disjunctive information. Furthermore, by adding deductive laws,
we get more general relational theories that can incorporate more real world knowledge such as
the representation of events, hierarchies and the inheritance of properties. Adding laws to a
relational database results in a deductive database. In BULLION, sources are relations. The laws
that are then added are those from the shared ontology and the context definition rules such as
those described in Chapter 3. For convenience, we will refer to such theories as BULLION
theories. We will now proceed to formalize this notion of a BULLION theory.
Alphabet of F]
Predicate symbols: closing-price(,,,,), stock(),
price(),exchange(),currency(),date();
Simple Types: stock(, price() ,exchange() ,currency() ,date(;
Constant symbols: stkl, ... , stk4, nyse, tokyo,usd,yen, ... ;
Domain Closure Axiom
Unique Name Axioms
Equality Axioms
Ground Axioms of type predicates
price(OO.00),.
stock(stk2),
exchange(nyse),
..,price(10000.00), date(tl), stock(stkl),
stock(stk3), stock(stk4), currency(usd),
exchange(tokyo);
Completion Axioms of type Predicates
Integrity Constraints
(VxlVx2Vx 3Vx4Vx5) closing-price (xl,x2,x3,x4,x5) ~
stock (xl) A price (x2) A exchange (x3) A currency(x4) A
date (x5) ;
Fig. 4.5 A Logical View of the Context of Receiver 2
We note that the language of the shared ontology is, in general, distinct from the
languages of sources and receivers. For example, Source 3 has a predicate s3_closing-price
that is not in the language of the shared ontology. Therefore, the language used to express a
BULLION theory must subsume the languages of the shared ontology, sources and receivers.
That is
Definition: Let Fg be the language of the shared ontology. Furthermore, let F ,...,Fn be
the languages used by various sources and receivers within the BULLION federation.
Then the language Fb of the BULLION federation subsumes Fg, F 1,... and Fn.
A BULLION theory Tb, specified in language Fb, will contain the following axioms:
1. Domain closure axiom (DCA).
2. Unique name axioms (UNA).
3. Equality axioms (EA).
4. Ground axioms of type predicates (TA).
5. Ground of axioms of non-type predicates (GA).
6. Axioms for the closed world assumption (CWA).
7. Context definition rules for sources and receivers (CD).
8. Laws from the shared ontology (SO).
More formally,
Definition: A BULLIONfederation is defined as (Fb,Tb) where Fb is the language of the
federation and Tb is a BULLION theory where Tb = DCA u UNA u EA u TA u GA u
CWA u CD u SO.
We now reexamine the significance of the various axioms in a BULLION theory. The
domain closure axiom now represents the set of all constant symbols within the BULLION
federation. This means that the scope of universal quantification applies to all constants within
the federation. These constant symbols include those in the language of the various sources and
receivers, as well as that of the shared ontology.
The unique name axioms state that all constant symbols that are not syntactically equal
are also not semantically equal. Furthermore, the equality axioms state that all constant symbols
are equal to themselves. In other words, there are no naming conflicts among constants in a
BULLION federation. This is an example of how proof theory makes explicit the assumptions of
the BULLION model. Obviously, naming conflicts will arise in practice. Such conflicts need to be
resolved before context mediation can be performed.
The completion axioms as defined previously are no longer appropriate as a
formalization of the closed world assumption when general rules are introduced to a relational
database. More general formalizations of the closed world assumption have been developed for
relational theories that contain deductive laws [29]. A detailed discussion of the formalization of
the closed world assumption, however, is not critical to the understanding of the BULLION model
and is therefore omitted.
The ground axioms of the BULLION theory include ground facts of the individual sources
as well as ground facts from the shared ontology. A BULLION theory can contain context
definition rules for multiple sources and receivers. Finally, a BULLION theory contains deductive
laws from the shared ontology.
Another observation we make is that BULLION is a consistent theory. Therefore, no
contradictory sentences are allowed. Furthermore, a statement that is asserted as true within a
source or the shared ontology is true throughout the BULLION federation. Dealing with multiple
inconsistent theories is beyond the scope of this thesis. However, any large scale federation of
sources and receivers must expect to deal with such an eventuality. The Logic of Contexts,
described in Chapter 2, is designed with such a problem in mind. LOC is an extension of first-
order logic. Since we have just defined the BULLION model in terms of first-order logic, its
relationship to LOC will not be difficult to understand. We will return to this matter in Chapter
7.
Recall the definition of a query Q in terms of Fb is defined as
Definition: A query Q for Fb = (AW) is any expression of the form <x1/ti,...,xn/Tn I W
(xl,...,xn)> where:
1. x1,..., xn are variables of A.
2. Each ti is a type of A.
The definition of an answer to a query issued against a BULLION theory Tb is now relatively
straightforward:
Definition: A tuple of constants <c 1,..., cn> of Fb's alphabet is an answer to query Q with
respect to Tb, a BULLION theory, iff
1. Tb I-Ti(ci) for i=1,...,n.
2. Tb I- W (c1,...,cn).
An answer to a query in a BULLION system, therefore, represents propositions that are provable
from multiple sources augmented by context definition rules and laws of the shared ontology.
These rules transform data in multiple sources to an answer that is consistent with the context of
the receiver.
4.6 Discussion
We have provided a formal specification of the Context Interchange Architecture from
the perspective of the knowledge level. Its nonprocedural and declarative nature provides a very
explicit specification of meaning, providing a formal semantics for what we are computing. It
tells us, for example, what knowledge is being represented in the ontology and in the contexts. It
also tells us what an answer should be, given the ontology and the contexts of source and receiver.
However, its nonprocedural character also means that our specification does not indicate how to
perform query operations in a Context Interchange Architecture. Of course various
implementations are possible, keeping in mind the usual trade-offs at the symbol level: namely
soundness, completeness, expressiveness, efficiency, degree of autonomy, functionality, etc.
However, such a description provides a rigorous basis for the understanding, analyzing and
implementing Context Interchange systems.
From the point of view of this specification, query processing is theorem proving. A
query defines the set of propositions to be proven from a first order theory made up of sources, a
shared ontology and the context definitions of sources and receivers. The propositions that are
provable make up the answer to a query. This specification can thus serve to verify various
implementations of Context Interchange systems. Therefore, in principle, if the sources, contexts
and shared ontology of a Context Interchange implementation are described in proof theoretic
terms, the answers that can be proven should be identical to that retrieved from the
implementation. This specification thus provides a basis for proving the correctness of an
implementation.
Also, from the point of view of this specification, multiple proofs might exist for an
answer to a query. This means that there is more than one possible way to perform a conversion
for a particular answer. Our specification allows us to express all possible proofs of an answer.
This raises some interesting theoretical and practical issues. For example, the efficiency of a
Context Interchange system might be increased by using only the most economical conversion
path available. On the other hand, the system might be highly inefficient if it were to prove the
same answer in all possible ways. This redundancy might however have a side benefit in that if
some conversion paths are "broken" due to missing deductive rules, the correct answer can still
be derived by means of an alternative proof. Also, a general theorem prover for our specification
can reveal certain conversion paths which are more viable but missed out by other more
specialized, "hand-crafted", query processing mechanisms. Our notion of an answer, therefore,
provides a framework in which to conceptualize and discuss such issues.
Furthermore, a proof can be used to explain an answer. That is, a proof can tell us which
original data sources were used, and how the original data was transformed to the final answer.
Thus, our specification, very naturally, provides a mechanism for explanation, which is one of the
key features of a Context Interchange system.
Therefore, our definition of an answer to a query is useful for various conceptual reasons.
However, a precise and formal model of what a Context Interchange should deliver is not
enough. How do we know if this model itself makes sense? Does this definition of a mediated
answer conform to our intuitive notion of what a mediated answer should be? In the following
chapter, we describe a prototype written in Prolog based on BULLION. This prototype is
intended as a proof of concept to demonstrate that this model makes sense. Further, it will serve
to concretely illustrate the ideas presented up until now.
5 The BULLION Prototype: Proof of Concept I
To make the ideas presented in the previous chapters more concrete, we now describe
these ideas in terms of a series of Prolog programs. Prolog, a logic programming language, was
chosen for a number of reasons. From the theoretical point of view, Prolog's theoretical
relationship to proof theory is relatively straightforward and well documented [55]. For example,
the unique name axioms are incorporated into Robinson's unification algorithm [63], which is the
heart of Prolog's inference engine. The domain closure of a Prolog program is the Herbrand
domain, which is simply the set of constants in the program. Furthermore, Prolog's relationship
to relational databases is also well understood and researched [17]. From a practical point of
view, Prolog readily facilitates the construction of a prototype system that can be demonstrated.
These Prolog programs will be used to illustrate as well as to verify the theory underlying the
BULLION model. For an introduction to Prolog, the reader can refer to the following texts [19,
70].
5.1 Context Interchange for Example A
5.1.1 Sources and Receivers
We first describe the Prolog prototype for a Context Interchange system for Example A.
The tuples in Source 1 and Source 2 will be modeled as Prolog statements, where the relation
name is the predicate name and the cell values of each tuple correspond to predicate arguments.
So Source 1 (Fig. 1.1) appears in a Prolog program as:
s1_head_office(cl, ny).
s1_headoffice(c4, ny).
Similarly, Source 2 (Fig. 1.2) appears as
s2_countryofincorporation(c5,usa).
s2_countryofincorporation(c6,japan).
As usual, arguments whose first letter is lowercase are constants, otherwise, the arguments are
variables.
The schema of Receiver 1 is
rlcountryof_incorporation (Company_name, Countryname).
Recall that Receiver 1 is interested only in companies c2 -c5.
5.1.2 The Shared Ontology and Context Definitions
We now consider the construction of the shared ontology and the respective context
definition rules. We first determine the appropriate predicates of the shared ontology. They are
headoffice(Companyname, City-name),
countryofincorporation(Companyname, Country-name) and
located_in (Cityname, Countryname). Now we incorporate the knowledge shown in
Fig. 1.3 into the shared ontology i.e.
country-of_incorporation (Company-name, Country-name) :-
head_office (Company-name, City-name),
locatedin (Cityname, Countryname).
locatedin(ny, usa).
locatedin(tokyo, japan).
locatedjin(london, uk).
locatedin(chicago, usa).
We also introduce the domain predicate which specifies the domain of a variable and is defined
in Prolog as
domain (X, [X|]).
domain(X,[_IY]) domain(X,Y).
The context definition of Source 1 is given by the following context definition rule
head_of fice(Companyname,City-name):-
domain(Company-name, [cl,c2,c3,c4]),
s1_head_office (Company_name,City-name).
Note that in this particular case, we did not choose to specify a restriction on the domain of
Ci ty-name for this source. Similarly, the context definition rule for Source 2 is
country_ofjincorporation (Company-name, City-name) :-
domain(Companyname, [c5,c6]),
s2_country-ofincorporation (Companyname, Cityname)
The context definition rule for Receiver 1 is
rl-country_of_incorporation (Companyname, Cityname) :-
country_of_incorporation (Companyname, City-name),
domain(Companyname, [c2,c3,c4,c5]).
Observe the simplicity of this context definition rule in that it need not contain the knowledge of
the relationship between headof f ice and country-of-incorporation. Knowledge of
this relationship is in the shared ontology and can be shared and reused, lowering the cost of
construction and maintenance. This rule also specified the domain of companies that Receiver 1
is willing to accept. The entire Prolog program is shown in Fig. 5.1.
5.1.3 Sample Queries and Answers
Thus, the SQL query
select Company-name
from r1_country-ofjincorporation
where Country-name= "usa"
is equivalent to the Prolog query
? rlcountry-of-incorporation(Company-name, usa).
The answer to this query is
Companyname = c4 ;
Companyname = c5 ;
which is the expected result. Observe that the receiver issues a query against its own schema "as
usual" and was not required to make the domain assumption of Company-name explicit within
the query. Furthermore, despite the different schemas of Source 1 and Receiver 1, knowledge in
the shared ontology was used to translate across heterogeneous schemas to deliver answers that
are meaningful to the receiver. The autonomy of the sources and receiver have also been
preserved. We now consider Example B where we deal with the problem of implicit arguments.
%Definition of the domain predicatedomain(X,[XI]).domain(X,[_IY]) :- domain(X,Y).
%Context Definition Rule for Receiver 1rlcountry-ofincorporation(Company-name,Cityname):-
country-of_incorporation(Company-name,Cityname),domain(Companyname, [c2,c3,c4,c5]).
%The Shared Ontologycountry-ofjincorporation(Company-name,Countryname):-
head-office(Company-name,City-name),locatedin(Cityname,Countryname).
locatedin(ny, usa).locatedin(tokyo, japan).locatedin(london, uk).locatedin(chicago, usa).
%Context Definition Rule for Source 1head_office (Companyname,Cityname):-
domain(Companyname, [cl,c2,c3,c4]),slheadoffice(Company-name,Cityname).
%Source 1 Dataslheadoffice(cl,ny).slheadoffice(c2,tokyo).slheadoffice(c3,london).slheadoffice(c4,chicago).
%Context Definition Rule for Source 2countryofjincorporation(Company-name,City-name):-
domain(Company-name, [c5,c6]),s2_country-ofjincorporation(Company-name,City-name).
%Source 2 Datas2_country-ofincorporation(c5,usa).s2_country-ofincorporation(c6,japan).
Fig. 5.1 Context Interchange System for Example A
5.2 Context Interchange for Example B
5.2.1 Sources and Receivers
For Example B, Source 3 is modeled as
s3_closingprice(stkl, 55,nyse).
s3_closingprice(stk2, 40,nyse).
s3_closingprice(stk3, 6330,tokyo).
s3_closing-price(stk4, 6531,tokyo).
The schema of Receiver 2 is
r2_closing-price(Stock, Price, Exchange).
5.2.2 The Shared Ontology and Context Definitions
We will use the predicate closing-price with arguments Stock, Price, Exchange,
Currency and Date based on the framework described in Chapter 3. Essentially,
closing-price is the attribute of Stock, a thing. Price and Currency represent the value of
the attribute closingprice. Date is a time argument which functions as the manifold. Recall
that the scale value of monetary amounts assumed by all sources and receivers is one. Thus, the
scale argument was not be specified.
The deductive laws needed for this example is the conversion of closing prices in yen to
usd. This is expressed as
closingprice(Stock,USprice,Exchange,usd,Date) :-
USprice = Yenprice/100,
closing-price (Stock, Yenprice, Exchange,yen, Date).
The context definition rules for Source 3 are
closingprice(Stock, Price,nyse,usd,tl):-
s3_closing-price(Stock, Price,nyse).
and
closing-price(Stock,Price,tokyo,yen,tl):-
s3_closingprice (Stock, Price, tokyo).
% Context Definition Rule for Receiver 2
r2_closing-price(Stock, Price, Exchange):-
closingprice(Stock, Price, Exchange,usd,t1).
% The Shared Ontology
closing-price(Stock,USprice,Exchange,usd,Date):-
closing-price(Stock,Yenprice,Exchange,yen,Date),
USprice = Yenprice/100.
% Context Definition Rules for Source 3
closingprice(Stock,Price,nyse,usd,tL):-
s3_closing-price(Stock,Price,nyse).
closingprice(Stock,Price,tokyo,yen,tL):-
s3_closingprice(Stock,Price,tokyo).
% Source 3 data
s3_closing price(stk1,55,nyse).
s3_closing-price(stk2,40,nyse).
s3_closingprice(stk3,6330,tokyo).
s3_closingprice(stk4,6531,tokyo).
Fig. 5.2 Context Interchange System for Example B
The first rule says that the closing prices for all stocks traded on the nyse exchange have
currencies in usd, and the corresponding date is t1. Similarly, the second rule says that the
closing prices for all stocks traded on the tokyo exchange have currencies in yen, and the
corresponding date is ti.
The context definition rule for Receiver 2 is
r2_closingprice(Stock, Price, Exchange):-
closing-price(Stock, Price, Exchange,usd,tl).
The entire program is shown in Fig. 5.2.
5.2.3 Sample Queries and Answers
The SQL query
select Stock, Price
from r2_closing-price
where Price > 50.
is equivalent to the Prolog query
? r2_closing-price(Stock,Price,) ,Price>50.
Observe that the underscore for the third argument, which is the exchange on which the stock is
traded, in the query means "don't care". The answer returned to this query has three tuples
Stock = stk3
Price = 6330/100
Stock = stk4
Price = 6531/100
Stock = stk1
Price = 55 ;
which is the desired result. Observe that the Prolog program did not evaluate the closing prices
of stocks stk3 and stk4. This is because the equality predicate "=" was used in the currency
conversion rule. To evaluate the closing prices, we should use "is" in place of "=".
Observe how the implicit currency and time argument for both source and receiver were
explicated. The receiver need not explicitly declare its currency or time assumptions within the
query. Note also how we can represent the assumption that the currency of the closing price of a
stock, in Source 3, depends on the exchange on which that stock is traded. Both source and
receiver autonomy are preserved. We now describe an even more challenging scenario and
demonstrate how the BULLION model resolves it in Example C.
5.3 Context Interchange for Example C
5.3.1 Sources and Receivers
In Example C, there are two sources, Source 4 and Source 5. Source 4 has two relations
shown in Fig. 5.4 and Fig. 5.5. The relation s4_head_of f ice contains information about the
head offices of various companies, much like in Source 1. The relation s4_revenue contains
information on the Revenue of the companies for the year t1 and t2. The currency of the
Revenue of a company depends on the country in which that company is incorporated. In this
case, the currencies of Revenue are usd, yen and pound for companies incorporated in the usa,
j apan and the uk respectively.
s4_headoffice
Company-name Citynamecl ny
c2 london
c3 tokyo
c4 chicago
c5 tokyo
Fig. 5.3 A Source 4 relation
s4_revenue
Company-name Revenue Yr
ci 1100 ti
c2 400 ti
c3 80000 ti
c4 1000 ti
c5 90000 ti
c1 1000 t2
c2 300 t2c3 70000 t2
c4 900 t2
c5 95000 t2
Fig. 5.4 Another Source 4 relation
Source 5 is shown in Fig. 5.5 and contains information on the Expense of various
companies. The implicit assumptions are that all currencies are in yen and this information
pertains to the year t1.
s5_expense
Company-name Expense
c1 10000
c2 9000
c3 8500
c4 9500
c5 11000
Fig. 5.5 Source 5
There are two receivers in this example: Receiver 3 and Receiver 4. Receiver 3 has the schema
rs3 (Company-name, Revenue, Profit, Country-name)
Country-name is a variable that stands for the country of incorporation of a company.
Furthermore, the domain of Country-name is the set of worldscope companies defined in the
shared ontology as cl-c4. The currency and year of Revenue and Prof it are usd and t1
respectively.
Receiver 4 has the following schema
c2 (Revenue,Yr).
Note that in this case, the name of the schema (i.e. c2) is actually a company name in Source 4
and 5. That is, we have schematic discrepancies (Chapter 2) within this federation! The currency
of Revenue expected by the Receiver 4 is usd.
5.3.2 The Shared Ontology
For the shared ontology, we will use the head_of f ice, country-of_incorporation
and located_in predicates of Example A. We will also use the predicates revenue, prof it
and expense, each of which have the following argument types Company-name, Amount,
Currency and Yr. These arguments correspond to thing, property, unit and time as described
by the framework presented in Chapter 3. Once again, we assume that the scale values for all
monetary amounts is one.
We will also require the conversion rates for yen to usd (100 yen to 1 usd) and for
pound to usd (2 pound to 1 usd) for revenue i.e.
revenue(Company-name, USamount, usd, Yr):-
USamount=Yenamount /100, revenue (Companyname, Yenamount, yen, Yr).
and
revenue(Companyname, USamount, usd, Yr):-
USamount=UKamount *2 , revenue (Company-name, UKamount, pound,
Yr).
Similar currency conversion rules are written for prof it and expense. Next, the relationship
among revenue, profit and expense is specified as
profit(Company-name, Profit, Currency, Yr):-
revenue(Company-name, Revenue, Currency, Yr),
expense(Company-name, Expense, Currency, Yr),
Profit=Revenue-Expense.
Observe that this rule states that to compute profit from revenue and expense, these amounts
must refer to the same company, year and currency. This enables the context mediator to select
the appropriate conversions. We also require the knowledge from the shared ontology of
Example A. Finally, we define the domain of worldscope companies as
worldscope (Companyname) :-
domain(Company-name, [cl,c2,c3,c4]).
Defining universally known domains within the shared ontology allows for reuse by sources and
receivers as discussed in Chapter 3
5.3.3 Context Definitions
The context definition rules for Source 4 are
head_office (Companyname, Cityname) :-
s4_head_of fice(Companyname,Cityname).
revenue(Company-name,Amount,usd,Yr):-
s4_revenue(Company-name,Amount,Yr),
country-ofincorporation(Company-name,usa).
revenue (Companyname,Amount,yen,Yr) :-
s4-revenue (Companyname, Amount, Yr),
country-ofjincorporation (Companyname, japan).
revenue (Companyname, Amountpound, Yr) :-
s4_revenue (Company-name, Amount, Yr),
countryofjincorporation (Company-name, uk).
The last three rules simply state that the currencies of the revenue are usd, yen and pound for
companies incorporated in the countries of usa, japan and uk respectively. The context
definition rule for Source 5 is
expense (Company-name, Expense, yen, tl) :-
s5_expense (Companyname, Expense).
This rule says that all expenses are in yen for the year tI. The context definition rule for
Receiver 3 is
rs3 (Company-name,Revenue, Profit, Country-name) :-
revenue (Company-name, Revenue,usd, tL),
profit (Company-name, Profit,usd, tL),
countryof_incorporation(Companyname,Countryname)
,worldscope (Company-name).
The context definition rule for Receiver 4 is
c2(Revenue,Yr):-
revenue(c2,Revenue,usd,Yr).
The entire program is shown in Fig. 5.6.
domain (X, (X| jI ) .
domain(X,[_IY]) :- domain(X,Y).
%***********Receiver 3: Context Definition Rules********
rs3(Companyname,Revenue,Profit,Country-name):-
revenue(Company-name,Revenueusd,tL),
profit(Company-name,Profit,usd,tl),
countryofjincorporation(Company-name,Countryname),
worldscope(Company-name).
%***********Receiver 4 Context Definition Rule********
c2(Revenue,Yr):-
revenue(c2,Revenue,usd,Yr).
%********The Shared Ontology***************
country-of-incorporation(Companyname,Country-name):-
head_office (Companyname, Cityname),
locatedin(Cityname,Countryname).
locatedin(ny, usa).
locatedin(tokyo, japan).
locatedin(london, uk).
locatedin(chicago, usa).
revenue(Company-name, USamount, usd, Yr):-
USamount=UKamount*2,revenue(Company-name, UKamount, pound, Yr).
revenue(Company-name, USamount, usd, Yr):-
USamount=Yenamount/100,revenue(Company-name, Yenamount, yen, Yr).
expense(Company-name, USamount, usd, Yr):-
USamount=UKamount*2,expense(Companyname, UKamount, pound, Yr).
expense(Company-name, USamount, usd, Yr):-
USamount=Yenamount/100,expense(Company-name, Yenamount, yen, Yr).
Fig. 5.6. Context Interchange System for Example C
5.3.4 Sample Queries and Answers
For Receiver 3, consider a query which requests for all tuples in the receiver's view to be
returned i.e.
? rs3 (Company-name, RevenueProfit, Country-name).
The following answer is returned,
profit(Company-name, USamount, usd, Yr):-
USamount=UKamount*2,profit (Companyname, UKamount, pound, Yr).
profit(Company-name, USamount, usd, Yr):-
USamount=Yenamount/100,profit (Companyname, Yenamount, yen, Yr).
profit (Company-name, Profit, Currency, Yr) :-
revenue(Company-name, Revenue, Currency, Yr),
expense(Company-name, Expense, Currency, Yr),
Profit=Revenue-Expense.
worldscope (Companyname) :-
domain(Companyname, [cl,c2,c3,c4]).
%*******Source 4 Context Definition Rules***********
head_office (Companyname,City-name) :-
s4_head_of fice(Company-name,City-name).
revenue (Company-name,Amount,usd,Yr) :-
s 4_revenue (Company-name, Amount, Yr),
countryofjincorporation (Company-name, usa).
revenue (Company-name, Amount , yen, Yr) :-
s 4_revenue (Company-name, Amount, Yr),
countryofjincorporation (Company-name, japan).
revenue (Company_nameAmount, poundYr) :-
s 4_revenue (Companyname, Amount, Yr),
countryofjincorporation (Companyname, uk).
Fig. 5.6. Context Interchange System for Example C (cont'd)
%*********Source 4 Data********
s4_revenue(cl,1100,tl).
s4_revenue(c2,400,tl).
s4_revenue(c3,80000,t1).
s4_revenue(c4,1000,tl).
s4_revenue(c5,90000,t1).
s4_revenue(cl,1000,t2).
s4_revenue(c2,300,t2).
s4_revenue(c3,70000,t2).
s4_revenue(c4,900,t2).
s4_revenue(c5,95000,t2).
s4_head_office(cl,ny).
s4_headoffice(c2,london).
s4_headoffice(c3,tokyo).
s4_headoffice(c4,chicago).
s4_headoffice(c5,tokyo).
%*******Source 5 Context Defintion Rules***********
expense(Company-name,Expense,yen,tl):-
s5_expense(Company-name,Expense).
%*********Source 5 Data********
s5_expense(cl,10000).
s5_expense(c2,9000).
s5_expense(c3,8500).
s5_expense(c4,9500).
s5_expense(c5,11000).
Fig. 5.6. Context Interchange System for Example C (cont'd)
Companyname = c2
Revenue = 400*2
Profit = 400*2-9000/100
Countryname = uk
Companyname = c3
Revenue = 80000/100
Profit = (80000-8500)/100
Countryname = japan
Company-name = c3
Revenue = 80000/100
Profit = 80000/100-8500/100
Countryname = japan
Company-name = c1
Revenue = 1100
Profit = 1100-10000/100
Countryname = usa
Company-name = c4
Revenue = 1000
Profit = 1000-9500/100
Countryname = usa ;
Note that there are multiple responses for company c 3. To understand why, observe the
corresponding values for Pro f it. We see that both responses calculated Prof it is different
ways, although the final result is still the same. In one answer tuple for c 3, subtraction occurred
first, followed by the conversion from yen to usd. In the other tuple for c3, Revenue and
Expense were both converted from yen to usd before subtraction. The reason for this is that
Prolog will look for all possible ways to derive an answer, giving rise to this redundancy
[70:ppl36-13 9].
Another query
? rs3 (Companyname, Revenue,Profit, Countryname),
Prof it>900.
which asks for all tuples but with Pro f it values greater than 90 0 usd, will retrieve the answers
Companyname = c1
Revenue = 1100
Profit = 1100-10000/100
Country-name = usa
Companyname = c4
Revenue = 1000
Profit = 1000-9500/100
Country-name = usa ;
There are a number of noteworthy features to note in the computation of these queries.
First, source and receiver autonomy were preserved. Second, the knowledge about
head_of f ice and its relationship to country-o fjincorporation was used for translation as
well as to define the currencies of revenue. This seems reasonable because there is no reason
why general knowledge cannot be used for both purposes. Third, there was a two-step
conversion (e.g. for c1) which involved a currency conversion (yen to usd for Expense of c1),
followed by a conversion from Revenue and Expense to Profit. Obviously, in a richer
ontology, longer conversion chains are possible. Fourth, just as in Example A, multiple sources
were involved. Fifth, the receiver's domain for company-name can be specified in its context
definition rule.
Finally, we now demonstrate how a relation and a receiver with discrepant schemas can
semantically interoperate. Consider the query issued by Receiver 4
? c2(Revenue,Yr).
which then receives the following answers
Revenue = 400*2
Yr = tl
Revenue = 300*2
Yr = t2
Thus, we have just shown an example of how schematic discrepancy can be resolved within the
Context Interchange framework without resorting to higher order languages, and without
sacrificing autonomy. Observe also how the currency conversion rule (from pound to usd) can
also be used for this other receiver.
5.4 Where did the Data come from? - The Logic Behind the Logic
To give further insight into the reasoning process of the context mediator, i.e. the Prolog
engine, we can construct a proof tree. Let us consider the tuple r s 3 ( c 2 , 4 0 0 * 2 , 4 0 0 * 2 -
90 0 0 /100 , uk), which is part of an answer returned to the query
? rs3 (Companyname, Revenue, Profit, Country-name).
issued by Receiver 3. A proof tree can explain how the Prolog engine proved this answer. The
program for constructing a proof tree is taken from [70:p329] and is shown in Fig. 5.7. To instruct
the program to construct a proof tree for rs3 (c2, 40 0*2, 400*2-9000 /100 , uk), we submit
the following query
? explain(rs3(c2,400*2,400*2-9000/100,uk),How).
The proof tree returned is
How = rs3(c2,400*2,400*2-9000/100,uk):-(revenue(c2,400*2,usd,tl):-
(400*2=400*2:-builtin), (revenue(c2,400,pound,tl):-
(s4_revenue(c2, 400, t1) :-true), (country-of_incorporation(c2,uk):-
(headoffice(c2,london) :-(s4_headoffice(c2,london):-
true)), (locatedin(london,uk):-true)))), (profit(c2,400*2-
9000/100,usd,t1):-(revenue(c2,400*2,usd,t):-(400* 2=400* 2 :-
builtin), (revenue(c2,400,pound,tl):-(s4_revenue(c2,400,t1):-
true), (countryofjincorporation(c2,uk) :-(headof fice(c2, london):-
(s4_headoffice(c2,london) :-true)), (locatedin(london,uk):-
true)))), (expense(c2,9000/100,usd,tl):-(9000/100=9000/100:-
builtin), (expense(c2,9000,yen,tl):-(s5_expense(c2,9000):-
true))), (400*2-9000/100=400*2-9000/100:-
builtin) ),(country_of_incorporation(c2,uk):-
(headoffice(c2,london) :-(s4_headoffice(c2,london):-
true)),(locatedin(london,uk) :-true)), (worldscope(c2):-
(domain(c2,[c1,c2,c3,c4]):-(domain(c2,[c2 ,c3 ,c4 ]):-true)))
%The basic meta-interpreter
builtin(builtin(X)).
explain(true,true):-!.
explain((A,B), (ProofA,ProofB)):-
!,explain(A,ProofA),explain(B,ProofB).
explain(A, (A :- builtin)):-builtin(A), !,A.
explain(A, (A:-Proof)):-clause(A,B), explain(B,Proof).
%A portion of the table of built-in predicates which %depend on
the particular Prolog implementation
builtin(A=B).
builtin(clause(A,B)).
builtin(A>B).
Fig. 5.7 A meta-interpreter for constructing proof trees
This is somewhat difficult to read though! So with a little reformatting, the refurbished
proof tree is shown in Fig. 5.8. Essentially, we have to prove (1). In order to prove (1), we need
to prove (1.1)-(1.4). But in order to prove (1.1), we need to prove (1.1.1)-(1.1.2) and so on.
Expression (1.1.1) is true because of the definition of the built-in predicate =, which is true if both
its arguments are syntactically equal. Expression (1.1.2.1) is true because it is asserted in Source 4.
Similarly, expression (1.1.2.2.2) is true because it is asserted in the shared ontology. The proof
tree shows the individual facts used from the various sources and the transformations that were
employed to derive the tuple.
A proof tree suggests a means of explaining to the receiver not only where the original
data came from, but what transformations took place in arriving at the final result. This
explanation capability might be very useful particularly since the entire query processing is
hidden from the receiver i.e. the receiver was not required to know what sources were accessed,
what rules in the ontology to use etc. The need to explain to the user "Where did the data come
from?" has been identified in [77, 78]. Wang and Madnick developed an algebra that produced
source tags as the explanation for which original and intermediate sources of data were used. A
proof tree, however, is more detailed and informative, showing which particular facts were used
and traces through the transformation steps. This is particularly useful for decision makers who
want to understand how reliable the answers returned are and what the assumptions made were.
5.5 What does the data mean? - Context Explication
The BULLION prototypes also allows us to ask questions about the underlying semantics
of data sources. This capability complements that of explaining the derivation of answers. For
example, the user might ask "What is the currency of the closing price of s tkl in Source 3?". This
question can be expressed as a query
? closing_price(stk1,_,_,Currency,_).
against Source 3 and its context definition rules, which is the following program
closing-price(Stock,Price,nyse,usd, t):-
s3.closingprice(Stock,Price,nyse).
closing-price(Stock, Price,tokyo,yen,tl):-
s3_closingprice (Stock, Price, tokyo).
How =rs3(c2,400*2,400*2-9000/100,uk):-
revenue(c2,400*2,usd,tl):-
400*2=400*2:-builtin
revenue(c2,400,pound,t1):- (1.1.2)
s4_revenue(c2,400,t1):-true (1.1.2.1)
country_ofincorporation(c2,uk):- (1.1.2.2)
head office(c2,london):- (1.1.2.2.1)
s4_headoffice(c2,london):true (1.1.2.2.1.1))
located in(london,uk):-true (1.1.2.2.2))
))
profit(c2,400*2-9000/100,usd,t1):- (1.2)
revenue(c2,400*2,usd,t1):- (1.2.1)
(1
4OO*2=4OO*2:-builtin (1.2.1.1)
revenue(c2,400,poundtl ):- (1.2.1.2)
s4 revenue(c2,400,tl1): -true (1.2.1.2.1)
country-ofjncorporation(c2,uk):- (1.2.1.2.2)
head office(c2,london):- (1.2.1.2.2.1)
s4_head office(c2,london):-:rue (1.2.1.2.2.1.1)
),f
Fs.4_8ArevenuePc2,400t)re for.2.1.2.1)
locatedjin(london,uk): -true
expense(c2,9000/100,usd,tl):-
9000/100=9000/100:-builtin
expense(c2,9000,yen,tl):-
s5_expense(c2,9000):-true
400*2-9000/100=400*2-9000/100:-builtin)
countryof_incorporation(c2,uk):-
headoffice(c2,london):-
s4_head__office(c2,london):-true)
located in(london,uk):-true)
worldscope(c2):-
domain(c2,[cl,c2,c3,c4]):-
domain(c2, [c2,c3,c4]): -true)
Fig. 5.8 A Prolog Proof Tree for Example C (cont'd)
(1.2.2)
(1.2.2.1)
(1.2.2.2)
(1.2.2.2.1)
(1.2.3)
(1.3)
(1.3.1)
(1.3.1.1)
(1.3.2)
(1.4)
(1.4.1)
(1.4.1.1)
(1.2.1.2.2.2)
s3_closing-price(stk1, 55,nyse).
s3_closing-price(stk2, 40,nyse).
s3_closingprice(stk3, 6330,tokyo).
s3_closing-price(stk4, 6531,tokyo).
The answer returned is
Currency = usd
signifying that the currency of the closing price of s tkI in Source 3 is usd. The next query
? closing-price (_,,Exchange Currency, _).
retrieves the following answers
Exchange = nyse
Currency = usd ;
Exchange = nyse
Currency = usd;
Exchange = tokyo
Currency = yen;
Exchange = tokyo
Currency = yen;
This answer reveals that nyse corresponds to usd and tokyo corresponds to yen.
5.7 Discussion
These series of Prolog programs served to illustrate the philosophy, principles and
capabilities that Context Interchange systems should possess. We have demonstrated how
various heterogeneities identified in the literature can be resolved within the Context Interchange
framework while preserving the autonomy of sources and receivers. We also showed how
knowledge in the shared ontology can be re-used by various sources and receivers for the
purposes of conversion and context definition. Furthermore, we also showed how conversion
procedures can be automatically constructed from simpler deductive rules. Finally, we
illustrated the notion of explanation and context explication.
These Prolog programs might also serve as specifications for Context Interchange
systems. They can be used to verify various implementations of Context Interchange systems.
For example, Prolog programs may be used to verify that the answers returned by a Context
Interchange system is complete and correct with respect to the Prolog specification. For example,
the implementation may be considered complete if the set of answers to a query that are provable
by the Prolog specification can be returned by the implementation. An implementation is correct
if the set of answers returned by the implementation are provable from the Prolog specification.
The next chapter concerns other aspects of scalability and flexibility. Specifically, we aim
to show that given a particular knowledge representation language, there will be more than one
way of encoding a BULLION theory. Each way will have a different impact of the scalability and
flexibility of the system. This dimension of scalability and flexibility has less to do with the
BULLION model itself and more with the way the model is encoded.
6 The BULLION Prototype: Proof of Concept II
We have already argued how global knowledge and its re-use allows for interoperable
systems to achieve greater scalability and flexibility. We now discuss other aspects of scalability
and flexibility of the BULLION prototype. Specifically, given a particular knowledge
representation language, there are different ways of encoding a BULLION theory with it.
Although these programs might be logically equivalent, they will have different impacts on the
scalability and flexibility of the system. Therefore, this particular dimension of scalability and
flexibility is independent of the BULLION model. Rather, it is related to how the BULLION model
is programmed in a particular knowledge representation language. In this chapter, we will
discuss various difficulties with scalability and flexibility of the Prolog program for Example C of
the previous chapter. We then show how refinements of the program lead to an equivalent but
more desirable system.
6.1 Refinement 1
Introducing new knowledge into the shared ontology of the Prolog program of Example
C might be cumbersome. For example, if a new currency conversion factor were introduced (say
US dollars to Singapore dollars with a conversion factor of 7/5), we will need to add another
three rules, one for each monetary amount i.e.
profit(Company-name, SINamount, sgd, Yr):-
SINamount=USamount*7/5,profit(Company-name, USamount, usd, Yr).
revenue(Company-name, SINamount, sgd, Yr):-
SINamount=USamount*7/5,revenue(Company-name, USamount, usd, Yr).
expense(Company-name, SINamount, sgd, Yr):-
SINamount=USamount*7 /5, expense (Companyname, USamount, usd, Yr).
Thus, if there were n monetary amounts, we would need to add n additional rules for each new
currency conversion. This is very cumbersome and certainly violates the requirement for Context
Interchange systems to be scalable and flexible.
domain(X, [X|1_).domain(X,[_IY]) :- domain(X,Y).
%***********Receiver 3: Context Definition Rules********
rs3(Companyname,Revenue,Profit,Country-name):-revenue(Company-name,Revenue,usd,t1),profit(Company-name,Profit,usd,t1),countryof_incorporation(Company-name,Country-name),
worldscope(Company-name).
%***********Receiver 4 Context Definition Rule********
c2(Revenue,Yr):-revenue(c2,Revenue,usd,Yr).
%********The Shared Ontology***************
countryofjincorporation(Company-name,Countryname):-head_o f f ice(Company-name,Cityname),locatedin(City-name,Countryname).
locatedjin(ny, usa).locatedjin(tokyo, japan).locatedin(london, uk).located-in(chicago, usa).
curcvt(yen,usd,1/100).curcvt(pound,usd,2).
revenue(Company-name, AmtTar, Curtar, Yr):-cur-cvt(Curorg,Curtar,Cfact),AmtTar=AmtOrg*Cfact,
revenue(Company-name, AmtOrg, Curorg, Yr).
profit(Company-name, AmtTar, Curtar, Yr):-cur-cvt(Curorg,Curtar,Cfact),AmtTar=AmtOrg*Cfact,
profit(Companyname, AmtOrg, Curorg, Yr).
expense(Company-name, AmtTar, Curtar, Yr):-cur-cvt(Curorg,Curtar,Cfact),AmtTar=AmtOrg*Cfact,
expense(Company-name, AmtOrg, Curorg, Yr).
profit(Company-name, Profit, Currency, Yr):-revenue(Company-name, Revenue, Currency, Yr),expense(Company-name, Expense, Currency, Yr),Profit = Revenue-Expense.
Fig. 6.1 Example D
worldscope(Company-name):-domain(Company-name, [cl,c2,c3,c4)).
%*******Source 4 Context Definition Rules***********head_office (Companyname, City-name) :-
s4_headoffice(Companyname,Cityname).revenue(Companyname,Amount,usd,Yr):-
s4_revenue(Company-name,Amount,Yr),country-ofjincorporation(Companyname,usa).
revenue(Company-name,Amount,yen,Yr):-s4_revenue (Company-name, Amount, Yr),country-ofjincorporation(Companyname,japan).
revenue(Company-name,Amount,pound,Yr):-s4_revenue (CompanynameAmount , Yr),countryofjincorporation(Companyname,uk).
%*********Source 4 Data********
s4_revenue(cl,1100,tl).s4_revenue(c2,400,tl).s4_revenue(c3,80000,tl).s4_revenue(c4,1000,tl).s4_revenue(c5,90000,tl).s4_revenue(cl,1000,t2).s4_revenue(c2,300,t2).s4_revenue(c3,70000,t2).s4 revenue(c4,900,t2).s4_revenue(c5,95000,t2).
s4_headoffice(cl,ny).s4_headoffice(c2,london).s4_headoffice(c3,tokyo).s4_headoffice(c4,chicago).s4_headoffice(c5,tokyo).%*******Source 5 Context Defintion Rules***********
expense(Company-name,Expense,yen,t1):-s5_expense(Company-name,Expense).
%*********Source 5 Data********s5_expense(cl,10000).s5_expense(c2,9000).s5_expense(c3,8500).s5_expense(c4,9500).s5_expense(c5,11000).
Fig. 6.1 Example D (cont'd)
This problem, however, can be eliminated by introducing the currency conversion
predicate cur-cvt (Curtar, Curorg, CFact) where Curtar is the target currency, Curorg
is the original currency and CFac t is the conversion factor. Then, currency conversion rules of
Example C can be rewritten as
revenue (Comp, Revenue*CFact, Curtar,Yr) :- cur_cvt (Curtar, Curorg,
CFact) ,revenue (Comp, Revenue, Curorg,Yr).
expense (Comp, Expense*CFact, Curtar, Yr) :- curcvt (Curtar, Curorg,
CFact) ,expense (Comp, Expense, Curorg, Yr).
profit (Comp, Profit*CFact,Curtar,Yr) :- cur cvt(Curtar, Curorg,
CFact) ,profit(Comp,Profit,Curorg,Yr).
cur_cvt(usd, yen, 1/100).
cur-cvt(usd, pound, 2).
This new program, Example D, is shown in Fig. 6.1. This program is logically equivalent to that
of Example C in that identical results will be obtained for the same queries. Now, however, the
addition of a currency conversion factor requires the addition of only a single statement e.g.
cur_cvt(sgd, usd, 7/5),
6.2 Refinement 2
There is, however, yet another problem. If we were to introduce a new monetary
amount, say tax, we would have to write one rule for currency conversion for this quantity.
That is,
tax(Comp,Tax*CFact,Curtar,Yr) :- curcvt (Curtar, Curorg,
CFact) ,tax(Comp,Tax,Curorg,Yr).
Thus, if we were to introduce n such amounts into the shared ontology, n such additional rules
for currency conversion need to be written, one for each amount. Once again, this problem can
be eliminated by introducing a new predicate moneyamt and replace the previous currency
conversion rules with the following more general currency conversion rule for all monetary
amounts
moneyamt (MoneyAmt, Companyname, AmtTar, Curtar, Yr) :-
cur_cvt(Curorg,Curtar,Cfact),
AmtTar=AmtOrg*Cfact,
moneyamt (MoneyAmt, Companyname, AmtOrg, Curorg,
Yr).
The variable argument MoneyAmt can take the values of revenue, expense and prof it or any
other monetary amount yet to be introduced. Fig. 6.2 graphically illustrates this refinement. The
new program, Example E, is shown in Fig. 6.3. This program is equivalent to that of Example C
and D in that identical results will be obtained for the same queries. Now however, the addition
of a new monetary amount, say tax, does not require the addition of any currency conversion
rules.
Let us illustrate. Suppose we add a new source and receiver. The new source, Source 6,
contains tax information i.e.
s6_tax (c1,11000).
s6_tax(c2,10000).
s6_tax(c3,9000).
s6_tax(c4,9700).
s6_tax(c5,10000).
The currency and year assumed by this source is yen and t 1 respectively. The context definition
rule for this source is
moneyamt (tax, Company-name, Tax, yen, t) :-
s6_tax(Companyname,Tax).
This context definition rule defines tax as a monetary amount. By doing so, all the currency
conversions for monetary amounts automatically apply to tax. So additional rules for currency
conversion specifically for tax are not required.
The new receiver, Receiver 5, has the schema rs5 (Company-name, Pro f it). The
argument Profit actually refers to profits after tax. Furthermore, the receiver expects the
information to be in Singapore dollars (sgd) for the time period t1. The name of the monetary
amount profit after tax as described in the shared ontology is pf t_at. The context definition
rule for the new receiver is therefore
reven e(Company-name, AmtTar, Curtar, Yr):-cur_ Curorg,Curtar,Cfact),AmtTar= tOrg*Cfact,
revenue(C any-name, AmtOrg, Curorg,Yr).
profit(Company-name, AmtTar, Curtar, Yr):-cur_cvt(Curorg,Curtar,Cfact),AmtTar=AmtOrg*Cfact,profit(Company-name, AmtOrg, Curorg, Yr).
expense(Companyname, AmtTar, Curtar, Yr):-curcvt(Curorg,Curtar,Cfact),AmtTar=AmtOrg*Cfact,expense(Company-name, AmtOrg, Curorg, Yr).
money-amt(MoneyAmt,Company-name, AmtTar, Curtar, Yr):-cur-cvt(Curorg,Curtar,Cfact),
AmtTar=AmtOrg*Cfact,money-amt(MoneyAmt,Company-name, AmtOrg,
Curorg, Yr).
Fig. 6.2 Refinement 2: Concepts revenue, prof it and expense transformed from predicates
to argument values
domain(X, [X|1).domain(X,[_IY]) :- domain(X,Y).
%***********Receiver 3: Context Definition Rules********
rs3(Company-name,Revenue,Profit,Country-name):-money-amt(revenue,Company_name,Revenue,usd,t1),moneyamt(profit,Companyname,Profit,usd,t1),country_ofincorporation(Companyname,Countryname),worldscope(Company-name).
%***********Receiver 4 Context Definition Rule********
c2(Revenue,Yr):-moneyamt(revenue,c2,Revenue,usd,Yr).
%********The Shared Ontology***************
country-ofjincorporation(Companyname,Countryname):-head_o ffice (Company-name, City-name),locatedin(Cityname,Countryname).
locatedjin(ny, usa).located in(tokyo, japan).located in(london, uk).located in(chicago, usa).
cur-cvt(yen,usd,1/100).cur_cvt(pound,usd,2).
moneyamt(MoneyAmt,Companyname, AmtTar, Curtar, Yr):-cur_cvt(Curorg,Curtar,Cfact),
AmtTar=AmtOrg*Cfact,moneyamt(MoneyAmt,Companyname, AmtOrg, Curorg, Yr).
moneyamt(profit,Companyname, Profit, Currency, Yr):-
Profit = Revenue-Expense,moneyamt(revenue,Companyname, Revenue, Currency, Yr),
moneyamt(expense,Companyname, Expense, Currency, Yr).
worldscope(Companyname):-domain(Company-name, [cl,c2,c3,c4)).
%*******Source 4 Context Definition Rules***********
headof fice(Companyname,City-name) : -s 4_head_o f fice(Company-name,City-name).
money-amt(revenue,Companyname,Amount,usd,Yr):-s4_revenue (Companyname, Amount , Yr),countryof_incorporation(Company-name,usa).
Fig. 6.3 Example E
money-amt(revenue,Companyname,Amount,yen,Yr):-s4_revenue(Company-name,Amount,Yr),countryof_incorporation(Companyname,japan).
moneyamt(revenue,Company_name,Amount,pound,Yr):-s4_revenue(Companyname,Amount,Yr),countryof-incorporation(Company-name,uk).
%*********Source 4 Data********
s4_revenue(cl,1100,tl).s4_revenue(c2,400,tl).s4_revenue(c3,80000,tl).s4_revenue(c4,1000,tl).s4_revenue(c5,90000,tl).s4_revenue(cl,1000,t2).s4_revenue(c2,300,t2).s4_revenue(c3,70000,t2).s4_revenue(c4,900,t2).s4_revenue(c5,95000,t2).
s4_headoffice(cl,ny).s4_headoffice(c2,london).s4_headoffice(c3,tokyo).s4_headoffice(c4,chicago).s4_headoffice(c5,tokyo).%*******Source 5 Context Defintion Rules***********
moneyamt(expense,Companyname,Expense,yen,t1):-s5_expense(Company-name,Expense).
%*********Source 5 Data********
s5_expense(cl,10000).s5_expense(c2,9000).s5_expense(c3,8500).s5_expense(c4,9500).s5_expense(c5,11000).
Fig. 6.3 Example E (cont'd)
rs5 (Company-name, Profit) :-
moneyamt (pft_at,Company-name, Profit, sgd, t1).
We also need the currency conversion factor from US dollars to Singapore dollars. We therefore
add the statement
cur_cvt(sgd, usd, 7/5).
Finally, we need to add a rule that states the relationship among prof it, tax and pf t_at i.e.
moneyamt (pftat, Companyname, Pft-at, Currency, Yr) :-
Pftat = Profit-Tax,
moneyamt(profit , Company_name, Profit, Currency, Yr),
moneyamt(tax,Companyname, Tax, Currency, Yr).
The new program, Example F, is shown in Fig. 6.4.
The query
? rs5(Company_name,Profit).
will then retrieve the following answers
Companyname = c3
Profit = (80000-8500-9000)*(1/
Company-name = c5
Profit = (90000-11000-10000)*(
Company__.name = c3
Profit = ((80000-8500)*(1/100)
100)*(7/5) ;
1/100)*(7/5)
-9000*(1/100))*(7/5) ;
Companyname = c5
Profit = ((90000-11000)*(1/100)-10000*(1/100))*(7/5)
Companyname = c3
Profit = (80000*(1/100)-8500*(1/100)-9000*(1/100))*(7/5)
domain(X, [X|]).domain(X,[_IY]) :- domain(X,Y).
%***********Receiver 3: Context Definition Rules********
rs3(Companyname,Revenue,Profit,Country-name):-moneyamt(revenue,Company-name,Revenue,usd,t1),moneyamt(profit,Companyname,Profit,usd,t1),country_ofincorporation(Companyname,Countryname),worldscope(Company-name).
%***********Receiver 4 Context Definition Rule********
c2(Revenue,Yr):-moneyamt(revenue,c2,Revenue,usd,Yr).
%***********Receiver 5: Context Definition Rules********
rs5(Company-name,Profit):-moneyamt(pftat,Companyname,Profit,sgd,t1).
%********The Shared Ontology***************
country-ofjincorporation(Companyname,Countryname):-head_o ffice (Company-name, City-name),locatedjin (City-name, Countryname).
locatedjin(ny, usa).located in(tokyo, japan).located in(london, uk).locatedjin(chicago, usa).
cur_cvt(yen,usd,1/100).cur-cvt(pound,usd,2).cur_cvt(usd,sgd,7/5).
money_amt(MoneyAmt,Company-name, AmtTar, Curtar, Yr):-cur_cvt(Curorg,Curtar,Cfact),
AmtTar=AmtOrg*Cfact,moneyamt(MoneyAmt,Company_name, AmtOrg, Curorg, Yr).
moneyamt(profit,Companyname, Profit, Currency, Yr):-
Profit = Revenue-Expense,moneyamt(revenue,Companyname, Revenue, Currency, Yr),
moneyamt(expense,Companyname, Expense, Currency, Yr).
moneyamt(pftat,Company-name, Pft-at, Currency, Yr):-Pft at = Profit-Tax,moneyamt(profit,Company-name, Profit, Currency, Yr),
moneyamt(tax,Companyname, Tax, Currency, Yr).
Fig. 6.4 Example F
100
worldscope (Company-name) :-domain(Companyname, [cl,c2,c3,c4]).
%*******Source 4 Context Definition Rules***********head_office (Company-name, City-name) :-
s4_head_of fice(Companyname,Cityname).moneyamt(revenue,Company_name,Amount,usd,Yr):-
s4_revenue(Companyname,Amount,Yr),countryof_incorporation(Company-name,usa).
money-amt(revenue,Company_name,Amount,yen,Yr):-s4_revenue(Companyname,Amount,Yr),country-ofjincorporation(Company-name,japan).
money-amt(revenue,Companyname,Amount,pound,Yr):-s4_revenue(Companyname,Amount,Yr),countryofjincorporation(Company-name,uk).
%*********Source 4 Data********
s4_revenue(cl,1100,tl).s4_revenue(c2,400,tl).s4_revenue(c3,80000,tl).s4_revenue(c4,1000,tl).s4_revenue(c5,90000,tl).s4_revenue(cl,1000,t2).s4_revenue(c2,300,t2).s4_revenue(c3,70000,t2).s4_revenue(c4,900,t2).s4_revenue(c5,95000,t2).
s4_headoffice(cl,ny).s4_headoffice(c2,london).s4_headoffice(c3,tokyo).s4_headoffice(c4,chicago).s4_headoffice(c5,tokyo).%*******Source 5 Context Defintion Rules***********moneyamt(expense,Company-name,Expense,yen,t1):-
s5_expense(Company-name,Expense).%*********Source 5 Data********
s5_expense(c1,10000).s5_expense(c2,9000).s5_expense(c3,8500).s5_expense(c4,9500).s5_expense(c5,11000).
%*******Source 6 Context Defintion Rules***********
moneyamt(tax,Company-name,Tax,yen,t1):-s6_tax(Companyname,Tax).
%*********Source 5 Data********s6_tax(cl,11000).s6_tax(c2,10000).s6_tax(c3,9000).s6_tax(c4,9700).s6_tax(c5,10000).
Fig. 6.4 Example F (cont'd)
101
Company name = c5
Profit = (90000*(1/100)-11000*(1/100)-10000*(1/100))*(7/5)
Company-name = c2
Profit = (400*2-9000*(I/1OO)-1OOOO*(1/100))*(7/5) ;
Company-name = c1
Profit = (1100-10000*(1/100)-11000*(1/100))*(7/5) ;
Companyname = c4
Profit = (1000-9500*(1/100)-9700*(1/100))*(7/5)
Company-name = c3
Profit = (80000-8500)*(1/100)*(7/5)-9000*(1/100)*(7/5)
Companyname = c5
Profit = (90000-11000)*(1/100)*(7/5)-10000*(1/100)*(7/5)
Companyname = c3
Profit = (80000*(1/100)-8500*(1/100))*(7/5)-9000*(1/100)*(7/5)
Company-name = c5
Profit = (90000*(1/100)-11000*(1/100))*(7/5)-10000*(1/100)*(7/5)
Companyname = c2
Profit = (400*2-9000*(1/100))*(7/5)-10000*(1/100)*(7/5) ;
Company-name = cl
Profit = (1100-10000*(1/100))*(7/5)-11000*(1/100)*(7/5) ;
Companyname = c4
Profit = (1000-9500*(1/100))*(7/5)-9700*(1/100)*(7/5)
Companyname = c3
Profit = 80000*(1/100)*(7/5)-8500*(1/100)*(7/5)-9000*(1/100)*(7/5)
Companyname = c5
Profit = 90000*(1/100)*(7/5)-11000*(1/100)*(7/5)-10000*(1/100)*(7/5)
Companyname = c2
Profit = 400*2*(7/5)-9000*(1/100)*(7/5)-10000*(1/100)*(7/5) ;
Companyname = c1
Profit = 1100*(7/5)-10000*(1/100)*(7/5)-11000*(1/100)*(7/5) ;
Company-name = c4
Profit = 1000*(7/5)-9500*(1/100)*(7/5)-9700*(1/100)*(7/5)
Once again, note that Prolog returns some redundant solutions, corresponding to different ways
of computing the same answer.
102
6.3 Discussion
In this chapter, we showed that the scalability and flexibility of a Context Interchange
system is also affected by the way in which knowledge in a shared ontology is encoded, given a
particular knowledge representation language. The program of Example C was refined to that of
Example E. Now, adding knowledge of a currency conversion (in this case US dollars to
Singapore dollars) to the shared ontology required adding one simple statement to Program E, as
opposed to introducing three more complex satements into Program C. Furthermore, adding a
new monetary amount such as tax to Program E did not require any any accompanying rules to
define the various currency conversions. In the case of Program C, three additional rules would
have been needed to define the currency conversions for tax (i.e. yen to usd, pound to usd, usd
to sgd). This difference in impact on scalability and flexibility has little to do with the BULLION
model itself, but more with the way the model is encoded. Thus, given a particular
representation language in which to represent a shared ontology, care must be taken to
appropriately encode it.
In the next chapter, we consider logic as an implementation paradigm for Context
Interchange systems. We discuss potential obstacles and solutions to making logic a viable
implementation approach for Context Interchange. The discussion will include the strengths and
weaknesses of Prolog as an implementation tool, and consider how these various weaknesses
may be resolved by more powerful logic languages. Some of these languages can add further
scalability and flexibility to the system.
103
7 Logic as an Implementation Paradigm
In this chapter, we will consider the use of Prolog, and more generally, logic
programming and the Logic of Contexts, in implementing Context Interchange Systems. There
are a number of benefits, both theoretical and practical, in doing so. First, the declarative nature
of logic programming tools makes them desirable for specifying shared ontologies as well as for
making context definitions explicit. Second, the theoretical base for logic and logic programming
is rich and well established [26, 35, 38, 55]. Many of the resources developed by the logic
programming community can be drawn upon to implement Context Interchange systems. We
have already seen in Chapter 5 how a meta-interpreter for explanation, a contribution from the
logic programming literature, has been used to explain answers for the purpose of Context
Interchange systems.
One of the first observations that one can make is that most of the sources that are likely
to be integrated are not Prolog databases, but will probably be relational databases instead. Thus,
a means of coupling Prolog to relational database systems is needed. We discuss this in Section
7.1. Next, we highlight some difficulties in Prolog with semantic query optimization (Section 7.2)
and looping (Section 7.3). These are well known weaknesses of Prolog. Then, we point to more
advanced logic programming languages aimed at overcoming various weaknesses of Prolog
(Section 7.4). These may be used to implement Context Interchange systems instead. Finally, we
shall revisit the Logic of Contexts and consider how it can be used to extend the BULLION model
to deal with various other issues pertaining to scalability and flexibility as a federation of sources
and receivers grows in size (Section 7.5).
7.1 Prolog and Relational Databases
A survey of systems for Coupling Prolog to Relational databases (i.e. CPR systems) is
described in [17]. A key focus of this stream of research is aimed at providing efficient data
access.
There are four major components of CPR systems. They are the Prolog engine, the Prolog
interface, the database interface and the database engine. The Prolog engine may have enhanced
features in order to adapt it to the proposed database environment. For example, some Prolog
engines provide fast access methods in main memory for searching and accessing facts. These
techniques include sophisticated indexing and hashing mechanisms. Another modification to the
104
Prolog engine concerns returning the set of all answers to a user who issued a query, as opposed
to returning it tuple at a time as was the case in the last chapter.
The Prolog interface is concerned with specifying and recognizing database Predicates in
the Prolog program. There are various levels of transparency for doing this. With full
transparency, database predicates are recognized by the interface with no user support. In this
case, a program analyzer accesses database directories in order to recognize database predicates.
With no transparency, the Prolog programmer is forced to write explicit queries in the language
of the database engine, e.g. SQL.
Next, the database interface is specifically designed for interacting and extracting tuples
from a database. The component is concerned with the types of queries that are considered by
the database. For example, queries issued by the Prolog engine to the database can be single-
predicate (selection) or multiple-predicate (join). Another concern is how the tuples are extracted
from the database i.e. tuple at a time versus the entire set. Note that this is a different issue from
returning answers to the end-user, which is the concern of the Prolog interface. The final
component is the database engine itself, which is taken to be a given in the BULLION model.
Examples described in [17] of CPR system prototypes include PRO-SQL[18], EDUCE [5]
and the CGW approach by Ceri, Gottlob and Wiederhold [16] among others. The point is that
this stream of work represents a resource upon which we can draw to construct Context
Interchange systems using logic programming.
7.2 Prolog and Semantic Query Optimization
The context definition rules of the BULLION model allow us to incorporate traditional
integrity constraints as part of the context definition. This facilitates semantic query optimization
[43]. For example, a semantic query optimizer checks for constraints to see if the result to a query
is empty. If it is, then the query need not be executed at all. This can minimize unnecessary
access to databases, and can potentially save a lot to time. Essentially, semantic query
optimization involves the intelligent pruning of a potentially large search space.
As a concrete example, consider Source 5 and its context definition rules as shown below
(from Example C). The context definition rule is modified by adding the constraint
Expense< 120 0 0 to the body of the context definition rule. This means that all values in the
E x p e n s e column are less than 1 2 0 0 0. Now, consider the query
expense (Companyname, 13000 , yen, t1) ?. A negative answer will be returned without
even having to check the database Source 5. This is because Prolog tests the literals in the body of
105
a clause from left to right. Thus, the query will fail (i.e. return a negative answer) when Prolog
encounters Expense<12 000.
%*******Source 5 Context Definition Rules***********
expense (Company_name, Expense, yen, t) :-
Expense<12000,
s5_expense (Company_name, Expense).
%*********Source 5 Data********
s5_expense(cl,10000).
s5_expense(c2,9000).
s5_expense(c3,8500).
s5_expense(c4,9500).
s5_expense(c5,11000).
Unfortunately, other queries such as expense (Company-name, Expense, yen, t1) ? cannot
be correctly processed by the above Prolog program. This is because in order to test the condition
Expense<12 000, the variable Expense has to be instantiated. This is not the case for this
particular query and the execution will be aborted.
Fortunately, however, BULLION does not restrict the implementation of Context
Interchange systems to Prolog, which is a limited logic language for the sorts of things we would
like to do. More powerful and efficient logic languages are being developed that have virtually
the same syntax as Prolog. These languages could be used instead. We will briefly describe some
of these languages in Section 7.4.
7.3 Prolog and Looping
Prolog employs a depth-first search strategy and might enter into an infinite branch of an
SLD tree and continue looping indefinitely. Such a situation can occur, for example, when we
want to specify a two-way currency conversion. Sincefunction inversion is not available to us in
Prolog, introducing a reverse currency conversion from Singapore dollars to US dollars to the
program of Example F means adding the Prolog statement
cur_cvt(sgd,usd,5/7).
We will, as a result, obtain an SLD-tree with an infinite branch in which Prolog continues to loop
by converting US dollars to Singapore dollars and back again. The problem of detecting an
infinite branch however is undecidable as Prolog has the full power of recursion theory.
106
This problem is being addressed by the logic programming community. One approach
to this problem is based on modifying the underlying computation mechanism that searches the
SLD-tree by adding the capability of pruning [6]. Such mechanisms are also called loop checking.
The purpose of a loop check is to prune every infinite SLD-tree to a finite subtree that still
contains the root of the original tree. Informally, a loop check is considered sound when no
solutions are lost due to the pruning. A loop check is complete if every infinite SLD-tree can be
pruned to a finite sub-tree. Besides soundness and completeness, another interesting property of
a loop checking mechanism is shortening. That is, if there are multiple derivations of an answer, a
shortening loop check mechanism will prune off the longer derivations and retain only the
shorter ones. This will certainly enhance the efficiency of a Prolog computation.
In [6], Bol et al introduced a class of such pruning mechanisms called simple loop checks.
They went on to prove, however, that no sound and complete simple loop checks exists even for
Prolog programs without function symbols. To date, we are not aware of any loop checking
mechanisms that are sound and complete for our purposes.
A possible, but crude, alternative solution to this problem is to prune branches of an SLD-
tree such that no branches exceed a certain finite depth, say d. This pruning mechanism is
obviously complete. This is because any SLD-tree with infinite branches can be pruned with this
mechanism to give a tree in which all branches are finite (i.e. with depth less or equal to d).
However, we run the risk of pruning off branches that lead to potential solutions to a query. In
this respect, this strategy is not sound. This is the classical trade-off between tractability and the
correctness of a computational strategy. That is, if we want tractability, we have to live with the
fact that a computational strategy may not be sound.
Ideally, we would like to have a value of d such that no potential solutions are lost. If, for
a particular federation of sources and receivers, we do not expect the longest finite conversion
chain to exceed a depth of h, then d can be safely set to h. We might also consider setting d<h.
This might be the case, for example, if we knew that all potential solutions pruned off in this
manner have shorter derivations in the newly pruned SLD-tree. If we are very concerned about
efficiency and not very worried about obtaining all solutions, we can make d even smaller.
We could also use a less expressive language, in which case we give up the ability to
express certain kinds of knowledge. Yet another possibility is to use more specialized, "hand-
crafted", inference strategies that take special advantage of domain knowledge to avoid such
looping. But once again, there is a trade-off in that we give up the generality of the inference
mechanism.
107
Another approach, yet to be explored us, is to employ more powerful programming
languages that do functional logic programming (Section 7.4). Such logic languages make
available to us the capability for function inversion. This feature might enable us to introduce
two-way currency conversions without having to write programs that go into infinite loops.
7.4 Other Logic Programming Languages
Various limitations of Prolog have led researchers to develop more powerful logic
programming languages aimed at addressing some of these weaknesses. One class of such
languages is referred to as constraint logic programming languages [38]. Constraint logic
programming, as the name suggests, involves the merger of two paradigms: constraint solving
and logic programming. When viewed from a constraint solving point of view, the unification
algorithm used by Prolog can be considered to be a special case of constraint solving where the
constraint is such that two terms are semantically equivalent if and only if they are syntactically
identical. This is the reason for Prolog's failure to correctly process the last query in Section 7.2.
A constraint logic programming language such as CLP(R) [39] , which takes a more general view
of constraints, can easily perform semantic query optimization without such problems. In fact,
constraint logic programming is considered more efficient than Prolog because constraint solving
involves the intelligent pruning of a search space.
Another class of logic programs combine logic programming and object-oriented
concepts such as inheritance and default values [24, 42]. Inheritance and default values are
powerful concepts that can be exploited in Context Interchange. For example, we can explicitly
declare that all currencies are in US dollars unless stated otherwise. This makes specifying
knowledge in the shared ontology easier.
Yet another class of logic programming languages, called functional logic programming
languages [35], combines functional programming with logic programming. Such languages allow
us to define functions using the "=" predicate, something that Prolog does not allow us to do.
One of the consequences is that functional logic programming languages have features such as
function inversion, which is not available in Prolog. Thus, specifying a two-way currency
conversion in Prolog requires additional statements that would not have been needed had we
used a functional logic programming language. Functional logic programming languages also
have more efficient operational behavior compared with pure logic languages since functions
allow more deterministic evaluations than predicates.
108
Finally, some logic languages such as LIFE (which stands for Logic, Inheritance,
Functions and Equations) [1] combine various aspects of constraint solving, object-orientation
and functional programming into one language! The point is this, there are powerful tools that
are available for implementing Context Interchange systems within a paradigm based on logic.
We are not just limited to Prolog. These tools would be useless, however, if we did not have a
good "blueprint" of what a Context Interchange system is. The key contribution of this thesis is
just such a blueprint, in the form of a formal specification based on logic.
7.5 The Logic of Contexts Revisited
In Examples C to F, we have been considering a federation of sources and receivers in
which monetary amounts were assumed to have a scale of one. Suppose we had another
federation of sources and receivers in which all monetary amounts are assumed to be in ten's (i.e.
10). Thus the statement
moneyamt (revenue , c1, 1100 , usd, t).
is true in the first federation but false in the second federation. Integrating the two federations
"as is" will lead to problems because of inconsistency in the scale values. One approach to solving
this problem is to require that all existing predicates be modified to include explicit scale
arguments. This, however, can be cumbersome and violates the Context Interchange objective of
being scalable and flexible.
Another approach is to use the Logic of Contexts (LOC) described in Chapter 2. LOC
was designed specifically with such problems in mind. In building the knowledge base the size
of Cyc, problems of inconsistent theories are bound to occur. LOC alleviates this problem in Cyc
by partitioning the knowledge base into multiple, internally consistent, microtheories. These
microtheories need not, however, be consistent with one another. This "chunking" reduces the
cognitive effort required in managing such a huge knowledge base because we can focus on
particular microtheories at a time, as opposed to the whole knowledge base at once. Links among
microtheories are provided by means of lifting axioms.
Since BULLION is specified in first order logic, making the link to LOC is not very
difficult. Each BULLION model can be considered to be a microtheory. Thus, the federation
described in Example F represents a single consistent microtheory. Let us call it Fedone. Any
proposition p asserted within this federation can be expressed as ist (FedOne, p) (e.g.
ist (FedOne, money-amt (revenue, c1, 1100, usd, t1) ) ). Let the second federation be
FedTwo. Lifting axioms can be used to make scale assumptions explicit by linking these two
109
microtheories to a more specific microtheory called FedOne&Two. The following lifting axiom
links FedOne to FedOne&Two:
ist (FedOne, moneyamt (Moneyamt, Companyname, Amount, Currency, Year))
ist (FedOne&Two, moneyamt (Money-amt, Companyname, Amount, Currency
Year, 1).
The last argument of the predicate money-amt in FedOne&Two is the scale argument. The next
lifting axiom links FedTwo to FedOne&Two:
i st (FedOne, moneyamt (Moneyamt, Companyname, Amount, Currency, Year))
ist (FedOne&Two, money-amt (Money-amt, Company-name, Amount, Currency
Year, 10).
A scale conversion rule can then be declared in FedOne&Two:
ist (FedOne&Two, moneyamt (Money-amt, Companyname, Amount1, Currency
Year, Scale1) * Amount1=Amount2*Scale2/Scale1 Amoney-amt
(Moneyamt, Companyname, Amount2, Currency Year, Scale2)).
This approach eliminates the need to modify existing predicates in both federations while
allowing both to interoperate meaningfully. A graphical depiction of this arangement is shown
in Fig. 7.1.
Each microtheory can also simply be an ontology without sources or receivers. Thus, we
can combine ontologies in this fashion as well. Using LOC, we can more easily manage the
growth of the size of a federation of sources and receivers.
In sum, Prolog is ideally suited to demonstrate proof of concept in this thesis because it is
a common language and its relationship to logic and databases is well understood. Its declarative
style is also in keeping with the Context Interchange philosophy of explicit representation of
knowledge. However, a number of weaknesses may prove to be a serious hindrance in using
Prolog as a full-fledge implementation platform. Fortunately, more advanced logic programming
systems, which retain many of the benefits of Prolog, have been or are being developed that are
aimed at making logic programming a more viable implementation solution. The choice of such
a language for a full fledge implementation of a Context Interchange system however, is a matter
for further investigation.
110
articulation axiom
articulation axiom
111
FedOneShared Ontology
Receiver Context
Context
FedOne&Twomoney-amt (Money-amt,Company-name, Amount1, CurrencyYear,Scale 1)4ee Amount1=Amount2*Scale2/Scalel A money-amt(MoneyamtCompany-name, Amount2, Currency Year,Scale2)
FedTwoShared Ontology
Source Context Receiver Context
niMediator ~
Fig. 7.1 Using LOC to integrate two federations
8 Conclusions and Future Work
8.1 Thesis Summary
The overarching goal of this thesis is the development of a formal model of semantic
interoperability, called BULLION, that realizes the philosophy of the Context Interchange
Approach. The aim of the Context Interchange Approach is to achieve a high level of semantic
interoperability while preserving source and receiver autonomy. We have demonstrated how
various important semantic heterogeneities identified in the literature can be solved by the
BULLION model. Furthermore, the autonomy of receivers and sources were preserved while
doing so.
We also described how Context Interchange systems based on BULLION are scalable and
flexible, as compared with current interoperable systems which fair poorly in achieving this goal.
This is possible in BULLION because general knowledge is encoded at the global level in the
shared ontology. Sources and receivers then use this ontology to explicitly declare their contexts.
The context mediator then uses the knowledge in the shared ontology and the context definitions
to automatically select the appropriate conversion procedures to execute. General knowledge is
globalized and is specified once. It can then be used and reused for context explication and
conversions. All this adds up to greater ease of construction and maintenance of a federation,
compared with some traditional approaches. We also demonstrated how explanation of answers
and context explication can be incorporated in the BULLION model. We also discussed how other
tools such as the Logic of Contexts can be used to extend the BULLION model to manage other
aspects of scalability and flexibility.
The core concepts that underlie the BULLION model are drawn from Bunge's Semantics
and Ontology. These concepts center around the notion of an "elementary" proposition as a basic
unit of exchange. A context is a constraint on what propositions are allowed. Conversion of
propositions is equated with logical deduction. The shared ontology contains the definition and
deductive relationships among propositions. Context mediation is then equivalent to
transforming propositions from a source, through deduction, to propositions that satisfy the
requirements of the receiver's context.
These core ideas are integrated into BULLION, a proof theoretic model of Context
Interchange. There are several reasons for using proof theory. For one thing, the semantics of
proof theory are more widely understood than idiosyncratic implementations. There is also a
112
wider and more established theory base for logic. Furthermore, since proof theory is abstract and
nonprocedural, underlying assumptions of the model are very explicit.
BULLION not only serves to formalize concepts such as conversion, context and ontology,
it also defines the notion of a context mediated answer to a query. Such a definition is critical to
the enterprise of delivering a context mediated answer, which is suppose to be more
"meaningful" than an unmediated one.
But how do we know if this is the "right" definition i.e. one that matches our intuitive
notions of a "meaningful" answer. As proof of concept, these ideas were concretely illustrated by
means of a series of Prolog programs. In the Prolog programs, we showed what is meant by
context definition and a shared ontology. We showed how the mediated answers returned in
response to queries satisfy the context requirements of the receiver and matched our intuitions as
to what a suitable answer should be. Thus, we can conclude that BULLION is a formal model that
faithfully realizes the goals of Context Interchange.
8.2 Future Work
This thesis also suggests that logic is useful not only for conceptualizing BULLION, but
also for implementing it. Logic offers a potential new paradigm for the semantic integration of
databases. This has benefit from both theoretical and practical perspectives. The rigor and
declarativeness of logic as a language are valuable features to the enterprise of semantic
integration. We highlighted several logic programming technologies that may be used to
effectively construct a Context Interchange system. Therefore as future research, we intend to
evaluate the use of various logic programming languages for the purposes of building a full-
fledge Context Interchange prototype. This prototype should possess the functionality described
in this thesis.
From a theoretical perspective, we intend to investigate how multiple inconsistent
theories may be meaningfully integrated. The problem of multiple inconsistent theories cannot
be avoided as the federation grows in size. This might involve integrating different ontologies
and even different federations. We discussed this briefly already in Section 7.5. The most
promising tool for this purpose, at least from the perspective of BULLION, is the Logic of
Contexts.
We also have to consider the notions of "default" and "overriding" conversion rules. That
is, some receivers may have preference for their own local conversions that may override the
corresponding conversion in the shared ontology. For example, a receiver might have preference
113
for a different currency conversion than the one specified in the shared ontology. Then for this
specific receiver, its local conversion rule overrides that in the shared ontology. Other receivers
will use the rule in the shared ontology as a default.
114
References
[1] Ait-Kaci, H., & Podelski, A. Towards a meaning of LIFE. In Proceeding of the ThirdInternational Symposium on Programming Language Implementation and Logic Programming:255-274, Passau, Germany, 1991.
[2] Akmajian, A., Demers, R. A., Farmer, A. K., & Harnish, R. M. Linguistics, anintroduction to language and communication (3rd ed.). MIT Press, Cambridge, MA, 1993.
[3] Arens, Y., & Knoblock, C. A. Planning and Reformulation Queries for Semantically-Modeled Multidatabase Systems. In Proceeding of the Conference in Information andKnowledge Management, Baltimore, MD, 1992.
[4] Batini, C., Lenzirini, M., & Navathe, S. A comparative analysis of methodologies fordatabase schema integration. ACM Computing Surveys, 18, 4: 323 - 364, 1986.
[5] Bocca, J. On the Evaluation Strategy of EDUCE. In Proceedings of the ACM-SIGMODConference, Washington, D.C., 1986.
[6] Bol, R. N., Apt, K. R., & Klop, J. W. An Analysis of loop checking mechanisms for logicprograms. Theoretical Computer Science, 86, 1: pp.35-79, 1991.
[7] Brachman, R., & Levesque, H. J. The Knowledge Level of a KBMS. In M. L. Brodie & J.Mylopolous (Eds.), On Knowledge Base Management Systems: IntegratingArtificialIntelligence and Database Technologies: 63-69, Springer-Verlag, New York, 1986.
[8] Bright, M. W., Hurson, A. R., & Pakzad, S. H. A Taxonomy and Current Issues inMultidatabase Systems. IEEE Computer: 50-60, 1992.
[9] Bunge, M. Semantics I: Sense and Reference D. Reidel Publishing Company, Boston,1974.
[10] Bunge, M. Semantics II: Interpretation and Truth D. Reidel Publishing Company, Boston,1974.
[11] Bunge, M. Ontology I: The Furniture of the World D. Reidel Publishing Company,Boston, 1977.
[12] Bunge, M. Ontology II: A World of Systems D. Reidel Publishing Company, Boston,1979.
[13] Bunge, M. Epistemology & Methodology III: Philosophy of Science and Technology D.Reidel Publishing Company, Boston, 1985.
[14] Buvac, S., Buvac, V., & Mason, I. A. The Semantics of Propositional Contexts. InProceeding of the Eighth International Symposium on Methodologies for Intelligent Systems,1994.
[15] Buvac, S., & Mason, I. A. Propositional Logic of Context. In Proceedings of the EleventhNational Conference on Artificial Intelligence, 1993.
[16] Ceri, S., Gottlob, G., & Wiederhold, G. Efficient database access through Prolog. IEEETransactions on Software Engineering, Feb 1989.
[17] Ceri, S., & Tanca, G. L. Logic Programming and Databases Springer Verlag, BerlinHeidelberg, 1990.
[18] Chang, C. L. PROSQL: A Prolog Programming Interface with SQL/DS. In Proceedings ofthe First Workshop on Expert Database Systems, Kiawah Island, SC, 1984.
[19] Clocksin, W. F., & Mellish, C. S. Programming in Prolog (2nd ed.). Springer-Verlag, NewYork, 1984.
[20] Codd, E. F. A relational model of data for large shared data banks. Communications of theACM, 13, 6: 377-387, 1970.
115
[21] Collett, C., Huhns, M. N., & Shen, W. Resource Integration Using a Large KnowledgeBase in Carnot. IEEE Computer, 24, 12: 55-63, 1991.
[22] Date, C. J. An Introduction to Database Systems (5th ed.). Addison-Wesley, Reading,MA, 1990.
[23] Davis, R., Shrobe, H., & Szolovits, P. What is a Knowledge Representation? AI Magazine:17-33, 1993.
[24] Davison, A. A Survey of Logic Programming-based Object Oriented Languages.Technical Report No. 92/3. Dept. of Computer Science, University of Melbourne, 1992.
[25] Dayal, U., & Hwang, K. View definition and generalization for database integration inmultidatabase system. IEEE Transactions on Software Engineering, SE-10: 628-644, 1984.
[26] Enderton, H. B. A Mathematical Introduction to Logic Academic Press, San Diego, CA,1972.
[27] Farquhar, A., Dappert, A., Fikes, R., & Pratt, W. Integrating Information Sources UsingContext Logic. Technical Report No. KSL-95-12. Stanford University, 1995.
[28] Gallaire, H., & Minker, J. Logic and Databases Plenum Press, New York and London,1978.
[29] Gallaire, H., Minker, J., & Nicolas, J. M. Logic and Databases: A Deductive Approach.ACM Computing Surveys, 16,2: 153-185, 1984.
[30] Graham, G. (1995, December 13). Single currency's computer debit. Financial Times, p.
[31] Gruber, T. R. The role of a common ontology in achieving sharable, reusable knowledgebases. In Principles of Knowledge Representation and Reasoning: Proceedings of the 2ndInternational Conference: 601-602, Cambridge, MA, 1991.
[32] Gruber, T. R. Toward Principles for the Design of Ontologies Used for KnowledgeSharing. In Guarino & Poli (Eds.), To appear in Formal Ontology in Conceptual Analysis andKnowledge Representation, Kluwer, 1993.
[33] Guha, R. V. (1991). Contexts: A formalization and some applications. STAN-CS-91-1399-Thesis, Stanford University.
[34] Guha, R. V., & Lenat, D. B. Cyc: A Midterm Report. AI Magazine: 32-59, 1990.
[35] Hanus, M. The Integration of Functions into Logic Programming: From Theory toPractice. The Journal of Logic Programming, 19,20: pp.583-628, 1994.
[36] Heimbigner, D., & McLeod, D. A Federated architecture for information management.ACM Transactions on Office Information Systems, 3: 253-278, 1985.
[37] Huhns, M. N., Jacobs, N., Ksiezyk, T., Shen, W.-M., Singh, M. P., & Cannata, P. E.Enterprise Information Modeling and Model Integration in Carnot. In Proceedings of the1st International Conference on Enterprise Integration Modeling, 1992.
[38] Jaffar, J., & Maher, M. J. Constraint Logic Programming: A Survey. The Journal of LogicProgramming, 19,20: pp.503-581, 1994.
[39] Jaffar, J., Michaylov, S., Stuckey, P., & Yap, R. The CLP(R) Language and System. ACMTransactions on Programming Languages and Systems, 14, 3: 339-395, 1992.
[40] Kay, R. L. (1994, October 17). What's the meaning of this? Computerworld, p. 89-93.
[41] Kent, W. Solving Domain Mismatch and Schema Mismatch Problems with an Object-Oriented Database Programming Language. In Proceedings of the 17th InternationalConference on Very Large Data Bases, Barcelona, Spain, 1991.
[42] Kifer, M., Lausen, G., & Wu, J. Logical Foundations of Object-Oriented and Frame-BasedLanguages. Journal of the ACM, May 1995, 1995.
116
[43] King, J. QUIST: A System for Semantic Query Optimization for Relational Databases. InIn Conference on Very Large Databases, 1981.
[44] Krishnamurthy, R., Litwin, W., & Kent, W. Interoperability of Heterogenous Databaseswith Schematic Discrepancies. In Proc. First Int'l Workshop on Interoperability inMultidatabase Systems: 144-151, 1991.
[45] Krishnamurthy, R., Litwin, W., & Kent, W. Language Features for Interoperability ofDatabases with Schematic Discrepancies. In Proceesings of 1991 ACM Sigmod Int'lConference on Management of Data: 40-49, Denver, Colorado, 1991.
[46] Landers, T., & Rosenberg, R. An Overview of Multibase. In Proceedings of the SecondInternational Symposiumfor Distributed Databases: 153-183, 1982.
[47] Larson, J. A., Navathe, S. B., & ElMasri, R. A Theory of Attribute Equivalence inDatabases with Application to Schema Integration. IEEE Transactions on SoftwareEngineering, 15,4, 1989.
[48] Lee, J., & Malone, T. W. Partially Shared Views: A Scheme for Communicating amongGroups that Use Different Type Hierarchies. ACM Transactions on Information Systems, 8,1, 1990.
[49] Lenat, D. B., & Guha, R. V. Building Large Knowledge-Based Systems Addison-Wesley,Reading, Mass., 1990.
[50] Levesque, H. J. A View of Knowledge Representation. In M. L. Brodie & J. Mylopolous(Eds.), On Knowledge Base Management Systems: IntegratingArtificial Intelligence andDatabase Technologies: 63-69, Springer-Verlag, New York, 1986.
[51] Levesque, H. J., & Brachman, R. J. A Fundamental Tradeoff in KnowledgeRepresentation. In H. J. Levesque & R. J. Brachman (Eds.), Readings in KnowledgeRepresentation, Morgan Kaufmann Publisher's Inc., Los Altos, Calif., 1985.
[52] Litwin, W. An Overview of the Multidatabase System MRDSM, Denver, CO, 1985.
[53] Litwin, W., & Abdellatif, A. Multidatabase interoperability. IEEE Computer: 10-18, 1986.
[541 Litwin, W., Mark, L., & Roussopoulos, N. Interoperability of Multiple AutonomousDatabases. ACM Computing Surveys, 22, 3: 183-235, 1990.
[55] Lloyd, J. W. Foundations of Logic Programming (2nd ed.). Springer-Verlag, 1987.
[56] Madnick, S. E. From VLDB to VMLDB (Very MANY Large Data Bases): Dealing withLarge Scale Semantic Heterogeneity. In Proceeding of the 21st VLDB Conference: 11-16,Zurich, Switzerland, 1995.
[57] McCarthy, J. Generality in Artificial Intelligence. Communications of the ACM, 30, 12: 1030-1035, 1987.
[58] Motro, A. Superviews: Virtual Integration of Multiple Databases. IEEE Transactions OnSoftware Engineering, 13, 7: 785-798, 1987.
[59] Motro, A., & Buneman, P. Constructing Superviews. In Proceedings of SIGMOD: 56-64,1981.
[60] Neches, R., Fikes, R., Finin, T., Gruber, T., Patil, R., Senator, T., & Swartout, W. R.Enabling Technology For Knowledge Sharing. AI Magazine, 12, 3: 16-36, 1991.
[61] Newell, A. The Knowledge Level. AI Magazine, 18, 1: 87-127, 1981.
[62] Reiter, R. Towards a Logical Reconstruction of Relational Database Theory. In M. Brodie,J. Mylopoulos, & J. W. Schmidt (Eds.), On Conceptual Modeling: Perspectives from ArtificialIntelligence, Databases and Programming Languages, Springer-Verlag, Berlin and New York,1984.
[63] Robinson, J. A. A Machine-Oriented Logic Based on the Resolution Principle. Journal ofthe ACM, 12: 23-41, 1965.
117
[64] Sciore, E., Siegel, M., & Rosenthal, A. Using Semantic Values to Facilitate InteroperabilityAmong Heterogenous Information Systems. Transactions on Database Sytems, 19, 2: 254-290, 1994.
[65] Shen, W.-M., Huhns, M. N., & Collet, C. Resource Integration without ApplicationModification. Technical Report No. ACT-OODS-214-91. MCC, 1991.
[66] Sheth, A., & Kahyap, V. So Far (Schematically) yet So Near (Semantically). In IFIPTC2/WG2.6 Conference on Semantics of Interoperable Database Systems, DS-5, Lome, Victoria,Australia, 1992.
[67] Sheth, A. P., & Larson, J. A. Federated Database Systems for Managing Distributed,Heterogeneous, and Autonomous Databases. ACM Computing Surveys, 22, 3: 183-235,1990.
[68] Siegel, M., & Madnick, S. Context Interchange: Sharing the Meaning of Data. SIGMODRecord, 20, 4: 77-79, 1991.
[69] Smith, J. M., & Smith, D. C. P. Database Abstractions: Aggregation and Generalization.Transactions on Database Systems, 2, 2, 1977.
[70] Sterling, L., & Shapiro, E. The Art of Prolog (2nd ed.). MIT Press, Cambridge, MA, 1994.
[71] Ventrone, V., & Heiler, S. Semantic Heterogeneity as a Result of Domain Evolution.SIGMOD RECORD, 20,4: PP.16-20, 1991.
[72] Wand, Y. A Proposal for a Formal Model of Objects. In W. Kim & F. Lochovsky (Eds.),Object-Oriented Concepts, Databases, and Applications: 602, ACM Press, New York, N.Y.,1989.
[73] Wand, Y., & Weber, R. An Ontological Analysis of Some Fundamental InformationSystems Concepts. In Proceedings of the Ninth International Conference on InformationSystems, Minneapolis, Minnesota, USA, 1988.
[74] Wand, Y., & Weber, R. Mario Bunge's Ontology as a Formal Foundation for InformationSystems Concepts. In P. Weingartner & G. J. W. Dorn (Eds.), Studies on Mario Bunge'sTreatise, Rodopi, Amsterdam, 1990.
[75] Wand, Y., & Weber, R. An Ontological Model of an Information System. IEEETransactions of Software Engineering, 16, 11: 1282-1292, 1990.
[76] Wand, Y., & Weber, R. Toward a Theory of the Deep Structure of Information Systems. InProceedings of the Twelfth International Conference on Information Sytems, 1991.
[77] Wang, Y. R., & Madnick, S. E. A Polygen Model for Heterogeneous Database Systems:The Source Tagging Perspective. In Proceedings of the 16th International Conference on VeryLarge Data bases (VLDB): 519-538, Brisbane, Australia, 1990.
[78] Wang, Y. R., & Madnick, S. E. A Source Tagging Theory for Heterogeneous DatabaseSystems. In International Conference on Information Systems: 243-256, Copenhagen,Denmark, 1990.
[79] Woods, W. A. What's in a Link: Foundations for Semantic Networks. In H. J. Levesque &R. J. Brachman (Eds.), Readings in Knowledge Representation, Morgan KaufmannPublisher's Inc., Los Altos, Calif., 1985.
118