CHAPTER 4 Implementing a Java Concept Mapping Tool

4.1 Previous Work
4.2 System Requirements

4.2.1 Development Framework
4.2.2 Supporting Multi-User Environments

4.3 jKSImapper

4.3.1 The Windows Manager
4.3.2 The Concept Map Window

4.4 jKSImapplet

4.4.1 jKSImapplet Navigator

4.5 Chapter Summary

CHAPTER 4
Implementing a Java Concept Mapping Tool

The purpose of the systems implemented as test cases for this research is to provide support for distributed interaction of concept maps on the Internet and the Web. To achieve this goal, two primary steps were required: first, to develop a class structure to support the manipulation of concept maps; and second, to extend such a system to allow multi-user elicitation of concept maps on the World Wide Web.

The work required to accomplish these steps was not done under isolated circumstances, but as part of a previously established effort to promote the use of concept maps in several areas of expertise. In particular, the test case systems implemented were highly influenced by previous developments at the Knowledge Science Institute of the University of Calgary. These developments, and their path of influence, are briefly described on the following section.

4.1 PREVIOUS WORK.

Figure 8. Concept Mapping Development at the Knowledge Science Institute.

• KDraw (Gaines, 1993) is a visual language version of the CLASSIC (Borgida, Brachman, McGuiness and Resnick, 1989) knowledge representation language. Developed for the Apple Macintosh, this system implements formal concept maps for single user environments. This system allows undo and redo.

  Characteristics:	Platforms:
  Formal Executable Undo/redo	Macintosh

• A direct descendant of KDraw, KMap (Gaines and Shaw, 1995b) is a generic visual language tool that can emulate specific languages, including KDraw. All operations on the concept maps are sent as events to AppleScript (Goodman, 1993), enabling KMap to be programmed for different applications.

  Characteristics:	Platforms:
  Formal and informal (language definable) Executable (in KDraw emulation) Undo/redo Hypermedia Scriptable (AppleScript)	Macintosh

• Mediator is a generic knowledge management system. Mediator 0 is a system derived from KMap, which has been extended to implement scripts for enabling two users to access concept maps in a synchronous, "What-You-See-Is-What-I-See" (WYSIWIS) manner.

  Characteristics:	Platforms:
  Multi-user interface (weak WYSIWIS) Undo/redo Hypermedia Scriptable (AppleScript)	Macintosh

• Mediator 1 is implemented using a concept mapping tool known as XConMap (Lapsley, 1995). XConMap is essentially a re-implementation of KMap under the Unix XWindows operating system. It was designed to provide an Internet implementation of Mediator by working in conjunction with Netscape Navigator.

  Characteristics:	Platforms:
  Hypermedia	XWindows

• KWrite is a fully capable word processor implementation. This system allows to embed multimedia information and concept maps produced by KMap and KDraw.

  Characteristics:	Platforms:
  Formal Executable Undo/redo Hypermedia Scriptable (AppleScript)	Macintosh

• Accord (Kremer, 1993) is a concept mapping tool based on KMap. This system is implemented on the Microsoft Windows operating system. In addition to the features found on KMap, Accord also implements the notion of persistent hyperbases.

  Characteristics:	Platforms:
  Hypermedia Persistent hyperbase	Windows-16

• Smart Ideas (Smart Ideas, 1996) is a concept mapping tool that was developed based on the Accord implementation. This system is available as a commercial product.

  Characteristics:	Platforms:
  Commercial system (as opposed to research) Hypermedia Persistent hyperbase	Windows-32

• NPSmart Ideas is the Netscape plug-in version of Smart Ideas. It allows browsers to access concept maps stored as read-only resources on the Internet.

  Characteristics:	Platforms:
  Commercial system (as opposed to research) Web browser-embeddable Hypermedia Persistent hyperbase	Windows-32

• KSIMapper is the demonstration program for the CMap class library, which was developed using the C++ programming language. This application allows manipulation of informal concept maps on single-user environments.

  Characteristics:	Platforms:
  Undo/redo	Windows-32

