Abstract for the MCC EI Workshop on Model Integration
		C. Marshall 1/22/92

Within the AI Technology Center at Digital we have recognized the problem of
Model Integration as one of the significant issues needed to be addressed in
order to make true Enterprise Integration realizable. We have both developed a
prototype "wrapper" pairwise integration which we call "The Concept Bus" and
have been following the work on global model integration being done for DARPA
and the Air Force by Dr. Ric Mayer at Texas A&M and Knowledge Based Systems,
Inc. We are involved in the Knowledge Representation area with the IEEE P1252
Working Group to create a Standard for Knowledge Representation. We have
explored both Federated and Global approches and found weaknesses in both.
Either approach can be pragmatically useful under specific circumstances, but
neither scale to generic levels. We don't have answers - but the questions we
have need to be addressed. 

The primary problem with both approaches is one of levels of abstraction. It is
our experience that no two models, even when done using the same language and
methodology on the same domain, use the same abstractions. All models are 
abstractions of the domain being modeled. An abstraction, by definition, 
ignores, or throws away, "irrelevant" aspects of the domain. Because we have no 
formal way to specify what is relevant or irrelevant (we have no Theory of 
Utility) we have no way to describe how the abstractions in one model relate to 
the abstractions in another. (The Semantics question.)

Most models are created to answer specific questions. Rarely is a "generic" 
model created with the intent to answer multiple, unanticipated, questions.
(It can be argued that this is what a relational database is, but such a model
is representationaly weak.) Once a question specific model is developed, it
usually leads to changes in the domain being modeled that invalidate the model.
The problem then becomes one of how to keep a model in sync with the domain 
being modeled, and how to reflect those changes in linkages to other models.
(The Model Evolution question.)

We have argued elsewhere (AAAI Spring Symposium, 1989) that where different 
domains overlap, their ontologies do not necessarily map in any clean way. This
is becoming evident in the ontologies being used in Software Engineering 
Repositories (IRDS, AD Cycle, Cohesion) which overlap with ontologies being
developed in Concurrent Engineering Repositories (STEP/PDES). 
(The Interacting Domains question.) 

In the representation space, there appears to be confusion between the concepts 
of data/type models and ontologies. Is an Ontology an extension of a Type Model
or is a Type Model a language in which to express an Ontology?
(The Type vs Ontology question.)

We are currently concerned by the lack of coordination between the Concurrent
Engineering (STEPS/PDES) community and the Software Engineering (IRDS/ATIS/AD
Cycle) communities. These communities appear to be well ahead of other
communities in the whole modeling arena. Both claim to be extensible to the
Enterprise Level. If mechanisms of coordination can be developed between these
domains, other domains will at least have a "model" of how to integrate with
these.