On Integrating Hypermedia into Decision Support and Other Information Systems

Michael Bieber

Department of Computer and Information Science
New Jersey Institute of Technology
University Heights - Newark, NJ 07102-1982
Phone: +1 973 596-2681
FAX: +1 973 596-5777
E-Mail: bieber@njit.edu
URL: http://megahertz.njit.edu/~bieber

Abstract

The goal of this research is to provide hypermedia functionality to all information systems that interact with people. Hypermedia is a concept involving access to information, embodying the notions of context-sensitive navigation, annotation and tailored presentation.

This paper presents the architecture of a system-level hypermedia engine, designed both to manage full hypermedia functionality for an information system and to bind interface-oriented front-end systems with separate computation-oriented back-end systems. The engine dynamically superimposes a hypermedia representation over a back-end application's knowledge components and processes. The hypermedia engine generates this representation using bridge laws, which capture the internal structure of client systems. Users access the application through its hypermedia representation.

The paper also describes a set of minimal requirements for integrating the hypermedia engine with an information system. These guidelines apply to all integration efforts, not just that described here. Information systems will require some supplementary routines for the engine to manage hypermedia functionality for them. The more sophisticated and cooperative the information system, the higher the level of hypermedia support the engine will provide.

Keywords:

Bridge Laws, Decision Support Systems, Filters, Hypertext, Hypermedia, Hypermedia Engine, Information Navigation, Information Systems Architecture, Integration

1. A Vision of Hypermedia and Information Systems

We envision a world in which information increasingly empowers people. Decision makers, analysts, researchers, trainees, students and casual browsers all will have access to information they need or desire, in a format tailored to their individual tasks and personal preferences.

The concept of hypermedia embraces the spirit of such access to information and eventually, we believe, will be incorporated in the interfaces of all decision support systems (DSS), and indeed, all information systems that interact with people. (Various authors, e.g., [43], support this prediction.) Our research goals are to facilitate this integration and to produce tangible results. Once an information system includes hypermedia functionality, the specific applications it supports (e.g., worksheets within a spreadsheet package, models within a linear programming package and expert systems within an expert system shell) automatically become hypermedia applications. Users communicate in hypermedia's direct, context-sensitive fashion and hypermedia functions supplement the system's original commands.

The goal of this paper is to encourage an ongoing discussion about providing the users of all information systems with dynamic hypermedia functionality. We began this discussion in [7, 8] by proposing a solution-a hypermedia engine that builders can integrate with their systems. From this we derived a starting set of minimal requirements for hypermedia integration, which we believe apply to all integration efforts, not just our own. This paper extends the architecture we originally introduced in [7, 8]. Here we deepen our description of the hypermedia engine's internal structure, develop an alternate architecture for information systems not abandoning their interfaces and expand our set of minimal requirements for hypermedia integration.

In Section 2 we briefly review the concepts of hypermedia and our enhancement, generalized hypermedia. Generalized hypermedia is at the heart of our hypermedia engine's architecture. We also examine the potential role of hypermedia in decision support. In Section 3 we introduce two versions of our engine's architecture and describe its internal structure. We illustrate its operation with a detailed example. In Section 4 we discuss the minimal requirements for hypermedia integration-the commitment information system builders have to make to use our architecture. We conclude in Section 5 by briefly comparing our work with other current approaches.

2. Hypermedia and Generalized Hypermedia

