There are many methodologies and techniques for easing the task of ontology building. Here we describe the intersection of two of these: ontology normalisation and fully programmatic ontology development. The first of these describes a standardized organisation for an ontology, with singly inherited self-standing entities, and a number of small taxonomies of refining entities. The former are described and defined in terms of the latter and used to manage the polyhierarchy of the self-standing entities. Fully programmatic development is a technique where an ontology is developed using a domain-specific language within a programming language, meaning that as well defining ontological entities, it is possible to add arbitrary patterns or new syntax within the same environment. We describe how new patterns can be used to enable a new style of ontology development that we call hypernormalisation.
Building ontologies is a difficult and time-consuming business for a number of reasons: from an abstract point-of-view knowledge about the domain can be difficult to gather, to understand and to represent ontologically; more, immediately, ontologies, especially those with a complex representation, can be taxing to describe and define consistently, to update, expand or change when that representation needs to change.
There have been numerous attempts to simplify and clarify
this process including: the development of methodologies such as
OntoClean that defines a set of meta-properties that can inform
ontological modelling
Another approach that can leverage both of these techniques is
ontology normalisation
Broadly, a normalised ontology is defined using a skeleton that is
a strict tree (i.e. not a acyclic graph) of concepts differentiated using
an inheritance (i.e. not a partonomy) relationship. These are further
split into: a set of self-standing entities in which children are disjoint
from each other, but do not cover the parent, and partitioning or
should
addressed:
refining concepts that form closed, covering and disjoint hierarchies.
Building an ontology in this way, allows the ontology developer to
exploit the reasoner to build a polyhierarchy by using classes that
define the self-standing entity in terms of the refining partitions.
Polyhierarchies are difficult to build manually, as human ontology
developers, no matter how good their domain knowledge, find it
hard to ensure all possible parents of an entity are taken into account.
The normalisation approach uses defined classes and reasoning to
remove this chore. Creating the tree of self-standing entities still,
however, remains as a task for the developer. The normalisation
approach can significantly increase the robustness and reduce the
work of manual maintenance
While the term “ontology normalisation” has been borrowed,
somewhat metaphorically, from database engineering, the process
of building ontologies using a set of standard design patterns
has a rather more direct relationship to the software engineering
equivalent. By reusing a standard set of patterns, it is possible to
build an ontology both rapidly, and consistently. This has manifested
itself in a number of different ways, with a number of different tools,
such as TermGenie
We have previously described a fully programmatic methodology
for ontology development
In this paper, we describe an extension of the normalisation
technique that we call hypernormalisation. This technique is
typified by the (near or complete) absence of asserted hierarchy
among the self-standing entities. We describe how this allows
construction of an exemplar ontology of amino-acids
Top Level SelfS-tanding Entities
Refining Type Body Substance
Person
Role
Value Types in the Tawny-OWL environment, including the definition of two new design patterns, the tier and the facet, and one syntactic abstraction, the gem, can be used to enable hypernormalised ontology development. Finally, we discuss the application of this approach to other ontologies. 2
Normalisation is a methodology that aims to disentangle an ontological structure, in the process managing its maintainability, utility and expressivity of the ontology generated. To achieve this, the ontology is split into two main hierarchies: self-standing entities and refining types, see Figure 2 for an example. The self-standing hierarchy contains entities with a central hierarchy or skeleton. In this part of the ontology, we would expect that hierarchy contains levels that are not-exhaustive – that is the children do not cover the parents, and parents are not closed to new children. This is contrasted by the refining hierarchy that consists of classes that are exhaustive; in many cases, children will be nonoverlapping and, therefore, disjoint. This is not to say that the refining types hierarchy are necessarily complete: in Figure 2, for example, the representation of Sex is too simple for many medical uses, but might be sufficient for a customer relations system. In general, the self-standing entities will be defined in terms of the refining types, while polyhierarchical relationships between the self-standing entities will be determined through use of a reasoner.
This form of ontology development is quite different from an
upper ontology and agnostic to the choice of upper ontology or
none. While
We next introduce the amino-acid, used here as an exemplar, which defines the biological amino-acids in terms of the physiochemical properties most relevant to their biological role. It is a structurally interesting ontology because it is normalised, with a clear and clean separation between the self-standing entities and the five refining concepts. It is rather more than this, though; the self-standing entities are split into only three sets: the aminoacids themselves (e.g. Alanine); a (very large) set of defined classes describing the refined types of amino-acid (e.g. Small Neutral Amino Acid); and, finally, the single class Amino Acid. Or, stated alternatively, it contains no skeleton hierarchy at all, and all relationships between the self-standing classes are arrived at through reasoning. This is particularly relevant for the amino acid ontology as it contains over 500 defined classes, with subsumption relationships to the amino acids and between themselves. Maintaining this form of ontology by hand would be impractical.
We call this style of ontology development hypernormalised.
We believe that it is a natural extension of normalisation. Rector
notes, for example, that the choice of aspect to form the skeleton
is “to some degree arbitrary”, but that they should be rigid (after
OntoClean
We note that the distinction between normalisation and hypernormalisation is not absolute, but one of degree; we are simply describing the tendency toward an ontology with an flat asserted hierarchy.
Having introduced the notions of a hypernormalised ontology, we next consider a set of new patterns in Tawny-OWL that enable this style of ontology development. 3
The Tawny-OWL environment
Top Level SelfS-tanding Entities Refining Type Defined Class
Amino Acid
Alanine
Arginine 18 more
Size
Charge
Hydro.
Polarity
SideChain Small AA
S. Neutral AA
S. N. Aliphatic AA 500 more
Tiny
Small
Large
Tawny-OWL itself wraps the OWL API
:super B)
This declares a new class A that has the pre-existing class B as a superclass 1 which in Manchester OWL notation would be expressed as:
This code is entirely valid Clojure and can be evaluated in any Clojure environment, such as CIDER/Emacs or Cursive/IntelliJ. It is also possible to define new patterns: for example the following pattern definition: (defn some-only [property & clazzes] (list (some property clazzes)
(only property (or clazzes))))
defines the some-only pattern which generates a set of
existential restrictions and one universal with the union of the
existential fillers as its filler, which implements the ontological
closure pattern. This is a function definition in Clojure terms: defn
introduces the function, property & clazzes is the argument
list, some, only and or are functions provided by Tawny-OWL
and list returns, prosaically, a list2. Critically, it is possible to
1 See
Tawny-OWL is now a mature and used software product; the first alpha release of Tawny-OWL was in Nov 2012, first full release, Nov 2013, followed by four point releases to 2016. This paper describes mostly the upcoming v2.0 release, although some of the features described were available in earlier versions. 4
A common pattern for building a normalised ontology is called the
value partition. This pattern
Axiomatically, this expands into: a class Size; three subclasses, Tiny, Small and Large; and, a property hasSize. The 3 For those with knowledge of Lisp, this is actually a macro; the main implementation is in the value-partition function. Tawny-OWL provides support for implementing syntactic macros whose function is simply to allow the use of bare symbols. For those without knowledge of Lisp, the distinction is not important! property is functional, has range of Size and domain of AminoAcid. Expanded, this would be expressed as follows4:
The subclasses are disjoint and cover the parent. Following the
terminology from
The value partition is a pattern aimed at a specific purpose – segmenting a continuous range. In practice, though, we have found that the axiomatization of this pattern is more generally useful. For example, considering the amino-acid ontology, it is natural to model the chemistry of the side-chain as such: (defpartition SideChainStructure [Aromatic Aliphatic] :domain AminoAcid :super PhysicoChemicalProperty)
While this is intuitive, ontologically, SideChainStructure
is actually of a very different form from Size, as it does not reflect
a spectrum. Either the side-chain contains a benzene ring, making
it aromatic, or it does not. This form of partition was also noted
in
The use of :suffix true causes a simple change to the naming of the entities: Positive will become PositiveCharge which would be expanded as follows:
Other names are modified equivalently. By default, this will manifest both when referring to the class in the Tawny-OWL environment, in the IRI of the concept when serialized as OWL, and in the value of an annotation on the concepts5. In addition to naming, it is also possible to optionalise: whether or not the subclasses are disjoint, covering, whether the property is functional or whether it is created at all.
The tier is a more general pattern than the value-partition; in fact, in the current version of Tawny-OWL, the latter is defined in terms of the former. 6
Both the value partition and tier introduce a new object property
named after the tier, and with a range limited to the classes defined
within the tier. The converse is also true; where we use one of the
tier classes, such as PositiveCharge it is most likely that we
wish to use it with the hasCharge property defined as part. Taken
together, we describe the combination of classes and a property as a
facet. Facets are a well known technique, first proposed in a library
classification (the Colon Classification
Tawny-OWL provides explicit support for facets, allowing the association of a property and a set of classes, as demonstrated by the following code: (as-facet hasCharge
The practical implication of this is that we can now use the facet function to return an existential restriction providing just a class. We can express this programmatically; for example, we might use the assert function provided by Clojure’s unit test framework. (assert (= (some hasCharge Positive)
(facet Positive)))
By itself, this ability is only slightly more succinct. However, when used with multiple facetted classes, the advantages become considerably clearer, as can be shown by the following assertion. (assert
(= (list (some hasCharge 5 The duplication between the annotation and the IRI fragment is there because IRI schemes such as numeric style OBO IDs; annotations have been elided for brevity
In addition to succinctness, this pattern also reduces the risk of errors; a class such as Tiny will always be used with its correct property. Without the use of facets, the ontology developer must achieve this by hand. It would also be possible to detect the error using reasoning, although this will only succeed if appropriate range and disjoint restrictions are in the ontology. The defpartition and deftier functions, of course, both add these range and disjoint restrictions and declare their classes as facets of their properties. 7
THE GEM
Finally, we define the gem that provides a syntactic abstraction for
a class composed entirely or mainly from facets. Following the
terminology from
:comment "An amino acid with a single methyl group as a side-chain." :facet Neutral Hydrophobic NonPolar
The other amino-acids can be likewise defined as a series of
gems. In fact, the amino acids are so regular, all having the same
five facets, that we use a further syntactic abstract specific to
the amino-acid ontology – a form of pattern that we describe as
localized
We have previously discussed the relationship between a design methodology such as normalisation and the use of an upper ontology. The Tawny-OWL patterns described here are all orthogonal and agnostic to the choice of an upper ontology or to none. They do not place their entities in any particular part of the class hierarchy nor define classes outside of those required for the domain ontology, although they could be easily extended to do so should the ontology developer require.
However, we agree with
In this paper, we describe how we have used Tawny-OWL to provide higher-level patterns which can be applied to ontology development. The patterns provide both functionality and syntactic abstraction over the underlying OWL implementation. In the process, they enable the easy and accurate construction of ontologies.
More specifically, we demonstrate two new patterns: the tier and the facet. The tier is an extension of the existing value partition pattern and can be used for the generation of many small hierarchies that can be used as refining properties. The facet borrows from the library sciences notion of a facetted classification, and is used to associate a set of classes with a specific set of values. This form of classification is very common in the web; the majority of web stores, for example, offer facetted browsing, often with the facets changing for different subsections of the catalogue.
Taken together, these two patterns enable a new form of ontology development, hypernormalisation, which is an extreme form of normalisation. In this form of normalisation, we do away with the creation of a tree of self-standing entities and instead rely on the reasoner to build all the hierarchy. As well as making the ontologist’s task easier, it makes the characteristic that would have been used to create the tree of self-standing entities explicit in the form of a refining characteristic. Here, we have described the application of this methodology to the exemplar amino-acid ontology. Of course, it is dangerous to extrapolate to generality from an exemplar, but we have also started to apply hypernormalisation to ontologies of other, more real, domains including clouds (in the meterological sense), cell lines and a reworking of the Gene Ontology. The tier has been made generic; it does not require, for example, that all refining types are closed (i.e. all possibilities are known in advance) nor disjoint.
Clearly, not all forms of ontology will naturally be represented
in a hypernormalised form. For example, the Karyotype
ontology