Ontology

An ontology is the schema layer that turns provisional keyword mentions into a typed world model: entity types, relation types, and the patterns that connect them (Owner -[:HAS]-> Pet). Fontana’s Ontology Builder is standalone and runnable at any point in a namespace’s life: you can publish a schema before a single file exists, or upload your corpus first and let Fontana propose one from what it finds.

Schema and facts are separate layers

The ontology is the schema (Owner -[:HAS]-> Pet as types and an allowed pattern), stored as published JSON. Instances (Peter -[:HAS]-> Mittens) are Falkor entities and typed relationships. Structure INDEX can write instance relationships against published patterns (for example typed table links), and NER recognises entities in prose. The Ontology Agent reviews what those lanes produced and invents or reuses patterns and facts under your evolution policy. Publishing a schema never invents facts by itself.

Building an ontology

You can build a schema through any combination of three sources:

• Bring your own: author a schema directly in the Fontana ontology JSON format, then publish.
• Algorithmic mining: Fontana’s free, no-LLM miner reads structure that is already explicit in your corpus (CSV and spreadsheet column headers, markdown table headers, repeated capitalized phrases and acronyms, folder and filename patterns) and emits draft candidate types with evidence counts for you to review.
• AI discovery: on demand, Fontana samples representative chunks from your corpus and proposes a schema (entity types, relation patterns, aliases) using your namespace’s strongest configured model, since schema errors compound into every downstream extraction. You edit the proposal, then publish.

Neither order is privileged: schema-first and data-first namespaces both consume the same publish step, and publishing a schema for the first time triggers a cheap keyword re-index (seconds per file, no LLM) rather than a full reprocess.

Schema format

Fontana keeps your schema as Fontana ontology JSON: a closed-world, schema-first property-graph schema that your gazetteer matching and schema-guided extraction consume directly. Fontana does not import or export LinkML, SKOS, OWL, RDFS, or JSON-LD today. If you maintain a schema in one of those formats, translate it into Fontana ontology JSON before you publish it.

Evolution policy: strict, log, evolve

During extraction, an LLM inevitably encounters entities or relationships that do not fit your published schema. You choose what happens to that off-schema signal, per namespace:

Policy	Behavior
strict	Off-schema types and patterns are dropped; only schema-conforming facts are written
log	Off-schema patterns (entity type → relation type → entity type) are queued in the proposal inbox with endpoint evidence; unknown instance relationships are not written until you accept and publish
evolve (default)	Off-schema patterns are applied to the published ontology in the same review pass, and matching instance relationships are written in that run (no second run solely to unlock the fact)

Under log, schema drift is an explicit review decision in the proposal inbox. Under evolve, Fontana grows the schema and writes the fact together; the inbox stays empty for that path.

Where the ontology is kept

A namespace keeps its ontology as a file in Fontana Files, .fontana/kg/ontology.json. The file holds the draft and published schema, the evolution policy, the proposals that were accepted or rejected, and the proposals the Ontology Agent made that still wait for review. Every change to the ontology is written to that file first and to the graph after it: the evolution policy you set in KG Studio, a term the Ontology Agent proposes, or a proposal your policy applies. Proposals mined from your documents, and the evidence behind them, are not kept in the file; they come back when the graph reloads your documents’ processing results.

What the Ontology Agent writes about instances, its facts, the entity types it sets and the entities it merges, is appended to .fontana/kg/manual-triples.jsonl in the same namespace before it reaches the graph. Merge decisions go to .fontana/kg/finalize-decisions.jsonl. When the graph is rebuilt, Fontana loads the ontology first, then your documents’ processing results, then these files in the order they were written, so the rebuilt graph holds the same schema and the same curated facts without a model call. See Architecture.

Provenance of mined types

Every entity type Fontana mines from your documents keeps a record of where it came from: the documents whose headings, table headers, acronyms, or capitalised phrases produced it, and how often it occurred in each. Select a type in the KG Studio graph to see its Provenance, and switch on Entity types with Entities to see every entity attached to its type. When you reprocess or delete a document, its evidence is updated with it.

What publishing does and does not invalidate

Publishing a new ontology version is cheap for most of your corpus:

Data	Effect of a new publish
Chunks, outline, full-text index, embeddings	Untouched; never invalidated by a schema change
Keyword mentions and co-occurrence signals	A cheap keyword re-index job re-scans each file (seconds per file, no LLM)
Typed relationships and LLM-derived mentions	Marked extract-stale (hash mismatch); re-extraction is explicit and budgeted, not automatic

This is what makes running the Ontology Builder at any time safe: the expensive layers of your pipeline, parsing and embedding, are schema-independent by construction, so evolving your schema never forces a full reprocess of a large corpus.