Beyond Explainable AI: From Symbol Processing to Semantic Cartographies in a World of Babel

Created with ChatGPT

This article was initially published on LinkedIn

Many criticisms directed at LLMs are actually criticisms of a much broader phenomenon: the gap between formal symbol processing and human meaning attribution.

What often changes between AI paradigms is not the existence of the problem, but merely where the uncertainty hides.

The common trap: confusing computation with understanding

Whether we talk about:

• LLMs processing tokens,
• Knowledge graphs processing IRIs,
• OWL reasoners processing logical axioms,
• Rule engines processing predicates,
• Bayesian networks processing probabilities,

the machine never manipulates “meaning” in the human sense.

An OWL reasoner does not know that:

http://example.org/aircraft/wing

refers to an actual aircraft wing.

For the reasoner, this is merely a syntactic identifier.

Likewise, a Prolog system does not know that:

aircraft(a320).

refers to a real aircraft.

It only manipulates symbols according to formal rules.

This observation is very close to the classic distinction between:

• syntax
• semantics
• pragmatics

The machine operates on syntax. Humans project semantics and pragmatics onto the syntax.

Why deterministic AI appears more trustworthy

A description logic reasoner is often considered:

• deterministic
• explainable
• verifiable
• auditable

because given the same ontology and the same axioms:

A ⊑ B
B ⊑ C

the same conclusion:

A ⊑ C

will always be produced.

Unlike an LLM, no stochastic sampling is involved.

This gives an impression of certainty.

But several traps remain.

Trap 1: Determinism does not imply truth

A deterministic system can be consistently wrong.

Suppose we define:

Whale ⊑ Fish

The reasoner will infer perfectly and deterministically all consequences.

The problem is not the reasoning.

The problem is the conceptualization.

This is an old issue in ontology engineering:

correctness of inference does not imply correctness of ontology.

Many people unconsciously move from:

the inference is valid

to:

therefore the conclusion is true

which is a logical fallacy.

Trap 2: Hidden assumptions become invisible

An explainable reasoner can explain:

Conclusion C follows from axioms A, B, and D.

But it cannot explain why those axioms should be accepted.

For example:

Supplier ≡ Organization and providesSomeProduct

may look innocent.

Years later people forget:

• who created the axiom,
• under which business assumptions,
• for which project,
• at which date.

The system becomes explainable internally but opaque externally.

The explanation only covers deduction.

It does not cover the origin of premises.

Trap 3: Symbol grounding remains unresolved

This is probably the point closest to your concern.

Suppose an ontology contains:

AircraftEngine

The reasoner manipulates it perfectly.

But what guarantees that:

• engineer A,
• engineer B,
• manufacturer C,
• regulator D

all associate the same concept with that symbol?

Nothing.

This is the famous symbol grounding problem.

The machine does not know whether the symbol corresponds to:

• a physical object,
• a design specification,
• a product family,
• a maintenance unit,
• a legal category.

The machine only knows relationships among symbols.

As you’ve often noted in discussions about interoperability, the hardest problem is usually not logical consistency but semantic alignment.

Trap 4: Formal consistency can hide conceptual inconsistency

An ontology may be formally consistent while being conceptually absurd.

For example:

Human ⊑ Vehicle
Vehicle ⊑ Asset

If no contradiction is introduced, the ontology remains consistent.

The reasoner reports:

ontology consistent.

People may incorrectly infer:

ontology makes sense.

Formal consistency is much weaker than semantic validity.

Trap 5: Closed-world expectations versus open-world logic

Humans often expect:

if it is not known, it is false.

Many logical AI systems, especially based on description logics, assume:

if it is not known, it is unknown.

This produces surprising behavior.

For example, the absence of information that a component has a safety certificate does not imply that it lacks one.

The reasoner is behaving correctly according to its semantics, but incorrectly according to user expectations.

Many industrial misunderstandings originate from this gap.

Trap 6: Explanations can create an illusion of understanding

This is perhaps the most dangerous trap.

Consider:

