Skip to main content

My Vision - The Knowledge Lifecycle

The Knowledge Lifecycle-1

info

This article was published on October 29, 2021 by Alan Chan, co-founder of Heptabase, one month after the company was incorporated.

Foreword

After finishing the first three articles (My Vision: The Context, My Vision: A New City, My Vision: A Forgotten History), I will begin introducing the next generation of the internet that I am building, Heptabase, from different perspectives starting with this article.

Heptabase’s vision is to create a contextualized knowledge internet, and an ecosystem of tools surrounding this knowledge internet, to augment the individual and collective intelligence of knowledge workers around the world. In this article, I will introduce this vision from the perspective of “The lifecycle of human knowledge work.”

The lifecycle of human knowledge work

Human knowledge work has a lifecycle: exploring → collecting → thinking → creating → sharing. For example, I explore ideas from Google and Are.na and collect valuable ones to Roam Research. I use Miro to make sense of these ideas, Notion to create content based on my thinking, Medium and Facebook to share it for others to explore.

The drawback to the process is that I’m constantly switching tools. The context of an idea is scattered across different tools, making it hard to trace and integrate. Humans have bad memories. An idea loses most of its meaning if I can’t remember the context behind it.

Heptabase helps knowledge workers bridge the gaps between different parts of the knowledge lifecycle and preserve the thinking context behind all ideas. The knowledge internet we’re building focuses on optimizing three dimensions: information interoperability, context retrieval, and collective knowledge creation.

Information Interoperability

To build a contextualized knowledge internet, the first step is to ensure information interoperability at all stages in the lifecycle. The current approach to this problem in the software world has two main directions. The first direction is to improve the ability of a single software, common practices are all-in-one apps and plugins. The second direction is to integrate multiple software information, common practices are API and vault.

An all-in-one app packs many features to integrate different parts of the lifecycle. Using Notion, for example, users can collect, think, create and share information. The disadvantage is that too many features cause a steep learning curve and make it not particularly good at doing anything.

Plugins are extensions that add specific features to the software. In Obsidian, for example, you can use different plugins to display the relation between Markdown files in different ways. Its disadvantages are the plugins are difficult to manage, getting started requires domain knowledge, and too many plugins lead to a lack of usability.

API is an interface that allows the software to expose data to others. For example, you can import Github’s data into Discord via the Github API and import Discord’s data into Notion via the Discord API. The disadvantage of APIs is the lack of a unified data interface among all software. If one software wants to connect with ten other software, it has to develop ten customized APIs, wasting a lot of development time.

Vault refers to using File System as a common API for software, allowing different software to read and present the same data differently. For example, Obsidian and Logseq can share Markdown files in the same folder. The disadvantage is that there is no common protocol that defines what software can or cannot do to a vault. If one software has a serious bug that causes data damage, the damage is universal. The more software you use on the same data, the greater the risk.

After a thorough study of the above four practices, we came up with three principles for building a contextualized knowledge internet: first, all software must share the same data schema. Second, all software must adhere to a common protocol about how to handle data. Third, software must be decoupled from the data as much as possible, avoiding direct ownership of the data. Heptabase is a system based on these three principles.

In Heptabase, all Meta-apps share the same card database. Each Meta-app presents and uses these cards differently, adding application-specific metadata to the cards as necessary.

Meta-apps have a lower learning curve than all-in-one apps and higher ease of use than plugins. As the operating system of Meta-apps, Heptabase ensures that all Meta-apps adhere to the same protocol, share the same database and data schema. Such an approach solves the shortcomings of API and Vault.

Context retrieval

To build a contextualized knowledge internet, the second step is to ensure that the thinking context behind all knowledge and ideas can be fully preserved and traced. When you see an idea, you should be able to find how it was created and in what context it was used.

For all human knowledge and ideas, there is always an input before there is an output. “Tracing the thinking context” helps us understand what kind of input leads to what kind of output. To achieve this goal, we must integrate the “collecting,” “thinking,” and “creating” stages of the knowledge lifecycle.

The principle of collecting is “fast.” Ideas are fleeting, and a good collecting tool should have very low friction and can capture ideas as they arise. In Heptabase, the Meta-app responsible for this task is called Journal. You can pour ideas into it anytime without creating an actual note.

The Knowledge Lifecycle-2

Journal

The principle of thinking and creating is “visual.” To clarify our thinking, we often have to visualize the big picture of our ideas. Moving and reorganizing information on visual space is a critical process to augment thinking. In Heptabase, the Meta-app responsible for this task is called Map. You can pull out contents from Journal onto an infinity whiteboard space to create cards and arrange these cards to clarify your thinking structure. A card can appear on multiple whiteboards at the same time.

The Knowledge Lifecycle-3

Cards on a whiteboard

Journal and Map, as Meta-apps, do not own the data of cards. They read and reference the card database of Heptabase, and the only data they have is metadata for presenting cards. For example, Map does not own the cards’ contents but store the cards’ spatial attributes (shape, color, arrow) on different whiteboards.

This sharing of card databases ensures that each Meta-app is not overly complex but is well integrated into a workflow, avoiding untraceable gaps between different stages of the knowledge lifecycle. When you see a card, you can trace when it was created, what other cards have mentioned it, what whiteboards it appears on, and its position in different mental frameworks.

The Knowledge Lifecycle-4

Shared Card Database

Collective knowledge creation

To build a contextualized knowledge internet, the final step is to let individual thinking interact and enable collective knowledge creation that can’t be done with any individual mind on their own. To achieve this goal, we must integrate the “sharing” and “exploring” stages of the knowledge lifecycle.

When it comes to collective intelligence, the examples that come to our mind are software like Notion and Miro, which put “shared workspace” and “real-time collaboration” in their value proposition. However, there are three main problems with such products that make collective intelligence difficult to emerge.

First, these shared workspaces force everyone in the team to use the same information architecture from the top-down, rather than letting everyone use the one that works for them.

Second, it’s easy to result in disorder when everyone’s thinking overlaps in the same workspace. It’s hard to know which documents are outdated and which are still in use. If many people have edited a document, it’s hard to trace why they edited it and the thinking context behind each editing.

Third, it’s easy to result in groupthink when entering real-time collaboration before the ideas from individuals get matured, which is terrible for independent thinking. For efficiency reasons, collaboration often takes a majority decision approach to develop ideas, resulting in an individual’s unique ideas being unexpressed and stifled early.

At Heptabase, we advocate bottom-up “asynchronous sharing” based on “personal workspace.” When knowledge workers want to collaborate, asynchronous sharing from a personal workspace allows them to track each other’s thinking clearer and reuse each other’s ideas and knowledge without disturbing anyone’s independent thinking process.

Instead of sharing an idea, we can share an entire thinking context that uses ideas as a unit. Every idea in each thinking context can be used by other thinking contexts. Heptabase’s context-tracing ability allows you to explore different thinking contexts behind any idea you see.

Summary

In short, from the perspective of “The lifecycle of human knowledge work,” we are building an ecosystem of tools to help knowledge workers integrate their knowledge lifecycle of exploring → collecting → thinking → creating → sharing. Our guiding principle is to optimize information interoperability, context retrieval, and collective knowledge creation, with the ultimate aim of evolving a contextualized knowledge internet.

In the next article, I will provide a detailed introduction to the structure of the Heptabase system, as well as the roadmap of our iterations for this system.