An AI Still Needs to Know What You Mean

Ask an AI system to read a collection of reports and suggest an ontology. It can return an impressive list of concepts and relationships before a human team has finished arguing about the first definition.

Some of those suggestions may be excellent. Others may repeat an inconsistency in the source material, merge two meanings, or give a casual phrase more authority than its author intended.

The useful question is what to do with the proposals. That brings us back to the library, although the person doing the work may now be called an ontologist, a knowledge engineer, or a data architect.

Building the model has always involved judgment

In their 2001 guide to ontology development, Natalya Noy and Deborah McGuinness described a practical, iterative activity: establish the purpose, consider reuse, develop concepts and relationships, and test the model against the questions it should answer. There is no single correct ontology for every possible use. Noy and McGuinness, Ontology Development 101

That last point is easy to forget when a model arrives as a polished file.

An ontology for finding technical reports may organize concepts differently from one used to check a design. The first needs good routes into relevant material. The second may need explicit requirements, conditions, and logical relationships. A large concept inventory does not tell us which job it can do.

The tools also have a history. Mark Musen’s doctoral work at Stanford in the 1980s contributed to the beginnings of Protégé, initially concerned with building knowledge-based systems. Its ontology-editing capabilities later became a reusable environment for many domains. The work involved helping specialists construct models, not assuming that expertise could be copied intact into software. Stanford, Protégé History

AI-assisted modelling belongs in that continuing practice. It changes how proposals are produced and how much material a team can examine. The proposed distinctions still need to serve a purpose.

What a generated graph does and does not establish

Darren Edge, Ha Trinh, and colleagues described a GraphRAG approach in 2024 that uses a language model to extract entities and relationships from text, builds a graph, and develops community summaries to support questions about a collection as a whole. Their work investigated a useful way to move beyond retrieving a few isolated passages. Edge and colleagues, From Local to Global

A graph built this way is not automatically a formal ontology. It may record relationships found or inferred in a particular collection without establishing the definitions, constraints, and identity rules needed by another application.

Suppose reports repeatedly place “assurance” beside “inspection.” An extracted graph may connect them. A professional model still needs to establish the relationship. Is an inspection one form of assurance activity? Does it provide evidence for assurance? Do the words mean different things in different departments?

The answer changes what the system can safely retrieve or conclude.

There is real value in having AI find the passages where the terms occur, group candidate uses, and propose a distinction. The practitioner can then inspect representative cases instead of beginning with an empty page. The improvement is concrete: more of the relevant material can enter the conversation.

Follow one claim all the way through

Imagine a team using an AI assistant to answer, “Which inspection procedure applies to this pump?”

A convincing answer needs several distinctions we have followed through the series. It needs to identify the particular pump rather than another unit with a similar name. It needs the equipment type and operating context. It needs the applicable procedure revision, not merely the most recent file mentioning pumps.

A retrieved report might quote an old procedure to explain why it was replaced. Treating the quotation as current instruction would reverse the document’s meaning.

The ontology and surrounding knowledge system can help by distinguishing a procedure from a discussion of that procedure, a current requirement from a historical one, and an applicable rule from a rule mentioned in passing. Source records and revision histories let a reviewer inspect the basis of the answer.

Those distinctions do not eliminate every error. They make important errors easier to find and correct.

The interface matters too. A user should be able to move from the short answer to the identified equipment, procedure revision, and supporting passage. If all the careful modelling disappears behind one confident paragraph, the person receiving the answer cannot benefit from much of the work.

The library principles are still doing work

Panizzi and Cutter help us ask whether names and descriptions bring the right resources together. Ranganathan keeps attention on the reader and on the several dimensions through which a subject can be approached. Avram reminds us that distinctions have to survive exchange between systems. Scientific ontology practice keeps a concept separate from the evidence supporting an individual claim.

These are connections between recurring problems, not a claim that every modern technique descended directly from one library method. The history contains parallel traditions, disagreements, and different purposes. Its usefulness lies in giving practitioners better questions.

What does this concept include? Which apparently similar thing does it exclude? Who uses another name for it? What would count as evidence that two records describe the same object? What happens to old records when the definition changes?

A team can ask those questions of an AI-generated draft just as it would ask them of a human-authored one.

The result should remain editable. Someone needs a practical way to challenge a definition, submit a counterexample, correct an association, and see which applications a change will affect. Maintenance is part of authorship when other people depend on the model.

We began with a book about bridges being confused with a book carrying a bridge on its cover. At the end of this journey, a system can make that same mistake across a million documents and phrase its answer beautifully. The old distinction still matters. So does the reader waiting for the right book.