In the Enter Semantics: An Expert System for Automated Monitoring – Part 1 of this blog series I introduced a tool for automated error analysis using advanced knowledge management techniques: error situations are described in a wiki such they are readable for humans and computers. In the latter case an expert system can extract data from the wiki to analyse error situations. Therefore it uses an expert system. The expert system makes a kind of first guess by analysing protocols and leads the user to a wiki page that provides background information. After solving the problem the user can add more information to the wiki page and describe how he solved the problem or he can alter the information in case of an incorrect analysis by the expert system.
Ontologies as cornerstone of expert systems
In the second part of this blog series we learn how to create an expert system using ontologies. Ontologies are formal representations of the knowledge by a set of concepts within a domain and the relationships between those concepts.
There are a lot of different technologies to build expert systems. What are the advantages of ontologies? First they are strong doing classifications and this is very useful for error analysis. Let me give the following example: if an application consumes too much memory the AS ABAP can kill the process or throw an exception that can be handled by the application and this can lead to an error message and a controlled exit or just give out a warning. So this memory problem can lead to different reactions of an application: protocols, logs, dumps and so. An automated error analysis will recognize these reactions as a specific error situation which is a memory problem in our case. More abstract it will be perform an error classification. It's not hard to imagine that these error situations ca be modelled as a tree of classes in an tree where each subclass is a specialisation of its parent. And dealing with those classifications is a strength of ontologies.
Another strength of ontologies is extensibility. Our show case (classification of BAL messages) is very simple but a monitoring tool in an heterogeneous system landscape will get information from lots of data sources and each one will use its own vocabulary to describe error situations. But this is nothing to frighten because there techniques to merge different ontologies so we can build bridges between them.
Those extensibility leads to another advantage of ontologies: they rely on open standards which can be used in web based architectures. Ontologies or parts of ontologies can be interchanged as XML messages f.i. as web services.
Working with Protégé
In the following I will define a ontology that contains an knowledge base together with a set of messages to be classified. In fact such an ontology will be created by an expert system from the data of a wiki as well as AS ABAP. But before we automate the process we have to do it at first manually. Therefore I use a tool called Protégé for expert and do the following:
- I create a small domain model,
- then I encode a knowledge base as classes and
- at last I solve an error analysis by using a classification problem.
An ontology can be serialized in XML and this one possible way how to build an expert system: we mash up the input to data into an ontology and use a reasoner to solve a classification problem.
In our domain model I'm creating with Protége there is the concept of an error and a message that corresponds to a BAL message. An error has a set of messages which indicate the problem:
Message has some properties which are strings: a message has a class, a number, a BAL object, a BAL subobject and a type:
Creation of a knowledge base for error conditions
An error is modelled as a class with subclasses corresponding to error situations which are defined within the wiki. And this is how we do it: in the following define a special error class corresponding to the example in the last weblog: "Error_in_Transfer_of_FI-CA_Totals_Records_to_General_Ledger".
In
In fact this error is characterized by the existence of two special BAL messages within a protocol:
| BAL Object | BAL Subobject | Message Class | Message Number | Type |
| FICA | FPG1 | >U | 435 | E |
| FICA | FPG1 | F5 | 808 | E |
This fact can be expressed by following logical expression:
So far we defined a domain model and a class respresenting an error situation. By creating similar classes we can encode the knowledge defined in the wiki as an ontology.
Error analysis means classification
The expert system works as follows: we have a set of BAL messages which come from a protocol within AS ABAP. For these messages we define a protocol (as instance of the error class) that contains both messages as a simple example:
When we have a protocol like the one above we want to know whether it fulfils the logical conditions of error situations like "Error_in_Transfer_of_FI-CA_Totals_Records_to_General_Ledger". The expert systems gives those classification back to the user who can have a look at the corresponding wiki pages to get more information about the error situation.
Reasoning
We can use Protégé´s reasoning functionality to ask for a classification. It's not surprising that the message belongs to problem class "Error_in_Transfer_of_FI-CA_Totals_Records_to_General_Ledger":
Summary
In this blog we learned
- how to create a domain model using ontologies,
- how to model a simple knowledge database a ontologies (i.e. the error condition "Error_in_Transfer_of_FI-CA_Totals_Records_to_General_Ledger" of the last instalment) and
- how to use classification for error analysis.
In the next instalment we deal with some pesky technical issues: data extraction from wiki and AS ABAP and the ontology creation.
I you are interested in the ontology we created in this blog entry you can find it here.
