Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

SUO: Re: ontology as engineering




o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o

Pat,

Are you familiar with H.A. Simon's 'The Sciences of the Artificial'?
You appear to be echoing some themes from his general point of view,
about the differences in emphasis between the sciences of discovery
and the sciences of design, but of course neither one can thrive
without the other.  This difference in emphasis also arose very
early in the history of pragmatic philosophy, with Peirce on
the one had tending to focus on the aspect of inquiry that
has to do with the "explanation" of "surprising phenomena"
and Dewey on the other hand tending to stress the aspect
of inquiry that has do with "plans of action" that solve
a "problematic situation" -- a forerunner of GPS methods.

No, the old GPS.

These two aspects of inquiry can both be recognized as involving
different modalities of "difference":  A "surprise" that requires
an explanation amounts to a difference between ones expectation and
what is actually observed to occur, while a "problem" of the ilk that
demands a plan of action amounts to a difference between a desired or
intended state of affairs and the one that is presently observed to
prevail.  My favorite co-author and I have written about this here:

http://www.chss.montclair.edu/inquiry/fall95/awbrey.html

Jon Awbrey

o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o

Patrick Cassidy wrote:
> 
>    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
> =============================================
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o