JSON ontology

Business
Opinion
KnowledgeGraphs
A JSON Schema is not an ontology.

Everyone building LLM extraction pipelines is converging towards a JSON Schema (YAML same thing). It works really well, because function calling (say, Pydantic AI) and structured outputs all speaks JSON natively and you get typed, validated data out of your model.

But there’s a quiet assumption baked into that choice. A JSON Schema describes the shape of data, it has no concept of what the data means.

Here are 4 things it simply cannot do and why they matter once your knowledge graph grows past a few hundred nodes.

  1. Two extractions, two valid JSON objects, same real-world person. JSON Schema sees them as unrelated. OWL’s functional properties and owl:sameAs let a reasoner merge them automatically. Without this, your graph accumulates ghost duplicates indefinitely.

  2. A JSON Schema composes structure but it carries no semantic inheritance. OWL's rdfs:subClassOf means a reasoner knows a Researcher is a Person without you re-stating it everywhere. Add property chains and you get implicit relationships inferred from existing ones for free.

  3. SHACL validates relationships between nodes — every Contract must have exactly one signatory who is a verified Person. That’s a constraint you cannot express in JSON Schema at all.

  4. Not the least…the open-world assumption. A JSON Schema treats missing information as an error. OWL treats it as unknown. In a knowledge graph built from thousands of documents, most entities are partially described. That’s not a bug, rather the nature of real-world knowledge. The closed-world assumption is correct for API contracts. It’s wrong for knowledge graphs.

Now, of course I use YAML and JSON for POCs and MVPs. It’s easy and fun. My remarks above relate to production, scale and enterprise needs. The world is a complex place and the variety of approaches available reflects the variety of challenges and business needs.