How much semantic modeling do your AI agents need?

You are arranging a meeting. Six people will attend in the office, and two will join online. You give a personal assistant the invitation and ask:

Book a meeting room in our office tomorrow, from 2 to 3 p.m. Six of us will be there, and two others will join the Microsoft Teams call.

Does that assistant need an ontology? For this request, I would start with the existing booking service and its SQL database. A property graph could help with equipment relationships and dependency questions. A formal ontology becomes worth considering if separate systems need to exchange definitions and apply agreed logical statements independently.

Here, semantic modeling means defining what the records mean and how they relate. An ontology describes domain concepts, relationships and logical definitions; OWL is a language for expressing a formal ontology. Choosing where to store the records is a separate decision. A property graph and an ontology can be used together. We’ll use the same example to decide what this assistant needs.

This is Part 3 of Beyond Similarity. Part 1 introduced clear business definitions. Part 2 tested whether an agent applied a selection rule correctly. Here, we ask how much modeling machinery the task actually needs. The meeting rooms and records are illustrative.

Start with the booking decision

The six people attending in person need seats. The two joining online need to see and hear them, and the people in the meeting room need to see and hear the call.

For this example, a suitable meeting room must have:

• At least six seats in the requested office.
• A working camera, microphone, speakers and TV or monitor.
• A verified way to use that equipment for the Microsoft Teams call.
• No confirmed reservation overlapping any part of 2–3 p.m.

A join method is how the meeting room’s equipment connects to the call: perhaps a dedicated console, or an approved laptop connected to the camera, sound equipment and display. Verification applies to that configuration and the call service named in the invitation. If the configuration changes, it needs checking again.

We assume the invitation has usable join details and the organization permits access. We require basic audio and video here; sharing slides would add a check for the chosen join method.

The office has four candidate meeting rooms, A–D. Their listed call setups have working cameras, microphones, speakers and displays. Their capacities, Teams verification and calendars differ:

Meeting room A has four seats, so it is too small. B has eight seats and a verified Teams setup, but another reservation starts at 2:30 p.m. It cannot cover the whole hour. C has six seats, a verified Teams setup and no overlap. D has eight seats and is free, but its Teams join method is unverified.

The answer is C. Missing verification for D is an unresolved check, while a known microphone failure would be a failed check.

Similarity search could find descriptions such as “video meeting room”. Those descriptions do not establish current equipment condition, service verification or availability for the whole hour. The booking service needs records for those checks.

SQL can handle the booking

Suppose rooms records the office and capacity, room_call_support records configured join methods, and reservations records confirmed bookings. The application resolves the date and time zone, validates the interval and binds the parameters.

Here, equipment_status = 'working' means all the required equipment used by that particular join method has passed the current checks. It does not mean some equipment somewhere in the meeting room is working.

SELECT r.room_id, r.capacity, s.join_method
FROM rooms r
JOIN room_call_support s ON s.room_id = r.room_id
WHERE r.office_id = :office_id
  AND r.capacity >= :in_person_count
  AND s.equipment_status = 'working'
  AND s.call_service = :call_service
  AND s.join_status = 'verified'
  AND NOT EXISTS (
      SELECT 1
      FROM reservations b
      WHERE b.room_id = r.room_id
        AND b.status = 'confirmed'
        AND b.start_time < :requested_end
        AND b.end_time > :requested_start
  );

With six people attending in person and teams as the call service, the query returns C and its join method. Our policy allows one meeting to end exactly when another starts; canceled reservations do not block a meeting room. The service can evaluate individual checks separately to explain exclusions and unresolved evidence.

Changing the invitation to Google Meet does not create a need for an ontology. Suppose C’s Google Meet method is unverified, while D has a verified, working laptop-connected Google Meet setup. The same query, with google_meet as the service, returns D. Microsoft’s Teams Rooms documentation illustrates why joining another call service depends on configuration and join method.

Expose a find operation and a reserve operation through the booking API. The assistant supplies the request and explains the returned evidence. It confirms the booking only after the service secures the slot. Several assistants can use that same API and the same selection rules. Adding another assistant does not itself require another data model.

When a property graph would help

Facilities staff also want to ask:

If Conference unit 7 fails, which meeting rooms and call setups are affected?

That question follows dependencies. Meeting room C contains Conference unit 7 and Display 2. Its Teams console uses both. Conference unit 7 has an approved equipment profile that lists its designed camera, microphone and speaker functions.

A property graph records things as nodes, connections as relationships, and attributes as properties. For example, a meeting room node can have a capacity, and a join-method node can have a verification status. Neo4j’s graph model describes these elements and how queries follow relationships.

Some of our graph’s facts would be:

Meeting room C → contains → Conference unit 7
Conference unit 7 → has approved profile → Profile P
Profile P → provides → Camera
Meeting room C → has join method → Teams via console
Teams via console → uses → Conference unit 7, Display 2
Teams via console → joins → Microsoft Teams

Here, Camera names a function, not a particular device. The approved-profile relationship records a reviewed mapping to the unit’s designed functions.

Following the uses connection identifies C’s Teams setup as dependent on Conference unit 7. A failure would make that setup fail the equipment check until it is repaired or a working alternative is verified. The graph can also derive a designed capability from the profile path. In Cypher, a property graph query language, that derivation could be written as:

