|To:||edbark@xxxxxxxx, "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>|
|Cc:||"[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>, ontolog-forum-bounces@xxxxxxxxxxxxxxxx|
|Date:||Fri, 23 May 2008 14:34:37 -0500|
I look at these threads as an interested engineer who recognizes that theory typically represented in mathematical forms, provides a basis relevant to reality and experience, from which an engineer can create systems and understand some of the elements of the design that relate to the goals of the system in some range of operating environments. That is why I was shocked by the statement that engineers don't need theory. If one looks at the practicing journals of todays engineers there are an astounding number of applications of theoretical principles from many disciplines that an engineer will use to experiment with alternative design models.
I have always bvelieved from over 30 yeras of engineering experience, that if I could express the major operating characteristics of a design with a set of mathematic expressions that were part of a real world theory in some scientific or engineering discipline, e.g., information theory, etc., than I fully understood more about the performance envelope than could ever be discovered by testing or experimentation. The requirement of course is to have a wide range of knowledge in multiple disciplines and their respective theories, and to know when they apply to a particular design problem or goal.
One can never experiment or test sufficiently the full operating envelope of a device, and as such having a theory that explains and predicts the oeprating performance and charactieristics of a system in this envelope allows the engineer to have higher confidence that a particular design satisfyes the design operating envelope goals.
Quite frankly if an engineer is ignorant of prevailing theories related to concepts associated with his design problem and goals, than in my opinion this person is not doing engineering. If the theories for development or application of technology to create systems are not adequate to explain or predict performance to design selections that I would say that one could follow historical best practices and rules of thumb, and various persons may have different skills in these practices, this still is not engineering but again some sort of ad-hoc development with highly unpredictable results. One can only overcompensate the choices of development in this situation with the hope that the resulting operating envelope covers the desired oeprating envelope, since one does not know the relationship of the development choices with its impact on the resultant operating envelope.
In my view engineering and design entail that the engineer have an ability to predict the effects of development choices on the operating characteristics of a system and its resultant operating envelope, if you can't do that than it is not engineering but some sort of trade practice with rules of thumb handed down through the generations.
Heere are a very few domains that engineers use daily in their respective design applications
The list goes on and on and I believe that the theories for knowledge representation, reasoning about knowledge, various types of logic and inferences, and philosophical works clarifying the relationship among the various approaches to representing and reasoning about knowledge informs the engineer about the basis and expectations and constraints for the application and use of such technological standards as ontology languages in the WWW, e.g., RDF/OWL, and the limitations of XML Schemas for example. Without this grounding in the expectations of various alternatives for knowledge representation at the theoretical engineers are then only applying magic without any understanding and again they would have abrogated theri responsibility as an engineer to understand as fully as possible the ffects of tehier design choices on the operating envelope.
As an engineer I for one regard this work in knowledge representation as the next set of major tools that all system engineers should understand to be able to design systems that can incorporate and share knowedge and reason in this limited fashion about knowledge. Again as an engineer I am not interested in the wars between the various KR apporoaches, but only intersted in understanding their capabilites and limitations so that I can apply them in designs with full understanding of their impact on the resultant system operation in some operating environment.
I need more theory and better understanding of their effects in designs.
John A. Yanosy Jr.
We are not so far apart. Indeed, I found most of your response
consistent with my own beliefs. But, to some extent, we are talking
past each other. So I am trying to sort out the issues.
> There is nothing worse than bad philosophy. But it's impossible
> to do good ontology without having a good sense for philosophy.
I would only observe that there is a difference between "having a good
sense for philosophy" and having an education in the classical
philosophical treatises and the deep understanding of the complexities
that is needed to be a "philosopher". "Having a good sense for
philosophy" may just be the recognition that all of "knowledge" is
belief based on something -- observations, theory, reasoning, doctrine,
Philosophies are also theories designed to explain observations. For a
scientist or engineer, one of the hallmarks of "having a good sense for
philosophy" is knowing when to stop the debate. The debate must end
when the bases for belief are incomparable.
And I take issue with the idea that "knowledge engineers" need to be
steeped in philosophical theory in order to build useful "ontologies".
Their job is to model belief -- the beliefs of the target user and
application community, not truth. An ontology that supports Creationist
theory isn't going to be consistent with an ontology that supports
Darwinian theory, or many others, but it doesn't have to be. And
whether an ontology that supports financial planning or intelligence
gathering has to be based on certain philosophical principles is not
clear, because the beliefs of the target community may not be. There is
a big difference between consistency with first-order logic and
consistency with (other) philosophical theories. (Cogito, ergo confusus
> There is no sharp distinction between science and
> engineering, and the best practitioners of both have a strong
> feeling for the other.
I think there is an important, if not very sharp, distinction:
Science is about observing and devising theory to explain the
observations. Engineering is about observing and using observations
and/or theory in the development of practice and the design of devices.
And the best practitioners of both must be good at making observations,
at using and questioning the observations of others, and at reasoning
inductively and deductively from those observations. That is, both
disciplines are deeply involved in understanding What is true of things,
and How they know that. And there are scientists who spend much time,
and sometimes achieve significant engineering advances, devising
mechanisms for making observations -- an engineering discipline in the
pursuit of science. (It is in fact what NIST does.)
My original point, in contrast to Len's, was only that engineering does
not require theory. Engineering can proceed by inducing what practices
work, or by borrowing that knowledge and enhancing it by experiment,
without knowing Why. Engineering can proceed more rapidly and
effectively if we know Why; but it can also proceed by knowing only What
and How. And it has done the latter for five millenia.
By comparison, a primary objective of science, and *the* primary
objective of philosophy, is to develop theory, to understand Why. When
science goes beyond observation, it is about the development of theory.
One certainly doesn't want engineering practice to conflict with
available scientific theory (although it does from time to time). But
where there is no theory, engineering can proceed on the basis of
observation. And historically, a goad for scientific research has been
the effectiveness of engineering practices in areas in which no
supporting theory exists.
> EB> The trick is to recognize which expertise is needed when and
> > apply it properly.
> I agree. But it is impossible to have a fixed methodology for
> doing truly revolutionary research.
Indeed, but it is possible to have a "nearly fixed" methodology for
performing scientific observation, and many scientists spend their
entire careers doing just that. You don't have to have a theory named
after you to make a major contribution.
And in the same way, it is possible to have a "nearly fixed" methodology
for doing effective engineering. Many engineering problems do not
require major new insights; they just require analysis of the problem
space (observation) and the application of accepted principles to the
design of solutions.
Like revolutionary science, truly revolutionary engineering also
requires the engineer to "think outside the box", to make less clearly
related observations, and to apply to the development of a solution
theory and knowledge that is not commonly perceived to be related. But
truly revolutionary engineering, and truly revolutionary science, are
the rarae aves of both disciplines.
> However, there is an effective way to stifle creativity:
> Define and enforce sharp boundaries between disciplines.
Of course. But we are not talking about enforcing boundaries, or at
least I wasn't. I was talking about defining the nature of a
discipline. You as an individual can act in multiple disciplines, as
long as you are aware of the knowledge and behavior requirements each
imposes. But a lot of would-be revolutionaries ignore the requirements
of their discipline(s), and therefore have none.
What you say, John, is very wise, but it is also precisely the kind of
wisdom-as-sound-byte that will be perverted by the ignorant to foolish
ends. And in software engineering, which to my mind includes knowledge
engineering, the ignorant and undisciplined are abundant.
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority."
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
_________________________________________________________________ Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/ Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (01)
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [ontolog-forum] Data Models v. Ontologies (again), Len Yabloko|
|Next by Date:||Re: [ontolog-forum] Data Models v. Ontologies (again), Ed Barkmeyer|
|Previous by Thread:||Re: [ontolog-forum] Data Models v. Ontologies (again), Ed Barkmeyer|
|Next by Thread:||Re: [ontolog-forum] Data Models v. Ontologies (again), Ed Barkmeyer|
|Indexes:||[Date] [Thread] [Top] [All Lists]|