← GlossaES···

What NeOn tells you not to build

Suárez-Figueroa and colleagues turned ontology engineering into a discipline of reuse rather than invention — a doctrine now caught between the language models that automate it and the pitfall scanners that decide whether the result is sound.

N° 341 July 2026Based on Suárez-Figueroa, Gómez-Pérez & Fernández-López, 'The NeOn Methodology for Ontology Engineering' · with eight companion sources
11 min read2,130 words
No mark means we checked it. A mark means be careful.gold corroborated: a document or record backs itdotted one source only, nothing else backs itplain asserted, and nothing we found backs it

Most engineering methodologies tell you how to build something. NeOn’s first instruction is to not build it — to go looking for what already exists and re-engineer that instead. The advice sounds like evasion. It is the opposite: a wager, made in Madrid two decades ago, that formal knowledge should be shared public infrastructure rather than a thing each project reinvents. That wager is now the spine of a doctoral thesis that turns the EU AI Act and the United States’ NIST framework into structured, queryable knowledge. The thesis borrows NeOn precisely for its discipline of reuse. But the same reuse work NeOn formalized for human experts is exactly what a new wave of language models now automates — with an automated pitfall scanner standing in as the judge of whether the result holds.

Part 01
§ 01

The method that says reuse

Before NeOn there was a habit of building ontologies from nothing. NeOn’s contribution was to treat that habit as the mistake.

NeOn came out of a European project with an unglamorous title: “Lifecycle support for networked ontologies,” funded under the EU’s Sixth Framework Programme.1 The work was led by the Ontology Engineering Group (OEG) at the Universidad Politécnica de Madrid, under Asunción Gómez-Pérez. It produced tools, a methodology, and eventually a book.

Its central claim was counterintuitive for an engineering method. Earlier approaches assumed you built an ontology the way you built a program: from a specification, from scratch. NeOn assumed the opposite. Most of the knowledge you need already exists somewhere — in a thesaurus, a standard, another ontology — and the real work is finding it, judging it, and re-engineering it into shape.

To make that operational, NeOn is scenario-based. It defines nine scenarios for building ontology networks, each a different combination of reuse and re-engineering.2 Only two of them matter for a thesis on AI regulation, and naming them precisely is the whole point of this reading.

A Madrid lineage
Thirty years of one lab's methodologies
METHONTOLOGY — build from scratch (now deprecated)
1997
NeOn project begins (EU FP6-027595)
2006
The NeOn Methodology, in book form
2012
OOPS! pitfall scanner published
2014
LOT methodology · AIRO ontology (Dublin)
2022
NeOn-GPT · LLMs4Life — LLMs automate the reuse
2024
  1. METHONTOLOGY — build from scratch (now deprecated)
  2. NeOn project begins (EU FP6-027595)
  3. The NeOn Methodology, in book form
  4. OOPS! pitfall scanner published
  5. LOT methodology · AIRO ontology (Dublin)
  6. NeOn-GPT · LLMs4Life — LLMs automate the reuse
Source. OEG-UPM publication record; companion sources in this reading

The lineage is worth seeing as a lineage. METHONTOLOGY, the same group’s method from 1997, is now deprecated. NeOn replaced it. LOT — Linked Open Terms — is the lightweight, agile successor the same lab published in 2022, and it supplies the step-by-step procedure that NeOn, a framework of scenarios, deliberately left open.3 A thesis defended in Spain can cite this as a national methodological tradition, not an import.

Part 02
§ 02

Scenario 2: turning a regulation into structure

The EU AI Act is prose. The NIST framework is prose. Scenario 2 is the discipline of turning that prose into something a machine can reason over.

The EU AI Act runs to more than a hundred articles. The NIST AI Risk Management Framework (AI RMF) — the United States’ voluntary counterpart — is organized into four functions and dozens of subcategories.4 Neither is an ontology. Both are what NeOn calls a non-ontological resource: structured human knowledge that has not yet been formalized.

Scenario 2 is the reuse and re-engineering of exactly these resources. The OEG had a dedicated pattern-based method for it years before the AI Act existed — for turning standards and classification schemes into ontologies.5 A thesis that formalizes Articles 11 to 14 of the Act is running Scenario 2 on a legal text.

Here is the concept the rest of the argument leans on. Imagine you want to claim that a NIST control “covers” an AI Act requirement — that an agency documenting under GOVERN and MAP has, in effect, satisfied Article 9. How would you know? NeOn’s answer is the competency question — a plain question, written in natural language, that the finished structure must be able to answer.

You write those questions first, in a document called the Ontology Requirements Specification Document (ORSD). They scope the work: they force you to name the concepts and relationships you will need. And they validate it: at the end, either the structure answers them or it does not.

The move that matters is that validation stops being a matter of taste. A crosswalk between two frameworks is not “does an analogous article exist.” It is: can the mapping answer whether a PATTERN-style system meets the Article 14 requirement of human oversight using only NIST documentation? If it cannot answer that, the crosswalk is incomplete — no matter how many boxes it ticks.

Before continuing, hold the question the whole thesis turns on: when two regulations use the same word — “risk,” “oversight,” “documentation” — and mean subtly different things, has a table that pairs them actually shown coverage, or only the appearance of it? The fast intuition says coverage. The method says: prove it with a question.