• NPKSIMapper is the Netscape plug-in version of KSIMapper. It implements functions to allow interaction with Netscape Navigator embeddable widgets through JavaScript.

  Characteristics:	Platforms:
  Web browser-embeddable Multi-user interface (weak WYSIWIS) Undo/redo Hypermedia Scriptable (JavaScript)	Windows-32

• Constraint Graphs (Kremer, 1996) is a system based on the KSIMapper implementation. This system has been extended to emulate formal visual languages.

  Characteristics:	Platforms:
  Formal Can be constrained to multiple formal visual languages Undo/redo	Windows-32

• NPConstraint Graphs is the Netscape Navigator plug-in version of Constraint Graphs.

  Characteristics:	Platforms:
  Web browser-embeddable Formal Can be constrained to multiple formal visual languages Multi-user interface (weak WYSIWIS) Undo/redo Hypermedia Scriptable (JavaScript)	Windows-32

• jKSImapper is the Java implementation of KSIMapper. This system is based on the Java jCMap class library, which was derived from the C++ CMap class library. jKSImapper allows manipulation of concept maps on single and multi-user environments.

  Characteristics:	Platforms:
  Multi-user interface (weak WYSIWIS) Undo/redo	All platforms where a Java interpreter is implemented.

• jKSImapplet is the Web-browser-embeddable and downloadable version of jKSImapper.

  Characteristics:	Platforms:
  Web browser-embeddable Multi-user interface (weak WYSIWIS) Undo/redo Hypermedia Scriptable (JavaScript)	All platforms where a Java interpreter is implemented.

• jKSImapplet Navigator is a Java applet based on jKSImapplet that implements an interactive interface for World Wide Web navigation. This browser-embeddable applet allows URL addresses to be associated with nodes for accessing hyperlinked HTML documents and concept maps. This system also supports multi-user environments.

  Characteristics:	Platforms:
  Web browser-embeddable Multi-user interface (weak WYSIWIS) Undo/redo Hypermedia Scriptable (JavaScript)	All platforms where a Java interpreter is implemented.

• CMap is a C++ class library on which the KSIMapper and Constraint Graphs applications are based.
• jCMap is a Java class library on which the jKSImapper and jKSImapplet applications are based.

4.2 SYSTEM REQUIREMENTS.

4.2.1 DEVELOPMENT FRAMEWORK.

Unfortunately, the term "concept map" eludes a concise description and definition. In Chapter 1, concept maps were defined as diagrams composed of links and nodes of different types. However, this description is too broad and ambiguous to be useful.

Instead, a definition for concept maps can be found by examining their use under the light of three levels of analysis (Gaines and Shaw, 1995b):

• The abstract perspective: From an abstract perspective, the basic concept map data structure consists of typed nodes, some of which are linked. Each node has a type, a unique identifier and a content (which may itself be structured, for example, as label plus other data). A node may enclose other nodes, allowing the construction of hypergraph structures in which a single link may connect sets of nodes. Links are visually represented by lines between nodes. These lines may or may not contain arrow heads to represent logical flow.
  

• The visualization perspective: From a visualization perspective, concept maps may be seen as diagrams, using the term to mean a drawing with reasonably well understood meaning in certain domains. To provide a consistent relation between the visual features and their internal infrastructure, the visual attributes of nodes and links need to be in one-to-one unique correspondence with their types. The node type may determine, and itself be determined by, the node shape, frame color, fill color, whether the type name is displayed and, if so, in what type face, style, size and color, and whether part of the content is displayed and, if so, in what type face, style, size and color. If links are typed, their types may determine, and be determined by, labeling, line thickness, color, cross-hatching, or other forms of decoration.
  

• The discourse perspective: From a discourse perspective, concept maps may be seen as an instrument to represent and communicate knowledge through visual languages. In this case, an abstract structure represented as a diagram in visual terms can be used as a knowledge representation and communication instrument when interpreted by some community. This circumstance creates an exact parallel between natural languages and visual languages, where the abstract grammatical structures and their expressions in a medium take on meaning only through the practices of a community of discourse.
  

• The abstract perspective is supported by defining node and link classes, and by defining classes that allow their manipulation inside logical data structures. A context box class, which is a variation of the node class, allows the arrangement of nodes inside its boundaries for grouping purposes. The node, context box and link classes implement content in the form of text labels. The link class has attributes to store the number of lines segments composing each link instance, as well as information on the attachment, if any, maintained by each one of those line segments. Hypermedia behavior is supported by using networking classes that allow interaction with remote processes and access to Internet resources.
  