Hypertext [3, 15, 49, 53, 54, 67] is the concept of specifying relationships among pieces of information and providing computer-mediated navigation among them. For example, we can automatically link a document with a stage in a decision analysis, a keyword with its definition and a calculation with its explanation. Hypermedia expands this concept to include media other than text. We refer to the information at either end of the link as nodes, and to the entire node and link structure as a hypermedia network. We signal the existence of a link from a node by highlighting a portion of the node's display contents, which we call a link marker. When a user selects a link marker the system traverses this link and displays an appropriate representation of the destination node. Figure 1 shows a hypermedia-oriented interactive document similar to those our Max prototype produces. [11, 38] This document node represents a report generated by a decision support system (DSS) and passed on to our hypermedia engine for display. The underlined and boldfaced text strings are link markers, each associated with one or more links. In Figure 1 the user has selected the marker "$60.00" representing the result of a DSS calculation. The hypermedia engine inferred three links associated with this marker's underlying calculation: to a node representing an expert system explanation, to a node representing its dynamic recomputation and to a node containing user comments about it. The two remaining links represent hypermedia engine commands for annotating elements of the DSS. The user navigates through the DSS thus, by selecting some item of interest and traversing a link representing an appropriate DSS (or hypermedia engine) command. The hypermedia engine would support other types of information systems in a similar fashion.

Figure 1: Accessing Application and Hypermedia Functionality in a Hypermedia-Style Interface

Hypermedia embodies a methodology of flexible access to information incorporating the notions of navigation, annotation and tailored presentation. Tailoring is inherent in other hypermedia functions, e.g., in customizing the network the user navigates and its annotations. Together, these features constitute what we call "full hypermedia functionality," an ideal level of functionality that few of today's hypermedia systems achieve. (Many systems calling themselves "hypermedia systems," in fact, provide only forward navigation-i.e., direct manipulation-and perhaps commenting [42, 62].)

Users navigate "forward" by selecting an item of interest (a link marker) about which to retrieve comments, annotations, definitions, explanations or any other inferable information. Link markers act as embedded menus [39], giving "context-sensitive" access to an underlying application's knowledge and operations. We have dubbed this the WYWWYWI ("what you want, when you want it") principle [5]. Users normally traverse from node to node at the detail level, i.e., with each node occupying a window on the screen. Users also should be able to navigate via (graphical) overviews [21, 40, 49, 54, 69] of the hypermedia network. Overviews (often-see [17]) help alleviate the network disorientation [15, 54] associated with hypermedia's nonrestrictive, user-directed access.

Information retrieval-style queries provide an alternative method of forward navigation [20, 23, 72, 71]. Queries return a relevant subset of an application's components, which is mapped to a hypermedia representation. Users then can navigate within this tailored subenvironment.

Users can navigate "backwards" as well, returning to prior stages or "screens" in their analysis, i.e., the previously visited computer screens, but in their current state. Backtracking is another important weapon against network disorientation. By providing an escape mechanism for returning to familiar territory, backtracking gives users the confidence to explore freely and take "detours."

Annotation comprises features such as user-declared links and comments. Analysts and instructors can use these, for example, to tie specific data, techniques and results together in trails [68] or guided tours [24, 46]. Trails and guided tours both direct and constrain forward navigation. They can document analyses or serve as tutorials, and can be tailored for specific users or tasks. In a DSS, for example, annotations can provide justification for courses of action [10].

Full hypermedia functionality can augment decision support [32]. Consider Simon's Intelligence (gathering information) - Design (developing alternate solution scenarios) - Choice (choosing a solution) framework of decision making [64]. An analyst navigates or browses through the documents, models, and data in the problem domain by making queries or by directly selecting items of interest ("drilling down" [49]). If the domain had been explored previously, the hypermedia representation may be tailored to this analyst, or his or her task. Prior users also may have specified annotations or recommended paths. Our analyst's own annotations document the solution scenarios he develops, and connects these to their sources and other supporting information. DSS commands mapped to hypermedia links enable the analyst to evaluate models and data directly through context-sensitive hypermedia navigation. As we see in figure 1, this provides a seamless interface for all DSS and hypermedia functions. The analyst can link his chosen solution scenario to documents reporting the decision. He also could package his analysis as a trail or guided tour. Hypermedia thus serves as a documentation and justification tool [43]. In fact, an entire class of hypermedia systems-argumentation systems, e.g., [16, 45]-specializes in capturing the decision rationale and deliberations so often unrecorded and quickly forgotten. Through the hypermedia representation, others can explore the analyst's alternatives and conclusions, and can comment upon them. (See [10] for a deeper exploration of hypermedia and decision support and [31, 49] for discussions of hypermedia and decision support research issues.)

