KMap was written as a module in a C++ class library that provides a wide range of data structures, communication protocols, scripting, graphic user interfaces, document processing, hypermedia, knowledge representation and inference (Gaines, 1994a). This makes it possible to support a wide range of applications of concept maps, including embedding in documents, information retrieval, and collaborative access over local area and wide area networks.
The KMap implementation has three layers corresponding to those discussed in the previous section. From the abstract perspective, a hypergraph representation data class has been implemented which supports typed nodes, and this is sub-classed to support typed links between nodes. From the visualization perspective, the node and link types have associated visual representation classes that record the parameters determining the appearance of the types and the methods for drawing them. From the discourse perspective, translators are supplied for some communities that recode the abstract data into an alternative form of knowledge representation, and, in general the graph structure can be exported to other tools that have such translation facilities.
This linking of appearance to node type allows the abstract sorted graph structure to be presented clearly to the user through the interface. The availability of a rich variety of visual presentation facilities is what enables KMap to be set up to emulate a wide range of existing forms of concept map. For example, in Figure 1 there are 3 types of node indicated by the presence and shape of the frame, and the type name itself is not displayed. In Figure 2 there are 6 types of nodes, all with the same shape but differentiated by the type name as a heading. In Figure 5 the form of the 3 node types was chosen to correspond to bond graph conventions; in Figure 6 the 3 node types correspond to conceptual graph conventions; and so on. Note that what may appear to be link labels are treated as nodes in KMap. This allows more concise and meaningful maps to be drawn since the "link label" node can have multiple incoming and outgoing arrows.
The content of a node is split into a visible component and an invisible component. The user tends to think of the visible component as the node name or content. The invisible component is used for computational purposes such as hypermedia links and information retrieval. Interactivity, such as the availability of popup menus, is determined by the node type, but the content of such interaction, such as the items in popup menus, is determined by the invisible component of the node content. Because the type and content of a node may be edited by the user, for example as part of a process of knowledge refinement, a unique identifier is associated with each node that may be used to preserve links between it and other data structures.
In most applications the node types are set up in advance, and the end user of a concept map has available a preset system of node types. However, the node type editor is available and the types and their appearance can be edited during ongoing development of a concept map if required. Figure 10 shows a concept map in a multimedia information retrieval system with the user selecting the type "Movie" on a popup menu prior to adding a new node. The visible content is entered by typing it into the text editing box under this menu. The invisible content is entered by double clicking on the node to edit it while holding down the "option" key on the Macintosh. KMap normally automatically word wraps the visible content to form a horizontal rectangle but this can be overridden by the user inserting the paragraph marker symbol, [[paragraph]], to indicate line breaks.
Figure 10 Concept map accessing multimedia materials
At the bottom of the popup menu the option "Edit..." is offered, and selecting this causes a node type editing window to open as shown in Figure 11. Near the top of its window, the editor provides a palette of shapes which can be associated with types, and in the bottom of the window all the types so far defined are shown. The shape and colors of existing types may be redefined and, when the "Apply" button is clicked, the new appearance will show up in the concept map in the window below.
Figure 11 Entering concept map types to define a visual language
The user interface through which the types of nodes may be selected is itself customizable. In Figure 10 types are accessed through the two popup menus at the top left. Two menus are provided because node types often divide naturally into two types, for example a "node type" and a "link type" with the constraint that nodes whose type is in one class may be connected by arcs only to nodes whose type in the other. The concept maps in Figures 1, 3 and 6 have such a bipartite structure.
However, the menus are only defined in a Macintosh operating system "resource" whose number is stored with the concept map, and a wide variety of other user interfaces may be defined through alternative resources. For example, the "buttons" at the top of Figure 7 are an alternative to a popup menu. If the KMap software receives a message that a button has been clicked it checks whether the label of the button is a defined type name and if so, treats a button click in the same way as a popup menu selection. In addition, by setting a switch stored with a concept map the entire editing pane shown at the top of most of the concept map examples may be defined to be a floating palette that does not appear until a node is double clicked. This is an important capability when a concept map is embedded in a document as shown in Figure 6, and should have the appearance of a simple diagram when viewed or printed, but also act as an active interface if required. The appearance of the concept map editing pane as a floating dialog is shown near the bottom of Figure 6.
KMap is itself programmable through the Apple high-level object event protocol (Apple, 1993a), and can be driven by any of the scripting languages in Apple's open scripting architecture such as AppleScript (Goodman, 1993), Frontier (Winer, 1992) and TCL (Ousterhout, 1994). Each concept map can have its own script which receives messages triggered by user interaction with the concept map. This enables KMap to be integrated with other applications, and user interaction with graphical structures in the visual language to be used to control any activity supported on the host computer or network. The development of a specific system involves writing scripts to provide the required functionality by drawing upon existing applications. Figure 12 shows part of the script associated with a server agent in the Mediator (Gaines and Norrie, 1994) collaborative system opened for editing.
Figure 12 Script editor with part of script for major KMap events
The message handler routines shown are those activated by a mouse click in the concept map, by a button click in the associated dialog, by a mouse click that activates a popup menu, by a popup menu selection, and by any form of change in the concept map. Each message passes a record with associated parameters, such as the document name, whether the click was single or double, what node, if any, the click was in, and so on. The "Get Menu" handler that is activated by a mouse click when the cursor is a popup menu symbol returns the menu items that should be displayed so that the actual menu can be constructed dynamically based on the content of the node. The "Do Changed" handler in this example sends information about the changes in a concept map to update the same map open in KMap running on another machine, thus supporting collaborative editing of concept maps. Messages are sent to the script when a concept map is initially opened and when it is closed, supporting start up and completion actions. Messages sent from external applications may be routed to scripts in concept maps, supporting cross-application, cross-platform and cross-network integration.
It is often inappropriate to have a separate script for every concept map. The functionality required is usually common to a family of maps, and hence KMap supports shared scripts in which the script in one concept map acts as an "agent" serving a set of linked maps. Scripts may link together specific maps, or a script may set a flag defining itself as a default agent receiving messages from all maps that do not have relevant handlers in their own scripts or linked scripts.
gaines@cpsc.ucalgary.ca 22-Nov-95