Announcing ontologies.periscoped.io: A Worldwide Index of Prior Art for Your Data Model | Blog

The Problem

Every time we shipped a big system, we ran into the same wall.

We would get deep into the build, sometimes months in, and realize we had missed a data set. Or shaped the schema wrong. Or modeled two concepts as one thing when they needed to be two. And then we would do the ugly part: go back and wedge the missing data into a model that was never designed for it. Records got mixed up. Reports stopped matching. The internal model, once set, resisted every change we tried to make.

AI did not save us from this. In some ways it made it worse. A grounded LLM is a real accelerant, but an ungrounded LLM writing against a wobbly schema just produces more wobbly output, faster.

The tension underneath all of it is the one every experienced team knows. Build the model too complex up front and you have to roll it back when the business case turns out to be smaller than you thought. Build it too simple and you hit a wall the first time reality asks a question the schema cannot answer. Either way you pay a tax.

We kept circling one question through all of this. How do we take advantage of the design work that experts in a domain have already done, instead of guessing our way to a schema every single time?

What We Learned

If someone has already built a well-established data model for how information in a domain talks about itself, we should stand on their shoulders.

That is what ontologies are. Not academic curiosities. Decades of domain-expert thinking about how a domain's data should be shaped, argued over, refined, and published for anyone to use. Biomedicine has been at it since the nineties. Finance has FIBO. Manufacturing, logistics, geography, media, government - they all have mature ontologies sitting in registries, waiting to be picked up.

We wrote before about why you should build an ontology and how to find the ones that already exist. This post is what comes next: the discipline of actually using them without falling into a new trap.

The lesson is simple. When you skip prior art, you are not being pragmatic. You are re-litigating decisions that smarter, more specialized people already settled years ago. And you are asking your LLM to guess at a domain it was never grounded in.

What You Can Do About It

Do not start with the app. Start with the business case, then find prior art, then scope it down with judgment. The order matters, and most teams get it backwards.

Here is the process we use.

Start with the business case. What are we actually building? What does this app need to do? Everything downstream is judged against this. Skip this step and you will either over-build or wander.
Find the ontology for the domain. Look at what exists, what is mature, what is actually used in the wild. Understand what is in it, what is missing, and where it is strong. This is where our new tool comes in: ontologies.periscoped.io is a worldwide index of ontologies, crawled from GitHub and the broader web, exposed through a single API call, with a semantic chatbot and a viewer on top so you can browse what is out there without building your own crawler.
Scope a lightweight version to the business case. There is a good chance you do not need the full ontology, so use judgment. Map what you need for now. Most of the time less is right, and you should default to less until the business case proves otherwise. This is the step that separates a project that ships from one that dies under its own weight.
Write the scope decision down. In your project notes, capture something like: "we are using a lightweight version of ontology X, version 1, scoped to these entities and these concepts." This becomes the anchor for every future extension. Without it, the scope decision gets lost, the next person (or the next LLM session) drifts, and you end up with a schema no one can defend.
Map that scoped slice to DDL. Turn the selected concepts into a real SQL schema. Now the abstract is concrete, and it is concrete only where it needs to be.
Comment every field in plain English. Not for the humans reading the schema later, for the LLM that is going to work against it. Plain-English field comments are what make AI-assisted development actually work.
Build the API layer on top of the schema. REST, clean, boring. The schema does the thinking.
Build a dead-simple admin panel. Log in, see the data, poke at it. You need to feel the model before you build on it.
Only then start on the application. By the time you get here, the foundation is trustworthy and the LLM working alongside you is grounded in a real domain model.

The principle to hold onto is this. You probably do not need the whole ontology, and you should be explicit with the LLM about that. If you hand it an ontology and say "build me a schema," it will go crazy and try to implement the entire thing, and you end up right back at the too-complex problem we started with. The instruction is not "use this ontology." The instruction is "give me a lightweight version of ontology X, version 1, scoped to this business case." Then write that decision down in your project notes so the scope is durable.

Disciplined selection from prior art, plus a written record of what you selected, is what keeps the foundation trustworthy months later.

That is the leverage. The ontology is the prior art. The business case is the filter. The written scope note is the memory. The LLM is the accelerant. Miss any of them and you are back to guessing.

Why It Matters

The counterintuitive part is that going slower up front is what makes you fast.

Every hour spent on the business case, the ontology search, the scope note, and the admin panel buys back days later. Not in some vague productivity sense. In real, measurable retrofit work that never has to happen. The retrofit tax is not a rounding error. It is an order of magnitude larger than the ontology-scoping work it would have prevented. We have paid it. We would rather not pay it again, and we would rather our clients not pay it either.

When the foundation is built this way, everything downstream changes.

The foundation holds. You are not retrofitting six months in. The schema was shaped by domain experts before you ever touched it, filtered through a real business case, and you have a written record of what is in and what is out. When the business asks for the next thing, you extend the model instead of rebuilding it.

The LLM actually helps. Grounded in a real ontology and a schema with plain-English comments, the LLM stops guessing. It writes migrations that make sense. It writes queries that match the domain. It writes application code that respects the model. The productivity jump is not incremental, it compounds every day you work in that codebase.

There is less painful data wedging. No more shoving fields into tables that were not designed for them. No more mixed-up records because two concepts got flattened into one column. The data model was right the first time, because it was borrowed from people who had already thought it through.

And the punchline is the one that trips teams up when they first see it. You get to a working app sooner, not later. The days you spent on the ontology and the scope note and the admin panel would have been paid back three or four times over by the retrofits you were about to do. Going slower on the foundation is not a tradeoff against speed. It is how you buy speed that lasts.

You stop fighting your own schema. You start building on top of it. And the tool that used to be the hardest part, finding the right prior art in the first place, is now a single API call.

ontologies.periscoped.io is live. It is one of the tools we built for ourselves first, because we were tired of paying the retrofit tax, and we think you will be too.