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

Internet Message Format | 1992-09-12 | 13.2 KB

Path: sparky!uunet!dtix!darwin.sura.net!wupost!ukma!memstvx1!langston
From: [e-mail] (Mark C. Langston)
Newsgroups: alt.hypertext
Subject: Re: Interaction with a hypertext (long > 200 lines)
Message-ID: <[e-mail]>
Date: 12 Sep 92 19:53:18 GMT
References: <[e-mail]> <[e-mail]>
Organization: Memphis State University
Lines: 269

In article <[e-mail]>, [e-mail] (Kirtland H. Olson) writes:
> 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 think most authoring systems (with the exception of Guide) require you to
start from conceptual 'scratch', and build any structure or types you need.
(I use HyperCard personally...)

>
> 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.


I was a bit vague, I think.  My original conception of annotation by the
end-user would place the annotations onto the annotated card, and not into
a new, dynamically created node.  Thus, over time, the HT would become more
linear, i.e., much of the information originally available on a large number
of nonlinearly linked cards would be available on a small subset of cards
containing a large amount of information, much like pages in a textbook.


>
>>>*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.

I agree with you here, as I seemed to have jumped ship conceptually, and
decided that a dynamic node-creation process would be best.  In this case,
you are absolutely right, and the nonlinearity would be preserved.  Writing
the link system to organize the annotations dynamically would, I think, be
a monumental task.


  [...confusion re:linear problem deleted...]
>>* 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.

[...navigation desc. deleted...]

> 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.

[...more deletia...]

> 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.
>


I agree totally, if annotations were assigned new nodes.  However, above I
was still referring to same-card annotation.  Sorry...I seem to think while
I write, and my flow of ideas sometimes becomes quite unclear...I really
should start treating such posts as a more formal writing experience...

>>* 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.

I can see your point, re: system limitations, but why arbitrarily pick 2 as
the limit for links leading from any one node?  I would think this could
become severely restrictive under some circumstances (e.g., the system I am
developing hypothetically has at least 2 links, and a reasonable upper limit
of 100 or 200.  Each keyword has 10 possible links (although not all keywords
have all 10 link types activated), and each card can contain as many keywords
as one would like, with an upper limit of text size within each card.  I even
have one card with (this is a rough estimate) 180-200 links (it is, however,
a taxonomy..)).


>
>>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.

In another discussion with someone (whom I just cant recall off the top
of my head), I had come to a similar conclusion:  maintain the annotations
as a seperate HT, each HT highly interlinked within itself, with fewer,
strategic links between the two HT's.  Of course, the annotation HT could
spawn a new HT, and so on ad infinitum.  The real problem here, again, is
dynamically creating the relevant links between any new piece of information
and the original HT (not the annotaiton HT).


>
> 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.

This seems like an adequate solution, if one is dealing with a small,
trained end-user population.  But the whole idea (at least from my standpoint
of using HT's in an educational setting) is to make the HT environment as
transparent as possibe, so the HT becomes a tool and not an obstacle in
the learning process.


>
>>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.

Hmmm...interesting idea, but I still think the 'engine' required for HT
management is an insurmountable task using present technology.

>
>
>>...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.

My idea here was to develop a general coherence structure, in which each
programmer (author) need only pay attention to the theoretical structure
and not worry about coherence issues.  The structure would be a bit
restrictive with regard to content of any one card, but I have such a system
running and coherence remains high (this is not based on empirical data per se,
but rather the reports of myself and test subjects as to the general flow of
information...I am planning to conduct a coherence study this fall.)

>
> [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.

You are right, the dynamicism does become restrictive, yet not limited.
However, one may have to rethink navigation issues once typed nodes and links
are instituted.


>
>
> [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.

Yes, but with an unstructured system, the author (programmer) must still assume
quite a bit about the end-user's frame of reference, familiarity with the
information, path through the HT, etc.  It almost cries out for structure.

>
> 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.

Interesting point.  What would be the benefits/detriments of a personal vs.
a shared knowedge annotation system?  I would think that a shared-k format
would be more beneficial to a greater number of users.


   [...more deletia...]

> 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.

It is possible to develop HTs in such a way that the meta-knowedge is
embodied by the organization of the HT.  In such a structure, the two are
no longer seperated, but fused.  This presents another possibility.

>
> 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.
> --
> Kirtland H. Olson                     [e-mail]
--
+--------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