A useful analog may be James Grier Miller's model
of a human cell in which he identifies 19 kinds of "operators" within the cell.
A system consists of operands and operators
arranged 'just so' to achieve the Measure(s) of effect-iveness assigned to
the system. In contrast, Systems Engineering is
part of (ideally about 5% of) a system that generates systems.
Accordingly, systems engineering can be modeled as
an ordered set of operands (knowledge) and operators (discovery and exchange),
then, because it is performed mostly by humans, it must contain further
operators of the error detection of correction kind,
Hierarchies can be used but always decrease
parsimony and increase ambiguity. Better we should learn to think of
multi-factor transfer functions.
Soooo, for the ontology of SE-speak, what are the
equivalent of J.G. Miller's 19 operators in a human cell. 'Is-a' doesn't
suffice and 'has-a' implies personification --- robots hate that.
ps. having designed intake system for successful
race car engines I can report that the nature of the relationship among
throttle, intake valve, piston, exhaust valve and exhaust pipe shape is
best approximated by discontinous, compressible flow --- the same category of
relational that characterizes workgroups having frontal lobes. Ants
and bees are simpler.
----- Original Message -----
Sent: Wednesday, January 28, 2009 9:22
Subject: Re: [ontolog-forum] Ontological
Means for Systems Engineering
> Recall that the
original query from Andreas Tolk was the application of
systems engineering. I pointed out that systems engineering has quite a bit
with complexity and hierarchy, part of the continuous mathematics.
PatH , in
Complexity theory uses analysis, of course, but hierarchies are discrete
but this is not what I mean. An engineered system does something. It flies
through the air, or tells time, or performs other useful duties. An engineered
system has components. These are discrete structures. I do not mean, however,
that they are in a hierarchy of ?is-a? relations. They are in a composition
relation to the whole, ?part-of.? The hierarchy is found in how the parts work
an airplane or clock does something, the parts of the composition work
together. There is a process element present. An ontology for systems
engineering should take that into account. The parts work together in a
presumably planned way. The desired behavior of the system emerges from the
interactions. In complex engineering s , however, there are many
compositions. The interaction of these may be hard to predict, and there may
be undesirable and unexpected emergent behaviors.
way to understand emergent behaviors is by looking at the hierarchy of
behaviors. The tool is hierarchy theory, a subdiscipline of complexity theory.
Both are part of the continuous mathematics, of calculus. The emergent
behavior is in the dynamical system. Since a system or subsystem has
components, the services the components provide are hierarchical. The pistons
in a gas engine have no knowledge of the accelerator functions , but the accelerator sends
the pistons a command message to speed up by means of the fuel injector. The
pistons respond, but only to a point limited by the piston and drive train
design. The pistons thus constrain the accelerator , although the accelerator does not know
how it was constrained, just that its command was limited to a top
threshold. This is a hierarchy of subbehaviors that together emerge
as one behavior to move the
person driving from one location to another.
systems engineering ontology that does not take performance into account is
very limited in terms of the purpose of the system?s planned use. Another way
to look at the situation is that ontologies are static. They lay on a page.
But designing a system must take into account states and transitions, dynamic
things. I suggest that the behaviors among components are better understood if
model as hierarchies of commands and constraints.
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J