Skip to main content

Overview

The ontology defines the schema of your knowledge graph — the types of entities (nodes) and relationships (edges) that Experio uses to organize extracted knowledge. A well-designed ontology ensures that information from different sources is connected meaningfully. At runtime the graph may be backed by Neo4j or FalkorDB depending on GRAPH_PROVIDER in System Settings. The ontology editor and schema semantics are the same; provider-specific behavior (for example certain analytics queries) is summarized in Graph backend (Neo4j & FalkorDB). Navigate to Admin > Graph > Ontology.

Visual Editor

The ontology is managed through an interactive visual editor:
  • Entity type nodes are displayed as draggable boxes on a canvas
  • Relationship edges connect entity types with labeled arrows
  • Zoom and pan to navigate the schema
  • Drag nodes to arrange the layout
  • Hide nodes from the canvas with the eye icon on the left list (session-only; not saved)

Filter by content type

The toolbar includes a content type dropdown. Use it to see which parts of the ontology a given content type actually extracts, without changing the saved schema.
  1. Leave All content types selected to see the full graph.
  2. Choose a content type. Nodes and relationships that are not in that type are hidden from the canvas. This uses the same hide behavior as the eye icon on each node in the left list.
  3. Click a remaining node and open Attributes. Attributes defined on the ontology but not selected on that content type are greyed out. They stay editable.
  4. Choose All content types again to restore the full graph.
The JSON view always shows the complete schema. Hiding a node with the eye icon is independent of the dropdown: clearing the filter does not un-hide nodes you hid by hand. The filter does not mark the ontology as unsaved. See Content Types for how a type selects a subset of this schema.

Permissions

  • Read-only users can view the ontology but cannot make changes
  • Write users can add, edit, and remove entity types and relationships

Asking the copilot

The Admin Copilot has a page pack for this page. Open it with the Copilot button or ⌘J and it can explain the schema, say what a change would break before you make it, check the schema for problems the save does not catch, and propose typed edits as a card. A proposal is checked on the server before you ever see it: the edits are applied to a copy of the schema, and the result must pass the same validation the save runs, be self-consistent, and come with the list of configurations the change would leave invalid or stale. Removing an entity type removes the relationships that touch it too, and the card names them. A card that would change nothing is refused. Applying a card only changes the canvas — the Save below is still what persists it, with the same impact confirmation. A card carries the whole resulting schema, so if the canvas no longer holds the schema it was made from (you edited or saved since, or applied another card), Apply asks first: applying replaces those newer changes, and Undo on the card puts them back. Rolling back a revision, resetting to the default and rebuilding an index have no copilot tool at all. It also has the tools of the other knowledge-model pages: it can check a saved artifact type you name, say what its Save would add, and propose a card for it that you apply in that artifact type’s editor. It can do the same for a saved data mapping, enrichment rule, matching strategy or taxonomy: checking it needs read access to that page, and a card needs write access. After a Save here that breaks mappings or rules, it proposes their cards by itself, one kind at a time (see Continue after a Save). The ontology tools work the same way from the Artifact Types, Taxonomies, Data Mapping, Enrichment Rules and Matching Strategies pages, over the saved ontology (see Knowledge-model pages share their tools). The copilot needs the same Graph Managers access as this page: without read access it offers no ontology tools, and without write access it explains but does not propose.

Entity Types

Entity types represent the categories of things in your knowledge graph. Common examples: Each entity type has:
  • Name — A unique identifier for the type
  • Properties — Attributes that instances of this type can have (e.g., Person has “name”, “email”, “title”)

Attribute types

Every attribute has a type, chosen from:
Prefer Enum over List or Text when the values really are a known, closed set (a status, a stage, a category). Extraction is more reliable against a fixed set, and the values stay reviewable.
Text and List attributes can additionally be marked for vector search, which includes them in the entity type’s embedding.

Relationships

Relationships define how entity types connect to each other. Examples:

Saving Changes

After modifying the ontology:
  1. Click Save. If the change renames or deletes schema elements (or otherwise breaks dependents), a confirmation modal lists the impact before anything is published.
  2. Confirm to persist the schema. Experio creates a new ontology revision, auto-updates matching names in content types, mappings, and related config, and sets those configs to stale or invalid as needed. A save that only changes details the revision check doesn’t compare (an entity type’s semantic intent or synonyms, an attribute’s instructions or options, or a relationship’s attributes) stores the schema but creates no revision and re-checks nothing.
  3. The canvas layout (node positions) is saved with the schema.
Deleting an entity type, attribute, or relationship does not silently rewrite or wipe downstream configuration. Affected content types, mappings, enrichment rules, and matching strategies keep their references and become invalid. Ingestion that uses those configs is blocked until you fix them and re-validate. See Ontology Compatibility.Existing nodes and edges already in the knowledge graph are not deleted.
Renames are applied automatically (for example, an entity type named Employee that you rename to Person updates matching names in configs). Those configs become stale so you can review them. Stale status warns in the admin UI; it does not block scans.

Revision history and rollback

Open History on the ontology editor, or go to Admin > Graph > Ontology > Revision history. The revisions list shows each published schema (newest first), who saved it, and a short change summary (additions, renames, breaking deletes). Select a revision to see a human-readable diff and the schema JSON.

Rollback

Write-access admins can restore a previous revision:
  1. Select the revision to restore (not the current one).
  2. Review the impact preview — the same confirmation used when saving.
  3. Confirm. Experio sets the live schema to that snapshot and publishes a new revision that records which revision you rolled back from.
Rollback does not rewrite content types or mappings to “fix” them. The compatibility engine re-checks every dependent config against the restored schema. You may still need to re-validate or edit configs afterward. The Audit tab on the history page logs revision publishes, rollbacks, and config re-validations.

Deleting an ontology

You cannot delete the default ontology. You also cannot delete an ontology that still has data mappings attached — remove or reassign those mappings first. After ingestion populates the graph, you can use Enrichment Rules to enrich it further. Enrichment rules process existing nodes and create new attributes, nodes, or relationships — all defined using the entity types and relationships in your ontology.

Best Practices

  • Start with a small, focused ontology and expand as needed
  • Use clear, descriptive names for entity types
  • Define relationships that reflect real-world connections in your organization
  • Review the ontology periodically as your data sources grow
  • After each save, check Ontology Compatibility and fix invalid configs before the next scan