Re: SUO: RE: ontology as engineering
The kind of ontology-building I am familiar with
is much closer in spirit to engineering than to
science. In many engineering projects there are
indeed some aspects of science -- applied science.
But the basic approach is different. My view:
SCIENCE:
(1) observe a phenomenon of nature
(2) generate a hypothesis to explain the
phenomenon in terms that will allow prediction
and testing of hypotheses
(3) set up an experiment to test the hypothesis.
ENGINEERING:
(1) observe a need for an artifact to do something useful
(2) generate a hypothesis for the structure of an
artifact that will perform the task
(3) build the artifact hypothesized
(4) test the artifact to see if it does the job.
In both cases, the hypothesis may fail and the
hypothesis may be scrapped completely or revised
to take the testing results into account.
John Sowa suggested that categorizing ontology
vis-a-vis science/engineering may not be a fruitful
activity:
===============================
John F. Sowa wrote:
> Bill, Julian, Jon, et al.,
>
> I don't think that we disagree. I didn't want to get pushed
> into making a hard and fast claim that ontology *is* a science,
> as opposed to anything else that one might call it. And for
> that matter, the term "science" is so broad that it gets applied
> to a lot of dubious cases, such as "military science".
>
> What I mainly wanted to claim is that there are scientific
> principles of gathering evidence and testing hypotheses against
> the evidence that can be applied to ontology. I also believe
> that a great deal of the evidence for the kinds of things that
> exist is the primary job of the specialized sciences, and
> ontologists can make reference to that work.
>
> There is also a lot of engineering involved in the choice of
> representations that can facilitate reasoning, even though
> such choices might be neutral with regard to what exists.
>
> And finally, there is an enormous role for mathematics, logic,
> linguistics, and philosophy -- as we have argued ad nauseam.
>
> Bottom line: I think we should recognize all these influences,
> but I'd rather not get hung up on exactly where we should put
> ontology in the pantheon of academic disciplines.
>
> John
>
=============================
There are, however, several characteristics of engineering
projects that are relevant to our goals here, and may provide
us with some clues on how to proceed:
(1) In order to build a complex artifact with many interacting parts,
(e.g. a computational ontology) one needs a centrally organized
and tightly coordinated team with a well-defined set of tasks
and a schedule
(2) one needs the participants to spend serious time on the project,
which means it needs to be funded
(3) you can guarantee failure in any project by providing less than
the minimum required funding (or time)
==============================
Since this group is (a) not centrally coordinated, and (b) is not
funded (except for the implicit self-funding of participants
contributing their time), it follows that
==> We have a very slim chance of success, unless:
(c) we somehow find a method to coordinate so as to mimic the
methods of successful engineering projects.
===========================
Recommendations:
(1) We break the task into units that can reasonably be tackled
in a short time.
(2) have working groups focus intently on those units
(3) resist, *resist*, **resist** the powerful urge to
break away from the original topic in each working group
to spend time and energy on related but not central issues;
Complete one task before proceeding to another.
If we can muster the discipline and self-control to focus on the
actual unit tasks, I think we may yet succeed in spite of the
heavy odds against us.
Part 4 of the engineering methodology also suggests one important
task we have yet to begin work on: a way to actually **test** the
artifact we are building for suitability to task. I would like
to begin discussions with others who are willing to try to find,
build, or modify an application that will use an upper ontology
in a non-trivial way so that we can actually test the structures
we are creating. Send me a note directly, or post to the list
as you wish. The OpenCyc may be one starting point.
Pat
=============================================
Patrick Cassidy
MICRA, Inc. || (908) 561-3416
735 Belvidere Ave. || (908) 668-5252 (if no answer)
Plainfield, NJ 07062-2054 || (908) 668-5904 (fax)
internet: cassidy@micra.com
=============================================