Re: an example ontology

Robert Neches <neches@ISI.EDU>
Message-id: <199208250348.AA13430@quark.isi.edu>
To: davis@ai.mit.edu (Randall Davis)
Cc: Gruber@sumex-aim.stanford.edu, srkb@ISI.EDU, neches@ISI.EDU
Reply-To: neches@ISI.EDU
Subject: Re: an example ontology 
In-reply-to: Your message of Mon, 24 Aug 92 18:28:06 -0400.
             <9208242228.AA06792@hatcher.ai.mit.edu> 
Date: Mon, 24 Aug 92 20:47:41 PDT
From: Robert Neches <neches@ISI.EDU>


> The main point is that there is a significant amount of genuine complexity in
> the world, complexity of the form that confounds attempts to write neat
> definitions and universally quantified rules.  We ignore that complexity at
> our peril....

> It's absolutely crucial: otherwise this is an exercise in the definitions we
> can write, not a exercise in finding out what we need to say; an exercise in
> what our current KR languages permit or make easy, not an exercise in finding
> out what we need to say.  Knowledge representation needs to be about the
> world, and the world as it is, not as we wish it would be.

Very good point.

It's critical to strike a balance between ignoring complexity and getting
swamped in it.  My personal view it that the way to do so is to focus on
ontologizing that facilitates merging software into larger units.  My argument
is that building more broadly functional systems is useful.  The models
underlying each of the individual to-be-merged modules may well ignore some
real-world complexity.  However, if those modules are useful, then clearly
their underlying ontologies were at least complex enough to be useful.  A
merged system therefore will face at least some complexity issues (since the
lower bound of its complexity is the complexity of its components' models and
the upper bound is the complexity of the interactions between those models).

Thus, as a strategy, taking this focus lets us incrementally bite off a bit
more complex situations, without necessarily biting off more than we can chew. 
And, the strategy of using ontologies to help compose bigger useful systems out
of smaller useful ones has the effect of focusing attention on building bigger
useful systems -- which strikes me as a nice thing.

This is the strategy we're taking in the MASTERMIND user interface ontology,
which we're trying to develop by analyzing the models (some explicit, some
implicit) in existing, separate pieces of software currently in use at ISI and
Georgia Tech.

It seems to me to characterize the strategy being followed in the PACT work,
although someone from that effort could speak to the point better than I.

It also seems to me to characterize the approach that at least some folks
(e.g., Bill Birmingham and friends) are taking on problem solving methods
models.

I don't claim that this is the only approach that can be taken to balancing
between the risk of ignoring complexity and the risk of endless modeling for its
own sake.  However, I would like to offer it for consideration as one strategy
for dealing with these concerns.

  -- Bob

======================================================================
                            Robert Neches
     USC/ISI, 4676 Admiralty Way, Marina del Rey, CA 90292 USA
                Phone: 310/822-1511, Fax: 310/823-6714
======================================================================