Two Lineages: Agents and Ontologies

This chapter traces the histories of agents and ontologies. The main point of the talk is not to memorize the history of these two terms. It is to understand what each one means and why they can be combined in the same system.

History provides the background. When we design a system, we use what an agent does and the model represented by an ontology. So we will first separate the two lineages, then confirm the design connection they share.

1. The Lineage of Agents

The talk traces the idea of an agent back to early thinkers in artificial intelligence (AI). The idea then developed into systems that perceive their surroundings, decide what to do next, and actually act. An agent here is not just a mechanism that returns text. It has a flow of perception, decision, and action.

Example (supplement): An Agent Checking Delivery Status

The following is an author-created example to make this definition concrete.

• Perception: It receives the user's request, “Where is my package?”, and information from a delivery tool.
• Decision: It decides which package to check and whether more confirmation is needed.
• Action: It calls the delivery tool and tells the user the resulting status.

The important point in this example is that the agent does not stop after reading the input. It connects its decision to a next action.

2. The Lineage of Ontologies

The other lineage begins with the philosophical question, “What is being?” The talk starts with Aristotle's ideas about kinds and categories of being, then moves toward later formalization. This history does not mean that Aristotle's categories became a software blueprint unchanged. It means that interest in a similar problem—dividing what exists in the world into kinds and organizing relationships—leads toward later knowledge representation.

As an important bridge to practice, the talk uses Gruber's 1993 formulation. An ontology is a formal specification of a shared conceptualization. In other words, it is a model that describes the things in a domain, the relationships among them, and the properties that matter, in a clear form. “Shared” does not mean a word list held only by one person. It means that people and systems can refer to the same model of the same domain.

Example (supplement): A Library Conceptualization

Consider this author-created example for a library.

• Entities: Things handled in the domain, such as books, members, and loan records.
• Relationships: Connections such as a member borrowing a book.
• Properties: Attributes that things have, such as a book's title or a date on a loan record.

If this model is shared, people and systems can understand in the same way that “borrow” is a relationship connecting a member and a book. This example explains the talk's definition; the talk is not proposing a library design.

3. The Bridge to Graph Databases and Knowledge Representation

When an ontology describes entities, relationships, and properties, it can be represented naturally as a graph. A graph database is a mechanism for storing and traversing such items and connections. Knowledge representation is the idea of expressing knowledge in a structure that machines can work with. The talk connects ontologies naturally to graph databases and knowledge representation.

An ontology and a graph database are not the same thing, however. An ontology is a conceptual model of how to understand a domain and what to connect. A graph database is one implementation for storing and using that model or its data. Keeping this distinction prevents us from confusing “what something means” with “where it is stored.”

For the same reason, philosophical categories and software entities are not identical. The philosophical discussion is a historical starting point. In software, we define the entities, relationships, and properties needed for the domain and its purpose. We do not need to convert historical categories directly into database tables or graph nodes.

4. Giving an Agent a Shared Model

The two lineages meet when we give an agent a conceptualization of a domain. If an agent only generates language probabilistically or plans its next action, it cannot necessarily handle the important things and relationships in that domain consistently. If we give it an ontology as a shared model, it can refer to the types, relationships, and properties of the domain in a structured way. That structure becomes a foundation for inference and for checking an agent's output, which later chapters discuss.

The talk's record contains fragmented renderings of some historical names related to early AI. For example, one name appears as “Von Quine,” but its exact spelling cannot be established from this material alone. This chapter therefore preserves the talk's historical sequence—“from early AI thought to agents”—without asserting a specific person's name.

Key Points

• An agent has a flow of perception, decision, and action. It is distinct from something that only generates text.
• An ontology is a formal specification of a shared conceptualization for a domain. It organizes entities, relationships, and properties rather than merely listing words.
• The history from Aristotle to modern knowledge representation is background. Philosophical categories must not be treated as identical to a software schema.
• Connecting an ontology with a graph or knowledge representation makes the model of the domain handled by an agent explicit.
• That shared model becomes a bridge for reasoning about an agent's proposal and checking it against domain rules later.