=Paper=
{{Paper
|id=Vol-2211/paper-10
|storemode=property
|title=A Tool for Building Topic-specific Ontologies Using a Knowledge Graph
|pdfUrl=https://ceur-ws.org/Vol-2211/paper-10.pdf
|volume=Vol-2211
|authors=Katinka Böhm,Magdalena Ortiz
|dblpUrl=https://dblp.org/rec/conf/dlog/BohmO18
}}
==A Tool for Building Topic-specific Ontologies Using a Knowledge Graph==
https://ceur-ws.org/Vol-2211/paper-10.pdf
A Tool for Building Topic-specific Ontologies
Using a Knowledge Graph
Katinka Böhm1 and Magdalena Ortiz1
Faculty of Informatics, TU Wien ?
katinka.boehm@gmail.com | ortiz@kr.tuwien.ac.at
Abstract. Nowadays we have very large knowledge graphs that orga-
nize common-sense knowledge about the world. They have been suc-
cessfully deployed in many areas, but the quality and relevance of the
contained knowledge varies greatly, and diverse knowledge domains are
unpredictably intertwined. This paper summarizes our preliminary ef-
forts at exploiting knowledge graphs to build digestible and reliable De-
scription Logic ontologies for specific common-sense topics. We describe
a simple yet effective approach to building small- to middle-sized topic
ontologies with moderate efforts. It is implemented in a proof-of-concept
tool with a command-line interface for quickly creating axioms by select-
ing from suggestions extracted from the ConceptNet knowledge graph.
To illustrate the kind of ontologies that can be built, we describe a few
example ontologies, which contain up to a few hundred concepts and
roles, and were built in a couple of hours.
Keywords: topic ontologies · ontology construction · knowledge-graph
1 Introduction
Decades-long research efforts have lead to readily available knowledge graphs
containing vast amounts of organized common-sense world knowledge, such as
Freebase [2][3], YAGO [17], OpenCyc [16] and DBPedia [12]. They are often the
result of integrating different knowledge extraction and data mining techniques,
and have been successfully applied in a range of areas. However, little can be as-
sumed about the quality of the knowledge they contain [8][7]. Possibly irrelevant
and imprecise facts coexist with relevant knowledge, and different knowledge do-
mains are interrelated in unpredictable ways. Moreover, these knowledge graphs
are not ontologies in the strict sense, with a logic-based semantics, and therefore,
they cannot be readily exploited for tasks that require non-trivial reasoning. On
the other end of the spectrum, we also have many repositories of high-quality
ontologies, but these are mostly for highly specialized domains, like life-sciences
and health care [11,5], and tailored more for experts than for laymen. Some of
them have been manually curated and extended over years, and are far too large
to allow a non-expert to get an understanding of the domain they describe.
?
This work was supported by the Austrian Science Fund (FWF) via projects P30360 and P30873.”
When it comes to understandable and reliable ontologies of manageable size,
describing non-technical every-day topics, there is a big gap. In fact, the only
such ontologies that we are aware of are hand-crafted toy examples, like the
Manchester Pizza Ontology1 and the DAML Wine Ontology2 .
In this paper we claim that the vast work invested into knowledge graphs can
be leveraged to build, with moderate efforts, small- to middle-sized topic-specific
Description Logic (DL) ontologies of every-day domains. We believe such ontolo-
gies can be extremely valuable for illustrative and didactical purposes, and in
research for quickly building ontologies for testing purposes. They could be fur-
ther improved with existing ontology-editing tools, and used as an starting point
for engineering larger high-quality ontologies for more specialized uses, reducing
the time and effort needed to develop them from scratch. We describe a sim-
ple yet effective algorithm that allows users to interactively build topic-specific
ontologies with moderate efforts, using suggestions retrieved from a knowledge
graph. We implemented the algorithm in a tool that queries the ConceptNet2
knowledge graph, and then suggests concepts and axioms to the user, who can
create the ontology using a simple command-line interface where he chooses from
the current suggestions, and creates axioms using both suggested and possibly
self-defined concepts and roles. Our simple proof-of-concept prototype allows to
build small- to middle-sized ontologies on everyday topics in a moderate time.
The created axioms range from plain concept inclusions, to inclusions with com-
plex ALCIO concepts. A key challenge is to identify suitable relations in Con-
ceptNet that are likely to encode ontological knowledge relevant to the user, and
to establish adequate orderings and thresholds for processing the suggestions in
a convenient way that does not overwhelm the user and yields a good trade-off
between the time invested and the quality of the resulting ontology. To illustrate
the usefulness of our prototype, we describe some illustrative ontologies with a
few hundred axioms, created with our tool in a couple of hours.
Related Work. Ontology engineering is a vast research field, with goals as
varied as developing user-friendly ontology authoring tools, and partly autom-
atizing the ontology design process using machine learning and data mining.
Works aimed at learning ontologies include DL-FOIL [6] and OCEL [15], which
use inductive logic programming to learn definitions of concepts from existing
ontologies and instance data. A newly published approach employs learning via
queries to an oracle [13]. Somewhat related to our work are frameworks for on-
tology construction like Text2Onto [4] and OntoGen [9], where ontologies are
generated semi-automatically with the help of user feedback and interference to
improve the results. However, these approaches exploit text corpora and rely
on established text processing methods. The creation of knowledge graphs al-
ready incorporates this kind of text and data mining, as well as other means of
knowledge extraction, so we want to take advantage of such preprocessed and
semi-structured knowledge. We are not aware of other attempts aiming at build-
ing manageable ontologies for varying topics from existing knowledge graphs.
1
https://protegewiki.stanford.edu/wiki/Protege4Pizzas10Minutes
2
https://www.w3.org/TR/2003/PR-owl-guide-20031215/wine
2 Ontologies and Knowledge Graphs
We consider the DL ALCIO. Here we recall its syntax only, and refer to [1] for
details. Let NC , NR and NI be countably infinite, pairwise disjoint alphabets
of concept names, role names, and individuals. Roles are expressions r and r−
with r ∈ NR , while concepts C obey the grammar C → > | ⊥ | A | {a} | ¬C |
C u C | C t C | ∃r.C | ∀r.C, where A ∈ NC , a ∈ NI , and r ∈ NR . An ontology
or TBox T is a set of general concept inclusions (GCIs) C v D where C and D
are concepts. We use NC (T ) to denote the concept names occurring in T , and
define taxonomies as restricted ontologies containing only atomic GCIs.
Definition 1 (ACIs, taxonomies). An atomic concept inclusion (ACI) is a
GCI of the form A v B with A, B ∈ NC \{>}, and a taxonomy is a set of ACIs.
The taxonomy Tax(T ) of an ontology T is the set of ACIs in T . A taxonomy
Tax can be represented as a directed graph GTax whose nodes are the concept
names in Tax, with an edge from A to B whenever A v B ∈ Tax.
We note that, for a taxonomy T , we have T |= A v B iff A v∗T B, where v∗T is
the reflexive transitive closure of vT = {(A, B) | A v B ∈ T }.
We use a generic notion of knowledge graphs formalized as follows:
Definition 2 (Knowledge Graph). We assume a fixed finite set R of relation
types. A knowledge graph is a triple K = (G, `, ω) where
– G = (N, E) is a directed graph whose nodes N are called entities,
– ` is a labeling function that assigns to each entity n a string `(n), which we
call the label of n, and to each edge e ∈ E a relation type `(e) ∈ R, and
– ω is a weight function that assigns a real number to each edge e.
If there is an edge e = (n, n0 ) ∈ E with `(e) = r, we write e = (n, r, n0 ) ∈ K.
ConceptNet. As a knowledge graph, we chose the freely-available ConceptNet
5.5 [18],which originated from the Open Mind Common Sense Project [10] of the
MIT Media Lab. It contains approximately 28 million edges in over 304 languages
and a core set of 37 relation types. A big part of the data was gathered through
crowd-sourcing and word games, and also integrates dictionary knowledge from
DBPedia, Wiktionary and WordNet. Each node has an ID and a natural language
label, which may have articles or filler words. The literature does not give a
precise definition of the edge weights, but they are described as an estimation
of the trustability of statements, obtained by assessing individual sources, and
adding the values when an edge originates from more than one source.
Topic Ontologies. We define a topic ontology as a DL ontology with a distin-
guished topic concept. We connect topic ontologies to a knowledge graph K via
a mapping φ from concept names in T to entities in K.
Definition 3 (Topic Ontology, KG-mapping). A topic ontology is a pair
O = (T , tc) of an ALCIO ontology T and a concept name tc occurring in T ,
which we call the topic concept of O. Given a knowledge graph K, a K-mapping
is a bijective mapping from a subset of NC (T ) to a set of entities of K. We
denote X = (T , tc, φ) a topic ontology with a K-mapping φ.
Extracting Suggestions from the Knowledge Graph. In what follows, we
assume a fixed knowledge graph K, and use it to build X = (T , tc, φ).
We use φ to pose queries to K. Each query returns a set Reqt (n, r) for an
entity n and a relation type r in K. Through t ∈ {s, e, b} we differentiate between
three types of such sets: end (e), start (s) and both (b). Reqe contains all pairs
(n0 , ω(e)), where there exists an outgoing edge from n to n0 that is labeled with r
in K. Similarly, Reqs returns all node-weight pairs for any incoming edges from
n0 to n labeled with r. In the case of Reqb , the union of both Reqe and Reqs is
returned. The answers are used to generate suggestions for concept names that
the user can rely on and use to iteratively add axioms to T .
To combine query results over edges with different relation types and improve
the generated suggestions, we define a filtered request Req(n,
g Re`) for an entity
n, which takes the union over multiple (r, t) of a relation r from k and a request
type t, and filters them according to a threshold function Θ:
[
Req(n,
g Re`) = {(n0 , ω(e)) ∈ Reqt (n, r) | ω(e) ≥ max Θ(Reqt (n, r))}
(r,t)∈Re`
(r,t)∈Re`
For example, if we refer to the node n through its label `(n) = ‘animal0
and request a set of start entities Reqs (‘animal’, IsA) = {(‘a rabbit’, 2.828), (‘A
beaver’, 2.0), (‘a centipede’, 1.0) , (‘a dolphin’, 4.0), (‘A primate’, 2.0), . . . },
then assuming a threshold function Θ(Reqs (‘animal’, IsA)) = 2.0, the filtered
request set looks as follows: Req(‘animal’,
g {(IsA, s)}) = {(‘a rabbit’, 2.828), (‘A
beaver’, 2.0), (‘a dolphin’, 4.0), (‘A primate’, 2.0), . . . }
Taking the results from a filtered request, we apply a naming function onto
that transforms the labels of entities in K into a set S(n, Re`) of concept names.
Formally, we let
S(n, Re`) = {onto(n0 ) | (n0 , ω(e)) ∈ Req(n,
g Re`)}
which results in S(‘animal’, {(IsA, s)}) = { Beaver, Dolphin, Primate, Rabbit, . . .}.
For our implementation we manually selected sets Re` of ConceptNet relation
types to produce suggestions, based on different themes that we considered of
interest for general knowledge domains. An overview can be found in Table 1,
and the specific use of these relations is explained in Section 3.
As a threshold function Θ we chose the following Θ̂:
2.0 if |{(n0 , ω(e)) ∈ Reqt (n, r) | ω(e) ≥ 2.0}| ≥ 10
1.1 if |{(n0 , ω(e)) ∈ Req (n, r) | ω(e) ≥ 1.1}| ≥ 5 and
t
Θ̂(Reqt (n, r)) = 0
|{(n , ω(e)) ∈ Reqt (n, r) | ω(e) ≥ 2.0}| < 10
1.0 else
This function favors results with higher confidence than the baseline of 1, trying
to keep at least five entities if possible, and it keeps only the suggestions with
very high confidence (≥ 2.0) if there are sufficiently many of them (≥ 10).
For onto, we chose a function that applies CamelCase to the labels, after
removing auxiliary words such as articles and conjunctions. As an example,
`(n) = “A romance novel” from K is converted to onto(n) = RomanceNovel.
3 Building a Topic Ontology
In this section we describe our interactive algorithm to build X = (T , tc, φ).
The user inputs a topic concept tc associated to some φ(tc) in K, and tc v > is
initially the only axiom in T . Then T is expanded with axioms given by the user
in three steps: (1) a core taxonomy is created, (2) axioms with possibly complex
concepts are created, and (3) T is refined by adding and removing inclusions.
Table 1. Relations from ConceptNet and request types used
ACIs (step 1) Re`v = {(IsA, s)}, Re`w = {(IsA, e)}, Re`∼
= = {(RelatedTo, b)}
GCIs (step 2) Re`part = {(HasA,e), (PartOf,s)}, Re`part − = {(HasA,s), (PartOf,e)}
Re`loc = {(AtLocation,s)}, Re`loc − = {(AtLocation,e)}
Re`cap = {(CapableOf,e), (ReceivesAction,e)}
Re`cap − = {(CapableOf,s), (ReceivesAction,s)}
Re`sp = {(HasProperty,b), (RelatedTo,b)}
Step 1: Building the Central Taxonomy
We first build a set CT of ACIs which we call the central taxonomy of X . This
CT is such that (i) tc ∈ NC (CT ), (ii) GCT is connected, and (iii) φ(A) is defined
for every A ∈ NC (CT ). To generate suggestions for CT , we use the ConceptNet
relations IsA and RelatedTo. More specifically, we use Re`v , Re`w and Re`∼ = in
Table 1. We build CT as follows:
(a) The suggestions in S(φ(tc), Re`v ) are prompted to the user. For each se-
lected A = onto(n) ∈ S(φ(tc), Re`v ), an axiom A v tc is added to T , and
φ is extended with φ(A) = n.
(b) Analogously, suggestions in S(φ(tc), Re`w ) are prompted, axioms tc v A
are added for the selected A = onto(n), and φ is extended with φ(A) = n.
(c) Next, suggestions in S(φ(tc), Re`∼ = ) are prompted and the user makes two
selections: those to treat as in in (a), and those to treat as in (b).
(d) For each A ∈ NC (CT ) introduced in items (a) to (c), items (a) and (b) are
repeated, adding axioms A v B and B v A, and extending φ accordingly.
(e) Lastly, the algorithm iterates over NC (CT ) and collects for each A, a set SA
of suggestions for possibly missing inclusions. SA contains each B such that
A v∗T B and A v∗T B 0 for some B 0 , but neither B v∗T B 0 nor B 0 v∗T B. For
each pair (B, B 0 ) ∈ SA × SA selected by the user, B v B 0 is added to CT .
Fig. 1 illustrates items (a) to (c) for the topic concept Animal.
Step 2: Adding complex GCIs
GCIs with possibly complex concepts are added next in four analogous substeps.
The suggestions presented in each substep are based on a certain theme. The first
three focus on popular relations in ConceptNet likely to be relevant in several
Fig. 1. Building a central taxonomy for the topic concept Animal.
Example Input:
Possible subclasses of Animal
Beaver[0], Ferret[1], Primate[2], Rabbit[3], Rodent[4]
Which concepts do you want to delete? 4 2
Possible superclasses of Animal
LivingCreature[0], Organism[1], Preditor[2]
Which concepts do you want to delete? not 0
Those might be sub- or super-classes too:
Bear[0], Beast[1], Fox[2], LivingBeing[3], Skunk[4], Squirrel[5]
Choose subclasses of Animal: 0 2 4 5
Result: CT = {Beaver v Animal, Ferret v Animal, Rabbit v Animal,
Animal v LivingCreature, Bear v Animal, Fox v Animal, Skunk v Animal, Squirrel v Animal}
domains: part-of relations, spatial locations, and capabilities (see Table 1). The
last substep uses suggestions from the generic ConceptNet relations HasProperty
and RelatedTo and creates axioms with topic-specific role names.
The procedure is then similar for each substep. An algorithm iterates over the
concept names in NC (CT ) using a queue QCT = (A1 , . . . , An ) where i < j when-
ever Aj v∗T Ai , to fix one concept name A from NC (CT ). Respective suggestions
are proposed for A and the user can select and create associated axioms.
Step C1: has-part and part-of. The user is asked whether he wants to create
HasPart and PartOf relations. If the answer is positive, then for each A ∈ NC (CT )
the two sets S(φ(A), Re`part ) and S(φ(A), Re`part − ) of suggestions are retrieved.
For each A ∈ NC (CT ), we define the following combined set of suggestions
[
SA := S(n0 , Re`part ). (1)
φ(B)=n0 TaxBvA
Using this combined set may result in a large number of suggestions for very
general concepts, but later redundant suggestions for more specific concepts
(which inherit already created GCIs) are removed.
The system asks if the user wants suggestions s of the form A has part s.
If the answer is yes, then the algorithm iterates over the queue QCT , skipping
those A for which SA is empty, and in each iteration proceeds as follows:
1. It asks if the user wants suggestions of parts of A. If the answer is no, then
it moves to the next concept in the queue.
2. If the answer is yes, then the user is prompted with the suggestions in SA .
He can select from the list, or type fresh concept names, and the axiom
A v ∃HasPart.(B11 t · · · t Bn1 1 )
is added, where (B11 , . . . , Bn1 ) is the list of the selected and typed concept
names. This step can be repeated to create as many analogous axioms as
desired, with different disjunctions (B1i t · · · t Bni i ).
3. The user is given the option of adding an axiom A v ∀HasPart.APart with
APart a fresh concept name.
4. The user is offered the option of jumping to step C4 (domain-specific roles)
with the current suggestions. If he does, he will then come back to this step.
After the whole queue has been processed, the user is asked if he wants sugges-
tions s of the form s has part A. If the answer is yes, then the role inclusion
PartOf − is defined as the inverse of HasPart, and the process is repeated, using the
role PartOf and the following combined set of suggestions for each A ∈ Nc (CT ):
[
0
SA := S(n0 , Re`part − ). (2)
φ(B)=n0 , TaxBvA
Example 1 in Fig. 2 shows the creation of an axiom with HasPart.
Fig. 2. Examples of input and resulting axioms during Step 2.
Example 1
1 MotorVehicle.HasPart.Engine Motor
MotorVehicle v ∃ HasPart.(Engine t Motor)
Example 2
1 relation name = HasIngredient Contains
2 Cake.HasIngredient.Sugar
3 Cake.Contains.SugarSyrup ArtificialSweetener
Cake v ∃ HasIngredient.Sugar t ∃ Contains.(SugarSyrup t ArtificialSweetener)
Example 3
1 relation name = InStorage InTemporalStorage
2 LibraryBook.InStorage.Shelf: Bookcase()
3 Enter subclasses for Shelf:Bookshelf
4 Enter instances for Bookcase:bc1 bc2 bc3 bc4 bc5
5 LibraryBook.InTemporalStorage.Table:
6 Enter subclasses for Table:PresentationTable RollingTable
{bc1,bc2,bc3,bc4,bc5} v Bookcase,
LibraryBook v ∃ InStorage.(Shelf t Bookcase) t ∃ InTemporalStorage.(Table),
Bookshelf v Shelf, PresentationTable v Table, RollingTable v Table
Example 4
1 relation name: HasTopping
2 Pizza.HasTopping.PizzaTopping:
3 Enter subclasses for PizzaTopping: Pepperoni Olive Onion
4 Create an existential axiom for Pizza? [y/n] y
5 Pizza.HasTopping.PizzaTopping
Pizza v ∃ HasTopping.PizzaTopping,
Pepperoni v PizzaTopping, Olive v PizzaTopping, Onion v PizzaTopping,
Pepperoni u Olive v ⊥, Olive u Onion v ⊥, Onion u Pepperoni v ⊥,
∃ HasTopping− .> v PizzaTopping
Step C2 / Step C3: locations / capabilities. In these two identical steps,
the user is asked whether he wants to get location/capability related suggestions.
If yes, the algorithm iterates over QCT , and accordingly proposes the suggestions
in S(φ(A), Re`loc ), S(φ(A), Re`loc − ), S(φ(A), Re`cap ), or S(φ(A), Re`cap − ). The
addition of axioms is then as described below in step C4 (topic-specific roles).
Step C4: topic-specific roles. The queue QCT is iterated and for each A
the user is optionally prompted with suggestions S(φ(A), Re`sp ). Then role and
concept names can be inserted and used to create GCIs as follows:
1. The user is asked if he wants to add a new axiom containing A. If not, the
algorithm moves to the next item in the queue.
2. If yes, the user is prompted to enter a set of relation names (R1i , . . . , Rm i
),
which may include IsA. Each such set creates one disjunctive axiom that
contains exactly the role names in it. Once entered, role names are saved
and can be chosen through the auto-complete function for future prompts;
a special role can be used to retain suggestions for later.
3. Following, m three-part prompts are issued, one for each Rji , 1 ≤ j ≤ m, in
which the user can select concept names or individuals with auto-complete,
or type fresh names. The list for selection contains the suggestions
S(φ(A), Re`sp ), concept names that were retained, and all individuals in
NI (T ) (see dynamic extensions to add individuals). If a fresh string is en-
tered, it is treated as a new concept name and added to NC (T ). If an indi-
vidual a is selected it is treated as a nominal {a}. Let (Bji1 , . . . , Bjin ) be the
entered concept names or nominals for Rji . Example 2 in Fig. 2 illustrates
how an input A.Rji .Bji1 . . . Bjin (line 3) is converted into ∃Rji .(Bji1 t· · ·tBjin ).
If Rji = IsA, then the input is converted into k Bki , without an existential.
F
After all m prompts are complete, they are combined into the final axiom
βi = A v k Bki t j ∃Rji .(Bji1 t · · · t Bjin )
F F
Steps 1-3 can be repeated as often as wanted for each A to create multiple βi .
Note that if k = 1 and j = 0, then βi has the form A v B.
When entering (Bji1 , . . . , Bjin ) the user can add one of two suffixes to any Bjk
to receive further prompts. We call this process dynamic extension.
Appending a colon (:) allows for the creation of a set of subclasses (A1 , . . . , Am )
together with respective axioms Ai v Bjk , 1 ≤ i ≤ m. Similarly with a set of
brackets (()) individuals (a1 · · · am ) are created together with axioms {ai } v Bjk .
This is especially useful when suggestions contain concepts that ought to be
added to the ontology, but not in the scope of A. More general concept names
can then be chosen in βi and subclasses or individuals assigned through dynamic
extensions. If k = 0, j = 1, and n = 1 in βi , a range restriction (3) for the cho-
sen Rji is also created. If a colon is used, then additionally a set of disjointness
axioms (4) is created for all Aij and Aik that were added as subclasses.
∃Rji− .> v Bjik (3) Aij u Aik v ⊥ (4)
We can create axioms B v ∃Rji .A by writing Rji with suffix ‘−’ and having
j = 1. The successive prompt changes to specify the left- instead of the right-
hand-side of the axiom; for this case dynamic extensions are not yet supported.
Examples 3 and 4 in Fig. 2 show the addition of an axiom βi with j = 2
using dynamic extensions, and an axiom with range restriction and disjointness.
Step 3: Clean-Up
The last step offers the option to further modify the taxonomy of T . In particular,
the user can create inclusions between concept names added in Step 2, and
introduce new concept names into the taxonomy. Initially the concept A = > is
selected and P> = {A | there is no B s.t. A v B ∈ T }. At each further step,
the set PA = {B | B v A ∈ T } is shown, and the user can choose between:
1. Get a new set PB for some selected B ∈ PA with PB 6= ∅, or
2. Input two sets {A1 , · · · , Am } and {B1 , · · · , Bn } by either selecting from PA
or entering new concept names. Then n × m axioms Ai v Bj for 1 ≤ i ≤ m
and 1 ≤ j ≤ n are added to T , and additionally
– if Bj is new, then Bj v A is added and Ai v A removed,
– if Bj ∈ NC (T ) and Bj v A 6∈ T then the user can choose to add it.
Note that the removed axioms are redundant, as they are implied by T .
All substeps of the construction process can be started separately and interme-
diate results are continuously saved.
4 Example Ontologies
We implemented our approach in CN2TopicOnto using Python3, and the Con-
ceptNet 5.6 REST API. To create and load OWL 2.0 files, we use the ontology-
oriented programming module owlready2 [14].
To illustrate the usefulness of CN2TopicOnto we provide examples of topic
ontologies built with it. Table 2 shows some parameters of selected topic ontolo-
gies. The last column gives a rough estimate of the total user time taken to build
each ontology from scratch. This includes suggestion selection and axiom input.
We also show selected parts for two created ontologies, one with tc = Animal
and the other with tc = Vehicle. Fig. 3 and 5 show subgraphs of their CT ,
where an is-a-arc between two concepts A and B translates to A v B. Small
arrowheads indicate that there exist further arcs that were omitted for space
reasons. Fig. 4 and 6 provide a selection of axioms from the respective T , where
the concept name at the top is the relevant A ∈ QCT .
Topic concept |NC (T )| |NR (T )| |NI (T )| |T | |Dom(φ)| complex GCIs Time
Animal 670 67 50 1249 347 33.4 % 6h
Vehicle 300 34 7 483 128 37.7 % 5h
NaturalDisaster 89 16 4 150 35 44.7 % 1.5h
Fruit 309 35 0 564 125 44 % 5h
FastFood 109 20 0 200 22 77.5 % 2.5h
University 153 15 5 233 46 22.3 % 3h
Table 2. Statistics for some constructed ontologies. Dom(φ) denotes the domain of φ.
5 Discussion and Future Work
We have presented an algorithm and a prototype tool CN2TopicOnto for con-
structing ontologies with the help of existing knowledge graphs. Knowledge elici-
tation and ontology authoring require an immense amount of time and expertise
to produce good results, but with our approach we want to simplify the process
and exploit the vast amount of existing knowledge repositories to our advantage.
Fig. 3. A selected part of CT of the Animal taxonomy.
Animal Pig
Animal v Creature, Pig v Animal, Pig v FarmAnimal,
Animal v ∀ HasPart.AnimalPart, Pig v Mammal, Pig v Omnivore,
Animal v ∃ HasPart.Cell, Pig v Quadruped,
Animal v ∃ PartOf.Ecosystem, Sow v Pig, Piglet v Pig, Boar v Pig,
Animal v ∃ PartOf.Nature, DomesticatedPig v Pig,
Animal v ∃ HasSpecies.AnimalSpecies, Pig v ∃ HasBodyPart.Snout,
Animal v ∃ LiveIn.(Home t Wilderness t Zoo) Pig v ∃ HasCharAnatomicalFeature.WiggleTail,
Herbivore Pig v ∃ HasTypicalColor.(Brown t Pink),
Herbivore v Animal, Pig v ∃ LiveIn.Mud,
Deer v Herbivore, Pig v ∃ HasBehaviourChar.{smart},
Pig v ∃ HasSenseOfSight.{good},
Herbivore v ∃ HasPreferredFood.Plant, Pig v ∃ MakeAnimalSound.{oink},
Meadow v ∃ NaturalHabitatOf.Herbivore
Pigsty v ∃ UsedToHold.Pig,
Feather
Pork v ∃ MeatOf.Pig
Down v Feather, GooseQuill v Feather,
DuckDown v Down, GooseDown v Down, Dodo
SwanDown v Down, Dodo v Bird, Dodo v ExtinctAnimal
Bird v ∃ Possess.Feather Dodo v ∃ FoundInGeographLocation.Mauritius
Fig. 4. Selected axioms from the Animal ontology.
From an ontology engineering perspective, the approach combines top-down and
bottom-up design. The topic concept and central taxonomy initialize a top-down
process, where concepts are added from general to more specific. Through dy-
namic extensions it is possible to add new subsuming concepts for subsets of
suggestions in a bottom-up fashion.
The ontologies created with our tool, despite being rather simple, can be used
as a basis to be developed further into high-quality ontologies that can used in
Fig. 5. A selected part of CT the Vehicle taxonomy.
Plane
FireEngine Plane v Vehicle,
FireEngine v EmergencyVehicle, CommercialPlane v Plane, Jet v Plane,
FireEngine v Truck, Plane v ∃ HasPart.Wing,
FireEngine v ∃ EquippedWith.Hose, Plane v ∃ HasPart.Cabin,
FireEngine v ∃ EquippedWith.WaterEngine, Plane v ∃ EquippedWith.AirplaneSeat,
FireEngine v ∃ HasColor.Red, Plane v ∃ EquippedWith.Lavatory,
FireEngine v ∃ WorkVehicleOf.Firefighter, Plane v ∃ EquippedWith.OverheadBin,
Plane v ∃ EquippedWith.EmergencyOxygenMask,
FireStation v ∃ UsedForPark.FireEngine
Plane v ∃ HasModeOfTransportation.Air,
SurfaceWatercraft Plane v ∃ UsedToTransport.(Cargo t Luggage
Boat v SurfaceWatercraft, t Person),
Ship v SurfaceWatercraft, Plane v ∃ ArriveAtTime.(Late t Punctual),
SurfaceWatercraft v Vessel, Plane v ∃ WorkEnvironmentOf.FlightAttendant,
SurfaceWatercraft v Vehicle, Plane v ∃ WorkEnvironmentOf.AirHostess,
SurfaceWatercraft v ∃ HasPart.(Propellor t Plane v ∃ WorkEnvironmentOf.Pilot,
Rudder t Sail) Runway v ∃ LandingAreaFor.Plane,
Taxiway v ∃ DrivingAreaFor.Plane
Fig. 6. Selected axioms from the Vehicle ontology.
research, and in applications that call for non-trivial reasoning services using
off-the-shelf DL algorithms.
Further empirical evaluation is needed to asses the quality of the created
ontologies and the effectiveness of our tool. We want to expand the supported
constructors to include negation and full conjunction. Moving to more expressive
DL such as SHOIQ would be useful to express common-sense statements like
Biped v = 2HasFoot.Foot or FourWheeledVehicle v = 4HasWheel.Wheel.
References
1. Baader, F., Calvanese, D., McGuinness, D.L., Nardi, D., Patel-Schneider, P.F.
(eds.): The Description Logic Handbook: Theory, Implementation, and Applica-
tions. Cambridge University Press (2003)
2. Bollacker, K.D., Cook, R.P., Tufts, P.: Freebase: A shared database of structured
general human knowledge. In: AAAI. pp. 1962–1963. AAAI Press (2007)
3. Chah, N.: Freebase-triples: A methodology for processing the freebase data dumps.
CoRR abs/1712.08707 (2017)
4. Cimiano, P., Völker, J.: Text2onto. In: NLDB. Lecture Notes in Computer Science,
vol. 3513, pp. 227–238. Springer (2005)
5. Donnelly, K.: Snomed-ct: The advanced terminology and coding system for ehealth.
Studies in health technology and informatics 121, 279 (2006)
6. Fanizzi, N., d’Amato, C., Esposito, F.: DL-FOIL concept learning in description
logics. In: ILP. Lecture Notes in Computer Science, vol. 5194, pp. 107–121. Springer
(2008)
7. Färber, M., Bartscherer, F., Menne, C., Rettinger, A.: Linked data quality of db-
pedia, freebase, opencyc, wikidata, and YAGO. Semantic Web 9(1), 77–129 (2018)
8. Färber, M., Ell, B., Menne, C., Rettinger, A.: A comparative survey of dbpedia,
freebase, opencyc, wikidata, and yago. Semantic Web Journal 1, 1–5 (2015), http:
//www.semantic-web-journal.net/system/files/swj1141.pdf
9. Fortuna, B., Grobelnik, M., Mladenic, D.: Ontogen: Semi-automatic ontology ed-
itor. In: HCI (9). Lecture Notes in Computer Science, vol. 4558, pp. 309–318.
Springer (2007)
10. Havasi, C., Speer, R., Arnold, K.C., Lieberman, H., Alonso, J.B., Moeller, J.: Open
mind common sense: Crowd-sourcing for common sense. In: Collaboratively-Built
Knowledge Sources and AI. AAAI Workshops, vol. WS-10-02. AAAI (2010)
11. Hoehndorf, R., Schofield, P.N., Gkoutos, G.V.: The role of ontologies in biologi-
cal and biomedical research: a functional perspective. Briefings in Bioinformatics
16(6), 1069–1080 (2015)
12. Ismayilov, A., Kontokostas, D., Auer, S., Lehmann, J., Hellmann, S.: Wikidata
through the eyes of dbpedia. Semantic Web 9(4), 493–503 (2018)
13. Konev, B., Lutz, C., Ozaki, A., Wolter, F.: Exact learning of lightweight description
logic ontologies. Journal of Machine Learning Research 18, 201:1–201:63 (2017)
14. Lamy, J.: Owlready: Ontology-oriented programming in python with automatic
classification and high level constructs for biomedical ontologies. Artificial Intelli-
gence in Medicine 80, 11–28 (2017)
15. Lehmann, J., Auer, S., Bühmann, L., Tramp, S.: Class expression learning for
ontology engineering. J. Web Sem. 9(1), 71–81 (2011)
16. Matuszek, C., Cabral, J., Witbrock, M.J., DeOliveira, J.: An introduction to the
syntax and content of cyc. In: AAAI Spring Symposium: Formalizing and Com-
piling Background Knowledge and Its Applications to Knowledge Representation
and Question Answering. pp. 44–49. AAAI (2006)
17. Rebele, T., Suchanek, F.M., Hoffart, J., Biega, J., Kuzey, E., Weikum, G.: YAGO:
A multilingual knowledge base from wikipedia, wordnet, and geonames. In: In-
ternational Semantic Web Conference (2). Lecture Notes in Computer Science,
vol. 9982, pp. 177–185 (2016)
18. Speer, R., Chin, J., Havasi, C.: Conceptnet 5.5: An open multilingual graph of
general knowledge. In: AAAI. pp. 4444–4451. AAAI Press (2017)