your knowledge, accessible

Day 2 of 6

Making Meaning Machine-Readable

Triples, TBox & ABox

Knowledge Graphs for AECO — a course for domain experts

Where we are going today

  1. Explain what "machine-readable" actually means, as opposed to a human-readable PDF or a BIM model file.
  2. Break a plain-language statement into a Subject–Predicate–Object triple.
  3. Tell TBox (what types of things may exist) apart from ABox (what actually exists).
  4. Explain why one fact can have several contradictory versions — and why that's a feature, not a bug.

Yesterday

Every manual connection you counted in "Graph your Monday" is an edge that exists — but only in your head.

Today: what does it take to write one of those edges down so precisely that a computer can act on it?

Human-readable is not machine-readable

A PDF, a scanned drawing, a specification chapter

…all require a person to read them and interpret them before any conclusion can be drawn.

A BIM model is closer — but the meaning is still locked inside a proprietary file

You need the right software, the right version, and someone who knows where to click.

Machine-readable means the fact is stated explicitly enough that a computer — or an AI — can act on it without a human translator in the loop

The smallest unit of meaning

One node-edge-node relationship is called a "triple" and describes a "statement" or a "fact"

A triple consists of a Subject, a predicate and an Object

It reads like the simplest possible sentence

Subject
Room 201
→
Predicate
is inside
→
Object
2nd Floor

A thing · a relationship · another thing.

An example from a BIM model

As more facts are added, the object in one triple becomes the subject in another

Objects can also represent simple data properties

Nobody writes triples one at a time

They accumulate. A wall's door, the door's material, the material's supplier — each fact clicks onto the last, and a network builds itself.

Two kinds of statement

We distinguish between the assertion layer (ABox) and the terminology layer (TBox)

TBox
Like the building code

"A bot:Space can be inside a bot:Storey."

Defines what is possible — not what exists yet.

ABox
Like the as-built drawing

"Room 201 is inside the 2nd Floor."

States what is actually true, for a specific building, right now.

Why separate them?

  • The building changes constantly — the ABox churns
  • What kinds of things exist changes slowly — the TBox is stable
  • Keeping them apart is what lets the graph stay useful as reality moves underneath it

Multiple realities

The web follows the AAA principle

Anyone can say Anything about Anything

It is up to you as a reflective individual to form your own opinion

This can be good or bad, but most importantly it lets us deal with the fact that reality is complex

Construction projects are also complex and there will exist more realities simultaniously

Drawing conclusions requires gathering information from multiple sources and always includes a multitude of assumptions

"Would the carbon footprint be reduced if we switch to a wooden structure?"

- It depends on how you calculate it!

Furthermore, the reality rapidly changes during the design stages making it hard to gather the current state of truth

"Is the door red or orange?"

- It depends on when you ask!

Over the years we gather so much information that multiple realities will inevitably exist

"Was this wall removed?"

- It depends on which document you look at!

Whose version is true?

Asset Owner

"Was this wall load-bearing?" — depends on which revision of the structural drawing you trust, and when.

Planner

"Is the setback 3 metres or 4?" — depends on whether you read the original permit or the as-built survey.

Facility Manager

"Was this filter replaced last quarter?" — depends on whether you trust the CMMS log or the technician's paper checklist.

Let's take a look at how we deal with inconsistencies

Let's see how an LLM would interpret it

Let's imagine that we had access to some provenence data about each statement

Full prompt for you to try

Context is important!

Trust needs context, not censorship

Notice what we did not do: pick a winner and delete the loser.

  • Keep all competing statements
  • Attach who said it, when, from what source, how confidently
  • Let the person — or the AI — weigh the evidence

The richer the input, the richer the output

True of human judgement and of AI alike.

Advanced — optional

How the door demo actually works under the hood

With RDF* (RDF star) it is posible to make a statement about another statement

Let's imagine we would like to describe some provenance about this fact

In RDF* it would look like this

In Turtle* syntax it would look like this

Exercise: "Triple it"

Pen and paper.

In small groups, 20 minutes.

  1. Take the handout — a short paragraph from a real specification or room data sheet.
  2. Rewrite three to five sentences as Subject–Predicate–Object triples, one per index card.
  3. Lay the cards out and connect them with string wherever an object in one card is the subject of another.

Now sort your cards into two piles

TBox

"This describes a type of thing."

ABox

"This describes a specific thing."

Which pile was bigger? Which was harder to agree on?

Key takeaway

"A fact isn't just data — it's a claim, made by someone, at some point in time, with some level of confidence. Machine-readable means explicit enough that a computer can tell the difference."

Tomorrow

We have facts. Now: why is asking questions of a graph fundamentally different from asking them of a database — and why does that mean nobody in this room needs to learn a query language?

Day 3 — Graphs vs. relational databases