"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
to bring back to public consciousness. Unfortunately, great press by
coupled with absolutely lousy human factors was enough to turn off most
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.
> 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
to evolve in the core of the system, while allowing it to be viewed
(possibly only?) in hierarchical fashion.
The hierarchy one is currently viewing is therefore the "document", and
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
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
it under "Java", "GUI apps", and "Swing", as well as under the
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
> 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
> o It must be possible to identify an object uniquely.
> * 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.
> * It must be possible to construct an new object by copying
> the content of a specific object with another instance identifier.
> We may want
> to track the fact that this object started as a copy of a specific
> o (Other requirements)
> 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...
Thanks again for your thoughts. I think that your requirements and the
I outlined have a lot in common. If the library succeeds in meeting
requirements, it may well be useful...
-------------------------- eGroups Sponsor -------------------------~-~>
It's Easy. It's Fun. Best of All, it's Free!
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 2b29 : Fri Dec 22 2000 - 15:07:49 PST