=Paper=
{{Paper
|id=Vol-225/paper-3
|storemode=property
|title=Towards Understanding the Needs of Cognitive Support for Ontology Mapping
|pdfUrl=https://ceur-ws.org/Vol-225/paper3.pdf
|volume=Vol-225
|dblpUrl=https://dblp.org/rec/conf/semweb/FalconerNS06
}}
==Towards Understanding the Needs of Cognitive Support for Ontology Mapping==
https://ceur-ws.org/Vol-225/paper3.pdf
Towards understanding the needs of cognitive support
for ontology mapping
Sean M. Falconer1 , Natalya F. Noy2 , and Margaret-Anne Storey1
1
University of Victoria, Victoria BC V8W 2Y2, Canada
{seanf, mstorey}@uvic.ca
2
Stanford University, Stanford, CA 94305, USA
noy@stanford.edu
Abstract. Researchers have developed a large number of ontology-mapping al-
gorithms 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 algo-
rithms 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 devel-
oped a plugin framework that enables developers to assemble a comprehensive
ontology-mapping tool by plugging in various components. We provide a refer-
ence 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 pro-
vide and the user-interface researchers can use the framework to experiment with
various visualization paradigms for ontology mapping (and not worry about im-
plementing 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.
1 Introduction
As ontologies become more commonplace and their number grows, so does their diver-
sity and heterogeneity. Reconciling different ontologies and finding correspondences
between their concepts is likely to be a problem for the foreseeable future. Thus, re-
search 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 [10], and researchers have proposed a standard mapping language
[11]. As the results of the contests show, ontology mapping is far from being a fully
automated task. We believe that in most cases manual intervention will be required to
verify or fine-tune the mappings produced by the 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 [12, 18, 24]).
Perhaps, one of the reasons this issue has not been addressed is the lack of under-
standing of the importance of cognitive support [23]. Cognitive support measures how
well a tool supports a user’s cognitive processes, and it results from the interplay be-
tween the system image and the user’s needs [8]. As Walenstein states, “The first rule of
tool design is to make it useful; making it usable is necessarily second, even though it is
a close second . . . [A tool’s] usefulness is ultimately dependent upon [its] utility relating
to cognition: i.e. to thinking, reasoning, and creating. Assistance to such cognitive work
can be called cognitive support.” [23]
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 qual-
ity 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 devel-
oped a plugin framework that covers many of the sub-tasks of ontology mapping, from
specifying algorithms for initial comparison to executing the mappings. This frame-
work is part of the P ROMPT ontology-management suite [18], itself a Protégé plugin.3
We have developed a reference implementation for each of the steps, including a num-
ber of cognitive aids. Developers can plug in their own components and use plugins
developed by others (including our team) in order to fill in the missing pieces to have a
comprehensive end-user tool.
This paper makes the following contributions:
– We analyzed requirements for cognitive support in ontology mapping (Section 2).
– We developed the P ROMPT plugin architecture for ontology-management that en-
ables 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 P ROMPT plugin architecture that
provides cognitive support for users in the ontology-mapping task (Section 5.2)
2 Requirements for Cognitive Support in Ontology Alignment
The set of end-user tasks in an ontology-mapping tool that we identified and the cor-
responding 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 map-
pings produced by the automatic component and creating the mappings that the auto-
matic algorithm missed. The following is a preliminary list of tasks that must be sup-
ported 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.
Identification of “candidate-heavy” ontology regions: identify visually which sec-
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.
Information about the reasons a mapping was suggested: provide the user with some
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 on-
tology. 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.
Conflict resolution and inconsistency detection: indicate to the user if some of the
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.
Verification of mappings through execution: enable users to “execute” the mappings,
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.
Direct creation and manipulation of the mappings: enable users to add details to the
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 creat-
ing the mapping. The users will also often add mappings that the tool has missed.
Navigation of verified and manually specified mappings: One result of the user in-
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 Related Work
Cognitive support is about introducing artifacts in order to improve cognitive systems
[23]. As Norman states [17], “The power of the unaided mind is highly overrated. With-
out external aids, memory, thought, and reasoning are all constrained.” Although cog-
nitive support can be addressed in a variety of ways, one popular approach is through
information visualization. Information visualization leverages innate human abilities
to perform spatial reasoning and make sense of relatively complex data using some
form of graphical representation language [9]. Information visualization is often used
to construct an advanced user interface to aid humans understand and navigate complex
information spaces. In software engineering, this approach has been applied specifically
to applications such as source code evolution [22] and algorithm animation [2].
Knowledge-engineering tools often use visualization to help users navigate ontolo-
gies. 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 [21]). One
of the goals of providing these various layouts is to help users view the same knowl-
edge in different formats and potentially to validate and invalidate their mental models.
As Richer and Clancy state, “. . . providing multiple views of the same knowledge or
behavior can help a user understand a complex system.” [19]
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 Ontology-Mapping Tools and Their User Interfaces
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 [7], MoA Shell [13], Chimaera [16], and the OWL Ontology Aligner [25] all
Fig. 1: Mapping two schemas in COMA++.
fall into one of these two categories. Some of these tools, such as FOAM, also support
interactive modes where a user can verify matches as they are computed.
Clio [12] and COMA++ [5] are examples of tools that support graphical user in-
terfaces. The number of visual paradigms that the tools use to display the mappings is
quite limited, however. Clio was developed by IBM for generating mappings between
relational and XML schemas. Clio can infer correspondences in the source and target
schemas and it also allows users to draw correspondences between parts of the schemas.
Once the correspondences have been generated and verified, Clio generates queries to
drive the translation from the source schema to the target schema. COMA++ works sim-
ilarly, although it also supports ontology mapping. COMA++ automatically generates
mappings between the source and target schemas, and draws lines between matching
terms. Users can also define their own term matches (see Fig. 1). Both tools draw map-
pings between the source and target schemas, which can be difficult to work with when
there are a lot of mappings or the distances between mapped terms is large.
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 ver-
ification 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 align-
ment. AlViz [15], a plugin for Protégé, applies multiple-views via a cluster graph visu-
alization along with synchronized navigation within standard tree controls. Generally,
there is a dearth of visual paradigms for ontology mapping. Until we have such end-user
tools with good cognitive support, many of the mapping algorithms that researchers de-
velop, are unlikely to leave the labs. Hence, we have developed a plugin framework
that treats an ontology-mapping process as a standard sequence of steps (from initial
comparison of ontologies to executing mappings) and enables developers to substitute
any of the steps with their own tools.
3.2 Component Frameworks for Ontology Mapping
Several researchers have addressed the issue of deomposing an ontology-mapping pro-
cess into a sequence of subtasks–a step necessary for introducing a plugin framework
for ontology mapping [6, 14]. These subtasks include pre-processing of the source on-
tology, configuration of the mapping algorithm, analysis of the results, and iterative
invocation of the mapping algorithm. In a sense, implementing a plugin framework for
ontology mapping starts with identification of this set of tasks. However, in order to
enable developers to substitute implementation of any of the tasks with their own, we
also must define interfaces, and must provide extension points in the tools.
The work that is closest to our plugin framework for mapping is the IBM XML
Mapping technology [20]. In this work, the authors developed a plugin framework for
mapping data sources such as relational database schemas, UML models, and XML
files to XML Schema. Their architecture distinguishes four core components, each of
which has extension points for plugins: (1) user interface, with plugins for viewing dif-
ferent types of models; (2) mapping population, allowing developers to plugin different
mapping algorithms; (3) mapping representation, enabling different forms of represent-
ing the mappings; and (4) code generation, providing runtime engines for executing the
mappings. We take a similar approach in our work. However, we focus more on cog-
nitive support for mapping, with user interface being a very prominent component. In
addition, our work is applied to ontologies and not only to XML schemas.
4 P ROMPT Plugin Architecture
P ROMPT is a Protégé plugin that supports various tasks for managing multiple on-
tologies, including ontology mapping [18]. In its original form, P ROMPT starts the
ontology-mapping process by performing initial comparison of the source and target
ontologies to be mapped, mainly based on lexical comparison of class names. After the
initial comparison, P ROMPT presents the user with a set of candidate mappings. A user
can examine the mappings, create new mappings, and save the correct ones. As the user
identifies a mapping as correct, P ROMPT performs structural analysis of the neighbor-
hood of the mapped concepts, suggesting new mappings based on the graph structure.
P ROMPT saves the mappings as instances in the mapping ontology [3]. After the user
defines the mappings, he can run a mapping interpreter [4] to transform instances from
the source to the target ontology based on the mapping.
When verifying candidate mappings, users can access the source and target ontolo-
gies in the Protégé interface; when a user selects a mapping to examine, the corre-
sponding 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 P ROMPT 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 com-
ponents, 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
Fig. 2: The P ROMPT user interface and the extension points in P ROMPT’s mapping component.
The left column shows the source ontology; the middle column displays the mappings suggested
by P ROMPT and explanations of these suggestions. The right column displays the target ontol-
ogy. There are tab extensions points for the source (1), mapping (2), and target (3) components.
Area (4) shows the suggestion header button extension point. Algorithms can provide their own
explanations for each candidate mapping (5).
execute. More specifically, we view the ontology-mapping process as a sequence of the
following steps (Fig. 3):
Perform initial comparison of the ontologies: an algorithm compares two ontologies
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 inter-
active 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 P ROMPT screen for configuring an algorithm for initial compar-
ison. The user has chosen to run a FOAM algorithm at this stage. The integration of
FOAM and P ROMPT is available as part of P ROMPT 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 P ROMPT 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.
Fig. 4: Selecting an algorithm in P ROMPT. The area marked (1) shows the options in P ROMPT,
here we have selected to map two ontologies. The area marked (2) displays the algorithm plugins
available, here we have selected our custom built FOAM plugin. Finally, area (3) shows the
algorithm configuration panel supplied by the FOAM plugin.
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 Cognitive Support in P ROMPT
We examine issues of cognitive support of the core P ROMPT plugin (before the addi-
tion 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 map-
ping. P ROMPT already addresses many of the cogntive support requirements that we
discussed in section 2. However, P ROMPT 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 Potential Problems in a Mapping User Interface
Although we have not yet carried out formal user studies to understand P ROMPT’s us-
ability, we have identified some questions that such usability testing will reveal. For
example, when a user selects a candidate mapping, P ROMPT highlights the terms in-
volved 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 immedi-
ate, 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 P ROMPT. 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.
P ROMPT 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 [1] found that web
browser users will not put more than 35 items in their favorite’s list before resorting
to categorizing links within hierarchies or stopping their use of favorites all together.
Similar issues may need to be addressed in P ROMPT. For example, what will users do
when presented with a list of a thousand or even a hundred suggestions?
The final issue with P ROMPT we wish to discuss is browsing the resulting mappings.
Unlike Clio and COMA++, which draw lines between matching terms, P ROMPT takes
a different approach. Firstly, after the user confirms a mapping suggestion, the corre-
sponding 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 C OG Z Interface Plugin for P ROMPT
In order to address some of the missing requirements in P ROMPT, we have developed
C OG Z—a user-interface plugin for the mapping component. C OG Z 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 candi-
date (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 shared-
hierarchy 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 Neighbor-
hood 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 allow-
ing 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 [21].
Fig. 5: P ROMPT’s mapping component with the interface plugin. Areas (1) and (2) show the
neighborhoods of the source and target terms of the currently selected suggestion. Area (3) shows
the location of the filter button. The neighborhood display makes it clear that the two classes have
different meaning in the two ontologies even though their names are the same (Research).
6 Discussion and Future Work
We have discussed the need for cognitive support in ontology mapping tools. We pro-
posed several requirements for satisfying this need, which were based on our own back-
ground 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 P ROMPT through user studies and tool usage statistics. We
also plan to enhance the visualization plugin in order to further address the requirements
that P ROMPT does not fullfill.
We also discussed the implementation of a plugin framework for P ROMPT. The
framework helps address two fundamental issues. Firstly, how can we satisfy the cog-
nitive 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 P ROMPT, 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 al-
gorithm researcher. By using these extensions, researchers (or software developers) can
easily incorporate their algorithms into P ROMPT, 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 chal-
lenges 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,
P ROMPT 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. [11])
and in-memory access to mappings. We envision that as developers begin to use the
plugin framework, we will need to introduce other extension points of this type.
We plan to further enhance the plugin framework by adding more extension points
for algorithms and interface components. P ROMPT, FOAM and C OG Z plugins are avail-
able as part of the full installation of Protégé 3.2beta.5 Instructions for plugin developers
and additional information are available on the P ROMPT wiki site.6
Acknowledgements
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
References
1. D. Abrams, R. Baecker, and M. H. Chignell. Information archiving with bookmarks: Per-
sonal web space construction and organization. In Human Factors in Computing Systems
(CHI 98), pages 41–48. ACM Press, 1998.
2. M. D. Byrne, R. Catrambone, and J. T. Stasko. Evaluating animations as student aids in
learning computer algorithms. Computers & Education, 33(4):253–278, 1999.
3. M. Crubézy and M. A. Musen. Ontologies in support of problem solving. In S. Staab and
R. Studer, editors, Handbook on Ontologies, pages 321–342. Sringer, 2003.
4. M. Crubézy, Z. Pincus, and M. Musen. Mediating knowledge between application compo-
nents. In Workshop on Semantic Integration at ISWC-2003, Sanibel Island, FL, 2003.
5. H.-H. Do. Schema Matching and Mapping-based Data Integration. PhD thesis, Department
of Computer Science, Universitt Leipzig, 2006.
6. M. Ehrig and Y. Sure. Ontology mapping - an integrated approach. In 1st European Semantic
Web Symposium, Heraklion, Greece, 2004. Springer, LNCS.
7. M. Ehrig and Y. Sure. FOAM–framework for ontology alignment and mapping; results of
the ontology alignment initiative. In Proceedings of the Workshop on Integrating Ontologies,
volume 156, pages 72–76, October 2005.
8. N. Ernst. Towards cognitive support in knowledge engineering: An adoption-centred cus-
tomization framework for visual interfaces. Master’s thesis, University of Victoria, 2004.
9. N. A. Ernst, M.-A. Storey, and P. Allen. Cognitive support for ontology modeling. Interna-
tional Journal of Human-Computer Studies, 62(5):553–577, 2005.
10. J. Euzenat. Eon ontology alignment contest. http://oaei.inrialpes.fr/2004/Contest/.
11. J. Euzenat. An api for ontology alignment. Technical report, 2006.
12. M. A. Hernandez, R. J. Miller, L. M. Haas, L. Yan, C. T. H. Ho, and X. Tian. Clio: A
semi-automatic tool for schema mapping. In SIGMOD Record, 2001.
13. E. . T. R. Institute. Moa shell. http://mknows.etri.re.kr/moa/docs/moashell.html, 2003.
14. Y. Kalfoglou and M. Schorlemmer. IF-Map: an ontology mapping method based on infor-
mation flow theory. Journal on Data Semantics, 1(1):98–127, Oct. 2003.
15. M. Lanzenberger and J. Sampson. Alviz - a tool for visual ontology alignment. In IV ’06:
Proceedings of the conference on Information Visualization, pages 430–440, Washington,
DC, USA, 2006. IEEE Computer Society.
16. D. L. McGuinness, R. Fikes, J. Rice, and S. Wilder. The chimaera ontology environment.
In Proceedings of the Seventeenth National Conference on Artificial Intelligence and Twelfth
Conference on Innovative Applications of Artificial Intelligence, pages 1123–1124. AAAI
Press / The MIT Press, 2000.
17. D. A. Norman. Things That Make Us Smart: Defending Human Attributes in the Age of the
Machine. Addison-Wesley, 1993.
18. N. F. Noy and M. A. Musen. The PROMPT suite: Interactive tools for ontology merging and
mapping. International Journal of Human-Computer Studies, 59(6):983–1024, 2003.
19. M. Richer and W. J. Clancy. Guidon-watch: A graphic interface for viewing a knowledge-
based system. IEEE Computer Graphics and Applications, 5(11):51–64, 1985.
20. M. Roth, M. Hernandez, P. Coulthard, L. Yan, L. Popa, and C. Salter. Xml mapping tech-
nology: Making connections in an xml-centric world. IBM Systems Journal, 45(2):389–409,
2006.
21. M.-A. Storey, N. F. Noy, M. Musen, C. Best, R. Fergerson, and N. Ernst. Jambalaya: an inter-
active environment for exploring ontologies. In IUI ’02: Proceedings of the 7th international
conference on Intelligent user interfaces, pages 239–239, New York, NY, USA, 2002.
22. L. Voinea, A. Telea, and J. J. van Wijk. Cvsscan: visualization of code evolution. In SoftVis
’05: Proceedings of the 2005 ACM symposium on Software visualization, pages 47–56, New
York, NY, USA, 2005. ACM Press.
23. A. Walenstein. Cognitive support in software engineering tools: A distributed cognition
framework. PhD thesis, Simon Fraser University, Vancouver, BC, 2002.
24. D. Wenke, S. Atanassov, D. Manov, M. Maier, and W. Sperling. D4.5.1 report on ontology
mediation as service component. Technical report, EU-IST SEKT Deliverable, 2003.
25. A. V. Zhdanova. Owl ontology aligner. http://align.deri.org:8080/deri/align.jsp.