0:00This video is about the building blocks of a knowledge graph: entities, attributes, and relationships. Then we'll see how one fact gets written down as a triple.
0:09Let's build a small domain by hand, and start with a single company.
0:13Here it is, the company everything else in this video hangs off.
0:18Inside the graph it carries a canonical I-D. Our worked examples write that as just acme, for short.
0:25That makes it an entity: a particular thing with an identity that persists, whatever else changes around it.
0:31Now we can describe it. The first fact we record is what the company is actually called.
0:36The second is the year it was founded.
0:38Both of those are attributes: facts about the company rather than the company itself. Notice the name is a value it carries, not the identity it has.
0:47Next we'll add a person. Alice Chen gets her own I-D, and her own type.
1:16Alice works at Acme, and that connection is a relationship: a typed fact between two entities.
1:23Drawn in the graph it becomes an edge, with a direction and a name of its own.
1:28Here's that same company on its own, and this time we're looking at how it gets referred to.
1:32Its identity is this I-D. Nothing about it depends on how anyone happens to spell the name.
1:38And people spell it in all sorts of ways.
1:40Each of these is a mention: an occurrence of a name somewhere in a piece of text.
1:45Different spellings don't create different companies. They also don't prove the opposite.
1:51Whether two mentions refer to the same thing is a separate question, and nothing here has answered it.
1:57A roe in a C-R-M system is a different kind of representation again. It has its own key, and its own spelling of the name.
2:05So we link the record to the entity it describes. And notice what doesn't happen to it.
2:40It stays exactly where it was. Keeping it is what lets us trace a fact back to its source, or undo the link if we got it wrong.
2:49Alice has a city, and right now it's just a value sitting inside her card.
2:53It's the string Berlin. If all you need is to display it or filter on it, an attribute is enough.
3:02But suppose you want to ask this. A plain string can't answer it, because nothing else in the graph points at that string.
3:08So we promote the value. Berlin becomes an entity in its own right, with its own ID and its own type.
3:16That's a modelling decision we made, not something the string did on its own.
3:20Alice connects to it through located in. Same information, now carried by a relationship rather than a value.
3:27And now other things can reference the same place. Here's Acme again.
3:31Acme is located in Berlin too. That's a second edge arriving at the same node.
3:37Which means the question has an answer. Follow Alice's location to Berlin, then look at every other edge arriving there.
3:44So here's the test for when to promote a value. Three things to check.
3:48Does anything else need to refer to it?
3:50Does it need attributes of its own?
3:53And does it sit on a path you'd want to follow?
3:56Berlin answered yes to all three, which is why it earned an identity. When none of them is true, keep the simpler model.
4:02We've been drawing relationships. Here's how you write one down.
4:06This is one fact, set out in three parts.
4:09Who the fact is about, what kind of connection it is, and what sits on the other end. Read it straight across and you get the relationship we drew a moment ago.
4:20That three part form is called a triple. In this one, both ends identify entities.
4:26The far end doesn't have to be an entity, though. Here it's a piece of text that belongs to Acme and has no separate existence of its own.
4:34And here the far end isn't a value at all. Company is neither a particular company nor a piece of text. It's the group that org acme is a member of.
4:44Now let's add a second company, Beta, with an I-D of its own.
4:48Acme acquired Beta. That's a new kind of connection between two things we already had on screen.
4:53And writing it down takes the same three columns. No new column on a company table, and no migration. A different kind of fact is just a different predicate.
5:04We already know Acme is in Berlin.
5:06Here's that fact written out as a triple.
5:09Now suppose we learn something more specific. Berlin is where Acme is headquartered.
5:14That's a second predicate about the same pair of entities, and it doesn't overwrite the first one.
5:19Both assertions sit there together. Adding one needed no table migration, though changing your vocabulary can still mean validation work.
5:28Here's the entity both of those facts are about.
5:31And here are two more facts about it. Its name, and the year it was founded, each written as its own triple.
5:39Which brings us to what this form costs.
5:41One entity's description ends up scattered across several facts, so a query has to gather the pieces rather than read one record.
5:49Labelled property graphs package the same material differently. The properties sit directly on the node, in chunkier units.
5:57Either way, though, flexible storage doesn't tell you which facts the domain ought to allow. Deciding that is a separate job, and it belongs to the schema rather than to the storage.
6:09So here's where that leaves you.
6:11You can tell a persistent entity apart from its names and from the records that describe it. And you can decide when a plain value deserves an identity of its own.
6:20You can also read a triple, and say what that form gives you and what it costs.
6:26One thing to carry out of this. An entity is the thing with the identity, and everything else is a fact recorded about it.

Entities, Attributes, and Relationships

Created by Abhyuday DesaiPublished 3 Oct, v1Runs 6 min 40 sec

0 views

About this video

A knowledge graph is built from three kinds of thing, and this video builds a small one by hand: a company as an entity with a canonical id, its name and founding year as attributes, and a person connected to it by a typed relationship. Then it writes one fact down as a triple and shows what that three-part form gives you and what it costs.

You'll learn how to:

Tell an entity apart from the names people spell it with and the records that describe it
Decide when a plain value, like a city, deserves an identity of its own (the promotion test)
Read and write a fact as a triple, and add a new kind of fact without a migration
See where the triple form scatters an entity's description, and how property graphs package it differently

For developers who know relational databases and want to model a domain explicitly. No prior knowledge graph experience needed.

What changed

v103 Oct 2026abhydesai6 min 40 sec21ba95b

First published version.

0 views0 likes on this version