© Jean-Marc Vanel - $Date: 2012-06-03$ - under Creative Commons License

TOC

Deployment of an EulerGUI project

There is a lot of flexibility for deployment of an EulerGUI runtime.

Inference engine

Here are the options for the pure expert system part ( business rules + possibly some RDFS + OWL generic rules ).

  1. Java platform : "pure" expert system, not stateful : use Euler engine jar ( < 8Mb ) + EG jar ( < 1Mb )
  2. Java platform : stateful Knowledge Base with Drools : drools-core (< 2.2 Mb ) + EG jar ( < 1Mb ) + compiled rule base in cache
  3. any platform supporting Yap prolog engine : call a Yap run with a system exec call or the Yap C API, on a set of N3 data and rules representing an EulerGUI project (one N3 data file has to be populated prior to calling Yap, and the result has to be parsed, which is easy with --no-qnames Euler option)
  4. any platform supporting Python : use Python N3 engines : CWM or FuXi
  5. any platform : useEulerGUI server (work in progress ) , or Euler server based on URL-encoding an argument string for stateless processing
  6. PHP platform : there is a RETE engine for PHP: PHP rules; a translator from N3 rules to PHP rules format couls be developped (with rules and templates)

Database access

Now for database access here are the options:

  1. use existing SPARQL source in EulerGUI (not sure if currently the query is re-done at every inference launch), and a choice of SPARQL server (Jena TDB or SDB, Virtuoso, Redland, Sesame, etc )
  2. use one of the relational to RDF bridges : D2R, DataMaster, etc

User interface

And for user interface generation here are the options. This is very promising, but it's work in progress.

  1. there is a nice OWL ==> Swing form generator, completely automatic, that is working at runtime with the Drools engine, but it is not feature complete;

    with the new architecture for embedding Java objects in KB, Java objects are activable by rules.

  2. of course one can reuse an existing framework for form generation, or an existing code base
  3. we are working on a rule base generating GUI for several platforms : Swing , Apache Wicket, TCL/TK, HTML+PHP ; leveraging on an ontology of atomic user interactions (see

    Building Applications with the EulerGUI + Déductions framework ) , and on Euler capabilities to produce formatted strings ( builtin e:format )

  4. Web applications are possible via Apache Wicket, see Web applications with GUI generation via embeded EulerGUI