ボトムアップ・モデリングと既存語彙の再利用

In this chapter, we look at bottom-up modeling, an approach different from one in which domain experts design the whole model first. The speaker explains how to observe customer reactions and activities, identify the entities and relationships that appear there, and add them to an ontology or graph. He then recommends reusing taxonomies and ontologies that already exist.

What Is Bottom-Up Modeling?

In a bottom-up approach, you do not decide on a finished model first. You begin by observing actual data, interactions, and customer reactions or activities. From these observations, you organize what appears and what is connected to what. You then add the entities and relationships you find to an ontology or graph that people can share and use.

Here, “adding” does not mean putting a free-form note into a database. For example, you model a reaction as a concept in the domain and represent how that reaction relates to a customer or an activity. This lets people and agents refer to the same meaning later.

The Difference from Top-Down Modeling

• Top-down: Domain experts analyze the whole domain and decide on the necessary entities, properties, and relationships. It moves from above toward a shared model.
• Bottom-up: You find useful entities and relationships from actual observations or activities. It moves from below toward a shared model.

The speaker does not say that one of these two methods is always better. The difference is the direction in which modeling begins and the source of the vocabulary. It is important to distinguish between starting with expert analysis and starting with observed activity.

Turning Customer Observations into a Model

The bottom-up starting point shown in the talk is “customer reactions.” The original explanation does not connect these reactions to a particular industry or product. Therefore, we should not invent a specific customer process here. The central idea is to extract the things and connections involved from observed reactions and activities.

Example (supplement): Suppose a customer reacts to a service. The team considers the customer, the reaction, and the related activity as separate concepts. It then represents necessary relationships in a graph, such as “this customer showed this reaction” and “this reaction relates to this activity.” This is the idea of changing a simple written record into a structure that can support search or reasoning. This is an example created for understanding; it does not mean that the speaker specified a particular customer domain.

Reusing Existing Vocabularies

The speaker next recommends not creating a taxonomy or ontology from zero every time. An established vocabulary can include not only names for concepts, but also ways to represent relationships among them. By examining and using such a vocabulary, you can obtain terms that are easier to share and avoid repeating earlier modeling work.

A Taxonomy, an Ontology, and a Graph Are Not the Same

• Taxonomy: A vocabulary for classifying concepts or arranging them in a hierarchy.
• Ontology: A formal model of a shared conceptualization. It can represent entities, properties, relationships, and necessary rules.
• Graph data: The actual things and connections among things represented using such a model. A graph database is one implementation for storing and working with that data.

This is a supplement to distinguish the terms. The speaker discusses taxonomies, ontologies, and graphs as related ideas, but does not define their formal differences in detail. Therefore, do not assume that a named vocabulary is already a complete application-specific graph. An existing vocabulary can be a starting point for building a domain model of your own.

Existing Vocabularies Named in the Talk

The speaker names the following as examples that can be reused.

• schema.org: Named as an example of an existing vocabulary.
• FOAF: An example of a vocabulary related to social networks.
• Dublin Core: An example of a vocabulary for describing research papers and books.
• DBpedia: An example of an ontology that the speaker explains in connection with graph-based lookup over Wikipedia.

We should treat the final explanation about Wikipedia and DBpedia as an example given by the speaker. The supplied material does not provide information to verify it in detail or add to its technical mechanism. The important idea here is that an already organized vocabulary or graph of knowledge can be used.

The Connection to Agents

Reusing an existing vocabulary provides a shared way to prepare the domain context given to an agent. When an agent produces an output about a customer or an activity, that output can be checked using the same vocabulary and graph concepts. In this way, observations gathered bottom-up and a framework of meaning borrowed from existing vocabularies become the basis for later validation.

However, using an existing vocabulary does not automatically make the model correct. You must check whether it can represent the concepts and relationships your domain needs. This chapter does not determine how particular vocabularies should be combined. The speaker’s proposal is to use existing shared representations while avoiding duplicated work.

Summary

This chapter can be organized as follows.

• Observe customer reactions and activities.
• Find the entities and relationships that appear in them.
• Add them to an ontology or graph as meaningful structure.
• Examine existing vocabularies such as schema.org, FOAF, Dublin Core, and DBpedia to reduce duplicated work from starting at zero.
• Later, use that shared vocabulary and graph as domain context for checking an agent’s output.

This bottom-up method grows a model from observations of reality. A top-down method, by contrast, begins with expert analysis. The speaker does not present them as opposites, but as two ways to begin making the world an agent works with explicit.