Topology
Here are a few questions about the underlying connectivity of a hypertext
web.
Are links two- or multi-ended?
The term "link" normally indeicates with two ends. Variations of this
are liks with multiple sources and/or multiple destinations, and constructs
which relate more than two anchors. The latter map onto logic description
systems, predicate calculus, etc. See the "Aquanet" system from Xerox
PARC - paper at HT91). This is a natural step from hypertext whose
the links are typed with semantic content. For example, the relation
"Document A is a basis for document B given argument C". From now
on however, let us restrict ourselves to links in the conventional
sense, that is, with two ends.
If they are bidirectional, a link always exists in the reverse direction.
A disadvantage of this being enforced is that it might constrain the
author of a hypertext - he might want to constrain the reader. However,
an advantage is that often, when a link is made between two nodes,
it is made in one direction in the mind of its author, but another
reader may be more interested in the reverse link. Put another way,
bidirectional linking allows the system to deduce the inverse relationship,
that if A includes B, for example, that B is part of A. This effectively
adds information for free. This is important when a critical parameter
of the system is how long it takes someone to create a link.
KMS and hypercard have one-way links; Enquire has two-way links.
There is a question of how one can make a two-way link to a protected
database. The automatic addition of the reverse link is very useful
for enhancing the information content of the database. See also:
Private overlaid web , Generic Links .
It may be useful to have bidirectional links from the point of view
of managing data. For example: if a document is destroyed or moved,
one is aware of what dangling links will be created, and can possibly
fix them.
A compromise that links be one-way in the data model, but that a reverse
link is created when any link is made, so long as this can be done
without infringing protection. An alternative is for the reverse links
to be gathered by a background process operating on a basically monodirectionally
linked web. See Building Back-links.
There is a design issue in whether one anchor may lead to many links,
and/or on link have many anchors. It seems reasonable for many anchors
to lead to the same reference. If one source anchor leads to more
than one destination anchor, then there will be ambiguity if the anchor
is clicked on with a mouse. This could be resolved by providing a
menu to the user, but I feel this would complicate it too much. I
therefore suggest a many-to-one mapping. JFG disagrees and would like
to see a small menu presented to the user if the link was ambiguous.
Microcosm does this.
A typed link carries some semantic information, which allows the system
to manage data more efficiently on behalf of the user. A default
type ("untyped") normally exists in some form when types are implemented.
See also a list of some types . (Should a link be allowed to have
many types? (- JFG ) I don't think so: that should be represented
by more than one link.(- TBL ))
Link typing helps with the generation of graphical overviews , and
with automatic tracing .
Should links contain ancillary information?
Does the system allow dating, versioning, authorship, comment text
on a link? If so, how is it displayed and accessed? This sort of
information complicates the issue, in that readable information is
no longer carried within node contents only. Pretty soon, following
this path leads to a link becoming a node in itself, annotatable and
all. This perverts the data model significantly, and I cannot see
that that is a good idea. Information about the link can always be
put in the source node, or in an intermediate node, for example an
annotation. However, this makes tracing more difficult. It is certainly
nice to be able to put a comment on a link. Perhaps one should make
a link annotatable. I think not.
Should a link contain Preview information?
This is information stored at the source to allow the reader to check
whether he wants to follow a link before he goes. I feel that the
system may cache some data (such as the target node title), or the
writer of the node may include some descriptive material in the highlighted
spot, but it is not necessary to include preview information just
because access may be slow. Caching should be done instead of corrupting
the user interface. If you have a fast graphic overview , this could
remove the necessity for a preview function.