Ten Pitfalls of Enterprise Ontology Management : Page 4

Mixing Definitions and Descriptions

Figure 4. Ontology Mapping: This figure shows an example of ontology mapping.

Each data element in your ontology needs to have a short definition that appears next to a graphical representation of the data element. This short definition needs to be clear and concise so that it is different enough from similar data elements in your ontology and to clarify the semantics of the data element. Many ontology tools or XML Schema mapping tools (see Figure 4) can display definitions next to a graphical representation of the data element. Some tools display a definition if the user hovers over a data element with a mouse. However, you should not write a definition longer than one or two lines. Definitions longer than two lines should be placed in a descriptive note in your ontology management system. This can include detailed discussions about usage, exceptions, and departmental-specific business rules on the use of the data element.

Many tools allow you to click on a hypertext link to open a full-page description of a data element including facts like who added it, when they added it and what systems might be impacted if this data element changes. This feature is called the data element traceability and it is critical to help people understand your ontology and therefore trust its credibility.

Poor Search
Already discussed were the problems of duplication of data elements and how search tools are necessary as ontologies grow and multiple ontology designers are involved. This section covers some specific problems related to searching ontologies and related assets. One of the first problems with ontologies is that they tend to be highly structured documents with complex relationships. You cannot easily break an ontology into a simple collection of classes, properties and value domains and then put these items into three tables in a relational database. Although you can create fast searches using standard relational databases you will find that storing ontologies in relational structures is just not flexible enough.

A much more practical approach is to store ontologies in a native XML database structure. This allows you to keep the complex structures in an ontology but still allows you to perform complex full-text searches. Some native databases such as the open source eXist database also have WebDAV interfaces that make adding ontologies as simple as a drag-and-drop into a folder. Ontologies are then automatically indexed and can be searched using standards such as XQuery. Open source reporting tools such as the Eclipse BIRT plugin can be used to create high-quality reports.

Lack of Versioning and Traceability

A best practice is to use a web-based version control system such as subversion to store ontologies and view the histories of these ontologies.

The need for versioning of any asset is critical for building long-term enterprise trust in that the asset was thoughtfully created by a trained team member and approved by a review team that represented stakeholders across the enterprise. One of the best practices is to use a web-based version control system such as subversion to store ontologies and view the histories of these ontologies. Subversion has many supporting tools that provide user-friendly colored differences, which show what changes were made by what users and when. These tools also allow developers to be more aggressive about removing duplicates when they know that these removals can be quickly undone.

Previous Page

Next Page