A
A → B
B → C

The reasoner explains:

C because B
B because A

This chain is perfectly transparent.

However, the transparency concerns only:

• deduction

not:

• ontology construction,
• category selection,
• abstraction choices,
• viewpoint selection.

The explanation may therefore create excessive trust.

The user sees a proof and assumes the whole system is justified.

Trap 7: The frame problem reappears

Logical systems only reason over what has been formalized.

If an ontology contains:

• engines,
• wings,
• fuel systems,

but not:

• political constraints,
• economic pressures,
• organizational factors,

then those factors simply disappear from the reasoning space.

The reasoner is deterministic precisely because the world has been drastically simplified.

The danger is forgetting the difference between:

• the model
• the modeled reality

A problem that also exists in engineering architectures and enterprise models.

Trap 8: Interoperability is mistaken for shared meaning

This is particularly relevant to your work.

Two organizations may share:

• the same ontology,
• the same IRI,
• the same RDF triples,

yet still mean different things.

For example:

Part

may denote:

• a CAD component,
• a purchasable item,
• a maintenance replaceable unit,
• a regulatory object.

The identifiers are identical.

The conceptualizations differ.

A reasoner cannot detect this unless the distinctions have already been explicitly formalized.

Thus syntactic interoperability and logical interoperability can exist without semantic interoperability.

Trap 9: Deterministic systems are often only locally deterministic

A reasoner is deterministic given:

• ontology O
• rules R
• inputs I

But who produced:

• O ?
• R ?
• I ?

Humans.

Therefore uncertainty is merely displaced upstream.

LLMs expose uncertainty at inference time.

Knowledge-based systems often hide uncertainty at modeling time.

The uncertainty has not disappeared; it has moved.

A deeper philosophical point

The criticism often directed at LLMs is:

“They only manipulate symbols.”

But from a strict computational perspective, the same is true of almost every AI system ever built.

The difference is that:

• LLMs manipulate statistical relationships among symbols.
• Logic-based systems manipulate formal relationships among symbols.

Neither automatically possesses access to the referents of those symbols in the actual world.

The real challenge is not stochasticity versus determinism.

It is the chain:

Reality → Observation → Conceptualization → Symbolization → Computation → Interpretation

Every step introduces possible distortions.

LLMs make the uncertainty visible because they can hallucinate.

Deterministic and explainable AI often appears safer because the uncertainty is hidden in the conceptualization, ontology, assumptions, mappings, and symbol grounding decisions made before the reasoning even starts.

From an interoperability and ontology perspective, one could even argue that the greatest danger of explainable AI is not that it is inexplicable, but that its explanations may encourage people to forget that the semantics still reside largely in the human community that created and interprets the symbols.

The DIKW confusion

The confusion is not merely between reliable AI and unreliable AI. It is often a confusion between representations and what is represented.

In that sense, many discussions around Knowledge Graphs, ontologies, AI, data governance, and even data science inherit an epistemological problem that long predates AI.

Many practitioners implicitly adopt the classical pyramid:

• Data
• Information
• Knowledge
• Wisdom

But in practice these notions are frequently collapsed into each other.

For example:

A knowledge graph contains:

(Paris) --capitalOf--> (France)

Many people then say:

“The knowledge graph contains knowledge.”

But what does it actually contain?

At the technical level:

• bits in storage,
• character strings,
• IRIs,
• graph structures,
• metadata.

The graph itself does not “know” anything.

Nor does the database.

Nor does the reasoner.

What exists is a formal representation that humans may interpret as expressing some proposition about the world.

This is very close to your distinction:

LevelNatureDataPhysical/digital artifactsInformationInterpreted structuresKnowledgeCognitive and social phenomenon

A triple store undeniably contains data.

Whether it contains information depends on an interpreter.

Whether it contains knowledge depends on a knowing subject or community.

Knowledge graphs are repositories, not knowledge

The expression “knowledge graph” itself may be misleading.

A graph database is fundamentally:

• a storage system,
• a retrieval system,
• a constraint system,
• sometimes an inference system.