• The visualization perspective is supported by classes that display visual attributes related to the underlying classes from the abstract layer. Visualization classes allow the displaying of shape and text attributes for nodes; and line segments, arrow heads and a text label for links. These attributes can be customized using a color palette and, in the case of text labels, different font types, styles and sizes.
  

• The discourse perspective is supported on its most basic form, meaning that knowledge structures can be freely constructed, but without any automated process enforcing specific formalisms. This characteristic can represent an advantage for authors willing to extend the system to support their formal representation of choice. As it will be mentioned further on Chapter 6, implementation of formalisms is part of future work proposed for this system.
  

4.2.2 SUPPORTING MULTI-USER ENVIRONMENTS.

Currently, most software systems are designed to support interaction between user and computer. However, market exigencies urge for software that also supports interaction between users, since much of an individual's work is within the context of a group. Organizations are not made up of people working individually at their desks, but rather people cooperating and collaborating as groups or teams. In this context, Computer Supported Collaborative Work (CSCW) is an area that studies the use of computers to enhance and extend people's natural abilities to collaborate for achieving their goals (Kremer, 1993). As shown in Table 4 (Ellis, Gibbs and Reln, 1991), CSCW systems must provide support for individuals working alone or in sub-groups, and at the same or at different times.

• Face-to-face meetings: Face-to-face meetings are the same as traditional meetings involving whiteboards. Their difference, however, resides in the application of computational tools to achieve goals. In a common scenario, meeting members use computer terminals to manipulate shared information, while facilitators can use large electronic boards to guide and synchronize members' efforts.
  

• Synchronous remote interaction: Synchronous remote interaction is similar to face-to-face meetings in the sense that members work at the same time, as they do in meetings, but using terminals from different locations. This interaction mode has the disadvantage of restricting the use of gestures and basic human interaction, which are common components of traditional meetings.
  

• Asynchronous interaction and asynchronous remote interaction: Under these interaction modes, systems are used by one member at a time (single user environment), regardless of whether the system is executed locally (asynchronous interaction) or from a remote computer (asynchronous remote interaction).
  

4.3 JKSIMAPPER.

jKSImapper is a standalone Java application that allows the generation and manipulation of concept maps. This system uses a graphical user interface based on windows, dialogs and menus to handle user requests. A pointing device is also required to modify specific attributes of objects, such as position, size and link attachment.

Figure 9. jKSImapper components.

4.3.1 THE WINDOWS MANAGER.

One advantage of using this approach is that one single Java interpreter supports all the concept maps that a user might want to utilize at a given time. If each concept map window has been implemented to use its own instance of the interpreter, it would have resulted on more resources being consumed to maintain each one of those independent instances.

Figure 10. The Windows Manager.

• The "File" menu option: This pull-down menu contains most of the options of the Windows Manager. These options allow users to initiate concept maps from scratch, to load concept mapping files stored on local or remote computers, and to exit the application. Remote files can be downloaded from a jKSImapper Server, or from the Web using URLs.
  As will be explained further in Chapter 5, the opening of a local file indicates that events generated by the user will be handled locally, without the mediation of any other (locally or remote) process. The same policy applies to files downloaded using URLs. On the other hand, the opening of a server file implies that the user is joining or starting a remote session on the server. Each one of these sessions support one independent concept mapping elicitation.
  

• The "Windows" menu option: This menu option contains one single sub-option named "List...", which displays a list containing all active Concept Map Windows. By selecting items from this list, users are able to bring to top those existing windows. This option is of great value for locating specific concept map windows when the screen is cluttered with multiple windows from this or other applications.
  

• The "Help" menu option: Up to the present implementation, just an "About" option is supported by this menu. Selecting this option will display an information dialog containing the name of the application, its place and year of development, and a copyright notice.
  

4.3.2 THE CONCEPT MAP WINDOW.

Figure 11. A formal concept map describing the sentence "Tom believes that Mary wants to marry a sailor."

