Tag: DKR

Summary of Doug’s call for Improving How We Improve

Published by Frode Hegland on May 16, 2018

Summary of Doug’s call for Improving How We Improve, edited into lists from the original keynote address, using only Doug Engelbart’s original words:

IMPROVING OUR ABILITY TO IMPROVE: A CALL FOR INVESTMENT IN A NEW FUTURE. Douglas C. Engelbart The Bootstrap Alliance April 23, 2002 (AUGMENT,133320,)

http://dougengelbart.org/pubs/augment-133320.html

A Level#

A level activities are the organization’s primary activities, such as marketing, sales, accounting, research etc.

B Level#

- B level investments are predictable.
- B level investments have specific objectives and tend to proceed in a straight line from specification to final delivery.
- Typical approach is narrowing the problem in order to make it more tractable.

C Level#

At the C level we are trying to understand how improvement really happens, so that we can improve our ability to improve.

- Different groups exploring different paths to the same goal constantly exchange information about what they are learning.
- The dialog between the people working toward pursuit of the goal is often just as important as the end result of the research. Often, it is what the team learns in the course of the exploration that ultimately opens up breakthrough results.
- Context is tremendously important, breakthroughs come from taking on an even bigger problem, moving up a level of abstraction, to look at the more general case.

The teams working at the C-level are working in parallel, sharing information with each other, and also tying what they find to external factors and bigger problems. Put more simply, C-level work requires investment integration – a concerted effort to tie the pieces together.

That is, by the way, the reason that the teams that I was leading at SRI were developing ways to connect information with hyperlinks, and doing this more than two decades before it was happening on the web. Hyperlinks were quite literally a critical part of our ability to keep track of what we were doing.

Thinking back to our research at SRI leads me to another key feature of development work at the C level: You have to apply what you discover. That is the way that you reach out and snatch a bit of the future and bring it back to the present: You grab it and use it: Application of the knowledge that is gained, as a way of not only testing it, but also as a way to understand its nature and its ability to support improvement.

CoDIAK#

As a mnemonic device to help pull together these key features of the C-level process, you can take “Concurrent Development,” “Integration,” and “Application of Knowledge” and put them together in the term “CoDIAK.” For me, this invented word has become my shorthand for the most important characteristics of the C-level discovery activity. The CoDIAK process builds on continuous, dynamic integration of information so that the members of the improvement team can learn from each other and move forward.

Pursuit of CoDIAK requires, in itself, some technical infrastructure to support the concurrent development and continual integration of dialog, external information, and new knowledge. If this sounds somewhat recursive to you, like the snake renewing itself by swallowing its own tail, be assured that the recursion is not an accident. As I just said, one of the key principles in CoDIAK is the application and use of what you learn. That recursive, reflective application gets going right at the outset.

DKR#

One of the most important things that we need is a place to keep and share the information that we collect – the dialog, the external information, the things that we learn. I call this the “Dynamic Knowledge Repository,” or DKR. It is more than a database, and more than a simple collection of Internet web sites.

It doesn’t have to be all in one place – it can certainly be distributed across the different people and organizations that are collaborating on improving improvement – but it does need to be accessible to everyone – for reading, for writing, and for making new connections.

The DKR is a wonderful example of the kind of investment that you can start making at the C level, with modest means, that will pay dividends back as it moves up the line to the B and the A levels.

You start small, and keep leveraging what you know at each stage to solve a bigger and bigger problem.

This is precisely the kind of outcome that can come from investment in building a DKR at the C level. What you learn there can be used to improve work at the C level, which in turn improves ability at the B level, which then translates into new capability at the primary, A level of the organization.

Hyperscope#

Another key, early investment is in the development of tools to provide access to the knowledge in the DKR for all classes of users, from beginners to professional knowledge workers expecting high performance. This “hyperscope” – that is my term for it – allows everyone to contribute and use the information in the DKR according to his or her ability.

ViewSpecs #

Tied to the hyperscope is the ability to provide different views of the knowledge in the DKR – and I do mean “views” – stressing the “visual” sense of the term.

Moving away from words on a page, we need to be able to analyze an argument – or the results of a meeting – visually. We need to move beyond understanding the computer as some kind of fancy printing machine and begin to use it to analyze and manipulate the symbolic content of our work, extending our own capabilities.

The Capability Infrastructure#

The Capability Infrastructure combines inputs from both the tool system and the human system.

The tool system is the contribution from the computer, provides access to different media, gives us different ways to portray information, and so on.
The human system brings its rich store of paradigms, information captured in customs, and so on.

Augmentation Systems#

The human system, as the part of this framework that is best at learning, also brings the opportunity to develop new skills, benefit from training, and to assimilate and create new knowledge. These dynamic elements are the “magic dust” that makes the whole system capable of innovation and of solving complex problems.

High-Bandwidth Symbol Manipulation#

These valuable, dynamic, human inputs must of course come into the system through the human’s motor and perceptual capabilities. If this interface is low-bandwidth and able to pass only a small amount of what the human knows and can do – and what the machine can portray – then the entire system tends to be more “automation” than “augmentation,” since the computer and the human are being kept apart by this low-fidelity, limited interface.

If, on the other hand, this interface can operate at high speed and capture great nuance – perhaps even extending to changes in facial expression, heart rate, or fine motor responses, then we greatly increase the potential to integrate the human capabilities directly into the overall system, which means that we can then feed them back, amplify them, and use them.

