Ontology as graph: entities, relationships, and extensibility

Video focus: approximately 05:24–06:27.

An ontology gives an agent a structured description of a domain. In this part of the talk, Frank Coyle presents that description as a graph of entities, the relationships between them, and the properties that describe them. This structure makes an organization's important concepts and connections explicit before an agent must reason about them.

The three building blocks

The terms are related, but they play different roles:

• An entity is a thing the organization cares about. It might be a customer, an order, or a product.
• A relationship connects one entity to another and says how they are connected. A customer placed an order, for example.
• A property is information that describes an entity or, in some models, a relationship. An order might have a status or an order date.

One simple representation could look like this:

[Customer: Maya] ──placed──> [Order: 1042]
                                  │
                            status = shipped

Here, Maya and Order 1042 are entities. placed is a relationship. status and its value shipped are a property and its value. The graph is useful because it keeps both the things and the connections visible. An agent can therefore work with a model of the domain rather than with an unstructured collection of words.

Teaching example: The small graph above is an explanatory example, not a quotation or a specific example from the video. Its purpose is to show the roles of entity, relationship, and property.

Why use a graph representation?

Coyle connects ontologies with graph databases and knowledge representation. The important idea is not that an ontology and a graph database are exactly the same thing. An ontology is a conceptual model: it says what kinds of things and connections exist and how they should be understood. A graph database is an implementation or storage structure that can store and retrieve connected items. The speaker's argument is that these ideas fit naturally together because both make relationships first-class.

The talk contrasts this with a fixed relational-table structure. In the speaker's description, adding a new kind of information to a table can require a new column and a structural change. A graph can instead accept another item, property, or relationship and attach it to the existing structure.

For example, imagine that an organization first records customers and orders. Later, it wants to represent which representative helped with an order. In a graph-oriented model, it can add a representative entity and a relationship such as assisted_with:

[Customer] ──placed──> [Order] <──assisted_with── [Representative]

The new connection extends the model directly. It does not require treating the relationship as an accidental note outside the domain structure.

This is a contrast about modeling flexibility, not a claim that relational databases can never evolve. Relational schemas can be changed, and graph systems also require design decisions. The speaker's point is that a graph makes it natural to add connected information without reshaping a table every time the organization discovers a new connection.

Formalizing what an organization does

Organizations often use the same words in different ways. They may also depend on connections that are understood by employees but never written down as a formal model. An ontology helps make those assumptions explicit:

1. Identify the entities that matter in the domain.
2. Describe the properties that characterize them.
3. Name the relationships that connect them.

The resulting vocabulary is more than a list of labels. It is a shared account of the domain's structure. That matters for an agent because later reasoning can refer to defined entities and relationships instead of relying only on the meanings suggested by a prompt.

At this stage, however, naming the vocabulary is only the beginning. An organization still needs to decide how to discover and organize that vocabulary. The next part of the talk introduces two directions for doing this: a top-down approach that begins with expert analysis, and a bottom-up approach that begins with observed activity.

The main idea

The chapter's practical model is:

ontology = entities + relationships + properties
graph database = one way to represent and work with those connections

Together, they give an agent a visible domain structure. The agent can then be guided by what the organization says exists, how those things connect, and what information describes them. The graph's extensibility is valuable because a useful ontology must be able to grow as the organization learns more about its work. The following chapters address the methods for building that model and the formal rules that can later check it.