Old Dominion University

ODU Digital Commons

Modeling, Simulation & Visualization Engineering
Modeling, Simulation & Visualization Engineering
Faculty Publications

2007

Applying the Levels of Conceptual Interoperability

Model in Support of Integratability, Interoperability,
and Composability for System-of-Systems
Engineering
Andreas Tolk
Old Dominion University, atolk@odu.edu

Saikou Y. Diallo
Old Dominion University, sdiallo@odu.edu

Charles D. Turnitsa
Old Dominion University, cturnits@odu.edu

Follow this and additional works at: https://digitalcommons.odu.edu/msve_fac_pubs

Part of the Digital Communications and Networking Commons, and the Numerical Analysis and
Scientific Computing Commons

Repository Citation
Tolk, Andreas; Diallo, Saikou Y.; and Turnitsa, Charles D., "Applying the Levels of Conceptual Interoperability Model in Support of
Integratability, Interoperability, and Composability for System-of-Systems Engineering" (2007). Modeling, Simulation & Visualization
Engineering Faculty Publications. 27.
https://digitalcommons.odu.edu/msve_fac_pubs/27

Original Publication Citation

Tolk, A., Diallo, S., & Turnitsa, C. D. (2007). Applying the levels of conceptual interoperability model in support of integratability,
interoperability, and composability for system-of-systems engineering. Journal of Systemics, Cybernetics, and Informatics, 5(5), 65-74.

This Article is brought to you for free and open access by the Modeling, Simulation & Visualization Engineering at ODU Digital Commons. It has been
accepted for inclusion in Modeling, Simulation & Visualization Engineering Faculty Publications by an authorized administrator of ODU Digital
Commons. For more information, please contact digitalcommons@odu.edu.
 Applying the Levels of Conceptual Interoperability Model
in Support of Integratability, Interoperability, and Composability
for System-of-Systems Engineering

Andreas TOLK, Saikou Y. DIALLO, Charles D. TURNITSA

Virginia Modeling Analyses & Simulation Center, Old Dominion University
Norfolk, VA 23529, USA
+1.757.686.6200 (Phone), +1.757.6214 (Fax), [atolk,cturnits,sdiallo]@odu.edu

mented world view captured in the model – need to be aligned

ABSTRACT as well. Currently, various organizations are coping with the
task to develop a theory of composability. Petty and Weisel [2]
The Levels of Conceptual Interoperability Model (LCIM) was formulated the current working definition: “Composability is
developed to cope with the different layers of interoperation of the capability to select and assemble simulation components in
modeling & simulation applications. It introduced technical, various combinations into simulation systems to satisfy specific
syntactic, semantic, pragmatic, dynamic, and conceptual layers user requirements. The defining characteristic of composability
of interoperation and showed how they are related to the ideas is the ability to combine and recombine components into differ-
of integratability, interoperability, and composability. The ent simulation systems for different purposes.” In order to be
model was successfully applied in various domains of systems, able to apply engineering methods to contribute to a compos-
cybernetics, and informatics. able solution, several models have been developed and applied.
However, at the end a machine readable and understandable
Keywords: Integratability, Interoperability, Composability, implementation based on data and metadata is needed to enable
Syntax, Semantics, Pragmatics, Dynamics agents to communicate about situations and the applicability of
M&S applications. They must share a common universe of
discourse in support of the decision maker, which requires a
common language rooted in a formal specification of the con-
1. INTRODUCTION cepts. A formal specification of a conceptualization, however,
is a working definition of a common ontology. This ontology
Until recently, the support of decision makers often focused on can then be applied to derive conceptually aligned and orches-
representing data. However, the advent of intelligent software trated configurations for conceptually composable, technically
agents using the Internet introduced a new quality to decision interoperable, and integrated solutions.
support systems. While early systems were limited to simple
situations, the examples given by Phillips-Wren and Jain [1] This paper shows how various layered composability ap-
show that state-of-the-art decision support is based on agent- proaches contributed to the definition of the Levels of Con-
mediated environments. Today, real-time and uncertain deci- ceptual Interoperability Model (LCIM) and how the results can
sion problems can be supported to manage the decision making be used to derive implications and requirements for ontologies
process in a highly dynamic and agile sphere. Simple data describing the universe of discourse in which intelligent agents
mining and presentation is no longer sufficient: based on his- serve to mediate between agile applications in order to com-
toric data, trend analysis and possible development hypotheses pose the individual systems into a meaningful system of sys-
must be developed and compared. This requires a purposeful tems. Cybernetics shows that simple methods often are to lim-
abstraction of reality and the implementation of the resulting ited to be applied in complex environments like the system-of-
concept to make it executable on computers. These processes system integration as envisioned here. The described method is
are better known as “modeling,” the purposeful abstraction of therefore phased and combines bottom-up and top-down ap-
reality and capturing of assumptions and constraints, and proaches: The information exchange requirements are identi-
“simulation,” the execution of a model on a computer. Model- fied by top-down analysis of the business processes to be sup-
ing & simulation (M&S) becomes more and more a backbone ported and the informatics be applied. This is followed by a
of operational research to cope with highly complex and dy- bottom up approach leading to a common ontology represent-
namic environments and decision challenges that are often ill- ing the various aspects of participating systems in phase two.
or semi-structured in nature, in particular when such M&S Finally, the composition and integration of systems is orches-
systems utilize knowledge management and agent directed trated using top-down means in phase III.
simulation to enable intelligent decision technologies, such as
agent mediated decision support. The rest of this paper is organized following these ideas. After
a short motivation why we need agent mediated decision sup-
While such enriched M&S systems are valuable contributors to port and how the work presented here fits into this vision, sec-
the decision makers toolbox, the task to compose them in a tion 3 will introduce the LCIM. The three phases are described
meaningful way is everything but trivial. The challenge is not in sections 4 to 6. Section 7 gives an application example be-
to exchange data between the system: the technical side is suf- fore we will give a summary.
ficiently dealt with by interoperability standards. The problem
is that the concepts of the underlying models – or the imple-

ISSN: 1690-4524 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 5 65

