Appearance
Personal Knowledge Management with Jotaid
Four of the five skills named in the paper that coined the term have been solved beautifully. The fifth one was "left to the individual student" in 1999, and for the most part it still is.
You remember reading something that bears on the question in front of you. Someone in an interview said the setup felt like too much work. There was a line in a book about habits. There was a thought you had in the shower and typed into your phone at a traffic light.
You find all three. Search is good now — better than the people who coined the term personal knowledge management dared to hope for. Your notes app returns the three of them in under a second, with the matching passage highlighted.
Then nothing happens.
You read them, you nod, you close the tab. Whatever runs between those three notes — if anything does — stays where it was: in your head, for as long as you can hold it there, and then gone. Next month you will find the same three notes again, have roughly the same thought, and lose it the same way.
It is tempting to read that as a discipline problem. It usually is not. Your capture pipeline works. Your search works. Your tags are fine. The system did everything it was built to do and then stopped, because the thing you needed next was never part of what it was built to do.
That is not a new complaint. It is not even a complaint — it is a design note, written down by the two people who gave this practice its name, in the same document that gave it the name.
What personal knowledge management actually meant
The term comes from a December 1999 working paper by Jason Frand and Carol Hixon at UCLA’s Anderson School of Management. Most of it is about volume. Scholarly journals up approximately 55% between 1987 and 1996. Search engines, by a report they cite, covering fewer than half the pages on the web and falling farther behind. The cost of disk storage dropping 60% a year. A projection from OCLC that the information available on the internet in 2001 would be greater than all knowledge in recorded history. Personal knowledge management, they write, "attempts to utilize the computer to help the individual manage the information explosion in a meaningful way."
Their definition:
PKM, as conceived at the Anderson School, is a conceptual framework to organize and integrate information that we, as individuals, feel is important so that it becomes part of our personal knowledge base. It provides a strategy for transforming what might be random pieces of information into something that can be systematically applied and that expands our personal knowledge.
The paper then names the skills — not as a theory of the field, but as the heuristics taught in a workshop for MBA students called the Anderson Edge, borrowed, in their words, heavily from traditional library science. The list is five items long:
searching/finding, categorizing/classifying, naming things/making distinctions, evaluating/assessing, and integrating or relating
For searching and finding they provide what they call "launch pads": sets of resources organised by the library in consultation with the school, some general and some discipline-specific, plus a database selection tool that helps a student pick a starting point based on the characteristics of the data.
For categorizing and classifying they give heuristics adapted from library scientists — Ranganathan, Dewey, Cutter. There are as many classification schemes as there are queries, so pick what works best for you. Anticipate how you are likely to use something before you classify it. Organise from the general to the more specific, putting items in the most specific category. Subdivide using a rule of thumb of seven plus or minus two.
For naming things and making distinctions they give another set, from the same tradition. Use names that are meaningful to you. Make them as complete as necessary and as short as possible. Use unique terms for distinct concepts. Be consistent. And — a rule that returns later in this article — when there are two different ways of expressing the same concept, choose one term and reference the other.
For evaluating and assessing they give a checklist adapted from a UCLA librarian: be aware a site may not be complete or accurate; question its purpose and look for evidence of bias; determine whether other sources confirm it; examine when it was last revised; question the authority of whoever created it; and ask whether there is a way to contact them.
Then the fifth:
The task of integrating and relating is left to the individual student.
The lines around that sentence report what they had seen students do rather than what to do. One student developed a website with hyperlinking of specific topics. Other possible options they list are partitioning the Windows environment and hyperbolic nets. They close the paragraph by saying they have found it is the underlying file structure which is critical.
The same construction appears three more times, elsewhere in the paper, describing not their workshop but the university around it. On divergent goals and departments that do not coordinate: integration is left to the learner. On course content that is novel and difficult to categorise and relate: Relating concepts is left to the learner. On the information-handling skills the computer had made possible: The application of these skills is left to the learner.
Twenty-six years of building the first four
That is what the paper says. The rest of this article is what I make of it, starting with an asymmetry.
Four of the five skills arrive with a body of technique, specific enough to teach in an afternoon and most of it inherited from a century of library science. The fifth arrives as a sentence, two suggestions and a remark about file structure. Meanwhile the definition those skills were meant to serve puts its weight squarely on the fifth: not storage, not retrieval, but transforming what might be random pieces of information into something that can be systematically applied. The word doing the work there is integrate.
It would be unfair to read the gap as laziness. In the weather they were describing, the urgent problem is triage. You build launch pads first and you build the relating part later.
Later arrived. The first four skills got twenty-six years of engineering, and they got very, very good.
Searching and finding was won outright. Frand and Hixon's students needed a librarian-built launch pad to decide which database to open. You type four words into a box and get the matching sentence, highlighted, in a note you wrote in 2019. Semantic search goes further and finds notes that never contain your words at all. Whatever else is wrong with your system, retrieval is not it.
Categorizing and classifying did not get solved so much as multiplied. Folders, then tags, then nested tags, then PARA, then Johnny Decimal, then the honest admission that a note about onboarding friction belongs in four places at once and a single hierarchy cannot hold it. The structure your app happens to use quietly decides which questions you can ask of your notes later on — which is a longer argument than this article can hold, and one I've made separately. The short version: every scheme in this lineage answers where does this note go. None of them answers what runs between these notes.
Naming and making distinctions had a genuine renaissance. The atomic-note discipline — one idea per note, titled as a claim you could argue with — is the best-taught habit in modern PKM, and it is exactly the skill Frand and Hixon put third on their list. It is also the point where the practice stops being filing and starts being thinking, which is why the unit worth building around turns out to be the concept rather than the document.
Evaluating and assessing grew a whole product category. Reference managers keep provenance attached. Highlight services carry the source, the page, the date, and your annotation from the book into your notes without retyping. The six questions on the 1999 checklist are, for most of us, now answered by metadata that arrives on its own.
Four for four. Then there is the fifth.
What does integrating and relating look like in a modern tool? It looks like a bidirectional link and the panel that lists them. You type [[Perceived value]], and the note you named now appears in a list on that concept's page. Do it a hundred times and you have a graph view: a cloud of dots and lines that looks, at a glance, exactly like a mind that has been doing serious work.
That is real progress and it should not be dismissed. Before backlinks, the fifth skill had no representation in software at all. But look closely at what a backlink actually records. It records that two notes touched. It does not record how, in which direction, how strongly, on what evidence, or since when — all properties that forty years of typed-link research knew how to store and that we mostly left behind (a story worth its own article).
There is a second limitation, less discussed, and for the purposes of this article the more serious one.
What stalling at the fifth skill looks like
Here is a diagnostic you can run on whatever system you use right now. It takes about ninety seconds and it has three parts.
1. Ask your notes a question you never wrote down
Open your system and ask it something like: what have I learned about why people abandon tools they liked?
Watch what it can do. It can find every note where you used those words. If it has semantic search, it can find notes that describe the idea in other words. What it almost certainly cannot do is tell you that across nine of those notes, two ideas keep arriving together — and that one of them is an idea you have never written a note about.
The distinction matters. The first is retrieval: it returns things you put in. The second is synthesis: it returns something about the collection that no single item in it contains. A system that only does the first is a very fast filing cabinet, and there is nothing wrong with a very fast filing cabinet as long as you know that is what you have.
2. Look at one relationship and try to say five things about it
Pick two ideas in your notes that you know are connected. Now try to answer, from the system rather than from memory:
- What kind of relationship is it — does one cause the other, contradict it, refine it, serve as an example of it?
- Which direction does it run?
- How strong is it — eleven notes' worth, or one offhand remark?
- What evidence supports it — which notes specifically, and can the system name them?
- When did it start, and is it still accumulating?
A link answers none of the five. It answers a sixth question, is there a link, and the answer is always yes, because you are the one who put it there.
3. Count how many of your connections you already knew about
This is the one that stings.
A wiki link is a declaration. You type [[Perceived value]] because, at that moment, you had already noticed that this note was about perceived value. Every edge in your graph is something you thought of. The graph is therefore a faithful, beautiful, growing picture of the connections you have already made — and structurally, it has a hard time showing you the pair you have never held in your head at the same time.
That pair is the whole reason you kept the notes.
You wrote down the interview in March and the chapter about habits in July. Those two sittings had nothing to do with each other. If the idea that joins them is going to surface, something has to notice that they keep landing in the same company without you ever having said so — because you were never in a position to say so. You read them four months apart.
This is the specific shape of the gap Frand and Hixon left open. Not "software cannot store relationships" — it can, and typed-link systems have stored them since the eighties. The gap is that every mechanism we did build for the fifth skill requires you to have already done the fifth skill. You must relate the concepts before the tool will record that they are related.
Which brings us to the question this article is actually about: what would a system have to do instead?
Six tests for a personal knowledge management system
These are not feature requests. Each one falls out of something above — either a skill the 1999 paper named, or a specific way the fifth skill fails today. Each comes with a way to check it in a couple of minutes, on whatever you already use. Run them on Obsidian, on Notion, on a folder of text files, on Jotaid. The point of a test is that the tool you like can fail it.
Test 1 — Concepts have to be first-class
Skill three on the 1999 list was naming things and making distinctions. If a concept has no home of its own, there is nowhere for a distinction to live: "perceived value" exists only as a string that occurs in some notes.
How to check. Open the idea you have used most this year, as an object. Not a search result — a page with its own definition, which you can edit, and which lists the notes that reference it.
Test 2 — Different names for one idea have to converge
Frand and Hixon's rule was the one quoted earlier: pick a single term and make every other way of saying it point there. Library science had settled this decades before either of us started taking notes. If "setup burden" and "onboarding friction" are the same idea and your system treats them as two, every count it shows you is wrong and the split is invisible.
How to check. Merge two names you know are duplicates. Then search for the old one. If the old name has quietly stopped resolving, you have just lost the ability to find your own back catalogue.
Test 3 — A relationship has to carry more than "exists"
Kind, direction, strength, evidence, date. A boolean cannot tell you that one idea keeps undercutting another, or that a connection you were confident about in March has not gained a single supporting note since.
How to check. Pick one connection and try to answer the five questions from the diagnostic above without opening a single note.
Test 4 — The system has to be able to propose a pair you never made
This is the one the whole article turns on. If every connection in your system is one you declared, the system can only ever show you back your own thinking, arranged prettily.
Something in the loop has to be able to say: these two ideas have turned up in the same nine notes and you have never once linked them. That claim requires no model and no cleverness — it is counting. Which is why a system that does not do it has run out of excuses.
How to check. Ask your tool for a connection you do not already have. Not a search. A candidate.
Test 5 — Every proposal has to come with its evidence
A suggestion you cannot audit is a rumour. This applies with equal force to a statistic and to a language model: "these two concepts are related" is worth nothing until you can see which notes, and get to them in one click.
This is skill four from 1999 — evaluating and assessing — pointed inward. You learned to ask a web page who wrote it and what it was for. The same six questions apply to a claim your own software makes about your own notes.
How to check. When the system suggests something, count the clicks to the underlying notes. If the answer is "there are none", it is decoration.
Test 6 — What you decide has to survive
You look at a proposed pair. You read the nine notes. You conclude that yes, these two are connected, and that the direction runs one way and not the other. Or you conclude that it is a coincidence of vocabulary and dismiss it.
That judgement is the most expensive thing in your entire system. It cost you twenty minutes of real reading, and it is the only part of the process a machine did not do. If it lives in a panel that recomputes tomorrow, you will make it again next month, and the month after.
How to check. Make a decision about one relationship. Close the app. Come back in thirty days. Can the system still tell you that you decided it — and distinguish it from the ones it merely guessed?
Six tests. Notice what is not on the list: nothing about AI. Tests 1, 2, 3 and 6 are pure data modelling and could have been passed in 1994. Test 4 is arithmetic on a co-occurrence table. Only Test 5 gets easier with a language model, and it gets easier in an unglamorous way — by summarising evidence you could have read yourself.
That ordering matters, because it means most of what comes next is a way of working rather than a piece of software. Here is the loop, with a worked example.
A personal knowledge management workflow you can run this week
Throughout this section, one worked example. It is an illustration, not a case study — but every number in it is internally consistent, so you can follow the arithmetic.
Suppose you are trying to answer a question that will not sit still: why do people abandon tools they initially found useful? Over three months you accumulate 21 notes about it. Seven are excerpts from user interviews. Four are from a book on habit formation. Six are things you noticed about software you yourself stopped opening. Four are arguments with a colleague, reconstructed from memory the same evening.
Step 1 — Start from a question, not a topic
A topic is a bucket; anything vaguely related falls in and nothing ever comes out. A question has a shape, which means a note can be relevant to it or not, and — the part that matters — a note can answer part of it.
Write the question down somewhere it will stay visible. Everything below hangs off it.
Step 2 — Capture the material and your reaction to it, separately
This is the habit that pays the most and costs the least. A note that records only the source is an archive entry. A note that records your reaction is evidence about how you were thinking that week.
Interview 6. They liked the idea of the app but stopped partway through setup. "I couldn't see what finishing it would get me."
My read: the effort isn't objectively high. It feels high because the payoff is still abstract. Worth checking whether this shows up when the payoff IS concrete.
Three months later that italic line is the useful half. It lets you tell what the participant said from what you inferred — which is the distinction you will need when one of your inferences turns out to be wrong.
Step 3 — Name the things that keep coming back
By note fifteen or so, certain ideas are recurring. Give each one a name and a home of its own: setup effort, perceived value, uncertainty about the next step, habit formation.
Then do the thing library science has been insisting on since Ranganathan. When you catch yourself writing "onboarding friction" in one note and "setup burden" in another, pick one and make the other point at it. Do not leave them as two. Two names for one idea will split every count you ever take, and — this is the dangerous part — the split will never show up as an error. It shows up as two concepts that each look slightly less important than they are.
Step 4 — Look at the pairs you never made
Now the step that 1999 left to you.
You have four concepts. Six possible pairs. The question is not which pairs you linked — you know that already — but which pairs the notes keep putting together while you were not paying attention.
In the example, the arithmetic comes out like this. setup effort appears in 14 of the 21 notes. perceived value appears in 11. They appear together in 9. That overlap — nine notes out of the sixteen that mention either — is the strongest pair in the collection, and you never once wrote a note that was explicitly about the relationship between them. Why would you? You wrote them four months apart.
The pair is not a finding. It is an instruction about where to spend twenty minutes.
Step 5 — Read the evidence, then decide something
Open the nine notes. Read them in one sitting, which you have almost certainly never done, because they arrived one at a time.
Now you can ask real questions of them. Do people accept more setup when the payoff is concrete? Two of the nine say yes explicitly. Is there a case where the payoff was obvious and they quit anyway? Yes — interview 3, which you had half-forgotten, and which is the most interesting note in the set precisely because it does not fit. Have you mostly collected evidence for a thing you already believed? Look at the four notes that came from arguing with your colleague and answer honestly.
Then write down what you now think, while it is still wet:
Setup effort looks like a cost problem and behaves like a forecasting problem. People abandon setup when they cannot predict what finishing it buys them — not when it is long. Interview 3 is the exception and it is worth understanding before this goes any further: the payoff was clear and they quit anyway.
That paragraph is the output of a personal knowledge management practice. Not the notes. Not the graph. This. It records an interpretation, keeps its uncertainty visible, names the piece of evidence that threatens it, and points at what to do next.
Step 6 — Spend it, then feed back what happened
Use it on something real: the article, the experiment, the decision, the argument with the colleague. Then write one more note about what using it taught you. This is the step everyone skips and it is the one that makes the whole thing compound — because the fastest way to find the missing piece in an interpretation is to try to act on it.
Six steps, and note how little of it requires any particular software. Steps 1, 2, 5 and 6 you can do in a text file today, and people did them in wooden boxes for four hundred years.
Steps 3 and 4 are where a tool starts to matter. Step 3 needs concepts to be real objects with converging names — Tests 1 and 2. Step 4 needs the counting to happen without you — Test 4 — and it needs the result to hand you the nine notes rather than a number — Test 5. And whatever you conclude in Step 5 needs somewhere to live that is not your memory — Test 6.
So: how does the software do?
How Jotaid answers the six tests
I build Jotaid, so treat this section the way you would treat any vendor grading their own homework: check it. I have tried to make that easy by answering, for every test, the only question that actually matters — where does the answer live, and how do you get it back in thirty days? A feature you cannot retrieve is a demo.
One of the six comes back half-finished. I have left that in.
Test 1 — Concepts are first-class ✓
Typing [[Perceived value]] anywhere in a note creates a node: a real record with its own body text, its own modified date, and its own tabs. The definition you write there lives on the node, not inside whichever note you happened to be editing when the idea crystallised.
The node also carries what the network knows about it — how many notes reference it, and where the shape warrants it, a role badge. Core means the concept sits inside a dense, well-connected cluster and is among the most-referenced in the project. Bridge means the opposite: it connects groups that otherwise have little to do with each other, which is usually where the interesting work is. Emerging means it has picked up at least two new references in the last fortnight.
Thirty days later: open the node. Everything above is a stored field, not a computed view that expires.
Test 2 — Names converge ✓
Rename a node and the old name stays behind as an alias row pointing at the new one. Merge two nodes and the absorbed name does the same. Search for "setup burden" a year after you standardised on "onboarding friction" and you still land on the concept.
That is Frand and Hixon's 1999 naming heuristic implemented literally: choose one term and reference the other. It is also the least glamorous feature in the product and the one whose absence corrupts the most, because a split concept produces wrong counts silently — and every number in Tests 3 and 4 is built on those counts.
Thirty days later: search the old name. If the connection had merely been mentioned in a note, it would be gone; the alias is a stored row.
Test 3 — Relations carry properties ✓
A relation in Jotaid is a record, not an edge. Each one stores a kind — currently one of four the system will produce: used in, contains, contrasts with, depends on — and the kind determines whether direction is meaningful. Contrasts with reads the same both ways. Depends on does not, and reversing it makes it false.
Each relation also stores how many notes support it, which specific note it came from, when it was created, and — the field that matters most once AI is in the loop — its origin and method: what produced this claim, and how. A guess a model made and a conclusion you reached are not interchangeable, so they are not stored the same way.
Thirty days later: the Relations section on the node. Each row still names its source note.
Test 4 — It proposes pairs you never made ✓
This is the test the whole article was built to reach, so it is worth being precise about what does the work. Not a model. Counting.
Every pair of concepts in a project gets a cell in a co-occurrence matrix: how many notes mention both, expressed as a share of the notes that mention either. In the worked example above, setup effort and perceived value share 9 of the 16 notes that mention one or the other — 56%. That number is a fact about your notes. It required no inference, it costs nothing to compute, and it would have been just as computable in 1999.
Two things follow from it that a link list cannot give you.
The first is that a high number with no relation recorded is a signal in its own right. Co-occurrence is counted fact; a relation is a judgement. They are orthogonal by design, and a pair that keeps co-occurring while carrying no relation is precisely the thing neither list shows you on its own. That pair is your reading list.
The second is the inverse, and it reaches things you had no way of noticing: two concepts that have never once appeared together, yet share a striking number of neighbours. The technique is standard network science — common-neighbour scoring weighted so that a shared neighbour that everyone connects to counts for less than a rare one. Each prediction shows its own working: which concepts the pair have in common, and the fact that they have never co-occurred.
Thirty days later: the matrix and the predictions are recomputed from your notes each time, so they are always current. What you decide about them is Test 6, and that is a different storage problem.
Test 5 — Evidence comes attached ✓
Every proposal above is one click from the notes underneath it. A matrix cell opens the notes in the intersection. A relation names its source note. A prediction lists the shared neighbours it reasoned from.
The same rule binds the AI features, which is where it is easiest to get lazy. Jotaid's AI can propose concepts from a project's notes, suggest groupings, summarise a theme, and read a graph back to you in a paragraph. Every one of those outputs is a starting point attached to material you can check. And where a relation comes out of AI analysis, the record keeps what produced it and by what method — so a model's guess and a conclusion you reached are not stored as the same kind of thing.
There is one piece of restraint here worth naming, because it cuts against the obvious commercial instinct. When Jotaid exposes your graph to an external AI agent, it also exposes a coverage figure: how many of this project's concepts carry any relation at all. If most of them were never analysed, the agent is told that an empty relation list is not a finding. A system that quietly let "no relations found" read as "no relations exist" would demo better and mislead you on a schedule.
Thirty days later: count the clicks to the source notes. That is the whole test.
Test 6 — Decisions survive ⚠ half
Here is the one I cannot tick.
The rejection half works. Dismiss a proposed relation and Jotaid writes a tombstone. Re-run the analysis a month later, on a larger set of notes, with a different model — the rejected pair does not come back. Your twenty minutes of reading bought something permanent. That is deliberate: a judgement that a later rescan can silently overwrite is not a judgement, it is a preference.
The confirmation half does not exist yet. The data model has the field. An agent reading your graph is told which relations were human-confirmed and puts them first. But there is no button in the app today that sets it, which means that in practice nobody's is set. So when I say Jotaid can tell an AI guess from a human decision, what is true right now is narrower: it can tell you what produced each claim and how, and it can remember what you threw away. It cannot yet remember what you endorsed.
Until that ships, the honest answer to "where does your conclusion live" is the same one this article gave in Step 5: you write it down. Put the paragraph on the node, or in the theme note that gathers the evidence. Prose is not a worse store than a boolean — it holds the reasoning, the exception you noticed, and the thing you are still unsure about, none of which fit in a flag. It is just not queryable, and a flag would be.
Thirty days later: the tombstone holds. The paragraph holds. The flag is not there to hold.
What this doesn't fix
It does not read for you. Step 5 is nine notes and twenty minutes, and nothing in the last section shortens it. Counting can tell you which nine. A model can give you a first pass at what they seem to say. Deciding what they mean is the part that was always yours, and a tool that offered to take it off your hands would be selling you the wrong thing.
Co-occurrence is not causation, and it is not even always a relationship. Two concepts can share nine notes because you have a verbal tic — because "friction" is a word you reach for on Tuesdays. The matrix is deliberately dumb: it reports what turned up together, which is exactly why it can surprise you, and exactly why a high number obliges you to go read rather than to conclude.
It cannot rescue notes that never had any context. If your archive is three thousand highlights with no reaction attached, none of this machinery has anything to work with. Concepts extracted from quotations are a list of the topics other people wrote about. The interpretive layer has to come from you, at capture time, in the form of the sentence about what you made of it.
Plenty of people should use something else. If your notes are mostly tasks, journals or reference lookup, an apparatus for developing concepts is overhead you will resent. Apple Notes and Bear capture faster than anything I have built and their sync is excellent. Obsidian's local-file model and plugin ecosystem give you a kind of freedom Jotaid does not offer, and if you have already built something that works in it, the honest advice is to keep it — the six tests are useful precisely because you can run them on the tool you already have. Jotaid is for the case where notes keep accumulating and never turn into anything, which is a specific complaint and not a universal one.
The practical boundaries, so you can rule it in or out quickly. Jotaid is macOS and iOS. Notes live on your devices, sync over iCloud if you want them to, and import and export as Markdown, so leaving is a copy rather than an extraction.
The free tier is a single project — Inbox — with the machinery in this article switched on: the editor, wiki links, the graph, the co-occurrence matrix, the canvas, iCloud sync, and the on-device semantic index that powers meaning-based search and tag suggestions without sending anything anywhere. The line is drawn at who makes the links. Analysing a network you built by hand is free — the graph, the matrix and the predictions all run on the [[ ]] you typed. Having the AI go and find what to link is Pro, as are multiple projects, bulk moves, and stacking more than one filter at a time. AI runs on an API key you supply yourself, from a provider you pick — that is a privacy and cost decision, not a discount route: the key does not unlock Pro, Pro unlocks the ability to use the key.
The MCP connection, for letting an external AI agent read your notes, is macOS-only, part of Pro, off by default, read-only, and scoped to the projects you explicitly allow. It has no tool that can write to your library. Turning it on is a decision to let something else read your thinking, and it is presented as one.
Back to 1999
Frand and Hixon wrote during the information emergency described earlier, and they were right about it. The volume arrived. It kept arriving. The tools they hoped for got built, and then got very good — search that finds the sentence, capture that keeps the provenance, naming discipline taught to hundreds of thousands of people who have never heard of Ranganathan.
What did not get built, for a long time, was the fifth thing. The task of integrating and relating is left to the individual student. Written in 1999 as a note about a workshop; read in 2026 as a fair description of most personal knowledge management stacks.
It is worth being clear about which part of it can be automated and which part cannot, because the two get confused constantly. The part a machine can take is the noticing: counting which ideas keep arriving together, and flagging the pair you were never in a position to spot because you read the two halves four months apart. That part is arithmetic and it should have been automatic decades ago.
The part that stays yours is the meaning. What those nine notes add up to. Which exception matters. What you now think, and how sure you are.
A personal knowledge management system earns its keep when it hands you a pair you did not know you had, along with the evidence, and then gets out of the way while you decide what it means. Everything before that is filing — useful, necessary, and not the point.
Start with a question you actually care about. Capture the material and your reaction to it. Name the ideas that keep coming back, and make the duplicates converge. Then go look at the pairs you never made.
That last step is the one 1999 left for later. It has been later for a while now.
Jotaid is where I put my answer to it. If you would rather read than install, the documentation walks the same loop this article describes.
Source
Jason Frand and Carol Hixon, Personal Knowledge Management: Who, What, Why, When, Where, How?, UCLA Anderson School of Management, December 1999. Every quotation in this article comes from that page. The original address stopped resolving years ago; the link goes to the Internet Archive’s copy, so you can check any sentence above against what they actually wrote.
Cover photo from Unsplash.