Concept Map Windows rely on a set of predefined operations to modify the composition of concept maps. As shown in Table 5, these operations are applied to one or several target elements and can be activated by using specific user interface components.

	Target Element
Operation	Node	Link	Context Box	Concept Map
Creation
Deletion	or	or	or
Selection
Move
Resize
Attach/Detach
Text Label	and	and	and
Font
Color
Shape
Line Segments
Arrow Heads
Undo/Redo
Save				and
User Interface Mediums: Menu Mouse Keyboard

Table 5. Operations performed in Concept Map Windows.

• Creation of elements: This operation provides the initialization of three different concept mapping objects, which are described below:
  • Node: As shown on Figure 12, nodes can be instantiated as rectangle, ellipse, or rounded rectangle shapes. The default attributes for a node are: empty text label, white fill color, black color for border and text, and plain style 12-point Courier font. Text labels are displayed at the center of the node. New nodes can be instantiated by using the "Node | New | <shape>" menu option (where <shape> represents one of the shapes available).
    
    
    

    Figure 12. Available Shapes for Nodes.
    

  • Link: As shown on Figure 13, links can be created as a two (binary), three (trinary), or four (quadrary) line-segmented arcs. The default attributes for a link are: empty text label, no arrow heads, black color for lines, arrow heads and text, and plain style 12-point Courier font. Text labels on links are positioned at the center of the joining point of the line segments. New links can be instantiated by using the "Link | New | <line-segments>" menu option (where <line-segments> represents one of the available link configurations).
    
    
    

    Figure 13. Available Links.
    

  • Context Box: Context boxes can be considered a specialized type of node. Context boxes share all the attributes existent for nodes except for the shape and the position of the text label. As shown on Figure 14, context boxes are just delivered in a single shape: as a rectangular frame containing an empty rectangular space. Context boxes have the peculiarity that the inside rectangle has a small offset downwards in comparison with the geometrical center of the external rectangle. This offset creates a header at the upper edge, which is used for displaying a text label. Context boxes are instantiated by using the "ContextBox | New" menu option. The default attributes for a Context box are: empty text label, white fill color, black color for border and text, and plain style 12-point Courier font.
    
    
    

    Figure 14. Example of a Context Box.
    

  In general, newly created objects are displayed on the upper left corner of the painting area.
  

• Deletion of elements: This operation is applied to selected objects. Once this pre-condition is fulfilled, selected elements are removed by choosing the "Edit | Delete" option from the menu, or by pressing the <delete> key from the keyboard.
  

• Selection of elements: Selection of elements is achieved using any of two methods: (a) by mouse-clicking on the element (the body in nodes, lines in links, and in the frame of context boxes); or (b) by enclosing the targeted element(s) with the selection rubber band.
  

  Figure 15 shows three selected elements: the rectangular node "BELIEF," the circular node "PTNT," and the link joining them. As it is depicted, the visual representation of a selection state is marked by small solid squares at the edges of the rectangular area occupied by the element, in the case of a node or context box, or by small squares located at the extremities of line segments, in the case of a link. Figure 15 also shows a dotted rectangle surrounding the node labeled "PERSON: Tom." This dotted rectangle is called the selection rubber band, and it is used to select one or more elements of a concept map. The selection rubber band is invoked by clicking on an empty point of the drawing area, and dragging the mouse to a position that will enclose the element(s) to select. To add elements to an existing selection, users may click on new elements while holding the <control> key. This technique is also used to deselect one of the elements of a group of selected objects.
  

  
  

  Figure 15. jKSImapper selection example.
  

• Movement of elements: Movement is accomplished by mouse-clicking inside the boundaries of an element and then dragging the mouse without releasing the button.
  

  Links are moved by clicking on one of their line segments. The movement of links with line segments attached to nodes, as well as the movement of nodes with line segments attached to them, will result on the resizing of those line segments. Additionally, the dimensions of a line segment will be determined by the joining point of a link and the closest point of attachment to a node. In the case of context boxes, their movement will result on the movement of all the elements enclosed by their frame.
  

  It is worth mentioning that the movement of a selected object will result in the movement of all selected objects by the same offset.
  

