Lecture Ten. The Politics of an Installed Ontology, and What Comes Next.

This is the last of ten talks about ontologies. Last time we took apart what Palantir means by the word: object types and link types for the nouns, action types and functions for the verbs, security woven through, and user decisions written back as data. Today, two things. First, what happens when a system like that is installed inside a state institution, which is where lecture eight's criticism stops being academic. Then, where all of this stands now that machines can read.

Start with a research paper that does something unusual: it studies a Palantir deployment from the inside.

The paper is by Vasilis Galis and Björn Karlsson, written at the IT University of Copenhagen and published in two thousand and twenty-four in the journal Information, Communication and Society. It is about POL-INTEL, which is not an acronym anybody expands — it is simply the name of the Danish police's customisation of Palantir's Gotham platform. The researchers interviewed both Palantir engineers and the police officers who use it.

Their opening move insists on something I have been circling for nine lectures. The concept of ontology here, they write, has to be understood in a twofold, albeit interconnected, way. It carries its usual philosophical burden — a claim about what exists — and it also refers to a centralised concept repository, the computer science sense of how data is structured. They then borrow Barry Smith's split between theory-focused R-ontologies and pragmatic E-ontologies, and find that the platform's E-ontology cannot be separated from Palantir's or the police's.

Their central claim is that the ontology is inherently political. Not politically abused, not politically vulnerable. Political in its construction. It is articulated, they write, by an assemblage of data, ideological positions, and economic concerns that are translated into the Danish context. And they use a phrase I would like you to keep, which they take from Leese: devices like this do not only describe the world but also enact it.

Their example of that is the one to hold on to.

A car. Its record is mirrored into the platform from the Motor Vehicle registry. In the registry it is a vehicle. Perfectly innocent, and true.

Now it enters the platform. An officer applies filters. And in that context the car is potentially seen as a getaway vehicle.

Nothing about the car changed. No new fact about the world was discovered. The category was produced by the interplay of the platform's concepts and the officer's analytical role, and not by the registry.

This is Bowker and Star's torque, from lecture eight, with a licence agreement attached. Torque, in the definition Stefan Helmreich gives in his review essay — and I should say plainly that my source on this book is reviews and reading notes rather than the book itself — is what unfolds when the time of the body and of its multiple identities cannot be aligned with the time of the classification system. Individual biographies, he writes, are twisted into tortured shapes where the scheme and everyday life do not line up. The comparison I would add is mine, not theirs. The International Classification of Diseases mainly describes. A police intelligence platform describes and then acts, because it has action types. Something happens next.

The paper documents a second effect: platformisation redistributes skill. It reports new distributions of capability between the platform and the officer, with consequences for organisational life and for accountability. The gloss is mine — the officer's expertise shifts from knowing a neighbourhood to knowing how to query. Nobody voted on that. It arrived with a procurement.

The authors are careful in a way that strengthens the argument. They do not claim the modelling is technically wrong. They grant that these platforms pragmatically integrate, analyse, and visualise data — and then they land the distinction. Pragmatically, not agnostically. These platforms are formatted, framed, and encoded with concepts, and through their ontology they perform politics.

They are blunter still elsewhere, in the sentence I would want read aloud at a procurement meeting: platforms such as POL-INTEL are not encoded with democratic values or other modernist sensibilities. Nobody ever claimed they were, and that is the difficulty. The failure mode is treating a delivered ontology as a neutral description of the domain rather than as an encoded set of choices about what counts — and delivery is precisely the moment it looks most neutral.

Now the legal side, because this stopped being a seminar question in February two thousand and twenty-three.

In its judgment of the sixteenth of February that year, Germany's Federal Constitutional Court, the Bundesverfassungsgericht, held that two provisions permitting automated data analysis by police, one in Hesse and one in Hamburg, are unconstitutional. It is worth naming them, because their smallness is the point: section twenty-five a, subsection one, first alternative, of the Security and Public Order Act for the Land Hesse, and section forty-nine, subsection one, first alternative, of the Act on Data Processing by the Police for the Land Hamburg. Two clauses of statute. The remedies differ, and the difference matters more than the headline. The Hamburg provision is void. The Hesse provision was left to continue to apply, subject to restrictions, until new provisions had been enacted, and in any case no later than the thirtieth of September two thousand and twenty-three. One law was struck out. The other was kept alive on a leash while the legislature fixed it.

