I can see the neverending problem with knowledge in organisations. On one hand people move around, they come and go, on the other hand information is increasing expotentially, giving both new facts and invalidating older ones. The problem is, the main vehicle for information are the people. There are always attempts to make the information independent by storing it in various ways but at least from my experience it is always ineffective: e-mails, various web pages, documents here and there it all makes the access hard and time consuming and eventually the information you get is often out of date and incomplete.
OWL expert system
I was looking for possible solutions and in my opinion very promising one could be a system containing of OWL knowledge base with a reasoner and some user interface which would constitute a expert system to store the knowledge in one place independently of employees and to provide access to everyone eligible at the same time. OWL is a language to represent knowledge about things and its relations. Knowledge base is just a collection of facts where all of them need to be typed in manually. Adding a reasoner however allows to unhide so called “inferred facts” which are usually created by our mind. Adding user interface is self-explanatory.
Let me give you very simple example. Imagine knowledge base which contains facts about 3 Things and its relations. Let’s name it “3 Things knowledge base”.
3 Things Knowledge base
There is a very nice tool for maintaining knowledge base itself: Protege. Clear interface allows to build and maintain knowledge base easily both in Windows and via web interface.
Let’s use it to create ontology for this expert system (I use the term knowledge base and ontology interchangibly).
Firstly, we need to create the minimum amount of facts. To do this we need to create 3 classes:
Secondly, it is required to name the relation between classes by adding object properties (and their hierarchy):
- contains is a transitive parent of containsDirectly
The implementation of the containers’ relationships is not straightforward. It should be split into transitive object property “contains” and its subproperty “containsDirectly” as on the Protege screenshot:
The important thing is the transitivity of “contains” (which means that if A contains B and B contains C then A contains C).
More on the types of object properties can be read for example HERE
Thirdly, we need to use the object properties to store the information about the class relations and add class instances (individuals) at the same time:
- BigThing containsDirectly MediumThing
- instance is bigbox
- MediumThing containsDirectly SmallThing
- instance is mediumbox
- SmallThing instance is smallbox
Notice, we do not need to put any facts related to SmallThing. You can see the text representation of the knowledge base HERE
It is required to apply some reasoner to the ontology. This is to check consistency as well as retrieve inferred facts. There are many more features and details but this is out of scope of this article…
I use HermiT reasoner in this example (HermiT.jar is required to run the program).
We need it for example to have inferred fact that BigThing contains SmallThing – there is no fact like this in knowledge base!
Also, OWL-API is required for reasoner to interact with the ontology. OWL-API.jar is needed in this example. When writing OWL-API and reasoner code I used very much of THIS example (I am using version 3.1.0).
Now, we need to use DL query to get the information we are interested in. DL query is the syntax you use to get information from ontology. As the result of the query you may get superclasses, classes and subclasses as well as individuals. We are interested in subclasses of the response in this example as well as individuals. The query looks like this:
contains some SmallThing
As the response we are going to get information which classes (which are going to be subclasses of this query) and which individuals of the ontology meet this condition.
As the result of our work we have such a expert system at this point:
Which works like this:
You can get the full code of the application from HERE.
It may be looking simple to do but unfortunately it is not easy to create the proper knowledge base even for simple case like here.
There are good practices you have to know before you can start creating knowledge base. For example to implement contener’s hierarchy like in this example one needs to read THIS.
Other than that, the reasoners differ from each other and they support various features so it is possible given reasoner will not be able to operate on the ontology as in this example.
Last but not least DL query is not intuitive way of asking questions in my opinion and I think it would be problematic to create a good translator of English sentences into DL queries.
Application of ontologies in QA world
The problem of knowledge base is very wide and interesting. When thinking of QA area I am thinking about the OWL knowledge base which contains information about application under test. This could be storing information about every aspect of the project: all its abstraction levels – starting from business information (usage, typical load etc.) down till classes and the design (detailed descriptions). This could be available both to project team members (developers to catch up with the code quickly, testers to understand how to use it etc.) and other applications which could benefit from such knowledge for example automatic testing tools (automatic exploration tests, automatic non functional tests etc.).
It was just the touch of the project knowledge maintenance problem which for sure is very complex to solve but it is very universal in my opinion as well and that’s why it is really worth to keep on experimenting and trying to find the solution.
I really mean it was just a touch – just take a look at THIS.