[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8. PowerLoom GUI

The PowerLoom GUI (or knowledge editor) is a Java-based graphical client for PowerLoom. The GUI is implemented as a Swing-based Java application which communicates with an embedded or remote PowerLoom server using a SOAP communication layer over HTTP.

The architecture of the PowerLoom GUI most closely resembles the traditional two-tier client/server model. Since the GUI does not contain a great deal of business logic (e.g., it does not know how to do inferencing), it does not directly map onto the traditional notion of a smart client. Similarly, since PowerLoom is much “smarter” than a typical DBMS, it does not cleanly map onto a traditional backend server. However, since the GUI contains the presentation logic, it is more similar to a 2-tier model than a 3-tier model where the presentation logic resides in a middle tier.

Communication between the GUI and PowerLoom is done via the XML-based SOAP protocol. In order to effectively communication via SOAP, a Web service layer was built on top of PowerLoom. This layer provides support for marshaling and unmarshaling of PowerLoom objects to/from XML, and also provides a PowerLoom API that is accessible as a web service. The Java client uses JAXM and the Castor framework (see http://www.castor.org) to support SOAP communication.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.1 Invoking the GUI

The PowerLoom GUI can be started in a variety of ways. The easiest way is to use the top-level powerloom script (see section Running PowerLoom) and supply the --gui option. This will start the Java version of PowerLoom, start a standalone embedded PowerLoom Web server, launch the GUI application and connect from it to the PowerLoom server (using port 9090 by default):

 
% powerloom --gui
Running Java version of PowerLoom...
Initializing STELLA...
Initializing PowerLoom...
Loading required system webtools
Loading required system ontosaurus

    Welcome to PowerLoom 4.0.0

Copyright (C) USC Information Sciences Institute, 1997-2010.
PowerLoom is a trademark of the University of Southern California.
PowerLoom comes with ABSOLUTELY NO WARRANTY!
Type `(copyright)' for detailed copyright information.
Type `(help)' for a list of available commands.
Type `(demo)' for a list of example applications.
Type `bye', `exit', `halt', `quit', or `stop', to exit.


PL-USER |= 

Alternatively, PowerLoom can be started in its standard command loop mode and then the GUI can be started with the start-powerloom-gui command. This is useful if the GUI becomes necessary at some point during development or if a different port should be used. For example:

 
% powerloom
Initializing STELLA...
Initializing PowerLoom...

    Welcome to PowerLoom 3.2.52

Copyright (C) USC Information Sciences Institute, 1997-2010.
PowerLoom is a trademark of the University of Southern California.
PowerLoom comes with ABSOLUTELY NO WARRANTY!
Type `(copyright)' for detailed copyright information.
Type `(help)' for a list of available commands.
Type `(demo)' for a list of example applications.
Type `bye', `exit', `halt', `quit', or `stop', to exit.


PL-USER |= (start-powerloom-gui :port 9092)

Loading required system webtools
Loading required system ontosaurus

PL-USER |= 

When the GUI is run against an embedded server as in the examples above, it is run asynchronously and commands can be executed at the PowerLoom command loop at any time. Moreover, when the GUI is exited, the command loop stays active until it is exited explicitly as well.

The GUI can also be run standalone in which case the user needs to connect to a running PowerLoom server. For example:

 
% powerloom --gui-only
Running standalone PowerLoom GUI...

Once the GUI is initialized, the user can connect to a server via the File -> Connect to Server menu item. After the first connection, the host and port of the last used server will be remembered for the next startup. If during the next startup that server is not active anymore, an error will be signaled and the user can connect to a different server instead.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.1.1 Starting a PowerLoom Server

The GUI always connects to a PowerLoom server which can be embedded in the same Java process (as in the examples above), or can be run in a separate Lisp or Java process or as part of a Tomcat server (a C++ Web server is not currently supported). To start a PowerLoom server do the following. Start the Java version of PowerLoom via the powerloom script or start a Lisp version of PowerLoom that supports a Web server such as Allegro CL or a Lisp that supports Portable AServe. Once PowerLoom is up and running, issue the following command:

 
PL-USER |= (start-powerloom-server)

Loading required system webtools
Loading required system ontosaurus

PL-USER |= 

The command also accepts a :port option to make the server listen to a different port.

Alternatively, the PowerLoom Web Archive available in

 
powerloom-x.y.z/native/java/lib/ploom.war

can be deployed in an Apache Tomcat server by copying it into the server installation’s ‘webapps’ directory. The GUI can then connect to it at the server port used by Tomcat.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.2 GUI Design Goals

The choice of technology was driven by a number of design goals which are summarized below. Note that the most of the GUI code was developed back in 2002 and is therefore somewhat outdated with respect to today’s Java and Web-based human interface technologies.

Visibility: Knowledge Bases are complex and loosely structured entities. It is often desirable to simultaneously maintain multiple views of a KB, and to simultaneously perform multiple complementary task such as browsing, editing, querying, and searching a KB. With Swing’s MDI (Multiple Document Interface) mode, many internal frames can be open at the same time within a single “desktop” frame. Swing also offers a very rich set of components and UI mechanisms which facilitate efficient use of screen real estate.

We designed the GUI to take advantage of Swing’s presentation strengths. We used the MDI mode, so browsers, editors, etc. can coexist on the same desktop. Additionally, multiple knowledge browsers can be open at the same time to present different views of a KB. The Knowledge Browser itself consists of multiple collapsible and resizable subpanes, which in turn are composed of scrollable lists and trees. This allows a “birds-eye” view of a Powerloom KB, in which many modules, concepts, relations, instances, propositions, and rules can be displayed at the same time.

Navigability: When exploring a KB, it is imperative that a user interface allows easy navigation between related objects. The PowerLoom GUI has extensive navigation capabilities, which are as good or better than browser based applications. For example, a user may click on a query result to instantly update the Knowledge Browser to display the selected object. Also, a user can right-click on a relation or argument in a proposition, and navigate to the clicked-on object.

Responsiveness: For the best possible user experience, a user interface should be highly responsive to a user’s input gestures. For example, (1) after initiating a gesture such as a mouse click or keypress, there should be a minimal delay before the appliction performs the intended action, and (2) “Power Users” should be able to perform complex tasks with a minimum number of mouse clicks, key presses, etc.

The PowerLoom GUI attempts to minimize network round-trips by caching large amounts of data. For example, when a user points the Knowledge Browser to a module, a large chunk of the module is retrieved from the server and cached in the client. Hence, when the user expands a tree in the browser, the GUI will not need to retrieve more data from the server. Also, the GUI takes full advantage of Swing’s ability to control the application via keyboard input. For example, to create a new instance named newName, a user needs to simply type the key sequence Ctrl-I newName RET.

Context Sensitivity: For any given object that is displayed in a user interface, there is a set of actions that can be performed on that object. Additionally, the actions that can be performed on an object depend on where the object is displayed. Therefore, the GUI pervasively supports context-sensitive popup menus. When users right-click on an object, a list of appropriate actions will be presented in a menu. For example, when a user right-clicks on a concept in the Knowledge Browser, the list of possible actions shown in fig:context-menu is presented.

../../../sources/powerloom-gui/doc/images/gui-context-menu

Figure 8.1: Context-specific menu of possible actions on a concept

Editability: Applications that support text editing often need capabilities above and beyond the baseline copy, cut and paste capabilities that all text widgets support. In particular, applications that allow editing of text with a regular structure such as source code or Lisp expressions may take advantage of special key bindings which augment basic navigation and editing capabilities.

The PowerLoom GUI makes use of Swing’s powerful text components by implementing a full set of Emacs-style keybindings. These keybindings allow a user to perform such operations as navigating up and down a subexpression hierarchy, selecting entire subexpressions, and completing incomplete symbols. In addition, matching parenthesis are automatically highlighted in the GUI’s text components.

Extensibility: While it is not easy to claim that Swing applications are inherently more extensible than Web applications, Swing’s MDI architecture and pull-down menu framework allows new features to be added with little disruption to the rest of the application. In particular, using modern GUI design tools that are part of IDE’s such as Netbeans or Eclipse, it is fairly easy to add new components and functionality to the PowerLoom GUI. It is also conceivable that the GUI code could be used as the basis for a more specific application which would have its own application-specific menus and windows, but would retain the general-purpose browsing, querying, and editing tools for direct manipulation of the knowledge base.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.3 GUI Overview

An example screen shot of the PowerLoom GUI is shown in fig:gui. The main application frame consists of pull-down menus, a toolbar, and a status bar.

../../../sources/powerloom-gui/doc/images/gui

Figure 8.2: The PowerLoom GUI

The menu bar contains the following menus:

Most menu items have accelerator keys that allow an item to be executed by a combination of keystrokes. The toolbar contains several buttons which provide shortcuts to menu items. There are currently toolbar buttons for cutting, copying, pasting, deleting, editing an object, and opening a query dialog. The toolbar may be undocked from its default position by dragging it anywhere on the desktop. It may also be hidden and unhidden by selecting the View -> Toolbar menu item.

The status bar at the bottom of the application contains information on the current status of the application. The status bar is divided into two sections. The leftmost section displays the last module that was selected by a user. The application keeps track of the current module in order to provide continuity between operations. For example, if a user opens a browser and browses the AIRCRAFT-KB, and then opens a query dialog, it makes sense for the query dialog to use the AIRCRAFT-KB module instead of some other module.

The rightmost section of the status bar contains messages that pertain to the current state of the application. For example, if a user selects a concept and then clicks the cut toolbar button, a message will appear in the rightmost status bar prompting the user to select another concept and perform a paste action. The status bar may be hidden and unhidden by selecting the View -> Statusbar menu item.

fig:gui shows a few internal frames that are open. The function of each frame is identified in the frame’s title bar, and each type of frame has a unique icon in it’s upper left-hand corner. In this example, the three open frames are used to browse the KB, query the KB, and edit an instance.

A user typically follows a workflow cycle similar to the following sequence:

  1. The user launches the GUI by executing the powerloom script, clicking on a desktop icon or on a hyperlink in a browser.
  2. The GUI is loaded on the user’s machine. If the GUI was launched via Java Web Start (not yet fully supported), the entire application may need to be downloaded or updated before execution begins.
  3. The GUI reads a preferences file stored in a default location on the user’s local machine. If this is the first time the application is being executed, a default preferences file is used. The preferences file includes among other things the PowerLoom server that was last accessed.
  4. If the preferences file contains the last-accessed server, the GUI attempts to connect to the server and query the server for a description of the server’s capabilities. If connection is successful, a browser window will open displaying the modules that are currently loaded in the server instance.
  5. The user selects any KB files (s)he wishes to load, and instructs the server to load the files.
  6. The user performs some browsing, querying, and editing of the loaded KB.
  7. If any changes were made, the user saves the KB to a new or existing file.
  8. The user repeats steps 5-7 as needed, and then exits the application.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.4 GUI Features

This section provides a detailed description of the features that are available in the GUI application. We describe general application-wide functionality as well as the functionality of specific components.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.4.1 Connect to Server

The first time the GUI is started, it will not attempt to connect to any server. To establish a server connection, the user must select the KB -> Connect to Server menu item. This will open a dialog prompting for a host name and port. After the user enters this information, a connection will be attempted. If the connection is successful, the server information will be stored in the preferences file and used next time the application starts up.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.4.2 Edit Preferences

A preferences dialog can be opened by selecting the Edit -> Edit Preferences menu item. Currently, the only preference that a user can edit is whether or not to open a browser when the application is started. The dialog contains a checkbox asking whether or not the preferences should be saved. If the checkbox is not checked, the preferences will remain in effect for the duration of the current session, but will not be in effect when the application is restarted.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.4.3 KB Load/Save

In its standard configuration, PowerLoom stores knowledge bases via flat files. The user can load one or more KB files from the local file system which will be transferred across the network and loaded into the server instance via PowerLoom’s load command. Conversely, a modified knowledge base can be saved to a local file on a per-module basis (using a version of PowerLoom’s save-module command). Future versions of PowerLoom will support more sophisticated persistence that will go directly to a database or other persistent store.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.4.4 Browsing

The knowledge browser window, shown in fig:browser, can be opened by selecting the KB -> Browse menu item or typing Ctrl-b. The browser provides a visual overview of all knowledge in the KB, and is capable of launching specialized tools such as editors, search dialogs, etc.

../../../sources/powerloom-gui/doc/images/gui-knowledge-browser

Figure 8.3: Knowledge Browser

The browser consists of several subpanes which we refer to as navigation panes. Each navigation pane consists of a title pane, a toolbar, and a content pane. The title pane contains a title indicating what is displayed in the content pane. The toolbar consists of zero or more buttons which perform actions relevant to the navigation pane. Currently, two toolbar buttons are present: "Add" and "Search". "Add" (indicated by a +-sign icon) adds an object associated with the type of navigation pane. "Search" (indicated by a flashlight icon) searches for objects associated with the type of navigation pane. The content pane contains the actual knowledge to be displayed, such as a list of instances or propositions.

There is one navigation pane for each type of KB object: Modules, Concepts, Relations, Instances, Rules, and Propositions. Each internal pane is resizable by dragging the movable divider between the panes. Panes may be hidden completely by clicking the "Collapse" arrow on the adjacent divider. Clicking the "Expand" arrow will unhide the pane.

Visual Cues: Navigation panes employ several visual cues to enhance the identifiability of object attributes. Object types are indicated by an icon to the left of the object’s name. For example, modules are represented by a blue M, concepts by a red C, etc. The status of propositions is also indicated visually. An italicized proposition indicates that the proposition was derived instead of asserted. Grey propositions indicate that their truth value is a default value instead of a strict value.

The main method for filling the contents of a navigation pane is to select some object in a navigation pane that is to the left or above it. This is discussed in more detail in the section below. However, in some cases, it is possible to modify the contents of a navigation pane without performing a selection. For example, in the instance navigation pane, it is possible to show derived or inherited instances by right-clicking on the instance list and selecting an appropriate menu item. Similarly, the relation navigation pane can toggle between direct or inherited relations. Propositions and rules are by default displayed according to the module that is currently selected. However, the contents of the proposition or rule navigation pane can be updated by selecting a more specific module in the View From Module combobox contained in the navigation pane’s title bar.

Selection: When the browser is initially opened, a tree of modules is displayed in the module navigation pane, and all other navigation panes are empty. When a module is selected, the remaining subpanes are populated with knowledge that is contained in that module. Similarly, selecting a concept in the concept navigation pane populates the relation, proposition, and instance panes with knowledge that is relevant to the selected concept. In general, selecting an object in a given navigation pane may affect the contents of navigation panes to the right and/or below it. More specifically, the rules for object selection are as follows:

The title pane in each navigation pane displays a description of the source of the subpane’s contents. For example, if both the relation WINGSPAN and the instance AGM-130 were selected, the proposition subpane would contain the title “Propositions for WINGSPAN and AGM-130”.

Each selection event is recorded in a selection history which can be rolled back and forward. For example, assume the user selects the AIRCRAFT-KB module and then selects the GUIDANCE-TYPE concept. If the user then selects the Navigate -> Back menu item, the selection history will be rolled back so that only AIRCRAFT-KB is selected. If the user then selects Navigate -> Forward, the selection history will be rolled forward to its original state so that both AIRCRAFT-KB and GUIDANCE-TYPE are selected.

Navigation: Knowledge can be explored by expanding and collapsing nodes in hierarchical navigation panes such as the concept and module navigation panes. If a tree or list is not fully visible, the user may use the scrollbar on the navigation pane’s right-hand side to scroll through the contents of the pane. Detailed views of objects such as concepts and relations can be obtained by right-clicking the object and selecting the Edit menu item. To navigate to a constituent of a proposition, the user can right-click the constituent and then select the Navigate to... menu item. For example, right-clicking on the GUIDANCE argument in the proposition (NTH-DOMAIN GUIDANCE 1 GUIDANCE-TYPE) presents a popup menu which displays (among other items) the item Navigate to GUIDANCE. Selecting this menu item will cause the browser to display and select the GUIDANCE relation.

Actions external to the browser may also update the browser’s contents. For example, clicking on an instance in a list of query results will cause the browser to navigate to the selected instance.

Actions: Right-clicking inside the browser will present a menu of actions that is relevant to the subpane that contains the mouse pointer. The list of items will depend on whether the mouse is over a specific item or if it is over the background of the subpane’s list or tree. For example, when the mouse is over a specific concept, the menu will contain items for cutting, pasting, instantiating, etc., but when the mouse is over the background of the concept tree, the only menu item presented will be to add a new concept.

The set of actions available for each subpane are as follows:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.4.5 Editing

Objects may be edited by right-clicking them and selecting the Edit... menu item in the popup menu. Alternatively, an object may be selected, and then the Objects -> Edit Object menu item or the the edit toolbar button can be pressed. Object editors do double-duty as object viewers, since all relevant object information is present in each editor.

There are several common user actions that are available in edit dialogs. For example, hitting RET while the cursor is positioned in the name field of the editor commits the concept. Most editors have OK and Cancel buttons at the bottom to commit or abort edits. Lists of items commonly have + and -- buttons at the top that allow one to add a new item or delete the selected item. When the + button is pressed, either a chooser dialog (see section Choosers) or a specialized editor will be opened. Similar to the browser, list items can be right-clicked to display a list of possible actions. For example, a superconcept can be clicked in a concept editor to immediately edit the concept’s parent.

../../../sources/powerloom-gui/doc/images/gui-instance-editor

Figure 8.4: Instance Editor

Each type of object has a specialized editor. For example, an instance editor is shown in fig:instedit. There are separate editors for modules, concepts, relations, instances, and propositions/rules, which are described below.

Module Editor: The module editor contains a number of fields and components used to enter information relevant for a new or existing module. Examples of values that can be edited are a module’s name, its documentation and its includes (or supermodules) list.

Concept Editor: The concept editor allows editing of concept attributes such as a concept’s supertypes, its name, its associated propositions, etc. In addition to the inherent attributes of a concept, all relations which have the concept as a domain type are displayed and may be edited. Clicking the + button above the relation list opens a new relation editor with default values filled in. Similarly, clicking the + button above the proposition list opens a proposition editor.

Relation Editor: The relation editor allows the user to enter a list of variables and types for the relation’s arguments, and allows the setting of various relation attributes, e.g., whether the relation is closed, functional, etc. Similar to the concept editor, propositions and rules associated with a relation can be edited.

Instance Editor: The instance editor allows the user to input an instance’s name, documentation, and associated propositions. If a proposition uses the relation image-url, an image will be retrieved from the server and presented in the editor window.

Proposition editor: The proposition editor, shown in fig:propedit, consists of a text field for entering the proposition, and a set of buttons for performing actions on the proposition. The buttons allow a user to assert, deny, or retract the typed proposition. There are several text-based facilities which support efficient editing of propositions. First, the editor supports many Emacs-style keybindings which facilitate editing of Lisp-like expressions, including selecting entire parenthesis-delimited subexpressions, jumping backward and forward over subexpressions, and navigating up and down expression trees.

../../../sources/powerloom-gui/doc/images/gui-proposition-editor

Figure 8.5: Proposition Editor

In addition to Emacs keybindings, the proposition editor has a matching parenthesis highlighter. When the cursor is placed before a left parenthesis, the matching right parenthesis is highlighted, and when the cursor is placed after a right parenthesis, the matching left parenthesis is highlighted.

The proposition editor also supports symbol completion. The GUI uses a predictive backtracking parser to analyze partial input of propositions. Based on the analysis, the parser is able to recommend appropriate completions. For example, if the user types (f and then selects the completion action by typing Ctrl-right, the parser will recommend a list of completions including the forall symbol and all concepts and relations that begin with the letter f.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.4.6 Choosers

In a number of situations, an object of a specific type must be selected. For example, when selecting a superconcept in a concept editor, the user should be presented with a list of existing concepts. In these cases, a chooser dialog is presented to the user which displays a filterable list of candidate objects. As the user types a name of the object in the name text field, the list of objects is filtered so that only objects which begin with the typed prefix are displayed. Choosers are available for modules, concept, instances, and relations. A variable chooser allows the user to type a variable name and select a type from a concept from a list.

../../../sources/powerloom-gui/doc/images/gui-extension-editor

Figure 8.6: Extension Editor


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.4.7 Extension Editor

The extension editor, shown in fig:extedit, allows editing of a concept or relation’s extension. It can be opened by right-clicking on a concept or relation in the browser or by selecting the Query -> Edit Extension menu item. The extension editor presents a relation’s extension as a list of tuples in table format. The user may add new tuples by typing names of instances at the bottom of the table, and may alter existing tuples by double-clicking on a table cell and typing in a new value. Instance name completion is available while typing instance names by typing Ctrl-right. A user may choose to abort the edited extension by clicking the Cancel button. If the user clicks the Commit button, the relation’s extension will be updated by asserting and retracting appropriate propositions.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.4.8 Ask and Retrieve Queries

../../../sources/powerloom-gui/doc/images/gui-query-dialog

Figure 8.7: Query Dialog

The Query dialog, shown in fig:query, can be opened by selecting the Query -> Query menu item, by typing Ctrl-Q or by pressing the query toolbar button. The Query dialog consists of a text area for typing the query, a results table for displaying the results of the query, a query list for saving and selecting pre-saved queries, and an options subpane for configuring various query parameters.

The query input pane supports features similar to that of the proposition editor, including Emacs key bindings, parenthesis matching and completion. Queries can be executed by typing Ctrl-RET or by clicking on the Execute button at the bottom of the dialog. After a query has executed, results will be displayed in the results table or a “No results found” indicator will flash. The column headers for the results will display the corresponding free variables in the query. Results may be sorted by clicking on a column header. Doing so will sort the results by using the clicked column as an index. Users may toggle ascending/descending sort order by clicking the header multiple times.

If the query contains no free variables, it is effectively a true/false ASK operation as opposed to a RETRIEVE. In this case, the result will be a truth value, and the column header will be labeled TRUTH-VALUE. If the query is the result of a partial retrieve operation, an additional column containing the match score will be displayed.

If the user clicks on a cell in the results table, the topmost browser will be updated to display the selected item. Right-clicking on a query result brings up a context menu which currently only contains an Explain result menu item. Selecting this will present an HTML explanation in a separate window. The displayed explanation may contain hyperlinked objects. Clicking on a hyperlinked object will update the topmost browser to display the object.

Users may save frequently-executed queries in a query list by clicking the Save button at the top of the options panel which will prompt them for a query name. Saved queries will be stored in the preferences file using an XML representation. Saved queries are stored in the combobox to the left of the save button. Selection of a saved query will prefill the query dialog with the query and all saved parameters.

Most important PowerLoom query options are controllable in the options dialog, such as number of results to retrieve, inference control options such as inference level, timeout, moveout and various others.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.4.9 Search

Users may search for objects in the KB by entering strings which match the name of the object. A search dialog as shown in fig:search can be opened by selecting the Query -> Search menu item, by typing Ctrl-f, or by pushing a search toolbar button (marked by a flashlight icon) inside the browser. If the user activates a search toolbar button inside a navigation pane, the search dialog will be configured to search for objects associated with the type of object displayed in that pane. For example pushing the search button inside the concept navigation pane will configure the search dialog to look for concept objects only.

Searches may be constrained in several ways. First, the module may be specified or the user may specify that the search should be across all modules. Second, the types of objects to be searched is configurable. For example, users may search for concepts and instances, instances only, etc. Finally, users may specify that an object’s name must match the beginning or end of the search string, or match the search string exactly.

../../../sources/powerloom-gui/doc/images/gui-search-dialog

Figure 8.8: Search Dialog

When the user executes the search by hitting RET or selecting the OK button, a list of results is presented. These results are provided in a table format where one column is the name of the retrieved object, another column contains the module that the object resides in, and the final column specifies the type of the object (i.e., concept, instance, etc). As is the case with query results, clicking on a search result item will update the topmost browser to display the selected object.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.4.10 Console

The console window, as shown in fig:console, can be opened by selecting the KB -> Open PowerLoom Console menu item or by typing Ctrl-p. This opens an internal window, which allows PowerLoom commands to be typed directly and sent to the PowerLoom server. The response generated by PowerLoom is sent back to the GUI and printed below the prompt. This functionality is similar to that of a LISP listener.

../../../sources/powerloom-gui/doc/images/gui-console

Figure 8.9: PowerLoom Console


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.4.11 Cut/Copy/Paste/Delete

The PowerLoom GUI supports cut, copy, paste, and delete operations. These operations can be used to edit text, and in some cases they can be used to edit objects in lists or trees. For example, the concept hierarchy can be edited within the browser by selecting a concept, executing a cut operation, selecting another concept, and then executing paste. This sequence of operations will delete the concept from it’s original position in the hierarchy, and make it a subconcept of the concept that was selected when the paste operation was performed.

The GUI implements a robust data transfer framework that is capable of recognizing the types of objects that are being transferred, and the types of potential transfer sources and destinations. This allows the application to prohibit nonsensical data transfers such as cutting a concept in a concept navigation pane and then trying to paste it into a module pane. It also allows data transfer operations to be context sensitive. For example, cutting a concept in a concept navigation pane means that a move operation is being initiated, while cutting a concept in a concept editor’s superconcept list means that the concept should be removed from the list. Additionally, copying an object such as a concept, then executing a paste inside a text window will paste the name of the object.

As one would expect, text may be cut, copied and pasted between the GUI and outside applications.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.5 Future Work

There are many areas where further development and improvement is needed, including:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.5.1 Large KBs

Currently, when a module is selected, the GUI attempts to retrieve all concepts, relations, and instances that are contained in that module. For large knowledge bases that might contain millions of objects and assertions, this is clearly infeasible. To handle such situations we need to develop more sophisticated retrieval and caching strategies to only materialize partial views of a KB in the GUI. Scrolling down a list, for example, might then trigger the retrieval and display of additional objects on demand, while older, inactive objects are being flushed from the cache.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.5.2 Undo

There is currently no undo facility and changes to the KB are written through to the server as soon as a user clicks OK in an editing dialog. To support this properly, we would need a snapshot mechanism that would allow rollback to earlier states of the KB.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.5.3 Drag and Drop

Adding a drag and drop capability would make ontology editing easier than is currently possible. For example, one concept could be dragged on top of another to move the object from its current position. We believe that the existing data transfer framework could be leveraged to implement a robust drag and drop facility.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.5.4 Scrapbook

In creating and editing ontologies, it is sometimes desirable to maintain heterogeneous scraps of information. We envision a scrapbook feature where text and objects of various types could be dragged to and organized visually for later use.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.5.5 Instance Cloning

It is often useful to create new instances that are similar to existing instances. We would like to implement a cloning facility in which a wizard-like series of dialogs would step the user through the process of copying information from one object to a new object. For example, the dialogs would prompt the user for propositions to transfer from the old instance to the new instance, and allow the user to modify the propositions in the process of transferring them.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.5.6 Security

There is currently no authentication and access control mechanisms in the PowerLoom GUI. The GUI client assumes that is communicating with a trusted host over a secure network. Similarly, the PowerLoom server assumes that it is communicating with a friendly client that has full access to the server. In the future, we need to add security mechanisms which allow clients to be authenticated, and resources on the server to be made accessible to authorized users only. In addition, we need to implement encryption mechanisms so that clear text is not sent over insecure networks, potentially compromising sensitive data.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.5.7 Multiple Users

Although the client/server model allows multiple GUI clients to concurrently share the same server, there is only very weak support for synchronizing clients and ensuring that users don’t accidentally step on each other. We need to improve our infrastructure to handle notification of KB updates, add support for transactions and KB locking, and improve our caching mechanisms to detect when the GUI state is out of sync with respect to the server.


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated by Hans Chalupsky on January 6, 2023 using texi2html 1.82.