But knowledge does not emerge automatically from storage.

A library is not knowledge.

A library contains documents.

Likewise a graph contains assertions.

The graph can support knowledge acquisition by humans.

It is not itself knowledgeable.

This distinction often disappears because computer science inherited a representational tradition in which:

representation of knowledge

gradually became

knowledge

The same shift happened historically with “expert systems”.

The rule base was often described as containing expert knowledge.

In reality it contained formalized traces of knowledge extracted from experts.

The knowledge remained distributed among:

• experts,
• institutions,
• practices,
• training,
• validation processes.

Trust is misplaced when attached to the artifact

Your point about trust is particularly important.

People often ask:

Can I trust the ontology?

But trust rarely originates from the artifact itself.

It originates from the socio-technical process that produced it.

For example, we trust a scientific formula not because it is written in a textbook.

We trust it because of:

• peer review,
• reproducibility,
• scientific institutions,
• education systems,
• accumulated empirical validation.

Similarly, an engineering standard is trusted because:

• experts contributed,
• review boards examined it,
• organizations maintain it,
• practitioners continuously test it.

The document is merely a carrier.

The trust resides in the social process.

The same applies to ontologies

Many ontology discussions implicitly assume:

If the ontology is formally correct, then it is trustworthy.

But formal correctness only means:

the axioms are internally coherent according to some logic.

Trustworthiness comes from questions such as:

• Who developed the ontology?
• For what purpose?
• Under which assumptions?
• How was consensus reached?
• How are disagreements handled?
• How is it maintained?
• How is it validated against reality?

These are governance questions rather than logical questions.

AI often obscures the institutional dimension

One of the dangers of current AI discourse is that it tends to individualize what is actually collective.

A scientist does not “know” Newtonian mechanics alone.

Their knowledge depends on:

• schools,
• universities,
• textbooks,
• laboratories,
• scientific communities,
• professional societies.

Knowledge is socially anchored.

Similarly, an engineer does not derive trust from a CAD model, ontology, digital twin, or knowledge graph.

Trust comes from:

• engineering processes,
• certification procedures,
• regulatory institutions,
• industrial experience.

The digital artifact is only one node in a much larger network of social validation.

A deeper inversion

Perhaps the deepest trap is that many AI narratives invert the relationship.

They suggest:

Data -> Information -> Knowledge

as if knowledge were produced mechanically from accumulating representations.

But one could argue the reverse is closer to reality:

Knowledge communities
        ↓
Conceptualizations
        ↓
Information artifacts
        ↓
Data representations

In this view, ontologies, knowledge graphs, standards, databases, and AI models are not the source of knowledge. They are the crystallization of prior human and institutional knowledge. The artifact does not create the epistemic authority; the epistemic authority creates the artifact.

This is why the ultimate question is often not:

“Can I trust this knowledge graph?”

but rather:

“What community, institution, discipline, validation process, and conceptual framework stand behind this graph?”

That question applies equally to a scientific database, an ontology, a description-logic reasoner, and a large language model. The technology differs; the epistemological dependency on human communities remains.

Are LLMs more trustworthy relying on GraphRAG?

This perspective has significant consequences for how we should evaluate GraphRAG.

The usual discussion around GraphRAG is often framed as:

“GraphRAG is more trustworthy than plain RAG because it uses a knowledge graph.”

From the epistemological viewpoint we have been discussing, that statement is incomplete and potentially misleading.

GraphRAG does not solve the grounding problem

GraphRAG combines:

1. A graph representation of entities and relationships.
2. Retrieval mechanisms.
3. An LLM that generates responses.

The graph may improve:

• retrieval precision,
• navigation of relationships,
• traceability of retrieved facts,
• consistency of retrieved contexts.

However, the graph remains a representation.

Whether the graph contains:

(Aircraft) --hasPart--> (Engine)

or a million triples, the system still depends on:

• how concepts were defined,
• who asserted the relationships,
• under which assumptions,
• for which purpose.