2. MOTIVATION FOR AGENT MEDIATED DECISION 3. LEVELS OF CONCEPTUAL INTEROPERABILITY
SUPPORT
The underlying work on composability of M&S applications
Before going into the details of LCIM and the three-phased conducted by the authors is mainly based on military applica-
method, this section deals with the rationale for working on tions, in particular within the domain of using simulation sys-
agent-mediated support and how this is applicable in the tems for training and experimentation in support of armed
broader context of complex business operations to be supported forces. Nonetheless the results are easy to be generalized for
by agile systems. For the military application domain, Alberts other application domains, such as complex business scenarios,
and Hayes [3] define the quality of support by decision support traffic flow [7], or medical emergencies [8].
systems in net-centric environments using the net-centric value
chain, which distinguishes four categories. They are easily Models for Composability
applicable in the broader context as well. The composability discussion started with Harkrider and
Lunceford [9] making the case that technical integration of
• The value chain starts with Data Quality describing the systems is necessary but not sufficient. Based on similar obser-
information within the underlying command and control vations, Dahmann [10] distinguished between technical inter-
system. This definition can be generalized to be applicable operability and substantive interoperability. Petty [11] extended
to decision support systems. the technical interoperability layer and introduced hardware,
communication, and protocol layer. However, while the com-
• Information Quality tracks the completeness, correctness, munity focused on implementation questions, it became obvi-
currency, consistency, and precision of the data items and ous that many challenges are on higher levels: the underlying
information statements available. concepts and models that have to be aligned in the process of
federating systems. While most current standardization efforts,
• Knowledge Quality deals with procedural knowledge and such as IEEE 1278 [12] and IEEE 1516 [13], are focused on
information embedded in the decision support system such the implementation level, standardization must be aimed at the
as templates for behavior, assumptions about capabilities modeling level to ensure interoperability between systems.
of entities, and domain specific assumptions, often coded Page et al. [14] introduced the idea to differentiate between
as rules. technical layers for integratability, implementation layers for
interoperability, and modeling layers for composability. There-
• Finally, Awareness Quality measures the degree of using fore, the LCIM detailed the substantive interoperability level in
the information and knowledge embedded within the deci- order to cope with these challenges explicitly.
sion support system. Awareness is explicitly placed in the
cognitive domain. Overview of the LCIM
The research on composability conducted at the Virginia Mod-
Data representing decision support systems were only able to eling Analysis & Simulation Center resulted in the LCIM,
reach the data quality. By bringing the data of heterogeneous which underwent several improvements since its first publica-
systems together into a common situation display adds the tion [15]. The current version of LCIM as depicted in Figure 1
necessary context needed for information. Instead of endless is documented in [16].
lists of data and messages, a common operational picture be-
comes possible. However, this picture is still only a snapshot.
In order to reach the next level of knowledge, procedural Level 6
Conceptual Interoperability

Increasing Capability for Interoperation

knowledge is needed. This procedural knowledge can be pro-
vided in form of simulation services, as simulations are based Level 5
Modeling / Dynamic Interoperability
on models, which are purposeful abstractions of reality, and Abstraction
simulations are the means to execute a model over time. We Level 4
therefore move from the common operational picture to the Pragmatic Interoperability

common operation model. While a picture says more than Level 3

1,000 words (or the 1,000 pieces of enumerated data), an ex- Semantic Interoperability
ecutable M&S application says more than 1,000 pictures! Simulation /
Implementation Level 2
Syntactic Interoperability
Finally, if data and metadata enables software agents to select Level 1
different M&S components and compose them to evaluate Technical Interoperability
alternative hypotheses, even the cognitive domain of awareness
Level 0
can be supported. However, in order to enable agents to be- Network /
No Interoperability
Connectivity
come the ambassadors for M&S components (or other agile
and dynamic processes and services), the agent must be aware
of the assumptions and constraints underlying the model. This Figure 1: Levels of Conceptual Interoperability Model
task is everything but trivial, as shown in [3a, 3b] and other
publications. However, in order to support the cognitive do-
The different levels are characterized as follows:
main of awareness, this knowledge must be captured in meta
data interpretable by intelligent software agents. Yilmaz [6]
• Level 0: Stand-alone systems have No Interoperability.
evaluates these ideas of agent-mediated composition further.
• Level 1: On the level of Technical Interoperability, a com-
munication protocol exists for exchanging data between

66 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 5 ISSN: 1690-4524

 participating systems. 1 On this level, a communication sition of applicable agile components and systems to support
infrastructure is established allowing it to exchange bits the decision maker; it is not to generate a general and complete
and bytes, the underlying networks and protocols are un- description of the problem sphere. We are well aware of alter-
ambiguously defined. native top-down approaches that start with a common under-
standing to derive necessary implementations; however, the
• Level 2: The Syntactic Interoperability level introduces a application domain we are focusing on in this paper uses al-
common structure to exchange information, i.e., a com- ready implemented agile systems to support a higher goal of
mon data format is applied. On this level, a common pro- the decision maker, so capturing the capabilities and constraints
tocol to structure the data is used; the format of the infor- of available services, applications, and systems was the primary
mation exchange is unambiguously defined. driver behind this effort. To what degree the bottom-up ap-
proach can be merged with top-down approaches, such as the
• Level 3: If a common information exchange reference coherence/correspondence approach described by Sousa-Poza
model is used, the level of Semantic Interoperability is [20] is topic of ongoing research.
reached. On this level, the meaning of the data is shared;
the content of the information exchange requests are un- The LCIM was applied in various domains successfully and
ambiguously defined. featured as a reference model in various journal contributions
and book chapters. The originally intended use is described in
• Level 4: Pragmatic Interoperability is reached when the [21]: applying the ideas to support composable M&S service
interoperating systems are aware of the methods and pro- for net-centric command and control applications. The Interop-
cedures that each other are employing. In other words, the erability Framework for future U.S. Department of Energy
use of the data – or the context of its application – is un- solutions for the Power-Grid described in [22] uses a derivate
derstood by the participating systems; the context in which of the model. How to apply the LCIM to align smart applica-
the information is exchanged is unambiguously defined. tions is the topic of [23]. Finally, the recent book on model and
simulation-based data engineering uses the LCIM to show
• Level 5: As a system operates on data over time, the state functionality and supported concepts of their solution [24]. The
of that system will change, and this includes the assump- study of Carnegie Mellon University on System of Systems
tions and constraints that affect its data interchange. If mentions the LCIM as one of the candidates for successful
systems have attained Dynamic Interoperability, then they evaluation of approaches [25].
are able to comprehend the state changes that occur in the
assumptions and constraints that each other is making over 4. THE MODEL-BASED APPROACH TO
time, and are able to take advantage of those changes. 2 In SYSTEM OF SYSTEMS ENGINEERING
particular when interested in the effects of operations, this
becomes increasingly important; the effect of the infor- The following advantages of model driven approaches to reach
mation exchange within the participating systems is un- alignment of heterogeneous decision-making processes are well
ambiguously defined. known in the domain of cybernetics and informatics. They have
been published in [26]. The idea is to use the first phase to
• Level 6: Finally, if the conceptual model – i.e. the understand the business processes and the supporting informa-
assumptions and constraints of the meaningful abstraction tion technology (IT) solutions and capture them in a common
of reality – are aligned, the highest level of interoperabil- model. The use of models is important, because:
ity is reached: Conceptual Interoperability. This requires
that conceptual models will be documented based on en- • Models help the decision makers understand the key
gineering methods enabling their interpretation and mechanisms of an existing process. A model provides a
evaluation by other engineers. In other words, on this we clear picture of acting entities, roles, relations, and tasks.
need a “fully specified but implementation independent This is needed to understand the processes of the allies as
model” as requested in Davis and Anderson [19] and not well as the processes of the non-military partners and vice
just a text describing the conceptual idea. versa.

