In this chapter, we look at the OWL examples shown near the end of the talk. A large language model (LLM) probabilistically creates plausible text or tool arguments. However, natural-sounding text is not necessarily consistent with the domain's meaning. OWL axioms and constraints provide a basis for checking whether an agent's result conflicts with domain rules.
The slide in the talk presents at least three different ways to check a result. The first limits the number of values allowed for one subject. The second keeps kinds that must not be treated as the same separate. The third limits values to a defined set. They may look similar, but they detect different kinds of errors.
A functional property can be explained as a constraint that allows only one value for a subject. In the talk's example, issuing a second refund for the same order violates this constraint. The second refund is not merely another English sentence being added. It breaks the semantic rule that the order has only one recorded refund.
This slide contrasts rules written in English with OWL axioms and shows a second refund for the same order as an error. With a functional constraint, the duplicate can be detected before the agent's refund result is accepted.
In the next example, Customer and SupportRep are treated as different kinds of entities. If the two kinds are disjoint, a proposal to send a payment to a support desk instead of the customer is a problem. The text may still read, "the payment was sent," but the recipient's role is wrong. Here OWL checks the recipient's kind and the payment relationship, rather than only the surface of the sentence.
This slide uses disjoint Customer and SupportRep classes to show the error of sending a payment to a support desk. It is an example of checking not only whether a payment destination exists, but also whether its role is appropriate for receiving this payment.
The third method limits the values of a property to a defined set. The talk gives an example in which an order's status may be only paid, shipped, or refunded. If an LLM returns a made-up status name, it may be readable as text, but it is not part of the vocabulary being managed. This constraint checks whether the status belongs to the allowed set.
This slide shows an OWL axiom that limits an order's status to the fixed values paid, shipped, and refunded. Even if probabilistic output invents an unknown status name, it can be treated as a value that is not allowed.
Natural language can express the same meaning in many ways. That flexibility is an LLM's strength, but it does not automatically reject a second refund, a recipient with the wrong role, or an unauthorized status name. The speaker's claim is that it is difficult to enforce these relationships and constraints strictly in English. He does not mean that English cannot express them.
A reasoner using an ontology compares an agent's proposal with domain constraints instead of executing it unconditionally. If the result has no contradiction, the system accepts it. If there is a problem, the surrounding program can return the result to the LLM for another attempt or ask a human to check it. OWL therefore does not replace LLM generation. It places semantic guardrails around an LLM that makes flexible proposals.
A one-value constraint finds a duplicate refund, disjoint kinds find a mix-up in the payment recipient's role, and an allowed-value constraint finds an unknown order status. In this way, formal OWL constraints give a validation loop information for cases where probabilistic text is grammatically correct but wrong in the domain. The talk proposes not a guarantee that the agent will never make a mistake, but a way to check semantic consistency before taking action.