Jintae Lee and Tom Malone position paper

Tom Gruber <Gruber@sumex-aim.stanford.edu>
Full-Name: Tom Gruber
Message-id: <2878500078-6075869@KSL-Mac-69>
Date: Wed, 20 Mar 91  15:21:18 PST
From: Tom Gruber <Gruber@sumex-aim.stanford.edu>
To: Shared KB working group <srkb@isi.edu>
Subject: Jintae Lee and Tom Malone position paper
\documentstyle{article}   
\title{The Position Statement for the Shared KB workshop}

\author{Jintae Lee and Thomas W. Malone\\
MIT Center for Coordination Science}

\begin{document}
\maketitle

In our research, we are concerned with how to represent, manipulate, 
and share knowledge that can be used by both people and their 
computational agents.  This implies two key characteristics of the 
KB's we use:  They are semiformal and end-user manipulable.  

\section{Semiformal KBs}

By a semiformal KB, we mean a knowledge base with the following three 
properties: (1) it represents certain information in formally 
specified ways that facilitate automatic processing of this 
information; (2) it represents and make it easy for humans to process 
the same or other information in ways that are not formally specified; 
and (3) it allows the boundary between formal processing by computers 
and informal processing by people to be easily changed.  

For example, the Object Lens system [Lai et al. 88] represents 
information using a relatively straightforward form of object 
inheritance hierarchy, with slots for each type of object and links 
between objects.  However, unlike most traditional knowledge bases, we 
do not place any necessary restrictions on the contents of slots.  
Except when explicitly specified otherwise, for instance, a slot can 
contain an arbitrary mixture of uninterpreted text and links to other 
objects (including, in principle other uninterpreted media such as 
voice or video).   

Using this system, people can represent certain information in formal 
ways that agents can process.  For instance, agents can use 
information in the "From" field of a "Message" to sort mail.  They can 
also use links in the "Supervisor" field of "Employee" objects to do 
more sophisticated reasoning about objects (such as finding all people 
who report to vice-presidents or all messages from people in a certain 
group) and to construct useful displays (such as organization charts).  
At the same time, however, people can enter much information into the 
knowledge base that is not formally represented at all.  For instance, 
messages can have text fields, and "Task" objects can have task 
descriptions.  Even in cases where the system might expect to find 
something formal (such as a link to a room for a meeting), users can 
enter informal information (such as "We don't know yet.")  Thus, the 
system can be useful to people, even when they don't have the time, 
inclination, or understanding to represent things formally, while 
still allowing them to take advantage of as much formal structure as 
they care to create.

The Sibyl system [Lee 90], which is built on top of Object Lens, 
illustrates the usefulness of semiformal KBs for capturing and reusing 
decision rationales.  In this system, people represent some knowledge 
formally, including the relationships between the "Goals," 
"Alternatives," and "Arguments" for a decision problem.  The 
descriptions of each of these goals, alternatives, and arguments, 
however, can be a mixture of free text and formal objects representing 
domain knowledge.  Thus, the system can use some structure to display 
useful summaries and retrieve previous relevant decisions, without 
requiring people to completely encode everything they want to say in 
an argument. 

\section{End-user manipulable KBs}

By an end-user manipulable KB, we mean one which people with no 
computer programming experience can easily see, augment, and 
manipulate.  For instance, we have taken great pains in the Object 
Lens system to make it very easy for end users to define new object 
types, add fields to them, and to specify display formats for 
collections of objects.  Programmers can, of course, do all these 
things in any knowledge base, but we have tried to make these things 
very easy for unsophisticated users by using a combination of simple 
graphical templates and menu choices.  For example, users can specify 
whether to display a collection of objects in a table, a tree, a 
calendar or a matrix by a set of simple menu selections.

\section{Developing knowledge bases as a byproduct of doing other 
things}

