here are many common problems that occur when corporations expand beyond their initial ontologies and start to build multiple ontologies that must remain consistent. Here is a list of the common problems, which are covered in this article:

• Tools – Use the right tools to build your ontology.
• Duplicating Data Elements – What do you do when two separate structures in your ontology represent the same concept?
• Role Pollution – What do you do when the role of a person or object becomes the class name?
• Mixing Processes for Semantics and Constraints – Learn how to use a single process for meaning and exchange-specific constraints.
• Untested Upper Ontologies – What do you do when critical upper ontology classes do not work as they were designed?
• Ambiguous Definitions – Learn how to write precise definitions for classes, properties, and values.
• Mixing Definitions and Descriptions – Definitions are critical because they get high visibility in many tools.
• Poor Search – Users need to find what they are looking for—especially if it already exists.
• Poor Reporting – Find all unapproved properties in a project that help you prioritize your work.
• Lack of Versioning and Traceability – Knowing who created a property and in what context can help you determine the intended purpose of a property.
• Lack of Code-Level Semantics – Knowing the meaning of classes and properties is necessary but not sufficient. Knowing the enumerated values of codes used in properties is just as critical.

Using Tools to Help Design Ontologies
There are many products today that claim to allow you to design Ontologies. Stanford University's widely used Open Source Protégé ontology editor (see Figure 1) or Altova's SemanticsWorks (see Figure 2) are both good examples of ontology design tools.

Figure 1. Open Source Protege: A widely-used ontology editor is Standford University's Open Source Protege

Figure 2. SemanticWorks: Altova's SemanticWorks is a good example of an ontology design tool.

Managing the data elements you create through the design tools becomes an essential component to maintaining an ontology. Just as a word processor helps you write a single document; document management systems help you organize multiple documents. In the same light, you will need some simple tools and processes to manage the data elements in your corporate ontology as they grow from a single OWL file to a family of files that must be consistent. Doing so allows you to:

• Track document history
• Track versioning
• Search for data
• Create reports of what documents were created by what individuals
• View timelines of when groups of data were created

Central to many of these tools is the creation of smaller discrete structures that bear semantic information but are reused in many ontologies. But in large organizations, shared meaning only comes through shared trust. If people do not trust the processes behind your ontology they will not use it and they will tend to re-invent the structures.

Author's Note: The term "data element" within this article refers to fine-grain structures that can be managed in an ontology. If you are familiar with OWL, these items include classes, properties, relationships and range values.