The Semantic Web is rapidly becoming a defacto distributed repository for semantically represented data, thus leveraging on the added on value of the network effect. Various ontology mapping techniques and tools have been devised to facilitate the bridging and integration of distributed data repositories. Nevertheless, ontology mapping can benefit from human supervision to increase accuracy of results. The spread of Web 2.0 approaches demonstrate the possibility of using collaborative techniques for reaching consensus. While a number of prototypes for collaborative ontology construction are being developed, collaborative ontology mapping is not yet well investigated. In this paper, we describe a prototype that combines off-the-shelf ontology mapping tools with social software techniques to enable users to collaborate on mapping ontologies.
The transformation of the Web from a mere collection of documents to a queryable
Knowledge Base (KB) is one of the most prominent targets of Semantic Web
(SW) [
Defining an ontology for representing data semantics is usually a costly and
time consuming task. Furthermore, knowledge evolves over time which adds to
maintenance cost. That is why more and more often successful proposals for
information sharing involve user’s feedback exploiting a network effect. If an
ontology is meant to reflect the views of a specific community and support their
knowledge sharing tasks, then the community itself should be empowered to
express, formalise, share and mantain a set of ontologies for supporting such
tasks [
The rise of social Web 2.0 applications has demonstrated how general Web
users can actively contribute and share all sorts of data and information, such as
images, videos, bookmarks, opinions, diaries and experiences. Adopting a similar
approach on the SW means supporting users to dynamically and collaboratively
build ontologies, add semantics to data, discuss and share views and suggestions,
etc. Good and colleagues [
The need to make explicit and publish the semantics of the data is becoming
increasingly central since more information systems are becoming largely
decoupled and separately managed. To this end, the vision of the SW is moving
towards a scenario where the task of creating and mantaining ontologies, that
formalise data semantics, is going to be handed to the community that actually
uses them [
Our work taps on the intersection of different but overlapping areas in ontology engineering: collaborative construction and management using social networking tools, data web and sharing of ontology fragments. We briefly highlight the main contenders in these areas and elaborate on their relationship with our work.
Historically speaking, investigations into enhancing user knowledge through
collaboration and sharing goes back to the early nineties [
The rise of Web 2.0 approaches has then demonstrated the effectiveness and
popularity of collaborative knowledge construction and sharing environments
that adopted lighter version of ontologies, where the emphasis is put on the
easiness of sharing knowledge rather than creating or adopting static formal
ontologies [
In the OntoMediate[
The implemented prototype is a Web application developed with J2EE and AJAX technologies. The system manages OWL ontologies that are parsed using the Jena API1. The system has been designed to be extended via its APIs and is composed of three main subsystems: – Ontologies and datasets manager; – Ontology alignment environment; – Social interaction environment.
This part of the system allows users to register (as well as unregister) the datasets they intend to share with the community and the ontologies that describe their data vocabulary. The ontologies that are loaded onto the system, need to be aligned with one or more shared ontologies in order to enable querying of the published data by the community. The system currently supports different storage types for the ontologies and/or datasets: – URL: only the URL is stored and the ontology is accessed (read only) remotely; – Cached file: the ontology file is uploaded to the system and stored in a file server; – Jena RDBMS : the ontology file is uploaded to the system and stored in a relational database using the Jena database back-end; – SPARQL endpoint : the document is remotely accessed using the SPARQL protocol2.
Once an ontology is registered with the system, the owner (or everyone if the ontology has been shared within the community) can browse it by using a flexible frame-like interface. The ontology browser displays the hierarchy of concepts, as well as detailed information for the focused concept (selected concept). The detailed information includes: labels, superconcepts, subconcepts, equivalent concepts, concept description (from the rdfs:comment annotations), properties and their constraints. 1 http://jena.sourceforge.net 2 http://www.w3.org/TR/rdf-sparql-protocol/
The full automation of ontology alignment is not an easy task [
Our system provides an API for automated ontology alignment tools to be
plugged in and also maintains data structures to store parameters needed by
a particular tool to execute (e.g. threshold values or available tool options).
The API allows for easy integration of new alignment tools, when they become
available, by means of wrappers - some tools have been already integrated with
our system (e.g. CROSI mapping system [
Once the automated mapping has been executed, the results are displayed in a proper interface for reviewing and for searching further alignments. The ontology alignment interface is split into two main panels, the left panel for the source ontology and the right panel for the target ontology, whereas the bottom space is used for summarising the mappings found for the focused source concept. The interface has two view modalities: Hierarchical and Detailed.
In the Hierarchical view the two taxonomies are centered on the source concepts that have been mapped to a target concept, both of which are highlighted. The user can browse both taxonomies and create new mappings by dragging a source concept and dropping it into a destination concept. When the user focusses on a mapping, he/she can switch to a detailed view and the description of the source and target concept are shown side by side.
In the Detailed view, the user can map the properties using the same drag
& drop facility used for mapping the concepts. The users can also explicitly
reject some automatically proposed mappings. This choice will be recorded by
the system and will be used to filter future mappings towards this target concept,
thus increase future ontology alignment precision. Alternative interface designs
for ontology mapping, such as the one presented in [
This functionality allows users of a community that deal with similar data and therefore have a mutual interest to maintain good quality alignments - to socially interact with each other. The aim of the social interaction is to exploit community feedback in order to enhance the overall quality of the ontology alignment and achieve agreement on semantics of concepts by means of community acceptance. This subsystem displays to the user three views: Ontology view;
The Ontology view (see Figure 1 top-left corner) displays an enhanced taxonomy browser for the selected shared ontology. The enhancements concern the user activities affecting the shared concepts, visualising additional information (e.g. number of incoming mapping per concept are reported in brackets like the number of post exchanged in the forum discussing such mappings). Moreover, the interface allows to inspect the set of labels used for equivalent concepts (i.e. the ones provided with the alignments) in local ontologies (see the Additional labels text field in Figure 1). The user or administrator can edit such labels and add them to the shared concept to enrich the concept description with users’ contributions. The new mapping, and the edited/added labels, will be logged in a database to be reused later to improve the recall of future ontology alignment tasks (section 4.2).
When the user selects a concept that has some user mappings associated with it, he/she can switch to the Mappings view that displays information about the local mappings for the focused concept. The user can then inspect a summarised description (i.e. subconcepts, superconcepts, properties etc.) of the local concepts and decide if they are relevant to the focused target concept or initiate a discussion thread in order to change them. The change proposal is composed of a thread post, that describes in natural language the content of the proposal, and a formal description of the operation to discuss. The proposed change can affect a number of alignments and may lead, if the proposal is accepted, to the relocation of such alignments to a different target concept. If the target concept refferenced in the change operation is not yet present in the ontology, a new one will be created within the hierarchy in accordance with the input given by the users in the forum. The possibility to create new concepts to host user alignments provides a way to reshape (even if only by additions) the target ontology in function of the (meta)data provided by users.
The system provides a forum for the discussion of the users’ proposals (see Figure 1 bottom-right corner). Every time a user proposes a change using the mappings view, a new thread is created in the forum and other users are free to debate the proposal, reply the proposal with a new one or simply agree or disagree with it. The user’s vote is computed for update the proposal statistics (i.e. number of votes, percentage of approvals and disapproval) that is promptly displayed along the proposal.
The new action item associated with a target concept is notified to every interested user by means of RSS feeds whose the interested users can subscribe to. Once a proposal has reached a critical mass (e.g. when the majority of users affected by the change have expressed their opinion) it will be endorsed, or submitted to the administrator in order to judge it and reach a final decision. 4
In order to better explain our approach and show how users’ feedback can be
used in order to improve the ontology matching task, we report on a small
example in the chemical domain and the findings of a working experiment. In this
example, two users want to share information on hazardous chemical compounds.
They each create an ontology that reflect the nature and structure of their
data sources (in our example the users deal with data about Landmines and
Hazardous Components, see Table 1).
This tiny community is provided with a shared domain ontology where a set of
entities and relationships relevant to the chemical domain is defined (see Table
1). The two users need to align their local ontologies to the shared one in order
to exchange information and integrate their data. To fulfill this task, the users
use off the shelf automatic tools with the Ontology Alignment environment
(see section 3.2). The automatic ontology alignment tools provide an initial set of
alignments that the users can revise, using the system interface explicitly stating
the correct alignments and the incorrect ones. With the same interface, the users
can then browse the two ontologies and provide manual alignments if required.
At the moment only equivalence relation is supported for expressing alignments
but the adoption of more expressive primitives is under study. In this scenario
the local ontologies act as ”contexts” of their respective data sources (following
the nomenclature used by Bouquet et al. [
The alignments provided by the alignment task will be reused to improve automatic future alignments toward the same target ontology. Lexical labels from users’ ontologies can be adopted by the shared model as rdfs:label that can be considered in future automatic alignment tasks in an attempt to improve performance and accuracy of automatic mapping tools. Within the chosen domain (i.e. hazardous chemical compounds, but the assumption holds in other domains), different labels can represent the same concept (e.g. the explosive HMX is also known as Octogen or Cyclotetramethylene-tetranitramine, see Table 2 for a summary of the labels logged from the alignment activity). The working assumption is that, gathering all the labels related to a concept from local representations, and learning which alignments must be avoided in the future (e.g. rejected by users), can help to increase the performance of automated alignments. As an example, assuming the two users of this example have subsequently aligned their ontologies, the labels collected from the first alignment (see Table 2) can be used for improving the performances of the second. Manual mappings discovered by the first user (e.g. Black Powder ≡ Gun Powder or Nitromethane ≡ Nitrocarbol ) can in fact helping the discovery of target concepts that would be missed otherwise by automatic tools. Such additional user’s labels can in fact bring, if integrated in the shared model, to an increase in automated tools precision and recall for subsequent alignments. 4.3
Browsing the definition of the shared ontology, the users can revise each other’s alignments to check that the definition of the local concepts is relevant to the targeted shared concept. The self curation of the shared alignments is an important premise of the approach; users that are interested in integrating their data or in querying the integrated knowledge base have a main concern in browsing such alignments, providing feedback and starting corrective operations whenever needed.
Automated ontology alignment tools usually fail to catch the difference among lexically similar concepts such as Nitromethane and Nitroethane. Despite their lexical and chemical similarity, it is very important to distinguish the two (the first can be used as an explosive while the second can not). For this reason, once a user has found the incorrect alignment (i.e. Nitromethane ≡ Nitroethane) inspecting the local concept definition, he/she can select the faulty alignment and initiate a change process. Along with the incorrect mapping, the user can provide the URI of the suggested correct target concept (i.e. Nitrocarbol, a synonym of Nitromethane) and issue a change proposal. If no suitable concept can be found in the target ontology the user can suggest the creation of a new one providing its location in the targeted hierarchy. The proposal will be posted in the forum dedicated to the maintenance of the shared concept alignment asset. The community can be alerted of the change proposal by RSS feed subscription (every target concept has a feed where new posts are published, and every interested user can register to the feed) and inspect the change proposal, discuss it on the forum, replying to the post or just expressing dis/agreement with the content of such proposal. Once the two ontologies have been aligned with the shared model, they can be exploited for assuring a meaning preserving information exchange between the components of the community. The discussion fostered in the social environment and the constant supervision by the users upon the ontology alignments help in mantaining agreement and awareness on terms’ semantics within the community. 5
Collaborative ontology mapping has a great potential in enhancing performance and in sharing results of automatic mapping tools. The system presented in this paper supports users in their ontology mapping activities and logs their feedback to further enhance the output of automated ontology mapping tools. Moreover it provides social features for community driven mapping revisioning and limited support for shared ontology evolution.
Ontology mapping is inherently difficult, and can be influenced by various
issues. For example, some mappings can be user or context dependent, in
which case a mapping that has been approved by some users may not
necessarily suit others. Mapping popularity can be used to weight each ontology
alignment. The degree of popularity of a specific alignment can be taken into
account when displaying alignment suggestions to the user. Storing user profiles
to personalise mappings has been proposed elsewhere [
When reusing mapping results, it is important to prevent error propagation. It is important to build a user interface in such a way to discourage blind reuse of mappings. OntoMediate allows the community to flag, discuss, and democratically change incorrect mappings, but this is of course dependent on users spotting erroneous mappings. If a mapping is reverted, it will be important to readjust its popularity accordingly.
In addition, mappings that receive repeated change proposals or become subject to long and intense discussions may be regarded as controversial or debatable mappings. Such mappings may also need to be handled with care when used or reused suggesting administrators to create appropriate ontological description to better characterize those particular local concepts.
OntoMediate uses off the shelf automatic ontology mapping tools, and hence
the complexity of its mappings are largely based on those of the mapping tools.
The current implementation of OntoMediate allows users to manually map
entities expressing simple one to one mapping. More complex mappings, such as
mapping a union of classes or linking properties by means of transforming functions,
is not currently supported. However, it has been reported that when engineering
ontologies collaboratively, complex OWL constructs are often not required [
Ontology mapping is a not an easy task, and hence users will not expected to link their ontologies without a clear added value. The ultimate goal of OntoMediate is to facilitate distributed querying and integration of knowledge bases in a community. Therefore, in addition to displaying concept mappings, it will be important to also display some information about the knowledge that each mapped ontology brings to the table. Showing what data a specific mapping or a whole ontology is bringing to the community might encourage others to (a) see the general value of this mapping and hence offer their expertise and help to map the new ontology correctly, and (b) map their ontologies to others if they have not already done so (e.g. to link their data to the new repository).
The approach we focused on in OntoMediate is based on a small to medium
size community, sharing interests and goals that can benefit from integrating
their data. In OntoMediate, it is presumed that an overall administrator can
act as the ultimate curator of the system. For such an approach to scale up to
the Web as a whole, the wisdom of the community will have to be the final
ruler. Wikipedia is a fine example of how this can work, and the Linked Data
initiative is a first step to creating a wide network of linked semantic data [
This paper presented a prototype for supporting ontology mapping with community interactions, where users can collaborate on aligning their ontologies, and manually-driven alignments can be stored and reused later. Our initial experiment showed good potential of increasing both precision and recall in ontology mapping when reusing past mapping results. Next, we plan to run much larger experiments to further test the validity of the approach, and the usability of the services and features that it provides. We have lately implemented services that exploits the managed alignments for translating queries and data. In the near future we will also implement services to allow users to submit formula to mediate between concepts or data that might not be directly mappable (e.g. when the concepts are culture-dependent, or when data property values are function of different other values). Additionally, we will next focus on building the capability to allow users to perceive, and query, the integrated KBs, thus increasing added value. The ontology alignments and the social network will be exploited to focus the search task. We will make the system available to the public online in the next few weeks. 7
This work was partially funded by a grant awarded to General Dynamics UK Ltd. and the University of Southampton as part of the Data and Information Fusion Defence Technology Centre (DIF DTC) initiative. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the UK Ministry of Defence, or the UK Government.