• Resizing of elements: Nodes and context boxes can be resized by clicking and dragging one of their selection squares (thus, selection mode is a pre-requisite). Links cannot be resized, but (as previously explained under "Movement of elements") their line segments can be resized if the joining point of a link is moved while the line segments are attached to a node or context box.
  

• Attachment/detachment of line segments: Selection squares on the edges of link line segments on a link can be clicked and dragged over the body of a node (or over the frame of a context box) for attachment. Attached line segments can be detached by dragging the line segment's selection square to an empty point on the drawing area. In case of detachment, line segments will return to a default stationary position.
  

• Editing of text labels: Nodes, context boxes and links support text labels. A text label is assigned to selected objects by using the "Edit | Set Label | Edit..." menu option. This option displays a dialog box requesting a string of characters to be used as a label. If just one object is selected when invoking this option, the object's current label is displayed for edition. No text will be displayed if multiple objects are found to be selected.
  

• Selecting font properties for text labels: Text labels can support three different font attributes, which are described as follows:
  • Type: Text labels can use Courier, Helvetica, and TimesRoman font types.
  • Style: Text labels can use plain, italic, bold and bold-italic font styles.
  • Size: A set of predefined sizes has been chosen for the present implementation. These sizes range from 8 to 40 points.
    

  Font attributes can be modified by using different selections available under the "Edit | Set Label | Font" menu option.
  

• Selecting objects' colors: jKSImapper allows to color different visual attributes on selected objects. Colors supported are, in alphabetical order, black, blue, cyan, dark gray, gray, green, light gray, magenta, orange, pink, red, white and yellow. These colors can be applied to the following attributes on objects:
  • Nodes and Context boxes: Color is supported on the body, border and text label of nodes and context boxes. Color is modified by using the sub-menus available on the "Node | Set Color" and "ContextBox | Set Color" menu options for nodes and context boxes, respectively.
  • Links: Colors can be applied to line segments, arrow heads, and text labels. Changes are done by using options available on the "Link | Set Color" sub-menu. Colors and font attributes are modified by accessing nested menu options.
    

• Modification Nodes' shape: Nodes can be instantiated and modified using any of three geometrical shapes: rectangle, ellipse, and rounded rectangle. Options to modify the shape of selected nodes can be found under the "Node | Set Shape" menu option.
  

• Modifying the number of Line Segments on Links: jKSImapper allows the creation of three link types, which are differentiated by their number of line segments. To modify the number of line segments of a link, users need to access options found under the "Link | Set Arity" menu option.
  

• Arrow Head settings on Links: jKSImapper provides different arrow head arrangements. As shown on Figure 16, arrow heads implemented can be found in the any of the following configurations:
  • (a) Undirected: No arrow heads are shown. This is the default configuration when a link is created.
  • (b) Directed: One line segment will contain an arrow directed towards its edge, while the remaining line segments will stay arrow-less.
  • (c) Double directed: All line segments, except one, will show an arrow directed toward their edge. The remaining line segment will have an arrow head directed toward the joining point of the link.
  • (d) Bi-directed: All line segments will have an arrow head pointing toward their edge.
  • (e) Double bi-directed: Line segments will have two arrow heads each, one pointing to the joining point of the link, and the second pointing towards the edge of the line segment.
    

  These configurations can be found under the "Link | Set Arrows" menu option.
  
  
  

  Figure 16. Arrow head configurations exemplified on trinary links.
  

• Undo/redo operations: All events generated by users are translated into commands that are stored after being executed by the system. Every operation performed by users results in the creation of a command that will be executed and stored on a history list (a description of the command and history list implementation is found on Chapter 5, under the Section "5.1.4. Command Handling Classes"). Commands maintained in the history list can be replayed backward (undoing previous operations) or forward (to recreate previously undone commands). When the user is participating on a multi-user session, messages requesting undo or redo operations are sent to the server and then broadcast to the clients. Under this scheme, identical history lists are maintained on the server and on each of the client members participating on each session. History lists maintained by server and client processes are emptied when the file in the session is saved.
  

  The undo and redo options can be found under the "Edit" option on the menu bar.
  

