Lewis Johnson position paper
Tom Gruber <Gruber@sumex-aim.stanford.edu>
Full-Name: Tom Gruber
Message-id: <2878500015-6072101@KSL-Mac-69>
Date: Wed, 20 Mar 91 15:20:15 PST
From: Tom Gruber <Gruber@sumex-aim.stanford.edu>
To: Shared KB working group <srkb@isi.edu>
Subject: Lewis Johnson position paper
\documentstyle[11pt]{article}
\addtolength{\topmargin}{-0.9in}
\addtolength{\oddsidemargin}{-0.75in}
\addtolength{\evensidemargin}{-0.75in}
\addtolength{\textwidth}{1.5in}
\addtolength{\textheight}{1.5in}
\title{Supporting Multiple Models, Users, and Formalisms}
\author{W. Lewis Johnson \\
USC / Information Sciences Institute \\
{\sf johnson@isi.edu}}
\begin{document}
\maketitle
We are developing an environment called {\sc Aries} for the
acquisition of software requirements specifications. It is
designed to support a new approach to requirements analysis,
that views it as primarily a knowledge representation and
acquisition problem. Using {\sc Aries}, analysts develop
executable models of domains, and of systems; requirements
are expressed in terms of these models. Facilities are
provided to allow analysts to reuse existing models in the
{\sc Aries} knowledge base, develop new models, and reconcile
differences between models.
{\sc Aries} is intended to be used as follows. Supppose that a
group of analysts is assigned the task of defining
requirements for an air traffic control system. First, they
identify different concerns that will have to be addressed,
e.g., radar performance requirements and flight plan
processing requirements, and assign these concerns to
different project members. The analysts make a first pass
at defining common terminology to be used throughout the
project. {\sc Aries} is assumed to already contain an extensive
knowledge base of generic and domain-specific concepts,
which can be reused and adapted to develop the project
knowledge base. Each analyst can then go off and explore
their assigned areas of concern. In so doing, they develop
their own models for their individual purposes, and define
requirements in terms of these models. They may also work
with different notations, e.g., state transition and process
diagrams, flow diagrams, type taxonomies, and temporal
logic. Models expressed in these various notations are
gradually integrated into the common project knowledge base, and
discrepancies between models are reconciled.
{\sc Aries} provides automated assistance for retrieval from the
shared knowledge base, model construction and adaptation,
and reconciliation of different views, expressed in
different notations.
\section{Knowledge sharing issues}
We are tackling a number of problems related to the problem
of knowledge sharing and reuse. First, we must support
multiple models of concepts. The form of represented
knowledge depends upon the intended use of that knowledge,
and {\sc Aries} users inevitably use concepts for different
purposes. For example, when monitoring the progress of a
flight it is sufficient to model a flight plan as a sequence
of flight segments, each along a straight line. When
defining radar tracking systems, it is important to model
aircraft maneuvers in detail, in order to predict the
position of the aircraft at the next point in time; the
overall flight plan of the aircraft is unimportant.
Second, models must be adaptable. This is implied
by the previous point. Analysts will need to specialize
general models to their particular concerns; they also
will need to adapt reusable knowledge to remove assumptions
that turn out to be unwarranted.
Two techniques in {\sc Aries} are designed to support multiple
models and model adaptation. We have developed a construct
called the {\em folder} for organizing information in the
knowledge base, somewhat similar to the microtheories of
Cyc. Folders encapsulate related concept definitions, and
are organized in a lattice. Alternative models of concepts
are stored in separate folders. Folders may be chosen based
upon the amount of detail they model; for example, we have
one folder which models aircraft maneuvers as proceeding
continuously over time, and another that models them as
instantaneous changes in heading. They may also be chosen
according to context in which the concept will be used; for
example, we have a general folder modeling direction, and
more specialized one used for navigation. Analysts
organize their work into private folders which inherit from
reusable folders. {\sc Aries} provides automated assistance to
find relevant folders and indicate where choices between
alternative models may be made.
{\em Evolution transformations} are used to adapt models and
representations. Evolution transformations make systematic
changes to domain models and specifications, changing
semantics along some dimensions and leaving other dimensions
unchanged. The following dimensions may be transformed:
\begin{itemize}
\item the modular organization of the specification, i.e., which concepts are
components of which folders, and which folders inherit from which
folders,
\item the entity-relationship model defined in the specification, i.e., for
each type what relations may hold for it, what attributes it can have,
what generalizations and specializations are defined, and what instances
are known,
\item information flow links, indicating for each process or event what
external information it accesses, what facts about the world it may
change, and what values are computed and supplied,
\item control flow links, indicating what process steps must follow a given
process step and what process steps are substeps of a given process
step,
\item state description links, associating statements and events,
on one hand, with preconditions and postconditions that must
hold in the states before and after execution, respectively.
\end{itemize}
Some of these dimensions are of relevance primarily to
specifications of systems and their behavior; others apply
to any knowledge representation activity.
Another knowledge sharing issue is support for multiple
notations. This arises in our work in two ways. First, we
need to be able to interchange knowledge representations
with other systems. The {\sc Aries} system is implemented in AP5,
but makes use of the {\sc Penman} Upper Model represented in LOOM,
and it outputs specifications to the KBSA Concept
Demonstration system implemented in Refine. Second, {\sc Aries}
allows analysts to describe systems using a variety of
notations; it has to be able to present system descriptions
in different notations from the ones they were entered in.
In order to accomodate multiple notations, we developed
an internal representation that is independent of the
surface notations used. This internal representation
embodies a common ontology of entities, relationships,
and events compatible with the notations that we studied.
Translators have been implemented between the internal
representation and a number of different external notations.
\section{The underlying vision}
The following are my responses to the questions posed in the
workshop announcement.
I believe that any scheme for knowledge base sharing must
allow for multiple models. Knowledge representations
inevitably reflect their intended use, either explicitly, as
in the work of Van Baalen, Amarel, and others, or
implicitly. Ontologies that are intended to reusable, such
as the {\sc Penman} Upper Model, still implicitly reflect
the uses envisioned by the knowledge base developers. Using
a sharable knowledge base should not imply buying into all
of the design decisions of the knowledge base designers.
Rather, knowledge engineers should be offered a choice of
representations, according to their particular needs.
Facilities must be provided for translating between
alternative models, and coordinating alternative models.
{\sc Aries} and Cyc are examples of systems providing such
facilities.
At the same time, the community needs to work toward
reducing needless discrepancies among ontologies. This is
particularly true at the highest level of the ontological
hierarchy. For example, Cyc, {\sc Penman}, and {\sc Aries}
each adopt particular ontologies of entities, relations, and
events that conflict to some extent, particularly regarding
the semantics of events. Cyc and {\sc Aries} view events as
decomposable into parts (subevents), while {\sc Penman} does
not. The semantics of subsumption of events in {\sc Aries} is
defined in a special way to take into account preconditions
and postconditions, and the allow for subevents having
different participants than the superevents. For example,
{\sf take-off} (an action performed by aircraft) has one
participant, the aircraft taking off; it is a specialization
of {\sf move}, which has multiple participants (the object
being moved, the agent doing the moving, and the destination
of the move). The specialization relation in {\sc Aries}
maps the participants of {\sf move} onto the participants of
{\sf take-off}.
Such conflict among high-level ontologies is inevitable.
Yet the more discrepancies there are in the semantics of
ontological primitives, the harder it is to translate
knowledge bases built on these primitives. I suspect that
many of the discrepancies between high-level ontologies in
current systems can be eliminated.
A good way of making progress in reusable knowledge bases is
to make the effort to adopt and adapt knowledge bases
developed by other groups. We have found the process of
integrating the {\sc Penman} Upper Model into {\sc Aries} to be
instructive, even though it has been only partially
successful so far. More experiments of this type should be
carried out. Developers of knowledge representation
frameworks should provide facilities for inputing knowledge
bases developed in other frameworks, to support this task.
More research needs to be conducted to understand the
relationship between the representation of knowledge and
its use. If people are going to use sharable knowledge bases,
they need to understand how such knowledge bases are intended
to be used, and what assumptions they make. Progress is being
made here, but more work needs to be done.
\end{document}