Inference Engines

Most real semantic applications will require an inference engine.  There is a lot of heavy math and computer science behind an inference engine, but the long and the short is that without it, no application will be able to link the scattered knowledge that a semantic web will make available.  It would be like reading table structures in a database without the ability to do SQL joins.

The most common operation in description logics is classification and typically you should be doing this frequently when adding logic to your classes in Protege.

There are many (many) inference engines and many of them will support OWL variants.  However, as with open source SQL databases, there is always the question of how well the language is actually supported.  To date, I have not found one that supports all OWL features, and it is critical to know what features are supported when designing your target application.

If you install Protege 4 Beta, you get two engines pre-installed (Pellet 1.5 and FACT++).  Other engines can be linked in, such as KAON2 (see instructions – though I have not tried using KAON2 directly in Protege yet), and some (such as Pellet 2) are available as plug-ins (see previous entry). Each of these engines by themselves support different kinds of queries and you can verify this externally (such as running KAON2 and Pellet directly from Java using JENA). Using them from inside Protege may impose further restrictions due to the interfaces. For instance:

• Pellet 1.5 does not support inference on data type properties – If you have data type properties in your class restrictions, Pellet in Protege will fail to find and classify corresponding individuals.  This was known in 1.5 and used to be written up on the Pellet FAQ (last year) and other places.
• Pellet 2.0 supports some data type properties – According to the Pellet site, the current 2.0 version has full DL support including datatypes.  I downloaded the latest Pellet 2.0 plug-in to see if it fixed the above problem, but my first try failed badly. A condition testing for equality like “hasBodyTemperature value 97” succeeded (this used to fail under 1.5) but one using an inequality like “hasBodyTemperature only int[< 90]” failed with a Pellet “InternalReasonerException: Unknown term type” exception.  According to the specs, they are going for full DL compliance, so this may be fixed in an update soon.
• KAON2 does not support “Nominals” (enumerated classes) but does support data type properties – See the description of the algorithm on the KAON2 site. This means that KAON2 can deal with classifications that Pellet 1.5 won’t do.

The unfortunate side of this is that if an ontology is published that works in Pellet, enumerated classes are a really handy feature and are frequently used, so it is likely that the ontology will not work in KAON2.  There are awkward ways of using the lowest common denominator between the two, but it is really difficult to publish a complex ontology that covers a large base of engines. This makes the typical SW scenario difficult at present.

It is easier if you are developing a specific application.  In this case you can build the ontology to match the task and choose your engine accordingly.

The list of issues changes frequently so I will publish updates as I test them.  More later.