-----Original Message-----
From: Eric Armstrong [mailto:eric.armstrong@eng.sun.com]
<SNIP>
MESSAGING BASIS FOR SYSTEM
--------------------------
I take it as a given that I want to interact
with the system in much the same fashion that I
interact with my email client -- only with much
more powerful capabilities. To me, the interchange
of messages is the right way to think about
designing a "front end" that captures knowledge
organically.
The basic problem with knowledge-storage systems
in general as that they are too inflexible, and
extremely difficult to right. Even when they do
sometimes get it right, the lack of flexibility
makes them less right over time, until they
eventually become useless. (John Lowrance at SRI
has some interesting war stories on the subject
that illustrate the point.)
So, the "email paradigm" is, to me, a given. The
system must allow users and the system to
interact. A user should be able to send a query
and get the system's idea of a response. Other
users should be able to review that response and
refine it, if necessary. In the process, they
should be making the system smarter, so it can
do a better job of generating answers in the
future (possibly by interacting with the originator
of the message, before the message is actually
sent).
<SNIP>
In a paper at http://www.csdl.tamu.edu/~shipman/aiedam/aiedam.html
(Integrating Different Perspectives on Design Rationale: Supporting the
Emergence of Design Rationale from Design Communication) Frank M. Shipman
III and Raymond J. McCall refer to 3 types of interaction during the
evolution of a design rationale -- Communication, Argumentation, and
Documentation.
Communication for them covers email, phone calls, meetings,
presentations, etc. These discussions tend to stimulate activity but are
generally poorly captured and poorly organized.
Argumentation covers such systems as Issue-Based Information Systems
(IBIS). It refines ideas through argument.
Documentation usually capture results and discards all but the essential
argumentation and communication.
They cite difficulties in getting people to use formalisms in
communication, thus making it difficult to organize communication into any
sort of structured knowledge.
The "email paradigm" is adequate for communication, but the collection of
emails is wholly inadequate as a knowledge base.
In experimenting with information annealing through a LAN-based hypertext
system, Neil Larson determined that it was necessary to have a knowledge
expert go through and operate on the new material -- format it, use standard
vocabulary, create information clusters, link to other nodes in the system,
etc.
If you look at any email list such as a Perl group, you find that a
question is posed, and several answers are given, the problem is refined,
problems with answers are exposed, and (usually) one or more workable
responses results. There is never any refactoring of the material to result
in accessible knowledge. Sometimes someone will undertake the generation of
a FAQ list capturing the most frequently asked questions and their answers.
Since the tools are poor, accessing the information in such a FAQ isn't
easy. There is only an index of questions, possibly organized into sections.
Doug bases his knowledge capture and organization on a series of
structured hyperdocuments rather than emails or similar communication.
The Extreme Programming Wiki has a discussion on Refactoring Wiki Pages at
http://c2.com/cgi/wiki?RefactoringWikiPages . Since refactoring of code is a
major tool in Extreme Programming, the people involved have gone to quite a
bit of effort to refactor the Wiki pages that organize the knowledge
resulting from their discussions. The result is a nice collection of
information that is still somewhat difficult to navigate. Linking to pages
is easy in a Wiki, but finding pages that are available to link to is not so
easy, nor is the evolution of a standard vocabulary, though they have worked
at that.
Communication doesn't result in organized, retrievable knowledge unless it
is reorganized, at least. Generally communication can benefit from some
formalism for argumentation to refine ideas and approaches, but until the
results are carefully organized into a set of structured hyperdocuments or a
similar knowledge structure, they are no suitable as a knowledge product
such as a design rationale or requirements document. For that you need
better tools.
Ability to refer to other communications definitely improves the
usefulness of collected communications. Organization of ideas into documents
or some similar basis for discussion or argumentation can add direction
during certain parts of the collaboration, but eventually the information
requires a high degree of organization and correlation with indexing and
vocabulary control to be suitable as a knowledge repository.
It seems that we need to go beyond the "email paradigm" in order to arrive
at a DKR.
Personally, I find that what I want at a minimum is a hyperlinking
outliner for the composition of documents and even emails. Using a linear
editor without hyperlinking and the ability to access the knowledge base
during composition results in information being far less organized,
coherent, and useful than it could be. Indeed, I find that lack of such a
tool to be a major problem in organizing just my personal information base.
Thanks,
Garold (Gary) L. Johnson
This archive was generated by hypermail 2b29 : Thu Jan 04 2001 - 03:49:43 PST