Platform

The ontology: your wiki as queryable, governed linked data

Wikantik doesn't just store prose — it maintains a formal model of what every page is about. Pages, clusters, tags, and LLM-extracted entities are projected into a wikantik: RDF/OWL ontology with stable, dereferenceable IRIs and public mappings to schema.org, SKOS, Dublin Core, and PROV-O. The wiki becomes standards-based linked data you can query with SPARQL — and it's curated by humans and AI agents under one schema, one validation gate, and one audit trail.

What the ontology is

The ontology is one model with three layers, projected from PostgreSQL into a Jena TDB2 triple store with RDFS inference:

  • The vocabulary (T-Box). The closed definitions everything conforms to — 9 entity classes, 5 content classes, and 21 typed relation predicates with domain/range, plus a SKOS concept scheme. Each maps out to public vocabularies (schema.org, SKOS, Dublin Core, PROV-O), so the model speaks the web's language, not a private one.
  • Page concepts. Every page is a typed concept — its content class, IRI, title and summary — and its cluster and tags become SKOS concepts it links to. This is the topical hierarchy, authored entirely from page frontmatter.
  • The Knowledge Graph. The entities mentioned across the wiki and the typed relations among them, projected as instances of the vocabulary's classes and predicates.

The model stays in sync automatically: a page's graph is re-projected when it's saved or renamed, and a nightly job reconciles the entity graphs — so the RDF is never stale for long.

Use case: ask the graph, don't grep the text

Keyword search maps terms to documents. An ontology maps concepts to one another — so you can ask structured questions a text index can't answer. A public, read-only SPARQL endpoint at /sparql takes SELECT / ASK / CONSTRUCT queries:

  • "Which technologies implement a given concept?" — follow the typed wk:implements edges.
  • "What's in this cluster, and what does it relate to?" — traverse skos:broader and the relation predicates.
  • "Give me every runbook verified in the last quarter, as JSON-LD." — filter on the projected metadata.

Every resource dereferences at /id/{type}/{id} as JSON-LD or Turtle (e.g. a page's /id/page/{canonical_id}), and the whole model is downloadable as a live Turtle dump or N-Triples. A public/restricted ACL split means content that isn't anonymously viewable never materialises in the public dataset — so the linked-data surface is safe to expose. Any RDF tool — a triple store, a SPARQL dashboard, a reasoner — can consume the wiki directly.

Use case: governed shared human + AI curation

Most "AI wiki" tools bolt a chatbot onto a document store. Wikantik makes the model itself a shared, governed artifact that humans and agents build together without it drifting between a human convention and an agent's guesses:

  • One schema. The structured frontmatter editor, the page Knowledge tab, the admin panel, and the MCP tools an agent calls all read the same server-authoritative schema and return the same suggestion-bearing validation messages — so an agent self-corrects exactly like a person does.
  • A write-time SHACL gate. Structurally invalid relations are refused at write time, citing the violated shape — there is no path, human or machine, that bypasses it.
  • Provenance & audit. Every entity and edge carries provenance (human-authored, human-curated, AI-inferred, AI-reviewed), and administrative changes land in a tamper-evident, hash-chained audit log.
  • A drift burn-down dashboard. A corpus-wide sweep counts every remaining metadata warning and SHACL non-conformance, with trends and per-item drill-downs — so inconsistency is measurable and can be driven to zero.

SEO that can't drift

A page's public structured data and its internal model are two faces of one truth: the schema.org @type and sameAs emitted for search engines are re-sourced from the ontology (a hub becomes a CollectionPage, a runbook a HowTo, a design doc a TechArticle). You can't have rich, correct structured data that silently disagrees with what the wiki actually models — because they come from the same place.

The Knowledge Graph and the ontology

The Knowledge Graph is the extracted entities and edges in the database; the ontology is the formal RDF/OWL model layered over the whole wiki — those entities plus page concepts and SKOS clusters/tags — that makes all of it queryable, standards-based linked data. They're complementary: the Knowledge Graph supplies much of the substance, the ontology supplies the schema, the IRIs, and the query surface. (Neither is the Page Graph, which is the separate graph of real wikilinks used for navigation.)

Frequently asked questions

What is the difference between the Knowledge Graph and the ontology?

The Knowledge Graph is the LLM-extracted entities and edges stored in the database. The ontology is the formal RDF/OWL model layered over the whole wiki — those entities, plus each page as a typed concept and each cluster and tag as a SKOS concept — all conforming to one vocabulary and queryable over SPARQL.

Can I query the wiki with SPARQL?

Yes — a public, read-only endpoint at /sparql accepts SELECT, ASK, and CONSTRUCT (with a result cap and timeout). Resources dereference at /id/{type}/{id} as JSON-LD or Turtle, and full dumps live at /export/ontology.ttl and /export/graph.nt. A public/restricted ACL split keeps non-public content out of the dataset.

How is the ontology kept correct as humans and AI agents both edit it?

Every curation surface reads the same schema and passes through the same write-time SHACL gate, provenance stamping, and audit log; invalid relations are refused at write time. A corpus-wide drift dashboard tracks any remaining inconsistencies so they can be burned down to zero.