OWLのプロパティ：推移性、機能性、制約

Ontologies represent entities, relationships, and properties in a graph. Here, we add rules about how a relationship behaves and which values are allowed. The speaker introduces RDFS and OWL (Web Ontology Language) as supporting technologies that work beside the graph to perform inference and apply constraints.

It is important in this chapter to separate written facts from facts derived by rules. The graph contains not only relationships stored from the beginning; the characteristics of OWL properties can also derive new relationships. Constraints about the number of values or about allowed combinations can reveal contradictory data or proposals.

Transitivity: connecting a chain of relationships

A relationship is transitive when, if the same relationship occurs in two consecutive steps, that relationship also holds between the two endpoints. An ancestor relationship is an example. In a family relationship, if A is an ancestor of B and B is an ancestor of C, then A is also an ancestor of C.

The speaker explains this with a chain of three people.

• Sue is an ancestor of Mary.
• Mary is an ancestor of Ann.
• If the ancestor relationship is transitive, we can derive that Sue is an ancestor of Ann.

The third relationship was not originally written as a separate fact. It is an inferred fact produced from the first two facts and the OWL characteristic that ancestor is transitive. This kind of derivation increases the usable information in the graph without requiring a person to register every indirect relationship one by one.

However, transitivity does not apply to every relationship. For example, being acquainted or making a phone call does not necessarily hold between the endpoints just because two such links form a chain. Therefore, which properties are made transitive must be decided from the meaning of the domain. The ancestor example is the transitive relationship shown by the speaker.

Functionality: allowing one value for one subject

A functional property allows only one value for a given subject. The important point is that this does not mean there can be only one value in the whole graph. It means there can be one value for one subject. An ordinary property can have multiple values, but multiple values for a functional property create a consistency problem.

The speaker uses a person's father or mother as an example. Suppose two different labels are attached to the father relationship for a person named Jim. If father is functional, the system does not simply accept that Jim has two fathers. It can infer that the two labels are different names for the same individual.

This is not a decision that the two strings are identical because they look similar. The conclusion that the two labels refer to the same individual follows from the domain constraint that this relationship has only one value. In the speaker's transcript, the identifier in this example sounds different in different places, like Bob or BB. The important point is the identity inference from the one-father constraint, not the exact spelling.

RDFS type inference and OWL property characteristics

The RDFS domain and range from the earlier example derive the types of the things on the two sides of a relationship. For example, if the domain of teaches is Teacher and its range is Student, then “Bob teaches Scooter” allows us to infer that Bob is a teacher and Scooter is a student. The OWL property characteristics discussed here instead describe how the relationship itself behaves. Transitivity derives a new relationship from a chain, while functionality limits the number of values that one subject may have.

In short, an RDFS domain and range rule adds information about “what kind of thing this is.” OWL transitivity and functionality deal with “how this relationship connects” and “how many values this relationship allows.” Both can work with information that is not explicitly written in the graph and can support later validation.

These rules are not always recorded one by one in the same form as the stored graph facts. A reasoner or validator using the rules works beside the graph, performs the needed derivations, and checks for violations of constraints. This creates a division of labor: the graph holds facts, while a separate rule layer performs meaning-based calculations and checks.

A rule layer that supports agents

This division also helps agents. A probabilistic LLM can flexibly propose the next words, or a tool and its parameters that it wants to call. But its proposal does not necessarily fit the facts or constraints of the domain. If ontology-based inference and constraint checking are placed near the proposal, the system can use relationships derived by transitivity and rules that allow only one value to detect problems in the proposal.

Example (supplement): finding a contradiction before execution

For example, suppose an agent proposes an operation that registers one person's father as two separate individuals. The LLM may return an explanation that sounds natural, but it does not fit the functional-property constraint. The system can infer that the two labels may refer to the same individual, or it can stop the proposal from passing unchanged and send it for another check. This does not mean that OWL replaces LLM generation. It means that a domain-based check is added after a flexible proposal.

Points that are easy to misread

• Transitivity does not automatically connect every relationship. It applies only to relationships defined as transitive.
• Functionality does not compare value strings and choose the most plausible one. It derives consequences about consistency or identity from the constraint that one subject has one value.
• An inferred fact is different from a fact explicitly stated in the original graph. We need to check which facts were asserted and which were derived by rules.

The speaker's examples show how OWL keeps a graph from being merely a collection of links. Transitivity derives indirect relationships, and constraints such as functionality reveal inconsistencies. Placing these rules beside the graph creates a basis for checking an agent's proposals against the meaning of the domain.