GraphRAG improves access to representations; it does not automatically improve the validity of those representations.

Trust shifts from the LLM to the graph

In standard RAG, the main question is often:

Can I trust the retrieved documents?

In GraphRAG, the question becomes:

Can I trust the graph construction process?

This includes:

• entity extraction,
• relationship extraction,
• ontology design,
• graph maintenance,
• source selection,
• update governance.

A GraphRAG answer can appear more authoritative because it traverses explicit links.

Yet every link originates somewhere.

For example:

Supplier A -> supplies -> Component B

may have been:

• manually curated,
• automatically extracted,
• inferred,
• imported from another system.

The graph structure itself does not reveal whether the relationship is correct.

Explainability can create overconfidence

One major selling point of GraphRAG is explainability.

The system can show:

Company A
   ↓
owns
   ↓
Company B
   ↓
supplies
   ↓
Product C

This chain looks reassuring because it resembles a proof.

But notice the same trap we discussed for ontologies:

The explanation shows:

how the answer was derived.

It does not show:

why the graph should be believed.

GraphRAG explanations are usually explanations of traversal, not explanations of truth.

The graph may amplify modeling biases

A graph appears objective because it externalizes structure.

However, every graph reflects choices:

• what entities exist,
• what relationships matter,
• what distinctions are ignored,
• what viewpoints dominate.

This is particularly important in enterprise architecture and interoperability contexts.

For example, a GraphRAG built around procurement concepts may answer very differently from one built around engineering concepts, even if both describe the same product.

The graph formalizes a conceptualization, not reality itself.

Provenance becomes more important than graph structure

From your perspective, one of the most important GraphRAG features is probably not the graph.

It is provenance.

A highly trustworthy GraphRAG would ideally answer:

Assertion:
    Aircraft X has Engine Y

Source:
    Engineering database Z

Responsible organization:
    Manufacturer M

Validation status:
    Approved configuration baseline

Date:
    2026-05-01

Notice that trust here comes from:

• source,
• authority,
• governance,
• validation process,

not from the existence of a graph edge.

The graph helps organize information, but provenance supports trust.

Enterprise knowledge versus graph content

In enterprise environments, GraphRAG is often presented as a way to “capture organizational knowledge.”

This can easily reintroduce the confusion between:

• knowledge,
• information,
• data.

A graph may contain:

• procedures,
• specifications,
• requirements,
• lessons learned.

But the enterprise knowledge remains distributed among:

• engineers,
• operators,
• managers,
• regulators,
• training programs,
• organizational practices.

The graph captures traces and representations of that knowledge.

It does not contain the knowledge itself.

This distinction becomes critical when people begin treating GraphRAG outputs as authoritative.

The strongest GraphRAG systems are socio-technical systems

The most reliable GraphRAG deployments are therefore not those with the most sophisticated graph algorithms.

They are those embedded within strong governance frameworks.

Their trustworthiness derives from:

• controlled vocabularies,
• ontology governance,
• configuration management,
• source traceability,
• review processes,
• domain expertise,
• institutional accountability.

In other words, the graph becomes part of a larger epistemic infrastructure.

A paradox

Interestingly, GraphRAG may increase trustworthiness while simultaneously increasing the risk of misplaced trust.

It increases trustworthiness because:

• retrieval is more structured,
• provenance can be attached,
• relationships become explicit,
• context can be more coherent.

But it also increases the risk of misplaced trust because:

• graphs look objective,
• graph traversals look logical,
• explanations look rigorous.

Users may therefore mistake:

explicit structure

for

validated knowledge.

The graph makes assumptions visible, but it does not validate them.

So from the viewpoint you have been developing around interoperability, ontology, and the distinction between data, information, and knowledge, the central question for GraphRAG is probably not:

“How good is the graph?”

but rather:

“What institutional, scientific, engineering, and governance processes produced, maintain, validate, and contextualize the graph and its sources?”

The trustworthiness of GraphRAG is ultimately bounded not by graph theory or retrieval algorithms, but by the quality of the socio-technical system that stands behind the graph.

