What's the difference between a bottom-up and a top-down ontology modeling approach?

Technical Q&A
, ,
#1

In general, there are many approaches to create data models and ontologies.

The two common ones are:

  1. Top-down: from abstract to concrete
  • The ontology is created in an abstract way, first by defining general concepts of the domain and then by classifying them into specific hierarchies.
  • These models might be too generic and cover more than the existing data structures by adding “empty” concepts without any data that represents them.
  • The opposite might also occur - they might not reflect the true nature of the data structures and could miss some of their important characteristics.
  1. Bottom-up: from concrete to abstract
  • They usually start with existing data structures, defining specific concrete concepts (the leaves of the hierarchy).
  • These concepts are usually physical, application-specific, and incomplete from an enterprise perspective.
  • They may not promote data sharing and abstractions, especially if they are built without reference to other parts of the organization/domain.

Choosing either approach is valid based on one’s different world-view and philosophical theories.

A combination of the top-down and bottom-up approaches is also possible: A middle-out approach - from the most relevant to the most abstract and most concrete.

In the middle-out approach :

  1. You start with the most important concepts in your organization/domain
  2. You try to generalize them by adding high-level concepts
  3. You add the relevant application-specific concrete concepts and try to generalize them either by adding middle-level concepts or by connecting them directly to the high-level ones

In my opinion, the best approach to start modeling an ontology is to look for existing ontologies (like FIBO for the financial domain) and try to reuse them as much as possible using the middle-out approach.
Import the relevant concepts from the existing ontology and then follow the steps of the middle-out approach.
This process should be iterative - as you might make mistakes along the way, and you want to detect them as soon as possible to avoid unnecessary work.

Sources:

https://protege.stanford.edu/publications/ontology_development/ontology101-noy-mcguinness.html
http://129.215.32.99/publications/documents/1996/96-ker-intro-ontologies.pdf

5 Likes
#2

I agree with the middle-out approach. A good resilient/adaptive ontology requires careful selection of the abstract elements so that the interconnections work effectively. A great ontology is characterized by its conciseness, how easy it is to understand, its durability, and how easy it is to extend whilst still retaining these essential properties. It takes a lot of skill to achieve this without producing unwieldy results. I have seen some of the poorer practices from the ER modeling world being replicated in contemporary ontology modeling, where bottom-up or insufficient abstractions lead to brittle models that do not stand the test of time (don’t adapt well). For similar reason, I’m not a fan of direct re-use domain-specific models such as FIBO; though I do accept that borrowing some of the important elements, adding them to your own model can be effective for productivity, communication, and also support interoperability within certain industries.

3 Likes