Jon Awbrey
Registered: Feb 2004
Posts: 551 |
Introduction to Inquiry Driven Systems
INTRO. Note 5
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 in practice.
Jon Awbrey
Last edited by Jon Awbrey on 11-07-2004 at 09:48 PM
Report this post to a moderator | IP: Logged
|