Is the extensional component just the schema?

No. It concerns represented instances or facts, while the schema describes structure and constraints.

Can derived facts be stored?

Yes. Materialization stores results, but systems should still distinguish their derivation from original inputs.

Does an absent fact mean the opposite is true?

Not universally. That depends on the chosen reasoning semantics and completeness assumptions.

AI Glossary / Data engineering and architecture / Intermediate

Extensional Component

Definition

The extensional component of a database or knowledge system is its collection of represented instances or facts, considered separately from the definitions and rules that describe or derive information. In a deductive database, the extensional database commonly contains the input facts, while intensional rules define derived relations. Terminology varies across knowledge-representation frameworks, so the exact boundary should be stated when using the term.

What it means

A schema can say that a person may supervise another person. The extensional component records particular instances, such as Ana supervises Ben. A rule can then define an indirect supervisory relationship. Separating these roles helps explain whether an answer was supplied as a fact or obtained through reasoning. Calling something a fact in the database does not certify its truth in the world; it describes how the system represents the information.

How it works

Facts are supplied through files, tables, assertions, or other input mechanisms. Rules operate on those facts to produce consequences under the chosen semantics. In Datalog, a fact can be written as a predicate applied to specific values, while a rule expresses a relationship between predicates. A system may materialize derived results, but storing a result does not erase its derivation history. Some frameworks distinguish a ground extensional component from a derived extensional component; others reserve EDB for base inputs. Document the vocabulary used by the particular system.

Three practical examples

Organizational knowledge: recorded direct reporting relationships form input facts for deriving indirect reporting chains.
Software analysis: extracted facts about program statements feed rules that identify possible dependencies or reachable states.
AI knowledge grounding: a curated set of entity relationships provides explicit assertions that a retrieval or reasoning system can cite and distinguish from inferred conclusions.

Think of it this way

Think of the recorded observations in a laboratory notebook compared with the rules used to interpret them. The observations resemble extensional content, while the interpretation rules resemble intensional knowledge. The analogy is limited because stored database facts can include administrative assertions rather than direct observations, and derived conclusions may also be stored. Provenance, uncertainty, and the system's reasoning assumptions remain important.

Worked example

A toy extensional database contains edge(A, B) and edge(B, C). Define reachable(X, Y) when edge(X, Y), and also when edge(X, Z) and reachable(Z, Y). The rules derive reachable(A, B), reachable(B, C), and reachable(A, C). The direct input contains two edges; the derived reachable relation contains three pairs under these rules. No rule establishes reachable(A, A), so it should not be added merely because reachability sometimes includes a zero-length path in other definitions. If edge(B, C) is removed, the derived relationships relying on it must be reconsidered. Keeping a stale materialized reachable(A, C) without recomputation or maintenance would confuse an old consequence with a current supported result.

Illustrative case study

Fictional example: Aspen Logistics records direct route connections and derives possible multi-stop routes. A removed connection remains in an old derived table, causing an assistant to propose an unsupported route. The team records which data snapshot and rule version produced each derived result and refreshes the affected outputs. This invented case illustrates the need to manage base facts and consequences together; it does not demonstrate that a particular reasoning engine or maintenance algorithm solves every update problem.

Common misconceptions and mistakes

Do not confuse extensional with external: input facts need not come from outside the organization. Do not assume every stored tuple is a base fact, because derived results can be stored too. Avoid treating absence as proof of falsehood without checking the system's assumptions. Also distinguish the data-level fact from its provenance and confidence. An assertion imported from an unreliable source remains an assertion, even when it is syntactically valid and usable by rules.

Business use

The distinction supports explainable knowledge systems, reproducible analyses, and controlled updates. Record the source, date context, and relevant identifiers for assertions. Keep rules and input snapshots identifiable so an answer can be reproduced or challenged. For AI applications, make it possible to tell whether a statement was directly recorded, inferred by a formal rule, or generated as an unsupported suggestion. This improves the quality of review without pretending that database representation alone establishes real-world truth.

Check your understanding

A system stores two direct links and derives a third indirect link. Are all three necessarily original input facts?

Answer: No. The two direct links are base assertions in the example; the indirect link is a consequence of those assertions and the rules. Storing the consequence does not make it independently supplied evidence.

Related terms

Intensional Component
Datalog
Deductive databases
Fact
Inference rules
Closed-world assumption
extensional database
deductive database
inference rule
materialization
provenance
knowledge graph

Learn next

write three base facts and two simple rules, then list every consequence by hand. Change one input and identify which conclusions lose support. Finally decide how your system will label base assertions and materialized consequences so users can trace the origin of an answer.

Sources

Sources: Soufflé, Facts, https://souffle-lang.github.io/facts ; Soufflé, Tutorial, https://souffle-lang.github.io/tutorial ; Soufflé project execution documentation, https://github.com/souffle-lang/souffle-lang.github.io/blob/master/pages/docs/execute.md . Primary project search excerpts consulted for facts, input files as EDB, and reachability rules. The broader terminology discussion and fictional examples are original synthesis; the entry flags framework-dependent treatment of derived extensional content.

Previous: Extension neural network Next: Extensive form