Good questions, those.
I don't favor anything. I am *biased* towards experimentation with WBI
simply because Doug is. I don't recall saying that WBI is the solution. It
is a candidate, a design point along a path, whatever.
I am biased toward knowledge-centric thinking for two reasons: (1)we intend
to build a DKR (read: Dynamic Knowledge Repository), and (2)that's the way I
I also think Eugene gave a brilliant layout of his needs for an OHS, that
thing connected to a DKR that users bang on to get stuff into and out of the
DKR. There is an OSS Java PIM that uses XML as its storage medium. I would
imagine that simply adding XLL to it would give it the linking ideas he
spoke of, and you would be off with a prototype to play with and expand
upon, heading towards that Version 1 we all dream about.
In the end, things we don't talk about here, some of which Rod Welch already
has running at his web site, must be pondered. One way or the other, they
will be pondered.
Firstly, we start with raw information. That's emails, journal papers,
books, movies, diagrams, recorded spoken words, and so forth. Next, we must
reduce that raw stuff down to filtered (read: interpreted in context) stuff.
There is a whole literature out there on Information Retrieval, part of
Knowledge Management. Here, we are talking about ways to build indexes into
all that raw stuff. Indexes that make sense for all potential users, and
that's the really hard part. If the primary categories in your world view
are women, fire, and dangerous things, chances are that I'm not gonna come
up with an indexing scheme to satisfy your needs. My world view spans,
Newtonian and quantum mechanics, molecular biology, and lots more. Not sure
how to map all that to women, or fire, or dangerous things. What is the
point of a DKR if nobody can get into it?
Following reduction, there is mapping to a representation system for machine
inference. Do the reduction poorly and you don't do mapping at all.
All this stuff about email vs web logs is pretty much surface level
(implementation level) discussion that should never go on until you have all
the requirements worked out. Eugene gave a series of scenarios that could
easily lead to requirements for a prototype. What it will look like when
implemented should not be on the discussion table (with such passion) at
In the end, Doug, as I recall, set out to get started on a machine that
would enhance human productivity in knowledge related work. He took pains to
outline global problems, like population, energy, environment, and so forth,
and made it, at least IMHO, very clear that such a tool was of enormous
value to our future. I happen to come from a background of believing the
same thing. To design anything less, no matter what the first out the door
version would look like, would be to completely ignore Doug's message. My
experience with my program The Scholar's Companion tells me that I don't
have to participate in the design of a first hack that prevents its own
From: Eric Armstrong <email@example.com>
> Jack Park wrote:
> > ... settling for what's doable is just liable to make it
> > impossible to append what's hard on as an afterthought.
> I would like to address that concern, if possible.
> Can you give a functional view of a knowledge-based system
> -- how it would act / what it would do / how you or I would
> interact with it, or possibly an internal view of a design?
> Or is this something that the group will need to explore,
> investigate, and define?
> If the former, I feel confident that we can take those issues
> into account while doing the design, and we should schedule
> a session to cover that ground, to make sure that we do.
> If the latter, I'm not sure that we, as a group, have that
> luxury. The group may decide that it wants to pursue that avenue.
> I'm sure it would be valuable. But my understanding of the
> present series of meetings was that it is focused on building
> a relatively immediate "next step" so that remote participants
> can take part in the design and discussions revolving around
> the next version.
> I find myself arguing both sides of the case, here. With WBI,
> I argue that it will be insufficiently robust, and with respect
> to knowledge management, I argue that it may open up the design
> space too far. So either I am inconsistent, or I am reaching
> for a reasonable middle ground. On the other hand, I see you
> favoring both WBI and knowledge-centered design. Do you see
> a potential connection between these two?
You have a voice mail message waiting for you at iHello.com:
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIfirstname.lastname@example.org
Shortcut URL to this page:
This archive was generated by hypermail 2b29 : Thu May 04 2000 - 14:17:14 PDT