[]
DejaVU Online
-- Project DejaVu (1992)
[]
-
[up]
[up]
introduction
background
hypermedia
components
studies
conclusions
Hypermedia research goals
In the last decade we were able to witness a rapid
growth in hypertext and hypermedia research.
This has resulted in a number of systems,
eg. KMS [Akscyn et al, 1988], Intermedia [Meyrowitz, 1986], Notecards [Halasz, 1988].
An overview of these systems and a more general
introduction to hypertext is given in [Conklin, 1987].
See also [Shneiderman and Kearsley, 1989] and [Akscyn, 1990].
The idea of hypertext dates back almost half
a century. See for example [Nyce and Kahn, 1991] for the historic
background.
Reflecting on the development of Notecards,
[Halasz, 1988] lists a number of research issues that
were not adequately addressed by the systems
existing at that moment.
These research issues concerned both the
architecture and design model of hypertext
systems as well as user aspects and authoring issues.
In a follow-up speech [Halasz, 1991], discusses the
dilemma's faced by hypertext/hypermedia development
groups, dilemma's with respect to the functionality embodied
in documents and links,
and dilemma's with respect to the generality
and functionality of retrieval and navigation mechanisms.
Most of the dilemma's sketched may be regarded
from an architectural perspective,
in that they may be translated into a preference
for a particular architectural solution.
In the following section we will examine a number of these
issues.
Link varieties
Basically, hypertext is just a collection of nodes
(documents) and links (expressing relations between documents).
Evidently, for hypermedia, documents may take a number
of forms. Less evident is that links may exist
in a number of ways.
In this section we will more closely
examine the nature of links.
We will discuss the way
links may impose structure on a hyperdocument,
by what means we may represent links,
how to employ knowledge-based processing
to support 'inferential links',
and finally we will discuss the pros and cons
of intrinsic versus extrinsic links.
Referential versus structural links.
Currently, there is a lively debate
in the hypertext community whether to support the means
to deal with structured collections of documents
in addition to the traditional referential links
that represent arbitrary associations
between documents.
To our mind, there are strong arguments in favor
of supporting structural links as a means
of representing the hierarchic structure of a compound
document.
Structural links are essential to produce
a linearized version of a hyperdocument.
Moreover, structural links allow for user defined
semantic checks,
whereas referential links are by nature
arbitrary.
Implicit versus explicit links.
Another question with respect to the architecture
of hypermedia systems is whether links
between documents must be represented explicitly
or implicitly.
Explicit links have the advantage that they are
directly (that is efficiently) available.
However, implicit links that are computed in
a particular information context do have the
advantage of flexibility and are functionally
more powerful.
Structural links are likely to be explicitly
stored in as far as they represent the hierarchic
structure of a hyperdocument.
However, for 'guided tours' or
tutorials based on a user model, which may also
be considered as represented by structural links,
it may be more convenient to employ an implicit representation,
in order to be able to adapt to the users need.
Direct versus inferential links
Our research interest is directed towards
exploring the use of what we like to call
'inferential links',
links that are computed by processing
the knowledge available at the time the
link needs to be established.
In contrast with
other links, including implicit links that
are the result of evaluating a function,
the functionality of inferential links
is characterized declaratively by a number of
knowledge rules.
To our mind a knowledge-based approach
is valid for both structural and referential links.
For example a guided tour may depend on answers
provided by the user.
Similarly, the importance of an annotation
may be decided by simple rules.
Intrinsic versus extrinsic links
A distinction that is somewhat analogous,
yet distinct from the distinction between
implicit and explicit links is that between
intrinsic and extrinsic links.
Intrinsic links are links that are somehow embodied
in the document and hence physically
connected with the actual document.
Extrinsic links, in contrast, may exist
completely independent of the actual document.
As an example of extrinsic links between
two documents, one may think of the relation
between coordinate positions of the bitmaps
representing the documents on a screen.
Another example is a relation between
documents expressed as file positions.
A definite advantage of extrinsic links is the fact that
these links may be stored independently of the actual
documents involved.
However, extrinsic links must be considered dead
links, since they will not reflect any change
in one of the documents, which clearly is
a disadvantage.
The tradeoff between intrinsic and extrinsic links
is a point of future research.
One possible solution here might be to
develop appropriate update protocols.
Document types
Evidently, hypermedia must support multiple
types of documents, such as ordinary text documents
but also sound samples and video images.
Active documents
Hyperdocuments are intrinsically active, since they must support
the dynamic interpretation of their contents as commands.
As an example, an ordinary referential link is an active spot
in a document since it allows the passage to related documents.
Multimedia documents are active in yet another sense.
For example, a document consisting of sound samples
may be considered active since displaying such a document
requires sound generation activity taking place
independently from the other processing involved.
In order for a user to manipulate such documents,
a handle must be available to display a sequence of
sound; and in addition, to integrate a document
of this kind in a hyperdocument, handles must
be provided to store links and annotations
for specific positions in a sequence.
Documents as objects
There is a close analogy of (active)
documents to objects (in the sense of OOP).
Documents, containing data of some sort,
must support methods that enable to view or display the
information contained and methods that allow
to relate parts of that document to other documents
by means of links.
Naturally, such objects must in some way be persistent,
since hyperdocuments (including the links)
must survive multiple sessions.
Multimedia (document) objects
must support autonomous (concurrent) behavior
in order to mediate the synchronization between
user requests and the devices in use.
An additional argument for employing
active objects (active in the sense of Active C++/DLP)
to represent multimedia documents is that active objects
are convenient for simulating the behavior
of active documents in the absence of a working device.
In other words, active objects provide
the flexibility needed to model the behavior of
a multimedia hyperdocument in a more abstract way.
Cf. [Gibbs, 1991].
Semantic constraints
One research issue of particular interest
is how we may model constraints
related to document types in a generic yet
flexible way.
One could think for instance of defining the structure
of a document by means of as SGML-grammar (for ordinary text)
or a HyTime specification (for time-based material).
However, in addition to specifying the syntactic
requirements we also wish to be able to check
for semantic constraints laid down in for instance
rules that specify the dynamic behavior of
a document.
Our intent is to employ the inference
capabilities of DLP for this purpose.
A problem still, however, is how to define
such constraints in a rule-based form.
Hierarchic contexts
Many of the current hypertext/media systems treat an application
as a large unstructured collection of documents connected by arbitrary link,
e.g. NoteCards [Halasz, 1988].
In contrast,
the Intermedia system allows the user to construct so-called
webs that provide a context for connecting documents.
The same document may occur in different webs with different
connections.
In addition to a context mechanism as provided in Intermedia
we like to explore a notion of hierarchic contexts
that automatically provide structural links
and may also be used as a mechanism to inherit shared
information.
Such contexts may be used both as a single (compound)
document as well as a collection of separate documents
that may each be accessed individually.
Hypermedia command languages
Another important research issue, pointed at in [Halasz, 1988],
concerns the means offered to authors of hypertext/hypermedia
systems to develop applications.
Scripting languages provide these means in a flexible way,
and may also be used by end-users to customize an application.
Currently, there are a number of scripting languages,
eg. Toolbook, HyperTalk, that support the development of hypermedia
applications.
In a recent lecture, Alan Kay remarked that there are over 750.000
people using HyperTalk, most of which are non-programmers.
Having established the need for an easy-to-use
hypermedia command language, we must remark that the scripting
languages that exist offer rather limited functionality,
or if they do it is in the form of a rather unstructured collection of
ad hoc solutions without a firm semantical basis.
See for example [Younggren, 1988].
Embeddable command languages
We believe that a hypermedia command language must be usable both in
a shell like fashion, to enable the construction of simple scripts,
and in the context of a compiled program,
to allow the development of more complex, yet efficient, applications.
Research concerning embeddable command languages is reported in
[Ousterhout, 1990] and [Ousterhout, 1991], which describe respectively Tcl,
an embeddable command language interpreter (embeddable in C programs)
and Tk, an X-windows toolkit based on Tcl.
As a first step in developing the environment we envisage,
we have developed the hush class library,
the C++ programmer interface to Tcl/Tk.
Interprocess communication
The approach taken in Tcl allows for an application
to have commands executed by command interpreters of other
applications. To achieve this, Tcl employs the X-windows
application manager to register existing interpreters and
to exchange commands.
Such an approach is of particular importance for hypermedia
applications since it allows to dispense with large monolithic programs
in favor of a number of small (cooperating) processes.
In particular, this allows for incorporating a variety
of software (such as a debugger or network
communication programs) in a seamless way,
that is consistent with the overall look-and-feel of
the application.
Declarative specifications
A hypermedia command language must be both easy to use and functionally powerful.
We wish to provide a language that allows to specify a hypermedia
application in a declarative way (to the extent possible).
We intent to explore the employment of logic-based
languages in this area (and in particular the distributed logic programming language
DLP) since these have a clear and easy to understand semantics
yet great expressive power.
Research in this direction has been reported a.o. in [Anjewierden and Wielemaker, 1989],
which describes an extension of Prolog with object oriented graphics
primitives.
We expect that, in combination with Active C++ and
the hush library, the use of DLP will enable
us to provide high level support for the
development of distributed (intelligent) hypermedia systems.
System implementation issues
With respect to the development of graphical user interfaces,
we have studied a number of toolkits.
[Hansen, 1990], [Linton et al, 1989], [Ousterhout, 1991] and [Young, 1990].
For our purposes we need a toolkit that fits in smoothly with Active C++.
In our group we have developed a pilot hypermedia system
with the InterViews library [Linton et al, 1989].
A drawback of InterViews, however,
it turns out that it is rather complex to use.
Another disadvantage of InterViews is that it
supports only a limited number of the widgets
commonly used in graphical user interfaces.
In contrast, many of such widgets are available
for example in the OSF/Motif widget kit. [Yo
A possible route to incorporate such a widget kit
in C++ is by using the wrapper classes provided
by the WWL library. toolkit
The WWL widget library [Fekete, 1992]
implements an approach that does allow the integration with programs developed
with OSF/Motif and other kits on top of X-windows,
by providing a wrapper mechanism that enables a flexible use
the C-based Athena, OSF/Motif and HP widget kits in a C++ context.
However, the drawback of this approach
is that it provides only a very shallow object interface,
clearly lacking the elegance of the InterViews
library.
A radically different approach to developing
graphical user interfaces is represented
by the Tcl/Tk toolkit.
The Tcl/Tk toolkit offers a large number of widgets
and a very flexible environment for rapidly
developing graphical user interfaces by means of Tcl
scripts.
Moreover, Tcl scripts defining interfaces are
easily coupled to applications developed in
C/C++.
However, we felt that the C programmer interface provided
by Tcl/Tk was not adequate for our approach.
Hence (to have the best of both worlds)
we developed the hush C++ interface to Tcl/Tk
in a style reminiscent of InterViews.
The hush class structure is, however, considerably
less complex than the class structure of InterViews.
Yet, it inherits in a natural way the rich
functionality offered by Tcl/Tk.
[]
-
[up]
[up]
introduction
background
hypermedia
components
studies
conclusions
