The ABCs of PKM: a community wiki glossary [Project idea]


This post is partially inspired by the Discord discussion that led @Oshyan to write his practical guide to choosing a task/project management tool outlining their major differentiating features. I’ll summarize the motivation for that guide:

There are too many task management apps. How do you choose one? You must identify your goals and needs first, then eliminate options. You can’t know what you want until you know what general features differentiate the tools. By outlining the range of existing options, the guide helps you make a personal list of your “must have” features to evaluate tools against.

I want to create something similar, but for personal knowledge management.

The post above is like a guide to the squircles in “The Idea Maze” diagram by Balaji S. Srinivasan:

Whereas I am more interested in documenting all the patterns as in A Pattern Language by Christopher Alexander:



To crowdsource and document accumulated wisdom and knowledge about abstract features common to personal knowledge management tools into a central wiki like a glossary or encyclopedic resource. Specific tools are secondary or tertiary.

For example, key pages in this resource might be about Aliases or Backlinks. The Aliases page would answer questions like “What are aliases? What are aliases used for? How do/should they work?”

This resource is intended to:

  • Help users understand what they need
  • Help users understand what features each tool offers
  • Help developers understand what users need
  • Help developers understand how to design what users need

This project is not seeking to be:

  • Just a list of tools, or even a list of features or differentiators
  • User reviews of specific tools


Avoid reinventing the wheel

Features, requests, frequently asked questions, and documentation in one app are often the same as those in another app. The duplicated work and finding common understanding within each app and its community is a waste of time. What if we could at least speak the same language? What can we learn from each other, and from the past? Can we outsource explanations of common ideas to a single place?

These concepts, and the discussion of these concepts, and even their names, seem to be reinvented by every tool and community. Instead, we could all share one canonical resource.

Avoid confusion in communication

Concepts in PKM can be tricky to understand. For example, the idea of “aliases” causes confusion often. A recent feature request in the Logseq forum shows how hard it can be to reach common ground.

Many apps coin their own neologisms or terms of art, such as “tiddler” or “rem” (a needlessly confusing mass noun with no distinct plural form), or overload generic words like “thought”. While I have nothing against coining terms for truly original concepts, we can do better than the current tower of Babel.

Existing resources are insufficient

Lists and comparison matrices of tools exist (1, 2, 3), but are not really sufficient for describing and explaining the fundamental rationales and trade-offs of each feature in isolation. Also, those resources can never be comprehensive, their knowledge is easily outdated, and they are a burden to maintain.

A central resource doesn’t exist yet

There is a clear need for a tool-agnostic resource to document common knowledge. When people ask questions, we have no comprehensive resource to point at, so we repeat the same conversations.

It’s even hard to know if such a resource exists, because searching for things like “personal knowledge management wiki” or “PKM wiki” only gives results about specific wiki software solutions.

Challenge to developers of note-taking apps

Over time, more features are becoming table stakes. How many of these features can you implement in the next month or year? The challenge is not to implement as many of them as possible, but only what has value for your app. However, this project first needs to gain visibility for this challenge to have any effect.

Project idea

This project is a significant and large undertaking, so to make it manageable, we must start small.

I am proposing that we focus on 1 letter per week. We effectively already started with “A is for Aliases.” We could continue with “B is for Backlinks” and end at “Z is for Zettelkasten” over 26 weeks. Eventually, the ABCs of PKM will help us all speak the same language.

Why here?

To summarize what @Karthikk said:

We PKM enthusiasts comprehend the common language between all these apps. We sense they are all moving in the same direction, albeit at different paces and taking different routes. While each app tackles a specific issue with its own flavor of ideas and implementations, there are gaps and pitfalls. We can make an impact by bringing together the knowledge accrued by each app and making sense of them at a meta level. We already have good connections with various founders.

But we need people on board. The only way this will happen is if you contribute. Share this project wherever people are discussing or have discussed these concepts, and invite them to join.

We start by defining projects for each letter of the alphabet and creating the framework for people to jump in and start contributing. Enthusiasts and hackers of specific apps already know what’s happening within their own app space. Here we are more interested in tackling the feature problems at a meta level. By establishing groundwork and spreading the word, we could gain a lot of leverage or authority in this niche. If we complete the Aliases project, that could ignite the rest.

Related projects

1 Like

Project structure

The project will be completely asynchronous, bottom-up, and open. Nobody will be prevented from working on whatever entry they want. However, I suggest that we:

  • Pick one entry to focus on per week.
    • If there are multiple options for a letter, vote on which one to focus on (using Discourse polls).
    • Alternatively, we can focus on an entire letter per week.
  • During the week, write down all existing thoughts on the topic.
  • After one week, move on to the next letter.
  • Previous topics will still be open to contributions, as no entry is ever fully finished.

