283
25. Second Generation Hypermedia II
25.1 Introduction
Previously we have defined the following properties of Second Generation
Hypermedia Systems:

Ability to store and work with a metainformation

Ability to define and browse hypermedia composites (collections of nodes and
links)

Automatic maintenance of the hyperweb

Global typed links separated from a document’s contents

Automatic support of the referential integrity

Extensibility and tailorability (i.e. customization of a hyperweb to suit the needs
of a particular user)
We have discussed, in particular, the first three of the above. In this chapter we shall
discuss the remaining three issues as they have been implemented in Hyperwave.
25.2 HyperLinks
WWW stores links directly in source documents as so-called “anchors”. The source
anchor is the visible representation of the link from which one can follow from (click
on the highlighted area) to go to the connected document, which in turn is represented
by the destination anchor. The anchors may appear anywhere in the document. In
text documents for example, they are created in HTML by using a HREF reference to
a URL. Thus, first-generation WWW links are:

Type- or attribute-free, in that no meta-information (e.g author, access rights,
keywords, type, date, etc) is kept

Unidirectional, in that one can go from the source anchor to the destination, but
not vice-versa

Embedded, in that the link is stored directly in the HTML document itself and
relies on the actual physical location of the document, that is the URL. Thus when
the destination document is removed or re-located, the reference to it is no longer
valid (“dangling”) and the document cannot be fetched.
284
25. Second Generation Hypermedia II
Figure 25-1: Simple link to another reference
Unlike WWW, Hyperwave stores links that are separate from the documents
themselves in a database. A link is modeled by a source anchor, attached to the
source document on one side and to a destination anchor or a whole destination
document on the other. The destination anchors allow the making of links to selected
portions of a document (for instance, a paragraph of a text document, a fraction of a
large map, a few bars of a piece of music).
Figure 25-2: Separate link database
Links are separated from documents have the following advantages (over storing links
directly in the source documents):

Links are bidirectional. This implies that it is possible to find the source document
from the destination and so you can navigate not only forwards, but also
backwards from the destination to source. More interestingly is that you can
generate link maps that show both incoming and outgoing links around a certain
document (see Figure 25-3)
Figure 25-3: Link map showing both incoming and outgoing links
25. Second Generation Hypermedia II

285
The bidirectional links can guarantee link consistency. For example, if a document
is removed, links pointing to it are removed as well. In Hyperwave, they are
actually tagged as “open”, i.e. the link is not visible to the end-user, but
visible/known to the document owner. When the document is re-instated, the link
is made visible again to the end-user.
Figure 25.4: “Removing” links of a deleted document

Links are realized as objects that contain characteristics or attributes (most
importantly, the anchor’s Position and the LinkType). They may be assigned
keywords and are searchable. For example, “Find all links with keyword ‘C’
attached”.
Figure 25-5: Link attributes
286

25. Second Generation Hypermedia II
Links may be assigned individual access permissions. This means that certain
links in a document may only be visible (accessible) to certain users or user
groups.
Figure 25-6: Controlling access rights

All types of documents may be made to link with each other because the anchor
positions are stored separately from the document itself. For example, one can
deal with links in MPEG video streams without a need to modify or extend the
MPEG standard. When showing the movie, the movie player receives both the
MPEG stream and the associated anchor objects, and shows both.

