This is the second in a two part blog series, sharing our best practices collected through our efforts in ontology consulting. The first part of the series described 5 key recommendations for any new ontology project. These recommendations need to be in place for any ontology project to be successful. This second blog provides specific methods for designing a business ontology (that being, one that will be intuitive, manageable, and usable to those who need it).

As a reminder, our most successful ontology projects deliver business users new and meaningful ways to see relationships between content and information. The complexity of the ontology is hidden from the business users who are able to discover related content without the need for formal or rigid navigation between content. The content owners/administrators are able to manage the relationships between content at a much more granular level with minimal additional effort. Often, these changes give our customers new ways to consolidate and present content and information both internal and external to their organization. Most importantly the value of these changes is visible to the project stakeholders and sponsors.

The design recommendations in this post assume that the project recommendations in Part I have already been implemented. These recommendations are focused on maximizing business value and usability.

Use Non-Technical Terms

Most ontology designers use terms like graphs, classes, nodes, and edges. Though these are accurate descriptions of what we are designing, they make ontologies seem unapproachable and difficult. Make a point of replacing these highly technical terms with terms that are more recognizable to your stakeholders.

 

Technical Term	Business Term
Class	Entity or Thing
Domain	Category
Attributes	Properties or Features
Edge	Relationship
SparQL	Query language like SQL

It is important that you communicate regularly with your stakeholders. Using non-technical terms will make the project feel more approachable and more business focused. As a result, it will be easier to get feedback from your stakeholders on their wants and needs.

Identify Your Domain 

The first step in creating an ontology is to identify the domain to which it belongs. By this, I mean the category or topical area the ontology describes. This cannot be done in a vacuum. Review your content and then come up with 3-4 terms that describe your domain. Use these terms to search for public ontologies with similar domains. To find similar domains that are publicly available, look in places like the following: 

 

• http://wiki.DBPedia.org
• http://protegewiki.stanford.edu/wiki/Protege_Ontology_Library
• http://semanticweb.org/wiki/Ontology.html
• https://www.w3.org/standards/semanticweb/ontology
• http://ontologydesignpatterns.org
• http://schema.org/  

Evaluate the content and entities in these public domains to see which one is most closely aligned with the content and entities in your domain. Use the public domain as the starting point for the rest of your work. Not only will this give you a headstart on the work, it will also ensure that you are following a standard that others use so that you can more easily integrate your domain with others.

Prioritize the Entities to Model 

Each ontology has a list of classes (think entities or types of things) that need to be modeled. For example, an ontology about people in an organization would likely include the following entities:

It would be very easy to create a huge list of entities for any domain that you work with. Many people begin by creating an exhaustive list to make sure they capture everything. This is a common mistake for people creating their first ontology. Start with a smaller list of entities that are easily recognizable and model those first. Prioritize the entities to develop through the use cases and goals you defined at the beginning of the project. This approach will save time and allow you to show value sooner. It will also result in a design that meets the business needs without introducing undue complexity and clutter.

Minimize Characteristics and Look for Patterns

The next step is to model the characteristics of these entities. If you are following a standard, some of this work may already be done for you. Some standards allow for a great deal of flexibility to define these characteristics. In these cases, you will need to make decisions about how much information you want to manage. Minimize the number of characteristics you capture though the use cases and goals for the project. Less is always better as you start out. Also, look for repeatable patterns that can be applied to as many entities as possible. Consistency among entities simplifies implementation and simplifies the way content can be queried using the SQL-like query language (SparQL).

Prioritize Relationships

Identifying the ways in which entities are related is one of the most powerful features of semantic ontologies. It is, unfortunately, also one of the easiest ways to create an ontology that is overly complex. Review the goals for your ontology. Prioritize the types of relationships to those that directly support the goals of your taxonomy. Try to limit these relationship types to less than 5 if possible. As with all of these things, it is better to start small and grow than to try and be comprehensive with your first ontology.

Validate your Design

Ontologies can be confusing to people who have never worked with them before. This does not mean that you should develop the ontology in a vacuum or without validation. Make sure you have a visual representation of your ontology and share it with the project stakeholders at every stopping point in the project. Show how the ontology relates to their content and information and how it will help them meet the objectives defined at the beginning of the project.

This feedback loop accomplishes three things:

• Your stakeholders see progress and understand why they are developing an ontology.
• The stakeholders may spot things that are missing, and
• You can validate that the design is easy to understand.

It is important that this is done before the ontology and its related features are implemented so that you do not go down the wrong path.

Ontologies offer a powerful way to manage and present content. Technology has advanced to the point where the ontologies and the semantic web are now a reality. An effective ontology can:

• Provide new ways to navigate and find content,
• Expose relationships between content that were once not visible, and
• Provide a seamless view of content across organizations.

I encourage all of you to consider how an ontology can improve your content or knowledge management sites. We are happy to help if you need ontology consultants to assist in the design of your ontology. Contact us at info@enterprise-knowledge.com.