The Business Cases for Conversational Semantic Decision Support (CSDS) can be expanded from simple requirements to design and development phases, including hints on service names and application messages. Standards, recommendations and best practices could serve as the base for conversational scripts, which would help a SME, (in this case, a software developer) to successfully implement them and create a truly semantically rich SOA environment.

In the semantically rich environment, there is no need for complex management tools. The names and messages are self-explanatory and directly tied to the ontological execution model. For example, service names and operations can be consistently composed with the Actor, Action, and Object vocabulary.

Application messages can be done in JSON style: {"time": "currentTime", "serverName": "{serverName}", "application": "{appName}", "service": "{serviceName}", "error": "(for example) database is down", "recoveryAction": "restart database", "notify": "currentlyOnCallPerson"}

If this method is consistent across the industry, vendors will create smaller, smarter and less expensive semantic sensitive tools to monitor and manage service operations.

Such messages can be RDF-formatted to compose a "situational graph" and find root cause factors of a problem registered with these messages. A very similar thing can be done with service messages directed to an enterprise service bus.

A semantic message listener will not need to be programmed to each specific message content and format. Instead, it will be able to listen to much wider themes, which can be quickly redefined by business, providing a new dimension for event-driven architecture. People-readable service messages will be quietly translated to RDF to accommodate the upcoming RDF Services standard.

Service monitoring and managing is one of the most dramatic areas of IT.

It is also one of the areas with the great potential to decrease cost and cut extra layers. We will cut down the need for the magic of writing monitoring scripts. Application messages can instruct applications on self-checking and self-healing.

A semantic listener will execute instructions written by application developers, who know best what to expect, how to prevent and recover. A semantic listener will be able to combine multiple application messages into a situational scenario, something that we desperately need and completely lack today.

This is not just a technical effort. This effort requires the local guidance and support from Information Governance locally. There is also a need for industry collaboration with W3C and OMG participation.