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). The Reasoning lane EXTRACT 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, or import it from a standard format (see below), 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.

Import and export formats

You bring a schema in a standard format; Fontana maps it into the Fontana ontology JSON that powers gazetteer matching and schema-guided extraction. The table below is the supported standards surface:

Format	Direction	Mapping
LinkML (YAML)	Import and export (preferred authoring format)	Classes become entity types, slots and associations become relations and patterns, aliases become gazetteer terms
SKOS (Turtle or JSON-LD)	Import	Concepts become entity types or instances, prefLabel and altLabel become aliases, broader becomes hierarchy
OWL / RDFS	Mapped subset import	Classes, object properties, and domain/range become types and patterns; unsupported constructs (open-world reasoning axioms) are reported and skipped in a fail-closed listing
JSON-LD context	Export	Compact context for interoperability with your own RDF tooling

LinkML, SKOS, and OWL mapped-subset import, plus LinkML and JSON-LD context export, are available in Ontology studio Standards mode. Unsupported OWL reasoning axioms are listed in the import skip report and are never executed.

Fontana models ontology as closed-world, schema-first, in the LinkML tradition. RDF-standard import and export sit at the edges so you can keep tooling you already trust, while the internal contract stays a straightforward property-graph schema your gazetteer and extraction pipeline consume directly.

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 EXTRACT pass, and matching instance relationships are written in that run (no second extract 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.

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.