3. Quine, and Ontology as a Property of Theories

About 21 minutes spoken, 3,091 words. Plain text for a reader app: 03-quine-ontological-commitment.txt

This is the third of ten talks about ontologies. In the first we separated three senses of the word. In the second we followed the word from Aristotle through Wolff and found that engineering kept the vocabulary but dropped the claim to uniqueness. Today we look at the move that made ontology usable by engineers, and it was made by a man who spent most of his paper explaining why the question, as normally asked, cannot be answered.

The paper is called “On What There Is.” It was published in nineteen forty-eight by Willard Van Orman Quine, and it is short. If you read one primary text from this entire series, read that one.

Quine starts from the problem that had the field stuck. Arguments about what exists do not settle. Worse, they seem to defeat themselves before they begin. Suppose I say Pegasus does not exist. That looks like a plainly true sentence. But look at what I have apparently done. To say Pegasus does not exist, I had to talk about Pegasus. I had to refer to something in order to say it isn’t there. If Pegasus were nothing at all, what was my sentence about? To deny that a thing exists, you seem to have to grant it enough existence to be denied.

A lesser philosopher spends a career there. Quine changes the question instead, and this is the move that matters for us.

He stops asking what exists. He starts asking what a theory says exists.

That’s it. That’s the whole trick, and it’s one of those moves that looks trivial once it’s made and was invisible for two thousand years. Instead of arguing about whether numbers really exist, which nobody can settle, ask a narrower question that actually has an answer. Does this body of statements — this theory, this model, this system — require numbers in order for its statements to come out true?

Quine gives you a procedure for finding out. First, regiment your theory into first-order logic. First-order logic, sometimes called predicate logic, is the standard formal language of “for all” and “there exists,” with variables ranging over things and predicates saying what is true of them. Once your theory is in that form, look at what the variables range over. Whatever must be in that range for your statements to come out true is what your theory is committed to.

The slogan, in Quine’s own words, is short. To be is to be the value of a variable.

You have probably heard it with an extra word in the middle — to be is to be the value of a bound variable. That version is the title of a later paper by George Boolos. It is a fair summary of Quine, and it is not Quine’s sentence, and it’s worth keeping the two apart if you ever go to the text looking for it.

Quine does state the criterion at length, and the long version is the one to keep. A theory, he says, is committed to those and only those entities to which the bound variables of the theory must be capable of referring in order that the affirmations made in the theory be true.

There’s a technical word in that sentence, so let me unpack it, because it’s easy to misread. A bound variable is one that’s governed by a quantifier. If I write “there exists an x such that x is a delayed shipment,” the x is bound by “there exists,” and I have committed my theory to at least one delayed shipment. If instead I write “shipment forty-two is delayed,” I’ve used a name, not a variable. Quine’s answer about names is that they don’t carry commitment by themselves, because a name can be paraphrased into a description. That’s why he insists on the regimentation step. You rewrite until the commitments sit in the quantifiers, where you can see them, instead of in the vocabulary, where you can’t.

Now, why does this matter to somebody who builds systems?

Because it converts an unanswerable philosophical question into a code review.

Let me do a worked example. Take an ordinary employee database. Table Employee, with columns for name, hire date, and manager ID, where manager ID points to another row in Employee. Apply Quine’s criterion. What must exist for the statements this schema can make to be true? Employees must exist. A managing relation between employees must exist. That’s the ontology of your database. Two kinds of thing: employees, and the manager-of relation.

Now watch what you cannot say. Someone comes to you and asks: which teams had more than thirty percent turnover last quarter? You go looking, and there’s no way to answer, because your schema doesn’t quantify over teams. Teams aren’t in the range of any variable. It isn’t that the data is missing. It’s that the model has no place for the data to go. You’d have to change the theory, not the contents.

Or a subtler one. Someone asks: who was Melissa’s manager in March? Your schema has a manager ID on the employee row, so it’s committed to employees having a manager, singular, now. It is not committed to a managing relation with a start date and an end date. Time isn’t in the ontology. To answer, you don’t add a column. You add a new kind of thing to the world your system believes in — a management assignment, which is an entity in its own right, with a manager, a report, and an interval.

That’s Quine’s criterion doing engineering work. Read the quantifiers, find the commitments, and you know in advance which questions your system will never be able to answer, before anyone asks them.

This is, incidentally, the technique behind competency questions, which we’ll meet properly in lecture seven. A competency question is a question your ontology must be able to answer, written down before you model anything. It’s Quine’s criterion run backwards: start from the questions, derive the commitments they require, then build a model that has them.

Now I want to spend a few minutes on what the criterion deliberately does not do, because this is where people over-read it.

