Papers in PDF format

aspect of many modern systems. Indiscriminate use of links, particularly in large distributed systems, has led to tangled
and mismanaged webs, frustrating for system managers and users alike. In Section 3 we discuss the structuring of data
in ways that can minimise the use of links with no loss of functionality. In this section we discuss why it is important
that links should be:
Not embedded in the documents themselves (see Section 2.1)
Bi-directional (see Section 2.2)
Typed (see Section 2.3)
Why Not Embedded?
The fact that links are imbedded in the documents themselves is a major limitation of first generation systems. We
believe that the only practical way to keep referential integrity, particularly in large hypermedia systems, is to store and
maintain the links in a separate link database. At the very least, links to documents that are removed should be
automatically un-highlighted - as is currently implemented in the Hyper-G system [Maurer et al., 1993a, Kappe et al.,
1993, Kappe et al., 1994]. Other interesting options are outlined in [Lennon and Maurer, 1996]. The Hyper-G system
also supports ``open" anchors which remain un-highlighted and inactive until such time as the link is automatically
resolved when the ``missing" documents are added to the system.
Another significant consequence of having non-embedded links is that it enables anchors to be placed in non-standard
objects such as movies, postscript files, and even the texture maps on 3-D objects [Andrews et al., 1995a, Maurer,
1996].
Finally, as we shall elaborate in Section 5, links that are stored in a separate database may have user rights associated
with them. This fact alone has far-reaching consequences.
Why Bi-directional?
The second requirement for links is that they be bi-directional. Bi-directional links have the following advantages:
Minimisation of the dangling link syndrome. When links are bi-directional, all the documents that point to any
particular document can be located. In large systems this provides the only practical means for notifying authors
about impending dangling links.
Automatic link maintenance. As we have mentioned, the Hyper-G system automatically de-activates links that
would point to a deleted document. This is only possible in a system with bi-directional links stored in a separate
link database.
Navigational maps. Much better navigational maps can be provided using a structured system with bi-directional
links. Several graphical browsers such as Hyper-G are providing history trails and three-dimensional maps of the
hyperspace [Andrews et al., 1994].
Statistics. The only way of collecting statistics such as ``who points to this document?" is by following links
back to their sources.
Why Typed?
Future systems should support a set of predefined link types, as well as user-defined link types. The document entitled
``What is a Link Type & How Many Are Enough" contains an interesting summary of a USENET discussion
[Trickel1996, 1996]. The discussion originated from a posting that commented on a quote from Conklin, ``Trigg
describes over 80 such links" [Conklin, 1987]. The lively discussion supported the view that users should be able to
define their own link types. NoteCards [Halasz, 1988], for example, ``supports an infinite number of link types"
[Trickel1996, 1996]. It is important that there be equally good support for link types in WWW systems [Lennon and
Maurer, 1996] - particularly for link filtering, by the type of document or by link author.