RE: [unrev-II] OHS / DKR problem revisited

From: Garold L. Johnson (
Date: Fri Dec 22 2000 - 08:04:58 PST

  • Next message: Jack Park: "Re: [unrev-II] Use Cases and Ontologies"

    -----Original Message-----
    From: Paul Fernhout []


    I like this and your other summarizes. I especially like the way you are
    referring to a debate on issues to create a set of requirements.

    I have a thought related to this and other subsequent posts by people,
    which is that since email is really the most widely used application on
    the internet, we need a clearer statement with details and use cases of
    how much better an OHS/DKR will be to solve any specific issues than
    email in a threaded email viewer.

    I like your list. What might make it even more useful is tying each
    point to a qualitative statement of how much this issue cannot be
    handled by email (the difficulty it entails for example, and how
    frequently it comes up). Perhaps we could start by refining the list,
    characterizing how one might address each issue with regular email (even
    if it required a certain disciplined use)?
    [Garold L. Johnson] The major problems with email all relate to linking, at
    least to a first approximation. Since emails have no unique identifiers,
    tying even a reply to a specific email much less a specific reference is
    difficult since there is nothing unique to which an email can refer. Hence
    we end up doing a lot of quoting because we canít refer to an email uniquely
    much less in a fine grained way, and there is no way of knowing how much of
    the email traffic any new viewer has.
    Egroups assigns a message number to every message it receives, but that
    number is not reflected in the email that is sent to the list. The
    originator doesnít know it since it isnít assigned until it is received by

    To give some idea of how little it would take, the egroup messages are
    available as URLs of the form
    where the final number is the message number within the group. This means
    that the email repository can be referenced by links to the global emails.
    Thus if there were just a little more information in the emails Ė the egroup
    sent the message number in some field, and the in-reply-to field was set to
    the message number, we could get threading directly, and we would solve the
    problem of access to the repository.
    Add a fine grain linking mechanism, and suddenly an email list manager
    begins to be a lot more useful.

    Add the ability to split a message reply or to reply to a message section,
    and we suddenly have a hyperlinked information base.

    Notice that this is little more than a WikiWeb generated by email.

    To carry that further, by using the Wiki formatting rules in email, we could
    send text that could be appropriately formatted into HTML.

    The implication of this is that if the OHS were to start here, it should be
    possible to pick an mail list server with existing code and link it to a
    WikiWeb, also existing code, and have a system that would allow us to
    organize this discussion in far more effective ways than an email list

    Since the entire content would be available as text files on the Wiki
    server, could be added to by email, and updated directly by Wiki, such a
    system should allow us to experiment with features easily.

    Depending on the Wiki base, there is support for version control of the
    nodes, allowing access to a history.

    Features can be added by adding buttons to the Wiki pages to allow new
    operations. If templates can vary based on the page, which is true of Wikis
    that support locked pages, we could experiment with nearly any option that
    we wanted at the expense of a rather small piece of CGI code.

    While most Wikis operate on text files, this is by no means a requirement.
    The page source could be held in any sort of database desired.

    Any post-processing schemes could be applied to the system at will since it
    would all be available. It might be necessary to add sections to the page
    source, much like the .ini files used in Windows. This would allow the
    addition of frame based attributes to a Wiki system. The impact of the
    various sections would depend on the code for the Wiki operations.

    Now we have a scheme that would allow us to simulate any sort of system that
    we might wish, or as many as we might wish, within the same base.

    Want to try out an IBIS style structured communication? Add options for
    classifying an email response to the email list server that saves the pages
    in the Wiki, add a section to the pages indicating that it is an IBIS
    system, have the page renderer add the links to the Wiki page for the
    various allowed sorts of linked responses, and you have an IBIS system with
    email input.

    It seems to be a very fast way to achieve a system on which all sorts of
    usage experiments can be loaded, each in their own sandbox if necessary, and
    post-analysis would allow for all sorts of tests on knowledge organizations.

    Obviously there have been discussions on this list on how to do such a
    fine grained linking in regards to the specifications and the purple
    numbers (acting like chapter and verse numbers in the Christian bible)
    accomplish the same thing.

    However, as an alternative, perhaps a more disciplined use of email
    subjects in a threaded discussion (including splitting replied into
    multiple smaller emails) would immediately address this issue with
    conventional technology? [Although that has it's own difficulties as it
    eliminates the notion of connected "essay" from the system.] For example
    Rod and SDS exemplify disciplined KM, but it takes effort and developing
    certain work habits. Or, perhaps something as tiny as a modified version
    of an email client to be able to link to those references already given
    email would then go a long way towards this? Or perhaps, this would not
    be so essential if we had a standard way of referring to messages not
    being directly replied to?

    [Garold L. Johnson] if you go to the egroup site the URL can be determined.
    If a few changes were made to the egroups email system, we could do all
    sorts of things. (see above).

    Obviously the international space station, the Boeing 747, the Taj
    Mahal, and the city of New York have all been built without OHS/DKR.
    (What tools did people use?) So we are not saying you can't make complex
    things without OHS/DKR.
    [Garold L. Johnson] Since I worked on many of these projects, I can tell you
    that they are tool averse. The majority of the work is done with paper
    documents done in word processors. These documents are now (sometimes)
    available on local networks, but there is not even so much as an index to
    them or a way to determine the latest version or release status of a given
    document. All document references are done by document title and in a few
    instances, by paragraph numbers, which may change in later revisions. With
    requirements, there are often unique identifiers and there are a few tools
    being used at times.
    There is little or not way to track discussions of topics until they end up
    in a published document, and then there is only the result of the
    discussions, not the discussions themselves.
    There is no way to revisit decision processes. There is no way to find out
    that a rejected alternative was held to be the best except for some
    impediments, and now that the impediments have been removed, there is a
    better alternative than the current one.
    Collaboration is mostly by direct meeting with viewgraphs and, sometimes,
    documents. Email is playing an increasingly large part, with all of the
    problems we have noted. When a discussion gets long enough or important
    enough, somebody captures a portion of it in a document describing a
    proposal. This document may or may not address any issues raised during the
    discussion. Then discussion starts on the new document.
    This is not unique to the projects you mention, it appears to be the state
    of the art for all projects.
    We talk about adding formalisms to our systems to aid in organization Ė most
    of these documents are produces without any use of even simple word
    processing features such as paragraph styles. There is no use of
    hyperlinking because there is no central place for a link to refer. Document
    copies get passed around in much the same way as we quote email. Trying to
    get the idea of a common document template across is nearly impossible.
    Going beyond that is hopeless. This is from engineering professionals trying
    to build products where any failure in precision can mean failures in the
    billions of dollars, and possibly numerous human lives.
    If the cultures in which these people operate cannot support KM formalisms
    at eve a low level, how are they ever going to support any real KM
    interaction? If we canít get professionals who have a real need for better
    KM to do even the little bit needed to make things better, how are we ever
    going to get groups of essentially casual users to do anything like it.
    We have to be more making statements about cost
    or speed. Then implicitly the reason for OHS/DKR becomes that lower cost
    or quicker speed may make developing a solution more politically
    feasible given limited resources. Or, another reasons is that
    technically, it may now be feasible to address problems that would
    otherwise morph faster than the solution could be devised. Again, though
    the issue is which problems have this requirement, as opposed to just
    using plain old text email to resolve?

    -Paul Fernhout
    Kurtz-Fernhout Software
    [Garold L. Johnson] I think that the combination of a (slightly) enhanced
    email system and a Wiki as I described could produce an extremely powerful
    platform for experimentation.
    By adding a publish option to an attached document. For example, we could
    generate an uneditable document with the famous purple numbers of other
    equivalent. We could autogenerate the section links as the emails were
    processed or the Wiki pages were saved depending on the source.
    Such a system should be relatively easy to build from existing code bases
    and could be exported to the rest of the internet.

    Now, if we talk about ways to edit Wiki pages with an intelligent editor /
    browser, we begin to get the possibility of greater formalism during the
    creation of emails and Wiki pages, for those who want to use them. By using
    some of the linking provisions in XML it should be possible to refer to
    individual elements of a document, which results in the fine grain links we
    believe are really needed for good KM representations.


    Garold (Gary) L. Johnson

    This archive was generated by hypermail 2b29 : Fri Dec 22 2000 - 08:21:16 PST