Skip to content

Month: December 2017

Update email to group, 27 Dec 2017

Merry Christmas Everyone! 

The status for the initiative to produce Something To Demo for the anniversary is nothing. Virtually nothing has been achieved this year.  

Organising for the celebrations on the day however, is coming along apace, with SRI and CHM collaborating so that is all well and good. While some of us thought we could inspire some collaboration to build something useful it turns out we have only been badgering a lot of you. We apologise.  

I am not the boss of this nor do I have any special qualifications, credentials or even credibility and I would be very happy to hand this over to someone else to bind together, but frustrating as it is, I think trying to build something to demo is vitally important. I have therefore decided to stop emailing you as a group, since this is just cluttering your mailbox. I will ONLY keep emailing those of you who explicitly ask me asking to stay on this software build list.   

However… 

Just as we needed to develop an environmental movement to help us deal with the environmental problems we are facing, there will at some point, a point I think we have long since passed, be a need to develop a deep literacy movement to help us deal with the sophisticated systems and tools we will need to develop in order to deal with increasingly urgent, complex problems.  

If we don’t do this, we will tip over to a point where we simply won’t have developed the expertise, experience, knowledge and know-how as well as culture and attitude (getting rid of the “I’m not a computer person” and “what I learnt to do in college is good enough 20 years later because I don’t have time to become more efficient” or even “tools don’t think, people do” on the theme of “guns don’t kill, people do”) to build ever more powerful knowledge systems. 

In order to do this we will need to coordinate designers, users, researchers, cognitive scientists and computer scientists on a useful scale. Otherwise, we will be stuck with the click-button over-simplicity which has dominated human-computer interaction since the popularisation of the GUI.  

Doug On Skis 

In my mind Doug Engelbart is screaming down a hill with the finesse of a world-class skier, in consummate control of every muscle in his body to move him over and around the shape of the mountain, hitting exactly the right beats, going exactly where he wants to go, with the greatest efficiency. Behind him are the rest of us, walking down with skis in our luggage since it would take too much effort to learn how to ski properly. 

Athletes of The Mind 

I am not talking about how to move through snow of course, I am talking about how we move through and manipulate information. Where we plod, he flies through cyberspace. It makes me smile thinking of him like that, but when I see the rest of us bumbling down the mountain there is nothing but sadness and fear, fear that we may simply not be up to the task of building augmentation systems for athletes of the mind with anything like the zeal we employ to augment and cheer on athletes of the body.  

Do we as as species posses the ability to come together to do that? Does our current population of 7 billion or so contain enough people who are passionate about this and organisations who will support them? 

Urgency & Opportunity 

This is an existence level question since it is becoming increasingly clear, as Doug warned us and Donald demonstrates, that our problems are becoming ever more complex and time sensitive but our ability to deal with the problems is not nearly keeping pace. I pointed out to the group that we have a once in a lifetime opportunity with the anniversary next year and I asked what people wanted to contribute but the response was a heavy silence. To enter 2018 with no real direction, resources or plans will be terrible. Every day gone reduces our ability to produce something amazing.  

• Can we build a truly rich dynamic knowledge space, in Doug’s language a Dynamic Knowledge Repository?  

• Can we even define what a modern DKR would be?  

• Or will we simply continue to work on our isolated projects and chat over coffee, only improving as much as a single effort is capable off? 

ACTION REQUEST 

I therefore ask you to have a look a the core Criteria for a 21st Century DKR. Please review and comment on whether you agree or have anything to add: http://wordpress.liquid.info/dkr-criteria-after-further-comments/ Also, for you who are interested, there is a weekly call today, 5PM UK time, 9AM Pacific: https://join.skype.com/jyTAc0eRXnJj 

And here is a picture of our 7 ¾ month old son Edgar when he got to meet Santa. I hope we will all get to *be* Santa next year   :-) 

Frode Hegland 

The Liquid Information Company 

#liquid.info | futureoftext.org 

Leave a Comment

DKR Criteria (after further comments)

 