MATCH (r:MeetingRoom {id: $meeting_room_id})
      -[:CONTAINS]->(:Equipment)
      -[:HAS_APPROVED_PROFILE]->(:EquipmentProfile)
      -[:PROVIDES]->(c:Capability)
RETURN DISTINCT c.name AS designedCapability;

For C, the shown path returns Camera without a direct camera-capability connection stored on C. Other functions can be found through their own provides connections.

So a property graph can support derived answers. Queries, application logic or an added rule engine can implement the derivation. Graph databases can also enforce constraints; Neo4j, for example, supports uniqueness constraints.

SQL joins can follow these relationships too. I would consider a property graph if dependency traversal became a substantial part of the workload and its modeling and query tools helped the team. For one team owning these definitions and operations, a property graph plus an API can be enough. No OWL layer is required for this example.

When different systems need to agree

Suppose the facilities team keeps the equipment records, the booking service keeps the calendar, and another company provides the assistant. Each has its own system.

The facilities system marks C as “video enabled” because it has a camera. The booking service uses the same words to mean that a Teams call has been tested successfully. The assistant could mistake one for the other and book a setup that hasn’t been checked.

The teams first need to agree on what their records mean. A camera being installed, a camera working today and a Teams setup being verified are separate facts. They also need to check that their records for C refer to the same physical meeting room.

A shared booking API and clear documentation may cover all of this. Having several systems does not, by itself, call for new technology.

If the teams want to share the facts for use in their own software, RDF is one option. It is a standard way to write facts as small statements, such as:

Meeting room C → contains → Conference unit 7.

The teams can use agreed identifiers for the meeting room, the device and the relationship between them. Software that reads RDF can then read the shared statements. The RDF specification describes this way of representing connected facts.

Someone still has to check the links to the source records and agree on the definitions. RDF gives the teams a common way to share facts; it doesn’t decide what “video enabled” should mean. They can use RDF without adding OWL.

What OWL adds

So far, we have shared facts about C and its equipment. The teams might also want to share a definition that lets software work out a further fact.

Take Conference unit 7. Its approved equipment profile lists a camera function. The teams could agree on this statement:

If a meeting room contains equipment whose approved profile lists a function, the meeting room has that designed function.

Following that statement tells us that C’s setup includes a camera function. We can work this out from the equipment records, even without a separate “has camera” flag on C.

OWL lets the teams write that definition in a standard form. Software called a reasoner can use it to work out the camera function from the connected facts. The OWL primer explains this kind of reasoning.

Each team can load the same definition into OWL software that supports it. With the same facts and model version, they can reach the same conclusion without each team coding the rule separately. They still need correct source records and a way to refresh old facts.

SQL joins and the property graph query can reach the same answer. For this one definition, a shared query may be simpler. I would consider OWL if the teams had many definitions like this and wanted to reuse them in software that applies the same logic. That can be useful within one system too.

There is still a separate question: does the camera work today? The equipment profile tells us what the device is designed to do. The booking service needs current checks to know whether the camera works and the selected Teams setup can use it.

Check the records, then check the booking

Suppose the shared graph shows no reservations for C tomorrow. Perhaps C is free. Or perhaps nobody has supplied its bookings yet. The assistant cannot tell from that missing information alone.

In OWL, a missing fact is not automatically treated as false. This is called the open-world assumption, described in the OWL primer. The assistant still needs to ask the booking service whether C is available for the requested hour.

The booking service must also prevent two people from reserving the same slot. That is a separate responsibility from interpreting the shared graph.

The teams may also want to catch incomplete records before the assistant uses them. For example, every record about joining a call could be required to name the call service and say whether the setup has been verified.

SHACL lets them share checks for RDF records. A check like “every join-method record must include a verification status” can flag a record where that field is missing. SHACL supports checks for required values.

These checks can also live in a database or application. I would use SHACL when the teams need to share the checks and run them in their own RDF tools. It can work without an OWL reasoner.

A record can pass those checks and still be out of date. A verification status recorded last month does not prove that the camera works today. The assistant needs both complete records and current evidence.

What I would use

Need	Tool to consider
Find an available meeting room and book it	SQL + booking API
See which meeting rooms depend on a broken camera	Property graph; SQL can also do this
Share facts such as “C contains Conference unit 7” between systems	RDF
Use a shared definition to work out what C’s setup is designed to provide	OWL
Flag a join-method record in RDF that is missing its verification status	SHACL

For the booking request we started with, I would keep SQL and the booking API. If equipment dependencies became a large part of the assistant’s work, I would look at a property graph. I would consider RDF or OWL when the teams could name the facts or definitions they needed to share, and explain why their existing approach wasn’t enough.

These tools can work together. The booking service can keep the calendar while a graph holds equipment connections. The practical question is what each added tool helps us do, and whether that help is worth the work of maintaining it.

I’ve used a meeting room booking example to explain these concepts and when to use each approach. You can apply the same principles to your own business domain.

---

The meeting rooms, equipment records and policies in this post are illustrative and written for learning purposes. The views are my own. Find me on LinkedIn.