A knowledge-based system (KBS) solves problems by reasoning over an explicit, structured model of a domain. Every expert system is a KBS, but the term emphasizes representations richer than flat IF-THEN rules: semantic networks, frames with inheritance, formal ontologies, and libraries of solved cases. These structures capture what things are and how they relate, so the system can classify new objects, inherit defaults, detect inconsistencies, and answer questions it was never explicitly programmed for.
Part of Knowledge & Reasoning. For production-rule engines see Rule-based Systems; for large-scale entity data see Knowledge Graphs.
Semantic networks represent concepts as nodes and relations as labeled edges, with is-a and instance-of links forming a taxonomy. Properties attached to a class are inherited by subclasses and instances unless overridden lower down.
Frames (Minsky, 1974) package this into record-like structures: a frame has slots with values, defaults, type constraints and attached procedures (demons) that run when a slot is read or written. Frames are the intellectual ancestor of object-oriented classes. Default inheritance with overrides is non-monotonic: adding a fact ("Tweety is a penguin") can retract a conclusion, which classical logic cannot express directly.
An ontology is a formal, shared specification of the concepts in a domain and the relations between them. On the web stack, data is expressed as RDF triples, schemas as RDFS, and richer axioms in OWL, whose semantics come from description logics — decidable fragments of first-order logic. The TBox holds class and property axioms; the ABox holds facts about individuals.
A reasoner computes the class hierarchy (subsumption), infers class membership of individuals, and detects contradictions. OWL profiles trade expressiveness for speed: OWL 2 EL scales to very large medical ontologies such as SNOMED CT, OWL 2 QL is designed for rewriting queries over relational databases, and OWL 2 RL can be implemented with rules. OWL uses the open-world assumption: a missing fact is unknown, not false. That differs from databases and from most rule engines, and it surprises newcomers.
Case-based reasoning (CBR) solves new problems by analogy to stored, solved ones, following Aamodt and Plaza's 4R cycle. Its knowledge lives in the case library plus a similarity measure and adaptation knowledge, which suits help desks, legal precedent, maintenance and design, where experts themselves reason from examples. CBR learns incrementally by retaining cases and degrades gracefully, but quality depends on the similarity metric and on adaptation, which is often the hardest part to automate.
# pip install rdflib owlrl
from rdflib import Graph, Namespace, RDF, RDFS
import owlrl
EX = Namespace("http://example.org/")
g = Graph()
g.bind("ex", EX)
# TBox
g.add((EX.Manager, RDFS.subClassOf, EX.Employee))
g.add((EX.Employee, RDFS.subClassOf, EX.Person))
g.add((EX.manages, RDFS.domain, EX.Manager))
g.add((EX.manages, RDFS.range, EX.Team))
# ABox
g.add((EX.ana, EX.manages, EX.platform_team))
g.add((EX.bob, RDF.type, EX.Employee))
# Materialize entailments (OWL 2 RL rule set, includes RDFS)
owlrl.DeductiveClosure(owlrl.OWLRL_Semantics).expand(g)
q = """
SELECT ?who ?cls WHERE {
?who a ?cls .
FILTER(?cls IN (ex:Person, ex:Employee, ex:Manager, ex:Team))
} ORDER BY ?who ?cls
"""
for who, cls in g.query(q, initNs={"ex": EX}):
print(who.split("/")[-1], "is a", cls.split("/")[-1])
# ana is inferred to be a Manager, Employee and Person; platform_team a Team.
Note that rdfs:domain is an inference rule, not a validation constraint: anyone who manages something becomes a Manager. To validate data, use SHACL shapes (pyshacl) instead.
| Ontology / frame KBS | Rule-based | Machine learning | |
|---|---|---|---|
| Knowledge form | Concepts, relations, axioms | IF-THEN productions | Learned parameters |
| Main inference | Classification, inheritance | Chaining | Function evaluation |
| Data needed | Little; expert effort | Little; expert effort | Lots of labeled examples |
| Explainability | High | High | Low to medium |
| Reuse across apps | High (shared vocabulary) | Low to medium | Medium (transfer learning) |
Suppose a small ontology states three axioms in the TBox: Penicillin is a subclass of BetaLactamAntibiotic; BetaLactamAntibiotic is a subclass of Antibiotic; and anything that hasIngredient some BetaLactamAntibiotic is a BetaLactamProduct. The ABox records that Amoxil hasIngredient amoxicillin, and that amoxicillin is a Penicillin. No one stated that Amoxil is a beta-lactam product, but a reasoner derives it in two steps: amoxicillin is a Penicillin, hence a BetaLactamAntibiotic (subsumption), so Amoxil satisfies the defining condition and is classified as a BetaLactamProduct. A rule "flag any BetaLactamProduct for a patient with a penicillin allergy" now fires for Amoxil without anyone having written that drug into the rule.
The open-world assumption shapes the other direction. If the ABox does not say whether a second product contains a beta-lactam, the reasoner does not conclude that it is safe; it concludes nothing. Systems that need "not recorded means false" add closed-world checks with a constraint language such as SHACL or with queries over the data.
The well-known bottleneck of knowledge-based systems is acquisition: experts find it hard to articulate what they know, and their vocabulary is ambiguous. Good practice is to start from competency questions, the concrete questions the system must answer, and model only what they require. Reuse existing vocabularies (schema.org, SKOS, domain ontologies such as SNOMED CT or the Gene Ontology) instead of reinventing classes. Run a reasoner after every change to catch unsatisfiable classes, and keep the ontology in version control with review, just like code. Name deprecated terms rather than deleting them, because downstream data may still refer to them.
| Need | Common options |
|---|---|
| Ontology editing | Protégé (desktop and web) |
| Reasoners | HermiT, Pellet, ELK (OWL 2 EL, very large ontologies), FaCT++ |
| Storage and query | RDF triple stores queried with SPARQL; property-graph databases for knowledge graphs |
| Data validation | SHACL shapes for closed-world constraints |
| Python | rdflib for RDF and SPARQL, owlready2 for OWL with an embedded reasoner |
Large language models hold a great deal of implicit knowledge but cannot guarantee consistency, cite a source for every fact, or apply a rule exactly every time. Explicit knowledge bases have the opposite profile. Current systems combine them: an LLM translates a user question into a SPARQL or Cypher query over a curated graph, retrieval-augmented generation pulls facts and their provenance from a knowledge graph (often called GraphRAG), and LLMs assist knowledge engineers by proposing candidate classes, synonyms and relations that a human then reviews. The ontology provides the guarantees; the language model provides the interface and coverage of informal text. See Retrieval-Augmented Generation and Logic & Inference.
Further reading. Minsky (1974), "A Framework for Representing Knowledge"; Brachman and Levesque (2004), Knowledge Representation and Reasoning; Baader et al. (2003), The Description Logic Handbook; Aamodt and Plaza (1994), "Case-Based Reasoning: Foundational Issues, Methodological Variations, and System Approaches"; Gruber (1993), "A Translation Approach to Portable Ontology Specifications"; W3C OWL 2 Web Ontology Language Primer (2012); Noy and McGuinness (2001), "Ontology Development 101".