HYPERNET:
A TOOL TO CHOREOGRAPH WORLDWIDE DISTRIBUTED HYPERMEDIA DOCUMENTS
NENAD
MAROVAC and LARRY OSBURN
Department
of Mathematical Sciences, San Diego State University, San Diego, CA 92182
Abstract-HyperNet
is an authoring and browsing system facilitating creation and navigation of
multimedia documents. It is conceived and designed to provide a mechanism for
very fast choreographing and configurating of hypermedia documents. This system
provides to the users a hypermedia integration and browsing envi ronment to
document component databases distributed across the world, provided they have
access to the Internet network and are valid HyperNet sites. The intention was
for users to be able to search for and retrieve documents stored locally and/ or
remotely, while the access mechanism being completely transparent. This system
was implemented and tested with a suite of hypermedia document components which
were distributed over southern California and Europe.
I. INTRODUCTION
Each
day we see more applications incorporating the hypertext paradigm originally
conceived 45 years ago [I]. Interest for potential applications in hypertext and
hypermedia documents are constantly increasing.
In
current hypermedia and hypertext systems, there are two limitations that we wish
to consider in this paper. First, hypertext systems * commonly support hypertext documents that have fixed
organization and content. It is true that hypertext machines are in ex
istence today. These are hypertext systems that enable users to create their own
hypertext documents with predefined structure and arbitrary content [2].
How ever, there are not many systems that provide users with tools to
routinely and rapidly design, choreograph, and assemble hypermedia documents
with arbitrary structures and content.
Second,
current systems do not provide features that enable a group of users,
distributed worldwide, to compose hypermedia documents from components that
exist in a worldwide distributed· database. Such need arises, for example, when
a number of profes sionals are working cooperatively on a document, or in
an international corporation when a number of people are assembling a business
report. Typically, current hypertext and hypermedia documents are lo
calized to either one computer or to one local area network
environment.
2. HYPERNET
HyperNet
addresses both of these limitations. It is a hypertext system supporting
creation, distribution, and browsing of hypermedia documents with links to
remote document components. It is not intended as a tool to organize ideas and
the creative process of an individual [3], but more as a vehicle for producing
an environment for the cooperative creation and use of hypermedia documents
within a group of people who
* Through the remainder of this document we will use the
term hypertext to denote both hypertext and hypermedia documents, unless there
is an explicit reason to differentiate.
are
dispersed geographically. Furthermore, a large em phasis was made to design
a system that would enable us, at some later stage, to introduce as much
intelligence as possible in the process of browsing multimedia doc uments.
The typical applications we envisage for the system is production of education
materials, scenarios for TV programs, and software engineering develop
ment. The last applications is a topic of a separate paper still in preparation
[ 4 ] .
To
meet these applications goals, HyperNet was conceived and designed with three
objectives in mind:
- To
supply a mechanism for rapid choreographing and configuring of hypermedia
documents.
- To
support cooperative authoring, editing, and browsing of hypermedia documents.
- To
provide a working environment in which users and the hypermedia database is
distributed world wide.
HyperNet
is a hypermedia machine [2] in the sense that it is a tool to design, implement
and browse mul timedia documents. It was built as an object-oriented
system. A HyperNet multimedia document, in its cre ation, is defined over a
space of document object classes. Each object class has clearly defined
operations associated with it. A HyperNet document is then an assembly of
components. Each component is an in stantiation of an object class. In
browsing of the doc ument, a HyperNet window is created for each com
ponent when a link to the component is activated. The content of the window is
generated by processing (computing) the component in accordance with the
operations associated with the underlying object class for that component. This
computational processing is completely transparent to the users as they browse
HyperNet documents.
In
the current implementation, HyperNet supports the following functionality:
- Definition
of architecture and content of hyper media documents.
- Creation
of document components as instantiation of object classes.
- Integration
of document components into hyper media documents.
- Storing
of hypermedia document architecture and components into a worldwide
distributed database.
- Search
for and retrieval of hypermedia document definitions and their components. The
search and retrieval capabilities are provided during both doc ument
composition (integration) and its browsing. The search and retrieval
activities are performed completely transparently to the user.
- Display
hypermedia documents on any number of HyperNet screens simultaneously. These
screens can also be distributed worldwide.
- Generation
of global and local overview dia gram[3].
- Generation
and maintenance of history maps and bookmarks [2] .
3.
THE FUNCTIONALITY AND ARCHITECTURE OF HYPERNET
The
functional architecture of the HyperNet is shown in Fig. 1. The figure also
presents the process taking place in "production" and use ofa multimedia
document. In this figure the document related infor mation is depicted
using square boxes and the HyperNet processing tasks are depicted using
circles.
The
square box on the left in the figure, labeled as document script, represents the "source" or "pro grammed" format
for a multimedia document. A doc ument script is a program for a hypermedia
document. It comprises information encoding for the document content interlaced
with markings specifying the archi tecture for the document, as well as the
operations re quired to either compose or browse the document. These
markings are statements in a language called Scripts. Scripts is the HyperNet "programming lan
guage."
In
fact, the functionality associated with the first HyperNet design objective from
section 2 is based on Scripts, its compiler and its interpreter. The language
Scripts is briefly described in section 3 of this paper.
Following
Fig. I we see that a script for a hypermedia document, when completed, is
processed by HyperNet document composer. This composer is a combination of the Scripts compiler
and the document assembly task.
The
composer configures the hypermedia document and produces the target encoding for
the document called the document browse. The target format is suit able for interactive
browsing of the document. It con tains content of the document together
with the in formation about the architecture of the document. It also
incorporates the linkages to all document com ponents (frames).
The
function of the document composer is to:
- Break
the document into frames.
- Establish
links and anchors to these frames.
- Initiate
storing offrames and the definition oflinks into HyperNet distributed data
base.
- Search
the HyperNet database to locate the c( ponents, which are required, but not
included the document script.
- Integrate*
these components into the documer
- Generate
the global overall diagram for the do ment and the local diagrams for each
compon "section. "
The
document is now ready to be used, i.e., brow!
When
a user initiates browse of a hypermedia do ment in HyperNet, the user can
specify either an dividual or a group browse. A group browse can specified as
unidirectional browse or bidirectio browse. If the user specifies a group
browse, then the first frame (main panel) is displayed within a " dow on the
user's screen, an iconic symbol will be c played on all screens corresponding to other U! within
the group. The symbol is labeled with the na of the document and the user
starting the browse. ] presentation purposes we will refer to the user start the
browse as user A and any other users within group as user G.
Any
user G can now open the icon if that user desl to participate in the cooperative
browse. The user tl becomes an active user as far as browsing of that d ument is concerned.
As a user G opens the icon, 1 situations can occur depending on whether the brOl
is unidirectional or bidirectional.
In
unidirectional browse, any user G can see 0 the frame user A selects. All users can edit the cum
frame but only the user A can navigate from fram~ frame.
In
bidirectional group browse, as a user G opens icon two windows appear on his/her
screen, one w
dow corresponds to the user A and
displays the fra user A has selected. In the other window the same fra is
displayed initially, but on that window user G ( browse as he / she wishes
around the document. At same time, a new window, corresponding to that U! is
opened on screens of already active users. These n windows display to all other
users the content of· window under control of that user G. In other wor every
active user has windows for all active memb
* It should be noted that remote components are not ~
essarily fetched during the composition of the document. So components may
instead be fetched during the initial brows of the document at that location.
During the compositior the document these components must be located and ine
porated into the documents through links. Whether they l at that point, also fetched from remote locations
storing th depends on the Scripts statement associated with their ine poration.
If the immediate fetch during the composition the document is requested through
the associated Scri statement, then copies for the components in question
fetched and stored locally, and used in all subsequent brows of the document at
that location until these copies are delet The deletion can be done either on a
request by a user, automatically when the remote originals are modified. T
strategy is used to ensure consistency of instances of docuffil components, and
also to guarantee that whenever a documl is being browsed it only incorporates
the last version of components.
store
and retrieve components
ofthe
group including himself/herself. However, each user can navigate on only one
window. In a bidirec tional browse in HyperNet, a group can have a max
imum of four active users at anyone time.
The
purpose of the group navigation is:
- In
an unidirectional browse, for one user to navigate a passive group of users
through a document, where users G can modify current frames but cannot direct
the navigation. The navigation is under control of the "teacher" or master
user for that session (user A).
- In
a bidirectional browse, we have the full telecon ferencing capabilities,
i.e., full interaction by all users, and complete
cooperative (or chaos) activity on a document.
HyperNet
implements two types of nodes, the win dow frame and leaf frame. The
most common node is the window frame which is a scroll able window con
taining plain text, HyperText, and/ or bitmap graphics. Anchors in a window
frame may link to objects in other window frames or a leaf frame. A leaf frame
contains an object that needs to be specially formatted to be displayed.
Leafframes cannot have links to other frames. An example of a leafframe is a
Postscript object that requires invocation of a postscript previewer to be
displayed.
HyperNet
has two basic types oflinks-explicit
and implicit. Explicit links are links that are emphasized in such a
way as to indicate to the browser that more information can be found on this
topic. This infor mation may take the form of any of the available classes
(plain text, HyperNet text, i.e., Scripts document pro gram, bitmaps, postscript
segment, etc.), and upon ac tivation of the link the desired
window frame or leaf frame will be displayed. The explicit links, which can be
thought of as moving forward or outward, combined with the backup command, which
steps back one frame, and history map allow the browser to navigate the
document space. These links were established by
the
author of the document and are embedded in the document. To minimize the visual
clutter, HyperNet links do not distinguish between different destination
classes, but if a single link provides more than one destination node, then a
drop down menu will provide the user with a choice. Implicit links are links
which allow the browser of a document to navigate the in formation space. That is the information space bounded by the complete
HyperNet database. These links provide more information on a subject, but are
not embedded within a HyperNet document as are the explicit links. Thus, the
browser can choose any word or string in the document and do a search for more
information on this topic. For example, if the word Peru was not emphasized, but
chosen as a link, the HyperNet database will be searched for the keyword Peru,
and the information found will be displayed for navigation. This may take the
form of a definition, postscript picture of South America, or the latest
busi ness activities occurring in Peru. Implicit links are im portant
for the following reasons:
- They
provide links to non-HyperNet documents;
- They
allow links to be dynamic (i.e., the information space of the HyperNet database is
dynamic and will contain information that may not have been avail able at
the time original document);
- They
allow the browser to navigate to wherever he chooses and limits the scope of
what links the author needs to provide.
These
last two points are very important because the author can never completely
anticipate the audi ence's knowledge base or curiosities.
HyperNet
was designed to have a two layer software architecture, as illustrated in Fig.
2. This architecture closely follows the one described by Campbell and Goodman
[2, 7], as presented in Fig. 2a. The kernel ofthe HyperNet model, shown in Fig.
2b, is called the Catalog Server. It handles all the information
storage,
retrieval,
removal, and searching. The Catalog Server provides this functionally
independent of where the objects are physically located in the HyperNet distrib uted database.
Thus, making a transparent interface to the next layers. The HyperNet objects
may be found either on the local machine, in the local database cache, or on a
remote machine. The database cache was im plemented to increase the
interactive performance of the system when objects are retrieved from remote
machines. Thus, once an object has been retrieved from a remote machine, when
the user moves to a different window frame and then returns back, on the next
re quest for the object the Catalog Server will first search the cache and
retrieve it from there.
The
next two layers of the system are the Hypertext Abstract Machine (HAM) and user
interface. At this time, HyperNet provides the functionality of both of these
layers in the Composer and the Browser. As the system evolves we plan to move to
a three layer model, allowing the VI to be interchangeable for different
platforms.
4.
DOCUMENT PROGRAMMING LANGUAGE SCRIPTS
Language
for "programming" of hypermedia doc uments, Scripts, was designed to
support the following tasks:
- Definition
and production of hypermedia object classes.
- Instantiation
of object classes into hypermedia doc ument components.
- Production
of hypermedia document architecture and its content.
- Storing
of these components into the HyperNet worldwide database.
- Incorporation
of these components into a hyper media document, defining links effecting
the in corporation, their types and the associated anchors.
- Requesting
the search of the Hypertext database for document components. The search can
be based on a number of parameters, like components names, their types,
keywords, and other properties. In the case of multiple components resulting
from
the
search, a menu list of all components satisf) search will be incorporated into
the document.
It
is impossible to present the Scripts language
full
in this paper. This is done in references [5, 6] this section we present only a
brief description ofSer statements.
A
Scripts hypermedia program is a sequence of' segments, graphics constructs,
encodings of raster ages in different raster formats, encodings of audio: video
components, interspersed with Scripts st ments. Alternatively, the actual text,
graphics, au or video encodings, may be substituted with Scr statements
referencing document components alre stored in HyperNet data base.
A
Scripts statement has the following general Stl ture:
< < statement operation, operation paramet statement
information content> >
Operations for Scripts statements are defined bel Operation parameters
are specifiers for the docure component
that is being defined or referenced with statement. They range from
- The
name ofthe owner of the component,
- Editing
or browsing rights,
- Object
class and subclass for the component,
- Logical
algebra expression of keywords for the c( ponent. These keywords are used to
classify component regarding a number of topics. n keywords are used to formulate search actions w
browsing a hypermedia documents, or to genel vector links to multiple
destinations.
- The
component addresses within HyperNet dist uted database, possibly including the
site, directc and the name of the physical "container" where object component
is already stores or is to be StOI
Statement
information content contains the encoC
for
the content for a multimedia component. This f is present only in statements used either to produce
modify an instantiation of a document object cl
This
encoding can be ASCII encoding for a textual component, CGM encoding[9] for a
graphical com ponent, or TIFF encoding [10] for a raster graphic im
age, etc.
The
current definition and implementation of Scripts language and the associated
processors includes the following operations:
- HEADER-The
first statement in a hypermedia program. It defines all attributes for the
associated hypermedia document.
- SAVE-This
statement will store the information content for a document component. This
com mand will be used to store the hypermedia doc ument component
for the first time only, i.e., to insert a multimedia component into the
system.
- STORE-This
operation is similar to the opera tion SA VE, except that it will return
a link to the stored segment and place it within the hypermedia document
structure at the location of STORE statement, i.e., the information within STORE statement is stored in
the HyperNet database, and the link to the newly created component (infor
mation) replaces the entire STORE command.
- MODIFY-The
content of the information within the statement MODIFY will replace either the
current content or modify attributes of a document component with the name as
specified in the MODIFY statement. The segment can be any where within
the distributed database, and the op eration will be executed only if the
segment already exists.
- RETRIEVE-This
statement will retrieve a doc ument component from HyperNet database and
insert the content at the place of RETRIEVE statement.
- LINK-This
statement will insert a link to the document component specified in the
statement, and will also associate an anchor with the link.
7
. DISPLAY -This statement will affect the auto matic display of the
component (frame) when that point is reached during the browse of a hypermedia
document.
- REMOVE-This
will remove a document com ponent from the HyperNet database.
- SEARCH-This
statement, if desired, will affect a search of the entire HyperNet distributed
data base for all documents that satisfy conditions specified by a
relational expression of a set of key words or other kind of document
component at tributes. This operation is performed at composing of a
hypermedia document. The result is a hyper text menu type link.
- COMMENT-This
statement is used to include remarks about other Scripts statements within a
hypermedia documents program.
- OSACTION-
This statement requests an action to be performed. It is used to associate
computa tional actions or requests to operating system to object classes
of document components. This
statement
is heavily used when developing soft ware engineering environments using
hypertext technology.
5.
HYPERNET IMPLEMENT A nON
The
first prototype of the system was designed and implemented by eight very
enthusiastic students during a semester course in Software Engineering, Fall
1990. The first author, who was the course instructor, also acted as the project
leader. The system is based on X windows and the TCP lIP network protocol. The im plementation environment
consisted of a local area network of eight Sun Sparc I workstations that were
connected to Internet network. However, during testing and demonstration of the
HyperNet VAX computers running VMS supporting TCP lIP were also incorpo rated into the system. The
system was demonstrated with components of the system running in computers
located in Southern California and Europe. It took about 20 minutes to remotely
load HyperNet software into computers in Europe. The system was used then to
search the "whole" world for document components and incorporate them into a
document using menu anchor-link types. The response of the system was amazing.
It took a couple of minutes to search "the world," locate all desired document
components, re trieve them, process them according to their object class,
generate appropriate component frames, and get the document ready for browsing.
However, one should note that the test was done at 10 p.m. California time and 7
a.m. European time. The load on Internet is small at that time.
The
system is implemented in C. The second version of the system will be
reimplemented in Ada. The cur rent implementation of the system supports
the system as described in this paper, except for group bidirectional browsing.
This functionality is currently being added into the system.
6. CONCLUSION AND FUTURE WORK
Principles of HyperNet, a hypertext
machine for generation of hypermedia documents in a distributed environment were
presented.
HyperNet
is evolving. Research and development is underway to incorporate PC computers
via NSF I
Eth ernet link and via a serial deal
up line. The support software on PCs will be Microsoft Windows 3.0. Two further
related projects are underway. The first project is research into adding
intelligent "user profile" based filters to HyperNet using Knowledge Based
technology. The other project deals with incorporation of High Level Document
Recognition for automatic incorpo ration of scanned documents into HyperNet
and con verting of flat documents into HyperNet format
[8].
Acknowledgements-We
wish to express thanks to Tom AI
katib, Holly Amstrong, Wade Blomgreen, Hoa Bui, M!tch Evans, Mark Hays, Larry
Osburn, and Yezen Y ~una~-elght excellent students in the CS532, Software
Engmeenng, Fall 1990, who designed and implemented the system as the
course
