SUO: *Date 03 Mar 2002 -- Monoliths & Mélanges
¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤
*WARS (Wholly Apriori Religious Systems)
JB = John Bateman
JS = John Sowa
PC = Pat Cassidy
I would like to follow up on the following exchange,
because it, along with the monolithic animadversion
that ensued upon it, resonate with issues that I've
been struggling to address here for quite some time.
JB: Any construction in this area is going to be theory-laden:
perhaps a further argument against the one-top-ontology-fits-all?
Although I belong to the "nice it's there" camp rather than the
"no use trying" one!
JS: Let me also emphasize that I belong to the "nice it's there" camp.
My paper on negotiation instead of legislation is not a protest against
building ontological resources, but against the idea that any one of them
(or even any collection of them) should be considered an official standard.
And it's more than a protest -- it's also my proposal for how multiple
resources (including legacy systems) can be accommodated.
JS: The term "theory laden" has been popular in linguistic circles,
since there have been many famous "linguistic wars" over theories
in the past 50 years. But that same term applies to any and every
field of science, engineering, business, and the arts -- and we
certainly don't want to exclude religion, which is famous for
its "religious wars".
JS: This raises the question of what we can standardize if
we are not standardizing content. The answer is form:
we should be focusing on formal ways of organizing all
the ontological resources that are available, including
SUMO, OpenCyc, IMPS, WordNet, EDR, etc.
JS: IFF is an effort in that direction, but it has not been tested on
actual content and applications. Having at least two rich content
ontologies, such as OpenCyc and SUMO, should bring to the fore the
question of how they can be mixed, matched, and used together.
JS: I would like to open up all the other sources
of content for consideration in this mélange.
When I am cool enough to think straight about it, I think of the task
before us as yet another programming problem, and my programming layer
is laid on top of a mathematical layer, in the mesoderm of which I first
learned to think of all proper programs as having the structure of proofs,
in particular, proofs by mathematical induction, that computeresians taught
me to call "recursion".
A recursive analysis of a task, or stepwise refinement, naturally involves,
if one is lucky, discovering the natural modularities of the task, and yet
there remain the stickier wickets of gley, glia, gluons, gluten, glycogens,
whatever, and the thornier thickets of entanglements that we all know and
try to deny that we do. I once encoded the things that come to mind in
this connection under the theme of "entanglement versus encapsulation",
and some of that is pertinent here, as I may get around to explaining.
But first, a recurrent personal note. It's a funny thing, I suppose,
but no matter how often one says that one believes that progress in
a particular task is possible, just not in a particular direction,
others who are dead set on that direction will tend to hear it as
a denial of the possibility of progress in general. Let us then
recognize this as what is often called a "persistent phenomenon".
I see now that some of the misunderstanding is my own fault,
so let me start up a stepwise clarification of what I meant.
When I advise against trying to progress further in a particular direction,
I see that what I sometimes mean is that no "further" progress is possible
in this direction, in other words, that our efforts in this direction are
not being demanded by any potential user group, or needed by any community,
discipline, or society, and would be utterly redundant for us to try doing,
since the affected interest groups already do a much better job of it than
we can hope to match, short of our learning their own ways of doing the job.
Concreteness. When I try to think of what is really needed here,
my mind goes back to the diverse practical and research settings
in which I had occasion to work as a statistical and data-debased
adjunct consultant, and it hits me that none of these clienteles
ever once requested me to create a taxonomy for them, either out
of my own fervent imagination, as appears to be the fashion among
ontologists today, or even otherwise. They already had their own
taxonomies, thank you very much, most of them 10^k for k in [1, 4]
years in the making. But the lion's share of the discussions that
get carried on in this forum appear to be oblivious to these basic
facts, as if we even had the option of dictating our legislated or
negotiated ontologies to any real-live constituency of proletarian
subject masses of actual practitioners who we omit to invite to the
negotiations and do not welcome all that warmly when they do show up
uninvited. And so when it comes to our brand of domain-non-descript
standardly uppity otiosology, they will undoubtedly return the favor,
asking "What the heck for?"
And yet these prole practitioners that I used to work with would have
genuinely appreciated a few billions bits of really apt and generic
siftware that could be used to soak up their customary taxonomies
and put them to work in yet to be heard of new ways, and I can
even still remember the day when I finally saw this and said
to myself "Okay, then I will work on that".
Another thing for which the practitioners in these settings seemed to
have a crying need, as I can say with some assurance on account of the
fact that they would frequently come to cry on my statistical shoulders
about it, was any manner of more methodical, routinized, and computerized
ways of passing from that raw-in-tooth-and-claw qualitative experience of
their practice and research domains with which their workaday lives were
embarassingly rich, and well past the point of being distressingly and
overwhelmingly rich, to any sort of formalized reach, and dare to hope
some sort of measurable and quantifiable grasp of the patterns of data
whose potentials for knowledge they clearly glimpsed or dimly glommed.
For the sake of future reference let me code these two needs as follows:
1. Concept Processors. These are preferably delivered "content free",
if you please, unless you are the sort of person who actually uses
that gagabyte worth of clip-art that came with your word processor.
Perhaps I need to mention that my concept of a concept is how most
folks conceived it from the beginning, as a kind of sign or symbol.
Cf. http://suo.ieee.org/ontology/msg03799.html
2. Bridge Over The River Qua. That is to say, a software bridge over
the troubled waters between qualitative and quantitative datatypes.
As long as I'm codifying hard-won experiences, let me just mention that
there is one type of thing that we definitely do not need any more of,
and that nobody out there needs or wants any more of:
3. "Expert Systems Sans Experts" (ESSE's).
After all, that's what we have governments for.
The concrete practical experiences to which I refer are now
more than a dozen years ago, and I really have learned one
or two things about the things that just won't work, and
that is on top of all those things that I learned about
what won't work in the effort to motorize mathematics,
and I even dare to imagine that I know one or two of
the reasons why.
It all comes round to the programming, surprisingly or not,
and the "minimally adequate data structures" that it takes
to do any task moderately well, for example, the tasks of
intercomm or interops. And what I have learned here is
that a certain class of of 3-adic relations, who shall
rename anonumous for now, is the minimum complexity of
structs that will even come close to carrying the day.
This is not just an empirical fact, learned through
hard knocks in the way that we always seem to learn
things first, but nigh unto a mathematical fact,
once you carry out the requisite task analysis
to a point of formal precision.
And it really is possible to see the light of the reasons for this,
once you get the stars out of your eyes that come from banging your
heads on that darned old megamonolithic block in the way of inquiry.
There are reasons why name-spaces and prefix-trees will fail at this task.
The fact that they fail is already a matter of empirical fact for folks
with the relevant experience. And yet, as always transpires at times
of paradigm transition, many more people actually have the relevant
experience than realize they do, for lack of recognizing what the
pattern of their experience is urging them to see. Such is the
power of a prior belief system, a paradigm, a myth, a dream.
For my part, I call it "Aristotle's Fable On Interpretation".
Just between pragmatic thinkers of a Peircean persuasion
this would all seem pretty obvious. Thought takes place
in signs, and signs can only make the sense that they do
in the context of specific sign relations, and these are
tantamount to 3-column relational data tables, so there,
that's the "minimal adequate data structure" (MADS) that
it takes to have any intelligence, artificial or natural.
Of course, the proof of this self-evident truth is a bit
more excruciating among the unenlightened, pragmatically
speaking. But granted that, from a formal point of view
communication among several interpreters is not all that
different, isomorphically speaking, from the various and
sundry forms of autodialogue that constitute the thought
of supposedly isolated interpreters. Altogether then it
is inescapable that 3-adic relations of a signal variety
form the irreducible core of all information interchange.
I would also like to consider the following bit of discussion:
PC: I can easily imagine agreement on a monolithic "terminological" ontology,
which contains every concept that anyone would want to work with, defined
in consistent terms.
JS: I agree with Leo that the naming scheme for the predicates in any
precisely formalized ontology will have to use rather long names.
An alternative, which I believe is preferable, is to use short names
that are prefixed with the name of the theory in which they are used.
For example, there might be a predicate (or concept type) "time",
which is used in multiple theories with only a four-letter name.
But when it is necessary to distinguish the exact predicate or type,
the name of the theory could be prefixed to it:
realLine.time
integerLine.time
realLineWithPointsAndIntervals.time
JS: Within a theory, the short name could be used, but the fully
concatenated name would have to be used in global references.
Maybe this would work if theoretical contexts were like rooms, in which
the people come and go, never setting autopoetic feet in any two parlers
at one and the same existential.moment.of.interpretive.time, but we know
that this prufrockian fantasy is not how the rest of us live our lives,
always stacking more haceks on our heads at once than all the world's
arche.type.set.in.their.way orthographies can barely contemplate.
Try to imagine the shape and the size of the index tree that it
would take to resolve the ambiguity of that one little sign "I".
It is supposed to mean something like "the one signifying", but
that is just a circumlocution with precisely the same degree of
ambiguity as the initial "I", or else it would not be its equal
at all, now would it? So we need an index tree with one branch
out of the root for each conceivable signifier, speaker, writer,
whatever. A thorny thicket indeed!
A great number of the proposals that are being tossed out for our
entertainment here have long and maculate histories. And most of
them are done in by well-known types of computational fallacies,
of the sort that we might call the "already been computed" (ABC)
or the "oracle invoking" (OI) congames. Maybe I can clue you
to a notion of these shell-games by means of this bit of yarn:
A contractor engages a subcontractor to design and program
a "language adept front end" (LAFE) for their established
application programming interface. Of course, the subcon
requests a million dollars up front to study the problem,
then comes back in a year or two saying that they can do
it if the contractor can just do a bit of preprocessing
on the input supplied, or gathered from the end users.
And just of much of course, of course, it turns out
that the little bit of preprocessing is actually
informationally equivalent, perhaps in disguise,
to a solution of the subcontracted problem.
Bottom line: The contractor goes bust.
Jon Awbrey
¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