Ontology Questions and Answers

Great question. This is an ongoing challenge because different parts of a company use terms differently. One rule of thumb is to avoid using terms that have many different meanings across the company—this will just cause confusion. Things can be set up so that local groups can see their own terms in UIs of systems they use, but ambiguous terms are best avoided in the enterprise-wide ontology.

Another factor is that when a number of major IT systems permeate everyday operations in the company, the terminology of the IT systems can effectively become the terminology of the company. Worse, these terms might originally be those of the vendor, not the company. A target to hit is for the terms in the ontology to be readily understood by anyone in the enterprise who a) needs to know what is going on and b) is unfamiliar with terms tied to specific applications. It can sometimes help to start with long names whose meanings are fairly easy to grasp. Independence from IT systems is important for an enterprise ontology which reflects the stable and essential concepts in the business; IT systems change a lot.

This is a complex and multi-faceted issue. The answer depends on the audience, who have varying degrees of a) knowledge in the domain, b) technical background, c) awareness of what the ontology is for and d) need to directly work with the ontology.

For everyone, and especially non-technical people, it is important for there to be natural language comments explaining the meaning of the concepts. It is helpful to have an overview of the ontology which has only the top few dozen classes and relationships (like a UML class diagram). It is good to have HTML documents that can be automatically generated from various tools. It should be possible to seamlessly move between levels of detail from the very general to the very specific and back. Ideally, you want to have different layouts automatically created and tailored to different circumstances. There are many visualization tools available to help with some of these things, but much more remains to be done.

For the very technical individuals, who will be using the ontology on a day to day basis, it is important to be able to locate concepts that are similar to what they have in mind. For this, it helps to have the ontology classes and properties organized into a small number of disjoint hierarchies.

This is a question of scope. An ontology is complete if it has all the concepts and axioms that are needed. Needed for what? This depends on the intended purpose of the ontology. If you have a local, one-time need to integrate a small number of databases, then you need to include all the concepts that are covered in those databases. On the other hand, if you are building an enterprise ontology to serve as a long-term semantic foundation for your organization, then you will want to focus on only those concepts that are both essential and stable in your organization, that is, the most important concepts: the ones that have been around for decades and will be around for decades to come.

If the ontology has a fairly broad purpose and was not built to be used by any specific IT systems, a good way to check for completeness is to identify a number of possible use cases for deploying it. You might start by brainstorming possible use cases and applications that would solve critical problems that the company currently faces. Focus on those that can be solved by having the right data available. For each use case, identify the goal, inputs and outputs, and the required data to make that use case work. Then check the data requirements against the ontology to make sure they are covered. What is missing might belong in the ontology—making it more complete; or it might be too detailed or application-specific and belong in another kind of model.

This is related both to scope and to design. An ontology is elegant if it has the fewest possible concepts to cover the required scope with minimal redundancy and complexity. Whereas completeness is about making sure enough is in the ontology, elegance is about making sure that the ontology is not done until there is nothing else you can take out. Once an ontology gets big enough, it is hard to remember exactly what is already there, so duplication and redundancy can arise. It can also arise in more subtle ways—you can end up with three different ways of modeling essentially the same thing if it was approached independently from three different perspectives. This is especially true if there are different authors, but it can also happen with a single author if the three different perspectives are approached and modeled at different times.

A good ontology simplifies your information management systems because it creates an enterprise-wide definition of what things are called and their interrelationships. In our experience, even the complex requirements of multi-billion, global companies can be organized into ontologies of about 1000 concepts. Because ontologies reuse properties they can represent the real world complexities of a business using many fewer properties than logical models would need.

A good place to start is to run an inference engine to see if there are any logical inconsistencies or classes that cannot possibly have any members. The former is always an error; the latter usually leads to an error. However, this is only the beginning. Plenty of errors can remain even when the ontology passes the above tests. Another good thing to do is to examine the inferred hierarchy to ensure that everything makes sense. When it does not, click to get an explanation and then track down the error. Another important technique is to create unit test data. Often an error will not show up until it is run against data. Creating test data is also a good way to test your understanding of the model; it is where the rubber hits the road. It is easy to think a portion of the ontology is right, only to find gaps and errors when creating test triples. Look at alphabetized lists of classes and properties to find likely spelling errors. You can also identify patterns that you know to be likely errors and write SPARQL queries to find them. For example, if you like to have inverses for all your object properties, you can easily find exceptions this way. Many of the most common pitfalls have been already identified and code has been written to find them; see: Are there any tools to help find common pitfalls in ontologies? Finally, you should check the ontology against the sources of knowledge. If you interviewed some experts, show and explain the ontology to them for feedback.

First, you need to know what the original objectives were for having the ontology. The more specific the objectives, the easier it is to test whether they have been met. If you never had any objectives (or requirements), it might be easier to declare success, but harder to defend what that means.

Whatever the specific objectives might be, some general things to look at include correctness, completeness, elegance and understandability. Correctness means that the classes, properties and axioms accurately characterize the subject matter being modeled. A good place to start is to run an inference engine to see if there are any logical inconsistencies. Completeness means that the ontology has the right coverage of subject matter—no important concepts are left out. Determining what should be in or out is a scoping issue that strongly depends on the ontology objectives. Elegance is the other side of the completeness coin: are there things in the ontology that are not needed? Importantly, this includes avoiding redundancy and complexity. Understandability is about the ontology being easy to learn and use. There must be high level overviews for those who don't need the details, and an easy way to drill down to the specifics for those who do.

I will answer this in the context of OWL ontologies where the errors are found using Hermit or Fact++ as the inference engine. I happen to use Protégé, but other ontology tools have similar functionality. There are a few cases. First, if the ontology is inconsistent, then one or more classes will be inferred to be equivalent to owl:Nothing and will show in red in the inferred class hierarchy. Click on one of those classes and click the question mark to get the explanation for that inference. Scan the explanation to see if you can find anything obvious. Much of the time, you will see that a property is used in a restriction instead of its inverse. If nothing is obvious, consider what you changed most recently in the ontology, and look there. If you still cannot find the problem, try clicking on other classes that are equivalent to owl:Nothing to see if there are any shorter explanations that may be easier to track down. If they all are approximately the same length, then you might just have to roll up your shirtsleeves and draw some venn diagrams or graphs connecting classes and properties to identify the problem.

After the ontology is consistent, there might still be some classes inferred equivalent to owl:Nothing. Use the same procedure as above. After this, look carefully at the whole of the inferred hierarchy to identify things that do not look correct. Find the explanation and proceed as before.

Yes. Check out OOPS! (OntOlogy Pitfall Scanner!). The authors looked through the literature and discovered 29 common pitfalls that arise when building ontologies. Code has been written to automatically find 21 of the 29 pitfalls. Try it out and give the authors feedback. The whole community will benefit.