Andreas,
In the original
posting in this thread, you wrote that “Ontologies provide the means to describe
the systems, its components, functions, and even constraints in form of
concepts, entities, relations, and axioms,” and that because ontologies are
machine understandable they can be used to analyze, model, or even synchronize
separate systems execution to achieve a common
goal.
A series of
postings followed, mainly waltzing around the idea of just what a system might
be – animal, vegetable, or mineral. Even Bertalanffy, a founder of general
systems theory, offered a wide-open
definition as “A set of interrelated elements in a single domain that together
exhibit behaviors.” His definition
provides a springboard for thinking about and solving complicated
problems about a set of interrelated elements that together have a systems
behavior. General systems theory may help in analyzing and constructing models
regardless of domain, or of system of systems models involving several
domains. Even though I believe you have
engineered systems in mind, the study of other kinds, such as biological
systems, yield ideas for use. After all, general systems theory is an outgrowth
of mathematical biology from the 1930s.
A system is
smaller than the world. A system of systems is still very small compared to the
world. They each have a known number of interacting parts. But the nature
of the interactions is perhaps limits how ontologies in the usual
sense can be used. The limitation is that ontologies are based in discrete
mathematics. Systems are not. Notions of continuous mathematics over the
continuum, such as found in real analysis, are also required in systems
analysis.
I am thinking
primarily of the hierarchical nature of systems and their subsystems.
Appreciating interactions requires hierarchy theory, itself a specialty of
complexity theory. What happens when systems execute is that unexpected
behaviors may arise. These may be good, or may be adverse. Emergent behavior can
be modeled, and adverse emergent behavior can be predicted and eliminated (to
some extent, anyway) through the analysis of the
hierarchies.
In short, to be
very useful, ontologies in systems engineering must factor in the notion of
hierarchy and emergent behaviors. Emergent behaviors and most system failures
occur at interfaces. (In fact, at one point in the system lifecyle, systems engineers might be called interface
engineers.) This means that a systems engineering ontology for any domain must
include hierarchy and behavior as components, in
addition to the usually identified system components.
BTW, you
mentioned that you teach DoDAF and Zachman in your classes. The Zachman
framework addresses hierarchy. While it does not provide much guidance on
applying hierarchy theory, at least it has
a structure is in place. DoDAF is intended to address commonality, but is
weak in hierarchy. The TOGAF, however, incorporates Zachman ideas.