© 2014 Volker Belli

Introduction#

The SemanticGuide was originally introduced by ontoprise GmbH and is based on the OntoBroker architecture. In mid of 2012 the company closed their services. The semafora systems GmbH took over OntoBroker and SemanticGuide the same year, providing services and support for the system, but did not take over the OntoBroker and/or SemanticGuide development team.

Developing diagnostic knowledge bases is usually a big investment. As a consequence former customers may worry about their past investments in knowledge engineering. Therefore, some (former) customers discuss the possible migration to another diagnostic platform, e.g. d3web KnowWE as an alternative to SemanticGuide. While in contact with several companies, we also experienced, that SemanticGuide does not offer advanced knowledge engineering tooling capabilities, e.g. continuous integration testing during the development or the automated analysis for knowledge base anomalies.

In consequence, we very motivated to find out whether a migration to KnowWE would be feasible.

Set-Up of the Trial#

At the beginning we were equipped with the original SemanticGuide knowledge base. We used both, the exported runtime version and the MS SQL Server database of the development system. No further information was available or used in that trial.

The main goals of the trial were:

1. Convert / migrate the knowledge base into a diagnostic wiki version, that can be used to continue the development of the knowledge base
2. Show that the resulting d3web knowledge base behaves exactly as the original one
3. Make sure that all contained languages, all textual descriptions and all media (images and movies) are available
4. The wiki version should not be created manually but generated automatically in a batch process

The Migration Process#

We created a batch processing pipeline that reads the folder (ZIP file) containing the executable version of the knowledge base (namely the file "domainlayer-sgversion.obl"). The folder also contains media attachments that are linked to objects of the knowledge base. These attachments are also considered during the process. From that, we added a number of wiki exporters to the pipeline that together create the following wiki articles at a glance:

• One article for each question and each solution, containing all information such as text labels and media files.
• One article for each flowchart, containing the graphical flowchart to process the diagnoses.
• An article containing the malfunctions (symptoms / cases) as well as an optimized "LeftMenu" for the wiki.
• A set of static articles for the comfortable of use and navigation of the wiki, e.g. documentation and configuration pages.

From that point the knowledge base showed to be fully functional in runtime environments deriving suitable diagnoses for entered symptoms. See table 1 on the right side for some details about the resulting knowledge base.

The next task was the visual handling of the diagnostic flowcharts in order to improve the readability for the knowledge engineers. That way, we decided to export the original layout as well (instead of automatically layout the graph in KnowWE, which would be possible as well). The export of the original layout minimizes the need of familiarization for the original creators of the knowledge base.

Since the runtime version of a SemanticGuide knowledge base includes no layout information, we extracted the node positions from the original MS SQL Server by using three plain SQL statements. These node positions were added to the created pipeline described above. As a result the exported flowcharts looks pretty similar to the original flows.

To make the presented results reproducible, I attached the source code of the migration pipeline to this article. Despite of the fact that the source code is commented, I know that not all of the steps are easily to reproduce, but feel free to contact me if you have questions. I also attached the used SQL statements to extract the node positions from the SQL database. You can download the full package here.

The Outcome#

The wiki was up and running and the knowledge base can be browsed, edited, tested, and downloaded in d3web KnowWE. The d3web runtime applications were capable to run the knowledge in all existing standalone applications on PC servers and mobile devices such as a smartphone. The diagnostic steps and the resulting solutions are identical to the derivation behavior of the original SemanticGuide application. The images and other media are attached to the questions and solutions. All available languages can be selected and switched during runtime.

The Way Beyond#

Frankly, the initial motivation was not running the knowledge base in d3web. This was a by-product. Instead our customer asked us to evaluate the diagnostic quality of the knowledge base, to give some hints how they should proceed in the future. We decided to migrate the knowledge to d3web KnowWE in order to be able to use the build-in evaluation capabilities, plus a bunch of additional evaluations we developed over the years.

A sample-set-based live test has been undertaken to show the overall diagnostic capability of the knowledge base. Additionally, we were interested in the answers to the following questions:

• How long does the diagnosis take for the different types of technical faults or symptoms?
• How good are the questions placed? Are there any questions with poor impact on the diagnosis?
• Are the diagnostic flowcharts drawn efficiently? Is there much duplication or other redundancy?

For this purpose we proceed and add more information to the pipeline. First we detect patterns of types of questions and actions, e.g. for executing measurements, mount/unmount equipment, making quick observations on the defect vehicle behavior, and so on. In total, we defined about ten of these patterns and associate the estimated time required to carry out the particular type of activity. Running the migration pipeline again results in a wiki and that helped us to answer these questions appropriately (see figure 1 and 2 on the right side).

Future Work#

However, there are a few aspects that were covered so far with this trial. The routing of the edges ("answers") between the nodes of the diagnostic flowcharts is not preserved by the migration. Instead KnowWE's auto-routing is used. For the most flowcharts the results are pretty good. We applied KnowWE's auto-rearrange tools to easily clean up flowcharts that are too messy.

If you plan to do a migration of a knowledge base and switch to KnowWE as the main authoring tool for productive use, you should make up your mind about how the content shall be structured in particular articles. Does every question should have its own article? Should some questions / solution be grouped? Are there "local question" that should be better placed with some flowcharts onto the same article? After answering these questions the migration should be adapted to produce the desired outcome. This will increase readability and understandability of the knowledge base and finally the overall productivity of your knowledge engineering team.

Result and Conclusions#

We have been capable to implement a batch-processing pipeline that automatically converts an ontoprise/semafora SemanticGuide knowledge base into a running KnowWE version. Only a few manual preparations are required, namely extracting the node positions by executing the prepared SQL statements. Even if the pipeline requires a bunch of days to be fully implemented, we are now capable to convert a knowledge base within less than an hour. Additionally we can add customer-specific information or a customer-specific assembly of the contents, if the exported system shall go productive.

As a result, diagnostic systems are no longer being walled gardens. Having an open-source basis, you can think about converting the knowledge into any other diagnostic system that is available and preferably used by the customer. The method will work for other diagnostic systems as well, especially because, in the past, d3web has shown that it likely has all required features to implement diagnostic knowledge bases. To break these walls I published the full sources as described in chapter The Migration Process.

If you are interested in further information about this or similar activities, feel free to contact me by email or consult our homepage.