Fallacies, fallacies, fallacies…

several fallacies that are not unique to AI, but which are being amplified by the current AI enthusiasm cycle.

What is interesting is that many of these fallacies already existed in:

• expert systems,
• knowledge management,
• business intelligence,
• semantic web,
• big data,
• digital twins,
• enterprise architecture.

AI has not created them; it has given them new forms and new marketing language.

1. The reification fallacy

This is perhaps the most fundamental one.

A representation is treated as if it were the thing represented.

Examples:

• “The knowledge graph contains knowledge.”
• “The model understands the domain.”
• “The ontology captures reality.”
• “The digital twin is the system.”

But a graph is not knowledge. An ontology is not reality. A digital twin is not the physical system. The representation becomes reified into the object itself. This is reminiscent of the famous warning:

The map is not the territory.

AI discourse frequently forgets this distinction.

2. The epistemic automation fallacy

There is often an implicit assumption:

More data
→ More information
→ More knowledge
→ Better decisions

But the transitions are not automatic.

Data processing can produce:

• inconsistencies,
• ambiguities,
• contradictions,
• irrelevant outputs.

Knowledge requires interpretation, validation, and contextualization. The belief that epistemic processes can be fully automated is largely unproven. What can be automated is computation. Whether knowledge is produced remains a social and cognitive question.

3. The explainability fallacy

A surprisingly common mistake is:

If I can explain how a conclusion was generated, then I can trust it.

Explanation and justification are different.

For example:

A → B
B → C
therefore C

The chain may be perfectly explainable.

Yet:

• A may be false.
• The model may be inappropriate.
• The ontology may be flawed.

Explainability only addresses the internal mechanics of inference.

It does not establish the validity of premises.

4. The formalization fallacy

Many AI narratives implicitly assume:

What cannot be formalized is unimportant.

This is particularly visible in enterprise and engineering contexts.

Graphs, ontologies, and models capture:

• documented processes,
• defined relationships,
• explicit concepts.

But much expertise remains:

• tacit,
• experiential,
• contextual,
• social.

Formal systems often represent the visible portion of organizational knowledge while ignoring the invisible portion.

The danger is assuming the visible part is the whole.

5. The objectivity fallacy

People often perceive:

• mathematical models,
• ontologies,
• graphs,
• AI outputs,

as objective because they are formal.

Yet every formalization embeds choices.

Someone decided:

• which entities exist,
• which distinctions matter,
• which categories are relevant,
• which data sources are authoritative.

The resulting artifact may be systematic without being objective.

The appearance of neutrality can hide subjective assumptions.

6. The authority transfer fallacy

This is extremely common.

Trust that properly belongs to institutions is transferred to technology.

For example:

People trust:

• science,
• engineering standards,
• medical practice,

because of:

• peer review,
• experimentation,
• professional accountability,
• institutional validation.

But then the trust migrates:

Science is trusted
↓
Scientific papers are trusted
↓
Scientific databases are trusted
↓
AI trained on scientific databases is trusted

At each step, some validation mechanisms disappear. The final artifact inherits authority without inheriting all the processes that generated that authority.

7. The intelligence fallacy

A major AI bubble narrative is the equation:

Problem solving = Intelligence

or

Language generation = Understanding

The fact that a system produces coherent outputs does not necessarily imply:

• understanding,
• intentionality,
• meaning,
• consciousness.

Historically, many successful engineering systems have performed useful tasks without possessing the properties attributed to them by observers.

Humans are particularly prone to anthropomorphism.

8. The scalability fallacy

There is a widespread assumption that:

If a system works on a small domain, scaling it up will eventually solve everything.

The Semantic Web suffered from this.

Knowledge Management suffered from this.

Big Data suffered from this.

AI may suffer from the same issue.

Many difficulties are not computational but conceptual:

• conflicting viewpoints,
• inconsistent definitions,
• organizational politics,
• disciplinary boundaries.

Scaling computation does not automatically scale consensus.

