Is inheritance the same as a part-of relationship?

No. A wheel can be part of a vehicle without being a kind of vehicle.

Can an individual belong to several categories?

Yes. Whether the combined classifications are consistent depends on the category definitions and constraints.

Does missing information count as an exception?

Not automatically. Open-world and default systems handle absence differently, so the inference policy must be explicit.

AI Glossary / Graphs and symbolic AI / Intermediate

Inheritance

Definition

Inheritance in knowledge representation is the use of a category hierarchy to derive information about more specific categories or their members from information attached to broader categories. Its exact behavior depends on whether the system uses strict logical rules, defaults or another explicitly defined mechanism.

What it means

If every calibration device is a measuring device, and Unit7 is a calibration device, the system can infer that Unit7 is a measuring device. This avoids repeating the broader classification for every individual unit.

Inheritance can also support consequences expressed for a whole category. If all measuring devices must have a recorded inspection status, that condition applies to calibration devices through the hierarchy. The condition must be represented appropriately; merely attaching an arbitrary note to a class does not make every member inherit it logically.

This entry concerns symbolic knowledge representation. Object-oriented programming uses the same word for related mechanisms involving classes and implementation reuse, but programming-language rules should not be assumed to define an ontology's reasoning behavior.

How it works

Represent categories and their relationships, such as subclass links, and identify the individuals belonging to them. A reasoner can follow strict inclusion relationships: membership in a subclass entails membership in its superclass.

Distinguish strict statements from defaults. A strict statement applies to every member under the model. A default describes what is normally assumed unless qualifying evidence defeats it. Default inheritance therefore needs an explicit account of exceptions and conflicts.

Multiple inheritance allows a category to have more than one parent. Compatible consequences can combine, but conflicting defaults or inconsistent strict constraints require attention. There is no universal rule that the nearest-looking node in a diagram always wins. The representation language and inference policy determine what follows and how conflicting information is handled.

Three practical examples

An equipment knowledge base infers broad device classifications from specific model categories.
A service-rule system applies a defined general requirement to all members of a category while recording explicit exceptions through its chosen default mechanism.
A terminology model places a specialized component under two compatible categories so queries through either category can find it.

Think of it this way

Think of a handbook with a general section and narrower sections for particular teams. A rule that truly applies to everyone in the general section also applies to each included team.

The analogy has limits. Handbooks may contain informal exceptions or contradictory wording. A knowledge system needs explicit semantics for those cases rather than relying on a reader's intuition about which paragraph overrides another.

Worked example

Following strict links without inventing an exception rule

Consider an invented hierarchy: CalibrationDevice is a subclass of MeasuringDevice, and MeasuringDevice is a subclass of Equipment. Unit7 is explicitly a CalibrationDevice. Strict inclusion therefore yields MeasuringDevice(Unit7) and Equipment(Unit7).

Now add the rule that every MeasuringDevice requires an inspection record. This yields RequiresInspectionRecord(Unit7). The conclusion comes from the class membership and rule, not from copying every annotation attached to the category.

Suppose the team also writes “portable equipment normally uses a battery” and classifies Unit7 as PortableEquipment. That statement is a default, not the strict assertion that every portable item uses a battery. If Unit7 is explicitly mains-powered and the model treats the power choices as incompatible, a default system may withhold the battery assumption according to its exception policy.

Encoding the default as an unconditional universal statement would instead create a conflict under those incompatibility assumptions. Adding a more specific category would not automatically retract the strict statement. The distinction between strict inheritance and defeasible inheritance is therefore part of the model, not merely a diagramming preference.

Illustrative case study

The fictional Cedar Knowledge team builds a product-support hierarchy. A general category description says that devices normally support a wireless connection, and the team initially treats that wording as a strict requirement for all descendants.

A wired-only product then causes contradictory conclusions. Reviewers separate true category definitions from typical features and record the wireless assumption using an explicitly supported default approach. They keep strict subclass links for actual inclusion relationships.

Cedar tests representative products with missing, exceptional and conflicting information. The case illustrates a modeling repair, not a claim that all ontology languages offer automatic default overriding or that a hierarchy removes the need to maintain accurate product facts.

Common misconceptions and mistakes

Inheritance means copying every property statement down a tree. Logical consequences depend on how statements and restrictions are represented.
Every typical feature is a universal truth. Defaults and strict assertions have different meanings.
A subclass automatically overrides a superclass in every knowledge language. That is not the behavior of ordinary strict logical inclusion.
Multiple inheritance always creates a conflict. It can combine compatible categories; conflicts depend on the actual assertions.

Business use

Inheritance can reduce duplication and make classification rules easier to maintain. A correctly modeled category relationship lets one general statement support many specific conclusions.

The main governance issue is the effect of a change high in the hierarchy. A mistaken broad assertion can affect many descendants. Review whether a relationship means kind-of, part-of or merely associated-with, because those support different inferences. Keep explanations that show the membership links and rules behind a conclusion. When exceptions matter, select and document a reasoning mechanism that actually supports them rather than relying on an informal expectation of overriding.

Check your understanding

Why does Unit7 belong to Equipment even if that membership was not entered directly?

Answer: Unit7 belongs to CalibrationDevice, which is included in MeasuringDevice, which is included in Equipment. The strict subclass chain supports the inferred membership.

Related terms

Semantic network
Ontology
Multiple inheritance
Subclass
superclass
default reasoning
defeasible reasoning
class membership

Learn next

Draw a three-level product hierarchy and add one individual. Write two genuinely universal rules and one typical feature. Explain which conclusions follow strictly and which require an explicit default-and-exception mechanism.

Sources

The W3C OWL 2 Primer explains subclass relationships, class membership and logical modeling: https://www.w3.org/TR/owl2-primer/

The original research paper Default Inheritance Reasoning in Hybrid KL-ONE-Style Logics discusses adding default reasoning to taxonomic representation: https://www.ijcai.org/Proceedings/93-1/Papers/095.pdf

The device hierarchy and Cedar Knowledge case are original examples. Default overriding is not attributed to ordinary OWL subclass semantics.

Previous: Infrastructure as code Next: Inherited Bias