Bottom-up modeling and reusing existing vocabularies

An ontology does not have to be designed entirely in advance. The speaker presents a second route: bottom-up modeling. Instead of beginning with a complete expert description of the domain, begin with what is happening in the domain and let useful concepts emerge from those observations.

Start with observed activity

In the speaker's example, an organization observes customer reactions and activities. It then asks:

1. What entities are involved?
2. What relationships connect them?
3. Which properties describe those entities or relationships?

The answers are added to the ontology or graph. The process therefore moves from concrete observations toward a shared model.

For example, suppose an observation concerns a customer reacting to something. A modeler might identify the customer as an entity, identify the reaction or activity as a concept worth representing, and record the relationship between them. The exact vocabulary depends on what the organization is trying to understand. The important step is not to save the observation only as an unstructured note. It is to decide whether the observation reveals a reusable domain concept or relationship.

This gives an agent a more explicit description of the world it operates in. Later, the system can use that description when it evaluates information or plans an action.

Bottom-up versus top-down

The previous chapter described top-down modeling. In that approach, domain experts analyze the domain first. They choose entities, define their properties, and specify their relationships. Bottom-up modeling reverses the direction:

Approach	Where modeling begins	How concepts enter the model
Top-down	Expert analysis of the domain	Experts define the shared vocabulary
Bottom-up	Observed data, interactions, or reactions	Useful entities and relationships emerge from activity

This is a contrast in starting point, not a claim that one method is always better. A top-down model can make important domain assumptions explicit. A bottom-up model can reveal concepts that become visible only when people or systems interact with the domain. In practice, the two directions can also inform each other, although the speaker's point here is to show that ontology construction need not start with a fully specified theory.

Reuse vocabulary that already exists

The speaker's next recommendation is not to reinvent every vocabulary. Existing taxonomies and ontologies may already provide terms and relationships that an organization needs. He names:

• schema.org
• FOAF, associated in the talk with social networks
• Dublin Core, associated in the talk with describing research papers and books
• DBpedia, which he associates with Wikipedia's graph-based lookup

Reusing an existing vocabulary can give different parts of a system a common set of terms. It can also avoid repeating modeling work that has already been done. If a suitable concept already exists, an organization can use that concept as part of its own domain graph instead of creating a second term with the same intended meaning.

Three related ideas

These terms are related, but they are not interchangeable:

• A taxonomy organizes concepts into categories, often by showing broader and narrower kinds.
• An ontology gives a more formal shared conceptualization. It can describe entities, properties, relationships, and rules about them.
• A graph is a representation of connected data. An application-specific graph can use an ontology's vocabulary, while the graph stores the particular entities and relationships observed by that application.

The talk moves among these ideas when it recommends existing resources. It does not fully formalize the boundaries between them. The practical lesson is to separate the reusable vocabulary—the meanings and relationships—from the local facts that an organization adds to its own graph.

Why reuse matters for agents

An agent produces probabilistic proposals, such as text or tool parameters. To check those proposals, the surrounding system needs a structured account of the domain. A reused vocabulary can supply part of that account.

The resulting architecture has a simple division of labor:

1. Observed activity helps the organization discover what its model needs to represent.
2. Existing vocabularies provide shared terms and relationships where they fit.
3. The organization adds application-specific entities and connections to its graph.
4. Later, formal rules and validators can use this domain context to check an agent's results.

This does not mean that an existing vocabulary automatically solves validation. The vocabulary still has to fit the organization's use case, and the graph still has to contain the relevant facts and relationships. But starting with established terms can make the formal context more consistent and can leave more effort for the parts of the domain that are genuinely specific to the application.

The chapter's main idea is therefore practical: build the ontology from real activity when that is useful, and reuse prior vocabularies instead of starting from zero. Both choices help create the structured domain context that the later agent-and-validator loop will need.