Post-coordination: Making things up as you go along


Pre- and post-coordination are notions that came out of SNOMED and concerns how the vast number of terms needed for coding, in SNOMED’s case, medical records; can one enumerate all needed terms and put them in the right place in a structured vocabulary before use, or does one put in a mechanism for creating terms as and when they are needed and putting them in the right place in the vocabulary’s structure? A pre-coordinated ontology has all the terms and relationships between them needed by an application; it is static; ‘what you see is what you get’. A post-coordinated ontology has the building blocks for the terms needed in an application such that they can be built as required, and so that their relationship can be determined as required; it is dynamic; the ontology is much more than ‘what you see’, since you can compose new expressions from the given building blocks. An ontology built using the Web Ontology Language (OWL) can take a compositional approach; it is built/can be used by composing classes and properties to make other classes. For example, an expression for large hydrophilic amino acid could be composed from the classes Hydrophilic amino acid and Large amino acid; in turn, these can themselves be composed of Amino acid and various qualities of amino acids. In this approach a reasoner can be used to determine the relationship between on-the-fly built expressions and the classes from the base ontology, i.e., expressions can be classified and placed at the correct location in the class hierarchy. This KBlog describes post-cordination, distinguishes it from pre-coordination, and discusses when post-cordination can be used, either at build time or delivery time within an application.


Robert Stevens and Uli Sattler
Bio-health Informatics and Information Management Groups
School of Computer Science
University of Manchester
Oxford Road
United Kingdom
M13 9PL and


The notion of pre- and post-coordination [1] is used in terminologies such as <a href="”>SNOMED CT and is used to manage the vast number of terms required for coding medical records, but without having to enumerate them all. Though arising from SNOMED, the idea of pre- and post-coordination is widely applicable wherever ontologies are used to describe things and it is likely that not all the desired terms can be made before use. To illustrate, assume we have a (possibly very long) list of expressions e1, e2, e3,… that we want to use in a given application, e.g., to label documents. Large hydrophilic amino acid is an example of such an expression. Also, assume that we have an ontology, vocabulary, or similar, called O, for these terms. Now _pre-coordination and post-coordination relate to the following questions:

If we answer the first and third question with yes, then we can say that O is pre-coordinated. If we answer the second and third question with yes, then O can be post-coordinated, and the degree to which it is depends on the number of expressions ej for which O does not contain a single term, but requires the construction of a suitable expression. Finally, O can be both pre-coordinated and post-coordinated: e.g., O may have a term for large hydrophilic amino acid, but may also be able to handle the expression Hydrophilic amino acid and Large amino acid. This can be illustrated with some examples using the Amino Acids Ontology. First of all, we can simply name a class of amino acid called Lysine.

Class: Lysine
        SubClassOf: AminoAcid

Lysine is a named class, and we have already stated how it relates to AminoAcid: it is a specialisation of it. We can further co-ordinate Lysine with other classes in the ontology to describe Lysine in terms of those classes, and we can do so for all 20 amino acids; descriptions of each of these can be composed from charge (positive, neutral or negative), polarity (polar and non-polar), size (tiny, small, medium and large) and hydrophobicity (hydrophilic or hydrophobic); here is this description for Lysine:

Class: Lysine
        SubClassOf: AminoAcid,
        hasHydrophobicity some Hydrophilic,
        hasSideChainStructure some Aliphatic,
        hasCharge some Positive,
        hasSize some Large,
        hasPolarity some Polar

We can also introduce terms for other classes of amino acids, e.g.:

Class: 'Positive amino acid'
        EquivalentTo: AminoAcid
                and hasCharge some Positive

Class: 'Hydrophilic amino acid'
        EquivalentTo: AminoAcid
                and hasHydrophobicity some Hydrophilic

Using the resulting ontology, I have two choices:

In this sense, we should rather speak about using an ontology in a pre-/post-coordinated way, and note that using an ontology in a post-coordinated way requires a reasoner (or similar tool) to determine the relation between the freshly made up expressions and those specified in the ontology. Similarly, we can say that an annotation tool supports post-coordination if it allows annotations in the form of expressions, and is able to determine the relationships between these expressions.

Why is it so groovy?

If we know that we are going to use an ontology in a post-coordinated way, then we know that we don’t have to introduce terms/named classes for each expression that we ever want to use – we can make them up given the base vocabulary from the ontology. As a consequence, we can build our ontology

So, in a nutshell, one gets classes on demand, together with their relationships. The ontology provides the building blocks and a class that gives a description is made when it’s needed. Of course, one can judge when it is worth naming a class and putting it in the ontology – when it’s frequently used or used as a part of another expression etc etc. By not putting all possible classes into an ontology one saves space, clutter, increases comprehensiblity etc.

Why is it hard?

Of course, it can’t all be positive: If an ontology is used in a post-coordinated way,

That’s all we can think of.

The last word

The act of composing one class with others and then linking it to other classes is coordination. This can be done exclusively at the time of building the ontology, which we can then use in a pre-coordinated way. Alternatively, an OWL ontology can be used in some software, e.g., to deal with document annotations, together with an automated reasoner. This means that classes can be composed or coordinated on the fly, with the reasoner placing the newly minted class in the appropriate place in the ontology’s hierarchy. In this case, this is post-coordination.


  1. A. Rector, and L. Iannone, "Lexically suggest, logically define: Quality assurance of the use of qualifiers and expected results of post-coordination in SNOMED CT", Journal of Biomedical Informatics, vol. 45, pp. 199-209, 2012.