It should be pointed out that these layers of operations are still • Models act as the basis for creating suitable information
driven by implementations of agile systems that should be de- systems that support the process. The model comprises
scribed in order to enable intelligent software agents to evalu- descriptions of process that can be used to identify neces-
ate their applicability to support a decision and their compos- sary support. Furthermore, the sub-processes already sup-
ability with other solutions. As such, it is a typical bottom-up ported by IT in the various participating organizations are
approach. The objective is to generate a usable and sufficient displayed. This includes systems’ interfaces as well as
description based on data and metadata supporting the compo- their information capability that is available information
that can be delivered to other systems as well as suitable
1
information that can be computed to deliver new insights.
Some early alternatives distinguish furthermore between Therefore, the model puts the various existing systems
hardware level and communication level when analyzing the into their place within the federated system of systems
domains of technical interoperability. supporting the overarching operations and also serves as
2
Methods that enable such interoperability can be the requirement driver for additional IT support.
(documented) open source, reference implementations, or
adequate documentation, such as complete UML models or • Models can be used to improve the current structure and
DEVS models [17]. Tolk and Muguira [18] proposed an operation. By creating a common description of the over-
initial framework based on the LCIM merging several all operation, participating organizations and supporting
engineering approaches, including UML and DEVS, to systems, redundancies as well as bottlenecks become ob-
insure consistent interoperation of services.

ISSN: 1690-4524 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 5 67

 vious. Necessary changes can be identified and solutions The result of the top down approach is the conceptual under-
can be derived and agreed on based on a common model. standing what information exchanges occur when, between
which processes, what are the business objects into which the
• Models show the structure of innovated solutions. The atomic information elements are composed or aggregated, and
model becomes the basis for a common action plan sup- which organizations – and hence which supporting IT systems
porting radical as well as incremental changes. The de- – contribute as source or target systems to this system-of-sys-
sired end state and the necessary steps leading from the tems supporting enterprise wide applications.
status quo to this end state are part of the model. The
model itself becomes an important management instru- 5. ONTOLOGIES FOR COMPOSABILITY
ment that orchestrates the necessary improvements in par-
allel and distributed events. The top-down use of models in understanding the alignment of
different processes in phase 1 must be accompanied by an
• Models can serve as a basis to evaluate new ideas. Mod- analysis of required information exchange between the proc-
els can be used to copy other structures, and evaluate esses resulting in data exchange requirements between the
processes used by other partners – or opponents – in the underlying IT systems and than used to compose the solutions
environment in which the operation takes place. As the in phase 2. The result of this activity is an ontology that is able
model comprises the necessary detail needed to derive a to satisfy the information exchange requirements of the partici-
conceptual or functional model of the mission space, sup- pating systems based on the concepts, relationships, and rules
port by M&S directly becomes possible. Respective ex- identified in phase 1.
periments can help evaluate such future concepts. An ap-
propriate model can be used to orchestrate respective ef- Our working definition is that “an ontology is a formal specifi-
forts and helps create a common understanding of all par- cation of a conceptualization.” As mentioned at the end of the
ticipating institutions. section on the LCIM, this definition is not aimed at the defini-
tion of an upper ontology describing everything within a possi-
• Models facilitate the identification of potential reuse of ble universe of discourse, but to describe the information ex-
existing solutions. Although every operation is special and change requirements and means for orchestration and choreog-
unique, many processes are supported by standard solu- raphy of highly agile, independently developed systems into a
tions. Additionally, when using a common model, the supported framework mediated by intelligent agents.
identification of processes supported in other operations
and that can be modified easily to support the current ef- Enabling systems to interoperate based on a merging of each
fort becomes feasible with minimal effort. system’s own ontological representation can be accomplished
by a number of different methods [32]. The method suggested
These arguments show that models play a pivotal role in gain- here is based on federating ontologies of different systems,
ing a common understanding of what processes have to be which will allow for the exchange of meaning between the
supported and which systems can help in these processes. As a different world-views that the systems each have. This method
product of this analysis, the supporting IT infrastructures, inter- is based, loosely, on the idea of federating databases, with the
faces between systems and services, and the information that nature of ontological representation addressing some improve-
needs to be exchanged are identified. ments to the method.

