Garold L. Johnson

Date: Wed, 20 Dec 2000 11:04:29 -0800

From:   Garold L. Johnson>

To:     UnRev II eGroup

Subject:   OHS/DKR problem revisited

I would like to try to capture what I think Paul and I have covered so far.

  1. This community is interested in developing and promoting an OHS/DKR system.

  2. Since tools are built with a function in mind, it makes sense to look at the uses to which KM can be applied. This gives rise to the investigation of the large scale problems addressed by the colloquium.

  3. What can we learn from a study of problems for KM application?

    These problems are socio-technical in nature. Most of them are more social than technical.

    Solutions to these problems will be socio-technical. Solutions will be developed and implemented by groups of individuals collaborating in their solution. Therefore, tools which facilitate collaboration will facilitate the solution of many of these problems.

    We need to distinguish the investigation of the nature of the problems and the attempt to solve the problems. From a KM development perspective, the nature of the effort to solve the problem drives requirements. Some investigation will be required in order to prototype, but it would be better if we could tackle problems that we know we can solve so that we can tell when our tools are helping. If we fail to solve a major social problem with our evolving tool, is it the tools or the problem?

  4. How should we proceed to develop such KM solutions?

    We need to reach agreement on what the tools should do.

    We need to use the tools to determine that they really contribute to problem solution.

    We need to iterate the solution and the requirements as necessary until the tools become useful for larger problems.

    All of this would be a lot easier if we already had the sort of system that we wish to build! It sure sounds like bootstrapping to me!

  5. What can we say about the nature of the KM tools we want? Without trying to do all of the requirements analysis in one shot, here are some things that seem obvious.

  6. Scalability

    We need to be able to represent addressable atoms of information. The kinds of information, the nature of the representation, and the operations that can be performed on them is part of the problem investigation.

    Since all input from the system will be by individuals, a successful tools will be usable by a single individual for managing the information with which he is directly involved. Start of scalability is 1 person.

    The next step beyond the individual is communication with other individuals. This is essentially publishing at varying levels of formality.

    Beyond publishing is accepting feedback.

    Beyond feedback is collaboration.

    Beyond collaboration is ???

  7. Functionality

    Studies show that people resist formalisms in capturing information even if they use such conventions by observations.

    Given this, we need ways to capture information as it arises, and connect it in various ways later.

    The tools need to allow us to capture and organization generated information.

    1. Free text to support totally formless, formality-free information input.

    2. Outline capability to support hierarchy. Hierarchy can be overused, but it is still a way to organize and manipulate information.

    3. Indexing support tools. Both automated tools and ways to add indexing to existing material.

    4. Multiple hierarchies and networks. Hierarchy assumes that there is a single location for any piece of information, a single classification taxonomy. Humans don't work that way. We use multiple hierarchies and networks to classify and organize experience.

    5. Easy reference to existing material.

    6. Hyperlinking in as much generality as we can envision uses for.

    7. Ease of gathering and reorganizing existing information. Refactoring is necessary since abstractions evolve over time, and classification structures change.

It seems to me that an approach similar to this has the following advantages:

  1. It will provide tools that a single individual can use on a local system.

  2. Information organized using the individual tools will be able to be published to a web site and maintained there by the individual.

  3. Tools will scale from there to allow feedback, and then collaboration.

  4. Both individual and web site information can be merged easily either between individuals or web sites or central repositories.

If we do this, we will have tools useful at various levels that can be applied to the problem of developing the tools themselves and also to the problems that we are developing the tools to address. At any point that the tools reach the scale where they are sufficient to any specific problem, that problem may be attacked in earnest by those people concerned with the problem.

"You can't start from where you aren't, you have to start from where you are."

What tools do we have that we can start to use for discussing the development of the KM tools.

  1. This egroup and similar email lists. This is a communication tools with little or no ability to post-process the data. Following it up with tools to help organize the information would help. Question: Will this egroup support the correct use of the "in-reply-to" field so that we can vary the subject within a thread? Does this break the tools that people use most.

  2. WikiWeb, manila or similar editable sites. This works well for information that has some persistence. It allows refactoring and some kinds of indexing. I believe that there is already one at

    The source for several varieties of Wiki is available so that the tool can be extended in various ways

    There is a substantial community of experience in the use of Wiki that we can draw upon.

    All information is available in straight text allowing relatively easy analysis and post-processing.

  3. Weblogs, journals, or import of email data to Wiki style repository.

  4. Other, possibly proprietary tools? I don't know abut these. SDS has been mentioned. Augment/NLS exists. There may be other systems that could be used.

  5. Open Source development support systems when we get to the point that it makes sense.

    SourceForge provides all kinds of tools for managing an open source project.

    Issue tracking systems that are web based

    Requirements tools

    Nearly any existing tools to support collaboration among software developers.

    General collaboration spaces such as Groove, BCSW, etc.


I think that this provides a good base for collaboration. I would like to see a good outliner with HTML or Wiki pages as a result. Thinker....

...sounds good, but I haven't been able to get it installed.

That should be enough to get a discussion started! (g)



Garold (Gary) L. Johnson