The criterion is completely silent about truth, and Quine says so himself. Asked how we are to adjudicate among rival ontologies, he answers flatly that the semantical formula does not provide it. So the criterion tells you what a theory is committed to. It doesn’t tell you whether the theory is any good. It doesn’t tell you whether the things it commits to are really out there. It’s a test of what a theory claims. It is not a test of whether the claim is right.

That silence has a consequence I want you to sit with. Quine goes as far as observing that disagreement in ontology involves basic disagreement in conceptual schemes, while the schemes still converge well enough in practice. The step I’m about to take is mine rather than his.

Two teams can build models of the same domain, both correct, both useful, both internally consistent, and commit to different things. A logistics company might commit to shipments, where a shipment has a route. Their partner might commit to legs, where a leg has an origin and a destination, and a shipment is just a name for a sequence of legs. Neither team is wrong. They regimented differently, because they answer different questions. One of them cares about customer promises. The other cares about vehicle utilisation.

Now those two companies try to exchange data, and somebody has to write a mapping. There’s a strong temptation to treat that mapping as remedial work — as though one side blundered, and if only everyone had modelled properly the mapping would be unnecessary. I think that’s the wrong frame, and Quine is the reason. Commitment is relative to a theory, and different theories serving different purposes will commit differently. The mapping isn’t cleanup. It’s a permanent, first-class engineering artifact.

That’s why ontology alignment — sometimes called ontology matching — is its own research field, with its own conferences, its own evaluation initiative running annual benchmarks, and its own tool ecosystem. There are systems built purely to match two ontologies and repair the inconsistencies that result: AgreementMakerLight for efficient automated matching, LogMap for large-scale matching with reasoning and inconsistency repair. There’s even a standard format, the Alignment Application Programming Interface, usually just called the Alignment API, whose job is to represent correspondences between ontologies so they can be shared. None of that infrastructure would need to exist if there were one right way to carve up a domain.

I want to be more precise about why it exists. The literature that studies this frames matching as a response to semantic heterogeneity — the condition where different parties adopt different ontologies, in systems that are open or evolving. Those two words carry the argument. Open, and the gloss here is mine, means parties turn up who were never consulted about your model. Evolving means the model everyone agreed on last year is not the model running now. If neither of those held — if you controlled every system in the picture and none of them ever changed — you could decree one model and enforce it. Nobody has that.

And there is a sentence from that literature I want you to carry, because it is the part people find hardest to accept. Ontologies do not remove heterogeneity by themselves. Independently adopted models can move the mismatch to a higher semantic level, where it still has to be matched explicitly. Read that slowly. Writing formal models does not dissolve the disagreement. It relocates it upward. Two teams who both did the work have not thereby agreed; they have made their disagreement precise, which is progress, and is not the same as the disagreement going away. My own gloss again: that is what Quine’s silence predicts. The criterion was never going to adjudicate, so the artifact you build instead of adjudication is the mapping.

Which raises the question of what a mapping actually is. It’s a set of correspondences between semantically related entities in two different ontologies — entity to entity, not file to file. And it earns its keep through what it lets you do afterwards: merge the two ontologies into one, answer queries that run across both, translate data from one into the other, and navigate from one vocabulary into another across the semantic web, which is lecture five’s subject. Four downstream jobs, one artifact. That is not the profile of remedial cleanup.

The Alignment API is shaped to match. It’s a Java library and implementation for expressing and sharing alignments, built on an extensible alignment format, and its five main interfaces are worth hearing in order, because the naming tells you the shape of the thing. Ontology networks. Alignment. Cell. Relation. Evaluator. Networks of ontologies at the top; an alignment holding between two of them; cells inside the alignment; a relation carried by a cell; and an evaluator, because alignments get scored. The package will compare two alignments using measures such as precision and recall. My reading, not the project’s: that tells you a mapping is the kind of object you can be partly right about. It’s a claim with a score, not a clerical translation table. The same package will also generate transformations or axioms out of an alignment, which is the moment a mapping stops being documentation and becomes something that runs.

One caution the project states emphatically about itself, and I’ll pass it on, because it gets misreported. The Alignment API is not an ontology matcher. It stores, finds, thresholds, hardens, compares and shares alignments. It does not compute them. The trivial matchers bundled with it are examples, not serious baselines — so an evaluation claiming a result against “the Alignment API” has not compared anything; a real comparison names actual matching systems. Representing a mapping and computing one are different jobs, and only the first has a settled answer.

Let me trace the line forward to the machinery.

There’s a formal construction with the same shape as Quine’s, and it sits directly under the modern tooling. Guarino, Oberle and Staab, in their two thousand and nine chapter, define an ontological commitment as a total function. It maps each symbol in your vocabulary to one of two things: an element of the domain, or an intensional relation. Those assignments then fix the set of intended models — the interpretations your vocabulary is meant to pick out. The underlying object, what they call a conceptualization, is an intensional relational structure rather than an ordinary model.

