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.

 

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:

 

Jason

PROs

  • 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)

CONs

  • 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

 

JADEX

PROs

  • Java based
  • Has its own BDI debugger tool

CONs

  • 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

 

JAM

PROs

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

CONs

  • 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

PROs

  • 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

CONs

  • 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

 

Clips

PROs

  • FOPC-like syntax

CONs

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

 

Jess

[Jess vs Prolog]

PROs

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

CONs

  • 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.

 

 

ACT-R

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.

PROs

  • Very popular among “cognitive modeling” community

CONs

  • 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)

 

Soar

Similar jargon as ACT-R.

PROs

  • 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

CONs

  • 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

 

JBoss Rules/Drools

[IBM tutorial]

PROs

  • 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

CONs

  • 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
  • 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

 

 

Cogent

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

PROs

CONs

  • 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.”

 

MatLabPROs

  • Popular in research community

CONs

  • Seems limited to numeric-oriented simulation rather than rule-based ones

 

Trackback URL
Leave your own comments about this post:
You must be logged in to post a comment.