Comparison of tools for rule-based inference

Although I started writing pseudo-code rules a few weeks ago, I’ve suspended that while I look for a tool for writing and testing rules so I don’t assume too much about the quality of the rules so far. This post describes what I’m looking for and the tools I’ve looked at. I’m likely to go with JIProlog or Amzi Prolog (and perhaps later, ECLiPSe).

I’m looking for an expert system-type tool that offers these features:

  1. Simple, first-order-predicate-calculus (FOPC) syntax rather than C-style code
  2. Can be embedded easily in Java programs
    • Prefer Java because it’s platform-independent
    • Java has widespread use in simulation research that I might use or partner with
  3. Has a large, active community that might be interested in my work, and from whom I might get tech help
  4. Has good IDE (editor tool) support for auto-completion, syntax-highlighting, breakpointing, etc
  5. Allows for easy changing of any rules governing beliefs, desires, and intentions (aka BDI)
  6. Has a way of tracking what papers/scenarios influenced the conditions and actions of each rule (aka “provenance tracking” in my terms)

This is what I’ve found:



  • Uses a Prolog-like syntax (i.e. fairly similar to FOPC)
  • Has a jEdit-based IDE that allows inspecting the mind of each agent, and history of actions among the agents
  • There is a book with in-depth how-to info (which I’ve ordered)


  • Structured as a “BDI” system, which sounds at first like a big positive, but on deeper inspection seems to mean that it handles beliefs, desires, and intentions in a pre-defined way. I’m not sure yet how limiting this might be.
  • I asked the creators if there was a compelling reason to use it over a simple inference engine (apart from the ability of MAS frameworks to allow agents to run over a network), and they said there isn’t much advantage in that respect.
  • Might not support back-chaining or facts with universally-quantified vars (however, this might be possible in Jason and all Rete-based systems by encoding such facts as rules with “true” as their antecedent)



  • Java based
  • Has its own BDI debugger tool


  • BDI support seems “cooked in” and likely to be hard to change
  • Rules must be expressed in an especially verbose form of xml
  • Might not support back-chaining or facts with universally-quantified vars



  • Java-based BDI
  • Distinguishes between achievement goals and maintenance goals
  • Seems more comprehensive in BDI concepts than similar systems


  • Procedural rather than FOPC-style syntax
  • Seems to have same limits on expressiveness (i.e. fairly restricted compared to FOPC or Prolog) as other forward-chaining expert system tools using the Rete clause-indexing algorithm

Discrete Event Calculus Reasoner (DECL)


  • The “event calculus” (EC) is a set of rules for dealing with the frame problem (aka “commonsense law of inertia” — things tend to stay as they are unless explicitly changed). The frame problem occurs when a rule system knows a fact was true in the past but isn’t sure whether to assume it’s still true. CCSS is likely to run into the frame problem often, since our systems are likely to be triggered by combinations of mental attitudes, but some of those attitudes may seem “stale” due to being triggered in the past. The “discrete” part in the name is due to assuming a timeline with discrete points rather than a continuous one.
  • Has a book that shows how to encode BDI and OCC in EC


  • Requires integrating Unix env, Python, “PLY”, and one of a small set of SAt logic solvers. This seems too brittle and platform-specific to me.
  • While EC has a good-sized community, this inference engine seems to have a small one
  • Seemingly no IDE support
  • Might not support  facts with universally-quantified vars



  • FOPC-like syntax


  • C-based, so integrations would have to use C, JINI, or system-level calls


[also see Jess vs Prolog]


  • Clips syntax implemented in Java
  • Has an Eclipse (IDE) plugin
  • Widely used


  • Roundabout support for facts with universally-quantified vars: One must use the special ‘nil’ slot value for such vars. Not sure if this will actually work.
  • Roundabout support for backchaining: Instead of indicating that a particular rule is backchaining, one must commit to making a particular predicate backchainable. This seems like it could have unwanted side-effects.


Uses special jargon — “chunk” is what most other systems call a fact; “declarative memory” (for chunks/facts) is what other systems call “working memory”; “procedural memory” is where production rules are kept (is this an oxymoron only to me?)

Structured very similarly to BDI toolkits — there is a goal buffer and a retrieval/belief buffer, but unlike BDI these buffers are allowed to hold only one fact/chunk at a time.


  • Very popular among “cognitive modeling” community


  • Limiting the size and number of buffers seems unnecessarily limiting — it limits the expressiveness of rule conditions
  • Seems to be no support for universally-quantified vars in facts, especially because vars are not allowed to bind with ‘nil’ in facts
  • Coded in Lisp, and special purpose IDE is very limited but does have a stepper (but perhaps not breakpointing)


