Informatics, Frame Analysis, and Ontologies: Formalising "What's Going On"

Informatics"Informatics" itself doesn't have one fixed, universally agreed scope — some institutions use it as a broader synonym for computer science generally (the University of Edinburgh's School of Informatics is the best-known example), others use it more narrowly for the study of information as a thing in its own right: how it's represented, structured, stored, retrieved, and transformed, as distinct from the study of computation for its own sake. What every version of the term shares is the object of study: not the machine, and not the algorithm, but the information — which immediately raises Goffman's question in a new costume. Before you can represent information about a domain at all, something has to have already decided what counts as a "thing" in that domain, what properties it can have, and what relationships between things are even expressible. That decision is a frame. Informatics' distinctive move is to insist the frame get written down, in a form a machine can check for consistency — which is exactly what an ontology is.

What an Ontology Actually Is

TheThe field's standard definition, still the most-cited formulation three decades on, is Gruber's: "an ontology is an explicit specification of a conceptualization" [1]. Unpacked, a conceptualization is the informal, usually unstated way a person or community already carves a domain up into things and relationships — precisely Goffman's frame, restated in knowledge-engineering vocabulary. An ontology is what results from making that carving explicit enough that a program can act on it: a set of classes (the kinds of things that exist — Person, Organisation, Event), properties and relations that connect them (employs, occurredAt, hasAge), and axioms constraining how they can combine (an employs relation only holds between an Organisation and a Person; a Person's hasAge is a non-negative integer). Guarino, Oberle, and Staab's later, more careful account distinguishes the informal conceptualization from its formal specification precisely to make room for the fact that many different formal ontologies can encode the same underlying conceptualization, and the same formal ontology can be read as encoding several different ones depending on who's asking [2] — which is the same slipperiness Goffman's own framework spends a career on, arrived at independently from the machine-representation side.

The payoff for doing this formally, rather than leaving it as an implicit frame, is that a formal ontology is checkable in a way an informal one structurally cannot be. Two people holding incompatible frames can talk past each other indefinitely, each one certain the other is simply wrong, with no shared procedure for resolving it — this is exactly the requirements-disagreement failure mode Frame Analysis for Software describes. Two formal ontologies encoding incompatible conceptualizations can, at minimum, be shown where they disagree: a description-logic reasoner can point at the specific axiom that makes one ontology's Customer a subclass of Person and another's a subclass of Account, which turns an unproductive argument about who's "really" right into a concrete, inspectable design choice either side can evaluate on its merits. This is the technical machinery underneath the W3C's Web Ontology Language (OWL), built on RDF triples (subject–predicate–object statements) and description logic, and it's the same technical lineage that produced the large-scale public knowledge graphs a RAG system can retrieve structured facts from rather than unstructured prose [3].

Two Kinds of Ontology This Site Already Has, Without Calling Them That

YouYou don't need OWL or a description-logic reasoner to be building an ontology — you need one the moment you've committed to a specific set of categories and relations for a domain, however that commitment gets implemented. Two pieces of this site's own material are, structurally, exactly this, in two very different styles:

• A hand-specified, symbolic ontology. This site's symbolic reasoning material describes representing knowledge as "explicit, discrete structures — rules, facts, logical relationships" that a system reasons over via formal inference. That's a working definition of an ontology in miniature, with the classes and relations declared by a person up front, in code a reader can inspect directly.
• An induced, trust-gated ontology. The self-model project's Abstraction component builds its category system the opposite way — inducing general categories from repeated entity/intent pairs at runtime, gated by trust rather than declared in advance by a designer. It's still an ontology in Gruber's sense (an explicit specification the system checks new entities against via categorize(entity)), but the conceptualization it encodes emerges from what the system has actually seen, not from a knowledge engineer's upfront design.

The connectionist side of the same distinction — a large language model's embedding space — is the interesting limit case, and it's worth being precise about why it doesn't fully count as an ontology in Gruber's sense even though it clearly encodes some conceptualization of the world. An embedding space groups related concepts by proximity and supports analogical structure (the well-known king − man + woman ≈ queen pattern), but it does so with no explicit classes, no named relations, and no axioms available for a reasoner to check — the "specification" is millions of real-valued weights, not a statement anyone (human or machine) can read off and verify against a rule. It's a conceptualization without ever being made explicit in Gruber's sense, which is precisely why understanding what a language model actually knows is a genuinely different, harder problem than checking a formal ontology for consistency — there's no axiom to point a debugger at.

Why This Matters Practically

OnceOnce ontologies and frames are recognised as the same underlying move at two different levels of formality, several things this site already covers separately turn out to be one recurring pattern:

• A boundary object — Star and Griesemer's term, covered in Frame Analysis for Software, for a shared artefact "plastic enough to adapt to local needs... yet robust enough to maintain a common identity across sites" — is, in informatics terms, exactly what a shared ontology is trying to be: a formal specification precise enough to check disagreements against, general enough that every team's local frame can still be read into it.
• Checkland's CATWOE Weltanschauung element, covered on the same page, is asking a stakeholder to state their informal conceptualization out loud. A formal ontology is what you get if you then insist that stated conceptualization be specified precisely enough for a machine to check it for internal consistency, rather than left as a paragraph of prose.
• An "ontology mismatch" between two integrated systems — the same field, different Customer class, incompatible axioms — is a formal, checkable instance of exactly the informal frame clash a requirements disagreement already describes. Naming it precisely is what turns "these two teams keep talking past each other" into "here is the specific axiom where their models diverge," which is a bug you can actually go and fix.

The practical discipline this suggests for any system that integrates data, knowledge, or requirements from more than one source: ask explicitly which conceptualization each source is committed to, before assuming a shared vocabulary means a shared ontology. Two systems can use the word "customer" identically and still disagree, invisibly, about whether a cancelled account is still one — and that disagreement will surface as a production bug long before anyone thinks to ask the question Gruber's definition was built to make answerable.

References

1. Gruber, T. R. (1993). "A Translation Approach to Portable Ontology Specifications." Knowledge Acquisition, 5(2), 199-220.
2. Guarino, N., Oberle, D., & Staab, S. (2009). "What Is an Ontology?" In S. Staab & R. Studer (Eds.), Handbook on Ontologies (2nd ed., pp. 1-17). Springer.
3. World Wide Web Consortium. "OWL 2 Web Ontology Language Document Overview." https://www.w3.org/TR/owl2-overview/