OWL properties: transitivity, functionality, and constraints

An ontology can do more than name entities and relationships. It can also describe how a relationship behaves and what combinations of facts are allowed. In this part of the talk, Frank Coyle uses OWL property characteristics to show two capabilities:

1. Derivation: infer a relationship that was not written directly.
2. Constraint checking: detect when graph facts conflict with the domain model.

These rules sit beside the stored graph. The graph contains asserted facts, while an OWL reasoner can derive additional facts or identify a consistency problem from those facts.

Transitivity: following a relationship chain

A relationship is transitive when it can be followed through an intermediate entity. If:

Sue is an ancestor of Mary.
Mary is an ancestor of Ann.

then the system can infer:

Sue is an ancestor of Ann.

The third statement is not a new observation that someone had to enter. It follows from the two asserted statements and the rule that ancestorOf is transitive.

In logical form:

ancestorOf(Sue, Mary)
ancestorOf(Mary, Ann)
--------------------------------
ancestorOf(Sue, Ann)

The intermediate person, Mary, connects the two edges. This is different from merely storing three unrelated text statements. The ontology gives the system permission to apply this particular pattern to this particular relationship.

Why this matters

Transitivity is useful when a graph represents chains. An agent or application can ask about a relationship that was not explicitly recorded and still receive an answer derived from the model. The result is also inspectable: the system can show the two links that produced the third one.

This does not mean that every relationship should be treated as transitive. For example, if worksWith(A, B) and worksWith(B, C) are true, it does not automatically follow that worksWith(A, C) is true. The transitive rule must match the meaning of the property. This contrast is a general modeling lesson: formal behavior belongs to a relationship only when the domain supports that behavior.

Functionality: allowing one value

A functional property allows at most one value for a given subject. In the speaker's examples, a person's father or a person's mother is modeled as a one-value relationship:

hasFather(person, value)

For one person, hasFather cannot have two different father values under this constraint. The same idea can apply to hasMother.

Suppose the graph contains two labels for the father of one person:

Alex hasFather Label-1.
Alex hasFather Label-2.

If hasFather is functional, the one-value rule says that Label-1 and Label-2 must refer to the same individual. The system is not deciding this because the labels look similar. It is using the domain rule: Alex has only one father value, so the two labels are treated as two names for one person.

The transcript renders the identifier in this example inconsistently in places, as “Bob” or “BB.” The important point is the identity inference, not the spelling of that identifier.

Functionality is not the same as transitivity

These characteristics answer different questions:

Property characteristic	Question it answers	Example effect
Transitive	Can two links be composed through an intermediate entity?	Sue's ancestor relationship to Mary plus Mary's relationship to Ann implies Sue's relationship to Ann.
Functional	Can one subject have more than one value for this property?	Two father labels for one person are inferred to identify one individual.

Transitivity creates a new relationship from a chain. Functionality limits the number of values and can force two names to be understood as the same individual. Neither rule is a general-purpose “make the data correct” switch. Each one expresses a specific meaning about one property.

Assertions, inferences, and constraints

It helps to separate three layers of information:

• An asserted fact is directly recorded, such as “Sue is an ancestor of Mary.”
• An inferred fact is produced by applying an ontology rule, such as “Sue is an ancestor of Ann.”
• A constraint or characteristic states how a property behaves or what the graph must satisfy, such as the one-value rule for hasFather.

The inferred fact may not be present as a row or edge in the original data. It can still be available to an application because a reasoner derives it when the graph is queried or checked. Likewise, a constraint may not add a new entity or relationship. Instead, it can reveal that the current set of statements cannot be interpreted as intended, or that two labels must be identified to satisfy the model.

This is the architectural point of the examples. The graph stores the domain information, and a formal layer supplies behavior and restrictions for interpreting that information. The rules need not be repeated as ordinary prose in every record.

From OWL reasoning to agent guardrails

Earlier, the talk described RDFS domain and range as a way to infer types from a statement such as “Bob teaches Scooter.” OWL property characteristics extend the idea in a different direction:

• RDFS domain and range can infer what kinds of entities appear on each side of a relationship.
• OWL transitivity can infer a further relationship from a chain.
• OWL functionality can enforce a one-value condition and support identity reasoning.

Together, these capabilities give a validator more than a check for well-formed text. When an agent proposes an action or returns a tool result, the surrounding program can place the result into the graph and ask whether it fits the domain model. A derived relationship may expose an implication that was not obvious in the response. A functional property may expose conflicting values. A suitable constraint can therefore help the system reject or reconsider an unreasonable proposal before it changes the outside world.

The speaker's claim is not that OWL stops an LLM from generating a bad answer. The LLM remains probabilistic. The proposed division of labor is different: the model supplies flexible proposals, while the graph and its formal rules provide a basis for checking those proposals. That is how these property characteristics become guardrails for an agent rather than only abstract features of a knowledge representation language.