• Saving a concept map: Concept maps can be saved locally or remotely. To save a file, Concept Map Window instances provide three options under its "File" menu bar option:
  • Save: This option saves the concept map on a previously defined file. jKSImapper will retain information of the place where a concept map was previously saved, whether locally or remotely. In the case that a concept map has not been saved before, a dialog asking for a new (local) file name will be displayed.
  • Save locally as: This option will present a file dialog requesting a file name. This file name will be used to store the concept map on the local computer.
  • Save remotely as: This option will display a dialog inquiring for the location of a networked computer running an instance of the jKSImapper Server process. Once a communication channel to the server has been opened, a dialog box requesting a file name will be displayed to the user. The file name provided is used for storing the concept map on the selected remote computer.
    

  As explained in previous sections, the origin of a loaded file has repercussions on the mechanism used to handle operations generated by the user. The same circumstance is applicable when saving a file: if the file is saved locally, new commands will be handled locally; if the file is saved remotely, a public session will be created and subsequent commands will be submitted to the server process.
  

4.4 JKSIMAPPLET.

Limiting the functionality of programs is one method to provide a secure environment for the execution of downloadable code in the Web. Another method might be to support well-defined security mechanisms to restrict the access to computer resources according to user-defined access policies. This method has the advantage of just restricting the functionality of those programs that do not conform to the level of trustworthiness granted by the user. Unfortunately, the absence of this (or a similar) security method has lead to the implementation of more restrictive (but simpler) security mechanisms.

Under this scenario, implementing jKSImapplet required the modification of some functions available on jKSImapper. Prominent adjustments were performed on two specific areas:

• User interface: Java does not provide mechanisms to implement menus in applets. A viable solution to interact with the user is achieved by embedding widgets in the HTML document containing the applet. These widgets were programmed to trigger events that would result on the calling of Java methods inside jKSImapplet. Linking widgets' events with jKSImapplet methods is achieved using Netscape's JavaScript language facilities. A more elegant (and complex) solution is discussed on Chapter 6, under "User Interface Improvements."
• File storage: Web browsers totally restrict applets from accessing local disk storage. This circumstance makes it impossible to save concept maps on the client computer, and no alternative solution is provided in the present implementation. As a result, jKSImapplet just supports manipulation of concept maps maintained by sessions held on server processes; specifically, by a server process running on the server from where the applet was downloaded.

Figure 17. HTML widgets interacting with jKSImapplet through JavaScript.

4.4.1 JKSIMAPPLET NAVIGATOR.

However, concept maps are not just aimed to communicate and gather ideas; they can also be used to organize information in different levels of abstraction. Concept maps can provide an active hypermedia interface by supporting hyperlinks to access resources. In the case of the Web, concept mapping tools can be used as hypermedia components to access Internet resources. To this end, jKSImapplet Navigator was developed as an example of the potential of concept maps to act as hypermedia navigator tools on the Web.

Figure 18. jKSImapplet Navigator.

Figure 18 shows a Netscape Navigator window being displayed as a response to a user selection on a concept map displayed on a separate window.

4.5 CHAPTER SUMMARY.

jKSImapper is based on work previously developed at the Knowledge Science Institute, as it was described on the first section of this chapter. Such systems were invaluable as a guide for the implementation of the test case systems presented.

The description of previous developments was followed by a discussion of the system requirements. A general development framework was determined by addressing the abstract, visualization and disclosure perspectives. Multi-user support was devised by analyzing the quadrants required for CSCW systems. These requirements were implemented in jKSImapper.

The last part of this chapter was devoted to introducing the operations performed by jKSImapper, jKSImapplet, and jKSImapplet Navigator. jKSImapper was described as composed of two elements: a Windows Manager and Concept Map Windows. The operations performed by jKSImapper were described in detail on Sections 4.3.1 and 4.3.2. jKSImapplet was introduced as a generic concept mapping applet derived from jKSImapper. One of several possible applications for jKSImapplet was depicted by jKSImapplet Navigator, which is an applet capable of accessing Web resources and hypermedia concept maps inside Netscape Navigator.

The next chapter (Chapter 5) will discuss the implementation of the applications described in this chapter. This chapter will start with a description of the jCMap Java class library, which will be followed by a discussion of the implementation of the runtime system architecture for the systems presented. Chapter 5 will end with an account of the lessons learned while porting C++ code to Java.