Therefore, the first step of phase 1 entails identification of the Federated Databases
organizations that will participate in satisfying a particular Taken as the model for federating ontological representations,
operation. This involves not only each organization, but also an we take the approach of federated databases [33]. This ap-
understanding of what each organization is contributing to the proach is applicable when there is a requirement for an outside
operation, as well as what systems the organization has to sup- system to access a single data model that is representative of a
port that contribution. The second step in this top-down ap- merging of a number of distinct data models.
proach is to construct a conceptual model of how each of the
contributing organizations will make their contribution to the Within the world of databases, this idea of created a merged
operation being discussed. Such a model will be based upon the database, based on merged data models, while allowing the
doctrine of the contributing organizations. This model is based original components to remain distinct and intact has been
on the different modeling strengths described above, as it can accepted for some time: federated databases. The objective of
result in not only a picture of what is expected to happen, but such a data federation is to merge different data sources, which
also provides a basis for showing how the different processes are – and remain – distributed, heterogeneous, and autono-
will interact with each other. This model is a conceptual model. mous.
Standard methods of systems engineering can be used in sup-
port of this task. The third and final step of phase 1 is the iden- In order to meet this objective, Sheth and Larson introduce a
tification of information exchange events between the proc- new five level architecture [33], shown in Figure 2. Every ap-
esses. While the second step resulted in conceptual models of plication has its own data view, the external schema. They are
all processes supported by each participating organization, we based however, on a so-called “federated schema” being the
are now looking at the new overarching and common processes common “data exchange” data model for all participants. Dif-
in support of the overall enterprise. In this process, the analysts ferent from the conceptual schema of distributed homogeneous
identify the conceptual data domains and data element concepts data bases, the federated schema only comprises the shared
needed to describe the information exchange necessary be- data elements, and doesn’t deal with all details of the local
tween the processes on the conceptual level. autonomous data bases.

68 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 5 ISSN: 1690-4524

 • Correctness – All concepts in the federated schema must
have either a semantically equivalent local concept or
must be a new inter-schema-relation that may not be in
External Schema 1 External Schema N
contradiction to any local schema.

Federated Schema • Minimality – Logically and semantically equal concepts

of the local schemata may be represented only once in the
Export Schema Export Schema federated schema.

Component Schema Component Schema • Understandability – The federate schema must be logical
and well documented (including semantics as well as
Local Schema Local Schema sources, constraints, mappings, etc.) to facilitate the work
of the users, as well as of the database administrators.

The problem of semantic heterogeneity was realized, in the

mid-1990s as a major problem to federated databases, in that
Figure 2: 5-Level-Architecture for Federated Databases each data base is likely to have different semantic values for
the objects it represents, and the relationships between those
objects. An overview of this problem is described in [35].
The local databases contribute to this federated schema their While this problem may have existed for federated database
part via export schemata comprising the data to be shared by instantiations, we will see below how an ontological
the local data base with other data bases. Each export schema is representation method within a federated ontology may avoid
part of a local component schema, which is a common presen- this problem, by accomodating semantic heterogenous
tation of the data elements being comprised in the local, system valuations of entities.
dependent schema. Therefore, the five levels are external, fed-
erated, export, component, and local schemata. Federated Ontologies
Taking the approach recommended for layering federated data-
The architecture shown in Figure 2 enables the evolutionary bases, the ability to federate the worldviews of multiple dis-
growing of the common data exchange model based on the tinctive ontological representations into a single ontological
actual information exchange request being formulated between representation should be possible. The approach of federating
the global applications and the local data bases. The moment, a ontologies is not a new one, and has been addressed several
new piece of data is needed in a global application; it becomes times in recent literature. One of the better known efforts was
part of the federated schema. However, the local data bases presented in [36], and proposes a layer of different ontological
don’t have to be changed as long as that piece of data is already representations similar to the way a federated database system
comprised in one of them. has a number of layered data schema.
In practice, the local schemata of the 5-level-architecture can The five layers, when applied to a federation of ontological
be interpreted as the conceptual data model of the 3-level-ar- representations, are as follows:
chitecture of the component model—the federate database.
Additionally, export schema and component schema are often • Local Ontology – This is the ontological representation of
swapped. The reason is, that it seems not to be worth to trans- each local system.
late all the tables of the local schema into the component
schema, but only the parts of the data model that have to be • Component Ontology – This is a transformed version of
used for the data to be exchanged during the federation execu- the Local Ontology, where each is represented using a
tion. similar representation method.
Generally, two concepts have to be used to implement a feder-
• Export Ontology – This is a subset of the Component
ated database:
Ontology, where only the subset of the Component Ontol-
ogy that is relevant. Federated Ontology – This is a merge
• Schema Transformation – The concept of schema of all the Export Ontologies into single ontological repre-
transformation maps two data models onto each other in a sentation that includes all aspects of the local ontologies.
semantically consistent way.
• External Ontology – This is the portion of the Federated
• Schema Integration – The concept of schema integration Ontology that might be of interest to an outside system
merges several different transformed schemata into a that might have to interact with the system of systems.
common resulting schema comprising data elements for
every piece of information that is part of at least one of the As with federated database systems, each of these layers may
original schemata. need to have the principles of integration or transformation
applied in order to derive it. In addition to integration and
As per Conrad [34], at least four rules have to be met to do the transformation, the method for arriving at both the Export On-
transformation and integration properly: tology and the External Ontology (which are possibly subsets
of, respectively the Component Ontology and the Federated
• Completeness – All concepts being comprised in one Ontology) requires a method of reducing the source ontology
local schema must be comprised in the federated schema into some subset. This represents a third principle, that of sub-
also. setting.

ISSN: 1690-4524 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 5 69

 standing being less generally defined than their parents is
For the discussion of a federated ontology, we will define these known in the knowledge representation and artificial intelli-
principles separately from how they were introduced for feder- gence communities as sub-sumption and a treatment of the
ated databases. topic can be found in [28]. The organization of all of an ontol-
ogy model’s entities into an interconnected graph is referred to
• Ontology Transformation – Transforming the ontological as a taxonomical model.
knowledge from one representation type into another. A
current approach is presented in [37]. Different entities, originating from different systems, may have
the same “name”, or symbol, representing them and have dif-
• Ontology Integration – This is commonly referred to as ferent characteristics. This leads to a situation making the en-
either merging or mapping of ontologies. A review and ablement of interoperability very difficult. Additionally, diffi-
critique of many reported techniques is presented in [38]. culties in enablement would arise when differently named enti-
ties are meant to represent the same thing from our limited
• Ontology Sub-setting – Selecting only the ontological universe of discourse. In both situations, and as hinted at
entities, attribution of those entities, and relationships, above, it can be seen that entities differ from each other based
subject to requirements of the representation method em- on their characteristics. These characteristics are defined by the
ployed, that are relevant to a sub-area of interest of the primitives of meaning that the entities can exhibit. This is dis-
original ontology representation reduced from. Ap- cussed further, below.
proaches, for selecting such a subset, are presented in [39]
based on syntactic selection, and in [40] based on seman- The type-subtype-instance relationship (of the taxonomical
tic selection. model) is not the only class of relations between entities that
can exist. Relations can provide a semantic link between enti-
The four rules of [34] – completeness, correctness, minimality, ties in any number of different ways. The enumeration of par-
and understandability – should be equally applied to Ontology ticular relation types is potentially unique for each universe of
Transformation, Integration, and Sub-setting. discourse [29].

