[Eulergui-user] a Java API for EulerGUI for inference engines inspired by Jena

[Jean-Marc V. <jea...@gm...>]

Hi

Comments and critics welcome !

The Jena object model for RDF and inference

Reference: Jena 2 Inference support
<http://jena.sourceforge.net/inference/>; Jena
JavaDoc <http://jena.sourceforge.net/javadoc/index.html> ; EulerGUI
JavaDoc<http://eulergui.sourceforge.net/maven-site-dev/apidocs/>(NEW!)

InfGraph ---|> Graph ---|> GraphAdd

             bound
Reasonner <>------ InfGraph
             schema
Reasonner <>------ Graph


InfGraph is a Graph where Triples added by inference can be distinguished.

Each Reasoner implementation is associated to ReasonerFactory.

ReasonerFactory are registered in a singleton ReasonerRegistry.

Graph is on the SPI side (Service Provider Interface), while Model (a huge
interface) is on the API side.
Comparison with EulerGUI model

In EulerGUI this does not exist:

   - distinction between Graph and InfGraph
   - the equivalent of Reasonner, ReasonerFactory, and ReasonerRegistry

In EulerGUI this exists:

   - ITripleStore is the equivalent of Graph
   - Project is the equivalent of Model
   - N3Source has no equivalent in Jena

Project and N3Source are at the heart of EulerGUI. The accent is put on how
to build a RDF + rules Model out of heteroneous parts. In contrast in Jena
the accent is put on the RDF Model itself, and once a source is added to the
Model, this action of adding is forgotten.

About reasoner support, there are differences. In Jena, one can bind many
reasoners of the same or different implementation to the same Graph,
resulting in as many InfGraph objects. In EulerGUI, each different engine
implementation is a unique service. A common feature is that different rule
engines do not collaborate, each has its own augmented model.

Currently (alas) the glue code for the inference engines (alias reasoners)
in EulerGUI is all in class Project. The first task is to modularize the
inference engines support in EulerGUI. To this end, these hardships exist:

   - some engines produce an explicit result, like Euler, while some like
   Drools enrich the triple set
   - some engines produce a result that can be N3 rules and quoted graphs,
   like Euler, while some like Drools just produce triples

Modularizing the inference engines support in EulerGUI

The first thing in modularizing the inference engines support in EulerGUI is
to design an *API to be used by the GUI layer*. The possible inference
engines should not be hard coded in the class Project, but offered as a
uniform list of services. The minimal capabilities expected from an
inference engine instance (already bound to a Project) are in this interface
:

public interface InferenceEngine {
  void setArguments(String args);
  String getArguments();
  N3Source launch();
  String getWarnings(); // and errors also
}

  This is easy to do, but does not take in account the dynamic knowledge
base features of Drools. Drools' RuleBase and WorkingMemory are used
directly in Project. These existing EulerGUI interfaces should be used more:

ITripleStoreRETE ---|> ITripleStore

The idea is to simply add this method in interface InferenceEngine :

  /** non dynamic knowledge base can return a NullTripleStore */
  ITripleStore getTripleStore();

Note the use of the null object design
pattern<http://en.wikipedia.org/wiki/Null_Object_pattern>.
A non dynamic knowledge base can also return a real ITripleStore, that can
be implemented by parsing and aggregating the N3 sources. This is a service
that is not currently provided by EulerGUI.

Here the interface ITripleStoreRETE is not necessary, as one can call
InferenceEngine.launch() .

The GUI layer should be able to get a uniform list of services corresponding
to the possible inference engines, and bind a Project to an inference
engine:

public interface InferenceEngineSupport {

  List<InferenceEngineFactory> getInferenceEngines();

}

The interface InferenceEngineFactory is just a place holder for an Inference
Engine implementation, and a concrete implementation knows how to create an
actual InferenceEngine, and bind it to a Project.

public interface InferenceEngineFactory {
  InferenceEngine bindInferenceEngine( InferenceEngineFactory e, Project p );

  String showShortName();

  String showLongName();

}

Now to add SPI support, one can just add an interface
InferenceEngineRegistry:

public interface InferenceEngineRegistry {
  void register( InferenceEngineFactory e );
  InferenceEngineSupport getInferenceEngineSupport();
}

The interface InferenceEngineRegistry should be implemented as a singleton.

Note that other design goals could be worked on:

   - reuse in EulerGUI the available reasoners from Jena
   - provide the available reasoners from EulerGUI as Jena Reasoners


-- 
Jean-Marc Vanel
Consulting, services, training,
Rule-based programming, Semantic Web
http://jmvanel.free.fr/
EulerGUI, a turntable GUI for Semantic Web + rules, XML, UML, eCore, Java
bytecode
+33 (0)6 89 16 29 52 -- +33 (0)1 39 55 58 16
( we rarely listen to voice messages, please send a mail instead )