Background
Developed in 1990 byAlgorithm
The FOIL algorithm is as follows: :Input ''List of examples'' :Output ''Rule in first-order predicate logic'' :FOIL(Examples) ::Let Pos be the positive examples ::Let Pred be the predicate to be learned ::Until Pos is empty do: :::Let Neg be the negative examples :::Set Body to empty :::Call LearnClauseBody :::Add Pred ← Body to the rule :::Remove from Pos all examples which satisfy Body :Procedure LearnClauseBody ::Until Neg is empty do: :::Choose a literal L :::Conjoin L to Body :::Remove from Neg examples that do not satisfy LExample
Suppose FOIL's task is to learn the concept ''grandfather(X,Y)'' given the relations ''father(X,Y)'' and ''parent(X,Y)''. Furthermore, suppose our current Body consists of ''grandfather(X,Y) ← parent(X,Z)''. This can be extended by conjoining Body with any of the literals ''father(X,X)'', ''father(Y,Z)'', ''parent(U,Y)'', or many others – to create this literal, the algorithm must choose both a predicate name and a set of variables for the predicate (at least one of which is required to be present already in an unnegated literal of the clause). If FOIL extends a clause ''grandfather(X,Y) ← true'' by conjoining the literal ''parent(X,Z)'', it is introducing the new variable ''Z''. Positive examples now consist of those values <''X,Y,Z''> such that ''grandfather(X,Y)'' is true and ''parent(X,Z)'' is true; negative examples are those where ''grandfather(X,Y)'' is true but ''parent(X,Z)'' is false. On the next iteration of FOIL after ''parent(X,Z)'' has been added, the algorithm will consider all combinations of predicate names and variables such that at least one variable in the new literal is present in the existing clause. This results in a very large search space.Let ''Var'' be the largest number of distinct variables for any clause in rule ''R'', excluding the last conjunct. Let ''MaxP'' be the number of predicates with largestExtensions
The FOCL algorithmMichael Pazzani and Dennis Kibler. The Utility of Knowledge in Inductive Learning. Machine Learning, Volume 9, Number 1, 1992Constraints
Unlike FOIL, which does not put typing constraints on its variables, FOCL uses typing as an inexpensive way of incorporating a simple form of background knowledge. For example, a predicate ''livesAt(X,Y)'' may have types ''livesAt(person, location)''. Additional predicates may need to be introduced, though – without types, ''nextDoor(X,Y)'' could determine whether person ''X'' and person ''Y'' live next door to each other, or whether two locations are next door to each other. With types, two different predicates ''nextDoor(person, person)'' and ''nextDoor(location, location)'' would need to exist for this functionality to be maintained. However, this typing mechanism eliminates the need for predicates such as ''isPerson(X)'' or ''isLocation(Y)'', and need not consider ''livesAt(A,B)'' when ''A'' and ''B'' are defined to be person variables, reducing the search space. Additionally, typing can improve the accuracy of the resulting rule by eliminating from consideration impossible literals such as ''livesAt(A,B)'' which may nevertheless appear to have a highOperational rules
Operational rules are those rules which are defined ''extensionally'', or as a list of tuples for which a predicate is true. FOIL allows only operational rules; FOCL extends its knowledge base to allow combinations of rules called non-operational rules as well as partially defined or incorrect rules for robustness. Allowing for partial definitions reduces the amount of work needed as the algorithm need not generate these partial definitions for itself, and the incorrect rules do not add significantly to the work needed since they are discarded if they are not judged to provide positive information gain. Non-operational rules are advantageous as the individual rules which they combine may not provide information gain on their own, but are useful when taken in conjunction. If a literal with the most information gain in an iteration of FOCL is non-operational, it is operationalized and its definition is added to the clause under construction. :Inputs ''Literal to be operationalized, List of positive examples, List of negative examples'' :Output ''Literal in operational form'' :Operationalize(Literal, Positive examples, Negative examples) ::If Literal is operational :::Return Literal ::Initialize OperationalLiterals to the empty set ::For each clause in the definition of Literal :::Compute information gain of the clause over Positive examples and Negative examples ::For the clause with the maximum gain :::For each literal L in the clause ::::Add Operationalize(L, Positive examples, Negative examples) to OperationalLiterals An operational rule might be the literal ''lessThan(X,Y)''; a non-operational rule might be ''between(X,Y,Z) ← lessThan(X,Y), lessThan(Y,Z)''.Initial rules
The addition of non-operational rules to the knowledge base increases the size of the space which FOCL must search. Rather than simply providing the algorithm with a target concept (e.g. ''grandfather(X,Y)''), the algorithm takes as input a set of non-operational rules which it tests for correctness and operationalizes for its learned concept. A correct target concept will clearly improve computational time and accuracy, but even an incorrect concept will give the algorithm a basis from which to work and improve accuracy and time.References
*http://www.csc.liv.ac.uk/~frans/KDD/Software/FOIL_PRM_CPAR/foil.html