Ontology or Language Model

Hardly any talk on digital twins of legislation ends without the same question: why build an ontology at all when a language model can simply read the statute? The question is legitimate, and it deserves a more precise answer than yes or no. This article compares the two methods for Law as Code against the criteria that matter in administrative law and shows which roles the language model, the ontology, and Austria's federal Legal Information System play in our architecture.

Two paths, the same statute

Anyone who wants to turn a statute into software has two fundamentally different tools today. The older path is symbolic: concepts, rules, and parameters are modeled explicitly, and a program applies them deterministically. In legal informatics this tradition goes back to the 1980s, when Sergot et al. (1986) formulated the British Nationality Act as a logic program, and has produced legal ontologies, rule languages, and domain-specific programming languages. The younger path is statistical: a large language model has seen millions of texts, statutes, commentaries, and rulings among them, and generates the most probable continuation in response to a question. Since ChatGPT, this path has been within reach of every case worker with a browser, and that is exactly where the question comes from.

A fair comparison needs criteria, and in administrative law they are stricter than in most other fields of application. A result must be correct, not probably correct. It must be reproducible: same input, same result, today and a year from now. It must be traceable to the provision it follows from, because citizens are entitled to contest it. And it must keep pace with every amendment. Two practical criteria come on top: what does building it cost, and who can read and verify the result?

What a language model does with a statute

A language model reads prose considerably better than the rule-based text tools that came before it. It recognizes the actors in a section, finds thresholds, proposes a structure, and, on request, formulates an understandable explanation. For every task in which text is turned into structure or structure is translated back into text, it is a gain, and that is exactly where we use it.

For applying the statute to an individual case, it is not sufficient on its own, for four reasons that have nothing to do with the size of the model.

• It computes probabilities, not legal consequences. The same question can be answered differently when run several times. Blair-Stanek and Van Durme have documented this instability for legal questions systematically (ICAIL 2025, arXiv:2502.05196). A jurist from our ongoing interview study with experts from legislatures, academia, the software industry, and notarial practice put the consequence in a nutshell: he could not settle for "probably right"; he needed to know whether the answer was yes or no.
• It has no trace back to the wording. A language model can name a section number, but it does not derive its result from it. References are missing, imprecise, or invented. For an administrative decision that must state its reasons, that is not a cosmetic flaw but a disqualifying one.
• Its knowledge is frozen. The model knows what was on the web at the time of its training, not what is in force in the provincial law gazette today. Even when it is handed the current text, it is not the text that decides which passage gets attention but the statistical weighting of the model.
• Plausibility replaces correctness. The answers are well written, and that is precisely what makes them risky: an error inside a fluent explanation is harder to spot than an error in a table.

An example from our use case makes this concrete. Under section 43 of the Upper Austrian Tourism Act 2018, a business in contribution group 1 located in a municipality of class C pays 0.40 percent of its assessable revenue; on 500,000 euros that is 2,000 euros. A language model without a connection to a model of the statute easily reaches for the rate of the neighboring class B, 0.45 percent, and returns 2,250 euros, complete with a convincing-sounding derivation. The error is small, but it repeats across roughly 29,000 liable businesses, each time in a different direction, and nobody can trace it. In the fourth article of this series we therefore classified the general knowledge of a language model as an informative source: useful for understanding a use case and for plausibility checks on results, unsuitable as the justification for a rule.

What an ontology delivers and what it does not

By Gruber's classic definition (1993), an ontology is a formal, explicit specification of a shared conceptualization. Less abstractly: it lays down what the statute talks about and how the concepts relate to each other, precisely enough that a machine can compute with it and a person can check it. For the tourism levy, these are classes such as tourism business, contribution group, tourism municipality, and municipality class, properties such as assessable revenue, and relations such as "is located in" or "belongs to". Every element carries a unique identifier and points to the provision that defines it.

