From: Rod Welch <email@example.com>
What do we want the system to do?
One approach is to say we want it to augment the driving force of human
capabilities: intelligence. If we can do that it will be the
proverbial tide that lifts all boats, helping people solve all problems,
large and small. How is human intelligence augmented now? The alphabet
is a solution that has existed for thousands of years without any
significant advance. It is the little engine that drives civilization.
How does it work?
It gives external form to the internal thought process that grows new
knowledge from daily experience through a simple cycle of plan, perform,
report. Making objects out of mushy subjective thoughts permits
objective improvements. The current application in books, memos,
articles, email, commonly called "documents" creates information.
Bill's wordprocessing tools provide greater power in arranging and
editing, making things bold and colorful, basically pretty. But
documents still only convey information, not intelligence. So, it is
not a really big improvement. We need a new technology that moves up a
notch on the cognitive scale from information to knowledge.
"Intelligence" capability is the bridge.
We need a definition of knowledge that lets use technology to greater
Suppose we define "knowledge" as chronologies of cause and effect
segmented into chunks according to objectives. At the most basic level
"objectives" are human needs, but pretty quickly we get up the scale to
asking how do we organize a DKR project, what are the objectives for
fixing the car, going to the dentist, mowing the lawn, building a
bridge? The human mind does all this constantly on the fly, and it is
all organic. Integrating automated MBO with chronologies of cause and
effect, that supports calling up stuff under a wide range of different
subjects, where any body of information can appear in a variety of
different contexts, emulates a large part of human "intelligence,"
because humans reason by experience. So essentially we need an
automated experience machine, something that manages sequence.
Let's not get too greedy. Let's not look for a machine that does our
thinking for us under the AI model, as set out in the record on
Let's follow Doug's lead, and aim for augmenting human thinking. This
is the computer aided thinking model described in one of Roy Roebuck's
many excellent references on 000125...
This concept strives to step beyond the notion of "documents" and start
thinking about "knowledge space," as a continuous information stream,
and second, how to solve meaning drift that causes those big projects to
fail which Dick Karpinski cited. Meaning drift also causes the high
cost of medical mistakes, it causes the space probe to bump into Mars,
instead of go into orbit, it causes endless argument in meetings where
people waste 70% of the day, and it causes small, petty frustrations
among each of us, all day long that hinder collaboration. All of the
linking tools you folks are discussing in XML and so on, can help solve
meaning drift, once we figure out how to capture meaning. What does
You observed the other day after coming forward with some preliminary
work, that using the environment would be taxing. That is an
understatement. Even a crude version of this capability, while it
provides significant new power to generate useful "intelligence," the
work product can be a Pandora's box for some, because it exposes a lot
of complexity the human mind is designed to suppress, so that people can
function. Most human thinking, the intelligence, occurs in the
subconscious. When we look at a tree, a pencil, an apple, the eyes do
not take in the whole thing, they take in some outline features and our
memory immediately fills in the rest from its reservoir of experience.
We do the same thing in listening to dialog. Building a powerful
"Knowledge Space" may not be as difficult as providing a means for
people to use it without being overwhelmed.
I think it will likely turn out to be just another thing to get use to,
like traveling at 40 miles per hour was a big once a deal, as was the
telegraph, the light bulb, and so on. That may be the biggest
contribution of the DKR: getting people used to the idea of adding
"intelligence" to management. Many feel it is impossible.
Anyway, just throwing in a few comments from "front". You are asking
the right question about what the DKR should do? As with the alphabet,
human capabilities can be augmented by an order of magnitude with some
very simple tools. The trick is getting onto the right design path.
Then, as you say, a lot of very bright people can contribute effectively
in moving civilization forward.
Eric Armstrong wrote:
> From: Eric Armstrong <firstname.lastname@example.org>
> Jeff Miller wrote:
> > From: Jeff Miller <email@example.com>
> > On Mon, Feb 07, 2000 at 02:18:58PM -0800, Eric Armstrong wrote:
> > > > Maybe he was. Maybe he's an RMS who never found his ESR.
> > > >
> > > Now you got me. What's an RMS? What's an ESR?
> > I don't know wether your serious or joking. so...
> > Richard Stallings (www.gnu.org) and
> > Eric S Raymond (http://www.tuxedo.org/~esr/)
> Thanks. I never joke about my ignorance.
> If I did, I'd die laughing...
> > Could someone provide a sketch on the modules/units we'd need...
> I think it's still a *bit* premature for that, but not by
> much. I've been doing some napkin design work, too, mostly
> as questions sent out to this forum. But we need to be really
> clear on the functional goals of the system (both initial and
> future) in order to steer the design discussions.
> Since giving the presentation last Thursday, I've been giving
> more thought to what the "core" of the system should be. The
> key to open source is to hack a nucleus that can be used right
> away. After that, the system can grow by leaps and bounds.
> We are thinking in terms of integrating email, Web documents,
> Augment, and source code.
> Of those, I would put source code last. It's an interesting
> use of the system, but the problems are less fundamental to
> making everything work together.
> An Augment front end looks like a possible starting place, but
> mostly because it will give us something to look at and give
> us a detailed set of requirements for capabilities the system
> really needs to have. (I mean, at a *minimum* it should do
> what Augment is already capable of, shouldn't it?)
> As interesting as that starting point is, though, I don't see
> that it attacks the really fundamental problem. That problem,
> as I see it, is "How do you integrate email and hyperdocuments?
> The one part of that which seems clear to me is that we should
> be able to eliminate the current separation between my email
> folders and my file folders. It should be possible to mail a
> hierarchical document, receive responses to sections of it,
> traverse as-yet-unread responses, create a new version, and
> mail that.
> That's one possibility. Or maybe we want something that supports
> "collaborative authoring" in an even more direct fashion. Such
> a system might use a two-tier system of email messages and
> documents. Or maybe the document needs to exist in a central
> The major question to answer is: What functions do we need?
> If we can visualize the system we need, and "see" it in operation
> in our mind's eye, then the design requirements become clear.
> I guess what I'm saying is:
> Functional Requirements --> Functional Specification
> --> Design Requirements --> Design Specification
> So: What do we need? How will an interactive email-like capability
> co-exist with a document system in the most meaningful way?
> We have XML. That gives us hierarchy and linking. We have email
> clients. Maybe we could utilize such a client to package up a
> document or a set of replies and send them off. How then do we
> shuttle a received message to the DKR? Do we have to save it as
> a file and then read it in? Or is there a better mechanism for
> doing that? (Can redirect an incoming file to a process, for
> example? Or can we redirect it to a folder and have the DKR
> process check for new files periodically?)
> At what point does differencing occur, and what is the best way
> to manage responses to nodes that have been deleted or moved?
> Should the ID of every node contain the original path at which
> it was created? (If a node did not exist at it's original location,
> a search of all nodes would then find it.) Or should a "phantom"
> node always exist that points to the current location of the
> node when it has moved. (Dually linked, so that whenever the node
> changes positions, the phantom's pointer can be updated.)
> Of course, now *I'm* going off into the design weeds again. It's
> so hard to stay focused on the real point -- what is that we want
> the system to DO?
> [ONElist Sponsor]
> Please click above to support our sponsor
> Community email addresses:
> Post message: unrev-II@onelist.com
> Subscribe: unrev-IIfirstname.lastname@example.org
> Unsubscribe: unrev-IIemail@example.com
> List owner: unrev-IIfirstname.lastname@example.org
> Shortcut URL to this page:
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIemail@example.com
Shortcut URL to this page:
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:44 PDT