Nowadays we have very large knowledge graphs that organize common-sense knowledge about the world. They have been successfully 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 efforts at exploiting knowledge graphs to build digestible and reliable Description Logic ontologies for speci c common-sense topics. We describe a simple yet e ective approach to building small- to middle-sized topic ontologies with moderate e orts. It is implemented in a proof-of-concept tool with a command-line interface for quickly creating axioms by selecting 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.
Decades-long research e orts have lead to readily available knowledge graphs
containing vast amounts of organized common-sense world knowledge, such as
Freebase [
In this paper we claim that the vast work invested into knowledge graphs can
be leveraged to build, with moderate e orts, small- to middle-sized topic-speci c
Description Logic (DL) ontologies of every-day domains. We believe such
ontologies can be extremely valuable for illustrative and didactical purposes, and in
research for quickly building ontologies for testing purposes. They could be
further 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 e ort needed to develop them from scratch. We describe a
simple yet e ective algorithm that allows users to interactively build topic-speci c
ontologies with moderate e orts, 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-de ned 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
complex ALCIO concepts. A key challenge is to identify suitable relations in
ConceptNet 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-o
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 eld, with goals as
varied as developing user-friendly ontology authoring tools, and partly
automatizing the ontology design process using machine learning and data mining.
Works aimed at learning ontologies include DL-FOIL [
We consider the DL ALCIO. Here we recall its syntax only, and refer to [
We use a generic notion of knowledge graphs formalized as follows:
De nition 2 (Knowledge Graph). We assume a xed nite 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 2 E a relation type `(e) 2 R, and
{ ! is a weight function that assigns a real number to each edge e.
If there is an edge e = (n; n0) 2 E with `(e) = r, we write e = (n; r; n0) 2 K.
ConceptNet. As a knowledge graph, we chose the freely-available ConceptNet
5.5 [
De nition 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 xed 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 2 fs; e; bg we di erentiate 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 di erent relation types and improve the generated suggestions, we de ne a ltered request Rgeq(n; 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 lters them according to a threshold function :
[ (r;t)2Re` Rgeq(n; Re`) = f(n0; !(e)) 2 Reqt(n; r) j !(e)
max (r;t)2Re` (Reqt(n; r))g
For example, if we refer to the node n through its label `(n) = `animal0 and request a set of start entities Reqs(`animal'; IsA) = f(`a rabbit', 2.828), (`A beaver', 2.0), (`a centipede', 1.0) , (`a dolphin', 4.0), (`A primate', 2.0), : : : g, then assuming a threshold function (Reqs(`animal'; IsA)) = 2:0, the ltered request set looks as follows: Rgeq(`animal'; f(IsA; s)g) = f(`a rabbit', 2.828), (`A beaver', 2.0), (`a dolphin', 4.0), (`A primate', 2.0), : : : g
Taking the results from a ltered 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`) = fonto(n0) j (n0; !(e)) 2 Rgeq(n; Re`)g which results in S(`animal'; f(IsA; s)g) = f Beaver; Dolphin; Primate; Rabbit; : : :g.
For our implementation we manually selected sets Re` of ConceptNet relation types to produce suggestions, based on di erent themes that we considered of interest for general knowledge domains. An overview can be found in Table 1, and the speci c use of these relations is explained in Section 3.
As a threshold function we chose the following ^: ^(Reqt(n; r)) = 82:0 > ><>1:1 > > >:1:0 if jf(n0; !(e)) 2 Reqt(n; r) j !(e) if jf(n0; !(e)) 2 Reqt(n; r) j !(e)
jf(n0; !(e)) 2 Reqt(n; r) j !(e) else 10 2:0gj 1:1gj 2:0gj < 10 5 and This function favors results with higher con dence than the baseline of 1, trying to keep at least ve entities if possible, and it keeps only the suggestions with very high con dence ( 2:0) if there are su ciently 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.
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 re ned by adding and removing inclusions. 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 rst three focus on popular relations in ConceptNet likely to be relevant in several 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-speci c 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 whenever Aj vT Ai, to x 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 2 NC (CT ) the two sets S( (A); Re`part ) and S( (A); Re`part ) of suggestions are retrieved. For each A 2 NC (CT ), we de ne the following combined set of suggestions SA :=
[ (B)=n0 Tax BvA
S(n0; Re`part ): (1) Using this combined set may result in a large number of suggestions for very general concepts, but later redundant suggestions for more speci c 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 9HasPart:(B11 t t Bn11 ) 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 di erent disjunctions (B1i t t Bnii ). 3. The user is given the option of adding an axiom A v 8HasPart:APart with
APart a fresh concept name. 4. The user is o ered the option of jumping to step C4 (domain-speci c 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 suggestions s of the form s has part A. If the answer is yes, then the role inclusion PartOf is de ned as the inverse of HasPart, and the process is repeated, using the role PartOf and the following combined set of suggestions for each A 2 Nc(CT ): 0 := SA
[ (B)=n0; Tax BvA
S (n0; Re`part ): (2) Example 1 in Fig. 2 shows the creation of an axiom with HasPart. 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-speci c roles). Step C4: topic-speci c 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; : : : ; Rmi), 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 entered, it is treated as a new concept name and added to NC (T ). If an individual a is selected it is treated as a nominal fag. 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 9Rji :(Bji1 t tBjin ). If Rji = IsA, then the input is converted into Fk Bki, without an existential. After all m prompts are complete, they are combined into the nal axiom i = A v Fk Bki t Fj 9Rji :(Bji1 t t Bjin ) 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 su xes 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 faig 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 chosen 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. 9Rji :> v Bjk i (3)
i i Aj u Ak v ? (4)
We can create axioms B v 9Rji :A by writing Rji with su x ` ' and having j = 1. The successive prompt changes to specify the left- instead of the righthand-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 o ers 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> = fA j there is no B s.t. A v B 2 T g. At each further step, the set PA = fB j B v A 2 T g is shown, and the user can choose between: All substeps of the construction process can be started separately and intermediate results are continuously saved. 4
We implemented our approach in CN2TopicOnto using Python3, and the
ConceptNet 5.6 REST API. To create and load OWL 2.0 les, we use the
ontologyoriented programming module owlready2 [
To illustrate the usefulness of CN2TopicOnto we provide examples of topic ontologies built with it. Table 2 shows some parameters of selected topic ontologies. 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 2 QCT .
Topic concept jNC (T )j jNR(T )j jNI (T )j jT j jDom( )j 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 We have presented an algorithm and a prototype tool CN2TopicOnto for constructing ontologies with the help of existing knowledge graphs. Knowledge elicitation 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. Pig v 9 HasBodyPart:Snout, Pig v 9 HasCharAnatomicalFeature:WiggleTail, Pig v 9 HasTypicalColor:(Brown t Pink), Pig v 9 LiveIn:Mud, Pig v 9 HasBehaviourChar:fsmartg, Pig v 9 HasSenseOfSight:fgoodg, Pig v 9 MakeAnimalSound:foinkg, Pigsty v 9 UsedToHold:Pig, Pork v 9 MeatOf:Pig Dodo Dodo v Bird; Dodo v ExtinctAnimal
Dodo v 9 FoundInGeographLocation:Mauritius
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 speci c. Through dynamic 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.
FireEngine FireEngine v EmergencyVehicle, FireEngine v Truck, FireEngine v 9 EquippedWith:Hose, FireEngine v 9 EquippedWith:WaterEngine, FireEngine v 9 HasColor:Red, FireEngine v 9 WorkVehicleOf:Fire ghter, FireStation v 9 UsedForPark:FireEngine SurfaceWatercraft Boat v SurfaceWatercraft, Ship v SurfaceWatercraft, SurfaceWatercraft v Vessel, SurfaceWatercraft v Vehicle, SurfaceWatercraft v 9 HasPart:(Propellor t Rudder t Sail) Plane Plane v Vehicle, CommercialPlane v Plane, Jet v Plane, Plane v 9 HasPart:Wing, Plane v 9 HasPart:Cabin, Plane v 9 EquippedWith:AirplaneSeat, Plane v 9 EquippedWith:Lavatory, Plane v 9 EquippedWith:OverheadBin, Plane v 9 EquippedWith:EmergencyOxygenMask, Plane v 9 HasModeOfTransportation:Air, Plane v 9 UsedToTransport:(Cargo t Luggage t Person), Plane v 9 ArriveAtTime:(Late t Punctual), Plane v 9 WorkEnvironmentOf:FlightAttendant, Plane v 9 WorkEnvironmentOf:AirHostess, Plane v 9 WorkEnvironmentOf:Pilot, Runway v 9 LandingAreaFor:Plane,
Taxiway v 9 DrivingAreaFor:Plane research, and in applications that call for non-trivial reasoning services using o -the-shelf DL algorithms.
Further empirical evaluation is needed to asses the quality of the created ontologies and the e ectiveness 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.