A 21st Century Dynamic Knowledge Repository ‘DKR’, will have some differences to Doug’s 20th Century model, which was created in an era of mainframes with limited bandwidth, processing capacity and ecosystems. Note, the term ‘document’ as used here refers to any data set which can be stored or transported on its own but does not at all need to carry the baggage of the term and is expected to evolve substantially. Please further note that the DKR is not a monolithic ‘bank account’, it is not a collection of documents, it’s an active ecosystem with an emphasis on the Dynamic processes it can support. 

 

A dynamic knowledge repository is a living, breathing, rapidly evolving repository of all the stuff accumulating moment to moment throughout the life of a project or pursuit.  http://www.dougengelbart.org/about/dkrs.html  

 

It is an ecosystem connected to the world, not isolated from it.

 

We are not trying to build a product here, we are trying to collaboratively establish a series of frameworks and build some of the components ourselves for proof of concept and further learning and development. 

 

 

Criteria 

 

These are the criteria as we understand them at the end of 2017: 

 

Design Perspective 

 

• The system needs to have provisions to co-evolve with the end users so user engagement in the design process is important 

• The system needs to be explicitly designed to bootstrap itself into ever more powerful versions 

• The design direction is to imagine and build powerful tools first and then on making them as useable as possible 

• Along the same lines, the design direction will focus on high performance users while providing novice users basic interactions 

 

Interactions 

 

• The DKR needs to support the CoDIAK process of ‘concurrent development, integration, and application of knowledge’ 

• The focus needs to be on rich interactions, where the user should be able to achieve high performance through powerful tools, not on ease-of-use for the sake of it 

• Creating powerful views, or ViewSpecs, of the information space is a prime challenge 

• Representing, analysing, creating and modifying information connections through links, associations, bindings, dimensions, searches and more, will further be a prime interaction challenge  

 

Data Space 

 

The system will need to support multiple data spaces, including but not limited to: 

 

• Live Database Interaction of Knowledge Gardens 

• Collaboratively authored Documents 

• Individually authored Documents 

• A Journal system for publishing Documents which are highly interrogable with a robust versioning system 

• All current and future media types and meta data 

• And the means through which to transfer data between the different spaces, both through networks and through something like Socratic Authoring   

 

Underpinning This 

 

• All material needs to be archived in usable and accessible ways for access in the distant future 

• The DKR needs to be able to interchange data with legacy systems   

• The DKR needs to be able to interchange data with different components among a heterogenous DKR 

• The DKR will be heterogenous, meaning that anyone can build components  

• The DKR must be massively scalable and robust, in order to deal with ever growing profusion of data and links.  

 

 

Questions raised from Dialog 

 

To contribute to this dialog please blog your thoughts and email a link to the webmaster, frode@liquid.info or post your thoughts as a comment below: 

 

• Vint Cerf  

 

“What kind of scaling problems might we encounter? will increasing numbers of documents produce increasing amounts of references that have to be repeatedly updated? the one-way links of the WWW escape this problem at the cost of broken links and lack of backward references”.  

 

This was entered in the list as ‘Must be massively scalable and robust, in order to deal with ever growing profusion of data and links.’ In the Underpinning This section. 

 

• Jack Park

 

You made it *document centric* since a repository holds stuff, mostly documents. I would argue that documents are only a tiny fraction of a DKR. For example, there is a kind of operating system for DKRs about which nobody (except the TQ tribe) ever speaks. After all, there is a social system in there together with a tool system. The social system needs an OS; we believe that an appropriate OS is Presencing. 

 

In the document-centric context, please note that Ward Cunningham’s FedWiki comes damned close to covering most of your key points. 

 

Also, too (channelling a recent female VP candidate), Yuzuru Tanaka’s Meme Media — WebbleWorlds — was invented when the OpenDoc initiative collapsed. You want documents, go talk to Yuzuru. He wrote a book about that whole space; well worth studying.  At the same time, he conducted a major conference on Knowledge Federation on the Web, long before Dino and I did the same thing. In fact, he attended every one of our Dubrovnik conferences. 

 

Final point: I salute any effort to come to grips with what DKRdom means. I would submit that it is borderline a fool’s errand to become so explicit in what, precisely, a DKR *is*. It will be whatever people make it to be. Pretty much, full stop.  But, that’s not the end of the story. You heard this before: 

 

