EK provides extensive Ontology Design services for our customers. Much of what we know comes from lessons learned on a wide variety of projects. Over time we’ve developed a library of best practices regarding what to do and what not to do when creating an ontology. Though this topic is already covered elsewhere, I’ve found much of the existing writing to be overly academic or theoretical. My goal in this article is to provide practical advice on how to design a business ontology (that being one that will be intuitive, manageable, and usable to those who need it).

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.

I have divided this blog into two parts. In this, the first part of this blog, I list 5 key recommendations that should be implemented as part of any Ontology project. In part II of the series, I will describe specific methods that we use to design an effective business ontology.

1. Set Measurable Goals

Ontologies come in many forms and can serve many purposes. It is important that you have a plan in mind as to how you will use your ontology. This plan has to be specific with measurable outcomes tied to it. We often hear our clients say they want to create an ontology that will support a semantic web application so that their users can discover relationships between content. While this goal sounds good, it is not measurable and as a result puts very few limits as to what the ontology should support. Ontologies based on open ended goals frequently lead to poor performance and failure.

We help our clients avoid this through our Ontology Workshop. As part of the workshop we meet with key stakeholders to identify practical actions that the ontology needs to support. We define user personas, use cases, and identify exemplar content types and topics, all of which provides a targeted focus for the overall design. At the end of the workshop we have an agreed upon set of use cases that will inform the design of the ontology. This approach allows us to put specific boundaries around what the ontology should support and allows us to measure success along the way so that we can purposefully evolve the ontology design over time.

2. Select from an Existing Specification

There are a large number of ontology specifications (SKOS, OWL, RDF, etc.). Take advantage of these existing specifications when designing your ontology. The specifications make it easy to transfer your ontology from one tool to another. They also make it easy to borrow from other existing ontologies. Finally, there are many libraries that automatically implement features for ontologies using standard ontologies.

It is important to select the right one for your needs. There are a number of factors that play into this selection, including:

• Your measurable goals;
• The features you plan to implement;
• Industry standards; and
• The management tool you’re planning to use.

The measurable goals in conjunction with the features that need to be implemented narrow the field of standards to choose from. SKOS is designed to support a hierarchical ontology similar to a taxonomy. OWL and RDF are better suited for situations where you are defining relationships between people, places and things.

It also makes sense to look at standards that are aligned with your industry or the tool you are planning to use. Selecting a standard that is commonly used in your industry means that you can borrow from the work of others. This existing work, if leveraged properly, can be a starting point from which you can grow. Finally, most tools support specific standards. If you have a tool that you have already purchased, use the standard that it uses. If you have not selected a tool try to select a tool that supports the standard you want to use.

3. Work Outside of Your Box

The Ontology community is an open community. The thought leaders in this community believe that ontologies are most powerful when shared across entities. If you are just getting started, there are a vast number of sites that provide starter ontologies. Taking advantage of these existing public ontologies will enable you to go further than you would have if you started from scratch. Think of ontologies as analogous to the open source community. Contribute back to the ontology you started with and you can take advantage of the work of others as your ontology grows organically. This is a powerful way to create a deep ontology on a limited budget.

Another way to take advantage of this open community is to design solutions that take advantage of public information. Don’t limit your solution to the content that you own and manage. The whole idea of semantic web and ontology is to gather and share information from across the web in a seamless fashion. When designing solutions, take advantage of other ontologies like DBPedia to offer information and features that could not be offered on a single platform.

4. Start Small and Grow Slowly

Ontologies are very powerful tools that let organizations harness information in new and powerful ways. It is easy to get caught up in what you could do with them and try to do too much too soon. Remember this is new to you and probably new to your users. Throw a whole bunch of new features at them and they will reject the change. Try to create too many relationships between content and the value of these relationships will be lost. Our clients begin with measurable success criteria and do just enough to meet those goals. They gather information and slowly add new features and ways to link data based on the activity of their users. Things that work are expanded; while things that didn’t are adjusted or removed. Over time, you can grow a powerful way to manage and share information that does not turn off your users.

5. Learn SPARQL

The W3C defines SPARQL as an RDF query language, that is, a semantic query language for databases, able to retrieve and manipulate data stored in Resource Description Framework (RDF) format. SPARQL is to semantic web and ontologies as SQL is to relational databases. Imagine designing a relational database without knowing SQL. You could create something, but it would not be very useful. This same logic applies to ontologies. Make sure that someone on your team understands the basics of SPARQL before going too far with your ontology. We like to provide an overview of the SPARQL language in our workshops so that people understand the impact of their choices.

In part II of this blog series I am going to share the methods we at EK use to prioritize and design business ontologies.  You can find part II here.

Ontologies are powerful tools that can change the way you manage, analyze, and share information. Ontologies and the Semantic Web are concepts that have been around for decades. The technology finally exists to support these concepts and as a result more and more organizations are solving content and information management with ontologies. As with any new technology, it is easy to do things wrong or inefficiently. We can help make sure your ontology is a success. For more information please email us at info@enterprise-knowledge.com.