Ontology basics: entities, relationships, and sources

Three weeks ago you typed one line into a meeting note: "Jiwoo Park founded Haneul Robotics, which is headquartered in Busan." Today you want to ask, "who do I know that's connected to a robotics company in Busan?"

Folders can't answer that, and neither can tags, because no tag saw the question coming. But if that sentence was saved as structured facts, the answer sits one hop away.

This lesson follows a sentence into queryable facts without changing your Markdown. Facts from source notes can be re-extracted; export the graph, vocabulary, and human decisions together to preserve the complete ontology.

What an ontology actually is

An ontology is a shared vocabulary that answers two questions. First, what kinds of things exist? (people, organizations, places). Second, how do things relate? (founded, headquartered in, develops).

Now suppose every note's facts speak that one vocabulary. A fact from a 2024 meeting note and a fact from a 2026 reading note land in the same model and connect, even though the two notes never mention each other.

Consilience's ontology has three parts you'll meet here: a base vocabulary of 11 entity kinds, with custom refinements (what things are), an open vocabulary of relation verbs (how things connect), and literal attributes (plain values like dates and numbers). A fourth part, Statements, captures your own decisions and questions word for word; it gets its own lesson.

Entities have identity

In plain markdown, "PostgreSQL" is just a run of characters. Search finds those characters, but nothing in the file knows that the "PostgreSQL" in your January note and the "PostgreSQL" in your June note are the same thing.

The graph's first job is identity. Every extracted thing becomes an entity, and its address comes from its normalized label (trimmed, whitespace collapsed, lowercased). Mention "PostgreSQL" in twenty notes and all twenty mentions land on one node, and that node carries four things:

• A canonical display label: the name the entity shows everywhere.
• Aliases: other names your note actually prints, so every alias traces straight back to your own words.
• A one-line description of what the entity is or does.
• An optional kind, recorded per note, from the built-in kinds or your configured custom kinds.

Triples: subject, predicate, object

The graph stores exactly one shape of fact: the triple, which reads subject → predicate → object. "Jiwoo Park founded Haneul Robotics." The subject is the entity the fact is about. The predicate is the typed relation. The object is another entity, or a plain value. That's the whole atom. Anything you can say about your world breaks down into these.

When you save a note, the extractor reads each sentence and pulls out the entities it finds plus the relations between them. Here's our opening sentence, taken apart:

Sentence in your note:
  "Jiwoo Park founded Haneul Robotics, which is
   headquartered in Busan."

The facts it becomes:

  (Jiwoo Park)       is a                (Person)
  (Haneul Robotics)  is an               (Organization)
  (Busan)            is a                (Place)
  (Jiwoo Park)       founded →           (Haneul Robotics)
  (Haneul Robotics)  headquartered in →  (Busan)

Objects don't have to be entities. Numbers, dates, and measures are stored as literals, plain values that sit at the end of a triple. So "launched in 2024" becomes a value on the entity instead of a dead-end node cluttering your graph. Most of these come from imported tables and CSV rows.

Ontology

The shared vocabulary of what exists (kinds) and how things relate (predicates).

Entity

A thing with stable identity across notes, stored as a node rather than plain text.

Triple

Subject, predicate, object: the smallest complete fact.

Predicate

The typed relation linking a subject to an object, like founded or headquartered in.

Literal

A plain value (number, date, text) as a triple's object.

Named graph

A per-note container recording which note asserted each fact.

RDF

The W3C standard data model Consilience stores all of this in.

Named graphs: which note said this

A fact without a source is a rumor, so Consilience never stores a bare triple. Every workspace keeps its own local RDF store on your device, and every fact is filed inside a named graph that belongs to the note that asserted it. The graph's address is the note's workspace-relative path, so each fact is really a quad: subject, predicate, object, and source note.

Every fact is stored WITH the note that asserted it:

  (Haneul Robotics) headquartered in → (Busan)
      from note:  meetings/2026-03-kickoff.md

The source note comes straight from the note's path.
The "which note said this" record is built into every fact.

• Re-extract a note → only that note's graph is replaced; every other note's facts are untouched.
• Delete a note → its graph is dropped. Rename it → its graph is re-keyed to the new path.
• Your markdown is never touched. The graph is a parallel structure you can always rebuild from the files.
• It travels: the whole graph exports as a portable graph.nq file, and the Share dialog's "Include knowledge graph (ontology)" option bundles it for whoever you send it to.

Core and custom kinds, open verbs

The 11 built-in kinds provide a shared base for graph colors, tables, and filters. In Ontology, you can define custom kinds with a core parent. The extractor can select these refinements; if the evidence does not justify a kind, it leaves the entity untyped.

Relation verbs come straight from your notes' own wording. "headquartered in" stays "headquartered in", and Korean verbs survive as-is. The graph speaks your notes' language and always shows predicates as plain words. In the "Domain vocabulary" panel you can declare canonical predicates and their variants. Do that, and "made" and "개발하다" both fold into one "develops" edge at extraction time.

Query across documents through relationships

A file lives in exactly one folder, so a hierarchy forces every note into a single home. Tags are flat labels you have to think of ahead of time. A graph needs neither: every fact has its own address, so you follow relationships instead of retrieving documents, the way memory actually works.

• Multi-hop questions become mechanical: person → founded → company → headquartered in → city. "Who do I know connected to a robotics company in Busan?" is a two-hop walk.
• Unplanned questions work: nobody tagged anything "robotics-busan", yet the answer is still there, because facts compose.
• Convergence is automatic: twenty scattered notes that mention one project all land on the same node, and no note ever had to link to another.
• The agent can reason over it: structured facts with provenance give an AI something to traverse and cite, well beyond keyword search.

Recap: one model, every screen

You now hold the whole model. Notes are read into entities, which get their identity from a normalized label. Entities are connected by triples, and every triple lands in the named graph of the note that asserted it. Every graph screen in this course is a different window onto that one structure: the 3D view, the entity table, the profile pages.