Inferenzmaschine zu berechnen passenden Satz nach internen Regeln

Question

ich eine Reihe von Objekten mit Attributen haben und eine Reihe von Regeln, die, wenn sie auf die Menge von Objekten angewendet, um eine Teilmenge dieser Objekte zur Verfügung stellt. Um diese leichter verständlich machen werde ich ein konkretes Beispiel geben.

Meine Objekte sind Personen, und jeder hat drei Attribute: Herkunftsland, Geschlecht und Altersgruppe (alle Attribute sind diskret). Ich habe eine Reihe von Regeln, wie „alle Männer aus den USA“, die entsprechen mit Teilmengen dieser größeren Menge von Objekten.

Ich suche nach einer vorhandenen Java „Inferenzmaschine“ oder etwas ähnliches, die von den Regeln auf eine Untergruppe von Personen, die Karte in der Lage, oder Ratschläge, wie meine eigenen gehen über das Erstellen. Ich habe auf Regel Motoren lesen, aber dieser Begriff scheint ausschließlich für Expertensysteme verwendet werden, die die Geschäftsregeln externalisieren, und in der Regel beinhaltet keine fortgeschrittene Form der Inferenz. Hier sind einige Beispiele für die komplexeren Szenarien ich zu tun haben:

1. ich brauche die Verbindung von Regeln. Also, wenn präsentiert mit den beiden „schließen alle Männer“ und „schließen alle US-Personen in der 10 - 20 Jährigen:“ Ich bin daran interessiert nur bei den Männchen außerhalb der USA, und die Männchen in den USA, die außerhalb sind die 10 - 20 Altersgruppe.

2. Die Regeln können unterschiedliche Prioritäten haben (explizit definiert). So eine Regel „schließen alle Männer“ sagt eine Regel außer Kraft gesetzt wird sagen: „umfassen alle US-Männer.“

3. Die Regeln können widersprüchlich sein. Also ich habe sowohl ein „alle Männer sind“ könnte und ein „alle Männer ausschließen“ in diesem Fall müssen die Prioritäten, die Frage regeln.

4. Die Regeln sind symmetrisch. So "sind alle Männer" ist gleichbedeutend mit "alle Frauen auszuschließen."

5. Regeln (oder Untergruppen eher) können Meta-Regeln (explizit definiert) mit ihnen verbunden sind. Diese Meta-Regeln müssen auf jeden Fall angewendet werden, dass die ursprüngliche Regel angewendet wird, oder wenn die Teilmenge erreicht ist über Inferenz. Also, wenn eine Meta-Regel „schließt die USA“ die Regel gebunden ist „schließt alle Männer“ und ich biete den Motor mit der Regel „schließt alle Frauen“, es sollte in der Lage Schluss zu, dass die „schließen alle Frauen“ Teilmenge zusätzlich ist die äquivalent „alle Männer sind“ Teilmenge und als solche die „schließt die US-Regel“ gelten.

Ich kann in aller Wahrscheinlichkeit leben, ohne Punkt 5, aber ich brauche alle anderen Eigenschaften erwähnt. Sowohl meine Regeln und Objekte in einer Datenbank gespeichert werden und können in jeder Stufe aktualisiert werden, so dass ich brauchen würde, das ‚Inferenzmaschine‘ instanziiert, wenn nötig und zerstören es danach.

Answer 1

There are a bunch of embedded Prolog-like SLD solvers for Java; my favourite approach is to use mini-Kanren for Scala, since that is clean and allows you to use Scala to lazily handle the results of queries, but I have not used it in any depth. See Embedded Prolog Interpreter/Compiler for Java for other options, as well as Ross' answer.

SLD solvers handle all of your criteria, provided they have some extra features that Prolog has:

