NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/alt/hypertex/749

Internet Message Format | 1992-09-11 | 9.9 KB

Path: sparky!uunet!dtix!darwin.sura.net!spool.mu.edu!agate!linus!alliant!mydual!olson
From: [e-mail] (Kirtland H. Olson)
Newsgroups: alt.hypertext
Subject: Re: Interaction with a hypertext (long > 200 lines)
Message-ID: <[e-mail]>
Date: 11 Sep 92 18:13:38 GMT
References: <[e-mail]>
Reply-To: [e-mail]
Organization: The Harvard Group, 01451-0667
Lines: 198

In trying to create hypertexts, I've seen some of these problems as
well.  I use HyperRez by MaxThink as a test bed, and that means I don't
have typed links or nodes--if I need them I must build them.  Thus my
experience differs from that of using an integrated system.  I find this
an advantage because I am forced to meet every issue head-on and thus
increase my understanding of the organizational issues.

I'd like to see more discussion of these issues in this group, and I
would welcome *any* comments on the notes I've added to Mark's
commentary.

In article <[e-mail]> [e-mail] (Mark C. Langston) writes:

>  The recent discussion of active v. passive hypertexts (HT's) piqued my
>interest.  I am doing R&D on educational hypertexts, and would like to
>incorporate the user into a more active role during navigation, along the
>lines of annotation.  Several issues come to mind:
>
>* If the HT structure is theory-determined or research-determined...
>  a strong indexing/inference engine would need to be incorporated into
>  the sytem to correctly link user annotations/additions.
>
>* If user after user after user annotates a particular HT, the possibility
>  arises that most of the accesible information (via the HT) will become
>  embedded in the annotations, and the HT will become redundant and linear.
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I see how the HT gets redundant with many annotations by different people,
but I don't see the linearity issue.

>>*Allowing multiple annotations increases the amount of user-irrelevant
>  material present on any one card or screen, and increases the linearity
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^^
If the system maintains typed links (as you later suggest) the
irrelevant material would be on the target screen, not the source
screen, so the link system must organize the kinds of relevance.

Sorry to be so dense about the linearity, but I don't grasp that issue.
I cannot imagine what I would do to linearize something that started out
with an organization that could not be drawn on a plane without crossovers.

>* Allowing multiple annotations increases the amount of material in general
>  accessible from any one card, and again increases the linearity of the HT.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yes, but in how many jumps?  Imagine a sheet of graph paper where the
intersections of the lines represent nodes and the lines represent
links.  To move from one node to another, I must follow the lines.

When I arrive at a node, it either contains the thought I sought, or it
does not.  I can investigate it's four neighbors to see if the idea is
there. Paths which move away from what I seek, I reject.  I should now
see the "line of reasoning" along each of the two orthogonal paths.  If
neither line will take me where I want to go, I have a line of reasoning
that must be added.  Adding a line of reasoning adds a dimension.  Now I
must have many sheets of graph paper, one above the other, and move
between sheets.

Thus I believe that adding comments must increase, not decrease, the
dimensionality of a hypertext.  I will add to the amount of material
accessible from any one node, but the reader will only follow the "line
of reasoning" corresponding to the reader's current interest.

In this organization, no diagonal links are allowed.  The relationship
of two remote nodes is built into the structure.  Adding a relationship
means adding a line of reasoning (which may connect existing nodes in a
new way) that the system must maintain as a new and separate line.

I think of these lines of reasoning as *threads* and consider hypertexts
to be *multiply threaded* as opposed to the single thread of a short
printed text.  The system may be sparsely populated, as in a novel where
the unities of time, place, etc. form threads underlying the story, but
the author presents the "nodes" in one chosen order.

>* Allowing dynamic node creation for indexing of end-user annotation opens the
>  door to computational explosion on number of links.
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In the system I describe, the number of possible links is known at the
outset from the number of permissible threads.  Each node connects to
two others along any thread, there are T threads, and adding a node adds
2*T links. Adding a thread adds 2*N links where N= Number of nodes.

>How would one rectify these problems?  [stuff deleted]

I believe one needs a system that maintains the threads separately,
maintains a sense of order along each thread, finds targets within a
node, and differentiates next and previous from forward and backward.
One also needs an authoring system that maintains the threads and their
permissible values--visible to the author or annotator--and
automatically places the node at the intersection of the values along
each thread.

Also, the writer must be trained to write in this context.  Conventional
writing training prepares one to write on paper and teaches tools to
create coherence in a *fixed* sequence.  When the sequence of paragraphs
can vary, conventional writing techniques provide no useful guidance
about structure.  In fact, if I postulated link types of "because,"
"consequently," and "for example," even paragraph structure rules might
get bent.

>One could assume
>unlimited storage/computational power, but I'm focussing on smaller
>systems.

Systems don't need to maintain empty boxes.  Rather than create all the
boxes and fill some, one can tag the material with it's conceptual box
and use the engine to maintain the virtual organization.  One must
resolve the issue of fullness--if the system is less than half full, the
tagged material concept saves space, if the system is more than half
full, the empty boxes cost less.


>...the end user has difficulty following the
>coherence of the links between keyword/card, since these are based on the
>programmer's assumptions of coherence, and not the user's....

All communication suffers this problem.  Hypertext offers the
possibility of multiple threads to reduce the problem, but the author
always chooses the purported coherence.  For example, take two textbooks
on the same subject and try to devise a scheme for putting them into one
hypertext.  Since each author chose a coherent scheme, melding the two
may require devising a third that can hold them both.

[stuff deleted]

>
>  It almost seems that there is an interaction between:
>    a) Number of links
>    b) Types of link structures
>    c) number of nodes
>    d) node types
>    e) coherence during link traversal
>    f) dynamicism of said HT.
>