Since there are now and in the future will be more DKRs out there, the Engelbart vision is best served not by engaging in pissing contests about *WTF is a DKR?* but, instead, how the hell to federate them.  In that context, I worship another hero: 

 

Oliver Selfridge, who, in 1958 — about the same time as some people got together at Dartmouth and invented the discipline of Artificial Intelligence — published a paper about his program Pandemonium. Pandemonium is a program with lots of agents. Some of them are pattern detectors. Like neurons, they shout according to the degree to which they detect a pattern.  Others are listeners; they evolve to turn the signals of groups of pattern detectors into other signals which are monitored by decision makers.  Think about it: that’s a DKR.” 

 

• Mark Szpakowski 

 

“I’ve installed Author (I’m a Mac owner, box of tissue by the side) & watched a couple of the videos. Gardening, documents, and document authoring certainly relate. You want to be able to harvest the garden at times, into forms such as text documents or more fully multimedia forms. Right now Author can bring in “citations” from sources such as Wikipedia or Amazon or anywhere: in this case the world-wide web is a kind of patchwork of jungle and cultivated areas. If there were a TopicQuests-style garden (a k-hub) then it could be a source from which Author could retrieve citations. Author-ed documents could then also get published/planted back into that garden. That could be mutually useful. 

 

Another growth direction might be along the lines of a “perspective editor” (in context of quests hosted on k-hubs which result in perspective documents (more static) or perspective viewers (more dynamic)), which could have two panes, one being the document editor, and the other being a view into an information source (like a garden) where the pieces to be documented appear in various forms (for example, you might have selected subsets of an IBIS conversation tree). The pieces from which the document is written are assembled “in the garden” (which also enables persistence and further personal or group re-use as permissioned), and then the document is written by one or more people. If the latter, then another adjacent growth direction is multi-user authoring. 

 

Regarding platforms, to further success these days the platform is the multi-device world. For example, for short-form writing and notes I use Bear, which works and syncs transparently across my MacBook, iPad and iPhone. Looking forward, I think DKR control rooms will be guild/agent-assembled mosaics making use of all available devices. But for now, as stepping stones and to demonstrate forward steps, limited platforms (Author is Mac-only) seem acceptable. If the functionality is seen as valuable, there will be pressure to implement it on the desired platforms. 

 

So, tl;dr: let Author read from and write to knowledge gardens. 

Is this Author-Garden federation?” 

 

• James Prescott 

 

“My name is James Prescott, and I was added to this email chain by Jack. We work together on TopicQuests. I have been hesitant to jump in because while I am a fan of Doug Engelbart’s work, I do not have the connection to him most people on this list seem to have. I never met him and, based on what I have heard, I felt that I would never be able to “get it” the way Mr. Engelbart got it. I would just have to muddle through with my interpretation of it.  

 

In some ways the lack of familiarity is helpful; instead of being worried about strict definitions, my concern is what works best and is used by the most amount of people. I can never achieve perfect Engelbart form, but if I am really good I can capture the spirit and function.  

 

In that spirit I would like to suggest two things. First, in terms of federating effort and creating an environment for development, I would like to recommend a process developed by Local Motors. They crowdsource the design of their vehicles at this site. It seems to me that creating a portal like this one to make it easy for people to jump on and off projects easily based on interest and skillsets is what the MOAD conference can use to facilitate the development of the Engelbartian tools we all need. It makes onboarding easier; plus you could build events around a site like this (hackathons, locals discussions, etc.) A centralized site with all of the projects that individuals across the country could swarm on. I think that could be a powerful thing. 

 

Second, it appears to me that there is a definition problem regarding what precisely to build. Different people have different priorities, and in the spirit of federation that would seem to expected. Instead of trying to constrain people to one set of features and risk alienating allies, MOAD50 can come up with a general set of guidelines (possibly specifically about how the data will be structured) and set everyone loose. MOAD50 doesn’t build a product; it establishes a framework or schema. This way, instead of revealing one product or tool, you can have an eco-system of interoperable tools, each of which speaks to an aspect of the Engelbartian vision. 

 

Just a thought from an uninitiated. Your personal mileage may vary. Thanks for your patience and thanks for organizing all this.” 

 

2 Comments