An effort in showing how federated ontologies may be con- System-to-system interoperability requires exchange of data,
structed is presented in [36]. The approach described there is and that data (in order to move past what the LCIM refers to as
based on a series of source documents that may be relevant to Level 1) must have a syntactic form. Further, to proceed to
several (two or more) ontologies. The principles of Formal even higher levels of conceptual interoperability, semantics are
Concept Analysis are applied to produce a merged structure of required of the data interchange. In both cases, and for further
concepts from both ontologies, and then an algorithm extension, a rule set, or grammar, is required to control the
(TITANIC) is applied to reduce that combined structure to a syntax and semantics of the data exchanged. But the data
manageable new, merged ontology. within a system undergoes certain operations defined by that
system. A set of rules defining the syntax and semantics of
Ontological Entities those operations is also required.
In order to access the conceptualization that an ontology is a
formal specification of, it is necessary to break that specifica- The existence of an taxonomical model that systems can refer-
tion up into accessible components. The first three types of ence allows for the specific identification of entities referred to
components that are discussed are entities, relations and rules. during system-to-system communications [30]. A set of rules
Entities and relations are quite familiar to the data modeling can provide for a semantically meaningful method for com-
community, and also appear within most modern ontological bining those entities into communications that satisfy the sys-
engineering theories. Rules, however, are an additional compo- tem-to-system communications supporting interoperability up
nent that assists with the ontology model being useful to sys- to the semantic level. Internal relations identified among the
tems, and will be described here in more detail. A fourth com- entities of a system’s data model even allow, in effect, infer-
ponent, concepts, is essential to the other component types and ence to be made within the interoperability supporting data
will be addressed in its own section, below. exchanges between systems 3 . What is still missing from our
ontology, although it was mentioned several times above, is the
As this paper is addressing ontology of information systems, specific characterization of our entities. This characterization
and more specifically, ontology for the purpose of assisting provides for definition of our entities, and also allows for the
interoperability between information systems, entities become application of the relations and rules defined above. Primitives
quite easy to define. As they are revealed in [27], it can be seen of meaning, which are exhibited by entities, provide this char-
that they are easy to recognize within a model. Entities are the acterization.
exchangeable symbols (words, data elements, etc) that repre-
sent the things of which our systems can address. Things are Primitives of Meaning: Atomic Elements of Understanding
further defined as being not only physical things, but also eve- Primitives of meaning, or just “primitives”, are the basis for
rything, which can be addressed by systems (things, both giving entities definition and characterization. They are the
physical and otherwise; phenomena, including both processes most difficult component of the ontology to define. They are
and events; modifiers for both of these). also often difficult to see within the entities that exhibit them. It

Entities, in order to satisfy the specification presented here,

3
need to be represented as both types and instances. Entity-types Internal relations, as defined here, support inference in this way – if a
may be divided up further into subtypes, but each child of an semantic exchange of data is made referring to the entities of a
entity-type (whether a true instance, or a subtype) retains all of system, and those entities have internal relations semantically
the identity of the parent type. This idea of terms of under- linking to other entities, then the chain of related entities is affected,
via inference of the semantic links, by the semantic exchange.

70 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 5 ISSN: 1690-4524

is helpful to have a good definition of what is meant by concept ess of revealing this apparent ontology, in the same language
in order to see how the ontology model requires them. One (using the same component structure) as other systems interop-
aspect of primitives to consider during the definition of the erating with can help to identify gaps (to be filled, if possible)
term is that primitives are the only component of our ontology in conceptual support of entities exchanged, and can also assist
that exists within actual items. They are the link between a data with the assessment as to the strength of the overall system-of-
representation of an item, and the actual item itself. The con- systems is concerned.
cepts behind, for instance, a truck, and the data representation
(within an information system) of a truck are the same [31]. A definition of apparent ontology may be helpful before pro-
These concepts are what we are calling primitives. ceeding. Many of the existing systems, and systems yet to be
developed, will have been constructed without a formal ontol-
Each ontological entity has a unique collection of primitives of ogy being recorded. This does not mean that the system archi-
meaning. Within the domain that the systems in question come tects did not have an ontological view of the system’s universe
from, the primitives of meaning must be universally recognized of discourse in mind when the design was taking place. Rather,
and accepted. However, each system’s ontological representa- this ontology is inherent in the (1) data model of the system, in
tion may have a different collection of primitives that make up the (2) assumptions concerning the structure and meaning of
the various entities it entails. This gives the different morphol- that model, and in the (3) operational functions and transfor-
ogy of similarly named entities, and is where the defined dif- mations that the system makes on that data. By examining the
ference may be found between the different system’s world- data elements of the system, this apparent ontology can be
views. As each system is a different abstraction of potentially revealed, and described in an accessible artifact, so that it can
the same reality, the difference is in which primitives of assist with system-to-system interoperability.
meaning each system assumes are involved in the make up of
their ontological entities. To reveal this apparent ontology, it is helpful to begin with the
interface specification. As mentioned, this suffices as the exter-
Following this reliance on primitives of meaning, if we have an nal rules for the ontology of the system, as it provides an effec-
ontological representation method that exposes these primi- tive grammar for the system to communicate.
tives, and this representation method is used for the Ontology
Transformation between the Local Ontology and the Compo- From the interface specification, we can enumerate and codify
nent Ontology, then the federated database problem of seman- the types and possible instances of entities coming from within
tic heterogeneity should be solved. A trivial example which the system. Any semantic relations between these entities will
illustrates this point is given in Figure 3. now suggest themselves, including any hierarchical structure
(leading to an entity-model).
If the primitives, which give identity to an entity, are known,
and captured within the ontology, then regardless of any ambi- The entities of the system and their functional transformation
guities with the entity’s name (or symbol), it can still be clearly that take place within the system exhibit the properties and
identified by using exactly these concepts [31]. Similarly, property values. These characteristic properties allow for the
proper definition of the primitives that give definition to the identification of the underlying primitives of meaning. Once
entities of two different systems interoperating with each other this is accomplished, we have a partial view of the apparent
can show where there may be conceptual gaps or misalignment ontology of the system.
between those entities.
Working with the revealed apparent ontology allows us to
compare, at the concept level, the sufficiency of meaning and
depth of understanding of the exchanged entities. The enu-
ENTITIES OF “LETTER” SYSTEM ONTOLOGY

