[Top] [All Lists]

Re: [ontolog-forum] Ontological Means for Systems Engineering

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Schiffel, Jeffrey A" <jeffrey.a.schiffel@xxxxxxxxxx>
Date: Fri, 23 Jan 2009 14:25:42 -0600
Message-id: <ECF42862FCA16D41BFA98F8C45F0955405723C82@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>



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.



-- Jeff Schiffel

Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (01)

<Prev in Thread] Current Thread [Next in Thread>