It recently occurred to me though that there is a great deal of confusion with regards to what a taxonomy is, and how it should be designed, constructed, and managed. Often this is simply because people have different backgrounds and intents when dealing with taxonomies, so they end up overseeing a great deal of scientific work that already exists on this area.

What are taxonomies?

Let’s start by looking at a simple taxonomy. Here’s one that I could use in order to sort out the junk I have accumulated in my backyard:

- hardware
--- pc tower cases [2]
--- pc accessories  [4]
- toys
--- construction toys 
------ meccano [1]
--- dolls [3]
- kitchen stuff
--- plates [10]
--- old cutleries [14] 

So what is a taxonomy? In general the aim of a taxonomy is to organise things into groups, according to some perceived similarities (e.g. structure, role, behaviour, purpose etc.). Not surprisingly this is what the Greek root ‘taxis’ means: putting things into order.

If you want a fancier definition, a taxonomy can be defined as a conceptual tool for classification. It’s a way to bring order to a domain of interest that can be composed by objects of any kind (e.g. physical or abstract, real or invented). A taxonomy normally plays the same role of an inventory or a list, for it describes what kind of things are available in a certain context and thus lets us carry out some task more efficiently within that context. For example, finding objects of interest, or comparing objects with similar characteristics.

I just said that a taxonomy is similar to a list or inventory of things; actually, that’s not correct. A taxonomy is much more than a list of concepts, in fact its key feature is that is organizes the concepts within a hierarchical structure. This is called the taxonomical tree.

root node
-- sub-concept-1
-- -- sub-concept 1-1 (leaf node)
-- sub concept 2
-- -- sub-concept 2-1 (leaf node)

The taxonomical tree is composed by nodes and links. In particular, the links are very important here as they offer a (more or less) explicit definition of the relationships among the categories that describe your ‘stuff’. In other words, a taxonomy acts a little bit like a map: it tells you what kind of things exists, and also how they can be meaningfully organized into a coherent framework.

So for example in biology we could have a taxonomy that organizes cell entities based on a (spatial) whole-part relationship:

Cell (Eukaryotic)
--Membrane
--Cytoplasm
----Mitochondria
----Nucleus
------Chromosomes
------Nucleolus

Consider now the case of a music magazine; here it might be more appropriate to construct a taxonomy based on a (thing-kind) sub-genre relationship:

rock
--blues rock
--hard rock
--heavy metal
---- speed metal
---- progressive metal

Finally, we can think of a mountaineering club that keeps an organized list of the instances of expeditions done by its members, by means of an instance-of relationship (or ‘example’):

Mountain
--Mount Everest
--Mount Kilimanjaro
Canyon
--Samaria Gorge
--Grand Canyon

So, in general, there can be many variations of ‘taxonomical maps’: spatial maps, thing-kind ones, thing-example ones etc.. And here’s the good news: the key to understanding how taxonomies work (and hence how to design them successfully) is to be able to identify and evaluate the implications of these variations.

The taxonomical relationship

I think it’s clear by now that the rationale for the hierarchical structure used by a taxonomy is not always entirely transparent. The meaning of the links that makes up the main taxonomical tree (the taxonomical relationship) is somehow left implicit. In fact, unless we have some accompanying documentation that defines the intended meaning of the relationship between one node and its parent(s) and children, it is up to us to interpret its sense.

This is often not a problem. If you look at the examples above, it is likely that you’d immediately understand what the taxonomical relationship stands for: e.g. part-of, type-of, broader-topic-than, instance-of etc..

However if your taxonomy has been growing over time, the situation could be rather different. An increasing number of relationships may have been used to construct a single tree, making it difficult for new users to make sense of the taxonomy, or for expert ones to update it without generating conflicts.

It is good practice then (especially if the taxonomy aims at being reused) to use a single relationship consistently throughout the taxonomical tree; also, to identify explicitly what the meaning of the taxonomical link is. As we will see in the next part of this post, this will make your work much more extendable and reusable.

The project started this July, it is based at King’s College London and is funded by the Leverhulme Trust. I’m more involved with the digital aspects of the project, and as usual one of the first steps involved in the building of a digital resource (in particular, a database-backed digital resource) is the construction of a conceptual model that can represent the main types of things being dealt with.

In other words, it is fundamental to identify which are the things our database and web-application should ‘talk about’; later on, this model can be refined and extended so to become an abstract template of the data-manipulation tasks the software application must be capable of supporting (e.g. entering data into the system, searching and visualising them).

Here’s a nice example of the sculptures (a sarcophagus from Aphrodisias) that constitute our ‘source’ materials:

What are the key entities in the sculpture domain?

To this purpose, a few weeks ago we had a very productive brainstorming session aimed at fleshing out the main items of interest in the world of sculpture. This is a very first step towards the construction of a formal model for this domain; nonetheless, I think that we have already managed to pin down the key elements we’re going to be dealing with in the next two years.

Here’s a list of the main objects we identified:

• – People, such as craftsman’s etc..
• – Sculptures (of various kinds)
• – Materials
• – Tools
• – Generic processes that are part of a sculpting project, such as quarrying and transport.
• – More specific methods being used within a particular process, e.g. carving styles, or approaches to quarrying.
• – Traditions, conceptualisations of the ‘way of doing things’ that, in turn, can inspire the way methods and processes are carried out nowadays.

We encoded the results of our discussions in a mind map for better readability, and also in order to use a technology that would make it easier to share our findings later on. I added it below.. (in case the interactive image doesn’t work, you can find it here too).

Fleshing out the model a bit more

After a few weeks of work we did a reiteration of the conceptual map above. The good news was that it soon became evident to us that we got it quite right on the first round; that is, we didn’t really feel like adding or removing anything from the map.

On the other hand, we thought we should try to add some relations (= links, arcs) among the concepts (=bubbles) previously identified, so to characterize their semantics a bit more. I had a go at adding some relations first, and here’s the result:

I should specify that I have no knowledge whatsoever of the domain of sculpture, so the stuff I added to the map came out entirely from the (little) research I’ve been doing on the subject (on and off) during the last weeks.

At the same time, also Will and Ben (the art historians I’m collaborating with) worked independently at the task of fleshing out the mind map with more relations. Needeless to say, what they came up with is way more dense and intricate than what I could have ever imagined! This is probably not surprising, as one would expect to see a significant difference between a non-expert’s representation of a subject domain and another one which is instead created by experts. Still, it was interesting to see it happening with my own eyes!
Here it is:

The next step will be trying to reduce the (natural) complexity of the portion of the world we are representing to a more manageable size… then, formalize it, and start building our database based on that.. stay tuned for more!