[Inquiry] Re: Introduction to Inquiry Driven Systems

[Jon Awbrey]

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

INT.  Note 7

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

1.3.  Model of Inquiry (concl.)

There are many well-reasoned and well-respected paradigms
for the study of learning and reasoning, any one of which
I might have chosen as a blueprint for the architecture of
inquiry.  The model of inquiry that works best for me is one
with a solid standing in the philosophy of science and whose
origins are entwined with the very beginnings of symbolic logic.
Its practical applications to education and social issues have
been studied in depth, and aspects of it have received attention
in the AI literature (Refs. 1-8).  This is the pragmatic model of
inquiry, formulated by C.S. Peirce from his lifelong investigations
of classical logic and experimental reasoning.  For my purposes, all
this certification means is that the model has survived many years of
hard-knocks testing, and is therefore a good candidate for further trial.
Since we are still near the beginning of efforts to computerize inquiry,
it is not necessary to prove that this is the best of all possible models.
At this early stage, any good ideas would help.

My purpose in looking to the practical arena of inquiry and to its
associated literature is to extract a body of tasks in real demand
and to start with a stock of plausible suggestions for ways to meet
these requirements.  Some of what we find depicted in contemporary
pictures of learning and reasoning may turn out to be inconsistent
postulations or unrealizable projections, beyond the scope of our
present or any possible technology.  But this is the very sort of
thing that we should be interested in finding out!  It is one of
the benefits of submitting theories to trial by computer that we
obtain just this brand of knowledge.  Of course, the fact that
no one can presently find a way to make a concept effectively
computable does not in itself prove that it is unworkable,
but it does place the idea in a different class.

This should be enough to say about why we sometimes need to cite the terms
and to critically reflect on the concepts of other fields in the process of
doing work within the disciplines of systems theory and software engineering.
To sum it up, it is not a question of entering another field or absorbing its
materials, but of finding a good standpoint on our own grounds from which to
tackle the problems that the outside world presents.

Sorting out which procedures are effective in inquiry and finding out which
functions are feasible to implement is a job that we can do better in the
hard light demanded by formalized programs.  But there is nothing wrong
in principle with a top-down approach, so long as we do come down.
I will follow the analogy of a recursive program that progresses
down steps to its base, stepwise refining the details of the
higher-level specifications.  One of the best reinforcements
for such a program is to maintain a parallel effort that
builds up competencies from fundamental rudiments.

Jon Awbrey

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