Criteria for a 21st Century Dynamic Knowledge Repository ‘DKR’ (submitted to group 7 Dec 2017)

A 21st Century Dynamic Knowledge Repository ‘DKR’, will have some differences to Doug’s 20th Century model, which was created in an era of mainframes with limited bandwidth, processing capacity and ecosystems. Note, the term ‘document’ as used here refers to any data set which can be stored or transported on its own but does not at all need to carry the baggage of the term and is expected to evolve substantially. Please further note that the DKR is not a monolithic ‘bank account’, it is not a collection of documents, it’s an active ecosystem with an emphasis on the Dynamic processes it can support. 

A dynamic knowledge repository is a living, breathing, rapidly evolving repository of all the stuff accumulating moment to moment throughout the life of a project or pursuit.  

#http://www.dougengelbart.org/about/dkrs.html  

We are not trying to build a product here, we are trying to collaboratively establish a series of frameworks and build some of the components ourselves for proof of concept and further learning and development. 

Criteria 

These are the criteria as we understand them at the end of 2017: 

Design Perspective 

• The system needs to have provisions to co-evolve with the end users 

• The system needs to be explicitly designed to bootstrap itself into ever more powerful versions 

• The design direction is to imagine and build powerful tools first, then on making them as useable as possible second 

• The design direction will furthermore focus on high performance users while always allowing novice users basic interactions 

Interactions 

• The DKR needs to support the CoDIAK process of concurrent development, integration, and application of knowledge 

• The focus needs to be on rich interactions, where the user should be able to achieve high performance through powerful tools, not on ease-of-use for the sake of it 

• Creating powerful views, or ViewSpecs, of the information space is a prime challenge 

• Representing, analysing, creating and modifying information connections through links, associations, bindings, dimensions, searches and more, will further be a prime interaction challenge  

Data Space 

The system will need to support multiple data spaces, including but not limited to: 

• Live Database Interaction of Knowledge Gardens 

• Collaboratively authored Documents 

• Individually authored Documents 

• A Journal system for publishing Documents which are highly interrogable with a robust versioning system 

• All current and future media types and meta data 

Underpinning This 

• All material needs to be archived in a usable and accessible way for the distant future 

• The system needs to be able to interchange data with legacy systems   

• The system needs to be able to interchange data with different components among a heterogenous DKR 

• The DKR will be heterogenous, meaning that anyone can build components  

• Must be massively scalable and robust, in order to deal with ever growing profusion of data and links.  

Questions raised from Dialog 

To contribute to this dialog please blog your thoughts and email a link to the webmaster, frode@liquid.info or post your thoughts as a comment below. 

Vint Cerf  

“What kind of scaling problems might we encounter? will increasing numbers of documents produce increasing amounts of references that have to be repeatedly updated? the one-way links of the WWW escape this problem at the cost of broken links and lack of backward references”.  

This was entered in the list as ‘Must be massively scalable and robust, in order to deal with ever growing profusion of data and links.’ In the Underpinning This section. 

Jack Park 

“It seems to me that your quest is now much better in focus. It would seem to me that you are now looking for intersections with other agendas, such as ours. 

Where is the overlap? 

Let me start here. 

I view everything that goes on as communication of one sort or another, starting with atoms communicating by binding, forming molecules which, similarly communicate by binding, which create organs which also communicate and form alliances to form organisms which communicate to form social networks, and here we are. Communicating at the social level. 

It’s *all* about conversation. 

In that context, I worship two heroes: 

Gordon Pask for his Conversation theory, in which we see speakers and listeners, trading places, and always negotiating  a space in between them Pask called an “entailment mesh” which I would call an kind of consensus topicmap. It’s both in the ether between us, and growing in our brains. 

Daniel Kahneman for his Thinking Fast and Slow, which, IMHO, properly articulates *how* we communcate. 

Now, Author, in that grand scheme of things, fits here: 

Kahneman’s really slow and articulate thinking 

Pasks speaker. 

A crucial point about Pask’s speaker: a speaker is speaking from a possessed domain model, but uses internal listener models to help structure what is uttered. No sense in talking about DeMorgan’s theorem to a toddler… 

So, a speaker, through Author, might be writing a dissertation, so that dissertation will be structures for listeners who are thesis committee members. 