9. The substitution fallacy

Another recurring belief is:

A representation can replace the community that produced it.

Examples:

• knowledge graph replacing experts,
• AI replacing scientists,
• digital twin replacing engineers,
• ontology replacing domain communities.

But the artifact depends continuously on:

• maintenance,
• interpretation,
• revision,
• governance.

Once separated from its supporting community, its relevance tends to decay.

10. The institutional invisibility fallacy

This may be the most important for your line of thinking.

Modern AI discourse often presents knowledge as if it emerged from data.

But knowledge usually emerges from institutions.

Consider:

• universities,
• laboratories,
• engineering organizations,
• standardization bodies,
• regulatory agencies,
• professional communities.

These institutions create:

• concepts,
• definitions,
• validation procedures,
• educational processes.

AI systems largely consume the outputs of these institutions.

The AI appears intelligent because it stands on a vast pre-existing infrastructure of human knowledge production.

The institutional layer becomes invisible.

The machine receives the credit.

The deeper bubble narrative

If one steps back, the AI bubble may partially rest on a category mistake.

Many discussions implicitly assume:

Knowledge is a property of machines.

whereas a more defensible position might be:

Knowledge is primarily a property of human and institutional systems.
Machines manipulate representations that participate in those systems.

From that perspective, the central unanswered question of AI is not merely:

“Can machines reason?”

but:

“Can computational systems participate in the social, epistemic, and institutional processes through which knowledge is created, validated, challenged, transmitted, and maintained?”

Current AI systems — including LLMs, GraphRAG systems, ontologies, and reasoners — are extraordinarily powerful tools for manipulating representations. The bubble often begins when this capability is conflated with the broader human and institutional phenomenon that we call knowledge.

Inhabiting Babel Manifesto and Semantic Cartography

My motivation for “Inhabiting Babel”, a manifesto for responsible meaning engineering and “semantic cartographies” is to challenge one of the deepest assumptions underlying much of the AI, Semantic Web, and knowledge management discourse:

that there exists a single, coherent semantic space waiting to be formalized.

I start from the opposite observation:

humans already inhabit a plurality of semantic worlds.

This changes the problem completely.

From knowledge representation to coexistence of conceptual worlds

Much of AI implicitly assumes a pipeline such as:

Reality
  ↓
Conceptualization
  ↓
Ontology
  ↓
Knowledge Graph
  ↓
Reasoning

The hidden assumption is that there is a sufficiently stable conceptualization that can be captured.

But in practice, especially in engineering and enterprise contexts, one observes:

Reality
  ↓
Many observers
  ↓
Many conceptualizations
  ↓
Many ontologies
  ↓
Many representations

A financial analyst, a safety engineer, a lawyer, a maintenance operator, and a regulator do not inhabit the same semantic world.

They may use the same words while meaning different things.

Or different words while referring to overlapping phenomena.

The challenge is therefore not merely representing knowledge.

It is navigating among conceptual worlds.

This is where Babel enters.

Inhabiting Babel

The traditional interpretation of the Tower of Babel is often:

diversity of languages is a problem to be eliminated.

Many interoperability efforts unconsciously inherit this mindset.

The goal becomes:

• one ontology,
• one vocabulary,
• one reference model,
• one source of truth.

But complex enterprises and societies rarely work that way.

A more realistic interpretation is:

Babel is not an accident.

Different disciplines necessarily create different conceptualizations because they pursue different purposes.

For example:

Each community constructs a legitimate but partial semantic world.

The problem is not the existence of Babel.

The problem is learning to inhabit it.

Why this matters for AI

Most AI systems are implicitly monocultural. They assume that concepts can be unified into a common representation.But many disagreements are not data problems. They are conceptual problems.

Consider the word:

System

A software architect, a systems engineer, a biologist, an economist, and a philosopher may all use the same word while referring to different conceptual structures.

• An AI trained on all these sources may statistically merge them.
• A knowledge graph may choose one definition.
• An ontology may enforce one interpretation.