Similar jargon as ACT-R.


  • Fair-sized community in AI and Psychology (e.g. John Laird of UMichigan)
  • Formalization of Cohen & Levesque’s teamwork theory exists, STEAM, created at USC by Milind Tambe’s group. (I strongly suspect any team- or cooperation-related work we do will have to build on C&L’s theory.)
  • Java-based
  • Has its own IDE


  • Would prefer Eclipse plugin to specialized IDE
  • Syntax allows for separate stages of “proposing” and “adopting” operators, and a lot of flexibility in conflict resolution. I don’t currently need this, though, and the syntax is somewhat different from traditional FOPC. I think I could migrate to Soar later if needed.
  • Not sure if Soar has negative connotations for roboticists and AI folk, due to its somewhat dogmatic views on cognitive architecture


Prolog-based simulation tool. It’s been used by its creators for simulating many domains, including a prey animal that anticipates a predator’s actions (by simulating the predator’s mind) and counteracts.

It appears to have some sort of unit-testing support built-in. Perhaps embeddable in a Prolog/Java bridge.

JBoss Rules/Drools

[IBM tutorial]


  • Very active community (enterprise)
  • Not only an Eclipse plugin but also a browser-based “rule management system” (not sure of its features yet)
  • Java-based


  • Two primary rule languages – one in “natural” but highly constrained English, and one that mixes FOPC with procedural constructs. There is a nascent effort to provide CLIPS/Jess-style language support also.
  • Doesn’t support backchaining
  • Probably doesn’t support facts with universally-quantified vars (unless through a workaround like Jess’)

Prolog in Java [external overview]

PRO: Prolog supports backchaining and facts with universally-quantified vars

  • JIProlog
    • PRO: Java can call Prolog, and vice versa
    • PRO: Available as shareware (free)
    • PRO/CON: Special-purpose IDE
    • PRO: Actively supported
  • AmziProlog
    • PRO: Java can call Prolog, and vice versa
    • PRO: Has a plugin for Eclipse IDE
    • PRO: There is a breakpointing debugger available for the IDE plugin
    • PRO: Good support through Amzi forums
    • CON: The breakpointer is not free
    • CON: The breakpointer, and the interpreter, require some getting used to. For example, the listener must be shutdown manually (via a “quit” typed command) before one exits Eclipse. Common keyboard shortcuts cause errors when the Listener has focus.
  • ECLiPSe
    • An extension of Prolog that supports “constraint programming”. In my terms, this allows one to make temporary bindings such as “T > 2” rather than only permanent absolute bindings like “T = 3” as pure Prolog demands, thereby delaying commitment to a specific value. This is a way to be efficient by doing search in a “constrain and generate” style rather than a “generate and test” style. For example, if one wanted to know if “the book was returned before Monday”, one could constrain a time variable to be before Monday and then search for book return events using that time variable, instead of searching for all book return events using an unbound time variable and then checking each variable binding to see if it was after Monday.
    • However, one is limited to relations for which a “constraint solver” can be written; ECLiPSe comes with several solvers for different kinds of problems.
    • A plugin for the Eclipse IDE is available, Saros, but I couldn’t get version 1.0 working. It was contributed by a Cisco employee, and rumor is that he will get official support to update it. I’ll re-evaluate when that happens.
  • JPL
    • PRO: Java can call Prolog, and vice versa. Commonly used with free SWI-Prolog
    • CON: Not actively supported since 2003 (at least not the docs)
  • tuProlog
    • PRO: open source, and appears actively supported
  • JLogic
    • PRO: Free
    • PRO/CON: Special-purpose IDE
  • Jinni
    • CON: Not free
  • SICStus Jasper
    • CON: Not free
  • GNU Prolog for Java 0.1.0
    • PRO: Free
    • CON: Very early release
    • CON: Appears not to be actively supported
    • CON: No IDE

Cyc engine and tools (but not KB) – TBD

Currently can’t run on Vista; will try on XP or Linux soon

RePast – TBD

Swarm – TBD


Targeted at situation-assessment and decision-making applications. Uses Bayesian network as part of its tech.



  • Appears to be not available, except perhaps through a belief net app from Charles River Analytics
  • “On the situation assessment side, one major problem we are confronted with is that the type of belief network currently used in COGENT does not model temporal information explicitly.”



  • Popular in research community


  • Seems limited to numeric-oriented simulation rather than rule-based ones
Print Friendly, PDF & Email