Re: [ontolog-forum] Data Models v. Ontologies (again)

[jayanosy@xxxxxxxxxxxxxxxxxxx]

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

1. Fourier Transforms
2. Feedback controls system theories
3. information theory
4. probability theory
5. sample data theory
6. statistical analysis
7. thermodynamics
8. optimization theory
9. electrical circuit theories (Kirchoff, Ohm's law, etc.)
10. graph theory
11. group theory

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. 

Best Regards,
John A. Yanosy Jr.

Cell: 214-336-9875
PH: 972-705-1807
Email: JAYANOSY@xxxxxxxxxxxxxxxxxxx

Ed Barkmeyer <edbark@xxxxxxxx>
Sent by: ontolog-forum-bounces@xxxxxxxxxxxxxxxx

05/23/2008 11:50 AM

Please respond to
edbark@xxxxxxxx; Please respond to
"[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>

To	"John F. Sowa" <sowa@xxxxxxxxxxx>
cc	"[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
Subject	Re: [ontolog-forum] Data Models v. Ontologies (again)

John,

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.

you wrote:

> 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,
contemplation.

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
sum.)

>  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.

-Ed

-- 
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/  
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
 

_________________________________________________________________
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)