Logic for Ontologists: Open Worlds, Closed Worlds and Inference
The single most common complaint from newcomers to OWL goes like this: “I said every Order must have a Customer. I loaded an order with no customer. The reasoner said everything is fine. Is it broken?” It is not broken. It is reasoning under the open-world assumption, and until you internalise what that means, OWL will keep surprising you in both directions: failing to flag what you consider errors, and inferring things you never said. This lesson gives you the minimum viable logic for ontology work: where description logics come from, what the open-world and unique-name assumptions really do, what a reasoner can and cannot conclude, and why the validation language SHACL had to exist.
From first-order logic to description logics
Classical first-order logic (FOL) is the gold standard for expressing knowledge: quantifiers, variables, arbitrary relations. Its fatal flaw for engineering is that reasoning over full FOL is undecidable; no algorithm can be guaranteed to answer every entailment question in finite time. Description logics (DLs) are the family of carefully restricted FOL fragments that trade expressive power for decidability. You give up arbitrary formulas and keep a disciplined vocabulary: concepts (classes), roles (properties) and individuals, combined through constructors like intersection, existential restriction (“hasPart some Impeller”) and universal restriction (“hasPart only MetallicThing”). In exchange, you get algorithms that always terminate and well-understood complexity bounds. OWL 2 DL corresponds to the description logic known as SROIQ(D); its tractable profiles EL, QL and RL (lesson 6) correspond to smaller fragments with polynomial-time reasoning. The W3C OWL 2 Primer is the canonical readable entry point, and unlike most of what ranks for “OWL tutorial”, it is not a 2007 slide deck.
Two vocabulary items you will use forever: the TBox is the terminological part of a knowledge base (class and property axioms, the ontology proper), and the ABox is the assertional part (facts about individuals, the instance data). Reasoning tasks divide accordingly: classification and satisfiability checking live mostly in the TBox; instance checking and consistency involve both. Lesson 15 shows why the TBox/ABox balance determines whether your reasoner finishes in seconds or hangs overnight.
The open-world assumption, properly understood
The closed-world assumption (CWA) is what every SQL database makes: anything not recorded is false. If the flights table has no row for a Tuesday flight to Rome, there is no Tuesday flight to Rome. The open-world assumption (OWA), which OWL adopts, says: anything not stated is unknown. Absence of a triple is not evidence of absence. The choice is not academic fashion; it follows from what an ontology is for. OWL was designed for the web, where knowledge is distributed and perpetually incomplete. Your graph not containing someone’s email address does not mean they lack one; it means you have not integrated the system that knows it. Under OWA, conclusions are monotonic: new facts can never invalidate old inferences, which is exactly the property you want when data arrives incrementally from many sources.
Now replay the newcomer’s complaint. The axiom “Order subClassOf hasCustomer some Customer” does not mean “reject any order record lacking a customer link”. It means “in every possible world consistent with this ontology, every order has at least one customer”. Load an order with no stated customer and the reasoner concludes, quite correctly, that the customer exists but is unknown. No contradiction, no error. Worse for your intuitions: if you also said every Order has exactly one Customer, and your data links order O-77 to both “ACME Ltd” and “Acme Limited”, the reasoner still finds no contradiction. It infers the two names denote the same individual. Which brings us to the second assumption.
No unique names, and what sameness means
SQL and most programming environments make the unique name assumption (UNA): distinct identifiers denote distinct things. OWL deliberately does not. Two IRIs may name the same real-world individual, because on the open web independent parties mint identifiers for the same things constantly. Sameness and difference are therefore assertable facts: owl:sameAs declares two IRIs co-referent, owl:differentFrom declares them distinct, and owl:AllDifferent does so for a whole set. Cardinality axioms interact with this in ways that catch everyone at least once: “hasParent max 2” plus three asserted parents does not produce an inconsistency; it produces the inference that at least two of the three IRIs denote the same person. You get an actual contradiction only if you also assert the three mutually differentFrom. Entity resolution, which lesson 29 and the domain modules treat as an engineering discipline, is in logical terms the practice of earning your sameAs assertions.
What a reasoner can and cannot conclude
A DL reasoner performs a small set of well-defined services, and knowing them stops you expecting the wrong ones. Consistency checking asks whether your ontology plus data admits any possible world at all; if not, something must be repaired. Classification computes the full subclass hierarchy implied by your definitions, including subsumptions you never asserted; define VegetarianPizza as a Pizza with only vegetable toppings and define MargheritaPizza with tomato and mozzarella toppings, and classification will file Margherita under VegetarianPizza without being told, provided the definitions entail it. Satisfiability checking finds classes that cannot possibly have members (usually a modelling bug, such as inheriting disjoint parents). Instance realization computes which classes each individual provably belongs to.
| You want to… | Can a reasoner do it? | Right tool |
|---|---|---|
| Derive implicit subclass relationships from definitions | Yes, classification is its core service | OWL reasoner (HermiT, ELK) |
| Detect logically contradictory data or definitions | Yes, consistency and satisfiability checking | OWL reasoner |
| Flag a record missing a mandatory field | No, OWA infers the value exists but is unknown | SHACL constraint validation |
| Enforce “exactly one value, and it must be a string matching this pattern” | No for enforcement; cardinality axioms trigger inference, not rejection | SHACL |
| Treat two differently named records as distinct by default | No, OWL makes no unique name assumption | Assert differentFrom, or validate with SHACL under closed-world semantics |
| Answer “list all X where no Y is recorded” | Not as entailment; negation as failure is closed-world | SPARQL (FILTER NOT EXISTS) or SHACL |
Worked example · the Aberdeen-2 asset register
Where we left it: the register will record states with temporal extents, so history survives maintenance.
Meet valve V-205. The engineering register knows it exists; the maintenance system has no inspection record for it at all:
ex:V205 a ex:Valve ;
ex:installedAt ex:Aberdeen2 .
# no ex:lastInspected triple anywhere in the graphIs V-205 uninspected? Under the open-world assumption the only honest answer is: unknown. And for the register mid-integration, unknown is the truth: the contractor spreadsheet, the one source that holds the 2024-2026 inspection campaign, has not loaded yet. A closed-world system would have converted “not yet integrated” into “never inspected” and pushed a false alarm to the regulator. The register therefore needs both stances, in different places: OWA inside, while sources arrive incrementally and monotonically; a deliberately closed world at the report boundary, where the compliance report declares “across the three sources loaded as of this date” and treats absence as absence within that stated scope. Closing the world is legitimate exactly when you can name the world you are closing.
State of the register: open world for integration, declared closed worlds at report boundaries, with lesson 11’s validation language doing the closing. Next lesson the register finally becomes real triples.
Why OWL will not flag your missing data, and why SHACL exists
By now the pattern is clear: OWL axioms are inference rules about how the world must be; they are not integrity constraints on how your dataset must look. For a decade, practitioners abused OWL as a constraint language, got the behaviour described above, and concluded the semantic stack was unusable for data quality. The W3C’s answer, standardised in 2017, is SHACL, the Shapes Constraint Language: a language for closed-world validation of RDF data. A SHACL shape says, in effect, “every node of this kind in this dataset must have exactly one customer link, here and now, or I will emit a violation report”. Same graph, different question. OWL asks: what follows from what we know? SHACL asks: does the data in front of me meet expectations? Mature deployments run both, and lesson 11 makes the case that SHACL in continuous integration is the single highest-value practice in modern knowledge graph engineering. The division of labour also turns out to be the backbone of safe LLM pipelines: models propose triples under open-world generosity, and closed-world validators dispose of the garbage, a loop you will build in module 6.
What breaks · the KPI that changed overnight
The compliance team, fluent in SQL, computes the “uninspected valves” KPI the obvious way:
SELECT (COUNT(?v) AS ?uninspected) WHERE {
?v a ex:Valve .
FILTER NOT EXISTS { ?v ex:lastInspected ?d }
}Monday’s report tells the regulator: 12 uninspected valves. Tuesday the contractor batch loads, and the same query returns 3. No data was wrong on either day; the query faithfully counted “valves with no recorded inspection in this graph at query time”. The report, however, claimed “uninspected valves”, a statement about the world. The gap between those two sentences is where audit findings live, and negation as failure guarantees the gap exists whenever the graph is incomplete, which during integration is always. The repair is not a cleverer query: it is attaching the scope to the claim, either as a completeness statement (“all three sources loaded through 2026-07-31”) or by validating at a declared report boundary, which is precisely the job the lesson assigns to SHACL.
Monotonicity, negation and the edges of the map
Three final concepts round out your logical toolkit. First, monotonicity has a flip side: OWL cannot express defaults or exceptions (“birds fly, except penguins”) because a new fact may never retract an old inference; genuinely default-ridden domains need rules layered alongside the ontology. Second, negation: OWL’s complementOf is classical negation (“provably not a Customer”), which is much stronger than the everyday “not recorded as a Customer”; the latter is negation as failure and belongs to SPARQL and SHACL. Third, decidability comes with usage conditions: OWL 2 DL restricts how you may combine features (for instance, transitive properties in cardinality restrictions are forbidden) precisely to keep reasoning terminating, and tools that let you stray into OWL Full territory leave the guarantees behind.
The mental model to carry forward is a triangle. OWL is your inference layer: open world, no unique names, monotonic, deriving what must be true. SPARQL is your query layer: closed-world negation available on demand. SHACL is your validation layer: closed world, constraint-based, reporting what fails expectations. Practitioners who keep the three layers straight stop fighting the stack and start composing it. With the logic in place, module 2 begins with the data model everything else stands on: RDF, triples, IRIs and the serializations you will read and write daily. For a deeper graded treatment of the logic underlying OWL profiles, the semantic standards course extends this material with reasoning exercises.
Check yourself
The ontology contains the axiom “every Valve has some inspection date”. The graph contains no ex:lastInspected triple for V-205. Which conclusion is actually licensed?
- V-205 has never been inspected.
- V-205’s inspection status is unknown to the graph; nothing about the valve itself follows.
- The reasoner will report a violation, because the axiom requires an inspection date and none is present.
- A SPARQL FILTER NOT EXISTS check proves V-205 is uninspected, so the compliance report may state it as fact.
Show the answer, and why each wrong option is wrong
B is correct. Under the open-world assumption an absent triple is not evidence of absence. If anything, the axiom makes the reasoner conclude the opposite of an error: in every consistent world V-205 has some inspection date, currently unknown. That inference is the axiom doing its job.
A is the closed-world instinct imported from SQL: absence of a row means falsity. In a graph built by integrating incomplete sources, absence usually means “not yet loaded”, and Tuesday’s batch proves it. C is the OWL-as-constraint-language misconception this lesson exists to kill: axioms are inference rules about how the world must be, not integrity checks on the dataset, so no violation is ever reported. D confuses negation as failure with classical negation. NOT EXISTS establishes a fact about the graph at query time, which is legitimate inside a report whose scope is declared, and false the moment it is presented as a fact about the valve.
