0:00This video is about the ontology, the layer that declares what a domain may contain. We'll build one for a small domain of companies and people, and then set it beside the graph it governs.
0:12Let's start with two entities from a small graph.
0:15A company and a person, and each one carries a type.
0:19Those type names aren't just labels printed on the cards.
0:23They're declared up here, in the model. From now on, the upper band is where the model lives and the lower band is where the instances live.
0:31So when we say Acme is a Company, we're pointing an instance at something the ontology declares.
0:38Same for Alice and Person. That's what lets you ask about a whole class of things instead of listing I-Ds one at a time.
0:44Let's set the instances aside and look only at the model. Types can extend other types. Here an Employee is a kind of Person.
0:52And a Contractor and a full time employee are both kinds of Employee.
0:57That buys you something concrete. With subtype aware queries, asking about Employees also returns the narrower classes underneath.
1:05And this is a modelling choice somebody made, not a fact about the world. Another company's model might not count a contractor as an employee at all.
1:15Types are one part of the model. The next part says how types are allowed to connect.
1:20This rule says a Person may work at a Company. Not the other way round, and not Person to Person.
1:26Here's the one we'll keep coming back to. For acquired, both ends have to be Companies.
1:31Those two requirements have names of their own. The allowed source type is called the domain, and the allowed target type is called the range.
1:40The model also says how many values are allowed. A company has exactly one name.
1:45It has at most one founding year, which leaves room for simply not knowing it.
1:49And an acquisition has exactly one date. Rules about how many are called cardinality constraints.
1:55So the model has three parts, and we've now seen all of them. Put together, that is what the word ontology means.
2:03Rules are only useful if something actually checks them, so let's set that up first.
2:09For this demonstration, nothing is allowed to be both a Company and a Person. Types that exclude each other are called disjoint.
2:17And we've configured the system to check on write.
2:20That second part matters. Declaring a constraint in an ontology doesn't on its own cause anything to be rejected. Something has to enforce it.
2:29Now back to the acquisition rule, which says both ends must be Companies.
2:34And here's a fact somebody is trying to record. Alice acquired Beta.
2:39The subject gets checked against the required source type. Alice is a Person, and under our policy she can't also be a Company.
2:47So the relationship is rejected at write time, before the mistake works its way into answers downstream.
2:53Swap the subject for Acme and the same check passes. Both ends are the right type.
2:58But that's one check, and the rule asked for two things.
3:02The date is still missing, so this acquisition isn't complete.
3:06And passing a check doesn't make the claim true. It only means the claim is allowed.
3:11None of this is as unfamiliar as it might sound. If you've designed a database schema, you've done most of it already.
3:18Here's a company table. A table holds one kind of thing, and declares what you can say about it.
3:23The primary key identifies a roe that stands for a company. That's the same job the canonical I-D does on the other side.
3:31Now the acquisition table. Two foreign keys, both pointing back at company.
3:36The ontology says the same thing by naming the relationship. Both of them model the connection.
3:43And similar looking models can still enforce different things. This column permits a missing closing date. The ontology requires one.
3:51Where they really differ is in what happens when the domain changes. A new kind of fact can mean new table structure.
3:59On the graph side it's a new predicate in the same three columns, and it can connect types that don't share a table.
4:06That flexibility still has to be maintained by someone. This is a different lens, not a reason to throw out what you have.
4:14Let's put ontology and knowledge graph side by side, because these two words get used as if they meant the same thing.
4:21On the left, the model. A Company may acquire a Company. That's a rule about what the domain permits.
4:28And an acquisition has exactly one date. Also a rule. Still no acquisition.
4:33On the right, the graph. Two specific companies, each with its own I-D.
4:38And a specific relationship between them, of a kind the model allows.
4:42Written out in full, that's the whole assertion, and it carries a date. Acme acquired Beta on the second of April, twenty nineteen.
4:51So: ontology means the schema. The rules, and nothing else.
4:55Knowledge graph means the populated entities and the assertions recorded about them. One says what a domain allows, the other holds what it has.
5:05So here's where that leaves you.
5:07You can read an ontology as three kinds of rule: the types, how they may connect, and how many values a thing may carry.
5:16And you can keep the two layers apart. The ontology says what the domain allows, and the graph holds what has been recorded in it.
5:24One thing to carry out of this. A rule only rejects a bad fact if something enforces it, and passing a check only means a claim is allowed.

What an Ontology Declares

Created by Abhyuday DesaiPublished 3 Oct, v1Runs 5 min 39 sec

0 views

About this video

Ontology and knowledge graph get used as if they meant the same thing. This video builds the ontology for a small domain of companies and people, watches a validator reject a bad fact at write time, compares the whole idea to a relational schema, and ends on the definition that keeps the two apart.

You'll learn how to:

Read an ontology as types and subtypes, domain and range, and cardinality constraints
Understand why a declared constraint rejects nothing until something enforces it, and why passing a check is not the same as being true
Map the ontology onto a relational schema you already know, and see where the two differ when the domain changes
State precisely what an ontology holds and what a knowledge graph holds

For developers who have designed a database schema and want to know what an ontology adds.

What changed

v103 Oct 2026abhydesai5 min 39 sec21ba95b

First published version.

0 views0 likes on this version