As to the question, "How should reusable knowledge bases be 
developed,"  one way of breaking the knowledge acquisition bottleneck 
is to acquire knowledge as a part of performing the tasks in which the 
knowledge will be useful.  Elsewhere, we referred to this as 
task-embedded knowledge acquisition [Lee 89].   In this mode of 
knowledge acquisition, a knowledge base then is a by-product rather 
than something that has to be created with extra efforts.   For 
example, in SIBYL, decision rationales are captured as a part of 
making decisions, which is then used by others for similar decisions 
in the future.  Of course, this mode of knowledge acquisition requires 
that the knowledge base be manipulable directly by the end users, and 
that it not require more formalization than the user is willing to 
provide.  

If we have a KB that cumulates each time we perform a task, then we 
can sometimes let common ontologies grow out of this KB.  For example, 
each time we use SIBYL to design something, say a window manager, many 
aspects of the design get represented and cumulated.   They include 
the alternatives, requirements, and arguments  considered.  As more 
and more cases get represented, people can use objects from past 
designs and specialize or generalize them.  This results in an 
ontology for a given type of task that is grounded in actual practice.   
Such an ontology is often not good enough to be used as a "standard"; 
we may need to check and readjust its categories for proper 
abstraction, consistency, mutual exclusiveness, etc.  However, it at 
least provides a useful basis for building a solid
ontology.

\section{Taxonomizing various translation schemes} 

Now as to the last question, "What are the critical issues that need 
to get resolved," one of the issues that we feel is important in 
sharing knowledge is when to try imposing a standard and when to try 
providing translations.  Elsewhere [Lee
\& Malone 90], we approached this problem by taxonomizing and 
analyzing the space of all possible
translation schemes.  For instance, one obvious scheme is for everyone 
to use the same language, in
which case no translation is necessary.  Another obvious scheme is for 
there to be no common language
and a separate translator for each pair of languages.  (This, of 
course, requires n squared translators
for n languages.)  A slightly more sophisticated approach is to have a 
single common language into and
out of which each language is translated (thus requiring 2n 
translators for n languages).  One of the
intriguing examples we identified was a translation scheme that 
exploited inheritance hierarchies.  If,
for example, I send you an instance of type "Student" when you don't 
know about students, your system
might still be able to automatically translate this into the nearest 
common ancestor we both share
(e.g., "Person").  This translation could, for instance, preserve all 
the fields shared with the common
ancestor and put the additional information into an uninterpreted 
"comments" field.  Our analysis in
this paper includes a proposal for a composite scheme (called 
"Partially Shared Views") which combines
the best features of all the translation schemes we considered.

This study admittedly only scratches the surface of the problem.  As 
applied to the problem of shared reusable KBs, or shared ontologies, 
the relevant questions are:  Do we want a canonical set of primitives?  
When do we want to allow them to be customized?  Is translation among 
the customized or specialized primitives feasible, desirable?  What 
kinds of translation mechanism are possible and what are the 
dimensions along which tradeoffs occur?

If we proceed to work on a single shared ontology, without considering 
these broader issues, then we might make the mistake of having a 
technology that solves no real problems. 


\section*{References}
\begin{description}

\item
Lai, K.-Y., T. Malone \& K.-C. Yu (1988).  Object Lens: A 
"Spreadsheet" for Cooperative Work. ACM
Transactions on Office Information Systems   6(4)  332-353


\item
Lee, J. (1989).   Task Embedded Knowledge Acquisition through a 
Task-Specific Language.  Proceedings of IJCAI Workshop on Knowledge 
Acquisition    Detroit, MI. 

\item
Lee, J. \& T. Malone (1990).  Partially Shared Views: A Scheme for 
Communicating among Groups that Use
Different Type Hierarchies. Transactions on Information Systems   8(1)  
1-26

\item
Lee, J. (1990).  SIBYL: A Qualitative Decision Management System. in 
Winston, P. H. \&   S. Shellard
(Eds.)  Artificial Intelligence at MIT: Expanding Frontiers.  vol. 1. 
MIT Press: Cambridge, MA 
\end{description}
\end{document}