Every detective drama has the same wall. Photographs, newspaper clippings, index cards, and red string running between them in every direction. The camera pans across it and we are meant to feel that the detective is close to something. But look at the wall for a moment as a piece of information. What does a piece of string say? It says: these two are connected. Connected how? The string doesn’t know. The detective knows, for now, and when the detective is gone the wall is a collection of photographs and some string.
Most of us build walls like that, only digitally. A note links to another note, a page links to a page, a card sits in a folder next to another card. Each link records that at some moment we saw a connection. It does not record what the connection was, and so the link’s value decays with our memory of making it.
This post is about the alternative: a graph in which every line carries a direction and a type, so that the line itself says what kind of connection it is. It starts with a little theory about graphs, moves on to why two particular kinds of relationship keep showing up in every classification humans have ever built, and then gets practical: how relationship types work in Knogra, how to define your own, and how to make the AI assistant think in your relationship types rather than in undifferentiated “related to”.
A line, an arrow, a sentence
In the mathematics of graphs, a graph is a set of nodes and a set of edges, and an edge is nothing more than a pair of nodes. That is the corkboard: string between photographs. Such a graph can still tell you things. It can tell you which nodes have many connections and which have few, whether the whole thing is one piece or several, how many steps it takes to get from one node to another. What it cannot tell you is anything about any single edge, because every edge is the same.
The first thing you can add to an edge is a direction. Now an edge runs from one node to another, and the graph is a directed graph. This is a small change and a large one. “Rome” and “Empire” joined by a line are two words with a string between them. “Rome” with an arrow to “Empire” is already an assertion that the two are not symmetric: one of them is the start of something and the other the end. A family tree is a directed graph; so is a flowchart, a food chain, a chain of citations. In each case the direction is most of the information.
The second thing you can add is a label: a word or phrase on the edge naming what kind of relationship it is. Now “Rome” with an arrow labelled “is the capital of” pointing to “Empire” is a complete sentence. Subject, verb, object. This is not an analogy: the labelled directed edge is exactly the form the semantic web settled on for knowledge, the triple, and it is what “knowledge graph” means when the phrase is used with any precision. A graph of labelled directed edges is a collection of sentences that happen to share their nouns.
That sharing is the point. Three sentences, “Rome is the capital of the Empire”, “Augustus rules the Empire”, “Augustus lives in Rome”, written on a page, are three sentences. Drawn as a graph they are three nodes and three edges, and the graph shows something the page did not: that the three facts close into a triangle. A fourth sentence about Augustus attaches to the node that already exists, and now everything you know about Augustus is in one place, reachable from anything else you know about him. The edges are what make it one body of knowledge rather than a pile of statements.
Two relationships that built every classification
If you look at the classifications people have actually made, from Aristotle’s genus and species through Linnaeus’s kingdoms and orders to the class hierarchies in a modern programming language, the same two relationships keep doing most of the work.
The first is kind-of. A sedan is a kind of car; a car is a kind of vehicle. Linguists call it hyponymy, and WordNet, the largest hand-built lexical database of English, organises every noun in the language into a single hierarchy of it, with “entity” at the top. What makes kind-of special is inheritance: whatever is true of cars is true of sedans, so when you learn something about the general case you have learned it about every specific case below it. A kind-of hierarchy is a machine for not repeating yourself.
The second is part-of. An engine is part of a car; a piston is part of an engine. Philosophers call the study of it mereology; WordNet calls it meronymy and tracks it separately from kind-of, because the two behave differently. A part does not inherit the properties of its whole: an engine is not a kind of car and does not have four seats. A part can belong to several wholes at once. And parts have a peculiar relation to existence: take enough of them away and the whole is gone, which is not true of kinds.
Anyone who has drawn a software diagram has met these two under other names. UML, the diagramming standard, gives them different arrowheads, a hollow triangle for generalization and a diamond for composition, precisely because a reader needs to tell them apart at a glance and the two are so easily confused. “Wheel” under “Car” could mean a wheel is a kind of car (wrong) or a wheel is part of a car (right), and nothing but the arrowhead settles it.
Then there is everything else. Rome is the capital of the Empire: not a kind, not a part. Augustus rules the Empire. Caesar precedes Augustus. Entanglement contradicts locality. Once you leave kinds and parts, the relationships stop forming neat hierarchies and start forming the real texture of a subject, and no fixed list of them fits every subject. A history is full of “precedes” and “causes”; a legal corpus is full of “cites” and “overrules”; a body of arguments is full of “supports” and “contradicts”. The vocabulary of relationships is itself part of what you know about a field.
Why naming the relationship is where the thinking happens
Joseph Novak, who developed concept mapping in the 1970s as a way of studying how children learn science, insisted on one rule that most diagram tools ignore: every link between two concepts must carry a linking word, so that concept, link and concept together read as a proposition. “Sky is blue” is a proposition; “sky” and “blue” with a line between them is not. His argument was that knowledge is stored as propositions, not as concepts, and that a map without linking words has left out the thing that was actually learned.
There is a practical version of this that anyone who has tried it recognises. Putting a line between two ideas is easy and feels productive. Being forced to say what the line means is hard, and it is hard because it makes you find out whether you actually know. Is superposition a part of quantum mechanics, or a consequence of it, or one of its postulates? You had a feeling they were connected. Naming the connection turns the feeling into a claim you can be wrong about, and a claim you can be wrong about is one you can check, refine, and build on.
Donella Meadows, writing about systems, made a related point from the other direction. A system, she said, consists of elements, the interconnections between them, and a purpose, and of the three the elements are the least important. Replace all the players on a football team and it is still a football team; change the rules that connect them and you have a different game. Most people, mapping a subject, spend their effort on the elements, on collecting concepts, and treat the interconnections as afterthoughts. Meadows’s point is that the interconnections are where the system’s behaviour lives. A body of knowledge is the same: what you know about a subject is much more in how its concepts relate than in the list of concepts.
So a graph whose edges have types is not a tidier version of a graph whose edges don’t. It records a different and larger thing. Each typed edge is a claim you made, in a vocabulary you chose, and the graph as a whole is a structure that can be read, questioned and extended by someone who was not there when you drew it, including you in a year, and including an AI assistant in the next minute.
Relationship types in Knogra
Knogra calls relationships edges, after the mathematics, and the type of an edge is its edge type. The rest of the app’s vocabulary is worth setting out once, because the words are used interchangeably and it helps to know they all mean the same thing.
An edge, a relationship and a connection are one thing: a link between two nodes. Every edge has a direction, and the two ends have several names too. The end an edge starts from is its source; Knogra’s menus call that node the parent, and it is the broader or bigger of the two, the whole, the general case. The end the edge points to is its target, the child, the narrower or smaller one, the part, the specific case. So an edge runs from the whole to the part and from the general to the specific: Car has part Engine, Vehicle has kind Car. If you have used a mind-mapping tool, this is the direction you already expect, out from the centre toward the details.
Every workspace, meaning every graph you build, has its own set of edge types. It is yours: you can rename the types, describe them, and add new ones, and the set travels with the graph when you export it. Each type has four things you can write.
| Field | What it holds |
|---|---|
| Name | The short handle, shown in menus and on the shelf |
| Description | What the relationship means, in your own words, as long as you like |
| Forward label | How an edge of this type reads from source to target: “has part” |
| Inverse label | How it reads from target back to source: “is part of” |
The labels turn every edge into a readable sentence in both directions. The description is where the meaning actually lives, and it matters more than it looks, for a reason that will become clear in the next section.
A new workspace starts with three edge types, and they follow directly from the two sections above.
| Type | Meaning | Reads forward | Reads back |
|---|---|---|---|
| Generalization | General to specific | Vehicle has kind Car | Car is a kind of Vehicle |
| Composition | Whole to part | Car has part Engine | Engine is part of Car |
| Association | Everything else | Rome relates to Empire | Empire is related to Rome |
The first two are the two relationships every classification is built on, and they draw with the arrowheads UML readers will recognise, the triangle and the diamond. The third is the honest name for a connection you have not classified further; it still has a direction, because every edge does, but its two labels differ only in voice. There are three because three is the smallest set that can hold a hierarchy and still leave room for what is not one, and because three distinct line styles is about as many as an eye can tell apart on a busy canvas, so each theme in Knogra draws three and the starter types take one each.
That is a starting point, not a recommendation. The three types are what a graph gets before you have told it anything about your subject. A graph of historical events may want “precedes” and “causes” and have no use for “part of” at all. A graph of arguments wants “supports” and “contradicts”. A graph of a codebase wants “depends on” and “calls”. A biochemist wants “regulates”, “produces”, “inhibits”. You can keep the starters, rename them, add five more, or add one more; the vocabulary of relationships is part of what you are modelling, and the right one is whichever lets your edges say what you mean. The only cost of many types is the one the corkboard already taught: the more kinds of string, the more the reader has to hold in mind, so each type you add should earn its place by saying something the others could not.
Asking the assistant for a particular relationship
Knogra’s AI assistant can propose new concepts for your graph and can find existing ones that belong in the scene you are working on. It never edits the graph itself: every proposal lands on the node shelf with a one-line reason, and you accept or discard each one. What this section is about is how you tell it what kind of proposal you want.
The assistant knows your edge types. Not a generic notion of “generalization” but your names, your descriptions, and your labels, sent with every request. When it reads your graph, it reads every edge as a sentence in your labels, “Quantum physics has part Superposition”, and when it proposes a concept it says which type of edge should connect it and in which direction. This is why the description field matters: if you write in it that Composition, for this graph, means “a named component in a standard textbook decomposition of the topic, not a prerequisite and not an application”, then that is what the assistant will understand by Composition, and its suggestions will follow the distinction you drew.
So when you ask for suggestions you can ask for a relationship, not just for concepts. Below the chat box are the buttons Suggest, for new concepts, and Connect, for existing nodes elsewhere in your graph that belong in this scene. Hover over either and a small menu opens.
Three rows. Child asks for concepts that would sit below the current node, at the narrow end of an edge starting from it: its parts, its kinds, its instances. Parent asks for concepts that would sit above it, at the broad end of an edge pointing to it: what it is a kind of, what it is part of. Any asks for concepts related to it in whatever way fits. Each row opens onto the list of your edge types.
This gives you four ways of asking, from loosest to tightest, and it is worth being deliberate about which one you want.
Click Any, and the assistant is free on both counts: it chooses concepts related to your node in any way, and for each one it names the type and direction it thinks fit. This is the wide net. Good for a node you know little about yet, or for finding the connections you had not thought of.
Click Child or Parent and stop there, and you have fixed the direction but left the type open. “Give me things below Quantum physics” will return a mixture: some parts, some kinds, some things that merely hang off it, each with the assistant’s guess at the type. Useful when you know which way you want the graph to grow but not what kind of edge the results will need.
Choose a type under Any, and you have fixed the type but left the direction open: “anything joined to this node by Association, in either direction”.
Choose a type under Child or Parent, and you have said exactly what you want, and the assistant is told that every concept it proposes must fit that one edge and no other, however relevant the others might seem. This is the narrow, sharp request, and it is where the feature pays for itself.
Take a node called Quantum physics. Parent plus Generalization asks: what is Quantum physics a kind of? The answer is short and specific, something like Modern physics, or Physics, and nothing else, because nothing else fits the sentence “X has kind Quantum physics”. Child plus Composition asks: what are its parts? Superposition, Entanglement, Wave function, Measurement. Child plus Generalization asks a different question again: what are its kinds? Quantum mechanics, Quantum field theory, Quantum information theory. Child plus Association asks for what is related but is neither part nor kind: Quantum computing, perhaps, or the Copenhagen interpretation. The same node, four requests, four sets of results that barely overlap, and each set sorted into the right relationship before it reaches you.
Compare that with a single request for “related concepts”, which returns all of the above mixed together, with the relationship left for you to work out for each one. Fixing the relationship in advance does two things. It makes the results sharper, because the assistant is answering a precise question. And it makes the results cheaper to review, because you already know what each proposal claims. Accepting “Entanglement” as a part of Quantum physics is a different decision from accepting it as a kind, and with the relationship named you make that decision once, when you send the request, rather than once per proposal on the shelf.
Whatever you chose in the menu is what you get. If you asked for children of type Composition, every accepted proposal is connected as a Composition child, regardless of anything the assistant may have said about it. Where you left a choice open, the assistant’s choice stands, and you can see it on the shelf before accepting.
Connect works the same way, with the same menu, except that instead of inventing concepts it looks through the nodes already in your graph but not in the current scene, and proposes the ones that belong here. Parent plus Composition on Connect asks: which of my existing nodes is this one a part of? That is a question about your own graph, and a good way to find the edges you forgot to draw.
You can also just type. A message like “what would a physicist say are the postulates of this theory, as parts of it” is read with your edge types in view, and the assistant will name a type and direction for each proposal it makes. The menu is a shortcut for the questions you ask most, not the only door.
One way to work, out of many
Here is one pattern that uses all of the above. It suits a subject with a natural hierarchy, like a science or a discipline, and it is offered as an example rather than a method.
Start with the node you actually care about, the thing you want to understand, and ask upward first: Parent plus Generalization. This places it. It tells you what larger thing it is an instance of, and often that larger thing is where the vocabulary and the basic laws come from. Then ask downward with Composition: what are its parts. Now you have a spine, general above, parts below, and every edge on it says which it is.
Then move to a node on the spine and repeat. A graph built this way grows as a tree at first, which is fine; trees are easy to read and easy to navigate.
The cross-links come last, and this is where Association, or whatever types you have added for your subject, come in. Ask Any on a node that already has its spine and see what the assistant proposes that is neither part nor kind. Those are the edges that turn a tree into a graph, the ones that connect Entanglement to Locality, or Measurement to the Copenhagen interpretation, and they are usually the interesting ones.
Other subjects want other patterns. A history graph might have no spine at all and be nothing but “precedes” and “causes” edges, in which case the useful requests are Child plus Causes, “what did this bring about”, and Parent plus Causes, “what brought this about”. A graph of a debate might run entirely on Supports and Contradicts. The mechanics are the same: define the relationships that matter for your subject, describe each one in your own words, and then ask for them by name.
The wall, revisited
Go back to the detective’s wall. Its problem was never the photographs, and it was not even the string. It was that the string was all the same string, and so the wall could hold a connection but never a claim. Give each piece of string a direction and a meaning and the wall becomes something else: a set of statements about the case that another detective could read, dispute and extend.
A knowledge graph with typed relationships is that wall. Each edge is a small, checkable claim in a vocabulary you chose because it fits the subject, and the graph is the body of claims taken together. The assistant’s job is to propose new claims in that same vocabulary, sharply when you ask sharply and widely when you ask widely. Yours is to decide which are true. That decision, made one edge at a time, is what it means to know a subject rather than to have collected it.