The Virtual Laboratory is an interactive environment for creating and conducting simulated experiments: a playground for experimentation. It consists of domain-dependent simulation programs, experimental units called objects that encompass data files, tools that operate on these objects, and a reference book. Current release is focused on graphical applications of L-systems, with an emphasis on the generation of fractals and the modeling of plants. The objects are organized, accessed and manipulated using domain-independent vlab system programs. The user can expand the laboratory by adding new objects, creating new experiments and composing them into hypertext documents.
The domain-independent framework for the Virtual Laboratory consists of:
A laboratory object is defined as a directory containing two types of files
and a subdirectory:
This definition is compatible with the UNIX hierarchical file system. Thus the object-oriented file structure (object database) which provides the basis for lab operation can be represented by a hierarchy of UNIX directories and files, as shown below:
The path of subdirectories leading to an object establishes the inheritance structure of the lab. Inheritance is based on the idea of specifying new objects in reference to objects which already exist. The old object is the prototype and the new one is itsextension. The extension contains only those files which are different from the corresponding files in the prototype. Files that remain the same are inherited from the prototype using symbolic links. Thus the object directory contains those files that are unique to the object, and links to files that are inherited from its prototype. This approach saves space, facilitates creation of objects similar to the prototype and allows a single change in the prototype to propagate through all descendents. The figure below illustrates an example:
In this example model 1.1 is an
extension of model 1, while model 1.1.1 is an extension of
model 1.1. model 1.1 has different specifications
file and
data1 file. Additionaly, it also contains a file data3.
Since icon and data2 remain the same, they are stored
as symbolic links to
model 1 files, denoted with yellow arrows.
Therefore if data2 was to be changed in model 1, it would
affect model 1.1 as well. Notice that such change would also affect
model
1.1.1.
The following information is stored with each hyperobject:
| filename | function |
|---|---|
|
node
|
Contains a hyperlink to an object in an oofs database. Not all hyperobjects need to point to an object in an oofs database. Those that do not contain a hyper-link are used as place-holders for other hyperobjects. |
| node | Also contains the name of the hyperobject. This description is usually related to the object the hyperlink points to under the given context. |
| node | Also contains the order of children. The order of children in a parent can be changed, which affects the traversal of hyperobject databases. |
| text | Contains a textual description of the hyperobject. |
| ext | A directory of children (other hyperobjects). |
The hyperlink in a hyperobject is specified as the ID of the object to which the hyperobject points, allowing hyperlinks to stay intact as long as the objects to which they point remain in the oofs database. Quick access to objects from hyperobjects is made possible by using the object lookup table.
Hyperobjects are organized hierarchically into an hyperobject file systems (hofs). At the implementation level, the structure of hofs is similar to the structure of oofs - it is a hierarchy of UNIX directories and files forming a directory tree. It is possible to think of hyperobjects as symbolic links in a UNIX file system, and of hofs databases as directory hierarchies entirely composed of symbolic links associated with textual descriptions. However, there is a very important conceptual difference between oofs and hofs databases. Hofs databases are not based on the prototype-extension mechanism. The reason for this design decision is simple: the prototype-extension mechanism is not needed for hyperobject databases. The prototype-extension model is advantageous when extensions share data with their prototypes, but this is uncommon for hyperobjects. The hierarchical organization of hyperobjects allows VLAB users to create and describe various conceptual relations between objects.
A user may browse through the objects in the lab by following the hierarchy induced by the prototype-extension relation. The object browser provides a visual interface for navigating through the hierarchy. The browser also makes it possible to move, copy, delete and rename objects. At any time, the user may request that the browser invoke the object manager to place a selected object on the lab table.
Upon invocation of the object manager, all files that make up the selected object are copied to a temporary location called the lab table. Consequently, manipulation of object parameters does not affect the stored version. When the experiment is completed, the user may save the results by overwriting the original object or by creating an extension. In the latter case, the files on the lab table are compared with those in the prototype object; those files that differ from the prototype are saved, and links to the remaining files are established automatically.
Objects are manipulated using a vlab system program called the object
manager, manifested as an icon with an associated menu of operations.
The menu lists the tools and utilities available for experimenting with
the object, and allows the user to select them dynamically. The user may
manipulate the object as a whole, without detailed knowledge of the programs
involved or the component files. The content of the menus is given in the
specifications
file, which is a mandatory file in each object.
The ability to easily manipulate the parameters of an experiment is an
important feature of the Virtual Laboratory. All parameters of an experiment
are represented in the object's data files. Parameter modification can
be performed using virtual control panels. A general-purpose panel
manager creates panels according to definition files also included
in the object. A panel definition file itemizes the appearance of each
control button or slider in the panel, and the format of the message to
be sent as a result of control manipulation. These messages are used to
edit the data files. As a control on the panel is manipulated, the corresponding
parameter in the data file will be updated. The application may then reread
the data file to obtain the new values.
Hyperbrowser is a VLAB program used to facilitate the presentation of a VLAB object in several different contexts, while keeping the main database intact. In other words, hyperborwser allows the user to operate on databases of hyperobjects. Both hyperbrowser and browser operate on databases which store information using the same file structure. To preserve consistency between VLAB applications, hyperbrowser offers the same interface for database manipulating functions as browser.
In many cases models separated in the prototype-extension hierarchy are
related conceptually and should be associated for presentation purposes.
Such associations are maintained by metatext,
a simple Unix-based hypertext system. Metatext makes it possible to invoke
objects and access related textual information in a manner independent
of the hierarchical organization of the lab. It should be noted that metatext
is considered now obsolete as all of its functionality has been replaced
by hyperbrowser. It is still distributed with VLAB but only for backward
compatibility.
The vlab daemon is invoked automatically by other
processes, and thus remains invisible to the end-user. However, the information
on its operation and the format of messages is essential to implementing
extensions of the Virtual Laboratory framework. Main functions are: support
of communication between components and launching of objects (i.e.: invocation
of the object manager).
Communication between vlab system programs and the vlab daemon is shown in Figure 3. Each process has a separate communication channel to the daemon. The daemon transparently forwards any message sent by an active vlab component to multiple receivers, which simplifies communication patterns compared to direct bilateral communication between pairs of components.
L. Mercer. The Virtual Laboratory. Master's thesis, University of Regina, Regina, Canada, 1991.
L. Mercer, P. Prusinkiewicz, J. Hanan. The concept and design of a Virtual Laboratory. In Graphics Interface '90 Conference proceedings, pages 149-155. Canadian Information Processing Society, 1990.
E. Lowe - Extensions to the Virtual Laboratory. Master's thesis, University of Calgary, Calgary, Canada, 1995.
H. Lieberman. Using prototypical objects to implement shared behavior in object oriented systems. In Proceedings of the ACM Conference on Object-Oriented Programming Systems, Languages and Applications, pages 214-223, New York, 1986, Association for Computing Machinery.
L. Mercer, P. Prusinkiewicz, J. Hanan - the concept of the Virtual Laboratory
L. Mercer - the first vlab implementation
E. Lowe - redesign of communication centered on the vlab daemon
I. Hernadi, L. Mercer, P. Prusinkiewicz - Virtual Laboratory Environment
documentation