In hypermedia, information is represented at the lowest conceptual
level by means of two basic information objects; links and nodes.
Even should the different hypermedia systems be quite unlike,
most systems are constructed on these two information objects.
This is probably the most important common trait for hypermedia
systems. This lesson examines the basic information objects.
The basic information objects are primarily conceptual entities
of the user interface, though they may also be logical entities
in the information model of some hypersystems, such as Intermedia.
The information model in other systems, such as Neptune (Delisle,
Schwartz 86), consists exclusively of the logical entity node,
and the link is a component of the node, whereas some other systems,
such as Xanadu (Nelson 90), may have information models comprising
nodes, links and composite information objects,. These topics
will be dealt with later in this lesson.
Links and nodes further constitute the basis for what we have
chosen to call composite information objects. These information
objects, for example database diagrams and various hyperdocuments,
reside on a higher level than links and nodes.
The second part of this lesson deals with composite information
objects. Please note that composite information objects may be
represented by nodes, e.g. NoteCards database diagrams are located
in nodes (Halasz, Moran, Trigg 87).
Links connect nodes. This means that links connect the information
units which constitute nodes. As early as 1945 Vannevar Bush described
a mechanism to move from one information unit to another. Bush
writes (Bush 45):
"When the user is building a trail, he names it, inserts
the name in his code book, and taps it out on his keyboard. Before
him are the two items to be joined, projected onto adjacent viewing
positions. At the bottom of each there are a number of blank code
spaces, and a pointer is set to indicate one of these on each
item. The user taps a single key, and the items are permanently
joined. In each code space appears the code word."
He goes on to say:
"Thereafter, at any time, when one of these items is in view,
the other can be instantly recalled merely by tapping a button
below the corresponding code space."
We thus see that Bush not only has described the link mechanism,
but that he has also formulated the requirement that following
links should be speedy and simple, in that the referenced node
should appear at the tap of a key. Moreover, the link must have
a name.
These features are typical of hypermedia links. In step with hypermedia
development, hyperlinks have also developed their functionality.
The following sections describe link structure and functions.
According to the definition in the previous section, links are
connections between nodes. Nodes can be connected in different
ways. We have chosen to use the term link categories about the
different classes of links, each handling different tasks in the
hypersystem. Links are commonly categorised into organisation
links, reference links and search links, used by among others
Conclin (Conclin 87, p. 33 - 34). With some reservations we shall
also use these categories. In place of search link we prefer to
use the more general term function link, which also comprises
search links. A more detailed division of links has been made
by DeRose (DeRose 89).
Organisation links handle the primary structure of a document,
hence keeping it together. The corresponding structure in printed
material may be the division into chapters, sub-chapters and sections.
In his article Conclin presumed that such structures are hierarchical,
so that links refer to either parent or child nodes. However,
other structures have also been discussed in the literature on
this field. This is dealt with from section 3.2.1 onwards. Therefore
we will not assume that organisation links represent a particular
structure.
Several hypersystems assume that a hierarchical structuring of
hyperdocuments is the most common approach. These systems therefore
only feature hierarchical organisational links. Intermedia is
an example of such a system (Yankelovich, Haan, Meyrowitz, Drucker
88). If another structure is to be used, this may be done using
reference links. For example, a system such as KMS (Akscyn, McCracken,
Yoder 88) allows the user to represent his or her own structures
using reference links, if the document cannot be represented by
a tree structure. Other systems such as Xanadu (Nelson 90) allow
any structuring of a document.
DeRose (DeRose 89) points out that often several structures are
needed within the same document. KMS permits a number of parallel
hierarchies in the same document. As Xanadu can be structured
in any way, this system can also hold several parallel structures.
Some systems, such as Intermedia and KMS, have explicit indications
of organisation links using a link spot, just like reference links.
Link spots are described in more detail in section 2.1.3. As some
systems require a hierarchical structure, moving via organisation
links is restricted to either the parent node or to a child node
(or sibling nodes, if appropriate). Such links do not need explicit
indication, as the user may move to parent or child nodes using
menu options. A system such as Neptune (Delisle, Schwartz 86)
operates a separate mechanism which allows the user to move via
organisation links through list boxes.
Reference links represent document branches which have no direct
connection with the document structure. They are thus references
to other nodes which are of a more random nature. Footnotes and
literature references are examples of such links. Reference links
are usually indicated by explicit link spots.
As there are many types of reference in the various types of document
(e.g. scientific publications, encyclopaedias, dictionaries, text-books),
reference links must be able to handle a number of possible tasks,
perhaps even tasks unforeseen when the hypermedia system was designed.
Most hypersystems are therefore able to specialise links with
descriptive attributes, such as link type and link name. We will
examine this further from section 2.1.2 onwards.
Organisation links and reference links typically represent link
reference nodes directly by a unique identifier connected to the
reference node. Therefore this is direct addressing. Function
links, however, use indirect addressing. This is one or another
form of description of the characteristic of the reference node.
The figure above shows a function link in principle. When the
user follows the link, he would normally not know in advance how
many nodes the link may lead to. The link must thus be assumed
to lead to none, one or many nodes which satisfy the link function.
Search links. These use a search function to find nodes
which satisfy a number of criteria. The search criteria may be
names, content or structure. For example: one query might be to
find "all nodes of the 'reference' type constructed by NN".
Halasz (Halasz 88, p. 846) states that it would be advantageous
to use the same search mechanisms for searches, filtering and
search links. There is a further discussion of searches/queries
in section 3.2.
Vocative links. DeRose (DeRose(89) also mentions another
type of function link called vocative links. These refer to nodes
(or positions within nodes) by means of names (labels). A look-up
means searching for the name of the reference node, which is the
relative address of the node. A negative factor regarding this
is long search time.
The advantage of vocative links is that the reference is dynamic.
This opens for the use of alternative sources for the reference.
An example of such a reference is "(Luke 10,10)" which
gives the same Bible verse irrespective of Bible edition or language.
Procedure links. This mechanism is similar to function
links as it is a link-like mechanism which initiates other processes.
In KMS, link-like areas are indicated in nodes, and these execute
applications, for example a back-up routine. Other procedures
which may be started from a procedure link are sequences featuring
audio, video and animation. Since such procedures do not lead
to nodes, there is some doubt as to whether they may be called
links.
At present, function links are not very common. Generally, search
abilities have not been a regular feature of hypermedia, but there
is an increasing recognition among researchers, including Halasz
(Halasz 88), of the need to exploit various search mechanisms
in hypermedia,. This indicates probable future improvement in
new systems. Moreover, long response times might cause problems
as some queries may be complex.
In many hypermedia systems links have a set of attributes connected
to them, and this really ought to be an absolute requirement for
all hypermedia systems. Attributes increase the semantics of links
and have several purposes. They may make it easier for the user
to select the right link if it is identified with an attribute
name and/or type. Furthermore, attributes are important search
criteria in systems offering search, filtering and search link
options. Other information units may also have attributes connected
to them in systems permitting this. Many of the attributes registered
for nodes equal those registered for other information units.
Nevertheless, the most common approach is that links are typically
registered with attributes. We will therefore examine links in
depth in the next sections, and more summarily examine other information
unit attributes.
Link attributes are not necessarily explicit, and attributes will
in such cases be regarded as logical characteristics of the individual
types of link. For example, the ownership attribute does not have
to be registered for the link itself, but may be handled by the
file system or even by a hyperbase system.
Figure 2.2 shows a typical dialogue box for setting link attributes.
This example is fictive, but the dialogue box has features similar
to Intermedia's.
Link attributes are mostly built into systems which treat links
as separate entities, such as Xanadu, Intermedia and Neptune.
In other systems, such as NoteCards and KMS, the links are node
components, and such systems therefore have less information tied
to each link. In the latter systems node attributes may be said
to apply to links as well, such as ownership.
The link type generalises some features shared by several links.
Usually this information states the purpose of the link. Compared
to link category, link type is a further specialisation of the
link. It must be noted that some systems use the term link type
for link category as, for example, Intermedia does
Examples of two link types may be "cf." and "literature
reference". These are specialisation's of the link category
reference link. Physically their functions are the same in that
they lead to a node. Their advantage is that they make it easier
for the user to decide whether it is interesting to follow the
type of link once s/he has seen what type of link it is.
NoteCards allows the author to decide on link types, hence the
author has to determine the necessary link types. gIBIS features
both fixed and user-defined link types. Systems which allow unlimited
numbers of author-defined link types may cause confusion when
used without restraints. Users may find it hard to cope with ever
new link types. Additional problems may arise when using queries,
as new link types may have been created since the query was formulated.
The query will thus not include newer link types.
On the other hand, being restricted to a small number of fixed
link types may hamper an author's ability to express himself adequately.
Seen from an author's point of view, it would apparently be best
if a hypermedia system could include both fixed and user-defined
link types. The author ought to employ the existing link types
as much as possible, only supplementing these with a limited personal
standard when necessary.
Author. Intermedia registers the link author (owner) as
a link attribute. This allows the system to handle a formal link
ownership, letting the owner be responsible for his own links.
See also access rights below.
Dating. Registering link dates is common, e.g. in Xanadu,
Intermedia and NoteCards. Dates are normally registered automatically
at the time of design. Dating enables filtering and querying according
to link age, and dating may furthermore provide a way of managing
different link versions in systems with version control.
Names. Most hypermedia systems allow some sort of link
naming. Usually the user names the link when it is created. At
other times the name of the referenced node will be used. This
offers a higher degree of specialisation than link typing, and
link names may thus be regarded as an example of a link type.
Names are often placed in the link spot.
Keywords. Keywords offer supplemental information about
the link. This may be exploited especially for queries and filtering.
For example, it enables searching for links which refer to nodes
containing the keywords "groupware" and "hypermedia".
Access rights. These control each user's access to links.
Typical rights are read, write and append rights for various groups
of users.
Link starting points, or the link spot, is the spot or area in
a node which indicates the start of a link. Link representation
may be divided into three different levels, and this tri-level
division approaches the concepts of Yankelovich, Smith, Garret
and Meyrowitz (Yankelovich, Smith, Garret, Meyrowitz 88). The
highest level is the visual representation of the link spot, that
is how the link starting point is indicated to the user. The second
level is the placement of the link spot in the node, that is how
links are placed in relation to each other, and in relation to
information objects such as text and pictures in the node. The
third level deals with how the link is represented in the information
model.
In order to indicate that there is a link in the area, it has
to be made visible to the user. Common methods of making links
visible are to print the link word in a different font or colour,
put it in italics or bold, underline it, place an icon where the
link is, or frame the link or picture area.
At present no common rules have been drawn up for link indication,
though some ideas have been suggested for a possible hypermedia
design language (Evenson, Rheinfrank, Wulff 89). These researchers
have suggested that different links in text objects could have
different icons or symbols to show what is behind the link. They
have also proposed that the link should be placed according to
the word the link goes from.
In some systems the link can be reached in other ways as well.
Intermedia enables the following of links via a drop-down menu.
In Neptune organisation links may be followed via a separate node
browser, where the links are followed according to the organisational
structure of the document. In the latter case it is not necessary
to see organisation links in the node as the documents are strictly
hierarchically organised. The user therefore sees which sub-trees
he may move in at any time, and his movements will thus either
be up or down the tree.
In hypermedia using text links is one of the most common ways
of representing links visually. Text links consist of one or more
specially indicated words. If the link is a word, the word will
often be the link name or reference node name. There are several
ways of indicating text links, for example changing text appearance,
placing link symbols (most often an icon) in the text where the
link starts, or framing the word or words where the link starts.
Changing text appearance may consist of printing text in bold,
underlining it or using italics where the link starts, or using
another text colour or font. However, this might cause certain
problems (Evenson, Rheinfrank, Wulff 89). Evenson, Rheinfrank
and Wulff point out that this kind of text treatment generally
has a particular meaning in traditional printed text. Bold will
often be used in headlines at the start of chapters, underlining
and italics are used to give special emphasis to words etc. Thus
users could become confused if such text appearance is given a
different semantic interpretation in hypertext than is the case
in printed text according to the prevailing norms. In spite of
this, however, such methods are in regular use and appear to function
well.
Using special symbols is another common method used to indicate
links in text, these often being buttons, icons or small bitmaps.
NoteCards and Intermedia use small icons to indicate links, and
different icons represent different link categories or types.
KMS has a similar way of indicating links, but uses text symbols
instead of icons. In KMS, a small circle before the reference
word indicates a reference link, and an organisation link is indicated
by a circle and an "@" and a function link is indicated
by a filled circle.
Figur 2.3 Exampel framing the link and overlapping regions
Another procedure for link indication is framing the link. This
method is used by, among others, NoteCards. This avoids the problems
concerning different text types, but other problems are introduced.
If regions overlap, users may find it hard to distinguish between
them. Intermedia's method for reducing these problems of overlapping
regions is to give overlapping regions a dark frame, while individual
regions are given a light frame. However, as pointed out by Conclin
(Conclin 87), this method only works when there are only two overlapping
regions.
In addition to text link, links may also lie in other information
objects in the node, or outside the node information objects.
A common method is to put areas sensitive to clicking into a picture,
so-called hypergraphics. Links may here be indicated by frames
around them so that the user can see that there is a link there.
Another possibility is to make it apparent from the picture itself
that there is a link under one area of it. An imagined example
could be a picture of an engine cross-section, allowing a user
to examine various engine details by clicking on the area of each
part. A third option is using links that cannot be seen, hidden
links. A user's task might then be to find the links and use them.
This option has up to now been used mostly in games, but might
also be useful in instruction systems.
Links may also lie outside the information objects, being freely
"suspended" in the node. These links may consist of
icons, buttons or text, such as text links. As will become apparent
in the next section, it is not necessarily possible to implement
this type of link in systems which are based on representing the
link spot in an information object, as the link is outside the
information objects.
As well as indicating the link, another normal feature is to have
the mouse cursor change appearance when it is placed on the link
spot. This is often called a "context sensitive cursor".
KMS features this. It highlights the link spot more clearly, especially
starting points which may be hard to distinguish, for instance
picture areas which are not indicated. In the Windows 3.1 help
system, the cursor changes from the normal arrow into the shape
of a hand with a pointing finger.
The previous section described how links may be represented visually,
and furthermore how this representation typically will be placed
in the node. The visual representation may thus be seen as the
way to enable the reading of information in the hyperbase.
The next issue is how link starting points are placed in the node.
The placement of the starting point in the node is determined
by the hyperbase author and the hypermedia system designer. For
those who only read from a hyperbase, this issue is of no consequence
because the screen picture will be the same for a user who is
reading, irrespective of the method used. There are several methods,
each having their advantages and drawbacks, and in this section
we will examine four of the most used methods.
The first method is to represent the start and stop boundaries
for the node directly in the reference object. The second method
is to let the entire link be a separate object placed in the text
so that this object is floating around in the text. The third
method is to let both text and links be separate objects placed
around in the node. The fourth solution is to separate the link
spot representation wholly from the information objects so that
the information object which the link initiates from is totally
separate from the link.
Representing the link area directly in the information object.
This option works well for text objects, and involves placing
a representation of the link start and stop point directly in
the information object where the link is. This may be done, for
example, by inserting special control characters at the start
and stop of each link area in the text. The link word thus becomes
part of the text itself.
An advantage of this method is that links will move around in the text object the same way as other text during editing, as the links are part of the text. Editing links may thus be done in the same way as for the rest of the text. Moreover, new text can be inserted within the link area without changing modes or opening another editor. The link area may thus be dynamically extended or restricted during editing.
One problem of this representation is that standard text editors
normally cannot insert control characters in the text. Hypersystems
employing this method will then have to use a specially designed
editor which can manage to represent the link spot in the text.
Furthermore, the application which presents the link visually
has to be able to interpret the code in order to represent the
link visually.
Another solution to this problem is to use a standard editor to
compose the text, and use special (but legal) characters to indicate
the start and stop points of the link.
E.g.: This is a link: ¤&start%link¤&stopp%
Here the text continues.
Specially designed software must then be used to represent the
text object and the link visually. The link above might then be
presented thus:
E.g.: This is a link: link Here the
text continues.
The link is here indicated by being underlined.
A disadvantage of the latter method is that the author has to
key in the special characters, which might be quite incomprehensible
as in the example above. This might make it hard for new users
to compose a document.
Another disadvantage of this method is that it may be cumbersome
to represent the link in systems where the links are placed as
separate entities in the hyperbase, cf. the next section. This
situation is made more complicated because the links have to be
inserted in the text object after it has been fetched from the
hyperbase. After editing, the links must be separated from the
information object again before being stored.
Links as separate objects in the information database.
This method also lends itself best to text objects, and involves
putting a representation of the link point in a separately encapsulated
object. This method must not be confused with encapsulation and
objects from the object orientation. This object may then float
in the text as a single character which must be edited separately.
Link spot editing may then be performed using a special editor
for this use. This method is often employed to represent pictures
in word processing software, for example Windows RTF. One possible
drawback to this method is that the link may be perceived as not
being a part of the text, as it must be edited separately.
Links as separate objects in the node. The third option
is to let each link and each object be independent objects in
the node and to be freely placed in it. This is the method for
object placement commonly used in desktop publishing.
A drawback of this method is that the author needs to track different
objects in the node, and links cannot be placed inside the text.
This makes this method best suited for typical reader systems,
and less well suitable for hypersystems with frequent additions
and changes to nodes.
Links separated from the nodes. The fourth solution is
to separate the links entirely from the node. The links are then
placed "above" the node. Links may thus be indicated
by a frame placed over the information objects.
This method will be especially easy to realise in systems which
have represented the links as separate entities because the links
will then be separated from the nodes both in the information
model and in the user interface.
The drawback of some systems is that the link position will not
be moved if the linked object is moved in the text. This may happen
if users append a sentence to a text. This will cause the link
region to move, while the link reference still remains in the
previous position. However, pictures and film sequences rarely
change their sizes, hence this method is well adapted for image
media. By automating the process, this method may be used for
text so that the link reference changes in step with the link
position.
Hyper-G, a second-generation WWW application, divorces the links
from the node with automatic updates. This was also the case with
the object database for Winix, which featured much of the structure
now found in Hyper-G.
Links are accessed via nodes. This means that nodes must contain
some representation of the links. As described above, the link
spot may be placed in the node in a number of ways, but the link
itself must either lie internally in the conceptual entity 'node',
or it must be represented externally as a separate entity in the
information model.
Representation by link information internally in the node has
the advantage of simplifying the information model, thereby offering
less complexity in the hypermedia system. The drawback is that
searching for special links is made difficult, perhaps even impossible,
in larger systems. This means that such systems not well-suited
for filtering process tasks. KMS has an internal representation
of the links.
Some hypermedia systems thus have a separate representation of
their links in the information model. Intermedia, Xanadu and Neptune
represent links as separate entities.
Link stopping points are frequently node positions, but may also
consist of an entire node, a link or a composite information object,
another hyperbase or another hyperdocument.
Reference and organisation links usually contain an explicit representation of the node or nodes they refer to, which means that they hold an address for the node referred to. This might be an internal code in the hypermedia system for the node referred to, or the name of the referred node.
Links may be one-way or two-way. In Intermedia, links are represented
by a link point both in the referring document and the referenced
document. Hence such links are two-way. The initial point in one
direction is thus the end point in the other direction. In Neptune,
the link end point is a relative position in the reference node.
In the information model, nodes are atomic objects, therefore
no absolute address may be referenced.
NoteCards connects links' link spots in the referring node to
the whole of the reference node, meaning that the link cannot
reference positions in the reference node. Such links thus are
one-way. The user may nevertheless return to the previous node
as a "return" command has been provided.
In Xanadu links may also reference other links. This allows a
number of nodes which contain links to another node to do this
via a common link. Both Xanadu and Neptune feature linking to
a particular version of a node.
Function links are naturally one-way, as functions find their
reference nodes at the moment when the user follows the link.
Such links thus refer to each node as a whole. Returning to the
referring part depends on a "return" option.
Nodes are elementary information objects which contain links and various information objects. The information objects consist of multimedia information. We will not go into detail concerning multimedia information representation.
Figure 2.4 Screen display from NoteCards comprising four nodes. The figure is from Halasz, Moran, Trigg 87.
(The node text is of no significance for the course and merely
serves illustration purposes).
Figure 2.4 shows a screen display from Notecards with some typical
nodes. Each node consists of a window with a single information
object. In the figure there are three text nodes and one graphics
node. Links are indicated both in the text nodes and in the picture
node. Links are indicated either with an icon or as framed text.
The topic of this hyperdocument must be said to be outdated! Luckily!
Similarly to links, nodes may also have a set of linked attributes.
Many of these are by and large equal to those registered for links,
with the same semantic meaning. See section 2.1.2 for an examination
of these attributes.
Name. The node name is normally set by the user when creating
the link. The node name is usually also the name of the window
in which the node is rendered.
Type. Generalisation of nodes with the same meaning (semantics).
Two nodes of the "see also" type have the same meaning
but may have widely different content. In Neptune/HAM, nodes of
a particular type contain a number of joint attributes. Neptune's
node types are created freely by the author. gIBIS has four fixed
node types, where different node types handle different information
types.
Intermedia and NoteCards have opted to associate the term 'type'
to the information objects contained by the nodes. This results
in one node type for meta-graphics, another for text etc. This
will be examined in the following section, 2.2.2.
The individual nodes may also share characteristics, independently
of node semantics. This may apply to such things as placement,
information content and connection to other nodes and links. These
characteristics may be placed in node templates, which are a mechanism
allowing the author to retrieve "pre-fabricated" nodes
while composing. Structure templates and node templates will be
dealt with in more detail in section 2.2.5.
As attributes largely have the same semantic meaning for links and nodes, in many cases it may be unnecessary to use the same attributes both in links and in nodes. Considering one example, we might have a user who follows a link of the type "literature reference". The user might then reasonably expect the reference node to be a literature reference. It should therefore not be necessary to type both the link and the node as "literature reference".
This also applies to queries. If a user searches for nodes which
are literature references, s/he may search for nodes of the type
'literature reference' or for links of the type 'literature reference'.
The main idea is to keep the various attributes in a hyperbase
consistent, for example employing authors' conventions, so the
user knows whether to search for attributes on links, nodes or
both.
In other cases it may be desirable to set attributes for both
links and nodes. After a node is created, new links may appear
which use the node as a referring node. The design date for the
node and the new links will thus be different. In systems used
by more than one person, an author might place a new link in a
node designed by another author. It must therefore be possible
to ascertain who the owner of the node is and the individual links
going from the node.
Thus there are grounds for setting attributes both on links and
nodes. However, in some hypersystems it is not possible to set
attributes for both information units. In KMS, the links are node
components, without their own semantics. Thus only nodes may be
ascribed attributes. The same applies to NoteCards. Intermedia
has link attributes. Links lie within documents, while the nodes
are pure information objects, for example a bitmap file. Xanadu
and HAM can place attributes both on the links and on the nodes.
User interfaces commonly represent nodes in separate windows.
Intermedia and NoteCards are typical examples of this. The node
will thus be treated as a regular window, and standard windowing
operations may be applied. The node name becomes the window title,
and the window can have a title, an icon and standard windowing
operations. Usually a number of nodes may be open at the same
time.
Nodes may also be represented in frames, KMS being an example
of such a system. In KMS all the nodes must be contained in a
frame of a certain size, representing 1132 x 805 pixels.
In Neptune nodes may be represented by means of two different
tools, a node browser and a document browser. Using the node browser
a user may follow the nodes from link to link in the normal way.
New links and nodes may be constructed from a node browser. A
document browser is a specialised tool which allows the user to
follow the structure of hierarchical documents, the organisation
links. A user may thus quickly navigate up and down in the document
hierarchy. New links and nodes cannot be constructed in the document
browser, and since it is designed for hierarchical documents,
it will not work for other structures.
Xanadu is not designed for specific hardware platforms. Xanadu
is primarily a storage model, and node presentation is left to
the application developer. The requirement is that node information
objects may be interpreted by application. Nelson uses a wide
node definition, considering margin notes, footnotes and bookmarks
as separate nodes (Nelson 90, p. 2/24). The Windows' help engine
also uses nodes of different appearance. There are two types,
a look-up node and a regular node.
Nodes with different visual representation may therefore be considered
to be different category nodes. This will undoubtedly enlarge
the system. The information model must be able to represent a
number of node categories, and the interface must be able to present
nodes of various appearance, for example different types of windows.
Some hypersystems limit the types of information object each node
may contain. In NoteCards and Intermedia, nodes may contain only
one information object, and only of one type. There is a class
of nodes for each type of information object, i.e. one for text,
one for raster graphics, one for meta-graphics etc. KMS and Xanadu
can represent several types of information in the same node.
Nodes must represent the information objects they contain. The
simplest representation is used in Intermedia. The node here consists
of a single information object. The links and other information
lie externally in the document information. The same node may
thus be used for several documents, perhaps in different contexts.
Another representation is found in KMS, where several information
objects are represented within the same node. Each node with its
information therefore constitutes a unit. The nodes may contain
different types of information, such as graphics and text. The
drawback to this is that the same information must be stored explicitly
in each node.
A third way of representing information is via references to external
information objects. This principle is shown in the figure above.
The advantage of this method is that the information objects are
not removed from their context. Information retrieved from an
external database may for example be updated independently of
the hypermedia system itself.
These methods may also lend themselves well when the information
cannot be physically represented directly in the node. The information
objects may be statically located on a CD-ROM disc or a video
disc. The same information might also be used in many contexts
in the hyperbase. This representation is used in gIBIS and Xanadu.
These solutions may also be combined. Files used to generate Windows
help files represent text information directly, while graphics
are represented by means of references to separate files.
In the previous section we discussed node representation in the
information objects, and in section 2.1.3.1 we discussed node
representation of links. The nodes themselves also need representation
in the information model. In most hypersystems nodes are separate
entities. Nodes may thus be used for regular database operations
such as look-ups, deletion, creation. Furthermore, operations
such as queries and filtering may be performed on sets of nodes.
Xanadu and Neptune/HAM are systems which represent nodes as separate
entities. Nodes are here linked to a selectable set of attributes.
Intermedia does not represent nodes as separate entities, rather
they are composed of a single information object and a description
of the node lying in the hyperdocument. On presentation of the
node the hypersystem will therefore retrieve the node's information
object and then connect the links with their attributes from the
hyperdocument. The sum of the parts then constitute a node.
There are often common features between different nodes. This
may be reflected in attributes such as link type, and in common
behaviour such as link category. However, the common characteristics
may relate directly to information content and to connections
to other information units. One example is the hyperbase in "The
Perseus Project" (Crane 91), which was also mentioned in
the introduction. This hyperbase contains, among other things,
a register of objects (vases) found in archaeological excavations.
Each object is registered with a small amount of information,
typically consisting of three to four pages of text, 22 pictures
of the object, links to 30 other objects for comparison, and literature
references.
To manually construct new nodes and structures which are approximately
equal to the previous ones time and again is not a good solution
for an author. In the above example the author must construct
a large number of nodes and links for each object to be registered.
Some of the information objects may also be placed in the same
location in the node. Neither is this a good solution for the
author. It takes time, he or she may grow weary of the whole process
and forget what was supposed to be placed in the new nodes.
One way of alleviating these problems is to use node templates.
This is a way of quickly creating new nodes based on a node template.
Firstly, the template may consist of information concerning the
individual node, such as the location of information objects,
the node's size, common attributes etc. Secondly, the template
may in some cases represent complete structures. The structure
will be links placed in nodes, and the construction of new nodes
will be based on these links. The new nodes made on the template
will be empty, but the location of new information objects and
links may be indicated.
Node templates are usually accessed via mechanisms outside the
hyperbase itself. Nodes and links, if any, generated by a template
will thus be independent information units, and the complete structure
can not be addressed as a separate object. Systems featuring node
templates are extensions of NoteCards (Jordan, Russel, Jensen,
Rogers 89) and Intermedia (Catlin, Garret 91).