In summary, hypermedia is a technique for providing direct, context-sensitive access to application data, the commands that manipulate this data, and metainformation about the data and commands. Such access should improve the quality and users' understanding of applications and their inputs and outputs, and increase the confidence people have in these. Performance issues aside, we believe that most information systems that interface with people would profit from hypermedia functionality. (The exceptions may be data entry and other transaction processing systems, in which users do not query information. Perhaps even here, validation and other feedback may benefit from a hypermedia representation.)

There are two basic limitations with most of today's "first generation" hypermedia systems. First, they implement a static and explicit model of hypermedia; the nodes, links and link markers must be declared explicitly and be fully enumerated (as opposed to being declared virtually and generated upon demand). Most applications, however, are dynamic and too large to mark up manually. Imagine a spreadsheet designer having to calculate all what-if analyses in advance. Second, most of today's hypermedia systems are "Éinsular monolithic packages that demand the user disown his or her present computing environment to use the functions of hypertext and hypermedia." [48] Users who want hypermedia functionality often must abandon the software they currently use-an impractical restriction [34, 43]. The first limitation motivated us to develop generalized hypertext or generalized hypermedia [6, 11, 12]. The second motivated our hypermedia engine, which will provide hypermedia functionality to an information system's applications. The engine incorporates our dynamic model of generalized hypermedia.

In generalized hypermedia we broaden the underlying model of hypermedia components-nodes, links, link markers, etc.-with three of Halasz' proposed extensions to hypermedia [27]: virtual specifications, dynamic computation, and filtering or tailoring. We use these to generate a hypermedia representation "on the fly" from basic declarations we call bridge laws that describe the internal structure of an information system. As we shall see in Section 3.2, bridge laws enable generalized hypermedia to superimpose a hypermedia network on an information system's application, generating all node, link and link marker representations dynamically from the application's original, non-hypermedia data or knowledge base. We should emphasize at this point that both generalized hypermedia and bridge laws are to be applied to an entire information system application package (such as a spreadsheet language, a DSS shell or a programming language), not individual applications (e.g., a specific worksheet, DSS or program module). Once declared for an entire package, hypermedia functionality will be provided automatically for each of its individual applications. (This is analogous to Garzotto et al.'s authoring in the large [25].)

Three aspects combined distinguish generalized hypermedia from other hypermedia approaches: (1) all mapping and computation in generalized hypermedia is dynamic; (2) through bridge laws, generalized hypermedia can provide system-level support to any information system with a well-defined internal structure; and (3) bridge laws map a hypermedia representation without altering an information system's data or knowledge bases. No other approach supports all three criteria. [10] This does not mean that information system builders simply can plug in our hypermedia engine without adjusting their systems. Each builder will have to declare a small set of bridge laws, register the system's communication protocols and add a relatively small number of routines to his system to route information formatted for these bridge laws to the hypermedia engine. This will suffice to provide hypermedia engine support for all specific applications written in his information system. Builders, however, will not have to make their systems or applications "hypermedia-aware" in any way. This is because (1) as mapped representations, nodes, links and link markers do not alter the original, underlying application information and (2) the hypermedia engine maintains all other hypermedia constructs (e.g., comments and trails) in its own knowledge bases separate from its client information systems. The engine adds no hypermedia constructs to its client systems or their applications.

3. The System-Level Hypermedia Engine

Figure 2 shows a version of our proposed hypermedia engine's architecture that binds independent back-end and front-end information systems. By back-end systems, we mean information systems that primarily provide computation functionality, such as DSS, expert systems, intelligent tutoring systems, database management systems, project management systems, etc. By front-end systems we mean those that primarily support interface-level functionality such as word processors and graphics packages. Instead of being tightly coupled, the hypermedia engine runs concurrently with-and independent of-the information systems it binds, communicating through external message passing. The engine embeds link markers in messages the back-end passes to the front-end for display and handles requests for back-end functionality or supplementary hypermedia support when a user selects one of these markers. As a result, the user can access a back-end through the interface of his or her choice, which now provides full hypermedia functionality. (This assumes that the front-end and back-end builders comply with the requirements we discuss in Section 4.)

