Automated Hypermedia Support for the Virtual Documents Generated by Analytical Applications

Michael Bieber, New Jersey Institute of Technology;

Roberto Galnares, New Jersey Institute of Technology

Position Paper for the Workshop on Virtual Documents, Hypertext Functionality and the Web at the WWW8 Conference


Our domain are the everyday analytical applications used daily in the real world [BK95]. By "analytical applications" we mean computational applications such as database management systems, decision support systems, spreadsheets and other systems that generate their display content in real time, often as a result of user queries and other interaction. The documents and display screens are virtual - they often do not exist before being displayed. Therefore hypermedia constructs must be added dynamically, in real time, as the document is about to be displayed. Furthermore, links cannot be inferred only using lexical analysis. Does the number "6" in a spreadsheet represent a month or net income?


We are developing the DHymE hypermedia engine to provide automated hypermedia support to analytical applications. DHymE uses mapping rules, which provide links for a particular type of object. For example, if a document contains a value representing the net income for a company, DHymE would search for mapping rules for "net income" objects. Our goal is supplementing analytical applications with hypermedia support, without altering them. We are developing the RA relationship analysis approach [BY99] to help developers determine which relationships are in their application domain. Each of these can then be specified by a mapping rule, and therefore become mapped to a hypermedia link..

This paragraph gives a technical description of DHymE's interaction with an analytical application. The DHymE hypermedia engine executes separately from the target application. We write a wrapper program for each application to integrate it into our engine architecture. Applications or their wrappers then connect to DHymE through a Web proxy server. DHymE intercepts all messages passing between the application and the user interface, and uses the mapping rules to map each appropriate element of the message to a hypermedia node or anchor. Our Web browser wrapper integrates these anchors into the document being displayed and passes it through the proxy server to the user's Web browser. When the user selects an anchor, the browser wrapper passes it to DHymE, which returns a list of possible links (one for each appropriate relationship as determined by the mapping rules). If the user selects a normal application command (mapped to an operation link), DHymE passes the command on to the application for processing. If the user selects a hypermedia engine link (e.g., to create an annotation), DHymE processes it entirely. If the user selects a supplemental relationship, DHymE infers the appropriate application commands, meta-application operations (e.g., at the operating systems level or schema level) or hypermedia engine operations that will produce the desired information. If the user selects a user-created annotation, DHymE retrieves it. Thus DHymE automatically provides all hypermedia linking (as well as navigation) to applications, which remain hypermedia-unaware and in fact often entirely unchanged. We currently are integrating several applications with DHymE, automatically giving each a Web interface or supplementing its existing Web interface: a personnel requisition tracking system, a relational database management system, a spreadsheet, and a mathematical model management system. [Bi99] describes these ideas and an older, non-Web prototype of DHymE in more detail.


There are many interesting issues involving virtual documents when mapping hypermedia to analytical applications. Here are a few:

* Parsing Virtual Documents

How do we parse the virtual documents created by analytical applications to determine where the elements of interest are? If an element of interest has a mapping rule for its element type, then the DHymE hypermedia engine creates a link anchor over that element of interest corresponding to the mapping rule.

* Document Specifications

How does one specify the set of commands that have to be passed to an application to create a specific document or screen? What parameters will be needed to specify a particular instance? These commands must be written in a general way and embedded in a mapping rule. It then must be instantiated with the particular instance that the user wants to see, based on which link anchor the user has just selected.

* Regenerating Virtual Documents

Suppose the user creates a bookmark or a stop along a guided tour to a virtual document or screen. Then the document or screen is closed. How do we regenerate that document or screen later, especially if the user had to input parameter values to create it in the first place? (We don't want to ask the user to re-input these parameter values.)

* Target Areas

How do we specify specific arrival anchors (target areas) within virtual destination documents once a link has been traversed and the virtual document is about to be displayed?

* Saving Virtual Documents

Who owns a virtual document - the user or the application? If the user saves it, do we strip out the hypermedia components we added to the document for integrity purposes? Should it be stored centrally by the DHymE engine or locally on the user's disk? May it be altered by the user or would the system creator wish to keep it intact for legal or copyright reasons?

and the old standard problems:

* Link and Annotation Integrity

If the content of the document changes, how do we relocate links?

* Link and Annotation Relevance

How do we know when a link or annotation has lost its relevance?


[Bi99] Bieber, M. "Supplementing Applications with Hypermedia," under revision for ACM Transactions on Information Systems. [On-line:]

[BK95] Michael Bieber and Charles Kacmar, "Designing Hypertext Support for Computational Applications," Communications of the ACM 38(8), 1995, 99-107.

[BY99] Bieber, M. and J. Yoo, "Hypermedia: A Design Philosophy," in submission. [On-line:]