Disclaimer: I have limited experience building domain models, this is purely asked out of interest to those who do

I have recently stumbled upon the concept of representing data models with ontologies. It seems like it would be a great method for specifying the domain model used by an organisation's software systems.

My questions are:

  1. When it worth formally specifying a domain model in a format like an ontology? E.g. I've read that 'complex knowledge systems' such as biomedical cataloguing software use them, but would they be too much extra work for a typical business applicaiton?

  2. Is it generally better practice to not have a representation of a domain model which is separate from the software? I.e. having the software be the single-source-of-truth for the domain model

2 Answers 2


In general domain models in software engineering are represented in UML and most UML class diagram constructs can be translated to an ontology. I have written about this here.

Benefits of ontologies for software engineering

The benefit of translating a UML class diagram to an ontology is that since the ontology is backed by artificial intelligence reasoning procedures, it can determine whether there are logical inconsistencies in your UML class diagram. Such logical inconsistencies are difficult to find via typical unit testing (once the class diagram is implemented in code) since the logical inconsistencies typically arise from the relations between classes rather than a single class which is usually the focus of unit testing. Moreover, besides highlighting inconsistencies, ontologies can provide reasons for why an inconsistency happened, which is helpful to eliminate the inconsistency.

Why ontologies are not used extensively in software engineering

If ontologies are so helpful, why are they not used extensively in software engineering? I think there are 3 main reasons (in my opinion):

(1) In my experience very few people seem to be aware of ontologies so that option is just not on their radar to start with.

(2) Many companies forgo requirements engineering completely or do a watered down version of requirements engineering due to time to market pressures. Hence, it is often up to the developer to "spec" the requirements and when left with the choice to code or draw a UML class diagram many developers will prefer writing code immediately.

(3) Tool support is a problem. Though there are a number of tools to create ontologies and reason over them, there are no tools for translating between UML and ontologies. Even in the absence of tools, one can do the translation by hand. One certainly has to become knowledgeable about mathematical logic underlying ontologies, which is not trivial, but the translation between UML and ontologies is well understood and there are sort of "patterns" for doing the translation. So the absence of tools for the translation presents a challenge, but it is not an obstacle. It does slow one down however.

When to use ontologies for software engineering

Taking into account the limited skills in ontologies and limited tool support I would say it makes sense to use it where the business logic is complex and/or the impact of getting the business logic wrong will have severely negative consequences for the business. As an example, I have helped a business analyst to design the domain model for the costing model of a company where they had in excess of 2000 permutations. This number of permutations made it very difficult for the stakeholders to think about the problem.

Part of the problem is that stakeholders often have fuzzy concepts in their mind with many concepts overlapping. The job of a business analyst is to untangle these concepts, but even for an experienced business analyst it can be difficult to articulate exactly which concepts in a domain model are problematic and why. The reasoning and explanation services of ontologies can give helpful insight in this regard.

In designing the ontology for the costing model, the inconistencies helped stakeholders to realize that their concepts are fuzzy and the explanations helped the business analyst to understand in what why the concepts are fuzzy and to propose alternatives.

Why you should consider having a domain model outside of your code

When the domain model can only be found in the code, it is only accessible to the software developers. It is not accessible to business analysts, testers, project managers, users, business stakeholders and sponsors. The biggest benefit to having a domain model outside of the code is that it enables a shared understanding of a system for all stakeholders, not just for software developers. Such a shared domain model fosters a shared understanding which results in less time being wasted due to miscommunication because of the need to translate between "developer terminology" and "business terminology".

UPDATE 20180513 - Wrt comment on modelling

In this question on stackoverflow, the accepted answer claims ...OWL purpose is not modelling...It should be distinct from any software engineering process... claiming that ontologies are better for 'knowledge representation' rather than 'data modelling'. What is the main distinction here?

The purpose of OWL is to describe concepts and the relations that exist between concepts. As such OWL can be seen as a conceptual modelling language. What is conceptual modelling? In my dissertation I have defined it as follows:

Conceptual modelling is the act of documenting a domain to facilitate understanding and communication between stakeholders. The artefact resulting from the conceptual modelling activity is called the conceptual schema. A conceptual schema is an abstraction of the conceptually relevant aspects of a domain from a particular point of view. Implementation specific details are excluded from a conceptual schema. A particular domain may be described by a number of different conceptual schemas.

UML is a general-purpose modelling language designed for use in the analysis, design and implementation of object-oriented software systems. Object-oriented analysis is distinguished from object-oriented design in that the focus of object-oriented analysis is to elicit and describe the classes and objects that form part of the problem domain, while the focus of object-oriented design is on designing the software solution consisting of objects and related collaborations that would fulfill the requirements. Thus, object-oriented analysis is strongly related to conceptual modelling while object-oriented design is strongly related to the implementation details of realizing the conceptual schema in code.

The key difference

OWL can be used to define the conceptual model/domain model of your software system (object-oriented analysis). However, OWL will be a bad choice for defining the implementation details of your software system (object-oriented design). Why? The implementation of a software system aims to realize the conceptual model while meeting various architectural quality attributes like performance, scalability, integratability, security, etc. These implementation details fall outside the scope of OWL. This is part of the reason why I believe the conceptual model/domain model should be available outside of the code base. In aiming to meet various quality attributes, the domain model is often obscured in the code base.

  • the word translated refers "henrietteharmse.com" which appears to be your site. In this case please provide explicit affiliation disclosure as explained eg here
    – gnat
    May 12, 2018 at 13:04
  • In this question on stackoverflow, the accepted answer claims ...OWL purpose is not modelling...It should be distinct from any software engineering process... claiming that ontologies are better for 'knowledge representation' rather than 'data modelling'. What is the main distinction here? May 12, 2018 at 22:33
  • 1
    @JoshTaylor I have updated my answer to address your comment. May 13, 2018 at 3:49
  • "Many companies forgo requirements engineering completely or do a watered down version of requirements engineering due to time to market pressures" - I think the real reason is, many companies have learned over time that waterfall approaches and BDUF with formal models don't work well for their projects. Don't get me wrong, but saying it is just "time to market pressures" gives me the impression of someone having a view form an ivory tower, ignoring that the goal of software engineering is to produce working products, not just formal models.
    – Doc Brown
    May 14, 2018 at 9:00

I will not repeat the excellent points made in the previous answer, but I wanted to add that a fundamental challenge in bridging the software-engineering (SE) and ontology-engineering (OE) divide is the former generally makes the closed world assumption and the latter makes the open world assumption.

One way of thinking about this is that OE/OWL etc is primarily focused on representing the structure of the world, whereas SE/UML etc is about the structure of data and code.

For a pragmatic example: an ontology may say that every human has exactly two biological parents; a data model that enforces this as a closed world cardinality constraint will be impractical as the database would need to be recursively populated with parents, ancestors, etc (since leaving this empty would be a constraint violation under the CWA).

This is only one facet of a very nuanced area, with a lot of literature, workshops, etc. You may also be interested in the W3C Ontology Driven Architectures document. For a quick overview, I think these slides are useful.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.