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.
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.
> 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?).
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)
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.)
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.
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!
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 ;)
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.
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.