A speaker, through Author, writing for, say, the relatively literate audience that reads medium.com, will necessarily structure the document differently. 

Overall, I see Author in the context of scholarly content submitted into the knowledge garden, and that’s were the intersections begin. 

My opinions follow. 

Author is, in its present implementation,  aimed at snotty Mac owners who have the cajones to upgraded their OS to Sierra. That means, for now, it’s not for everybody, so its intersection with the garden is limited to folks who craft PDF documents they wish to share into the garden, in which case, it fits already. 

Author in the future is anyone’s guess. To the extent and duration that it remains only for snotty Mac owners, it’s wide open to replication in the open source arena. Consider Substance: http://substance.io/  It has been around for moons. To the extent that people observe what’s insanely great about Author, some will evolve Substance in that very direction. 

So, where, really, are the intersections? 

I believe, Frode, that you have the opportunity to set the bar really high, and, from my own perspective, the garden — the TopicQuest’s interpretation of what DKRdom means — is all about setting the bar really high. TheDoug would be proud. 

Turning now to the message you just sent around to a limited group in which you linked your DKR spec document: 

#http://wordpress.liquid.info/criteria-for-a-21st-century-dynamic-knowledge-repository-dkr-sketch-with-first-notes/ 

I note that you chose a particular, and IMHO terribly restrictive definition of DKR: we are back to bank accounts. You chose that one from a document which is a summary doc authored, most likely, by Christina. It all centers around interpretation of the specific word *repository*. See below. 

Doug’s seminal paper http://www.dougengelbart.org/pubs/augment-132811.html does not even mention DKR.  It’s not until later, and consider this paper: 

#http://www.dougengelbart.org/about/vision-highlights.html#1e and the specific paragraph in which a DKR is defined: 

“Central to improving a group’s Collective IQ will be cultivating increasingly effective “Dynamic Knowledge Repositories” (DKRs) – essentially the capability, in dealing with a complex problem, for advancing our knoweldge of, and providing the best, up-to-date understanding of, the current state of both the problem and its solutions. In this use of the term, “repository” is a living, dynamic ecosystem in which the group’s knowledge work emerges and is readily captured, integrated and evolved. Tool Systems would be endowed with Open Hyperdocument System technology specifically designed to rapidly improve our collective process – especially the ongoing organic emergence and utility of comprehensive DKRs within that process.” 

This is Christina again. The first hyperlink is to the page from which you quote, but notice carefully that the paragraph soon gets specific about “repository” as a *living, dynamic ecosystem* — it’s most definitely not a bank account. 

We are now in the domain of religious belief systems, and interpretations of domain bibles. Wicked-central, but not for most people: most of the people in that tiny tribe you addressed this morning are not at all aware of subtle differences in interpretations and certainly don’t care. 

If you insist that a DKR is a repository in the same sense as a bank accounts, then let’s just build the world’s best topic map and be done with it. If, instead, you believe that a DKR is an ecosystem best understood as TheDoug’s NIC system, then we are way closer to the same page. It is only in the ecosystem interpretation that Author even matters. 

Second point: 

You made it *document centric* since a repository holds stuff, mostly documents. I would argue that documents are only a tiny fraction of a DKR. For example, there is a kind of operating system for DKRs about which nobody (except the TQ tribe) ever speaks. After all, there is a social system in there together with a tool system. The social system needs an OS; we believe that an appropriate OS is Presencing. 

In the document-centric context, please note that Ward Cunningham’s FedWiki comes damned close to covering most of your key points. 

Also, too (channelling a recent female VP candidate), Yuzuru Tanaka’s Meme Media — WebbleWorlds — was invented when the OpenDoc initiative collapsed. You want documents, go talk to Yuzuru. He wrote a book about that whole space; well worth studying.  At the same time, he conducted a major conference on Knowledge Federation on the Web, long before Dino and I did the same thing. In fact, he attended every one of our Dubrovnik conferences. 

Final point: I salute any effort to come to grips with what DKRdom means. I would submit that it is borderline a fool’s errand to become so explicit in what, precisely, a DKR *is*. It will be whatever people make it to be. Pretty much, full stop.  But, that’s not the end of the story. You heard this before: 