The key to building a more powerful capability infrastructure lies in expanding the channels and modes of communication – not simplifying them. If we begin to act on this notion of our relation, as humans, to these amazing machines that we have created, we really begin to open up new opportunities for growth and problem solving.

My sense is that computer science has brought us a gift of great power, the ability to amplify and extend our ability to manipulate symbols.

It seems to me that the established sources of power and wealth understand, in some dim way, that the new power that the computer has brought from the heavens is dangerous to the existing structure of ownership and wealth in that, like fire, it has the power to transform and to make things new.

We need to become better at being humans. Learning to use symbols and knowledge in new ways, across groups, across cultures, is a powerful, valuable, and very human goal. And it is also one that is obtainable, if we only begin to open our minds to full, complete use of computers to augment our most human of capabilities.

4 Comments

Glossaries Glorified into Core Connectors

Glossaries Glorified into Core Connectors

Published by Frode Hegland on January 29, 2018

Personal Context/Diary Note

This was written the morning after calling Jack Park to discuss using Glossaries as a means to tie documents and knowledge graphs together. I have since slept and I am now enjoying a nice single shot of espresso. Meanwhile, Jame’s sent an email with a great start to defining the goal and framework of a DKR, which I hope he will also blog so that I can refer to it easily here, while having yet another espresso at the Groucho. The approach comes from how yesterday morning I spent some time thinking about how I am kind of ‘representing’ the document approach and Jack Park and David Price representing knowledge graphs in databases approach and maybe I should quite simply switch my focus. For a while. I therefore thought about designing front end aspects of a knowledge graph while out for a walk with my son(!) across from Hammersmith to Wimbledon via the Common, and for some reason it hit me that a glossary definition might be a jump point between the two systems. I don’t know how this came about but here is the idea:

Glossaries Integrated into Knowledge Graphs

Doug sold me on the importance of glossaries, defined as definitions local to a document, author, field or some other particular use. It struck me that a glossary definition is made up of words and that at least some of these words also have glossary entries and that this might very well be a crude and simple knowledge graph!

Example

I enter “A DKR is produced using OHS technologies” which has two nodes: DKR as the term being defined and OHS being a term the DKR is being defined with, using the connection ‘is produced using’. This means we have two terms which are nodes and a link with a specific type.

Benefit: Reuse

This approach would allow for more easy re-use of contents (by having terms compressed and expanded into glossary terms in body text) and for rich visual and computational mapping of the terms in knowledge graph spaces with little initial effort when creating entries/nodes or integrating with them and keeps the various media intact all the while being deeply interrelated.

Glossary Entries as Knowledge Graph Nodes

So what I proposed to Jack is that we can use this as a kind of a human interface (as opposed to strict data transfer interface) between a regular document and a knowledge graph: A user can add to the knowledge graph by using this type of a ‘glossary’ interface when authoring and when reading a whole (or many whole) graphs can be accessible in this way. The reverse is of course also true, that when in a graph environment the user can benefit from what’s been added outside the graph environment.

So to achieve this we would have to build an interface for different platforms which can be invoked outside a knowledge graph but use its data. Jack said this is exactly what he and his team have been looking at but they called it something like wormholes or portals or teleports not glossaries but the principle remains pretty similar.

Scenario

I have posted a walkthrough scenario here: http://wordpress.liquid.info/glossaries-integrated-into-knowledge-graphs-scenario/

Importance of Powerful Views

Jack further discussed the importance of doing knowledge transforms, similar to how we can do mathematical transforms and this is just a powerful way of looking at it. I simply added the perspective of the user having the ability to jump around, to see same or related information in very different contexts and how I was annoyed that I refer to Headings as Nodes in Author when collapsing into Outline/Dynamic View and how that went further and how I found that the word Node actually basically means ‘knot’ and this removes the notion of a Node as being something solid and the connections between them something more etherial. Why not provide the user with the ability to flip the visual display so that Nodes becomes connecting lines and the connecting lines become the Nodes?

Seeing New Perspectives

BTW, I use purposefully visual vocabulary when discussing connecting lines since they could be so many things created in so many ways and interactable in so many ways, as I’ve been working on defining for some time and hope to put up a, yes, Glossary on, with the collaboration with all of you and particularly with our colleagues in Russia; Timour, Elena and Irina, based on Skype meetings, perhaps on http://symbolspace.info where we can write our definitions and where we disagree, if and when we inevitably usefully disagree, for a communal growth of this particular knowledge space.

Legacy Anchoring

This approach allows for interaction with a knowledge graph either natively or when in a more familiar environment and, crucially, allows for the user to switch between the environments at will and thus get the best of both worlds, or, to put it in a more Doug way, they get powerfully different ViewSpec options.

Issues

There are a lot of implementation issues of course, such as:

• what, if any, knowledge graph data is baked into the word processing document at the point of publishing the document

• what will the human-computer interfaces will be like; will they be plain text based like the original idea suggested or more click-on-categories and so on style?

• how should the data transfers be between these components? JSON-LD?

• how can we implement a frame for this on different OS platforms

• when should the data be integrated, immediately or use WordPress etc. as a glossary storage until a publish or other action?

• & more.

Proposal

I don’t know the answers, but I think this approach lends itself well to the criteria and goals proposed by James and should therefore be part of our core investigations.

I eagerly await comments here in the comment box, as blog posts or elsewhere.

DKR Criteria (after further comments)

Published by Frode Hegland on December 27, 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

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