Yet the plurality remains. The AI often hides Babel rather than revealing it.

Semantic cartographies as an alternative

A cartography does not claim to be the territory.

Nor does it claim to be the only map.

Instead it makes explicit:

• viewpoints,
• boundaries,
• scales,
• projections.

This metaphor is powerful.

Geographers do not ask:

Which map is true?

They ask:

For which purpose was this map produced?

A metro map, a geological map, a political map, and a topographic map can all be valid simultaneously. They reveal different aspects of the same territory.

Applying cartography to semantics

A semantic cartography would therefore describe:

• conceptual territories,
• their boundaries,
• their overlaps,
• their conflicts,
• their translations.

Instead of seeking:

One ontology

it seeks:

A map of ontologies

Instead of:

One vocabulary

it seeks:

A map of vocabularies

Instead of:

One truth model

it seeks:

A map of perspectives

This is a radically different objective.

Implications for GraphRAG

Current GraphRAG systems often assume:

Graph
    ↓
Truth structure

A semantic cartography perspective would suggest:

Graph
    ↓
Perspective structure

The graph would not merely store assertions.

It would also locate:

• who made them,
• from which discipline,
• under which assumptions,
• for which purpose.

The graph becomes less a repository of truths and more a repository of situated viewpoints. This aligns much more closely with how science and engineering actually function.

Implications for trust

This is where your earlier point about institutions returns.

Trust is not:

Graph → Trust

but rather:

Institution
      ↓
Conceptualization
      ↓
Representation
      ↓
Graph

A semantic cartography makes this chain visible.

Instead of asking:

Is this statement true?

one asks:

From which conceptual territory does this statement originate?

Which institution validates it?

Under which assumptions does it hold?

This shifts trust from artifacts back to the social and epistemic structures that produced them.

The AI bubble from a Babel perspective

Many AI narratives can be interpreted as attempts to rebuild the Tower of Babel:

• universal foundation models,
• universal ontologies,
• universal knowledge graphs,
• universal assistants.

The implicit dream is:

one representation capable of encompassing all human meaning.

A Babel-aware perspective suggests that the problem may be fundamentally different. The challenge is not constructing a universal semantic system. It is constructing systems capable of navigating among multiple semantic systems without collapsing them into one.

In that sense, “Inhabiting Babel” is not merely a critique of AI. It proposes a different research agenda:

• from representation to mediation,
• from ontology to meta-ontology,
• from knowledge bases to semantic cartographies,
• from universal meaning to negotiated meaning,
• from eliminating plurality to making plurality navigable.

This is also why your notion of semantic cartography seems more aligned with interoperability than with traditional AI. Interoperability is rarely about proving that one conceptualization is correct; it is about enabling communication, coordination, and translation among communities that legitimately inhabit different semantic worlds.

🧭 Conclusion

The current wave of AI systems — LLMs, GraphRAG, ontologies, reasoning engines — does not fundamentally change the epistemic situation. It intensifies a long-standing confusion:

we keep mistaking representations for what they represent.

Whether deterministic or stochastic, explainable or opaque, these systems operate on symbols, not meaning. The meaning comes from human and institutional worlds that define, maintain, and validate those symbols.

This is why trust in AI cannot be grounded in the artifact alone. It is grounded in the socio-technical ecosystem behind it: scientific practices, engineering standards, governance structures, and communities of expertise.

From this perspective, the key shift is not toward “more intelligent machines”, but toward a different epistemic posture:

• from unified knowledge systems → to plural semantic worlds
• from ontologies → to ontological plurality
• from explainability of inference → to transparency of conceptualization
• from GraphRAG as truth retrieval → to GraphRAG as navigable perspective space

This is the core intuition behind Inhabiting Babel:

Babel is not a problem to solve. It is a condition to inhabit.

And semantic cartographies are not about finding the single correct map — but about making visible the multiplicity of maps, their boundaries, their assumptions, and the institutions that sustain them.

In that sense, the future of AI may be less about “knowing the world” and more about learning how to move responsibly across many ways of knowing it.