Most of my posts lately have been about my travels, so I think it is time to write a little about my work. On my first post for this PIRE grant to Barcelona, I mentioned the work that my collaborators have made on the SERA project. Although we decided not to directly interface with this system, we are using the main technique employed in that project: A Rules-based inference system.

So how does it work? More or less like this: In a Rule-based inference system, you have some input 'facts'. For example:

1. Xabriel is the son of Jose.
2. Jose is the son of Aurelio

The Rule system has, well, 'rules'. These work as templates for variables that the system tries to satisfy. If a rule is satisfied, then it gets 'fired'. Lets take this example rule:

• If 'person_1' is son of 'person_2', and 'person_2' is son of 'person_3', then 'person_1' is grandson of 'person_3'.

Based on the facts above, we can match all the variables (I.e. person_1 to Xabriel, person_2 to Jose, and person_3 to Aurelio), the rule gets fired, and thus it infers that Xabriel is the grandson of Aurelio.

I made this example very simple, but both the facts and the rules can get arbitrarily complex. The work of a Rules-based inference system is to make the matches, to be always correct ('correct' according to the given facts) and to be efficient (because we don't want to wait 5 minutes to know that Xabriel is the grandson of Aurelio). Most forward-chaining rule systems do fast inferencing by implementing the RETE algorithm, or a derivation of it. This algorithm was proposed by Charles L. Forgy when doing his PhD at CMU.

Now the power of this is that you can decompose a quite complex system into simpler parts and give it to a rule engine to infer some new facts. Think of a general graph. It is quite complex if you look at it as a whole:

But as we now, we can decompose it into simpler relations between its members:

• "1" is connected to "2" (and viceversa)
• "2" is connected to "3" (and viceversa)
• etc.

Can you see the similarity with the previous example facts? They are both describing relations. "Object 1"  has "relation A" with "Object 2". We can of course use this way of representation for a bunch of stuff. In my case, to represent Distributed Ensembles of Virtual Appliances (DEVAs). We describe DEVAs in easy to comprehend facts (I.e. "Appliances 1 has installed Service A") and then we try to infer some other info from that. I cannot comment on the details of what we are doing, but I can say that rules do map well to our problem domain.