[unrev-II] Communication, Argumentation, and Documentation

From: Garold L. Johnson (dynalt@dynalt.com)
Date: Thu Jan 04 2001 - 03:38:14 PST

  • Next message: John J. Deneen: "[unrev-II] NIH Related Use Case: Knowledge Discovery and Data Mining in Biological Databases"

      -----Original Message-----
      From: Eric Armstrong [mailto:eric.armstrong@eng.sun.com]
      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

      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
      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
       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,

      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.


      Garold (Gary) L. Johnson

    This archive was generated by hypermail 2b29 : Thu Jan 04 2001 - 03:49:43 PST