In my last post, I got started with Flora-2 and showed how we can model homeopathic remedies from a therapeutics perspective. Although such a limited view of remedies can be helpful in treating acute ailments, for treating chronic diseases, a comprehensive understanding of the various remedies from the perspective of keynotes, kingdom classification and miasms is absolutely essential. This information is available in various materia medica and published clinical cases. If a knowledge representation system such as Flora-2 can help us in converting the available natural language descriptions of remedies into a formal model, that would help us tremendously in implementing much better computer programs to recommend appropriate remedies for patients who require homeopathic care (homeopathy is quite popular in some countries, especially India). Although there are several widely used computer programs such as MacRepertory and RadarOpus, they all use electronic repertories. Repertories are prepared manually from the natural language descriptions of materia medica and other sources, and they contain remedy information in a semi-structured form (better than natural language, but not formal). They are then converted to an electronic form suitable for use with specific software. Understandably, there are significant variations across the different repertories supported by the homeopathic software. What is required is a concerted effort to model the original source material in a KR system such as Flora-2 so that we get precise and unambiguous models of remedies. This is a challenging problem that requires serious attention by the community.

In today’s post, I want to continue my exploration of Flora-2, but this time focus on how to capture the key features of remedies independently, devoid of the therapeutics bias. Note that homeopathy remedy pictures are quite detailed and comprehensive, but what I am showing here is just a tiny fragment, for obvious practical reasons.

Modeling Requirements

Two important modeling requirements became apparent to me as I waded through the huge volume of information available on homeopathic remedies

1. We need a way to model inheritance of properties that are available across remedy classification hierarchies. For instance, remedies can be prepared from Minerals, Plants, Animals, etc. Some remedies in the Mineral kingdom inherit the traits of multiple minerals. As an example, the remedy “Kali Carbonicum” is supposed to have some traits of the “Kali” as well as “Carbon” family. We would like our model to capture these ideas without being redundant and verbose.

2. Remedy descriptions must be “open”, that is, it should be possible to describe the same remedy, in parts, in multiple source files. Assuming we have captured certain properties of a remedy R1 in File1, we should be able to add to this remedy information by providing additional details for R1 in File2, File3, and so on. We should not be forced to alter the original file File1 in order to add to the remedy (we might have to modify File1 to make changes to the descriptions in that file, but that is different). For this to be possible, the formal system must consider the different descriptions of the same remedy as a “union”. When we work with large knowledge bases that are managed and maintained by many authors, this requirement becomes quite crucial. 

If the second requirement seems obvious and straightforward, it is worth pointing out that in modern programming languages, this is not possible in Java or C++ but is supported in C# (through partial keyword).

Flora-2, fortunately, satisfies the second requirement. We can define multiple Frames for the same predicate symbol either in the same source file or different source files. See this example:

Coming to requirement (1), Flora-2 supports both structural and behavioral inheritance (see the manual). In fact, it is possible to inherit from multiple base classes too! However, just as in the traditional OO languages such as C++, if the same name appears in a frame across multiple parent classes in Flora-2, this will result in conflict, and the name will not be inherited (additional rules can be defined to customize this behavior).

To understand this, see the example below:

Here, classes Base1 and Base2 have two attributes that have the same name. Derived is a subclass of both Base1 and Base2. Take a look at the output for different queries in Flora-2:

Notice how attrib1 and attrib2 are not inherited, where as attrib3 and attrib4 are inherited.

In the context of homeopathic remedies, inheritance is common and even multiple inheritance occurs in a few places. in such cases, we want the remedy to inherit the union of behaviours from multiple remedy classes, instead of cancelling out. I could have tweaked some rules to get this working in Flora-2, but decided to follow a different strategy, by introducing an explicit attribute called group in the remedy description. 

Here is an example of hierarchy seen our model.

See the following description of the remedy lach, showing that it is a part of Crotalidae group:

The group attribute points to one or more remedy groups that this remedy belongs to.

I define two rules to handle behavior inheritance from different groups:

The remarkable thing here is that Flora-2 gives us the flexibility to define our concepts the way we want to model!

Take a look at the remedy model I have developed for capturing a very small subset of features of some common homeopathic remedies. 

A Lisp Application to Access the Flora-2 Engine

When I was working on this model, I felt that the default Flora-2 console, although quite functional, was not that appealing for extended use, so I decided to write a Lisp application to directly use the Flora-2 engine through the published Java API! To keep things simple and manageable, I restricted the scope to loading multiple knowledge bases and then querying the engine (functionality that is available in ErgoAI IDE, but that is a priced product). Fortunately, LispWorks comes with Java support, so it was not hard to build the application (the application is still evolving, so I am not uploading it now). The examples that follow are shown in the context of my Lisp application.

Here is the application at startup:

The application allows us to 

* Load a KB file (module can be specified)

* Add more files into the same session

* Reload the last file

* Clear the current session and create a new one

* Edit KB files

* Query the Flora-2 engine

Here is the screen after loading the file homeopathy-advanced.flr

The loaded file can be opened for editing by clicking the Launch Editor button.

This is a no-frills editor. No syntax highlighting, etc., but supports basic editing and printing.

OK. It is time to ask some queries on the KB file we just loaded:

What are the mental keynotes of the remedy kali_c (Kali Carbonicum)?

The answer appears below the query – the variables in the query are matched with respective bindings.

Another query: Which remedies have a quarrelsome mind?

The remedy kali_c matches the query.

Next: Which class (or classes) does the family “Crotalidae” inherit from?

Flora-2 prints all the base classes, up to the root.

Next query: Which remedy belongs to the Plant group?

We see two remedies, Lycopodium and Nux Vomica coming up as matches.

To make it a little bit more interesting, let us load another KB into the same session, using the Add Rule button. The file homeo-pathology.flr is essentially the same example we discussed in the last post, with minor changes to conform to the new model. Note that we are adding to the current session, not replacing the previously loaded KB. 

The information available in the session is the union of the two KBs, as we discussed earlier. Let us ask a query that involves both information:

Enumerate the Rheumatism remedies along with their full names

This is a conjunctive query, and as expected, fetches the correct answers.

One last query: Which remedies have psoric miasm in the second degree?

Everything seems to be working well! When I get some free time, I plan to enhance the application to make it more usable.

That brings us to the end of today’s discussion on modeling remedy keynotes. While converting from natural language description as in materia medica and other sources, we have to be careful in adopting and following a uniform terminology as well as a consistent frame structure (in the context of Flora-2). I found the whole exercise enjoyable, mainly due to the expressiveness of Flora-2. There is a lot more to learn!

You can download the model files homeo-pathology.flr and homeopathy-advanced.flr and take a look. Suggestions for improvements are welcome.

Have a great weekend!

 

Tags: Flora-2, homeopathy, Knowledge Representation, LispWorks