"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