この章では、オントロジーをグラフとして見る考え方を説明します。中心になるのは、エンティティ、エンティティどうしの関係、そしてエンティティのプロパティです。その後で、グラフデータベースとリレーショナルテーブルを比べます。最後に、組織が自分たちの仕事をどのように形式化できるかという問いにつなげます。
This chapter explains how to view an ontology as a graph. The main elements are entities, relationships between entities, and the properties of entities. It then compares graph databases with relational tables. Finally, it leads to the question of how an organization can formalize what it does.
オントロジーを構成する三つの要素
The three elements of an ontology
エンティティ（entity）は、モデルの中で区別して扱う対象です。たとえば、ある組織を表すモデルなら、顧客や注文のような対象をエンティティにできます。エンティティは、単なる単語ではありません。モデルの中で「この対象について考える」と決めた単位です。
An entity is a distinct object treated as a unit in a model. For example, in a model of an organization, objects such as customers and orders can be entities. An entity is not just a word. It is a unit that the model has chosen to consider as a particular object.
関係（relationship）は、二つ以上のエンティティがどのようにつながっているかを表します。たとえば「顧客が注文する」という関係では、顧客と注文が別のエンティティであり、「注文する」が両者を結びます。関係には向きがある場合もあります。どの対象が関係の出発点で、どの対象が相手なのかを区別できることが大切です。
A relationship represents how two or more entities are connected. For example, in the relationship “a customer places an order,” the customer and the order are separate entities, and “places an order” connects them. Some relationships have a direction. It is important to distinguish which object is the starting point of the relationship and which object is on the other side.
プロパティ（property）は、エンティティが持つ特徴や値です。顧客なら名前、注文なら注文日がプロパティの例です。つまり、エンティティは対象、関係は対象どうしのつながり、プロパティは対象の特徴です。この三つを分けると、ドメイン（domain）で何が存在し、何がどう結びつくかを整理できます。
A property is a characteristic or value that an entity has. A customer’s name and an order’s date are examples of properties. In short, an entity is an object, a relationship is a connection between objects, and a property is a characteristic of an object. Separating these three helps organize what exists in a domain and how its parts are connected.
例：仕事の世界をグラフで表す
Example: Representing a working world as a graph
**例（説明のための例）**として、顧客が注文を出し、その注文が商品を含む場面を考えます。「顧客」「注文」「商品」はエンティティです。「顧客が注文する」「注文が商品を含む」は関係です。顧客の名前や注文の日時はプロパティです。グラフでは、このような対象を点として、関係を線として表せます。すると、エージェントが扱うべき対象とつながりを、目で確認できる形にできます。
Example (for explanation): Consider a situation in which a customer places an order and that order contains a product. “Customer,” “order,” and “product” are entities. “Customer places an order” and “order contains a product” are relationships. The customer’s name and the order’s date and time are properties. In a graph, these objects can be shown as points and the relationships as lines. This makes the objects and connections an agent should handle visible for inspection.
ここで、オントロジーとグラフデータベースを同じものだと考えないようにします。オントロジーは、対象の種類、関係、プロパティをどう理解するかという概念モデルです。一方、グラフデータベースは、そのような情報を保存したり検索したりするための実装です。両者は同一ではありません。ただし、対象と関係を中心に情報を扱うため、オントロジーはグラフデータベースと自然に組み合わせられます。これは、講演者が示す組み合わせです。
Here, do not treat an ontology and a graph database as the same thing. An ontology is a conceptual model of how to understand the types of objects, their relationships, and their properties. A graph database, in contrast, is an implementation for storing and searching such information. They are not identical. However, an ontology combines naturally with a graph database because both center on handling objects and relationships. This is the combination presented by the speaker.
リレーショナルテーブルとの対比
Contrast with relational tables
講演者は、グラフデータベースをリレーショナルテーブルへの不満と結びつけて説明します。リレーショナルデータベースでは、情報を表と列の構造で表すことが多いです。そこへ新しい種類の情報を加えると、新しい列が必要になり、構造の変更が必要になる場合があります。講演者が示すのは、このような固定された表の構造と、グラフの柔軟な構造との対比です。
The speaker explains graph databases in connection with dissatisfaction with relational tables. In a relational database, information is often represented through a table-and-column structure. When a new kind of information is added, a new column may be needed, and the structure may need to change. The contrast the speaker presents is between this kind of fixed table structure and the flexible structure of a graph.
グラフでは、既存の情報に別の項目を加えたり、エンティティに新しいプロパティを加えたり、エンティティどうしに新しい関係を加えたりできます。情報の追加を、表全体の列構造を先に作り直す作業としてではなく、グラフの一部を広げる作業として扱える、という考え方です。ただし、これはリレーショナルデータベースが決して変更できないという意味ではありません。講演者の例は、ドメインの変化をモデルに取り込みやすいかどうかという、モデリングの柔軟性の話です。
In a graph, another item can be added to existing information, a new property can be added to an entity, or a new relationship can be added between entities. The idea is to treat adding information as extending part of the graph, rather than as first redesigning the column structure of the whole table. This does not mean that relational databases can never be changed. The speaker’s example is about modeling flexibility: how easily changes in a domain can be represented in the model.
組織の仕事を形式化する
Formalizing an organization’s work
この説明から、講演者は「組織は、自分たちがしていることをどのように形式化できるのか」と問いかけます。組織の仕事に登場する対象、対象の特徴、対象どうしのつながりを明示すれば、仕事のドメインを共有できるモデルに近づけます。補足すると、このモデルはエージェントが推論する対象を明確にする土台にもなります。エージェントが何を扱い、どの関係を作れるかを、グラフの語彙で確認しやすくなるためです。
From this explanation, the speaker asks, “How can an organization formalize what it is doing?” Making the objects in the organization’s work, their characteristics, and their connections explicit brings it closer to a shared model of the domain. Supplement: This model can also become a foundation for the objects an agent reasons about. It becomes easier to check what an agent handles and which relationships it can create through the vocabulary of the graph.
グラフの語彙を決めた後の問い
The question after choosing the graph’s vocabulary
エンティティ、関係、プロパティを決めることは、出発点にすぎません。組織は、その語彙をどのように見つけ、どの順番で構造化するかも決める必要があります。講演者はこの後で、専門家の分析から始めるトップダウンの方法と、観察された活動から始めるボトムアップの方法を区別します。グラフは情報を広げやすい形を与えますが、何を表すべきかを考える作業そのものを不要にはしません。
Choosing entities, relationships, and properties is only a starting point. An organization must also decide how to discover this vocabulary and in what order to structure it. The speaker next distinguishes a top-down method that begins with expert analysis from a bottom-up method that begins with observed activity. A graph provides a form that is easy to extend, but it does not remove the work of deciding what should be represented.