1. Conjunction of rules: Basic SLD goal processing;
2. Rules may have different priorities: Prolog's cut rule allows representation of negation, provided the queries are decidable;
3. Rules may be conflicting: Again, with cut you can ensure that lower priority clauses are not applied if higher priority goals are satisfied. There are a few ways to go about doing this.
4. Rules are symmetric: With cut, this is easily ensured for decidable predicates.
5. Rules (or rather subsets) may have meta rules (explicitly defined) associated with them: your example seems to suggest this is equivalent to 4, so I'm not sure I get what you are after here.

The advantages and disadvantages of SLD solvers over description logic-based tools are:

1. Programmatic power, flexibility: you can generally find programming solutions to modelling difficulties, where description logics might require you to rethink your models. But of course absence of duct-tape means that description logic solutions force you to be clean, which might be a good discipline.
2. Robustness: SLD solvers are a very well understood technology, while description logic tools are often not many steps from their birth in a PhD thesis.
3. Absence of semantic tools: description logic has nice links with first-order logic and model logic, and gives you a very rich set of techniques to reason about them. The flexibility of Prolog typically makes this very hard.

If you do not have special expertise in description logic, I'd recommend an SLD solver.

Answer 2

For the case you're describing I think you'll want to use backwards-chaining, rather than forward chaining (RETE systems like Drools are forward-chaining, in their default behavior).

Check out tuProlog. Easy to bind with Java, 100% pure Java, and can definitely do the inferencing you want. You'll need to understand enough about Prolog to characterize your rule set.

Prova can also do inferencing and handle complex rule systems.

Answer 3

This pretty much sounds like description logic and knowledge bases to me. You have concepts, roles and individuums.

If you want to roll out your problem as description logic-based reasoning, you should be fine modeling your problem and execute a reasoner on it.

There are some free reasoners availaibe, a list can be found here.

Note however, that this is rather a complex yet powerful approach.

You might want to have a special look at KAON2 and DIG when using Java.

Answer 4

I believe that you could use sort of ID3 algorithm to extract a set of rules from the initial state of your objects. I don't know any concrete Java implementation, although Wikipedia points to different implementations from Ruby to C (I can't post more than one hyperlink :-)), but it's not a hard algorithm to learn.

Once it builds the decision tree, that can be expressed in rule format, you could use it to see to which class your objects belongs: to all males from the US, to all females between 10 and 20,... and when someone updates your objects in the database, you can rebuild the decision tree.

Answer 5

Ok, this may be a dumb answer. But i will try anyway.... You could use BeanShell to make things like this:

• Create a simple selector command (something like select(inicialSet, paramName, paramValue) ) that return a set elements which is in inicialSet and match your params.

• Create some constants that can help you write nice BeanShell scripts.

This way you can write your rules as simple scripts AND nest rules.

So, this

I need the conjunction of rules. So when presented with both "include all males" and "exclude all US persons in the 10 - 20 age group," I'm only interested in the males outside of the US, and the males within the US that are outside the 10 - 20 age group.

will became a script like this:

originalSet = getOriginalSet(); //Get all from DB

//elements in originalSet that have gender=male
males = select(originalSet, PARAM.GENDER, GENDER.MALE);

//elements in males that have age in [10,20]
youngMaleGuys = select(males, PARAM.AGE, AGE.10_20);

//Exclude from
males.removeAll(youngMaleGuys);

notYoungUSMaleGuys = select(males, PARAM.COUNTRY, COUNTRY.US);

males.removeAll(notYoungUSMaleGuys);

return resp;

Of course, this sucks. I made it now. But you can write very nice commands and find a way to make this more readable.

Not so fast, but easy to mantain and to read (I think). And you do not have to worrie about ordering

Thats it. I tried. :)

Answer 6

One of the most powerful Java-based production rules engines (inference engine) is JBoss DROOLS.

http://jboss.org/drools

I'll be honest though, unless your application get a LOT more complicated, using a rules engine is WAY overkill. On the other hand, if you application gets too big and has too many conflicting rules, then it will fail to provide a result.

If you can control your customer or problem domain better, it would be better to avoid inference engines altogether.