To limit the scope further, I also suggest that we:

  • Discourage entries that don’t meet the criteria.
  • Discourage creating entries later in the alphabet.
  • Finish the Aliases project first, since we already started it.
    • If we never finish “A” to any level of satisfaction, then there’s no point doing this project.


Week Dates (Fri–Thu) Topic in focus Other open topics
0 final week of 2020 Aliases
1 Jan 1 – Jan 7 Aliases A
2 Jan 8 – Jan 14 B…… A, B
3 Jan 15 – Jan 21 C…… A, B, C

For this week, also think about what might be a good next project for “B” and “C.”

1 Like

Entry structure

What should an entry contain?

  • Nomenclature, definition, description, explanation, rationale, and practical use cases.
  • History of the concept, well-researched and well-linked. Links to other discussions of the topic.
  • Examples and comparisons of key existing implementations (and date when feature was added).
  • Visuals, lists, tables, icons, diagrams, drawings, mockups, animations.
  • Relevant examples of usage.
  • How the entry relates or interacts with other entries.
  • What problem does this feature solve?
  • Frequently asked questions or confusing concepts about this entry.
  • How challenging is this feature to implement/design? How difficult is it for users to understand?
  • What should a complete/ideal implementation do? Could an incomplete implementation suffice?

To avoid getting too theoretical and far from the tools that already exist, we should always consider what tools are currently able to do, and what needs they are currently unable to address. We can make a list of 6–8 major tools that we often compare and use to inform our entries. This is inspired by the following:

To be neutral, many international auxiliary languages (e.g. Interslavic, Interlingua, and Esperanto) construct their vocabulary by considering a set of selected “control languages” as sources.

What makes a good entry?

  • An unintuitive concept or term that newcomers to this field likely need explained.
  • An ambiguous or polysemous term to help people find common ground in communication.
  • An opinionated concept about which many people disagree.
  • A term about which good resources don’t exist yet.
  • A frequently asked question or concept.
  • A common abstraction that isn’t necessarily a feature, but to collect good advice (marked with *).

What makes a poor entry?

  • A term that is obvious or easy to explain (“Bulleted list”).
  • A term that is too vague or broadly-encompassing (“Privacy”).
  • A feature that is obvious or easy to implement.

Candidate entries

Here are some candidate glossary entries. Disclaimer: It is biased toward my interests. Feel free to suggest or edit anything.

A.  Aliases, Attributes, Autocompletion
B.  Backlinks (Bi-directional links), Blocks (manipulation/dragging/collapsing, Block–page dichotomy), Block references (Block addressability), Breadcrumbs
C.  Capture, Command palette, Collaboration, Clipping, *Community
D.  Daily notes, Digital garden, Databases (schemas/models), *Documentation
E.  Extensibility (Plug-ins, Themes, Integration, Hackability), Encryption
F.  Folders/Flat structure, Folding (of headings/blocks), Filtering, Future-proof, Fuzzy search
G.  Graph visualization
H.  Hierarchy/Heterarchy (Folder/Flat structure), Hover previews
I.   Indentation (Outliner)
K.  Keyboard shortcuts, Knowledge graphs
L.  Links
M.  Maps of content (MOCs), Maps (Spatial visualization), Markup (Syntax, File formats), Mobile, Metadata, Migration (Import/Export), “Multiplayer”, Machine learning (NLP, anything “smart”)
N.  Namespaces
O.  Outliner, Orphan notes (Homeless notes), Offline, Outline view
P.  Panels (Sidebar, Frames, Windows), Publishing, PKM, Permissions
Q.  Querying, Queues
R.  Recent changes (RSS feeds), Redlinks, Refactoring, Relation types
S.  Search, Sliding panes, Slash menu, Spaced repetition, Structured data, Subpages, Sync
T.  Transclusion, Text editing/manipulation, Templates (e.g. Text expanders), Tags (vs. pages), Text as graph
U.  Unlinked mentions, URLs, Unique IDs, UI/UX, Undo
V.  Versioning
W.  Wikilinks
Z.  Zettelkasten

1 Like

Very detailed and well thought out proposal. Thanks for tossing this out for discussion.

As I read it, I was thinking that we should not limit when contributions could be submitted. Since you already proposed ideas for each letter, maybe my objection is already satisfied. Concentrating on a letter for a week sounds like a reasonable idea to try and make a more organized team effort response, to your suggestion.

Just reading and following your links already provided me several more resources that I had not already located.

Looking forward to see how much traction this gets.


I think the images you uploaded there are broken, could be because the the image is placed inside of a collapsible bullet. I have noticed in the past that some features don’t work well in discourse when they are combined, for example placing an image inside of the collapsible bullet. Do take a look .