The court's reasoning, in its own words, is that the powers allow the police, with just one click, to create comprehensive profiles of persons, groups and circles, and may also subject many persons who are legally innocent to further police measures. Reporting the ruling, WIRED noted that the court issued strict guidelines for the first time on how automatic data analysis tools like Palantir's can be used by police, and warned against including data belonging to bystanders, such as witnesses or lawyers.

One of the eleven claimants was Britta Eder, a Hamburg defence lawyer, and her position shows exactly why link types matter. Her client list includes anti-fascists, people who campaign against nuclear power, and members of the P-K-K, a banned militant Kurdish nationalist organisation. She is a lawyer doing her job. In a link-based system she is a heavily connected node in a graph of suspects.

Hold that next to lecture nine. A link type is the schema definition of a relationship between two object types. Bidirectional. Independently traversable from both sides. That is a technical fact about a data model, and it is also the thing that puts a defence lawyer inside an investigation. Which link types exist, and the thresholds inside a function, are policy choices with legal consequences, made by engineers.

So here is the review I would want run on any operational ontology. It is four questions.

Which object and link types create legal exposure? Not which are technically difficult. Which ones, once traversable, put people in a graph they did not choose to be in.

Whose data enters as a by-product of proximity rather than of suspicion? That is the bystander problem the German court named, and it is structural rather than accidental.

When a real case does not fit a category, who bears the cost? That is Bowker and Star's question, and it is the one with no technical answer. Helmreich compresses their answer into a clause: there is no experience of torque for those in power. If the cost lands on somebody who was not in the room when the categories were drawn, then the modelling decision was a policy decision, and it should have been made like one.

And when a case does not fit, the instinct is to treat the case as the anomaly. Eric Nehrlich, in his reading notes on the book, states the correction: there will always be elements which do not slot neatly into a category, but that is not a reflection of the element, it is a reflection of the inadequacy of the system. His example is the platypus. The step I would add is that a platypus takes no harm from being hard to classify, and the element here is a person.

And can the audit trail reconstruct why a person was surfaced? Not just what action was taken. Which filters, which thresholds inside which function, which link traversal. If the answer is no, then nobody can be held responsible for a decision the system effectively made.

That last one is where the writeback mechanism from lecture nine turns from a feature into an obligation. If every decision becomes data, the record exists. Whether anyone can read it back into an explanation is a design choice.

Notice that all four questions assume a human being is the one asking. Put an agent in that seat and the volume of decisions taken through these categories goes up, and the governance and audit questions scale with it. Which is where the rest of this lecture goes. Where does all of this stand now that machines can read?

The obvious challenge is straightforward. Every ontology in this series exists because somebody had to write down what nobody writes down. Lenat's argument in lecture four was that reading text cannot supply common sense, because the writers leave it out. Large language models — LLMs, systems trained on enormous quantities of text to predict and produce more of it — appear to have learned an enormous amount of it from text anyway.

So let me separate three questions that get conflated constantly, because they have three different answers.

Question one: can a language model replace an ontology as a store of knowledge? The case for replacement deserves stating fairly first, and I should flag that my note reconstructs that case rather than quoting it, because no source in this corpus argues for it directly. It runs like this: a model trained on a large corpus encodes much of the taxonomic and relational knowledge an ontology would state, and answers questions without anybody having written an axiom. The premise is not disputed by the people who go on to test it. Sun and colleagues grant that models demonstrate an impressive ability to internalize knowledge and answer natural language questions, and they record that this is sparking a growing debate about whether traditional knowledge graphs will be replaced by language models in real applications. So the question is live, and nobody here is knocking over a straw man.

Then they test it. Their two thousand and twenty-four paper in the database-systems literature asks directly whether large language models are a good replacement of taxonomies, and this is where the evidence is weakest for replacement. Their result: models perform miserably poorly in handling specialised taxonomies and leaf-level entities, and the question-answering accuracy of the best model drops by up to thirty per cent as you go from common to specialised domains, and from the root of a taxonomy to its leaves. They concede the other half plainly: for common domains, the manually maintained taxonomies may not be needed shortly. In specialised domains they recommend that practitioners stay with the tree.