I want to be careful about what that resemblance is, because it’s easy to oversell. Their paper never mentions Quine. They don’t cite him. So read it as two constructions of the same shape, not as a lineage anyone has traced.

And a structure of that shape is what OWL, the Web Ontology Language, implements. OWL’s meaning is fixed by a formal semantics, defined over interpretations: concepts are read as sets of individuals, roles as sets of pairs, and an axiom either holds in an interpretation or doesn’t. When an OWL reasoner tells you your ontology is inconsistent, it’s telling you that no interpretation satisfies all your axioms at once. You’ve committed to a world that can’t exist. That’s Quine’s question, asked by a program, in a few milliseconds.

So the chain runs like this. Aristotle asks what kinds of things there are. Wolff tries to derive the answer deductively and claims it’s the only answer. Quine says stop, ask what a theory commits to, and hands you a procedure. The formal treatments arrive at the same shape independently. And a reasoner runs it over your file.

Two things the criterion is often made to say, and doesn’t.

The first is that ontology is arbitrary. You’ll meet someone who argues that since commitment is relative to a theory, and theories are chosen, any model is as good as any other. That doesn’t follow. Relativity of commitment doesn’t make all theories equal. It means the comparison happens at the level of the theory, on grounds of what it explains and predicts and answers, rather than by staring harder at the world and hoping the categories announce themselves.

The second is subtler, and it trips people. What a theory is committed to is not the same as what a theory is about. A theory of chemistry is about molecules. But if it uses numbers to state concentrations, and it quantifies over numbers, then it’s committed to numbers as well. Those commitments come along for the ride, and they’re the ones people forget.

The engineering version of that is worth stating plainly. Every modelling framework you adopt drags in commitments you didn’t choose. Adopt an upper ontology, and you’ve committed to its top-level distinctions, including the ones you’ll never use and the ones you’d argue with if anyone asked. Adopt a relational database and you’ve committed to a closed world, where the absence of a fact means the fact is false. Description logics, the family OWL is built on, don’t generally assume that. Absence there means unknown, not false. That difference is lecture six, and it’s the single biggest source of surprise for engineers arriving from databases. None of these is wrong. They’re commitments made by the framework rather than by you, and knowing they’re there is the difference between a model you understand and a model you inherited.

Here’s a test I use on top of the criterion. This one is mine, not Quine’s, so weigh it accordingly. Somebody proposes a class called Engagement. Or Initiative. Or Opportunity. Fine. Ask: when are two engagements the same engagement? If your team can’t answer that in one sentence, the class has no identity conditions, and it will cause trouble forever. You’ll get duplicates you can’t detect, merges you can’t justify, and counts that two departments compute differently and both defend. Ask it in every design review.

That test is also why OWL two added a mechanism for keys, and why the biomedical ontologies are so exacting about identifier space and about keeping the meaning of a term stable once it’s published. From outside, that looks like bureaucracy. It’s an identity condition, operationalised.

There’s a second use of the criterion, and it’s the one that turns it from a diagnostic into a design lever. Commitment is relative to how you choose to regiment, and you have choices. The same information can be modelled with different commitments, and choosing between them is real design work.

Take a common one. Does your system have a Meeting class? Or does it have People, Times, and an attendance relation, with “meeting” being a way of talking about a cluster of those? Both can represent the same facts. But the first commits you to meetings as entities, which means a meeting can have properties, can be linked to, can be referenced from a decision record, and can survive when the attendees change. The second doesn’t, and querying for what happened in that meeting becomes a pattern-matching exercise.

This is what people mean by reification, when the term gets thrown around. Reification is the act of promoting something that was implicit in a relationship into a thing in its own right. It’s exactly Quine’s regimentation choice, made deliberately — which is what we did earlier with the management assignment, except that in most systems it arrives late, under pressure, in a migration. Quine gives you the vocabulary to make that decision in advance instead.

And it changes how you defend a modelling choice. You don’t defend it by claiming it’s how the domain really is. You defend it by showing which questions it answers, at what cost, compared with the alternative you rejected. That’s a review you can actually run.

So, the claim to keep from this lecture.

To be is to be the value of a variable. Stop asking what exists in your domain, and ask what your model must quantify over for its statements to come out true. That question has an answer, you can read it off the model, and it tells you in advance which questions your system will never answer.

Next time, we jump forward two thousand years from Aristotle and about forty from Quine, to the moment computer science needed this word and went looking for it — and to the most expensive experiment the field has ever run.