Figure 2: Hypermedia Engine Architecture (Version 1) This architecture binds independent back-end and front-end information systems.

This architecture also allows users to access multiple back-end systems at once and incorporate information (linked objects) from different back-ends in a single front-end document [58]. Eventually this architecture will support workgroups of multiple simultaneous users on heterogeneous front-ends.

Many computation-oriented information systems, of course, have high-quality interfaces. Among these are spreadsheets and CAD systems, as well as specific cases of the aforementioned front-end and back-end systems. A second version of the hypermedia engine, shown in Figure 3, would run concurrently with such systems and manage hypermedia functionality for them. In this architecture, internal communications between the interface and computation modules must be routed through the hypermedia engine.

Figure 3: Hypermedia Engine Architecture (Version 2) This architecture serves information systems that have both adequate interface and computation functionality.

For the rest of this paper we shall use the terms "front-end" and "back-end" to indicate interface-oriented and computation-oriented functionality in both versions of the architecture.

3.1. An Overview of the Paper's Example

We describe the hypermedia engine's architecture through Figure 1's simple text-based example both here and in Section 3.5. (Our model also supports non-text content and link markers.) Figure 1's interactive document entitled "Ordering Recommendation" started as a message from the DSS back-end. As an illustration, suppose the second sentence of that message had the following format:

In the following sections we examine different aspects of the hypermedia engine and then return to this example in further detail.

3.2. Bridge Laws and Filters: Techniques for Automating Hypermedia

In this section we discuss filters and bridge laws. As part of compiling the document component set, the hypermedia engine must determine the locations (i.e., infer the existence) of link markers in back-end messages. Bridge laws enable this inference. Filters tailor it.

The hypermedia engine uses filters to customize the user's interaction in many ways. For example, filters can direct:

