Comment by Terretta | Hacker News Reader

Comment by Terretta | Hacker News Reader

I read this as a prophecy of Foam (https://github.com/foambubble/foam), Obsidian.md (https://obsidian.md/), and the like. See this thread on Foam from 2020:

https://news.ycombinator.com/item?id=23666950

Despite ”design for knowledge based organizations” being the title of the article in the PDF, this is perhaps more about approach and capabilities for organizing flow from capture to use to pruning of knowledge, more than the organizations working on knowledge.

There is one aside about the organization itself:

> Engelbart sees every organization as a collection of interacting knowledge domains. He has focused his research on designing support structures for knowledge collection and refinementwithin and across these knowledge domains.

But then that jumps down into a given domain, and goes on to propose a knowledge management approach within that (and each) domain.

This is where it gets interestingly predictive of the recent coalescence in knowledge management tools emerging after the two dark age decades of style over semantics.

The first idea is a concept of bringing knowledge in, working it, and keeping it. He calls this Concurrent Development, Integration, and Application of Knowledge (CODIAK) process.

To make this workable he proposes a time-relevance layered approach very similar to the (perhaps easier to action) “PARA” method adopted by many KM tool users today:

https://fortelabs.com/para

After this, he goes into functional implications, and describes almost to a T capabilities in the latest round of knowledge management tooling “systems” such as, say, Obsidian.md, built on standards (markdown, wikilinks, front matter) and extensibility enabling journaling, querying, views, as first class citizens.

When hypertext markup iterated into a page style description advertorial tool rather than linked semantic knowledge structure, that left an opening for the tools we’re seeing now. Today, Obsidian.md is close to the mark, except, of course, for approachability by casuals. For casuals, consider e.g. Craft.do (https://www.craft.do/).

If you’re doing a comparison before jumping in, it’s worth diffing the tools against Englebart’s take.

I’d argue he’s dead on.

Obsidian's been helpful, even game-changing for my working life. But my obsidian knowledge is siloed to my computer. Is there something similarly good for working with teams/organizations? Confluence and Notion seem to check some of the boxes, but neither tool feels as fluent to use as Obsidian or Roam.

I like craft.do for teams with casuals on them, it allows you to make team spaces. It’s markdown based and also has incredibly frictionless online sharing.

For technical teams, you can hook your obsidian markdown folders to a multi-party savvy file sync system, e.g. git, there are extensions for this. Then it plays nice with, for example, team members using VS Code as well. You can match the markdown, linking, tagging, etc., using VSCode plugins, or by carefully matching options between them, you can have some people in Obsidian and some people in VSCode + Foam.

Craft looks interesting, thanks for the reply!

Using obsidian+git is definitely possible, but it doesn't really get to the seamless collaborative feel that I'm looking for. Looking into Notion again, it seems like they've imported more ideas from Roam et al. and might be worth another look.

There are similarities but I'd disagree with this:

> Despite ”design for knowledge based organizations” being the title of the article in the PDF, this is perhaps more about approach and capabilities for organizing flow from capture to use to pruning of knowledge, more than the organizations working on knowledge.

I would agree that without the tools, an organization wouldn't be able to collaborate effectively in the way he advocates for, but I think unlocking group productivity should very much be more the goal here than single-person productivity. From the second page: "Englebert realized that they key to dealing with increasing complexity was human collaboration."

No amount of methodology will let a single person keep up with a team using a similar methodology.

Another key line from me: "Englebert is not advocating that we perform artificial acts with documents by superimposing structure on them. Instead, he advocates that we capture the inherent structure in all forms of human expression in order to make them easier for people to navigate through, view in different ways, and hyperlink."

As you note, there are a lot of similarities in there to Roam Research and those similar systems, especially the cross-linking/blocks type stuff vs just having a single hierarchical document structure. But don't just think of it for your own navigation and recollection, but for others to learn and get up to speed and then offer their perspectives.

But I think it's a big disservice to think about it only from a single-person's POV vs a way of capturing knowledge inside a group.

Think of "git" for software dev too, which is very along the lines of the logging/journaling of changes discussed in the article, but which differs from some previous iterations by being far more multi-user friendly (remember fighting over SVN locks?).

This presumably is the point where one should consider that long before Foam, there were things called "wikis". One of them tries to build a network of human knowledge. It's called Wikipedia, you might have heard of it ;)

Foam is simply the next evolution - the shared tool is well-understood, we're now getting an augmented local version. And after that, we'll get something that's far more multi-user friendly, too. It's a pendulum that seems to swing back and forth in our industry.

The thing that I hope Foam & Friends will generate is a much better understanding of knowledge "operations", so we can understand the fundamental structures underneath better. (That's what happened with git & signed DAGs as version log. That's what happened with text & CRDTs as a model of shared edits)

In terms of the commenter here talking about "tools emerging after the two dark age decades of style over semantics" wikis don't count as new development. ;) Even Wikipedia is more than 20 years old.

And I think wikis are still quite limited in that bit I quoted: "Englebert is not advocating that we perform artificial acts with documents by superimposing structure on them. Instead, he advocates that we capture the inherent structure in all forms of human expression in order to make them easier for people to navigate through, view in different ways, and hyperlink."

They have hyperlinks, sure, but otherwise most pages in wikis have only those views that can be created through operations on a hierarchical table of contents. The structure is imposed by the tech, there, rather than the expression of knowledge itself. The blocks in Roam - https://thinkstack.club/how-to-use-roam-block-reference-menu... - seems like a major iteration on that to me in terms of moving towards units of knowledge as the fundamental element instead of "pages." (It's also worth noting that Foam doesn't do this - https://github.com/foambubble/foam/issues/294 - though apparently Obsidian does.)

Absolutely. But the blocks, which are the one notable improvement, are tech that isn't well-used enough that we could make sense of it in a multiuser environment. That's the reason it's single-player right now. (And hence my comment about better understanding underlying structures)

And yes, it's closer to Engelbert's vision. We've been getting closer to that (and the Memex) for a long time, and we'll continue to do so. They are distant visions what a future could look like, while we barely understand knowledge work. I mean, the term itself is already an improvement of clarity on the ideas of the memex.

If you compare knowledge work to Mathematics, I'd guess we're shortly before Elements. We're at best about to understand the basic building blocks. Which I find tremendously exciting - we're still at the very beginning of exploration.

Maybe I'm too software-development-oriented but I feel like the blocks are tantalizingly close to being ready for multi-user. EDIT: To the point of frustration with how things like that are still silo'd away. Seems like so much work has been done around like "concurrent editing" (Notion seems like a big improvement over Confluence here, but still seemed to be the same page-based world just with a better editor) but so little around what documentation are we actually building for teams?

In my head they're akin methods, and so in software that idea of "call this from lots of different places, edit it in a centralized way" concept is pretty well established.

In terms of "a single document flowing with a single voice" you can't necessarily do that from assembling an arbitrary collection of blocks like that, but for "good enough for effective in-corp collaboriation"? Sure!

Maybe. The problem with multi-user blocks is the same as with methods in software - Hyrum's law. People will rely on them staying as-implemented vs as-spec'd.

I think that (and the problem of bait-and-switch) still need an answer before it's usable beyond small groups. Maybe small groups is good enough for now. If it goes in any form like software development, we'll at some point split into two camps. One will say YOLO and just implement shared blocks, trusting in good will, and the other group will noodle on foundational principles to get this right. (Group 1 will make the money, group 2 will have the fun. As always ;)

I was describing this as a system for all persons within a given knowledge domain at an organization, not individuals.

That’s what E’s describing as well.

My point is, he’s NOT describing how to communicate between domains, thus, it’s not really the whole organization, it’s the domains (teams) within an organization.

Engelbart was always dead on. But very few listened, and now, unfortunately he’s just dead. And we are stuck with unchangeable web pages laid out for graphic design purposes rather than understanding and information reuse. It will be another several decades before this broadly changes.

Reply on news.ycombinator.com