BobJ's Note
February 1995
If one follows discussions on some usenet and listserv lists, it's easy to see a point where something raised in the thread sends the discussion down a whole new track, but yet the thread heading doesn't always get changed. When this happens in a hypertext, one of the decisions an editor could make is to splice that portion of the web off, sort of like splitting an amoeba, and let it take on a life of its own, develop its own context.
One other option would be to do mini-hypertexts to start. That is, don't link everything to everything, but instead link sections to a table of contents of sorts.
Here's what I'm thinking might work. I'm reading Jakob Nielson's Multimedia and Hypertext: The Internet and Beyond. In his chapter on the applications of hypertext, he describes how software engineers, who need to work collaboratively, use hypertext to look at design issues. He refers specifically to gIBIS (graphical Issue Based Information System) from MCC in Austin, Texas (page 71).
He writes:
Since software design is usually a collaborative process
involving many people, gIBIS was a multiuser hypertext
system. It was based on a theoretical model of the design
process as a conversation among "stakeholders" who bring
their respective expertise and viewpoints to bear on a
number of design issues. The participants in the design
process argue about these issues by suggesting positions
(ways to resolve the issue) and arguments for and against
those positions. All of this is presented in hypertext
structure with three types of nodes: issues, positions,
and arguments.
The graphic he presents is something along these lines.
_-Position---(-)-Argument
_- _-------~ |
_- _ -~ |
Issue-------Position_---(+)-Argument
~-_ ~-_|
~-_Position---(-)- Argument
The idea being that arguments refer to both positions and other arguments and thus can be linked accordingly.
The scheme suggest one way to invite a collaborative hypertext and to suggest an organizing principle. We could write a node which describes an issue, and invite readers to take a position. We could set a time frame, posting the issue statement in the invitation. As position statements came in, we could link them to the Issue node. After we've recieved position statements, we could then ask for arguments. Since we aren't working with a multiuser system, arguments would have to include directions on which node they wanted to be linked from (which position) and which arguments they would be referencing. It could be a matter of indicating the writer's lines in the node as in, John wrote (give summary, paraphrase or quote), so that whoever was placing the links knew where to send them. Nodes could received numbers?: Arg 1, Arg 2, based on order they came in or in relation to a position.
We could set a limit to argument number--two or three per contributor, and position statements one per contributor, so that the web would stay manageable. After a person's hit their limit, the could offer one final statement to use as they wish--a summary of their thoughts, a synthesis, a search for consensus, a new issue, an ammended position.
This would provide a set hypertext that could offer a use of hypertext that was genuine and not just a linear essay chunked up into links and nodes. By setting some limits, it would provide a fixed web that could be navigable. Collections of these types of discussions could be cross referenced, thus providing access to a larger whole, but would still leave within the issue domain a followable array.
Doing something along these lines wouldn't preclude more chaotic/rhizomatic structures from developing.
Just another idea for the hopper.