PRIMITIVES OF MEANING meration of rules and relations reveals the inferred meanings of
Entity A

A1 A1
those entities, and the operation up on those entities within the
A2 A2 system, thus revealing what may be needed in support from a
foreign system to fully support interoperability to the semantic
Entity B

B1 B1
level, and perhaps to move beyond.
B2 B2
C1 The existence of the revealed apparent ontology is itself useful
Entity C

C1
C2 for future developments of interfaces and evaluation of the
C2
soundness of combining the system with others. There is also
value, however, in the process of revealing the apparent ontol-
ogy, as it assists with evaluating the internal rules, the relations,
and the entities of the system being investigated.
A1 B1 C1 A2 B2 C2
Entity 1 Entity 2 The result of this phase is an ontological description of the
ENTITIES OF “NUMBER” SYSTEM ONTOLOGY
information exchange model derived from the common con-
ceptual model. This is more than just a data model. The onto-
Figure 3: Primitives of Meaning logical representation formally specifies the concepts regarding
their property meanings (syntax and semantics), the contexts in
which they are exchanged (pragmatics), and the business rules
Apparent Ontologies defined by Interface Specifications that need to be applied in form of axioms.
By looking at the agreed to interface specification (which have
been identified as a source for external rules, for the purposes
of the ontology definition), we can help to understand the ap-
parent ontology of a system supporting the interface. The proc-

ISSN: 1690-4524 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 5 71

 6. ONTOLGY-BASED SERVICE LANGUAGES • C-BML targets operational command and control systems,
military simulation systems, and robotics. All these do-
In principle, the ontology derived in phase 2 is sufficient to mains have domain-specific solutions, such as IEEE 1278
compose the contributing systems into a system of systems able [12] and IEEE 1516 [13] for distributed simulation sys-
to provide the IT infrastructure and services identified in the tems, but there are not many common standards. How-
conceptual model. However, in order to support the engineers ever, all systems can support web services, so XML be-
with more help, the third phase produces communication pro- comes a common basis for structuring the data, hence we
tocols and information exchange specifications applicable in support the syntactical level.
the domain of service-oriented architectures.
• C-BML identified a common information exchange refer-
In general, service-oriented architectures promise easier inte- ence data model with broad acceptance. This common ref-
gration of functionality in the form of services into operational erence model comprises all concepts identified to share
systems than is the case with interface-driven system-oriented tasks and reports, hence we support the semantic level.
approaches. However, although the Extensible Markup Lan- Tolk and Diallo [44] show how these ideas can be gener-
guage (XML) enables a new level of interoperability among ally used to not exclusively support military operations but
heterogeneous systems, XML alone does not solve all interop- other domains as well, such as complex business scenar-
erability problems users contend with when integrating services ios, traffic flow, medical emergencies, and other elements
into operational systems. In addition, XML is often managed of critical importance for decision makers.
using underlying databases, which are less ambiguous than flat
tag structures. But even when using data bases, the rules for • In the implementation depicted in Figure 2, we used open
accessing them appropriately need to be captured separately. sources and open standards to construct a web-based on-
Using an ontology as derived in phase 2 facilitates this process tology-driven service-oriented architecture for information
significantly: because all necessary information can be derived exchange and storage. In order to achieve pragmatic inter-
from one common model, the often observed inconsistencies operability, the concepts captured in the common infor-
between information exchange model and common reference mation exchange reference data model were accessible via
model is avoided. The axioms of the ontology lead to business atomic web services. Following the rules, these concepts
rules. The concepts, entities, relations, entities, and properties are combined into entities and relations of the apparent
are mapped to table and attribute definitions, which are used to ontologies of the participating systems, resulting in com-
derive the XML schema. posed web services which incorporate the business rules
and objects of the targeted systems.
The second advantage of this approach is that the information
exchange requirements are based on the information exchange The ontological constructs entities and relations are used to
capabilities of the systems. Current practice is to define an describe the information exchange requirements of the partici-
information exchange model as a common language between pating systems, in the figure referred to as systems A and B,
the services. The model resulting at the end of phase 2, how- based on the implicitly defined apparent ontologies. How they
ever, is based on the definition of exchangeable information are populated or how they disseminate information is captured
identified in phase 1. In other words: the model is by design in the construct rules. The common elements with a common
part of these systems: (a) what needs to be exchanged is part of interpretation in the universe of discourse and supporting the
this model, and (b) what is part of this model needs to be ex- decisions are modeled as concepts. All these concepts can be
changed. A simulation system specific view of this approach accessed individually, so that all every possible composition
has been published in [41]. can be generated based on the rules. In addition, commonly
accepted business object comprising of more than one concept
7. APPLICATION EXAMPLE can be defined as well.

Our application example is rooted in the idea to generate a In practice, this effort has some limitations if using a common
common language between operational entities, simulated enti- information exchange data model that is already established for
ties, and robots operating in the same application domain to operational use to exchange data between real system, as such a
generate orders and plans from planning organizations to the model usually already comes with in intended business logic to
executing entities as well as to generate reports contributing to support. In other words, we already have a couple of business
the awareness of the current developments from these entities objects that comprise more than concepts. The developer is
to the planning organization. The underlying application is the faced with mandatory fields that may be only of tangential
international Coalition Battle Management Language (C-BML) interest for his application. 4 In a perfect world, such business
effort discussed by Sudnikovich et al. [42]. Tolk et al. [43] objects are exclusively defined via rules. In practice, estab-
describe the technique used to implement the ideas. lished information exchange data models can still be applied to
model the necessary concepts as long as it is possible to insert,
The different levels of interoperability are supported by the update, and access concepts individually via atomic web ser-
application of complementary standards and processes. vices.

