Creating a Domain Ontology

If you want to create a sophisticated ontology describing a domain of interest, there are a few basic steps to get started. Below is a brief outline of the process; the related resources at the end of the guide provide a more thorough treatment.

Community or Solo?

Given your particular goals and knowledge, you will need to decide whether to make the ontology development a community effort. Reasons to do so include greater buy-in (acceptance) and use of the ontology, greater awareness of the work, and access to a larger pool of knowledge.

Reasons you might want to develop the ontology on your own include representing a particular perspective, preserving ownership and credit, and greater efficiency because you eliminate consultation and developer agreement.

Developing a sophisticated domain ontology is usually quite challenging, and at a minimum you will want to have access to a specialist that has some experience developing this kind of information resource. Such an ontology specialist can provide critical guidance and technical support throughout the process.

In the Beginning: Capture Concepts of Interest

As a first step in the process, you'll want to identify key concepts in the domain. Techniques include literature surveys and searches, use-case identification and documentation, analyzing data sets (particular database and file headers, and metadata descriptions), and brainstorming among members of the team.

It is not critical at this stage to get the names or meanings of the terms exactly right. If there is confusion about a particular term, define it or describe the nature of the issue, but don't waste too much time trying to resolve it.

Organize Concepts

For ontology building, it is important to capture not just hierarchies, but meaningful relationships (with verbs) between the different concepts. Using a general tool for organizing concepts (like IHMC CMAP), put terms in a diagram and link them to each other with relationships, creating a large set of linked terms. Many brainstorming and diagramming tools exist to help you organize your concepts.

This is a good time to begin discussing your understanding of the different terms on the page, and to make sure you agree in your understanding of the end document. It isn't necessary yet to have a precise analytical description of all the components—say, at the level of a research paper—but you don’t want to ignore conflicts of views. In some cases, the easiest approach may be to document differences and continue identifying relationships.

Formalize Relationships, Classes, Properties and Instances, and Subclass Relations

Certain relations will be apparent in almost any concept diagram from the previous step: one thing "is a" thing of some other type; this thing "has" those things. Key to an effective ontology will be identifying which terms are really properties of another (a rock has a shear strength, or a fluid has a boiling point), and which are general concepts (cars) as opposed to instances (Honda Civics).

At the same time, you should identify key relationships that are necessary to create your ontology, and define them in terms other semantic tools can use (is it a transitive relationship? is it symmetric?).

Another type of relationship is that of a class to its subclass. While a Honda Civic is certainly an instance of "car types," the Honda Civic in my driveway is an instance of the sub-class "Honda Civic model." So, whether a concept is a class, a lower-level subclass, or an instance, is not always straightforward.

This can be the trickiest part of building an ontology, as the classification of concepts into the different categories can depend not just on subtle judgments of the usefulness of each classification, but also on the purpose to which the ontology will be put. For example, classifications appropriate for a samples database may not be very effective for a training module. An expert knowledge engineer can contribute to this stage of discussions.

Capturing the Information in a Knowledge Model

Depending on the situation, discussions in the last section can take place on a white board, in a drawing or concept mapping tool, or in an ontology-building application such as the ontology editors Protégé or TopBraid. The final step in the initial process, at least until iteration begins, is to capture the discussions as thoroughly and accurately as possible using an ontology editor.

This process will either strengthen, or question the knowledge model realized in the ontology. These discussions can be represented as additional relationships, which add inferences into the model. The added relationships and inferences will either support the consistency and usefulness of the ontology, or identify problems that need to be resolved.


As new information is added to the existing model—or the existing model and its inferences are reviewed and used by other systems—discrepancies and issues inevitably arise. A process is necessary by which the model owner (individual or community) can review the work and update it. This can be expected to continue indefinitely for more complex models, and even more so for those that represent cutting-edge research. Getting the knowledge in an ontology "just right" is usually not a goal for the short term, but with increasing maturity and feedback the ontology can become increasingly consistent, powerful, and reusable.


The following references provide much more information about creating ontologies.

Suggested Citation

Graybeal, J. 2011. "Creating a Domain Ontology." In The MMI Guides: Navigating the World of Marine Metadata. Accessed July 9, 2020.