[Inquiry] Re: Introduction to Inquiry Driven Systems

[Jon Awbrey]

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

INT.  Note 5

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

1.2.  Initial Approach (concl.)

There are several implications of my approach that I need to emphasize.
Many distractions can be avoided if we guide our approach by the two
questions that were raised above, of principles and extensions, and
if we guard against confounding what they ask with what they do not
ask.  The issues that surround these points, concerning the actual
nature and the possible nurture of the  capacity for inquiry, will
be taken up shortly.  But first I need to deal with a preliminary
source of confusion.  This arises from the two vocabularies, the
language of the application domain, which talks about higher order
functions and intentions of software users, and the language of the
resource domain, which describes the primitive computational elements
to which software designers must try to reduce the problem.  We are
forced to use, or at least to mention, both of these terminologies
in our effort to bridge the gap between them, but each of these
languages plays a different role in the work.

In studies of formal specifications the designations "reduced language"
and "reducing language" are often used to discuss the two roles that are
encountered here, that of the "application", "practice", or "target" domain,
on the one hand, and that of the "base", "method", or "(re)source" domain,
on the other.  I will be using all of these terms, with the following two
qualifications.

First, I must note a trivial caution.  Our sense of "source" and "target"
will often get switched depending on our direction of work.  Furthermore,
these words are reserved in category theory to refer to the domain and
the codomain of an "arrow", that is, a function, a mapping, a morphism,
or a transformation.  This will limit their use in the above sense to
the more informal contexts.

Now, I must deal with a more substantive issue.  In attempting to automate
a fraction of such grand capacities as intelligence and inquiry, it is seldom
that we totally succeed in reducing one domain to the other.  The reduction
attempt will usually result in our saying something like this:  that we have
reduced the capacity A in the application domain to the sum of the capacity B
in our base domain plus some residue C of unanalyzed abilities that must be
called in from outside the basic set.  The residual abilities will then be
assigned to the human side of the interface, that is, attributed to the
conscious observation, common sense, or creative ingenuity of users and
programmers.  In the theory of recursive functions, we would say that A
is "relatively computable", given an "oracle" for C.  For this reason,
I will often speak of "relating" a task to a method, rather than fully
"reducing" it.  A measure of initial success is often achieved when we
can relate or connect an application task to a basic method, long before
we can completely reduce one set of them to the other.  The catch will
always be whether the basic set of resources has already been implemented,
or is just being promised, and whether the residual ability has a lower
complexity than the original task, or is actually more difficult.

Jon Awbrey

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