Climbing the DIKW pyramid – do we have everything we need?

The ‘divide and conquer’ principle or the ‘separation of concerns’ design principle have served well engineers for many centuries. A system viewed as a collection of interconnected modules (sub-systems) each assigned a dedicated function is a good way to focus on each issue in its turn, to solve different problems one after another.

Service-oriented Architecture, a simple triangle, that can be imagined in general to be composed of 3 vertices: i) service provider, ii) service requester and iii) register, give a possibility to build complex and scalable systems, where service requesters with the help from known and (hopefully) trusted registers can discover and engage with the service providers.

Building loosely-coupled systems, where the links between service requestors and providers dynamically change as the overall goal or goals the entire system follows change as well, make it possible for system, in general, to provide a better service as, for example, to cope with some unforeseen conditions at system design time. In order words, a system can do things, which its creators were not foreseeing the system should or could be doing.

Another viewpoint on systems we develop could be through DIKW (Data / Information / Knowledge / Wisdom) pyramid. Such viewpoint could help us to go from abstract services that can be dynamically invoked to serve some abstract changing needs of abstract system to arrive to the point, where we can formulate the goals and purpose for those actual systems.

At the bottom of the DIKW pyramid, one can imagine data or sensor readings. As such, those without context provide little value. For example, a temperature of 233 °C may tell us a little. However, as we start to develop a context or information, linking the temperature with the material exposed to that temperature, we can start to “see” that at given temperature paper catches the fire. However, in a different “context” of Aluminium, you will need to rise the temperature about 3 times more, for the metal to start melt.

Still, we usually try to climb that pyramid to make something useful, which could be interaction with the environment. So, for example, we may wish that, for example, a furnace we made to melt metals would maintain the right temperature to melt given metal. We could make an application that will use information about the melting temperatures and will keep right levels at operation time. The operational knowledge can be hardcoded in the application.

However, if we wish to build truly intelligent systems, we may want to push the limits and make those rules also to change dynamically. Not that we will be able to change some “constants” for metals, but to at least allow systems to learn how to treat yet unseen situations and update its experience. For that purpose, we may need to learn how to represent Wisdom from the above-mentioned pyramid.

Are available knowledge representation standards all that we need to build systems having “Wisdom” or we miss some languages and standards to grasp essentials of learning process, to express the emergence of intelligence?