What the ontology delivers with this is exactly what the language model lacks. The meaning of a term is fixed and identical for everyone who uses the twin: for the specialist application of the tax authority as much as for the accounting software of a hotel. An example from our interviews shows why this is necessary: how long someone counts as a "child" is regulated differently in tax law than in criminal law. A language model picks the meaning by contextual probability; an ontology makes the context explicit and leaves no room for a second reading. Add to this automatic consistency checking, versioning, and the ability to connect to registers, business software, and other ontologies.

Equally clear is what an ontology does not do. It does not compute; for that, the configuration and logic layers are needed, which we described in the second article of this series. It does not read prose; someone has to extract the concepts from the text, and so far that has been the most expensive step of every formalization. And it cannot make indeterminate legal terms more determinate than the legislature intended; where discretion begins, the ontology ends.

The obvious move would be to reuse existing legal ontologies. FOLaw, LRI-Core, and LKIF-Core are carefully built vocabularies, and LegalRuleML is an OASIS standard for normative rules. But they were designed for the way jurists and their expert systems work: analysis, classification, retrieval, argumentation. They are not optimized for the deterministic application of administrative law under the rule of law. That is why we are building our own hierarchically growing ontology, scaling from a single statute through related subject areas to entire fields of law, and why we are examining, in a systematic mapping study of legal ontologies from 2017 to 2025 that continues the work of Rodrigues et al. (2019), which existing building blocks can be integrated.

The Legal Information System as knowledge base

Both methods need a reliable source, and for Austrian law that is the federal Legal Information System (RIS). It provides federal and provincial law in current and historical versions and labels documents with the European Legislation Identifier (ELI), which makes every provision uniquely and permanently addressable.

For the twin of legislation, the RIS is the text layer. The wording is not copied and adapted but referenced: every class in the ontology, every percentage in the configuration, and every step of the logic points via ELI to the passage in the RIS from which it follows. When an amendment appears there, that is the trigger to update the twin, and the version relationship between text and model remains visible at all times. This is the core of the twin idea: the model stays synchronized with its original, and anyone can verify it.

For a language model, the RIS is the right source as well, but in a different role. A model that retrieves the current text at run time knows the wording in force, yet still processes it probabilistically. It reads the statute; it does not apply it. That distinction is the core of the whole comparison.

Both, but in separate roles

I therefore consider the question "ontology or language model" to be wrongly posed. The productive question is who takes on which task. In the pipeline we are developing for the path from statutory text to twin, the roles are divided as follows:

During construction, the language model supplies proposals: a segmentation of the statute into functionalities, candidates for ontology classes, the list of parameters, a draft of the calculation logic together with test cases. Every proposal passes through the hands of people with legal and technical expertise. That is not a precaution that disappears with better models; it is the point at which accountability is created.

During application, the language model is the interface, not the core. For the tourism levy twin we have additionally published the interface via the Model Context Protocol. An assistant accepts the question in natural language, hands municipality, business activity, and revenue to the twin, receives the levy together with its log, and formulates the explanation from it. The model writes what the twin has computed, with the references the twin has supplied. The source code is openly available on GitHub.

The language model may propose and explain. Only the model that traces every step back to the wording may decide.

This division of labor has a further advantage that is often overlooked: it makes the ontology affordable. The most expensive step of the symbolic method has always been knowledge acquisition. When the language model delivers the first draft and people only verify, the effort drops considerably without losing the guarantees of the deterministic model. Preliminary prototypes indicate measurable reductions in development effort and update latency (ESWC 2025); the precise quantification is the subject of the ongoing evaluation.

The next step

We presented the ontology approach in June at the PhD Symposium of the Extended Semantic Web Conference (ESWC 2025) in Portorož; together with Christoph Schütz, we will present the reference architecture with its interface for language models at the Developers Workshop of SEMANTiCS 2025 in Vienna from September 3 to 5. Both papers can be found under Publications. What a digital twin of legislation is meant to deliver overall is described on the page Digital Twin of Legislation. Anyone in an administration or a company currently examining whether a language model can "simply read" a provision is invited to walk through that question with us along the criteria in this article.