Re: [unrev-II] Refactoring and information annealing

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Fri Dec 22 2000 - 14:57:08 PST

  • Next message: Eric Armstrong: "Re: [unrev-II] Theory of Knowledge Leads to KM"

    "Garold L. Johnson" wrote:

    > I used MaxThink...for years and use an outliner today.

    Congrats on your disoveries with outliners. That's one of the things we
    want
    to bring back to public consciousness. Unfortunately, great press by
    ThinkTank
    coupled with absolutely lousy human factors was enough to turn off most
    of the
    early adopters, thereby killing the acceptance curve.

    > Using this approach I could generate a hierarchical document that was
    > very coherent, and do it very quickly. This applies formalisms largely
    > after the fact...

    That is their real power. The ability to shift and rearrange at will.

    > I conclude that it is necessary to be able to refactor information at
    > any stage. It would be nice if the base material were still available
    > also as a check on the refactoring, but the refactoring is essential.

    Yes.

    > ...
    > Hierarchical organization is generally superior to linear
    > presentation....(but) One of the problems with hierarchy is
    > that is implicitly assumes that any piece of information has exactly
    > one place to go.

    Yes. That is fundamentally what makes hierarchies less useful over time.

    However, it is clear that hierarchical presentation is desirable.
    The solution, I suspect, is to allow a rich, interconnected network of
    nodes
    to evolve in the core of the system, while allowing it to be viewed
    always
    (possibly only?) in hierarchical fashion.

    The hierarchy one is currently viewing is therefore the "document", and
    that
    document is nothing more than a *view* extracted from the underlying set

    of information nodes.

    > The first response to this in a hierarchical system is the ability to
    > clone a topic so that it can exist in multiple places in the hierarchy
    > and still be a single topic – edit it anywhere and it changes
    > everywhere.

    Useful functionality, certainly.

    > (But) It becomes clear with just a little observation and
    > introspection that humans organize information using
    > multiple hierarchies, at least.

    Yes. I'll get an email telling how to solve a technical problem. I need
    to file
    it under "Java", "GUI apps", and "Swing", as well as under the
    particular
    project it applies to. In email, I have to copy the message. Not good --

    especially when I get the time later to edit it, clean it up, and expand
    on it.

    > This leads us to bi-directional, typed, links which may have added
    > attribute information about the link...

    Yes. The system must allow for the rich variety of linking necessary to
    make information usable and accessible.

    >
    > By refactoring the path we have already followed, we should be able to
    > get a set of requirements for an eventual KM system...

    For another view, see
    http://www.treelight.com/software/collaboration/requirements.html

    > o It must be possible to identify an object uniquely.

    Absolutely.

    > * It must be possible to reference the state of an object as
    > of a specific point in time – we must be able to refer to versions of
    > an object.

    Yes.

    >
    > * It must be possible to construct an new object by copying
    > the content of a specific object with another instance identifier.

    Of course.

    > We may want
    > to track the fact that this object started as a copy of a specific
    > object.

    Possibly.

    > o (Other requirements)

    Yes.

    > o Versioning of nodes. This includes versioning and archiving
    > of documents, which establish points in time where a give node can no
    > longer be edited.

    And I want to tell you that the really huge levels of complexity are
    introduced right here, by this requirement. The node library I've been
    working on attempts to do just that. Hopefully, over the holidays I'll
    unwind some of the complexity issues I got myself embroiled in right
    before it overwhelmed me.

    > The basic reference engine is a real bear...

    Yar.

    Thanks again for your thoughts. I think that your requirements and the
    ones
    I outlined have a lot in common. If the library succeeds in meeting
    those
    requirements, it may well be useful...

    -------------------------- eGroups Sponsor -------------------------~-~>
    eGroups eLerts
    It's Easy. It's Fun. Best of All, it's Free!
    http://click.egroups.com/1/9698/0/_/444287/_/977525824/
    ---------------------------------------------------------------------_->

    Community email addresses:
      Post message: unrev-II@onelist.com
      Subscribe: unrev-II-subscribe@onelist.com
      Unsubscribe: unrev-II-unsubscribe@onelist.com
      List owner: unrev-II-owner@onelist.com

    Shortcut URL to this page:
      http://www.onelist.com/community/unrev-II



    This archive was generated by hypermail 2b29 : Fri Dec 22 2000 - 15:07:49 PST