|
|
RacerPorter is a text-based ontology editor and the default GUI client of the RacerPro description logic system (DLS). The metaphorical name RacerPorter was chosen to stress that a “user friendly entrance” shall be provided to an otherwise “faceless” DL-server, like a hotel porter. Although quite a number of ontology browsing and inspection tools (called OBIT in the following) as well as authoring tools exist and numerous papers have been written about them [KPS+05, LN05, LN06, KMR04], RacerPorter represents a different approach. We present the design principles behind RacerPorter as well as the tool.
As already mentioned before (e.g., in [LBF+06]), ontology editors are currently the main software tool for ontology design tasks. They provide for functionality such as browsing and editing single ontology elements and the whole ontology structure, performing communication with background reasoners, visualization of reasoners’ feedback and so on.
When developing RacerPorter, the aim was not only to support this basic functionality but also to enhance usability and to solve certain “scalability problems”. Users “unscrupulously” load rather large OWL files into the reasoner and expect their taxonomies to be visualized with the ontology design tools such as RacerPorter. We reacted to the complaints of RacerPorter users by enhancing the performance and usability of previous versions of RacerPorter on large KBs.
RacerPorter exclusively uses the KRSS port of RacerPro, although support for OWL is included as well. Compared with DIG, KRSS has the advantage that it can also be used as a shell language (DIG was designed under a different perspective). The XML messages standardized by DIG are not on the correct level of abstraction for a shell language (even if a non-XML serialization of DIG messages were used).
In a nutshell, RacerPorter has been designed to meet the following design characteristics:
A KRSS or OWL ontology represented in a description logic system has many different aspects: the taxonomy represents the subsumption relationships between concept names or OWL classes, the role hierarchy represents the subsumption relationships between roles or OWL properties, and the ABox represents information about the individuals and their interrelationships (the extensional knowledge). Additional aspects may be present, e.g. queries and rules. Thus, we can make a “shopping list” of “things” which must be accessed, managed and visualized with a DLS OBIT: different DL servers and their connection profiles1 , TBoxes, ABoxes, concepts, roles, individuals, queries and rules, ABox assertions, etc.
In order to avoid an overloaded GUI – which would try to represent these different aspects and aspect-specific functionality in a single window pane – in a similar way as other graphical ontology tools, we favor tabbed interfaces in order to achieve a clean separation of different aspects. Different tabs thus present different aspects of the ontology together with aspect-specific commands. The term “different perspectives” also describes the approach quite well.
Whereas many operations are directly performed on the displayed representations of the objects on the RacerPro servers by means of mouse gestures (direct manipulation), we also favor push buttons to invoke commands. In many cases, push buttons will directly invoke KRSS commands, e.g., send an abox-consistent? to the connected DL server. Push buttons also have the neat effect to inform the user directly about commands which are reasonable to apply or which can be applied at all in a given situation, simply by being visible, so there is no need to search for a command in a pull-down menu, which distracts focus. However, it should also be noted that the buttons occupy screen space, and using buttons and menus should be kept in balance.
In many cases, some input arguments must be provided to KRSS commands. Input arguments are provided directly by the user if direct manipulation is employed for the interaction, but with simple push buttons this is not directly possible. Either the user must be prompted for arguments, or a notion of “current objects” must be employed. These current objects may have been (implicitly) selected by the user before and are from then on automatically supplied as input arguments to KRSS functions. This results in a stateful GUI. Sometimes, stateful GUIs are considered harmful. However, we will see that states are unavoidable if non-trivial ontology-inspection tasks shall be performed. Additionally, since also a DLS has a state, this state should be adequately reflected by the GUI as well (which automatically makes it stateful). In order to avoid opaqueness it is very important that the current state is appropriately visualized, e.g., in a status display which is visible at any time. According to the shopping list mentioned before, we must thus have a notion of a current DLS server, a current TBox and ABox, current concept, individual and role, current query, etc. These current objects partially constitute the current state of the OBIT.
The different tabs of the OBIT visualize often different objects. For example, one tab shows the individuals in the current ABox (the individuals tab), and another tab shows the concepts in the current TBox (the concepts tab). The information displayed in a certain tab thus depends on the current state. Additionally, the current concept (or the current individual) will be highlighted in the concepts tab (resp. the individuals tab), so it can be recognized easily. Two different tabs can also present the same objects, but use different visualizations. For example, the taxonomy tab also presents the concepts in the current TBox, but displays them as nodes in a graph whose edges represent subsumption relationships. Since all tabs display information according to the current state, the shown information is interrelated.
For certain ontology inspection tasks, it is further necessary to relate the information displayed on different tabs. One must establish a kind of information flow between different tabs. Let us illustrate this need for an input/output flow of information with an example.
As described, the individuals tab presents the list of individuals in the current ABox. If an individual is selected from that list, it automatically becomes the current individual. In order to explore of which concepts this individual is a direct instance, it is possible to push the “Direct Types” button which sends the direct-types KRSS command to the DLS, using the current ABox and current individual as arguments. In many cases, further operations shall be applied to the result concepts just returned, e.g., in order to explore which other instances of these concepts are presented in the KB. Thus, the concepts tab should provide a functionality which allows to refer to and highlight the just returned concepts, so that subsequent operations can be easily applied on them.
In order to establish this kind of information flow, we augment the notion of the current state by also including sets of selected objects in the state. Thus, the concepts returned by the direct-types command can become selected concepts. Selected concepts are shown as highlighted, selected items in the tabs which present concepts. Moreover, there are also selected individuals and selected roles. Objects can either be selected manually by means of mouse gestures, or automatically by means of KRSS commands, no matter how they are invoked. All what matters is the notion of selected objects. The set of selected objects is also called the clipboard. The current objects are seen as specific selected objects. Furthermore, all this state information is session-specific, given the fact that the OBIT should be able to maintain several connections and thus associated sessions simultaneously.
As said earlier, a shell tab is provided for interactive textual communication with the DLS. We claim that only shell-based interactions can offer the required flexibility and expressivity needed for advanced ontology inspection tasks. The shell must be incorporated into the above mentioned information flow as well. For example, if the direct-types command is entered into the shell, then it must be possible to refer to the current ABox as well as to the current individual which has been selected with the mouse in the individuals tab before (without having to type its name or having to use “copy & paste”). Furthermore, after the command was executed, it must be possible to select the returned concepts which are now shown in the shell as command output.
Focus control and navigation are two other important issues. It is well-known that the notion of current and selected objects can be used to control the focus. For example, the current concept can provide the root node in the taxonomy graph display. Only the descendants of the current concept will be shown. To browse larger taxonomies, a “depth limit” cutoff on the paths to display can be specified, and an interactive “drill down”-like browsing style can be realized. The node gesture “select” (e.g., a left mouse click) automatically changes the current concept and thus the graph root. If the graph is redrawn immediately, this allows to drill down a large taxonomy interactively and dynamically. However, this automatic graph recomputation changes the focus.
In principle, changing the focus automatically can be very distracting. In Web browsers, the navigation buttons (back and forth) are thus of utmost importance; they allow to reestablish the previous focus effortlessly. Thus, a focus or history navigator should be present in an OBIT, as also found in Swoop or GrOWL [KPS+05, SK06]. However, many users are unhappy with hyperlink-like focus-destroying operations. In Web browser, tabbed browsing has been invented to address this problem. Thus, we think that the user should be able to determine when and how the focus is changed once a gadget is selected.
Sometimes, it is also desirable to focus on more than one object, e.g., for ABox graphs. We can simply use the selected objects for that as well. In case of the ABox graph, each selected individual can specify a graph root, and unraveling (as understood in Modal Logics) is used to establish a local perspective from that individual’s point of view (so there is one graph per selected individual). This resolves many visual cluttering problems. The clipboard is thus not only a structure that enables flow of information, but can also be used to control the focus. This also implies that the focus control is now highly flexible: Since the clipboard can be filled from results of KRSS commands, even a semantic focus control is possible. For example, an ad-hoc nRQL query can be typed into the shell, and, with the push of a button, one can focus on the returned ABox individuals in the ABox graph tab. In our terminology, this kind of focusing by invoking inference services (such as, e.g., direct-types) is called semantic focusing. However, one also often wants to focus on individuals simply by their names. Thus, a kind of search field is needed. Objects that contain the search string get selected automatically. This enables a so-called syntactic focusing. We have found that many available tools don’t offer adequate mechanisms to achieve this kind of information flow and focus control.
Summing up, we conclude that the current state must be a vector <current objects, selected objects,active tab,display options>. Each time a state changing operation is performed by the user (e.g., the current objects or the clipboard is changed), a so-called history entry is automatically created, which is just a copy of the current state vector. History entries are inserted at the end of a queue, the so-called navigation history. A history navigator offers the standard navigation buttons. The OBIT always reflects the current state, no matter whether this is the latest one or a historic state from the history. A history entry only preserves the state information of the GUI, but not the content of the DLS at that time. Thus, a well-known problem arises here: If a historic state is reactivated, then it may no longer be possible to actually refer to the objects referenced by that state, since they may have been already deleted from the DLS. This problem is well-known to WWW users which keep a browsing history. There is no practical solution to this problem (one cannot preserve “copies” of DLS server states in history entries).
We believe that OBITs should allow for asynchronous usage. While a time-consuming command is processed by the DLS, the GUI shouldn’t block; instead, the result should be delivered and displayed asynchronously once available. Although the busy DLS will not accept further commands until the current request had been fulfilled (nowadays, there are no true multi-user DLS), in the meantime the OBIT should a) display status information in order to inform the user what the DLS is currently doing (future versions of RacerPro and RacerPorter will also support progress bars), and b), if possible, allow the user to do other things, e.g., continue editing a KRSS KB, or connect to and work with a different DLS.
RacerPorter was designed according to the design principles just explained. Each tab has a uniform organization, which, we believe, makes the GUI consistent and comprehensible. With the exceptions of the log tab and the about tab, each tab has six areas. Figure 6 shows the taxonomy tab. Let us describe the six areas of this tab.
The first area shows the available tabs: Profiles, Shell, TBoxes, ABoxes, Concepts, Roles, Individuals, Assertions, Taxonomy, Role Hierarchy, ABox Graph, Queries, Rules, Log, and About tab. The second area is the status display. It displays the current objects, the current namespace, the current profile (representing the current server connection), as well as the current communication status. The clipboard content is not shown, only the cardinality of the sets of selected objects (in the small number fields). The selected objects are highlighted once an appropriate tab is selected. The third area shows the history navigator. The fourth area is the tab-specific main area. Tab-specific display options and commands are then presented in the fifth area. Finally, there is the info display which is the sixth area. The info area is similar to the shell; however, it only “echos” the shell interaction (accepts no input). All user-invoked KRSS commands are put into the shell which are thus also echoed in the info display. This helps to avoid opaqueness, and as a side effect, the user learns the correct KRSS syntax.
The taxonomy and the ABox graph tabs use graph panes for the fourth area. With the exception of the shell, log and logo tab, the other tabs use list panes. List panes allow single or multiple selections of items; selected items represent the selected objects (clipboard). The last selected item specifies the current object. A search field is always present and allows to select objects by name. Selected items will appear on the top of the list if the “Selected First” checkbox is enabled. Some list panes display additional information on their items in multiple columns; e.g., in case of the TBox pane, not only the TBox name is shown, but also the number of concepts in that TBox, profile and DLS server information is shown in the profiles list, etc.
The graph panes are more complicated to handle since they allow to specify focus, layout as well as update options. In case of the ABox graph pane, one can determine which individuals and which edges are displayed. Thus, for both individuals and roles, the focus can be set to the current objects, to the selected objects, or to all objects. Appropriate radio buttons are provided. Additional radio buttons control whether only told role assertions, or also inferred role assertions shall be shown. Additional buttons allow to specify whether the graph display shall be updated automatically if the focus or layout options changes, or whether the user determines when an update is performed. In the latter case, the user first uses the button “Request Graph” to acquire the information from RacerPro (phase 1). Once the graph is available, the “Display Graph” button becomes enabled; if pushed, the graph layout is computed and displayed. Both phases can be canceled (and different focus and layout options selected subsequently) if they should take too long2 .
Finally, let us briefly discuss some features of the shell. The shell provides automatic command completion (simply press the tab key) as well as argument completion. The potential commands / arguments are presented in a pop-up list. Command completion is achieved by accumulating all results ever returned by KRSS commands. In order to make it easy to reexecute commands, the shell maintains its own shell history (not to be mistaken with the navigation history). Since the shell is tailored for KRSS commands in Lisp-syntax, we provide parenthesis matching, convenient multi-line input as well as pretty printing. Moreover, one no longer has to use full qualified names for OWL resources. To select the objects returned by a shell command, one has to hit the appropriate button (e.g., the “Selected Individuals := Last Result” button).
The log tab keeps a communication log which can be inspected at any time in order to learn what the DLS is currently doing. The current communication with RacerPro is also visualized in the request and response status fields; appropriate colors are used to visualize the different stages of such a communication (first the request is send, then RacerPro is busy, then the result is received over the socket, finally the result is parsed, etc.; note that errors can occur at any time in such a processing chain).
RacerPorter includes an Emacs-compatible editor with buffer evaluation mechanism (see Figure 7). Furthermore, RacerPorter will provide for visualization of explanations if an inconsistency occurs. This is done in two ways: a) by highlighting of culprits for inconsistency in the axioms and assertions tabs, and b) by highlighting of culprits in the editor window.
In the queries tab, nRQL queries can be executed. Besides of this, next versions of RacerPorter will also allow for sending SPARQL queries and displaying result tuples in the special SPARQL tab.
RacerPorter also includes basic functionality to start and stop RacerPro servers; startup and connection options can be specified with a profile editor. Finally, we want to stress that RacerPorter is a multi-session tool; thus, the current state and history, but also the shell content, is session or profile specific. Thus, the content of the shell must be saved and reinstalled once the original profile or session is reactivated. As one expects, this can be very memory-intensive, but thats the only way to do it.
We learned that a lot of effort must be put into an OBIT until it can be successfully used on large KBs. We tested the redesigned version of RacerPorter on the OpenCyc ontology [Ope] consisting of 25568 concepts, 9728 roles and 62469 individuals. The result is that RacerPorter can be used to browse and visualize this ontology. Moreover, time and memory requirements are not too bad. To achieve this, many aspects of the original code had to be reworked thoroughly. This not only concerns the choice of appropriate container data structures “that scale”, but also issues like communication over socket streams. For example, in our case it was no longer possible to simply coerce sequences of characters read from the socket connected to RacerPro to strings (although this is a very fast operation), since these strings simply get too big to be represented in the environment we use. For the implementation of the clipboard, we originally used lists as data structures. However, if the clipboard contains some ten-thousand instances, one can easily imagine that performance breaks down, since checking whether an object is selected (and thus a member of the clipboard) or not is an operation which has to be performed very frequently. Furthermore, in order to reduce socket communication latency, caches must be used in order to achieve an acceptable performance. Even the design of theses caches is demanding.
Summing up, we have presented design principles for OBITs and showed how they are realized in RacerPorter. Given the abundance of visualization facilities required, an OBIT has to link interactions and results into a coherent information flow. In RacerPorter, this information flow is established not only between the tabs and the system core (like a plugin architecture as it is realized, e.g., in Protégé) but also between certain tabs. To be user-friendly, an OBIT must come up with easy browsing and navigation solutions even for large ontologies. Although the existing tools are already very impressive, there is certainly room for enhancements, especially regarding visualization of and navigation in large ontologies in combination with powerful text-based editing techniques.
If you have specific requirements for visualizing your Aboxes or if you have specific application code that should be integrated into the user interface for the reasoning component, ask Racer Systems for consulting.
