3 ms·

I did some work in the early 1990s on a rule-based Expert System Builder funded by the EU's Esprit research programme. It was implemented in Common Lisp, hosted

I did some work in the early 1990s on a rule-based Expert System Builder funded by the EU's Esprit research programme. It was implemented in Common Lisp, hosted on Lisp machines and then Macintosh systems, and had a frame-based knowledge representation. The approach had various problems at the time: * what to do with a chain of reasoning if a previously asserted fact was retracted (i.e. when being questioned by the system, you realise that a previous answer was wrong) * very brittle knowledge that doesn't transfer well outside a specific domain (the 'joke' example was a medical expert system that would diagnose rust-patches on a car as measles) * The problem that as rule sets grew in size, domain knowledge needed to be supplemented by software engineering skills We found it telling that none of the contributing companies continued to use the rule-based approach for very long when the EU funding dried up, and that none of them successfully commercialised it for a third party company. However, as an experienced programmer rather than an AI researcher, in at least one case, I found that the rule-based approach was a good way of getting domain experts to articulate the heuristics they used, and then embed these in a conventional application. The GUI we developed for the frame-based component was also repurposed for a very successful in-house modelling too, so the codebase wasn't a complete loss.

j-pb 5y ago
> * what to do with a chain of reasoning if a previously asserted fact was retracted (i.e. when being questioned by the system, you realise that a previous answer was wrong) Mixing up the concepts of "forgetting" (a monotonic operation that maintains a systems consistency at the cost of completeness), and "retraction"/"deleting" (a non-monotonic operation that requires truth maintenance and chooses completeness potentially at the cost of corectness (of the whole system)), is the billion dollar NULL mistake of the knowledge representation and database world.
- PaulHoule 5y ago
  Many symbolic A.I. programs (e.g. MYCIN) were based on production rules engines. Great progress has been made in rules engines since then, but production rules haven't gotten mainstream and I've long wondered why. Retraction is largely solved. Rules engines such as Drools and Clara use the RETE algorithm, hashtable/b-tree indexes, can match against millions of rules. These work particularly well for "complex event processing" where you could could gather up events (say from a rocket starting up or a financial trade) into compound events you code against. People who use this kind of tool http://www.hets.eu/ http://www.hets.eu/ would say their tools are much better and that the "logic" of production rules is a pale shadow of what SAT solvers, theorem provers, etc. can do. For ordinary "Business Rules", production rules engines compete against implementing the rules in ordinary code. http://inform7.com/book/WI_1_1.html http://inform7.com/book/WI_1_1.html is a toolkit for writing text adventure games in what looks like English. Just blasting through rules in order it uses defaults as a primary mechanism of control. Production Rules and logic compete with databases in the sense that a more expressive system won't scale as well (you want to fit in the L3 cache if not the RAM) RDFS and OWL implement limited-but-useful subsets that scale better than others. I've used production rules in data transformation one record at a time, they work well for this, but today I implement the same organizational principles in a set of Python functions that act on dicts. The production rules do https://en.wikipedia.org/wiki/Transitive_closure https://en.wikipedia.org/wiki/Transitive_closure idiomatically but in the limited cases where you need that you can look it up in an algorithm book. Production rules also are great for highly interactive systems. I have used production rules in the control plane for a distributed data processing system where the system compiled a description of a job into a set of rules. They are great for "internet-of-things" both because "IF-THIS-THEN-THAT" feels natural and the compound event capability. It seems that they'd even be an answer to the asynchronous communication problem in Javascript.
  - HerrMonnezza 5y ago
    What literature/books would you recommend to know more about the subject to be able to apply it to practical programs?
    - leeuw01 5y ago
      +1, I'm currently investigating rule-based systems at my job and I would love to understand the theory behind them better.

j-pb 5y ago

> * what to do with a chain of reasoning if a previously asserted fact was retracted (i.e. when being questioned by the system, you realise that a previous answer was wrong) Mixing up the concepts of "forgetting" (a monotonic operation that maintains a systems consistency at the cost of completeness), and "retraction"/"deleting" (a non-monotonic operation that requires truth maintenance and chooses completeness potentially at the cost of corectness (of the whole system)), is the billion dollar NULL mistake of the knowledge representation and database world.

PaulHoule 5y ago
Many symbolic A.I. programs (e.g. MYCIN) were based on production rules engines. Great progress has been made in rules engines since then, but production rules haven't gotten mainstream and I've long wondered why. Retraction is largely solved. Rules engines such as Drools and Clara use the RETE algorithm, hashtable/b-tree indexes, can match against millions of rules. These work particularly well for "complex event processing" where you could could gather up events (say from a rocket starting up or a financial trade) into compound events you code against. People who use this kind of tool http://www.hets.eu/ http://www.hets.eu/ would say their tools are much better and that the "logic" of production rules is a pale shadow of what SAT solvers, theorem provers, etc. can do. For ordinary "Business Rules", production rules engines compete against implementing the rules in ordinary code. http://inform7.com/book/WI_1_1.html http://inform7.com/book/WI_1_1.html is a toolkit for writing text adventure games in what looks like English. Just blasting through rules in order it uses defaults as a primary mechanism of control. Production Rules and logic compete with databases in the sense that a more expressive system won't scale as well (you want to fit in the L3 cache if not the RAM) RDFS and OWL implement limited-but-useful subsets that scale better than others. I've used production rules in data transformation one record at a time, they work well for this, but today I implement the same organizational principles in a set of Python functions that act on dicts. The production rules do https://en.wikipedia.org/wiki/Transitive_closure https://en.wikipedia.org/wiki/Transitive_closure idiomatically but in the limited cases where you need that you can look it up in an algorithm book. Production rules also are great for highly interactive systems. I have used production rules in the control plane for a distributed data processing system where the system compiled a description of a job into a set of rules. They are great for "internet-of-things" both because "IF-THIS-THEN-THAT" feels natural and the compound event capability. It seems that they'd even be an answer to the asynchronous communication problem in Javascript.
- HerrMonnezza 5y ago
  What literature/books would you recommend to know more about the subject to be able to apply it to practical programs?
  - leeuw01 5y ago
    +1, I'm currently investigating rule-based systems at my job and I would love to understand the theory behind them better.