One of the benefits of leveraging ontologies with SOA is the fact that, no matter where the information resides, we can understand and map information relevant to our SOA problem domain. Ontologies allow you to differentiate between resources, which are especially useful when those resources have redundant data (such as customer information in almost all enterprises).
Thus, in order to make better sense of and represent the data in a more meaningful way, terms defined in ontologies allow the architect to fully understand the meaning and context of the information -- in other words, the ability to put entities in the appropriate context and map data from the complex and difficult to use to the simplistic and easy to use. It creates order out of chaos.
[ Effective architecture is key to business flexibility, agility, and efficiency. Keep up on developments in SOA with InfoWorld's Technology: Architecture newsletter. ]
What does data have to do with services? Everything. Most services exist to produce and consume information, and they provide us with the ability to leverage complex structures within abstractions that are more relevant to our business. In essence, we're putting simplistic data structure lipstick on the complex and heterogeneous data pig. Ontologies provide us with a good approach to understanding and organizing that data.
An important notion of ontologies is entity correspondence. Ontologies that are leveraged in more of a distributed environment, which SOA always is, must leverage data scattered across very different information systems and information that resides in many separate domains. Ontologies, in this scenario, provide a great deal of value because we can join information together, such as product information mapped to on-time delivery history, customer complaints, and compliments.
This establishes entity correspondence between data that is physically distributed. To gather information specific to an entity, we need to leverage different resources to identify individual entities, which vary widely from each physical information store. For example, when leveraging a relational database, entities are identified using keys, such as customer number.
Using ontologies takes some practice. However, those of you looking to make short work in understanding data in the context of your SOA, they are the best approach as far as I'm concerned.