Reusing ontologies can signi cantly accelerate the development of new ontologies, and therefore interoperability. However, reuse of ontologies calls for e cient means to identify reusable parts within and across existing ontologies. This paper presents a novel, graphical user interface to explore semantic overlaps between ontologies in order to identify parts for knowledge reuse. Existing tools typically only compare pairs of ontologies. Our approach allows for exploring concept mapping links across arbitrarily many ontologies, represented as so-called hyperontology graphs. To cope with the inherent complexity of such graphs, we allow for a variety of information hiding techniques tailored to speci c exploration tasks. By manipulating the hyperontology graph interactively the user can re ne the concept mapping network to his needs. Finally, we show how the resulting graph can be used to automatically synthesise a new ontology by extracting the corresponding modules and merging them appropriately.
Creating a high-quality ontology from scratch is a time consuming endeavour. Reusing existing ontologies or fragments of them is the obvious thing to do here. In most cases, the envisioned new ontology overlaps with several existing ontologies in various aspects and degrees: they may share instances, common or similar class or property names, or indeed axioms. The only `reuse' construct supported by the OWL languages is to globally import the whole of an ontology. Of course, this is rather undesirable as it is too coarse, i.e. it (often) imports too much.
The general subject of our work are two problems of ontology reuse: rstly, the matching process, i.e. how to identify the overlapping fragments of ontologies, and secondly, the merging process, i.e. how to merge the overlaps of interest into a new ontology.
Both problems are central issues in the research area of ontology matching
[
The focus of this paper is on the matching process, whereas the second
aspect, the merging process, will only brie y be sketched from the user interaction
perspective. Theoretical details as well as implementation descriptions about
the extraction and merge process are discussed in our related paper [
As said above, reusing existing ontologies to create new ontologies is a
major goal. Creating a new ontology typically starts with a set of relevant terms
(words) denoting ontological entities (classes, instances, properties, etc.) of our
interest. The intellectually more demanding e ort lies in specifying the right
constraints for these entities, i.e., de ning a concept hierarchy, domain and range for
properties, stating axioms, etc. Reusing this kind of knowledge is therefore the
main goal. So the basic idea is a systems that takes as initial input only words
and returns all relevant knowledge it can nd from the ontology repository. This
relevant knowledge should comprise all axioms (speci ed in other ontologies)
formally determining the meaning of these words. Finding the right reusable parts
is an interactive process, though, only initialized by these input words that serve
as seeds for knowledge aggregation. Very often, however, identical concepts are
expressed in di erent words in di erent ontologies. Therefore, we have to take
synonymy into account. Matching class and property names across ontologies
is thus our initial step towards ontology reuse. A survey of ontology matching
techniques and system evaluations can be found in [
For our purposes, we take advantage of existing systems, in particular
Falcon [
Before the user starts interacting with the system, the repository is
preprocessed by a matcher system (Falcon in our case): each ontology is matched
against each other in the repository. This results in a list of synonyms for each
3 Ontology matching and alignment based on statistical methods is a relatively
developed eld, with yearly competitions since 2004 comparing the various strengths and
weaknesses of existing algorithms. See http://oaei.ontologymatching.org/2009/
4 Note that modular ontology languages such as DDLs and E-connections take a more
complex approach towards cross ontology relationships [
From the list of synonyms belonging to pairs of ontologies we compute sets of synonyms (synsets for short) that belong to sets of ontologies: for instance, if Falcon determines the word transporter from the Transport ontology as a synonym for the word carrier in the Logistics ontology as well as the word vehicle in the Traffic ontology, then ftransporter; carrier; vehicleg is a synset for the ontologies fTransport; Logistics; Trafficg. Once all synsets of the repository are calculated, the ontology developer can match her initial words (used as seeds for the envisioned ontology) against these synsets. It should be mentioned that this matching process is based on regular expressions|no ontology matcher is involved here. If for instance one of the initial words is vehicle, then the system would nd it in the synset ftransporter; carrier; vehicleg and return the ontologies fTransport, Logistics, Trafficg as recommended candidates for ontology reuse in the subsequent steps of ontology development.
Eventually, the system will nd all ontologies related (via the precompiled synsets) to a given set of initial words. The ontology developer may then further restrict or extend the set of ontologies that should be partially reused later on. A graph based presentation of the remaining ontologies and synsets allows the developer to select those elements that should be included or excluded in the following knowledge reuse process. 2
In general, ontology matching can match various constructs of the ontology
language and the outcome of the matching can be various kinds of relations between
these constructs attached with a con dence value [
f(airport; port); (cargo; freight); (passenger; passenger); : : :g
We distinguish two phases of the matching process: rst, a matching tool computes synonyms, and subsequently the developer manually deletes mismatches and adds synonyms not detected by the matcher. We shall call the rst phase the automated matching phase and the latter the manual matching phase (or also the matching revision phase). The former is moreover a preprocessing phase since it is performed before the developer starts searching for ontologies to be reused.
Semantic matching is a non-trivial process, so we can never totally rely on the results obtained from automated matching. Syntactic matching leads to results like (airport; port), which is at least an arguable identi cation. Lexical matchings like lookups in Thesauri (e.g. WordNet6) tend to yield more convincing results like (cargo; freight). Due to this limited competence of automated matching systems, an e cient support for matching revision is desirable to get the right synonyms.
Essentially, our approach for manual matching revision is to visualise the relevant outcome of the automated matching process as a graph and let the developer (visually) manipulate this graph until it represents the desired synonyms between class names of di erent ontologies.
Our central data structure representing a matching of several ontologies is a
special kind of graph, called OCS-graph or visual hyperontology graph.7 It has
(1) two type of nodes: C-nodes representing classes and O-nodes representing
ontologies, and (2) two types of edges: CC-edges between C-nodes representing
synonymy and OC-edges between O-nodes and C-nodes saying that the class
is part of the ontology. Note that an OCS-graph may contain several nodes with
the same label. In case of O-nodes it can happen that di erent ontologies are
labelled by their respective developers with the same name. More importantly
for us, though, duplicates of C-nodes indicate possible homonymy: the class
name point may stand for two entirely di erent concepts, a geometric object,
or a unit of counting in scoring a game. Revising a matching in the graph
representation thus means deletion of any kind of nodes or edges, or adding new
CC-edges (compare [
The main challenge in the graph presentation, however, is to present to the user only the relevant fragment of the OCS-graph, because even for a small set of ontologies the graph soon becomes very complex so that the user easily gets lost in all its crossing links and cluttered nodes.
One obvious way of complexity reduction in a graph is hiding and revealing nodes together with their in- and outgoing links. We will not talk much about this feature; the basic idea follows the scheme \hide all nodes satisfying property
7 These graphs are a `visual' variant of the corresponding `textual' hyperontology
speci cations which codify the formal structuring of the theory represented by such a
graph. The relationship between the two is described in more detail in [
P ", where P could be, e.g.: \being connected to node C", etc. There is a huge
number of possible lter criteria with various areas of applicability (see e.g. [
Another common way to reduce complexity e ciently is to collapse connected parts of a graph into single nodes. We consider this technique as one of the most promising for our purpose. Fig. 1 shows schematically how this works in principle.
The only types of subgraphs we want to collapse are syncomponents and C-clones. A syncomponent is a maximally CC-edges-connected subgraph that contains only C-nodes. The set of C-nodes extracted from a syncomponent represents a set of synonym class names|we call it a synset. A C-clone is a maximally connected subgraph of a syncomponent whose C-nodes all have identical labels.8
There are two basic types of visually presenting a graph collapse: reduce to a set of labels (this is depicted in Fig. 1) or to inner graphs (as depicted in Fig. 2). Collapsing to a set of labels reduces more complexity than collapsing to an inner graph: in the latter case, the edges from the outside nodes are reduced whereas in the former case also the edges of the subgraph vanish. Finally, it should be noted that all complexity reduction operations (i.e. hiding and collapsing ) can be performed without any loss of information, i.e., there always exist the corresponding inverse operations of reveal and expand. 8 Note that there can be several C-clones within one syncomponent.
Graphical Interaction on the Hyperontology Graph So far we have described in general how we represent a multi ontology matching by a graph and how such a matching can be manually analysed and modi ed by a set of graph manipulation operations. In this section, we want to illustrate this process by an example.
Let us assume our developer wants to develop an ontology for transportation by reusing knowledge from a repository that contains, among other, several presumably related ontologies like Logistics, Traffic, Public transport, etc. In order to retrieve this knowledge, she starts entering the following initial class names for concepts: passenger, freight, vehicle, line, and route. car goods load cargo airline line route
The system displays the graph as shown in Fig. 3 where all syncomponents are collapsed to sets of labels. Here, and in all following gures, the ellipses represent C-nodes (e.g. freight, passenger, line, etc.). Those ellipses grouped in a big yellow rectangle represent a synset (e.g. freight and vehicle)9 whereas a small blue rectangle with a single name in it represents an ontology. There are only arrows from O-nodes to synset boxes or sole C-nodes, meaning that the corresponding classes are contained in the linked ontologies (e.g. the class freight is part of the warehouse and the ship transport ontology). In order to reduce complexity, only those synset boxes are presented that contain synonyms of the class names initially entered by the developer. In our example, we have the above mentioned ve initial class names passenger, vehicle, line, and route. These are classi ed (by simple syntactic matching) into three synsets: the left most contains freight and vehicle among others, the right most contains line and route among others, and the third in the middle is one that contains passenger as the only class name. The condensed graph shows all relevant synsets for a given list of class names together with their contexts, i.e., the ontologies where they occur. 9 C-nodes outside of a rectangle do not have synonyms (e.g. passenger). warehouse cargo
car goods load
As mentioned before, the synsets automatically found by a matcher are often unsatisfying. This is also the case for vehicle and freight in our example: in contrast to the matcher, we would not consider these two words as synonyms for the same concept. To see where this mismatch stems from, we can expand our condensed view of our graph. Fig. 4 shows the expansion of that synset. Arrows between C-nodes in this synset represent the synonymy relation computed by the matcher. Obviously, this relationship is not an equivalence relation, in particular it is not transitive. Otherwise, there should be, for instance, a link from cargo to vehicle, because these C-nodes are connected via car.
Yet, by default, we tacitly assume that the synonymy relation computed by the matcher induces an equivalence relation (i.e., that it's transitive and symmetric closure hold as well). It is the user's obligation, though, to remove (or add) synonymy links from the computed synset to adjust it to commonsense understanding. In our example, an obvious synonymy mismatch is cargo to car (which typically results from mere partial syntactic matching).
Hence, the user would interactively remove the cargo{car link and thereby split the synset into two synsets as shown in Fig. 5. Along this separation we see also how the contexts (i.e. the corresponding ontologies) separate, only the aviation ontology contains concepts from both synsets. The left-hand synset box of Fig. 5 already comprises a reasonable set of synonyms, whereas the righthand synset box may suggest further splitting. For this it might be necessary to look more deeply into the (axiomatic) details of the involved ontologies, but this is beyond the scope of this paper.
Let us now turn to the expanded synset depicted in Fig. 6 which contains the class names line and route (i.e. the right-hand synset box from Fig. 3). This view is more detailed than Fig. 5 as it not just links ontologies to a synset, but moreover to the classes inside the synset. In general, this expansion shows more ontology to class name links, as an ontology itself can already contain synonyms. For instance, in the public transportation ontology the matcher has computed underground line and bus line as synonyms for line from warehouse goods load cargo car carrier carriage the ship transportation ontology. Note again that the matcher has not computed underground line and bus line directly as synonyms, but due to our interpretation of synonymy as equivalence relation these two class names are indirectly synonyms (due to the transitivity of synonymy). Again, we have several synonymy mismatches. Most of them could be repaired much the same way as described above. But what is new here is the occurrence of homonyms, i.e., one word with two meanings, namely two meanings of the word line. Just from the context information we can see that this line class name refers to two very di erent contexts, namely the graphics and ship transportation ontology.
Most likely we do not want to integrate the notion of line from the graphics ontology into our envisioned transportation ontology. Hence, we want to make explicit the existence of two meanings for a single label. This is done with the further expansion of our diagram Fig. 6 as depicted in Fig. 7, where two nodes with the label line are displayed: one linked to the graphics and the other to the ship transportation ontology. Apart from line the class name route is also contained in two ontologies, namely ship transportation and traffic network. In Fig. 6 they are also visible as two C-nodes in Fig. 7. line route line route
Comparing Fig. 6 and Fig. 7, we also see that the single synonym link from line to route expands to two synonym links. In particular, we see that line from ship transportation has not been linked to route from ship transportation, but to route from traffic network|a detail that was not visible in Fig. 6.
Now that we have the fully expanded view of a synset, we can remove all mismatched synonymy links. The nal result might look like Fig. 8. 4
We said in the previous section that the outcome of the above described procedure is an OCS-graph that serves as a basis for the synthesis of a new ontology that reuses knowledge from the ontology repository. In this section, we sketch the whole process of ontology reuse depicted in Fig. 9 with the graph manipulation being a central part.
Before any interaction with the user takes place, a matcher computes all
synonyms between ontologies in the repository and thus builds the initial OCS-graph.
Only a part of this graph is presented to the user based on the initially provided
class names as described above. Manipulating the OCS-graph is basically the
route
line
route
combined action of restriction and expansion that is performed in a cycle
until the OCS-graph re ects the intended knowledge core of what should become
a new ontology|we call this graph the seedgraph for an ontology synthesis.
Once the user has extracted the seed graph from the initial OCS-graph, this
graph is used to synthesise a new ontology. Each O-node together with all its
linked C-nodes in the seed graph are fed into a module extractor (see [
Ontology matching is the general research eld related to our work and [
Common to all these tools is that always only two ontologies (or schemas) are presented at a time. Hence, semantic overlap can be studied only between two ontologies presented side by side. This is su cient if the user already knows what pair of ontologies to investigate for potential overlap. Our approach, in contrast, supports the task to rst gure out which ontologies have the relevant semantic overlap to a given set of class names. With current systems, this task is very tedious to achieve: one needs to search for ontologies containing the given class names and then scan and analyse all their matchings with other ontologies in the repository step by step. We believe that, with our approach, the user will nd much faster the semantic overlaps between ontologies from a repository for a given set of class names because of the simultaneous presentation of matchings involving several ontologies. 10 http://neon-toolkit.org
We have introduced the notion of a hyperontology graph as a representation for concept matching across ontologies; we demonstrated several task speci c techniques of information hiding to cope with the complexity of that graph, and we determined graph modi cation operations to correct \wrong" concept matchings. The resulting graph can be used to automatically synthesise a new ontology from the explored and user-adjusted fragment of the hyperontology graph.
Synonymy of class names was the only type of link that we considered so far in the hyperontology graph. All our de nitions extend naturally to synonymy of property names. However, generalising our approach to other types of matching than synonymy requires more conceptual work. The next matching types we are going to investigate within our approach will be subsumption and disjointness. Adding new types of links to the hyperontology graph increases its complexity and thus calls for new kinds of information hiding techniques.
At the time of writing the system is in its early alpha stage and serves mostly as a proof of concept. It is not yet mature enough for a systematic evaluation w.r.t. usability and scalability, but will be made freely available and accessible as a web-service at a later stage.
Acknowledgements Work on this paper has been supported by the DFG-funded collaborative research centre SFB/TR 8 `Spatial Cognition' and by the EU-funded OASIS project.