Basic Modes Guide

Part 5 in a Series on BoostSRL

Previous Page - Wiki - Next Page

---

The modes of our system follow the Aleph modes definitions. Please refer to http://www.cs.ox.ac.uk/activities/machinelearning/Aleph/aleph for Aleph definitions. Modes are used to restrict/guide the search space and are a powerful tool in getting relational algorithms such as BoostSRL to work. So if your algorithm does not learn anything useful, then the first debug point would be the modes (in the bk.txt file).

The key difference is that for our case, we use the mode definitions of the form:

mode: predicateName(ModeTypeArg1,...).

For example consider the famous 'trains' testbed of Michalski:

mode: eastbound(+train).

mode: short( +car).

...

mode: shape( +car, #shape).

mode: has_car(+train, -car).

The modes supported by our system are +,- and #. These follow the definitions of Aleph:

(1) +v: indicates that variable v must be already mentioned in the current tule before. For instance, let us assume that the goal is to learn if the train is eastbound (i.e., eastbound(train) is the target)). Then the search algorithm first considers only the predicates that has a modeType +train in them. If no predicates has the modeType +train, the algorithm terminates. In this case, it will add has_car as it has the modeType +train.

(2) -v: indicates that a new variable v can be introduced into the clause (essentially an EXISTENTIAL). So, continuing the above example, has_car can be added because it has both +train and -car. -car allows for a new variable to be added and +train will allow for the algorithm to consider this predicate. It should be mentioned that if the mode definition had been has_car(+train,+car), it would have been ignored by the search. This is because, while train has been declared earlier (in the target), car has not been defined earlier and this predicate will be ignored. Hence to add a clause say has_car(X,Y) -> eastbound(X), it is essential that the car is of type -.

(3) #v: indicates that the variable is of type constant. This is the simplest of all the modes in that the variables are grounded and their specific values are searched over.

Finally, if one observes closely, has_car(X,Y) -> eastbound(X) is not informative in that all the trains will have at least one car. Hence, the algorithm can never learn this clause. To enable learning of this clause, one has to increase the lookahead of the search algorithm. This can be achieved in two ways:

(1) Setting a parameter in bk.txt. nodeSize=2 will allow for two predicates to be considered at the same time. So it is possible to learn has_car(X,Y) ^ big(Y) -> eastbound(X).

(2) Defining a bridger. The other simple way to do this is to define has_car as a bridger. The bridger predicate will not be scored during search but will serve to merely introduce new objects in the search space (in this case, a car). This is defined as follows:

bridger: has_car/2.

The number after the / sign indicates the number of parameters of that predicate.

Feel free to contact us if your particular mode file does not work.