AI Glossary / Graphs and symbolic AI / Advanced

Inductive logic programming

Definition

Inductive logic programming, usually abbreviated ILP, is a machine-learning approach that learns logical rules from examples and background knowledge. The learned hypothesis is a logic program: a collection of rules that can be used with the supplied knowledge to explain examples and make further inferences. It combines inductive learning with relational, commonly first-order, representations.

What it means

Instead of representing every observation as an isolated row of numerical features, an ILP task can describe objects and relationships between them. The learner tries to discover a definition for a target relationship. Human-provided background knowledge supplies useful building blocks, but the target definition is learned from examples rather than simply copied from a complete specification.
ILP differs from ordinary logic programming, where a programmer supplies the rules to execute. It also differs from the Carnap-associated meaning of inductive logic, which concerns formal degrees of evidential support rather than specifically learning executable logical hypotheses.

How it works

Define the target predicate and provide background knowledge B. In a common noise-free setting, positive examples identify target statements that should follow, and negative examples identify statements that should not follow.
The learner searches a permitted hypothesis space for rules H such that B together with H entails the positive examples and does not entail the negative examples. Systems supporting noisy observations can use objectives that trade fit against complexity instead of requiring perfect consistency.
Constraints on the rule language make search more manageable. They can restrict available predicates, argument types, clause length, or recursion. Some systems generate candidate programs, test their consequences, and use failures to exclude further candidates. ILP names a family of approaches, not a single search procedure or a guarantee that every learned program is optimal.

Three practical examples

• A logistics analyst learns a route qualification rule from examples and background facts about links and transfer facilities. Relations between several locations can appear directly in the rule.
• A software team learns a small list-processing program from input-output examples and permitted operations. The resulting program must still be checked on inputs beyond the demonstrations.
• An engineering team explores rules connecting component arrangements with labeled assembly outcomes. Existing structural relationships help express patterns that would be awkward to describe using only independent component attributes.

Think of it this way

Think of giving a trainee a map, a vocabulary of allowed relationships, and examples of approved and rejected journeys. The trainee proposes a general rule and checks its consequences. Knowing the map supports the task, but the examples may still leave several possible rules open.

Worked example

Consider an invented target predicate qualified_route(Start, End). The intended examples concern routes using exactly two directed links with a certified intermediate location.
The background knowledge contains four link facts: link(a,b), link(b,c), link(a,d), and link(d,e). It also contains certified(b). These are the only background facts used in this example.
The positive training example is qualified_route(a,c). The negative training examples are qualified_route(a,b), qualified_route(a,e), and qualified_route(b,c). A negative example means the candidate program should not derive that target statement. The examples themselves are not inserted as target facts for the program to reuse.
Consider candidate A:
qualified_route(X,Z) :- link(X,Z).
Here uppercase letters are variables, and the symbol :- means that the conditions on the right imply the conclusion on the left. Candidate A derives direct routes. It misses the positive example a-to-c and incorrectly derives the negative examples a-to-b and b-to-c.
Candidate B uses two links:
qualified_route(X,Z) :- link(X,Y), link(Y,Z).
This derives a-to-c through b, but also a-to-e through d. It therefore covers the positive example while incorrectly covering one negative example. Adding another condition may exclude that unwanted consequence.
Candidate C is:
qualified_route(X,Z) :- link(X,Y), certified(Y), link(Y,Z).
For a-to-c, choose X = a, Y = b, and Z = c. All three conditions are supported by the background facts. For a-to-e, the potential intermediate location is d, but certified(d) has no support in the supplied knowledge. Candidate C therefore does not derive a-to-e. It also derives neither of the direct-route negative examples.
Over this background, candidate C derives the pair (a,c), satisfying the stated training requirement. This does not prove that certification is the true operational policy; it establishes that this candidate fits the supplied examples and representation.
For a generalization check, add background facts link(x,y), link(y,z), and certified(y), without adding a labeled target fact for x-to-z. Candidate C now derives qualified_route(x,z) using the same variable-based rule. A hypothesis that merely memorized qualified_route(a,c) would not make that inference.
Finally, absence of certified(d) is not a universal statement that d lacks certification in reality. Missing background information can affect what the program derives. Correct deployment therefore depends on what the recorded facts mean and whether the needed information is available.

Illustrative case study

Fictional Maple Logistics experiments with learning route rules from historical examples. The team initially allows only direct-link predicates in candidate bodies, making the desired intermediate-location pattern impossible to express.
After reviewing the representation, it permits a shared intermediate variable and the certification predicate. The learned rule fits the training cases, but Maple tests additional route structures before adopting it.
The review also finds incomplete certification records. Maple separates missing knowledge from observed rejection labels so that data gaps do not silently become claims about real facilities.

Common misconceptions and mistakes

“ILP only executes handwritten rules.” Its central task is learning rules.
“Training examples uniquely determine a program.” Several hypotheses may fit them.
“Readable rules are automatically correct.” Their assumptions and consequences still need review.
“An absent fact is always false.” That depends on the chosen semantics and data interpretation.
“Every ILP system learns recursion.” Supported language and search capabilities vary.

Business use

Choose ILP when relationships and reusable background knowledge are central to the task. Budget for defining predicates, preparing examples, and reviewing derived consequences. Compare useful generalization with memorization, and document restrictions that limit possible hypotheses. A short rule can aid inspection, but its dependence on incomplete or mistaken background facts remains operationally important.

People also ask

Is ILP a single algorithm?

No; multiple learning strategies exist.

Can background knowledge include rules?

Yes, as well as facts.

Must all examples be perfectly fitted?

That depends on the learning setting and noise treatment.

Check your understanding

Why does candidate B fail?

Answer: It also derives the negative a-to-e route.

What does the shared Y enforce?

Answer: Both links pass through the same intermediate location.

Why does candidate C generalize to x-to-z?

Answer: Its variables express a reusable relational pattern.

Related terms

• Predicate (logic)
• Background knowledge
• Hypothesis space
• Entailment
• Inductive bias
• Logic programming
• predicate
• relational learning

Learn next

Add certified(d) to the background. Identify the newly derived route and explain why the existing negative example would then conflict with candidate C.

More in Graphs and symbolic AI

• Indexing - Indexing is the process of organizing a knowledge base so that a reasoning system can fetch potentially relevant facts or rules efficiently.
• Inductive learning - Inductive learning is learning a general rule or predictive function from specific examples.
• Inductive logic - Inductive logic is the study of formal principles for assessing how strongly evidence supports a hypothesis without necessarily proving it.
• Inference - Inference is the process of obtaining conclusions or outputs from available information using a specified method.
• Inference Data - Inference data consists of the input values supplied to a trained machine-learning model when it produces a prediction or other output.
• Inference engine - An inference engine is the component of a knowledge-based system that applies rules or other reasoning procedures to available facts to derive conclusions...

Sources

AIMA glossary, inductive logic programming: https://github.com/aimacode/aima-glossary/blob/master/glossary.md Stephen Muggleton, Inductive Logic Programming: https://www.doc.ic.ac.uk/~shm/Papers/ilp.pdf Andrew Cropper and Rolf Morel, Learning programs by learning from failures: https://link.springer.com/article/10.1007/s10994-020-05934-z

Previous: Inductive logic Next: Inductive probability