But the deeper problem with replacement is not accuracy. It is the three properties I flagged in lecture four as my own argument rather than Lenat's. An axiom is inspectable, you can read it. It is consistent, in the sense that a reasoner will tell you when it contradicts another axiom. And it can be audited: you can ask where it came from and why. A model's answer has none of the three. For a great many uses that does not matter. For a drug interaction, a regulatory filing, or a police record, it is the whole game.

Question two: can a model build an ontology? Break the job up before answering, because building an ontology is several tasks and they are not equally hard. The tooling literature names three. Term typing, which maps a lexical term to a class. Taxonomy discovery, which finds the hierarchical is-a and subclass relations. And non-taxonomic relation extraction, which finds everything else — part-of, causes, used-for. There is also a separate setup, called Text to Onto, which extracts terms and types from raw text rather than from an existing ontology. So when somebody tells you a model built their ontology, the first question is which of those it did, because the word covers all four.

This is where the answer is mixed. Maria Keet argues that developing an ontology from a language model is harder than it looks, and her lead point is that models are not knowledge bases. They do not store the structured facts, axiomatised sentences, and rules needed to make inferences, so there is no assurance a model returns the same answer to the same query twice, and two runs may give two different ontologies. Her second objection is logical, and her own example carries it. If a majority is ignorant of the fact that whales are mammals and wrote about their misconception, a model may propose them to be fish — and that would make the ontology inconsistent if the rest of animal classification was represented properly. Inconsistent ontologies, she adds, are bad computationally. The shape of that failure is worth naming, and the naming is mine: the model is not wrong about the text. It is wrong about the world, and the ontology is the only place the two get compared.

The tooling bears that out with specific numbers. Direct all-pairs matching with a model is quadratic and documented as suitable only for small ontologies, around two hundred concepts or fewer. Retrieval narrows the candidate set, and the standing recommendation is pure models for well-known domains, retrieval for specialised ones, and, where reliability matters more than convenience, ensembles that combine a model with symbolic methods or with several other models. Matching thresholds are dataset- and use-case-specific, so they do not transfer. And on prompting, the finding runs the opposite way to the folklore: clear prompts and structured output do reduce hallucination and inconsistency. What they do not do is remove the need to validate relationships and labels against representative held-out data, multiple metrics, and classical baselines.

The pattern I would draw out of that is a division of labour, and it is my summary rather than any source's finding. Models are good at proposing candidates from text. Reasoners and constraint languages are good at rejecting the proposals that do not hold. Generate and verify, where the verifier is a program with formal semantics.

Sun and colleagues propose a different division, and theirs follows their own measurement more closely than mine does: the entities near the roots move into the model's weights, while the entities near the leaves stay in the tree.

The best implementation of the guarded pattern in this corpus is ELOT, and it is worth describing because it is a template. ELOT is a literate ontology-engineering environment, where one plain-text notebook is both the ontology source and its documentation. Its optional model integration lets a model inspect resources, search labels, lint, run queries, run consistency, unsatisfiability and explanation checks, mint policy-compliant identifiers, and edit the files. And the mutation surface is deliberately guarded: file writes are project-scoped, disabled by default, confirmation-gated, and revalidated with rollback. Its documentation is honest about the limit: the automatic validation checks lint and OWL parsing — OWL being the Web Ontology Language from lecture five — not semantic consistency, so a separate consistency check is still required.

Two small details are what make guarded mean something rather than sound reassuring. A newly minted identifier cannot be used as the subject of an axiom in the same batch, so inserting a term and then saying something about it take two separate calls — the tool will not let a model do both in one motion. And the identifier policy holds that labels, not identifiers, should carry human-readable meaning, which is lecture seven's rule surviving intact into a model-assisted workflow. The project is also candid about itself in a way I would want from anything I depended on: its documentation says out loud that the long-form manual is under construction, that several manual files are stubs or drafts and may be inaccurate, and which documents are the reliable ones. On how widely it is used, the project claims scores of ontology projects — that is its own account of itself, and I have no independent count.

