[HN Gopher] Doug Engelbart's design for knowledge-based organiza...
___________________________________________________________________
Doug Engelbart's design for knowledge-based organizations (1992)
[pdf]
Author : conanxin
Score : 47 points
Date : 2022-09-02 14:07 UTC (8 hours ago)
(HTM) web link (www.dougengelbart.org)
(TXT) w3m dump (www.dougengelbart.org)
| physicsgraph wrote:
| This seems to be a preview of an article available as PDF after
| you sign in. Without the main content the purpose isn't clear to
| me. Am I missing something?
| Jtsummers wrote:
| https://www.dougengelbart.org/pubs/seminars/sembinder1992nov...
| - A PDF of the actual thing, matches the two opening paragraphs
| and you don't need to sign-in. From 1992, for the curious.
| 082349872349872 wrote:
| > _From 1992_
|
| That explains the fax-mediated comments section. I guess HTML
| FORMs[0,1] weren't going to hit until late[2] 93...
|
| [0] https://web.mit.edu/kolya/.f/root/net.mit.edu/sipb.mit.ed
| u/u...
|
| [1] View Source confirms still in use by HN
|
| [2] http://1997.webhistory.org/www.lists/www-
| talk.1993q4/0447.ht...
| dang wrote:
| We've changed to that from
| https://www.customers.com/articles/doug-engelbarts-design-
| kn... above. Thanks!
| Terretta wrote:
| 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.
| majormajor wrote:
| 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?).
| mikewarot wrote:
| Bush's Memex and Engelbart's mother of all demos hint at
| something much more powerful than HTML and the premature
| optimization that we got as a result.
|
| In reading the pdf linked by Jtsummers, I recall how some of the
| sales people I supported had 20+ gigabytes of email in their
| inboxes... which drove me nuts (Exchange Server really didn't
| cope well with it back then), and _now I know why_ , they were
| building a hyperlinked database (well, threaded) that they could
| search through.
|
| Here in HN, we do the same thing over time, building a tree
| structured database that preserves context and is searchable. The
| main limitation here is there's only one possible tree, and it's
| the privileged view.
|
| There's at least a billion dollars of knowledge captured _here_
| in HN. Yet, it takes Dang and a strong community to keep that one
| view rational, due to the corrupting forces of human nature and
| profit motives from spam and scams.
|
| There's got to be a better way.
| dr_dshiv wrote:
| Autoencode it into the latent space of the collective
| conceptual understanding. (See OpenAI's latest paper on
| concepts arising due to "multimodal neurons" [1]). Then use all
| of hacker news to "fine tune" GPT-x. That will preserve the
| knowledge in a highly flexible manner that can be queried at
| will to generate any representation you like.
|
| [1] https://openai.com/blog/multimodal-neurons/
| Xeoncross wrote:
| I think Google, GPT-3, co-pilot, simple tricks like a
| 'wordcloud' and even regurgitation/review communities like HN,
| reddit and good reads show that the presentation format of the
| information in a given system can be transformed to many
| diverse representations.
|
| Books and movies have long made plots off new ways to help
| humans learn things and form connections by either 1) changing
| the presentation format or 2) downloading all the information
| into the human brain to let it do the sorting. For example,
| overlying data on a map in 3d using glasses or wiring a human
| brain into a computer's serial ports.
|
| The main problem moving forward is making the data available. I
| have a fear that in the future only governments and large
| companies in bed with governments will have access to this data
| and use it in unethical ways.
|
| Meanwhile, startups and individuals will be bared from creating
| 'unlicensed' presentations or accessing the underlying data
| itself (i.e. running a search engine)
___________________________________________________________________
(page generated 2022-09-02 23:00 UTC)