I suggest that adding "coherence types" cleans up the interaction by
limiting it to a knowable, finite number.

Now the dynamicism of the HT gets restricted, but not limited.  That is,
you can only do certain things, but you can do as many as make sense to
you until your machine runs out of speed and storage.  If the things you
can do cover all your needs, you've won.  If not, you need a new engine.


[stuff deleted]

>Why not dump the theoretical basis of the HT?  Well, one could do this, but
>the whole point of grounding such a system theoretically/empirically is to
>facilitate search speed and accuracy, and to maintain user coherence, instead
>of relying on the user to infer the programmer's reasons for coherence.

To the extent that programmer means author, the programmer's only reason
for coherence needs to derive from the user's frame of reference.  One
must know one's audience and create in their terms if one wishes to
communicate.

I suggest that users annotate a well-crafted piece to tie it to another
framework rather than to correct the original framework.  Thus users
will need to create threads and nodes that represent personal, rather
than shared knowledge.

In the group annealing process, an existing group links the foreign
knowledge to its previously shared knowledge.

In groups newly formed around a "starter" HT, the group develops its
shared knowledge around the HT by offering personal knowledge for
discussion.

These situations all differ, but they share one problem.  *The annealing
discussion includes both knowledge and knowledge about knowledge.*  Thus
I suggest that the interactions take place on multiple planes and the
hypertext system needs to keep them separated.

Even in conversation the separation of meta-knowledge from knowledge
seems to need lots of trials and false starts.  Asking the HT engine to
do smoothly what I can barely describe may need a few trials to find,
design, and learn to use the engine.  My experience of databases and
outliners as well as spreadsheets keeps reminding me how difficult it is
to separate what I know from the way in which I know it.  Working with
hypertext helps by giving another view.

One further possibility occurs to me.  Perhaps I don't want to annotate
the HT, but to *transform* it into a framework that I define.  Put
another way, maybe you want my hypertext as an annotation to yours.  Once
again, the meta-knowledge level dominates because the task is now to
translate between two knowledge frameworks.

>
>--
>+--------8<------Cut Here------8<------Cut Here------8<------Cut Here---------+
>  Mark C. Langston   |  "Secrecy is the beginning of tyranny."
>  Psychology Dept.   |  "Always listen to experts.  They'll tell you what can't
>  Memphis State U.   |     be done, and why.  Then do it."
>      "Pftph!"       |           -From the notebooks of Lazarus Long




--
Kirtland H. Olson                     [e-mail]