Creating and manipulating links do not require modification of the documents the
link is attached to. Creating interactive links is thus easier.
Figure 25-7: Linking read-only documents
However, it also means that creating a link to or from a document does not require a
write permission for the document. This is useful for attaching links to read-only
25. Second Generation Hypermedia II
287
documents. For example, data on CD-ROMs or other servers to which the server
cannot write. Automatic link generation is further simplified.
A simple decision to separate links from the document’s contents can bring about
many advantageous features, one of the most important being the automatic support
of link consistency for referential integrity.
We next look at other features that can help customise a hyperweb.
25.3 Alternative Cluster
One of Hyperwave’s structuring facilities is the alternative cluster (cluster, for short).
In a cluster, one can combine documents with the same or similar content but
different appearances. For example, different explanations (text, audio, video) of
documents in different languages, etc.
Figure 25-8: Embedded clusters
Clusters can be referred to or embedded as ordinary HTML documents or media
objects. Only one of such cluster members is dynamically selected whenever the
document is presented to a client. To select a cluster object, the system uses special
information defining a particular user’s profile or preferences.
It may also be the case that the same contents must be presented in different
languages or that a certain media type must be mapped into another type because the
former cannot be visualised by a particular hardware/software configuration or cannot
be perceived by a particular user.
A multilingual document can consist of a cluster that comprises some languageindependent objects and some language-dependent objects of the same document
type. When the cluster is displayed, all the language-independent members are
displayed and, depending on the language the user chooses, one of each type of the
language-dependent document is displayed. Any document with more than one title is
regarded as language-independent. For example, a picture may have one title in
English and another in German. Or, one title could be in “lay” language and the other
in an “expert” language.
288
25. Second Generation Hypermedia II
Figure 25-9: Only one cluster member gets selected
Individual clusters are easily created using a Hyperwave client. Once created,
documents can be inserted as one would do for a collection.
25.4 MultiCluster
Another Hyperwave’s important structuring facilities is the multicluster. In a
multicluster, all documents are combined in the same way as in an alternative cluster.
Once a multicluster is accessed, all its elements (members) are shown together as a
new composite document. The multicluster pools together many single media items
and presents them as a single “multimedia document”. Text and images can then be
shown together along with the simultaneous play of an audio track Thus pages can
consist of small elements, separating an internal structure and content.
Figure 25-10: Single multimedia document from a multicluster
Suppose we have a repository of small documents (D1 – D6, in this particular case).
We are selecting now four documents: D2, D3, D5 and D6 to concoct a new
document. We form now a new document just by selecting the four documents in the
multicluster. This is very useful for many applications (see Figure 25-11).
25. Second Generation Hypermedia II
289
Figure 25-11: Generating a new document in a multicluster
25.5 Conclusion
The Web is fast evolving. Second-generation systems such as Hyperwave certainly
has far advanced features compared to the simple, flat, node-link models of the
prevailing first generation system. Compared to the first generation system,
Hyperwave data is structured (into collections, clusters and sequences). It has metainformation attached, its data is cleanly separated from the user interface, and its links
are kept in a separate object-oriented link database.
Let us conclude by looking at how we are able to customize a hyperweb to suit our
needs because the second-generation features give us greater extensibility and
tailoribility.
Links in Hyperwave, as we know, are not embedded in the documents. If links are
embedded, they cannot be removed automatically from other documents because you
have not authored that other document. By keeping the links in a separate database,
you can also add links to documents that do not belong to you.
For example, sometimes, you find a document on the Web and you want to make a
private remark to that document like a yellow sticker in real life. Note however, the
document does not belong to you and the author barely would allow you to modify
the source HTML text. In Hyperwave, you can do that by adding your own links
emanating from a document authored by some other person. Whenever you return to
that document, you will see the anchor made before.
The anchor can be only visible to the author (private link). If the link is visible to a
whole user group, the members of that group can create new links to this particular
note.
The other feature we have seen is also about links having attributes which can keep
information about the title, author, access rights, modification dates etc. This allows
link flitering, i.e. certain links should be only visible to certain persons. It also allows
you to, for example, distinguish between links that point to footnotes from other links.
290
25. Second Generation Hypermedia II
It can allow you to say “show me only the documents that were modified in the last
week”. This is useful in collaborative work environments.
The most important point is that it allows you the cutomization of material.
Let us look again at an example from Web-based training. Suppose we have six
educational modules A to F, and we have three users each with different learning
profiles. We want to supply them with different modules according to their
preferences.
Figure 25-12: Different users and individualized links
There exists a number of ways of solving this problem. Thus for example, we can
define three user groups: “ABEF”, “DBC” and “ECBD”. For each user group, we
define a set of links.
Now you can see what happens. If a user from the user group “ABEF” logs in, only
the “A-B-E-F” links are visible. If a user from the user group “DBC” logs in, only the
“D-B-C” links are visible. And so on.
The advantage of this solution is that no copying of modules is done, and if we have
to make a correction/modification in one module, the correction will have to be done
only once.
There are many other possible, exciting, customizable applications not thought of
before that can now be developed with the power of second-generation hypermedia
systems.