Ontologies

A ten-lecture audio course and a searchable knowledge base, built from the awesome-ontology list and a research pass that filled the gaps it left.

• The lectures — ten talks, about 4.2 hours, each with a plain-text file a reader app can fetch.
• Synthesis — the argument of the whole corpus in one essay.
• Notes — 181 notes on tools, languages, vocabularies, and arguments.
• Glossary — every term in one alphabetical list.

What is here that is not in the source list

The original list covers standards, tooling, reasoners, and vocabularies well. It has nothing on where the idea came from, the criticism of it, or the operational sense Palantir uses. Thirteen notes were added for that: the history from Aristotle to Wolff, Quine on ontological commitment, Gruber’s definition, Cyc, the 2001 Semantic Web vision and what became of it, the knowledge graph turn, Doctorow, Shirky, Bowker and Star, Palantir’s Ontology and the case against it, and the argument about whether large language models replace any of this.

Search is in the top bar, or press s.

Source

Notes, transcripts, and the generator for this site live in matthiasdebernardini/ontology-notes. Notes are CC BY 4.0, code is MIT.

The lectures

Ten talks, 36,106 words, about 4.2 hours. Written to be listened to, not read: no headings, no bullets, no code, no URLs spoken aloud. Each one opens by saying where it sits in the arc, and ends by stating the single claim it wants you to keep.

Listening on a phone

Each lecture has a plain-text file. Paste its link into a reader app that fetches URLs, or open the lecture page and read it there.

The course plan gives the beats and the source notes behind each lecture. Narration setup covers the voice.

1. Three Things People Mean by “Ontology”

About 22 minutes spoken, 3,143 words. Plain text for a reader app: 01-three-things-people-mean.txt

This is the first of ten talks about ontologies. Over the series we’ll cover where the idea came from, how the machinery works, how you’d build one, the arguments against the whole enterprise, and what Palantir means when it uses the word, which is not quite what anyone else means. Today is groundwork. By the end of this lecture you should be able to hear the word “ontology” in a sentence and know which of three completely different things the speaker has in mind.

Let me start with the problem this lecture exists to solve.

Suppose you’re at a conference and three people use the word “ontology” in the same hour. The first is a philosopher, and she’s talking about whether numbers exist. The second is a biologist, and he’s talking about a file he downloaded that has forty thousand terms for gene functions in it. The third works in enterprise software, and she’s talking about a layer in a platform that lets a warehouse manager reassign a shipment. All three are using the word correctly. None of them is talking about the same thing. And if you assume they are, you will spend years slightly confused, because the confusion is subtle enough to survive.

So. Three senses.

The first sense is the philosophical discipline. Ontology, in this sense, is the branch of philosophy that asks what exists, and more precisely, what kinds of things can exist and what relations they can stand in. Aristotle called it first philosophy, and he defined it in Book Four of the Metaphysics as the study of being qua being. That phrase, being qua being, is worth pausing on, because it’s doing real work. Physics studies things insofar as they move. Biology studies things insofar as they’re alive. Ontology studies things insofar as they are, full stop. It’s after the attributes something has purely by virtue of existing, rather than by virtue of being a particular kind of thing.

The second sense is a specific theory of what exists. When a philosopher says “Quine’s ontology is austere,” she doesn’t mean Quine had a discipline. She means Quine had a position, a list, a set of commitments about what’s real. In this sense ontology is a countable noun. You can have one. You can compare two. You can argue that yours is better. And you’ll notice that this is already much closer to how engineers talk. When someone says “the financial industry ontology,” they’re using the word the way a philosopher uses it in “Quine’s ontology” — a particular account, not the discipline that produces accounts.

The third sense is the artifact. A file. Something you can download, open in an editor, run a program over, and check for contradictions. This is the sense that concerns us for most of this series, and it’s the youngest by about two thousand three hundred years.

That third sense has a birthday, more or less, and it has a definition that almost everyone in the field quotes. The year is nineteen ninety-three. Tom Gruber was working inside a project his own acknowledgements call the ARPA, later DARPA, Knowledge Sharing Effort — ARPA being the Advanced Research Projects Agency, renamed the Defense Advanced Research Projects Agency, the American military research funder. And what Gruber wrote, in that context, is that an ontology is, and I quote, “an explicit specification of a conceptualization.”

That sentence has launched about thirty years of argument, so let’s take it apart slowly, because it repays the effort.

Start with “conceptualization.” Gruber borrowed that term from two earlier researchers, Genesereth and Nilsson, and the wording most often quoted is Gruber’s own later restatement of it: the objects, concepts, and other entities that are presumed to exist in some area of interest, and the relationships that hold among them. And they added a line that I think is the single most useful sentence in the whole literature: a conceptualization is an abstract, simplified view of the world that we wish to represent for some purpose. Every knowledge base, every knowledge-based system, is committed to some conceptualization, explicitly or implicitly.

Read that again in your head. Every system is committed to some conceptualization. Explicitly or implicitly. That is the entire argument for doing ontology work, compressed into one sentence. Your software already has an ontology. Every database schema you’ve ever written is a claim about what kinds of things exist in your domain and how they can relate. When you created a table called Customer with a foreign key to Address, you asserted that customers exist, that addresses exist, that a customer has an address, and — by the absence of anything else — that customers do not have, say, relationships to other customers. You made a metaphysical commitment. You just made it in a hurry, over lunch, and you didn’t write down why.

So the question is never whether your system has an ontology. It’s whether the ontology is written down where you can inspect it, argue about it, and check it for contradictions.

Which brings us to the other load-bearing word: “explicit.” Explicit means the commitments are stated, in a form a machine can read, separately from the code that uses them. Not implied by a table layout. Not living in the head of the one engineer who’s been there six years. Written down, in a language with defined meaning, so that a program can take your ontology and derive consequences from it that you didn’t state.

There’s a third word that arrived later. In nineteen ninety-seven, Borst revised Gruber’s definition to read: a formal specification of a shared conceptualization. He added “shared,” and that addition matters more than it looks. It means the conceptualization expresses a consensus between several parties, not one person’s private view. An ontology that only you agree with is a data model with delusions of grandeur. The point of the artifact is that two systems, or two teams, or two institutions that share nothing else can share the vocabulary.

Gruber makes this concrete with an idea I find clarifying. He describes an ontology as an interface specification. It’s the language two agents use to talk to each other about a domain. And here’s the part people miss: an agent that supports the interface is not obliged to store its knowledge that way internally. Your inventory system can keep its data in whatever gruesome legacy format it likes. What the ontology fixes is the terms in which it talks to the outside world.

That single idea — ontology as interface rather than as storage — is the architectural move behind almost everything in this series. It’s why an ontology can sit above a dozen incompatible systems that will never be rewritten. It’s what the Semantic Web tried to do at the scale of the entire web. And it’s what Palantir does inside a single company, which we’ll get to in lecture nine.

Now let me spend a few minutes on what an ontology is not, because the negative space defines the concept better than the positive space does.

An ontology is not a taxonomy. A taxonomy is a hierarchy of terms — this is a kind of that. Taxonomies are useful and they’re one shape an ontology can take, but they’re a special case, not the general one. There’s a whole standard from the World Wide Web Consortium, the W three C, called SKOS, the Simple Knowledge Organization System, built specifically for representing thesauri, classification schemes, and subject headings as concepts with broader and narrower links. And SKOS is scrupulous about this: it explicitly distinguishes its concepts from formal ontology classes. A SKOS concept is a term in a vocabulary that librarians agreed on. An OWL class — OWL being the Web Ontology Language — is a set, with formal semantics, and asserting that one class is a subclass of another has logical consequences a machine can compute. Those are different claims. SKOS knows they’re different. Many people using SKOS do not.

Be precise about what SKOS is doing, because the precision is the lesson. In SKOS, the concepts of a thesaurus are modelled as individuals rather than as classes, and the scheme’s descriptions are facts about those individuals. They are not facts about how the domain itself is arranged. Say that slowly. SKOS records that a group of librarians put this term under that one. It does not record that the world is that shape. And that is deliberate, because the design goal is to let you publish a thesaurus or a classification scheme you already have, in machine-readable form, on the web, without first re-engineering it into formal domain axioms. It carries the labels — preferred, alternative, and hidden, in as many languages as you like — the scheme’s own notation codes, the documentation notes, and mappings between schemes, including close and exact equivalence. That is real work, done properly. What it does not do is much checking: the specification defines relatively few integrity conditions, on purpose. When you need the formal domain axioms, you use OWL alongside it. And here’s the part I find funny. The SKOS model is itself formally defined as an OWL Full ontology. The standard that draws the line is written in the language on the far side of it.

An ontology is not a database schema, though they overlap. The difference is what happens at the edges. A schema is a constraint: it tells the database what to reject. An ontology is, at least in the formal tradition, a set of premises: it tells a reasoner what to conclude. A schema says a customer must have an address or the insert fails. An ontology says every customer has an address, therefore if you show me a customer, I will conclude there exists an address for them, even if I’ve never seen it. That difference sounds like hairsplitting. It is not. It’s the open-world assumption, and it’s the thing most likely to make a database engineer’s head hurt the first time they meet it. Lecture six is about that in detail.

And an ontology is not a knowledge graph. This one causes the most trouble right now, because “knowledge graph” is the phrase with commercial momentum. A knowledge graph is a data-shaped commitment: your information is entities and relationships rather than rows and joins. That’s a good idea and often the right one. But being graph-shaped doesn’t give you formal semantics. There’s a documented case in the corpus these lectures are built from: a system called SciGraph loads an ontology-centred biomedical model into a graph database, and the mapping is explicitly and deliberately lossy. It can’t round-trip. It drops some structures entirely. It’s a useful tool, and it isn’t an ontology, and the SciGraph documentation says exactly that: the mapping is lossy and does not round-trip. Many production knowledge graphs have no ontology in the formal sense at all. That’s fine. It’s only a problem when someone sells you the graph and bills it as the semantics.

SciGraph itself is honest about all this, which is why it makes a good example. Reasoning support is a stated non-goal. It doesn’t create ontologies, doesn’t manage them, doesn’t version them, isn’t a primary data store, and doesn’t offer CRUD — create, read, update, delete — at all. It is a loader and an access layer, and it says so.

And there’s a detail in it that ties back to the taxonomy point, because it shows that distinction has teeth. SciGraph is built around OWL. Hand it a vocabulary whose SKOS concepts have not also been asserted to be OWL classes, and the OWL library underneath simply never sees them. They are not loaded. Not mangled, not approximated. Absent. So the difference between a librarians’ concept and a class with formal semantics is not a philosophical nicety there. It decides whether your terms are in the graph at all.

The same documentation frames an ontology as something that can serve as data, as vocabulary, or as semantics, and I think that is the most useful three-way split after the one this lecture opened with. A graph database hands you the first two without much trouble. The third is the one you pay for, and the reason to pay is that formally defined meaning lets software do more than string matching.

Let me try to draw these distinctions together with a single example.

Imagine you’re modelling flights. A taxonomy tells you a widebody aircraft is a kind of aircraft. A schema tells you the departure time column cannot be null. A knowledge graph lets you walk from a flight to its aircraft to its maintenance records to the technician who signed them off, in one traversal, without writing four joins. And an ontology tells you that a flight has exactly one assigned aircraft, that an aircraft assigned to a flight cannot simultaneously be in maintenance, and that if those two facts are ever both asserted, your data is inconsistent — and it tells you that in a form where a program can find the contradiction on its own, at three in the morning, without a human noticing.

That last capability is the whole pitch. Whether it’s worth the cost is the argument of the next nine lectures.

Now some orientation, because I want you to know what you’re signing up for.

This series is not a sales pitch. The field has a real history of overclaiming, and there are three serious criticisms of the whole enterprise, made by serious people, that have never been fully answered. We’ll spend an entire lecture on them, and I’ve deliberately put that lecture after the ones that teach you how the machinery works, so that when the criticism arrives you’ll have something concrete for it to argue with. The critics are Cory Doctorow, who attacked the incentives; Clay Shirky, who attacked the range of cases where it applies; and Geoffrey Bowker and Susan Leigh Star, who attacked the consequences, and whose criticism is the one I think the technical community still hasn’t answered.

There’s also a story about ambition. The idea we’re studying was once meant to reorganise the entire World Wide Web, and that project largely failed, in ways that are well documented and instructive. The same machinery then quietly succeeded in genomics, in museums, and in finance, where it’s load-bearing infrastructure today. Understanding why it failed in one place and succeeded in the other is, I think, the most useful thing this whole course has to offer.

Now to the exercise, which you can do while walking, because this stuff sticks better when you’ve run it on something you know.

Pick a system you’ve worked on. Any system. Now answer four questions about it.

First question. What kinds of things does it assume exist? Go table by table, or collection by collection, and name them. Customers. Orders. Sessions. Whatever they are.

Second question. What relations can hold between them, and which relations are conspicuously absent? Every foreign key is a relation you committed to. But look at the absences. Can two customers be related to each other in your model? Can an order relate to another order? If not, you’ve asserted that those relationships don’t matter, and one day somebody will ask about them.

Third question. Which of your categories have fuzzy edges that everyone works around? There’s always at least one. A status field with a value called “other” or “pending review” or “legacy,” which in practice holds four different situations that nobody wanted to model. That value is where your ontology is lying, and the size of that bucket is a decent measure of how wrong the model is.

Fourth, and this is the sharpest one. If you had to explain your data model to a company you were merging with, what would you have to say out loud that isn’t written anywhere? That gap — between what the schema says and what you’d have to explain — is the implicit part of your conceptualization. Making it explicit is, literally, the definition of doing ontology work.

I find that exercise clarifying. Every answer is already in the system; the exercise only makes you say it out loud.

One distinction comes up constantly, and it’s a source of quiet confusion in organisations.

A data dictionary is not an ontology. A data dictionary is a document that tells a human what a field means. Take an example of my own: a field called customer status code, holding values A through F, where A means active. That’s genuinely useful and every organisation should have one. But it’s prose for people. A machine can’t do anything with it except display it. There’s no way for a program to work out that an active customer is a kind of customer, or that status codes are mutually exclusive, or that something has gone wrong when a record has two of them.

The move from a data dictionary to an ontology is the move from documentation to specification — from telling a person what you meant to telling a machine what follows. That’s what Gruber’s word “explicit” is doing. Not “written down.” Written down in a form with defined consequences.

And here’s something I run into again and again. An organisation that says it wants an ontology often wants three things at once, and has no language to separate them. They want a shared vocabulary, so two departments stop meaning different things by “active customer.” They want machine-checkable consistency, so the contradiction is caught by the build rather than in a board meeting. And they want to reuse someone else’s model rather than inventing their own. Those are three different projects with three different costs. A glossary gets you the first. A formal ontology with a reasoner in continuous integration gets you the second. Adopting a published standard gets you the third. That route usually costs the most up front, because you have to negotiate with a model somebody else designed. It usually saves the most over the years that follow.

Being able to tell a client which of those three they actually need will save you a great deal of money and argument.

So, the one claim I want you to keep from this lecture.

The word “ontology” names three things: a branch of philosophy, a particular theory of what exists, and a machine-readable file that states, explicitly, what kinds of things a system assumes exist and how they relate. Every piece of software you’ve ever built already made those assumptions. The only question the third sense poses is whether you wrote them down.

Next time, we go back two thousand years and find out where the word came from, and why the man who put it into circulation would have been appalled by what we’ve done with it.

2. From Aristotle to Wolff: Where the Word Came From

About 19 minutes spoken, 2,815 words. Plain text for a reader app: 02-aristotle-to-wolff.txt

This is the second of ten talks about ontologies. Last time we separated three senses of the word: the philosophical discipline, a particular theory of what exists, and the machine-readable file. Today we trace where the word itself came from, over about two thousand three hundred years, and we finish with a question worth carrying through the rest of the series: when computer science borrowed this word, what came with it, and what got quietly left behind.

Let me warn you at the start that this lecture has more dates in it than the others.

Start with Aristotle, in the fourth century before Christ. Aristotle does not use the word “ontology.” Nobody does for another two millennia. What Aristotle does is identify the subject. In Book Four of the Metaphysics he describes a discipline he calls first philosophy, and he distinguishes it from every other science by the way it takes its object.

Here’s the distinction, and it’s cleaner than most people give it credit for. Every particular science studies things under a restriction. Physics studies things insofar as they’re subject to motion. Medicine studies bodies insofar as they’re healthy or sick. Each one cuts a slice out of reality and works on the slice. First philosophy takes no slice. It studies things insofar as they are — being qua being, in the standard translation. It asks what’s true of everything that exists, purely because it exists.

That sounds impossibly abstract until you notice that Aristotle immediately gets concrete. He wants to know: what are the fundamental kinds? What is it for something to be a substance rather than a property? Is a horse the same kind of thing as the colour of the horse, or the horse’s height, or the horse’s running? His answer is the Categories, a list of the basic ways a thing can be said to be.

Now, why should an engineer care about a list from the fourth century before Christ? Because that’s an upper ontology. That’s exactly the move that BFO, the Basic Formal Ontology, makes today. BFO is a small upper-level ontology that deliberately excludes physical, chemical, biological and other terms belonging to the specialised sciences. Its whole job is to supply domain-neutral categories that a specialised ontology can then sit beneath, and more than five hundred and fifty ontology-driven projects use it that way. Aristotle is doing the same job with the same motivation, which is that if you don’t fix the top-level kinds, every domain will invent its own and they’ll never fit together.

So the subject is ancient. The word is not.

Aristotle’s commentators, all through the Middle Ages and into the early modern period, recognised that being as such was a distinct object of study. But none of them thought a new word was needed. They said metaphysics, and that was that.

Then, at the start of the seventeenth century, somebody coined it.

One candidate is sixteen oh six. A German philosopher named Jacob Lorhard published a work called Ogdoas Scholastica, and in it the Latin word ontologia appears — the science of being. That’s the appearance Britannica credits.

Seven years later, in sixteen thirteen, Rudolf Goclenius printed the word in his Lexicon philosophicum, a philosophical dictionary. And priority between those two is contested. Ferrater Mora, writing without Lorhard in front of him, says the first instance occurs in Goclenius. So which date you get depends on which reference work you open.

There’s also a persistent misattribution worth knowing about. A whole line of respectable historians — Eucken, Gilson, Pichler, Wundt, Heimsoeth — name Johann Clauberg as the first philosopher to use the term. Ferrater Mora’s rebuttal is a date. Clauberg published Ontosophia only in sixteen forty-seven, by which time the word was already in use.

Now to the man who actually made the word stick.

Christian Wolff, the German rationalist, published Philosophia prima sive ontologia in seventeen thirty. First Philosophy, or Ontology. That’s the book that put the word into general circulation, and Wolff’s definition is the one worth memorising because it’s the high-water mark of the ambition: ontology is scientia entis in genere, quatenus ens est. The science of being in general, insofar as it is being.

Two things about Wolff’s programme matter for us.

The first is his method. Wolff proceeds demonstratively — rationally, deductively, from first principles, in the manner of a geometry textbook. Definitions, axioms, theorems. This is ontology as a proof system.

And underneath the method sits a claim about us. On Ferrater Mora’s account, Wolff took the human intellect to be capable of knowing the essence of things. That, as I read it, is the load-bearing assumption. Without it the deductions still run, but they stop being deductions about being and become deductions about your own definitions. And that ambition, that you could derive the structure of reality by deduction, is exactly the ambition that description logic and OWL, the Web Ontology Language, inherit at the level of technique while abandoning at the level of scope. A modern reasoner does deduce theorems from axioms. It just doesn’t claim the axioms are true of reality. It claims they’re true of your model, which is a much smaller and much more defensible claim.

The second thing is Wolff’s organisational scheme, and this one is a direct ancestor of how ontology repositories are laid out today. Wolff divided metaphysics into two parts. General metaphysics, which is ontology, deals with being as such — the categories that apply to anything whatsoever. Special metaphysics deals with particular kinds of being: the soul, bodies, God. General first, then special.

Look at what that maps onto. General metaphysics is the upper ontology: BFO, or DOLCE — the Descriptive Ontology for Linguistic and Cognitive Engineering — or the Suggested Upper Merged Ontology. Special metaphysics is the domain ontology: the Gene Ontology for gene function, CIDOC CRM, the Conceptual Reference Model, for cultural heritage, the Financial Industry Business Ontology for finance. And between them, modern practice has inserted a layer Wolff didn’t have — the mid-level ontology, like the Common Core Ontologies, which supply reusable notions such as agents, events, measurements, and facilities that are too specific for the top and too general for any one domain.

That three-layer structure, upper, mid, domain, is the standard architecture of ontology engineering, and it’s Wolff’s distinction with an extra floor.

I should flag something about that mapping, because I’ve now made it twice and I don’t want it to pass as history. It’s my mapping. None of the sources I’m working from claims that the engineering layers descend from Wolff. What the sources give me is the shape at both ends and nothing in between. At one end, Britannica’s Wolff: general metaphysics applies to all things, special metaphysics to particular kinds of thing. At the other end, Guarino, Oberle and Staab on modern practice: the primary purpose of top-level ontologies, they say, lies in providing a broad view of the world suitable for many different target domains. Same shape, no documented line of descent. Reinvention is at least as likely as inheritance. What I’ll claim is only this — the split gets made twice, by people with different problems, and that is worth noticing.

Since I keep saying upper ontology as though it were obvious what one buys you, let me say what the two I’ve named actually commit to.

The Basic Formal Ontology describes itself as a small upper-level ontology intended to support information retrieval, analysis, and integration across scientific and other domains. Read that as a list of jobs rather than a claim about reality. Find things, examine things, join things up. I said a moment ago that it excludes the specialised sciences, and the project states that exclusion as a warning to its own users: don’t expect it to supply specialised scientific terms, because those are outside its scope on purpose. So what it commits to is deliberately small. A shared upper-level structure for your domain ontologies to align around. The domain terms remain your problem, and that’s the deal rather than a shortfall.

The Common Core Ontologies commit to something more awkward, because a mid-level has two neighbours to answer to instead of one. It’s a suite of eleven ontologies of logically defined generic terms and relations, and it extends the Basic Formal Ontology, which its documentation calls an ISO-standard top-level — ISO being the International Organization for Standardization. The modules cover time, artifacts, currencies, geospatial entities, information entities and so on, and the classes are the ones you would otherwise rebuild in every project you ever work on: person, date, employment, nickname, measurement.

Then comes the part that tells you what it really commits to. Its authors explicitly encourage users to publish their own domain extensions rather than expanding it indefinitely with domain content. It is not meant to absorb content specific to individual domains. That content belongs in extensions, maintained separately, sitting underneath.

So each floor is defined as much by what it refuses to hold as by what it holds, and the refusal is enforced editorially — a governance board, a contributing guide, a standing instruction to take your domain content elsewhere. That last framing is mine again. The sources give me the policy; calling it the engineering form of general-versus-special is me.

So we have the word, we have the ambition, and we have the architecture. Now we get the demolition.

Immanuel Kant went after general metaphysics directly, and that attack is why Wolff’s programme stops being the mainstream. What exactly it amounts to is a philosophy course of its own, and the one-line gloss I’m about to give you is mine, not something my sources settle. As I read it, Kant’s charge is that Wolff mistook a feature of our thinking for a feature of the world.

I raise it because that charge has a direct engineering echo, and the echo is the useful part.

Mistaking a feature of the modelling apparatus for a feature of the modelled world is precisely the failure mode of ontology engineering. You build a model of shipping. It has a class called Delay. You get very good at reasoning about delays. And after two years, nobody in the organisation can think about a late shipment except as an instance of Delay with a cause property, because that’s the only shape the system will accept. The category has stopped describing your operations and started constraining them. That’s Kant’s objection, arriving on a Tuesday, in a stand-up meeting. We’ll see it again in lecture eight under a different name, when Bowker and Star call it torque, and again in lecture ten when a Danish police platform turns a car in a registry into a getaway vehicle.

After Kant, the word survives but changes hands.

In the early twentieth century Edmund Husserl, the founder of phenomenology, picks it up. Husserl calls Wolff’s general metaphysics formal ontology, and he contrasts it with special, regional ontologies — the ontologies of particular domains of being. Note that vocabulary. Formal ontology. Regional ontologies. If you’ve spent time in this field, you have just heard two phrases you already know. You probably thought computer scientists coined them in the nineteen-nineties. They didn’t. Martin Heidegger took the word in a different direction, arguing that the whole tradition had forgotten to ask what being means, and grounding the question in the analysis of human existence, which he called Dasein.

I mention Heidegger mostly to draw a boundary. Nothing in the Heideggerian line feeds into computer science. If you go looking for the philosophical roots of OWL you’ll find Aristotle, Wolff, and Quine. The phenomenological branch is a genuinely different tradition with a genuinely different question, and confusing the two produces a lot of bad writing.

One thing I skipped in that sprint through the centuries is worth going back for, because it turns up in modern practice wearing different clothes. It’s the argument about universals, and it has a genuinely surprising payoff.

The question is: when we say Socrates is human and Plato is human, is there a thing, humanity, that both of them share? Three answers were on offer. The realists said yes, universals exist independently of the particular things. The conceptualists said universals exist, but only in the mind. And the nominalists said there is nothing but individuals plus the names we give them — “human” is a word we apply to similar things, and there’s no further entity.

That argument ran for centuries, and the reason I’m telling you about it is that it’s the same argument two engineers have when one says “we should have a Customer class” and the other says “there is no such thing as a customer, there are just people who bought something, and ‘customer’ is a label we apply.”

Both of them are right, in the sense that neither position has won. The General Formal Ontology, a modern top-level ontology, deliberately offers several kinds of category — universals, concepts, and symbolic structures — precisely so that it can stay open across realism, conceptualism, and nominalism. That’s how unsettled the question still is. And the choice has consequences in the model. If you’re a realist about customers, Customer is a class, and a person either is one or isn’t. If you’re a nominalist, “customer” is a role that a person plays with respect to a transaction, and the right model has people, transactions, and a role that relates them.

That second modelling choice, incidentally, is the more flexible one, and it’s why upper ontologies treat roles as a first-class notion. The General Formal Ontology gives detailed accounts of roles and functions. So does gUFO, the lightweight form of the Unified Foundational Ontology, which separates a taxonomy of individuals from a taxonomy of types and makes role one of the type kinds. The reason is that treating a role as a class produces a specific and very common bug. If Customer is a subclass of Person, then a person who stops buying has to change class — and in my experience that is the change these models handle worst. Whereas if being a customer is a role a person plays in a relationship, they can start and stop playing it without becoming a different entity.

That is a live, practical, expensive modelling decision, and the medieval debate about universals is exactly where the arguments for both sides were worked out. Nobody tells engineers this, and I think they’d model better if someone did.

So what actually made the crossing into computing?

Three things came across. The vocabulary came across: ontology, category, formal, upper and regional, the whole lexicon. The architecture came across: general before special, upper before domain. And the deductive method came across: axioms, definitions, and a machine that derives theorems from them, which is what a reasoner is.

One thing did not come across, and it’s the one that matters most. Wolff’s ontology was meant to be the single true account of being, derived by reason, correct for everyone. An engineering ontology is nothing of the kind. It’s chosen for a purpose. Gruber’s phrase for these things is that they are designed artifacts, formulated for specific purposes and evaluated against objective design criteria. Notice what does the judging in that sentence. Design criteria. Not correspondence with being. There are many possible models of the same domain, and the good ones are good relative to a set of questions somebody needs answered. Genesereth and Nilsson said it in the line I quoted last time: a conceptualization is a simplified view of the world that we wish to represent for some purpose. For some purpose. Wolff would have found that sentence unbearable.

And here is where the trouble comes from. The vocabulary still carries Wolff’s ambition even though the practice abandoned it. When a vendor says “we have modelled the ontology of your enterprise,” the word is doing work that the artifact cannot support. It sounds like a discovery about your business. It is a set of choices about your business, made by people, for reasons, that could have gone otherwise. Every time you hear the word used with a definite article — the ontology, as though there could only be one — a claim of objectivity is being made that nothing in the engineering practice earns.

So, the claim to keep from this lecture.

Ontology began as the search for the one true account of being, and its whole vocabulary was built for that job. Engineering kept the vocabulary, kept the layered architecture, kept the deductive method, and quietly dropped the claim to uniqueness. Most of the overclaiming you’ll encounter in this field is that dropped claim sneaking back in through the word itself.

Next time, the philosopher who found a way to make ontology tractable, by refusing to answer the question at all.

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.

4. The Cathedral: Cyc, and the Birth of the Engineering Sense

About 19 minutes spoken, 2,780 words. Plain text for a reader app: 04-cyc-and-the-engineering-sense.txt

This is the fourth of ten talks about ontologies. The first three did the word, its philosophical history, and Quine’s move that turned ontology into a property of theories rather than a claim about reality. At the end of the last one I promised you the most expensive experiment this field has ever run. That’s today, together with the moment somebody wrote down a definition that stuck.

Start with the premise, because everything else follows from it.

Douglas Lenat’s claim was that machine learning and natural language understanding both stall without a large base of background knowledge. Learning cannot bootstrap that base, because you need background knowledge before you can interpret the examples. Reading text cannot supply it either, because the writers leave it out.

So somebody has to enter it by hand. All of it. Until the system reaches what Lenat called critical mass and can take over its own learning.

Two claims are packed into that, and they come apart cleanly. The first is that common sense is an engineering target at all — not a mystery, and not a by-product of being alive, but a body of knowledge a team can be set to work on. The second is the critical-mass hypothesis: that there is a threshold, and that crossing it hands the work back to the machine. You can accept the first and reject the second, and if you do you get a very different sort of project. Cyc is what you build when you accept both.

In nineteen eighty-four, Lenat and Mary Shepherd began that project. It was called Cyc. The article to read is Lenat’s “CYC: A Large-Scale Investment in Knowledge Infrastructure,” published in Communications of the ACM — the A-C-M, the Association for Computing Machinery, the main professional body of the field — in nineteen ninety-five. It is short, and it is worth reading in full. In it Lenat says something I find genuinely admirable, and I’ll quote it. Mary Shepherd and I, he writes, embarked on that task in nineteen eighty-four, “knowing we had little chance of success, but seeing no alternative but to try.” That is not the sentence of a man overselling his research programme.

What does codifying common sense require? Lenat’s list is sobering. Causality. Time. Space. Substances. Intention. Contradiction. Uncertainty. Belief. Emotion. All of that has to be represented before a machine can reason about anything ordinary at all.

The examples in the paper are the part people remember, and they’re worth hearing, because they show exactly what kind of knowledge is at stake.

You cannot remember events that have not happened yet.

If you cut a lump of peanut butter in half, each half is also a lump of peanut butter. But if you cut a table in half, neither half is a table.

Sit with that second one. What I’m about to say about it is my reading rather than Lenat’s. It is the distinction between mass nouns and count nouns, and what it decides is whether half of a thing is still an instance of the thing’s type. Any system reasoning about materials, or chemicals, or fuel, or blood needs that distinction, and needs it written down, because it does not fall out of anything else.

Lenat’s own line about why counting words will not get you there is worth quoting directly. Statistics, colocation, and frequency, he writes, “do not resolve such questions. But the task goes from impossible to trivial if one already knows a few things about boxes and pens.”

So how big did it get? The nineteen ninety-five paper reports a universal schema of roughly a hundred thousand general concepts spanning human reality, about a million commonsense axioms handcrafted for and entered into Cyc’s knowledge base, and millions more inferred and cached by Cyc itself. And it reports a price: a person-century of effort since nineteen eighty-four.

Hold that number, because it is the only one of its kind. This is the only document I know of that states the price of hand-codified knowledge as a figure. Every plan that says “we’ll just model our domain properly” is quietly betting against it. Because underneath every one of those plans sits the question every ontology project eventually has to answer: how much of the world do we have to write down before the model earns its keep? Cyc is the largest sustained attempt anyone has made to answer it, which is why it is the reference experiment for the cost side of this whole discipline.

Cyc also introduced an idea that has aged well. Micro-theories. Each one, in the paper’s own words, “inhabits its own context,” and each is “relatively small, solid, and flat.” Now, the reason I think that matters is mine and not the paper’s, so take it as my inference. Demanding that one enormous knowledge base be consistent from end to end is a losing requirement. Small, flat, locally coherent contexts are a way of not asking for it.

What happened to the project? Cyc is still going, and it is sold today as a commercial platform — machine reasoning built on codified human common sense rather than on patterns and statistics. Where it is sold is the part that would surprise a reader of the nineteen ninety-five paper. The emphasis now is healthcare operations. Charge capture. Denial management. Post-acute-care forecasting. Staffing. The offer is a knowledge and reasoning layer placed over complex operational workloads, using continuously enriched patient and order context to make auditable decisions. The capability list runs: logic-based machine reasoning, codified common-sense knowledge, dynamic real-world data, semantic context, autonomous decision-making. And it is pitched hard on explainability and auditability.

I want to hand you that description with a warning attached, because I am reading it off the company’s own page. It makes broad product and performance claims, and it supplies no ontology structure, no evaluation details and no implementation guidance, which means none of those claims can be assessed from that source alone. Take it as positioning. It tells you what the market is willing to buy from a knowledge base, which is genuinely informative, and it tells you nothing about whether the thing works.

What Cyc never reached is the critical mass Lenat described, where the hand entry stops and the system reads for itself. The payoff was always deferred to a threshold that had not yet arrived.

And I want to draw the engineering lesson carefully, because it’s easy to be glib about a project that has run for forty years.

The lesson is not that the effort was wasted, and it is not that hand-built knowledge is worthless. The lesson is about the shape of the bet. A knowledge base whose value depends on reaching a threshold, rather than on being useful at every stage, is a bet on the threshold. The alternative shape is layered: a small ontology that answers real competency questions early, and keeps answering more of them as it grows. When you plan a knowledge project, ask which of those two shapes it has. If the answer is “it’ll be great once we’ve modelled everything,” you have a Cyc, and you should know that going in.

Now, the second half of this lecture, and the reason the word we’re studying entered computer science at all.

Tom Gruber’s nineteen ninety-three work gave us the definition: an ontology is an explicit specification of a conceptualization. We took that apart in lecture one, so I’ll only restate what matters here — and what matters here is where he was standing when he wrote it. Gruber’s own acknowledgements place the work inside the ARPA Knowledge Sharing Effort. ARPA is the Advanced Research Projects Agency, the American military research funder, later renamed DARPA with Defense on the front. And the operative word in that programme’s name is sharing.

Read the definition next to the name of the programme and the shape of the thing becomes obvious. Gruber’s ontology is an interface specification. It is the language two agents use to talk to each other about a domain, and — this is his sentence — “the agents sharing a vocabulary need not share a knowledge base; each knows things the other does not.” An agent that supports the interface is not obliged to store its knowledge that way internally at all.

That is why an ontology can sit on top of systems that share nothing else. Two teams, two internal representations, neither of which is going to be rewritten. What do they have to agree on? Not their code. Not their storage. The vocabulary, and a written-down account of what the vocabulary means, explicit enough that a machine can check it.

Hold on to that shape, because it recurs. Palantir describes its own Ontology in almost the same architectural words — it sits, in the company’s own phrasing, on top of the digital assets integrated into the Palantir platform, and connects them to their real-world counterparts. On top of, and connected to. Not in place of. Palantir never invokes Gruber, so what I am pointing at is a resemblance and not a lineage, and lecture nine is where we take it apart properly.

That agreement has a name in this literature. Ontological commitment. In lecture three it was a formal object. In Gruber’s engineering register it is something plainer than that: an agreement to use a vocabulary consistently.

In nineteen ninety-seven Willem Borst revised the definition to “a formal specification of a shared conceptualization.” That word, shared, adds consensus. And I’d say the addition is really the original mission catching up with the sentence: an ontology only one team agrees with does not solve a sharing problem.

So of the words in that definition, two carry the weight. Explicit — the commitments are written down and machine-readable. And, after Borst, shared — more than one party agreed to them.

I don’t want to leave that sentence looking tidier than it is, though, because the field’s founding definition is also the field’s longest-running argument, and Gruber knew it. He concedes in his own writing that the terms specification and conceptualization have, and I quote, “caused much debate.” Guarino, Oberle and Staab — whose formal construction of commitment we met in lecture three — wrote their two thousand and nine chapter largely to repair that informality, on the grounds that all the earlier definitions were assuming, as they put it, an informal notion of conceptualization.

The instability goes all the way down to the wording, and it is worth being precise about that. In lecture one I gave you the conceptualization half of the definition as the objects, concepts and other entities presumed to exist in some area of interest, and I flagged there that this is Gruber’s own restatement of himself, from two thousand and nine. Genesereth and Nilsson’s original says assumed to exist, not presumed. Nothing much hangs on the difference. What hangs on it is the fact that the field’s most-quoted sentence circulates in more than one authorised wording, and almost nobody who quotes it has ever had to decide which one they mean.

And there is a standing objection that Gruber records and then rejects. The objection is that the definition is overly broad, allowing, in its words, “a range of specifications from simple glossaries to logical theories couched in predicate calculus.” Whether that breadth is a defect is still argued. What is not in doubt is the practical consequence: it is exactly what lets a team call any schema they like an ontology. Keep that in your pocket. It explains a great deal of what you will hear the word used for.

There’s one more strand feeding into this moment, and it’s the one that makes the artifact computable. Description logics. They are a family of formal knowledge-representation languages, more expressive than propositional logic and less expressive than first-order logic, built out of concepts, roles, individuals and axioms, and deliberately balanced so that expressive power is traded against the cost of reasoning. Many of their core reasoning problems are decidable — meaning a program is guaranteed to stop and give you an answer rather than running forever. Description logics are the logical foundation of OWL, the Web Ontology Language, and of its profiles, and they are the whole subject of lecture six.

The trade behind those profiles is a single sentence. Adding operators, and letting the concept hierarchy get more complicated, usually increases the computational complexity of inference. Profiles are what you get when a standards committee takes that sentence seriously.

Two more things about that family before we leave it, because “makes the artifact computable” is a promise until you have seen what it consists of.

The first is a translation table, and it is shorter than you would expect. A concept corresponds to a class, or to a unary predicate — something you assert of one thing. A role corresponds to a property, or to a binary predicate — something that relates two things. An individual corresponds to a constant. Three slots, and that is the whole apparatus.

The next step is my reading rather than the source’s, so take it as mine. Those are the same three slots lecture three’s criterion cares about. Gruber wants two agents to agree on a vocabulary. Quine wants you to read a theory’s commitments off what it quantifies over. Description logics say the vocabulary is predicates and constants, and then hand the lot to a machine. So the engineering tradition and the philosophical one are not merely being polite to each other in this lecture. They are describing one structure from opposite ends.

The second thing is reach. Description logics turn up in ontologies, in the Semantic Web, in biomedical informatics, in defence, in climate modelling, and in industrial knowledge graphs. Six fields with almost nothing in common except the need to state what kinds of things exist and how they relate, and the same small formalism sitting under all of them. I’d take that as the fair measure of how load-bearing this quiet idea turned out to be.

So two traditions meet in the early nineties. From the artificial intelligence side, Cyc’s hard-won verdict that background knowledge is the bottleneck, plus a formal apparatus for computing over concept descriptions. From the systems side, a funding programme whose goal was reuse. Ontology, in the engineering sense, is the artifact where those two meet.

Let me put Cyc back on the table one last time, because it has become relevant again in a way that would have surprised everyone in nineteen ninety-five.

Cyc’s motivating claim is that statistics alone will not resolve commonsense questions. That is precisely the claim large language models contest most directly, because they absorb an enormous amount of exactly that background from text, and nobody hand-wrote a single axiom to put it there. The paper is from nineteen ninety-five and says nothing about them — it could not. It is nevertheless the thing everyone is arguing with. Every later dispute about whether a model can replace an ontology is, whether it cites the paper or not, a dispute with that one sentence about boxes and pens.

The counter-argument I’d make is mine, not Lenat’s, and I want to flag it as mine. What the axiom gave you that the model does not is three properties. It 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. What a model absorbs has none of those three. Notice, incidentally, what Cyc sells on commercially today: explainability and auditability. Not coverage.

So the honest position, as I read it, is that Lenat may have been wrong about where the background knowledge would come from and right about what you lose when it arrives any other way. The field is still working out what to do with that split verdict, and we end the series on it.

So, the claim to keep.

The computer-science sense of “ontology” was invented to solve a sharing problem between knowledge-based systems, not a reasoning problem. That is why an ontology is an interface specification rather than a storage format, and why the definition eventually acquired the word “shared.” And the field’s founding megaproject, Cyc, bet everything on a critical mass it never reached — which makes it the standing warning about knowledge work whose payoff sits at a threshold instead of arriving in increments.

Next time, the moment this quiet engineering discipline was handed the entire World Wide Web.

5. The Semantic Web: A Vision and the Stack It Built

About 27 minutes spoken, 3,913 words. Plain text for a reader app: 05-semantic-web-vision-and-stack.txt

This is the fifth of ten talks about ontologies. Last time we saw the engineering sense of the word emerge from a military-funded programme about reuse, and we met Cyc, the field’s most expensive experiment. Today, the moment the discipline was handed the whole web, and the standards that came out of it. By the end you should understand why the technology has the shape it has.

One caveat first, said out loud rather than buried. Reading the whole stack as a set of answers to one magazine article is my reconstruction. The article does not claim it, and no source I am working from claims it. One major piece, the query language, arrived five years after the article was published, which on its own tells you the story is tidier than the history. Take the reconstruction as a way of remembering the design, not as a chain of cause and effect.

The article appeared in Scientific American in May two thousand and one. The authors were Tim Berners-Lee, who invented the World Wide Web, along with James Hendler and Ora Lassila. It is called “The Semantic Web,” and it opens with a scenario I am going to read you a piece of, because everything follows from it.

The entertainment system is belting out the Beatles when the phone rings. Pete answers, and his phone turns the sound down by sending a message to all the other local devices that have a volume control. His sister Lucy is on the line from the doctor’s office. Their mother needs to see a specialist and then has to have a series of physical therapy sessions, twice a week or so. Lucy says she will have her agent set up the appointments. Pete agrees to share the driving. At the doctor’s office, Lucy instructs her Semantic Web agent through her handheld browser. The agent retrieves information about the prescribed treatment from the doctor’s agent, looks up several lists of providers, checks which of them are in-plan for their mother’s insurance and within twenty miles of her home with a rating of excellent or very good on trusted rating services, and then starts matching available appointment times, supplied by the agents of individual providers through their own websites, against Pete’s and Lucy’s schedules.

Hold that scenario in your head, because I want to inventory what it demands. The inventory is mine rather than the article’s, but I do not think any of it is a stretch.

First, Lucy’s agent talks to the doctor’s system, to several clinics, to rating services, to an insurer’s list, and to two personal calendars. No service was built to talk to any other. So requirement one: data from independent sources must combine without anyone having agreed in advance to combine it.

Second, the agent has to know that the doctor’s “physical therapy” and the clinic’s “physiotherapy” are the same treatment. Requirement two: shared meaning across independent vocabularies.

Third, the agent has to work out that a provider rated “excellent” satisfies a request for “excellent or very good,” which nobody stated. Requirement three: make inferences about information that was left out.

Fourth, and I want to stress this one, the appointment times are supplied by the agents of individual providers through their own websites. Not through a booking platform. Not through an aggregator. Requirement four: decentralisation. That is the article’s own emphasis and not my gloss. Decentralisation is the point of the exercise.

Four requirements. Now watch the standards line up against them.

Requirement one is combining data from strangers. The answer is RDF, the Resource Description Framework, a standard from the W three C, the World Wide Web Consortium, which is the body that publishes almost everything in this lecture. RDF was designed as a metadata data model, and Sinclair Target’s history calls it the grammar in which Semantic Web pages expressed information. What it says is: express everything as three-part statements. Subject, predicate, object. Anna works at the clinic. The clinic provides physical therapy. That is the entire data model. Formally it is a labelled directed multigraph made of subject, predicate and object statements. The version I am describing, RDF one point one, was published in two thousand and fourteen, and in practice a graph like that lives in a triplestore.

Why triples rather than tables? This argument is mine and not the specification’s, so weigh it accordingly. If I hand you two relational databases about the same domain, merging them is a project. You reconcile schemas, resolve key collisions, decide what to do about columns that exist on one side only. If I hand you two sets of triples, you concatenate the files. The union of two graphs is a graph. There is no schema negotiation because there is no schema to negotiate.

RDF also carries the identity half of requirement two. Subjects and predicates are identified by IRIs, Internationalized Resource Identifiers. You will hear the older term URI, Uniform Resource Identifier, at least as often, and the two thousand and one article uses that one throughout. Either way, the idea is a globally unique name, so that when two publishers who have never met both use the same identifier for physical therapy, their statements join up the moment the graphs merge. Objects can also be plain literals, or blank nodes, which are anonymous and not directly identifiable from the statement they sit in.

There is a limit on that trick that undercuts the optimism, and it is stated in the specification rather than by critics. Producers and consumers must agree on what an identifier means, because that agreement is not inherent in RDF. A shared name is not a shared meaning.

Now let me clear up the thing that has confused people for twenty years. RDF is an abstract graph model. It is not a file format. Do not confuse the abstract model with any one serialisation of it. The same graph can be written as Turtle, TriG, N-Triples, N-Quads, JSON-LD, or RDF in XML, the Extensible Markup Language, among others. Turtle, the Terse RDF Triple Language, is the compact one, intended to be more readable and more editable by hand than the XML form, and it is what you would write yourself. JSON-LD, JavaScript Object Notation for Linked Data, encodes linked data in JSON while keeping the shape of traditional JSON, so linked-data meaning can be introduced by modifying documents a web developer already has. Turtle cannot express named graphs on its own, and TriG extends it for exactly that. The XML form is the one OWL requires conformant tools to be able to exchange, which is why it will not die. These are spellings. The graph is the model.

Two of those spellings deserve a moment more, because they are aimed at different people. Turtle’s syntax resembles the query language we will come to, and its job is to abbreviate the identifier-heavy form of a triple: you declare prefixes once, then share a subject or a predicate across several statements instead of repeating it. JSON-LD comes from the other direction. The document carries a context, and that context maps ordinary JSON property names and types onto concepts in an ontology, using the RDF model underneath. The context can sit inside the document or be referenced from outside it, which is how you give linked-data meaning to traditional JSON that nobody wants to rewrite. Two reserved keys supply identity and type, both IRI-based. Values can be coerced to a stated datatype or tagged with a language. And because the identifiers resolve, a client can follow them to discover further RDF. An RDF processor can interpret the mapped properties when it understands the vocabulary, which is the shared-meaning caveat again in different clothes. Where that ended up is worth naming: schema dot org and search-engine work, biomedical informatics, provenance, Activity Streams and ActivityPub, and Thing Descriptions in the Internet of Things.

Requirement two, shared meaning, needs more than identifiers. It needs a way to say what a term means, and that gives us two layers.

The first is RDFS, RDF Schema, and it is deliberately basic. Classes and instances. Transitive class and property hierarchies, subclass and subproperty. Global domains and ranges for properties. Labels and comments for humans. That is close to the whole language, and applications use the domain and range information for inference, for editing suggestions, and for error discovery. If your ontology is a controlled vocabulary with a hierarchy, RDFS does the job.

Two traps come with that simplicity, and both are in the specification’s own list. The first: a domain or a range is global to the property, not local to a class. Say that the property “treats” has a range of patients and that holds everywhere the property is used; RDFS gives you no way to say that inside one class it means something narrower. The second follows from the first. Declaring a domain twice does not narrow anything. It widens it, because multiple declarations mean the subject belongs to all of the declared classes at once. RDFS also does not prescribe what an application ought to do with any of this, and the specification is explicit that where RDF Schema and the RDF Semantics document disagree, RDF Semantics is the authority. That last point is small but it shows you how the stack is assembled. The layers are documents, documents can conflict, and somebody had to write down which one wins.

The second is OWL, the Web Ontology Language, and it is where the ambition lives. OWL two adds keys, property chains, richer datatypes, qualified cardinalities, further property characteristics, and better annotations. Cardinality: this flight has exactly one assigned aircraft. Property chains: the manager of my manager is my second-line manager. OWL two also has profiles, called EL, QL and RL, which restrict what you are allowed to say in order to buy something specific back. Reasoning over very large ontologies. Querying against relational data. Rule-based processing of RDF graphs. Each profile trades expressive power for a computational or implementation benefit, and lecture six explains that trade properly.

While we are here, OWL has a feature that confuses everyone, and it is easier to hear now than to discover later. OWL has two semantics, because an ontology can be viewed either as an abstract structural object or as an RDF graph. The Direct Semantics supports OWL two DL, that is OWL two Description Logic, and description-logic reasoning. The RDF-Based Semantics applies to any OWL two ontology taken as an RDF graph. The description-logic route is the one that buys well-behaved reasoning, and it charges for it in syntactic conditions. For example, a transitive property is not allowed to appear in a number restriction. So OWL is not one language with a quirk. As I read it, it is two views of the same documents, and the seam is visible in the specification. Worth knowing, because when a perfectly reasonable-looking piece of RDF makes your reasoner refuse it, you are standing on that seam.

Two footnotes on OWL, both of which save time later. The first is syntax. I said the XML form is the mandatory one for interchange, and it is, but it is not the only one on offer. OWL has its own XML syntax, a Functional Syntax, the Manchester Syntax, and Turtle, and they exist because processing and reading are different jobs. Different file, same ontology. The second footnote is a caveat on the RL profile. Rule-based reasoning in RL, run over an arbitrary RDF graph, is sound but may be incomplete unless the ontology satisfies RL’s structural definition and the query conditions that come with it. You can trust what it tells you. You cannot assume it told you everything. And the OWL document I have been taking the shape of the language from is itself an overview, informative rather than the normative definition, which is spread across several core specifications.

Requirement three, inferring what was never stated, is what OWL is for and what a reasoner does. A reasoner computes class consistency, subsumption, and instance retrieval. If the ontology says every physiotherapist is a healthcare provider, and the data says Anna is a physiotherapist, then Anna is a healthcare provider, and nobody had to write it down. Target’s history puts RDF Schema and OWL in exactly that role: they are how you make inferences about omitted information.

Then there is the piece the article did not plan for, which is querying. It turns out that once you have a large graph, most of what people want is to ask it questions rather than derive theorems. SPARQL is the answer, and the acronym stands for SPARQL Protocol and RDF Query Language, which contains itself, and tells you something about the era. In its version one point one it is the W three C’s query language for RDF graphs. Triple patterns are RDF triples with variables in them, and a basic graph pattern matches when you can substitute terms for those variables and get an equivalent subgraph. On top of that you get optional matches, alternatives, negation, and property paths, which express traversal compactly, including paths of arbitrary length. Queries run against a dataset with one default graph and any number of named graphs. And there are four result forms: SELECT returns variable bindings, CONSTRUCT builds a new graph from a template, ASK reports whether a match exists at all, and DESCRIBE returns a description graph whose shape the service decides, not your query. It works over data stored as RDF or merely exposed as RDF through middleware.

Three things the neat summary leaves out. First, shaping the answers. Beyond matching you get assignment, inline tables of values, aggregation, grouping, subqueries, expressions, and the sequence modifiers: ordering, deduplication, offset and limit. Ordering matters more than it sounds, because a pattern match initially produces its solutions in no specific order at all. Deterministic presentation is something you ask for. So a query that came back in a stable order all through testing and shuffles itself in production is doing exactly what the specification says it may do.

Second, federation. Querying across several endpoints, which is what the decentralised story actually requires, is not in the query language recommendation. It is defined in a separate SPARQL one point one recommendation of its own. The boundary is drawn explicitly, and I will only note where it falls: the central act of the two thousand and one scenario, an agent asking many independent providers at once, sits outside the document that defines how you ask.

Third, and this genuinely surprises people, a query language has an attack surface. A query that names the graphs it wants may dereference those identifiers, which means it spends network, disk and processor time on your behalf at addresses you did not choose. The specification warns about denial of service, about access to local files, about attacks that use the query service to reach through a firewall, about risks specific to whatever extensions an engine has added, and about identifiers containing Unicode characters that look like other characters. Every one of those follows from the design choice we were admiring earlier. The identifiers are global, and global means the thing at the far end belongs to somebody else.

And there is a layer that arrived later than the rest and that, in my experience, matters more than its position in the stack suggests. Validation. SHACL, the Shapes Constraint Language, and its cousin ShEx, Shape Expressions. SHACL describes RDF graphs by constraining their content, their structure and their meaning. Node shapes constrain nodes. Property shapes constrain the values you reach along a path. Constraints state things like datatype, minimum count, length, ranges, patterns, and logical combinations. Targets say where a shape applies, and targeting a class also targets the members of its subclasses. You run it with a data graph and a shapes graph, and what comes back is an RDF validation report, with severities: Violation, Warning, Info.

Now, why is that a separate technology? Why can OWL not do it? Because OWL and SHACL answer opposite questions, and this is one of the most useful distinctions in the field.

OWL says: here are my premises, tell me what follows. If the ontology says every order has a customer, and I show you an order with no customer, OWL concludes that there exists a customer I have not told you about yet. It does not complain. It infers.

SHACL says: here are my expectations, tell me what is broken. Same situation, and the report names a violation: this node has zero values for the customer property, and the shape requires at least one.

The reason OWL behaves that way is stated plainly by Horrocks, Patel-Schneider and van Harmelen. OWL, they write, “adopts the standard logical model of an open world assumption: a statement cannot be assumed true on the basis of a failure to prove it. Clearly, on the huge and only partially knowably World Wide Web this is the correct assumption.” That is the whole explanation. OWL was built for the web in the scenario we opened with, where the fact you are missing is probably sitting on somebody else’s server. SHACL was built for a graph you control, where a missing fact is a bug.

One honest complication before we move on. I have just given you a slogan, and the specification is less tidy. SHACL is not only constraints. Its built-ins can be extended through SPARQL or through JavaScript, and it carries SHACL Rules, a mechanism for inferring new statements. So the validation language infers too. My reading is that this does not collapse the distinction, since inferring under a closed set of shapes you wrote yourself is a different act from inferring under an open world. But if somebody tells you the whole difference between OWL and SHACL is that one infers and the other checks, they have given you the slogan and not the specification.

And one trap, because it is easy to get wrong. A property shape can carry its own target, saying where it applies. Include that same property shape inside a node shape and its own target is ignored, and the node shape decides. Placement changes targeting behaviour, and nothing warns you. The shapes simply stop firing where you expected them to. The other half of that lesson is what the output is for: the report carries severities and messages so that a person can be told what failed and what to do about it. A validation report is addressed to a human, not just to a build script.

So: RDF for merging, global identifiers for identity, RDFS and OWL for meaning, reasoners for inference, SPARQL for questions, SHACL for validation. Six pieces, and five of them line up against the four requirements. The sixth, SPARQL, does not. It postdates the article by five years and answers a need the scenario never mentions. I point that out because the tidy version of this story gets told a great deal, including by me, ten minutes ago.

Now, what happened to the vision. Lecture eight does the criticism properly, so this is only the shape of the decline, and I am taking it from Sinclair Target’s retrospective of two thousand eighteen, which sets it out in four phases.

The first, from two thousand and one to two thousand and five, was the golden age of Semantic Web activity, and the W three C issued the first version of the RDF standard in two thousand and four. The second phase shifted from setting standards and building toy examples to creating and popularising large RDF datasets, which is linked open data. The third adapted the standards to the actual practices and preferences of web developers, and that is where JSON-LD and schema dot org came from. The fourth is the W three C’s own retrenchment, folding the work under the heading of Data Activity. Somewhere along the way Berners-Lee began referring to the Semantic Web as Web three point oh.

Target’s diagnosis of the sequencing is the part I would keep, and it generalises well outside this field: standards before applications. A committee that specifies before anybody ships produces artifacts nobody adopts.

The other thing that happened is that the agent layer centralised, into Google, into Yelp, into Siri, so that a provider advertises to the platform rather than from its own site. That is the exact inversion of the scenario we started with. In the article the clinic publishes and the agent finds it. In practice the clinic files its details with a platform and hopes.

Look back at requirement four. Decentralisation. That is the requirement that died, and my own view is that it died to economics rather than to any technical defect, because the other three were satisfied by standards that work.

There is also an objection aimed at the vision itself rather than at what became of it. Lecture eight is built on that objection, so today I only put it on the table. The vision assumed that publishers would annotate their pages voluntarily, accurately, and at scale, with no direct incentive to do any of it. Target’s summary of the counter-argument is that most web users were likely to provide either no metadata at all, or else lots of misleading metadata meant to draw clicks. That single assumption, that people will describe their own data honestly and for nothing, is the point on which most later criticism turns. Notice, and the emphasis here is mine, that it is not a criticism of RDF, or of OWL, or of any specification we have looked at today.

One more observation about where the work went, and this one comes from the source rather than from me. The two thousand and one plan was to make the data structured enough that a simple agent could act on it. The current plan is to make the agent capable enough to act on unstructured data. Same scenario, same errand at the doctor’s office. The layer doing the work moved.

But the machinery survived, and the retrospectives themselves name where: schema dot org, knowledge graphs, Wikidata, DBpedia, and the biomedical ontologies. Wikidata is the clearest case. It is a free knowledge base that humans and machines both read and edit, it exports in standard formats, it has a public SPARQL service, and its WikiProjects are where the modelling and quality decisions actually get made. What every survivor has in common is that it is a governed, funded, bounded domain where somebody has an incentive to curate. The open web is none of those things. So when you next evaluate an ontology proposal, ask which of those two situations it resembles.

So, the claim to keep.

Every awkward feature of these standards is an answer to a requirement in the two thousand and one article, with the honest caveat that the mapping is a reconstruction and that the query language does not fit it. Triples because data from strangers must merge. Global identifiers because merging needs shared identity. OWL because agents must infer what nobody stated. SHACL because inference is not validation. And most of those requirements assumed an open web of strangers, which is the assumption that did not hold.

Next time, we open the box and find out how the reasoning actually works, and meet the one assumption that breaks everybody’s intuition the first time.

6. How the Machinery Actually Works

About 28 minutes spoken, 4,071 words. Plain text for a reader app: 06-how-the-machinery-works.txt

This is the sixth of ten talks about ontologies. Last time we walked the standards stack, and I offered you a way of remembering it: read each layer as an answer to a requirement set out in the Scientific American article of two thousand and one, with the caveat that the mapping is my reconstruction rather than a chain of cause and effect. Today we open the box. What does a reasoner actually compute, and why does it sometimes behave in ways that seem, on first contact, completely mad?

I’ll warn you that this is the most technical lecture in the series. There’s no code and nothing to look at, so I’ll keep every example small enough to hold in your head while walking.

Start with the mental model, which comes from description logics.

A description logic — DL for short, and those two letters are all over this material — is a formal knowledge-representation language, more expressive than propositional logic and less expressive than first-order logic. They come as a family, and that family is the logical foundation of OWL, the Web Ontology Language, and of its profiles. The mental model has three pieces and they’re simpler than the name suggests.

Concepts denote sets. When you write a class called Aircraft, you’re not naming a thing. You’re naming the set of all aircraft. Roles denote sets of ordered pairs. When you write a property called assignedTo, you’re naming the set of all pairs where the first element is assigned to the second. And individuals denote specific members. That’s it. Sets, pairs, and members.

From those three pieces you build compound descriptions. The set of things that are aircraft and have more than one aisle. The set of things that are flights whose assigned aircraft is a widebody. Description logics are, in essence, a compact notation for describing sets by their properties rather than by listing them, plus a machine that computes the relationships between those sets.

That austere little notation has travelled: the literature lists applications in ontologies, the Semantic Web, biomedical informatics, defence, climate modelling, and industrial knowledge graphs. Sets, pairs, and members, in every one of those.

Your ontology then splits into two parts, and this distinction is worth learning because the whole literature uses it.

The TBox is the terminology. General statements about concepts. Every widebody is an aircraft. No aircraft is a crew member. Every flight has exactly one assigned aircraft. These are the rules of your world.

The ABox is the assertions. Facts about specific individuals. This particular aircraft, tail number such-and-such, is a widebody. This flight is assigned to it. These are the contents of your world.

TBox is the schema-ish part, ABox is the data-ish part, and I say “ish” because the analogy leaks, as you’re about to see.

So what does a reasoner compute? Five things, mainly.

Subsumption. Is concept A a subset of concept B, in every possible interpretation that satisfies your axioms? This is the big one, and it’s less obvious than it sounds, because the answer is often yes for reasons nobody stated. Suppose you define a LongHaulFlight as a flight with duration over six hours, and separately define a TransatlanticFlight as a flight from Europe to North America, and you’ve said elsewhere that every Europe-to-North-America route has duration over six hours. The reasoner will tell you that every transatlantic flight is a long-haul flight. Nobody wrote that. It follows.

Classification. Do subsumption for every pair of concepts and you get the complete inferred hierarchy. This is the standard operation you run in an editor: you author a set of definitions in whatever order made sense to you, press the button, and the reasoner rearranges them into the hierarchy your axioms actually imply. When the result surprises you, one of your axioms says something you didn’t mean. I’d argue that’s the most valuable error message in the field.

Instance checking. Is this individual a member of that concept? Same logic, one level down.

Relation checking. Does this pair of individuals stand in this role? Instance checking asks whether a thing is in a set; relation checking asks whether a pair is in a set of pairs. Same question, one shape over — and it’s an inference, so the answer can come back yes when nobody asserted that pair.

Consistency. Is there any possible interpretation that satisfies all your axioms at once? If not, your ontology is inconsistent — you’ve described a world that cannot exist. A closely related service, which reasoners list separately, is finding unsatisfiable concepts: classes that can have no members in any interpretation at all.

Now. The open-world assumption. This is the idea that breaks people, and I want to spend real time on it, because every strange reasoner behaviour you’ll ever meet comes from here.

A database operates under the closed-world assumption. If a fact is not in the database, it’s false. You ask whether Melissa has a manager, the manager column is null, the answer is no. That’s not a limitation, it’s the design. A database is a record of what’s the case, and it’s authoritative over its domain.

OWL operates under the open-world assumption. If a fact is not stated, it’s unknown. Not false. Unknown. You ask whether Melissa has a manager, nothing says she does, and the answer is: I don’t know, and neither do you.

Here’s why, and it goes straight back to last time. The Semantic Web was built for a web of strangers publishing independently. Your graph is a fragment. The fact you’re missing might be on a server in Osaka that you’ll merge with tomorrow. Under those conditions, concluding “no” from “not stated” is simply invalid, so the logic refuses to do it.

Let me give you the consequence, because it’s the one that generates support tickets.

You write an axiom saying a valid order must have at least one line item. You load an order with no line items. You run the reasoner expecting a complaint. The reasoner reports that everything is fine. Why? Because you didn’t state a constraint. You stated a fact about the world: orders have line items. The reasoner reads your data, sees an order, and concludes that there exists at least one line item for it which you have not yet told it about. It has done exactly what you asked. It just wasn’t what you wanted.

Here’s a second case, and I prefer it to the first because it isn’t my illustration — it’s documented behaviour, written down by the people who maintain a production reasoner. You define a named class as equivalent to a restriction saying all the values of some property must be of a certain kind. Everyone assigned to this flight is cabin crew, say. Things with no value at all for that property may then get classified under your named class: the flight with nobody assigned to it comes back as one of your all-cabin-crew flights. My reading of why is that a condition on all the values of a property is trivially satisfied when there are no values — but the behaviour is the documented part and the gloss is mine. Note the shape of it either way. The surprise arrives not as an error but as a membership nobody wanted, sitting in a hierarchy that classified without complaint.

That’s why SHACL exists — the Shapes Constraint Language, a recommendation from the World Wide Web Consortium for describing a graph of RDF, the Resource Description Framework, by putting constraints on its content, its structure, and its meaning. And it’s why the split between inference and validation is not a matter of taste. When you want the machine to find what follows, use a reasoner. When you want the machine to find what’s missing, use SHACL: you write shapes, you say what they target, you feed the engine a data graph and a shapes graph, and it hands back a validation report with a severity on every finding. Reaching for the wrong one produces either a serene silence where you expected an error, or an error where the system was being perfectly reasonable.

A word on how shapes are put together, because it decides where a constraint actually bites. Shapes come in two kinds. Node shapes constrain nodes; property shapes constrain the values you reach by following a path. The constraints are the vocabulary you’d expect — datatype, minimum count, length, ranges, patterns, logical combinations. Targeting is the part people get wrong, in two documented ways. Targeting a class also targets the members of its subclasses, through the subclass relation, so a shape written for one class is quietly validating everything underneath it. And when a property shape is included inside a node shape, that property shape’s own targets are ignored. Where you put a shape changes what it validates, so if your shapes fire on things you never meant, or don’t fire at all, look there before you look at the constraints.

And one honest complication, because I’ve drawn the split too cleanly. Reasoners infer, SHACL validates — that’s the working heuristic, and SHACL doesn’t fully respect it. Alongside its built-in constraints it has extension mechanisms, and rules of its own for inferring new statements. So it’s a good way to decide which tool to reach for, not a wall between two kinds of technology.

There’s a companion assumption that catches people just as often, and it’s called the no unique name assumption. In a database, two different primary keys are two different rows. In OWL, two different identifiers might name the same thing. You have a person identified one way in the human resources system and another way in the badge system. Unless somebody asserts they’re different, the reasoner treats it as an open question. And it can run the other way too. If you say a flight has exactly one assigned aircraft, and your data shows two, a reasoner will not report an error. It will conclude that those two names denote the same aircraft. Which may be true. It may also mean your integration has a bug that you will now never see.

Notice that both assumptions are correct for the environment they were designed for and wrong for the environment most people use them in. The standards were built for an open web of strangers. Most deployments are inside one organisation where the data is authoritative and missing means missing. That mismatch is, I’d argue, the single largest source of frustration with this technology, and it’s a mismatch of context rather than a defect.

Now, the trade-off that shapes everything else: expressivity against complexity.

The more you can say in a language, the harder it is to compute with. This isn’t an implementation problem you can engineer your way past. It’s a mathematical property of the languages, and the sentence that states it is short: adding operators, and letting the concept hierarchy get more complicated, usually increases the computational complexity of inference. Negation, disjunction, cardinality restrictions, inverse properties — each one costs you. And past a certain point the language becomes undecidable, meaning no program can be guaranteed to give you an answer at all.

Description logic research charted that landscape in detail: for each combination of operators, how hard is reasoning, and is it decidable? Many of the core reasoning problems in the family are decidable, and they’re decidable because the languages were deliberately balanced to keep them so. That map is what OWL’s profiles are built from.

OWL two defines three of them, and the specification names them by letters: EL, QL, and RL. Each one restricts what you’re allowed to say in order to buy one stated benefit.

EL buys reasoning over large ontologies. ELK is a reasoner built for that profile, and it shows you what the restriction is worth: it implements a polynomial-time procedure for a fragment of OWL two EL, it can put several processor cores on the job at once, and when your axioms change it recomputes only the results that depended on them, which can bring a class-hierarchy update to something near real time. One wrinkle there, which I mention because it stands for a whole class of them: ELK’s standalone command-line tool cannot parse RDF in XML, the Extensible Markup Language — the syntax conformant OWL two tools are required to be able to exchange. It takes OWL two Functional-Style Syntax and nothing else, so you convert first, and large classifications may want a bigger Java heap.

QL buys relational querying. It’s the profile for the case where the data you care about lives in a relational database and you want to ask ontology-shaped questions of it.

RL buys rule-based processing of RDF graphs — which is to say you can run the thing as rules over the data rather than calling a reasoner at all. The specification attaches a caveat to that which is worth memorising. Rule-based OWL two RL reasoning over an arbitrary RDF graph is sound, but it may be incomplete unless the ontology meets the RL structural definition and the query conditions the spec sets out. Sound means it will not tell you anything false. Incomplete means it may not tell you everything true.

And then there’s full OWL two DL, with the expressive power and the worst-case complexity to match.

Two things about it that the profile story hides. The first is that OWL two DL charges for its decidability in the grammar. It imposes syntactic conditions on what counts as a legal OWL two DL ontology, and the example the specification’s own overview reaches for is this: a transitive property cannot appear in a number restriction. If parthood is transitive, you are not permitted to say a thing has exactly three parts. Not discouraged, not slow — not allowed. As I read it, that’s the decidability boundary drawn in advance, in what you may write down, rather than met at reasoning time by a tool that gives up.

The second is that OWL two has two semantics rather than one. The direct semantics supports OWL two DL and description-logic reasoning; the RDF-based semantics applies to any OWL two ontology taken as an RDF graph. So when a reasoner tells you which semantics it works to, that isn’t paperwork. It’s saying which of two readings of your file its answers are about.

Which brings us to two reasoners to know by name. HermiT is built on a hypertableau calculus, works to the direct semantics, and its authors say it passes all the OWL two conformance tests for direct-semantics reasoners. It also documents support for DL Safe rules, and the limit on those belongs right beside the RL caveat, because it’s the same bargain in different clothes: reasoning with DL Safe rules is incomplete when the ontology has property chains or transitivity axioms and the rule bodies use complex properties. Sound but possibly incomplete is not a tax the weak profiles pay for being weak. It turns up on a full DL reasoner too. Openllet is a Java reasoner for OWL two DL that will check whether an ontology is consistent, find the unsatisfiable concepts, compute the class hierarchy, check whether an axiom is entailed, explain an inference, and answer queries.

Both do genuinely impressive work, and both can fall off a cliff. The triggers are documented — Openllet ships a linting tool whose entire job is to find them, and the list it works from is this. General concept inclusions. Large disjunctions. Large cardinalities. Interacting existential restrictions. And large sets of assertions that individuals are all different from one another. Those are the constructs that create nondeterminism, generate extra individuals, or run the memory up in a tableau-based reasoner. So when an ontology that classified in two seconds stops finishing overnight, the diagnostic is not “reasoners are slow.” It’s: which one of those did I just add? And the honest answer is often that you have to remodel, because that linting tool warns you in as many words that its own automatic repairs are not semantically equivalent to the constructs they replace, and that several of its findings are warnings only.

That question has a limit, and the same tool draws it. It distinguishes modelling patterns that live inside a single axiom from patterns established across a whole ontology. The first kind you can point at. The second exists only in aggregate — no single axiom is the culprit, the shape of the thing is — and for those, I’d say the useful question isn’t what you added last week but what the ontology has been slowly turning into.

So how do you choose? Not by expressive power. By workload. What questions do you need answered, how big is the ontology, how big is the instance data, and how often does it change? The overview specification puts the rule plainly: pick EL, QL, or RL when its stated trade-off matches your application. A very large terminology with no instance data wants EL. A model sitting over a relational store wants QL. A pipeline running rules across a graph wants RL. Full DL is for when you genuinely need the expressive power and can pay for it.

A caveat about that document, since I’ve been quoting it all lecture. The OWL two overview is explicitly a non-normative overview and roadmap. The language is defined normatively across several other specification documents, and the overview says in as many words that later ones may supersede it. It’s the right map. It isn’t the territory, and conformance decisions don’t live in it.

And the wider class of wrinkle I flagged at ELK, quickly, because it decides more afternoons than the theory does. Openllet has required Java eleven since its two point six point five release and its documented Protégé plugin wants a Protégé built on the five point one line of the OWL programming interface; HermiT’s documented release is one point three point eight, on version three point four point three of that same interface. Serialisations are spelling and convert freely. Versions are not spelling.

Now, something about what reasoners are actually good for in practice, because there’s a gap between the textbook pitch and the working reality.

The textbook pitch is that the reasoner derives valuable new knowledge at query time. That happens, and it’s real, particularly in classification-heavy domains.

The working reality, in my reading of how successful projects use this, is that the reasoner is most valuable as a contradiction detector during authoring. You have a hundred people editing a large ontology over ten years. Somebody adds an axiom in one branch that contradicts an axiom added six years ago in another. No human will catch that. The reasoner catches it every time, in the build. Treat classification as a continuous integration check on meaning, and the technology earns its keep even if you never run a single inference in production.

There’s a companion habit on the authoring side, and it turns a classified ontology from a wall of inferred parents into something you can interrogate. Protégé Desktop has a feature called the DL Query tab — shipped as both a tab and a view widget, in version four, version five, and later — which searches a classified ontology using class expressions written in Manchester OWL syntax. A class expression is just the compound description we built at the start of the lecture, written down: things that are aircraft and have more than one aisle. You describe a set, and it hands you back what falls into it. Because it works from the inferred relationships rather than the asserted ones, you can ask for the subclasses and superclasses of an expression nobody ever named, and get answers nobody ever typed.

The workflow is short. Start a reasoner — FaCT plus plus, or HermiT — to classify the active ontology, confirm the inferred hierarchy is populated, enter your expression, choose which kinds of result you want back. And if the query looks right, you can add it to the ontology as a newly named defined class. Dwell on that last move, because it’s the loop this whole technology exists for. You describe a set by its properties, you look at what falls into it, and only when the membership looks right do you give the set a name. Definition after inspection, rather than definition and then hope.

Two documented ways it goes wrong. Queries run only on a classified ontology, so until you’ve run the reasoner there is nothing to query. And matching individuals aren’t shown unless the individuals result option is ticked — the exact recipe for a query that looks correct, is correct, and returns nothing. There’s a broader tell too: if the inferred hierarchy contains only Thing and nothing beneath it, that isn’t an ontology with no structure. That’s classification having failed.

Let me give you two more things that come up the moment you use a reasoner in anger.

The first is explanation, and it’s the feature that turns a reasoner from a curiosity into a tool you can work with.

When a reasoner tells you your ontology is inconsistent, that’s useless on its own. Your ontology has four thousand axioms. Which ones are fighting? So the reasoners implement explanation. ELK will show you, step by step, how a logical consequence follows from your axioms. Openllet lists explaining inferences as one of its services alongside consistency and classification. You point at the conclusion and the machine walks you back to what produced it.

That’s the debugger. You get told that your class Widebody has been inferred to be equivalent to nothing — unsatisfiable, no possible members — and you ask for the explanation, and you get back three axioms. One says every widebody has more than one aisle. One says every aircraft in the regional fleet has exactly one aisle. And one, added by a colleague two years ago, says every widebody is in the regional fleet. Nobody could have found that by reading. The machine finds it in a second and hands you the three lines.

Which is why I’d say explanation, rather than inference, is what makes an ontology maintainable by more than one person over more than one year.

The second thing is the choice between computing entailments ahead of time and computing them when asked. This part is my own engineering reading rather than anything the specifications hand you, so take it as that.

You can run the reasoner once, write everything it derives into the store beside the statements you asserted, and then query the result with an ordinary engine that knows nothing about logic. That’s the shape the RL profile is built for. Queries get fast, and everything downstream is just data. What you pay is three things: the stored graph gets much bigger than the source you started from, updates get awkward, because adding one fact can entail many and retracting one means working out what depended on it, and you’re held to whatever profile your rule engine implements, with the sound-but-possibly-incomplete caveat we just went through.

Or you keep the reasoner in the loop and compute the entailments when somebody asks. Openllet is the worked example: it answers queries through Jena, through the OWL programming interface, or from its own command line, with the reasoner underneath the whole time. Nothing is stored twice, updates are trivially correct, and you get the full expressive power. And your query latency now depends on a reasoning problem whose worst case is the cliff I described a moment ago.

So, the claim to keep from this lecture.

Open-world semantics is the single idea that most often breaks a database engineer’s intuition, and every strange behaviour of a reasoner follows from it. Unstated means unknown, never false. That is why your reasoner will not complain about the order with no line item, why two identifiers can quietly turn out to be one aircraft, and why SHACL had to exist as a separate technology rather than as a feature of OWL. Everything else today — sets and pairs, TBox and ABox, the profiles and what each one costs — is machinery. That one assumption is the thing to carry out with you.

Next time, we put all of this into practice, and find out why an ontology project is really a governance project with a file attached.

7. Building One for Real

About 27 minutes spoken, 3,986 words. Plain text for a reader app: 07-building-one-for-real.txt

This is the seventh of ten talks about ontologies. The first three were the word and its history. Four, five and six were the engineering tradition — Cyc, the standards stack, and last time the machinery, where a reasoner computes what your axioms force to be true and the open-world assumption breaks a database engineer’s intuition. Today is practice. If you were handed a real project on Monday, what would you do, in what order, and where would it go wrong?

I’ll organise this around the sequence of decisions, because in my experience the order matters more than any individual choice.

Decision one, and it comes before you open an editor: write the competency questions.

A competency question is a question the finished ontology must be able to answer, written in plain language, before any modelling starts. Which suppliers ship components that appear in products currently under recall? Which nurses on shift tonight are certified for this procedure?

The term isn’t mine. The Common Core Ontologies document their design patterns as motivated by use cases and competency questions, and ship each pattern with a diagram and a query that answers it.

My practice on top of that: write twenty, get the people who’ll use the system to write them rather than the modellers, and keep them, because they are your acceptance tests. When somebody proposes a new class, the question is which competency question needs it. If none does, it doesn’t go in. That’s the strongest control on scope I know of.

It’s also Quine’s criterion from lecture three run backwards. He gave us a way to read commitments off a theory; competency questions start from the questions and derive the commitments those questions require.

Decision two: how many layers, and which foundation.

The layering is three deep. At the top, an upper ontology giving domain-neutral categories. In the middle, a mid-level ontology with reusable notions. At the bottom, your domain. That’s the arrangement the Common Core Ontologies describe for themselves — sitting between the most generic categories above and the domain-specific ontologies below.

BFO, the Basic Formal Ontology, is that layer above. It’s a small upper-level ontology meant to support retrieval, analysis and integration across scientific and other domains, and its defining trait is what it refuses to contain. It deliberately excludes physical, chemical, biological, and other terms belonging to the specialised sciences. Its own guidance is to use it as a domain-independent top-level framework beneath a specialised ontology, and more than five hundred and fifty ontology-driven efforts do exactly that. Do not expect it to hand you scientific vocabulary; the project explicitly places that outside its scope.

Below it sits the mid-level. The Common Core Ontologies, CCO, are the clearest example: eleven modules extending BFO, covering agents, events, time, qualities, measurement units, currencies, facilities, artifacts, information entities, geospatial entities and extended relations, with broadly reusable classes like person, facility, date, employment and measurement. Things every domain needs and no domain owns.

Other foundations make different bets, and the differences are real.

DOLCE — the Descriptive Ontology for Linguistic and Cognitive Engineering — has been stable since its release in two thousand and two, is formally specified in first-order logic, and has a published consistency proof. The catch its own documentation states is that the versions in OWL, the Web Ontology Language, are re-engineerings rather than identical releases: they omit modality and temporal indexing, and add descriptions and situations that official DOLCE does not cover. Adopt DOLCE in OWL and you have adopted an adaptation.

Gist is Semantic Arts’ minimalist upper ontology for enterprise use. Roughly one hundred classes and a similar number of attributes and relationships, familiar top-level concepts like person, organization and agreement, extensive high-level disjointness to expose inconsistent typing, and no inverse properties.

gUFO is a lightweight implementation of UFO, the Unified Foundational Ontology, aimed at OWL two applications in the description-logic profile. It selects a subset of UFO and separates a taxonomy of individuals — objects, aspects, events, situations — from a taxonomy of types: kinds, phases, roles, categories, relationship types. “Lightweight” is a deliberate trade-off, and its authors say so. Some intended constraints go undeclared because declaring them would break decidability: proper parthood is described as asymmetric and irreflexive, and both characteristics are left out of the implementation.

Worth seeing what adopting one looks like at the class level, because people imagine something more mystical than it is. gUFO’s own instruction is to reuse its domain-independent distinctions by specialising or instantiating its classes. A class of yours can at the same time specialise its object class and instantiate its kind class; the occurrences you record instantiate its event class and use the temporal properties it supplies. That’s the move. A foundation, as I read it, is not a layer you admire from below. It’s a set of parents and types you attach your own terms to, one term at a time.

Choosing among these isn’t a matter of quality. As I read it, it’s a matter of which commitments you want to inherit — and you will inherit them, because everything you build sits underneath them.

And you inherit an apparatus with them. BFO expects you to work with its guidebook, publications, tutorials, release history and user forums; DOLCE, which began as a module of the WonderWeb foundational ontologies library, sends you to OntoClean and to applied research on roles, qualities, organizations, artifacts and group agency. You are choosing a body of practice, not a top-level diagram.

Decision three: reuse before invention.

Reuse an existing term, extend an existing ontology, and only then mint something new. The Common Core Ontologies state the institutional version of this: their authors explicitly encourage users to publish their own domain extensions rather than expanding the core indefinitely with domain content. BFO states the same boundary from the other side by refusing scientific terms outright.

To reuse, you have to find things, and there are catalogues. The OBO Foundry — the Open Biological and Biomedical Ontology Foundry — is the one to know: a community effort to develop interoperable ontologies for the biological sciences, whose site pairs an ontology catalog with published principles and best-practice material. You can search or filter the table, consult the principles, or submit an ontology for consideration.

Reuse doesn’t only happen at the level of whole ontologies, and this is the place to say what a design pattern is, because I used the phrase at the top of the lecture and let it go past.

A design pattern is a documented, reusable treatment of a modelling situation that recurs — published as an artifact you can lift, not as advice you have to interpret. That’s why the Common Core patterns come with a graph, a visualisation and a query attached rather than a paragraph of guidance, and the query is the part that matters: it makes the pattern checkable instead of merely persuasive, because it is the pattern demonstrating that it answers the question it was written for. Their documentation recommends reusing those patterns when you map data into a knowledge graph, on the argument that it speeds up the mapping and the querying and improves consistency and interoperability between the people doing it. Which is the case for patterns entire: the win is not cleverness, it’s two teams solving the recurring problem the same way.

There is a community portal for patterns as such. It organises them by type and by domain, links patterns to the modelling issues that motivate them, collects exemplary ontologies, and runs training, open review and a quality committee.

And now the caution the catalogues state about themselves and people ignore anyway. Inclusion is not endorsement. The OBO Foundry’s home page presents principles, resources and catalog access, but it does not itself establish that every listed ontology satisfies every principle — selecting one still means examining that entry and its metadata yourself. The ontology design patterns portal is the same story: it still marks certified content as due to come, so presence in that catalogue is not certification either. Finding an ontology in a catalogue tells you it exists, and, as I read it, nothing more.

Decision four: identifiers and labels, and this is where projects acquire scars.

The rule that matters is that identifiers should be opaque and stable, and labels should carry the human-readable meaning. ELOT — the literate ontology-engineering environment — states it in those words: labels, not the compact identifiers, carry human-readable meaning. The Common Core Ontologies learned it the hard way. Their version two changed the IRI namespace — that’s the Internationalized Resource Identifier, the global name of a term — and adopted opaque local identifiers, and the release summary records no other ontology changes in that step. A whole release spent on identifiers.

The reason, as I read it, is one-way doors. Mint an identifier that spells out a term’s meaning, refine that meaning later, and you have a permanent lie in a name other people have already cited.

ELOT also documents the mechanical traps. Numeric-only counter identifiers are technically invalid as XML names, so an alphabetic counter template is recommended instead, and its slug scheme is lossy. Its position is that identifier policy belongs to each ontology rather than to the tool, with a documented menu — universally unique identifiers, label-derived slugs, formatted counters, registered custom schemes. Pick from it before the first commit, and enforce that in the build.

Decision five: which editor, and this is less consequential than teams believe.

Protégé is a free, open-source OWL ontology editor covering the whole lifecycle. Desktop Protégé does local modelling, reasoning and querying on a Java plug-in architecture; WebProtégé does the same work in a browser when several people need to collaborate. It’s also the assumed tool elsewhere: the Common Core Ontologies tell you to import their all-core file into Protégé to assemble the eleven modules.

And there’s a text-first tradition worth knowing about, because it fits how software teams already work. ELOT makes one plain-text notebook the ontology source and its documentation at once. The outline carries formal meaning: headlines declare classes, properties and individuals, nesting expresses the subclass hierarchy, and description-list rows attach annotations and axioms written in Manchester syntax. Queries and diagrams live in the same file as the prose. Its documentation says it has been used in scores of projects, including an ISO standard.

It’s also unusually honest about its own state, and that’s a property I’d weigh when choosing any tool here. Its documentation says outright that the long-form manual is under construction, that several manual files are stubs or drafts and may be inaccurate, and then names the documents that are reliable. It publishes a feature matrix across editors too: Emacs is the reference implementation and gets things first, while the Visual Studio Code extension marks queries, diagrams and the assisted-authoring features as planned rather than available. My view is that a tool telling you which parts of its own documentation to distrust should raise your confidence, not lower it.

Decision six: automate the lifecycle, because this is what separates a project that survives from one that doesn’t.

ROBOT is the workhorse — a tool for working with Open Biomedical Ontologies, available as a command-line program or as a library. Its documented commands cover annotation, conversion, diffing, extraction, filtering, materialisation, merging, querying, reasoning, repair, reporting, templating, profile validation, and verification. ELOT leans on it too: optional there, but required for conversion, queries, reasoning or reports.

That whole surface is reachable from a script, and my argument is that this is the point. Put it in continuous integration: every change classifies the ontology, checks the profile, runs the report, and fails if consistency broke. Encode the competency questions as queries in the same suite, so a change that breaks an answer fails the build rather than surfacing in a meeting six weeks later. Treat your ontology like source code and it behaves like source code.

WIDOCO — the Wizard for Documenting Ontologies — is the publication half, generating human-readable documentation from the ontology’s own annotations and folding in visualisation, an evaluation report, licence metadata, provenance, and changelogs computed between versions. Its advice is to keep that metadata inside the ontology as annotations rather than in a separate configuration file, because embedded metadata is easier to maintain across releases.

Decision seven: expect alignment, and budget for it.

We established in lecture three why this is permanent. Different purposes produce different commitments, so two correct models of the same domain will differ, and somebody has to write the mapping.

There is mature tooling. AgreementMakerLight, AML, is an automated, efficient matcher emphasising element-level matching supported by background knowledge. It runs between a source ontology and a target, in three modes — automatic matching, manual matching configured through a settings file, and alignment repair, where an existing alignment is the required input rather than an optional hint. Its authors report strong results across several shared evaluation tracks. One trap: it saves nothing unless you give it an output path.

LogMap is the other one to know, built for scale — semantically rich ontologies with tens or even hundreds of thousands of classes. It maps classes, properties and instances rather than classes alone, and it integrates reasoning and mapping repair to minimise logical inconsistencies in the alignments it produces. A large task can be divided into subtasks, and that division is a documented module rather than something you improvise. Its documentation is also honest about the cost of scale: newer Java versions need specific virtual-machine arguments, and the suggested configuration allows a heap of up to twenty-five gigabytes. That number is the caution.

Alignment is also where the large language models arrived first, and I’ll flag it here because it’s where this course ends up. LogMap’s documentation states that it supports validation by a large language model during matching, and points at related work described as using large language models as oracles for ontology alignment — oracle meaning, as I read it, that the matcher proposes a correspondence and the model is asked whether it holds. The same documentation records neighbouring work augmenting alignment with semantic or knowledge-graph embeddings and with distant supervision. Notice the role the model is given. It is not authoring the ontology and it is not deciding the alignment; it is consulted about one candidate correspondence at a time, inside a system that still does its own reasoning and its own repair. Hold that shape in mind. We come back to it at the end of the course.

Decision eight: version and deprecation policy, which has to exist before the first release.

Versioning an ontology is harder than versioning code, for one reason. Release version two of a library and consumers upgrade when they choose; old versions keep working. Release version two of an ontology and other people’s data already contains your identifiers — in published datasets, in papers, in databases you have never heard of. You cannot recall them.

The field’s answer is institutional. The OBO Foundry’s published principles include an identifier space, versioning, change notification, maintenance, stability of term meaning, and responsiveness — six of the sixteen are about not breaking the people downstream. Gist shows the other side: its major release fourteen broke compatibility with earlier versions, migration scripts were supplied, and the following release was backward-compatible again. Breaking changes happen; migration material is what makes them survivable.

There’s a consumer’s half of this, and the Common Core Ontologies are living it in public right now. Their repository is being modernised through structural changes planned across two coming releases, and the guidance says plainly what that means downstream: the Governance Board recommends waiting until after the later of the two before updating, and anyone who needs the current changes should take them from the development branch. That is a version policy doing its job — one answer for the patient, a documented route for the impatient. Ask it of every ontology you intend to depend on, and if nobody can answer, you have learned something about the project you were about to marry.

The metadata is mechanical, so automate it. WIDOCO’s guidance is to give the vocabulary a stable namespace and prefix, a licence, a version identifier and version information, and a link to the previous version — that last link is what lets it generate a changelog at all. Term annotations carry deprecation and status, running from unstable through testing and stable to archaic. Stamp those in the release process, because a file that doesn’t say which version it is ends up in four places at three versions.

Decision nine: documentation, and the gap between the file and what a human needs.

An ontology is not self-documenting, whatever anyone tells you. A class annotated “a customer” is documented in the same sense that a variable called data is documented. Textual definitions are one of the OBO Foundry’s principles, and WIDOCO’s checklist says the same at the term level: describe classes and properties with labels and definitions, and use the optional annotations for examples, original source, rationale, deprecation and status.

The one people skip — my addition, not theirs — is the negative definition. What the class deliberately is not. If your Order class does not cover cancelled orders, say so in the annotation, where the person integrating at midnight will read it. Otherwise they find out by writing a query that returns a slightly wrong number nobody notices for a year. WIDOCO renders all of this; it cannot write the definitions. Somebody has to, and writing a genuine definition is the best test of whether the class should exist, because a class you can’t define crisply will accumulate junk.

Now, four failure modes.

The first is scope creep, and it starts reasonably. Someone notices the model doesn’t cover a nearby case, so they extend it. Then another. Two years later nobody understands the whole thing, classification is slow enough that people stop running it, and no consuming system uses more than a fraction of the terms. The competency questions are what prevent this, which is why they’re decision one. And notice that BFO’s refusal to include scientific terms, and the Common Core’s instruction to publish extensions rather than grow the core, are institutional versions of the same defence. The foundations that lasted say no for a living.

The second is version drift, and this one is documented rather than folklore. The Common Core Ontologies warn their own contributors that different versions of the OWL programming interface and of Protégé can generate spurious formatting differences — your diff shows a thousand changed lines and one real edit. Their remedy is worth stealing: before substantive edits, make a token change, inspect the diff to see what your toolchain does to the file, and confirm the result still loads. Pin your versions, and treat an upgrade as a change requiring review.

And the version problem doesn’t stay inside the file; it runs through the whole tool chain. Read the installation notes rather than the front pages and you find ROBOT wanting Java eleven or later, the exporter that pulls existing models into ELOT wanting Java twenty-one or newer, and AgreementMakerLight naming the three Oracle Java releases it was tested against, stating that compatibility with OpenJDK — the open Java Development Kit — is not guaranteed, and advising you to download the built release rather than compile it, because the build reports errors. LogMap’s older interface branch is explicitly unmaintained. Individually none of that is interesting. Together it means a working pipeline pins several runtimes at once, and the rule I take from it is dull and it holds: your tool versions are part of your ontology’s build, so declare them and let the build fail when they drift.

Licensing belongs in the same honest paragraph, because it’s the other thing teams discover late and from the wrong person. Gist’s licence requires attribution — an obligation that arrives with the download and binds whatever you build on top of it. That’s why licence sits in the metadata list I read out a minute ago, and why the licence of every ontology you import belongs inside the ontology, before somebody asks the question in a procurement meeting.

The third is confusing syntactic success with semantic correctness. Your file parses. It passes the linter. That tells you nothing about whether it is consistent, or whether it means what you intended. This matters most when a language model is proposing edits, and ELOT shows both halves of the pattern. The guard rails: file writes are project-scoped, disabled by default, confirmation-gated, revalidated, and rolled back if revalidation fails. And the honesty: its documentation states plainly that the automatic validation checks lint and parsing, not semantic consistency, so the separate consistency check still has to run.

The same tool documents a smaller, mechanical version of the lesson: a freshly minted identifier cannot be used as the subject of an axiom in the same batch, so creating a term and then saying things about it takes two separate calls. That isn’t in the pitch, it’s in the pitfalls — which is where the working knowledge of every tool in this lecture turns out to live.

The fourth is the ontology that becomes an end in itself. The team spends more time on the upper ontology than on the domain. Debates about foundational categories run for weeks with no consuming system waiting on the answer. The class count grows faster than the query count. And when you ask which competency question a new branch serves, you get an answer about completeness. Completeness is not a goal. It’s the failure mode that Cyc’s forty years, from lecture four, should have inoculated this field against, and hasn’t, because building a beautiful model of the world is more fun than answering three tedious questions about shipments.

Two last things from experience rather than from the sources, and I’ll flag them as mine. Month one of a real project is not modelling; it’s competency questions, and discovering that two departments have used the same word differently for a decade. Month three should be the first small model that answers three of those questions end to end against real data, because that proves the pipeline.

And staffing: three roles, rarely the same person. Someone who knows the domain well enough to say when a distinction is real. Someone who knows the formalism well enough to say when a modelling choice will cause trouble in two years. And someone with the institutional standing to rule when two departments disagree about what a word means, and make it stick. The third gets left out of project plans, and it decides whether the thing ships.

Which is the point of the whole lecture, so let me finish there.

Who decides what a term means? What’s the deprecation policy when a term turns out to be wrong, given that other people’s data already cites it? Who is responsible in five years?

Those questions have institutional answers, not technical ones, and the projects in today’s sources answer them out loud. The OBO Foundry publishes principles covering authority, collaboration, change notification, maintenance and responsiveness, plus a submission route and working groups. The Common Core Ontologies have a Governance Board that tells users which release to wait for. Gist ships migration scripts, and namespace rules forbidding you from defining your own terms in its space. None of that is overhead attached to the real work.

So, the claim to keep. Write the competency questions first and use them as acceptance tests. Reuse before inventing, and don’t mistake catalogue inclusion for endorsement. Put the ontology in continuous integration with ROBOT. Budget for alignment, because it’s permanent. And understand what you’re setting up: an ontology project is a governance project with a file attached. The modelling is the easy half.

Next time, the case against everything I’ve just told you.

8. The Criticisms That Landed

About 30 minutes spoken, 4,416 words. Plain text for a reader app: 08-the-criticisms-that-landed.txt

This is the eighth of ten talks about ontologies. For seven lectures I’ve been explaining how this technology works and how to build with it, and last time I left you with a governance body that happens to produce a file. Today I’m going to make the case against the whole enterprise, as strongly as I can, using three critics who were right about different things.

I’ve put this lecture here deliberately. If you hear the criticism before you understand the machinery, it sounds like grumbling. Now that you know what a reasoner does and what a governance body costs, the criticism has something concrete to bite.

Three critics, three layers. Doctorow attacks the incentives. Shirky attacks the range of cases where the approach applies. Bowker and Star attack the consequences. In my judgement the first two have been substantially answered and the third has not.

Start with Cory Doctorow. His essay is called “Metacrap,” subtitled “putting the torch to seven straw-men of the meta-utopia,” first drafted in May two thousand and one and circulated in August — months after the Scientific American article.

That essay is routinely filed as the reply to that article. It isn’t. Doctorow never mentions the Scientific American piece, never mentions the Semantic Web, and never mentions Berners-Lee. His stated target is broader, and he says so in his opening: explicit, human-generated metadata, he writes, has enjoyed recent trendiness, especially in the world of X-M-L, the Extensible Markup Language. Read it as an attack on hand-declared metadata generally and it lands hard.

His thesis in one sentence: a world of exhaustive, reliable metadata would be a utopia, and it is also, and I quote, “a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities.” He gives what he calls at least seven insurmountable obstacles, and I’ll give you all seven, because the list is better than its reputation.

One. People lie. Metadata exists in a competitive world where suppliers compete for wallets and attention, and when poisoning the well benefits the poisoner, the water gets toxic fast. His examples are of their time — a search for a common term turning up a porn link in the first ten results, spam with subject lines reading “Re: the information you requested,” press releases with gargantuan lists of empty buzzwords — but the mechanism is permanent. Anyone who has looked at search engine optimisation has watched this happen in real time.

Two. People are lazy. Your clueless aunt sends email with no subject line. Half the pages on Geocities are called “please title this page.” Your boss stores files on his desktop called UNTITLED dot DOC. His test case is downloading ten random music files and finding that at least one has no title, artist, or track information — despite the ripping software having a button that fetches all of it in one click. This laziness, he says, is bottomless, and no amount of ease-of-use will end it.

Three. People are stupid, by which he means careless, and his example is the best in the essay. On eBay every seller has a strong financial incentive to spell a listing correctly, because a misspelled listing never appears in a correctly-spelled search and therefore attracts fewer bids and a lower price. Search eBay for “plam,” p-l-a-m, and you would find nine typoed listings for Plam Pilots. You can almost always get a bargain on a Plam Pilot. Money on the table, and people still get it wrong.

Four, and this is his own title: Mission Impossible — know thyself. In the meta-utopia everyone weighs their own stuff and accurately reports its properties. When Nielsen used log-books to gather the viewing habits of sample families, the results skewed heavily towards Masterpiece Theater and Sesame Street. Replacing the log-books with set-top boxes that reported what the set was actually tuned to showed what the average American family was really watching. People, in his phrase, are lousy observers of their own behaviours, and asking them to describe those behaviours in a form is asking for fiction.

Five. Schemas aren’t neutral. This is where the essay turns from mockery to argument, and it’s the part that has aged best. A manufacturer of small, environmentally conscious washing machines draws a hierarchy that leads with energy consumption, water consumption, and size. A manufacturer of glitzy, feature-laden machines leads with colour, size, and programmability. Both are honest. Neither is neutral. Any hierarchy of ideas asserts that some axes matter more than others, and the belief that competing interests will come to easy accord on a common vocabulary ignores the power of organising principles in a marketplace.

Six. Metrics influence results. A common yardstick privileges whatever scores high on it, regardless of overall suitability. Intelligence tests privilege people who are good at intelligence tests. His sharpest example: Nielsen couldn’t generate ratings for three-minute mini-programmes, so MTV couldn’t demonstrate the value of advertising on its network, so MTV stopped showing videos. A measurement system reached back and changed the thing it was measuring.

Seven. There’s more than one way to describe something. “No, I’m not watching cartoons, it’s cultural anthropology.” “This isn’t smut, it’s art.” Reasonable people can disagree forever about how to describe the same object, and requiring everyone to use one vocabulary, in his phrase, denudes the cognitive landscape.

Now, what does Doctorow actually conclude? Not that metadata is worthless. He says so explicitly. He endorses implicit metadata, and his example is Google, which at the time derived the reputation of a page from the number and quality of links pointing at it — data produced as a by-product of what people did, not as a declaration of what they claimed. That sort of observational metadata, he writes, is far more reliable than the stuff human beings create for the purpose of having their documents found.

Observed signal against declared signal is the durable core of the essay. My own gloss on why: the first four obstacles are all arguments against asking a person to declare something, and none of them has much purchase on a signal you simply record.

So use obstacles one to four as an incentive audit, two questions long. Who enters this data? And what do they gain from entering it well, compared with entering it badly? If the answer to the second is “nothing” or “less,” your ontology will fill with garbage no matter how good the model is. Use obstacles five to seven as a design review: name the axes your model privileges, and say out loud whose interests they serve.

That split has become more useful since he wrote it, not less, because language models cut the list in half. They change the economics of obstacles two, three, and four by extracting structure nobody wanted to type — laziness, carelessness, and being a poor witness to your own behaviour are all costs of making a person fill in a field. They do nothing at all about one, five, six, and seven, because those are about incentives and power rather than effort. So the half of the list that no interface improvement could fix is the same half no extraction can fix. That last conclusion is my inference from the shape of the list, not his claim; he was writing in two thousand and one.

Now Clay Shirky, and the essay “Ontology Is Overrated,” a heavily edited concatenation of two talks he gave in two thousand and five — one at the O’Reilly ETech conference in March, one at IMCExpo in April.

Shirky is more often cited than read, and what he actually says is narrower and better than the version that circulates. His own wording is that the strategy is both widely used and badly overrated in terms of its value in the digital world — and “in the digital world” is carrying as much weight there as “overrated.” His target is not classification. It’s ontological classification specifically, which he defines as organising entities by their essences and possible relations, and — this is the key part — designing categories in advance to cover cases that haven’t arrived yet. A library catalogue assumes that a new book’s logical place already exists in the system before the book does.

He starts by conceding the best case. The periodic table gets his vote for best classification ever. Organise elements by proton count and you get enormous descriptive and predictive value, and because you’re organising actual things, it’s about as close to essence as physical reality permits.

And then he finds the flaw, which I love. Look at the noble gases. Helium is no more essentially a gas than mercury is essentially a liquid. Helium is a gas at most temperatures, and the chemists who classified it couldn’t get it cold enough to see otherwise. So they took a property that holds at room temperature, absolutely unrelated to essence, and put it at the centre of the category. And it’s stayed there ever since, a frozen accident everyone has got used to.

His point: if a near-perfect scheme over physical essence still contains context errors, what chance does a domain with no essence at all have?

Then the libraries. Take the religion block of the Dewey Decimal Classification, the D-D-C — the two hundreds. Nine subdivisions in total: natural theology, Bible, Christian theology, Christian moral and devotional theology, Christian orders and local church, Christian social theology, Christian church history, Christian sects and denominations, and then two-ninety, “other religions.” Eight of the nine are Christian or Christian-adjacent, and everything else on earth is in the ninth.

That one’s easy to laugh off as period bias. The Library of Congress example is harder, and it’s the one that does the work. The L-C’s top-level categories under History run D-A Great Britain, D-B Austria, D-C France, D-D Germany, D-F Greece, D-G Italy — and then, presented as co-equal with those, D-R the Balkan Peninsula, D-S Asia, and D-T Africa. These are all top-level categories, all presented as co-equal. The Balkan Peninsula and Asia sit at the same level.

Shirky asks what’s being optimised, and rules out the obvious answers. It isn’t geography. It isn’t population. It isn’t regional economic output. The Library of Congress has a staff of people who do nothing but think about categorisation all day long.

What’s being optimised is the number of books on the shelf.

And then the line that carries the whole essay: the essence of a book isn’t the ideas it contains. The essence of a book is “book.” A book can be about several things at once, but the physical bound object can only be in one place, so it has to be declared to be about one main thing, regardless of its actual contents.

Which brings the punchline. In the digital world, there is no shelf. The physical constraint that produced hierarchical classification is simply gone.

And here’s his parable. Yahoo, faced with organising the web with no physical constraints at all, hired a professional ontologist and built a hierarchy. Go to their Entertainment category and you’ll find Books and Literature marked with an at-sign, which means the category isn’t really there. It’s a convenience link. To see those links you have to go where they really are, under Humanities. And when you get to Literature, booksellers aren’t really there either, because they’re a commercial service, so they’re really in Business.

Given the freedom to put anything anywhere, Yahoo added the shelf back. They couldn’t imagine organisation without it, so they reinstated the constraint and then told users which location was real.

Now, Shirky’s argument is regularly over-read into “ontologies are useless,” and he does not say that. But be careful with the part people quote back as his checklist, because it’s weaker than the version they repeat. He does not offer a test. What he offers, in his own words, is a partial list of characteristics that help make it work — nine of them, in two groups. On the domain: a small corpus, formal categories, stable entities, restricted entities, clear edges. On the participants: expert catalogers, an authoritative source of judgment, coordinated users, expert users. The more of those characteristics that are true, he says, the better a fit ontology is likely to be. That’s a description, not a decision procedure. Inverting it into a go/no-go screen for a project is my framing, and I’ll go on using it, but it isn’t his.

His worked positive examples are two: the periodic table, and the D-S-M-Four, the fourth edition of the psychiatrists’ Diagnostic and Statistical Manual, where the American Psychiatric Association is the authority that says what symptoms add up to what, and cataloguers and users are both expert. That people infrastructure, he says, is a big part of what makes it work, and it’s expensive. Turn the list over and you get the negative version — large corpus, no formal categories, unstable entities, no clear edges, uncoordinated and amateur users — which, as he observes, is an almost perfect description of the Web.

There’s a whole half of that essay I’ve left out, and leaving it out is what turns him into a demolition man. The full title is “Ontology Is Overrated: Categories, Links, and Tags,” and the links and the tags are a proposal.

His way in is a question about merging. Suppose you merged your personal library into the Library of Congress. Do you and the Librarian first have to sit down and reconcile your scheme with theirs? Of course not. They take your books and ignore your categories, because every book carries an I-S-B-N, an International Standard Book Number. The merge happens at the level of the globally unique item, not the category. The presence of unique labels, he says, means that merging libraries doesn’t require merging classification schemes. And on the web everything already carries such a label, because a web address is exactly that — so anybody can hang labels on those pointers without anybody first agreeing on a scheme.

That is a tag. Tags, in his phrase, are important mainly for what they leave out: forgoing formal classification is precisely what lets them produce organisational value at vanishingly small cost. He quotes the man who built the social bookmarking service delicious — each individual categorisation scheme is worth less than a professional one, but there are many, many more of them.

He also has the reply to the obvious objection, which is that free-form labels need a thesaurus to tidy them up — that if you say “movies” and I say “film” and somebody else says “cinema,” we should all be collapsed together. His answer is that those words encode different things, and that with genuinely contested vocabulary all the signal loss is in the collapse, not in the expansion. Which is Doctorow’s seventh obstacle arriving from the other direction, as a design principle rather than a complaint.

One last piece of his, because it hands the next critic their whole argument. Why do we know a sport utility vehicle is a light truck rather than a car? Because the government says it is. Shirky calls that voodoo categorisation, where acting on the model changes the world: when the government says it’s a truck, it is a truck, by definition. He raises it as a limit — most of the world, he says, is not amenable to voodoo, and nobody can settle whether Buffy the Vampire Slayer is science fiction because there’s no authority and no force to apply. Read it in the other direction, which is my move and not his: where the authority and the force do exist, naming really does change the thing named.

Which is the third critique, and the one I think is unanswered.

Geoffrey Bowker and Susan Leigh Star, “Sorting Things Out: Classification and Its Consequences,” published in nineteen ninety-nine. It’s not a technical book. It’s an ethnographic study, and in the words of Terrence Brooks, reviewing it, the effect of its examples is to illustrate how values, policies and modes of practice become embedded in large information systems and become expressed in classification systems.

I owe you a warning about how I know this, and it’s an awkward one to give in a lecture about hidden provenance. I have not read the book. What follows comes from Brooks’s review, from Stefan Helmreich’s review essay, and from Eric Nehrlich’s reading notes, so when I quote, I am quoting them quoting it. Take the next few minutes as second-hand, and go to the primary text before you build on it. Brooks’s verdict on what the book achieves is worth having up front: it is the accomplishment of this book, he writes, to recognise classification itself as an object of study, as a vehicle for ethnography.

Their first case is the International Classification of Diseases, the I-C-D, which sounds like the most neutral document imaginable. A list of diseases. Developing it took many years and there are still many disagreements over it. Tropical countries believe tropical diseases are grossly under-represented compared with rich-world diseases like cancer and heart disease. And there’s a detail I find unforgettable: in Japan a heart attack is considered a low-status way of dying, so death certificates will often list a stroke as the cause instead, which skews the results when they’re compared with other nations.

Their central concept is torque. Stefan Helmreich’s review essay gives the definition: the process that 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 don’t line up. Note both halves of that. A person’s own account of themselves fails to align with the system, and it is the person who gets twisted. The system wins.

Their extreme cases make it unmistakable. Tuberculosis patients, wholly dependent on a doctor’s diagnosis for their own status. And race classification under apartheid in South Africa, where citizens were tossed back and forth between being classified as White, then Coloured, then back again, and where a government declaration of your race forced you to change residence, job, and family. Helmreich walks one life through that machinery, and the detail is the argument. A South African boy, born of an Indian father and an African mother. At birth he is classified Asian, because a rule under the Group Areas Act has children living with the father’s side. Then he reaches the age of majority, and a different statute takes over — the Population Registration Act, under which he is expected to follow the station of the parent of lower racial status. So he becomes African, and is expected to shift his associations accordingly. Nothing about him has changed. Two laws disagreed about which parent counted, and the thing that moved was the person. Helmreich adds that the torsion could go further still: conceivably this man could later have tried, with some difficulty, to pass as Coloured, by cultivating work and residence associations with the appropriate people and avoiding the street-level classificatory challenge that might come from a police officer. A life spent managing a category. I read that as a category acting on a person rather than describing one — but that reading is my gloss, not theirs.

Then they do something cleverer, which is to show the same mechanism in an ordinary case with no villain. Nurses were asked to describe what they do so that it could be classified, standardised, and put into a billing system, and the result was the Nursing Interventions Classification, the N-I-C. Some nurses cheered that they would now be in the system. Others were aghast that they would no longer be free to do what they thought was right. Both reactions were correct. What the case makes evident is the tension between the system and the local adaptations you have to make for the system to function at all, and that tension runs through the whole book. Which gives the companion lesson, the one I’d write on the wall: there will always be elements that don’t slot neatly into a category, and that is a fact about the inadequacy of the system, not about the element. Their example is the platypus.

Their last point is about invisibility. Classification systems tend to get black-boxed, in the sense of Bruno Latour — that’s his term, and it’s the right one. They become infrastructure, and infrastructure is by definition the thing you stop noticing. We forget how much effort went into creating them, and the political and ethical issues bound up in their creation. What’s left looks like a description of how things simply are.

Put the cases and the black-boxing together and you get the book’s actual argument, which is not the one people expect from a critique. It is not that classification is avoidable. It is that classification is consequential and usually invisible, so the only real choice available to you is whether the consequences get examined.

Now, why do I say this critique is unanswered?

Because everything the technical field built answers a different question. Consistency checking, profile validation, alignment, provenance tracking — all of it measures the model against the world. Is the model coherent, does it fit the data, does it agree with that other model. Torque runs the other way. It’s the world being measured against the model, and a person losing.

There’s no reasoner for that. There’s no lint rule. The only mechanism that addresses it is a human process: someone in the room asking, when a real case doesn’t fit a category, who bears the cost. Helmreich puts the sharp end of it in a line — there is no experience of torque for those in power. So if the cost lands on someone who isn’t in the room, the modelling decision is a policy decision, and it should be made by people with the authority to make policy.

The book’s fair criticism comes from Brooks, the reviewer I quoted earlier. He objects that the examples pile on without advancing the argument, that the next step nobody has taken is establishing which classification characteristics are associated with which human, linguistic, or institutional ones, and that the book is strangely disconnected from the large body of empirical, cognitive research on classification that already exists. All fair. Take the case studies as demonstrations, not as a predictive theory.

Before I sum up, the defence, because I’ve given you three critics and no reply, and that isn’t a fair hearing.

Two years before the essay I just walked you through, in November two thousand and three, Shirky wrote a companion piece arguing that the Semantic Web is a machine for creating syllogisms, that it will therefore improve all the areas of your life where you currently use syllogisms, which is to say almost nowhere, and that it requires too much coordination and too much energy to effect in the real world. In two thousand and fifteen Dave McComb of the firm Semantic Arts published a direct rebuttal, and his central move is a joke at Shirky’s expense: that entire article, he points out, is itself a syllogism. Making it a premise of your argument that a thing will fail because nobody argues in that style is an awkward place to be standing. But notice what McComb does not claim. He does not claim the critics have been answered. His own sentence is that we still have a long way to go to staunch the critics, which is an unusually honest thing for a defender to write.

So let me say what I think each critique actually establishes, since that’s the thing a listener needs.

Doctorow establishes that declared metadata is unreliable in proportion to the incentive to misdeclare, and that no interface improvement fixes it. What he does not establish is that curated metadata fails. The successes the retrospectives themselves name — schema dot org, knowledge graphs, Wikidata, DBpedia, the biomedical ontologies — are governed, funded, bounded domains where somebody has an incentive to curate, and a curator on a funded biomedical ontology is not your clueless aunt filling in a form. His obstacles are about hand-annotating the open web, and the field moved off the open web: from annotating it by hand, to publishing linked datasets, to modelling a single enterprise.

The retrospectives draw a sequencing lesson out of that, and it is about incentives rather than semantics. A committee that specifies before anybody ships produces artifacts nobody adopts. Schema dot org worked partly because the search engines gave publishers a direct reason to comply: it was started by Google, Bing and Yahoo with the express purpose of delivering better search results. Then look at what its team are careful to state on their website — that they are not attempting to create a universal ontology. So the vocabulary that actually got adopted answers Doctorow by giving the people doing the declaring something they want, and answers Shirky by declining, in writing, to attempt the thing he says can’t be done. My reading is that those are one decision rather than two.

Shirky establishes that designing categories in advance is the wrong tool for a large, ill-defined corpus with uncoordinated, amateur users. What he does not establish, and does not claim, is that it’s the wrong tool everywhere. The periodic table and the D-S-M-Four both concede the point.

Bowker and Star establish that categories act on the people they classify, and that this is invisible by design. What they do not offer is a way to tell in advance which categories will torque, which is exactly what an engineer would want. Their contribution is to make you look, and looking turns out to be most of it.

So, the claim to keep from this lecture.

Three critiques, three different layers. Incentives, applicability, and consequences. The incentive argument has an answer: prefer observed signal over declared signal, and audit who benefits from lying. The applicability argument has an answer: Shirky’s characteristics, honestly applied before you start. The third, the consequences, is the one the field still has not answered. There is no technical reply to torque, only the discipline of asking, out loud and in the room, who pays when a real case doesn’t fit.

Next time, the company that took this word, kept about half of it, and built the most commercially successful thing anyone has ever called an ontology.

9. Palantir: The Ontology as an Operational Layer

About 29 minutes spoken, 4,140 words. Plain text for a reader app: 09-palantir-operational-layer.txt

This is the ninth of ten talks about ontologies. Last time we went through the three criticisms that landed. Today we look at the most commercially successful thing anyone currently calls an ontology, and work out what it has in common with everything we’ve studied and what it doesn’t.

I’m going to work almost entirely from Palantir’s own architecture documentation, because I want the description to be theirs rather than mine. The criticism comes next lecture. This one is about what the thing actually is.

Start with their own framing, which is more interesting than the marketing usually is.

Palantir’s architecture documentation says the Ontology is the system at the heart of their architecture, and that it is designed to represent the complex, interconnected decisions of an enterprise, not simply the data. Decisions, not data. Hold onto that, because everything else follows from it.

And there’s a second statement, which is the most useful piece of self-description in the whole document. They say, and I’m quoting: the Ontology is not a semantic layer. The fourfold integration and operationalisation of data, logic, action, and security cannot be accomplished with a thin semantic layer or a monolithic design.

So they’re distancing themselves from the whole category of “we put a vocabulary over your warehouse.” That description of the category is mine, not theirs, and it’s worth one sentence: a semantic layer sits between a warehouse and the people asking questions of it, so that revenue means one thing in every dashboard. It answers questions. It has no verbs. Let’s see what Palantir puts there instead.

The fourfold structure is data, logic, action, and security. I’ll take them in turn.

Data first. Their documentation describes it flowing in from every conceivable source — fragmented enterprise resource planning estates, homegrown systems of record, customer relationship systems, industrial databases, geospatial repositories, real-time sensors, document stores. Their phrase is “essentially any other digital alcove.” All of that gets unified into coherent objects, properties, and links.

It’s worth being precise about what it sits above, because they are. Not just datasets — integrated datasets, virtual tables, and models. And the reason for sitting there is the next thing they say: it connects those assets to their real-world counterparts. Their examples are plants, equipment, products, customer orders, financial transactions. So an object type is not meant to be a convenient grouping of columns. It’s meant to stand for the thing itself, with the datasets underneath being merely how the system happens to know about it. That’s a claim about reference, and I’d point out — this is my observation, not theirs — that it’s the same kind of claim the tradition we’ve been studying makes about its identifiers, arrived at from the opposite direction.

Now, the semantic elements. These are the nouns, and if you’ve followed the series they’ll look familiar with the labels changed.

An object type is the schema definition of a real-world entity or event. An object, or object instance, is one of them — a single real-world entity or event. An object set is a collection of them. Their worked example: you create an Employee object type defining the characteristics of all employees. An object is one employee, Melissa Chang, say. An object set is a group, like all tenured employees. Same pattern with a Flight object type, where an object is the specific flight from New York to San Francisco on a given date.

A link type is the schema definition of a relationship between two object types, and a link is one instance of that relationship. Employee to Employer. Flight to assigned Aircraft. Links can also run between two objects of the same type, which is how you model a manager and a direct report.

There’s a detail about link types worth noting because it shows the design thinking. A link type is bidirectional and has two sides, one for each object type, and each side is traversable independently with its own name. From code you call one side to get the aircraft assigned to a flight, and the other side to get all flights for that aircraft. Creating one link type does not implicitly create a reverse link type, because there’s no reverse to create — one link type already carries both directions. But you can define multiple distinct link types between the same two object types when they represent genuinely different relationships, like an assigned aircraft and a scheduled maintenance record.

And Palantir offers an analogy that I think is the most honest thing in their documentation, so let me give it to you exactly as they put it. An object type is analogous to a dataset. An object is analogous to a row. An object set is analogous to a filtered set of rows. A link type is analogous to a join between two datasets, and a link is analogous to a row joined with a row.

Sit with that for a second, because it tells you a great deal. Object types are tables. Objects are rows. Links are joins. That’s the semantic half of the Palantir Ontology, in their own words. It’s a very well-executed entity-relationship model over integrated data, with rich metadata and governance attached.

Now, if that were all, this lecture would be short and slightly deflating. It isn’t all, and the other half is the interesting part.

Palantir’s phrasing is that the nouns must be complemented by verbs, that semantics must be paired with kinetics. So the kinetic elements.

An action type is the definition of a set of changes to objects, property values, and links that a user can take at once, as a single transaction, along with the side effects that occur on submission. Their example: an Assign Employee action type that changes an employee’s role. It takes a parameter for the new role in a standardised form. It has rules for automatically creating a link between the employee and a new manager. It includes a notification side effect that tells the old and new manager. And it validates that only authorised employees, such as human resources staff, can perform it.

Read that specification again and notice what it contains: a state change, a schema for its input, a derived link, a notification to two named parties, and a permission check. All bundled as one named, invokable thing that sits in the model rather than in application code.

There’s a further piece of anatomy in their action-types documentation, which points onward to rules, parameters, and submission criteria. Three named parts. That passage doesn’t define them, so the mapping onto the worked example is mine rather than theirs: the parameter is the new role in its standardised form, the rules are what the action does to the data including the automatic link to the new manager, and the submission criterion is that only authorised human resources staff may put it through.

Hold those three apart, because a conventional application has all of them too. It just keeps them in different places — the form definition, the service method, and an authorisation check somewhere near the request handler, often written by three different people in three different quarters, and drifting apart quietly ever after. Declaring them together, as one named thing inside the model, is the design move. It is, as I read it, the move the field already made with nouns when it took the meaning of a column out of the application and put it in a schema, now applied to verbs.

Behind actions sit functions, which carry the logic. Palantir is explicit that this can be a simple business rule, a conventional machine learning model, a language-model-driven function, or a complex multi-step orchestration across several compute engines. The purpose they state for functions is to author and evolve business logic with arbitrary complexity, and both halves of that phrase are load-bearing. Arbitrary complexity means the model puts no ceiling on what sits behind a verb: the action type is a fixed, named, permissioned surface, and what runs underneath it may be one line of arithmetic or a fleet of models across several engines. Evolve means the logic is expected to change while the surface stays still. The noun holds, the name of the verb holds, and the reasoning inside is a moving part.

And there are interfaces, which describe the shape and capabilities of an object type and give you polymorphism, so different object types sharing a shape can be handled consistently.

Then there’s writeback, which is the bit I’d flag if you only remember one mechanism. Changes made through an action commit to the Ontology, appear in every application immediately, and are captured in the object type’s writeback dataset. Their documentation says the data asset grows in richness and value as user decisions and insights are captured as edits.

Think about what that means. Every operational decision anyone makes through the system becomes data in the system. The dispatcher who reassigns a shipment, the analyst who flags an exception, the manager who approves a plan — each of those becomes a durable record attached to the objects involved. The ontology stops being a description of the business and becomes a recording of it, including the reasoning.

Fourth element, security, and Palantir treats it as woven through the other three rather than layered on top. Their worked example is a medical manufacturer with plants, work orders, customers, inbound packages, and outbound shipments drawn from hundreds of sources. Production teams need global telemetry on machines and finished goods. Warehouse associates have restrictions by region. Supply chain analysts have row and column level restrictions on sensitive fields.

And then the part that shows where the product is heading. They point out that when teams build artificial-intelligence agents, those agents must have security scopes that either inherit from a human user or come from a project’s permission structure. The ability to trigger a purchase order might be tightly restricted while running a scenario to gauge the impact of a reallocation is more permissible, and the underlying optimisers and language-model calls might have different scopes again. Their claim is that the security system reconciles all of those policies at the moment of interaction, across tens of thousands of humans and agents.

They also describe the whole thing as, in many settings, a digital twin of the organisation, containing both semantic and kinetic elements. And they group the implementation into three parts: an Ontology Language that models the semantics, an Ontology Engine, and an Ontology Toolchain.

Right. Now the comparison, which is why this lecture exists.

Take the Palantir Ontology and the W three C stack and put them side by side.

One caveat before I do, because it governs how much weight the comparison can carry. Their documentation doesn’t mention OWL, or RDF — the Resource Description Framework — or the W three C, or reasoners, or world assumptions. They aren’t positioning against this stack. They give no sign of having it in mind at all. So everything that follows is my comparison and not their claim, and if any of it makes them look like they lost an argument, they were never in one.

With a single exception, and it’s a good one. Their type reference states that data types in Foundry — Foundry being the platform this Ontology sits at the centre of — are, and I’m quoting, inspired by similar concepts in RDF, OWL and XSD. So the debt is acknowledged, at the level of data types. What is not borrowed, on documentation that neither asserts nor denies it, is the semantics. You get the vocabulary of the formal tradition without the model theory underneath it. That, I’d argue, is the most useful single fact for understanding why this word causes so much trouble: the words travelled and the logic didn’t.

Both are trying to do the same fundamental thing, and it’s Gruber’s thing from lecture four: create a shared vocabulary that sits above heterogeneous systems that will never be rewritten, so that people and programs can talk about the domain in common terms. That’s a genuine shared ancestry, not a coincidence of naming.

Now the differences, and there are four that matter.

First, open world against closed world. OWL, the Web Ontology Language, assumes your data is a fragment of a larger world, so unstated means unknown. Palantir’s Ontology is a closed operational system for one organisation. If the shipment isn’t there, it isn’t there. That single difference explains most of the others, and honestly, for the enterprise use case, the closed-world assumption is the right one. We spent half of lecture six on how much trouble the open-world assumption causes people who don’t need it.

Second, reasoning. There’s no reasoner in the Palantir sense. Nothing derives subsumption. Nothing classifies your object types into an inferred hierarchy. Nothing tells you your model describes an impossible world. That capability, which the entire description logic tradition was built to provide, is absent. What you get instead is logic in functions, which is procedural code, evaluated when called.

Third, federation. OWL was built so anyone could publish and anyone could merge, using global identifiers. Palantir’s documentation states plainly that links between object types across different Ontologies are not supported, and suggests a shared Ontology instead. That’s a hard boundary, and it’s the closed-world assumption showing up in the architecture. And notice what the other tradition spends to keep federation available: OWL names one mandatory interchange syntax that every conformant tool must be able to exchange, so two parties who have never met can read each other’s ontologies at all. Palantir has no equivalent, because Palantir has no such requirement.

Fourth, and this is the one that runs the other way, actions and permissions are first-class. OWL cannot express “an authorised human resources employee may change this person’s role, which creates a link to the new manager and notifies both managers.” It has no vocabulary for that. It’s a language for what is, not for what may be done. There have been research efforts to bolt actions onto description logics and none of them are in common use.

There’s a fair objection to that fourth point and I want to take it, because the W three C stack does have something that resembles the validation half of an action. SHACL, the Shapes Constraint Language, exists to describe a graph by putting constraints on its content, its structure and its meaning, and it even carries rules that infer new statements. We went through its mechanics in lecture five. So isn’t that the missing piece?

No, and the reason is worth having. SHACL consumes a data graph and a shapes graph and emits a validation report, with a severity on each finding. That is the whole transaction: graphs in, report out. It tells you the state is wrong. It does not change the state, it does not notify anybody, it does not ask who you are, and nothing survives it to record that a person decided something. Palantir’s submission criteria and SHACL’s constraints look alike written down, and they sit at opposite ends of the sentence. One is a gate in front of an action. The other is a verdict on a graph.

So the honest summary is that the two traditions are trading in opposite directions. The W three C stack gives you deduction, open-world semantics, and public federation, and gives you nothing about action or permission. Palantir gives you action, permission, and writeback, and gives up deduction and federation.

Which raises the question of whether the word is being used honestly, and I want to be fair here.

If you take the term to mean an OWL file with model-theoretic semantics, then no, this isn’t one. If you take Gruber’s definition — an explicit specification of a conceptualization, shared, functioning as an interface between agents — then it qualifies comfortably. Object types and link types are an explicit statement of what kinds of things the organisation assumes exist and how they can relate. It’s shared, in that the whole company works through it. And it functions exactly as Gruber described: an interface specification, where the underlying systems keep their own internal representations.

By the definition the field actually adopted, it’s an ontology. It’s just an ontology in the tradition that descends from database modelling and enterprise integration rather than the one that descends from description logic. Both traditions have equal claim to the word, and the confusion is real, and now you can hear which one is being spoken.

One last observation, about why the kinetic half turned out to matter more than anyone expected.

When you connect a language model to an enterprise, the hard question is not what it can read. It’s what it can do. An agent with raw database access is unbounded and unauditable. An agent that can only invoke a fixed set of named actions, each with a typed parameter schema, each with validation rules, each with a permission check, each producing an audit record — that’s a governed system. The nouns give the agent something to reason about. The verbs give it a bounded set of things it can do and a record of what it did.

That’s my framing of it. Theirs is more specific, and it’s worth hearing because it names what they’re arguing against. Their pitch is that the Ontology lets language models go beyond, quoting again, the data-centric limitations of retrieval-augmented generation, and instead interface with the interconnected data, logic, and action primitives, through what they call an extensible tools paradigm. Retrieval-augmented generation is the framing being rejected, and the stated objection is that it is data-centric. It hands the model things to read.

What they put in its place they describe as a tool factory, one that lets builders define tools for both humans and agents, and they state that actions can be automatically surfaced as tools for artificial-intelligence-driven copilots and automations. The word to notice there is automatically. If the verbs are already declared in the model, with their parameters and their submission criteria and their permission checks, then the agent’s tool list isn’t a second artifact that somebody writes and then has to keep in step with the first one. It’s a projection of the model that already exists. And the same declaration serves the person clicking a button and the agent calling a tool, which is what they mean by tools for both.

Palantir has been building the verbs since well before the current wave of agents, for its own reasons. That work turns out to be the thing that matters when you put a language model in the loop, and it’s the part the semantic web tradition never built.

Two more things before I close, one about the product landscape and one about what this design is actually optimising for.

First, the landscape, because the word “semantic layer” that Palantir went out of its way to reject is a real category and you should know what they were rejecting.

Over the last decade a class of tools emerged whose job is to sit between a data warehouse and the people asking questions of it. You define metrics once — what revenue means, what an active user is, what counts as churn — and every dashboard, notebook, and report pulls that definition rather than reimplementing it. The problem being solved is genuine and painful: three teams computing revenue three ways and defending all three in the same meeting.

That’s a vocabulary layer. It’s a shared explicit conceptualization by Gruber’s definition, incidentally, though nobody in that market uses the word. And what it does not have is any notion of doing something. It answers questions. It has no verbs, no permissions on verbs, no writeback, no audit of decisions taken.

So when Palantir says “we are not a semantic layer,” the claim is specific and, on their own description, accurate. The distinguishing feature is that their model contains the actions. Whether that’s worth what they charge is a commercial question I have no view on. But the architectural claim is coherent, and it identifies a real gap in the category they’re distancing themselves from.

Second, and more interesting: what is this design actually optimising for?

I’d say it optimises for the round trip. Data comes in from the operational systems, gets assembled into objects, a human or an agent looks at those objects, decides something, invokes an action, the action writes back to the operational systems, and the decision itself is retained as data attached to the objects.

That loop is the product. Everything else serves it. The reason actions are first-class is that the loop needs a controlled way to close. The reason security is woven through rather than layered on is that the loop crosses trust boundaries at every step. The reason writeback exists is that a loop with no memory can’t be improved, and the reason they say the data asset grows richer as decisions are captured is that they’re accumulating a record of how the organisation actually decides, which is something no operational system holds.

Now compare that with what the W three C stack optimises for, which is the merge. Independent parties publish, graphs combine, identity is global, and a reasoner finds what follows from the combination. Everything in that stack serves the merge, which is why identifiers are global, why the world is open, and why there’s no notion of an action — an action is a thing one party does inside one system, and the merge doesn’t care.

Two different loops. Merge versus round trip. Once you see that, the divergence in every design decision follows, and neither tradition looks confused any more. They’re solving different problems and they both named the solution “ontology,” because both of them are, in Gruber’s sense, an explicit specification of what a domain contains.

There’s one more thing about the Palantir design that I think is under-discussed, and it’s the interface concept.

Recall that an interface describes the shape of an object type and its capabilities, giving polymorphism across object types that share a shape. That sounds like a minor convenience. It isn’t, if you think about what it enables. It means you can write an application, or a tool for an agent, against a shape rather than against a specific type. Something that handles anything with a location and a status, without knowing whether it’s a shipment, a vehicle, or a patient.

That’s the mechanism that lets one workflow generalise across an organisation without a central committee agreeing on a single model of everything. Which is, interestingly, a partial answer to the federation problem I said they had. You can’t link across ontologies, but you can write against a shared shape. It’s a weaker form of interoperability than global identifiers, and it may be the pragmatic one.

Let me end this lecture where the next one begins.

Everything I’ve described in this lecture is, from a technical standpoint, defensible engineering solving real problems that large organisations genuinely have. Integrating a hundred data sources is hard. Governing who can do what across tens of thousands of people is hard. Giving an agent a bounded set of permitted actions rather than a database connection is straightforwardly the responsible design.

And every one of those capabilities has a second face when the organisation is a police force rather than a manufacturer.

The object type that unifies a hundred sources into one view of an entity is the same mechanism whether the entity is a shipment or a person. The link type that lets you traverse from a flight to its aircraft to its maintenance history is the same mechanism that traverses from a person to their contacts to their contacts’ records. The action type with its permission check and its notification is the same mechanism whether the action is reordering stock or dispatching officers. And the writeback that turns every decision into data is the same mechanism whether the decision is a schedule change or a determination about a human being.

None of that makes the engineering wrong. It makes the deployment context the whole question, which is exactly what the last lecture is about.

So, the claim to keep.

Palantir’s Ontology pairs semantic elements — object types, properties, links — with kinetic elements — actions, functions, dynamic security — and commits user decisions back as data. It has no reasoner, no open-world semantics, and no federation across ontologies. It expresses actions and permissions, which the W three C stack cannot express at all. The two traditions share Gruber’s definition and almost nothing else.

Next time, the final lecture: what happens when an ontology like that is installed inside a state institution, and what all of this means now that machines can read.

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

About 26 minutes spoken, 3,751 words. Plain text for a reader app: 10-politics-and-what-comes-next.txt

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.

Ontologies: A Ten-Lecture Course

Ten lectures, twenty to thirty minutes each, about four hours ten total at a narration pace of one hundred and forty-five words per minute. Written to be listened to rather than read. Transcripts live in transcripts/ as plain text files, numbered in listening order.

Length follows the sources. Each lecture runs exactly as far as the notes listed for it carry it, and no further, so the files differ in length by a third or more. Shipped word counts:

Every claim traces to a note in this repository. The source notes are listed per lecture below, and the transcripts name their sources aloud where it matters.

Design constraints

• Solo lecturer. One voice, spoken prose, no bullets, no code, no URLs, no section headings inside the transcript. Anything a narrator cannot say out loud has been cut or rewritten.
• One sitting per file. Twenty to thirty minutes at about 145 words per minute. There is no word target. Quality is the constraint and length is the by-product: a lecture stops when its notes are spent.
• Self-contained openings. Each lecture starts by saying where it is in the arc, because listeners on a walk lose the thread between sessions.
• One recap beat. Each lecture ends by stating the single claim it wants retained, then stops. No summary-of-the-summary.
• Acronyms expanded on first use in every lecture, since listeners may start anywhere.

The arc

Lectures one to three establish what the word means and where it came from. Four to seven are the engineering tradition, ending with how you would actually build one. Eight is the criticism. Nine and ten are Palantir and the present. The criticism deliberately lands after the listener knows how the machinery works, so it argues with something concrete.

Lecture plans

1. Three Things People Mean by “Ontology”

Claim to retain: The word names a philosophical discipline, a specific theory of what exists, and a machine-readable file. Most confusion in this field is one of those three senses being swapped for another.

Beats: the airport-conversation problem; sense one, the branch of philosophy; sense two, a particular philosopher’s ontology; sense three, the artifact; Gruber’s definition read slowly; why “explicit” and “shared” are the load-bearing words; what an ontology is not (a database schema, a taxonomy, a knowledge graph); the promise of the series.

Sources: notes/gruber-ontology-definition.md, notes/ontology-word-history.md, notes/skos-simple-knowledge-organization-system.md, notes/scigraph.md, SYNTHESIS.md.

2. From Aristotle to Wolff: Where the Word Came From

Claim to retain: Ontology began as the search for the single true account of being, and the engineering version quietly dropped that ambition while keeping the vocabulary.

Beats: Aristotle’s “being qua being” and why first philosophy is not physics; the two-thousand-year gap before the word; Lorhard 1606; Goclenius 1613 and the Clauberg misattribution; Wolff 1730 and the demonstrative method; general versus special metaphysics as the ancestor of upper versus domain ontologies; Kant’s demolition; Husserl’s formal ontology; what survived the transfer to computing and what did not.

Sources: notes/ontology-word-history.md, notes/bfo-basic-formal-ontology.md, notes/common-core-ontologies-cco.md.

3. Quine, and Ontology as a Property of Theories

Claim to retain: To be is to be the value of a variable — Quine’s own wording, not the familiar “bound variable” version, which is Boolos’s later title. Ask not what exists, but what your model must quantify over to be true.

Beats: the problem of non-being; the move from world to theory; the criterion stated plainly; worked example on an employee schema; why the criterion is silent about truth; why that silence makes ontology alignment permanent rather than embarrassing; the structural resemblance between Quine’s criterion and Guarino’s construction, which cites neither the other.

Sources: notes/quine-ontological-commitment.md, notes/gruber-ontology-definition.md, notes/ontology-matching.md, notes/alignment-api.md.

4. The Cathedral: Cyc, and the Birth of the Engineering Sense

Claim to retain: The computer-science sense of “ontology” was invented to solve a sharing problem between knowledge-based systems, and its founding project bet everything on a critical mass it never reached.

Beats: expert systems and the knowledge-acquisition bottleneck; Lenat and Shepherd starting Cyc in 1984 knowing the odds; what codifying common sense requires — causality, time, space, substances, intention, belief; the peanut butter and table example; a million hand-crafted axioms; the DARPA Knowledge Sharing Effort and why sharing, not reasoning, produced the definition; Gruber 1993; Borst’s addition of “shared”; the lesson about deferred payoff.

Sources: notes/cyc-lenat-1995.md, notes/gruber-ontology-definition.md, notes/cyc.md, notes/description-logics-dls.md.

5. The Semantic Web: A Vision and the Stack It Built

Claim to retain: Every awkward feature of the standards is an answer to a requirement in the 2001 article, and most of those requirements assumed an open web of strangers.

Beats: the Pete and Lucy scenario read out; what it demands technically; RDF as the merge-without-coordination data model; the URI as global identity; why triples and not tables; RDFS as the small vocabulary; OWL as the expressive one; SPARQL as the query layer; SHACL and ShEx as the validation layer that arrived late and mattered more than expected; serializations as spelling rather than substance; the four phases and where the energy went.

Sources: notes/semantic-web-2001-vision.md, notes/rdf-resource-description-framework-1-1.md, notes/rdf-schema-rdfs-1-1.md, notes/owl-2-web-ontology-language.md, notes/sparql-1-1.md, notes/shacl-shapes-constraint-language.md, notes/turtle.md, notes/json-ld.md.

6. How the Machinery Actually Works

Claim to retain: Open-world semantics is the single idea that most often breaks a database engineer’s intuition, and every strange behaviour of a reasoner follows from it.

Beats: description logic as the mental model; concepts as sets, roles as pairs; TBox and ABox; what a reasoner computes — subsumption, membership, consistency; the classification example; the open-world assumption spelled out with a worked case; no unique name assumption; why absence proves nothing; the expressivity and complexity trade; OWL profiles EL, QL, RL and what each buys; why validation with SHACL is a different job from inference with a reasoner.

Sources: notes/description-logics-dls.md, notes/owl-2-web-ontology-language.md, notes/elk.md, notes/hermit.md, notes/openllet.md, notes/shacl-shapes-constraint-language.md, notes/dl-query-class-expression.md.

7. Building One for Real

Claim to retain: An ontology project is a governance project with a file attached. The modelling is the easy half.

Beats: competency questions before classes; layered reuse and why BFO excludes scientific terms; mid-level ontologies; picking a foundation and what DOLCE, gist, and gUFO each commit you to; design patterns and why the pattern catalogue is not a certification; identifiers and the label-carries-meaning rule; Protégé and the editor spectrum; automation with ROBOT and documentation with WIDOCO; alignment as its own discipline; version and profile compatibility as an operational fact; the scope-creep failure mode.

Sources: notes/bfo-basic-formal-ontology.md, notes/common-core-ontologies-cco.md, notes/gist.md, notes/gufo.md, notes/dolce-descriptive-ontology-for-linguistic-and-cognitive-engineering.md, notes/ontologydesignpatterns-org.md, notes/protege.md, notes/robot.md, notes/widoco.md, notes/obo-foundry.md, notes/elot.md, notes/agreementmakerlight-aml.md, notes/logmap.md.

8. The Criticisms That Landed

Claim to retain: Three critiques, three different layers. Incentives, applicability, and consequences. The third is the one the field still has not answered.

Beats: Doctorow’s seven obstacles with the eBay and Nielsen examples; schemas are not neutral, washing machines both ways; what Doctorow concedes about implicit metadata; Shirky’s periodic table and noble gases; Dewey’s 200s and the Library of Congress on Asia and Africa; there is no shelf; the parable of the Yahoo ontologist; Shirky’s real preconditions restated as a checklist; Bowker and Star on the International Classification of Diseases, apartheid reclassification, and the Nursing Interventions Classification; torque; black-boxing; what each critique does and does not prove.

Sources: notes/doctorow-metacrap.md, notes/shirky-ontology-is-overrated.md, notes/bowker-star-sorting-things-out.md, notes/semantic-web-retrospective.md.

9. Palantir: The Ontology as an Operational Layer

Claim to retain: Palantir’s Ontology adds verbs and permissions to the nouns, which is exactly what the W3C stack cannot express, and it drops the logic, which is exactly what the W3C stack is for.

Beats: what Palantir actually says in its own architecture documentation; the fourfold integration of data, logic, action, and security; object types, objects, object sets, link types and their two sides; the dataset analogy Palantir itself offers; action types as transactions with parameters, validation, and side effects; functions and interfaces; writeback, so decisions become data; digital twin framing; the explicit claim that it is not a semantic layer; the head-to-head with OWL on open versus closed world, reasoning, and federation; why the agent story makes actions the important half.

Sources: notes/palantir-ontology.md, notes/owl-2-web-ontology-language.md, notes/shacl-shapes-constraint-language.md, notes/gruber-ontology-definition.md.

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

Claim to retain: 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.

Beats: the Danish POL-INTEL study and its two senses of ontology; the getaway-vehicle example; platformisation and the redistribution of skill; the German constitutional court ruling of February 2023 and the bystander problem; why this is Bowker and Star with a contract attached; what a responsible review of an operational ontology asks; then the present — can a language model replace an ontology, build one, use one; the three answers; the guarded pattern from ELOT; closing verdict on when to build one and when not to.

Sources: notes/palantir-ontology-critique.md, notes/bowker-star-sorting-things-out.md, notes/llm-ontology-debate.md, notes/ontolearner.md, notes/ontoaligner.md, notes/elot.md.

Listening in ElevenReader

Upload the ten files in transcripts/ in order. They are plain text with no markup, so nothing is read aloud that should not be. See VOICE.md for the narrator setup.

Narration setup

Michael Caine

ElevenLabs launched an Iconic Marketplace with Sir Michael Caine as a partner. His licensed voice is available inside the ElevenReader app to narrate books, articles, PDFs, and uploaded text.

It is not in the shared voice library and not reachable through the ElevenLabs API. So the route is the app, not a generated MP3:

1. Open ElevenReader on the iPhone.
2. Add each file from transcripts/ as a document (they are plain .txt).
3. Pick Michael Caine from the Iconic voices.
4. Play in order, 01 through 10.

Ten files, one per walk, eighteen to twenty-four minutes each.

Why the transcripts are shaped this way

Everything a narrator cannot say has been kept out: no headings, no bullets, no markdown, no code, no URLs. Verified by grep — the files contain none of these. Acronyms are expanded on first use in every lecture, because you may start anywhere in the series.

Numbers, dates, and Latin phrases are written the way they should be spoken (1606, scientia entis in genere). Text-to-speech handles both correctly.

If you want MP3 files instead

The Caine voice cannot be generated through the API, so an offline render needs a different narrator. A British male narration voice from the shared library works; generate per file with the ElevenLabs text_to_speech tool at stability around 0.4 and speed 1.0.

Cost check first: about 29,000 words, roughly 165,000 characters across the ten files. Confirm the character allowance before rendering all ten.

Ontology Synthesis

What ontologies are

Across these materials, an ontology is best understood as an explicit, shared model of a conceptual domain: it names the kinds of things that matter, the relations among them, and axioms whose formally defined meaning lets software do more than string matching. notes/scigraph.md notes/owl-2-web-ontology-language.md

The ecosystem separates several layers that are often casually conflated. notes/rdf-resource-description-framework-1-1.md notes/owl-2-web-ontology-language.md RDF is the labeled directed multigraph foundation—subject–predicate–object statements identified mainly by IRIs—while Turtle, JSON-LD, RDF/XML, N-Triples, and the other concrete syntaxes are serializations of that abstract graph, not different conceptual models. notes/rdf-resource-description-framework-1-1.md notes/turtle.md notes/json-ld.md RDFS adds a deliberately small modeling vocabulary for classes, instances, subclass and subproperty hierarchies, global domains and ranges, labels, and comments. notes/rdf-schema-rdfs-1-1.md OWL 2 adds a more expressive ontology language for classes, properties, individuals, data values, restrictions, keys, property chains, cardinalities, and other axioms, with Direct Semantics for OWL 2 DL and RDF-Based Semantics for arbitrary OWL-as-RDF graphs. notes/owl-2-web-ontology-language.md Description logics supply the underlying mental model: concepts denote sets, roles denote ordered pairs, a TBox states terminological structure, an ABox states facts about individuals, and reasoners answer questions about subsumption, membership, relations, and consistency. notes/description-logics-dls.md

A taxonomy is therefore one useful shape of ontology, not the whole idea. notes/skos-simple-knowledge-organization-system.md SKOS intentionally represents thesauri, classifications, and subject-heading systems as URI-identified concepts with multilingual labels, broader/narrower/associative links, collections, and cross-scheme mappings, while explicitly distinguishing those concepts from OWL classes and formal facts about how the domain itself is arranged. notes/skos-simple-knowledge-organization-system.md Likewise, a knowledge graph can contain ontology-governed data, but “graph-shaped” alone does not imply formal ontology semantics: SciGraph, for example, loads an OWL-centered model into a useful but explicitly lossy Neo4j representation that cannot round-trip the ontology and is not itself an authoring or reasoning system. notes/scigraph.md

The recurring architecture is layered reuse. notes/bfo-basic-formal-ontology.md notes/common-core-ontologies-cco.md An upper ontology supplies domain-neutral categories—BFO deliberately excludes specialized scientific terms—while a mid-level layer such as CCO adds reusable notions such as agents, events, measurements, facilities, and information entities, and separately maintained domain extensions add the local subject matter. notes/bfo-basic-formal-ontology.md notes/common-core-ontologies-cco.md Other foundations make different commitments: DOLCE’s official release is a first-order-logic axiomatization, gist aims for a small enterprise-oriented core with extensive high-level disjointness, and gUFO is a lightweight OWL 2 DL implementation of a selected UFO subset. notes/dolce-descriptive-ontology-for-linguistic-and-cognitive-engineering.md notes/gist.md notes/gufo.md This makes ontology engineering less like inventing a universal dictionary and more like choosing explicit commitments at the right level, reusing stable identifiers and patterns, and keeping domain scope visible. notes/common-core-ontologies-cco.md notes/ontologydesignpatterns-org.md

Ontologies also sit beside, rather than replace, validation and query languages. notes/shacl-shapes-constraint-language.md notes/sparql-1-1.md SHACL and ShEx make expected RDF node shapes executable and report whether data conforms, whereas OWL reasoners derive consequences under formal semantics; SPARQL matches graph patterns and returns bindings, constructed graphs, existence answers, or service-defined descriptions. notes/shacl-shapes-constraint-language.md notes/shex-shape-expressions.md notes/sparql-1-1.md In practice, a healthy ontology project therefore has several artifacts and checks: identifiers and definitions, axioms, mappings, competency questions or queries, documentation, provenance, release metadata, and governance. notes/common-core-ontologies-cco.md notes/widoco.md notes/obo-foundry.md

The landscape

Languages and standards

• Graph and interchange foundation: RDF defines the graph model; Turtle favors readable authoring, JSON-LD carries linked data in familiar JSON, TriG and N-Quads represent datasets or named graphs, and HDT targets compact storage with search operations over large RDF datasets. notes/rdf-resource-description-framework-1-1.md notes/turtle.md notes/json-ld.md notes/trig.md notes/n-quads.md notes/hdt.md
• Ontology semantics: OWL 2 is the central W3C ontology language, with EL, QL, and RL profiles that trade expressivity for large-ontology classification, relational-query access, or rule-oriented RDF processing; OBO Flat File Format 1.4 supplies a biomedical-community syntax with a defined mapping to OWL 2 DL. notes/owl-2-web-ontology-language.md notes/obo-format-obof.md
• Broader logical choices: Common Logic is an ISO framework for first-order-logic interchange, while Notation3 extends compact RDF notation with RDF-based rules and SWRL proposes Horn-like rules combined with OWL DL or OWL Lite. notes/common-logic-cl.md notes/notation3.md notes/swrl-semantic-web-rule-language.md
• Constraint and schema layer: SHACL and ShEx validate RDF structures, while LinkML authors a schema once in YAML and can generate validation or implementation artifacts including SHACL, ShEx, OWL, JSON Schema, SQL, and programming-language types. notes/shacl-shapes-constraint-language.md notes/shex-shape-expressions.md notes/linkml.md
• Query layer: SPARQL 1.1 is the general RDF query language; SPARQL-DL instead gives a substantial SPARQL subset semantics directly in terms of OWL-DL entailment, and Protégé’s DL Query tab searches a classified ontology using Manchester class expressions. notes/sparql-1-1.md notes/sparql-dl.md notes/dl-query-class-expression.md

Authoring, collaboration, and publication

• Protégé is the general-purpose editor presented here: Desktop supports local OWL 2 modeling, reasoning, and querying, while WebProtégé provides collaborative browser editing and a Java plug-in ecosystem surrounds the desktop application. notes/protege.md
• Different interfaces serve different modelers: Eddy uses the Graphol visual language with design-time validation and OWL 2 export, Fluent Editor uses controlled natural language, OWLGrEd emphasizes whole-ontology graphical editing, and VocBench supports collaborative multilingual OWL, SKOS/SKOS-XL, OntoLex-lemon, and generic RDF assets. notes/eddy.md notes/fluent-editor.md notes/owlgred.md notes/vocbench.md
• Text-first engineering is viable: ELOT makes one Org document the formal source, documentation, hierarchy, query notebook, and diagram workspace, while Tawny-OWL constructs OWL programmatically in a Clojure DSL and yamlpyowl offers a YAML representation backed by Owlready2. notes/elot.md notes/tawny-owl.md notes/yamlpyowl.md
• Automation closes the lifecycle: ROBOT covers conversion, extraction, merging, querying, reasoning, repair, reporting, templating, profile validation, and verification; OnToology reacts to GitHub changes by proposing generated documentation, diagrams, evaluation, and JSON-LD context; WIDOCO produces standards-aware documentation, provenance, visualizations, evaluation, and version changelogs. notes/robot.md notes/ontoology.md notes/widoco.md
• Libraries embed ontology work in applications: OWL API and Apache Jena provide Java integration surfaces, Owlready2 exposes OWL entities and HermiT reasoning as Python objects, FunOWL mirrors OWL functional syntax in Python, and Horned OWL and Owlish provide Rust data structures and processing. notes/owl-api.md notes/apache-jena-ontology-api.md notes/owlready2.md notes/funowl.md notes/horned-owl.md notes/owlish.md

Reasoning, alignment, and access

• Reasoners are chosen by semantic profile and workload, not by a single “best” ranking: ELK and CEL target tractable EL-family classification, Openllet provides broad OWL 2 DL services, HermiT implements OWL 2 Direct Semantics with hypertableau reasoning, and OWL-RL materializes RDFS/OWL 2 RL consequences by forward chaining in RDFLib. notes/elk.md notes/cel.md notes/openllet.md notes/hermit.md notes/owl-rl.md
• Alignment is its own engineering problem: AgreementMakerLight emphasizes efficient automated matching, LogMap combines large-scale matching with reasoning and inconsistency repair, OntoAligner offers a modular classical/retrieval/LLM/RAG/embedding/ensemble pipeline, and the Alignment API supplies a shareable RDF correspondence format. notes/agreementmakerlight-aml.md notes/logmap.md notes/ontoaligner.md notes/alignment-api.md
• Repositories and catalogs are entry points, not substitutes for evaluation: BioPortal supports biomedical browsing, annotation, recommendation, mappings, and APIs; Linked Open Vocabularies catalogs vocabularies and terms; BARTOC spans terminologies and registries; OBO Foundry couples a biological ontology catalog with community principles. DBpedia Archivo adds automated Web discovery, persistent snapshots, and minimum-viability signals for retrievability, licensing and interoperability, and consistency; its stars are not a quality ranking. notes/bioportal.md notes/linked-open-vocabularies.md notes/bartoc-basel-register-of-thesauri-ontologies-classifications.md notes/obo-foundry.md notes/dbpedia-archivo.md
• Smaller access tools solve bounded jobs: OAK spans adapters, mappings, graph operations, validation, changes, and similarity; obonet reads OBO into a NetworkX multigraph; Tarql maps CSV rows to RDF through SPARQL 1.1 syntax; and SciGraph exposes OWL-centered data as Neo4j, vocabulary, annotation, and REST services. notes/oak.md notes/obonet.md notes/tarql.md notes/scigraph.md

Public knowledge bases and linked-data resources

• General-purpose resources expose different kinds of knowledge: Wikidata is a community-editable structured-data hub with a SPARQL service; ConceptNet is an open multilingual semantic network with assertion-level source metadata and a JSON-LD API; and Cyc is presented as a commercial logic-and-common-sense reasoning platform whose fetched page supplies product positioning rather than technical ontology or evaluation detail. notes/wikidata.md notes/conceptnet.md notes/cyc.md
• Integrative and historical resources require version context: KBpedia maps seven public sources into a shared ontology and graph; the fetched YAGO page describes a Wikipedia-, WordNet-, and GeoNames-derived knowledge base but identifies itself as an unmaintained old project page; Freebase is a frozen 2007–2015 dump with Wikidata mappings and no live API; and the archived NELL publication offers RDF releases with several provenance representations. notes/kbpedia.md notes/yago.md notes/freebase.md notes/nell-ontology-and-knowledge-base.md
• Ecosystem-scale resources show connectivity and provenance, with limits: the Linked Open Data Cloud maps qualifying linked datasets and publishes diagram data; BTC 2019 preserves source-document context in more than two billion crawled quads but is heavily dominated by Wikidata; and the fetched Mosaic Knowledge Graphs source is only an archive wrapper, so it supports no capability claims about the underlying application. notes/the-linked-open-data-cloud.md notes/billion-triple-challenge-btc-2019-dataset.md notes/mosaic-knowledge-graphs.md

Alternative upper and mid-level foundations

• SUMO combines an upper ontology with extensive formal and lexical infrastructure: it is written in SUO-KIF, mapped to all of WordNet, extended by domain ontologies, and distributed through tooling and translations for theorem proving, Neo4j, and OWL. notes/sumo-suggested-upper-merged-ontology.md
• GFO and YAMATO emphasize different foundational theories and maturity profiles: GFO covers objects, processes, time, space, roles, functions, facts, and situations and offers a stable OWL core, while its documentation records incomplete tutorial and axiomatization material and possible inconsistency among parallel extensions; YAMATO highlights theories of quality and quantity, representations, and objects, processes, and events, with downloadable Hozo and OWL files and reported domain uses. notes/gfo-general-formal-ontology.md notes/yamato-yet-another-more-advanced-top-level-ontology.md
• MILO is a bridge rather than another top level: it connects SUMO’s abstract categories to more specific domain vocabulary through KIF declarations, relation constraints, functions, and logical and temporal rules. notes/milo-mid-level-ontology.md

Users and use-cases

The use-cases are unusually broad: GO supplies evidence-backed cross-species gene-function annotations, Uberon integrates animal anatomy, and FoodOn standardizes foods and production processes in the OBO ecosystem. notes/gene-ontology-go.md notes/uberon.md notes/foodon.md FIBO supports shared financial meaning and cross-system federation, CIDOC CRM mediates heterogeneous cultural-heritage records, UCO standardizes cyber-investigation and security concepts, OEO supports energy-system analysis terminology, and Digital Buildings maps physical spaces, equipment, telemetry, and relationships for portable building analytics. notes/fibo.md notes/cidoc-crm-conceptual-reference-model.md notes/unified-cyber-ontology-uco.md notes/open-energy-ontology-oeo.md notes/digital-buildings-ontology-dbo.md Cross-domain vocabularies solve narrower reusable problems: PROV-O exchanges provenance, OWL-Time models instants, intervals, duration, and temporal position, Dublin Core supplies broad metadata properties, Schema.org publishes a large Web-oriented type hierarchy, and GoodRelations describes products and services for machine consumption. notes/prov-o.md notes/owl-time-time-ontology.md notes/dcmi-metadata-terms.md notes/schema-org-schemas.md notes/goodrelations.md

Ontologies + LLMs

The notes contain a small number of direct, documented LLM integrations and a much larger body of non-LLM graph, reasoning, and ML work; the distinction matters because an ontology or knowledge graph used for search, embeddings, or symbolic inference is not automatically an LLM application. notes/ontoemma.md notes/digital-buildings-ontology-dbo.md notes/materials-data-science-and-informatics-awesome-fair-data.md

Learning and construction

OntoLearner provides the clearest end-to-end ontology-learning account in the notes. notes/ontolearner.md It frames learning as term typing, taxonomy discovery, and non-taxonomic relation extraction, with a separate Text2Onto path for extracting terms and types from raw text. notes/ontolearner.md Its LLM-only learners rely on model-internal knowledge, retriever-only learners index training examples as embeddings, and RAG learners retrieve similar ontology examples as domain-specific few-shot context before generation; earlier task outputs may feed later tasks, but tasks can also run in parallel. notes/ontolearner.md Text2Onto additionally uses a Hugging Face generation backend to create synthetic documents, enriching prompts with term-typing, taxonomy, and non-taxonomic graph context so generated passages remain closer to the source ontology. notes/ontolearner.md The documented guidance is conditional rather than triumphant: pure LLMs are recommended mainly for general or well-known domains, RAG for specialized domains, and LLM/symbolic or multi-model ensembles for higher-stakes reliability. notes/ontolearner.md Clear prompts and structured output reduce but do not eliminate hallucination and inconsistency, so labels and relationships still need validation against representative held-out data, multiple metrics, domain criteria, and classical baselines. notes/ontolearner.md Large retrieval contexts can cause memory problems, and nonstandard ontologies can require custom extraction and ontology-specific blank-node filtering. For Text2Onto specifically, the documentation says it works best with instruction-tuned models and ontology context that fits the model window; it presents stricter structured-output validation, repair retries for missing labels, richer graph-context retrieval, and candidate reranking as possible improvements rather than framework-wide requirements. notes/ontolearner.md

A curated Semantic Web list names OntoGPT as a tool for populating semantic schemas from unstructured text with LLMs, but that note records only the directory entry and does not establish a detailed extraction method or evaluation result. notes/semantalytics-awesome-semantic-web.md The same list names SPARQLLM as allowing SPARQL queries to call search engines, LLMs, or vector databases during query execution; again, this is a linked resource description rather than a verified capability study in the harvested note. notes/semantalytics-awesome-semantic-web.md

Alignment and validation

OntoAligner implements direct LLM matching by turning candidate concept pairs—optionally with parent or child context—into yes/no prompts and mapping generated output back to match labels. notes/ontoaligner.md Its documented LLMs4OM RAG flow retrieves target candidates for each source concept and asks an LLM to verify each pair, with concept-only, parent-context, child-context, few-shot, and in-context-vector variants; ensembles can combine these signals with lexical, structural, retrieval, and knowledge-graph-embedding matchers. notes/ontoaligner.md Direct all-pairs LLM matching is quadratic and documented as appropriate only for small ontologies of roughly 200 concepts or fewer, while RAG narrows candidates and logit scoring reduces GPU cost; parser assumptions, context-encoder mismatches, and dataset-specific thresholds remain operational risks. notes/ontoaligner.md

LogMap’s README states that matching can use LLM validation and links LogMapLLM work describing LLMs as alignment oracles, while LogMap itself contributes scalable matching, reasoning, and inconsistency repair. notes/logmap.md That is an explicit project claim but not, in the harvested note, a detailed account of prompts, metrics, or validation guarantees, so it should not be stretched beyond “LLM-assisted mapping validation is supported and associated work is linked.” notes/logmap.md By contrast, OntoEMMA’s learned matcher is logistic regression or an AllenNLP neural network, with no LLM or RAG integration stated; calling every learned alignment pipeline “LLM-based” would erase an important category boundary. notes/ontoemma.md

Agentic authoring, linting, reasoning, querying, and editing

ELOT documents the most complete agentic ontology-engineering loop in the collection. notes/elot.md Its optional Emacs elot-gptel integration lets an LLM inspect resources and conventions, search labels, lint, issue SPARQL queries, invoke ROBOT-backed consistency, unsatisfiability, and explanation checks, mint identifiers under project policy, and edit or restructure the literate ontology source. notes/elot.md The mutation surface is deliberately guarded: writes are project-scoped, disabled by default, confirmation-gated, automatically linted and parsed, and rolled back on failed revalidation. notes/elot.md Those automatic mutation checks establish syntax and OWL parsability, not semantic consistency, so a separate consistency check is still required; moreover, a newly minted CURIE cannot be used as an axiom subject in the same batch. notes/elot.md The feature is also editor-specific in the documented matrix: Emacs is the reference implementation, while VS Code marks AI-assisted authoring, SPARQL, and diagrams as planned. notes/elot.md

Natural language to SPARQL and adjacent retrieval patterns

The Python ecosystem list explicitly describes LangChain’s GraphSparqlQAChain as generating SPARQL SELECT and UPDATE from natural language, executing against files, endpoints, or triple stores, and returning natural-language responses. notes/pysemtec-semantic-python-overview.md Because this evidence comes from a curated overview whose authors warn that it may be incomplete and biased, it establishes that the integration is listed and characterized that way, not its accuracy, safety, or production readiness. notes/pysemtec-semantic-python-overview.md A separate directory lists LoRiS for generated natural-language representations of SPARQL queries over Wikidata and DBpedia, but this is query verbalization in a resource list, not evidence of a general conversational ontology agent. notes/semantalytics-awesome-semantic-web.md

Two further pages merely point outward: OAK’s documentation index contains a guide titled “How to use Large Language Models (LLMs) with OAK,” and LinkML’s index contains “How to Generate AI prompts,” but neither harvested page states the guide’s method or capability. notes/oak.md notes/linkml.md A knowledge-graph directory similarly lists a book about putting graphs from structured and unstructured sources into LLM and RAG applications and says Termboard can use common chatbots, but the note is a catalog description rather than primary implementation evidence. notes/totogo-awesome-knowledge-graph.md

Finally, several tempting examples are explicitly KG-only or non-LLM in these notes: CCO recommends reusable graph patterns for mapping and querying, Digital Buildings uses its inheritance graph for navigation and search expansion, FAIR resources include graphs and conventional ML extraction, and OntoEMMA uses classical/neural matching without an LLM. notes/common-core-ontologies-cco.md notes/digital-buildings-ontology-dbo.md notes/materials-data-science-and-informatics-awesome-fair-data.md notes/ontoemma.md

Pitfalls

• Open-world semantics defeats database-style intuition: absence of a fact does not imply its negation, different names need not identify different things, and SKOS deliberately defines few integrity conditions. notes/description-logics-dls.md notes/skos-simple-knowledge-organization-system.md
• More expressivity is not free: richer description-logic operators raise inference complexity, OWL profiles restrict the language for particular implementation benefits, and tableau reasoning can become intractable through large disjunctions, cardinalities, existential expansion, or many different-individual assertions. notes/description-logics-dls.md notes/owl-2-web-ontology-language.md notes/openllet.md
• Syntactic success is not semantic correctness: ELOT’s automatic LLM-edit validation checks linting and parsing but requires a separate consistency run, while OWL 2 warns that rule-based RL reasoning can be sound yet incomplete outside its structural and query conditions. notes/elot.md notes/owl-2-web-ontology-language.md
• Representation conversions can be partial or lossy: SciGraph’s OWL-to-Neo4j mapping cannot round-trip and omits some SKOS arrangements, while obonet’s ontology edge direction conflicts with everyday NetworkX ancestor/descendant intuition and collapsing to a simple graph discards relationship distinctions. notes/scigraph.md notes/obonet.md
• Identifiers and names require policy, not improvisation: RDF alone does not make producers agree on identifier semantics, while ELOT documents XML-name-invalid numeric counters, lossy slug schemes, and the principle that labels—not CURIEs—should carry human-readable meaning. notes/rdf-resource-description-framework-1-1.md notes/elot.md
• Scope creep harms reuse: BFO deliberately excludes specialized scientific content, CCO tells adopters to publish domain extensions rather than expand the common core indefinitely, and Digital Buildings advises reusing types before proposing validated extensions. notes/bfo-basic-formal-ontology.md notes/common-core-ontologies-cco.md notes/digital-buildings-ontology-dbo.md
• Version, profile, and tool compatibility are part of the model’s operational life: CCO warns that different OWL API and Protégé versions can produce spurious diffs, HermiT documents specific OWL API and plug-in compatibility boundaries, and gist had a major release that broke compatibility and required migrations. notes/common-core-ontologies-cco.md notes/hermit.md notes/gist.md
• Domain transfer and generic parsing assumptions can fail: Digital Buildings marks some guidance as Google-campus-specific. Taken together, the OntoAligner and OntoLearner documentation shows that generic parsing or extraction depends on common RDF/OWL constructs and requires customization when an ontology represents labels, hierarchies, or other semantics differently. notes/digital-buildings-ontology-dbo.md notes/ontoaligner.md notes/ontolearner.md
• Catalog inclusion is not endorsement or current maintenance: OBO Foundry’s homepage does not prove every listed ontology satisfies every principle, OntologyDesignPatterns.org says catalogue presence is not certification, and curated directories explicitly warn of abandoned, stalled, incomplete, or biased listings. notes/obo-foundry.md notes/ontologydesignpatterns-org.md notes/semantalytics-awesome-semantic-web.md notes/pysemtec-semantic-python-overview.md
• LLM assistance adds scaling and trust problems rather than removing ontology engineering: Taken together, OntoAligner and OntoLearner document quadratic matching, dataset-specific thresholds, hallucination, context, validation, and baseline concerns. A separate authoring example, ELOT, keeps mutation confirmation, rollback, and separate semantic checks. notes/ontoaligner.md notes/ontolearner.md notes/elot.md

Where the idea came from

The word is older than the technology by about four hundred years, and the two senses have never fully separated. Aristotle named the subject in Book IV of the Metaphysics as “first philosophy,” the study of being qua being. The Latin ontologia first appears in Jacob Lorhard’s Ogdoas Scholastica in 1606, with priority contested, and was put into circulation by Christian Wolff in 1730, who defined it as the science of being in general as being, and who split general metaphysics from special metaphysics in a way that resembles the later split between upper and domain ontologies. notes/ontology-word-history.md notes/bfo-basic-formal-ontology.md

Quine made the idea tractable for engineers by moving the question. Instead of asking what exists, “On What There Is” asks what a theory must quantify over for its statements to be true. Ontology becomes a property of a language rather than a claim about reality, which is the form the engineering discipline inherited. notes/quine-ontological-commitment.md

Gruber’s 1993 definition — an explicit specification of a conceptualization — created the computer-science term, and Borst added the requirement that the conceptualization be shared. Guarino, Oberle and Staab later reconstructed conceptualization formally because the informal wording had produced years of argument. notes/gruber-ontology-definition.md Cyc, the era’s largest knowledge-engineering programme, is the field’s reference experiment on the cost side: the largest sustained attempt to answer how much of the world must be written down before a knowledge base pays off, at a person-century of effort by 1995. notes/cyc-lenat-1995.md

The 2001 Scientific American article moved the idea to web scale and set the design brief that RDF and OWL answer, with SPARQL arriving later to query the result. notes/semantic-web-2001-vision.md notes/rdf-resource-description-framework-1-1.md notes/owl-2-web-ontology-language.md notes/sparql-1-1.md The open-web version did not arrive; the machinery survived in governed domains and was rebranded around knowledge graphs after 2012. notes/semantic-web-retrospective.md notes/knowledge-graph-turn.md The retrospective’s own summary is that the survivors are “governed, funded, bounded domains where somebody has an incentive to curate.” notes/semantic-web-retrospective.md The corpus’s own success stories fit that pattern across gene function, anatomy, food, cultural heritage, finance, cyber investigation, energy, and buildings. notes/gene-ontology-go.md notes/uberon.md notes/foodon.md notes/cidoc-crm-conceptual-reference-model.md notes/fibo.md notes/unified-cyber-ontology-uco.md notes/open-energy-ontology-oeo.md notes/digital-buildings-ontology-dbo.md

Criticism worth answering

Three critiques have survived and each attacks a different layer. Doctorow’s “Metacrap” attacks the incentive layer: voluntary metadata fails because people lie, are lazy, are careless, and misjudge themselves, and because schemas and metrics are never neutral. His constructive residue is the distinction between observed signal and declared signal: he endorses implicit metadata, produced as a by-product of behaviour, citing Google’s use of link structure. notes/doctorow-metacrap.md

Shirky attacks the applicability layer. His target is narrower than usually reported: designing categories in advance to cover cases that have not happened yet, applied to unbounded corpora with uncoordinated cataloguers and untrained users. His library examples show that a classification optimises for its physical substrate rather than for concepts, and his Yahoo example shows designers reimposing that constraint after it disappeared. notes/shirky-ontology-is-overrated.md

Bowker and Star attack the consequences layer, and on the evidence of this corpus it is the critique the technical sources engage with least. Categories act on people. Their concept of torque names what happens when a person and a classification disagree and the classification wins. notes/bowker-star-sorting-things-out.md That argument becomes concrete and legal once an ontology is installed inside a state institution. notes/palantir-ontology-critique.md

These do not overturn the pitfalls already listed in this document. They add a category of pitfall the standards do not cover, because open-world semantics, profile complexity, and lossy conversion are all failures of the model against the world, while torque is a failure of the world against the model.

Operational ontologies: the other tradition

Palantir’s Ontology uses the word for something else, and it belongs to a different lineage than the W3C stack. Palantir’s own architecture documentation says it models the interconnected decisions of an enterprise rather than its data, and states outright that it is not a semantic layer. It pairs semantic elements, meaning object types, properties, and link types, with kinetic elements, meaning action types, functions, and interfaces, enforces security across data, logic, and action at once, and commits user edits back as data. notes/palantir-ontology.md

The contrast with OWL is instructive in both directions. OWL has model-theoretic semantics, an open-world assumption, reasoners that derive consequences, and public shared vocabularies, none of which the Palantir Ontology has. The Palantir Ontology has actions and permissions as first-class primitives, which OWL cannot express at all. The comparison is this corpus’s, not Palantir’s: its documentation never mentions OWL, the W3C, reasoners, or world assumptions. notes/palantir-ontology.md notes/description-logics-dls.md notes/owl-2-web-ontology-language.md A team choosing between them is choosing between deriving what follows and governing what may be done.

Ontologies after large language models

The corpus documents tooling that uses models to learn, align, and author ontologies, with consistent warnings about hallucination, quadratic matching cost, dataset-specific thresholds, and the gap between syntactic validity and semantic correctness. notes/ontolearner.md notes/ontoaligner.md notes/elot.md The broader argument about replacement is separate and worth keeping separate: whether a model can replace an ontology, build one, and use one are three different questions, and this corpus answers them differently. notes/llm-ontology-debate.md

Learning path

1. Begin with the data model, not an editor: read the RDF note until the abstract graph is clearly separate from RDF/XML, then read Turtle and JSON-LD as contrasting concrete serializations. notes/rdf-resource-description-framework-1-1.md notes/turtle.md notes/json-ld.md
2. Learn the lightest semantic layer: use RDFS to understand classes, instances, subclass hierarchies, labels, and the inference meaning of global domains and ranges. notes/rdf-schema-rdfs-1-1.md
3. Learn when a vocabulary is not a formal domain theory: study SKOS labels, schemes, collections, and mappings, especially its explicit distinction between thesaurus concepts and OWL classes. notes/skos-simple-knowledge-organization-system.md
4. Add formal ontology semantics: read the description-logics note for TBox/ABox, open-world semantics, and the expressivity/complexity trade-off, then use the OWL 2 overview to map those ideas onto language features, profiles, syntaxes, and semantics. notes/description-logics-dls.md notes/owl-2-web-ontology-language.md
5. Author one small ontology in Protégé: create classes, properties, individuals, labels, and a few restrictions, then classify it and try Manchester class expressions in the DL Query tab. notes/protege.md notes/dl-query-class-expression.md
6. Query data directly: work through SPARQL’s triple patterns, optional and alternative patterns, named graphs, property paths, SELECT, CONSTRUCT, ASK, ordering, aggregation, and limits. notes/sparql-1-1.md
7. Separate inference from validation: compare an EL reasoner such as ELK with an OWL 2 DL reasoner such as Openllet, then encode data expectations in SHACL or ShEx and inspect machine-readable validation results. notes/elk.md notes/openllet.md notes/shacl-shapes-constraint-language.md notes/shex-shape-expressions.md
8. Study layered reuse and governance: compare BFO, CCO, and a domain ontology such as GO, then read OBO Foundry’s principles and OntologyDesignPatterns.org’s pattern-oriented workflow before designing a larger model. notes/bfo-basic-formal-ontology.md notes/common-core-ontologies-cco.md notes/gene-ontology-go.md notes/obo-foundry.md notes/ontologydesignpatterns-org.md
9. Automate repeatable engineering: use ROBOT for transformations and checks, WIDOCO for release documentation and provenance, and OnToology to understand repository-triggered generation and review. notes/robot.md notes/widoco.md notes/ontoology.md
10. Embed ontologies in software: choose Owlready2 for a Python object model with reasoning, Jena or OWL API for Java, and OAK for a higher-level multi-adapter utility surface; inspect obonet only when the bounded OBO-to-NetworkX job fits. notes/owlready2.md notes/apache-jena-ontology-api.md notes/owl-api.md notes/oak.md notes/obonet.md
11. Learn alignment after single-ontology work is comfortable: start with the matching problem and evaluation community, then compare AgreementMakerLight, LogMap’s logic-aware repair, and OntoAligner’s modular classical-to-LLM spectrum. notes/ontology-matching.md notes/ontology-alignment-evaluation-initiative-oaei.md notes/agreementmakerlight-aml.md notes/logmap.md notes/ontoaligner.md
12. Approach LLMs last, with baselines and guards: reproduce OntoLearner’s LLM-only, retrieval, and RAG distinctions, compare OntoAligner’s retrieval-narrowed alignment, and study ELOT’s confirmation, rollback, lint, parse, and separate semantic-check boundaries before allowing model-written ontology changes. notes/ontolearner.md notes/ontoaligner.md notes/elot.md

Glossary

Every term the lectures and notes use, in one alphabetical list. Concepts are defined here. Tools, languages, and vocabularies link to their note.

# · A · B · C · D · E · F · G · H · I · J · K · L · M · N · O · P · Q · R · S · T · U · V · W · Y

Other

[protege-user] which is the best query language for owl ontologies? — A 2016 Protege-user mailing-list reply comparing DL Query, SPARQL, and SQWRL for querying OWL ontologies.

A

A List of Ontology Engineering Tools (Ontology Editors) — This is an archived directory of ontology-engineering tools and their websites.

ABox — The assertional part of a knowledge base: the individuals and the facts about them, as opposed to the class definitions in the TBox.

AgreementMakerLight (AML) — AgreementMakerLight is an automated, efficient ontology-matching system with a flexible, extensible framework.

Alignment — Finding correspondences between entities in two different ontologies so data described by one can be read through the other.

Alignment API — The Alignment API is a Java API and implementation for expressing and sharing ontology alignments.

Apache Jena Ontology API — The Jena Ontology API is a Java programming interface for working with RDF-backed RDFS and OWL ontologies.

Apollo — Apollo was a Java-based, user-friendly knowledge-modeling application designed for varied knowledge-representation needs.

Association for Ontology Design & Patterns (ODPA) — The fetched source does not contain the requested ODPA association page; it resolves to the OntologyDesignPatterns.org main page.

Axiom — A statement in an ontology’s formal vocabulary whose consequences a reasoner can derive.

B

BARTOC (Basel Register of Thesauri, Ontologies & Classifications) — BARTOC is a site that unites information about terminologies and terminology registries.

BFO (Basic Formal Ontology) — BFO is a small upper-level ontology intended to support information retrieval, analysis, and integration across scientific and other domains.

Billion Triple Challenge (BTC) 2019 Dataset — BTC 2019 is an open dataset produced by an LDspider crawl of RDF/XML, Turtle, and N-Triples documents from 12 December 2018 to 11 January 2019.

BioPortal — NCBO BioPortal presents itself as a comprehensive repository of biomedical ontologies that is free and open to all users without login.

Bowker and Star, “Sorting Things Out” (1999) — An ethnographic study of classification systems and information infrastructure, and the deepest criticism of ontology work in this corpus.

buaaliuming/Awesome-Knowledge-Bases — Awesome-Knowledge-Bases is a compact curated page of currently available knowledge bases, ontologies, knowledge graphs, and taxonomies, maintained for quick use and survey.

Built Environment Ontology Lookup Service (BE-OLS) — BE-OLS is a platform for discovering, exploring, and evaluating built-environment ontologies.

C

CEL — CEL is a lightweight description-logic reasoner aimed at large-scale biomedical ontologies.

CIDOC CRM (Conceptual Reference Model) — CIDOC CRM is a formal ontology and information-integration framework for cultural heritage documentation.

CLARIAH/awesome-humanities-ontologies — A curated directory of ontologies, vocabularies, terminologies, and taxonomies for modelling and publishing Humanities datasets as Linked Data.

Classification — The reasoning task of computing the full subclass hierarchy implied by an ontology’s axioms.

Closed-world assumption — Treating anything not stated as false. F-logic, SPIN constraints, and Palantir’s Ontology work this way. OWL does not.

Common Core Ontologies (CCO) — CCO is a suite of eleven ontologies containing logically defined generic terms and relations intended to cover entities across domains.

Common Logic (CL) — Common Logic is an ISO-published framework for a family of first-order-logic-based languages intended to exchange and transmit knowledge between computer systems.

ConceptNet — ConceptNet is a freely available, open multilingual semantic network intended to help computers understand word meanings.

Conceptualization — The abstract model of a domain that an ontology is a specification of, in Gruber’s 1993 definition.

Consistency checking — Asking a reasoner whether an ontology is consistent, which is a separate question from whether an individual class is satisfiable.

costezki/awesome-semantic-tools — A compact curated list of projects related to ontology engineering and Semantic Web technologies.

Criticism of Operational Ontologies (Palantir) — The research and legal record on what happens when a vendor ontology is installed inside a state institution.

cwm — cwm is a general-purpose Semantic Web data processor and forward-chaining reasoner for querying, checking, transforming, and filtering information.

Cyc — Cyc is presented as an enterprise machine-reasoning AI platform that uses codified human common sense and knowledge rather than patterns and statistics.

Cyc as a Knowledge-Engineering Programme (Lenat 1995) — Douglas Lenat’s article “CYC: A Large-Scale Investment in Knowledge Infrastructure” describes the Cyc project, begun with Mary Shepherd in 1984, as an attempt to hand-codify common sense.

D

D3FEND — The fetched page is the MITRE D3FEND ontology-resource hub, distributing the entire current D3FEND model.

DBpedia — DBpedia presents itself as global, unified access to knowledge graphs and as a major Linked Open Data resource built from Wikipedia-language editions and Wikidata.

DBpedia Archivo — DBpedia Archivo is an ontology archive that automatically discovers OWL ontologies on the web, checks them every eight hours, and persistently archives changed snapshots on the Databus.

DBpedia Ontology (DBO) — The DBpedia Ontology is described as the heart of DBpedia: a shallow, cross-domain ontology that began from commonly used Wikipedia infoboxes and evolved through community-maintained ontology schema and infobox mappings.

DCMI Metadata Terms — DCMI Metadata Terms is the authoritative specification of metadata terms maintained by the Dublin Core Metadata Initiative.

Description logic — A family of languages more expressive than propositional logic and less expressive than first-order logic, forming the logical foundation of OWL and trading expressive power against reasoning complexity.

Description Logic Complexity Navigator — A web navigator maintained by Evgeny Zolin for complexity results about reasoning in Description Logics.

Description Logics (DLs) — Description logics are a family of formal knowledge-representation languages, generally more expressive than propositional logic and less expressive than first-order logic.

Digital Buildings Ontology (DBO) — Digital Buildings is an Apache-licensed schema and toolset for representing structured information about buildings and installed equipment.

DL Query (class expression) — The DL Query tab is a Protégé Desktop feature for searching a classified ontology with class expressions based on Manchester OWL syntax.

Do Language Models Replace Ontologies? — The live argument about whether large language models make hand-built ontologies unnecessary, obsolete the labour of building them, or increase their value.

Doctorow, “Metacrap” (2001) — Cory Doctorow’s essay against voluntary metadata, version 1.0 dated 15 May 2001 and version 1.3 dated 26 August 2001 — months after the Scientific American article, though Doctorow never mentions it, the Semantic Web, or Berners-Lee.

DOLCE (Descriptive Ontology for Linguistic and Cognitive Engineering) — DOLCE is a foundational ontology developed and maintained by the ISTC-CNR Laboratory for Applied Ontology.

Dublin Core Metadata Element Set — The Dublin Core Metadata Element Set 1.1 is a vocabulary of fifteen broad, generic properties for describing many kinds of resources.

E

Eddy — Eddy is a cross-platform graphical editor for specifying and visualizing Graphol ontologies.

ELK — ELK is a Java-based ontology reasoner for the OWL 2 EL profile.

ELOT — ELOT is a literate ontology-engineering environment in which one plain-text Org notebook is both the ontology source and its documentation.

Entailment — A triple a reasoner derives from an ontology’s axioms rather than one anyone asserted.

Explanation — A reasoner’s step-by-step account of how a logical consequence follows from an ontology’s axioms.

F

F-Logic — F-Logic (frame logic) is a knowledge-representation and ontology language combining conceptual modeling and object/frame-oriented features with declarative syntax and logic-programming semantics.

FaCT++ — FaCT++ is presented as a new generation of the FaCT OWL-DL reasoner.

FIBO — The Financial Industry Business Ontology (FIBO) defines financial-business things and the relationships among them so that finance data can carry shared meaning.

Fluent Editor — Fluent Editor is an ontology editor centered on Controlled Natural Language, especially a restricted form of English intended to reduce ambiguity and complexity.

Food Ontology — This is an RDF/XML OWL ontology for foods, drinks, meals, and meal courses, derived from and substantially modifying a DAML wine ontology.

FoodOn — FoodOn is a controlled vocabulary and ontology for naming food-bearing parts of animals, plants, and fungi, derived food products, and production processes.

Freebase — Freebase was a data-sharing project that ran from 2007 to 2015; its API has been shut down.

FunOWL — FunOWL is a pure-Python implementation of OWL 2 Functional-Style Syntax with a Pythonic API that stays close to the raw OWL functional model.

G

Gene Ontology (GO) — The Gene Ontology Resource is a knowledgebase and bioinformatics initiative for computationally representing how genes encode biological functions from molecular through organism levels across many species.

Geographical Entity Ontology — The Geographical Entity Ontology is an ontology of geographical entities implemented in OWL 2 and based on Basic Formal Ontology (BFO).

GFO (General Formal Ontology) — The General Formal Ontology is a top-level ontology for conceptual modeling under continuing development by Onto-Med.

gist — gist is Semantic Arts’ minimalist, domain-independent upper ontology for enterprise use.

GoodRelations — GoodRelations is a Web vocabulary for publishing detailed product and service information in a form that search engines, mobile applications, and browser extensions can extract and present.

Gruber’s Definition and Its Successors — The sentence that created the computer-science sense of the word.

gUFO — gUFO is a lightweight implementation of the Unified Foundational Ontology for Semantic Web OWL 2 DL applications.

H

HDT — HDT (Header, Dictionary, Triples) is a compact data structure and binary serialization format for RDF.

HermiT — HermiT is an open-source reasoner for OWL ontologies, based on a hypertableau calculus and released under the LGPL.

History of the Word “Ontology” — The philosophical lineage behind the word that computer science borrowed.

Hoolet — Hoolet is a prototype OWL-DL reasoner that translates an ontology into first-order axioms and sends them to a first-order prover for consistency checking.

Horned OWL — Horned OWL is a Rust library for processing and manipulating OWL documents inside Rust applications.

HyLAR — HyLAR is a hybrid, location-agnostic, rule-based incremental reasoner for the Web.

I

IMI (Infrastructure for Multilayer Interoperability) Core Vocabulary — IMI is a Common Vocabulary Framework for describing shared terms and their relationships to improve interoperability in open data and Digital Government.

Individual — A named instance in an ontology, as opposed to a class or a property.

Instance checking — The reasoning task of asking whether an individual belongs to a class, listed alongside relation checking, subsumption, and concept-consistency checking.

J

jbenner-radham/awesome-semantic-web — A curated directory of Semantic Web and linked-data resources.

jcel — jcel is a Java reasoner for description logics in the EL family, described specifically as an EL+ / OWL 2 EL reasoner.

JSON-LD — JSON-LD (“JavaScript Object Notation for Linked Data”) is a W3C Recommendation for encoding linked data in JSON while retaining a form similar to traditional JSON.

K

KBpedia — KBpedia is an open-source knowledge graph that integrates seven public knowledge bases into one computable structure for data interoperability and knowledge-based AI.

KBS/Ontology Projects Worldwide — This is an alphabetically indexed directory of knowledge-base, ontology, knowledge-representation, and related projects and groups.

KMax/awesome-semantic-web-business — A curated list of resources showing Semantic Web technologies in business applications.

Knoodl — Knoodl was presented as a cloud-hosted Distributed Information Management System combining semantic and traditional information-management technology.

L

Linked Open Vocabularies — Linked Open Vocabularies (LOV) is a catalog containing 910 vocabularies in the fetched page.

LinkML — LinkML is the Linked Data Modeling Language, a flexible language for authoring data schemas in YAML.

Liquid-Legal-Institute/Legal-Ontologies — A curated list of selected resources, methods, and tools for legal ontologies, data schemes, and knowledge graphs.

List of ontology editors — The fetched page defines ontology editors as applications that assist with creating or manipulating ontologies, commonly through one or more ontology languages.

Lists of ontologies — This W3C Wiki page is a directory of ontology-listing pages that map themes such as people or products to ontology URIs.

LODE — LODE 2.0 is an open-source service that extracts entities and textual definitions from semantic artifacts and renders browsable, linked HTML documentation.

LogMap — LogMap is a highly scalable ontology matching system with built-in reasoning and inconsistency-repair capabilities.

Loom — Loom is a knowledge-representation language and environment for constructing intelligent applications, developed at USC’s Information Sciences Institute.

M

Materialization — Expanding a graph with inferred triples ahead of time by forward chaining, as OWL-RL does for RDFS and OWL 2 RL.

Materials-Data-Science-and-Informatics/awesome-fair-data — A curated “Awesome FAIR” list from the Helmholtz Metadata Collaboration’s Hub Information & FAIR Data Commons at FZJ.

Microtheory — Cyc’s device for scoping assertions into small local contexts, each of which inhabits its own context.

MILO (Mid-Level Ontology) — MILO is a formal ontology intended to bridge SUMO’s abstract content and the richer detail of domain ontologies.

MindNet — MindNet is a Microsoft Research knowledge-representation project that automatically builds semantic networks from dictionaries, encyclopedias, and free text.

Mosaic Knowledge Graphs — The fetched source identifies an archived page titled “Mosaic Knowledge Graphs.” It contains Wayback Machine capture metadata rather than the archived application’s descriptive content, so the nature and capabilities of the resource are not stated.

N

N-Quads — N-Quads is a W3C RDF serialization with the .nq extension and application/n-quads media type.

N-Triples — N-Triples is a line-based plain-text serialization for RDF graphs and a subset of Turtle.

Nanotation — Nanotation is described as a mechanism for using “digital sentences” to enhance blog posts, forum discussions, tweets and other micro-blog posts, HTML, and plain-text documents.

National Center for Ontological Research (NCOR) — NCOR describes itself as an international nonprofit ontology research-and-development network.

NELL ontology and knowledge base — This archived Linked Data server publishes the ontology and knowledge base produced by NELL, the Never-Ending Language Learning project in Carnegie Mellon’s Read-The-Web initiative.

Notation3 — Notation3 (N3) is a compact, non-XML serialization for RDF models designed for human readability.

O

OAK — Ontology Access Kit (OAK) is documented as a toolkit for working with ontologies through both Python and a command line.

Object type — Palantir’s term for the schema definition of a real-world entity or event; its own analogy is that an object type is like a dataset and an object like a row.

OBO Format (OBOF) — This is the working-draft specification for OBO Flat File Format 1.4, providing a BNF grammar and a mapping to OWL 2 DL.

OBO Foundry — The Open Biological and Biomedical Ontology Foundry is a community effort to develop interoperable ontologies for the biological sciences.

obonet — obonet is a lightweight Python package for reading OBO-serialized ontologies into a NetworkX MultiDiGraph.

OntoAligner — OntoAligner is a modular Python toolkit for matching entities across two ontologies or knowledge graphs.

OntoEMMA — OntoEMMA is an ontology matcher for generating alignments between knowledgebases.

OntoLearner — OntoLearner is a modular, extensible Python framework for semi-automatic ontology construction and enrichment.

Ontological commitment — What a theory must say exists for it to be true. Quine’s answer to what ontology means for a formal theory.

Ontology Alignment Evaluation Initiative (OAEI) — OAEI is a coordinated international initiative seeking consensus on how schema- and ontology-matching methods should be evaluated.

Ontology language — Ontology languages are formal, usually declarative languages for constructing ontologies and encoding domain knowledge.

Ontology List — Ontology List is an archived, categorized directory of ontology and vocabulary names, with short descriptions for some entries.

Ontology Lookup Service (OLS) — The rendered Ontology Lookup Service page is a browsable catalog of ontologies, prominently including OBO Foundry resources and many scientific and biomedical domains.

Ontology Matching — Ontology Matching is an information repository devoted to methods for finding correspondences between semantically related entities in different ontologies.

OntologyDesignPatterns.org — OntologyDesignPatterns.org is a Semantic Web portal dedicated to ontology design patterns and run by ODPA.

OntoME — OntoME is an ontology management environment for object-oriented structured data models.

OnToology — OnToology automates part of collaborative ontology development for a GitHub repository containing OWL files.

ontor — ontor (ONTology editOR) is a Python library built on Owlready2 for creating, editing, extending, debugging, visualizing, and reasoning over OWL2 ontologies.

Ontospy — Ontospy is a lightweight Python library and command-line tool for inspecting vocabularies encoded in RDF-family languages.

OntoStudio — OntoStudio X is a lightweight, Excel-based IDE for building explainable knowledge systems with OntoBroker’s Java API and ObjectLogic capabilities.

Open Energy Ontology (OEO) — The OEO is an open domain ontology for the energy-system-analysis context and part of the Open Energy Family.

Open Graph protocol — The Open Graph protocol is a metadata vocabulary that lets a web page be represented as a rich object in a social graph.

Open-world assumption — Treating anything not stated as unknown rather than false, so that lack of a fact does not imply its negation. OWL’s default.

Openllet — Openllet is an open-source, Java-based OWL 2 DL reasoner.

OPPL — OPPL is an abstract formalism for manipulating ontologies written in OWL.

OWL 2 Web Ontology Language — OWL 2 is a W3C ontology language for the Semantic Web with formally defined meaning, representing classes, properties, individuals, and data values in Semantic Web documents.

OWL API — The fetched site is the owlcs-maintained project landing page for the OWL API.

owl-cli — This repository now documents Cool RDF, the project formed by merging and updating the former owl-cli and turtle-formatter.

OWL-RL — OWL-RL is a simple RDFLib-based implementation of the OWL 2 RL profile plus basic RDFS inference.

OWL-Time (Time Ontology) — OWL-Time is an OWL 2 DL ontology for describing temporal properties of resources.

OWLGrEd — OWLGrEd presents itself as a graphical ontology editor intended to make ontologies easier to see and edit.

Owlish — Owlish is a Rust library providing OWL 2 data structures for building and working with ontologies.

Owlready2 — Owlready2 is an LGPLv3 package for ontology-oriented programming in Python.

OWLTools — OWLTools is a Java library and command-line toolkit that simplifies common OWLAPI operations, especially work with annotation properties and connections between classes.

P

Pellet 2 — Pellet is an open-source, pure-Java OWL 2 DL reasoner.

prefix.cc — prefix.cc describes itself as a namespace lookup service for RDF developers.

Product Types Ontology — The Product Types Ontology provides GoodRelations-compatible class definitions for product or service types that have entries in English Wikipedia.

Protege Ontology Library — A Protege Wiki page for the Protege Ontology Library.

Protégé — Protégé is a free, open-source OWL ontology editor for building and managing ontologies.

PROV-O — PROV-O is the W3C Recommendation that expresses the PROV Data Model in OWL 2, providing classes, properties, and restrictions for representing and exchanging provenance across systems and contexts.

Punning — Treating one name as both a class and an individual. Most OWL reasoners do not support it, which is why tools such as yamlpyowl generate proxy individuals instead.

pyfactxx — pyfactxx provides Python bindings that connect the C++ FaCT++ reasoner to RDFLib.

pyLODE — pyLODE is a Python reimplementation of LODE that parses OWL/RDF with RDFLib and generates human-readable, static HTML ontology documentation.

pyontutils — pyontutils is a collection of Python utilities for maintaining ontologies in Git and making them available through SciGraph.

pysemtec/semantic-python-overview — A curated, awesome-list-inspired overview of projects that connect Python with semantic technologies such as RDF, OWL, SPARQL, and reasoning.

Q

Quine and Ontological Commitment — Quine’s 1948 paper “On What There Is” gives the criterion that makes ontology tractable for engineers.

R

Racer — Racer is a freely available knowledge-representation system implementing an optimized tableau calculus for the description logic SHIQ(D).

RDF (Resource Description Framework) 1.1 — RDF is a W3C method for describing and exchanging graph data, originally designed as a metadata data model.

RDF Schema (RDFS) 1.1 — RDF Schema 1.1 is a W3C data-modeling vocabulary and semantic extension for RDF.

RDF* — The fetched source is the RDF-star community landing page, describing RDF-star (formerly RDF*) as part of the RDF-DEV community group.

RDF/XML — RDF/XML is a W3C-defined syntax for serializing an RDF graph as an XML document.

RDFa — RDFa, or Resource Description Framework in Attributes, is a W3C Recommendation that adds attributes to HTML, XHTML, and XML-based documents so they can carry rich metadata.

Reification — Modelling provenance about a statement, one option alongside n-ary relations, named graphs, singleton properties, and NDFluents.

rNews — rNews is an IPTC-approved standard for embedding news-specific metadata in HTML documents.

ROBOT — ROBOT is a tool for working with Open Biomedical Ontologies, available as a command-line program or as a library for JVM languages.

S

Schema.org Schemas — This Schema.org page is the development-version view of the full schema hierarchy.

SciGraph — SciGraph represents ontologies and ontology-encoded data as a Neo4j property graph.

semantalytics/awesome-semantic-web — A curated list of semantic-web and linked-data resources, maintained primarily as a categorized README.md.

Semantic layer — A label Palantir explicitly rejects for its Ontology, which its architecture documentation says represents an enterprise’s interconnected decisions rather than its data.

SENSUS — The fetched source does not describe SENSUS: the requested URL redirected to the USC Information Sciences Institute Natural Language Group home page.

SHACL (Shapes Constraint Language) — SHACL is a W3C Recommendation for describing RDF graphs through constraints on their content, structure, and meaning.

ShEx (Shape Expressions) — Shape Expressions (ShEx) is a data-modeling language for describing and validating RDF graphs.

Shirky, “Ontology Is Overrated” (2005) — Clay Shirky argues that designing categories in advance to cover cases that have not happened yet is badly overrated in digital systems.

SIOC (Semantically Interlinked Online Communities) — SIOC is an ontology of terms for describing online communities on the Web of Data.

SKOS (Simple Knowledge Organization System) — SKOS is a W3C Recommendation defining a common data model for sharing and linking knowledge organization systems such as thesauri, classification schemes, subject-heading systems, and taxonomies on the Web.

SPARQL 1.1 — SPARQL 1.1 Query Language is a W3C Recommendation defining the syntax and semantics of queries over RDF graphs.

SPARQL* — The fetched page is the community home for RDF-star, formerly RDF*, within the RDF-DEV community group.

SPARQL-DL — SPARQL-DL is a substantial subset of SPARQL with semantics based directly on OWL-DL entailment.

SPARQL-OWL algorithm — This paper presents a sound and complete query-answering algorithm for SPARQL’s OWL 2 Direct Semantics entailment regime.

SPIN (SPARQL Inferencing Notation) — SPIN is a W3C Member Submission for representing SPARQL rules and constraints on Semantic Web models, described by its site as a de-facto industry standard.

Subsumption — The relation of one class being a subclass of another, either declared as an axiom or derived by a reasoner.

SUMO (Suggested Upper Merged Ontology) — SUMO and its domain ontologies are presented as a large free formal ontology used in search, linguistics, and reasoning.

SWOOP — SWOOP v2.3 beta 3 is an OWL ontology browser and editor built around a standard web-browser UI paradigm, including an address bar, history, bookmarks, and hypertext navigation.

SWRL (Semantic Web Rule Language) — SWRL is a 2004 W3C Member Submission proposing a rule language that combines OWL DL/OWL Lite with Unary/Binary Datalog RuleML.

T

Tarql — Tarql is a Java command-line tool, based on Apache ARQ, that converts CSV files to RDF using SPARQL 1.1 syntax.

Tawny-OWL — Tawny-OWL is a Clojure domain-specific language for constructing OWL ontologies in an evaluative, functional, fully programmatic environment, implemented directly over the OWL API.

TBox — The terminological part of a knowledge base: the concept hierarchy, as opposed to the role axioms in the RBox and the facts in the ABox.

The Knowledge Graph Turn (2012 onwards) — The rebranding and repositioning that let ontology technology survive the Semantic Web’s disappointment.

The Linked Open Data Cloud — The Linked Open Data Cloud site hosts a diagram of datasets published in Linked Data format, organized into domain subclouds.

The Palantir Ontology — Palantir’s Ontology is the operational layer at the centre of Foundry’s architecture.

The Semantic Web Vision (Berners-Lee, Hendler, Lassila 2001) — The Scientific American article that moved ontologies from an AI research topic to a web-scale programme.

TopBraid Composer — The fetched source does not identify or describe TopBraid Composer.

Torque — Bowker and Star’s term for the twisting that happens when a classification system and a person’s own account of themselves do not line up, and the system wins.

totogo/awesome-knowledge-graph — A curated directory of knowledge-graph learning materials, databases, tools, datasets, services, events, and books.

TriG — TriG is a plain-text serialization format for RDF graphs, named graphs, and RDF datasets.

Triple — The atomic unit of RDF: subject, predicate, object.

TriX — TriX (“Triples in XML”) is an XML serialization for RDF graphs, Named Graphs, and RDF Datasets.

Turtle — Turtle (Terse RDF Triple Language) is a syntax and .ttl file format for expressing RDF graphs.

U

Uberon — Uberon is an integrated cross-species ontology of anatomical structures in animals.

Unified Cyber Ontology (UCO) — Unified Cyber Ontology (UCO) is a community-developed ontology/model intended to provide a consistent foundation for standardized information representation across the cyber-security ecosystem.

Unique name assumption — Assuming two different names refer to two different things. Description logics do not generally assume it, so different names need not denote different things.

Upper ontology — A domain-neutral ontology of very general categories, meant as a shared spine that domain ontologies hang from.

V

vCard Ontology — A W3C Interest Group Note mapping vCard RFC 6350 to RDF/OWL for describing people and organizations with Semantic Web techniques.

VocBench — VocBench is a free, open-source, web-based platform for multilingual collaborative management of OWL ontologies, SKOS/SKOS-XL thesauri, OntoLex-lemon lexicons, and generic RDF datasets.

VocPrez — VocPrez is an archived, read-only web delivery system for RDF vocabularies formulated in SKOS.

W

WebODE — WebODE is an extensible ontology-engineering suite built around an application server and a shared ontology access service.

WebVOWL — WebVOWL is a browser UI for presenting ontology visualizations, with OWL2VOWL providing the conversion backend.

What Happened to the Semantic Web — The retrospective account of why the 2001 programme did not arrive as described.

Whelk — Whelk is an OWL reasoner based on the algorithm implemented by ELK.

WIDOCO — WIDOCO (WIzard for DOCumenting Ontologies) generates enriched, customizable, human-readable ontology documentation through a GUI wizard or command line.

Wikidata — Wikidata is a free, open knowledge base readable and editable by both humans and machines.

Wine Ontology — The Wine Ontology is an example OWL ontology derived from the DAML Wine ontology, with substantial changes to its region relations.

Y

YAGO — YAGO is a large semantic knowledge base jointly developed by the Max Planck Institute for Informatics and Télécom ParisTech.

YAMATO (Yet Another More Advanced Top-level Ontology) — YAMATO is a foundational ontology built and maintained by Riichiro Mizoguchi, first created in 1999 and subsequently revised several times.

yamlpyowl — yamlpyowl reads ontologies—including individuals and SWRL rules—written in YAML and represents them as Python objects through owlready2.

All notes

181 notes across 22 sections. Every note follows the same shape: what it is, key concepts, how you would use it, the angle on large language models, pitfalls, and a verdict.

History & Foundations

• Cyc as a Knowledge-Engineering Programme (Lenat 1995) — Douglas Lenat’s article “CYC: A Large-Scale Investment in Knowledge Infrastructure” describes the Cyc project, begun with Mary Shepherd in 1984, as an attempt…
• Gruber’s Definition and Its Successors — The sentence that created the computer-science sense of the word.
• History of the Word “Ontology” — The philosophical lineage behind the word that computer science borrowed.
• Quine and Ontological Commitment — Quine’s 1948 paper “On What There Is” gives the criterion that makes ontology tractable for engineers.
• The Knowledge Graph Turn (2012 onwards) — The rebranding and repositioning that let ontology technology survive the Semantic Web’s disappointment.
• The Semantic Web Vision (Berners-Lee, Hendler, Lassila 2001) — The Scientific American article that moved ontologies from an AI research topic to a web-scale programme.
• What Happened to the Semantic Web — The retrospective account of why the 2001 programme did not arrive as described.

Operational Ontologies

• The Palantir Ontology — Palantir’s Ontology is the operational layer at the centre of Foundry’s architecture.

Criticism

• Bowker and Star, “Sorting Things Out” (1999) — An ethnographic study of classification systems and information infrastructure, and the deepest criticism of ontology work in this corpus.
• Criticism of Operational Ontologies (Palantir) — The research and legal record on what happens when a vendor ontology is installed inside a state institution.
• Doctorow, “Metacrap” (2001) — Cory Doctorow’s essay against voluntary metadata, version 1.0 dated 15 May 2001 and version 1.3 dated 26 August 2001 — months after the Scientific American…
• Shirky, “Ontology Is Overrated” (2005) — Clay Shirky argues that designing categories in advance to cover cases that have not happened yet is badly overrated in digital systems.

Upper-level Ontologies

• BFO (Basic Formal Ontology) — BFO is a small upper-level ontology intended to support information retrieval, analysis, and integration across scientific and other domains.
• DBpedia Ontology (DBO) — The DBpedia Ontology is described as the heart of DBpedia: a shallow, cross-domain ontology that began from commonly used Wikipedia infoboxes and evolved…
• DOLCE (Descriptive Ontology for Linguistic and Cognitive Engineering) — DOLCE is a foundational ontology developed and maintained by the ISTC-CNR Laboratory for Applied Ontology.
• GFO (General Formal Ontology) — The General Formal Ontology is a top-level ontology for conceptual modeling under continuing development by Onto-Med.
• gist — gist is Semantic Arts’ minimalist, domain-independent upper ontology for enterprise use.
• gUFO — gUFO is a lightweight implementation of the Unified Foundational Ontology for Semantic Web OWL 2 DL applications.
• SUMO (Suggested Upper Merged Ontology) — SUMO and its domain ontologies are presented as a large free formal ontology used in search, linguistics, and reasoning.
• YAMATO (Yet Another More Advanced Top-level Ontology) — YAMATO is a foundational ontology built and maintained by Riichiro Mizoguchi, first created in 1999 and subsequently revised several times.

Mid-level Ontologies

• Common Core Ontologies (CCO) — CCO is a suite of eleven ontologies containing logically defined generic terms and relations intended to cover entities across domains.
• MILO (Mid-Level Ontology) — MILO is a formal ontology intended to bridge SUMO’s abstract content and the richer detail of domain ontologies.

Cross-domain Ontologies

• Billion Triple Challenge (BTC) 2019 Dataset — BTC 2019 is an open dataset produced by an LDspider crawl of RDF/XML, Turtle, and N-Triples documents from 12 December 2018 to 11 January 2019.
• ConceptNet — ConceptNet is a freely available, open multilingual semantic network intended to help computers understand word meanings.
• Cyc — Cyc is presented as an enterprise machine-reasoning AI platform that uses codified human common sense and knowledge rather than patterns and statistics.
• DBpedia — DBpedia presents itself as global, unified access to knowledge graphs and as a major Linked Open Data resource built from Wikipedia-language editions and…
• Freebase — Freebase was a data-sharing project that ran from 2007 to 2015; its API has been shut down.
• KBpedia — KBpedia is an open-source knowledge graph that integrates seven public knowledge bases into one computable structure for data interoperability and…
• MindNet — MindNet is a Microsoft Research knowledge-representation project that automatically builds semantic networks from dictionaries, encyclopedias, and free text.
• Mosaic Knowledge Graphs — The fetched source identifies an archived page titled “Mosaic Knowledge Graphs.” It contains Wayback Machine capture metadata rather than the archived…
• NELL ontology and knowledge base — This archived Linked Data server publishes the ontology and knowledge base produced by NELL, the Never-Ending Language Learning project in Carnegie Mellon’s…
• OWL-Time (Time Ontology) — OWL-Time is an OWL 2 DL ontology for describing temporal properties of resources.
• SENSUS — The fetched source does not describe SENSUS: the requested URL redirected to the USC Information Sciences Institute Natural Language Group home page.
• Wikidata — Wikidata is a free, open knowledge base readable and editable by both humans and machines.
• YAGO — YAGO is a large semantic knowledge base jointly developed by the Max Planck Institute for Informatics and Télécom ParisTech.

Domain Ontologies

• Built Environment Ontology Lookup Service (BE-OLS) — BE-OLS is a platform for discovering, exploring, and evaluating built-environment ontologies.
• CIDOC CRM (Conceptual Reference Model) — CIDOC CRM is a formal ontology and information-integration framework for cultural heritage documentation.
• CLARIAH/awesome-humanities-ontologies — A curated directory of ontologies, vocabularies, terminologies, and taxonomies for modelling and publishing Humanities datasets as Linked Data.
• D3FEND — The fetched page is the MITRE D3FEND ontology-resource hub, distributing the entire current D3FEND model.
• Digital Buildings Ontology (DBO) — Digital Buildings is an Apache-licensed schema and toolset for representing structured information about buildings and installed equipment.
• FIBO — The Financial Industry Business Ontology (FIBO) defines financial-business things and the relationships among them so that finance data can carry shared…
• Food Ontology — This is an RDF/XML OWL ontology for foods, drinks, meals, and meal courses, derived from and substantially modifying a DAML wine ontology.
• FoodOn — FoodOn is a controlled vocabulary and ontology for naming food-bearing parts of animals, plants, and fungi, derived food products, and production processes.
• Gene Ontology (GO) — The Gene Ontology Resource is a knowledgebase and bioinformatics initiative for computationally representing how genes encode biological functions from…
• Geographical Entity Ontology — The Geographical Entity Ontology is an ontology of geographical entities implemented in OWL 2 and based on Basic Formal Ontology (BFO).
• GoodRelations — GoodRelations is a Web vocabulary for publishing detailed product and service information in a form that search engines, mobile applications, and browser…
• Liquid-Legal-Institute/Legal-Ontologies — A curated list of selected resources, methods, and tools for legal ontologies, data schemes, and knowledge graphs.
• OBO Foundry — The Open Biological and Biomedical Ontology Foundry is a community effort to develop interoperable ontologies for the biological sciences.
• Open Energy Ontology (OEO) — The OEO is an open domain ontology for the energy-system-analysis context and part of the Open Energy Family.
• Product Types Ontology — The Product Types Ontology provides GoodRelations-compatible class definitions for product or service types that have entries in English Wikipedia.
• PROV-O — PROV-O is the W3C Recommendation that expresses the PROV Data Model in OWL 2, providing classes, properties, and restrictions for representing and exchanging…
• rNews — rNews is an IPTC-approved standard for embedding news-specific metadata in HTML documents.
• SIOC (Semantically Interlinked Online Communities) — SIOC is an ontology of terms for describing online communities on the Web of Data.
• Uberon — Uberon is an integrated cross-species ontology of anatomical structures in animals.
• Unified Cyber Ontology (UCO) — Unified Cyber Ontology (UCO) is a community-developed ontology/model intended to provide a consistent foundation for standardized information representation…
• vCard Ontology — A W3C Interest Group Note mapping vCard RFC 6350 to RDF/OWL for describing people and organizations with Semantic Web techniques.
• Wine Ontology — The Wine Ontology is an example OWL ontology derived from the DAML Wine ontology, with substantial changes to its region relations.

Ontologies and Vocabularies

• BARTOC (Basel Register of Thesauri, Ontologies & Classifications) — BARTOC is a site that unites information about terminologies and terminology registries.
• BioPortal — NCBO BioPortal presents itself as a comprehensive repository of biomedical ontologies that is free and open to all users without login.
• DBpedia Archivo — DBpedia Archivo is an ontology archive that automatically discovers OWL ontologies on the web, checks them every eight hours, and persistently archives changed…
• KBS/Ontology Projects Worldwide — This is an alphabetically indexed directory of knowledge-base, ontology, knowledge-representation, and related projects and groups.
• Linked Open Vocabularies — Linked Open Vocabularies (LOV) is a catalog containing 910 vocabularies in the fetched page.
• Lists of ontologies — This W3C Wiki page is a directory of ontology-listing pages that map themes such as people or products to ontology URIs.
• Ontology List — Ontology List is an archived, categorized directory of ontology and vocabulary names, with short descriptions for some entries.
• Ontology Lookup Service (OLS) — The rendered Ontology Lookup Service page is a browsable catalog of ontologies, prominently including OBO Foundry resources and many scientific and biomedical…
• OntologyDesignPatterns.org — OntologyDesignPatterns.org is a Semantic Web portal dedicated to ontology design patterns and run by ODPA.
• prefix.cc — prefix.cc describes itself as a namespace lookup service for RDF developers.
• Protege Ontology Library — A Protege Wiki page for the Protege Ontology Library.
• The Linked Open Data Cloud — The Linked Open Data Cloud site hosts a diagram of datasets published in Linked Data format, organized into domain subclouds.

Vocabularies

• DCMI Metadata Terms — DCMI Metadata Terms is the authoritative specification of metadata terms maintained by the Dublin Core Metadata Initiative.
• Dublin Core Metadata Element Set — The Dublin Core Metadata Element Set 1.1 is a vocabulary of fifteen broad, generic properties for describing many kinds of resources.
• IMI (Infrastructure for Multilayer Interoperability) Core Vocabulary — IMI is a Common Vocabulary Framework for describing shared terms and their relationships to improve interoperability in open data and Digital Government.
• Open Graph protocol — The Open Graph protocol is a metadata vocabulary that lets a web page be represented as a rich object in a social graph.
• RDF Schema (RDFS) 1.1 — RDF Schema 1.1 is a W3C data-modeling vocabulary and semantic extension for RDF.
• Schema.org Schemas — This Schema.org page is the development-version view of the full schema hierarchy.
• SKOS (Simple Knowledge Organization System) — SKOS is a W3C Recommendation defining a common data model for sharing and linking knowledge organization systems such as thesauri, classification schemes,…

Languages

• Common Logic (CL) — Common Logic is an ISO-published framework for a family of first-order-logic-based languages intended to exchange and transmit knowledge between computer…
• HDT — HDT (Header, Dictionary, Triples) is a compact data structure and binary serialization format for RDF.
• JSON-LD — JSON-LD (“JavaScript Object Notation for Linked Data”) is a W3C Recommendation for encoding linked data in JSON while retaining a form similar to traditional…
• Loom — Loom is a knowledge-representation language and environment for constructing intelligent applications, developed at USC’s Information Sciences Institute.
• N-Quads — N-Quads is a W3C RDF serialization with the .nq extension and application/n-quads media type.
• N-Triples — N-Triples is a line-based plain-text serialization for RDF graphs and a subset of Turtle.
• Nanotation — Nanotation is described as a mechanism for using “digital sentences” to enhance blog posts, forum discussions, tweets and other micro-blog posts, HTML, and…
• Notation3 — Notation3 (N3) is a compact, non-XML serialization for RDF models designed for human readability.
• OBO Format (OBOF) — This is the working-draft specification for OBO Flat File Format 1.4, providing a BNF grammar and a mapping to OWL 2 DL.
• Ontology language — Ontology languages are formal, usually declarative languages for constructing ontologies and encoding domain knowledge.
• OWL 2 Web Ontology Language — OWL 2 is a W3C ontology language for the Semantic Web with formally defined meaning, representing classes, properties, individuals, and data values in Semantic…
• RDF (Resource Description Framework) 1.1 — RDF is a W3C method for describing and exchanging graph data, originally designed as a metadata data model.
• RDF* — The fetched source is the RDF-star community landing page, describing RDF-star (formerly RDF*) as part of the RDF-DEV community group.
• RDF/XML — RDF/XML is a W3C-defined syntax for serializing an RDF graph as an XML document.
• RDFa — RDFa, or Resource Description Framework in Attributes, is a W3C Recommendation that adds attributes to HTML, XHTML, and XML-based documents so they can carry…
• TriG — TriG is a plain-text serialization format for RDF graphs, named graphs, and RDF datasets.
• TriX — TriX (“Triples in XML”) is an XML serialization for RDF graphs, Named Graphs, and RDF Datasets.
• Turtle — Turtle (Terse RDF Triple Language) is a syntax and .ttl file format for expressing RDF graphs.

Logics

• Description Logic Complexity Navigator — A web navigator maintained by Evgeny Zolin for complexity results about reasoning in Description Logics.
• Description Logics (DLs) — Description logics are a family of formal knowledge-representation languages, generally more expressive than propositional logic and less expressive than…
• F-Logic — F-Logic (frame logic) is a knowledge-representation and ontology language combining conceptual modeling and object/frame-oriented features with declarative…

Querying

• [protege-user] which is the best query language for owl ontologies? — A 2016 Protege-user mailing-list reply comparing DL Query, SPARQL, and SQWRL for querying OWL ontologies.
• DL Query (class expression) — The DL Query tab is a Protégé Desktop feature for searching a classified ontology with class expressions based on Manchester OWL syntax.
• SPARQL 1.1 — SPARQL 1.1 Query Language is a W3C Recommendation defining the syntax and semantics of queries over RDF graphs.
• SPARQL* — The fetched page is the community home for RDF-star, formerly RDF*, within the RDF-DEV community group.
• SPARQL-DL — SPARQL-DL is a substantial subset of SPARQL with semantics based directly on OWL-DL entailment.
• SPARQL-OWL algorithm — This paper presents a sound and complete query-answering algorithm for SPARQL’s OWL 2 Direct Semantics entailment regime.

Rule and Schema Definition

• LinkML — LinkML is the Linked Data Modeling Language, a flexible language for authoring data schemas in YAML.
• SHACL (Shapes Constraint Language) — SHACL is a W3C Recommendation for describing RDF graphs through constraints on their content, structure, and meaning.
• ShEx (Shape Expressions) — Shape Expressions (ShEx) is a data-modeling language for describing and validating RDF graphs.
• SPIN (SPARQL Inferencing Notation) — SPIN is a W3C Member Submission for representing SPARQL rules and constraints on Semantic Web models, described by its site as a de-facto industry standard.
• SWRL (Semantic Web Rule Language) — SWRL is a 2004 W3C Member Submission proposing a rule language that combines OWL DL/OWL Lite with Unary/Binary Datalog RuleML.

Reasoners

• CEL — CEL is a lightweight description-logic reasoner aimed at large-scale biomedical ontologies.
• cwm — cwm is a general-purpose Semantic Web data processor and forward-chaining reasoner for querying, checking, transforming, and filtering information.
• ELK — ELK is a Java-based ontology reasoner for the OWL 2 EL profile.
• FaCT++ — FaCT++ is presented as a new generation of the FaCT OWL-DL reasoner.
• HermiT — HermiT is an open-source reasoner for OWL ontologies, based on a hypertableau calculus and released under the LGPL.
• Hoolet — Hoolet is a prototype OWL-DL reasoner that translates an ontology into first-order axioms and sends them to a first-order prover for consistency checking.
• HyLAR — HyLAR is a hybrid, location-agnostic, rule-based incremental reasoner for the Web.
• jcel — jcel is a Java reasoner for description logics in the EL family, described specifically as an EL+ / OWL 2 EL reasoner.
• Openllet — Openllet is an open-source, Java-based OWL 2 DL reasoner.
• OWL-RL — OWL-RL is a simple RDFLib-based implementation of the OWL 2 RL profile plus basic RDFS inference.
• Pellet 2 — Pellet is an open-source, pure-Java OWL 2 DL reasoner.
• pyfactxx — pyfactxx provides Python bindings that connect the C++ FaCT++ reasoner to RDFLib.
• Racer — Racer is a freely available knowledge-representation system implementing an optimized tableau calculus for the description logic SHIQ(D).
• Whelk — Whelk is an OWL reasoner based on the algorithm implemented by ELK.

Ontology Editors

• A List of Ontology Engineering Tools (Ontology Editors) — This is an archived directory of ontology-engineering tools and their websites.
• Apollo — Apollo was a Java-based, user-friendly knowledge-modeling application designed for varied knowledge-representation needs.
• Eddy — Eddy is a cross-platform graphical editor for specifying and visualizing Graphol ontologies.
• ELOT — ELOT is a literate ontology-engineering environment in which one plain-text Org notebook is both the ontology source and its documentation.
• Fluent Editor — Fluent Editor is an ontology editor centered on Controlled Natural Language, especially a restricted form of English intended to reduce ambiguity and…
• Knoodl — Knoodl was presented as a cloud-hosted Distributed Information Management System combining semantic and traditional information-management technology.
• List of ontology editors — The fetched page defines ontology editors as applications that assist with creating or manipulating ontologies, commonly through one or more ontology languages.
• OntoME — OntoME is an ontology management environment for object-oriented structured data models.
• OntoStudio — OntoStudio X is a lightweight, Excel-based IDE for building explainable knowledge systems with OntoBroker’s Java API and ObjectLogic capabilities.
• OWLGrEd — OWLGrEd presents itself as a graphical ontology editor intended to make ontologies easier to see and edit.
• Protégé — Protégé is a free, open-source OWL ontology editor for building and managing ontologies.
• SWOOP — SWOOP v2.3 beta 3 is an OWL ontology browser and editor built around a standard web-browser UI paradigm, including an address bar, history, bookmarks, and…
• TopBraid Composer — The fetched source does not identify or describe TopBraid Composer.
• VocBench — VocBench is a free, open-source, web-based platform for multilingual collaborative management of OWL ontologies, SKOS/SKOS-XL thesauri, OntoLex-lemon lexicons,…
• WebODE — WebODE is an extensible ontology-engineering suite built around an application server and a shared ontology access service.

Ontology Utilities

• LODE — LODE 2.0 is an open-source service that extracts entities and textual definitions from semantic artifacts and renders browsable, linked HTML documentation.
• OAK — Ontology Access Kit (OAK) is documented as a toolkit for working with ontologies through both Python and a command line.
• obonet — obonet is a lightweight Python package for reading OBO-serialized ontologies into a NetworkX MultiDiGraph.
• OnToology — OnToology automates part of collaborative ontology development for a GitHub repository containing OWL files.
• Ontospy — Ontospy is a lightweight Python library and command-line tool for inspecting vocabularies encoded in RDF-family languages.
• owl-cli — This repository now documents Cool RDF, the project formed by merging and updating the former owl-cli and turtle-formatter.
• OWLTools — OWLTools is a Java library and command-line toolkit that simplifies common OWLAPI operations, especially work with annotation properties and connections…
• pyLODE — pyLODE is a Python reimplementation of LODE that parses OWL/RDF with RDFLib and generates human-readable, static HTML ontology documentation.
• pyontutils — pyontutils is a collection of Python utilities for maintaining ontologies in Git and making them available through SciGraph.
• ROBOT — ROBOT is a tool for working with Open Biomedical Ontologies, available as a command-line program or as a library for JVM languages.
• Tarql — Tarql is a Java command-line tool, based on Apache ARQ, that converts CSV files to RDF using SPARQL 1.1 syntax.
• VocPrez — VocPrez is an archived, read-only web delivery system for RDF vocabularies formulated in SKOS.
• WebVOWL — WebVOWL is a browser UI for presenting ontology visualizations, with OWL2VOWL providing the conversion backend.
• WIDOCO — WIDOCO (WIzard for DOCumenting Ontologies) generates enriched, customizable, human-readable ontology documentation through a GUI wizard or command line.
• yamlpyowl — yamlpyowl reads ontologies—including individuals and SWRL rules—written in YAML and represents them as Python objects through owlready2.

OWL-aware libraries

• Apache Jena Ontology API — The Jena Ontology API is a Java programming interface for working with RDF-backed RDFS and OWL ontologies.
• FunOWL — FunOWL is a pure-Python implementation of OWL 2 Functional-Style Syntax with a Pythonic API that stays close to the raw OWL functional model.
• Horned OWL — Horned OWL is a Rust library for processing and manipulating OWL documents inside Rust applications.
• ontor — ontor (ONTology editOR) is a Python library built on Owlready2 for creating, editing, extending, debugging, visualizing, and reasoning over OWL2 ontologies.
• OPPL — OPPL is an abstract formalism for manipulating ontologies written in OWL.
• OWL API — The fetched site is the owlcs-maintained project landing page for the OWL API.
• Owlish — Owlish is a Rust library providing OWL 2 data structures for building and working with ontologies.
• Owlready2 — Owlready2 is an LGPLv3 package for ontology-oriented programming in Python.
• Tawny-OWL — Tawny-OWL is a Clojure domain-specific language for constructing OWL ontologies in an evaluative, functional, fully programmatic environment, implemented…

Alignment & Matching

• AgreementMakerLight (AML) — AgreementMakerLight is an automated, efficient ontology-matching system with a flexible, extensible framework.
• Alignment API — The Alignment API is a Java API and implementation for expressing and sharing ontology alignments.
• LogMap — LogMap is a highly scalable ontology matching system with built-in reasoning and inconsistency-repair capabilities.
• OntoAligner — OntoAligner is a modular Python toolkit for matching entities across two ontologies or knowledge graphs.
• OntoEMMA — OntoEMMA is an ontology matcher for generating alignments between knowledgebases.
• Ontology Matching — Ontology Matching is an information repository devoted to methods for finding correspondences between semantically related entities in different ontologies.

Machine Learning

• Do Language Models Replace Ontologies? — The live argument about whether large language models make hand-built ontologies unnecessary, obsolete the labour of building them, or increase their value.
• OntoLearner — OntoLearner is a modular, extensible Python framework for semi-automatic ontology construction and enrichment.

Datastore

• SciGraph — SciGraph represents ontologies and ontology-encoded data as a Neo4j property graph.

Communities

• Association for Ontology Design & Patterns (ODPA) — The fetched source does not contain the requested ODPA association page; it resolves to the OntologyDesignPatterns.org main page.
• National Center for Ontological Research (NCOR) — NCOR describes itself as an international nonprofit ontology research-and-development network.
• Ontology Alignment Evaluation Initiative (OAEI) — OAEI is a coordinated international initiative seeking consensus on how schema- and ontology-matching methods should be evaluated.

Related

• buaaliuming/Awesome-Knowledge-Bases — Awesome-Knowledge-Bases is a compact curated page of currently available knowledge bases, ontologies, knowledge graphs, and taxonomies, maintained for quick…
• costezki/awesome-semantic-tools — A compact curated list of projects related to ontology engineering and Semantic Web technologies.
• jbenner-radham/awesome-semantic-web — A curated directory of Semantic Web and linked-data resources.
• KMax/awesome-semantic-web-business — A curated list of resources showing Semantic Web technologies in business applications.
• Materials-Data-Science-and-Informatics/awesome-fair-data — A curated “Awesome FAIR” list from the Helmholtz Metadata Collaboration’s Hub Information & FAIR Data Commons at FZJ.
• pysemtec/semantic-python-overview — A curated, awesome-list-inspired overview of projects that connect Python with semantic technologies such as RDF, OWL, SPARQL, and reasoning.
• semantalytics/awesome-semantic-web — A curated list of semantic-web and linked-data resources, maintained primarily as a categorized README.md.
• totogo/awesome-knowledge-graph — A curated directory of knowledge-graph learning materials, databases, tools, datasets, services, events, and books.

Cyc as a Knowledge-Engineering Programme (Lenat 1995)

What it is Douglas Lenat’s article “CYC: A Large-Scale Investment in Knowledge Infrastructure” describes the Cyc project, begun with Mary Shepherd in 1984, as an attempt to hand-codify common sense. It appeared in Communications of the ACM 38(11) in 1995, per its DBLP record. Lenat’s premise was that machine learning and natural-language understanding both stall without a large base of background knowledge, so somebody had to enter that knowledge by hand until the system reached critical mass and could take over its own learning. The paper reports “a universal schema of roughly 10⁵ general concepts spanning human reality,” about a million commonsense axioms “handcrafted for and entered into CYC’s knowledge base, and millions more … inferred and cached by CYC,” and “a person-century of effort” since 1984. Lenat states plainly: “Mary Shepherd and I embarked on that task in 1984, knowing we had little chance of success, but seeing no alternative but to try.”

Key concepts Common sense as an engineering target; the critical-mass hypothesis; causality, time, space, substances, intention, contradiction, uncertainty, belief, and emotion as things that must be represented; micro-theories, each of which “inhabits its own context” and is “relatively small, solid, and flat”; the examples the paper uses — “You cannot remember events that have not happened yet”; “if you cut a lump of peanut butter in half, each half is also a lump of peanut butter; but if you cut a table in half, neither half is a table.”

How you’d use it Treat Cyc as the reference experiment for the cost side of ontology engineering. It is the largest sustained attempt to answer the question every ontology project eventually faces: how much of the world do we have to write down before the model earns its keep? Cyc’s answer — “a person-century of effort” by 1995 — is the number every “we will just model our domain properly” plan is implicitly betting against.

LLM angle Cyc’s motivating claim is that statistics alone will not resolve commonsense questions: “statistics, colocation, and frequency do not resolve such questions. But the task goes from impossible to trivial if one already knows a few things about boxes and pens.” That is the claim large language models most directly contest, since they absorb an enormous amount of that background from text without anyone hand-writing axioms. The paper is from 1995 and says nothing about them; the counter-claim that what a model absorbs is not inspectable, not consistent, and cannot be audited is mine, and it is argued out in llm-ontology-debate.md.

Pitfalls & lessons Lenat’s own framing concedes the risk up front: the project’s payoff was always deferred to a critical mass that had not yet arrived. A knowledge base whose value depends on reaching a threshold, rather than on being useful at every stage, is a bet on the threshold. Compare the layered approach the rest of this corpus recommends, where a small ontology answers real competency questions early.

Verdict Worth reading in full, and short. It is the only document in this corpus that states the price of hand-codified knowledge as a number, and every later argument about whether models can replace ontologies is arguing with it.

Sources consulted

• https://faculty.cc.gatech.edu/~isbell/classes/reading/papers/lenat95cyc.pdf
• research/firecrawl/ai-lenat-cyc95.md
• https://dblp.org/rec/journals/cacm/Lenat95 (venue, volume, and year)
• research/dblp/lenat-cyc-1995.json
• See also cyc.md for the current commercial positioning.

Gruber’s Definition and Its Successors

What it is The sentence that created the computer-science sense of the word. Tom Gruber’s 1993 work, written inside what his own acknowledgements call the ARPA (later DARPA) Knowledge Sharing Effort, defined an ontology as “an explicit specification of a conceptualization,” where a conceptualization is “the objects, concepts, and other entities that are presumed to exist in some area of interest and the relationships that hold among them.” That wording is Gruber’s own 2009 restatement; Genesereth and Nilsson’s original says “assumed to exist.” The conceptualization half is borrowed from Genesereth and Nilsson, who describe it as an abstract, simplified view of the world represented for some purpose, and who note that every knowledge base is committed to some conceptualization whether or not it admits it.

Key concepts Explicit specification of a conceptualization; ontology as an interface specification rather than an internal encoding; ontological commitment as an agreement to use a vocabulary consistently; Borst’s 1997 revision to “a formal specification of a shared conceptualization,” which adds consensus; Guarino’s formal reconstruction of conceptualization as an intensional relational structure.

How you’d use it Read the definition as an engineering contract, not a metaphysical claim. Gruber’s point is that an ontology is the language two agents use to talk to each other about a domain. An agent that supports the interface is not obliged to store its knowledge that way internally. Gruber puts it plainly: “The agents sharing a vocabulary need not share a knowledge base; each knows things the other does not.” That is why an ontology can sit above heterogeneous systems that share nothing but the vocabulary. Palantir describes its own Ontology in the same architectural terms — it “sits on top of the digital assets integrated into the Palantir platform … and connects them to their real-world counterparts” — though Palantir never invokes Gruber; see palantir-ontology.md.

LLM angle none stated

Pitfalls & lessons Gruber concedes that “the terms specification and conceptualization have caused much debate,” and Guarino, Oberle and Staab wrote their 2009 chapter largely to repair the informality, noting that all the earlier definitions “were assuming an informal notion of ‘conceptualization’.” One standing objection, which Gruber records and rejects, is that the definition “is overly broad, allowing for a range of specifications from simple glossaries to logical theories couched in predicate calculus.” Whether that breadth is a defect is still argued; in practice it is what lets a team call any schema an ontology. The load-bearing words are explicit — the commitments are written down and machine-readable — and, after Borst, shared — more than one party agreed.

Verdict Worth studying, and short enough to read in full. The definition is the hinge between the philosophical and engineering senses of the word, and knowing which two words carry the weight — explicit, and after Borst shared — settles most arguments about whether a given artifact qualifies.

Sources consulted

• https://tomgruber.org/writing/definition-of-ontology/
• https://tomgruber.org/writing/onto-design.pdf
• https://iaoa.org/isc2012/docs/Guarino2009_What_is_an_Ontology.pdf
• research/firecrawl/gruber-definition.md
• research/firecrawl/guarino-what-is-ontology.md
• research/firecrawl/gruber-onto-design.md
• research/firecrawl/pltr-ontology-overview.md

History of the Word “Ontology”

What it is The philosophical lineage behind the word that computer science borrowed. Aristotle named the subject without naming the word: Britannica says the subject “was called ‘first philosophy’ by Aristotle in Book IV of his Metaphysics,” and Guarino, Oberle and Staab gloss his definition of it as the science of “being qua being,” meaning “the study of attributes that belong to things because of their very nature.” The Latin coinage came almost two thousand years later, and its priority is contested. Britannica credits Jacob Lorhard, who used ontologia in Ogdoas Scholastica in 1606. Ferrater Mora, writing without Lorhard, says “the first instance occurs in Rudolf Goclenius” in his Lexicon philosophicum of 1613. Johann Clauberg is often credited — Ferrater Mora names Eucken, Gilson, Pichler, Wundt and Heimsoeth as making that attribution — and rebuts it: Clauberg published Ontosophia only in 1647, after the term was already in use. Christian Wolff put it into general circulation with Philosophia prima sive ontologia in 1730; Ferrater Mora records his definition as scientia entis in genere, quatenus ens est, the science of being in general as being.

Key concepts Being qua being; first philosophy; general metaphysics versus special metaphysics; ontologia 1606; Wolff’s “demonstrative [i.e., rational and deductive] method”; Kant’s attack on general metaphysics; Husserl’s “formal ontology”; Heidegger’s Dasein; the split between ontology as a question about reality and ontology as an artifact you can build.

How you’d use it Use this history to keep three senses of the word apart when reading anything about ontologies. Sense one is the philosophical discipline: what exists. Sense two is a specific philosophical theory of what exists, which is why philosophers say “Quine’s ontology” the way engineers say “the FIBO ontology.” Sense three is the computer-science artifact: a file containing a formal vocabulary. Britannica records that “Wolff contrasted ontology, or general metaphysics, which applied to all things, with special metaphysical theories such as those of the soul, of bodies, or of God.” The same shape recurs in the engineering tradition, where Guarino, Oberle and Staab say “the primary purpose of top-level ontologies lies in providing a broad view of the world suitable for many different target domains” — see bfo-basic-formal-ontology.md and common-core-ontologies-cco.md for what that looks like in practice. The resemblance is mine to point out; no source in this corpus claims descent.

LLM angle none stated

Pitfalls & lessons Do not treat the engineering sense as a straightforward continuation of the philosophical one. Wolff’s ontology used a “demonstrative [i.e., rational and deductive] method” and, on Ferrater Mora’s account, took the human intellect to be capable of knowing the essence of things. Gruber, by contrast, describes formal ontologies as “designed artifacts, formulated for specific purposes and evaluated against objective design criteria” — an engineering ontology is one of many possible models of the same domain. Reading across the two senses without marking the switch is my own warning, not a claim any source here makes: the slide is easy, and it can smuggle in a claim of objectivity the artifact has not earned.

Verdict Worth studying. It is the cheapest way to stop confusing the three senses of the word, and the general-versus-special split it records is the shape the engineering tradition later reinvented as upper versus domain ontologies.

Sources consulted

• https://www.britannica.com/topic/ontology-metaphysics
• https://www.ferratermora.org/essa_ontology.html
• https://www.etymonline.com/word/ontology
• https://iaoa.org/isc2012/docs/Guarino2009_What_is_an_Ontology.pdf
• research/firecrawl/phil-britannica.md
• research/firecrawl/phil-ferratermora.md
• research/firecrawl/phil-etymonline.md
• research/firecrawl/guarino-what-is-ontology.md
• research/firecrawl/gruber-onto-design.md

Quine and Ontological Commitment

What it is Quine’s 1948 paper “On What There Is” gives the criterion that makes ontology tractable for engineers. Quine’s problem was that arguments about what exists get stuck: to deny that something exists, you seem to have to refer to it first. His move was to stop asking what exists and start asking what a theory says exists. A theory’s ontological commitments are whatever must be in the range of its quantified variables for its statements to come out true. His slogan, in his own words, is “To be is to be the value of a variable” — the familiar “bound variable” version of it is Boolos’s later title, not Quine’s sentence. Quine’s own statement of the criterion is that “a theory 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.”

Key concepts Ontological commitment; “To be is to be the value of a variable”; regimenting a theory into first-order logic to read off its commitments; ontology as a property of a language rather than of the world; the criterion says nothing about which theory is correct.

How you’d use it Use Quine’s criterion as a debugging tool on any schema, database, or ontology. Ask what the model quantifies over. If your system has an Employee table with a manager_id, the schema is committed to employees and to a managing relation, but not to teams, contracts, or roles. If a competency question requires teams and nothing in the model quantifies over teams, no amount of querying will produce an answer. Guarino, Oberle and Staab give a construction of the same shape without citing Quine: an ontological commitment is a total function mapping each vocabulary symbol either to an element of the domain or to an intensional relation, which in turn fixes the set of intended models. Their paper never mentions Quine, so read the resemblance as structural rather than as a lineage anyone has traced.

LLM angle none stated

Pitfalls & lessons The criterion is deliberately neutral about truth. Quine says so directly: asked “how are we to adjudicate among rival ontologies? Certainly the answer is not provided by the semantical formula ‘To be is to be the value of a variable’.” It tells you what a theory is committed to, not whether the theory is any good. Quine also observes that “disagreement in ontology involves basic disagreement in conceptual schemes” while the schemes still converge in practice. My own reading of that, not his: two teams can model the same domain with different commitments and neither be at fault, which makes ontology alignment a standing engineering problem rather than a sign that somebody blundered.

Verdict Worth studying, and short. Quine’s criterion is the one philosophical idea in this corpus that transfers directly to a schema review, because it turns “what exists” into the answerable question “what does this model quantify over.”

Sources consulted

• https://rintintin.colorado.edu/~vancecd/phil375/Quine.pdf
• https://plato.stanford.edu/entries/ontological-commitment/
• https://iaoa.org/isc2012/docs/Guarino2009_What_is_an_Ontology.pdf
• research/firecrawl/quine-onwhatthereis.md
• research/firecrawl/quine-sep-commitment.md
• research/firecrawl/guarino-what-is-ontology.md

The Knowledge Graph Turn (2012 onwards)

What it is The rebranding and repositioning that let ontology technology survive the Semantic Web’s disappointment. Google launched the Knowledge Graph in May 2012 and announced it under the title of Amit Singhal’s post “Introducing the Knowledge Graph: Things, Not Strings.” It was built largely on Freebase: “Google’s Knowledge Graph derives from Freebase, a proprietary graph database acquired by Google in 2010 when it bought Metaweb.” Ars Technica records the jump in scale — “when Google purchased Metaweb, Freebase’s database had 12 million entities; Knowledge Graph now tracks 500 million entities.” Microsoft shipped Satori for Bing in the same period: “as of June 1, Satori had mapped over 400 million entities and Knowledge Graph had reached half a billion.” The phrase “knowledge graph” then spread past any single definition; as one survey puts it, “the definition of a ‘knowledge graph’ remains contentious, where a number of (sometimes conflicting) definitions have emerged, varying from specific technical proposals to more inclusive general proposals.” Google’s own graph is not built on the W3C stack; Satori, by contrast, “uses the Resource Description Framework and the SPARQL query language.”

Key concepts Things not strings; heterogeneity of entities, schemas, and values as the integration problem the VLDB survey foregrounds; the shift from open-web publishing to proprietary curated graphs; schema.org as the surviving open vocabulary, “started by Google, Bing, and Yahoo with the express purpose of delivering better search results”; the VLDB account of three generations — entity-based, text-rich, and dual neural knowledge graphs — “and the business impact”; Wikidata, which the two-decades-on survey lists among the field’s success stories.

How you’d use it Use the distinction to avoid a common category error. A knowledge graph is a data-shaped commitment: entities and relations rather than rows and joins. An ontology is a semantic commitment: a formal vocabulary with axioms whose consequences a reasoner can derive. Many production knowledge graphs have no ontology in the formal sense, and this corpus documents a concrete case: scigraph.md records an OWL-to-Neo4j mapping that “is explicitly lossy and does not round-trip ontologies.”

LLM angle The knowledge-graph framing is the one current retrieval work inherits. The VLDB survey’s position is that “at the current moment, LLMs clearly have not replaced knowledge graphs,” the stated reason being hallucination. How often the graph is justified as model grounding rather than as an agent substrate is my impression, not a measured claim any source here makes.

Pitfalls & lessons The turn traded openness for viability. The 2001 plan was that anyone could publish data and any agent could use it. What shipped is a small number of large private graphs that a provider must feed to be visible. Berners-Lee’s decentralisation requirement was the casualty, and it was the point of the original design: “today we are stuck with giant, centralized repositories of information,” and “no precedent exists in the Semantic Web setting for the type of decentralised infrastructure envisaged by Berners-Lee.”

Verdict Worth studying, mostly as a corrective. It explains why the word “ontology” and the word “knowledge graph” are not interchangeable, and why most things sold as knowledge graphs carry no formal semantics at all.

Sources consulted

• https://arstechnica.com/information-technology/2012/06/inside-the-architecture-of-googles-knowledge-graph-and-microsofts-satori/
• https://www.vldb.org/pvldb/vol16/p4130-dong.pdf
• https://www.technologyreview.com/2012/06/14/19504/googles-new-brain-could-have-a-big-impact/
• research/firecrawl/kg-arstechnica-2012.md
• research/firecrawl/kg-generations-vldb.md
• research/firecrawl/semweb-twobithistory.md
• research/firecrawl/semweb-two-decades-on.md
• research/exa/kg-revival.json (launch month; definitional contention)

The Semantic Web Vision (Berners-Lee, Hendler, Lassila 2001)

What it is The Scientific American article that moved ontologies from an AI research topic to a web-scale programme. Tim Berners-Lee, James Hendler, and Ora Lassila argued that the web should carry not only documents but data with machine-readable meaning, so that software agents could act on it. The article opens with a scenario in which Pete and Lucy’s agents negotiate their mother’s physical-therapy appointments against provider ratings, insurance coverage, and both siblings’ calendars, with no service having been built to talk to any other. Berners-Lee, Sinclair Target records, later “began referring to the Semantic Web as Web 3.0.”

Key concepts Machine-readable meaning as an extension of the existing web rather than a replacement; agents that compose services they were never wired to, so that “programs could exchange data across the Semantic Web without having to be explicitly engineered to talk to each other”; RDF triples as the grammar; ontologies supplying the shared terms; decentralisation as the point.

How you’d use it Read the 2001 article as the design brief that produced RDF, RDFS, and OWL. Target’s account connects those three to it directly: RDF as “the grammar in which Semantic webpages expressed information,” and “RDF Schema and another standard called OWL” as the way to “make inferences about omitted information.” Reading the rest of the stack, SPARQL included, as answers to the same brief is my own reconstruction and not a claim any source here makes; SPARQL postdates the article by five years. The article does explain a persistent cultural trait of the field, which is that the standards were built for an open world. Horrocks, Patel-Schneider and van Harmelen state the reason plainly: OWL “adopts the standard logical model of an open world assumption: a statement cannot be assumed true on the basis of a failure to prove it. Clearly, on the huge and only partially knowably World Wide Web this is the correct assumption.”

LLM angle The 2001 agent scenario is close to what current tool-using language-model agents attempt, with one inversion. The Semantic Web plan was to make the data structured enough for a simple agent. The current plan is to make the agent capable enough for unstructured data. The scenario is the same, the layer doing the work moved.

Pitfalls & lessons The vision assumed voluntary, accurate, widespread annotation by publishers with no direct incentive to provide it. Target’s summary of the objection is that “most web users were likely to provide either no metadata at all or else lots of misleading metadata meant to draw clicks.” That assumption is the single point on which most later criticism turns.

Verdict Worth reading in full, and it is six pages. Every later argument in this corpus — the standards, the criticism, the knowledge-graph turn, the agent pitch — is either executing this brief or objecting to it.

Sources consulted

• https://www.scientificamerican.com/article/the-semantic-web/
• https://www-sop.inria.fr/acacia/cours/essi2006/Scientific%20American_%20Feature%20Article_%20The%20Semantic%20Web_%20May%202001.pdf (archived full text)
• https://twobithistory.org/2018/05/27/semantic-web.html
• https://www.cs.ox.ac.uk/people/ian.horrocks/Publications/download/2003/HoPH03a.pdf
• research/firecrawl/semweb-sciam-2001.md (paywall stub: masthead only, no article body)
• research/firecrawl/semweb-sciam-2001-fulltext.md (archived PDF of the full article)
• research/firecrawl/semweb-twobithistory.md
• research/firecrawl/semweb-two-decades-on.md
• research/firecrawl/semweb-making-of-owl.md

What Happened to the Semantic Web

What it is The retrospective account of why the 2001 programme did not arrive as described. Sinclair Target’s Two-Bit History account of 27 May 2018 sets out a periodisation in four phases. The first, “from 2001 to 2005, was the golden age of Semantic Web activity,” in which “the W3C issued the first version of the RDF standard in 2004.” The second shifted “from setting standards and building toy examples to creating and popularizing large RDF datasets” — linked open data. The third “involved adapting the W3C’s standards to fit the actual practices and preferences of web developers,” which produced JSON-LD and schema.org. The fourth is the W3C’s retrenchment “under the heading of ‘Data Activity’.” The move to enterprise and scientific deployment is a separate thread, argued by Ontotext rather than by Target. Aaron Swartz, in an unfinished book published after his death, argued that Doctorow was attacking a straw man and located the failure elsewhere: the “formalizing mindset of mathematics and the institutional structure of academics” produced years of standards debate before there were applications to standardise, and the standards that emerged were too abstract to adopt.

Key concepts Standards before applications; RDF’s origins in Ramanathan Guha’s metadata work at Apple; XML’s associated machinery as a cost JSON undercut — “whereas XML came packaged with a bunch of associated technologies of indeterminate purpose … JSON was just JSON. It was less verbose and more readable”; the shift from annotate-the-open-web to publish-a-dataset (linked open data) to model-an-enterprise; centralisation of the agent layer into Google, Yelp, Siri, so that a provider advertises to the platform rather than from its own site; the survival of the machinery in biomedicine, cultural heritage, and finance.

How you’d use it Use the periodisation to date any claim you read. Criticism written in the early 2000s — Doctorow’s Metacrap is dated 26 August 2001 — is aimed at annotating the open web by hand, and mostly landed. The successes the retrospectives themselves name are schema.org, knowledge graphs, Wikidata, DBpedia and biomedical ontologies: governed, funded, bounded domains where somebody has an incentive to curate. This corpus documents further cases in the same shape — see gene-ontology-go.md, cidoc-crm-conceptual-reference-model.md and fibo.md — though no retrospective in this corpus names them. When evaluating a new ontology proposal, ask which of these two situations it resembles.

LLM angle Ontotext argues the machinery found its market as the substrate for enterprise knowledge graphs rather than as an open-web annotation layer: “enterprise knowledge graphs came as a second wave to serve a different purpose.” That post says nothing about language models. The retrieval leg comes from elsewhere: the VLDB survey of knowledge-graph generations notes that “at the current moment, LLMs clearly have not replaced knowledge graphs,” citing hallucination — see knowledge-graph-turn.md.

Pitfalls & lessons The strongest lesson in the retrospective is about sequencing rather than semantics. A committee that specifies before anyone ships produces artifacts nobody adopts. Schema.org succeeded partly because search engines gave publishers a direct reason to comply: it “was started by Google, Bing, and Yahoo with the express purpose of delivering better search results,” and its team “are careful to state on their website that they are not attempting to create a ‘universal ontology’.”

Verdict Worth reading before any argument about whether ontologies work. It supplies the dates that decide which criticism is aimed at what, and the sequencing lesson — applications before standards — is the one most reusable outside this field.

Sources consulted

• https://twobithistory.org/2018/05/27/semantic-web.html
• https://twobithistory.org/about.html (byline)
• https://semantic-web-journal.net/system/files/swj2303.pdf
• https://www.ontotext.com/blog/the-semantic-web-20-years-later/
• https://www.cs.ox.ac.uk/people/ian.horrocks/Publications/download/2003/HoPH03a.pdf
• research/firecrawl/semweb-twobithistory.md
• research/firecrawl/semweb-two-decades-on.md
• research/firecrawl/semweb-ontotext-20yr.md
• research/firecrawl/semweb-making-of-owl.md
• research/firecrawl/semweb-twobithistory-about.md
• research/firecrawl/crit-doctorow-metacrap.md
• research/firecrawl/kg-generations-vldb.md

The Palantir Ontology

What it is Palantir’s Ontology is the operational layer at the centre of Foundry’s architecture. Palantir’s own architecture documentation states that it is designed to represent the interconnected decisions of an enterprise rather than its data, and that it is explicitly “not a semantic layer.” It sits above integrated datasets, virtual tables, and models, and connects them to real-world counterparts — plants, equipment, products, customer orders, financial transactions. Palantir describes it in many settings as a digital twin of the organisation.

Key concepts

• The fourfold integration: data, logic, action, and security. Data flows in from ERP estates, systems of record, CRMs, industrial databases, geospatial repositories, sensors, and document stores, and is unified into objects, properties, and links.
• Semantic elements — the nouns. An object type is the schema definition of a real-world entity or event; an object is one instance; an object set is a collection. A link type defines a relationship between two object types and is bidirectional, with two independently traversable sides. Palantir’s own analogy: an object type is like a dataset, an object like a row, an object set like a filtered set of rows, and a link type like a join.
• Kinetic elements — the verbs. An action type is “the definition of a set of changes or edits to objects, property values, and links that a user can take at once”; an action is “a single transaction.” It “includes the side effect behaviors that occur with action submission” — Palantir’s worked example is a notification to the old and new manager on a role change. The action-types documentation points onward to “rules, parameters, and submission criteria.” Functions “provide a way to author and evolve business logic with arbitrary complexity”; the logic behind a given action “could be a simple business rule, a conventional machine learning model, an LLM-driven function, or a complex multi-step orchestration that involves several compute engines.” Interfaces “provide object type polymorphism, allowing for consistent modeling of and interaction with object types that share a common shape.”
• Writeback. Edits commit to the Ontology, propagate to every application, and are captured in an object type’s writeback dataset, so user decisions become data.
• Security as a first-class element, enforced across data, logic, and action simultaneously, with agents inheriting scope from a human user or a project’s permission structure.
• Language, Engine, and Toolchain as the three component groups of the system.

How you’d use it Compare it against the W3C stack rather than assuming it competes. The comparison that follows is mine: Palantir’s documentation never mentions OWL, RDF, the W3C, reasoners, or world assumptions, so nothing below is a Palantir claim. Both aim at shared meaning across heterogeneous sources, and there the resemblance stops. OWL is a logic with model-theoretic semantics under an open-world assumption, designed for anonymous parties on a public web, with reasoners that derive consequences — see owl-2-web-ontology-language.md and description-logics-dls.md. Palantir’s Ontology is a closed-world operational system for one organisation, whose distinguishing feature is that it models actions and permissions as first-class primitives. OWL cannot express “an HR employee may reassign this person’s role, and doing so notifies both managers.” That gap is the product.

LLM angle Palantir positions the Ontology as the tool surface for AI agents, and explicitly against retrieval as the framing: it “enables LLMs to go beyond the data-centric limitations of retrieval-augmented generation, and instead interface with the interconnected data, logic, and action primitives … through an extensible tools paradigm.” The Ontology is “a ‘tool factory’ that lets your builders define tools for both humans and agents,” actions “can be automatically surfaced as tools for AI-driven copilots and automations,” and the security system “has to reconcile all of these granular policies, at the time of interaction, across tens of thousands of humans and agents.” The pitch, in my summary, is that an agent gets a governed set of nouns it can read and verbs it is permitted to invoke rather than the tables underneath.

Pitfalls & lessons The vocabulary is borrowed from the formal tradition, and Palantir acknowledges some of that debt at the data-type level: its type reference says “data types in Foundry are inspired by similar concepts in RDF, OWL and XSD.” The semantics are not borrowed. My reading, since the documentation neither asserts nor denies it: there is no reasoner deriving subsumption, no open-world assumption, and no shared public vocabulary, so reading Palantir’s “ontology” as an OWL ontology, or as an implementation of the Semantic Web programme, misdescribes both. Palantir does state one hard boundary itself: “links between object types across different Ontologies is not supported.”

Verdict Worth studying, and the most useful counterexample in this corpus. It shows that the commercially successful sense of the word keeps the nouns, drops the logic, and adds verbs and permissions — which tells you what the market actually wanted from an ontology.

Sources consulted

• https://palantir.com/docs/foundry/architecture-center/ontology-system/
• https://palantir.com/docs/foundry/ontology/overview/
• https://palantir.com/docs/foundry/object-link-types/object-types-overview/
• https://palantir.com/docs/foundry/object-link-types/link-types-overview/
• https://palantir.com/docs/foundry/action-types/overview/
• https://www.palantir.com/platforms/ontology/
• https://blog.palantir.com/connecting-ai-to-decisions-with-the-palantir-ontology-c73f7b0a1a72
• https://palantir.com/docs/foundry/object-link-types/type-reference/
• research/firecrawl/pltr-ontology-system.md
• research/firecrawl/pltr-ontology-overview.md
• research/firecrawl/pltr-object-types.md
• research/firecrawl/pltr-link-types.md
• research/firecrawl/pltr-action-types.md
• research/firecrawl/pltr-platform-ontology.md
• research/firecrawl/pltr-blog-ai-decisions.md
• research/exa/palantir-ont.json

Bowker and Star, “Sorting Things Out” (1999)

What it is An ethnographic study of classification systems and information infrastructure, and the deepest criticism of ontology work in this corpus. Reviewing it, Terrence A. Brooks writes that “it is the accomplishment of this book to recognize classification itself as an object of study, as a vehicle for ethnography,” and that the effect of its examples “is to illustrate how values, policies and modes of practice become embedded in large information systems and become expressed in classification systems.” The book’s best-known concept is torque. Stefan Helmreich’s review essay gives the definition: Bowker and Star “introduce the force metaphor of ‘torque’ to describe the process that unfolds when ‘the “time” of the body and of [its] multiple identities cannot be aligned with the “time” of the classification system’.“ Helmreich adds that “individual biographies are twisted into tortured shapes” where the scheme and everyday life do not line up, and that Bowker and Star “argue that there is no experience of torque for those in power.”

The account below follows Brooks’s and Helmreich’s reviews and Eric Nehrlich’s reading notes; the primary text has not been read for this note.

Key concepts

• The International Classification of Diseases. On Nehrlich’s account, “developing this classification took many years and there are still many disagreements over it.” “Tropical countries believe that tropical diseases are grossly underrepresented compared to ‘rich-world’ diseases like cancer and heart disease.” “In Japan, heart attacks are considered a low-status way of dying, so death certificates will often list a stroke as the cause of death, leading to a skewing of results when compared to other nations.”
• Apartheid race classification in South Africa. Brooks describes “South African citizens who have been tossed back and forth between being classified as Whites, then Coloreds, then back again”; Nehrlich records that “a government declaration of one’s race forced one to change residences, jobs and families.” Helmreich works through a case where a boy classified as Asian at birth would, on reaching majority, be reclassified African under a different statute. Reading that as a category acting on a person rather than describing one is my gloss, not theirs.
• Tuberculosis patients, wholly dependent on a doctor’s diagnosis for their own status.
• The Nursing Interventions Classification. “Nurses were asked to describe what they do, so that it could be classified, standardized, and integrated into a billing system.” “Some nurses cheered the fact that they would now be ‘in the system’. Others were aghast that they would not be free to do what they thought was right.” Nehrlich notes that in this case “the tension between the system, and between the local adaptations one has to make for the system to actually function, was made clearly evident.”
• Black-boxing. “Classification systems tend to get black-boxed, in the sense of Bruno Latour. They tend to become invisible, and we forget how much effort went into creating them, and the political and ethical issues that were bound up in their creation.”

How you’d use it Use torque as a review question on any operational ontology: when a real case does not fit a category, who bears the cost? Helmreich’s point that “there is no experience of torque for those in power” is the sharp end of it — if the cost lands on a person outside the room, the modelling decision is a policy decision and should be made accordingly. Nehrlich’s second lesson is the companion: “there will always be elements which do not slot neatly into a category. But it is important to remember that this is not a reflection of the element — it is a reflection of the inadequacy of the system.” His example is the platypus.

LLM angle none stated

Pitfalls & lessons The book’s argument is not that classification is avoidable. It is that classification is consequential and usually invisible, so the only real choice is whether the consequences are examined. Brooks objects that “the survey treatment … leads to multiple examples that pile on and do not advance the argument,” that “the research challenge is to take the next step and establish certain classification characteristics are associated with certain human, linguistic or institutional characteristics,” and that the book “is, however, strangely disconnected from a large body of empirical, cognitive research in classification and categorization that already exists.” Take the case studies as demonstrations rather than as a predictive theory.

Verdict Worth deeper study, and the only book in this corpus that treats classification as a political act with named victims. Read it after you know how the machinery works, so the argument lands on something concrete.

Sources consulted

• https://mitpress.mit.edu/9780262522953/sorting-things-out/
• https://nehrlich.com/book/sortingthingsout.html
• https://faculty.washington.edu/tabrooks/Documents/bowkerReview.htm
• https://muse.jhu.edu/article/44230 (Helmreich, “Torquing Things Out,” review essay)
• research/firecrawl/crit-sorting-things-out.md (MIT Press page: date, authors, case-study list)
• research/firecrawl/crit-torquing-review.md (failed scrape: MIT Anthropology 404)
• research/firecrawl/crit-torquing-review-refetch.md (Helmreich review essay, re-fetched from the Internet Archive)
• research/.firecrawl/faculty.washington.edu-tabrooks-Documents-bowkerReview.htm.md (Brooks review)
• research/.firecrawl/nehrlich.com-book-sortingthingsout.html.md (Nehrlich reading notes)

Criticism of Operational Ontologies (Palantir)

What it is The research and legal record on what happens when a vendor ontology is installed inside a state institution. The most direct study is Vasilis Galis and Björn Karlsson’s 2024 paper, written at the IT University of Copenhagen, on POL-INTEL, the Danish police’s customisation of Palantir’s Gotham, based on interviews with Palantir engineers and police-officer users.

Key concepts

• Ontology in two senses at once. The authors write that “the concept of ontology should be understood in a twofold, albeit interconnected, way: it stands for its usual philosophical burden, but also refers to a centralized concept repository.” They then borrow Barry Smith’s terminological split between theory-focused R-ontologies and pragmatically oriented E-ontologies, and argue that “the platform’s E-ontology cannot be separated from Palantir’s and/or the police.”
• The ontology is political. “POL-INTEL’s ontology is inherently political, as it is articulated by an assemblage of data, ideological positions, and economic concerns that are translated into the Danish context.” Such devices, they write, quoting Leese, “not only describe the world but also enact it.”
• The getaway-vehicle example. A car’s record is mirrored from the Motor Vehicle registry. Inside the platform, viewed by an officer applying filters, it is potentially seen as a getaway vehicle. The category is produced by the interplay of the platform’s concepts and the officer’s analytical role, not by the registry.
• Platformisation redistributes skill. The paper reports new distributions of capability between the platform and the officer, with consequences for organisational life and accountability.
• The German constitutional ruling. In its judgment of 16 February 2023 (1 BvR 1547/19, 1 BvR 2634/20) the Bundesverfassungsgericht “held that § 25a(1) first alternative of the Security and Public Order Act for the Land Hesse … and § 49(1) first alternative of the Act on Data Processing by the Police for the Land Hamburg … are unconstitutional.” The remedies differ: the Hamburg provision “is void,” while the Hesse provision “will continue to apply, subject to the restrictions set out below, until new provisions have been enacted, and in any case no later than 30 September 2023.” The court’s reasoning 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 the court “issued strict guidelines for the first time about how automatic data analysis tools like Palantir’s can be used by police” and “warned against the inclusion of data belonging to bystanders, such as witnesses or lawyers.” One of the eleven claimants was Britta Eder, a Hamburg defence lawyer whose “client list includes anti-fascists, people who campaign against nuclear power, and members of the PKK.”

How you’d use it Use this as the applied version of Bowker and Star — see bowker-star-sorting-things-out.md, where torque is the twisting that happens when a person’s own account of themselves cannot be aligned with the classification system. It becomes concrete when the classification is enforced by a state platform: the residual categories, the link types that make two people related, and the thresholds inside a function are policy choices with legal consequences, made by engineers. When reviewing an operational ontology, ask which object and link types create legal exposure, whose data enters as a by-product of proximity rather than suspicion, and whether an action’s audit trail can reconstruct why a person was surfaced.

LLM angle Adding agents that both query the ontology and invoke its actions increases the volume of decisions taken through these categories, and the governance and audit questions scale with it.

Pitfalls & lessons The criticism is not that the modelling is technically wrong. Galis and Karlsson grant that these platforms “pragmatically integrate, analyze, and visualize data” — and then land the distinction: “Pragmatically, not agnostically. Data integration and analysis platforms are formatted, framed, and encoded with concepts: through their ontology, they perform politics.” They are blunter still elsewhere: “platforms such as POL-INTEL are not encoded with democratic values or other modernist sensibilities.” 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.

Verdict Worth deeper study, and the place to start if you want the consequences argument rather than the technique. It is the only source in this corpus where a modelling decision has a court ruling attached to it.

Sources consulted

• https://doi.org/10.1080/1369118X.2024.2410255 (Galis and Karlsson, Information, Communication & Society 27:13, 2438-2456)
• https://www.bundesverfassungsgericht.de/SharedDocs/Pressemitteilungen/EN/2023/bvg23-018.html (judgment of 16 February 2023)
• https://www.wired.com/story/palantir-germany-gotham-dragnet/
• https://theconversation.com/when-the-government-can-see-everything-how-one-company-palantir-is-mapping-the-nations-data-263178
• research/firecrawl/pltr-crit-polintel.md
• research/firecrawl/pltr-crit-wired-germany.md
• research/firecrawl/pltr-crit-conversation.md
• research/firecrawl/pltr-crit-bverfg-pressrelease.md
• research/firecrawl/pltr-crit-seer-seen.md (failed scrape: HTTP 403; not relied on)

Doctorow, “Metacrap” (2001)

What it is Cory Doctorow’s essay against voluntary metadata, version 1.0 dated 15 May 2001 and version 1.3 dated 26 August 2001 — months after the Scientific American article, though Doctorow never mentions it, the Semantic Web, or Berners-Lee. His stated target is broader: “explicit, human-generated metadata has enjoyed recent trendiness, especially in the world of XML.” His thesis is that a world of exhaustive, reliable metadata would be a utopia, and is also “a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities.” He gives what he calls “at least seven insurmountable obstacles,” under the section title “seven straw-men.”

Key concepts The seven obstacles:

1. People lie. Metadata exists in a competitive world, and when poisoning the well pays, the well gets poisoned. His examples are spam subject lines and keyword-stuffed press releases.
2. People are lazy. Untitled files, subject-less email, MP3s with no track information despite a one-click lookup button.
3. People are stupid. His eBay example: search “plam” and find nine misspelled Palm Pilots, cheap, because misspelled listings never appear in correct searches.
4. Mission: Impossible — know thyself. “People are lousy observers of their own behaviors.” Nielsen’s log-books skewed heavily to Masterpiece Theater and Sesame Street; replacing the journals with set-top boxes “showed what the average American family was really watching.”
5. Schemas aren’t neutral. A maker of efficient washing machines ranks by energy and water use. A maker of feature-laden ones ranks by colour and programmability. Any hierarchy asserts that some axes matter more.
6. Metrics influence results. “Agreeing to a common yardstick … necessarily privileges the items that score high on that metric.” His example: MTV stopped showing videos because “Nielsen couldn’t generate ratings for three-minute mini-programs, and so MTV couldn’t demonstrate the value of advertising on its network.”
7. There is more than one way to describe something. Requiring one vocabulary “denudes the cognitive landscape.”

How you’d use it Use obstacles 1 to 4 as an incentive audit on any proposed ontology. Ask who enters the data, what they gain from entering it well, and what they gain from entering it badly. Use obstacles 5 to 7 as a design review: name the axes the model privileges and say out loud whose interests they serve.

LLM angle Language models change the economics of obstacles 2, 3, and 4 by extracting structure that nobody wanted to type. They do nothing about 1, 5, 6, or 7, because those are about incentives and power rather than effort.

Pitfalls & lessons Doctorow’s own conclusion is not that metadata is worthless. He endorses implicit metadata, citing Google’s use of link structure — data produced as a by-product of behaviour rather than declared. In his words, “this sort of observational metadata is far more reliable than the stuff that human beings create for the purposes of having their documents found.” That distinction, observed signal versus declared signal, is the durable part of the argument.

Verdict Worth reading in full; it is short, and it is the incentive argument every ontology proposal has to answer. Read it as an attack on hand-declared metadata generally, not as a reply to the Semantic Web article — it never mentions it.

Sources consulted

• http://www.well.com/~doctorow/metacrap.htm (original)
• https://chnm.gmu.edu/digitalhistory/links/pdf/preserving/8_17.pdf (archived copy consulted)
• research/firecrawl/crit-doctorow-metacrap.md

Shirky, “Ontology Is Overrated” (2005)

What it is Clay Shirky argues that designing categories in advance to cover cases that have not happened yet is badly overrated in digital systems. His own wording is that the strategy “is both widely used and badly overrated in terms of its value in the digital world.” The essay is “a heavily edited concatenation” of two 2005 talks: “Ontology Is Overrated” at O’Reilly ETech in March and “Folksonomies & Tags” at IMCExpo in April. He is precise about his target: not classification in general, but ontological classification, which organises entities by their essences and possible relations, and assumes a new item’s logical place already exists before the item does.

Key concepts

• The periodic table as the best case. It organises by proton count and gets enormous predictive value. Even so, “noble gas” is a frozen accident: helium is no more essentially a gas than mercury is essentially a liquid, but the chemists could not get it cold enough to see that. If a near-perfect scheme over physical essences still has context errors, softer domains have no chance.
• Library catalogues optimise for shelves, not concepts. Dewey’s 200s split religion into nine subdivisions, eight of them Christian or Christian-adjacent, with everything else in “290 Other religions.” Library of Congress History puts DA Great Britain and DC France at the same level as DR Balkan Peninsula, DS Asia and DT Africa: “these are all the top-level categories — all of these things are presented as being co-equal.” What is being optimised is books on a shelf. “The essence of a book isn’t the ideas it contains. The essence of a book is ‘book.’”
• There is no shelf. Digital items have no physical constraint forcing one item into one place, so the constraint that produced hierarchical classification is gone.
• The parable of the ontologist. Yahoo, free of physical constraints, hired a professional ontologist and added the shelf back: Books and Literature appears in Entertainment with an “@” marking that it is not really there. Yahoo chose to assert what is real rather than let items sit in many places at once.
• The alternative. Links and tags. Free-form labelling looks like a recipe for disaster, but large messy data sets yield surprising value.

How you’d use it Shirky offers not a test but what he calls “a partial list of characteristics,” in two groups. Domain: small corpus, formal categories, stable entities, restricted entities, clear edges. Participants: expert catalogers, an authoritative source of judgment, coordinated users, expert users. “The more of those characteristics that are true, the better a fit ontology is likely to be.” His worked positive examples are the periodic table and the DSM-IV, “a classic example of an classification scheme that works because of these characteristics”; his negative list is the mirror image — large corpus, no formal categories, unstable entities, no clear edges, uncoordinated and amateur users. Inverting the list into a go/no-go screen for a project is my framing, not his.

LLM angle none stated

Pitfalls & lessons The essay is regularly overread as “ontologies are useless.” Shirky attacks a priori categorisation applied to unbounded, uncoordinated, user-facing corpora. He does not deny that the periodic table works. Dave McComb of Semantic Arts published a direct rebuttal in 2015 to Shirky’s earlier syllogism essay of 7 November 2003, arguing that “this entire article is a syllogism” and conceding that “we still have a long way to go to staunch the critics.”

Verdict Worth reading in full. It is the sharpest statement of when formal classification does not pay, and its characteristic list is directly reusable as a project screen — provided you notice that Shirky offers it as description, not as a decision procedure.

Sources consulted

• http://shirky.com/essays/ontology-is-overrated-categories-links-and-tags/
• http://shirky.com/essays/the-semantic-web-syllogism-and-worldview/
• https://www.semanticarts.com/shirky-syllogism-and-the-semantic-web/
• research/firecrawl/crit-shirky-overrated.md
• research/firecrawl/crit-shirky-syllogism.md
• research/firecrawl/crit-semanticarts-reply.md

BFO (Basic Formal Ontology)

What it is BFO is a small upper-level ontology intended to support information retrieval, analysis, and integration across scientific and other domains. As a genuine upper ontology, it deliberately excludes physical, chemical, biological, and other terms belonging to specialized sciences.

Key concepts Upper ontology; domain neutrality; information retrieval; analysis; integration; adoption by more than 550 ontology-driven efforts.

How you’d use it Use BFO as a domain-independent top-level framework beneath a specialized ontology, consulting the project’s guidebook, publications, tutorials, release history, and user forums as needed.

LLM angle none stated

Pitfalls & lessons Do not expect BFO itself to supply specialized scientific-domain terms; the site explicitly places those outside its scope.

Verdict A widely used, intentionally small foundation for aligning domain ontologies around a shared upper-level structure.

Sources consulted

• http://basic-formal-ontology.org/

DBpedia Ontology (DBO)

• What it is — The DBpedia Ontology is described as the heart of DBpedia: a shallow, cross-domain ontology that began from commonly used Wikipedia infoboxes and evolved through community-maintained ontology schema and infobox mappings. The fetched page reports a class subsumption hierarchy, thousands of properties, and millions of instances.

• Key concepts — Classes and properties form the TBox, while RDF type statements, object relations, literal facts, and normalized properties form ABox data. Since DBpedia 3.7, the class hierarchy is a directed acyclic graph rather than a tree, allowing multiple superclasses; infobox mappings normalize differing infoboxes, property names, datatypes, and parsing rules.

• How you’d use it — Download development or release-aligned ontology versions, query the ontology through DBpedia’s SPARQL endpoint, obtain TBox and ABox dump files, browse the hierarchy and instances, or contribute mappings and ontology extensions through the public mappings wiki.

• LLM angle — none stated

• Pitfalls & lessons — Development snapshots and monthly dataset releases are distinct, so consumers must choose a version deliberately. Multiple inheritance means the ontology is not intrinsically a tree; the page says a taxonomy can be produced only by ignoring all but the first, most important superclass. The mapping system exists partly because raw Wikipedia infoboxes use inconsistent classes, property names, and datatypes.

• Verdict — Worth deeper study as a large, community-maintained cross-domain ontology tightly coupled to a public knowledge graph and an explicit mapping/release workflow.

Sources consulted

• https://www.dbpedia.org/resources/ontology/

DOLCE (Descriptive Ontology for Linguistic and Cognitive Engineering)

What it is DOLCE is a foundational ontology developed and maintained by the ISTC-CNR Laboratory for Applied Ontology. Originally a WonderWeb Foundational Ontologies Library module, it has remained stable since its 2002/2003 release, is formally specified in first-order logic, and has a published consistency proof.

Key concepts Foundational ontology; first-order-logic axiomatization; WonderWeb documentation; OntoClean; roles, qualities, functions, organizations, artifacts, and group agency; OWL adaptations.

How you’d use it Ground domain modeling in DOLCE’s official FOL axiomatization and consult the cited methodological and applied research for patterns in areas such as manufacturing, organizations, engineering, and agency. For OWL work, evaluate DOLCE Lite or DUL as adaptations rather than identical releases.

LLM angle none stated

Pitfalls & lessons The OWL models depart from official DOLCE: they omit modality and temporal indexing, while adding descriptions and situations that official DOLCE does not cover.

Verdict A stable, formally documented foundational ontology, with an important distinction between the official FOL release and later OWL re-engineerings.

Sources consulted

• http://www.loa.istc.cnr.it/dolce/overview.html

GFO (General Formal Ontology)

What it is

The General Formal Ontology is a top-level ontology for conceptual modeling under continuing development by Onto-Med. It covers categories including objects, processes, time, space, properties, relations, roles, functions, facts, and situations, while aiming to integrate levels of material, mental, and social reality.

Key concepts

Distinctive ideas include integrating objects and processes through “persistants,” treating time and space as entities in their own right, coincidence, “situoids” as highly independent comprehensible wholes, and detailed accounts of roles and functions. GFO also provides different category kinds—universals, concepts, and symbolic structures—to remain open across realism, conceptualism, and nominalism.

How you’d use it

Use gfo-basic.owl as the stable core for a domain ontology and import it into extensions for areas such as time, space, or processes. The source recommends opening that file in an ontology editor to inspect basic categories and their short descriptions.

LLM angle

none stated

Pitfalls & lessons

The native formalization language is first-order logic, but the source says its partial FOL axiomatizations were not publicly available. Introductory/tutorial material was incomplete, draft reports could contain technical deficiencies, parallel extensions might be mutually inconsistent, and the fuller gfo.owl had not yet been adapted to gfo-basic.owl.

Verdict

A philosophically broad upper ontology with an OWL core and unusually explicit object/process integration, but the fetched documentation records substantial maturity, consistency, and accessibility caveats.

Sources consulted

• http://www.onto-med.de/ontologies/gfo/

gist

What it is gist is Semantic Arts’ minimalist, domain-independent upper ontology for enterprise use. It aims to cover common business concepts with roughly 100 classes and a similar number of attributes and relationships while minimizing primitives and ambiguity.

Key concepts It uses familiar top-level concepts such as person, organization, and agreement; extensive high-level disjointness to expose inconsistent typing; sparing domain/range constraints; and no inverse properties. Specialized enterprise or application ontologies can build on this foundation.

How you’d use it Download or clone the release package, or import https://w3id.org/semanticarts/ontology/gistCore into Protégé, then extend gist with domain concepts while retaining its namespace rules. Releases include Turtle, RDF/XML, and JSON-LD serializations plus documentation and migration material.

LLM angle none stated

Pitfalls & lessons Major release 14.0.0 broke compatibility with earlier versions, although migration scripts were supplied; 14.1.0 is backward-compatible with 14.0.0. CC BY 4.0 use requires attribution, gist concepts must remain in the gist namespace, and users must not define their own terms there.

Verdict A deliberately small enterprise foundation with practical modeling safeguards and multiple distribution formats; adopters should manage major-version migrations and namespace discipline.

Sources consulted

• https://semanticarts.com/gist/

gUFO

What it is

gUFO is a lightweight implementation of the Unified Foundational Ontology for Semantic Web OWL 2 DL applications. It selects a subset of UFO-A and UFO-B and is intended as an implementation artifact for structuring knowledge bases or knowledge graphs, rather than as a full reference ontology.

Key concepts

gUFO separates a taxonomy of individuals—such as objects, aspects, events, and situations—from a taxonomy of types, including kinds, phases, roles, categories, and relationship types. It also distinguishes endurants from events and situations, and provides patterns for parts, reified qualities, modes, relators, temporal boundaries, and quality values.

How you’d use it

Reuse its domain-independent distinctions by instantiating or specializing gUFO classes and properties in a lightweight ontology. For example, a domain class can both specialize gufo:Object and instantiate gufo:Kind, while concrete occurrences can instantiate gufo:Event and use the supplied temporal properties.

LLM angle

none stated

Pitfalls & lessons

“Lightweight” is a deliberate trade-off: gUFO uses limited expressiveness, includes only selected UFO-A/UFO-B material, and offers minimal UFO-B support. Some intended constraints are not declared when they would violate OWL 2 DL decidability rules; for example, proper parthood is described as asymmetric and irreflexive, but those characteristics are omitted from the implementation.

Verdict

A practical upper-level foundation when an OWL 2 DL knowledge graph needs UFO distinctions without importing the full reference ontology; its omissions and pragmatic formalization choices should be treated as part of the design contract.

Sources consulted

• http://purl.org/nemo/doc/gufo

SUMO (Suggested Upper Merged Ontology)

What it is SUMO and its domain ontologies are presented as a large free formal ontology used in search, linguistics, and reasoning. SUMO is written in SUO-KIF, owned by IEEE, mapped to all of WordNet, and extended by numerous domain ontologies under the GNU GPL.

Key concepts Upper and mid-level ontologies; domain extensions; formal axioms and definitions; WordNet mappings; first-order theorem-prover formats; SigmaKEE, SUMOjEdit, and SigmaNLP tooling.

How you’d use it Browse or edit formal terms, map English words through WordNet, perform inference, use TPTP exports with provers such as E or Vampire, or consume Neo4j and OWL translations. The portal also provides language-generation templates and a language-to-logic training corpus.

LLM angle none stated

Pitfalls & lessons The large taxonomy graph is explicitly too large to display in a browser. The portal offers several translations and toolchains, so users need to choose among SUO-KIF, TPTP, Neo4j, and OWL representations according to their task.

Verdict A richly axiomatized, tool-supported upper ontology with broad domain coverage and unusually extensive WordNet integration.

Sources consulted

• https://www.ontologyportal.org/

YAMATO (Yet Another More Advanced Top-level Ontology)

What it is YAMATO is a foundational ontology built and maintained by Riichiro Mizoguchi, first created in 1999 and subsequently revised several times. The site provides browsable English content and downloadable Hozo and OWL files, both marked updated on 2021-08-09.

Key concepts Its highlighted features are theories of quality and quantity, representations or content-bearing things, and objects, processes, and events. The site also connects YAMATO to formal work on artifacts, biological functions, events, roles, and occurrents.

How you’d use it Use the downloadable ontology as a top-level foundation for domain modeling. The source reports applications in medical ontology development, learning and instructional theories, genomics, mobile-user behavior, and functional ontology.

LLM angle none stated

Pitfalls & lessons The site says its cited ontology of function and theory of roles are not reflected in YAMATO, despite being related work. Users should therefore distinguish the ontology’s included content from the broader theories listed around it.

Verdict A long-running upper-level ontology centered on three explicit theory areas and backed by reported use across several domain projects.

Sources consulted

• https://www.hozo.jp/onto_library/upperOnto.htm

Common Core Ontologies (CCO)

• What it is — CCO is a suite of eleven ontologies containing logically defined generic terms and relations intended to cover entities across domains. It is a mid-level ontology extending the ISO-standard top-level Basic Formal Ontology (BFO), adding broadly reusable classes such as person, facility, date, employment, nickname, and measurement.

• Key concepts

  • CCO occupies the mid-level between BFO’s most generic categories and domain-specific ontologies; its authors explicitly encourage users to publish their own domain extensions rather than expanding CCO indefinitely with domain content.
  • Its eleven modules cover geospatial entities, information entities, events, time, agents, qualities, measurement units, currencies, facilities, artifacts, and extended relations.
  • Documented design patterns are motivated by use cases and competency questions, and include a Mermaid graph, a visualization, and a SPARQL query.

• How you’d use it — Clone the repository and import AllCoreOntology.ttl into Protégé to assemble the eleven modules, or use the pre-merged files under src/cco-merged/ to avoid managing imports. Releases are also viewable through the Industrial Ontology Portal; documented patterns can be reused for RDF data mapping and SPARQL querying.

• LLM angle — The documentation explicitly recommends reusing CCO design patterns in knowledge graphs to speed data mapping and querying and improve consistency and interoperability. No LLM- or RAG-specific use is stated.

• Pitfalls & lessons

  • CCO is not intended to absorb content specific to individual domains; that content belongs in domain extensions.
  • The repository is undergoing modernization through planned 3.0 and 4.0 structural changes. The Governance Board recommends waiting until after 4.0 to update, while users needing current changes should pull from develop.
  • Different OWL API and Protégé versions can generate spurious formatting diffs; contributors are told to make a token change and inspect the diff before substantive edits, then verify that the result loads correctly in Protégé.
  • Version 2.0 changed the IRI namespace and adopted opaque local identifiers; the release summary says there were no other ontology changes from v1.7 to v2.0.

• Verdict — A documented cross-domain mid-level foundation for shared classes, relations, and reusable knowledge-graph patterns, intended to sit beneath separately maintained domain extensions.

Sources consulted

• README.md
• documentation/README.md
• documentation/user-guides/design-patterns/README.md
• documentation/contributing/README.md
• documentation/contributing/contributing.md
• documentation/contributing/registering IRIs.md
• documentation/diff-reports-previous-version/README.md
• documentation/diff-reports-previous-version/v1.7-release-summary.md

MILO (Mid-Level Ontology)

What it is MILO is a formal ontology intended to bridge SUMO’s abstract content and the richer detail of domain ontologies. Its KIF source combines natural-language documentation with subclass and instance declarations, relation signatures, functions, and logical rules across topics such as people, processes, communication, devices, substances, social relationships, and measurement.

Key concepts

• SUMO-to-domain bridge: mid-level vocabulary connects abstract categories to more specific concepts.
• Formal semantics: subclass, instance, domain, range, implication, equivalence, and temporal predicates constrain the represented terms.
• Time-sensitive modeling: rules use constructs such as holdsDuring and WhenFn; the organism-remains section explicitly treats a living organism and its post-death remains as temporally disjoint.
• Broad reusable vocabulary: documented terms include human life stages, starting and stopping processes, communication and social relations, devices, shapes, quantities, and biological classes.

How you’d use it Use MILO as a shared mid-level vocabulary when a domain ontology needs more specificity than SUMO alone provides. Reuse its documented classes and relations, their argument constraints, and its implication rules to connect domain assertions to broader categories and derive explicitly encoded consequences.

LLM angle none stated

Pitfalls & lessons The file warns that its treatment of death and organism remains is awkward but deliberate: Dead should not be applied to an Organism, nor Living to OrganismRemains. It also labels adult legal personhood as a simplified, jurisdiction-dependent model, and its licensing notice requires GPL compliance plus credit to Teknowledge and Articulate Software and asks users to cite the named FOIS-2001 paper.

Verdict A substantial, formally axiomatized bridge vocabulary with useful domain breadth, but adopters should inspect its modeling assumptions, temporal distinctions, and licensing/citation conditions rather than treating every rule as context-free.

Sources consulted

• https://github.com/ontologyportal/sumo/blob/master/Mid-level-ontology.kif

Billion Triple Challenge (BTC) 2019 Dataset

What it is

BTC 2019 is an open dataset produced by an LDspider crawl of RDF/XML, Turtle, and N-Triples documents from 12 December 2018 to 11 January 2019. It contains 2,155,856,033 quads from 2,641,253 RDF documents across 394 pay-level domains; merging them and removing duplicate triples yields 256,059,356 unique triples.

Key concepts

• Each quad’s fourth element records the Web document from which its triple was parsed.
• The release separates gzipped N-Quads, a deduplicated gzipped N-Triples graph, and a VoID statistics file.
• The quads/triples contain 38,156 unique predicates and instances of 120,037 unique classes.
• Files are divided by the top 100 contributing pay-level domains, with the remaining 294 domains combined; very large domain files are split at roughly 150 million quads.

How you’d use it

Use the N-Quads when source-document provenance matters, the deduplicated N-Triples for one merged RDF graph, and the VoID file for dataset statistics. The page recommends a streaming parser such as Raptor, RDF4j/Rio, or NxParser.

LLM angle

none stated

Pitfalls & lessons

The collection is highly skewed: Wikidata contributes 93.06% of all quads and 52.15% of unique triples, so raw counts should not be treated as balanced coverage of the Linked Data Web. Its scale also makes streaming processing important. Reuse is under CC BY 4.0, and the record asks research users to cite the accompanying BTC-2019 paper.

Verdict

A large, provenance-preserving snapshot suited to Web-scale RDF processing and dataset-analysis work, but its strong domain skew must be kept visible in any conclusions.

Sources consulted

• https://zenodo.org/record/2634588

ConceptNet

What it is ConceptNet is a freely available, open multilingual semantic network intended to help computers understand word meanings. It combines knowledge originating in Open Mind Common Sense with other crowdsourced, expert-created, dictionary, encyclopedia, ontology, and game-derived sources.

Key concepts ConceptNet exposes relational assertions as Linked Open Data through a JSON-LD API, including relation, start and end concepts, source attribution, surface text, and weight. ExternalURL links connect terms to resources such as WordNet, DBpedia, and OpenCyc; ConceptNet also provides multilingual, cross-language-aligned word embeddings designed to avoid harmful stereotypes.

How you’d use it Browse concepts or query the REST/JSON-LD API for general relational knowledge, follow external vocabulary links for additional information, or use its published embeddings for word similarity and analogy tasks.

LLM angle none stated

Pitfalls & lessons The graph aggregates heterogeneous sources, so retain the assertion-level source metadata when provenance matters. Follow the site’s attribution guidance and review the CC BY-SA 4.0 licensing details before redistributing data.

Verdict A practical multilingual source of general word- and concept-level relationships with an accessible linked-data API.

Sources consulted

• http://conceptnet.io/

Cyc

What it is Cyc is presented as an enterprise machine-reasoning AI platform that uses codified human common sense and knowledge rather than patterns and statistics. The fetched site emphasizes healthcare operations products, including charge capture, denial management, post-acute-care forecasting, and staffing.

Key concepts Logic-based machine reasoning; codified common-sense knowledge; dynamic real-world data; semantic context; autonomous decision-making; explainability and auditability.

How you’d use it Deploy the Cyc platform as a knowledge and reasoning layer for complex operational workloads, with the showcased applications using continuously enriched patient and order context to make auditable decisions.

LLM angle none stated

Pitfalls & lessons The fetched page makes broad product and performance claims but provides no technical ontology structure, evaluation details, or implementation guidance, so those claims cannot be assessed from this source alone.

Verdict A commercially framed logic-and-knowledge reasoning platform with a strong auditability pitch, but the fetched landing page is more useful for positioning than for technical evaluation.

Sources consulted

• https://www.cyc.com/

DBpedia

• What it is — DBpedia presents itself as global, unified access to knowledge graphs and as a major Linked Open Data resource built from Wikipedia-language editions and Wikidata. The fetched page describes a community-supported open knowledge graph plus datasets, tools, releases, and access infrastructure.

• Key concepts — Linked Open Data, interconnected knowledge graphs, community extraction, a cross-domain DBpedia ontology, data cataloging and versioning through Databus, entity linking, and SPARQL/Linked Data access. The page distinguishes the main knowledge graph from its ontology and supporting release, catalog, lookup, and linking services.

• How you’d use it — Download latest-core or tailored dataset collections, browse or query the DBpedia ontology, access graph data through SPARQL and Linked Data services, publish/version datasets with Databus, or use DBpedia linking and lookup tools to connect text and datasets to entities.

• LLM angle — none stated

• Pitfalls & lessons — The page describes a broad ecosystem rather than one frozen dataset: snapshots, monthly development releases, latest-core collections, language chapters, ontology versions, and Databus artifacts have different scopes. Users therefore need to select and version the particular DBpedia resource their application depends on.

• Verdict — Worth deeper study as a central public Linked Open Data knowledge graph and as an ecosystem for querying, downloading, linking, cataloging, and versioning graph data.

Sources consulted

• https://wiki.dbpedia.org/

Freebase

What it is Freebase was a data-sharing project that ran from 2007 to 2015; its API has been shut down. Google now hosts the last available dumps for citation and possible contribution to open-data and graph-database work.

Key concepts The available artifacts include Freebase triples, deleted triples, and Freebase/Wikidata mappings. The main RDF snapshot uses UTF-8 N-Triples compressed with Gzip, while the mapping dataset links Freebase entities to Wikidata entities.

How you’d use it Download the historical dumps for reproducibility, legacy graph analysis, or mapping old Freebase identifiers to Wikidata. When parsing the large RDF snapshot, the page recommends reading directly from the Gzip file rather than first expanding it.

LLM angle none stated

Pitfalls & lessons The dumps are substantially out of date, may contain information that was never accurate, are unmaintained, and come without support. The API is unavailable; Freebase dumps are CC BY, while the Freebase/Wikidata mappings are CC0.

Verdict Useful as a frozen legacy dataset and identifier bridge, not as a current or supported knowledge service.

Sources consulted

• https://developers.google.com/freebase/

KBpedia

What it is KBpedia is an open-source knowledge graph that integrates seven public knowledge bases into one computable structure for data interoperability and knowledge-based AI. Its distribution includes the KBpedia Knowledge Ontology (KKO), the full graph, mappings, and about 70 largely disjoint typologies.

Key concepts

• The seven core sources are Wikipedia, Wikidata, schema.org, DBpedia, GeoNames, OpenCyc, and UNSPSC products and services.
• The site reports more than 58,000 reference concepts, mappings to about 40 million entities, and 5,000 relations and properties.
• KKO is the upper structure; modular typologies can be substituted or expanded, and candidate additions are subjected to logic and consistency tests.
• KBpedia primarily uses OWL 2 and also names RDF, RDFS, SPARQL, SKOS, and SWRL among its open standards.

How you’d use it Browse or query the graph through its SPARQL endpoint, download its resources, map an existing vocabulary or instance data into its scaffolding, and extend it with domain concepts. The source proposes uses including concept and entity tagging, disambiguation, semantic search, data integration, fact extraction, and creating machine-learning training sets or embedding corpora.

LLM angle none stated

Pitfalls & lessons The coverage, scale, speed, and accuracy figures on the fetched page are project claims rather than evaluation results presented in the source. Integrating another vocabulary still requires explicit mapping, which the site itself describes as essential.

Verdict An ambitious cross-domain integration layer with broad public-KB mappings and concrete semantic-search and machine-learning workflows, best assessed by testing its downloadable graph against the target domain.

Sources consulted

• http://kbpedia.org/

MindNet

What it is MindNet is a Microsoft Research knowledge-representation project that automatically builds semantic networks from dictionaries, encyclopedias, and free text. Its pipeline sentence-splits and parses text into semantic dependency graphs, aggregates them, and weights subgraphs probabilistically by corpus frequency.

Key concepts Broad-coverage parsing; Logical Form semantic dependency graphs; graph aggregation; corpus-frequency weights; path search, sorting, and similarity.

How you’d use it Build or inspect a large semantic network derived from text, then search, rank, or compare paths for work aimed at world knowledge and common-sense reasoning; a small number of sample MindNets are available for online browsing.

LLM angle none stated

Pitfalls & lessons Only a small number of sample MindNets are described as available for online browsing; the page does not state a general download or current production interface.

Verdict A clear example of automatic, corpus-scale semantic-network acquisition, with the fetched page emphasizing the construction pipeline more than present-day access.

Sources consulted

• https://www.microsoft.com/en-us/research/project/mindnet/

Mosaic Knowledge Graphs

What it is The fetched source identifies an archived page titled “Mosaic Knowledge Graphs.” It contains Wayback Machine capture metadata rather than the archived application’s descriptive content, so the nature and capabilities of the resource are not stated.

Key concepts Wayback Machine archive; 132 captures dated from 23 July 2019 through 22 November 2025; the requested capture is marked successful.

How you’d use it The fetched source supports only locating the named resource and its archive history; it does not provide enough application content to state a grounded usage workflow.

LLM angle none stated

Pitfalls & lessons The source is an archive wrapper rather than the target site’s content. Do not infer what “Mosaic Knowledge Graphs” contains or does from its title alone.

Verdict Insufficient fetched evidence for a substantive assessment; the underlying archived page would need to be captured successfully before this resource can be evaluated.

Sources consulted

• https://web.archive.org/web/20240715235324/https://mosaickg.apps.allenai.org/

NELL ontology and knowledge base

What it is This archived Linked Data server publishes the ontology and knowledge base produced by NELL, the Never-Ending Language Learning project in Carnegie Mellon’s Read-The-Web initiative. NELL has iteratively visited web pages and extracted knowledge from their unstructured content since January 2010, while NELL2RDF publishes that material as RDF.

Key concepts Release identifiers combine the NELL2RDF software version with the source NELL iteration, so 0.3#1100 means software 0.3 over iteration 1100. The server offered vanilla RDF plus provenance modeled through RDF reification, n-ary relations, named graphs, singleton properties, or NDFluents, distributed as compressed N-Triples or HDT and licensed CC0 1.0.

How you’d use it Download the ontology, NELL2RDF metadata ontology, and a dump matching the required provenance representation, or query the corresponding SPARQL endpoint using the documented anonymous credentials.

LLM angle none stated

Pitfalls & lessons The fetched page is an archived snapshot, and the provenance-rich dumps are much larger than the 315 MB vanilla HDT: listed variants range from 13.4 GB to 19 GB before zipped alternatives. Record both parts of the release identifier so the converter version and NELL iteration remain clear.

Verdict A provenance-conscious RDF publication of web-extracted general knowledge, best approached through the dump variant that matches the project’s storage and provenance needs.

Sources consulted

• https://web.archive.org/web/20241014060631/http://nell-ld.telecom-st-etienne.fr/

OWL-Time (Time Ontology)

What it is

OWL-Time is an OWL 2 DL ontology for describing temporal properties of resources. It covers ordering relations among instants and intervals, durations, and temporal positions expressed in Gregorian date-time or other temporal reference systems such as Unix time, geologic time, and alternative calendars.

Key concepts

• time:TemporalEntity has the two subclasses time:Interval and time:Instant; beginning, end, duration, and generic time-association properties connect temporal descriptions to entities.
• Allen-style interval relations—such as before, meets, overlaps, during, starts, and finishes—support qualitative ordering and relative-position reasoning.
• time:TRS, time:TimePosition, time:GeneralDateTimeDescription, and time:TemporalUnit support coordinate, ordinal, and calendar-clock representations with explicit reference systems and precision.

How you’d use it

Attach an instant, interval, or duration to an event or other resource, then represent its position with an XSD date-time, a structured date-time description, or a value in a named temporal reference system. Use the interval relations when relative ordering matters more than a single timestamp.

LLM angle

none stated

Pitfalls & lessons

The fetched document is a Candidate Recommendation Draft and says it should be cited as work in progress. Calendar arithmetic is not uniformly exact: Gregorian months have variable length, leap-second handling differs from ISO 8601, detailed time-zone definitions are outside the ontology, temporal vagueness is not addressed explicitly, and time series are out of scope.

Verdict

A broad, reusable temporal vocabulary when data must combine instants, intervals, durations, and non-Gregorian or ordinal reference systems; its stated scope boundaries and draft status should be accounted for.

Sources consulted

• https://www.w3.org/TR/owl-time/

SENSUS

What it is The fetched source does not describe SENSUS: the requested URL redirected to the USC Information Sciences Institute Natural Language Group home page. That page describes a research group working across natural-language processing and computational linguistics, including ontologies, machine translation, question answering, summarization, information retrieval, and natural-language generation.

Key concepts No SENSUS concepts are present in the fetched source; only the Natural Language Group’s broad research areas and institutional context are stated.

How you’d use it The fetched page can be used to identify the group and its research areas, but it does not provide enough information to use or evaluate SENSUS.

LLM angle none stated

Pitfalls & lessons The source URL resolved to a different, generic group page, so inferring SENSUS’s purpose, structure, availability, or capabilities from this fetch would be unsupported.

Verdict Insufficient source: a SENSUS-specific note requires a working project page, paper, or archived description.

Sources consulted

• https://www.isi.edu/natural-language/resources/sensus.html

Wikidata

What it is Wikidata is a free, open knowledge base readable and editable by both humans and machines. It centrally stores structured data for Wikimedia projects and also supports external sites and services.

Key concepts Its data is available under free licenses, exported in standard formats, and interlinkable with other open datasets on the linked-data web. The main page highlights items, properties, entities, community editing, and a SPARQL query service.

How you’d use it Retrieve or contribute structured data, query it through the SPARQL service, join subject-focused WikiProjects, or donate organizational datasets. Tutorials, tools, and community channels support both editing and reuse.

LLM angle none stated

Pitfalls & lessons Anyone can edit the knowledge base, and the source points to WikiProjects as places for data-modeling and quality decisions. Licensing differs by namespace: structured data in the main, Property, Lexeme, and EntitySchema namespaces is CC0, while text in other namespaces is CC BY-SA.

Verdict A large, machine-readable, community-maintained hub for cross-domain structured data, with SPARQL access and explicit reuse licensing.

Sources consulted

• https://www.wikidata.org/

YAGO

What it is

YAGO is a large semantic knowledge base jointly developed by the Max Planck Institute for Informatics and Télécom ParisTech. The fetched project page says it derives knowledge from Wikipedia, WordNet, and GeoNames and reports more than 10 million entities and 120 million facts.

Key concepts

The page highlights a WordNet-derived taxonomy enriched by Wikipedia categories, more than 350,000 classes, confidence values on relations, temporal and spatial annotations, thematic domains, and extraction from ten language editions of Wikipedia. It reports a manually evaluated confirmed accuracy of 95%.

How you’d use it

Download, browse, or query its cross-domain entity-and-fact graph, including time- and space-aware knowledge, or obtain the source code for further work.

LLM angle

none stated

Pitfalls & lessons

The fetched page explicitly says it is the old YAGO project page and is no longer maintained, directing readers to a newer site. Its scale and accuracy figures should therefore be read as claims about the version represented by this archived page, not necessarily the current project.

Verdict

A broad multilingual knowledge-base resource with taxonomy, confidence, and temporal/spatial context, but this particular source is primarily useful as a historical project overview.

Sources consulted

• https://www.mpi-inf.mpg.de/departments/databases-and-information-systems/research/yago-naga/yago/

Built Environment Ontology Lookup Service (BE-OLS)

What it is BE-OLS is a platform for discovering, exploring, and evaluating built-environment ontologies. The fetched page describes a database of more than 100 ontologies, organized across 20 built-environment-specific domains.

Key concepts Ontology cards; classes and properties; analytics; ontology network graph; multi-criteria ratings for alignment, accessibility, robustness, quality, and quantity; FAIR assessment; domain-driven categorization.

How you’d use it Search and filter the ontology database, inspect ontology cards and analytics, compare ratings and FAIR characteristics, and use the network graph to examine relationships among domain ontologies.

LLM angle none stated

Pitfalls & lessons none stated

Verdict A domain-specific discovery service that adds comparative evaluation and relationship mapping to a sizable built-environment ontology catalog.

Sources consulted

• https://cyberbuildlab.github.io/BE-OLS/

CIDOC CRM (Conceptual Reference Model)

What it is CIDOC CRM is a formal ontology and information-integration framework for cultural heritage documentation. It supplies definitions and a formal structure for the concepts and relationships needed to query and explore diverse, dispersed datasets in a software- and schema-agnostic way.

Key concepts

• CRMbase provides the basic cultural-heritage classes and relations.
• Harmonized modular extensions support specialized areas such as bibliographic documentation and geoinformatics while remaining compatible with the base model.
• The model is intended as a shared semantic framework and common language for domain experts and system implementers.
• CIDOC CRM is an official ISO standard; the fetched page identifies ISO 21127:2023 as superseding ISO 21127:2014.

How you’d use it Model or map museum, library, archive, and related heritage information to a common semantic framework, then integrate and query facts across source systems. Use CRMbase for the shared core and a harmonized extension when a research question needs a specialized model.

LLM angle none stated

Pitfalls & lessons The page calls CIDOC CRM a living standard, so implementers should identify the official version and relevant extensions rather than assume one fixed model. Its role is semantic mediation across existing sources, not dependence on a particular software product or schema.

Verdict A mature, ISO-recognized semantic backbone for integrating heterogeneous cultural-heritage information, with a base ontology and compatible domain extensions.

Sources consulted

• http://www.cidoc-crm.org/

CLARIAH/awesome-humanities-ontologies

• What it is — A curated directory of ontologies, vocabularies, terminologies, and taxonomies for modelling and publishing Humanities datasets as Linked Data. It groups linked resources by areas including general entities, literary studies, cultural heritage/history, periodicals, musicology, language, and fiction studies.

• Key concepts —

  • The collection treats persons, places, events, time, and documents as cross-domain modelling concerns.
  • Its entries cover provenance, argumentation, spatial and temporal description, events, bibliographic records, knowledge-organization systems, and structured web data.
  • Domain models include literary themes and intertextual relations; archaeology, museum, archival, rights, and person-name data; periodical enumeration and chronology; musical works, scores, MIDI, artists, albums, and tracks; lexicons and languages; and drama and narrative motifs.
  • Several listed resources are explicitly described as extensions or profiles of other models, such as CRMinf and CRMArcheo extending CIDOC CRM and Linked Art being a CIDOC-CRM application profile.

• How you’d use it — Use the README as a categorized discovery list, follow a linked resource, and select a model appropriate to a Humanities dataset intended for Linked Data publication. Formats and tooling explicitly represented in the entries include RDF vocabulary/RDF Schema, OWL, SKOS, schema.org, and GeoSPARQL with spatial reasoning support in triple stores. Contributions are made by editing the README, using a link plus a minimal one-sentence description, and submitting a pull request.

• LLM angle — none stated

• Pitfalls & lessons — Contributors are told to follow the existing heading logic, avoid placing additions in General where possible, and add new categories to the table of contents. List entries should remain minimal, with one linked ontology and a one-sentence description.

• Verdict — A domain-organized starting point for discovering Linked Data models across Digital Humanities, rather than documentation for one ontology.

Sources consulted

• README.md
• CONTRIBUTING.md

D3FEND

What it is

The fetched page is the MITRE D3FEND ontology-resource hub, distributing the entire current D3FEND model. It separates ontology files from data files containing relationships generated by inference.

Key concepts

Ontology distributions are offered as RDF/OWL XML, Turtle, and JSON-LD Graph. Inferred mappings are separately available in SPARQL 1.1 CSV and JSON, with versioned releases listed from beta versions through 1.5.0.

How you’d use it

Load an ontology distribution into a semantic graph database and query it, or download the full-mappings data when you need the inferred relationships shown on the D3FEND website.

LLM angle

none stated

Pitfalls & lessons

Do not assume every expected relationship is explicitly present in the ontology files: some are generated through inference and published in the Data Files section. The page says the SPARQL queries used to generate them are not yet open-sourced but are planned.

Verdict

A practical distribution page for consuming either the D3FEND model or its materialized inferred relationships, with several machine-readable formats and historical releases.

Sources consulted

• https://d3fend.mitre.org/resources/ontology/

Digital Buildings Ontology (DBO)

What it is

Digital Buildings is an Apache-licensed schema and toolset for representing structured information about buildings and installed equipment. Its ontology defines semantic primitives and concrete constructions for physical spaces, equipment, telemetry, and relationships; Google says a version is used to manage its own building portfolio.

Key concepts

• An entity is a modeled thing such as a building, floor, or equipment item. An entity type places it in a composable taxonomy and declares its expected fields; directed, named connections relate entities.
• Subfields are the basic units of meaning. Categorized subfields compose semantically precise fields, while units, states/multi-state groups, inheritance, abstract types, canonical types, and namespaces provide further structure.
• The ontology allows a global namespace plus exactly one child level; hierarchical namespacing is disallowed. Definitions may be elevated to the global namespace when safe.
• A building configuration is the instance or “Assertion box”: it maps real assets and raw data to ontology types using GUID-keyed entities, translations, links, and connections. The docs distinguish logical, reporting, and virtual entities.
• The supplied abstract model favors minimal atomic functional field sets composed into equipment types. Its stated target is portable high-level analysis and control—not a full cloud BMS.

How you’d use it

• Use the YAML ontology as the primary configuration source, or generate RDF/OWL from it. Extend entity types, fields, states, or subfields in YAML and validate extensions for consistency and backward compatibility.
• Describe one building (or another logical division) in a YAML building configuration, mapping device-native point names to standard fields with translations and linking reporting data into virtual devices where needed.
• Use ABEL to move between templated Google Sheets and building configurations, Explorer to compare ontology types, the Instance Validator for configurations and optional telemetry, the Ontology Validator for YAML extensions, and the RDF/OWL Generator for RDF output.
• The documented workflow is: reuse existing types where possible; otherwise propose and validate an ontology extension, then construct a GUID-based building configuration and validate both its type mapping and telemetry.

LLM angle

No LLM or RAG use is stated. The ontology docs do state that implicit inheritance forms a graph of related field concepts which can support navigation and search expansion—for example, fanning a search for zone_air_temperature across fields containing that subfield set.

Pitfalls & lessons

• Equipment boundaries are subjective: a flatter graph yields fewer, more complex entities, while deeper composition yields simpler comparable components but harder retrieval. DBO generally chooses the flatter approach because equipment is usually analyzed as a unit.
• Field names should use the smallest subfield set that is unambiguous in context; overly strict construction can create redundant or unwieldy names, yet arbitrary device scope means there is not always one correct name.
• The abstract model is intentionally reductionist, so low-level configuration, most interpreted alarms, and full BMS behavior are outside its normal focus unless explicitly needed.
• Some useful concrete-model conventions are not yet encoded in the ontology structure, detailed explanations are primarily HVAC-focused, and the ontology’s versioning process and constraints are still TBD.
• Building-configuration documentation includes details specific to Google’s campus implementation and warns that they may not transfer directly to other deployments.

Verdict

A practical, validation-centered building ontology for portable operational analytics and control, strongest when its deliberately minimal, flatter equipment model matches the deployment’s scope.

Sources consulted

• README.md
• ontology/README.md
• ontology/docs/overview.md
• ontology/docs/ontology.md
• ontology/docs/model.md
• ontology/docs/building_config.md
• ontology/docs/ontology_config.md
• ontology/docs/faq.md
• ontology/yaml/README.md
• ontology/rdf/README.md

FIBO

What it is The Financial Industry Business Ontology (FIBO) defines financial-business things and the relationships among them so that finance data can carry shared meaning. It is hosted and sponsored by EDM Council, standardized by the Object Management Group, and published in multiple formats for operational use and business definitions.

Key concepts FIBO is developed in OWL, whose Description Logic basis is presented as making concepts unambiguous and readable by humans and machines. Its concepts reflect industry consensus developed through member review and reference to industry data models and message standards.

How you’d use it Apply FIBO’s concepts to finance data in spreadsheets, relational databases, XML documents, or other sources to support shared terminology, cross-system federation and aggregation, regulatory reporting, decision-making, and analytics. The site offers ontology, vocabulary, data-dictionary, and schema.org products plus viewer, documentation, training, tools, and a GitHub-based contribution process.

LLM angle none stated

Pitfalls & lessons none stated

Verdict A platform-independent, machine-readable financial data standard with formal OWL foundations, industry review, and an open community development process.

Sources consulted

• https://spec.edmcouncil.org/fibo/

Food Ontology

What it is

This is an RDF/XML OWL ontology for foods, drinks, meals, and meal courses, derived from and substantially modifying a DAML wine ontology. It imports the companion wine ontology and connects local food concepts to wine classes, properties, and named values.

Key concepts

• A hierarchy rooted in ConsumableThing, including EdibleThing, PotableLiquid, Meal, MealCourse, fruits, meats, seafood, desserts, and pasta dishes.
• Four object properties: madeFromFruit, course, hasFood, and hasDrink, each with stated domains and ranges.
• OWL constructions including subclassing, disjointness, union and intersection classes, cardinality constraints, value restrictions, enumerations, equivalentClass, and sameAs.
• Course classes encode drink constraints: for example, a spicy red-sauce pasta course restricts its drink to red, full-bodied, strong, dry wine characteristics.

How you’d use it

Use it as an OWL example for modeling meals and food categories, then classify course descriptions or check their restrictions against imported wine characteristics. Its course axioms also demonstrate how a food category can constrain the properties of a paired drink.

LLM angle

none stated

Pitfalls & lessons

The source comment says the food and wine ontologies mutually import one another because they share many wine properties, so the model is intentionally coupled to its companion ontology rather than self-contained. Its scope is selective: the file concentrates on a small set of meal, food, and pairing categories rather than presenting a general inventory of food knowledge.

Verdict

A useful, compact OWL modeling example—especially for restrictions, class expressions, and cross-ontology links—but too selective and wine-dependent to serve as a standalone broad food ontology.

Sources consulted

• https://www.w3.org/TR/2004/REC-owl-guide-20040210/food.rdf
• Local fetched source: sources/food-ontology.txt

FoodOn

What it is FoodOn is a controlled vocabulary and ontology for naming food-bearing parts of animals, plants, and fungi, derived food products, and production processes. It is an open-source OBO Foundry ontology designed for statements that people and computers can store, query, and reason over.

Key concepts Its farm-to-fork coverage is organized through facets such as organism source, anatomical part, harvest state, maturity, processing, packaging, physical qualities, and chemical components. It reuses terms from interoperable OBO Foundry ontologies and includes more than 9,600 generic food-product categories.

How you’d use it Annotate food products and connect them to facets in a graph database for standardized descriptions, nutrition and shelf-life research, or food-contamination trace-forward and trace-back work. Users can explore it through OLS, OntoBee, BioPortal, or AgroPortal and obtain development files from its GitHub repository.

LLM angle none stated

Pitfalls & lessons A simple product reference can remain ambiguous—for example, whether fruit is still on a tree or ripe—unless harvest-status and maturity facets are attached. FoodOn prioritizes descriptive vocabulary; its own product hierarchy is a secondary objective and is not always deeply detailed.

Verdict A broad, interoperable food vocabulary whose facet model is especially useful when generic product names alone are not precise enough.

Sources consulted

• https://foodon.org/

Gene Ontology (GO)

What it is The Gene Ontology Resource is a knowledgebase and bioinformatics initiative for computationally representing how genes encode biological functions from molecular through organism levels across many species. It provides human- and machine-readable information used in computational analysis of large-scale molecular-biology and genetics experiments.

Key concepts

• The ontology is a network of biological classes for molecular functions, cellular locations, and biological processes that gene products may carry out.
• A GO annotation is an evidence-based, traceable statement that a specific gene product exemplifies a GO class.
• GO-CAM links standard GO annotations into a more complete model of a biological system.
• The site provides ontology and annotation downloads, AmiGO browsing, enrichment analysis powered by PANTHER, APIs, notebooks, and curation/search/visualization tools.

How you’d use it Use GO classes and evidence-backed annotations to describe or analyze gene-product functions across species. Browse or download the ontology and annotations, run enrichment analysis on gene sets, or use the APIs and guides to integrate GO into a research workflow.

LLM angle none stated

Pitfalls & lessons GO represents evolving knowledge, and annotations are tied to specific, traceable scientific evidence; consumers should preserve that evidence context rather than treat every association as an unexplained label. The ontology, annotations, and GO-CAMs are distinct products with different roles.

Verdict A broad, evidence-centered foundation for interoperable gene-function annotation and computational biological analysis.

Sources consulted

• http://geneontology.org/

Geographical Entity Ontology

What it is

The Geographical Entity Ontology is an ontology of geographical entities implemented in OWL 2 and based on Basic Formal Ontology (BFO). Its developers state an aim to adhere to OBO Foundry principles, and the OBO page classifies it in the environment domain.

Key concepts

The ontology uses the geo identifier space and is distributed as geo.owl through an OBO Library PURL. The page links to its homepage, GitHub repository, issue tracker, and several ontology browsers, and lists a CC BY 4.0 license.

How you’d use it

Retrieve geo.owl from http://purl.obolibrary.org/obo/geo.owl, inspect it through OntoBee, AberOWL, OLS, or BioPortal, and use the linked repository and tracker for source access or issues.

LLM angle

none stated

Pitfalls & lessons

The fetched page says the developers aim to adhere to OBO Foundry principles; it does not claim or show full conformance. It also provides only a high-level domain description rather than enumerating the ontology’s terms.

Verdict

A clearly packaged OWL 2/BFO geographical-entity ontology with a stable OBO PURL, open license, repository, tracker, and browser links.

Sources consulted

• http://www.obofoundry.org/ontology/geo.html

GoodRelations

What it is

GoodRelations is a Web vocabulary for publishing detailed product and service information in a form that search engines, mobile applications, and browser extensions can extract and present. The page frames it as a rich-data vocabulary for Web marketing and e-commerce.

Key concepts

The examples cover products and services, vehicle details, real-estate features and locations, offers, opening hours, payment options, menus, and tickets. The ontology is available under the Creative Commons Attribution 3.0 license.

How you’d use it

Add extra structured code to Web content so external software can understand and present commercial offers, including use cases in automotive, real estate, mobile commerce, restaurants, and ticketing.

LLM angle

none stated

Pitfalls & lessons

none stated

Verdict

A focused choice when the goal is to publish precise e-commerce offer data for reuse by search and application interfaces.

Sources consulted

• http://www.heppnetz.de/projects/goodrelations/

Liquid-Legal-Institute/Legal-Ontologies

• What it is — A curated list of selected resources, methods, and tools for legal ontologies, data schemes, and knowledge graphs. It is an index rather than a single ontology: its sections point to use cases, ontologies, datasets, modeling tools, research groups, and tutorials.

• Key concepts — The documented ontology-learning tasks include domain terminology extraction, concept discovery, concept-hierarchy derivation and extension, learning non-taxonomic relations, rule discovery, ontology population, and frame/event detection. The catalog also shows the breadth of legal modeling targets through resources for legislation, legal documents and rules, contracts, copyright, transactions, legal services, and parliamentary activity.

• How you’d use it — Use the README as a discovery map: follow its links to candidate legal ontologies and standards, supporting datasets or annotation guidelines, and tutorials. For modeling and development it names Protégé, Fluent Editor, OntoStudio, and OWLGrEd; listed interchange resources include Akoma Ntoso, LegalRuleML, Legal Document ML, and UBL, which the README describes as XML templates for potentially legally binding business documents.

• LLM angle — none stated

• Pitfalls & lessons — The list cautions that GoodRelations is not strictly legal, although it may help model transactions. Maintenance is category-driven: contributors are asked to submit one suggestion per pull request, add links at the bottom of the relevant category, use informative titles, and explain why an addition is useful; new categories and categorization improvements are welcome.

• Verdict — A concise starting index for finding legal ontology resources and tooling, not a self-contained legal domain model or implementation guide.

Sources consulted

• README.md
• contributing.md

OBO Foundry

What it is

The Open Biological and Biomedical Ontology Foundry is a community effort to develop interoperable ontologies for the biological sciences. Its site combines principles and best-practice material with community resources and an ontology catalog.

Key concepts

The listed principles cover openness, common format, identifier space, versioning, scope, textual definitions, relations, documentation, users, collaboration, authority, naming, change notification, maintenance, term-meaning stability, and responsiveness. Catalog metadata can be downloaded as YAML, JSON-LD, or RDF/Turtle.

How you’d use it

Search or filter the ontology table to find community ontologies, consult the principles and tutorial, use the linked browsers and tools, or submit an ontology for consideration. Participation routes include mailing lists, Slack, working groups, and GitHub reports or suggestions.

LLM angle

none stated

Pitfalls & lessons

The home page presents principles, resources, and catalog access but does not itself establish that every listed ontology satisfies every principle; ontology selection still calls for examining the relevant entry and metadata.

Verdict

A useful discovery and governance hub for interoperable biological-science ontologies, offering both machine-readable catalog exports and multiple ways to participate.

Sources consulted

• http://obofoundry.org/

Open Energy Ontology (OEO)

• What it is — The OEO is an open domain ontology for the energy-system-analysis context and part of the Open Energy Family. It represents standard terminology used by human experts to improve the transparency, comparability, and transferability of energy-system modelling and scenario analysis.

• Key concepts —

  • The ontology follows Basic Formal Ontology (BFO) principles and reuses external ontologies.
  • It has a modular structure: OEO-owned modules are collected separately from imported modules and assembled by the main ontology file.
  • Releases distinguish an asserted class hierarchy (oeo-full.owl) from a hierarchy inferred by the HermiT reasoner (oeo-closure.owl).
  • Ontology changes are treated as interdisciplinary work: content additions call for domain-expert review, restructuring for ontology-expert review, and changes involving both for both kinds of expertise.

• How you’d use it — Download a released OWL artifact, browse the inferred version through the TIB terminology service, or inspect it in the Open Energy Platform viewer. For editing, the repository uses Manchester OWL Syntax and recommends Protégé; contributors work in the appropriate module, validate the assembled ontology for inconsistencies, and submit changes through issues and reviewed pull requests. Individual classes can be referenced by label and full OEO URI.

• LLM angle — none stated

• Pitfalls & lessons — The ontology is continually extended, so the stable release, latest development branch, and inferred lookup view are distinct artifacts. Contributors are cautioned that the main oeo.omn file is usually not the correct place for a change, must check for introduced inconsistencies, and should merge promptly to reduce conflicts. Substantive proposals require discussion and domain/ontology review before implementation rather than unilateral edits.

• Verdict — A well-governed, modular ontology specifically scoped to shared terminology and formal organization for energy-system modelling and scenario analysis.

Sources consulted

• README.md
• CONTRIBUTING.md

Product Types Ontology

What it is The Product Types Ontology provides GoodRelations-compatible class definitions for product or service types that have entries in English Wikipedia. It is intended for Semantic Web e-commerce and imports the GoodRelations vocabulary.

Key concepts Wikipedia-based product identifiers; GoodRelations compatibility; RDF/XML and OWL; per-class representations; a requested-class dump; CC BY-SA 3.0 licensing.

How you’d use it Use Product Ontology classes alongside GoodRelations when describing the type of a commercial product or service, and retrieve the dump or follow rdfs:seeAlso links when class data beyond the ontology header is needed.

LLM angle none stated

Pitfalls & lessons The root ontology document contains only the header. The dump includes only repeatedly requested, non-disambiguation classes and omits comments and non-English labels, which must be fetched through linked class representations.

Verdict A focused bridge from Wikipedia product/service types into GoodRelations-based e-commerce data, but consumers must account for its distributed and selective class data.

Sources consulted

• http://www.productontology.org/

PROV-O

What it is PROV-O is the W3C Recommendation that expresses the PROV Data Model in OWL 2, providing classes, properties, and restrictions for representing and exchanging provenance across systems and contexts. It is intentionally lightweight, directly usable, and designed to be specialized for domain-specific provenance models.

Key concepts Its foundation is prov:Entity, prov:Activity, and prov:Agent: things with fixed aspects, processes that act on entities over time, and bearers of responsibility. Core relations describe generation, use, derivation, attribution, association, delegation, and timing; expanded terms add collections, bundles, agent types, versions/alternates, primary sources, locations, and invalidation. Qualified influence nodes such as prov:Usage, prov:Generation, and prov:Association let a model attach details such as time, role, or plan to an otherwise binary relation.

How you’d use it Publish RDF provenance chains showing which activities used or generated entities and which agents were responsible, then add expanded or qualified terms only when the application needs more detail. Prefer an unqualified relation when it needs no attributes; when using the qualified form, also including its equivalent unqualified statement is encouraged to make consumption easier.

LLM angle none stated

Pitfalls & lessons Consumers should recognize both qualified and unqualified forms and treat the qualified form as implying the unqualified one. PROV-O defines few inverse properties because competing assertion directions force consumers to add reasoning, code, or larger queries; use the ontology’s preferred property direction. It is based on OWL 2 RL but has five union-domain/range axioms outside that profile, and multiple RDFS domains/ranges denote intersections rather than alternatives.

Verdict A compact, progressively adoptable provenance vocabulary with a simple core and an explicit path to richer, domain-specific detail. Its interoperability guidance is practical, but implementers need to handle the two relationship forms and its small OWL 2 RL exception set deliberately.

Sources consulted

• https://www.w3.org/TR/prov-o/

rNews

What it is rNews is an IPTC-approved standard for embedding news-specific metadata in HTML documents. It provides the terminology and data model needed to give article regions machine-readable meaning through RDFa or HTML5 Microdata rather than relying on visual styling.

Key concepts

• The page covers production rNews 1.x and says version 1.2 was approved on 23 October 2013.
• Its classes include concepts, places, geographic coordinates, people, organizations, storylines, news items, articles, media objects, and user comments.
• RDFa and HTML5 Microdata are the embedding frameworks described for applying rNews metadata in HTML.
• The standard is published under the Creative Commons Attribution 3.0 license.

How you’d use it Mark up an online news page so machines can reliably identify the headline and other news entities and relationships independent of site-specific presentation. Follow the implementation guides for the chosen RDFa or Microdata syntax and use the class documentation or quick reference to select terms.

LLM angle none stated

Pitfalls & lessons Visual HTML styling alone is not reliable machine-readable semantics because publishers use inconsistent styles and may reuse the same style for multiple regions. The page describes an OWL ontology only as a third draft available for review, so that artifact should not be confused with the approved production status stated for rNews 1.x.

Verdict A domain-specific semantic-markup model for making online news understandable to machines, with clear RDFa and Microdata implementation paths.

Sources consulted

• http://dev.iptc.org/rNews

SIOC (Semantically Interlinked Online Communities)

What it is

SIOC is an ontology of terms for describing online communities on the Web of Data. The initiative aims to integrate online-community information by representing rich Social Web data in RDF.

Key concepts

Its Core Ontology Specification defines the main concepts and properties for online-community information. SIOC is commonly used with FOAF for personal-profile and social-networking information, and it was previously published as a W3C Member Submission from 16 organizations.

How you’d use it

Represent user-generated and online-community content in a standard RDF vocabulary, then build semantic applications over that Social Web data. The site also points to implementation status, related vocabularies, a mailing list, and a GitHub repository containing the website, ontologies, and applications.

LLM angle

none stated

Pitfalls & lessons

none stated

Verdict

A focused RDF vocabulary for integrating online-community data, with documented relationships to other vocabularies and evidence of use in commercial and open-source applications.

Sources consulted

• http://sioc-project.org/

Uberon

What it is Uberon is an integrated cross-species ontology of anatomical structures in animals. It bridges multiple species-specific ontologies and is scoped to anatomy and development across Metazoa.

Key concepts

• The distribution includes a core ontology, a base ontology of axioms defined within Uberon, a basic OBO edition with external ontologies and most relations excluded, and collected or composite metazoan and vertebrate editions.
• Its identifier space is uberon, its published PURL is http://purl.obolibrary.org/obo/uberon.owl, and the listed license is CC BY 3.0.
• The OBO Foundry page lists dependencies including BFO, CL, GO, NCBITaxon, PATO, RO, and others.
• Documented users apply it to sample and assay annotation, cross-species gene-expression comparison, and expression or phenotype queries.

How you’d use it Annotate animal tissues or anatomical structures with shared Uberon terms so data can be compared or queried across species. Select the product matching the integration need: core/base for Uberon axioms, basic for fewer external imports and relations, or a collected/composite edition for broader multi-ontology coverage.

LLM angle none stated

Pitfalls & lessons Uberon is published in several editions with different inclusion and redundancy choices, so consumers must choose deliberately rather than treat every downloadable product as equivalent. The full ecosystem also has numerous ontology dependencies that an integration may need to resolve.

Verdict A practical cross-species anatomy bridge with demonstrated use in biological annotation and comparative querying, but distribution choice and dependencies deserve attention.

Sources consulted

• http://obofoundry.org/ontology/uberon

Unified Cyber Ontology (UCO)

What it is Unified Cyber Ontology (UCO) is a community-developed ontology/model intended to provide a consistent foundation for standardized information representation across the cyber-security ecosystem. Cyber-investigation, defense, threat-intelligence, malware, vulnerability-research, and offensive-operation representations can be defined as suitable subsets of its constructs.

Key concepts Shared cyber-domain foundation; subdomain-specific subsets; standardized representation; shared APIs; automated information flow across subdomain boundaries; community governance and versioned releases.

How you’d use it Base a cyber-security subdomain model on the relevant UCO constructs so that its representation remains consistent with other subdomains and can participate in shared APIs and automated information exchange.

LLM angle none stated

Pitfalls & lessons Subdomain representations should be scoped as appropriate subsets rather than treated as isolated models; the site emphasizes broader community involvement in deciding both what to represent and how.

Verdict A useful shared semantic foundation for cyber-security models whose main value is consistency and information flow across otherwise separate operational subdomains.

Sources consulted

• https://unifiedcyberontology.org/

vCard Ontology

What it is — A W3C Interest Group Note mapping vCard RFC 6350 to RDF/OWL for describing people and organizations with Semantic Web techniques. Its goal is compatibility between semantic vCard representations and traditional vCard implementations without changing RFC 6350 semantics.

Key concepts —

• The ontology keeps the http://www.w3.org/2006/vcard/ns# namespace for backward compatibility and also uses it as the JSON-LD context.
• URI-like resources are generally represented by OWL object properties named hasX, while literals such as strings and dates use data properties named x.
• Direct properties provide simpler resources; hasValue/value support n-ary structures when vCard property parameters require added metadata.
• Mapped kinds include Individual, Organization, Group, and Location; mapped fields cover identification, addresses, communications, geography, organizations, explanatory data, security keys, and calendar links.

How you’d use it — Represent contact data as RDF using the documented classes and properties, choosing direct relationships for simple values and n-ary relationships for parameterized values. The note supplies equivalent examples in RDF/XML, RDFa, Turtle, and JSON-LD, plus mapping tables from RFC 6350 properties.

LLM angle — none stated

Pitfalls & lessons — The note deprecates rdf:value for property parameters in favor of hasValue/value, and lists numerous deprecated or mapped terms from the previous ontology. Some RFC parameters are represented through general RDF mechanisms such as rdf:type, rdf:Seq, rdf:Alt, or rdf:ID, while others are unnecessary or assumed by the ontology.

Verdict — A detailed interoperability mapping for publishing RFC 6350-style contact information in RDF/OWL, with explicit migration guidance and serialization examples.

Sources consulted

• https://www.w3.org/TR/vcard-rdf/

Wine Ontology

What it is The Wine Ontology is an example OWL ontology derived from the DAML Wine ontology, with substantial changes to its region relations. It imports the OWL Guide food ontology and models wines, grapes, wineries, regions, vintages, and sensory descriptors.

Key concepts Wine is constrained by maker, grape, sugar, flavor, body, color, and location properties. The file demonstrates OWL constructs including cardinality and value restrictions, intersections, unions, enumerated descriptor values, inverse properties, a transitive locatedIn, a symmetric adjacentRegion, and functional descriptor properties.

How you’d use it Use it as a concrete OWL/RDF example for exploring class definitions and reasoning over wine categories—for example, WhiteWine combines Wine with a white-color value, while FrenchWine combines Wine with location in FrenchRegion.

LLM angle none stated

Pitfalls & lessons The ontology depends on an imported food ontology, and its own comment warns that its region-based relations were substantially changed from the DAML source. Its exact cardinality constraints are part of the model, not merely documentation.

Verdict A compact, feature-rich teaching ontology that makes many OWL modeling patterns inspectable in one domain.

Sources consulted

• https://www.w3.org/TR/owl-guide/wine.rdf

BARTOC (Basel Register of Thesauri, Ontologies & Classifications)

What it is — BARTOC is a site that unites information about terminologies and terminology registries. Its stated purpose is to facilitate the use of knowledge organization systems.

Key concepts —

• Terminologies.
• Terminology registries.
• Knowledge organization systems.

How you’d use it — Consult its combined information about terminologies and registries when looking to use knowledge organization systems.

LLM angle — none stated

Pitfalls & lessons — none stated

Verdict — A terminology and registry discovery point by its own description; the fetched source gives only this high-level mission and no operational detail.

Sources consulted

• https://bartoc.org

BioPortal

What it is NCBO BioPortal presents itself as a comprehensive repository of biomedical ontologies that is free and open to all users without login. The portal provides ontology and class browsing alongside search, annotation, recommendation, and mapping functions.

Key concepts Biomedical ontology repository; class search; ontology groups; annotation; ontology recommendation; mappings; REST API; virtual appliance; web widgets.

How you’d use it Search for a biomedical class or browse ontologies and curated groups, then use mappings, the Annotator, or the Recommender as needed; programmatic and deployable access are represented by the REST API and virtual appliance.

LLM angle none stated

Pitfalls & lessons none stated

Verdict A high-coverage discovery and access hub for biomedical ontologies, with both interactive tools and programmatic integration options.

Sources consulted

• https://bioportal.bioontology.org/

DBpedia Archivo

What it is DBpedia Archivo is an ontology archive that automatically discovers OWL ontologies on the web, checks them every eight hours, and persistently archives changed snapshots on the Databus. At fetch time, its catalog reported 2,009 ontologies and exposed published-web and developer-version views.

Key concepts

• Archived ontology snapshots with Databus artifact links and downloads in OWL, Turtle, and N-Triples formats.
• A four-star “minimum viability” rating based on retrievability and parsing, license evidence and interoperability, and successful consistency checking.
• Per-entry metadata including triple count, semantic version, timestamps, addition date, parsing, license, consistency, LODE conformity, and crawling status.

How you’d use it Use the list to discover an ontology, inspect its viability signals, follow its source or Databus record, and download the latest archived serialization. A missing ontology can be submitted through Archivo’s suggestion feature.

LLM angle none stated

Pitfalls & lessons A four-star rating is not a claim that an ontology is high quality; Archivo explicitly says its stars measure only minimum viability and minimal FAIRness. Lower ratings may reflect an ontology that cannot be retrieved or parsed, unclear or non-interoperable licensing, or a failed consistency check, all of which can impede later processing such as SPARQL, reasoning, or SHACL.

Verdict A useful discovery, archival, and first-pass triage index for web ontologies, provided its stars are treated as viability checks rather than a quality ranking.

Sources consulted

• https://archivo.dbpedia.org/list

KBS/Ontology Projects Worldwide

What it is This is an alphabetically indexed directory of knowledge-base, ontology, knowledge-representation, and related projects and groups. Its entries range across ontologies, languages, tools, methodologies, search and question-answering systems, lexical resources, and other collections.

Key concepts The page is a discovery list rather than a single ontology or formal specification. Representative entries include BFO as an upper ontology, Chimaera for creating, merging, and diagnosing ontologies, Common Logic as a standard language, ConceptNet as a commonsense knowledge base and NLP toolkit, UMLS as aligned biomedical vocabularies, and WordNet as a lexical reference system.

How you’d use it Use the alphabetical index to discover names and short descriptions of projects, then follow the listed pointers for deeper investigation. The page also invites readers to email the maintainer about related work that is missing.

LLM angle none stated

Pitfalls & lessons Despite the heading “Some Ongoing” projects, the page itself marks Carter as defunct and says the Twente Ontology Collection page no longer seems available. Several descriptions also preserve dated context, such as ConceptNet statistics “as of 2010,” so entries should be treated as leads rather than current-status verification.

Verdict A broad historical discovery index with useful taxonomy-by-example, but not a curated guarantee that every linked project is current or available.

Sources consulted

• http://www.cs.utexas.edu/users/mfkb/related.html

Linked Open Vocabularies

What it is Linked Open Vocabularies (LOV) is a catalog containing 910 vocabularies in the fetched page. It organizes vocabulary discovery through category tags and exposes sections for vocabularies, terms, agents, SPARQL/dumps, patterns, documentation, and an API.

Key concepts Vocabulary catalog; category tags; terms and agents; SPARQL and dumps; patterns; API access; latest insertions and updates.

How you’d use it Browse the catalog by categories such as General & Upper, Biology, Time, Government, W3C Recommendation, Health, or eBusiness, then use its term, agent, SPARQL/dump, documentation, and API areas for further investigation.

LLM angle none stated

Pitfalls & lessons none stated

Verdict A broad discovery hub for surveying linked-data vocabularies and tracking newly inserted or updated entries.

Sources consulted

• https://lov.linkeddata.es/dataset/

Lists of ontologies

What it is This W3C Wiki page is a directory of ontology-listing pages that map themes such as people or products to ontology URIs. It also records example selection approaches, strengths, and drawbacks, and includes a detailed MarineTLO entry.

Key concepts Theme-to-URI discovery; popularity and quality criteria; usage ranking; documentation and independent adoption; domain ontology listings.

How you’d use it Start with a data theme and follow a listed directory to find a candidate vocabulary, while checking the list’s inclusion criteria and maintenance status. The MarineTLO example shows the richer metadata a listing can provide: namespace, prefix, documentation, adopters, tools, and OWL technical details.

LLM angle none stated

Pitfalls & lessons The page questions who defines popularity and quality. It explicitly flags some lists as too small, arbitrary, possibly unmaintained, or containing stale links, and notes that stated membership criteria do not guarantee a good ontology.

Verdict Useful as a historical discovery index and as a reminder to evaluate ontology lists critically, not as a current quality seal.

Sources consulted

• https://www.w3.org/wiki/Lists_of_ontologies

Ontology List

What it is

Ontology List is an archived, categorized directory of ontology and vocabulary names, with short descriptions for some entries. The fetched page groups resources by subject rather than defining an ontology or comparing the listed models.

Key concepts

• Categories include friendship and relationships, thesauri and folksonomies, communities, news/blogs/wikis, data sharing and integration, bibliographic and multimedia information, geology, biology/biomedicine, general ontologies, information technology, business, linguistics, medicine, scientific research, and other topics.
• The list spans well-known and specialized resources, including FOAF, VOAF, SKOS, BIBO, Gene Ontology, WordNet, SUMO, Dublin Core, BFO, GoodRelations, and the Event Ontology.
• Descriptions focus on intended scope, such as people and relationships, citations, datasets, geographic features, research communities, biological entities, or business processes.

How you’d use it

Browse the domain headings to generate candidate vocabularies for a modeling task, then use each candidate’s own material for evaluation. The one-line summaries can help distinguish broad upper ontologies from narrower models for areas such as bibliography, multimedia, biomedicine, or organizations.

LLM angle

none stated

Pitfalls & lessons

This is a Wayback Machine capture from April 2021, and the entries are uneven: many have a one-line explanation while others are only names. Some items are repeated, and the fetched text contains character-encoding artifacts, so it is not a current or normalized registry.

Verdict

A useful historical discovery index with wide topical coverage, but not an authoritative source for a candidate’s present status, specification, or fitness.

Sources consulted

• https://web.archive.org/web/20210413125526/https://info.sice.indiana.edu/~dingying/Teaching/S604/OntologyList.html

Ontology Lookup Service (OLS)

• What it is — The rendered Ontology Lookup Service page is a browsable catalog of ontologies, prominently including OBO Foundry resources and many scientific and biomedical domains. Its catalog rows identify an ontology, ID, description, and actions for searching classes, properties, and individuals.

• Key concepts — Ontology catalogs, controlled-vocabulary and OWL ontology discovery, domain tags, ontology identifiers, class/property/individual browsing, and cross-domain coverage spanning anatomy, chemistry, disease, phenotype, organisms, simulation, and upper ontologies.

• How you’d use it — Filter the catalog by tags or text, select an ontology from the paginated results, and follow its actions to search classes, properties, or individuals. The rendered navigation also exposes API documentation, downloads, an MCP server, and informational pages.

• LLM angle — none stated

• Pitfalls & lessons — The unrendered page is only a JavaScript application shell, so automated consumers must use the service’s rendered interface or documented machine interfaces rather than assume the initial HTML contains the catalog. Individual catalog descriptions vary in detail and should not be treated as a substitute for each ontology’s own documentation.

• Verdict — Worth deeper study as a practical discovery and lookup front end for a large, domain-tagged collection of scientific ontologies.

Sources consulted

• https://www.ebi.ac.uk/ols4/ontologies

OntologyDesignPatterns.org

What it is OntologyDesignPatterns.org is a Semantic Web portal dedicated to ontology design patterns and run by ODPA. It began under the NeOn project and combines pattern catalogues with training, events, reviews, modeling issues, and community submissions.

Key concepts Pattern lists and types; domain classification; modeling issues linked to patterns; exemplary ontologies; open and quality-committee review.

How you’d use it Browse patterns by type or domain, look for a pattern tied to a modeling issue, study training material, or submit and review patterns and exemplary ontologies.

LLM angle none stated

Pitfalls & lessons Editing requires an account, and the page still marks “Certified content OP” as “Due to come,” so catalogue presence should not be mistaken for certification.

Verdict A practical community portal for discovering and contributing ontology design patterns, with review and training context alongside the catalogue.

Sources consulted

• http://ontologydesignpatterns.org/

prefix.cc

What it is prefix.cc describes itself as a namespace lookup service for RDF developers. Its examples show a prefix, a prefixed name, comma-separated prefixes, a .sparql form, and the URI http://xmlns.com/foaf/0.1/name.

Key concepts RDF namespaces; prefixes such as foaf, dc, rdfs, and geo; prefixed names such as foaf:knows; an unlabeled term-URI example; JSON-LD and SPARQL-oriented entry points.

How you’d use it Enter a prefix, prefixed name, or list of prefixes to perform a namespace lookup; the page also shows a .sparql request form for a prefix list and, without labeling its semantics, the URI http://xmlns.com/foaf/0.1/name.

LLM angle none stated

Pitfalls & lessons The fetched page is extremely terse and does not explain result semantics, API guarantees, namespace curation, conflict handling, or the JSON-LD option.

Verdict A narrowly presented lookup aid for RDF namespace prefixes, with useful input examples but little fetched documentation beyond them.

Sources consulted

• http://prefix.cc/

Protege Ontology Library

What it is — A Protege Wiki page for the Protege Ontology Library. The page states that the library is no longer maintained and directs users seeking biomedical ontologies to BioPortal.

Key concepts —

• The library’s stated status is unmaintained.
• BioPortal is the page’s recommended destination for biomedical ontologies.

How you’d use it — Treat the page as a retirement notice rather than a maintained ontology catalog; follow its BioPortal pointer when the need is biomedical.

LLM angle — none stated

Pitfalls & lessons — The source contains no library inventory or usage documentation, and explicitly says the library is no longer maintained.

Verdict — Not a current ontology-discovery resource on the evidence fetched; its useful content is the maintenance warning and biomedical redirect.

Sources consulted

• https://protegewiki.stanford.edu/wiki/Protege_Ontology_Library

The Linked Open Data Cloud

What it is The Linked Open Data Cloud site hosts a diagram of datasets published in Linked Data format, organized into domain subclouds. It provides historical diagram releases, raw data, and the LOD Cloud Draw generator.

Key concepts Resolvable HTTP(S) URIs; RDF representations; cross-dataset RDF links; RDF crawling, dumps, or SPARQL access; domain subclouds; reusable diagram data.

How you’d use it Browse the diagram to see connected Linked Data datasets, download a historical PNG, SVG, or JSON release, or submit a qualifying dataset after publishing it according to the site’s Linked Data criteria.

LLM angle none stated

Pitfalls & lessons Inclusion requires at least 1,000 triples, at least 50 links to an existing diagram dataset, RDF resolution, and access to the entire dataset. The site calls the 50-link threshold arbitrary and says the submission process is still under development.

Verdict A useful visual and machine-readable map of the Linked Data ecosystem, with explicit—but partly pragmatic—admission rules.

Sources consulted

• https://lod-cloud.net/

DCMI Metadata Terms

What it is DCMI Metadata Terms is the authoritative specification of metadata terms maintained by the Dublin Core Metadata Initiative. It includes the original fifteen Dublin Core elements plus several dozen properties, classes, datatypes, and vocabulary encoding schemes, expressed as RDF vocabularies for Linked Data.

Key concepts

• Four namespaces cover the original elements (/elements/1.1/), broader terms (/terms/), the DCMI Type Vocabulary (/dcmitype/), and vocabulary-description terms (/dcam/).
• Each term has a URI, label, definition, and type; applicable terms may also declare domain, range, hierarchy, membership, or equivalence information.
• The specification encourages /terms/ for new use while promising indefinite support for /elements/1.1/.

How you’d use it Choose stable DCMI URIs to describe resources and combine them with compatible vocabularies in an application profile. In non-RDF systems such as XML, JSON, UML, or relational databases, the document says you can treat RDF relations as usage suggestions and rely on the natural-language definitions, notes, and examples.

LLM angle none stated

Pitfalls & lessons The original fifteen properties exist in parallel in /elements/1.1/ and /terms/; the source says most users can treat them as equivalent, but their formal ranges differ and matter to RDF applications.

Verdict A strong primary reference for selecting and interpreting Dublin Core terms, especially when URI stability and formal RDF semantics matter.

Sources consulted

• http://dublincore.org/documents/dcmi-terms/

Dublin Core Metadata Element Set

What it is

The Dublin Core Metadata Element Set 1.1 is a vocabulary of fifteen broad, generic properties for describing many kinds of resources. The fetched 2012 reference is explicitly a historical snapshot; current documentation for these terms is part of the larger DCMI Metadata Terms specification.

Key concepts

• The fifteen elements are contributor, coverage, creator, date, description, format, identifier, language, publisher, relation, rights, source, subject, title, and type.
• The legacy dc: properties have no formal domains or ranges so existing “simple Dublin Core” RDF implementations remain conformant.
• Correspondingly named dcterms: properties are subproperties of the legacy terms and add formal domains and ranges for machine-processable inference.
• DCMI terms are designed to be combined with compatible vocabularies in application profiles.

How you’d use it

Attach a small, interoperable metadata record to a resource using the fifteen generic properties, applying controlled vocabularies or formal identifiers where the term guidance recommends them. Choose between the legacy dc: and dcterms: variants according to application requirements, while following DCMI’s encouragement to prefer the more semantically precise dcterms: properties over time.

LLM angle

none stated

Pitfalls & lessons

The page warns that this version is somewhat out of date and directs implementers to DCMI Metadata Terms for current documentation. The two namespaces are not interchangeable in semantics: dcterms: adds domains and ranges that the legacy dc: properties intentionally omit.

Verdict

A compact historical reference for the original fifteen Dublin Core properties; useful for legacy interpretation, while new work should consult the current DCMI terms and favor their more precise variants where appropriate.

Sources consulted

• http://dublincore.org/documents/dces/

IMI (Infrastructure for Multilayer Interoperability) Core Vocabulary

What it is

IMI is a Common Vocabulary Framework for describing shared terms and their relationships to improve interoperability in open data and Digital Government. It represents terms as organized concepts, associates words with those concepts, and distinguishes class concepts from property concepts.

Key concepts

The Core Vocabulary contains roughly 60 class concepts and 250 property concepts plus associated words. Domain and application vocabularies extend the core through inherited concepts, while a Data Model Description (DMD) packages human-readable explanations, use-specific constraints, program data structures, and mappings between structures and IMI concepts.

How you’d use it

Data providers associate published data with IMI vocabulary concepts, and developers or users interpret that data through the same associations. Define and share a DMD for a specific use so existing data structures can be mapped to precise meanings without requiring providers to change how they publish data.

LLM angle

none stated

Pitfalls & lessons

Interoperability depends on representing text words and dataset labels as shared concepts, not merely sharing labels. For individual uses, the source presents DMD constraints and mappings as the mechanism that preserves existing publishing practices while making meaning precise.

Verdict

A compact core-and-extension framework for cross-party data interoperability, with DMDs providing the application-specific bridge between conceptual meaning and concrete data structures.

Sources consulted

• https://imi.go.jp/goi/imi-about-en

Open Graph protocol

What it is

The Open Graph protocol is a metadata vocabulary that lets a web page be represented as a rich object in a social graph. Its initial design is based on RDFa and uses <meta> elements in the page’s <head>, with developer simplicity as an explicit goal.

Key concepts

• Every page requires og:title, og:type, og:image, and og:url; the URL is the object’s canonical permanent identifier in the graph.
• Recommended optional metadata includes audio, description, determiner, locale and alternate locales, site name, and video.
• Structured properties add details such as a media item’s secure URL, MIME type, dimensions, and image alternative text.
• Repeating a meta property forms an array, while global and custom namespaced object types extend the type system.

How you’d use it

Add the four required properties to a page’s <head>, then supply optional and type-specific properties for the preview or graph object you need. Add structured media metadata after its root property, and provide og:image:alt when an Open Graph image is present.

LLM angle

none stated

Pitfalls & lessons

Some og:type values impose additional required properties. For repeated values, the first tag wins conflicts; structured properties must immediately follow the root value they describe, because a new root starts a new grouping. The protocol also says an Open Graph image should have alternative text.

Verdict

A deliberately small implementation target for turning ordinary pages into graph objects, with enough extension points for richer media and domain-specific types.

Sources consulted

• http://ogp.me/

RDF Schema (RDFS) 1.1

What it is RDF Schema 1.1 is a W3C data-modeling vocabulary and semantic extension for RDF. It describes groups of related resources and their relationships using RDF itself.

Key concepts Its core terms include classes and instances (rdfs:Class, rdf:type), transitive class and property hierarchies (rdfs:subClassOf, rdfs:subPropertyOf), global property domains and ranges, and human-facing documentation (rdfs:label, rdfs:comment).

How you’d use it Define an application vocabulary, classify resources, organize class/property hierarchies, and state the classes to which property subjects and values belong. Applications may use domain/range information for inference, editing suggestions, or error discovery.

LLM angle none stated

Pitfalls & lessons Domains and ranges do not directly express restrictions local to one class, and multiple declarations mean membership in all declared classes. RDFS does not prescribe how applications act on this information, and the specification says RDF Semantics is authoritative if the two documents disagree.

Verdict A compact, extensible vocabulary layer for RDF; use a richer ontology language such as OWL when the required meaning exceeds its deliberately basic facilities.

Sources consulted

• https://www.w3.org/TR/rdf-schema/

Schema.org Schemas

What it is This Schema.org page is the development-version view of the full schema hierarchy. It presents two hierarchies: one for the things being described and another for textual property-value data types.

Key concepts The main hierarchy organizes types/classes under Thing, while the parallel DataType hierarchy includes values such as Boolean, Date, DateTime, Number, Text, URL, and Time. Types can have more than one super-type.

How you’d use it Open or close the hierarchy to browse Schema.org’s available types and see a type in parent-child context, then consult the parallel data-type tree when choosing a value category.

LLM angle none stated

Pitfalls & lessons The page is explicitly a development version. Although a type may have multiple super-types, the visualization shows it in only one branch, so the displayed tree is not a complete view of multiple inheritance.

Verdict A useful broad map of Schema.org’s type space, but not a complete visualization of every super-type relationship.

Sources consulted

• https://schema.org/docs/full.html

SKOS (Simple Knowledge Organization System)

What it is

SKOS is a W3C Recommendation defining a common data model for sharing and linking knowledge organization systems such as thesauri, classification schemes, subject-heading systems, and taxonomies on the Web. It represents those systems as RDF triples under a model formally defined as an OWL Full ontology, while explicitly distinguishing a knowledge organization system from a formal knowledge-representation ontology.

Key concepts

• URI-identified skos:Concept resources grouped into concept schemes.
• Preferred, alternative, and hidden multilingual labels; notations for scheme-specific codes; and extensible documentation notes.
• Hierarchical and associative semantic relations, labeled or ordered collections, and mappings between schemes using hierarchical, associative, close-equivalence, or exact-equivalence links.
• An optional SKOS-XL extension for identifying, describing, and linking lexical entities.

How you’d use it

Publish an existing thesaurus, taxonomy, or classification scheme as machine-readable RDF without first re-engineering it into formal domain axioms. Use labels, notes, relations, collections, and cross-scheme mappings to support exchange, linking, navigation, and discovery across applications.

LLM angle

none stated

Pitfalls & lessons

SKOS concepts model the ideas in a thesaurus as individuals and the scheme’s descriptions as facts about those individuals; they are not OWL classes or formal facts about how the domain itself is arranged. The OWL Full/open-world basis is also important: missing data supports no conclusion, the specification defines relatively few integrity conditions, and its RDF/XML schema captures only a normative subset of the full specification.

Verdict

A strong fit for interoperable, Web-published controlled vocabularies when preserving their informal or semi-formal character matters; use OWL alongside it when the application instead needs formal domain axioms.

Sources consulted

• https://www.w3.org/TR/skos-reference/
• Local fetched source: sources/skos-simple-knowledge-organization-system.txt

Common Logic (CL)

What it is Common Logic is an ISO-published framework for a family of first-order-logic-based languages intended to exchange and transmit knowledge between computer systems. Concrete syntaxes are dialects that inherit CL semantics by demonstrating conformance to its abstract, model-theoretic semantics.

Key concepts The standard specifies CLIF, CGIF, and XML-based XCL. Conformant dialects are comparable through translation to a common language, but they may differ in expressiveness; the page also names COLORE, Hets, and partially supporting cltools as implementations or supporting resources.

How you’d use it Define or select a dialect whose concrete syntax maps precisely to the CL abstract syntax, then use that mapping to exchange logical knowledge across dialects. A less expressive CL subset can generally translate into a more expressive one.

LLM angle none stated

Pitfalls & lessons Reverse translation from a more expressive language is only defined for a subset of that language, so interchange is not automatically lossless in both directions. The article is also marked as needing more citations.

Verdict A semantics-first interchange framework for heterogeneous logical syntaxes, strongest when conformance and expressiveness boundaries are made explicit.

Sources consulted

• https://en.wikipedia.org/wiki/Common_Logic

HDT

What it is HDT (Header, Dictionary, Triples) is a compact data structure and binary serialization format for RDF. The project says it compresses large RDF datasets while preserving search operations.

Key concepts Header–Dictionary–Triples organization; RDF compression; searchable binary data; C++ and Java libraries; Apache Jena and Jena Fuseki integration; the HDT-it GUI.

How you’d use it Keep application RDF data in HDT through the C++ or Java libraries, integrate it with Jena or Fuseki, or use HDT-it on Windows, macOS, or Linux to generate and browse HDT files.

LLM angle none stated

Pitfalls & lessons none stated

Verdict A focused option for storing large RDF datasets compactly without giving up search, with both programmatic and GUI entry points.

Sources consulted

• http://www.rdfhdt.org/

JSON-LD

What it is

JSON-LD (“JavaScript Object Notation for Linked Data”) is a W3C Recommendation for encoding linked data in JSON while retaining a form similar to traditional JSON. It is designed so linked-data semantics can be introduced by modifying JSON documents.

Key concepts

• An @context maps JSON properties and types to concepts in an ontology using the RDF model.
• Contexts may be embedded in a document or referenced for traditional JSON through an HTTP Link header.
• Values can be coerced to specified types or tagged with a language; @id and @type support IRI-based identity and typing.
• Resolvable IRIs let clients follow links to discover additional RDF data, and RDF processors can interpret mapped properties when they understand the vocabulary.

How you’d use it

Add a context to ordinary JSON to map application fields to vocabulary IRIs, identify entities unambiguously, and expose linked-data meaning to RDF-aware processors. The page reports use in Schema.org and search-engine optimization, biomedical informatics, provenance, Activity Streams/ActivityPub, and IoT Thing Descriptions.

LLM angle

none stated

Pitfalls & lessons

none stated

Verdict

A practical bridge between familiar JSON structures and RDF-linked semantics, with documented adoption across web metadata, federated activity data, provenance, biomedicine, and IoT.

Sources consulted

• https://en.wikipedia.org/wiki/JSON-LD

Loom

What it is Loom is a knowledge-representation language and environment for constructing intelligent applications, developed at USC’s Information Sciences Institute. Its deductive system supports declarative definitions, rules, facts, and default rules while integrating logic programming, production rules, and object-oriented programming.

Key concepts

• A classifier uses forward chaining, semantic unification, and object-oriented truth maintenance to compile declarative knowledge into a network for online deductive queries.
• A logic-based pattern matcher drives both production rules and pattern-directed object-oriented method dispatch.
• Loom can act as a deductive layer over an ordinary CLOS network.
• Ontosaurus provides a dynamically generated, hyperlinked browser for Loom and PowerLoom knowledge bases.

How you’d use it Define domain concepts, facts, defaults, and rules, then rely on the classifier and query machinery to maintain and reason over the knowledge base. The source also describes using Loom as a common high-level vocabulary over heterogeneous information sources or as a domain-model layer above lower-level application data.

LLM angle none stated

Pitfalls & lessons The fetched project page’s release news is historical, with Loom 4.0 dated July 1999 and its most recent listed news dated June 2006. The software is open-source licensed but explicitly remains USC intellectual property and is not in the public domain.

Verdict A historically significant integrated reasoning environment with unusually close declarative/procedural coupling; evaluate its dated release context before adopting it for new work.

Sources consulted

• https://www.isi.edu/isd/LOOM/

N-Quads

What it is

N-Quads is a W3C RDF serialization with the .nq extension and application/n-quads media type. It is a superset of N-Triples that adds an optional context value in the fourth position.

Key concepts

Each illustrated statement contains an RDF subject, predicate, and object plus a graph/context IRI before the terminating full stop. The format also permits comments beginning with #.

How you’d use it

Use it when line-oriented RDF data must retain the graph or context associated with individual triples, such as serializing an RDF dataset rather than only one RDF graph.

LLM angle

none stated

Pitfalls & lessons

none stated

Verdict

A small extension of N-Triples suited to RDF data that needs explicit per-statement graph context.

Sources consulted

• https://en.wikipedia.org/wiki/N-Triples#N-Quads

N-Triples

What it is

N-Triples is a line-based plain-text serialization for RDF graphs and a subset of Turtle. It is a W3C format with the .nt extension and application/n-triples media type.

Key concepts

Each statement line contains a subject, predicate, object, and terminating full stop; subjects may be URIs or blank nodes, predicates must be URIs, and objects may also be literals. Comments begin with #, and statement-ending line breaks cannot be wrapped arbitrarily.

How you’d use it

Use it to store or transmit RDF in a representation that is simple for software to parse and generate. Its low representational variation also makes it convenient for expected “model answers” in RDF test suites.

LLM angle

none stated

Pitfalls & lessons

It lacks shortcuts such as CURIEs and nested resources, so large files can be onerous to type and difficult to read. Do not confuse it with Notation3, which the source identifies as a superset of Turtle.

Verdict

A deliberately simple, predictable RDF interchange and testing format, trading human compactness for ease of machine processing.

Sources consulted

• https://en.wikipedia.org/wiki/N-Triples

Nanotation

What it is Nanotation is described as a mechanism for using “digital sentences” to enhance blog posts, forum discussions, tweets and other micro-blog posts, HTML, and plain-text documents. It also turns those document types into end-user channels for contributing data incrementally to public or private Linked Open Data clouds.

Key concepts Digital sentences; ordinary publishing formats as data-contribution conduits; public and private Linked Open Data clouds; piecemeal, crowd-sourced curation and publishing.

How you’d use it Add digital sentences to an existing post or document so that publishing the text also contributes a small piece of data to a Linked Open Data cloud.

LLM angle none stated

Pitfalls & lessons The fetched page is archived and read-only, and it provides only a high-level description plus a link to a 2014 blog post; it does not state a syntax, implementation procedure, or interoperability details.

Verdict An appealing lightweight idea for crowd-sourced Linked Data publishing, but the fetched source is too brief to evaluate how the mechanism works in practice.

Sources consulted

• https://www.w3.org/community/rww/wiki/Nanotation

Notation3

What it is Notation3 (N3) is a compact, non-XML serialization for RDF models designed for human readability. It also goes beyond RDF serialization by supporting RDF-based rules, while Turtle is described as its simplified RDF-only subset.

Key concepts

• N3 uses prefixes, compact subject/predicate repetition, QNames, blank-node shorthand, lists, and RDF paths.
• It adds quantification directives such as @forAll and @forSome, statement lists, and implication or equivalence operators that the page says Turtle and N-Triples lack.
• The documented filename extension is .n3, and the media type is text/n3;charset=utf-8.

How you’d use it Write RDF graphs in a more concise form than RDF/XML, using prefixes and punctuation to reduce repetition. Choose N3 rather than its Turtle subset when the model needs the additional rule, quantification, path, or statement-list features shown on the page.

LLM angle none stated

Pitfalls & lessons The page’s feature comparison is explicitly marked incomplete. N3 should not be treated as interchangeable with Turtle: the example is valid in both, but several N3 constructs listed on the page are not Turtle syntax.

Verdict A readable RDF notation with meaningful logic and rule extensions, useful when Turtle’s RDF-only scope is too narrow.

Sources consulted

• https://en.wikipedia.org/wiki/Notation3

OBO Format (OBOF)

What it is This is the working-draft specification for OBO Flat File Format 1.4, providing a BNF grammar and a mapping to OWL 2 DL. It defines how physical OBO files parse into abstract documents, imposes structural constraints, and gives their semantics through OWL translation rules.

Key concepts An OBO document has one header frame followed by zero or more term, typedef, or instance frames made of tag/value clauses. The specification covers identifiers and frame merging, tag cardinalities, header macros, OWL mappings, an owl-axioms escape hatch, the restrictive OBO Basic sublanguage, and informative OWL macros.

How you’d use it Use it to implement or validate OBO parsers and serializers, translate OBO constructs into OWL 2 DL, or determine whether a document satisfies OBO Basic assumptions such as being a DAG, fully asserted, fully labeled, and free of imports and dangling clauses.

LLM angle none stated

Pitfalls & lessons The document labels itself a working draft and says some parts may be unstable. Translation into a sublanguage is generally lossy; arbitrary OWL axioms can round-trip through owl-axioms but remain opaque to many OBO applications; and the specification explicitly says OBOF is not a good choice for knowledge bases that use individuals.

Verdict The authoritative source in this fetch for OBOF 1.4 syntax and OWL semantics, but its draft status and legacy-compatibility constraints matter when implementing against it.

Sources consulted

• http://purl.obolibrary.org/obo/oboformat/spec.html

Ontology language

What it is Ontology languages are formal, usually declarative languages for constructing ontologies and encoding domain knowledge. They often include reasoning rules and are commonly based on first-order logic or description logic.

Key concepts The page classifies languages both by syntax—traditional, markup, controlled natural language, and open-vocabulary natural language—and by logical structure—frame-based, description-logic-based, and first-order-logic-based. Examples include Common Logic and KIF, RDF/RDFS and OWL, and Attempto Controlled English.

How you’d use it Use the classifications as a map for choosing a representation style: markup-oriented interchange, controlled-language authoring, frame modeling, description-logic classification, or first-order predicates.

LLM angle none stated

Pitfalls & lessons The source itself is flagged for possible original research, insufficient citations, and weak inline citation coverage, so treat its taxonomy as an orientation aid rather than a definitive standard.

Verdict A concise vocabulary and taxonomy for surveying ontology-language families, but the article’s editorial warnings limit its authority.

Sources consulted

• https://en.wikipedia.org/wiki/Ontology_language

OWL 2 Web Ontology Language

What it is

OWL 2 is a W3C ontology language for the Semantic Web with formally defined meaning, representing classes, properties, individuals, and data values in Semantic Web documents. This W3C Recommendation is a non-normative overview and roadmap; OWL 2 itself is normatively defined across several core specification documents.

Key concepts

• An ontology can be viewed as an abstract structural object or as an RDF graph.
• RDF/XML is the mandatory interchange syntax for conformant tools; OWL/XML, Functional Syntax, Manchester Syntax, and Turtle serve other processing or readability needs.
• Direct Semantics supports OWL 2 DL and description-logic reasoning, while RDF-Based Semantics applies to any OWL 2 ontology as an RDF graph.
• The EL, QL, and RL profiles restrict expressivity to gain particular computational or implementation benefits: large-ontology reasoning, relational querying, or rule-based RDF processing.
• OWL 2 adds features over OWL 1 including keys, property chains, richer datatypes, qualified cardinalities, additional property characteristics, and enhanced annotations.

How you’d use it

Define and share a domain vocabulary with explicit relationships, serialize it in a tool-supported syntax, and use reasoners for class consistency, subsumption, or instance retrieval. Select EL, QL, or RL when its stated performance/implementation trade-off matches the application; use the Primer or Quick Reference for a more approachable entry point than the core specifications.

LLM angle

none stated

Pitfalls & lessons

This overview is informative rather than the normative language definition and notes that later documents may supersede it. OWL 2 DL requires syntactic conditions—for example, transitive properties cannot appear in number restrictions. Rule-based OWL 2 RL reasoning over an arbitrary RDF graph is sound but may be incomplete unless the ontology meets the RL structural definition and the stated query conditions.

Verdict

The authoritative starting map for understanding OWL 2’s syntax, semantics, profiles, and document suite, but implementation and conformance decisions must follow the linked normative specifications.

Sources consulted

• https://www.w3.org/TR/owl2-overview/

RDF (Resource Description Framework) 1.1

What it is RDF is a W3C method for describing and exchanging graph data, originally designed as a metadata data model. Its abstract model is a labeled directed multigraph made of subject–predicate–object statements, with RDF 1.1 published in 2014.

Key concepts Subjects and predicates are identified by IRIs; objects may also be blank nodes or literals. The same graph can be serialized as Turtle, TriG, N-Triples, N-Quads, JSON-LD, RDF/XML, and other formats, stored in a triplestore, and queried with SPARQL.

How you’d use it Represent resources and relationships as triples, choose a suitable serialization, store the graph in a triplestore, and query it with SPARQL. RDFS, OWL, and SHACL can add vocabulary, ontology, or validation layers over RDF.

LLM angle none stated

Pitfalls & lessons Do not confuse RDF’s abstract graph model with RDF/XML, one serialization of it. Producers and consumers must agree on identifier semantics because that agreement is not inherent in RDF; blank nodes are also anonymous and not directly identifiable from a statement.

Verdict A simple, flexible graph foundation for interoperable knowledge representation, with deliberate separation between the abstract model and its concrete syntaxes.

Sources consulted

• https://en.wikipedia.org/wiki/Resource_Description_Framework

RDF*

What it is The fetched source is the RDF-star community landing page, describing RDF-star (formerly RDF*) as part of the RDF-DEV community group. It links to the Final Community Group Report, drafts, use cases, test suites, syntax and semantics documents, implementation reports, and community channels.

Key concepts

• The page distinguishes a Final Community Group Report, latest published draft, and editor’s draft.
• Listed technical materials cover Turtle-star, TriG-star, N-Triples-star, semantics, and SPARQL-star.
• The community infrastructure includes GitHub issues and a repository, a mailing list, meeting minutes, and implementation reports.

How you’d use it Use the landing page as a directory to the specification, use cases, syntax and evaluation suites, semantics, SPARQL-star materials, and implementation evidence.

LLM angle none stated

Pitfalls & lessons none stated

Verdict A useful navigation hub, but the fetched text is too sparse to explain RDF-star’s data model or technical behavior on its own.

Sources consulted

• https://w3c.github.io/rdf-star/

RDF/XML

What it is RDF/XML is a W3C-defined syntax for serializing an RDF graph as an XML document. Its media type is application/rdf+xml, and the fetched source identifies RDF/XML 1.1 as released on 24 February 2014.

Key concepts It is an XML-derived container for RDF data and was historically the first official W3C RDF serialization format. It is also the primary exchange syntax for OWL 2 and must be supported by all OWL 2 tools.

How you’d use it Use RDF/XML when an RDF graph must be exchanged as XML, particularly with OWL 2 tooling that is required to support it.

LLM angle none stated

Pitfalls & lessons RDF/XML is sometimes misidentified as RDF itself; it is only one syntax for expressing the RDF graph model.

Verdict A standardized XML exchange syntax with mandatory OWL 2 tool support, but it should not be conflated with RDF as a whole.

Sources consulted

• https://en.wikipedia.org/wiki/RDF/XML

RDFa

What it is RDFa, or Resource Description Framework in Attributes, is a W3C Recommendation that adds attributes to HTML, XHTML, and XML-based documents so they can carry rich metadata. Its RDF mapping embeds subject-predicate-object expressions in markup and lets compliant user agents extract RDF triples.

Key concepts

• about identifies the resource being described; rel and rev express relationships.
• src, href, and resource identify a partner resource, while property names a property.
• content, datatype, and typeof control values, datatypes, and RDF types.
• RDFa Lite narrows the model to five attributes: vocab, typeof, property, resource, and prefix.
• RDFa 1.1 works with HTML 4/5 as well as XML because it no longer depends on XML namespaces.

How you’d use it Annotate visible web content with vocabulary terms—for example, Dublin Core title, creator, and date properties—so the page remains readable while software can extract triples. For ordinary markup needs, the source presents RDFa Lite as a smaller, upward-compatible subset.

LLM angle none stated

Pitfalls & lessons Version and host-language distinctions matter: RDFa 1.0 is associated with older XHTML, whereas RDFa 1.1 is generic across HTML and XML. The usage figures in the fetched page are historical (2013 and 2017), including an explicit update marker, so they should not be treated as current adoption data.

Verdict A practical bridge between human-facing web markup and extractable RDF, with RDFa Lite offering the clearest entry point described by the source.

Sources consulted

• https://en.wikipedia.org/wiki/RDFa

TriG

What it is TriG is a plain-text serialization format for RDF graphs, named graphs, and RDF datasets. It extends Turtle, uses the .trig extension and application/trig media type, and is a W3C Recommendation.

Key concepts A TriG document can declare prefixes and group RDF statements inside graph blocks identified by names. The source’s example uses three interlinked named graphs, including statements about who asserted or quoted other graphs.

How you’d use it Write Turtle-like triples inside named graph blocks when one text document needs to preserve multiple related RDF graphs and their identities.

LLM angle none stated

Pitfalls & lessons The linked Yacker validator is explicitly described as not handling sub-graphs and not validating the page’s example, so validator capability should not be assumed from TriG support alone.

Verdict A compact, readable RDF dataset syntax when named-graph structure matters.

Sources consulted

• https://en.wikipedia.org/wiki/TriG_(syntax)

TriX

What it is

TriX (“Triples in XML”) is an XML serialization for RDF graphs, Named Graphs, and RDF Datasets. Created jointly by HP Labs and Nokia, it is presented as a compact, readable alternative to RDF/XML.

Key concepts

A TriX document contains graphs and triples, with explicit XML elements for URIs, plain literals, and typed literals. The fetched page lists text/xml as its media type.

How you’d use it

Use it when RDF graphs or datasets need an XML representation whose triple structure and literal types are explicit in the document tree.

LLM angle

none stated

Pitfalls & lessons

The fetched article flags itself as needing more citations, potentially lacking demonstrated notability, and being too technical for many readers. It also notes that serialization-dependent digital artifacts need an immutability-verification mechanism and mentions cryptographic hashes in applied URIs as a proposed approach.

Verdict

A structurally explicit XML option for RDF datasets and named graphs, but the fetched overview itself has sourcing and accessibility warnings.

Sources consulted

• https://en.wikipedia.org/wiki/TriX_(serialization_format)

Turtle

What it is Turtle (Terse RDF Triple Language) is a syntax and .ttl file format for expressing RDF graphs. It is a W3C Recommendation whose syntax resembles SPARQL and is intended to be more readable and manually editable than RDF/XML.

Key concepts RDF statements are subject–predicate–object triples; Turtle abbreviates their URI-heavy representation with prefixes and shared subjects or predicates. It is a subset of Notation3, a superset of N-Triples, uses the text/turtle media type, and is always UTF-8.

How you’d use it Declare prefixes, write RDF triples in compact form, and parse or serialize them with an RDF toolkit such as RDFLib, Jena, RDF4J, Redland, or N3.js.

LLM angle none stated

Pitfalls & lessons Turtle can serialize only valid RDF graphs, not the broader expressiveness of full Notation3. It does not itself support named graphs; TriG extends Turtle for that purpose.

Verdict A compact, readable choice for authoring and exchanging ordinary RDF graphs.

Sources consulted

• https://en.wikipedia.org/wiki/Turtle_(syntax)

Description Logic Complexity Navigator

What it is — A web navigator maintained by Evgeny Zolin for complexity results about reasoning in Description Logics. It starts from ALC and lets a selected logic vary by concept constructors, role constructors, TBox/RBox features, and whether complex roles are allowed in number restrictions.

Key concepts —

• The selectable concept features include functionality, unqualified and qualified number restrictions, nominals, and a least-fixpoint operator.
• Role features include inverse, intersection, union, complement, composition, reflexive-transitive closure, and concept identity; axiom choices include empty, acyclic, or general TBoxes plus transitivity, role hierarchies, and complex role inclusions.
• Results cover concept satisfiability, ABox consistency, and finite- and tree-model properties.
• The page distinguishes upper bounds (“in C”), lower bounds (“C-hard”), and matching bounds (“C-complete”).

How you’d use it — Select the constructors and axiom features of a Description Logic, then consult the reported reasoning complexity and model properties. When a target combination has no result, the page suggests adding or removing ingredients to inspect known neighboring logics, while warning that this does not fill every intermediate gap.

LLM angle — none stated

Pitfalls & lessons — The author says the navigator is always incomplete and frequently updated; a missing result means the page author found none in the literature, not that no result exists. Logic names can also hide whether complex roles are allowed in number restrictions, and the navigator cannot display every independent combination of role use in value versus number restrictions.

Verdict — A focused comparison tool for navigating how Description Logic features relate to reasoning complexity, best treated as an incomplete literature map rather than an exhaustive authority.

Sources consulted

• http://www.cs.man.ac.uk/~ezolin/dl/

Description Logics (DLs)

What it is Description logics are a family of formal knowledge-representation languages, generally more expressive than propositional logic and less expressive than first-order logic. They model concepts, roles, individuals, and axioms while balancing expressive power against reasoning complexity; many core reasoning problems are decidable.

Key concepts

• Concepts correspond to classes or unary predicates, roles to properties or binary predicates, and individuals to constants.
• A TBox states concept hierarchies; an ABox states facts about individuals.
• DL semantics interpret concepts as sets of individuals and roles as sets of ordered pairs.
• Common inference tasks include instance checking, relation checking, subsumption, and concept-consistency checking.
• DL does not generally assume unique names or a closed world.

How you’d use it Use a DL to encode domain concepts and relationships, then ask a reasoner about membership, relations, subsumption, or consistency. The source identifies DLs as the logical foundation for OWL and its profiles and notes applications in ontologies, the Semantic Web, biomedical informatics, defense, climate modeling, and industrial knowledge graphs.

LLM angle none stated

Pitfalls & lessons Adding operators and making the TBox more complicated usually increases the computational complexity of inference. The open-world stance also means that lack of a fact does not imply its negation, and different names need not denote different things.

Verdict A compact conceptual map of the logic beneath OWL, with the expressivity-versus-reasoning-cost tradeoff as the central design lesson.

Sources consulted

• https://en.wikipedia.org/wiki/Description_logic

F-Logic

What it is

F-Logic (frame logic) is a knowledge-representation and ontology language combining conceptual modeling and object/frame-oriented features with declarative syntax and logic-programming semantics. It was originally developed for deductive databases and is now used chiefly in semantic technologies.

Key concepts

Object identity, complex objects, inheritance, polymorphism, query methods, and encapsulation are core features. Its syntax represents classes, individuals, properties, relations, and rules; its usual semantics use a closed-world assumption, unlike the open-world assumption described for description logics.

How you’d use it

Use it to model classes and individuals, state object properties and relations, and write inference axioms for information integration, question answering, semantic search, or other rule-oriented semantic applications.

LLM angle

none stated

Pitfalls & lessons

Description logic and OWL are described as more popular and accepted. F-Logic is generally undecidable, while the source says OWL DL’s underlying SHOIN description logic is decidable; the source also warns through an example that a syntactically expressible inference need not be factually sound.

Verdict

An expressive ontology and rule language when object/frame modeling and closed-world reasoning matter, but its lower adoption and general undecidability are important tradeoffs.

Sources consulted

• https://en.wikipedia.org/wiki/F-logic

[protege-user] which is the best query language for owl ontologies?

• What it is — A 2016 Protege-user mailing-list reply comparing DL Query, SPARQL, and SQWRL for querying OWL ontologies. It argues that “best” depends on requirements and summarizes differences in semantic awareness, expressiveness, tooling, and federation.

• Key concepts — DL Query uses an OWL class expression and returns superclasses, subclasses, or individuals; SPARQL matches RDF graph patterns and can query OWL through the OWL-to-RDF mapping; SQWRL extends OWL/SWRL with query-oriented built-ins and set operators. The discussion distinguishes a rule language (SWRL) from the SQWRL query language built on it.

• How you’d use it — Choose DL Query for compact, reasoner-backed class-expression questions inside Protégé; choose SPARQL for variables, rich operators, broad engine support, relational mappings, or federation; consider SQWRL for Protégé-local OWL-aware queries over individuals with arithmetic and cross-property comparisons.

• LLM angle — none stated

• Pitfalls & lessons — DL Query lacks variables, has limited operators, and does not federate. SPARQL over OWL can become verbose because complex OWL expressions have complex RDF representations, and not every SPARQL engine supports OWL 2 entailment. SQWRL is documented here as Protégé-only and non-federated. The thread explicitly cautions that suitability is requirement-dependent.

• Verdict — Worth reading as a compact, source-grounded decision guide for choosing among three OWL query approaches, with the caveat that it reflects a 2016 mailing-list discussion.

Sources consulted

• https://mailman.stanford.edu/pipermail/protege-user/2016-August/004995.html

DL Query (class expression)

What it is The DL Query tab is a Protégé Desktop feature for searching a classified ontology with class expressions based on Manchester OWL syntax. It ships with Protégé Desktop 4, 5, and later as both a tab and a view widget.

Key concepts Queries can retrieve individuals or classes according to inferred relationships, including subclasses and superclasses of an expression. The examples combine classes, properties, values, datatypes, cardinality restrictions, existential or universal restrictions, and negation.

How you’d use it Start FaCT++ or HermiT to classify the active ontology, confirm that the inferred class hierarchy is populated, enter a Manchester-syntax expression, and select the result types you want. A useful query can be added to the ontology as a newly named defined OWL class.

LLM angle none stated

Pitfalls & lessons Queries only run on a classified ontology, and individual matches are not shown unless the “Individuals” result option is checked. If the inferred hierarchy contains only Thing, the ontology may not have been classified successfully.

Verdict A practical Protégé interface for testing class definitions and exploring reasoner-derived matches before committing a definition to the ontology.

Sources consulted

• https://protegewiki.stanford.edu/wiki/DLQueryTab

SPARQL 1.1

What it is

SPARQL 1.1 Query Language is a W3C Recommendation defining the syntax and semantics of queries over RDF graphs. It supports data stored directly as RDF or exposed as RDF through middleware, and can return either solution sets or RDF graphs.

Key concepts

• Triple patterns generalize RDF triples by allowing variables; basic graph patterns match when RDF terms can be substituted for those variables to produce an equivalent subgraph.
• Graph patterns can combine required, optional, alternative, and negative matches; property paths compactly express traversal, including arbitrary-length paths.
• Queries run against an RDF dataset with one default graph and zero or more IRI-named graphs; GRAPH changes the active graph for part of a query.
• SELECT returns variable bindings, CONSTRUCT builds an RDF graph from templates, ASK reports whether a match exists, and DESCRIBE returns a service-determined description graph.
• Assignment, inline VALUES, aggregation, grouping, subqueries, expressions, and sequence modifiers such as ORDER BY, DISTINCT, OFFSET, and LIMIT shape the solutions.

How you’d use it

Write a WHERE graph pattern against the relevant default or named graphs, then choose the result form suited to the task: bindings with SELECT, a derived graph with CONSTRUCT, an existence check with ASK, or a service-generated resource description with DESCRIBE. Add filters, expressions, grouping, and explicit sequence modifiers when results need constraints, calculated values, aggregation, ordering, deduplication, or slicing.

LLM angle

none stated

Pitfalls & lessons

Pattern matches initially produce solutions in no specific order, so deterministic presentation requires ORDER BY. DESCRIBE output is determined by the query service rather than prescribed by the query. Queries using FROM, FROM NAMED, or GRAPH may dereference IRIs, consuming network, disk, or CPU resources; the specification also warns about denial-of-service, local file: access, firewall-indirection attacks, extension-specific risks, and visually confusable Unicode IRIs.

Verdict

This is the authoritative query-language reference: it combines examples with normative syntax, formal algebra and evaluation semantics, grammar, and conformance requirements. Its boundaries are explicit—resource descriptions are service-defined, and federated-query behavior is defined in a separate SPARQL 1.1 Recommendation.

Sources consulted

• https://www.w3.org/TR/sparql11-query/

SPARQL*

What it is The fetched page is the community home for RDF-star, formerly RDF*, within the RDF-DEV community group. It serves as an index to the final report, specification drafts, use cases, test suites, implementation reports, and SPARQL-star syntax and evaluation documents.

Key concepts RDF-star; SPARQL-star syntax; SPARQL-star evaluation; community reports; specifications; use cases; test suites; implementation reports.

How you’d use it Use the page to reach the SPARQL-star syntax and evaluation documents, inspect the specification and test suites, review implementation reports, or participate through GitHub, the mailing list, and open community meetings.

LLM angle none stated

Pitfalls & lessons none stated

Verdict A useful navigation and community hub for SPARQL-star materials, rather than a self-contained query-language explanation on the fetched page.

Sources consulted

• https://w3c.github.io/rdf-star/#sparql-query-language

SPARQL-DL

What it is SPARQL-DL is a substantial subset of SPARQL with semantics based directly on OWL-DL entailment. It is designed to combine TBox, RBox, and ABox queries while remaining implementable over standard services from existing OWL-DL reasoners.

Key concepts Queries are conjunctions of typed atoms such as Type, PropertyValue, SubClassOf, SubPropertyOf, and property-characteristic tests. The paper defines their model-theoretic satisfaction, solution mappings, and translation into SPARQL basic graph patterns.

How you’d use it Express mixed schema, property, and instance questions in the defined abstract atoms, translate them to RDF graph form, and evaluate them through an OWL-DL reasoner. The Pellet prototype first evaluates TBox/RBox atoms, substitutes their bindings, and reduces the remainder to ABox queries.

LLM angle none stated

Pitfalls & lessons Variables inside complex class expressions were excluded because they prevent reduction to standard reasoner services; arbitrary class expressions in results can also produce infinitely many answers. The prototype had no overall performance evaluation, did not support cyclic non-distinguished-variable ABox queries, and called broad queries such as Type(?x, ?C) impractical on a large ABox.

Verdict A pragmatic middle ground between unstructured RDF query languages and less expressive DL query interfaces, with explicit expressiveness limits chosen for implementability.

Sources consulted

• http://ceur-ws.org/Vol-258/paper14.pdf

SPARQL-OWL algorithm

What it is This paper presents a sound and complete query-answering algorithm for SPARQL’s OWL 2 Direct Semantics entailment regime. Its prototype combines ARQ, the OWL API, and HermiT and supports variables in complex class expressions and bindings to class or property names.

Key concepts Basic graph patterns are mapped to OWL axiom templates, simplified, split into connected components, and evaluated in a planned sequence. The optimizations include query reordering, rewriting, dedicated reasoner tasks, and exploitation of class/property hierarchies.

How you’d use it Use the algorithm to answer ontology-aware SPARQL queries whose results depend on OWL entailment rather than simple RDF subgraph matching. Put selective axiom templates early and add restrictive templates for variables to reduce intermediate mappings and reasoning work.

LLM angle none stated

Pitfalls & lessons Compatible mappings can grow exponentially with the number of query variables, and even optimized execution may remain expensive. The evaluation was preliminary—LUBM plus custom GALEN queries on one constrained machine—and some unoptimized queries exceeded the 30-minute limit.

Verdict A technically strong bridge from expressive SPARQL patterns to complete OWL reasoning; its reported gains of up to three orders of magnitude make optimization central rather than optional.

Sources consulted

• http://ceur-ws.org/Vol-796/owled2011_submission_4.pdf

LinkML

What it is LinkML is the Linked Data Modeling Language, a flexible language for authoring data schemas in YAML. It is also an Apache-2.0, community-driven framework for validating JSON, RDF, and TSV data and compiling schemas into other frameworks.

Key concepts Its metamodel is itself written in LinkML and centers on schema, class, slot, type, and enum definitions, each with a w3id.org/linkml URI. The documented toolchain covers constraints, rules, inheritance, URIs and mappings, schema linting, validation, conversion, and generators for formats and languages including JSON Schema, SHACL, ShEx, OWL, SQL, Python, Java, TypeScript, and Rust.

How you’d use it Describe a model in a YAML schema, validate datasets with the LinkML CLI or Python APIs, and generate the downstream schema, code, database definition, RDF artifact, or documentation needed by consumers.

LLM angle The documentation index includes a how-to guide titled “How to Generate AI prompts,” but the fetched landing page provides no further detail.

Pitfalls & lessons none stated

Verdict A broad schema hub when one authored model needs validation plus outputs for several data and programming ecosystems.

Sources consulted

• https://linkml.io/linkml

SHACL (Shapes Constraint Language)

What it is SHACL is a W3C Recommendation for describing RDF graphs through constraints on their content, structure, and meaning. It supports built-in constraints, extension through SPARQL or JavaScript, and SHACL Rules for inferring new statements.

Key concepts Node shapes constrain nodes, property shapes constrain values reached through paths, constraints express requirements such as datatype, minimum count, length, ranges, patterns, and logical combinations, and targets select where shapes apply. Validation consumes a data graph and a shapes graph and emits an RDF validation-report graph with severities such as Violation, Warning, and Info.

How you’d use it Create shapes for the resources or property paths you care about, assign targets, and run a SHACL engine against an RDF data graph. Use the report’s severity and messages to explain failures or suggest fixes.

LLM angle none stated

Pitfalls & lessons Targeting a class also targets members of its subclasses through rdfs:subClassOf. When a property shape is included by a node shape, the property shape’s own targets are ignored, so placement changes targeting behavior.

Verdict A highly expressive, RDF-native validation language with clear targeting and machine-readable reports, plus extension and rule mechanisms when built-ins are insufficient.

Sources consulted

• https://en.wikipedia.org/wiki/SHACL

ShEx (Shape Expressions)

What it is Shape Expressions (ShEx) is a data-modeling language for describing and validating RDF graphs. Shapes may be written in the compact ShExC syntax or in RDF serializations such as JSON-LD or Turtle, then used to check whether RDF nodes conform.

Key concepts ShEx combines Turtle/SPARQL-like syntax with semantics inspired by regular-expression languages such as RelaxNG. Shapes constrain properties, value types, references to other shapes, and cardinality—for example, requiring one string name and allowing zero or more links to nodes conforming to a person shape.

How you’d use it Write shapes for the RDF node patterns your dataset should satisfy, then run a compatible implementation such as PyShEx, shex.js, Ruby ShEx, ShEx.ex, or Shaclex to validate data.

LLM angle none stated

Pitfalls & lessons Implementation support is uneven in the fetched comparison table, with many feature cells unknown or unsupported. One listed online demo is explicitly marked as a possible link-rot case.

Verdict A concise, human-oriented way to make RDF structural expectations executable, provided the chosen implementation supports the needed features.

Sources consulted

• https://en.wikipedia.org/wiki/ShEx

SPIN (SPARQL Inferencing Notation)

What it is SPIN is a W3C Member Submission for representing SPARQL rules and constraints on Semantic Web models, described by its site as a de-facto industry standard. It also supports user-defined SPARQL functions and query templates and includes a library of common functions.

Key concepts SPIN links class definitions to SPARQL queries through a lightweight set of RDF properties. Rules use SPARQL CONSTRUCT or UPDATE, constraints use ASK or CONSTRUCT with closed-world semantics, and templates can expose higher-level domain-specific forms that hide direct SPARQL authoring.

How you’d use it Attach rules to classes to derive property values, initialize or update data under conditions, and drive incremental or interactive behavior directly over RDF data. Attach constraints to check required values or formats and raise inconsistency flags when the available data violates them.

LLM angle none stated

Pitfalls & lessons The site’s July 2017 update tells prospective users to read “From SPIN to SHACL” before exploring SPIN further. Constraint results use closed-world semantics and reflect the information currently available, which is a distinct assumption from open-world ontology reasoning.

Verdict A SPARQL-native framework for executable RDF rules, constraints, templates, and functions, with an explicit migration-era pointer to consider before adoption.

Sources consulted

• http://spinrdf.org/

SWRL (Semantic Web Rule Language)

What it is

SWRL is a 2004 W3C Member Submission proposing a rule language that combines OWL DL/OWL Lite with Unary/Binary Datalog RuleML. It extends OWL axioms with Horn-like rules and defines abstract, XML, and RDF syntaxes plus a model-theoretic semantics.

Key concepts

A rule is an implication whose antecedent and consequent are conjunctions of atoms; variables are universally quantified within a rule and variables in the consequent must also occur in the antecedent. Atoms can test class or data-range membership, properties, equality or difference, and built-in relations; the proposal includes built-ins for comparisons, math, booleans, strings, dates/times, URIs, and lists.

How you’d use it

Add implications that derive knowledge not conveniently expressed by OWL alone—for example, infer hasUncle(?x,?z) from hasParent(?x,?y) and hasBrother(?y,?z). Prefer native OWL constructs when they already express the same fact, such as a subclass axiom instead of a rule saying every student is a person.

LLM angle

none stated

Pitfalls & lessons

The unrestricted extension makes OWL DL undecidable. The submission therefore advises restricting rule form or expressiveness to improve interoperability, reuse, implementation ease, scalability, and tractability; it also explicitly notes that W3C publication does not endorse the submission.

Verdict

A formally specified bridge between OWL knowledge bases and Horn-like rules, useful for explicit derivations but requiring disciplined restrictions and careful implementation expectations.

Sources consulted

• https://www.w3.org/Submission/SWRL/

CEL

What it is

CEL is a lightweight description-logic reasoner aimed at large-scale biomedical ontologies. It reasons over EL+, the core expressive features of the tractable OWL 2 EL profile, and its main task is computing the subsumption hierarchy induced by an ontology using a polynomial-time algorithm.

Key concepts

• EL+ / OWL 2 EL reasoning tailored to medical and biological ontologies.
• Ontology classification and output as superclass sets, a direct subclass/superclass taxonomy, or an indented hierarchy.
• Supplemental features from version 1.0 including incremental classification, modularization, and axiom pinpointing.
• An OWL API wrapper and Protégé plug-in, plus a simple interactive interface and command-line mode.

How you’d use it

Load and classify an EL+ ontology from the CLI, emit its taxonomy or hierarchy, or start an interactive session with a preprocessed ontology. It can also act as the backend reasoner inside Protégé through the OWL API plug-in; module extraction is exposed for a concept or a signature.

LLM angle

none stated

Pitfalls & lessons

The site describes CEL as an OWL 2 EL reasoner “with some limitations,” and says extending expressivity toward EL++ is ongoing work. It also says the downloadable compiled releases are Linux 32-bit only; other platforms require compiling the Allegro Common Lisp sources.

Verdict

A focused choice when tractable classification of large EL+-style biomedical ontologies is the priority, provided its expressivity and platform constraints match the deployment.

Sources consulted

• https://julianmendez.github.io/cel/
• Local fetched source: sources/cel.txt

cwm

What it is cwm is a general-purpose Semantic Web data processor and forward-chaining reasoner for querying, checking, transforming, and filtering information. Its core language is RDF extended with rules, using RDF/XML or RDF/N3 serializations, and it is written in Python as part of SWAP.

Key concepts It can load and emit RDF/XML or N3, apply N3 rules, filter query results, pretty-print data, and generate arbitrary formats. Built-ins cover math, strings, web document access, command-line and environment inputs, cryptographic operations, and some database access.

How you’d use it Use the command-line tool to combine RDF data and N3 rules, derive results by forward chaining, filter them to a query, and serialize the output. The page positions it primarily for prototyping Semantic Web applications.

LLM angle none stated

Pitfalls & lessons Untrusted rules can read web or confidential data, leak information through URIs, and consume processor time or memory. The software is explicitly not guaranteed or made for production use, and its main RDF/XML parser omits some obscure syntax cases.

Verdict A flexible rule-driven RDF/N3 processing workbench for prototypes, with unusually clear warnings against trusting rules or treating it as production-grade.

Sources consulted

• https://www.w3.org/2000/10/swap/doc/cwm.html

ELK

• What it is — ELK is a Java-based ontology reasoner for the OWL 2 EL profile. It implements a polynomial-time, goal-directed consequence-based procedure for a fragment of OWL 2 EL and emphasizes concurrent, incremental reasoning and derivation explanations.
• Key concepts —
  • Classification and class hierarchies: ELK can classify an ontology and produce a taxonomy; class hierarchies are one of the reasoning results it can update.
  • Incremental reasoning: after ontology axioms change, ELK recomputes only results that depend on those axioms, which can make class-hierarchy updates nearly real time in many cases.
  • Concurrent reasoning: it can use multiple processor cores to accelerate reasoning-result computation.
  • Explanations: it can show, step by step, how a logical consequence follows from ontology axioms.
• How you’d use it — Run the standalone Java CLI to classify an ontology and save its taxonomy (java -jar elk.jar -i pizza.owl -c -o pizza-taxonomy.owl); use the elk-owlapi Maven dependency through the OWL API OWLReasoner interface for Java integration; or install the ELK reasoner plug-in in Protégé. The standalone parser accepts OWL 2 Functional-Style Syntax, and the packaged CLI documents -h for its available options.
• LLM angle — none stated
• Pitfalls & lessons — ELK’s documented procedure covers a fragment of OWL 2 EL rather than unrestricted OWL. The standalone CLI cannot parse RDF/XML and accepts only OWL 2 Functional-Style Syntax, so other OWL formats must first be converted (the documentation suggests Protégé); larger classifications may also require increasing the Java heap.
• Verdict — A focused OWL 2 EL reasoner suited to fast classification, incremental updates, and explainable consequences through CLI, OWL API, or Protégé workflows.

Sources consulted

• README.md
• elk-distribution-parent/elk-distribution-cli/src/main/resources/README.txt
• elk-distribution-parent/elk-distribution-owlapi/src/main/resources/README.txt
• elk-distribution-parent/elk-distribution-protege/src/main/resources/README.txt
• elk-distribution-parent/elk-distribution-resources/src/main/resources/README.md

FaCT++

What it is FaCT++ is presented as a new generation of the FaCT OWL-DL reasoner. It retains established FaCT algorithms while changing the internal architecture, adding optimizations and features, and using C++ for efficiency and portability.

Key concepts OWL-DL reasoning; FaCT algorithms; C++ implementation; revised internal architecture; optimizations; binary and source distributions; DIG build support.

How you’d use it Download a binary or build the GNU-licensed source with a C++ compiler and GNU make; a DIG build additionally requires the Xerces-C++ XML parsing library.

LLM angle none stated

Pitfalls & lessons Building requires a C++ toolchain and GNU make, and DIG support adds a Xerces-C++ dependency. The fetched page directs source and binaries to a Google Code URL, so its distribution pointer may require verification before relying on it.

Verdict A C++ OWL-DL reasoner aimed at improved efficiency and portability, but the landing page’s build and download guidance appears dated.

Sources consulted

• http://owl.man.ac.uk/factplusplus/

HermiT

What it is HermiT is an open-source reasoner for OWL ontologies, based on a hypertableau calculus and released under the LGPL. Given an OWL file, it can check consistency, identify class subsumption relationships, classify ontologies, and answer queries.

Key concepts The site emphasizes OWL 2 direct semantics and says HermiT passes all OWL 2 conformance tests for direct-semantics reasoners. The documented release is HermiT 1.3.8, built on OWL API 3.4.3, with command-line, Protégé plug-in, and Java OWLReasoner integration paths plus support for DL Safe rules.

How you’d use it Use the command-line interface for common tasks such as classification and query answering, install its JAR as a Protégé plug-in, or embed it in Java through the OWL API’s OWLReasoner interface.

LLM angle none stated

Pitfalls & lessons The documented OWL API compatibility excludes 3.0.x, and Protégé alpha/beta versions require different HermiT lines. Reasoning with DL Safe rules is incomplete when the ontology has property chains or transitivity axioms and rule bodies use complex properties; nightly builds are experimental and not guaranteed to work.

Verdict A standards-focused OWL 2 reasoner with several practical integration modes, accompanied by explicit compatibility and rule-reasoning limits.

Sources consulted

• http://www.hermit-reasoner.com/

Hoolet

What it is

Hoolet is a prototype OWL-DL reasoner that translates an ontology into first-order axioms and sends them to a first-order prover for consistency checking. Its implementation uses the WonderWeb OWL API for parsing, Vampire for reasoning, and TPTP as the communication format; it was also extended to translate SWRL rules.

Key concepts

• OWL-to-first-order axiom translation.
• Consistency checking through Vampire, with TPTP allowing other compatible theorem provers in principle.
• Optional RDF-encoded SWRL rule sets activated alongside an ontology.

How you’d use it

On Linux, unpack the prototype, run hooletGUI, load an OWL ontology URL and optionally a rules URL, activate selected rules, and issue queries from the Query panel. Inputs are expected as OWL RDF/XML and rules as RDF using the proposed SWRL schema.

LLM angle

none stated

Pitfalls & lessons

The authors explicitly call the translation naive, say it is highly unlikely to scale, and position Hoolet for small illustrative examples rather than effective reasoning. The bundled prototype is Linux-only, loading an ontology clears current rules, rule class atoms must be named classes, and Hoolet’s performance should not be treated as evidence about Vampire’s general performance.

Verdict

Useful as a small-scale demonstrator of OWL/SWRL translation into first-order theorem proving, not as a scalable production reasoner.

Sources consulted

• http://owl.man.ac.uk/hoolet/

HyLAR

• What it is — HyLAR is a hybrid, location-agnostic, rule-based incremental reasoner for the Web. It combines an rdfstore.js triplestore with an incremental reasoning engine and can run as an npm module, a browserified client, or a server.

• Key concepts —

  • Ontologies are loaded and classified before being queried with SPARQL; loading can replace the knowledge base or retain its existing values.
  • Entailment covers RDFS and a documented subset of OWL 2 RL.
  • Custom business logic is expressed as forward-chaining conjunctive rules: one or more cause triples imply a consequence triple. Rule terms can be variables, URIs, or literals, and predicates can also be comparison operators.
  • The Triple Storage Manager separates direct triplestore operations from inferencing: its query() delegates to rdfstore.js and does not infer at that level.

• How you’d use it — Install hylar through npm, instantiate Hylar, call load(rawOntology, mimeType, keepOldValues), then issue SPARQL with query(). The main API documents Turtle, N3, and JSON-LD input; the storage-manager documentation also describes RDF/XML conversion to Turtle. Add or remove named custom rules with parseAndAddRule() and removeRule(). For deployment, generate a browser bundle with npm run clientize, or install the global server and use its classify, query, and rule endpoints; server options select RDFS versus OWL 2 RL entailment and incremental versus tag-based reasoning, with tag-based reasoning providing proofs.

• LLM angle — none stated

• Pitfalls & lessons — HyLAR supports only a subset of OWL 2 RL and RDFS. OWL 2 RL axiomatic triples are not yet supported, while RDFS axiomatic support excludes axioms related to rdf:Seq and rdf:Bag. Direct queries through the Triple Storage Manager bypass inferencing.

• Verdict — A practical JavaScript reasoner when you need incremental RDFS or partial OWL 2 RL entailment, SPARQL access, and custom forward rules across local, browser, or server deployments.

Sources consulted

• README.md
• github-pages/main.md
• github-pages/stor.md

jcel

• What it is — jcel is a Java reasoner for description logics in the EL family, described specifically as an EL+ / OWL 2 EL reasoner. It computes consequences from axioms and supports ontology classification and entailment through an OWL API interface, a Protégé plug-in, or a standalone application.

• Key concepts —

  • Description logics are presented as knowledge-representation languages and as formal foundations of the Semantic Web; a reasoner derives consequences from a set of axioms.
  • The documented operational fragment includes EL with general concept inclusions (top, conjunction, existential restriction, and subsumption), bottom, role hierarchies, transitive roles, and role composition.
  • Classification translates OWL API axioms into integer-based jcel axioms, detects expressivity, normalizes axioms (creating auxiliary entities when needed), saturates object-property deductions, applies completion rules to a fixed point, removes auxiliaries, and builds a graph of direct parents, children, and equivalent concepts.
  • The architecture separates all supported axioms and normalization from normalized axioms, classification algorithms, the reasoner, OWL API translation, and Protégé integration.

• How you’d use it — Use jcel as a Protégé plug-in, standalone application, or Java library. The documented Maven dependency is de.tu-dresden.inf.lat.jcel:jcel-owlapi:0.24.1; the standalone example invokes a JAR with --ontology, --output, and --loglevel, and the repository includes an OWL RDF/XML example ontology. The README also points to OWL and KRSS inputs and inferred XML outputs for several biomedical ontologies.

• LLM angle — none stated

• Pitfalls & lessons — The README explicitly says OWL 2 EL support currently has limitations. The FAQ marks inverse roles, functional roles, ABox assertions, and nominals as experimental; concrete predicates are planned; universal restrictions, disjunction, negation, and qualified or unqualified number restrictions are not planned. The release notes list version 0.25.0 as unreleased and version 0.24.1 (2017-04-28) as the latest dated release.

• Verdict — A focused EL-family ontology reasoner with clearly documented normalization/completion architecture and OWL API, Protégé, standalone, and library entry points, but with an explicitly bounded expressivity profile.

Sources consulted

• docs/README.md
• docs/faq.md
• docs/RELEASE-NOTES.md
• docs/data/start-jcel.sh.txt
• docs/data/example.owl

Openllet

• What it is — Openllet is an open-source, Java-based OWL 2 DL reasoner. Its documented capabilities are ontology consistency checking, taxonomy/class-hierarchy classification, entailment checking, inference explanations, and SPARQL or SPARQL-DL query answering through Jena, OWL API, or its command-line interface.

• Key concepts —

  • Reasoning services include deciding whether an ontology is consistent, finding unsatisfiable concepts, computing a class hierarchy (optionally with instances), checking whether axioms are entailed, and explaining inferences.
  • Pellint distinguishes axiom-level modeling patterns from patterns established across a whole ontology. It teaches that general concept inclusions, large disjunctions, large cardinalities, interacting existential restrictions, and large DifferentIndividuals sets can create nondeterminism, generated individuals, or high memory use in tableau-based reasoning.
  • Some constructs can also produce unintended entailments: for example, defining a named class as equivalent to an allValuesFrom restriction may classify things with no value for that property under the named class.

• How you’d use it — Add the openllet-owlapi or openllet-jena Maven dependency and invoke the reasoner from Java, or run openllet.sh help to discover CLI operations for consistency, unsatisfiable concepts, hierarchy display, and SPARQL-DL queries. Pellint accepts an ontology file or URI, can limit analysis to the root ontology or to RDF/OWL checks, can check RDF/XML resource typing, and can write selected repairs to a new ontology with -f.

• LLM angle — none stated

• Pitfalls & lessons —

  • The README says the project needs “a lot more tests.”
  • Since 2.6.5, Java 11 is required; migration also renamed many com.clarkparsia.* / com.mindswap.* packages into openllet.* and changed typing substantially.
  • The documented Protégé plugin requires a Protégé version using OWL API 5.1.x and is not compatible with Protégé’s main branch.
  • Pellint explicitly warns that its repairs are not semantically equivalent to the constructs they replace; they are intended only to improve reasoning time.
  • The authors caution that GCIs, disjunctions, large cardinalities, existential expansion, and many different-individual assertions can make reasoning time or memory intractable; several Pellint findings are warnings only and require remodeling the ontology.

• Verdict — A practical Java OWL 2 DL reasoning toolkit for classification, consistency, entailment, explanations, querying, and ontology-performance linting, with documented compatibility and scalability cautions.

Sources consulted

• README.md
• misc/doc/index.html
• tools-cli/README.md
• tools-pellint/README.txt
• tools-pellint/PATTERNS.txt
• tools-profiler/README.md

OWL-RL

• What it is — OWL-RL is a simple RDFLib-based implementation of the OWL 2 RL profile plus basic RDFS inference. It computes inference by forward chaining and can run RDFS and/or OWL-RL reasoning.

• Key concepts —

  • OWL 2 RL reasoning is presented as rule-based inference over RDF graphs; RDFS inference is also supported.
  • A deductive closure expands a graph with inferred triples, with an optional destination named graph for those results.
  • The documentation exposes datatype handling for XSD and RDF literal datatypes, including conversions for numeric, temporal, URI, binary, XML, HTML, language-tag-like, and string forms.

• How you’d use it — Install owlrl from PyPI with pip or Poetry; it requires RDFLib 7.6.0 or newer. In Python, pass an RDFLib Graph or Dataset to owlrl.DeductiveClosure(...).expand(...); with the oxigraph extra, the same closure entry points accept a PyOxigraph in-memory Store. The package also ships a local scripts/owlrl file-to-RDF/stdout command and an adaptable CGI service.

• LLM angle — none stated

• Pitfalls & lessons — The Oxigraph integration is for compatibility, not speed: conversion to and from RDFLib objects removes most of Oxigraph’s performance benefit, and inference still uses RDFLib types and logic internally. The CGI script may need adaptation to the local server setup. The dedicated Sphinx installation and usage pages are still marked “Coming soon.”

• Verdict — A narrowly scoped forward-chaining choice for materializing OWL 2 RL and RDFS inferences in RDFLib-oriented Python workflows.

Sources consulted

• README.md
• docs/source/index.rst
• docs/source/installation.rst
• docs/source/usage.rst
• docs/source/indices_and_tables.rst
• docs/source/stubs/owlrl.__index__.rst
• docs/source/stubs/owlrl.DeductiveClosure.rst
• docs/source/AxiomaticTriples.rst
• docs/source/AxiomaticTriples_source.rst
• docs/source/Closure.rst
• docs/source/CombinedClosure.rst
• docs/source/DatatypeHandling.rst
• docs/source/DatatypeHandling_source.rst
• docs/source/OWLRL.rst
• docs/source/OWLRLExtras.rst
• docs/source/RDFSClosure.rst
• docs/source/RestrictedDatatype.rst
• docs/source/XsdDatatypes.rst
• docs/source/XsdDatatypes_source.rst

Pellet 2

• What it is — Pellet is an open-source, pure-Java OWL 2 DL reasoner. Its documented scope includes ontology consistency checking, taxonomy classification, entailment checking, inference explanations, and SPARQL/SPARQL-DL query answering; the repository offers it under AGPL or a commercial license.

• Key concepts —

  • Consistency and satisfiability: check whether an ontology is consistent and find unsatisfiable concepts.
  • Classification: compute or display the class/taxonomy hierarchy, optionally including instances.
  • Entailment and explanation: test entailments and explain inferred results.
  • Ontology querying: answer SPARQL-DL queries over OWL ontologies.

• How you’d use it — Run the bundled command-line interface, beginning with pellet.sh help, to check consistency, find unsatisfiable concepts, display hierarchies, or issue SPARQL-DL queries. Java applications can integrate Pellet through either Jena or the OWL API; the guide says the two packages provide almost equivalent functionality. A prebuilt distribution includes required libraries, while repository builds use Ant; SWOOP is named as a GUI that uses Pellet for reasoning.

• LLM angle — none stated

• Pitfalls & lessons — The repository-local FAQ contains no answers and redirects readers to an online FAQ for the latest version. The bundled guide documents a Java 1.5-compatible JVM, Ant 1.5+, and a Subversion-oriented build workflow; the README also cautions that Pellet 3.0 is a separate closed-source next-generation version embedded in Stardog.

• Verdict — A focused Java reasoner for OWL 2 DL validation, classification, explanation, entailment, and semantic querying through CLI, Jena, or OWL API integrations.

Sources consulted

• README.md
• doc/index.html
• doc/FAQ.txt

pyfactxx

• What it is — pyfactxx provides Python bindings that connect the C++ FaCT++ reasoner to RDFLib. FaCT++ is an open-source reasoner for the SROIQ(D) description logic with simple datatypes (OWL 2).
• Key concepts — FaCT++ represents ontologies as terse directed acyclic graphs through atomic decomposition and applies a tableaux decision procedure for SROIQ(D). The README highlights normalization, synonym replacement, absorption, cycle elimination, backjumping, semantic branching, model merging, and taxonomy clustering among its optimization heuristics. Persistent reasoning saves inferred information and internal state for later reload, while incremental reasoning identifies change-affected inferences and recomputes only a subset.
• How you’d use it — Install with pip install pyfactxx; create a coras.Coras instance, load an ontology (the example uses Turtle), call parse() and realise(), then query through the unified SPARQL access point. The package also exposes the C++ interfaces RDFLib needs through the coras interface and adds improved individual precaching.
• LLM angle — none stated
• Pitfalls & lessons — OWL 2 reasoning has double-exponential worst-case time complexity, motivating the documented persistent and incremental modes. The linked work on direct C++ usage is explicitly described as unmaintained.
• Verdict — A focused RDFLib-facing route to optimized OWL 2/SROIQ(D) reasoning, including SPARQL access and persistence/incremental-reasoning support.

Sources consulted

• README.md

Racer

What it is

Racer is a freely available knowledge-representation system implementing an optimized tableau calculus for the description logic SHIQ(D). It succeeds RacerPro and supports standard reasoning over T-boxes and A-boxes as well as non-standard services such as logical abduction.

Key concepts

Its nRQL conjunctive query language supports features including negation as failure, numeric constraints across individuals’ attribute values, and substring relations between string attributes. Racer exposes reasoning services through Common Lisp and Java APIs and is also available as open source on GitHub.

How you’d use it

Install it through Quicklisp with (ql:quickload "racer"), then use its reasoning and nRQL query facilities from Lisp or Java. The page recommends Portacle as a host environment and describes a Portacle-based setup.

LLM angle

none stated

Pitfalls & lessons

The page says Racer requires ASDF 2.32 and gives an additional encoding setting for LispWorks. Its Portacle setup also includes platform-specific configuration, including a macOS quarantine command and memory-related Lisp settings.

Verdict

A feature-rich description-logic reasoner for T-box/A-box inference and expressive querying, especially suited to users comfortable with its Lisp-centered installation path.

Sources consulted

• https://www.ifis.uni-luebeck.de/~moeller/racer/

Whelk

• What it is — Whelk is an OWL reasoner based on the algorithm implemented by ELK. It represents reasoning state as an immutable functional data structure: adding axioms creates a new state while references to earlier states remain unchanged.

• Key concepts —

  • OWL EL classification is the core reasoning capability; Whelk also provides OWL RL and a subset of SWRL for reasoning over individuals.
  • Its persistent reasoner states support preclassifying and storing a shared ontology TBox, then independently extending it with multiple axiom sets such as ABoxes or rolling back to an earlier state.
  • Documented reasoning features include object-property-assertion materialization, SWRL class and object-property atoms, ABox-oriented OWL RL features, extended Self restrictions for rolification, and limited classification of unions in superclass position, such as inferring a common superclass of the union operands.

• How you’d use it — Use Whelk from application code when submitting many description-logic queries, running queries concurrently without blocking, or branching multiple reasoning workloads from a saved TBox classification. A basic OWL API OWLReasoner implementation is included, but the documented preferred route for its immutable-state features is the Scala API.

• LLM angle — none stated

• Pitfalls & lessons —

  • ELK is much faster for ordinary classification of a single ontology; Whelk targets workloads that benefit from persistent states, parallel queries, or its additional ABox/rule features.
  • Classification involving unions in superclass position is explicitly not guaranteed to be complete.
  • The project is under development and its Scala API is in flux; the OWL API interface is described as basic.

• Verdict — A specialized OWL reasoner for immutable, branchable, concurrent reasoning workloads and selected ABox/SWRL features, rather than a speed-first replacement for ELK on basic single-ontology classification.

Sources consulted

• README.md

A List of Ontology Engineering Tools (Ontology Editors)

What it is This is an archived directory of ontology-engineering tools and their websites. The captured page labels itself “A List of Ontology Engineering Tools (Ontology Editors)” and reports a last update of April 24, 2008.

Key concepts The content is a long name-and-link inventory spanning editors, workbenches, servers, converters, plug-ins, browsers, and related semantic tooling. Listed examples include Protégé, SWOOP, TopBraid, OBO-Edit, Ontolingua, and OWL plug-ins for editors and IDEs.

How you’d use it Use it as a historical index for discovering tool names and archived project URLs, then investigate any candidate separately before relying on it.

LLM angle none stated

Pitfalls & lessons The page provides links rather than evaluations, capabilities, compatibility details, or maintenance status. Because its stated last update is from 2008 and the consulted copy is a Wayback Machine capture, the list does not establish that any linked tool remains available or suitable.

Verdict A useful snapshot of the ontology-editor ecosystem circa 2008, but too old and too lightly annotated to serve as a current buying or adoption guide.

Sources consulted

• https://web.archive.org/web/20170827085837/http://www.hozo.jp/OntoTools/

Apollo

What it is Apollo was a Java-based, user-friendly knowledge-modeling application designed for varied knowledge-representation needs. Its internal frame-system model followed the OKBC protocol and was built from classes, instances, functions, and relations.

Key concepts Apollo performed full consistency checks during editing, supported an open view-based interface, and separated storage formats through I/O plug-ins. Its main window paired an ontology view of objects and ontology hierarchies with a focus view of the selected object and related objects.

How you’d use it Use the editor to construct and inspect a frame-based knowledge base, create anonymous instances through a dedicated dialog, and add new perspectives as views. The listed export plug-ins target CLOS and OCML.

LLM angle none stated

Pitfalls & lessons The source presents Apollo in an archived research summary and consistently describes it in the past tense. The only storage-format plug-ins named on the page are exports to CLOS and OCML.

Verdict Historically notable as an extensible, consistency-checking frame editor, but the consulted page documents it as archived research rather than a current tool.

Sources consulted

• http://apollo.open.ac.uk/

Eddy

• What it is — Eddy is a cross-platform graphical editor for specifying and visualizing Graphol ontologies. Its PyQt5/Qt5 design environment centers on a drawing viewport, with docked widgets for editing, navigation, and diagram inspection, plus design-time syntax validation that color-codes invalid expressions.

• Key concepts —

  • Graphol is a visual language for Description Logic ontologies intended to make ontologies understandable without requiring users to work in complex textual syntax.
  • Its graphical primitives are inspired by Entity–Relationship diagrams, so ontologies that can be rendered as ER diagrams retain a similar diagrammatic shape.
  • Eddy validates Graphol expressions while they are being designed. The README describes OWL 2 QL and RL profile support and marks OWL 2 EL support as “to appear”; these profiles are less-expressive OWL 2 fragments against whose syntax validation can run.

• How you’d use it — Draw and inspect a Graphol ontology in the desktop editor, choose an OWL 2 profile for profile-specific validation, and export the result as an OWL 2 ontology for third-party reasoners or editors such as Protégé; PDF export is also provided. The simplest installation is a bundled GitHub release, while PyPI/source installs require Python 3.9+ and Java 11+; launch those with eddy or python3 -m eddy.

• LLM angle — none stated

• Pitfalls & lessons — The documentation recommends a virtual environment because system Python packages can introduce dependency-version conflicts. A non-standard Java installation may require JAVA_HOME, and automatic JDK detection can fail. PyQt5 installation may hang when pip cannot find a wheel and starts a source build at a license prompt; source compilation can take a long time, particularly on platforms such as aarch64 Linux. Standalone Linux tarballs are deprecated in favor of AppImage or PyPI because AppImage builds are described as more reliable across distributions.

• Verdict — A focused visual Graphol authoring and validation tool whose documented interoperability path is OWL 2 export to the broader ontology-tool ecosystem.

Sources consulted

• README.md
• docs/install.md
• docs/dev.md
• docs/contributing.md

ELOT

• What it is — ELOT is a literate ontology-engineering environment in which one plain-text Org notebook is both the ontology source and its documentation. It has an Emacs reference implementation, a VS Code extension, and an editor-independent CLI; the README says it has been used in scores of ontology projects, including ISO 23726-3.

• Key concepts —

  • The document outline carries formal meaning: headlines declare classes, properties, and individuals, while nesting expresses subclass or subproperty hierarchy.
  • Description-list rows attach annotations and OWL axioms, with axiom values written in Manchester Syntax; annotations can themselves be attached to annotations and axioms.
  • One source file may declare multiple ontologies. Under an Individuals section, an inherited and overridable ELOT-subheading-relation can make immediate-parent nesting assert relations such as skos:broader, so the outline is also the source of a SKOS hierarchy.
  • Identifier policy belongs to each ontology rather than to ELOT globally: documented schemes include UUIDs, label-derived slugs, formatted counters, and ACME identifiers, and custom schemes can be registered.
  • Queries, diagrams, prose, and formal content can live together: SPARQL SELECT/CONSTRUCT blocks and rdfpuml/PlantUML output form part of the same document.

• How you’d use it — Author an .org file in Emacs or VS Code, insert an ontology header and skeleton, then add resource headings and description-list axioms. Tangle Org to OWL Manchester Syntax, optionally use ROBOT to produce Turtle and perform ontology operations, import existing OWL into Org with the Java/OWLAPI elot-exporter, and export documentation to HTML or other Org/Pandoc formats. Emacs additionally runs in-place SPARQL and rdfpuml diagrams; elot-cli supplies Org-to-OWL, HTML export, and shared SQLite label-index management outside an editor. Label display, lookup, hover details, and cross-references help work with opaque CURIEs.

• LLM angle — The optional Emacs elot-gptel integration lets an LLM inspect resources and conventions, search labels, lint, query with SPARQL, run ROBOT-backed consistency/unsatisfiability/explanation checks, mint policy-compliant identifiers, and edit or restructure ELOT files. File writes are project-scoped, disabled by default, confirmation-gated, and revalidated with rollback; semantic reasoning remains a separate check from the automatic lint-and-parse validation. ROBOT is optional but required for conversion, SPARQL, reasoning, and report tools.

• Pitfalls & lessons —

  • The long-form manual is explicitly under construction; several manual files are stubs or drafts and may be inaccurate. The documentation status page identifies the root README and the gptel, toolsheet, and identifier documents as reliable.
  • Emacs is the reference implementation and receives features first; the documented VS Code matrix marks SPARQL, AI-assisted authoring, and diagrams as planned rather than available.
  • elot-exporter requires Java 21 or newer, while ROBOT and diagram tooling are separate optional dependencies.
  • Automatic LLM mutation validation checks lint and OWL parsing, not semantic consistency; run the separate consistency check after edits. A newly minted CURIE also cannot be used as an axiom subject in the same batch, so insertion and axiom editing require two calls.
  • Numeric-only counter identifiers are technically invalid XML NCNames, so an alphabetic counter template is recommended. ACME slugs are lossy and have finite per-slug/day random entropy; labels, not CURIEs, should carry human-readable meaning.

• Verdict — A strong fit when an ontology team wants a version-control-friendly Org document to be the shared source for OWL structure, explanatory prose, queries, diagrams, and guarded LLM-assisted editing, especially in Emacs.

Sources consulted

• README.md
• documentation/README.org
• documentation/elot-gptel.org
• documentation/elot-id.org

Fluent Editor

What it is

Fluent Editor is an ontology editor centered on Controlled Natural Language, especially a restricted form of English intended to reduce ambiguity and complexity. The page presents it as compatible with OWL 2, OWL-DL, OWL-RL, SWRL, SPARQL, RDF, and CNL, and as an alternative to XML-oriented editing.

Key concepts

• A predictive editor blocks grammatically or morphologically invalid sentences and assists while the user writes Controlled English.
• Interactive diagrams can display an ontology and inspect results after materialization.
• An embedded SWRL debugger shows which rules executed during materialization and which entities were substituted.
• The ecosystem includes custom plugins and grammars, team/server collaboration, Protégé synchronization, and R access through the rOntorion package.

How you’d use it

Model a taxonomy, vocabulary, or rule set in constrained English, materialize it, and inspect the result visually. Use the debugger for SWRL behavior, the plugin to move between Fluent Editor’s meaning-focused view and Protégé’s structural view, or rOntorion for semantic processing in R.

LLM angle

none stated

Pitfalls & lessons

Controlled English intentionally restricts grammar and vocabulary rather than accepting unrestricted prose. The page notes that SWRL execution is difficult to trace, especially in larger ontologies, which motivates the debugger. Download activation requires a form and a key sent by email; free use is stated for individual developers, open-source projects, academic research, education, and small professional teams.

Verdict

A human-readable editing environment with unusually strong rule-debugging and interoperability features, best suited to users willing to work within its controlled-language constraints.

Sources consulted

• https://www.cognitum.eu/Semantics/FluentEditor/

Knoodl

What it is Knoodl was presented as a cloud-hosted Distributed Information Management System combining semantic and traditional information-management technology. Its tools covered creating, managing, querying, analyzing, collaborating on, and visualizing RDF/OWL descriptions.

Key concepts Content is organized into communities, wikis, and “Vocabularies,” where each vocabulary contains an RDF graph and gives every class, property, and instance its own page. Capabilities included ontology editing and import/export, per-ontology SPARQL endpoints, threaded discussion, permissions, remote endpoint registration, relational-to-RDF mappings, federated queries, dashboards, and ontology visualization.

How you’d use it Create a community vocabulary, edit and document its OWL resources, query its graph or registered remote endpoints with SPARQL, and turn results into tables, charts, or dashboards. The broader advertised architecture paired Knoodl with Spyder for exposing sources as RDF and Federator for querying distributed Spyders through one endpoint.

LLM angle none stated

Pitfalls & lessons The fetched material is a 2019 Wayback Machine snapshot rather than a current product page. A 2011 release notice warned that existing queries and views would no longer be accessible after that upgrade.

Verdict Historically notable as an integrated collaborative RDF/OWL workspace, but the archived source makes it unsuitable as evidence of current availability.

Sources consulted

• https://web.archive.org/web/20190703092924/http://knoodl.com/

List of ontology editors

What it is The fetched page defines ontology editors as applications that assist with creating or manipulating ontologies, commonly through one or more ontology languages. Despite this entry’s name and anchored URL, the captured Editors section describes editor capabilities rather than supplying a list of editor products.

Key concepts

• Visual navigation through a knowledge model.
• Inference engines, information extraction, and module support.
• Import and export of foreign knowledge-representation languages for ontology matching.
• Support for meta-ontologies such as OWL-S and Dublin Core.

How you’d use it Use the listed capability categories as a compact checklist when comparing an ontology editor: navigation, reasoning, extraction, modularity, interchange, matching, and meta-ontology support.

LLM angle none stated

Pitfalls & lessons The surrounding ontology-engineering section says an ontology must remain current with domain knowledge and term use, provide sufficient specificity and coverage, and support its intended use cases. The fetched Editors section itself does not enumerate tools, so it cannot ground a product shortlist.

Verdict Useful as a high-level editor-feature checklist, but not actually a list of ontology editors in the fetched content.

Sources consulted

• https://en.wikipedia.org/wiki/Ontology_(information_science)#Editors

OntoME

What it is OntoME is an ontology management environment for object-oriented structured data models. It supports building, managing, and aligning ontologies, including alignment to CIDOC CRM and compatible models.

Key concepts Classes; properties; namespaces; domains; profiles; projects; collaborative ontology creation; CIDOC CRM alignment; interoperability.

How you’d use it Create a free account to define classes and properties collaboratively for a project, align those classes with CIDOC CRM-compatible models, or browse existing ontologies through the class, property, namespace, project, and profile lists.

LLM angle none stated

Pitfalls & lessons none stated

Verdict A practical collaborative environment for creating and aligning structured ontologies, especially where CIDOC CRM interoperability matters.

Sources consulted

• https://ontome.net/

OntoStudio

What it is OntoStudio X is a lightweight, Excel-based IDE for building explainable knowledge systems with OntoBroker’s Java API and ObjectLogic capabilities. It lets engineers and domain experts model, run, query, debug, and audit active ontologies within macro-free .xlsx workbooks.

Key concepts

• ObjectLogic queries return cell values or spill into Excel dynamic arrays.
• Named intermediate objects can be reused across formulas, and a workbook can connect to multiple OntoBroker servers and ontologies.
• The bundled Java and Python bridges avoid VBA macros.
• ObjectLogic supports higher-order rules, expressive frames, parametrized relations, and built-ins; an F2 workflow opens cell content in VS Code with syntax coloring.

How you’d use it Create a manager connection to one or more OntoBroker servers, bind named ontology objects in the workbook, declare axioms and rules with worksheet functions, and run spilling queries for automatically sized result tables. Use Java or Python helpers where needed while keeping ontology artifacts and results addressable from spreadsheet cells.

LLM angle none stated

Pitfalls & lessons The described workflow depends on OntoBroker servers and targets OntoBroker 6.x for its full ObjectLogic rule support. The fetched page is a product overview rather than a compatibility, deployment, or licensing specification.

Verdict A distinctive spreadsheet-native ontology IDE for teams that want live reasoning and auditability inside Excel, provided their stack is centered on OntoBroker and ObjectLogic.

Sources consulted

• https://semafora-systems.com/technology/ontostudio-x/

OWLGrEd

What it is OWLGrEd presents itself as a graphical ontology editor intended to make ontologies easier to see and edit. Its site emphasizes whole-ontology visualization and usability for people who are not ontology specialists.

Key concepts Whole-ontology graphical views; configurable inclusion of OWL entity types; automatic-layout adjustment; customizable graphical style; image export.

How you’d use it Open an ontology in the desktop editor, choose which OWL entity types to visualize, adjust the automatic layout and graphical styling, then export the refined view as an image for documentation or a web page.

LLM angle none stated

Pitfalls & lessons The fetched landing page does not state supported OWL versions, import/export ontology formats, reasoning capabilities, platform requirements, or behavior on large ontologies.

Verdict A visually oriented editor whose clearest value is seeing, adapting, and sharing an ontology diagram without working through long text files one item at a time.

Sources consulted

• http://owlgred.lumii.lv/

Protégé

What it is Protégé is a free, open-source OWL ontology editor for building and managing ontologies. It is available as a local desktop application and as WebProtégé for collaborative browser-based editing.

Key concepts OWL 2; ontology modelling; reasoning and querying; collaboration; Java plug-in architecture; desktop and web editing.

How you’d use it Use Protégé Desktop for local ontology development or WebProtégé when multiple people need browser-based collaboration, carrying a model from initial authoring through reasoning and querying.

LLM angle none stated

Pitfalls & lessons none stated

Verdict A mature, extensible editor covering the full OWL 2 ontology-development lifecycle, with a clear choice between local and collaborative workflows.

Sources consulted

• https://protege.stanford.edu/

SWOOP

• What it is — SWOOP v2.3 beta 3 is an OWL ontology browser and editor built around a standard web-browser UI paradigm, including an address bar, history, bookmarks, and hypertext navigation. It can load multiple web-based ontologies and render ontologies, classes, properties, and individuals in an accessible form.

• Key concepts —

  • OWL ontologies are navigated through named entities—classes, properties, and individuals—and can include arbitrary class expressions and general concept inclusions (GCIs).
  • Integrated reasoners support subsumption and consistency checking; Pellet additionally provides explanations for unsatisfiable classes, inconsistent ontologies, and inferred assertions.
  • SWOOP supports sound-and-complete conjunctive ABox queries written in RDQL, cross-ontology search, and finding references to named OWL entities.
  • Experimental partitioning transforms an ontology into an E-connection, while Crop Circles visualizes a class hierarchy.
  • Changes are logged and can be rolled back or undone; Annotea annotations can carry and distribute ontology change sets.

• How you’d use it — Start the Java 1.4 application with runme.bat on Windows or runme.sh on Mac/Unix, using the high-memory launcher for large ontologies such as NCI. Load ontologies from the web, browse or edit entities, switch between the bundled simple RDFS-like reasoner and Pellet, query with RDQL, search across loaded ontologies, compare entities, generate HTML, or export to a remote WebDAV store. Source and editing formats include RDF/XML, OWL Abstract Syntax, and Turtle; workspaces and ontology changes can be saved in SWOOP files (*.swo, *.swp). Its plugin system supports extensions.

• LLM angle — none stated

• Pitfalls & lessons —

  • With Pellet enabled, switching ontologies can be considerably slow because classified trees are cached but reasoner results are not.
  • Nested class expressions lack a form-based editor; the documented workaround is inline RDF/XML editing.
  • Large change logs render slowly. The suggested workarounds are saving the workspace, pruning the log, disabling change logging, or turning off change rendering.
  • Datatype enumerations lack RDF/XML rendering support, so affected ontologies cannot be serialized.
  • “Show References” ignores information from imported ontologies.

• Verdict — A web-browser-style OWL editor with rich reasoning, explanation, change-management, query, and serialization features, but with explicitly documented performance and editing/serialization limitations.

Sources consulted

• readme.txt

TopBraid Composer

What it is

The fetched source does not identify or describe TopBraid Composer. The requested archive URL resolved to TopQuadrant’s current homepage, which describes the company’s AI-ready data foundation and TopBraid EDG rather than the named editor.

Key concepts

The available page emphasizes knowledge graphs, a governed context layer, semantic models, taxonomies, glossaries, metadata, reference data, and business logic. These are claims about TopQuadrant’s current platform, not evidence of Composer’s capabilities.

How you’d use it

The fetched source supports using TopQuadrant’s current offering to connect structured and unstructured information, standardize terminology, govern enterprise data, and manage taxonomies and ontologies. It does not support a grounded Composer-specific workflow.

LLM angle

none stated

Pitfalls & lessons

The source/target mismatch is decisive: the fetched URL is https://www.topquadrant.com/, not the requested archived Composer page. Composer-specific features, availability, and usage should not be inferred from this page.

Verdict

Insufficient source evidence to evaluate TopBraid Composer; refetch a Composer-specific archived page before treating this as an editor note.

Sources consulted

• https://archive.topquadrant.com/products/topbraid-composer/

VocBench

What it is VocBench is a free, open-source, web-based platform for multilingual collaborative management of OWL ontologies, SKOS/SKOS-XL thesauri, OntoLex-lemon lexicons, and generic RDF datasets. Its business and data-access layers are implemented by the open-source Semantic Turkey platform.

Key concepts Collaborative editing; multilingual resources; OWL; SKOS and SKOS-XL; OntoLex-lemon; RDF datasets; thesauri, code lists, and authority resources; Semantic Turkey.

How you’d use it Use its web editing environment to collaboratively maintain semantic assets—ranging from ontologies and thesauri to lexicons and arbitrary RDF datasets—in semantic-web or linked-data workflows.

LLM angle none stated

Pitfalls & lessons none stated

Verdict A flexible collaborative editor for teams that need one open platform to manage several RDF-based knowledge-organization formats, not only OWL ontologies.

Sources consulted

• http://vocbench.uniroma2.it/

WebODE

• What it is — WebODE is an extensible ontology-engineering suite built around an application server and a shared ontology access service. It was designed as a scalable, integrated workbench covering ontology-development activities such as conceptualization, reasoning, and exchange, with services that interoperate with other information systems.

• Key concepts —

  • Ontology development is presented as a process spanning conceptualization, reasoning, exchange, documentation, evaluation, evolution, learning, and merging.
  • A common ontology access service forms the workbench core and is used by applications and services plugged into the server.
  • Axioms can be edited with the WebODE Axiom Builder (WAB), while an inference engine supplies reasoning support.
  • Ontology-language exchange is supported through import and export rather than a single required representation.

• How you’d use it — Edit and browse WebODE ontologies through the HTML-form- and Java-applet-based Ontology Editor, then use plugged-in services for axioms, documentation, evaluation, evolution, learning, merging, and inference. Import or export XML, RDF(S), OIL, DAML+OIL, OWL, CARIN, FLogic, Jess, or Prolog; running the suite requires JDK 1.6 and the Resin webserver.

• LLM angle — none stated

• Pitfalls & lessons — Support was discontinued in 2006, and the repository marks the project unsupported: it is stable and usable, but its authors have ceased work and a new maintainer may be needed. Its documented runtime and editor depend on JDK 1.6, Resin, HTML forms, and Java applets.

• Verdict — A historically broad ontology-engineering workbench with extensive lifecycle and format support, but explicitly discontinued and unsupported.

Sources consulted

• README.md

LODE

What it is LODE 2.0 is an open-source service that extracts entities and textual definitions from semantic artifacts and renders browsable, linked HTML documentation. It can produce live documentation for browsing or a ZIP containing a static site, RDF serializations, and stylesheets for deployment.

Key concepts /extract returns HTML or Turtle, RDF/XML, or N3, optionally scoped to one resource; /build creates one HTML page per resource plus serializations and stylesheets. Options cover annotation language, structural warnings, direct imports or their transitive closure, URL caching, file upload, and content negotiation between human-readable pages and raw ontology files.

How you’d use it Submit an ontology URL or supported local RDF file to generate documentation, enable warnings or imported axioms as needed, and use /build for a one-off static bundle. For CI/CD or GitHub Actions, install LODE locally and run lode build instead of automating the web /build endpoint.

LLM angle none stated

Pitfalls & lessons Despite the service’s broader semantic-artifact description, the implementation-status section says only read_as=owl is currently enabled; RDF/RDFS and SKOS modes return errors. URL results may come from a four-hour cache unless cache=false, and specifying both imported and closure gives precedence to imported.

Verdict A useful publishing utility for turning OWL artifacts into navigable live or static documentation, with clear current limits outside OWL.

Sources consulted

• https://essepuntato.it/lode/

OAK

What it is Ontology Access Kit (OAK) is documented as a toolkit for working with ontologies through both Python and a command line. Its documentation spans ontology access, transformation, validation, graph operations, mappings, similarity, and multiple ontology-related data models.

Key concepts CURIEs and URIs; labels, aliases, and synonyms; mappings and cross-references; relationships and graphs; adapters and triplestore backends; OboGraphs, OWL, SSSOM, KGCL, and semantic similarity.

How you’d use it Follow the Python or command-line tutorials, choose an ontology adapter/backend, then use the relevant interface, converter, utility, or how-to guide for tasks such as graph visualization, validation, applying ontology changes, similarity analysis, or cross-ontology diffing.

LLM angle The documentation lists a guide titled “How to use Large Language Models (LLMs) with OAK,” but the fetched page does not state any method or capability from that guide.

Pitfalls & lessons none stated

Verdict A broad ontology utility layer with both library and CLI entry points, especially promising when one workflow must span several formats, backends, or ontology operations.

Sources consulted

• https://incatools.github.io/ontology-access-kit/

obonet

• What it is — obonet is a lightweight Python package for reading OBO-serialized ontologies into a NetworkX MultiDiGraph. Its parser targets OBO format specifications 1.2 and 1.4, and the project describes itself as specializing in OBO-to-NetworkX loading rather than general ontology processing.

• Key concepts — Ontology terms become graph nodes, while typed relationships become directed edges; multiple relationships between the same nodes are retained by the MultiDiGraph. Traditional ontology edges such as is_a run from subterm to superterm, so in this representation NetworkX descendants returns superterms and ancestors returns subterms. The tutorial demonstrates node properties, ID/name mappings, parent and child relationships, all paths to a root, ontology-level metadata, and obsolete-term replacement via replaced_by.

• How you’d use it — Call obonet.read_obo() with a local path, URL, or open file handle; compression is inferred from the path extension. Analyze the returned graph with NetworkX—for example, count nodes and edges, check whether it is a DAG, traverse superterms/subterms, inspect properties, or enumerate paths to a root. Pass include_clauses=True to preserve parsed OBO comments and trailing modifiers, pass ignore_obsolete=False when building obsolete-to-replacement mappings, or use the CLI to convert OBO to NetworkX node-link JSON.

• LLM angle — none stated

• Pitfalls & lessons — Only reading OBO files is supported. Some ontology nodes may have an ID but no name, so mappings should access name defensively. The documented edge direction can be confusing because it makes NetworkX ancestor/descendant terminology opposite the ontology’s general/specific hierarchy. Compared with the more general nxontology/pronto route, format coverage and retained metadata differ; conversion to a plain DiGraph requires choosing relationship types, reversing edges, and collapsing parallel edges.

• Verdict — A focused choice when the job is to load OBO 1.2/1.4 data into a metadata-rich NetworkX multigraph and analyze it with standard graph operations.

Sources consulted

• README.md
• examples/go-obonet.ipynb

OnToology

• What it is — OnToology automates part of collaborative ontology development for a GitHub repository containing OWL files. When a tracked ontology changes, it generates documentation, diagrams, an evaluation report, and a JSON-LD context, then proposes the generated files in a pull request; it can also publish ontologies through GitHub Pages with a w3id.org permanent identifier.
• Key concepts — Ontology engineering artifacts can be regenerated from the ontology on every repository change and reviewed before merging. The documented artifact set includes HTML documentation, class and taxonomy diagrams, an OOPS! evaluation based on common pitfalls, and a JSON-LD context. Publication assigns a unique reserved identifier such as https://w3id.org/def/alojamiento, while the syntax checker tests whether RDFLib can parse a supplied ontology URL in the selected serialization.
• How you’d use it — Put OWL files in a GitHub user repository, register user/reponame, authorize OnToology, and review the pull request it creates after processing. Generated resources live under a top-level OnToology directory that mirrors the repository structure; each ontology gets documentation, diagrams, evaluation, and an OnToology.cfg. Per-ontology widoco, ar2dtool, and oops sections enable or disable documentation, diagrams, and evaluation. You can also validate an ontology URL and format, download a publication bundle, or reserve a w3id and publish through the gh-pages branch.
• LLM angle — none stated
• Pitfalls & lessons — OWL functional-style syntax, GitHub organization repositories, and private repositories are not supported. Folder and file names are limited to English letters, underscores, dashes, and dots. Evaluation depends on the OOPS! web service, whose outages can prevent successful reports; publication can stall if authorization, the OnToologyUser collaborator, or gh-pages setup is missing. Generated documentation may not work when opened locally because Chrome and Firefox disable AJAX for local HTML, and large ontologies may time out in the syntax checker.
• Verdict — A GitHub-centered automation service for keeping documentation, diagrams, evaluation, JSON-LD context, and permanent publication in step with changing OWL ontologies.

Sources consulted

• README.md
• templates/stepbystep.html
• templates/faqs.html
• templates/syntax.html

Ontospy

What it is

Ontospy is a lightweight Python library and command-line tool for inspecting vocabularies encoded in RDF-family languages. It can scan RDFS, OWL, SKOS, and SHACL material, expose ontology information through Python objects, and generate documentation.

Key concepts

• It works as a Python package, direct command-line scanner, or optional interactive shell/REPL.
• Models can be loaded from files or graph URIs, then interrogated for classes, properties, SKOS concepts, SHACL shapes, and entity relationships.
• A local repository can cache ontologies for later inspection.
• Documentation output includes simple HTML, Markdown, and interactive D3.js-based visualizations; version 2 moved this facility from Django to Jinja and added SHACL support.

How you’d use it

Run ontospy scan against a graph URI for a quick terminal inventory, instantiate Ontospy in Python when an application needs schema information, or use ontospy gendocs to produce browsable ontology documentation. Cache frequently inspected vocabularies locally when repeated loading would be inconvenient.

LLM angle

none stated

Pitfalls & lessons

Ontospy explicitly does not edit ontologies. The interactive shell requires the optional readline dependency, and the version 2 internal changes may break custom extensions built around the older documentation generator.

Verdict

A focused inspection and documentation utility for people who want RDF schema visibility without opening a full ontology editor; use another tool when authoring or editing is required.

Sources consulted

• http://lambdamusic.github.io/Ontospy/

owl-cli

• What it is — This repository now documents Cool RDF, the project formed by merging and updating the former owl-cli and turtle-formatter. It provides high-level Java libraries and the cool command-line tool for formatting and converting RDF documents, diagramming OWL ontologies, and performing OWL 2 DL reasoning.
• Key concepts
  • RDF graph edges have no serialization order, so two text files can differ while representing the same RDF model; the formatter therefore enforces reproducible ordering and configurable Turtle style, especially for version-controlled artifacts.
  • OWL visualization must make semantics explicit: putting properties inside UML-like class boxes is ambiguous because a property restriction and a property domain have different meanings.
  • Because OWL has no standardized graphical notation, Cool RDF defines one intended to represent all OWL axioms meaningfully, remain familiar to Protégé users, and cover element types, data ranges, class expressions, axioms, assertions, and SWRL rules.
  • The infer operation performs OWL 2 DL reasoning over an input ontology and writes the inferred result.
• How you’d use it
  • Install Java 25 or later and run the executable JAR as cool. cool diagram ontology.ttl produces an automatically laid-out SVG by default (PNG is also supported) through Graphviz dot.
  • Use cool write to read RDF/Turtle, RDF/XML, N-Triples, or N3 from a file, URL, or standard input and emit one of those formats. Turtle output exposes controls for prefixes, ordering, indentation, encoding, literal style, blank-node IDs, and related formatting choices.
  • Use cool infer ontology.ttl - to reason over an ontology and write to standard output. Ontology-taking commands also accept OWL API formats including Turtle, RDF/XML, OWL/XML, and OWL Functional Syntax.
  • In Java, the documented cool-rdf-formatter API takes an Apache Jena Model plus a FormattingStyle and returns or streams reproducibly formatted Turtle.
• LLM angle — none stated
• Pitfalls & lessons
  • The current CLI is named cool, not owl; migration also changed the build from Gradle to Maven, moved formatter packages to cool.rdf.formatter, and raised the Java requirement to 25.
  • No native executables are currently provided, and diagram generation needs the optional Graphviz dependency.
  • cool infer overwrites a file input when no output argument is supplied; pass an explicit output or - when that is not intended.
  • The graphical notation is project-specific because OWL has no standard diagram notation, and the diagrams target documentation rather than necessarily supporting interactive ontology editing.
  • The Java API page says documentation is not yet available for some libraries; only the formatter module is described there.
• Verdict — A focused utility for reproducible RDF serialization, static OWL diagram generation, and OWL 2 DL inference, with the formatter being the documented Java integration point.

Sources consulted

• README.md
• docs/src/docs/antora/modules/ROOT/pages/index.adoc
• docs/src/docs/antora/modules/ROOT/pages/cool-cli.adoc
• docs/src/docs/antora/modules/ROOT/pages/diagram-notation.adoc
• docs/src/docs/antora/modules/ROOT/pages/java-api.adoc
• docs/src/docs/antora/modules/ROOT/pages/release-notes.adoc

OWLTools

• What it is — OWLTools is a Java library and command-line toolkit that simplifies common OWLAPI operations, especially work with annotation properties and connections between classes. Its documented scope also includes sound transitive closure over large ontologies, ontology release building, ontology-based data mining and statistics, semantic similarity, class enrichment, and an NCBI Taxonomy-to-OWL converter.

• Key concepts —

  • Direct connectivity: determine whether classes are connected by restrictions such as SubClassOf part_of some, including nested expressions, without an intermediate named object, and recover the relationship connecting them.
  • Indirect connectivity and closure: follow chains such as transitive part_of relations to obtain ancestors; the docs contrast this traversal need with repeatedly testing or pre-naming class expressions for a DL reasoner.
  • Least Common Subsumers (LCSs): semantic similarity may require an LCS that includes class expressions, not only named classes—for example, preserving a shared quality or a shared has_part restriction.
  • Semantic similarity: compare individuals by properties in common using metrics the docs name, including Jaccard similarity and information-content measures over an LCS.
  • Taxonomy modeling: the NCBI converter creates an OWL class per taxon, turns parent IDs into superclass links, uses stable OBO-style IRIs, and represents labels, cross-references, ranks, and typed synonym annotations.

• How you’d use it — Download the prebuilt executable script/JAR, make the wrapper executable if necessary, add its directory to PATH, and start with owltools -h; alternatively, build the Maven projects from a proper Git clone with mvn clean install. For NCBI Taxonomy conversion, provide the line-based taxonomy.dat input to ncbi2owl.jar and produce OWL/XML; advanced modes can also serialize axioms to text so Unix sort and diff can compare representations.

• LLM angle — none stated

• Pitfalls & lessons —

  • A source build requires Git metadata: the build embeds branch, version, and date in the JAR manifest and fails when .git is absent, so a proper Git clone is required.
  • Skipping tests with -DskipTests is explicitly marked “Not Recommended”; normally any failed test stops the build.
  • NCBI conversion is resource-heavy: the documented input exceeds 200 MB, the resulting OWL file exceeds 800 MB, and conversion needs several GB of RAM.
  • Comparing two OWL representations is described as tricky; the documented workaround is to serialize the OWLAPI axioms, sort them, and compare the sorted text.
  • Some NCBI fields (MGC ID and INCLUDES) are explicitly not handled.

• Verdict — A practical OWLAPI-based utility suite for ontology graph traversal, semantic-similarity support, release work, and large taxonomy conversion, rather than a general-purpose LLM or RAG framework.

Sources consulted

• README.md
• OWLTools-Core/README.txt
• OWLTools-NCBI/README.txt
• OWLTools-Oort/reporting/README.txt
• OWLTools-Runner/contrib/README.md

pyLODE

• What it is — pyLODE is a Python reimplementation of LODE that parses OWL/RDF with RDFLib and generates human-readable, static HTML ontology documentation. It also documents SKOS vocabularies and, through its supermodel mode, standalone or multipart models built from profiles and modules.
• Key concepts — It treats good ontology annotation as a prerequisite for good documentation and intentionally supports a conventional subset rather than translating every RDF statement. Its documented model includes owl:Ontology definitions, classes, properties, richer agent metadata, PROF profiles and resource descriptors, recursive graph closure for multipart models, lode:Module configuration, SHACL- or schema:domainIncludes-described class properties, label overrides, and vocabulary bindings to SKOS concept schemes.
• How you’d use it — Install it from PyPI and provide a local file or URL to the CLI, selecting ontpub for ontologies, vocpub for SKOS vocabularies, or supermodel for profiles/modules; output can be written as HTML, sorted, and emitted with or without embedded CSS. It is also usable as Python classes (OntPub and VocPub), a Falcon HTTP service, standalone executables, or Docker; remote ontology URLs served to the API must support RDF HTTP content negotiation.
• LLM angle — none stated
• Pitfalls & lessons — pyLODE deliberately does not render everything expressible in RDF, so unsupported patterns require a feature request and poorly annotated inputs produce poor results. A supermodel entry document must contain either an owl:Ontology or exactly one prof:Profile; imported resource descriptors are limited to Turtle, N-Triples, and N-Quads. Authors recommend keeping pyLODE-specific lode: statements out of published profiles and importing them separately with the lode:config role so downstream profiles can override documentation choices; the docs also mark configurable label predicates and downstream module disabling/ignore behavior as future or unsettled work.
• Verdict — A focused ontology-publication utility for turning conventionally annotated OWL, SKOS, PROF, and SHACL model descriptions into static HTML, not a general RDF-to-HTML renderer.

Sources consulted

• README.md
• supermodel.md

pyontutils

• What it is — pyontutils is a collection of Python utilities for maintaining ontologies in Git and making them available through SciGraph. The repository also contains related packages for deterministic Turtle serialization, NIF-Ontology workflows, SciCrunch/InterLex integration, and an OWL-backed neuron-type data model.
• Key concepts —
  • Deterministic serialization matters for ontology version control: ttlser imposes stable formatting and total ordering so Git diffs show meaningful ontology changes rather than triple reordering.
  • Neuron Lang models a neuron type as a collection of phenotypes backed by OWL 2 classes. A phenotype is an object–predicate pair expressed with a CURIE or URI; shared ontology identifiers bridge different local phenotype names and support regular, rule-based neuron names.
  • OWL modeling choices are reasoner-dependent. The documented neuron model uses classes, restrictions, intersections, phenotype subproperties, transitive partOf, and location-property chains, then checks query behavior with ELK and FaCT++.
  • CURIE/qname management, ontology identifiers, RDF lists, blank nodes, restrictions, axioms, and graph comparison are treated as practical concerns in an ontology toolchain rather than only as abstract modeling topics.
• How you’d use it — Install pyontutils from PyPI, configure its YAML files and (when needed) a SciGraph API key, then use the supplied CLIs: ttlfmt for deterministic Turtle, ontutils for common ontology operations/refactorings, ontload for loading a Git-managed ontology into SciGraph, qnamefix for qnames, scig for endpoint queries, graphml_to_ttl for yEd GraphML conversion, and ontree for hierarchy browsing. With neurondm, define Neuron values from Phenotype object–predicate pairs, search identifiers through %scig, manage reusable local names and phenotype contexts, and export Python or any RDFLib-supported serialization (with deterministic Turtle preferred).
• LLM angle — none stated
• Pitfalls & lessons —
  • The README says pyontutils is only “slowly approaching stability,” and several workflows have substantial external requirements (including Java/Maven for ontload, FSL or atlas data for parcellation, and native build dependencies).
  • ttlser documents unresolved determinism/correctness hazards: symmetric predicates must be known, duplicate prefixes can make prefix selection history-dependent, deterministic output depends on specific RDFLib changes, blank-node ranking can fail randomly, and the scottl serializer is described as broken.
  • Neuron Lang is add-only within a running graph; removing neurons requires resetting the program, so persistent notebook state can be confusing. Use outside NIF-Ontology is possible but not fully abstracted and needs additional Config setup.
  • A hasLocationPhenotype property-chain axiom is explicitly reported to break FaCT++, illustrating that an OWL design that works with one reasoner may fail with another.
  • The release documentation strongly warns never to run its destructive release functions on a working repository because stashed or untracked work can be lost; it also requires tests, TestPyPI inspection, and hash verification before release.
• Verdict — A broad, NIF-oriented ontology engineering toolbox whose strongest documented contributions are stable Turtle/Git workflows, SciGraph integration, and an executable OWL-backed DSL for neuron phenotypes.

Sources consulted

• README.md
• docs/NeuronLangExample.ipynb
• docs/release.org
• ilxutils/README.md
• librdflib/README.md
• neurondm/README.md
• neurondm/docs/NeuronLangExample.ipynb
• neurondm/docs/basic-model.org
• neurondm/docs/neurons_notebook.md
• neurondm/docs/types.org
• nifstd/README.md
• ttlser/README.md
• ttlser/docs/ttlser.md

ROBOT

What it is ROBOT is a tool for working with Open Biomedical Ontologies, available as a command-line program or as a library for JVM languages. Its Java code is divided into robot-core ontology operations and the robot-command command-line interface.

Key concepts Its documented commands cover tasks such as annotation, conversion, diffing, extraction, filtering, materialization, merging, querying, reasoning, repair, reporting, templating, profile validation, and verification. The library exposes operation classes plus IOHelper methods for loading and saving ontologies and sets of term IRIs.

How you’d use it Install Java 11 or later and run the packaged JAR through the supplied shell or batch script, or use the OBO Library Docker image. For embedded use, add the Maven artifacts or standalone JAR and compose robot-core operations—for example, loading an ontology and term list, extracting a core subset, and saving the result.

LLM angle none stated

Pitfalls & lessons The command-line installation requires both the JAR and the correct platform script on PATH. The source specifically warns that PowerShell versions before 6 write a byte-order mark that breaks the generated Windows batch file.

Verdict A broad automation surface for ontology workflows, usable both from scripts and directly inside JVM applications.

Sources consulted

• http://robot.obolibrary.org/

Tarql

What it is

Tarql is a Java command-line tool, based on Apache ARQ, that converts CSV files to RDF using SPARQL 1.1 syntax. It treats CSV contents as a table of variable bindings and commonly generates RDF with CONSTRUCT queries.

Key concepts

Header names become SPARQL variables by default, while headerless input uses ?a, ?b, and so on; ?ROWNUM exposes the non-empty input-row number. Mappings may be SELECT, ASK, or one or more consecutive CONSTRUCT queries, and the CLI supports CSV/TSV parsing controls, Turtle or N-Triples output, testing, and duplicate removal.

How you’d use it

Write a SPARQL mapping that binds tabular columns, computes IRIs or tagged literals with SPARQL expressions, and constructs the desired RDF, then run tarql mapping.sparql input.csv. Use --test to inspect the template, variables, and a few rows while developing the mapping.

LLM angle

none stated

Pitfalls & lessons

CSV and TSV inputs vary in headers, delimiters, quote/escape characters, and encodings, so configure parsing explicitly when defaults do not fit. In multi-CONSTRUCT mappings, generated triples can feed later queries, and the source warns that OPTIONAL/BIND order is significant.

Verdict

A focused bridge from tables to RDF that lets existing SPARQL skills define both transformation logic and output structure.

Sources consulted

• https://tarql.github.io/

VocPrez

• What it is — VocPrez is an archived, read-only web delivery system for RDF vocabularies formulated in SKOS. It presents vocabulary data over HTTP as human-readable pages and machine-readable representations, and the project says its functionality is now incorporated into Prez.

• Key concepts —

  • VocPrez treats a SKOS ConceptScheme as synonymous with a vocabulary and ships presentation support for SKOS ConceptScheme, Collection, and Concept, plus registers/containers of those resources.
  • It distinguishes an information-model view, defined by a formal profile, from the media format used to serialize that view; multiple profiles and multiple media types per profile are supported.
  • Its pyLDAPI foundation turns RDF data into Linked Data, exposing the same vocabulary material in human- and machine-readable forms.

• How you’d use it — Configure one or more vocabulary sources and instance details, then serve the Python/Flask WSGI application (the root README gives gunicorn wsgi:application for local use). Documented back ends include RDF databases/triplestores through SPARQL, local RDF files, Research Vocabularies Australia, VocBench3, vocabulary APIs, and GitHub; adapters populate a cached vocabulary index. Jinja2 templates produce HTML for SKOS objects, while mapping code provides RDF or other machine-readable formats, and deployments can override templates for institutional branding.

• LLM angle — none stated

• Pitfalls & lessons —

  • The repository is archived and directs users to Prez, where VocPrez has been incorporated.
  • VocPrez is a publisher, not a SKOS editor; it expects an existing configured data source.
  • It is ready for SKOS-only vocabularies; SKOS-plus-extra features require a fork or enhancement.
  • Release 2.4 changed configuration incompatibly by replacing CACHE_DIR with a required CACHE_FILE, and the 1.0 release is explicitly unsupported.

• Verdict — A focused SKOS-to-Linked-Data publishing interface with profile-aware HTML/RDF delivery, useful as documented precedent but superseded by Prez.

Sources consulted

• README.md
• docs/README.md
• docs/_coverpage.md
• docs/_media/README.md
• docs/_navbar.md
• docs/_sidebar.md
• docs/contacts.md
• docs/other/changelog.md
• docs/other/faq.md
• RELEASE_NOTES.md

WebVOWL

• What it is — WebVOWL is a browser UI for presenting ontology visualizations, with OWL2VOWL providing the conversion backend. The documented full-stack deployment combines both under one Tomcat origin, while a frontend-only deployment omits file and IRI conversion.

• Key concepts —

  • OWL2VOWL converts ontology files into VOWL-specific JSON for presentation by WebVOWL.
  • The legacy documentation names OWL, RDF, and TTL as watched ontology inputs; current operator docs demonstrate posting an RDF ontology to /convert.
  • The UI and converter are expected on the same origin because WebVOWL uses relative /convert and /serverTimeStamp endpoints.

• How you’d use it — Run the full stack with docker compose build && docker compose up -d --wait, then open http://localhost:8080; the image clones and builds OWL2VOWL and exposes /convert. A frontend-only Compose setup is available when conversion is unnecessary. For development, install Node dependencies, build with the npm/Grunt tasks, and serve deploy/; visualizations can be exported as SVG, provided the CSS-inlining code is kept synchronized with vowl.css.

• LLM angle — none stated

• Pitfalls & lessons —

  • The old visualdataweb.org URL is no longer owned by VisualDataWeb, and the legacy WAR download host is broken or compromised; the accepted Docker design builds OWL2VOWL from source instead.
  • Separating the UI and converter across two unproxied origins breaks the relative /convert integration.
  • Docker builds require network access to clone OWL2VOWL; pin OWL2VOWL_GIT_REF for reproducible releases.
  • The documented build toolchain retains end-of-life Node 12 and Java 8.
  • SVG export requires CSS rules to be inlined; changing vowl.css without regenerating the inlining code makes the exported image differ from the displayed graph.
  • The repository was migrated from internal SVN and cleaned with git filter-branch, so its commit history may contain oddities.

• Verdict — A focused browser visualization frontend with a documented OWL-to-VOWL conversion path and workable local deployment, but with a legacy toolchain and notable deployment-history hazards.

Sources consulted

• README.md
• docs/adr/README.md
• docs/adr/0001-docker-local-development.md
• docker/README.md
• doc/Docker/README.md
• util/VowlCssToD3RuleConverter/README.md

WIDOCO

• What it is — WIDOCO (WIzard for DOCumenting Ontologies) generates enriched, customizable, human-readable ontology documentation through a GUI wizard or command line. It extends LODE for term documentation and integrates WebVOWL visualization, OOPS! evaluation, Licensius license metadata, PROV-O provenance, and Bubastis-based version changelogs.
• Key concepts —
  • Keep publication metadata with the ontology as annotations when possible; the docs recommend this over a separate .properties file because embedded metadata is easier to maintain across releases.
  • Describe the vocabulary itself with stable namespace and prefix, name/title/description, creators and contributors, license, version IRI and version information, creation date, and a link to the previous version. WIDOCO uses the previous-version relation to generate changelogs and emits a W3C PROV-O-compliant provenance page.
  • Describe classes and properties with labels and definitions; optional term annotations cover examples, original source, rationale, deprecation, and status. Supported term statuses include unstable, testing, stable, and archaic.
  • Treat publication as more than an HTML page: WIDOCO supports content negotiation, multiple ontology serializations, JSON-LD snippets in generated HTML, imported-ontology handling, evaluation reports, and diagrams.
• How you’d use it — Download the release JAR and run the GUI, or invoke java -jar widoco-VERSION-jar-with-dependencies.jar with a local ontology (-ontFile) or ontology URI (-ontURI) and an output folder. Docker and Maven/JitPack dependency workflows are also documented. Customize output through ontology annotations or config.properties; useful switches include multilingual generation, WebVOWL, OOPS!, imported terms, Apache publication bundles, section replacement, and serialization display controls. Inputs shown in the docs include Turtle/OWL ontology data, while generated publication support includes HTML plus Turtle, RDF/XML, N-Triples, and JSON-LD serialization links.
• LLM angle — none stated
• Pitfalls & lessons — A separate .properties file must be maintained independently, so ontology annotations are recommended. Entity-valued creator/contributor/publisher metadata is resolved only inside the ontology; external URI resolution is not supported. Generated split-section HTML may appear incomplete when opened directly from the local filesystem because browsers block local section loading; use -uniteSections or serve the files, noting that the LODE visualization is unavailable in the local united-file case. The JAR requires Java 8 or newer.
• Verdict — A focused ontology publication utility for turning annotated ontologies into customizable, standards-aware documentation, provenance, visualization, evaluation, and version-change artifacts.

Sources consulted

• README.md
• doc/metadataGuide/guide.md
• doc/bestPractices/sections/introduction-en.html
• doc/bestPractices/sections/checklist-en.html

yamlpyowl

• What it is — yamlpyowl reads ontologies—including individuals and SWRL rules—written in YAML and represents them as Python objects through owlready2. Its goal is to make manually authored ontologies more approachable for contributors who may not know Protégé or OWL syntaxes such as Manchester, while still supporting reasoning and RDF/XML export.

• Key concepts —

  • YAML declarations cover OWL classes, object and data properties, individuals, property facts, and SWRL rules; documented property characteristics include functional and transitive roles.
  • X_RelationConcept is a yamlpyowl extension for modeling n-ary relations: subclasses represent the relation, the parser creates an associated role, and relation_concept_facts creates concrete relation instances.
  • “Proxy individuals” represent knowledge about a class when metaclasses/punning are unavailable; __create_proxy_individual can generate individuals named i<ClassName>.
  • The zebra-puzzle notebook distinguishes asserted knowledge from facts inferred after synchronizing a reasoner, then queries the inferred graph with SPARQL.

• How you’d use it — Install with pip install yamlpyowl, author an .owl.yml file, and load it with yamlpyowl.OntologyManager(path). Use the manager’s name-mapping container and underlying owlready2 ontology to access entities and relations, call sync_reasoner(infer_property_values=True) for inference, issue SPARQL via make_query, or use the installed yamlpyowl CLI to convert YAML to RDF/XML. Python 3.8+ and Java are required.

• LLM angle — none stated

• Pitfalls & lessons — Ordinary documentation does not yet exist, and the authors describe yamlpyowl as an early prototype likely to be expanded and changed. The README also says owlready2 and most OWL reasoners do not support metaclasses/punning, motivating the optional proxy-individual workaround.

• Verdict — A documented prototype for human-readable YAML ontology authoring that bridges into owlready2 reasoning, SPARQL inspection, and standard RDF/XML export.

Sources consulted

• README.md
• doc/demo_notebooks/zebra_puzzle.ipynb

Apache Jena Ontology API

What it is

The Jena Ontology API is a Java programming interface for working with RDF-backed RDFS and OWL ontologies. It provides language-neutral ontology facets and convenience methods over the RDF triples in an OntModel, with configurable language profiles, storage, and reasoning.

Key concepts

• OntModel extends Jena’s RDF Model; ontology objects do not hold separate state, and API operations read or assert underlying RDF triples.
• RDF resources can expose multiple Java facets, selected at runtime with as() and checked with canAs().
• OntSpecification selects profiles and inference recipes; models may expose asserted plus entailed triples through the same model interface.
• GraphRepository supports recursive import closure while keeping the base ontology and imported graphs separate.

How you’d use it

Create an OntModel with the required OWL/RDFS profile and reasoner, read ontology data, then create or inspect classes, class expressions, properties, individuals, annotations, and imports through Java methods. Choose the base model when only asserted statements are wanted, or an inference-enabled model when applications should query entailments too.

LLM angle

none stated

Pitfalls & lessons

The documentation assumes RDF and Jena familiarity, covers the new API introduced since Jena 5.1.0, and directs readers to Javadoc for full detail. The default model uses OWL2 DL, in-memory storage, and built-in RDFS inference; inference can add many statements, cannot be distinguished from asserted statements through the combined model, and is often undesirable in editors. Imports are not loaded by a basic read unless the model is created with the specialized repository setup.

Verdict

A practical Java layer for manipulating RDF-native ontologies with optional inference and modular imports, provided callers deliberately choose the profile, reasoning behavior, and asserted-versus-inferred view they need.

Sources consulted

• https://jena.apache.org/documentation/ontology/

FunOWL

• What it is — FunOWL is a pure-Python implementation of OWL 2 Functional-Style Syntax with a Pythonic API that stays close to the raw OWL functional model. It constructs and parses functional-syntax ontologies and can emit either OWL Functional Syntax or RDF through RDFLib. The project is no longer supported and directs users to migrate to py-horned-owl.
• Key concepts —
  • Ontologies are assembled from prefix declarations, ontology/version IRIs, imports, annotations, entity declarations, and axioms such as SubClassOf, EquivalentClasses, and ClassAssertion.
  • Class and data expressions shown in the documentation include intersections, unions, existential and universal restrictions (ObjectSomeValuesFrom, DataSomeValuesFrom, DataAllValuesFrom), and enumerated data values (DataOneOf).
  • One documented transformation turns selected classes expressed only through SubClassOf axioms into “fully defined entries” using EquivalentClasses and ObjectIntersectionOf.
  • Open-ended OWL productions are exposed with variadic Python constructors, avoiding the less natural requirement to wrap operands in a list.
• How you’d use it — Install the package and use Ontology, OntologyDocument, RDFLib Namespace objects, entity constructors, and axiom constructors to build an ontology, then call str(...) for Functional Syntax or to_rdf(Graph()) for RDF serialization. to_python accepts Functional Syntax from a string, URL, file location, or open file; the funowl CLI converts a Functional Syntax file or URL to RDF and supports RDFLib output formats including Turtle, RDF/XML, JSON-LD, N-Triples, N-Quads, TriG, and TriX.
• LLM angle — none stated
• Pitfalls & lessons —
  • FunOWL is no longer actively maintained; the authors recommend migration to py-horned-owl, citing its active maintenance, faster Rust-backed parsing/serialization, broader format support, and OWL 2 conformance testing.
  • String CURIEs such as ex:X and :Y are stored as opaque strings rather than expanded; the migration guide recommends RDFLib Namespace values when using FunOWL so IRIs expand immediately.
  • FunOWL has no built-in method to retrieve all classes; its documented access path is the ontology’s axiom collection.
  • The README says RDF-oriented Python OWL generation is time-consuming and error-prone, and notes that RDFLib’s infixowl was close enough to the intended capability that the authors might have built on it instead of starting from scratch had they known about it.
• Verdict — A close-to-the-spec Python model and converter for OWL 2 Functional Syntax, useful for understanding or migrating existing FunOWL workflows but not a sound choice for new maintained work.

Sources consulted

• README.md
• docs/index.md
• UseCase.md
• ImplementationNotes.md
• MIGRATION_GUIDE.md

Horned OWL

• What it is — Horned OWL is a Rust library for processing and manipulating OWL documents inside Rust applications. It supports OWL 2 and SWRL, targets ontologies with millions of terms, and describes preliminary validation benchmarks as potentially 20–40× faster than competing OWL API-based implementations.
• Key concepts —
  • OWL 2 is the core ontology language, with profile reporting for EL, QL, RL, and DL.
  • SWRL rules are supported alongside OWL 2 ontologies.
  • Ontologies can import other ontologies; the materialize tool downloads and resolves an ontology’s imports.
  • Parsing can be syntactically successful yet semantically incomplete when some RDF triples cannot be represented as ontology components. A visitor trait supports navigating and manipulating the resulting ontology structures.
• How you’d use it — Add horned-owl = "2.1.0" to a Rust project’s Cargo.toml. The library reads and writes RDF/XML, OWL/XML, Functional Syntax, and Manchester Syntax; optional features add non-UTF-8 OWL/XML parsing (encoding) and non-local RDF/XML import resolution (remote). The horned CLI provides generation, parsing, validation, conversion, import materialization, profile checks, summaries, comparison, round-tripping, raw triple output, and inspection of unparsed content. The workspace also documents a pretty RDF/XML writer that produces more readable RDF/XML and can translate to and plug into the oxrdfio data model and serializers.
• LLM angle — none stated
• Pitfalls & lessons — Most parsing-oriented CLI tools exit successfully after a syntax-valid parse even when the ontology model is semantically incomplete; use validate for CI or scripts that require a hard failure, or inspect unparsed/dump output for the remainder. triples bypasses axiom construction, so incomplete ontology-model parsing does not apply to it. The reported 20–40× performance improvement is explicitly described as preliminary and potential.
• Verdict — A Rust-focused OWL 2/SWRL library and CLI suite for large-ontology parsing, manipulation, conversion, validation, import handling, and profile inspection.

Sources consulted

• README.md
• horned-bin/README.md
• horned-pretty-rdf/README.md
• doc/roadmap.org (empty)

ontor

• What it is — ontor (ONTology editOR) is a Python library built on Owlready2 for creating, editing, extending, debugging, visualizing, and reasoning over OWL2 ontologies. Each ontor instance represents one ontology.

• Key concepts —

  • Ontologies contain taxonomies, classes, object and data properties, individuals/instances, relations, restrictions, and axioms.
  • General Class Axioms express statements more complex than ordinary class axioms; ontor implements them through equivalent helper classes as an Owlready2 workaround. The documented seafood-pizza example shows a reasoner inferring a price for matching classes and instances without requiring an explicitly defined class for that concept.
  • Ontologies can import other ontologies, and deletion can preserve structure by appropriately reassigning subclasses and instances.

• How you’d use it — Install with pip install ontor, then create or load an ontology, edit it through ontor’s tuple-based syntax, and save it; JSON and CSV are supported. The documented scratch workflow is add_taxo first, then add_ops/add_dps, followed by add_axioms/add_gcas/add_instances. You can extract axioms and class restrictions, run reasoning, interactively debug by deleting problematic axioms, and visualize selected classes, instances, and properties around a focus node.

• LLM angle — none stated

• Pitfalls & lessons — Creation order matters: the taxonomy must exist before properties, and properties before axioms or instances, because later steps depend on already-defined classes and properties. General Class Axioms require an equivalent-helper-class workaround in Owlready2.

• Verdict — A focused Owlready2-based editor for programmatic OWL2 ontology construction and maintenance, with structured import formats plus reasoning, debugging, and visualization support.

Sources consulted

• README.md
• docs/source/index.rst

OPPL

What it is OPPL is an abstract formalism for manipulating ontologies written in OWL. The current version is OPPL 2, an open-source project available under the LGPL and developed as part of the CO-ODE project.

Key concepts Ontology manipulation; OWL; OPPL version 2; open-source LGPL licensing; CO-ODE.

How you’d use it Use OPPL 2 when you need a formalism for manipulating an OWL ontology, consulting the linked releases, documentation, source, or support materials from the project site for the concrete workflow.

LLM angle none stated

Pitfalls & lessons Version 1 differs in many respects from version 2 and is no longer active, so material or scripts for the older version should not be assumed to apply to OPPL 2. The fetched page does not describe the language syntax or specific manipulation operations.

Verdict A focused, openly licensed formalism for OWL ontology manipulation, with the important caveat that the fetched overview is too sparse to assess its concrete feature set.

Sources consulted

• http://oppl2.sourceforge.net/

OWL API

What it is The fetched site is the owlcs-maintained project landing page for the OWL API. It directs users to the GitHub repository, downloadable releases, Maven Central, a wiki, and versioned Javadocs.

Key concepts GitHub repository; releases; Maven Central; wiki documentation; Javadocs for versions 3–5; issue and pull-request contributions; Java 8 in version 5.

How you’d use it Obtain the latest release directly or through Maven Central, consult the wiki and matching Javadocs, and propose or implement API changes through issues, the mailing list, or pull requests.

LLM angle none stated

Pitfalls & lessons Version 5 requires Java 8. The page also notes that tools such as Protégé were using version 4 and that version would remain supported until the community moved to newer versions, so version compatibility matters.

Verdict A concise gateway to OWL API artifacts and contribution channels, with explicit attention to Java and tool-version compatibility.

Sources consulted

• http://owlcs.github.io/owlapi/

Owlish

• What it is — Owlish is a Rust library providing OWL 2 data structures for building and working with ontologies. Its model follows OWL functional-style syntax, representing constructs such as ClassAssertion(:Person :Mary) with correspondingly shaped Rust tuple structs; the project also publishes Node.js/WASM packaging.
• Key concepts —
  • OWL functional-style constructs are represented directly as typed data structures rather than hidden behind a higher-level abstraction.
  • The documented/released model includes declarations and class assertions; object, data, and annotation properties; domains and ranges; equivalent classes, unions, and subproperty axioms; annotations and reification/resource IDs; and typed literals including numeric, boolean, date/time, and duration values.
  • Ontologies can be combined with Ontology.append; a planned “conceptual API” would concatenate OWL data for relevant types, but the README marks it TBD.
• How you’d use it — In Rust, use the low-level functional-syntax representation exported from owlish::owl::*. Releases document RDF-triple/Turtle parsing, parsing individual triples, Turtle serialization, JSON deserialization/mutation, and WASM bindings. In Node.js, read owlish_bg.wasm from the npm package with fs and pass its bytes explicitly to the module initialization function before calling Owlish APIs.
• LLM angle — none stated
• Pitfalls & lessons — The higher-level conceptual API is still marked TBD. Node.js initialization currently requires explicit WASM loading, and the changelog records that blank nodes are ignored rather than causing parser failure; it also documents repeated historical fixes around parser coverage, TypeScript types, annotations, and WASM integration.
• Verdict — A low-level, functional-syntax-shaped OWL 2 data model with Rust and WASM access plus documented RDF/Turtle tooling, but not a finished higher-level conceptual API.

Sources consulted

• README.md
• CHANGELOG.md

Owlready2

What it is Owlready2 is an LGPLv3 package for ontology-oriented programming in Python. It loads OWL 2.0 ontologies as Python objects, supports modification and saving, and performs reasoning with the included HermiT reasoner.

Key concepts The package combines Python-level OWL access with an SQLite3-based optimized triplestore/quadstore intended for large ontologies. Its documentation covers classes and individuals, properties, restrictions and logical operators, open and local closed-world reasoning, SWRL rules, general class axioms, annotations, namespaces, SPARQL, persistent or isolated worlds, parallelism, and the PyMedTermino2 integration for UMLS and medical terminology.

How you’d use it Load or create an ontology in Python, manipulate its entities and axioms as objects, persist it to OWL or an SQLite-backed world, query it with SPARQL, and run HermiT for automatic classification and inferred results.

LLM angle none stated

Pitfalls & lessons none stated

Verdict A feature-rich Python interface for applications that need both programmatic OWL manipulation and reasoning.

Sources consulted

• https://owlready2.readthedocs.io/

Tawny-OWL

• What it is — Tawny-OWL is a Clojure domain-specific language for constructing OWL ontologies in an evaluative, functional, fully programmatic environment, implemented directly over the OWL API. Its Manchester-inspired textual syntax is intended to combine interactive ontology development with ordinary source control, extensible domain patterns, testing, packaging, dependency management, and continuous integration.

• Key concepts

  • The documentation defines an ontology as a computational representation of domain knowledge, normally expressed as concepts plus properties or relationships. OWL is a W3C language with description-logic semantics, enabling reasoners to infer conclusions and detect inconsistencies.
  • Ontology entities are built with frame-style forms: classes can have :super, :sub, :equivalent, and :disjoint frames, while OWL class expressions cover existential and universal restrictions, negation, union, intersection, cardinalities, values, and self restrictions. An equivalence definition gives necessary and sufficient membership conditions.
  • Asserted relationships and inferred relationships are deliberately separate: ordinary query functions inspect asserted axioms, while reasoner functions derive relationships. The reasoning docs distinguish satisfiability of classes, coherence of an ontology, and consistency when individuals are asserted.
  • Because the ontology is executable Clojure, repeated structures can become ontology-specific functions or patterns. Entities may also be built incrementally, which helps with mutual references and reusable modeling idioms.
  • Loading, importing, and reading are different operations: loading creates an OWL API object from a file; OWL importing makes another ontology’s axioms participate in the current ontology and its reasoning; Tawny reading exposes imported entities as Clojure vars. Numeric IRI mappings and memorization files support stable, readable source names when upstream labels change.

• How you’d use it

  • Add the Clojars dependency to a Leiningen project.clj, import tawny.owl, declare an ontology with defontology, and define classes, object/data/annotation properties, individuals, axioms, and annotations in Clojure source.
  • Work interactively in a REPL to add, refine, inspect, or remove entities, then serialize with save-ontology in Manchester (:omn), OWL (:owl), or RDF (:rdf) form. Protege is documented as a useful read-only viewer for the generated ontology.
  • Select HermiT or ELK through tawny.reasoner for coherence, consistency, unsatisfiable-class, and inferred-hierarchy checks. Use clojure.test fixtures and probe entities to test expected inferences and disjointness, including ontologies authored outside Tawny.
  • Reuse existing OWL through OWL API loading, owl-import, or tawny.read/defread; filters and label-to-symbol transforms can make external ontologies usable as Tawny namespaces.

• LLM angle — none stated

• Pitfalls & lessons

  • Tawny is documented as an ontology-development interface first, not a conventional general-purpose Clojure API. Most operations mutate OWL API state and are not thread-safe; the implicit “current ontology” and dynamic scoping can make multiple ontologies awkward, so explicit ontology arguments are safer for API-style use.
  • Macro-based declarations require symbols to exist before use. String-based functional calls avoid that constraint but can silently create a new entity after a spelling mistake or let one IRI become both a class and a property, so the docs discourage casually mixing the two styles.
  • Lazy Clojure operations can appear to do nothing because ontology changes are side effects; the scripting guide recommends doseq, or forcing lazy sequences with doall.
  • Protege sees only generated OWL, not the abstractions that produced it, and edits in Protege do not update Tawny source. The docs also warn that Protege and Tawny may use different OWL API versions.
  • Reasoner availability is limited in the documented setup to mavenized HermiT and ELK. The default GUI progress monitor can be irritating in headless tests and can prevent the JVM from terminating unless replaced with the text or silent monitor.
  • The authors caution that ontologies are most worthwhile for sufficiently complex, categorical knowledge; probabilistic or heavily numerical domains are generally better served by statistical models.

• Verdict — Best suited to source-controlled, pattern-heavy OWL engineering that benefits from a REPL, automated reasoning, and tests; its own documentation positions general ontology manipulation as a secondary, less conventional use.

Sources consulted

• README.md
• docs/getting-started.md
• docs/what-is-owl.md
• docs/adding-restrictions.md
• docs/reasoning.md
• docs/querying.md
• docs/testing.md
• docs/importing.md
• docs/tawny-as-an-api.md
• docs/scripting.md
• docs/repl.md
• docs/protege.md
• docs/namespaces.md
• docs/nameclashes.md
• docs/obo.md
• docs/memorize.md
• docs/polyglot.md

AgreementMakerLight (AML)

• What it is — AgreementMakerLight is an automated, efficient ontology-matching system with a flexible, extensible framework. Its documented approach emphasizes element-level matching techniques supported by background knowledge, and the project reports strong results across several OAEI tracks.
• Key concepts —
  • Ontology matching is performed between a mandatory source ontology and target ontology.
  • Element-level matching can be supported by background knowledge.
  • An alignment can be supplied as a reference during matching or as the required input to alignment repair.
  • AML distinguishes automatic match, configurable manual match, and alignment-repair modes.
• How you’d use it — Download and extract the ready-to-run release, then launch AgreementMakerLight.jar with Java for the graphical interface or pass command-line options for the source ontology, target ontology, optional or required input alignment, and output alignment. The CLI supports automatic matching, manual matching configured through store/config.ini, and repair; AML does not save results unless an output path is given.
• LLM angle — none stated
• Pitfalls & lessons — The documented release was tested with Oracle Java 1.7, 1.8, and 1.9, while OpenJDK compatibility is not guaranteed. The authors also report Maven compilation errors and advise downloading the release instead of building with Maven for the time being.
• Verdict — A focused ontology matcher for generating or repairing alignments between two ontology files, with both GUI and CLI workflows and a documented emphasis on element-level methods plus background knowledge.

Sources consulted

• README.md

Alignment API

What it is The Alignment API is a Java API and implementation for expressing and sharing ontology alignments. It uses an extensible RDF alignment format to represent sets of correspondences between entities in ontologies that need reconciliation.

Key concepts Its five main interfaces are OntologyNetworks, Alignment, Cell, Relation, and Evaluator. Services include storing and finding alignments, piping alignment algorithms, thresholding and hardening results, generating transformations or axioms, and comparing alignments with measures such as precision and recall; the package also includes the ontowrap wrapper for several ontology APIs.

How you’d use it Use the Java API, command line, web interface, or Alignment Server to represent, manipulate, evaluate, generate, store, and share alignments. The server exposes documented REST and SOAP messaging, while EDOAL is available for expressive, declarative alignments.

LLM angle none stated

Pitfalls & lessons The project emphatically states that the API is not itself an ontology matcher. Its bundled trivial matchers are examples, not serious baselines for matcher comparisons, so evaluations should name and compare actual matching systems rather than claim comparison with “the Alignment API.”

Verdict A reusable alignment representation and processing infrastructure, not a substitute for a competitive matching algorithm.

Sources consulted

• http://alignapi.gforge.inria.fr/

LogMap

• What it is — LogMap is a highly scalable ontology matching system with built-in reasoning and inconsistency-repair capabilities. It extracts mappings between classes, properties, and instances, and is intended to handle semantically rich ontologies containing tens or even hundreds of thousands of classes.

• Key concepts

  • Ontology matching can cover classes, properties, and instances rather than classes alone.
  • Reasoning and mapping repair are integrated to minimize logical inconsistencies in produced alignments.
  • User intervention and LLM validation can participate in the matching process.
  • A large alignment task can be divided into manageable subtasks; the repository describes this as a dedicated LogMap module.
  • A separate LogMap variant targets violations of the conservativity principle.

• How you’d use it

  • Run the standalone distribution from the command line as either an ontology matcher or a mapping-debugging system, or integrate LogMap into a Java application.
  • Supply formats supported by OWL API, including RDF/XML, OWL/XML, OWL Functional Syntax, OBO, KRSS, and Turtle (N3).
  • Build the Maven/Eclipse project with mvn package or mvn clean install; deploy the generated JAR alongside the generated java-dependencies directory and parameters.txt.
  • For OAEI workflows, use LogMap’s MELT-platform wrapper/interface; HOBBIT support is also documented through a separate package.

• LLM angle — The README states that LogMap supports LLM validation during matching and points to LogMapLLM work described as using large language models as oracles for ontology alignment. It also documents related work that augments alignment with semantic or knowledge-graph embeddings and distant supervision.

• Pitfalls & lessons

  • The old web interface is not functional; a replacement is being pursued.
  • The OWL API 3 branch is explicitly non-maintained; the main project relies on OWL API 4.
  • The Google Translate dependency is not downloaded automatically and must be added manually to the local Maven repository.
  • Newer Java versions require documented VM arguments, including a module-opening flag and increased entity-expansion limit; the suggested configuration also allows a heap up to 25 GB.
  • LogMap-ML is marked as under development.

• Verdict — A documented fit for large-scale, logic-aware ontology alignment and mapping repair, with command-line, Java, and evaluation-platform integration plus emerging LLM/embedding extensions.

Sources consulted

• README.md

OntoAligner

• What it is — OntoAligner is a modular Python toolkit for matching entities across two ontologies or knowledge graphs. It exposes a consistent parse → encode → align → postprocess workflow across lexical/fuzzy, retrieval, LLM, RAG, knowledge-graph-embedding, property, graph, and ensemble methods, with evaluation and export support.
• Key concepts —
  • An ontology-matching dataset contains a source ontology, a target ontology, and optionally reference correspondences; parsed concepts can carry IRIs, labels, parents, children, synonyms, and comments.
  • Encoders turn those concepts into method-specific representations: lightweight natural-language strings, LLM prompts, RAG inputs, or graph triples. Aligners propose source–target correspondences, while optional reranking and postprocessing reorder, filter, normalize, or impose cardinality constraints.
  • Evaluation treats alignments as source–target pairs and reports precision, recall, F-score, and intersection; ranked candidate outputs can also be measured with Hit@K and MRR.
  • Ensemble alignment normalizes heterogeneous matcher outputs and fuses them through weighted voting, reciprocal-rank fusion, Borda, Condorcet, or score averaging before top-k, threshold, or bijective selection.
• How you’d use it — Install with pip install -U OntoAligner (the docs recommend Python 3.10+, PyTorch 1.4.0+, and Transformers 4.41.0+). Load OWL/RDF source and target files with GenericOMDataset or a track-specific dataset, choose compatible parser/encoder/aligner/postprocessor components, then run either the one-step OntoAlignerPipeline or the lower-level AlignerPipeline; optional reference alignments support evaluation, and results can be exported as OAEI-compatible XML or JSON. Custom parsers can redirect nonstandard label, synonym, definition, or hierarchy properties, or support non-RDF sources by extending the base parser.
• LLM angle — Standalone Hugging Face LLM aligners turn concept pairs and optional parent/child context into yes/no prompts, then map generated text back to match labels. The documented LLMs4OM RAG flow uses each source concept as a query over target concepts, retrieves candidates, and asks an LLM to verify each pair; it supports concept, concept-parent, and concept-children representations, plus few-shot and in-context-vector variants. The toolkit also includes KGE aligners that learn low-dimensional entity/relation vectors from graph triples, and ensembles can combine lexical, structural, retrieval, KGE, LLM, and RAG signals.
• Pitfalls & lessons —
  • Direct LLM matching has quadratic complexity and is documented as suitable for small ontologies (about 200 concepts or fewer); RAG narrows the candidate set and uses single-forward-pass logit scoring to reduce GPU use.
  • An LLM encoder and its dataset class must represent the same context (for example, children with children); mismatches can omit required fields and break the pipeline.
  • The generic parser assumes common RDF/OWL predicates such as rdfs:label, skos:altLabel, rdfs:comment, and rdfs:subClassOf; ontologies that store these semantics differently need targeted parser overrides.
  • Matching thresholds are dataset- and use-case-specific, and reranking is useful only when each source still has multiple target candidates—not after a single-target matcher has made its final selection.
• Verdict — A broad experimentation and integration toolkit for ontology alignment, strongest when you need one modular interface for comparing classical, retrieval, graph, LLM/RAG, and ensemble pipelines rather than a single fixed matcher.

Sources consulted

• README.md
• docs/source/gettingstarted/overview.rst
• docs/source/gettingstarted/installation.rst
• docs/source/gettingstarted/quickstart.rst
• docs/source/developerguide/pipeline.rst
• docs/source/developerguide/parsers.rst
• docs/source/developerguide/metrics.rst
• docs/source/developerguide/reranking.rst
• docs/source/aligner/lightweight.rst
• docs/source/aligner/retriever.rst
• docs/source/aligner/llm.rst
• docs/source/aligner/rag.rst
• docs/source/aligner/kge.rst
• docs/source/aligner/propmatch.rst
• docs/source/aligner/flora.rst
• docs/source/aligner/olala.rst
• docs/source/aligner/ensemble_learning.rst

OntoEMMA

• What it is — OntoEMMA is an ontology matcher for generating alignments between knowledgebases. It provides training and alignment workflows with either a logistic-regression model or an AllenNLP neural-network model.

• Key concepts —

  • Alignment is staged as candidate selection followed by pairwise prediction. Candidate entities are ranked using word and character n-gram token maps and summed token IDF scores.
  • Pair features use entity aliases plus the canonical names of parents and children; canonical-name tokens are also stemmed and lemmatized.
  • Candidate quality can be evaluated against gold mappings with candidate yield and precision/recall at selected top-k values; final predicted alignments can likewise be evaluated when a gold file is supplied.
  • UMLS-derived supervision treats identifiers mapped under the same concept ID as positive pairs. Training data adds hard negatives selected from nonmatching candidates and easy negatives sampled randomly from the rest of the knowledgebase.

• How you’d use it — Run ./setup.sh to create the ontoemma Conda environment. Train with train_ontoemma.py, choosing lr or nn, a model path, and a JSON configuration; then align a source and target with run_ontoemma.py, optionally supplying an input alignment, output TSV, and CUDA device. OntoEMMA documents support for its KnowledgeBase JSON and pickle files and, “to the best of its ability,” OBO, OWL, TTL, RDF, and ontology web URIs. Its UMLS extractor writes knowledgebases as JSON and pairwise mappings/training examples as TSV.

• LLM angle — No LLM or RAG integration is stated. The documented learned matchers are logistic regression and an AllenNLP neural network; the knowledge-graph-related scope is ontology/knowledgebase alignment.

• Pitfalls & lessons — The README explicitly says the library is no longer maintained. Format handling for OBO, OWL, TTL, and RDF is qualified as working only “to the best of its ability.” Reproducing UMLS training also requires obtaining the UMLS Metathesaurus and updating local path variables, while the documented defaults point to AllenAI-internal NFS locations.

• Verdict — A documented, classical ML pipeline for candidate-based ontology alignment and UMLS-derived training data, useful as a reference but constrained by discontinued maintenance and environment-specific data setup.

Sources consulted

• README.md
• docs/ontoemma.md

Ontology Matching

What it is Ontology Matching is an information repository devoted to methods for finding correspondences between semantically related entities in different ontologies. It frames matching as a response to semantic heterogeneity in open or evolving systems where different parties adopt different ontologies.

Key concepts Semantic heterogeneity; entity correspondences; ontology interoperability; ontology merging; query answering; data translation; semantic-web navigation.

How you’d use it Consult the repository when studying or selecting ontology-matching approaches, then use the resulting correspondences to support merging, cross-ontology queries, translation, or navigation.

LLM angle none stated

Pitfalls & lessons Ontologies do not remove heterogeneity by themselves; independently adopted models can move the mismatch to a higher semantic level and therefore require explicit matching.

Verdict A focused conceptual and information resource that clearly explains why ontology alignment is needed and what downstream interoperability tasks it enables.

Sources consulted

• http://www.ontologymatching.org/index.html

Do Language Models Replace Ontologies?

What it is The live argument about whether large language models make hand-built ontologies unnecessary, obsolete the labour of building them, or increase their value. The corpus already documents the tooling side of this in OntoLearner, OntoAligner, and ELOT. This note records the argument itself.

Key concepts

• The replacement case, reconstructed here rather than quoted, since no source in this corpus argues it directly. A model trained on a large corpus encodes much of the taxonomic and relational knowledge an ontology would state, and answers questions without anyone writing an axiom. Sun and colleagues confirm the debate exists — “sparking a growing debate about whether traditional knowledge graphs will be replaced by LLMs in real applications” — and that models “demonstrate an impressive ability to internalize knowledge and answer natural language questions.” It is the strongest challenge to Lenat’s premise; see cyc-lenat-1995.md.
• The measured rebuttal. Sun and colleagues ask “Are Large Language Models a Good Replacement of Taxonomies?” in PVLDB 17(11), 2024, and test it empirically. The result splits on two axes at once: “LLMs perform miserably poorly in handling specialized taxonomies and leaf-level entities. Specifically, the QA accuracy of the best LLM drops by up to 30% as we go from common to specialized domains and from root to leaf levels of taxonomies.” They concede the other half plainly — for common domains, “the manually constructed and maintained taxonomies in these domains may not be needed shortly” — while recommending “that industrial practitioners continue with the current tree-structure taxonomies in specialized domains to ensure reliability.”
• Keet’s objection. Keet argues that generating an ontology from a model is harder than it looks. Her lead point is that models are not knowledge bases: “the LLMs do not store the (structured) facts, (axiomatised) sentences, and rules to make the inferences, and so nor does an LLM offer the reliability that it would return the same answer to a query when it’s posed more than once,” so “two different runs then may lead to two different ontologies.” Her second is logical: “if a majority is ignorant of the fact that, say, whales are mammals and wrote about their misconception, an LLM may propose them to be fish, but that would make the ontology inconsistent if the rest of animal classification was represented properly. Inconsistent ontologies are bad computationally.” Her third is about consensus: an ontology is supposed to record agreement, and “this doesn’t entail that the humans in the project have reached consensus just because an LLM said so.”
• The grounding case. Ontology-grounded retrieval work argues the relationship is complementary. The OG-RAG paper states the gap — “existing retrieval-augmented models, such as RAG, offer improvements but fail to account for structured domain knowledge… ontologies, which conceptually organize domain knowledge by defining entities and their interrelationships, offer a structured representation to address this gap” — and reports “30% faster attribution of responses to context” alongside a 27% gain in fact-based reasoning accuracy. On the other side, “LLMs also enable ontology extraction from both structured and unstructured data.”
• A division of labour, which is my summary rather than any source’s. Models are good at proposing candidates from text; reasoners and constraint languages are good at rejecting the proposals that do not hold. Note that Sun and colleagues propose a different split — the entities near the roots move into the model’s weights, while the entities near the leaves stay in the tree.

How you’d use it Separate the three questions people conflate. Can a model replace an ontology as a store of knowledge? Can it build one? Can it use one? My reading of the evidence in this corpus, not a finding any source states: it is weakest on the first, mixed and improving on the second, and strongest on the third. A team that needs auditable and consistent answers still needs the explicit artifact, whoever or whatever drafted it; if it also needs permission-governed answers, palantir-ontology.md shows what that costs.

LLM angle The whole note is the LLM angle.

Pitfalls & lessons The corpus’s existing pitfalls apply directly. Clear prompts and structured output reduce hallucination and inconsistency but do not remove the need to validate relationships and labels. Direct all-pairs matching is quadratic and documented as suitable only for small ontologies, around two hundred concepts or fewer. Large retrieval contexts cause memory problems. Automatic validation checks lint and parsing, not semantic consistency, so syntactic validity is not semantic correctness. ELOT’s guarded design — file writes project-scoped, disabled by default, confirmation-gated, revalidated with rollback, and with a separate consistency check still required — is the concrete pattern to copy.

Verdict Worth studying, and the note to read before betting either way. The corpus’s evidence says models do not replace ontologies outside common, well-represented domains, help build them only under guarded validation, and are most clearly useful when an ontology grounds them.

Sources consulted

• https://www.vldb.org/pvldb/vol17/p2919-sun.pdf
• https://keet.wordpress.com/2025/03/26/is-developing-an-ontology-from-an-llm-really-feasible/
• https://aclanthology.org/2025.emnlp-main.1674/
• https://arxiv.org/abs/2511.05991v1
• research/firecrawl/llm-taxonomies-vldb.md
• research/firecrawl/llm-keet-ontology.md
• research/exa/llm-ont.json (the only local capture for the ACL Anthology and arXiv entries above)
• See also ontolearner.md, ontoaligner.md, elot.md.

OntoLearner

• What it is — OntoLearner is a modular, extensible Python framework for semi-automatic ontology construction and enrichment. It joins reusable ontology loading and modularization with datasets, learner models, and evaluation for a full fit → predict → evaluate workflow.

• Key concepts —

  • Its core learning objects are terms/entities, which populate an ontology, and types/classes, which provide its abstract categories.
  • The LLMs4OL task model comprises term typing (map a lexical term to a class), taxonomy discovery (find hierarchical is-a/subclass relations), and non-taxonomic relation extraction (find relations such as part-of, causes, or used-for). Text2Onto separately extracts terms and types from raw text.
  • OntologyData carries term-to-type mappings, parent–child taxonomic relations, and head–relation–tail non-taxonomic relations. Earlier task outputs can feed later tasks, though tasks may also run in parallel.
  • An Ontologizer turns an ontology into a Python object, retaining provenance metadata and extracting ML-ready datasets; the documented analyzer distinguishes graph-topology metrics from extracted-dataset metrics.

• How you’d use it — Install with pip install -U ontolearner (the docs recommend Python 3.10+, plus PyTorch and Transformers). Instantiate a built-in Ontologizer or use AutoOntology, load from Hugging Face or a local OWL/RDF/XML/TTL file, call .extract(), split the resulting OntologyData, and run an LLM-only, retriever-only, or RAG learner directly or through LearnerPipeline. The tooling also supports custom Ontologizers and extraction hooks, generated JSON task datasets, ontology metrics, synthetic Text2Onto corpora, and Dublin Core metadata exported as RDF/XML.

• LLM angle — LLM-only learners use a model’s inherent knowledge; retriever-only learners index training examples as embeddings; RAG retrieves similar ontology examples and supplies them as domain-specific few-shot context to the LLM. Text2Onto uses a direct Hugging Face transformers backend to generate synthetic documents, enriching prompts with term-typing, taxonomy, and non-taxonomic graph context so passages stay closer to the source ontology.

• Pitfalls & lessons —

  • The authors recommend pure LLMs mainly for general or well-known domains, RAG for specialized domains, and LLM/symbolic or multi-model ensembles for higher-stakes reliability.
  • Clear prompts and structured output reduce hallucination and inconsistency; relationships and labels should be validated, and evaluation should use representative held-out data, multiple metrics, domain-specific criteria, and classical baselines.
  • Large retrieval contexts can cause memory problems; AutoRetrieverLearner(batch_size=...) computes similarities in smaller batches.
  • Text2Onto works best with instruction-tuned models and ontology context that fits the model window. The docs identify stricter structured-output validation, repair retries for missing labels, richer graph-context retrieval, and candidate reranking as possible improvements.
  • New ontologies may need custom extraction logic when they do not use standard RDF/OWL constructs, plus ontology-specific blank-node filtering; format/path mismatches can cause parsing or missing-file failures.

• Verdict — A focused experimentation and benchmarking toolkit for converting curated ontologies or raw text into standardized ontology-learning datasets and comparing retrieval, LLM, and RAG approaches across the documented ontology tasks.

Sources consulted

• README.md
• docs/source/index.rst
• docs/source/installation.rst
• docs/source/quickstart.rst
• docs/source/learning_tasks/learning_tasks.rst
• docs/source/learning_tasks/llms4ol.rst
• docs/source/learning_tasks/text2onto.rst
• docs/source/learners/llm.rst
• docs/source/learners/retrieval.rst
• docs/source/learners/rag.rst
• docs/source/ontologizer/ontology_modularization.rst
• docs/source/ontologizer/ontology_hosting.rst
• docs/source/ontologizer/new_ontologies.rst
• docs/source/ontologizer/metadata.rst
• docs/source/ontologizer/metrics.rst

SciGraph

• What it is — SciGraph represents ontologies and ontology-encoded data as a Neo4j property graph. It is an OWL-centric, domain-agnostic loader and access layer with graph, vocabulary, annotation, and REST operations.

• Key concepts —

  • Ontologies are presented as formal, explicit specifications of shared conceptualizations that can serve as data, vocabulary, or semantics.
  • OWL classes, subclass relations, object properties, and existential restrictions are mapped into graph structure; the documentation stresses that “the IRI is king” and distinguishes IRIs, CURIEs, and fragments as identifiers.
  • Vocabulary support connects ontology identity to application features: label-to-node resolution, CURIE-to-IRI resolution, search, autocomplete, suggestions, OpenRefine resolution, and free-text entity identification.
  • The graph enables relationship-pattern queries across combined ontological and biological data, illustrated with subclass, phenotype, interaction, orthology, and sequence relationships.

• How you’d use it —

  • Ingest OWLAPI-supported formats—including OWL, RDF, OBO, and TTL—into Neo4j with the batch loader and YAML configuration; configuration can name ontologies, reasoner settings, categories, and mapped properties.
  • Consume the result directly through Neo4j/Cypher, add scigraph-core for convenience and vocabulary operations, or run scigraph-services as a Dropwizard REST service. The documented REST surface includes vocabulary lookup/search/autocomplete, lexical annotation, graph lookup/neighborhoods, and configurable domain-specific Cypher queries.
  • Graph endpoints can return json-bbop, GraphML, GraphSON, GML, JPEG, or PNG. Once generated, the graph can also be used by an application with no SciGraph dependency.

• LLM angle — none stated

• Pitfalls & lessons —

  • The mapping is explicitly lossy and does not round-trip ontologies; SciGraph does not create, manage, or version ontologies, is not a primary data store, and does not support CRUD operations.
  • Reasoning support is a stated non-goal. The presentation also says OWL mapping requires declarations in cases such as SKOS.
  • SciGraph is OWL-centric: an arbitrary SKOS ontology whose skos:Concept resources are not asserted as owl:Class will not expose those concepts to OWLAPI and they will not be loaded.
  • The authors list Neo4j limitations for this use: poor fit for global aggregate number crunching and binary/blob/object storage, Neo4j-specific Cypher, and a conceptual shift; an earlier presentation also flags replication.
  • Because Neo4j uses memory-mapped I/O, its database cannot be stored in a Vagrant shared directory.

• Verdict — A focused OWL-to-Neo4j ingestion and access toolkit for ontology-backed graph, vocabulary, and annotation services—not an ontology authoring, versioning, round-tripping, or general reasoning system.

Sources consulted

• README.md
• docs/presentation/20150211 SciGraph.pptx
• docs/presentation/20150801 SciGraph.pptx

Association for Ontology Design & Patterns (ODPA)

What it is The fetched source does not contain the requested ODPA association page; it resolves to the OntologyDesignPatterns.org main page. That page only establishes that ODPA runs the ontology-design-pattern portal and that the association was formed.

Key concepts Portal stewardship; ontology design patterns; workshops and tutorials; community contribution and review.

How you’d use it From this source, you can identify ODPA as the portal operator and follow the referenced ODPA page, but you cannot reliably recover the association’s mission, membership, or governance.

LLM angle none stated

Pitfalls & lessons The fetched URL is the portal main page rather than the named ODPA page, so association-specific conclusions would be unsupported.

Verdict Insufficient as a grounded profile of ODPA; useful only for confirming its stewardship of OntologyDesignPatterns.org.

Sources consulted

• http://ontologydesignpatterns.org/wiki/ODPA

National Center for Ontological Research (NCOR)

What it is

NCOR describes itself as an international nonprofit ontology research-and-development network. It promotes interdisciplinary research, education, collaboration, and ontology-engineering best practices intended to support interoperability and robust AI systems.

Key concepts

Its scope spans foundational, biomedical, industrial, and applied ontologies; semantic interoperability; methodology; and engineering. It also presents itself as a coordinating hub linking philosophy, computer science, AI, information science, domain experts, academic institutions, government, and industry.

How you’d use it

Use the network to join ontology working groups and events, find educational material and publications, collaborate with practitioners, or consult its vetted open-source standards, including BFO and Common Core Ontology modules.

LLM angle

none stated

Pitfalls & lessons

none stated

Verdict

A broad community and coordination resource for people seeking research, standards, training, and cross-sector collaboration in formal and applied ontology.

Sources consulted

• https://ncor-network.org/

Ontology Alignment Evaluation Initiative (OAEI)

What it is

OAEI is a coordinated international initiative seeking consensus on how schema- and ontology-matching methods should be evaluated. It runs controlled experimental evaluations to assess systems and techniques and to improve work on ontology alignment and matching.

Key concepts

Its goals include identifying system strengths and weaknesses, comparing technique performance, improving evaluation methods, and increasing communication among algorithm developers. Its main mechanisms are a yearly evaluation event and publication of tests and results for later analysis.

How you’d use it

Use its annual evaluations, competence-test library, and published results to compare matching approaches or analyze established evaluation tasks; the site also provides participation and dataset-submission guidance.

LLM angle

none stated

Pitfalls & lessons

The initiative emphasizes controlled evaluation and shared tests rather than unsupported comparisons between alignment systems.

Verdict

A long-running evaluation community and evidence source for ontology-matching systems, with events listed from 2004 through 2026.

Sources consulted

• http://oaei.ontologymatching.org/

buaaliuming/Awesome-Knowledge-Bases

What it is

Awesome-Knowledge-Bases is a compact curated page of currently available knowledge bases, ontologies, knowledge graphs, and taxonomies, maintained for quick use and survey. Its README frames these resources as carriers of human knowledge that have evolved from dictionaries and rules through taxonomies and RDF/OWL ontologies to knowledge bases and knowledge graphs.

Key concepts

• Knowledge resources are presented as important to machine intelligence, natural-language understanding, reasoning, and cognition.
• The README names a progression of knowledge representations: dictionaries, rules, taxonomies, ontologies (RDF/OWL), knowledge bases, and knowledge graphs.
• Listed resources include OwnThink, OpenKG, XLORE, and OpenHowNet. The descriptions characterize OwnThink as exposing JSON APIs for a question-answering robot, knowledge graph, and semantic understanding; XLORE as a large cross-lingual knowledge graph; and OpenHowNet as an open sememe-based linguistic knowledge base.

How you’d use it

Use the README as a quick survey and link directory when looking for an available knowledge resource, especially the listed Chinese-language or cross-lingual knowledge graphs and linguistic knowledge bases. Follow the linked project that matches the needed representation or capability; this repository itself supplies brief descriptions rather than usage instructions.

LLM angle

none stated

Pitfalls & lessons

none stated

Verdict

A useful but very small discovery index: it gives a concise vocabulary for knowledge representations and points to four resources, but provides no comparative criteria, integration guidance, or documentation beyond the README’s short annotations.

Sources consulted

• README.md

costezki/awesome-semantic-tools

What it is

A compact curated list of projects related to ontology engineering and Semantic Web technologies. It organizes links by function, spanning distributed linked data, development and web frameworks, RDF transformation/ETL, ontology documentation, alignment, search, validation, and query engines.

Key concepts

• Distributed Linked Data: Linked Data Fragments explores shifting query load among clients, servers, and caches, while Solid applies Linked Data principles and existing W3C standards to decentralized social applications.
• RDF development and applications: the list points to RDFLib for Python, Jena and RDF4J for Java, plus Semantic Web-oriented web frameworks and content-management extensions.
• Data integration and transformation: the ETL section includes RDF pipelines, data integration, XML-to-RDF conversion, XQuery/SPARQL transformation, workflows, and RDF-to-property-graph conversion.
• Ontology documentation and constraints: WIDOCO and pyLODE generate ontology documentation; RDFUnit, SHACL, and ShEx implementations cover validation.
• Federated access: Comunica is described as a modular meta-query engine for the Web, and HyperGraphQL exposes multiple Linked Data services through GraphQL schemas and federated querying.

How you’d use it

Use the category headings as a discovery map: choose the job at hand—RDF programming, ETL, documentation, validation, search, or querying—then follow the linked projects for deeper evaluation. It is especially useful for quickly assembling a shortlist across languages and approaches, such as RDFLib versus Java frameworks, or SHACL versus ShEx tooling.

LLM angle

none stated

Pitfalls & lessons

The README is an index rather than a comparison or implementation guide: several entries are raw links or have only a few words of description, the alignment section contains an empty bullet, and LDIF is explicitly marked outdated. Treat inclusion as a lead to investigate, not as evidence that a project is current, maintained, or appropriate for a particular deployment.

Verdict

A useful high-level discovery checklist for the Semantic Web tool landscape, particularly because its categories cover the workflow from RDF creation and integration through documentation, validation, and querying. Its sparse and occasionally stale curation means each candidate still needs verification in its own documentation.

Sources consulted

• README.md

jbenner-radham/awesome-semantic-web

What it is: A curated directory of Semantic Web and linked-data resources. It groups specifications, ontologies, vocabularies, schemas, and related tools by subject area rather than providing an ontology or software implementation of its own.

Key concepts: The collection spans identity and vCards, résumés/CVs, organizations, security, calendars, time, bibliography, electronics, media, provenance, and assorted Semantic Web resources. It points to several representation styles—including RDF, OWL, JSON-LD, JSON Schema, Microformats, and Microdata—and often includes a vocabulary namespace or direct RDF/OWL/Turtle URL beneath the main reference. Some entries demonstrate content negotiation, such as the OPDM vocabulary links with an RDF/XML Accept header.

How you’d use it: Start in the relevant subject section, compare the listed standards or vocabularies, then follow the specification and namespace links to select terms or retrieve a machine-readable representation. The direct serialization links are particularly useful when an entry offers RDF, OWL, Turtle, JSON, N3, or N-Triples variants.

LLM angle: none stated

Pitfalls & lessons: The README is an index, not a comparative guide: it provides links but generally does not explain tradeoffs, compatibility, maturity, or selection criteria. Several resources are explicitly marked archived, and others are struck through, so availability and currency should be verified before adoption. The miscellaneous section is largely an unannotated link list.

Verdict: Useful as a compact discovery map across many Semantic Web domains and representation formats, especially when you need canonical namespaces or downloadable serializations. It is best treated as a starting point for further validation rather than as implementation guidance.

Sources consulted

• README.md

KMax/awesome-semantic-web-business

What it is

A curated list of resources showing Semantic Web technologies in business applications. The repository organizes its material into links to other Semantic Web lists, a W3C use-case collection, and a table of companies said to employ Semantic Web technologies in their solutions.

Key concepts

• Business adoption is represented through named companies rather than through an ontology or software implementation.
• Inclusion evidence, when supplied, takes several forms: job postings, product descriptions, blog posts, presentations, a white paper, and a scientific article.
• The list connects readers to a general Semantic Web list and a separate list focused on vocabularies and ontologies.
• Its sole use-case resource is the W3C “Semantic Web Case Studies and Use Cases” collection, labeled 2007–2012.

How you’d use it

Use it as a starting index for finding organizations and business-facing examples associated with Semantic Web technology. Follow the “Reason to include” links to inspect the supporting job, product, article, or presentation evidence, and use the two related awesome lists when the need is broader or specifically ontology-focused.

LLM angle

none stated

Pitfalls & lessons

Many company rows have no stated reason for inclusion, while others rely on external or archived links, so the table itself does not provide equally strong evidence for every entry. The README supplies names and pointers rather than detailed case summaries, and its one consolidated use-case collection is explicitly dated 2007–2012.

Verdict

Useful as a lightweight discovery directory for commercial Semantic Web examples and adjacent resource lists, but not as a self-contained account of how the technologies were implemented. Entries with explicit supporting links are the most actionable; unannotated rows require independent follow-up.

Sources consulted

• README.md

Materials-Data-Science-and-Informatics/awesome-fair-data

• What it is — A curated “Awesome FAIR” list from the Helmholtz Metadata Collaboration’s Hub Information & FAIR Data Commons at FZJ. It collects resources around making scientific data findable, accessible, interoperable, and reusable, spanning principles, assessment, metadata and ontology standards, discovery, provenance, software publication, and repository infrastructure.

• Key concepts —

  • FAIR means findable, accessible, interoperable, and reusable; the README explicitly cautions that FAIR is not the same as open, although they overlap.
  • Interoperability is supported through shared metadata and semantic models such as DCAT, Dublin Core, RDF, Schema.org, SKOS, PROV-O, and the Helmholtz Digitization Ontology.
  • Persistent identification is part of the metadata layer: ORCID identifies people, ROR identifies organizations, and PIDA generates ontology IRIs through a maintained PURL service.
  • FAIR Digital Objects are presented through linked-data/RDF infrastructure work and pragmatic packaging such as RO-Crate, which combines existing technologies and ontologies to annotate scientific datasets.
  • Provenance is treated as a first-class concern for simulation, data, ML, and research workflows, with PROV-O and combinations of RO-Crate, PROV, and BagIt listed as standards-based mechanisms.

• How you’d use it — Use the README as a categorized directory: learn the FAIR principles, assess an identified dataset with FAIR Evaluator or F-UJI, choose metadata/semantic standards, find ontology lookup services, discover datasets or software, select provenance tooling, or identify repository software such as Dataverse, Invenio, and InvenioRDM. Documented practical formats include JSON-LD, JSON Schema, RDF, CITATION.cff, CodeMeta in JSON/XML, RO-Crate, PROV, and BagIt; several catalog and graph entries also expose search interfaces or APIs.

• LLM angle — No LLM or RAG use is stated. Knowledge-graph-adjacent material includes Microsoft Academy’s PID graph, OpenAIRE/Scholex scholarly-data links, Crossref’s queryable graph of related entities, RDF/linked data, ontologies, and SOMEF’s use of ML and other techniques to extract software-publication metadata from READMEs and other documentation.

• Pitfalls & lessons — FAIR should not be conflated with open data. The provenance section warns that general workflow-tool lists overlap with provenance tooling but not every pipeline or workflow manager provides good provenance tracking. The README marks Microsoft Academy as shut down at the end of 2021; contribution guidance also requires checking for duplicates and placing an item in exactly one category even when it fits several.

• Verdict — A useful, broad FAIR-data reference index with a strong metadata, ontology, identifier, and provenance layer, but it is a curated directory rather than an ontology specification or implementation guide.

Sources consulted

• README.md
• CONTRIBUTING.md

pysemtec/semantic-python-overview

What it is A curated, awesome-list-inspired overview of projects that connect Python with semantic technologies such as RDF, OWL, SPARQL, and reasoning. The repository also presents itself as a possible crystallization point for a community interested in how these projects can productively interact, while acknowledging that the list may be incomplete and biased.

Key concepts

• Projects are organized into “Established Projects,” “Probably Stalled or Outdated Projects,” and “Further Projects / Links,” with entries alphabetized within sections.
• The catalog spans ontology construction and editing, RDF parsing and storage, SPARQL querying and endpoints, reasoning, knowledge-graph exchange, semantic validation, visualization, and graph/data-science integration.
• Entries commonly provide a short description, documentation links, feature summaries, and sometimes literature references or maintenance-status notes.
• Representative integrations include RDFLib, NetworkX, Pandas, OWL reasoners, graph databases, and semantic formats such as RDF, OWL, OBO, JSON-LD, SHACL, and LinkML.

How you’d use it Use the README as a discovery index when selecting a Python semantic-technology project: start with the relevant capability, follow the linked project documentation, and check whether the entry is established or flagged as probably stalled or outdated. It is especially useful for comparing nearby options—for example, RDF/SPARQL tooling, ontology APIs and editors, reasoners, knowledge-graph loaders, or bridges into NetworkX and the PyData stack.

LLM angle The README identifies LangChain’s GraphSparqlQAChain as a module that makes RDF and OWL accessible through natural language by generating SPARQL SELECT and UPDATE queries, running them against files, endpoints, or triple stores, and returning natural-language responses. It also describes kglab’s “Hybrid AI” focus on combining graph technologies with ML work and notes integration examples involving deep learning.

Pitfalls & lessons The authors explicitly warn that the collection may be incomplete and biased because of their limited knowledge, so it should be treated as a starting point rather than an authoritative inventory. Maintenance status matters: several projects are separated into a probably stalled or outdated section, with last-update information or legacy dependencies, and the README invites issues and pull requests to improve the catalog.

Verdict A strong orientation map for the Python semantic-web and ontology ecosystem, particularly when you need names, capability summaries, and links before evaluating tools in depth. Its value is breadth and categorization rather than hands-on guidance, and its own completeness and bias caveat makes follow-up validation essential.

Sources consulted

• README.md

semantalytics/awesome-semantic-web

• What it is — A curated list of semantic-web and linked-data resources, maintained primarily as a categorized README.md. Its scope runs from standards, serializations, stores, SPARQL, mappings, ontologies, and reasoners through programming libraries, development tools, machine learning, and NLP.

• Key concepts

  • The standards catalog separates RDF concepts and semantics, RDFS vocabulary description, OWL ontology language, SHACL and ShEx shapes, and SPARQL querying, updates, federation, protocols, result formats, and entailment regimes.
  • RDF can be exchanged in formats including Turtle, TriG for named graphs and RDF datasets, JSON-LD, N-Triples, N-Quads, RDF/XML, HDT, and binary or streaming formats such as Jelly.
  • Mapping is treated as a distinct layer: the listed tools transform heterogeneous, CSV/tabular, XML, relational, object, geospatial, and property-graph data to or from RDF, with R2RML, RML, CSVW, ShExML, and related mapping approaches represented.
  • Ontology work includes vocabulary discovery and reuse (for example LOV, BioPortal, SKOS, PROV-O, and DCAT), authoring and templates, validation and pitfall scanning, graph versioning, maturity and schema-drift checks, and logical reasoning.
  • The reasoner catalog includes Description Logic, OWL 2/DL/RL, proof-engine, and entailment-proof tooling; one listed OWL 2 DL reasoner explicitly supports multithreaded consequence-based reasoning.

• How you’d use it — Browse the category matching a task, then follow the maintained links to the governing specification or an implementation: choose an RDF serialization and MIME type, map source data into RDF, query or update it with SPARQL, find an existing vocabulary, and select an editor, validator, or reasoner. To extend the catalog, the contribution guide asks for one resource per pull request, a concise explanation of why it belongs, an appropriate section, and a duplicate search first.

• LLM angle — The machine-learning section lists OntoGPT for populating semantic schemas from unstructured text with LLMs and SPARQLLM for letting SPARQL queries access search engines, LLMs, or vector databases during query execution. The NLP section also lists LoRiS for generated natural-language representations of SPARQL queries over Wikidata and DBpedia, while the reasoning section links OWL and Description Logic reasoners plus tooling for proofs of entailments.

• Pitfalls & lessons — The maintainers caution that listed packages can become abandoned or retain breaking builds for long periods; contributors should update or remove such listings and notify maintainers through an issue or pull request. They also explicitly call the “Academic” database classification somewhat arbitrary, and note that issue-based “awesomelet” suggestions may be evaluated only at an indeterminate future time, whereas pull requests are evaluated immediately.

• Verdict — A broad, ontology-relevant discovery index for standards, vocabularies, mappings, authoring, validation, querying, and reasoning tools rather than a step-by-step ontology tutorial.

Sources consulted

• README.md
• CONTRIBUTING.md
• CLAUDE.md

totogo/awesome-knowledge-graph

• What it is — A curated directory of knowledge-graph learning materials, databases, tools, datasets, services, events, and books. Its main organization separates infrastructure, knowledge engineering, datasets, and learning resources; it is a resource list rather than an ontology specification or tutorial.

• Key concepts —

  • The infrastructure landscape is divided into graph databases, triple stores, graph-computing frameworks, visualization, graph construction, query languages, and managed hosting.
  • The listed Semantic Web and Linked Data stack includes RDF parsing and storage, triples/quads, inferencing, SPARQL endpoints, and W3C-compliant semantic graph databases.
  • Knowledge-graph construction can be mapping-driven: Morph-KGC uses RML mappings, while Ontop exposes SQL sources as a virtual knowledge graph through R2RML mappings.
  • Knowledge engineering includes web knowledge harvesting, seed-entity subgraph extraction, fuzzy deduplication/entity resolution, and link discovery.
  • Dataset examples distinguish general graphs, semantic networks, academic graphs, and domain graphs; their descriptions emphasize entities, facts, concepts, named entities, semantic relations, and the integration of heterogeneous sources.

• How you’d use it — Use the categorized links to shortlist graph storage and computation systems, choose among Cypher, Gremlin, SPARQL, GraphQL+-, and GQL, find RDF libraries or graph visualization tools, and locate public knowledge-graph datasets. For construction, follow the listed RML/R2RML tools; for learning, start with the linked official Cypher/Gremlin documentation and community books or guides.

• LLM angle — The listed Knowledge Graphs and LLMs in Action covers introducing knowledge graphs built from structured and unstructured sources into LLM applications and RAG pipelines. The Termboard entry also says its graphical term-and-relation editor can use ChatGPT, Google Bard, or another chatbot.

• Pitfalls & lessons — The catalog explicitly marks Apache Marmotta as a retired Apache project, and Tencent Knowledge Graph as a beta service available only in Chinese. Its contribution guide also warns that maintainers may request changes to an existing pull request before merging it.

• Verdict — A broad discovery index for knowledge-graph infrastructure, datasets, and learning links, but not a documented method for designing ontologies.

Sources consulted

• readme.md
• contributing.md