METHOD FOR BUILDING A HYPERMEDIA INFORMATION MANAGEMENT TOOL

Abstract: A method for building a hypermedia information management tool in an object-oriented programming environment is provided. The method employs Selection/Output Interpreters (SOIs) and hyperstructures. An SOI is an object that controls a display and user selection of display icons, and a hyperstructure is an object that controls data retrieval and interprets user selections. This method produces an information management tool that has the capability of providing a common user interface to a plurality of diverse computer systems.

Description: Met od for Building a Hypermedia Information Management Tool Technical Field of the Invention The invention relates to computer-based information management tools and more particularly to a method for building such tools, and tools built thereby. Background of the Invention A large portion of application programs running on computers today support one or more information management tasks. These application programs often require information retrieval (IR) and information processing (IP) functions and features. Large application programs like these are often referred to as IR and IP systems, respectively. An information management tool provides some IR and IP functions, as well as functions that are often considered part of management information systems (MIS), data base management systems (DBMS), decision support systems (DSS), and question answering systems (QA). These different information system types are described in pages 7 to 10, Chapter 1 of INTRODUCTION TO MODERN INFORMATION RETRIEVAL by Gerard Salton and Michael McGUl, McGraw-Hill Book Company, 1983. Information management tasks are diverse and far-reaching and tools satisfying the needs of the people doing these tasks have evaded traditional approaches toward tool building. Com¬ menting on this, Salton and McGill (pages 426 and 427) motivate the need for mixed information retrieval systems. In this document, the functionality of an information management tool may include the functionality implied by mixed information retrieval systems. Typical IR and IP tools are constructed as shown in figure 2A, with application programs 100 imple- menting the tool functionality. These programs may communicate with other programs, and communicate directly with the Input Output (I/O) devices and drivers 110, as well as the databases 120. However, the applications are not readily portable to different platforms because the interface program code is tied very tightly to the application code. This means that it is very difficult to separate the application code from the interface code. To port application programs to other I/O devices and databases, much of the application code must be rewritten in general. Since the interfaces to the I O devices and databases are tied closely to the application code, different applications cannot easily share a common high-level data¬ base and/or operator interface. There is a growing emphasis on content-based document handling in information system research today (see the proceedings of the RIAO 88 conference). Specifically, much effort is spent finding betters ways to: automatically extract content information from documents of many types, organize that information for later use, store it in an efficient and effective way, retrieve that information, and provide ways to present information so it fits specific needs for a variety of users. The need for this technology is obvi¬ ous. Already in the average office environment there is much more data available than there are applica¬ tions to use that data effectively. In many cases, even the data that is available is that which is most easily gathered rather than that which is most important for later use. Compounding the problem, developments in media technology are enabling the increasing availability of data for nontraditional media (e.g. voice, images, video). Obviously, better information management tool-building tools are needed in response to these trends. Typically, IR and IP systems require large and costly development efforts and require continued costly maintenance. The IR and IP functions of such systems are difficult to integrate and generally lack com¬ mon interfaces. These systems are most often platform-dependent as well. Today, the kinds of data (media) processed are of a greater variety than in the past Voice, video, and graphics are examples of media that require special storage, processing, retrieval, and interface mechanisms. These problems are compounded due to the need for more sophistication and functionality as described earlier. Making great inroads in these information management tools is an emerging technology called "hyper¬ media". The term "hypertext" has been used to refer to the general notion of supporting associative links between pieces of text With recent advances in computing technology, "hypertext" and its more general form, "hypermedia" have been realized through computer programs. Recently, hypermedia has been res¬ tricted in definition to refer to windows on a computer screen that are associated with objects in a data¬ base, the support for links between these database objects, and a mechanism that gives the user the abil¬ ity to interact with these objects. See "Hypertext: An Introductory Survey" by Jeff Conklin in IEEE COMPUTER, September, 1987, and the special issue on hypertext in the Communications of the ACM, Vol. 31, No. 7, July 1988, for descriptions of hypertext and hypermedia. A programming environment particularly suited to handling database objects is an object-oriented programming environment There are many well-known advantages to object-oriented programming. OBJECT ORIENTED PROGRAM¬ MING: An Evolutionary Approach, by Brad Cox, Addison-Wesley, 1986, describes these advantages as well as introduces essential object-oriented programming concepts. For an information management tool, hypermedia technology offers a simple user-machine interface paradigm based upon a user "selecting" interface icons (from a display, like for example, a window con¬ taining graphics) with an input device, like for instance, a mouse. The link(s) associated with the selected icon is(are) used to retrieve associated data. In addition, hypermedia techniques are being developed to handle various media. Hypermedia has been applied to problem domains including: computer-supported authoring, computer- supported cooperative work, information retrieval, computer-aided instruction, to name a few. In spite of its successes, hypermedia has not been generally useful for many information management tools. There are several reasons for this. There is little commonality to date among the hypermedia tools, making them as costly to build and maintain as more conventional tools. The simple interface scenario has led to limitations in capability and flexibility. In most cases, the links between objects in the database have to be hand-crafted before a tool is useful, and many of the retrieval functions found in IR tools are miss¬ ing. In addition, hypermedia tools tend to be isolated, lacking hooks to other tools and are tied to proprietary data structures. Another inadequacy of current hypermedia systems is the problem of navi¬ gating in "large unfamiliar heterogeneously structured networks" ("Reflections on Notecaids: Seven Issues for the Next Generation of Hypermedia Systems" by F.G. Halasz in COMMUNICAΗONS of the ACM, Vol. 31, No. 7, July 1988). Finally, although some hypermedia tools have a programming language that accompanies them, there is little support far building information management tools. Even if current definitions of hypermedia do not fully support the needs of information management tools, these tools can benefit gready from hyper- media features and functions. As described above, hypermedia technology will play a larger role in information management tools of the future. It is an object of the present invention to solve the problem of providing a method for building hyper¬ media information management tools that smoothly integrates hypermedia technology with traditional IR and IP technology. It is a further object of the present invention to provide an information management tool that performs as a common user interface to a plurality of diverse computer hardware and software systems. Summary of the Invention The present invention solves the problem by providing a method called Hylink for building hypermedia information management tools that retrieve, process, and display information. The Hylink method pro¬ vides a means for applying specialized features and functionality related to this technology as it pertains to the needs of IR and IP. The Hylink method encourages the application builder to build tools that incorporate existing databases and specialized application programs, alternative forms of presentation media and selection devices, as well as stresses program reusability, tailorability, distributed processing, and user interface simplicity. The Hylink method is influenced by the expectation that future information management tools will require a broad spectrum of media data types and have to be easily tailorable to specific needs. The Hylink method is performed in an object-oriented programming environment and employs objects called Selection Output Interpreters (SOIs) and Hyperstructures to generate a hypermedia information management tool. An SOI is an object having a data structure that includes a hyperstructure lookup table associating a display icon with a hyperstructure. The data structure of the SOI also includes: a procedure to associate a display icon with a hyperstructure in a hyperstructure lookup table; a procedure to display a specific data type; and a procedure for defining a selection-context and calling a hyperstructure associ- ated with a display icon. A hyperstructure is an object having a data structure that includes: a context-indicator table for holding instructions for processing an icon and associated context information; a table for holding data to be displayed; and a pointer to an SOI. The hyperstructure data structure also includes: a procedure for pro¬ cessing a context-indicator table; a procedure for locating data to be displayed; and a procedure for cal- ling an SOI to display die data. According to the Hylink method, a hypermedia information management tool is built by: creating an instance of an SOI; creating a function to build a hyperstructure instance; creating a function to define the output format for a display device type; creating a function to define the input format for a display device type; and initializing a display instance. Once this is done, a user interacts with the system to accomplish an information management task. Interacting with the system and retrieving data causes information objects and relations to be created in the system. This provides further opportunities for the user to retrieve and manipulate data from other sources and of different types. Thus, through interaction with the system by the user, the system grows (filling with data) in a way that fits the special needs of the user. The Hylink method provides a simple user-machine interface paradigm enabling user-centered system design. This, in turn, lowers development costs and encourages the use of common user-machine inter¬ faces by means of libraries having reusable components. The method provides a means for integrating hypermedia with other information management techniques as well as enabling the use of a variety of media as data. Independent applications and data resources are easily integrated in application code that can be made relatively platform-independent The integration of IR and IP functionality with hypermedia technology is achieved without relying on proprietary data structures. Hypermedia enhancements, like dynamic creation of hypermedia links and application extensibility, increase information management tool functionality while reducing development effort Brief Description of the Drawings Figure 1 is a schematic diagram showing an overview of the invention; Figure 2 shows a comparative view of information management tool architectures; Figure 3 shows a flowchart of the Hylink Method used for building a hypermedia information management tool; Figure 4 is a schematic diagram showing the selection handling process for a display; Figure 5 is a schematic diagram showing die process created for each SOI to handle user selection; Figure 6 shows the EP-LINK login display; Figure 7 shows die top layer display for EP-LINK; Figure 8 is an EP-LINK display showing an information retrieval task demonstrating expanding text in the primary pane of the top layer in EP-LINK; Figure 9 is an EP-LINK display showing an information retrieval task demonstrating expanding text in the primary pane of the top layer in EP-LINK; Figure 10 is an EP-LINK display showing a menu giving die user media options for displaying information; Figure 11 is an EP-LINK display showing an information retrieval task demonstrating automatic formating of text in the primary pane; Figure 12 is an EP-LINK display showing a window collection in the assembly layer and highlighting of and assembly component object in a graphic pane; Figure 13 is an EP-LINK display showing the highlighting of and assembly graphic identification number just prior to selecting it with the pointing device; Figure 14 is an EP-LINK display showing an assembly text overlay window for accessing textual information related to the assembly being viewed in the assembly layer; Figure 15 is an EP-LINK display showing information access in an assembly text overlay window; Figure 16 is an EP-LINK display showing information filtering and dynamic link creation of parts list information in an assembly text overlay window; Figure 17 is an EP-LINK display showing several component window collections in the component layer; Figure 18 is an EP-LINK display showing information access mode selection from a command pane in the component layer; Figure 19 is an EP-LINK display showing retrieved and formated information displayed in an object pane within the component layer; Figure 20 is an EP-LINK display showing information access modes selected in the assembly text overlay window; Figure 21 is an EP-LINK display showing ECO information menu options and highlighted com¬ ponents in an assembly graphic that are affected by the selected ECO; Figure 22 is an EP-LINK display showing annotation filters for the assembly layer, Figure 23 is an EP-LINK display showing audio annotation icons for the assembly layer; Figure 24 is an EP-LINK display showing text annotation icons and editing of a text annotation in the assembly layer; Figure 25 is an EP-LINK display showing example interactions with the note pane, typein pane and history pane in the top layer, Figure 26 is an EP-LINK display showing new mail notification and a note buffer list for the note pane in the top layer; Figure 27 is a diagram showing the different layers in EP-LINK; Figure 28 is a functional diagram of the top layer in EP-LINK; Figure 29 is a functional diagram of the assembly layer in EP-LINK; Figure 30 is a functional diagram of die component layer in EP-LINK; Description of the Invention A portion of the disclosure of this patent document contains material to which a claim of copyright pro¬ tection is made. The copyright owner has no objection to the copying of the patent document or die patent disclosure, but reserves all other rights. 1 Introduction The Hylink method requires an object-oriented programming environment in which to build hypermedia information management tools. Object-oriented programming is based upon the notion of 'objects', where each has a local state (data) and a collection of procedures (called methods) that allow it to com- pute things. Objects are sent 'messages', calling their associated methods. The 'class' represents the object data type. An object-oriented programming environment is a combination of computer hardware and software that supports the process of object-oriented programming. Examples of object-oriented languages are: Smalltalk, Flavors, C++, Objective-C, and CommonLoops. The Hylink method relies on the concepts found in object-oriented programming, yet is not tied to a par- ticular object-oriented language. The EP-LINK hypermedia information management tool described below, portions of which were built according to die Hylink method, as well as some Hylink constructs are implemented on a platform including die programming languages Common Lisp, and IT Lisp exten¬ sions, as well as the MIT Flavor object-oriented programming system. In the example described below, die Hylink method was performed on an Explorer II workstation by Texas Instniments, Inc. (Explorer is a trademark of Texas Instniments Inc.). Referring to die Drawings, Figure 1, the hardware includes an operator interface having a visual display (CRT) 10, a keyboard 12, and a pointing device 14 (a 3 button mouse), and a speech processing module 13 including a microphone and a speaker for digitizing speech to be recorded and reproducing digitized speech. The hardware also includes mass memory, disk 16, as well as a CPU and main memory 18 running the object-oriented pro- gramming language system Flavors 22 and d e CommσnLisp programming system 20. The Hylink software resulting from the Hylink method includes: an SOI 24, a hyperstructure 26, a function to build a hyperstructure instance 28, a function to define an output format 30, and a function to define an input format 32. An SOI is an object having a data structure tiiat includes a hyperstructure lookup table associ¬ ating a display icon with a hyperstructure. The data structure of the SOI also includes: a procedure to associate a display icon with a hyperstructure in a hyperstructure lookup table; a procedure to display a specific data type and a procedure for defining a selection-context and calling a hyperstructure associated with a display icon. A hyperstructure is an object having a data structure that includes: a context-indicator table for holding instructions for processing an icon and associated context information; a table for holding data to be displayed; and a pointer to an SOI. The hyperstructure data structure also includes: a procedure for pro- cessing a context-indicator table; a procedure for locating data to be displayed; and a procedure for cal¬ ling an SOI to display die data. The hardware components of the workstation are connected by a bus 34. Referring to figure 2B, which schematically depicts a hypermedia information management tool built by the Hylink method, it can be seen that the Hylink method promotes the use of specialists that communi- cate with the I/O devices and drivers 130 and the data 160. These specialists are the Selection/Output Interpreters (SOIs) 140 and hyperstructures 150, tiiat communicate with die data bases 160, I/O devices 130, and the application programs 170. The SOIs 140 manage the tool interface for the application pro¬ grams, and the hyperstructures 150 manage database access, link following, and coordination tasks for die application programs 170. The Hylink method results in broad application coverage and user-interface simplicity. The method makes the information management tool-building process easier while providing d e features necessary to capture a wide range of functionality. One area in which simplicity plays a role is in describing a tool interface. The user-machine interaction scenario for Hylink-built tools (such as EP-LINK) is one in which a use "selects" icons from a display using an input device such as a pointing device. The tool interprets the selection, calling appropriate actions and responds (by displaying data) to the user so she can, in turn, make another selection. All user input is treated as a selection. Figure 4 shows the selection-handling process that is representative of tools built using die Hylink method. After the user selects a display icon using an input device, an SOI instance processes the selec¬ tion 40 by determining the selected icon's type 42, and locates the icon's associated hyperstructure 44. If successful, a selection-context is built 46 and the identified hyperstructure is called 48, passing it die selection icon and die selection context. The hyperstructure tiien determines die intent of die selection 50 by processing context indicator tables stored in the hyperstructure 52. This process produces eiti«r data to display, a function tiiat can be used to locate data to display, or neither of tiiese. If tiiere is a function to locate the data, tiiis is called 54. If tiiere is data to be displayed, an appropriate SOI instance is located to display die data and the data, context, and a display action are sent to that SOI instance 56. The receiving SOI instance displays that data 60 by creating an appropriate hyperstructure 62, associat¬ ing it with a string (called die print name) in die hyperstructure lookup tables 64, and displaying a suit¬ able icon representing die data itself 66. 2 Overview Referring to figure 3, the Hylink mediod for building hypermedia infoimation management tools includes die steps of: gadiering requirements 30, creating Selection/Output Interpreters (SOIs) 32 for all displays, creating functions to build specific hyperstructure instances 34, creating functions to define output for¬ mats 36, creating functions to define input formats 38, and initializing at least one of the display instances 39. The step of gadiering requirements 30 is left to the tool designer and Hylink does not provide any specific support here. However, die Hylink mediod does not restrict a designer to any specific approach for the requirements capture step. The Hylink SOIs represent abstractions of die displays. An SOI is an instance of an SOI class. There may be more than one SOI class, named differendy but related. The SOI class includes a data structure for holding descriptive information about its associated display as well as hyperstructure lookup tables (described below). The SOI class also has procedures for displaying specific types of data in the form of display icons on its associated display type, associating selected display icons with hyperstructures in die hyperstructure lookup tables, and defining die context in which a selection is made of a display icon from its associated display. For each display type (e.g. graphics window, text window, text window with scrolling, text window with annotations, etc.) the tool builder creates the procedures above and creates instances (called instantiating) of the SOI classes. One of the advantages of this object-oriented approach is that SOI classes may be reused, copied, and edited. The hyperstructures are used as intelligent linking mechanisms between data. Data may be objects in an object-oriented programming sense, or any data type. A hyperstructure is an instance of a hyperstructure class that is a data structure having a context indicator table for holding instructions for interpreting die intent of a user's selection of a display icon. Display icons are associated with hyperstructures in an SOI's hyperstructure lookup table. The hyperstructure relies heavily on data representing die context of the selection. The hyperstructure data structure also holds any data that is to be displayed as a result of processing die context-indicators and may hold a function that can be used to locate such data. There is also a pointer to an SOI instance that is called to display any of this data. The hyperstructure class has procedures for processing die context-indicator tables, a procedure for locating data to be displayed and a procedure for calling an SOI instance to display data. Hyperstructures are created to represent the application tool functionality. The builder creates functions that build specialized hyperstructure instances. Creating these functions requires the builder to specify die context-indicators according to some guidelines described below. Once these hyperstructure-building functions are created, tiiey can be called by die SOIs. The SOIs call these functions to create hyper- structures tiiat they associate with display icons in their own hyperstructure lookup tables. The functions to define die output formats 36 and input formats 38 tie die SOIs to die actual display(s) and actual input device(s), respectively. These functions translate abstract actions at the SOI level to actions at the device level (and vice versa) for the specific devices used. These functions may be low level (like device drivers) or at a higher level (e.g. using high level standard packages like GKS or CORE graphics standards). Above die level of these functions, a Hylink-built tool is not dependent on a particular platform with respect to its interface functionality. The step of initializing at least one of the display instances 39 is necessary because there must be some display icons from which die user can make a selection. In addition, diere must be at least one hyper¬ structure instance created to process die selection. The initialization is done in one of three ways. The first is to send an SOI some data to display (i.e. pretend to be a hyperstructure instance calling an SOI with some data to display). The second is to send a hyperstructure some data and a predefined selection context so that the hyperstructure can locate or compute some odier data tiiat it will send to an SOI to display (Le. pretend to be an SOI handling a selection by calling a hyperstructure). The tiiiid approach is to down-load at least one SOI witii a predefined hyperstructure lookup table and tiien call functions to display some display icons (Le. pretend to be an SOI displaying data). Once a display instance is initialized, a user can interact with the system to accomplish an information management task. Interacting with the system and retrieving data causes information objects and rela¬ tions to be created in the system. This provides further opportunities for the user to retrieve and manipu¬ late data from other sources and of different types. Thus, through interaction with die system by the user, the system grows (filling with data) in a way that fits die special needs of die user. 3 The Selection Output Interpreters (SOIs) As far as end users are concerned, interfaces to tools built with the Hylink method may be no different from those built any other way. The Hylink method does not restrict the range of display or interaction modalities. For die tool builder, however, die mediod simplifies d e interface building process dirough the use of SOIs which act as interface front-ends to die application programs. It does this by treating all input to an application program as a selection of an interface icon. In doing this, the programmer can take advantage of a common representation for the selection itself, the selection context and die linking of interface icons to their respective hyperstructures. The SOI is a class that is responsible for two things. First, it takes input data and interprets it as a user's selection of an icon from an output device. The icon's print-name is used to locate a hyperstructure in the hyperstructure lookup tables stored witiiin the SOI data structure. The hyperstructure will carry out actions interpreting the intentions of d e user's selection. The second thing the SOI is responsible for is to prepare data that is given to it by a hyperstructure to be displayed. This involves specifying which of the data needs to be displayed, creating display icons for that data, determining which display icons should be made selectable, associating hyperstructures witii those display icons, and displaying die display icons on its associated display. 3.1 Output Devices Output devices refer to die logical or physical devices upon which data are displayed. Typically, output devices refer to physical devices such as a video display terminal (for text graphics, and images) or a speaker (for audio or voice). The development of windowing systems has allowed portions of a video display (called windows) to have very different characteristics and behaviors. These windows are as different in kind as physical devices might be and thus may be considered to be different logical output devices. Within tins disclosure, die words "output device" are used to refer to both physical and logical output devices as described above. The terms "display device" and "output device" are used synonymously as well. The term display is used throughout this disclosure to mean die rendering of data (referred to as display icons) on an output device. The data can include speech and die rendering of speech data will be referred to as display. 3.2 The SOI Class Object The SOI is a class that has two general functions. First it takes input data and interprets it as a user's selection of an icon from an output device. The icon's print-name is used to locate a hyperstructure in the hyperstructure lookup tables stored within the SOI data structure. The hyperstructure will cany out actions interpreting the intentions of the user's selection. Within an SOI (and across SOIs), many display icons may be associated widi the same hyperstructure. In addition, several different display icons may be used to display die same data and refer to the same hyperstructure. The SOI maintains its own lookup tables for this purpose and may inherit die lookup tables from the transitive closure of SOIs via the PARENT-SOI slot in die SOI data structure. This is very useful because die hyperstructure lookup tables are one way to capture context information. This is because die same data may be associated with different hyperstructures in different SOIs (and therefore, different displays). Since the hyperstructures represent different sets of instructions for processing die data when it is selected, this effectively means tiiat a selection produces different results under different cir¬ cumstances. If a hyperstructure is found, data representing the context of die selection is packaged as an instance of a selection-context object The hyperstructure associated witii the selected display icon is called with the selection-context instance and die selected icon as arguments. The modular nature of hyperstructure lookup tables offers several advantages. First an SOI can be down-loaded with, or stripped of, specialized lookup tables that will affect die functionality of the SOI but will not interfere with the content of its otiier tables. This is also a way for SOIs to share hyperstruc¬ ture lookup tables. In addition, tiiis approach makes it possible to add sophisticated table selection func¬ tions tiiat will change the behavior of an SOI depending upon state data. A process is created for each SOI to monitor input events. A typical process is shown in figure 5. The process is described as being in a wait state until a user makes a selection of an icon 210 from the SOI's associated display. When this occurs, a separate process is created to handle die selection 200 and die wait state is entered again until there is more input Separate processes are not necessary but can often increase tool responsiveness. The second function of the SOI is to prepare data that is given to it by a hyperstructure to be displayed. This involves specifying what needs to be displayed, where and how to display it and determining which of die displayed icons should be made selectable. To display die display icon, functions defining die output format are used. Before becoming selectable, a datum needs a hyperstructure associated with it to carry out the appropriate actions when the display icon is selected. This association is made prior to displaying any icons for the data. This involves locating or creating a hyperstructure for the data 62, as seen in figure 4, and associating the print name for the data witii die hyperstructure in a hyperstructure lookup table 64. To do this, the SOI first looks for a suitable hyperstructure in its lookup tables. If one is not found, it creates one using information about die data, die display device and die context of the previous selection. There is a great deal of flexibility in this process because during the second step of the tool-building process 32 (in figure 3) creating die SOIs includes creating functions to determine which type of hyperstructure to create and associate with any datum. Referring to figure 3, die second step 32 in applying the Hylink method is to create an SOI instance for each display device. Given a collection of existing SOI class descriptions, this may be simply a matter of instantiating a suitable SOI class tiiat has already been defined by die programmer. In other situa- tions, die appropriate SOI class will need to be created by the programmer. The SOI instances provide common features of selection handling (device independent) as well as die specializations needed for particular display devices. Similarities between devices (different types of windows, for instance) pro¬ vide opportunities for reusing and/or copying SOI class descriptions, thus reducing development time and encouraging the use of common user interfaces. 4 Hyperstructures A hyperstructure object is an instance of a hyperstructure class that selects and executes appropriate actions when a user selection has been made. Hyperstructures are called by SOIs and use die selected display icon data along with context information provided by die SOI (in die form of a selection-context object instance) to interpret the selection far the information management tooL The range of possible processing actions is not limited in any way by die hyperstructure. The selection interpretation may include calling specific application programs, identifying and/or retrieving data from local or remote databases, packaging that data in a form that provides an appropriate response to die user selection. The hyperstructure also identifies an appropriate SOI to send any data that should be displayed. With respect to hypermedia, die hyperstructures represent sophisticated links that also have information about how to process themselves. Hyperstructures, in effect orchestrate the application's response to the user's selec¬ tion. There are three main advantages of Hyperstructures. First they are sharable. In situations where die selection of different display icons initiates similar application responses (e.g. follow the same link type), they may be associated in an SOI hyperstructure lookup table with die same hyperstructure. The second advantage is that tiiey provide die glue for integrating independent application programs (like text editors, data analysis programs, expert systems, mail, etc.), as well as remote and/or disparate databases, thus tying die outside world to a hypermedia information management environment Third, they are high-level embodiments of application knowledge that lend themselves to better clarity, understandabil- ity, and a greater potential for reuse. Hyperstructure instances are created and linked to the print-names of the display icons displayed by die SOIs. The links are stored in the hyperstructure lookup tables in the respective SOIs. Using the generic hyperstructure class description, a designer of a hypermedia information management tool using the Hylink tool is responsible for specifying what each hyperstructure instance should look like. The pro¬ grammer then creates the functions that die SOIs use to build die specific hyperstructure instances. This is the third step 34 shown in figure 3. These functions represent different hyperstructure types for the application tool The different hyperstructures include hooks to other application programs and/or data querying and retrieval capability that may be used to process display icon selections. Only a few different hyperstructures are needed to support sophisticated applications. The EP-LINK hypermedia information management tool described below demonstrates this by having only three different hyperstructure types. Defining the different hyperstructures is a large portion of the tool build¬ ing process. Hyperstructures lend themselves well to support from hyperstructure libraries and special purpose hyperstructure-creating tools. The presendy preferred hyperstructure class data structure (Flavor definition) is given in table 1 below. The methods associated witii the hyperstructure class are shown in appendix 1. (defflavor HYPERSTRUCTURE (RELEVANT-FOR ;This is the Context-Indicator table indicating ;what actions to take once the hyperstructure is invoked. REFERRED-TO-INSTANCE ;This is the instance of the class being referred to by ;the selected display icon. ;The following slots are filled by the actions taken when ;the RELEVANT-FOR slot is processed upon selection. (LOCATE-ACTION nU) ;A function that, when invoked, finds the data that will ;be displayed. (DISPLAY-ACTION .display-text) ;A function (actually a method) that will do the actual displaying of the data (default function is to display ;the data as text). (DATA nil) ;This is the data to be displayed. SOI ;This is a pointer to the SOI that the data and the ;display request are sent to. ) 0 nnittable-instance-variables :gettable-instance-variables .settable-instance-variables) Table 1 • Hyperstructure Flavor Definition When a hyperstructure is called it uses die selection-context sent to it by the calling SOI and die context-indicator tables found in its RELEVANT-FOR slot to determine what where, when, and how die selection is to be interpreted. This is equivalent to determining how the sophisticated links associated with die selected data should be traversed. If data is retrieved to be displayed, die hyperstructure places it in its DATA slot After locating an appropriate SOI to display die data, a pointer to that SOI is placed in the SOI slot If the hyperstructure makes a decision about how the data will be displayed (e.g. as text as opposed to in a graphical form), this is recorded in the DISPLAY-ACTION slot If die data is not retrieved until die time in which it is to be displayed, the access function can be put in the LOCATE-DATA slot Below, the RELEVANT-FOR slot is explained in more detail. The RELEVANT-FOR slot value is the context indicator table that holds die instructions for interpreting the selection. One way this may be implemented is using an association list data structure (as described below) to represent the context- indicator table. The association list has keys (enumerated below) that indicate the nature of their associ¬ ated functional values. Once called, a hyperstructure tests the conditions held by die context-indicator keys in the RELEVANT-FOR slot and calls the appropriate associated functions. Table 2 lists the presently preferred context-indicator keys found in die RELEVANT-FOR slot with a description of how they are used. 'ALWAYS-BEFORE • Condition always returns true and invoke the associated function as the first thing done when the hyperstructure context-indicator tables are processed. 'ALWAYS-AFTER • Condition always returns true and invoke the associated function as the last thing done when the hyperstructure context-indicator tables are processed. 'EXACT-CONTEXT - When used, the value is a list of pairs in which the first of each is either an object instance or the printed representation of one. A condition is true if the item in the CONTEXT slot of the selected-context is equal to one of these <exact-contexts>, then the associated member of the pair is called. 'CONTEXT-DEPENDS-ON-FLAVOR - Like EXACT-CONTEXT above, the value is a list of pairs. The only difference is that in this case the first member of each pair is the name of a class object A condition is true if the item in the CONTEXT slot of the selected-context is a display icon and if the value of the REFERRED-TO-INSTANCE variable, for the hyperstructure associated with that icon, depends on the class given here, then call the associated function. If the CONTEXT is an object instance itself and if it depends on the class given, then evaluate the associated function as well. 'FUNCTION - When used, the value is a list of pairs in which both members are functions. For any pair, a condition is true if the first function returns T when evaluated with the selection-context and the hyperstructure itself as arguments, then the second function in the pair is evaluated with the same arguments. 'DEFAULT - When used, the condition is always true and the associated function is evaluated if none of the previous three context indicators is successful Table 2 • Context-Indicator Keys The RELEVANT-FOR slot is processed in the following manner. (Note: "call the function" actually means call it using the selection-context and die hyperstructure itself as arguments.) If there is an ALWAYS-BEFORE entry, call die function associated with it Next start with the EXACT-CONTEXT entry and try to match die first member of any pair (as described in table 2) to the value of the CON- TEXT slot in die selected context If any condition is true, call the associated function. If successful, process die ALWAYS-AFTER entry and stop. If not successful, do a similar thing for the CONTEXT- DEPENDS-ON-FLAVOR entry. If a condition is found one, call die associated function, process die ALWAYS-AFTER entry and stop. Odierwise, look for a function pair in die FUNCTION entry for which calling die first member returns true. If successful, call the associated member function, process die ALWAYS-AFTER entry and stop. Finally, if no condition in the previous three entries is true, call the function in the default entry. If there is an ALWAYS-AFTER entry, call the function found tiiere. The ALWAYS-BEFORE and ALWAYS-AFTER functions are always done, but only one action can be selected from the EXACT-CONTEXT, CONTEXT-DEPENDS-ON-FLAVOR, FUNCTION, or DEFAULT entries (and these are tested in order). Changes to the context-indicator table, as well as die way in which it is processed, may be changed to achieve specific functionality. The structure and process described here is only one example that has proven useful The use of hyperstructures alleviates the following inadequacies of current hypermedia systems. These are: node network reconfigurability, navigation, node composites, extensibility, and tailorability. The fol¬ lowing paragraphs describe these issues. The EP-LINK tool which was built using the Hylink method of die present invention demonstrates how links between concepts are created dynamically by die Hylink method. Links are created when the SOI recognizes the type of data that is being displayed and creates an appropriate hyperstnicture instance to interpret that data when it is selected by a user. The hyperstructures use context information to deter¬ mine what die displayed data will be linked to and how to traverse those links. The node network is vir- tual, only viewed as an artifact of selection interpretation. This application demonstrates one approach to dynamic link creation (or netwoik reconfigurability). It is very successful because, although there is a large amount of diverse data tiiat is accessible, all of that data is related in obvious ways to a small number of object types. For example, one of these types is the electronic assembly. After defining a object description for a generic electronic assembly (with respect to the customer's business), much of the data that is retrieved from remote databases would partially fill an instance of this type. The assem¬ bly object brings structure to the data and die attributes of die object are used to determine how the data might be used. The EP-LINK tool shows that the Hylink method may be used to test different approaches to dynamic link creation. As noted previously, one inadequacy of current hypermedia systems is the problem of navigating in "large unfamiliar heterogeneously structured networks". Hyperstructures can be defined to recognize par¬ ticular pieces of these networks. Each hyperstructure may be an expert in following specific links and retrieving specific types of information. The hyperstructures act as filters for the user, making the net¬ woik appear to be familiar and well structured. In addition, since hyperstructures are linked to die displayed objects dynamically, die linking, navigation, and retrieval methods can be selected to fit the context of the user and the complexity of the application. In addition, content-based querying may be used in which true navigation gives way to a more direct access approach to retrieval. Since the node netwoik is virtual, the content search capability used is tailored to die source data itself (and will often already exist). Hyperstructures can very easily accommodate a content-based querying approach and SOIs can readily handle query-style input Hyperstructures can capture the same information that would exist if hypermedia node composites were explicitly maintained, but without die overhead of doing tiiat Influenced by the feature of dynamic link creation, many nodes found in tools built using die Hylink method will be virtual. In other words they will not be represented by a specific node data structure. In most cases, this eliminates the need to main- tain explicit node composite data structures since they will be virtual in nature as well. If, however, a tool required explicit nodes and composite node, the Hylink approach accommodates tiiis quite well in the form of several simple hyperstructures that understand these node structures. I have defined hyper¬ structures tiiat handle Flavor objects representing information nodes, and these Flavor objects are very similar in kind to what one would expect to find in hypermedia node data structures. The Hylink mediod directly supports tailorability and extensibility. Both the hyperstructures and the SOIs are intended to make both of these easier as their very nature is modular and additive. 5 The EP-LINK Hypermedia Information Management Tool 5.1 The Information Problem The EP-LINK tool was built to solve an information management problem for an organization that manufactures electronic assemblies. The need resulted from a very common situation within large busi¬ ness organizations. Due to a variety of functional needs, diverse collections of computer hardware and software tools to keep track of product configuration, parts lists, manufacturing processes, and inventory were acquired over time. This lead to inefficiencies resulting from data redundancy, heterogeneous data models and database query systems, a variety of inter-machine communication systems, and the lack of knowledge (on die part of the users) about what data existed, where it resided, where and when it was used, and how to access it 5_2 The EP-LINK Solution The solution that the EP-LINK tool provides is to place a "shell" around the existing systems providing a single point of entry to the diverse collection of information sources. Incorporating some of the features of hypermedia, a shell system can go beyond merely granting access to a variety of other systems by providing a unifying view of the entire information space tailored to specific user needs. This approach is called an "intelligent shell system" solution. In die shell solution described above, the principal benefactors are those individuals tiiat need access to information from a variety of information resources. In the case of electronic assembly manufacturing, an activity that requires accessing data from diverse sources is die handling of engineering change orders (ECOs). The introduction of an ECO (a very common occurrence) may affect much of the data and many of the processes throughout die organization and across many computer systems. Manufacturing processes, test programs, bill of materials, and scheduling data (to name a very few) may need to be updated for a particular assembly. Many people need to be notified and a variety of information must be available for them to make their specific changes. The EP-LINK tool reduces die perceived distance between die users and die information they need. 5.3 The EP-LINK Interface Paradigm The Hylink mediod was used to build the EP-LINK tool. The system is specifically tailored to the needs of die people that use it and is not intended to be a general hypermedia system. It does, however, share many of die features of hypermedia and is an example of a hypermedia infoimation management tool. EP-LINK demonstrates a unified interface providing transparent access to data residing on several different computer systems. It provides an interface widi die "look and feel" 'of the electronic assembly manufacturing business and uses an interface paradigm in which users select icons (e.g. strings, graphical objects) from a display and are provided with information related to those icons within the context of the selection. EP-LINK has the ability to filter and combine retrieved data so that it best fits the needs of die user. This is accomplished by defining descriptions of key objects of the business (like assemblies, ECOs, etc.) that may be found in die data so that the tool can automatically identify and create objects (nodes) for data that fit those descriptions. It demonstrates die ability to create links between related data automatically at run time and supports a wide variety of presentation media types. Generally, a user may move freely between related data widiout getting lost in the search process and die EP-LINK interface tool provides many ways for the user to get to the same information from different points of view. In addition to being hypermedia-like, die interface follows a metaphor of layered composition, making it easier for the user to keep from "getting lost in the information". A user thinks of different types of information access in terms of EP-LINK layers. Adding information management applications is analo- gous to adding a layer. A cross-layer history mechanism is used to keep users from losing track of what they have done and where they have been in the information management task. The EP-LINK tool currently has three layers as shown in figure 27. The layers are: TOP LAYER 1100, ASSEMBLY LAYER 1102, and COMPONENT LAYER 1104. Each of the layers use collections of windows to present information to a user. These window collections are called frames. During an information management task, there may be more than one frame instance used in the assembly and component layer. These multiple frame instances are used to display information associated witii different electronic assemblies and assembly components, respectively. The top lays' uses only one frame instance. The frames are composed of windows (also called panes) that are functionally and logically connected. Diagrams of the frame types for particular layers are shown in figure 27 and are referred to as the top layer frame 1106, die assembly layer frame 1103, and the component layer frame 1105. The TOP LAYER provides general information access dirough a variety of means. The TOP LAYER provides die principle entry point for a user information session. In addition to providing access to a variety of information, die TOP LAYER provides several ways for a user to move to the ASSEMBLY LAYER. The ASSEMBLY LAYER provides access to a variety of information pertaining to electronic assemblies. In addition, the ASSEMBLY LAYER provides access to die COMPONENT LAYER which provides access to assembly component information. A user may move between these layers several times during an information access session and this is recorded in die history pane 1106 in die TOP LAYER. A user may go to a specific layer and frame by selecting it in die history pane, or by selecting the frame (and thus layer) directly, using any of die means provided by the TI EXPLORER ϋ window manager. 5.4 The EP-LINK Architecture EP-LINK is a hybrid information management tool built by using the Hylink method in cooperation with other infoimation processing methods. The EP-LINK architecture is described with respect to die layers presented earlier. Functional block diagrams shown in figures 28-30 show the support provided for the TOP LAYER. ASSEMBLY LAYER, and COMPONENT LAYER, respectively. EP-LINK benefited from a parallel development effort. Some of the tool was built with die Hylink method while other parts were built widiout it The Hylink mediod allowed tiiose pans to be integrated easily. In figures 28-30 the broken line boxes are those developed using Hylink while the solid line boxes indicate functions that were developed using conventional software development techniques. Note: die functions designated by the solid line boxes were developed widiout Hylink because they were developed prior to the time that Hylink was available. This demonstrates die ease with which die Hylink method can be integrated with conventional techniques. It should also be noted that the functions developed by conventional techniques can easily be replaced by functions developed by the Hylink method. Referring to figure 28, the top pane handling 1200 consists of functions for displaying text icons 1202, tracking a mouse input device 1204, highlighting icons pointed to by die mouse 1204, and processing mouse selections of display icons 1206 (called mode selection handling). The primary pane handling 1208 consists of functions for formatting and displaying text icons 1210, han¬ dling user selections of those icons with a mouse 1212, and scrolling of the text in the window 1214. Because of the way icons are displayed, mouse tracking and highlighting are handled by the TI EXPLORER π system software. The typein pane handling 1216 consists of functions to parse character input 1218, echo typed character input 1220, look up the parse results in a command table 1222, execute any matching functions 1222, and output text to respond to any input strings 1224. The notes pane handling 1226 includes a notification function 1228 that notifies a user of new mail, a menu function 1230 that lets a user select a mail mode, and a note icon selection handler 1232. The mode menu supports a note creating mode 1234 that allows a user to author a note in the note pane. The newly created note is retained in a note buffer. In addition, there is a note send mode 1236 that allows a user to send a note to another user or to an assembly object The file mode 1238 lets a user explicitly save one of die notes (in the note buffer) into the user's note file area. The edit mode 1240 lets a user select a note from the note buffer to edit in die note pane. The find mode 1242 searches for a note stored in a note file area, placing it in the note buffer, and edit it in the note pane. The Irill-or-save mode 1244 gives a user a multiple choice menu allowing that user to kill or save the notes in the note buffer. The history pane handling 1246 consists of displaying a user action history 1248 that captures actions a user makes to move across layers. History icon selection handling 1250 changes the display to reflect die state (and layer) that represents die selected history icon. Referring to figure 29, die assembly layer function handling 1300 consists of functions for displaying function icons 1302, manipulating die associated assembly-graphic frame and graphic 1304, processing ECO information filters 1306, and processing annotation filters 1308. Graphic pane handling 1310 includes functions for displaying assembly graphics and assembly com¬ ponent graphical icons 1312, defining component object instances 1314, tracking a mouse input device 1316, highlighting icons pointed to by the mouse 1316, processing mouse selections of component icons 1318, and managing an assembly information text window 1320. Command handling 1322 includes functions for displaying command icons 1324, and handling mode set- ting 1326 as a result of command icon selection by a user witi a mouse input device. Referring to figure 30, the component layer object pane handling 1400 includes functions to format and display component object information as text icons 1402, handling user selections of those icons with a mouse 1404, and scrolling of the text in the window 1406. Because of die way icons are displayed, mouse tracking and highlighting are handled by the TI EXPLORER II system software. The command pane handling 1408 is similar to the command pane handling described above for die assembly layer and includes a command icon display handling function 1410 and a mode selection han¬ dling function 1412. The following sections describe d e SOIs and hyperstructures for those components built for EP-LINK using the Hylink method. 5.4.1 The Selection/Output Interpreters The data accessed by EP-LINK is related in one way or another to an electronic assembly or an ECO. The retrieved data is organized and represented in instances of electronic assembly and ECO class definitions. This makes dynamic concept linking a product of organizing retrieved data around object instances. The structure of these objects indicates (via defined hyperstructures) how they should be han¬ dled if selected from within a display. The limited number of class descriptions for these objects makes it easy for the SOIs to interpret them for display. With the exception of a speech output device, die displays that need SOIs in EP-LINK are windows of one type or another. The features of many of the windows are the same and this is reflected in the SOI descriptions. The differences in the SOIs are due to specific characteristics of die displays they represent and to the input devices that could be used to select icons from within those displays. The SOI class definition for EP-LINK is found in appendix 1. The SOI definition for the upper left win- dow (primary pane 530) in figure 5 is shown in Table 3, using the standard Flavor description for instan¬ tiating a class. The SOI definitions for that and other panes in figure 5 can be found in appendix 4. (make-instance 'SOI :OUTPUT-TYPE :accordion-type ;The display is a scrolling text ;window that allows text icons to ;be expanded (or contracted) by the ;selection of those icons with the ;mouse. :DISPLAY-OBJECT Object-scroll-window ;This is the Flavor class of which ;the display window is an instance. :OUTPUT-INSTANCE primary-pane ;The : OUTPUT-INSTANCE is the actual ;flavor instance for the display ; window. :SELECTION-DEVICES '(:mouse) ;The only input device recognized ;by this SOI for this display is ;a mouse. :CONTEXT-TABLES (list *primary-hyper-table*) ;This is the hyperstructure lookup table ;that this SOI starts with. :PARENT-SOI frame-soi)) ;This is the parent SOI. Table 3 • Selection/Output Interpreter Flavor Definition A principal contribution of die SOI is not shown in Table 3. It lies in the methods associated with the SOI class descriptions. For die SOI description in Table 3, ":accordion-type" and ":handle-mouse- selection" are names of methods defined specifically for the EP-LINK application and are specified in appendices 1 and 5, respectively. 5.4.2 The Hyperstructures EP-LINK has three hyperstructure-building functions tiiat build three different hyperstructure types. One handles command-like objects (e.g. pan, scroll, zoom, for the assembly layer). Another interprets assem¬ bly component selections, and die third is for general purpose object instance handling. The function that creates hyperstructure instances for handling object-instance interpretation is shown in Table 4. (defun build-general-hyper-structure 0 (make-instance 'hyper-structure :referred-to-instance nil :relevant-for (aeons 'functions ;If the selected object is a string, and there is a value for its ;:REFERRED-TO-INSTANCE, then make that the data to be displayed and ;set the display function to be :DISPLAY-INSTANCE. (list (cons #' (lambda (context hyper) (and (stringp (send context :selected-object)) (send hyper :referred-to-instance))) #'(lambda (context hyper) (send hyper :set-output-port (send context :output-port)) (send hyper :set-Iocate-action nil) (send hyper :set-data (send hyper :referred-to-instance)) (send hyper .set-display-action .display-instance))) ;If the selected object is associated with a function to make a ;remote call for data, make the call and expect that what is returned ;is an object instance which is made the referred-to-instance of the ;selected object On subsequent selections, the remote call is not ;made. (cons #'(Iambda (context hyper) (and (stringp (send context :selected-object)) (assoc (send context rselected-object) *remote-data-alist* :test #'string-equal))) #'(Iambda (context hyper) (let* ((obj-name (send context :selected-object)) (remote-fun (cdr (assoc obj-name *remote-data-alist* :test #'string-equal)))) (send hyper :set-referred-to-instance (funcaD remote-fun)) (send hyper :set-SOI (send context :SOI)) (send hyper :set-locate-action nU) (send hyper :set-data (send hyper .referred-to-instance)) (send hyper :set-display-actkm :display-instance)))) ) (aeons 'always-after ;If there area several ways to display the data, find the appropriate one (perhaps by asking the user). #'(lambda (context hyper) (let ((data (send hyper :data))) (cond ((and (instancep data) (> (length (send data tdev es)) 1)) (send hyper :set-output-port (find-correct-output-port data context hyper)))))) nϋ)))) Table 4 • Function to Create a Hyperstructure Instance This hyperstructure-defining function and die oύier two hyperstructure building functions in EP-LINK are specified in appendices 4 and 5. 5.5 EP-LINK Features and an Information Access Session. Several annotated displays of die running EP-LINK tool are found in figures 6 to 26. This section describes the specific functionality provided by die EP-LINK tool. The description is organized to coin¬ cide with die displays tiiat a typical user would see when using the tool for an infoimation management task. After logging into die EP-LINK tool by typing a user name at a login prompt 400 in die login display 410 (figure 6), the user is presented with the display 490 shown in figure 7 except that the contents of the primary window 530 would be empty. This so-called top layer frame contains windows from which the user can access infoimation. Each of these windows has an SOI instance associated witii it to inter¬ pret input to that window. The top-level window 500 gives die user three options 502, 504, and 510 for accessing information in EP-LINK. These options represent information access modes and affect die contents of the primary win- dow as well as change some EP-LINK state information. In addition, to exit the EP-LINK session a user selects die exit display icon 520, resetting state information and displaying die login prompt in the login display. Selection is done by pointing at a display icon with a pointing device (in this case a three but¬ ton mouse) and indicating a selection (in this case by pressing die left mouse button). In figure 7, d e user has selected die assemblies display icon 510. As a result of selecting the assemblies icon, several text icons 540, 580, and 590 are displayed in the pri¬ maiy window 530. These items indicate to the user that by selecting the assembly icon from the top- level window, die user will be able to access information about "Lines of Business", Tending ECOs", and "Manufacturing Engineers". The user may request further information by selecting one of these icons, or may go back to die top-level window and change the mode by selecting an icon other than assemblies. In figure 7, the user has positioned a pointing device, depicted by die arrow 600 ova: die tact icon "Lines of Business" 540. Note that when the pointing device is over die text icon, die text icon is highlighted witii an enclosing box. The other windows on die display in figure 7 are the notes window 560 which provides die interface to a mail facility. The history window 550 maintains a record of some of the user's operations. This is described below. The typein window 570 allows the user to enter typed instructions, queries, and data as input to EP-LINK. The primary window provides basic information access that is based upon elaboration of any selected display icons. When the user selects one of the icons in die window, EP-LINK assumes the user wants more detailed infoimation about it Any selection is interpreted by die primary window's SOI, and hyperstructures are responsible for retrieving die relevant data in the context of the primary window and die previous selection. This retrieval process may include retrieving information from remote databases, filtering any retrieved data for condensed, relevant infoimation, or simply looking for an object that represents the selected icon. The hyperstructures currently associated widi icons in die primary window tiy to display retrieved data back in die primary window if die data is textual. Icons in the primary window are said to be "expanded" when they are selected, elaboration data is retrieved or computed, and displayed directly under die selected icon, indented slighdy. Any text below the selected icon is shifted downward just enough to accommodate die text resulting from the expansion. Icons are "contracted" when selected in the expanded state and die previously expanded text is removed from the display. The primary window has scrolling capability for when more data is displayed than can fit within the display window itself. Figure 8 shows where die user has expanded die "Lines of Busi¬ ness" icon 540 shown in figure 7. The expansion of that icon is a list of members of the lines-of -business collection. After the expansion of die "Lines of Business" icon, the user expanded the "COPY (Copy 5 Products)" icon 610 and finally die "EPD (Electronic Photography Division)" icon 612. This process continues with the user contracting die "COPY (Copy Products)" icon, expanding die "Multi Disk Player Model SV-7500" icon 620 as shown in Figure 9, and is about to select die "Motor Speed Control" icon 622. Figure 10 shows that the user is given an option in die form of a menu 630 for displaying the expansion data for die "Motor Speed Control" icon. This occurs because the Motor Speed 10 Control is an electronic assembly and die user can be shown either a textual description of it or the board graphic. Figure 11 shows the textual expansion of die icon and shows a text formatting feature for the primary window. The description text 640 for the selected icon is automatically formated to ensure that it fits within the primary window. If a user selects the "Display Graphic" option from the display option menu 630 (figure 10), the user is 15 asked to select (with the pointing device) the upper left and lower right corner of a frame for displaying die assembly graphic. This moves the user to the assembly layer. At the assembly layer, there is a frame for each assembly graphic being viewed and die number is limited only by die memory available to die user by the Explorer system. Each frame is comprised of windows (or panes) as shown in figure 29. One such frame and assembly graphic is shown in figure 12. 20 When retrieving the board graphic, a parts list is retrieved for the assembly. The component objects are defined for each component of die assembly and die individual component graphic icons are made select¬ able. As a user points at one of the assembly component icons, it becomes highlighted and the user may select it to receive more component information. Figure 12 shows the pointing device icon pointing to a component 652 which is highlighted. 25 Each frame in die assembly layer has a command pane across the top that contains text icons 654, 656, 658, 660, 662, and 664. The user can select these to set the mode of information access with respect to the assembly object This is described below. Each frame also has a function pane along the left side. There are icons that allow the user to pan (666, 668), scroll (670, 672), and zoom (674, 676, 678) die graphic image. There is a reshape window icon 30 680 that is used to change the shape of the assembly layer frame. A filters icon 682 allows the user to add tilings called filters to the graphic display. One such filter is die text annotation filter described below. The last icon is the ECO-pending icon 684 and this tells a user that there is an ECO pending on the assembly being viewed. Figure 13 shows a user about to select the assembly number (690) from within the assembly graphic. 35 This causes a text window to be overlayed on the graphics window as is shown in figure 14. This win¬ dow is not shown in die frame diagram in Figure 27 but is a part of an assembly layer frame. The text window is similar in function to the primary window 530 in figure 7. The user may expand die assembly number 702 within this text window by selecting it Figure 15 shows the description 710 tiiat is displayed when this is done. If a user selects the parts list icon 712. the parts list is retrieved and figure 40 16 shows that only a portion of die parts list 720 is actually displayed. This demonstrates an ability of die EP-LINK tool to tailor die presentation of data to fit specific needs. Since an ECO is pending 722, a user is interested in finding how die assembly is affected by it The parts of interest are those that are to be added or deleted as a result of the pending ECO. These part icons are selectable and a user interested in the description of one of them may select them directly. Assembly components also have information pertaining to manufacturing, quality, test, purchas¬ ing, scheduling and sales but the information is different from that of assemblies. Special component viewing windows are created to display die component information. Figure 17 shows two of these win- dow collections 730, 732 which represent frames in die component layer at that time. In one window, die resistor with reference designator r34 has a description displayed 734. The component layer frames have different modes mat may be selected. Figure 18 shows tiiat die scheduling mode 740 was selected and die associated data is displayed below the component data When a user selects the supplies/demands icon 742, supply and demand data 744 are retrieved and displayed as shown in figure 19. Figure 20 shows the assembly text overiay window 746 after die manufacturing process information was retrieved and die test process information was retrieved. Fig 21 shows a menu 750 that is displayed when die ECO icon (684 in figure 12) is selected. The menu allows a user to view the new, deleted, and modified parts affected by die ECO. A user had previously selected the new part icon 752 and the new part icon 754 is displayed and temporarily highlighted. Figure 22 show a filter menu 760 that lets a user select an annotation filter for the assembly graphic. An annotation filter displays any annotations that are associated with the assembly graphic. A user may read (or hear), author, or edit any of die annotations. This is just one example of the way annotations may be used in this context Figure 22 shows a user about to turn audio annotations on. Audio annotations are shown in Figure 23 by means of icons depicting a hand holding a horn 770. These icons are highlighted 772 whenever they are pointed at by a user (via a pointing device). The annotations in EP-LINK are recorded digital audio signals that represent digitized speech. These are created by a speech input device and "displayed" by a speech output device. Text annotations are easier to visualize and examples are shown in figure 24. The text annotations are represented by icons shaped like a pen 780. A user may create a text annotation whenever the text anno¬ tation mode is on and a selection is made in a location in the graphic window that is not already occu¬ pied by a text annotation icon. During text annotation mode, the assembly components themselves are not selectable. When creating a text annotation, an empty text scroll annotation window 784 is displayed. A user types text into this window and strikes the <END> key on the computer keyboard. The annotation is stored and an icon is created for it. Rgure 24 shows a text icon 782 being selected and the text anno¬ tation being displayed in the annotation window 784. Going back to the top layer, Figure 25 shows a typed mail message 790, an address menu 792, a typed query input 794, and an example of history data 796. Figure 26 shows mail notification 800 and a note buffer list 802. Finally, figure 26 also shows a good example of dynamic link creation. When a user selects the manufacturing engineers icon, a text file of manufacturing data is retrieved from a remote computer sys¬ tem. The EP-LINK tool searches the file for text strings that refer to objects that are known in the current state of running EP-LINK In other words, it looks for strings that match objects that have been created as a result of previous information access. In this case, the strings representing the names of the lines of business are recognized and these are made selectable. Note that in this figure, Electronic Pho¬ tography 810 has been selected (expanded) and a user can access the same infoimation as was accessed in figure 9. Refeπing to figure 1, EP-LINK can be implemented on the same platform employed to perform the Hylink method, hi this embodiment it is a useful tool for managing and retrieving infoimation stored on disk 16. Its usefulness is extended to managing and retrieving information stored in a plurality of diverse computer systems by providing a data translation module 1000 (shown by broken lines in figure 1) and a communications interface 1002 to a plurality of applications 1004, 1006, and 1008. The data translation module 1000 translates the data format of data retrieved from the plurality of diverse computer hardware and software systems into the object data format employed by die informa¬ tion management tool. This may be done by creating a separate data translator for each computer system that has a data format different from the one employed by die information management tool The communications module 1002 enables and manages (the electronic) movement of data and instruc¬ tions between the information management tool and die plurality of diverse computer hardware and software systems. A communication facility is necessary for the information management tool to access information and run applications on other computer systems. One way to provide this communication is to use a local area netwoik (LAN) specification such as ETHERNET (Ethernet is a trademark of Xerox Corporation) and die Transission Contrd Protocol/Internet Protocol (TCP/IP). The TCP/IP provides an interface for file transfer between computer systems supporting TCP/IP. In addition to ETHERNET and TCP/IP, the communication module may contain programs to formulate and interpret instructions sent between the different computer systems. Application 1 (1004) could be a Digital Equipment Corporation VAX computer running the VMS operat- ing system and executing an inventory management system (VAX and VMS are trademarks of Digital Equipment Corporation). Application 2 (1006) could be an HP engineering workstation running a CAD circuit design and configuration control system. Application 3 (1008) could be a SUN workstation run¬ ning the UNIX operating system (UNIX is a trademark of AT&T) and executing a production resource management tool. ADVANTAGES The Hylink method facilitates building hypermedia information management tools by supporting a sim¬ ple user-comouter interaction scenario that guides a system designer and builder. This encourages com¬ mon user interface designs as well as enables greater interface software reuse. The Hylink method builds shell tools around existing application and database tools. This introduces time and cost savings and can be viewed as a forni of reuse. The Hylink method facilitates adding hypermedia features to infoimation mangement tools without con¬ straining die designer and builder by requiring diem to use existing hypermedia features and techniques. The Hylink mediod provides a means for alleviating several problems that exist in current hypermedia systems. The Hylink method makes it possible for tools to exhibit the ability to be reconfigurable, sup- port a variety of ways for navigating through large unfamiliar heterogeneously structured networks, to support the creation and management of information node composites, and provide for tool extensibility and tailorability. One way to navigate through large unfamiliar heterogeneously structured networks is through the use of content-based user queries. Hyperstructures easily accommodate this approach and SOIs can handle query-style inpu The Hylink mediod directly supports tailorability and extensibility. Both die hyperstructures and die SOIs are intended to make botii of these easier as their very nature is modular and additive. The Hylink method supports integration of IR and IP application features in a way that is transparent to a user. Hylink allows a designer to easily integrate and test new I O devices for use in a Hylink-built information management tool without requiring extensive redesign and reimplementation efforts. In addition, die Hylink method makes it easy for a tool designer and builder to incorporate specialized functionality and existing application programs. This can be done with little tool redesign and reimple¬ mentation. Finally, die method accommodates new and/or different sources of data and/or databases in the same fashion as the specialized functionality as described above.

Claims: I Claim 1. A method of building a hypermedia information management tool for retrieving, processing, and displaying information, comprising the steps of: in an object-oriented programming environment a. creating an instance of a Selection Output Interpreter (SOI) for a display type, the SOI being an object having a data structure including, (1) a hyperstiucture lookup table associating a display icon with a hyperstiucture, and pro¬ cedures including, (a) a procedure to associate a display icon with a hyperstructure in a hyperstructure lookup table, (b) a procedure to display a specific data type according to a specific output format by calling a function tiiat builds a hyperstiucture instance and associating the hyperstructure instance with a display icon in the hyperstructure lookup table, (c) a procedure for defining a selection-context and calling a hyperstructure associ¬ ated with a display icon, and (d) a procedure for handling a user selection input according to a specific input for¬ mat for a display device type by calling a function that defines the input format for that type, where a hyperstiucture is an object having a data structure including, i. a context-indicator table for holding instructions for processing an icon and associated context information, ii. a table for holding data to be displayed, and iii. a pointer to an SOI, and procedures including, i. a procedure for processing the context-indicator table, ii. a procedure for locating data to be displayed, and iii. a procedure for calling an SOI to display the data; b. creating a function to build a hyperstructure instance; c. creating a function to define die output format for a display device type; d. creating a function to define the input format for a display device type; and e. initializing a display instance. 2. The method claimed in claim 1, wherein the object-oriented programming environment includes: Common lisp and die Massachusetts Institute of Technology (MTT) flavor system. 3. The method claimed in claim 1, wherein the SOI data structure further includes: a list of valid input device types. 4. The method claimed in claim 1, wherein the SOI data stiucture further includes: a description of its output device type. 5. The method claimed in claim 1, wherein the SOI data structure further includes: a pointer to a parent SOI. 6. The method claimed in claim 1, wherein the SOI procedures further include: a procedure for locat¬ ing a hyperstructure previously associated with an icon in a hyperstiucture table. 7. The method claimed in claim 6, wherein the hyperstiucture table is from an enclosing SOI or any SOI in die transitive closure of PARENT-SOIs of the enclosing SOI. 8. The method claimed in claim I, wherein the procedure for displaying a specific data type specify¬ ing which data is to be made eligible for selection by a user. 9. The method claimed in claim 1, wherein the procedure for displaying a specific data type further includes a procedure for matching the output device type of the SOI to the eligible output device types of the data type to be displayed. 10. The mediod claimed in claim 1, wherein the procedure for displaying a specific data type includes a procedure for calling a procedure created for the specific data type and the associated display device type. 11. The method claimed in claim 10, wherein the data needed by the display device type is extracted from the selection-context instance and from the data type to be displayed. 12. The method claimed in claim 1, wherein a selection-context is an object having a data stiucture including, a. a table for holding input device-specific data resulting from a user input, b. a pointer to user-selected display-icon, c. a table for holding data defining a context of a user input, d. a pointer to an SOI, e. a pointer to an input device type, and f. a table for holding data specific to an input device type. 13. The method claimed in claim 1, wherein the hyperstructure data stiucture further includes: a table for holding pointers to functions for locating data to be displayed. 14. The method claimed in claim 1, wherein the hyperstructure data structure further includes: a table for holding pointers to functions for displaying specific types of data. 15. The method claimed in claim 1, wherein the context-indicators in the context-indicator table include: ALWAYS-BEFORE, ALWAYS-AFTER, CONDITIONAL, and DEFAULT. 16. The method claimed in claim 15, wherein the context-indicators in the context-indicator table further include: EXACT-CONTEXT, and CONTEXT-DEPENDS-ON-CLASS. 17. The method claimed in claim 1, wherein die step of initializing a display instance, comprises: cal¬ ling a hyperstiucture with initializing data. 18. The mediod claimed in claim 1, wherein the step of initializing a display instance, comprises: cal¬ ling an SOI with initializing data. 19. The method claimed in claim 1, wherein the step of initializing a display instance, comprises: downloading an SOI with a predefined hyperstructure lookup table and calling a function to display a display icon. 20. The method claimed in claim 17, wherein the initializing data comprises a selection context and a selected icon. 21. A tool for building a hypermedia infoimation management tool for retrieving, processing, and displaying information, comprising: a. an object-oriented programming platform including a CPU, an object-oriented programming run-time environment, and a user interface including an input device and a display; b. Selection Output Interpreter (SOI) means for controlling the display, die SOI means being an object having a data structure including, (1) a hyperstructure lookup table associating a display icon with a hyperstructure, and pro¬ cedures including, (a) a procedure to associate a display icon with a hyperstructure in the hyperstiuc¬ ture lookup table, (b) a procedure to display a specific data type according to a specific output format by calling a function that builds a hyperstructure instance and associating the hyperstiucture instance with a display icon in the hyperstiucture lookup table, (c) a procedure for defining a selection-context and calling a hyperstructure associ¬ ated with a display icon, and (d) a procedure for handling a user selection input according to a specific input for¬ mat for a display device type by calling a function that defines the input format for that type, where a hyperstructure is an object having a data structure including, i. a context-indicator table for holding instructions for processing an icon and associated context information, ii. a table for holding data to be displayed, and iii. a pointer to an SOI, and procedures including, i. a procedure for processing the context-indicator table, ii. a procedure for locating data to be displayed, and iii. a procedure for calling an SOI to display the data; c. means for building a hyperstructure instance; d. means for defining die output and input format for the display; and e. means for initializing a display instance. 22. The tool claimed in claim 21, wherein said programming platform includes a Texas Instruments (TI) Explorer II Lisp Machine. 23. The tool claimed in claim 21 and 22, wherein said platform further includes the programming languages Common lisp, and TI Lisp extensions, as well as the MTT flavor object-oriented pro¬ gramming system. 24 The tool claimed in claim 21, wherein said procedure for locating data provides for retrieving data from remote information systems. 25. The tool claimed in claim 24, wherein said procedure for locating data further provides for calling other application programs and including die data resulting from those calls into the information system. 26. A hypeimedia infoimation management tool built by the method of claim 1. 27. The hypeimedia infoimation management tool claimed in claim 26, providing a user interface to a plurality of diverse computer systems and further including a data translation module and a com¬ munications module. 28. The hypermedia infoimation management tool claimed in claim 27, wherein the computer systems support applications in a manufacturing environment including CAD, inventory control, and pro¬ duction resource management. 29. A hypermedia information management tool for retrieving, processing, and displaying infoimation, comprising: a. an object-oriented programming platform including a CPU, an object-oriented programming run-time environment, and a user interface including an input device and a display; b. A plurality of Selection Output Interpreter (SOI) means for controlling die display, each SOI means being an object having a data stiucture including, (1) a hyperstructure lookup table associating a display icon with a hyperstructure, and pro¬ cedures including, (a) a procedure to associate a display icon witii a hyperstiucture in the hyperstruc¬ ture lookup table, (b) a procedure to display a specific data type according to a specific output format by calling a function tiiat builds a hyperstructure instance and associating die hyperstructure instance with a display icon in the hyperstructure lookup table, (c) a procedure for defining a selection-context and calling a hyperstiucture associ¬ ated with a display icon, and (d) a procedure for handling a user selection input according to a specific input for¬ mat for a display device type by calling a function that defines die input format for that type; and c. a plurality of hyperstructure means for controlling data retrieval and interpretation of user selections, where a hyperstructure is an object having a data structure including, (1) a context-indicator table for holding instructions for processing an icon and associated context information, (2) a table for holding data to be displayed, and (3) a pointer to an SOI, and procedures including, (a) a procedure for processing die context-indicator table, (b) a procedure for locating data to be displayed, and (c) a procedure for calling an SOI to display die data. 30. The infoimation management tool claimed in claim 29, for providing a user interface for a plural¬ ity of diverse computer systems, further comprising: a. data translation means for translating data formats from the data format employed by said computer systems to the object data format employed by die information management tool; and b. communications interface means for managing communication of data and instructions between the management tool and the computer systems. 31. The infoimation management tool claimed in claim 30, wherein said computer systems support applications in a manufacturing environment including CAD, inventory control, and production resource management

Inventors: HAEFNER MICHAEL E, HAEFNER, MICHAEL, E.
Applicants: EASTMAN KODAK CO, EASTMAN KODAK COMPANY
Application year: 1990
Main classification: G06F15
IPC codes: G06F9, G06F17