Use the ontology output

Import the Compiled World ontology into RDF, linked-data and graph systems without losing validation, evidence or stable identity.

The two projections in every package

Every portable package includes ontology/knowledge.jsonld and ontology/knowledge.ttl. They are semantic projections of the Compiled World. The current export is RDF/JSON-LD with TAVONEL node kinds and compiled relation predicates; it should not be described as a hand-authored OWL/TBox schema. Keep provenance and validation beside the ontology, because the ontology is for semantic navigation and integration rather than a replacement for source evidence.

The predicates each engine emits

PredicateEmitted byHow it is derived
supported_byLive engine and fallback engineA claim to the evidence for one exact document version, carrying the evidence id
mentionsLive engine onlyA claim to an entity, from a case-folded match over capitalised phrases, acronyms and Korean organisation names in that claim's own sentence
contradictsLive engine onlyTwo claims that disagree on a number or on whether something is the case, inside one topic and one time reference. A candidate for review, not a resolution, and blind to jurisdiction, units and exception clauses
mentions_entityFallback engine onlyDocument-level co-occurrence from a capitalised-token scan, not read semantics
discusses_topicFallback engine onlyDocument-level co-occurrence from a small keyword rule set; the live engine has no Topic kind

Note Relations the ontology vocabulary could express and no engine emits — supports, supersedes, depends_on — are not in a package. Query for a predicate that is not in the table above and the result is empty rather than wrong. contradicts is in a package now and was not before, so a query written against an older export finds nothing rather than nothing being there; and a contradicts row is a flagged pair awaiting a person, never a decided conflict.

Loading it into a target system

TargetUseImportant companion
JSON-LD / linked-data applicationontology/knowledge.jsonldprovenance/activities.jsonl + validation/report.json
RDF store / SPARQL / RDF toolingontology/knowledge.ttlcanonical/model.json + provenance/ + validation/
Neo4j or another property-graph importgraph/nodes.csv + graph/relationships.csvKeep the same stable ids and evidence ids
Production AI or agentPrefer live MCP/APIThe active World stays current and preserves access/evidence resolution
  1. Read validation/report.json first. A review_required candidate is not approved organizational truth.
  2. Choose JSON-LD for linked-data JSON consumers, Turtle for RDF/SPARQL consumers, or the CSV graph for property-graph import.
  3. Preserve every urn:tavonel:<id> identifier. Those ids are the join key across ontology, canonical model, graph and evidence-bearing records.
  4. Do semantic traversal in the ontology, but resolve factual claims back to provenance/evidence before presenting them as grounded answers.
  5. Treat a signed ZIP as a snapshot. When the active World changes, import the newer signed projection or use MCP/API instead of editing the old snapshot in place.

Inspecting it with SPARQL

Portable SPARQL inspection
SELECT ?resource ?type ?label
WHERE {
  ?resource a ?type .
  OPTIONAL { ?resource <http://www.w3.org/2000/01/rdf-schema#label> ?label }
}
LIMIT 50

Note The Turtle projection serializes node types, rdfs:label values and compiled relations. The JSON-LD projection also carries node evidence references through the PROV mapping in its context. For exact source locators, keep the provenance/evidence material from the same signed package.

API version 2026-09-02.1 · reviewed 11 September 2026

Something here out of date or wrong? Report an issue with this page.