The hypermedia engine uses logical rules called bridge laws to map a hypermedia representation over the components of a back-end system. We adopted the term "bridge law" [29, 37, 50] because these logical rules serve as a "bridge" or connection between objects defined in the language of the back-end (e.g., models, variables, calculations) and those in that of the hypermedia engine (e.g., nodes, links, link markers). Bridge laws employ logical quantification, i.e., they apply to every instance that satisfies the set of conditions specified. Logical quantification (i.e., specifying "for each" or the logical symbol """) enables individual laws to map entire classes of back-end objects to hypermedia components; the same bridge law will map every object in the application knowledge base that satisfies the bridge law's conditions.

In Figure 1's example, the hypermedia engine used a bridge law similar to the following pseudo version to identify the object "calculation(variable(tc), model(eoq), scenario(eoq(2)))" within the "DSS1" back-end's original message and tag it as a link marker in the document component set.

For each calculation with attribute values satisfying the set of conditions Y and filter settings Z:

map a hypermedia link of type "explain" from the object to the DSS1 explain function, and

map a hypermedia link of type "re-evaluate" from the object to the DSS1 re-evaluate function.

As we shall discuss later, because it is specific to a particular back-end, the back-end's builder would have declared this bridge law. The hypermedia engine maintains its own set of general bridge laws that pertain to all back-ends. For example, the following general bridge law finds objects with comments registered in the hypermedia engine's knowledge bases.

For each object with a user-specified comment that satisfies filter settings Y

and access security specifications Z:

map a hypermedia link of type "comment" between the object and its user-declared comment.

The engine uses the following general bridge laws to infer keywords. The first finds keywords that a message's back-end has declared. The second searches for keywords that a user has registered.

For each phrase in the message matching a keyword registered by its back-end

that satisfies filter settings Z:

map a hypermedia link of type "keyword" from the phrase to the back-end object it represents.

For each phrase in the message matching a keyword registered by a user that satisfies filter settings Y

and access security specifications Z:

map a hypermedia link of type "keyword" from the phrase to the object it represents.

Together, generalized hypermedia and its bridge laws provide a logic-based knowledge representation that enables the hypermedia engine to reason about the components (models, data, commands, etc.) of the underlying information systems they map. For example, full hypermedia functionality includes both producing an overview of an application's components, and searching or querying over these components. As part of our research, we shall determine whether a complete set of bridge laws suffices for the engine to perform both structure search and content search [25, 27] and generate a network overview. (Producing an overview for a static hypermedia network is not a trivial task (see, e.g., [69]). No one, as yet, has tackled overviews for virtual environments involving computation, which a hypermedia mapping for dynamic information systems would involve.)

Ours is not the only hypermedia knowledge representation. In addition to the argumentation-based hypermedia models mentioned earlier, several other knowledge representation approaches have appeared in the hypertext literature, e.g., Petri nets [65, 66], structured object representation [35], schemata [25, 32, 45], object-oriented hypermodeling [41], HyperSets [57], De Bra et al.'s extensible data model [19] and high-level specification languages [61]. Other systems that make use of a knowledge representation include Hypermedia-based Argumentation DSS [30], Electronic Working Papers [17], MacWeb [51], IDE [33] and RelType [2]. In future papers we hope to compare implementations using bridge laws and a generalized hypermedia engine with systems using other knowledge representations.

The browsing semantics of the different systems also will influence this evaluation. The browsing semantics define the dynamic behavior of a system and are constrained by its underlying knowledge representation [65]. In our model, the hypermedia engine incorporates the browsing semantics and, as we shall see, attempts to integrate them into the front-end's functionality (constrained by the front-end's level of compliance, as we discuss in Section 4.1).

The hypermedia engine stores bridge laws and filter settings in knowledge bases belonging to its Internal Control Subsystem. For an in-depth discussion of bridge laws see [6, 10, 11].

3.3. Internal Control Subsystem (CS)

The hypermedia engine has two major components: the Internal Control Subsystem (CS) and the Internal Display Subsystem (DS). We describe the structure of each next and illustrate their interaction in Section 3.5's example.

The CS performs all configuration-independent processing. It handles the communication link between the hypermedia engine and the back-end systems. Back-ends pass messages containing reports, queries and menus. From each message the CS compiles the configuration-independent contents of a document component set or query component set, which the CS passes to the Internal Display Subsystem.

In the future we intend to upgrade our hypermedia engine for a networked, multi-user environment. At that time we shall split the CS into two logical modules, a single global module and multiple local modules. The global module will keep track of information that users on all systems should be able to access. Security permitting, everyone should have access, for example, to public comments, informational links, keyword definitions and documents registered by any user.

The CS maintains the following knowledge bases, each containing facts and rules for a different domain of inferencing.

3.4. Internal Display Subsystem (DS)

The DS has two major responsibilities. First, it translates the configuration-independent document component set for the specific front-end that will display it. Second, it provides whatever "behind the scenes" support its front-end needs to provide hypermedia functionality. The DS maintains the following knowledge bases:

3.5. Example

Figure 5 presents an informal data flow diagram depicting how the hypermedia engine compiled both the link ensemble in Figure 1 for the link marker "$60.00" that the user selected and the interactive document "explain($60.00)" in Figure 4 resulting from traversing the "explain" link.

Figure 5: Informal Data Flow Diagram of the Hypermedia Engine This diagrams the processing of a standard request for information about an application object when the user selects the link marker representing it.

The hypermedia engine expects back-ends and front-ends to support two standard commands for all objects: generating a short description ("What is this?") and generating a list of possible actions ("What can I do with this?"). The user also should be able to select any command within a menu or represented by a link, and request assistance ("What happens if I do this?"). The front-end should provide some mechanism for the user to request each, e.g., a special keystroke combination or menu command. The back-end should provide the respective descriptions, command lists for its objects and assistance for its commands.

Another common action is an implicit request to edit. Because front-ends must ensure the integrity of link marker representations belonging to external systems, when users try to edit a marker's display value the CS must grant permission.

We now expand Section 3.1's hypothetical example, following the flow of information illustrated in Figure 5. Note that Figure 5's diagram does not cover editing or requests for assistance. This discussion complements, but greatly deepens the illustration in [11].

1. The Front-End Passes a Message to the DS in Response to a User Action

When the user selects a highlighted text string, such as the "$60.00" in Figure 1, the front-end sends a message to the DS. The message from a "hypermedia engine-friendly" front-end-one that maintains external objects-will contain both the user's requested action ("What can I do with this?") and the object's internal identifier ("[7, DSS1, calculation(variable(tc), model(eoq), scenario(eoq(2)))]").

The less sophisticated the front-end, the more inferencing the DS must do to manage hypermedia functionality. For example, if the front-end does not maintain external objects then it may be able to pass only the selection's location in coordinates relative to the start of the document. In this case, the Display KB must maintain an up-to-date map of the front-end's documents that records the current location of all hypermedia objects. From this the DS must infer which object the user selected.

2. The CS Processes the User Request

The DS passes the action requested and the identifier of the selected object to the CS. From the identifier the CS can determine the system to which the object belongs. When a back-end owns the object, the CS compiles the appropriate request for the back-end. The CSKB supplies the back-end's protocols and access path. If the hypermedia engine owns the object, such as with user-specified keywords, the CS has all necessary information for the user request in its own knowledge bases. This also applies to hypermedia metainformation about back-end objects. Users may select user-specified comments and links associated with a back-end object and inquire about their creators, modification dates and even comments about these links and comments. The Hypermedia KB contains such metainformation.

We now detail three possible user requests: requests for (a) editing, (b) a short description and (c) a list of relevant commands.

2a. The CS Processes the User Request: Edit Link Marker

For requests to edit a link marker's display value, the CS does not have to check with the back-end. The CSKB contains hypermedia engine-owned bridge laws controlling editing permission for each type of link marker. For example, users may delete, but not modify, back-end object markers. Users may alter a keyword, but the CS will cancel its marker status as a keyword and direct the front-end to dehighlight it. Users may alter the content of user-specified links without canceling the marker or deleting its link. The CS approves or rejects the edit request in a message it returns to the DS.

2b. The CS Processes the User Request: Short Description (i.e., "What is This?")

The back-end responds to this standard request with a message containing the short description in a format analogous to that of Section 3.2. The CS converts this description to a configuration-independent document component set. First the CS infers the appropriate document template for short descriptions from the CSKB. Next it instantiates the template form with the message contents. Then it determines what to represent as link markers as follows.

The CS often can generate the list of relevant back-end commands directly from the back-end's bridge laws and therefore does not have to communicate with the back-end. For example, the first bridge law in Section 3.2 maps the two back-end commands we see in Figure 1's link ensemble. Resolving complex bridge laws, however, may require internal back-end calculations or information stored in the back-end's own knowledge bases. In this case the CS will have to send a request to the back-end as part of resolving the back-end's bridge laws. (As this may slow processing, we hope that most bridge laws will be specified fully enough to not require back-end processing at run-time.) The CS also processes the selected object using its own general bridge laws. One of the bridge laws in Section 3.2 identified a user-specified comment about the selected DSS calculation (i.e., back-end object). The CS represents access to this comment with the third link in Figure 1. Two other CS bridge laws mapped links corresponding to the hypermedia engine commands "start new user link" and "create new comment."

The CS now formats the link ensemble as a configuration-independent query component set. The CS retrieves the appropriate query template for link ensembles from the CSKB and inserts the five links along with a directive to the DS to include the selected marker's display value as the title. The CS represents each of the five links as a link marker in the query so the user can select any and request assistance (i.e., "What happens if I do this?") for its underlying DSS or hypermedia engine command. Simplistic assistance returns the equivalent of a short description. Sophisticated back-ends provide more sophisticated help.

3. The DS Converts the Document or Query Component Set for the Front End

The DS prepares the document or query for its front-end. It retrieves the protocol the front-end will recognize for documents and queries from the FEKB. The front-end may or may not accept objects embedded in messages and may restrict identifier length. If the front-end does not process dimensional attributes, the DS must pre-format object display representations (e.g., sending "$60.00" instead of <value(60), form(currency(US))>). Ideally the front-end will accept a standard document protocol such as ODA or SGML [14], or even a HyTime representation (an SGML-based hypermedia communications standard [52]). Based on the level of front-end support, the DS has to determine whether to represent the query link ensemble (1) as a dialog such as in Figure 1, into which the user types information, (2) as a document in which users must select a link marker representing one of the commands, or (3) as a menu. The DS may have to sacrifice functionality. For example, Figure 1's front-end supports query dialogs, but cannot highlight each link as a link marker. Users, therefore, cannot request "What happens if I do this?" assistance for commands directly.

Once converted, the DS passes the document or query component set to the front-end and updates its knowledge bases as shown in Figure 5. The DS records the user's request and the engine's response in the Session KB to support backtracking, trail construction and undo/redo, etc. The DS records each component set object in the Display KB for interpreting subsequent user requests and for reformatting displays. (The DS includes physical object locations if it must maintain these.) The DS also passes this set of displayed objects to the CS's Active KB to support dynamic updating.

3.6. Our Prototype: Max

We have implemented a preliminary text-based prototype of the hypermedia engine inside the Max system, which we developed for the U. S. Coast Guard. Max is a knowledge-based DSS shell [11, 38]. The engine uses a preliminary version of bridge laws to map (1) objects in the DSS knowledge base and reports to hypertext nodes, (2) DSS commands to links, and (3) keywords and objects embedded in DSS messages to link markers. Max's interactive documents and link ensemble queries resemble those in Figure 1 and Figure 4.

Max, admittedly, is an "insular, monolithic package," providing its own mandatory front-end. The front-end does not support external objects, so the engine keeps track of its objects' locations within the front-end's windows. The current prototype's front-end and hypertext engine are not entirely independent, neither are the DS and CS entirely separate subsystems. The back-end, however, is completely independent of the engine. It communicates solely through Figure 2's back-end communications language. Indeed we have developed two separate computation-oriented back-ends for Max, a project management system and TEFA [4, 5], a model management system.

4. Hypermedia Engine/Client Cooperation and Coordination

The two proposed architectures pose many interesting and unresolved questions concerning cooperation and coordination among a hypermedia engine and independent external information systems. This section discusses several issues our research will address.

The hypermedia engine requires the cooperation of its client front-ends and back-ends. The more sophisticated and coordinated each is, the higher the degree of hypermedia functionality the engine can provide. To provide ubiquitous hypermedia support, however, the engine must accommodate front-ends and back-ends that do not meet the compliance standards we desire. As part of our research we are investigating the minimal level of cooperation among front-ends, back-ends and the hypermedia engine. ([18, 34, 60, 62] also investigate compliance requirements. [32, 31] report on an integration architecture using state-change messages that claims to require less coordination among the hypermedia engine and its external systems. Marshall also has an enlightening discussion of how compliance affects hypermedia support during document interchange [44]. [8] complements this discussion.)

In [7] we introduced a preliminary set of minimal requirements for client/engine cooperation. Now we augment this set, addressing the interaction between the engine and interface-oriented front-end systems in Section 4.1, and between the engine and computation-oriented back-ends in Section 4.2. These apply to information systems from either version of our architecture. In Section 4.3 we discuss how these requirements impact the integration of existing information systems.

These requirements stem from our own research. We believe, however, that they are universal enough to provide a starting set of general guidelines for all system-level approaches to hypermedia integration, including those not employing an external hypermedia engine. (Approaches that integrate hypermedia directly into individual applications, e.g. [41], do not require our degree of generality.)

While we primarily address compliance and coordination issues in this paper, we must investigate many other issues ranging from the validity of links and node contents (especially when fusing information from multiple, dynamic back-ends [7]), to handling different versions [26, 27, 55], to supporting cooperative work such as with group DSS and distributed group support systems, etc. We discuss other "non-compliance" issues in [6, 7, 11].

4.1. The Hypermedia Engine and Front-end Compliance

The hypermedia engine provides the front-end and its users with simultaneous access to multiple back-ends. The engine manages hypermedia constructs (e.g., link markers representing user-defined and back-end objects, comments, trails, and overviews) and hypermedia control (e.g., filtering, context-sensitive forward navigation and backtracking). In return the front-end should provide the following functionality.

* Identifying objects in front-end workspaces

4.2. The Hypermedia Engine and Back-end Compliance

The hypermedia engine provides the back-end and its users with access to a variety of front-ends. It manages hypermedia functionality (linking, annotation, backtracking, filtering, network overviews of applications) on behalf of the back-end. In return the back-end should supply the hypermedia engine with specific information about its structure, and its applications' documents and data elements. However, even if a back-end declares no bridge laws or keywords, and passes messages without objects, the hypermedia engine still will provide standard hypermedia functionality (user annotation, backtracking, etc.) In this case the user will not be able to access back-end objects or operations in a hypermedia fashion.

* Builders must write bridge laws

In [7] we also discussed the following requirements.

4.3. The Hypermedia Engine and Existing Systems

Builders developing an information system from scratch will find interfacing with the hypermedia engine easier than builders who must retrofit the coordination that the hypermedia engine demands. Builders of existing information systems (assuming they can be located [31]) must reengineer the communications path between the system's interface components and computational components, allowing the hypermedia engine to intercept messages and embed objects. The more loosely coupled and modular an information system is, the simpler hypermedia integration will be.

5. Conclusion

We have yet to see hypermedia availability as a common interface feature. Information system builders wishing to incorporate full hypermedia functionality today must do it themselves. Few new system builders would be willing or able to do this. Fewer builders would put forth the effort to convert existing systems. "A more modest [and practical] goal is to create rules and tools that could be used to allow slightly modified existing applications to produce data accessible in hypermedia style." [67 pg. 81] Certain operating systems, for example, provide system-level hypermedia toolkits for adding hypermedia constructs-nodes, links, markers, etc.-to application data (e.g., the Andrew Toolkit [63], and a recently proposed "core system" [47]). Apple Computer's new operating system, System 7, provides publish and subscribe capabilities, but these, in themselves, fall far short of full hypermedia functionality.

Several research efforts have succeeded in creating links among primarily non-hypermedia information systems and in facilitating their traversal. The commercially-available Sun Link Service [59], PROXHY [34], Microcosm [18] and Multicard [62] each has a hypermedia engine that executes concurrently with external systems and provides linking support. Each of these four hypermedia systems (ideally) expects client information systems to support link creation and selection by embedding hypermedia calls and handling minimal hypermedia functionality in a manner similar to the toolkit approach. The latter three systems also provide multiple levels of hypermedia support, based on the degree of hypermedia compliance the client non-hypermedia information system provides. Each also provides a limited set of support for client systems that are not hypermedia compatible at all. All four systems, however, concentrate primarily on supporting front-end interface-oriented systems, as opposed to back-end computation-oriented systems. ([18] and [62] seem to imply that support for back-end systems could be implemented in Microcosm and Multicard, but this neither is stated explicitly nor is their primary focus.)

Our research, in contrast, emphasizes the mapping of hypermedia representations to the back-end computational aspects of information systems. We find few methods that externally superimpose hypermedia constructs over an application without adding to its data or knowledge base (e.g., the proposed Relationship Management System [32]). When completely developed, our hypermedia engine will provide full hypermedia functionality to dynamically changing applications while running concurrently with them and mapping a hypermedia representation that does not alter them.

Through our preliminary architecture we have identified many challenges for hypermedia support of dynamic information systems. We have started developing techniques to address these, which we soon shall implement in an improved prototype.

Hypermedia should be a widely implemented paradigm for information management and presentation. We invite information system developers, and challenge both information system and hypermedia researchers, to join us and make this goal a reality.

References