From raw data to usable knowledge, and the metadata in between

Knowledge is of no value unless you put it into practice. — Anton Chekhov

In college, I took a course called IF15: Knowledge Engineering. That's when I heard the word ontology for the first time in my life. It would pop up occasionally in papers and articles I read, but I never took the time to dig deeper–I never felt the need, the necessity.

This term has come back in force over the past few months with the GenAI boom, and especially with the realization that classic RAG is failing and the rise of an alternative–or rather, a helper–GraphRAG. GraphRAG relies on the notion of Knowledge Graphs, which is deeply connected to the concepts of Ontologies.

Originally, this article was just going to be an introduction to ontologies. Then I realized how irrelevant it would be to stay narrowly scoped on that single concept. So I reoriented the article toward knowledge in general–the broader picture.

The thread running through this article: how do we structure what we know so that both machines and humans can understand it?

This subject comes in four parts:

1. From raw data to usable knowledge, and the metadata in between (this post)
2. Six ways to structure knowledge, from a list to a knowledge graph
3. Modelling knowledge for humans and for agents
4. Why classic RAG retrieves text instead of knowledge

---

Knowledge Definition from my IF15 course

The Triptych: Data → Information → Knowledge

Before talking about how to model knowledge, let's define what it is.

We generally distinguish three levels:

• Data: Raw facts, without context. 42, "Paris", 2024-01-15.
• Information: Contextualized data. "The customer ordered 42 units in Paris on January 15, 2024."
• Knowledge: Information usable for action or decision-making. "Paris orders increase in January–we need to anticipate stock levels."

Knowledge is therefore information used in a given context to solve a problem or make a decision (thanks to my UTT course).

Knowledge Engineering

My IF15 course defined knowledge engineering as:

An approach that collects and structures reasoning. Its objective is to formalize problem-solving—the approach followed by one or more experts to solve a problem.

In other words: externalize the knowledge produced "in" and "for" a domain, and make it exploitable.

At the time, I found it very theoretical, almost boring. Today, with agents that need to "understand" our data to generate SQL queries or answer business questions, this discipline makes complete sense.

The Two Faces of Metadata

When we talk about knowledge in enterprises, we're essentially talking about metadata–data about our data. This metadata divides into two fundamental categories:

Metadata Two Faces

Domain Knowledge (Business Knowledge)

This is what the business knows about its domain:

• Business concepts and jargon: What is "churn"? "MRR"? A "qualified lead"?
• Glossaries and definitions: How do we calculate revenue? Gross or net?
• Acronyms and synonyms: WC = World Cup, ARR = Annual Recurring Revenue, CMR = Cameroon

Structural Knowledge (Technical Knowledge)

This is what the data knows about itself:

• Relationships between elements: Which tables can be joined? On which keys?
• Dependencies: If I modify this column, what breaks?
• Lineage: Where does this data come from? What transformations has it undergone?

These two types of knowledge are complementary. Domain knowledge says "the business talks about revenue", structural knowledge says "revenue is in fact_sales.amount". Without the mapping between the two, it's impossible to translate a business question into a technical query.

Garbage In, Garbage Out

We all know this principle in Machine Learning: if your training data is bad, your model will be bad.

This principle applies exactly to GenAI and Agents, but with an important nuance: for GenAI, the "garbage" we're talking about is primarily the metadata.

When you want to do a text-to-SQL project for example, the heart lies in the metadata—the description of the data you have in your possession.

Very often, companies rush directly into the AI layer, GenAI–either to follow the trend or because they think that's where the difficulty lies. But not at all. The difficulty is upstream: in the quality and completeness of metadata (and obviously data, but this is normally already well known...).

Investing heavily in sophisticated models without investing in metadata is building a house on sand.

---

Next: Six ways to structure knowledge, from a list to a knowledge graph