NeOn's nine scenarios
Which scenarios the thesis actually uses
Used here
1 · Build from specification (from scratch)
Used here
2 · Re-engineer non-ontological resources — standards, regulation
Used here
3 · Reuse existing ontological resources
Used here
4 · Reuse and re-engineer ontological resources
Used here
5 · Reuse and merge ontological resources
Used here
6 · Merge and re-engineer ontological resources
Used here
7 · Reuse ontology design patterns
Used here
8 · Restructure ontological resources
Used here
9 · Localize ontological resources
Used here
Source. Scenarios per the NeOn Methodology; selection is this thesis's
Part 03
§ 03

Scenario 3: reusing what Dublin already built

You could define “high-risk system” from scratch. Or you could reuse the ontology in which a group in Dublin already did.

Scenario 3 is the reuse of ontological resources — structures someone else already formalized. For AI regulation, the concrete case has a name: AIRO, the AI Risk Ontology.

AIRO was built at the ADAPT Centre at Trinity College Dublin, by Delaram Golpayegani, Harshvardhan Pandit and Dave Lewis.6 It formalizes the AI Act’s risk concepts — system, provider, high-risk, impact — and aligns them to the ISO 31000 risk-management standard. It ships with the machinery to use them: constraint checks in SHACL — a language for validating the shape of data — and queries in SPARQL, the query language for this kind of structured knowledge. Point it at a case and it can compute whether the system falls under the Act’s high-risk annex.

The detail that makes Scenario 3 vivid is what happened next. AIRO did not just sit beside the DPV; it was folded into it, as the DPV’s official EU AI Act extension.7 AIRO reuses the DPV; the DPV absorbs AIRO. The reusable resource is itself a product of reuse.

That is the doctrine made flesh. NeOn tells you how to reuse; AIRO and the DPV are what you reuse; and the two of them, folding into each other, show that “reuse over creation” is not an excuse for thin work. It is how a field accumulates.

Part 04
§ 04

When the machine does the reuse — and what audits it

The same reuse NeOn formalized for experts is now what language models automate. A tool from the same Madrid lab decides whether they got away with it.

The name gives it away: NeOn-GPT. It is a pipeline that grafts large language models onto NeOn’s own steps — requirements, reuse, formalization — and lets the model do the work a human engineer used to do.8 A companion project, LLMs4Life, extends that pipeline into the life sciences, generating deep ontologies evaluated against an existing gold-standard one.9

The promise is compression: skip the expert, keep the structure. The evidence is more sober. A 2025 benchmark comparing GPT models and Perplexity on ontology creation found the models weakest exactly where a regulation is most demanding — on subclass relations and on the domain and range of properties, the parts that fix a hierarchy in place.10 A model can emit something that reads like an ontology and get the hierarchy quietly wrong.

Which is where the audit comes in — and where the geography closes a loop. OOPS!, the OntOlogy Pitfall Scanner, was built by the same OEG group in Madrid that built NeOn.11 It scans a finished ontology for “pitfalls”: recurring modeling errors — a class that looks connected but is orphaned, an inverse relation declared backwards, a missing disjointness. Its catalog has been extended since.12 The scanner does not certify correctness. It flags the places where the structure is probably wrong.

An ontology can pass every surface check and still be conceptually broken underneath.— the pitfall, restated

Here is the hinge of the whole reading. A pitfall is the gap between an ontology that looks sound and one that is sound. Read that sentence against the thesis’s own premise — that documentable compliance is not the same as real compliance — and it is the same gap, one level down, in the tooling. A crosswalk with undetected pitfalls generates false congruence between two frameworks: the boxes are ticked, the inference is wrong.

So the question the automation raises is not technical. It is a question about authority. When a model generates the concept and a scanner rubber-stamps the surface, who is left to say what the concept means? NeOn’s answer was: an expert, writing competency questions, held responsible for the judgment. The automation’s answer is still being written.

Part 05
§ 05

An ontology is discourse, and a border can outlaw it

The last companion source turns the whole problem political — and hands the thesis its clearest mirror.

In biomedicine, ontologies are built and released with a shared toolchain, the Ontology Development Kit (ODK), used across the OBO Foundry — a community of interoperable biological and biomedical ontologies. A recent report on that toolchain makes an argument that sounds abstract until it isn’t: an ontology is a form of discourse. Like code, it can fall under laws about expression. The same ontology can be lawful in one jurisdiction and prohibited in another.13

The proposed fix is a “split world.” You produce slightly divergent editions of one ontology, each tuned to a jurisdiction’s legal mandate, without contaminating the shared global core. The semantic core stays intact; a local variant absorbs the regulatory load.

Read that against the thesis and it is a structural twin. A US federal agency working under the NIST framework wants to produce documentation that also satisfies the EU AI Act — without redesigning its controls. Fork the artifact, keep the core: interoperability without duplication. The ODK’s split-world is a working precedent for the abstract pattern the thesis defends.

The healthcare cases are not a detour. They are the proof that the pattern generalizes: reuse as doctrine, automation as temptation, the pitfall scanner as the thin line between an artifact that looks right and one that is. What the AI Act makes legally consequential, medicine has already made clinically consequential.

What is still uncertain is whether the automation can ever carry the part of the work that made NeOn a methodology rather than a tool — the expert judgment encoded in a competency question — or whether it can only imitate its surface. The benchmarks say imitation, for now.

What is not uncertain is the shape of the thing. NeOn’s doctrine — reuse, re-engineer, validate against questions you wrote in advance — is the spine the thesis needs, and the pitfall gap it exposes is real at every level: in an OWL file, in a model’s output, in a table that pairs two regulations.

What the reader is left with is a way to read the crosswalk that sits under all of this. It is not a list of textual equivalences. It is a re-engineering, in the strict NeOn sense, that either answers its competency questions or does not. A crosswalk that cannot answer them is a pitfall with the quotation marks removed.