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
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.
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.