A first ontology often feels fine for a long time. Classes accumulate. Individuals get typed. A disjoint axiom is added in a later session, after something has already been asserted to be both of the things you just declared cannot overlap. The file still opens. The hierarchy still looks tidy in the asserted view. Then someone starts a reasoner, a class turns red, or an individual is inferred into a class you never intended, and the editor offers an explanation that only helps if you already know what you are looking at.
The file opened is not the same as the file is consistent. Opening is a syntax event. Consistency is a logical one. If you have never watched a reasoner report a clash on a file you can read in a single sitting, the first real inconsistency in a project file is a poor place to learn the difference.
The First Consistent Ontology Hour (for Protégé) is a one-hour working path in Protégé: open a small consistent ontology, run the reasoner, then open a labeled teaching file that contains a deliberate clash so you can see what an inconsistency looks like and how you clear it. It is written for Protégé Desktop 5.6.9, the stable release of 7 March 2026. The OWL and Turtle files are ordinary OWL 2 files and also open in other OWL editors. The kit does not include the Protégé application or a reasoner binary. You obtain those from official project sources and start the reasoner in your own copy of Protégé. That is the workflow the kit is for.
What problem does a first reasoner hour actually solve?
Four problems sit under that late, unpleasant surprise, and they are worth naming before you open either file.
The first is a first ontology that grows for weeks before anyone runs a reasoner. The longer the gap, the harder the explanation is to read, because the clash may rest on a handful of axioms chosen on different days, for different reasons, none of which look suspicious in isolation.
The second is disjointness added late, after individuals have already been typed in a contradictory way. Disjointness is often the right axiom. It is also the axiom that makes a loose type assertion suddenly expensive. If you add it at the end of a long session, you find out about the contradiction at the worst possible time.
The third is that there is no small, known-good file to compare against when the reasoner reports a problem. A large, messy project file is a difficult teaching aid. You want a graph you can hold in your head: a few classes, a few properties, a few individuals, and one disjoint axiom you already understand.
The fourth is a teaching need for a clash you can inspect and undo without damaging a real project file. You should not have to invent a first ontology in order to practice the check, and you should not have to risk a client’s file to see what an inconsistency looks like.
A fifth, quieter confusion sits under all four: uncertainty about the difference between “the file opened” and “the file is consistent.” This hour is built to make that difference visible.
Why check early, and against a known-good example?
The useful habit here is older than OWL, and it has the same shape in three different crafts.
Luca Pacioli, in his 1494 treatise on bookkeeping, described double-entry as a system that has to balance. A ledger that can be opened is not yet a ledger you can trust. The check is not a ceremony at the end of the year. It is how you know the books still mean what you think they mean.
Euclid’s Elements made a related demand of a formal system: if two statements cannot both be true, the system will not quietly absorb the contradiction. It will fail in a way you can trace back to the axioms. The skill is not “avoid all errors.” The skill is to read a failure back to the statement you did not mean.
Navigators running a long voyage learned a third version of the same rule. Dead reckoning will carry you for a while. A noon sight, taken regularly, tells you whether the reckoning has drifted. You do not wait until the scheduled landfall to find out. You check after each small stretch of sailing, while a correction is still cheap.
A first ontology is in the same position. Run the reasoner after each small change, not once at the end of a long editing session. Keep a small, known-good file around so that, when a later file goes red, you still remember what a clean inferred hierarchy looks like.
What, exactly, is in the two files?
The kit ships a 6-page guide, two OWL files with Turtle copies of the same graphs, and a README. The guide walks the hour itself, what the two files contain, how to clear the teaching clash, and how to start your own file afterwards.
The consistent file, Northshore-Field-Station-consistent.owl, is the starter. It has four classes, three properties, four individuals, one disjoint axiom, and three existential restrictions. The classes are Site, Instrument, Person, and Observation, all under owl:Thing. The disjoint axiom says that Instrument and Person do not overlap. The object properties are observedAt (Observation to Site), usedInstrument (Observation to Instrument), and recordedBy (Observation to Person). The existential, or “some,” restrictions say that every Observation has some site, some instrument, and some recorder. These are the “some” form, not the “only” form — “an observation has some instrument,” not “an observation has only instruments,” which is the restriction that quietly surprises people later. The individuals are HarborJetty (a Site), Anemometer-A1 (an Instrument), LeaMarin (a Person), and Observation-2026-11-01 (an Observation), with the three property assertions filled in.
The teaching file, Northshore-Field-Station-INCONSISTENT-teaching.owl, is the same ontology plus one intentional clash, and it is labeled for practice only. The intended clash is that Anemometer-A1 is typed as both Instrument and Person, while those two classes are disjoint. Turtle copies of both graphs are included if you prefer to read or import that syntax.
The domain is fictional: Northshore Field Station, a made-up site with a harbor jetty, an anemometer, an observer named Lea Marin, and one observation on 1 November 2026. It is a teaching story, not a scientific data set and not a claim about any real station. The ontology IRI is https://organa.agency/examples/northshore-field-station. That is an example IRI for this kit, not a live lookup service. When you start your own ontology, choose an IRI you actually control.
The OWL files were parsed as RDF/XML and Turtle with rdflib when the kit was built, and a structural check confirms which file contains the clash. That check is not a substitute for running a reasoner in Protégé. You run the reasoner in your copy. That is the point of the hour.
What does the hour itself look like?
Install or open Protégé Desktop 5.6.9. File, then Open, and choose the consistent .owl file, or the .ttl copy. In the Entities tab, open the class hierarchy and confirm the four classes. Open the object properties and confirm the three properties and their domains and ranges. Open Individuals and select Observation-2026-11-01. You should see the three assertions: observed at the jetty, used the anemometer, recorded by Lea Marin.
Start the reasoner you have installed. In Protégé 5.6.9 this is the Reasoner menu: choose a reasoner — HermiT is the usual choice when it is installed with Protégé — then Reasoner, then Start reasoner. After it finishes, look at the inferred class hierarchy. The four classes should remain satisfiable. Observation should not have collapsed to owl:Nothing. The individuals should still be in the classes you asserted. Then stop the reasoner before you switch files, so you are not looking at stale inferences.
If the consistent file ever comes up red in your copy of Protégé, stop and check that you opened the file named consistent, and that no merge or import pulled in the teaching file by mistake. The consistent file was written not to contain the clash.
Next, open the labeled teaching file in a new Protégé window, or close the consistent file first. This file is labeled inconsistent on purpose. Do not use it as the starter for a real project. Start the reasoner the same way. Protégé will report that the ontology is inconsistent, or you will see unsatisfiable classes, often coloured and equivalent to owl:Nothing in the inferred hierarchy. Use the reasoner’s explanation — in current Protégé this is offered from the inconsistent-class or reasoning-error indicator, the question-mark or Explain controls on the unsatisfiable class. You should be able to trace the clash to three axioms together: Instrument and Person are disjoint; Anemometer-A1 is an Instrument; Anemometer-A1 is also asserted as a Person.
Stop the reasoner. Remove the extra type assertion on Anemometer-A1 — the one that types it as a Person — or, if you are practising the other repair, reconsider the disjoint axiom. In this teaching story, the extra type is the mistake. Start the reasoner again. The file should now behave like the consistent starter.
In plain language, you told the reasoner that nothing is both an instrument and a person, and then you said the anemometer is both. The reasoner is doing what those axioms ask. The useful skill is to read the explanation back to the axioms, rather than turning the reasoner off. A repair rule you can reuse: write down the explanation’s axioms in a list, and ask which axiom you did not mean. In this file, you did not mean “the anemometer is a person.” Keep the disjoint axiom — it is doing real work — and retract the bad type. In your own ontology the mistaken axiom will differ, but the method is the same.
What should you do after the hour?
File, then New, in Protégé. Set an IRI you control, and save. Add a handful of classes you can define in a sentence each. Add disjoint axioms only where two classes truly cannot share an individual. Add a few object properties with domain and range. Prefer “some” restrictions when you mean “must have at least one.” Create a few individuals and assert only what you know. Start the reasoner after each small change, not once at the end of a long editing session. Keep the consistent file as the known-good comparison whenever you want to look at a clean, small graph again.
How is this different from the Ontology Starter Kit?
The Ontology Starter Kit is a layered Obsidian vault plus a worked ontology in notes, Turtle, and CSV. This kit is a Protégé-hour: two OWL files and a reasoner path. The example domain is a fictional field station, not a home library, and the files are OWL, not that kit’s TTL. They can sit side by side. Neither replaces the other.
Protégé is a trademark of its trademark owner (the Protégé project / Stanford University, as used for the official editor). This is an independent tool for people who use Protégé. It is not an official Protégé product, and it does not include the Protégé application or a reasoner binary.
A clash you can afford to inspect
You get two files that already demonstrate the difference this hour is about, plus a guide that walks the exact sequence: consistent file, reasoner, teaching clash, clear the clash, then your own file. You do not have to invent a first ontology in order to practice the check, and you do not have to risk a real project file to see what an inconsistency looks like.
Open the consistent file, run your reasoner, then open the labeled teaching file and clear the clash. Get the First Consistent Ontology Hour (for Protégé) and make the reasoner part of the editing loop, not a surprise at the end of it.
The First Consistent Ontology Hour is listed on our Tools for Protégé page, alongside the rest of the tools in that line. You can browse every Organa Obscura tool on the Products page.
Leave a Reply