Researchers have developed a large number of ontology-mapping algorithms in recent years. However, ontology mapping is hardly a fully automated task and users must verify and fine-tune the mappings resulting from automated algorithms. Both academic and industry researchers have focused on the algorithms themselves and largely ignored the issue of cognitive support for users in the task of analyzing mappings proposed by the algorithms and creating new mappings. The lack of comprehensive user-oriented tools for ontology mapping (rather than just algorithms) hinders the adoption of the new technologie. In this paper, we analyze requirements for cognitive support for the ontology-mapping task. Recognizing that many researchers must focus on improving the algorithm performance itself (or only on providing better visualization), we have developed a plugin framework that enables developers to assemble a comprehensive ontology-mapping tool by plugging in various components. We provide a reference implementation of the complete framework. Thus, developers can plug in only the components they are interested in. For example, algorithm developers can plug in their algorithm and use the visualization components that we provide and the user-interface researchers can use the framework to experiment with various visualization paradigms for ontology mapping (and not worry about implementing the algorithms themselves). We also discuss specific cognitive aids for ontology mapping that we have developed and that are available as part of this framework.
As ontologies become more commonplace and their number grows, so does their
diversity and heterogeneity. Reconciling different ontologies and finding correspondences
between their concepts is likely to be a problem for the foreseeable future. Thus,
research on ontology mapping has become a prominent topic in the Semantic Web and
ontology communities. There are mapping contests that compare the effectiveness of
different algorithms [
In general, a user interacting with an ontology-mapping tool, must examine the
candidate mappings produced by the tool, indicate which ones are correct and which
ones are not, and create additional mappings that the tool has missed. This process is
a difficult cognitive task. It requires understanding of both ontologies being mapped
and how they relate to each other. Also, both the ontologies themselves and the number
of candidate mappings that the tools produce can be very large. However, there has
been very little research on how to provide cognitive support for ontology mappings.
Researchers have focused on improving the performance of the algorithms themselves,
largely ignoring the issue of end-user tools (with a few exceptions [
Perhaps, one of the reasons this issue has not been addressed is the lack of
understanding of the importance of cognitive support [
Cognitive-support research is still new to software and knowledge engineering. In software engineering, generally, most tools are built with some consideration of utility and usability. Only recently, researchers started using a more formal approach to address these issues. The situation is similar in the field of knowledge-engineering tools. In this paper, we bring cognitive-support considerations to the ontology-mapping tools, and outline a set of requirements for these tools.
We believe that in order for the ontology-mapping tools to reach beyond research
labs, both the performance of automatic ontology-mapping algorithms and the
quality of cognitive support in ontology-mapping tools must improve. Recognizing that in
many cases, researchers must focus on one or the other of these tasks, we have
developed a plugin framework that covers many of the sub-tasks of ontology mapping, from
specifying algorithms for initial comparison to executing the mappings. This
framework is part of the PROMPT ontology-management suite [
This paper makes the following contributions: – We analyzed requirements for cognitive support in ontology mapping (Section 2). – We developed the PROMPT plugin architecture for ontology-management that enables developers to assemble a comprehensive ontology-mapping tool with their own components as part of the tool (Section 4). – We implemented a set visualization plugins to the PROMPT plugin architecture that provides cognitive support for users in the ontology-mapping task (Section 5.2) 2
The set of end-user tasks in an ontology-mapping tool that we identified and the corresponding requirements are based on the common problems we have experienced and 3 http://protege.stanford.edu witnessed. We assume that the user’s tasks involve verifying and fine-tuning the mappings produced by the automatic component and creating the mappings that the automatic algorithm missed. The following is a preliminary list of tasks that must be supported during the mapping process. Some of the requirements below address visual aids that make the user’s job easier, and others are tasks that help reduce the user’s cognitive load.
Navigation of ontologies being mapped: provide full access to the source and target ontologies.
Incremental navigation: enable browsing of the ontologies being mapped with the terms in the current mapping as focal points. Incremental navigation restricts the focus to the terms and allows the user to visually verify that the two terms suggested in the mapping have similar context and similar neighbors.
tions of the ontologies have large numbers of candidate mappings. Users may often want to focus on the sections where many of the mappings are, since these are likely to be the sections of the two ontologies where most of the mapping takes place. Browsable list of candidate mappings: provide easy navigation and filtering of the candidate mappings produced by the automatic step. There must be a way for the user to instruct the tool to focus on certain regions of the ontologies or categorize the candidate mappings they are verifying. Such support allows the user to focus on smaller tasks and reduce complexity by validating higher priority matches first.
indication of why the automatic algorithm suggested a particular mapping. This reason helps establish trust between the user and the algorithm. For example, state that the two ontology terms matched exactly, or were synonyms of each other. Context for mapping terms: display where the terms being mapped are in the ontology. Easy access to this information is essential in enabling the user to verify candidate mappings. In particular, the neighborhood of a term (immediate parent and children in the is_a hierarchy) may be especially important.
Definitions for mapping terms: provide easy access to full definitions of the terms in the ontology. For example, the definition might include the properties of a class and restrictions on those properties. Like the neighborhood, the internal structure helps explain the meaning of the term.
mappings that he has created produce conflicts or are inconsistent. Conflicts can arise from a variety of situations, such as when two concepts are mapped, but some structural elements that are critical for their definition have not been mapped yet. Ability to save the verification state: The verification process must support potential interruptions where the user must be able to save their current progress and restart from that point at a later time.
for example, by transforming instances from the source to the target ontology based on specified mapping or using queries that access those individuals but this time direct them to the newly mapped term One can view such a transformation as a debugging step in creating a complete mapping: the user can verify if the instances created in the target from the source instances are the ones that he expected.
verified mappings. For example, a user may specify that a value of one property must be changed in a specific way in order for the mapping to be correct. Also, users may want to add metadata to mappings and describe their reasons for creating the mapping. The users will also often add mappings that the tool has missed.
teraction with a mapping tool is a set of verified mappings, additional mappings, and details about the mappings. Users must be able to navigate this information. Progress feedback: inform the user about their current progress in the mapping. How much they have verified and how much is left to verify. Verifying mappings can be a lengthy process, but providing feedback about the users’ progress enables them to see that they are moving in the correct direction. 3
Cognitive support is about introducing artifacts in order to improve cognitive systems
[
Knowledge-engineering tools often use visualization to help users navigate
ontologies. Usually, the problem these visualization tools are addressing is the comprehension
and navigation of large information spaces. Different types of graph layouts are often
used in order to display the ontology from different perspectives (e.g., see [
Navigation is also a relevant issue in ontology mapping, as users need to understand the structural context related to the match operations they must verify. However, in ontology mapping the focal point of the navigation is the terms involved in the mapping, not necessarily the entire information space. 3.1
Most user interfaces for mapping tools fall into one of three categories: graphical user
interface, console-based, and finally web-based. Both the console-based and web-based
tools follow similar approaches; the user supplies URIs for two ontologies, submits
the input, and the tool processes the ontologies producing a list of potential matches.
FOAM [
Clio [
These tools provide a mechanism to allow the user to supply an initial set of matches.
This mechanism may be adapted to store a partially verified mapping and to restart
verification at that particular stage. Also, tools like Clio and COMA++ support in-tool
navigation of ontologies. There’s also recently been an effort by a small number of
researchers towards investigating applying visualization techniques to ontology
alignment. AlViz [
The work that is closest to our plugin framework for mapping is the IBM XML
Mapping technology [
PROMPT is a Prote´ge´ plugin that supports various tasks for managing multiple
ontologies, including ontology mapping [
When verifying candidate mappings, users can access the source and target ontologies in the Prote´ge´ interface; when a user selects a mapping to examine, the corresponding concepts are highlighted in the ontologies trees. A user can also navigate to the tab that displays the mapping ontology and its instances and edit the mappings there directly (see Fig. 2).
The PROMPT plugin framework allows developers to replace any of the components that we have just described with their own. The plugin framework works by providing Java interfaces for various types of plugins (comparison algorithm, visualization components, etc). A plugin developer chooses the interface they wish to implement, and then supplies the appropriate method bodies in order to perform the operations they wish to execute. More specifically, we view the ontology-mapping process as a sequence of the following steps (Fig. 3):
and produces a list of candidate mappings.
Present candidate mappings to the user enabling him to analyze the results. This step includes components for cognitive support (various visualizations of the source and target ontologies, options to filter content presented in the display, etc.) and interactive comparison algorithms that are invoked either explicitly by the user or as a result of mappings being verified.
Fine tune and save the mappings in a declarative mapping format.
Execute mappings to transform instances from source to target or to perform other operations.
In the current implementation, developers can replace components of any of the steps in this list, and our plan is to make all of the steps replaceable.
Figure 4 shows the PROMPT screen for configuring an algorithm for initial comparison. The user has chosen to run a FOAM algorithm at this stage. The integration of FOAM and PROMPT is available as part of PROMPT distribution 4. A developer of an algorithm plugin can specify not only how to invoke the algorithm, but also how the configuration screen presented to the user should look like.
User-interface extension points exist throughout the P ROMPT mapping interface. We currently support extensions that allow a developer to add new tabs to the source, 4 At this time, the only algorithms integrated are FOAM and the original PROMPT algorithms. Fig. 3: Configurable steps in the PROMPT framework. Developers can replace any component in the figure with their own implementation. Cognitive aids can be applied at each step to ease cognitive load. mapping, and target panels in the mapping component (see Fig. 2). Also, new header buttons can be added to the mapping suggestion list. For example, developers could use actions on these buttons to filter information (Section 5.2). 5
We examine issues of cognitive support of the core PROMPT plugin (before the addition of the interface plugins discussed in Section 5) as an example of questions that arise when developing support for such a cognitively complex task as ontology mapping. PROMPT already addresses many of the cogntive support requirements that we discussed in section 2. However, PROMPT may not address all of these requirements so that users can make use of the features effectively. Meeting the requirements is not enough, we must also understand the usability of the implemented features. 5.1
Although we have not yet carried out formal user studies to understand PROMPT’s usability, we have identified some questions that such usability testing will reveal. For example, when a user selects a candidate mapping, PROMPT highlights the terms involved in the mappings in the source and target display. Thus, the user can see the context of the terms in the mapping. But this feature could potentially introduce new cognitive issues. For example, the selection of the terms in the ontologies is immediate, the ontology trees are expanded directly to the term that needs to be displayed, no animation of this process exists. Does jumping immediately to the term destroy the user’s global context about where they are in the two ontologies? Does it interrupt the user’s work flow? What if the user had used the ontology tree to browse to a particular location, but selecting a suggestion removed the user’s selected focal point?
Another related issue is incremental navigation in PROMPT. Currently, the user can browse the source and target ontologies via a tree control in the mapping component. However, selecting a suggestion immediately switches the tree’s focus. Also, this type of view can be difficult to use when viewing items deep in the hierarchy.
PROMPT loads all its generated mapping operations into a browsable suggestion
list. With large ontologies, this list could be very large. There is currently no support
for sorting, categorizing, or filtering the list. Abrams and colleagues [
The final issue with PROMPT we wish to discuss is browsing the resulting mappings. Unlike Clio and COMA++, which draw lines between matching terms, PROMPT takes a different approach. Firstly, after the user confirms a mapping suggestion, the corresponding terms in both the source and target ontologies get a “mapped” icon associated with them indicating that the terms have already been mapped. Secondly, the occurance of the mapping event is recorded in a mapping ontology that is browsable by the user. Although the icon indicator certainly is less cluttered than the line drawing in Clio and COMA++, there is no explicit way for the user to visualize what the corresponding matched term is. 5.2
In order to address some of the missing requirements in PROMPT, we have developed COGZ—a user-interface plugin for the mapping component. C OGZ attempts to provide user support for reducing the size and complexity of a mapping and to improve user interaction with establishing the term context and improving incremental navigation.
We addressed the complexity and size requirement by adding filters to the list of candidate mappings. There are several types of filters. First, users can filter candidate mappings based on the explanation provided by the algorithm that generated the candidate (see area (5) in Fig. 2). For example, the user can filter the list to inspect only exact term matches first, and then address more complex matches, like synonym or sharedhierarchy matches. There is also a filter that allows users to restrict mappings to classes from certain subtrees in the ontologies. Users can specify multiple subtrees in both the source and the target ontologies. This filter provides a powerful means for the user to address areas of the ontology they are most familiar with.
Finally, to address the context and navigation requirements, we added a
Neighborhood tab to both the source and target ontology components. The neighborhood tab is
synchronized with the browsing of candidate mappings: selecting a mapping displays
the corresponding term’s neighborhood. The neighborhood consists of the immediate
parents and children of the term. The viewer supports incremental navigation by
allowing the user to expand incrementally the neighborhood of any visible node. Also, the
plugin provides six different layouts to allow the user to view the graph from a multitude
of perspectives (see Fig. 5). The visualizations are provided by Jambalaya [
We have discussed the need for cognitive support in ontology mapping tools. We proposed several requirements for satisfying this need, which were based on our own background work and experience. While these requirements are preliminary, we believe they represent a good initial description of the problems faced by users performing mappings. We believe it is very important to refine these requirements by carrying out studies and surveys in the knowledge engineering community. Specifically, we plan to evaluate the effectiveness of PROMPT through user studies and tool usage statistics. We also plan to enhance the visualization plugin in order to further address the requirements that PROMPT does not fullfill.
We also discussed the implementation of a plugin framework for PROMPT. The framework helps address two fundamental issues. Firstly, how can we satisfy the cognitive support requirements in one consistent environment, and secondly, how can we close the gap between mapping algorithm research and mapping users. By supporting user interface extension points in PROMPT, experts and developers in Human Computer Interaction can incorporate their ideas and tools to help decrease the cognitive load on end users of mapping tools. Similarly, the algorithm extension points also help the algorithm researcher. By using these extensions, researchers (or software developers) can easily incorporate their algorithms into PROMPT, allowing the research to be available under one consistent user interface. End users will benefit from having access to the best known algorithms, as well as the best cognitive support tools available.
In addition to developing better cognitive support for mappings, other research
challenges remain. Our decomposition of the mapping process (Fig. 3) may not be general
enough. It does not account fully for comparison algorithms that require an initial set
of mapped terms as input. One can invoke such an algorithm at the iterative step, but
more direct support for specifying the inputs precisely will likely be required. Similarly,
PROMPT assumes a declarative representation of mappings (mainly as instances in an
ontology). We would like to extend it to allow the use of an alignment API (e.g. [
We plan to further enhance the plugin framework by adding more extension points for algorithms and interface components. PROMPT, FOAM and COGZ plugins are available as part of the full installation of Prote´ge´ 3.2beta.5 Instructions for plugin developers and additional information are available on the PROMPT wiki site.6
This work was supported in part by the National Center for Biomedical Ontology, under roadmap-initiative grant U54 HG004028 from the National Institutes of Health. 5 http://protege.stanford.edu/download/download.html 6 http://protege.cim3.net/cgi-bin/wiki.pl?Prompt