Since there are now and in the future will be more DKRs out there, the Engelbart vision is best served not by engaging in pissing contests about *WTF is a DKR?* but, instead, how the hell to federate them.  In that context, I worship another hero: 

Oliver Selfridge, who, in 1958 — about the same time as some people got together at Dartmouth and invented the discipline of Artificial Intelligence — published a paper about his program Pandemonium. Pandemonium is a program with lots of agents. Some of them are pattern detectors. Like neurons, they shout according to the degree to which they detect a pattern.  Others are listeners; they evolve to turn the signals of groups of pattern detectors into other signals which are monitored by decision makers.  Think about it: that’s a DKR.” 

Mark Szpakowski 

“I’ve installed Author (I’m a Mac owner, box of tissue by the side) & watched a couple of the videos. Gardening, documents, and document authoring certainly relate. You want to be able to harvest the garden at times, into forms such as text documents or more fully multimedia forms. Right now Author can bring in “citations” from sources such as Wikipedia or Amazon or anywhere: in this case the world-wide web is a kind of patchwork of jungle and cultivated areas. If there were a TopicQuests-style garden (a k-hub) then it could be a source from which Author could retrieve citations. Author-ed documents could then also get published/planted back into that garden. That could be mutually useful. 

Another growth direction might be along the lines of a “perspective editor” (in context of quests hosted on k-hubs which result in perspective documents (more static) or perspective viewers (more dynamic)), which could have two panes, one being the document editor, and the other being a view into an information source (like a garden) where the pieces to be documented appear in various forms (for example, you might have selected subsets of an IBIS conversation tree). The pieces from which the document is written are assembled “in the garden” (which also enables persistence and further personal or group re-use as permissioned), and then the document is written by one or more people. If the latter, then another adjacent growth direction is multi-user authoring. 

Regarding platforms, to further success these days the platform is the multi-device world. For example, for short-form writing and notes I use Bear, which works and syncs transparently across my MacBook, iPad and iPhone. Looking forward, I think DKR control rooms will be guild/agent-assembled mosaics making use of all available devices. But for now, as stepping stones and to demonstrate forward steps, limited platforms (Author is Mac-only) seem acceptable. If the functionality is seen as valuable, there will be pressure to implement it on the desired platforms. 

So, tl;dr: let Author read from and write to knowledge gardens. 

Is this Author-Garden federation?” 

James Prescott 

“My name is James Prescott, and I was added to this email chain by Jack. We work together on TopicQuests. I have been hesitant to jump in because while I am a fan of Doug Engelbart’s work, I do not have the connection to him most people on this list seem to have. I never met him and, based on what I have heard, I felt that I would never be able to “get it” the way Mr. Engelbart got it. I would just have to muddle through with my interpretation of it.  

In some ways the lack of familiarity is helpful; instead of being worried about strict definitions, my concern is what works best and is used by the most amount of people. I can never achieve perfect Engelbart form, but if I am really good I can capture the spirit and function.  

In that spirit I would like to suggest two things. First, in terms of federating effort and creating an environment for development, I would like to recommend a process developed by Local Motors. They crowdsource the design of their vehicles at this site. It seems to me that creating a portal like this one to make it easy for people to jump on and off projects easily based on interest and skillsets is what the MOAD conference can use to facilitate the development of the Engelbartian tools we all need. It makes onboarding easier; plus you could build events around a site like this (hackathons, locals discussions, etc.) A centralized site with all of the projects that individuals across the country could swarm on. I think that could be a powerful thing. 

Second, it appears to me that there is a definition problem regarding what precisely to build. Different people have different priorities, and in the spirit of federation that would seem to expected. Instead of trying to constrain people to one set of features and risk alienating allies, MOAD50 can come up with a general set of guidelines (possibly specifically about how the data will be structured) and set everyone loose. MOAD50 doesn’t build a product; it establishes a framework or schema. This way, instead of revealing one product or tool, you can have an eco-system of interoperable tools, each of which speaks to an aspect of the Engelbartian vision. 

Just a thought from an uninitiated. Your personal mileage may vary. Thanks for your patience and thanks for organizing all this.” 

Leave a Comment