• C-BML uses the service-oriented architectures executed 4

on the Internet – or the military counterpart called the In military command and control systems, the timestamp and
Global Information Grid (GIG) – to exchange information origin of a report is of essential interest in order to be able to
elements. TCP/IP ensures that the elements can communi- evaluate how to use the message when contributing to the
cate with each other on the technical level. situational awareness, therefore such fields are mandatory
for the command and control domain. M&S applications
have another focus for information exchange, so that they
often not even support such fields.

72 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 5 ISSN: 1690-4524

 [7] J.A. Sokolowski, R. Mielke, “Supporting Evacuation
The next step of our research will focus on the remaining two Planning with Modeling and Simulation,” Proceedings
levels of interoperability: dynamic and conceptual. Currently, IEEE Spring Simulation Interoperability Workshop,
we are evaluating the use of UML and capturing the informa- IEEE CS Press, 2006
tion using XML Metadata Interchange (XMI) to generate the [8] F. Agrò, I. Giuliano, F.A. Montecchia,
necessary metadata. In particular when embedded into the ”A new human-dynamic simulator (Air Man) for airway
higher constructs of OMG’s Model Driven Architecture training in emergency situations,” Am J Emerg Med.
(MDA). However, the current state of our prototype only im- 2002 Sep; 20(5):495.
plements the levels up to pragmatic. Also, the use of intelligent [9] S.M. Harkrider, W.H. Lunceford, “Modeling and Simula-
software agents is under investigation and not yet a broadly tion Composability,” Proceedings Interservice/Industry
accepted idea, but it works in related domains, in particular in Training, Simulation and Education Conference
the domain of semantic web applications such as described in (I/ITSEC), 1999
Pohl [45], which is at least encouraging for the application [10] J.S. Dahmann, F. Kuhl, and R. Weatherly, “Standards for
domains dealt with in this paper. Simulation: As Simple as Possible But Not Simpler: The
High Level Architecture for Simulation,” Simulation,
8. SUMMARY Journal, Vol. 71, No. 6, 1998
[11] M.D. Petty, “Interoperability and Composability,” M&S
Our research showed that meaningful interoperability requires Curriculum of Old Dominion University: Short Course
much more than technical layers of interoperability. The LCIM Presentation, Old Dominion University, 2002
identifies the technical, syntactical, semantic, pragmatic, dy- [12] IEEE Standard Group 1278: Distributed Interactive
namic, and conceptual layers of interoperation. Ontologies Simulation (Revision 2002), IEEE CS Press
have been shown to be a potential contributor on the semantic [13] IEEE Standard Group 1516: High Level Architecture
and the pragmatic level. To what degree they can support the (Revision 2000), IEEE CS Press
dynamic and conceptual layer, however, is topic of ongoing [14] E.H. Page, R. Briggs, J.A. Tufarolo, “Toward a Family of
research. In connection with web services, first implementa- Maturity Models for the Simulation Interconnection
tions showed the potential. Problem,” Proceedings IEEE Spring Simulation Inter-
operability Workshop, IEEE CS Press, 2004
We assume that the research we are contributing to with this [15] A. Tolk, J.A. Muguira, “The Levels of Conceptual
paper will enable discussions on the objective beyond the Se- Interoperability Model (LCIM),” Proceedings IEEE Fall
mantic Web, as envisioned in [46]: Our view is that we are Simulation Interoperability Workshop, IEEE CS Press,
moving towards a “Dynamic Web,” supporting the orchestra- 2003
tion and alignment of agile components at least up to the dy- [16] C.D. Turnitsa, “Extending the Levels of Conceptual Inter-
namic layer with standardized metadata and clearly going be- operability Model,” Proceedings IEEE Summer Com-
yond the currently discussed concept of choreography based on puter Simulation Conference, IEEE CS Press, 2005
business process languages [47]. These developments will [17] B.P. Zeigler, H. Praehofer, T.G. Kim, Theory of Model-
enable us to support not only higher levels of interoperability, ing and Simulation. 2nd Edition, Academic Press, 2000
but also to contribute significantly to knowledge and awareness [18] A. Tolk, J.A. Muguira, “M&S within the Model Driven
quality within agent mediated decision support system, as envi- Architecture,” Proceedings Interservice/Industry
sioned in [1]. While this doesn’t solve the challenge of system Training, Simulation and Education Conference
0f systems engineering, as originally formulated in [48], the (I/ITSEC), 2004
work contributes to potential solutions. [19] P.K. Davis, R.H. Anderson, Improving the Composabil-
ity of Department of Defense Models and Simulations.
9. REFERENCES RAND, National Defense Research Institute Report, 2003
[20] A.A. Sousa-Poza, “Pragmatic Idealism as the Basis for
[1] G.E. Phillips-Wren and L.C. Jain (Eds.), Intelligent Deci- Understanding,” Proceedings International Conference
sion Support Systems in Agent-Mediated Environ- on Systems, Man and Cybernetics, IEEE Press, 2005
ments, Volume 115 Frontiers in Artificial Intelligence and [21] A. Tolk, S.Y. Diallo, C. Turnitsa, L.S. Winters, “Compos-
Applications, IOS Press, 2005 able M&S Web Services for Net-centric Applications,”
[2] M.D. Petty, E.W. Weisel, ”A Composability Lexicon,” Journal Defense Modeling and Simulation 3 (1):27-44,
Proceedings IEEE Spring Simulation Interoperability 2006
Workshop, IEEE CS Press, 2003 [22] GridWise Architecture Council Interoperability
[3] D.S. Alberts, R.E. Hayes, Power to the Edge, Command Framework Team, “Interoperability Context-Setting
and Control in the Information Age, CCRP press, 2003 Framework,” V1.0, July 2007
[4] M. Spiegel, P.F. Reynolds, D.C. Brogan, "A Case Study [23] P. Dobrev, O. Kalaydjiev, G. Angelova, “From Conceptual
of Model Context for Simulation Composability and Structures to Semantic Interoperability of Content,”
Reusability," Proceedings of the IEEE Winter Simula- Bookchapter in Conceptual Structures: Knowledge Ar-
tion Conference, IEEE CS Press, 2005 chitectures for Smart Applications, pp. 192-205,
[5] R. King, “Towards Conceptual Linkage of Models and Springer Verlag, 2007
Simulations,” Proceedings IEEE Fall Simulation Inter- [24] B.P. Zeigler, P.E. Hammonds, “Modeling & Simulation-
operability Workshop, IEEE CS Press, 2007 Based Data Engineering: Introducing Pragmatics into
[6] L. Yilmaz, S. Paspuletti, “Toward a Meta-Level Frame- Ontologies for Net-Centric Information Exchange,” Aca-
work for Agent-supported Interoperation of Defense demic Press, 2007
Simulations,” Journal Defense Modeling and Simula- [25] E. Morris, L. Levine, C. Meyers, P. Place, D. Pla-
tion 2 (3):161-175, 2005 kosh, “System of Systems Interoperability (SOSI),

