Giving an entity in a knowledge graph a dedicated name raises the question of whether this name is used consistently in the knowledge graph or not. In this paper, we investigate the way complex concepts, e.g., medical diseases, are represented and used in knowledge graphs. In particular, we wonder whether knowledge graphs include definitions of concise but informative names for more complex concepts that can be used in lieu of more explicit but lengthy representations. For this purpose, we formalise the idea of introducing dedicated names for complex expressions in OWL. We use this formalisation to conduct a case study on SNOMED CT. We analyse how often names for complex concepts are introduced, how often these names are used throughout an ontology, and whether these names are used consistently whenever they can be used. We find that many complex concepts in SNOMED CT are associated with a dedicated name and that such names are mostly used in a consistent fashion throughout the ontology. However, there are a few exceptions and there are also cases of complex concepts that are not associated with a dedicated name.
and 1 ≤ ≤ where is some property that associates entity with characteristic . On the other hand, using approach (ii), only triples of the form (, rdf:type, Elephant) are required, plus (approximately) triples to define the meaning of Elephant in terms of the characteristics.
The meaning of a name, e.g., Elephant, in a knowledge graph can be specified via the semantics
of a knowledge representation language, e.g., OWL [
actsSpecificallyOn.(Blood ⊓ ∃ hasPhysicalState.(PhysicalState ⊓
∃ hasState.Liquid)) ⊓ ∃ hasOutcome.SolidBlood) This axiom is arguably complex due to both its size and the nesting of expressions. However, Galen also contains the following axioms:
Given these equivalences, the named concept LiquidBlood can be used to simplify the representation of Clotting to
This observation provides the motivation for investigating whether names for more complex
expressions are in fact used in their stead. The contributions are as follows: (i) we propose an
approach for identifying definitions of various kinds for named classes in ontologies, (ii) we
develop techniques for quantifying the use and lack of reuse of such named classes, and (iii)
we use these techniques to conduct a case study on SNOMED CT [
We assume the reader to be familiar with OWL [
The Oxford English Dictionary defines the word abbreviation to denote “[t]he result of
shortening something; an abbreviated or condensed form, esp. of a text; a summary, an abridgement” [
A complex OWL expression can be equivalent to more than just one named class. We refer to equivalent named classes as synonyms.1 Please note that synonyms are not necessarily abbreviations. However, a synonym for an abbreviation is also an abbreviation (due to transitivity of EquivalentClasses ).
Definition 2 (Synonym). A synonym for a named class N in an ontology is a named class S s.t. |= EquivalentClasses (S, N). The axiom EquivalentClasses (S, N) is called the definition of S.
Both abbreviations and synonyms are notions based on entailment, i.e., an EquivalentClasses axiom with exactly two arguments. However, OWL specifies EquivalentClasses as an -ary constructor. So, for the purpose of analysing how abbreviations and synonyms are specified in ontologies, we introduce a notion that accounts for all syntactic variants of EquivalentClasses . Definition 3 (Definition Types). Let A be an abbreviation, S1, . . . , S synonyms, and C1, . . . , C complex class expressions. Then, an axiom is a • simple definition of A, if = EquivalentClasses (A, C), • simple definition of S, if = EquivalentClasses (A, S), • ambiguous definition of A, if = EquivalentClasses (A, C1, . . . , C), • enumerative definition for S1, . . . , S, if = EquivalentClasses (S1, . . . , S), • compound definition for S1, . . . , S, if = EquivalentClasses (S1, . . . , S, C1, . . . , C).
With this notion of definition types, we can quantify how abbreviations and synonyms are
specified in an ontology, i.e., we can count both explicit as well as implicit EquivalentClasses
in an ontology. Since the extraction of finite sets of entailments is a non-trivial matter [
(hasTopping some (PizzaTopping and (hasSpiciness some Hot))) 2 = SpicyTopping EquivalentTo PizzaTopping and (hasSpiciness some Hot) 3 = SpicyTopping EquivalentTo HotTopping 4 = DiavolaPizza SubClassOf SpicyPizza 5 = DiavolaPizza SubClassOf Pizza and hasCountryOfOrigin value Italy 6 = NapoletanaPizza SubClassOf Pizza and hasCountryOfOrigin value Italy
Consider the example ontology shown in Figure 1. Here, the abbreviation SpicyPizza is specified via a simple definition in axiom 1 and occurs on the right-hand side of 4. So, we say an abbreviation is used if it occurs in an OWL axiom that is not its definition. Definition 4 (Abbreviation Use). Let A be an abbreviation in an ontology . If A occurs in an axiom ∈ and is not a definition for A (according to Definition 3), then A is used in .
In addition to the use of an abbreviation, we can also determine if an abbreviation is not used even though its use would be possible.
Definition 5 (Possible Abbreviation Use). Let EquivalentClasses (A, ) be the definition of an abbreviation A in an ontology . If C occurs in an axiom ∈ and is not a definition for A (according to Definition 3), then there is a possible use for A in .
Consider axiom 1 ∈ . Here, the abbreviation SpicyTopping or its synonym HotTopping have possible uses since the complex OWL expression PizzaTopping and (hasSpiciness some Hot) could be replaced by either SpicyTopping or HotTopping.
Note that the definition of a possible use for an abbreviation is dependent on the existence of an abbreviation in an ontology. However, in cases where no abbreviation is available, one may wonder when it makes sense to introduce an abbreviation for a reoccurring complex expression. A high number of occurrences of a complex class in an ontology may be used as an indicator for the identification of potential candidates for a new abbreviation.
Definition 6 (Abbreviation Candidate). Let C be a complex expression in an ontology s.t. there is no abbreviation for C. If C occurs at least times in , then C is a abbreviation candidate w.r.t. threshold .
With the notions of an abbreviation’s use (Definition 4), possible use (Definition 5), and abbreviation candidate (Definition 6), we can quantify the impact of abbreviations in an ontology. First, however, one needs to identify all abbreviations in an ontology. So, in the next section, we specify a procedure for determining all explicit as well as implicit abbreviations defined in an ontology.
Explicit definitions for abbreviations (according to Definition 3) can be determined in a straightforward manner by checking the syntactic shape of all axioms in a given ontology. Similarly, implicit definitions can be determined in a straightforward manner by checking |= EquivalentClasses (A, C) for all pairs of named classes and complex classes occurring in an ontology. However, this is impractical for large ontologies with a large number of both named and complex classes.
Instead, we propose to determine implicit abbreviations by building on highly optimised
implementations of the standard reasoning service classification , i.e., the computation of all
entailed SubClassOf and EquivalentClasses axioms between named classes in a given
ontology [
The idea is to first introduce abbreviations for all complex class expressions that occur in a given ontology, then to compute its ICH, and finally to read of all implicit abbreviations from the ICH. So, more formally, for a given ontology , we create the ontology
= ∪ {EquivalentClasses (A, C) | C occurs in , A does not occur in } and compute ICH(). Since the ICH captures all SubClassOf and EquivalentClasses relationships between named classes in an ontology, it is straightforward to identify all named classes in that are equivalent to a newly introduced abbreviation A in . We will present a worked example of this approach and will discuss a number of technical details that are not mentioned in the high-level description outlined above.
Consider shown in Figure 1. The ontology consists of six axioms in which the six complex class expressions C1, . . . , C6, as shown in Figure 2a, occur. So, given these six class expressions, we construct the ontology
= ∪ {EquivalentClasses (A1, C1), . . . , EquivalentClasses (A6, C6)} where A1, . . . , A6 are newly created class names that do not occur in . We then classify and represent the resulting ICH by a transitive reduct (w.r.t. the SubClassOf relation) in which equivalent classes are grouped into collections. More formally, let [C] denote the set {C | |= EquivalentClasses (C, C)}. By abuse of notation let SubClassOf ([X], [Y]) denote the set of axioms {SubClassOf (X, Y ) | X ∈ [X], Y ∈ [Y]}. With this, the transitive reduct of an ontology’s ICH is defined as the set of SubClassOf axioms between equivalent classes, i.e.,
TR() = {SubClassOf ([X], [Y]) | |= SubClassOf ([X], [Y])}.
Figure 2 shows the transitive reduct for the ICH of (omitting ⊥ for presentational purposes). With this representation of the ICH, it is straightforward to read of all abbreviations in . For example, SpicyPizza is equivalent to A4, which in turn is equivalent to C4. So, SpicyPizza is an abbreviation for C4 in . Likewise, it is straightforward to identify complex class expressions without abbreviations. C1 = hasSpiciness some Hot C2 = PizzaTopping and (hasSpiciness some Hot) C3 = hasTopping some (PizzaTopping and (hasSpiciness some Hot)) C4 = Pizza and (hasTopping some (PizzaTopping and (hasSpiciness some Hot))) C5 = hasCountryOfOrigin value Italy C6 = Pizza and hasCountryOfOrigin value Italy (a) Complex class expressions in .
⊤ Hot
A3
Pizza
A5
PizzaTopping
A1 SpicyPizza, A4
A6
HotTopping, SpicyTopping, A2 DiavolaPizza
NapoletanaPizza (b) Visualisation of TR() without ⊥.
The subject of abbreviations in knowledge bases raises a number of research questions. We distinguish between four broad categories of such questions. The first category is about the prevalence of abbreviations in ontologies; both in terms of their definition (cf. Section 3.1) as well as their use (cf. Section 3.2). The second category revolves around how abbreviations, in the sense of concise but informative names for complex expressions, can be generated and used. The third category deals with the claimed benefits of abbreviations regarding improved ontology comprehension, maintenance, and use in practice. And, finally, the fourth category is concerned with the potential impact of abbreviations in the wider context of ontology engineering. For example, how do abbreviations afect common ontology engineering services, e.g., ontology alignment, visualisation, and reasoning only to name a few.
To develop a first understanding of abbreviations in ontologies, we focus on the first category in this work. In particular, we investigate the following questions: (Q1) How many abbreviations and synonyms are defined in ontologies? (Q2) How often are defined abbreviations and synonyms used? (Q3) How often is an abbreviation not used despite being defined?
We also shed some light on the search space of potential candidates (cf. Definition 6) for abbreviations. For this purpose, we investigate the following questions: (Q4) How often do complex expressions reoccur in ontologies? (Q5) How large are such reoccurring complex expressions? (Q6) What is the nesting depth of reoccurring complex expressions?
The notion of an abbreviation is based on entailment (cf. Definition 1). However, an OWL ontology is published as a computational artefact in a concrete syntax. Furthermore, the syntactic structure of an ontology cannot, in general, be assumed to be arbitrary. So, we distinguish between explicit and implicit axioms in the design of our empirical investigation. This investigation consists of four distinct inquiries that we use to analyse the latest international release of SNOMED CT (June 2022). These inquiries concern the (i) definition of abbreviations and synonyms, (ii) their use, (iii) the reoccurrence of complex class expressions, and (iv) the size and nesting depth of such complex class expressions. We give a brief description of each of these inquiries in the following: 1. Number of Abbreviations and Synonyms: We determine how many abbreviations and synonyms are defined in SNOMED CT (according to Definition 3). We count explicit and implicit definitions separately following the approach described in Section 3.3. Furthermore, we compare the number of abbreviations and synonyms to the number of named classes in SNOMED CT. 2. Prevalence of Abbreviation Use: We determine to what extent abbreviations are used (cf. Definition 4) and to what extent they are not used even though this would be possible (cf. Definition 5). We also determine to what extent diferent synonyms for abbreviations are used. 3. Reoccurrence of Complex Expression: We determine how often complex expressions reoccur in SNOMED CT, i.e., how often a given complex class expressions occurs more than once. Furthermore, we analyse to what extent such class expressions are associated with abbreviations or not, i.e., how many complex class expressions are potential abbreviation candidates. 4. Size and Nesting Depth of Complex Class Expressions: We determine the size and nesting depth of complex class expressions, where the size and depth of an expression are defined respectively as () = 1 and ℎ() = 0 if is atomic, and () = 1 + ∑︀ =1 () as well as ℎ() = 1 + max ℎ() 1≤≤ if = (1, . . . , ).
We use the international edition of SNOMED CT (June 2022) downloaded via the Unified Medical Language System Terminology Service (http://owlapi.sourceforge.net/). and use the Snomed OWL Toolkit (https://github.com/IHTSDO/snomed-owl-toolkit) to convert its release format (RF2) to OWL. All reasoning tasks are performed with ELK version 4.3 (https://github.com/ liveontologies/elk-reasoner). The empirical investigation is orchestrated using the OWL API version 5.1.15 (http://owlapi.sourceforge.net/).
SNOMED CT contains 357 095 named classes of which 131 954 (about 37%) qualify as abbreviations according to Definition 1. For 128 482 of these classes, SNOMED CT contains an explicit simple definition according to Definition 3. Otherwise, there are no explicit definitions of either abbreviations or synonyms. For 129 758 classes, only simple definitions can be inferred and for the remaining 2 196 classes, ambiguous definitions can be inferred. For 2 109 of these classes with implicit ambiguous definitions, SNOMED CT contains an explicit simple definition. This means that these 2 109 classes are equivalent to at least two complex class expressions, even though only one equivalence is stated explicitly. It is not clear whether this is intended in the design of SNOMED CT or not.
To summarise, we observe that the vast majority of abbreviations in SNOMED CT, i.e., more than 97%, are explicitly stated as simple definitions. There are only 3 472 classes for which no explicit definition can be found in SNOMED CT.
Yet, there are many abbreviations that are used at least once and up to ten times, namely 4 994 + 3 005 + 986 = 8 985. Furthermore, there is a fair number of abbreviations that are used more than ten times and up to 100 times, namely 285 + 103 + 23 = 411. These numbers show that many named classes in SNOMED CT are used as abbreviations (according to Definition 4). Otherwise, we observe that the use of implicit abbreviations is comparable to the use of explicit abbreviations.
Table 2 shows how many times a complex class expression in SNOMED CT gives rise to a possible abbreviation use according to Definition 5. For example, the last column tells us that there are two explicitly defined abbreviations that could be reused more than 100 times in SNOMED CT. Here, we find that most complex class expressions associated with an explicit abbreviation do not give rise to any possible abbreviation use. This means that such complex class expressions do not occur SNOMED CT other than in an abbreviation’s definition (which is not counted as a possible abbreviation use). However, there is also a fair number of complex class expressions that give rise to more than 10 possible abbreviation uses, namely 34+18+2+2 = 56 in the case of explicitly defined abbreviations, and 42 + 4 + 1 + 1 = 48 in the case of implicitly defined abbreviations.
51–100
Complex Class Expressions (ordered by reoccurrence) two, while the remaining 1 217 exhibit a nesting depth of 1. Similarly, the size of most such complex class expressions is comparatively small: 1 217 expressions exhibit a size of three, 195 exhibit a size of 5, and only 76 expressions have a size larger than 5.
However, it is important to note that there are instances of large complex class expressions with many occurrences in SNOMED CT. For example, the complex class expression at the index 1 311 in Figure 3 has a size of 15 and occurs 395 times. Expressions of this size are arguably hard to read and comprehend and might be good candidates for the introduction of an abbreviation.
Logical equivalent rewritings for ontologies are usually motivated for the purpose of improved
reasoning performance [
In the work presented in this paper, the focus is not on rewritings that are minimal in size. Rather, we study to what extent domain-specific vocabulary defined in an ontology can be reused to simplify otherwise complex expressions. The main argument being that a meaningful name is more readily understood by domain experts compared to its technical representation in a knowledge representation language, i.e., a complex class expression in OWL. It is important to note that the associated reduction in size is secondary in this context.
The task of determining abbreviations in an ontology (cf. Section 3.3) can be interpreted
as concept definability, i.e., the problem of finding a definition for a concept name in an
ontology [
So far, research into logical rewritings of ontologies for improving their comprehension has focused on reducing the size of logical expressions. However, this strategy may not always be appropriate in practice. For example, an axiom of the form EquivalentClasses (A, C1, C2) for a named class A may in fact capture two diferent ways of interpreting A, namely C1 and C2 — both of which may be useful in diferent contexts. In such a case, replacing all occurrences of both C1 and C2 in an ontology with A (excluding its definition), would lead to a more concise representation but doing so would remove information about the two diferent ways of interpreting A in diferent contexts.
So, the question of when to use an abbreviation may be subject to pragmatic considerations that
may vary between use-cases. Developing an understanding of what makes a logical expression
easier to understand or use in diferent contexts will require an evaluation of diferent rewriting
strategies with user studies. Some work in this direction already exists for understanding
justifications of entailments [
Besides the question of when to use an abbreviation, is the question of when to introduce a new abbreviation. We have proposed the notion of an abbreviation candidate (cf. Definition 6) that is based on the number of occurrences of a complex expression in an ontology. However, heeding our caution against using conciseness as the primary goal for rewriting ontologies, we also caution against introducing abbreviations solely based on their potential to replace many occurrences of a complex expression. Rather, many occurrences of a complex expression should only be seen as an indication for an abbreviation candidate.
Orthogonal to the introduction of a new abbreviation is the choice of its name. This name
should be concise but informative so that it conveys relevant parts of its formal representation.
The problem of finding a suitable name for a complex class expression involves two separate
tasks. First, the complex class expression needs to be verbalised into a description of what the
expression represents. And second, given such a description, one needs to find a word that
matches the description. Intuitively, the second task can be seen as the inverse operation of a
dictionary lookup. Instead of looking up the definition of a given word, one looks for a word
given a description. As there already exists work for both of these two tasks, i.e., verbalising
OWL expressions [
Lastly, it needs to be highlighted that the introduction of an abbreviation, as defined in this
work, changes the meaning of an ontology. Consider the ontology and = ∪ { } where
= EquivalentClasses (A, C) is a definition for an abbreviation A. If A does not occur in
, then ̸≡ because |= but ̸|= . This change in meaning can be avoided by
encoding abbreviations using a meta-language, e.g., OTTR [
Napoletana Diavola Hawaiian
SubClassOf Pizza and hasCountryOfOrigin value Italy, SubClassOf Pizza and hasCountryOfOrigin value Italy,
SubClassOf Pizza and hasCountryOfOrigin value Canada
defined, so that can be encoded as = {
Napoletana Diavola Hawaiian
SubClassOf ItalianPizza, SubClassOf ItalianPizza,
SubClassOf Pizza and hasCountryOfOrigin value Canada Note that ItalianPizza is not an OWL class but an expression in OTTR. In particular, the ontology is semantically equivalent to because the OTTR expression ItalianPizza is indistinguishable from Pizza and hasCountryOfOrigin value Italy on the level of OWL. The use of a meta-level language also opens up possibilities to summarise representations on higher levels of abstractions. In the case of the example ontology , the representation of a pizza’s country of origin could be captured by a parametrised OTTR expression PizzaWithOrigin() ↦→ Pizza and hasCountryOfOrigin value . With this, all three pizzas in can be encoded in a uniform manner giving rise to the following even more succinct encoding: = {
Napoletana Diavola Hawaiian
SubClassOf PizzaWithOrigin(Italy), SubClassOf PizzaWithOrigin(Italy), SubClassOf PizzaWithOrigin(Canada) }
In this paper, we proposed a method for analysing how names in ontologies are defined and used. We used this method to conduct a use case study on SNOMED CT. We find that a large proportion, namely 37%, of named classes are defined to be equivalent to more complex class expressions (cf. Section 5.1). This finding suggests that concrete names for more complex ideas play an important role in SNOMED CT’s design.
Furthermore, we find that such names are often reused (cf. Section 5.2). This finding suggests that concrete names for complex ideas seem to be preferred in SNOMED’s design compared to their more complex logical representations. However, we also found a number of instances in which this is not the case. Whether this is intended or whether these cases are undesired efects of an automated workflow in which complex class expressions are generated will need to be determined by further research.
Lastly, we investigate the phenomenon of reoccurring complex class expressions that are not associated with a dedicated name. Here, we find that there are cases of complex class expressions that occur frequently in SNOMED CT and are non-trivial in both size and depth (cf. Section 5.3 and Section 5.4). These findings motivate further research into generating concise but informative names for complex class expressions for the purpose of improving ontology comprehension. } }