Appearance
Why Backlinks Are Not the Same as Relationships
A link is a boolean. A relationship has a kind, a direction, a strength, an evidence base and a date. You cannot type your way to the difference.
Twenty-three linked mentions, and one question you can't answer
Open a concept you've been working on for a year. Say it's [[async writing]], and the page shows 23 linked mentions. That number feels like progress — twenty-three separate occasions when this idea earned its place in something you were writing.
Now try to use it.
Here's a question the list cannot answer: are you for it? Some of those 23 argue that writing things down asynchronously is what makes a distributed team work at all. One is a complaint that it mostly produces long documents nobody reads. A couple mention it only in passing, as a symptom of something else — the meetings you couldn't get out of. In the pane, all 23 look identical. Same bullet, same weight, same nothing.
Second question: which of them is load-bearing? One of those notes is where the idea actually came from. One is where you changed your mind about it. The rest are drive-by mentions. You can sort that list by title, or by date. There is no sort called by which one mattered.
Third question: is this still true? Most of the links may be from two years ago, when you were defending a decision, and the newest from a project where the same words have come to mean something almost opposite. A backlink carries no date in the sense that matters. It has a file modification time, which is a fact about the file.
The pane isn't broken. It is answering the question it was built to answer: where has this string appeared? That's a real question, and getting a fast, complete, always-current answer to it was a genuine advance. It just isn't the question you had.
The gap has a name. Joel Chan, an information scientist at Maryland who studies how people synthesise knowledge, calls it an information-model barrier — the obstacle isn't a missing feature, it's the model of information the tools are built on. Get the model wrong and no amount of interface work rescues it, because every feature you add is a better view of the wrong object.
Here is the wrong object, stated plainly:
A backlink records that two things touched. A relationship is a claim about how.
This essay is about the distance between those two sentences: what a relationship actually consists of, why the obvious fix — let people label their links — has been tried at least four times since 1983 and failed every time for the same non-technical reason, and what you can do instead. By the end you'll have five questions you can put to any single connection in your notes, and to any tool that claims to manage them.
Adjacency is not a relationship
Strip the vocabulary away and look at what your app actually stores when you type [[async writing]] into a note about onboarding.
It stores an unordered pair, and a true.
That's the whole record. Not a small record — an empty one, in a specific way. It has no kind: "supports," "contradicts," "is a special case of," "is the same idea I already had under a different name," and "I mentioned this while thinking about something else" all compile down to the identical line. It has no direction: the pair {onboarding, async writing} reads the same from both ends, though the two ideas are plainly not equally important to each other. It has no strength: one passing mention and a two-thousand-word argument produce the same edge. It has no evidence, in the sense of anything you can inspect to check the claim — the link is the claim, and it cites itself. And it has no time: nothing records when the relationship started, whether it has grown, or whether it quietly stopped being true in 2024.
Five properties. A backlink has none of them, and the tools built on top inherit the poverty: a graph view can only draw what the edge contains, and what the edge contains is true.
It's worth noticing that the field which actually studies relationships never treated a tie as a boolean, not even at the beginning. When Mark Granovetter wrote the paper that founded modern network sociology, his first move was to define what he was measuring: "the strength of a tie is a (probably linear) combination of the amount of time, the emotional intensity, the intimacy (mutual confiding), and the reciprocal services which characterize the tie" (Granovetter, 1973, p. 1361). Four dimensions, stated before a single result.
The definition earned its keep immediately. Granovetter argued — and reported the numbers a year later in Getting a Job — that people hear about work through their weak ties disproportionately often. Among professional, technical and managerial workers in his sample, 27.8% heard about the job they took through a weak tie against 16.7% through a strong one. The explanation is the interesting part: "Those to whom one is closest are likely to have the greatest overlap in contact with those one already knows, so that the information to which they are privy is likely to be much the same as that which one already has."
Hold on to that sentence. It is also a precise description of what goes wrong in a densely linked set of notes, and it will come back.
The point for now is narrower. That result cannot even be stated without tie strength. Strong ties and weak ties do different jobs, so a record that says only "connected" cannot tell you which kind you're holding, and therefore cannot tell you which of your connections is worth anything.
Two footnotes on the same page are worth more than most of what has been written about links since. In the first, Granovetter notes that the ties in his paper "are assumed to be positive and symmetric; a comprehensive theory might require discussion of negative and/or asymmetric ties, but this would add unnecessary complexity to the present, exploratory comments." In the second, he explains that treating strength as strong/weak/absent is a "substitution, for convenience of exposition, of discrete values for an underlying continuous variable."
Symmetric, and discrete: exactly the two simplifications a backlink makes. The difference is that Granovetter marked them as temporary scaffolding, in 1973, in the paper that started the field. Note-taking software shipped them as the data model.
The properties that make a relationship useful are precisely the ones the double bracket dropped.
Which raises the obvious question — were they ever there? They were. Three separate traditions worked this out before the double bracket existed, and each of them held on to a property we later let go.
Three traditions that had this worked out
1945: the trail had a name
Everyone credits Vannevar Bush with the ancestor of the hyperlink. Fewer people read what he actually specified, which is a shame, because the specification is more interesting than the credit.
In As We May Think the unit is not a link. It is a trail, and the first thing that happens to a trail is that it gets named: "When the user is building a trail, he names it, inserts the name in his code book, and taps it out on his keyboard." The second thing is that it has an order — "when numerous items have been thus joined together to form a trail, they can be reviewed in turn, rapidly or slowly, by deflecting a lever like that used for turning the pages of a book." The third is that it lasts: "the user taps a single key, and the items are permanently joined," and, in the line everyone quotes without noticing what it implies, "his trails do not fade."
The fourth is the one that gives the game away. A trail is an object you can hand to somebody. Bush's scientist, having built one, "sets a reproducer in action, photographs the whole trail out, and passes it to his friend for insertion in his own memex." There is a job title for the people who will do this professionally: "There is a new profession of trail blazers, those who find delight in the task of establishing useful trails through the enormous mass of the common record." And there is a claim about what such work leaves behind: "The inheritance from the master becomes, not only his additions to the world's record, but for his disciples the entire scaffolding by which they were erected."
The scaffolding. Not the documents — the structure that produced them.
Count what a 1945 trail carries: a name, an order, permanence, and independent existence. Count what arrived seventy-five years later in the tool you are using right now: an unordered pair and a true. The name went. The order went. The trail as an object went, leaving an adjacency you cannot name, cannot sequence, and cannot hand to anyone.
Mechanism 1: a relationship is a thing in its own right, with a name and an order — not a property hanging off the two documents at its ends.
1963: nobody had to declare anything
The January 1963 issue of American Documentation carried a paper by M. M. Kessler whose abstract opens: "This report describes the results of automatic processing of a large number of scientific papers according to a rigorously defined criterion of coupling."
Automatic processing. 1963. The criterion was bibliographic coupling: two papers are coupled when their reference lists overlap, and the more references they share, the stronger the coupling. Neither paper cites the other. Neither author declared anything about the other's work, or knew it existed. The relationship was computed out of what they both pointed at.
Ten years later Henry Small turned the arrow around. Co-citation, he wrote, is "defined as the frequency with which two documents are cited together" — A and B are related to the extent that later papers keep putting them in the same reference list.
Read that definition slowly, because something structurally strange is in it. The relationship between A and B is not a property of A. It is not a property of B. It is a property of what everyone else does with them. Which means it moves. Two papers can sit untouched on a shelf for a decade and grow closer together, or drift apart, because the field around them changed its mind about whether they belong to the same conversation. The documents are frozen. The relationship is not.
The two measures also disagree. Small reports that co-citation patterns "differ significantly from bibliographic coupling patterns" — same corpus, two ways of deriving relationships from it, two different answers, both useful, neither declared by anybody. What came out of the second one was a map: "Clusters of co-cited papers provide a new way to study the specialty structure of science."
Both measures work on your notes, unchanged. Two notes that link the same concept are coupled, whether or not you ever connected them. Two concepts that keep turning up in the same notes are co-cited, whether or not you ever thought of them together.
Mechanism 2: the relationships worth having are derived from the corpus rather than declared at the endpoints — and they are a function of time, not a fact stored once.
1983: someone already built the typed-link system
If you have ever thought "the fix is obvious, let me label my links," you are in good company and about forty years late.
Randall Trigg's 1983 doctoral dissertation at Maryland, A network-based approach to text handling for the online scientific community, worked the idea out in full. Not a handful of relationship types — Trigg catalogued eighty classes of link type, organised into a hierarchy, split at the top level between internal "substance" links and external "commentary" links, each broken into sub-classes and sub-sub-classes. The system built on it, TEXTNET, was described in ACM Transactions on Office Information Systems in 1987. This was a serious, complete, carefully reasoned answer to exactly the problem this essay is about, finished six years before Tim Berners-Lee wrote the proposal for the World Wide Web.
What happened next is the interesting part. By the mid-nineties, part of the research community had stopped asking people to pick a type and started trying to compute it. James Allan's Automatic Hypertext Link Typing, at Hypertext '96, opens by conceding that researchers "have seldom had marked success with automated approaches to linking documents by content," and then argues for pressing on — on the grounds that an automatically generated link is far more use when the system can also say what kind of link it just made.
Two sentences from that paper are worth keeping:
"A link type is a description of the relationship between the source and the destination of a link. As such, it cannot be determined by considering only the destination document: the document could be an example of one concept, and a counter-example of another. Nor are link types symmetrical: following a link may lead to an expanded discussion of a topic, but returning along the link will clearly not do the same."
Two independent fields, in different decades, wrote the same warning into the record. Granovetter marked symmetry as a simplification he was adopting for convenience in 1973; Allan states flatly in 1996 that link types are not symmetrical. The [[ ]] you typed this morning is symmetric.
Mechanism 3: kind is real, it points one way, and it cannot be read off either endpoint alone — so somebody, or something, has to supply it.
That is the whole tally. By 1996 the literature had all five properties on the table: kind, direction, strength, evidence and time. What shipped twenty-four years later, in the tools that finally made linked notes popular, had none of them.
Not because anyone was careless. Because every serious attempt to put them back has run into the same wall, and it isn't a technical one.
Four attempts to put the properties back
The obvious repair is to let the writer state the kind. Type the link, then say what it is. It has been tried at least four times at four different scales, by people who were not naive, and each attempt is worth understanding on its own terms before you notice what they have in common.
The complete taxonomy
Trigg's eighty link types are the maximal version: a full vocabulary, hierarchically organised, covering the rhetorical moves of scientific writing. For a bounded, conventional literature this is close to right — academic prose really does mostly support, refute, extend, review and cite as background, and a fixed vocabulary buys you machine-processable structure in return.
Look at what it costs at the point of use. Every time you connect two things, you stop, and you classify the connection into one of eighty categories in a hierarchy someone else designed. Not once, as a setup step — every time, forever.
The universal schema
The Semantic Web is the same idea rebuilt for everything. An RDF triple is a typed link and nothing else: subject, predicate, object. Kind and direction are not features bolted on; they are the data structure. It had a W3C working group, a standards stack, and two decades of serious engineering behind it.
Clay Shirky's 2003 assessment aged into the consensus: the Semantic Web "will improve all the areas of your life where you currently use syllogisms. Which is to say, almost nowhere." His diagnosis was not that the vision was wrong but that it "requires too much coordination and too much energy to effect in the real world, where deductive logic is less effective and shared worldview is harder to create than we often want to admit."
Two years earlier, Cory Doctorow had listed seven reasons the metadata would never show up. Be careful transplanting that essay, though — most of it is about public, competitive metadata, and the sharpest obstacle, "people lie," simply evaporates in a private notebook. Nobody games their own vault.
Two of the seven survive the move to a private system intact, and they are the two that do the damage. The first: "This laziness is bottomless. No amount of ease-of-use will end it." The second: "People are lousy observers of their own behaviors."
A third mutates instead of disappearing. Doctorow's argument that "reasonable people can disagree forever on how to describe something" seems inapplicable when the only person is you. It isn't. You across five years are not reliably one person. The word you would reach for today to describe how two ideas relate is not the word you reached for in 2023, and the vocabulary you settle on in month one is chosen at the exact moment you understand your material least.
Structure where the schema is already known
Notion relations, Tana's supertags, Dataview's inline fields, Obsidian's typed-link plugins. These work, they are well made, and it is worth being precise about why they work, because the reason is not "they tried harder."
They are used where the schema is known before the data exists. A meeting belongs to a project. A task has an owner. A paper has an author and a year. You know those relationships at the moment of writing because you knew them before you started writing — the shape of the domain was settled in advance. That is a database problem, and a database is the correct tool for it. If your work has that shape, use them; nothing in this essay argues otherwise.
The difficulty starts when the same machinery is aimed at thinking. Whatever the relationship between [[async writing]] and [[onboarding]] turns out to be, it was not known before the notes existed. Working it out is what the notes are for.
The serious version, for the hardest case
The strongest form of the argument is Joel Chan's discourse graphs: "an information model for bodies of knowledge that emphasize discourse moves (such as questions, claims, and evidence), and relations (such as support or opposition), rather than papers or sources as the main units."
This one deserves more than a nod. It is strong precisely because it doesn't try to type everything. It applies a small, purpose-built grammar to one job — research synthesis — where the moves really are questions, claims and evidence, and where "supports" and "opposes" really are the relations you need. If you are doing a literature review for a dissertation, a discourse graph will serve you better than anything described later in this essay, and I would tell you to go use one.
Chan is also the most careful person in this story about what is and isn't established. His own summary: "despite the significant hypothesized benefits of discourse graphs, we don't yet know very much about whether or how they work in scientific practice. Their efficacy in facilitating synthesis or increasing the speed of research advancement remains uncertain." And on the ancestor: judging that two things are "the same" is "problematic and difficult," and doing it without engagement with context "can sometimes introduce more destructive ambiguity, not less, a hard-won lesson from the history of Semantic Web."
What all four run into
The common wall is not effort, and it is not that people are too lazy to type one extra word. It is three things, and only the first is about labour.
Declaration can only annotate what you already noticed. This is the fatal one. Typing a kind onto a link presupposes the link — and the link presupposes that you already saw the connection and thought it worth recording. The relationships you most need are the ones sitting between two notes you have never once opened on the same day. There are, roughly, n² of those, and you will annotate none of them, because annotation is an operation on connections that already exist.
Be precise about the limit, because it is narrower than the usual complaint and harder to escape. A declared-relationship system can absolutely tell you things you had not consciously worked out: that is exactly what a discourse-graph query does when it finds every piece of evidence that informs your question but opposes a claim you believe. What it cannot do is reach a pair you never touched. Its recall is bounded by your attention, and its blind spot is the shape of your blind spot.
The kind is often unknown at write time. Recall Allan's point: a link type "cannot be determined by considering only the destination document." At the moment you type [[onboarding]] into a paragraph about async writing, you frequently do not yet know whether the second idea supports the first, complicates it, or is the same idea under a different name — and if you did know, you would not need the system. Requiring the type at write time guarantees the system records only the relationships that were already obvious.
Declared structure decays silently; derived structure doesn't. An unmaintained derived relationship simply recomputes itself next time, from whatever the corpus now says. An unmaintained declared relationship stays on the screen looking authoritative while quietly becoming false. A stale type is worse than no type, because you will believe it.
So the question was never whether relationships should have properties. Everyone from Bush onward agreed they should. The question is who supplies them — and any property that depends on you supplying it at write time will be missing in precisely the cases where you needed it most.
That reframing is what turns the five properties into something you can actually test a tool with.
Five questions to ask one relationship
Not a tool. One relationship. Pick two concepts in your own notes that keep turning up near each other — [[async writing]] and [[onboarding]], or whatever your equivalents are — and put these five questions to that single pair. Each one comes with a second question attached, which turns out to be the important one: who can answer this?
1. What kind of relationship is it? Not "are they related" but which of these: one is a precondition for the other, one is a special case of the other, one contradicts the other, one is the same idea you have been writing under two names, or they simply share a context and nothing more. Five very different situations, one undifferentiated line on a graph. Who can answer it: you — but often not on the day you first typed the link, and sometimes not for a year.
2. Which way does it point? Even a perfectly symmetric measurement can carry asymmetric meaning. Suppose async writing is the single strongest partner onboarding has, while onboarding sits seventh among async writing's partners. Identical pair, identical score, two entirely different facts: for one concept this is the defining neighbour, for the other it is one context among many. Rank is not symmetric even when overlap is. Who can answer it: your notes, already.
3. How strong is it, on a scale that compares? A raw count won't do. "Nine shared notes" means something triumphant for a concept that appears in twelve notes and something close to noise for one that appears in four hundred. You need a normalised figure, so that this pair can be ranked against every other pair you have. Who can answer it: your notes, already.
4. What would I have to read to check it? Every claimed relationship should come with its receipts: the specific notes that produced it, openable now. A relationship nobody can check is a rumour, and a computed one you cannot check is a rumour that has learned to sound precise. Who can answer it: your notes, already.
5. When did it become true, and is it still? A pair that co-occurred fifteen times in 2024 and never since is a finished conversation. A pair that has co-occurred four times this month is a live one. Same edge on the graph. Opposite instructions to you. Who can answer it: your notes, already.
Run the tally, because it is not what the argument seemed to be heading towards.
Four of the five questions are answerable right now, from material you have already written, with no new discipline, no schema, no vocabulary to agree with yourself about, and nothing typed at write time. Direction, strength, evidence and time are not missing from your notes. They are unread. Every one of them is a counting problem over things you already did, which is exactly the observation Kessler was acting on in 1963.
As a test of a tool, then, the five collapse into two questions. Which of the four does it actually compute for you? And does it leave the fifth alone, in a form that can hold a sentence?
The fifth is different in kind, and it is the one everybody tries to solve first. Kind is a judgment — about your own material, in your own vocabulary, at a moment when you finally understand the pair well enough to say something. Trigg tried to give it eighty boxes. RDF tried to give it a predicate. Notion gives it a relation property. Each of those is an attempt to compress a judgment into a token so a machine can carry it.
Here is the claim this essay has been walking towards. The kind of a relationship does not belong in a dropdown. It belongs in a sentence. "Async writing only pays off when onboarding is already written down, because the new person is the one who reads the archive" — that is a claim, it has a truth value, you can be wrong about it, and no controlled vocabulary can hold it. Compress it to supports and you have kept the least valuable part.
Which puts the job of the software somewhere unexpected. Not to help you file the judgment. To do the four counting problems well enough that you are standing in front of the one pair worth writing a sentence about.
Building for the four, and leaving the fifth alone
I'm the independent developer of Jotaid. The longer argument for why its unit is the concept rather than the note is in the first essay in this series; this section is only about the edge between two of them, and about the one property I deliberately don't try to capture.
Strength: one number, comparable across every pair
For any two concepts, Jotaid counts the notes that mention both and divides by the notes that mention either. Nine notes shared out of twenty-one that mention one or the other gives 0.43. That is the Jaccard index, it lands between 0 and 1, and its whole virtue is that it is comparable — a 0.43 in a corner of your notes where everything is thinly connected means the same thing as a 0.43 anywhere else.
Every pair gets a cell in a grid, and the strength reads as a five-segment bar, so that scanning a column is a matter of seeing relative weight rather than comparing decimals. (The matrix as an instrument deserves its own essay and will get one.)
One threshold in there is worth explaining, because it inverts the usual reading of a strong result. When a pair reaches 0.8, Jotaid stops congratulating you and flags it — in warning colour, labelled High Similarity. Two concepts that turn up together in eighty percent or more of the notes mentioning either of them are generally not two concepts. They are one concept you have been writing under two names, and the correct action is to merge them, not to admire the number. A strength measure that only ever says "more is better" isn't measuring anything.
Direction: the number is symmetric, the ranking is not
Jaccard is symmetric by construction. Rank isn't, and rank is where the meaning is.
Click a cell and the panel shows two lists side by side, one per concept: async writing co-occurring with… and onboarding co-occurring with…, each ranked, with the counterpart highlighted if it appears at all. Same pair, same score, two positions. Async writing might be the top partner onboarding has, while onboarding sits seventh in async writing's list — which tells you something no single number could: onboarding is largely about async writing, and async writing is about a lot of things, of which onboarding is one.
That asymmetry is exactly what Granovetter set aside as too complicated in 1973 and what Allan stated flatly in 1996. It costs nothing to compute. It just has to be shown from both ends instead of one.
Evidence: every relationship opens
No score in Jotaid is a dead end. A pair's panel carries the notes where the two concepts actually co-occur, with the full count, and each one opens. If the tool claims a relationship, you can be reading the sentences that produced the claim within two clicks. This is the property I would refuse to ship without: an automated relationship you cannot audit is a rumour with a confidence score attached.
The same principle governs how a concept's incoming references are presented, which is as three separate sections rather than one merged list:
- Backlinks — notes where you wrote
[[the concept]]. You did this on purpose. - Unlinked mentions — notes where the words appear but you never made the link. Found by a plain deterministic scan, no model involved, with a one-click Link on each row.
- Semantic backlinks — notes that discuss the concept without ever naming it. This one asks a model, on demand, and it is a Pro feature on your own API key.
Three tiers of how we know, kept apart on purpose. Merging them would produce a longer list and a worse one, because the top section is a record of your own decisions and the bottom is a machine's guess, and you should never have to wonder which you are looking at.
The note-level panel makes the same distinction. When Jotaid shows related notes, a row is labelled either by how many concepts the two notes share — a structural fact you created — or as Similar, meaning the two are close in the on-device semantic index without sharing any link at all. The comment sitting next to that code says why: shared links are a fact the user built, semantic proximity is only the model's judgment, and showing them identically leaves the reader with no way to tell why the tool thinks these two belong together.
The semantic rows deliberately show no percentage. 0.62 is not information a person can act on; it invites the question "how was that computed?" instead of the question "is this actually related?", and only the second one is any of your business.
Time: recent activity outranks structure
Each concept is classified by its position in your network. A Core node has references in the top fifth of your whole corpus and a tightly interconnected neighbourhood. A Bridge node has at least three neighbours who mostly don't know each other — the broker, sitting between clusters that would otherwise never meet.
Then there is Emerging: a concept that has picked up at least two new references in the last fourteen days. And Emerging overrides the other two. If a node qualifies as both Core and Emerging, it shows as Emerging, because a structural fact about your last three years is less useful to you this morning than a fact about your last two weeks.
Being honest about the limit: this is a coarse instrument. It is a flag on a concept, not a history of a relationship. Jotaid does not store how a given pair's strength moved over five years, and answering "was this always true?" precisely would need a time series it doesn't keep. Of the four countable properties, time is the one I've done least with.
The network-level version of the same idea
Remember Granovetter's explanation for why weak ties carry the useful information — those closest to you have "the greatest overlap in contact with those one already knows," so what they know "is likely to be much the same as that which one already has."
Read that as a description of a set of notes and it stops being a nice observation and becomes a diagnosis. A knowledge network where everything connects to everything nearby is not rich. It is a network in which every new note tells you what you already knew.
So Jotaid computes the global clustering coefficient of your concept network, and when it runs above 0.55 with no bridge nodes at all, it says so, in those words: highly clustered, no bridges, echo-chamber risk. It will also tell you the opposite — that the network is too sparse to conclude anything yet — because a tool that only ever reports good news is a tool you stop reading.
The fifth property: a sentence, not a dropdown
Jotaid has no link types. No relation vocabulary, no predicate field, no place to declare that this edge is a supports and that one is a refutes. That is a decision, and the reasoning is everything in the previous section: a type you have to supply at write time is a type that will be missing exactly where you needed it, correct only for the connections that were obvious anyway, and quietly wrong a year later.
What it does instead has two halves.
The first is a proposal. Ask, and Jotaid reads the notes where the two concepts actually co-occur and writes one sentence, about twenty words, describing how the second relates to the first — is it a component of it, a prerequisite for it, an application of it, an alternative to it, a concept derived from it. Note that this is directional by construction: the sentence is written from one end towards the other. It runs on your own API key and it is a Pro feature.
And it is not stored as truth. It does not become a property of the edge, nothing downstream is computed from it, and it is never written to disk — the response cache is in-memory and dies with the process, so a sentence about your notes does not outlive the session that produced it. It is a sentence that appears next to a relationship you were already looking at, phrased as a claim, so you can disagree with it. The disagreement is the useful part.
The second half is where the kind actually goes, and the mechanism matters more than the phrasing suggests. You write a note stating the claim, and you mark both concepts inside it — [[async writing]], [[onboarding]].
That single act attaches the claim to the edge. A note mentioning both concepts is, by construction, a member of that pair's intersection: it is now one of the notes the pair's own panel lists as evidence, and because that list is ordered by recency, it is the first thing you see the next time you open the cell. You did not file the judgment somewhere else and hope to run into it again. In a system whose unit is the concept, writing a sentence about two concepts is itself the operation that annotates their relationship. There is no type field because there is no need for one.
Then compare what the two records can hold. A dropdown value is a token sitting on an edge: supports — no author, no hedge, no date, no reasoning, and no way of being interestingly wrong. The note is a claim. It can be a paragraph. It can be conditional. It can name the three notes that changed your mind. It can be revised, and a later note can contradict it — at which point that note joins the same evidence list, and the disagreement is visible on the same edge, which is more than any controlled vocabulary has ever managed.
One honest consequence of the mechanism: the claim you wrote now also counts towards that pair's strength, because a note discussing both concepts is precisely what the measure counts. That is the measure working rather than inflating — your synthesis is evidence of a relationship in the same way your raw capture is — but it is worth knowing that the number includes your conclusions and not only your inputs.
The honest limits here are real and I'd rather state them than have you discover them. Of the five properties, kind is the one I solve least completely, in two specific ways.
First, if you never write the sentence, the kind of that relationship stays unwritten. The software cannot do that part, and every design in this essay that claimed it could has a chapter in the history section.
Second — and this is the place where a typed edge is genuinely better — the claim note is not marked as the claim. It sits in the evidence list looking like any other note, and recency is the only reason it sits on top. Six notes later it doesn't. What Jotaid has here is emergent rather than declared, and emergent structure is superb at surviving neglect and worse at being retrieved on demand. If you want a relationship you can query by type, this is not that tool, and the section above named the tools that are.
The relationship with zero backlinks
The last piece is the one that answers the wall from the previous section directly.
Jotaid looks for pairs of concepts that share a lot of neighbours and have never once appeared in the same note. It weights the shared neighbours by how rare they are, on the reasoning that two people who share an obscure acquaintance are more likely to know each other than two people who both know someone famous.
That weighting is not mine. Lada Adamic and Eytan Adar published it in 2003, in a study of personal home pages, as a way of deciding when two pages are strongly related — pages that share a rare feature are more alike than pages that share a common one. Liben-Nowell and Kleinberg carried it across to networks the same year, in the paper that framed link prediction as a problem in the first place. Their survey of proximity measures puts Adamic/Adar directly beside the Jaccard coefficient, defined over shared neighbours exactly as this essay has been using it. The two things Jotaid computes about a pair of your concepts — how strong the relationship is, and whether one should exist that doesn't — come from the same page of the same paper. Neither needs any modification to work on notes.
These surface as Potential Links, each showing the shared neighbours by name and a line that states the case plainly: these two each share notes with those, but never with each other. The strength shows as a bar. There is deliberately no verdict word attached, because "Strong" would be claiming more than the arithmetic supports.
Look at what that object is. It has a strength. It has an evidence trail you can open. It has a clear direction for what to do next. And it has zero backlinks, because you never made one — you had not noticed. No amount of labelling discipline could have produced it, no schema could have held it, and no amount of tagging would have found it, because every one of those operates on connections that already exist.
That is the whole difference between deriving relationships and declaring them, in one panel.
Everything in this section that counts rather than guesses is free, in a single project, with no limit and no expiry. The two pieces that ask a model — the relation sentence and semantic backlinks — are Pro, and run on a key you supply.
Twenty minutes, one relationship
Here is the loop. It is deliberately small, and the constraint that makes it work is that you do exactly one.
Pick a pair. Three places to find one worth the time, in ascending order of interest:
- a cell that is stronger than you expected, where you cannot immediately say why those two keep meeting;
- a pair whose ranking is lopsided — top of one concept's list, buried in the other's;
- a Potential Link: two concepts with many shared neighbours that have never once appeared in the same note.
Read the four countable properties before thinking about the fifth. This is the part people skip, and skipping it is how you end up writing a claim your own notes contradict. Read the strength. Read both rankings, from each end. Then open the evidence — actually open it, read three of the shared notes, the most recent ones first. Check whether the relationship is alive or finished.
Only then, the kind. Ask for the proposed sentence if you want a starting point, and treat it as an opening bid.
Write one theme note, and mark both concepts inside it. A claim, in your words, that could turn out to be wrong — and, because it names both concepts, a claim that from now on lives on that pair rather than beside it.
Then stop. One relationship, thought through and written down, beats twelve skimmed.
Run it end to end on the pair this essay has been carrying.
The strength is 43% — nine shared notes out of the twenty-one that mention either concept. Unremarkable on its own. What makes it worth opening is the asymmetry: async writing sits at the top of onboarding's partner list, while onboarding is well down async writing's. One of these is largely about the other; the other is about a great many things.
Then the evidence, which is where the actual work is. Open the nine notes. What they have in common turns out not to be visible on either concept's page: every one of them is about somebody's first week. Not remote work in general. Not documentation culture. Week one.
Now ask for a sentence, and the proposal comes back as async writing is a prerequisite for onboarding. Perfectly reasonable — and near enough identical to the example this essay reached for several sections ago, back when the pair had been looked at and the notes had not. That is what both a model and a writer produce from the outside of a relationship.
The nine notes say something narrower and more useful. The dependency runs one way and it expires. A new person cannot ask a question they don't yet know how to phrase, so in week one the archive is all they have. By month three the same person is better served by ten minutes of talking, and the archive has become the slow path. So the relationship is not "prerequisite." It is a dependency with an expiry date — a different claim, with different consequences for how you would actually run someone's first month, and one that could not have been reached without reading the nine.
That sentence is the output. Not the link, not the score, not the graph.
Write it down with both concepts marked and it becomes the tenth shared note — which means the next time that cell comes up, the first thing in its evidence list is the conclusion you reached last time, and the question in front of you is no longer how are these two related but is that still what I think. The software's whole contribution was to put the pair in front of you with nine notes open. Yours was the tenth.
What this doesn't fix
It needs material. Every technique here is arithmetic over things you have written. Thirty notes will produce a matrix of near-zeros and a set of predictions that are noise wearing a confidence bar. A hundred notes with concepts marked is roughly where the numbers start meaning anything.
Co-occurrence cannot tell agreement from opposition. This is the strongest objection to everything above and it deserves to be stated at full strength. Two concepts that always appear together because one causes the other, and two concepts that always appear together because you keep contrasting them, produce the same number. The strength is real; the valence is invisible. Derivation finds you the pair, and it will never tell you whether you have been building a case or arguing with yourself.
This is precisely what a typed-link system does capture. If your work is mostly of that shape — a literature where the moves genuinely are supports and opposes, and you are willing to adopt a grammar to record them — then a discourse graph is not a worse tool than mine, it is a better one, and I would rather you used the right thing.
The kind stays unwritten unless you write it. No feature closes this. A tool that filled it in for you would be handing you a conclusion you did not reach, which is the failure mode this entire series is arguing against.
There is no history of a relationship. Jotaid can tell you a pair is active now. It cannot show you the curve of how it got there, and I'd like it to.
If the schema is known before the data, use a database. Meetings belonging to projects, papers having authors, tasks having owners — Notion and Tana are excellent at exactly that, and none of this essay applies.
Your twenty-three backlinks
Bush's trails had names. They had an order, they could be reviewed in sequence, and they could be photographed out and handed to a colleague as objects in their own right — because he understood that the trail, not the document, was the thing worth inheriting. Granovetter defined four dimensions of a tie before he reported a single result, and footnoted the two simplifications he was making so nobody would mistake them for the theory. Kessler had a machine deriving relationships from overlap in 1963.
What ended up in your notes is a symmetric boolean, and the graph view is a faithful drawing of it.
So the test is not how many links you have. Take one pair of concepts you have been circling for a year and ask: how strong, compared to what? Which way does it point? What would I read to check? Is it still live? And then, when you know the answers to those four — what kind of relationship is this, and can I write it down as something that might be wrong?
A backlink is a record of something you once did. A relationship is a claim about your material. Nothing turns the first into the second except you, sitting down and writing the sentence — but the arithmetic can tell you, out of ten thousand pairs, exactly which sentence is worth your twenty minutes.
Your twenty-three backlinks are not twenty-three relationships. They are twenty-three places a relationship might be, and nobody has looked.
Jotaid is free for a single project with all of the counting intact — the matrix, the ranked partner lists, the evidence notes, the network diagnosis, link prediction and the on-device semantic index. The two AI pieces are part of Pro, and run on an API key you supply yourself. If you want to try the loop once, you don't need to migrate anything: a week of notes with concepts marked, and twenty minutes, is enough to find out whether your own material has anything to say back.
Free to start · Mac and iOS
Not currently available on the China mainland App Store.
A short glossary
| Term | What it means |
|---|---|
| Jaccard index | Shared ÷ combined. For two concepts: notes mentioning both, divided by notes mentioning either. Lands between 0 and 1, and is comparable across every pair. |
| Clustering coefficient | Of a concept's neighbours, what fraction are connected to each other. High means a tight-knit neighbourhood; low means the concept sits between groups that don't otherwise meet. |
| Bridge node | A concept with several neighbours who mostly don't know each other. The broker. Granovetter's weak tie, at the level of ideas. |
| Adamic–Adar | A similarity score that weights shared neighbours by rarity: sharing an obscure acquaintance counts for more than sharing a famous one. Used here to predict relationships that should exist and don't. |
| Bibliographic coupling | Two documents are related because their reference lists overlap. Fixed at publication. |
| Co-citation | Two documents are related because later documents keep citing them together. Changes over time while both documents sit still. |
| Discourse graph | An information model whose units are questions, claims and evidence, linked by relations like supports and opposes. |
Further reading
- Vannevar Bush, As We May Think (1945) — sections 7 and 8, on trails, and on what a trail leaves behind
- Mark Granovetter, The Strength of Weak Ties, American Journal of Sociology 78:6 (1973) — read footnotes 2 and 4 on page 1361
- M. M. Kessler, Bibliographic Coupling Between Scientific Papers, American Documentation 14:1 (1963)
- Henry Small, Co-citation in the Scientific Literature, JASIS 24:4 (1973)
- Randall Trigg, A Network-Based Approach to Text Handling for the Online Scientific Community (PhD thesis, Maryland, 1983); Trigg & Weiser, TEXTNET, ACM TOIS 4:1 (1987)
- James Allan, Automatic Hypertext Link Typing, Hypertext '96
- Cory Doctorow, Metacrap: Putting the Torch to Seven Straw-Men of the Meta-Utopia (2001)
- Clay Shirky, The Semantic Web, Syllogism, and Worldview (2003)
- Lada Adamic & Eytan Adar, Friends and Neighbors on the Web, Social Networks 25:3 (2003)
- David Liben-Nowell & Jon Kleinberg, The Link Prediction Problem for Social Networks (2003)
- Joel Chan, Discourse Graphs for Augmented Knowledge Synthesis: What and Why