ISSN: 1690-4524 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 5 73

 Final Report”, Software Engineering Institute, formation Enabler. Simulation Journal, Vol. 80, pp. 669-
Carnegie Mellon University, Pittsburgh, PA, 2004 680, 2004
[26] A. Tolk, “Beyond Technical Interoperability - Introducing [43] A. Tolk, S.Y. Diallo, K. Dupigny, B. Sun, C.D. Turnitsa,
a Reference Model for Measures of Merit for Coalition “A Layered Web Services Architecture to Adapt Legacy
Interoperability,” Proceedings of the Command and Systems to the Command & Control Information Ex-
Control Research and Technology Symposium, CCRP change Data Model (C2IEDM),” Proceedings ACM
Press, 2004 European Simulation Interoperability Workshop,
[27] P.P. Chen, "The Entity-Relational Model – Toward a Uni- ACM Press, 2005
fied View of Data," ACM Transactions on Database [44] A. Tolk, S.Y. Diallo, “Model-Based Data Engineering for
Systems, 1,1, pp. 9--36, March, 1976. Web Services,” IEEE Internet Computing, Vol. 9, Nr. 4,
[28] R. Brachman and J. Schmolze, “An Overview of the KL- 2005
ONE Knowledge Representation System,” Cognitive Sci- [45] J. Pohl, “The Evolution of Intelligent Computer Software
ence, 9(2): 171–216, 1985 and the Semantic Web,” Proceedings 16th International
[29] B. Smith, W. Ceusters, B. Klagges, J. Kohler, A. Kumar, Conference on Systems Research, Informatics and Cy-
J. Lomax, C. Mungall, F. Neuhaus, A. Rector, C. Rosse, bernetics; Intelligent Software Systems for the New
“Relations in biomedical ontologies,” Genome Biology, Infostructure, pp. 11-34, 2004
April 2005 [46] M. Daconta, L. Obrst K. Smith, The Semantic Web: A
[30] G. Zhang and B.P. Zeigler, "The system entity structure: Guide to the Future of XML, Web Services, and
Knowledge representation for simulation modeling and Knowledge Management, Wiley, Indianapolis, IN., 2003
design," in Artificial Intelligence, Simulation and Mod- [47] A. Tolk, “What comes after the Semantic Web – PADS
eling, L. E. Widman, K. A. Loparo, and N. R. Nielsen, Implications for the Dynamic Web,” Proceedings 20th
Eds. New York: Wiley, 1989, pp. 47-73. ACM/IEEE/SCS* Workshop on Principles of Ad-
[31] J. Sowa, “Ontology, Metadata, and Semiotics”, Published vanced and Distributed Simulation, IEEE/ACM Press,
in B. Ganter & G. W. Mineau, eds., Conceptual Struc- 2006
tures: Logical, Linguistic, and Computational Issues, [48] C. Keating, R. Rogers, R. Unal, D. Dryer, A. Sousa-Poza,
Lecture Notes in AI #1867, Springer-Verlag, Berlin, 2000, R. Safford, W. Peterson, G. Rabadi, “System of Systems
pp. 55-81 Engineering,” Engineering Management Journal Vol.
[33] Sheth, A. P., and Larson, J. A. 1990. Federated database 15 No. 3, pp. 36- September 2003
systems for managing distributed, heterogeneous and
autonomous databases. ACM Computing Surveys 22:
183-236.
[34] Conrad, S. 1997. Föderierte Datenbanksysteme. Berlin:
Springer.
[35] Colomb, R. M. 1997. Impact of Semantic Heterogeneity
on Federating Databases. The Computer Journal
40(5):235-244.
[36] Stumme, G., and Maedche, A. 2001. Ontology Merging
for Federated Ontologies on the Semantic Web. In Pro-
ceedings of the International Workshop for Foundations of
Models for Information Integration. Viterbo, Italy.
[37] Mostowfi, F., and Fotouhi, F. 2006. Improving Quality of
Ontology: An Ontology Transformation Approach. In
Proceedings of the 22nd International Conference on Data
Engineering Workshops. 61-61. Atlanta GA.
[38] Kalfoglou, Y., and Shorlemmer, M. 2003. Ontology
Mapping: The State of the Art. The Knowledge Engineer-
ing Review. 18: 1-31
[39] Chopra, S., Parikh, R., and Wassermann, R. 2000. Ap-
proximate belief revision. In Proceedings of the Work-
shop on Language, Logic and Information, 2000.
[40] Budanitsky, A., and Hirst, G. 2001. Semantic distance in
wordnet: An experimental,application-oriented evaluation
of five measures. In Proceedings of the Workshop on
WordNet and Other Lexical Resources, Pittsburgh, PA.,
2001.
[32] Kalfoglou, Y., and Shorlemmer, M. 2003. Ontology
Mapping: The State of the Art. The Knowledge Engineer-
ing Review. 18: 1-31
[41] A. Tolk, C.D. Turnitsa, “Conceptual Modeling of
Information Exchange Requirements based on Ontological
Means,” Proceedings of the IEEE Winter Simulation
Conference, IEEE CS Press, 2007
[42] W.P. Sudnikovich, J.M. Pullen, M.S. Kleiner, S.A.
CareyExtensible Battle Management Language as a Trans-

74 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 5 ISSN: 1690-4524