ABSTRACT
Computers require formally represented information to
support users but users often cannot provide it. This paper
looks at an approach called “incremental formalization”,
when users express information informally and the system
supports them in formalizing it. Incremental formalization
requires a system architecture that can integrate formal and
informal representations and enable and support moving
information upward in formality. The system should include
tools to capture naturally available informal information and
knowledge-based techniques to suggest possible
formalizations of this informal information. The Hyper-
Object Substrate (HOS), a system with these characteristics,
has been applied to a variety of domains, including network
design, archeological site analysis and neuroscience
education. Users were successful in adding information
informally and in incrementally formalizing that
information. In particular, informal text was added, which
later had attributes added and partook of inheritance
relationships.
KEYWORDS: Formalization, structure, hypermedia,
knowledge-based systems, knowledge representation,
knowledge acquisition.
INTRODUCTION: THE PROBLEMS OF FORMALITY
Computers require formally represented information to
support users but users often cannot provide it. This paper
looks at the nature of this problem and proposes an approach
to dealing with it: computer-based support for incremental
formalization.
The Need for Formalization
For the purposes of this paper we will define formalization
as the process of identifying machine-processable aspects of
information. This includes the delimiting of “chunks,” along
with their types, properties (attributes and values) and
relationships to other information “chunks.”
According to our definition, computers can only process
information that has been formalized. This means that
formalization is required for computers to be of any use. In
general, the greater the level of functionality needed, the
greater the level of formalization required. Thus, a word
processing program provides low-level functionality and
requires the very low level of formalization of textual input.
Knowledge-based systems offer a much higher
functionality--i.e., they are more active in aiding the user--
and require a much higher level of formalization of
information.
There is a great and increasing need for computational aids
for dealing with the notorious “information overload.”
Above all, this problem takes the form of a deluge of
informal information--especially text. Better means are
desperately needed for searching and filtering this ocean of
data to find the small fraction of it that serves our
information needs. All such means require increased
formalization of this information.
The information overload is one of a number of forces
behind the drive for higher-functionality software. The next
generation of software development aims to put many high-
functionality computer systems to work in everyday support
of end-users. This will require extensive formalization of
input.
The Need for Explicit Formalization by Users
In principle, the required formalization of information need
not be done by users. If a computer were to be pre-loaded
with a great deal of knowledge of the users’ application
domain, little or no explicit formalization by users would be
needed. The machine could, in theory, completely formalize
the input automatically. An example of this would be
machine understanding of natural language input.
Unfortunately, it has not yet proved possible to put nearly
enough knowledge into software to allow input to be
formalized without the user explicitly telling the machine a
great deal about its formal properties. The high-functionality
software that users and developers are planning for will
Supporting Knowledge-Base Evolution
with Incremental Formalization
Frank M. Shipman III
*
Department of Computer Science &
Institute of Cognitive Science
University of Colorado, Boulder, CO 80309
(303) 492 - 1218
E-mail: shipman@cs.colorado.edu
Raymond McCall
College of Environmental Design &
Institute of Cognitive Science
University of Colorado, Boulder, CO 80309
(303) 492 - 7042
E-mail: mccall_r@cubldr.colorado.edu
In Proceedings of CHI ‘94, April 24-28, 1994, Boston, Mass., pp. 285-291.
inevitably create greater requirements for explicit
formalization of input by end users. This is problematic,
because it seems that users are unhappy about having to
explicitly formalize input.
Problems Experienced with Formality
A number of problems have been experienced when systems
require extensive formalization of information by their
users. One is that it takes a great deal of extra time and
effort. Often this extra effort is not balanced by a payoff at
the time the formalization is required and for the persons
who must do the formalization. Our experience indicates
that even relatively small amounts of this extra time and
effort can disrupt the flow of work [3]. Also, formalization
often seems to be highly error prone and difficult to correct
when done wrong. Users are hesitant to formalize for fear of
prematurely committing to an erroneous understanding of
their tasks.
Why is providing a formal representation of information
difficult? The difficulties that users have in formalizing
information are not just interface problems. More effort is
required of users in part because formal representations
require the explicit statement of information that might have
been left implicit or tacit [12] in a less formal representation.
In addition, substantial effort is typically required to learn a
formal representation. This requires both talent and interest
in formalization that users are unlikely to have.
To the extra time and the disruption resulting from
formalization must be added the extra cognitive overhead.
This overhead is especially problematic when users are
already devoting their full cognitive efforts to understanding
and performing their normal work tasks. Formalization
requires many extra decisions to divide information into
chunks, to type and label these appropriately, to link them
with useful relationships and assign properties to them.
One well-known difficulty of formalization is that of
prematurely imposing structure [6]. As new situations are
encountered, an expert’s understanding of the specific
problem--and even the domain--will change. Formalizations
based on previous understandings will become outdated and
counterproductive. Users learn this quickly--and often
painfully. As a consequence, they begin to resist efforts to
get them to structure their information until quite late in the
project.
Resistance to Formalization
In apparent response to the problems with formalization,
users of many different types systems have resisted
formalization. When systems require formalization as part
of all input, users resist using those systems [10]. Thus
expert systems simply fail to get maintained. Hypertext
authoring systems--e.g., gIBIS [1]--often fall into disuse.
Hypertext, of course, requires a far lower level of
formalization of information than an expert system. And
here we see a crucial irony, for it is not only the requirement
for formalization that seems to cause hypertext authoring
systems to fall into disuse. Users seem also to find that the
hypertext is too passive to be of sufficient value. They want
systems be more of an active aid to their work--to do more
for them. Yet they already resist the low level of
formalization required for passive hypertext. Adding the
desired additional active functionality--e.g., knowledge-
based functionality--to hypertext would require far more
formalization of input by users.
Analysis of These Problems
We seem to be facing a dilemma. On the one hand, users--
and software designers--want higher-level functionality for
their systems. On the other hand, users resist the
formalization of information that is required for higher-level
functionality. But the appearance of dilemma is illusory.
The illusion is based on a number of mistaken assumptions.
For one thing, the formalization need not be done at the time
of input of information. For another thing, while
formalization cannot be automated, it can be supported with
software. The approach adopted here involves identifying
and attacking these assumptions.
APPROACH: INCREMENTAL FORMALIZATION
A number of different approaches can be and have been
taken to solving the problem of user’s resistance to
formalization. One approach is to find a formal
representation that is easy for users to work with--a goal of
end-user programming languages. A second approach
attempts to provide help to the user in learning and using a
formal language (e.g., LISP)--a goal of “end-user
modifiable” systems [5]. An approach radically different
from either of these attempts to make the system understand
the informally represented information--a goal of natural
language processing. The approach presented in this paper
combines aspects of all of the above approaches. Users enter
information into the system in an informal or semi-formal
representation and the computer aids the users in
formalizing this information.
Need for an Incremental Approach
Often the human understanding of what should be
formalized and how emerges slowly during actual use of the
system. This should not be surprising, since what is
formalized and how depends on the purposes the system is
used for--and these are only discovered during actual use.
The Process of Incremental Formalization
This approach allows information to be entered in an
informal or semi-formal representation and to become more
formalized over time through a series of small and simple
intermediate steps. For example, a textual annotation could
collect attributes one at time. (Figure 1 diagrams this
process.) As formalization proceeds, progressively more of
the following are identified: 1) “chunks”, i.e., meaningful
Object A
Relation:
Object B
Frame or
Idea
Traditional Knowledge Acquisition
Text
Note
Text
Note
with
Attrs.
Incremental formalization through
Object B
Attr: value
Semantic NetInformal / Semiformal Representations
Figure 1: Diagram of Incremental Formalization
units, 2) relevant attributes, values and relationships, 3)
associations between chunks, attributes, values and
relationships, 4) constraints, 5) generalizations (both rules
and inheritance relationships), and 6) aggregate constructs.
Incremental formalization aims, first of all, to eliminate the
cognitive costs of formalization that inhibit user input.
Secondly, it aims to reduce the burden of formalization by
distributing it and making it demand driven.
A crucial feature of our approach to incremental
formalization is that it is non-destructive. When a formal
representation is produced, it supplements rather than
replaces the less formal representations. This is because
formalization generally results in a loss of information
content--e.g., unstated background knowledge and rationale.
Keeping the informal knowledge from which formal
knowledge is derived helps us to check and revise formal
representations, as found by Hofmann in [7].
The second crucial feature of our approach is a
“bootstrapping” strategy for supporting formalization. As
explained below, we use the knowledge that has already
been formalized to suggest possible formalizations of
additional input. Thus, the more information has been
formalized, the more support the users gets for further
formalization.
SUBSTRATE FOR INCREMENTAL FORMALIZATION
To support and set the stage for incremental formalization,
we have developed the Hyper-Object Substrate (HOS) [14].
HOS provides a domain-independent framework,
combining characteristics of hypermedia systems and
knowledge engineering systems.
Basic System Functionality
HOS integrates representations of varying degrees of
formality by insuring that all information in the substrate
(informal text, semi-formal design rationale, and formal
knowledge including objects with attached properties) is
represented as first-class objects. A first-class object is an
object that has no restrictions placed upon it, i.e. there is no
difference between objects with respect to the system’s
reasoning mechanisms.
HOS does include a number of object types. The object
types within HOS are text-graphic, composite, view, agent,
and shell. Text-graphic objects are objects which contain a
drawing method which describes the display of that object.
A composite object is a set of other objects which can have
interactive and conceptual properties as a set. A view object
is a resizable finite two dimensional plane which may have
any number of the other types of objects displayed in the
plane. Agent objects may have dynamically computed
displays and actions based on information in the current
object space. Shell objects provide an interface to
information available to the Unix shell. Text-graphic,
composite, agent, and shell objects can be moved or copied
between views and can be displayed in multiple views at
once.
All objects in HOS, regardless of display type, have an
extensible set of attributes and relations, and can take part in
inheritance relationships. In HOS there is no need to know
all of the attributes of an object at creation time. Every HOS
object may also have a navigational link to a HOS view
object. As is typical in page-oriented hypermedia, clicking
on an object with a navigational link will cause the linked
view to be displayed. Another feature of HOS common to
many hypermedia systems is that users may choose views to
be added to a list of bookmarks. Bookmarks provide for
direct access to views so marked.
Interface to Adding and Formalizing Information
The goal of having end-users of HOS applications have
access to the system’s formal representations has led to a
deliberate attempt to reduce the amount of knowledge
required to order to use the formal aspects of HOS’s
representation. This motivated the use of prototype
inheritance [8] to remove the distinction between objects
acting as classes and objects acting as instances. HOS’s
variation of prototype inheritance allows for inheritance
relations between objects to form generic graphs, that is
there can be cycles in the inheritance graph. In short, objects
can inherit from any other object, without restriction. These
decisions have removed the requirement that the user learn
about knowledge engineering concepts like classes,
instances, hierarchies or directed acyclic graphs which are
normally important to the use of inheritance mechanisms.
Use of Formal Information
Agent objects, also just called agents, are HOS’s generic
mechanism for using formal information. Agents use the
information represented in the form of attributes and
relations to determine when to take some action.
Agent objects consist of a trigger, query, and action, similar
to agents in OVAL [9]. Triggers determine when active
objects evaluate their query to recompute their display or to
take some other action. Examples of triggers are “check
every modification”, “check when displayed”, and “check
when requested by user”. The query looks for objects in the
system which match certain patterns. The objects, if any,
returned by the query are then passed on to the action.
Actions may display the objects found, present a message to
the user, or add a bookmark. This variety of triggers and
actions allows for different active objects to have very
different interaction styles. They may collect information
like Halasz’s virtual structures [6], or notify users of the
occurrence of certain conditions like critics in JANUS [4].
SUPPORTING INCREMENTAL FORMALIZATION
Beyond enabling incremental formalization, HOS includes
mechanisms for importing informal information and
actively supporting its subsequent formalization.
Capturing Normal Flow of Informal Information
For many tasks, the problem is not lack of on-line
information but the lack of usefully formalized information.
The rapidly increasing volume of electronic mail, USENET
News, and other on-line information already provides many
users with more information than they can use. Systems
which require the acquisition of formal information can tap
into this flow of information by allowing this informally
represented information to be imported for later
formalization and by providing a natural communication
channel for collaborating users [13].
HOS includes mechanisms for importing text, electronic
mail, and USENET News files. When importing an
electronic mail message or USENET News article HOS
parses the header and adds the information as attributes to
the newly created object. Figure 2 shows an electronic mail
message concerning network design in a view containing
the formally represented design that the message discusses.
Suggesting Formalizations of Informal Information
The problems associated with formalization require systems
which actively support the formalization process. We have
explored mechanisms to support formalization that make
suggestions for formalizations based on textual patterns
within the information already in the system. (For a
description of a similar use of spatial patterns see [11].) The
mechanisms included in HOS may suggest the addition or
modification of attributes and relations or suggest new
hyperlinks. Because these suggestions are based on the
current state of the information space, these suggestions can
help bootstrap the information space. If accepted the new
information may lead to new suggestions.
The heuristic mechanisms in HOS used for making
suggestions based on text are deliberately simple, using a
type of string search rather than natural language processing
techniques. The mechanisms use a lexicon created by
collecting the names and synonyms of the objects in the
information space. When triggered, the mechanisms look
for occurrences of the items in the lexicon within the text
display of an object and in the textual values of attributes.
When a reference is found, a rule base is used to determine
what attribute or relation is suggested to the user based on
characteristics of the object possibly being referenced.
These mechanisms execute and display suggestions when
the user views an object’s attributes in the property sheet.
Figure 3 shows the property sheet for the electronic mail
message from Figure 2 just after it was imported. In this
Figure 2: Imported Electronic Mail Message
case four suggestions (the top four attributes listed) have
been provided. Three are based on possible references
within the body of the text to people, places, and devices in
the base. The fourth suggestion, for the “From” attribute, is
a modification of an attribute created by parsing the
electronic mail header. In this case the system suggests
replacing the textual value “Evi Nemeth <evi>” for the
attribute with a relation to the object named “Evi Nemeth”.
Suggestions can be accepted as is, modified and accepted,
deleted, or just ignored. If the attribute being edited is one
suggested by the system the “Explain” button becomes
active, as it is in Figure 3. The mechanisms can provide an
explanation of why each suggestion was made, providing
users with rationale about the formalization process and
about the specific formalization being suggested. These
explanations are generated by filling in information from the
lexicon item, the rule base, and the object believed to be
referenced into a template.
There are both domain-independent and domain-dependent
suggestion mechanisms. The “people involved”, “places
involved”, and “devices involved” suggestions in Figure 3
are produced by a mechanism which requires the situation-
specific lexicon containing the important people, places and
things in a domain. In this case the “things” suggestion has
been specialized to devices for the domain of network
design. People, places, and things represent the who, where,
and what involved in a piece of text. These are likely
candidates for formalization across domains. While the
information used to create the lexicon is specific, the
mechanism is domain independent. Likewise, the
mechanism which suggests textual attribute values be
changed to relations to other objects (such as the “From”
relation in Figure 3) uses domain-specific information with
a domain-independent mechanism.
APPLICATIONS
HOS has been used to create a variety of domain-oriented
information spaces. This includes the creation of a
knowledge-based design environment supporting
Figure 3: Suggested Attributes in a Property Sheet
collaborative network design, called XNetwork, and use in
graduate-level class projects in the domains of archeological
site analysis and neurosciences.
Creation of XNetwork
HOS has been applied in the creation of XNetwork, a
domain-oriented design environment to support the
collaborative long-term design and administration of
computer networks [2]. The development of XNetwork in
HOS, driven by a changing understanding of the problem of
network design, provides an example of the evolutionary
development of a knowledge-based system. Computer
network design is an appropriate domain for enabling
knowledge-base evolution since without the addition of new
technologies and devices the environment will quickly
become out-of-date.
XNetwork showed that the suggestion mechanisms are
useful beyond the formalization of the specific information:
they can also act as shortcuts in adding information. For
example, while building the inheritance hierarchy of device
types, HOS suggested “device involved” relations to the
object planned to be the recipient of the inheritance relation.
By changing this suggested relation to an inheritance
relation, the number of user actions required to create
inheritance links was substantially less than required when
no such suggestion was available for modification.
The suggestion mechanisms also can aid the user in finding
mistakes or in learning about relevant information within
the information space. In particular, users will begin to
develop expectations of when and what types of suggestions
will appear, then when the system does not meet the user’s
expectations, the suggestion (or lack thereof) may trigger a
realization that the information space is either inaccurate or
incomplete. Unexpected suggestions can also lead to the
discovery of information previously unknown by the user.
For example, during the creation of XNetwork, occasionally
suggestions were made that were based on information that
was imported automatically from other on-line information
sources. These suggestions acted like notifications of this
other information’s existence.
Besides the creation of XNetwork and smaller design
environments for other domains, HOS was used for a
number of more traditional hypermedia tasks. The
traditional hypermedia uses of HOS include trip reports,
discussions of current literature, and the development of the
outline for a dissertation. The experience of these tasks
suggests that HOS’s hypermedia abilities, while not being as
polished as those in commercial systems, were not hindered
by the system’s functionality concerned with more formal
representations. The knowledge-based system functionality
was invisible to users who did not need it.
Semester-Long Graduate Student Projects
Besides the use of HOS for creating hyperdocuments and
design environments, the system was used for two semester
projects in a graduate-level knowledge systems class. The
goal of the class projects was to create a knowledge-based
system for a domain and task of the student’s choice.
One class project used HOS to build the Archeological Site
Analysis Environment (ASAE), a tool to aid archeological
teams with experts in different topics sharing and analyzing
information concerning the “dig” site. The purpose of
ASAE, as described in the project report, is “to handle the
information overload, to link the archeological team
members, and to make historical and scientific background
knowledge more accessible and useful.”
To try to meet these goals, ASAE combines formal and
informal information about archeology in general as well as
information about the specific site. Artifacts found at the site
have their location, size and composition formally
represented for use by knowledge-based decision support.
Agents were used in ASAE to act as “advertisers” of some
information and are intended to facilitate communication
among group members. The development of ASAE required
some programming to add basic numerical methods used by
archeologists for the classification and grouping of artifacts.
The other knowledge systems class project using HOS
developed the Interactive Neuroscience Notebook (INN).
The purpose of INN is to provide an environment for
student neuroscientists to collect and organize their
information about neuroscience within the context of a pre-
authored framework and set of information. The resulting
role of INN can be seen as a combination of textbook and
personal notebook.
Like ASAE, INN is composed of both informally and
formally represented information. Information from an
introductory textbook on the visual system was placed in
pages of textual information. Some of the objects on these
pages represent concepts or objects in the domain, such as
particular types of cells. These objects include formally
represented information, mostly attributes describing
features of the object. INN included a number of agents to
suggest interesting or related information based on the
current modifications to the notebook being performed. The
development of INN was done without programming.
Figure 4 shows a page of the seeded neurosciences notebook
(upper left) that was suggested by an agent in the bookmark
window (upper right) being displayed along with the
property sheet for one of the domain concepts discussed on
the page.
Information Space Evolution
Close to fifty snapshots of each project were taken during
the semester and a log of attribute modifications was
collected to be used to look for patterns of evolution. Both
the snapshots and the logs provide some noticeable patterns
of growth in the projects. In particular, both projects had
two or three periods of rapid growth in the content of their
information spaces, the rest of the time experiencing slow
growth. Several of these jumps were accompanied by the
modification of attributes for objects already in the system.
The occurrence of these rapid growth periods leads to the
question of was there a cause or was it just the students
working harder on their projects. In looking at what