Question three: can a model use an ontology? Here I would say the answer is strongest, and that ranking of the three questions is my reading of the evidence rather than a finding any source states. It is where lecture nine ended. An agent that can only invoke named actions with typed parameters, validation rules, permission checks and audit records is a governable system. One with raw data access is not. The ontology becomes the interface through which a model is allowed to touch the world, which is Gruber's definition from lecture four arriving somewhere he could not have predicted.

There is a fourth question hiding behind those three, and it is the one I find most interesting.

If a language model can answer questions about a domain without an ontology, what exactly was the ontology for?

The honest answer is that it was never only for answering questions. Go back to lecture four. The word entered computer science through a programme about sharing, not about reasoning. The artifact exists so that two parties who share nothing else can agree what a term means, and can check that they are using it consistently.

A language model does not solve that problem. It can tell you what "active customer" usually means. It cannot make your finance department and your sales department agree what it means here, and it cannot hold them to the agreement afterwards. Keet puts the point sharply: it does not follow that the humans in the project have reached consensus just because a model said so. That is a governance function, and it needs an artifact that people can point at, argue about, sign off, version, and cite.

So my reading is that the question-answering use of ontologies is the part most exposed to substitution, and the agreement-and-audit use is the part that is not exposed at all. Which happens to be the original use.

The complementary pattern is retrieval grounded in structure: rather than handing a model a pile of documents and hoping, you give it a graph and let it traverse. The ontology-grounded retrieval work states the gap in its own terms: existing retrieval-augmented models offer improvements but fail to account for structured domain knowledge, whereas ontologies, which conceptually organize domain knowledge by defining entities and their interrelationships, offer a structured representation to address it. It reports a twenty-seven per cent gain in fact-based reasoning accuracy, and thirty per cent faster attribution of responses to context. The second number is the one that matters here, because an answer that came from these three linked records is auditable and a similarity score over an embedding is not.

The traffic runs the other way as well: the same literature notes that language models enable ontology extraction from both structured and unstructured data. Which is question two again, wearing different clothes.

I should also name the failure mode I expect to become common.

A team uses a model to generate an ontology from their documentation. Hundreds of classes, sensible hierarchy, plausible relations, generated in an afternoon rather than a year. It parses. It lints. Everyone is delighted.

And nothing in that process asked whether the distinctions are the ones the organisation actually needs, whether two departments agree with them, or whether anyone will maintain them. The model produced a plausible conceptualization, which is exactly what it is good at. What it could not produce is a shared one, and "shared" is the word lecture four spent its time on, because sharing is a social fact rather than a text-generation problem.

The correct use of the same capability is narrower and genuinely valuable. Use the model to draft candidates, then run them through the humans who have to live with them and the reasoner that has to check them. The verification is the part that cannot be automated away, and treating the draft as the deliverable is how you end up with a model of the business nobody in the business agreed to.

All of which changes the cost of this work rather than the need for it. The expensive part used to be extraction and drafting, and that is getting cheap. The expensive part is now, and always was, agreement.

So, a verdict, since that is what a last lecture owes you. It is mine, not a rule any source states.

Build one when three things hold together. When the domain is bounded and somebody is accountable for what the terms mean. When wrong answers are expensive enough to justify auditability, meaning regulation, safety, money, or law. And when more than one system or institution has to agree, because that is the problem the artifact was invented to solve.

Do not build one when the domain is unbounded and nobody is paid to curate it. When the incentive audit from lecture eight comes back badly, because the people entering the data gain nothing from accuracy. When a search index would answer the actual questions. Or when what you want is a graph database, in which case build a graph database and do not dress it in a word that promises semantics you are not implementing.

And whatever you build, know which sense of the word you are using. That is what these ten lectures have really been about. A branch of philosophy that asked what exists. A coinage in sixteen oh six, and Wolff's demonstrative method in seventeen thirty that tried to make it a science. Quine's move that turned it into a property of theories. Gruber's definition that turned it into an interface between programs. A stack of standards built for a web of strangers that largely did not arrive. And an operational layer inside a company, installed in institutions that decide who gets stopped on a Tuesday. The word travelled a long way, and it kept its old authority the whole distance.

So, the claim to keep.

Once an ontology drives actions inside an institution, its categories stop describing the world and start producing it. Everything in lecture eight becomes a legal question.