Many organizations empower enterprise ontologists to become the keeper of semantic precision. Ontologists can become the core team that helps an organization:

Enforce consistent semantics for shared business rules Create a shared process for defining data element approval Create shared meaning of conformed dimensions in a data warehouse Create consistent product taxonomies Create consistent integration maps that map database systems to web services Create consistent leaf-level data elements that move between any two computer systems

This precision and consistency of ontologies allows organizations to save time and money building complex systems. Tools to find trusted data elements quickly allow these organizations to be agile. Together ontologists and semantic web technologies can play a leading role in large- scale enterprise costs savings.

In large standards this review process usually is directed to a committee of experts who have a specialized understanding for specific parts of the ontology. In financial institutions some members might specialize in stock transactions and some in bonds. The key is to have a clearinghouse to assign data elements to the group that has the most expertise. This is one of the central aspects of data governance and data stewardship that must be in place for the ontology to gain enterprise respect and usage.

You can use ontologies as a central location to store the semantics or meaning of the data elements that live on the leaves of XML documents. When they are stored in a well-controlled centralized corporate ontology the definitions of the data elements go beyond the needs of a specific version of a web service. The data elements have individual histories:

Creation dates Approval workflow status Approval committees Revisions and date-stamps of when they were approved for corporate usage

On the other hand, you should not view XML Schemas as containers of the semantics of data elements. XML Schemas are containers of the data elements and each one expresses the order and cardinality of the collection of elements. XML Schemas are the constraints of a specific data exchange. For example, a single developer can add and delete Web services for data subscribers. Your job as a corporate ontologist is to support such activities, maintain semantics, and get out of the way of a specific business unit that has their own instance of specific required fields, which must be present as inputs to their web services. So when people have questions about the meaning of data: that is the ontologist's signal to step in and bring the tools to build semantic precision. But if a problem has to do with what elements are present, what order they appear in a transaction, which data elements are required, and which ones are optional;; it is recommended to let the data publisher and subscriber try to work things out.

Computer systems that have similar upper ontologies will have much lower integration costs. If upper ontologies are stable then people will develop trust in the systems. They are the anchors of your semantics and the foundation of your building. Change them frequently and you will quickly lose the trust of your stakeholders. [..] An upper ontology is like a high-level sieve. Data elements come pouring out of requirements like little grains of sand and need to be sorted correctly by the "uppers." Even a novice that is unfamiliar with your ontology should have the ability to guess how the data elements are sorted.

Here is a summarized list of five characteristics for great data element definitions:

Precise - The definition should use words that have a precise meaning. Try to avoid words that have multiple meanings or multiple word senses. Concise - The definition should use the shortest description possible that is still clear. Non Circular - The definition should not use the term you are trying to define in the definition itself. This is known as a circular definition. Distinct - The definition should differentiate a data element from other data elements. This process is called disambiguation. Unencumbered - The definition should be free of embedding rationale, functional usage, domain information, or procedural information.

Once you have a great definition, make sure that every class, property, range value and all derived artifacts carry the definitions with it. It is disappointing to open an OWL file, an XML Schema, or a relational database only to see that none of the tables or columns have any definitions and you are left to guess at the meaning.

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

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