Why an Ontology Is Not Just a Database

I needed to build a data ontology for mapjson.com and thought it would be good to briefly write about it and explain what ontology is and why it is more than just some tables with joins and lookups. Consider trying to build a map of "Georgia", what does that mean?

The problem: names are ambiguous

"Georgia"  ──?──►  🇺🇸 Georgia, the US state
           ──?──►  🇬🇪 Georgia, the country near Turkey

A plain database can't help you here. Ask a database "give me Georgia" and it does exactly what you asked: it finds every row where the name matches and hands you both. Databases are great at lookups — "find the thing with this exact name" — but a lookup can't answer "which one did you mean?"

That question needs something extra. That something is an ontology.

A database stores facts. An ontology stores what facts mean.

Here's the simplest way to see the difference.

A database is like a phone book. It knows names and numbers. Ask it "who is Paris?" and it says "here's the row for Paris." That's it.

An ontology is like a family tree. It doesn't just know who Paris is — it knows Paris is a city, that it's the capital of France, that France is part of Europe. Things, their types, and their relationships:

        Earth
          │
       Europe
          │
       France ◄── is a country
          │
        Paris ◄── is a city, is the capital of France

And here's the trick: nobody ever wrote down "Paris is in Europe." The ontology figures it out by walking up the tree: Paris → France → Europe. If A is inside B, and B is inside C, then A is inside C. Kids know this instinctively — your bedroom is in your house, your house is in your town, so your bedroom is in your town. An ontology writes that same rule down in a form software can apply.

That walking-up-the-tree move is called inference, and it's the first thing a plain database doesn't do.

But the really useful part is disambiguation

Back to Georgia. Suppose someone sends MapJSON this batch of names to put on a map:

["Texas", "Ohio", "Georgia", "Florida"]

You already know the answer, don't you? Georgia is obviously the US state here. But how do you know? You didn't look it up anywhere. You used the company it keeps: Texas, Ohio, and Florida are all US states, so Georgia probably is too.

That reasoning — "judge a name by its neighbors" — is exactly what the mapjson ontology does. Here's how it works.

Step 1: Find every possible match

For each name, look up all the things it could mean:

"Texas"   ──► [ 🇺🇸 Texas, US state ]                 ✓ only one match — easy!
"Ohio"    ──► [ 🇺🇸 Ohio, US state ]                  ✓ only one match — easy!
"Florida" ──► [ 🇺🇸 Florida, US state ]               ✓ only one match — easy!
"Georgia" ──► [ 🇺🇸 Georgia, US state ]               ❓ two matches...
              [ 🇬🇪 Georgia, country ]                ❓ ...which one?!

Texas, Ohio, and Florida are anchors — names with only one possible meaning. They're the clues we'll use to work out which Georgia this is.

Step 2: Ask the anchors where they live

This is where the family tree becomes useful. Every place in the ontology has an ancestor path — the list of everything it's inside of:

Texas    ──►  { USA, North America, Earth }
Ohio     ──►  { USA, North America, Earth }
Florida  ──►  { USA, North America, Earth }

Stack them up and count how often each ancestor appears. This gives us the batch profile — a picture of where this group of names "lives":

   BATCH PROFILE (from the 3 anchors)

   USA            ███  3 votes
   North America  ███  3 votes
   Earth          ███  3 votes

Step 3: Score each Georgia against the profile

Now take our two Georgia candidates and check their ancestor paths:

🇺🇸 Georgia (state)   ──►  { USA, North America, Earth }
🇬🇪 Georgia (country) ──►  { Asia, Earth }

How much does each one overlap with the batch profile?

                        USA    N.America   Earth    Asia
   Batch profile:        ✓        ✓          ✓
   ─────────────────────────────────────────────────────
   🇺🇸 Georgia (state)    ✓        ✓          ✓              overlap: 3/3 🎯
   🇬🇪 Georgia (country)                      ✓        ✓     overlap: 1/3

The US state matches on everything. The country only matches on "Earth." Case closed?

Not quite — there's one more step.

Step 4: Not all clues are equal

Notice something: everything is on Earth. Matching on "Earth" tells you nothing! It's like a detective saying "the suspect breathes air." True, but useless.

So the ontology gives each ancestor a weight based on how rare it is:

   Earth          ──►  contains everything      ──►  weight ≈ 0   (useless clue)
   North America  ──►  contains 40-ish places   ──►  weight = medium
   USA            ──►  contains 50 states       ──►  weight = HIGH (great clue!)

The rule: the fewer things a clue points to, the more it's worth. "The suspect breathes air" is worth nothing; "the suspect lives on Maple Street" is worth a lot.

Now redo the scores with weights:

   🇺🇸 Georgia (state):    USA(high) + N.America(med) + Earth(0)  =  BIG score
   🇬🇪 Georgia (country):                              Earth(0)  =  ~zero

Winner: the US state. Confidently, and for a reason the system can explain.

The same batch, flipped

Now send MapJSON a different batch:

["Georgia", "Turkey", "Armenia"]

Now the anchors are Armenia (only a country) and... well, Turkey is ambiguous too (country? bird? that is also a US town name). The ontology finds the reading where the whole group huddles together on the family tree:

   As countries:                     As US things:
                                     
        Asia ◄─── all 3 cluster       USA ◄─── only... some? barely?
       ╱  │  ╲    here! 🎯                │
  Georgia │ Armenia                    (weak, scattered)
        Turkey

Same word, "Georgia." Same algorithm. Opposite answer — because the neighbors changed. That's the whole point: the meaning of a name isn't stored in a row somewhere; it's computed from context, every time.

A database could never do this, because a database only answers the question you literally asked. An ontology answers the question you meant.

So what makes it "not just a database"?

Let's make the scorecard explicit:

And here's the irony: under the hood, the mapjson ontology lives inside a boring old PostgreSQL database. The tables are ordinary. What makes it an ontology is the shape of the knowledge (a tree of typed things and relationships) plus the reasoning that runs on top (tree-walking, batch profiles, weighted scoring). An ontology is a database plus a way of thinking.

Why this matters for maps

When you send mapjson a list like ["Georgia", "Texas", "Ohio"], you don't want a clarifying pop-up quiz. You want the map. The ontology is what lets a single API call take messy, human, ambiguous names and return exactly the boundaries you meant — because it reasons about your names the same way you would:

"Well, everything else here is a US state, so..."

And every time it gets one wrong and someone corrects it, that correction is remembered — the clue weights get a little sharper, the family tree a little richer. The system doesn't just store geography. It gets better at understanding what people mean by geography.

That's the difference. A database remembers. An ontology understands. Try to paste some keys into the resolve API call on MapJSON or explore the current data ontology.