THE WELCH COMPANY
440 Davis Court #1602
San Francisco, CA 94111-2496
415 781 5700


Date: Thu, 30 May 2002 20:30:17 -0700

04 00067 61 02053002



Unfinished Revolution
ba-ohs-talk@bootstrap.org
OHS DKR Project
SRI International
333 Ravenswood Avenue
Menlo Park, CA 94025
..
Subject:   What are we trying to accomplish?

Dear Paul,

Responding to your letter

Specifically on October 25, 2000 Doug called for developing technology that implements the OHS Launch plan that describes a Hyperscope, a DKR and a new work role for augmenting intelligence that improves handling of daily working information for solving world problems.
..
Another thing Doug wants to accomplish is to foster a community of practice that "bootstraps" its expertise by applying ABC improvement methods to existing technology, primarily through linking email that creates a connected web of dialog and analysis that, over time, grows knowledge about how to augment intelligence and how to build technology that aids that objective.
..
So far these objectives have not been accomplished, except see by SDS for example on December 22, 1999, and later on October 25, 2000 when Doug got comments implementing his ideas. Throughout this period, the OHS/DKR group regularly received work product implementing Doug's goals, as shown on October 17, 2000.
..
On 001126 Eugene Kim recommended using IT with greater diligence to accomplish Doug's vision, rather than using SDS.
..
In addition, on June 23, 2000 Jack Park wanted to accomplish ontology tasks by building an "engine, so that knowledge work would be faster and easier than it is using current IT.
..
This "engine" would accomplish Eric's goal of augmenting intelligence, which he identified based on Doug's vision, reported on April 23, 2000.
..
Without being too long winded, there has been discussion about dialog maps, topic maps, outlining, IBIS and XML.
..
Paul noticed recently that progress has been delayed because license issues prevent people from submitting actual code. Doug addressed this issue, and Mei Lin proposes rolling up our sleeves and getting to work, starting with new meetings were experts can listen to Doug and formulate a solution.
..
Today, Paul raises important conceptual issues both on technology and on the business case relating to investing time.
..
I like Paul's discussion about documents.

My sense is that since documents have been around for 2,000 years, books, articles, reports, correspondence like this letter, and so on will continue to be used for the foreseeable future We therefore need to develop ways that add value to information in documents. This raises the prospect of a new way of working with literacy for reading and writing. Since Doug proposes a new way of working and thinking on the Bootstrap website, reviewed on December 22, 1999 a new way of working with documents seems like a reasonable step to take.
..
One approach using eight (8) steps for applying SDS that has evolved over the past 20 years, or so, is explained in the record on December 19, 2000, and further in in POIMS.
..
Since everyone will not agree, Paul's second point about the practical business considerations for creating a next generation technology is critical.
..
What seems most evident is that (1) the design of KM is difficult, certainly counterintuitive, and (2) people are not willing to invest time to work on ideas they do not believe are effective. The whole concept of open source, that folks do what they want, is antithetical to innovative design. By definition innovation is "new," so people are ignorant and fearful about it until they gain experience.
..
So, even if the design were given over, there is no hope it can be implemented without investment to buy people's time to work on things they believe will not work, until such time as they gain sufficient experience to learn about KM, as set out in POIMS. see for example the record on November 1, 1996 showing how experience discloses the meaning of Knowledge Management.
..
In other words there is an innovation loop that can only be transcended through experience, and it takes money to buy time for people with the right kind of skills to gain that experience.

This is evident from Eric's letter on 011003 saying people have to be paid to do KM, because it takes so much time using the tools everybody likes to use....
..
http://www.welchco.com/sd/08/00101/02/01/10/03/160603.HTM#O73F

Eric's point is evident from the failure of folks to link the record, as requested by Doug on 001025. If we are unwilling to do this simple step because it does not fit with the way we like to work, how can we hope to build tools that are different from the way we think they should work?
..
Accordingly, I largely agree with Paul's point about starting small and bootstrapping OHS development.

Hopefully, Paul, Jack, Eugene, Joe, Lee, Eric, and others will go ahead and develop their ideas and provide work product demonstrating added value for a new way of working that saves time and money. This will attract a critical mass of capabilities that accomplish Doug's vision for a DKR that uses an OHS and Hyperscope to implement the ABC improvement model, as Doug laid out on 001025, based on his writings the past half century.
..
Rod


Paul Fernhout wrote: > > Mei Lin Fung wrote: > > [Lost of good stuff snipped] > > People who have been in Doug's orbit sometimes feel they understand > > fully the problem and what needs to be done. Often that seems to involve > > putting Doug on the shelf so that he stops making these troublesome > > remarks that people can't understand. > > > > This is to do him a disservice, that's my opinion. He is not at a place > > in his life where he wants to debate his ideas and plans, they have been > > the product of 51 years of thinking. He just wants to do it and to work > > with people that want to do it. What he wants to do has been outlined > > in the OHS Launch Plan for the hyperscope, BI2120. > > > > http://www.bootstrap.org/augment/BI/2120.html > > [Trying to catch up a tiny bit...] > > Mei Lin- > > One major issue here is a fundamental contradiction between implementing > the perfect OHS on the first pass, versus bootstrapping a population of > tools capable of evolution. > > I don't think anyone here disrespects Doug's technical accomplishments > or his social ones of getting creative people together. I don't think > anyone here disrespects his vision for something good for humankind by > enabling high performance teams capable of further bootstrapping (until > transcendence?). It would be wonderful to see Doug's current vision for > an OHS implemented as it is a distillation of years of experience and > pondering, whether or not the current design is perfect. If you want to > help him implement exactly that specification, and recruit others to do > so, more power to you. > > Still, doing so would take considerable effort, and the question is who > will make that investment and for what reasons -- given an estimate of > the project's chances of success (in various ways) against how useful it > will be and what is already out there. Much of the value of this list > has been in seeing all the other things people have been doing, both for > ideas and to avoid reinventing wheels (or at least, for me, to avoid > reinventing other free wheels). > > I'm not ready to make that investment myself, in part (beyond licensing) > because I have specific design issues with aspects of OHS design, which > were raised quite a while back. (And frankly, I'm not up on all the > latest discussion, so some of these issues may have been better > addressed since then, either by Doug or various other contributors.) > > The most serious issue is in the notion of "Document" which I think > needs further contemplation. For example, where do document boundaries > end? How are documents composed of other components? How do documents > change through time along with the system itself? How are documents > merged? How are they split? Is the notion of "Document" really a > valuable idea as opposed to say nested versioned hierarchies (e.g. OTI's > Envy for Smalltalk) or networks with paragraphs at the base?) (These are > related to some issues William Kent raises in "Data & Reality"). > > The second major design issue revolves around the notion of a link. > While I think it makes sense to be able to use a system to move from a > viewed concept to related items, it isn't clear what the best way to do > that is, given the power of search engines (which can find all pages > containing a text string) and that the link an author originally creates > (say for a definition) may not reflect the current needs of the reader. > Also, related to transcending links is the issue of distributed > non-locational content. > > Design issues can be thrashed through and both of the above issues could > probably be resolved in some form in a process that involves > bootstrapping Doug's design (if license issues & permisison to use were > resolved yada yada). > > Doug seems to have a gift for defining requirements, and the documents I > look at seem more like requirements documents than architecture to me. > To elaborate on how what is spelled out are requirements, one could say > the system should be capable of helping people deal with things some > people call documents -- even if documents don't exist in the system as > such. Similarly, the system should support the author's intent in > defining useful links -- but that does not mean that is necessarily the > only sort of link or navigation the system might handle, or that > internally the system will represent links as they are conventionally > described these days in HTML syntax. > > This fundamental contradiction between implementing a perfect system in > one pass versus bootstrapping a self-reflective one (is perhaps one > reason people (including me) set off in entirely different directions > rather than implement the OHS or Hyperscope spec. I, for one, remain > respectfully always informed by Doug's vision, but perhaps not always > movign things along in a way exactly as he planned. > > Also, such systems may tend to be perhaps nearly from scratch in various > ways but using existing tools. This fundamental contradiction might > also end up being reflected in the tools used and the tradeoffs (speed > vs. storage vs. flexibility etc.) in and Bootstrappable architecture. > It's a difficult set of challenges -- and there are schools of > programming thought like "extreme programming" that argue to never put > in any flexibility in the system because there are infinite ways you can > do that so most of that effort will be wasted. I don't completely agree > with that; I think every once in a while you see an elegant way to stay > flexible. > > Frankly, it isn't clear to me from the OHS or Hyperscope specifications > I have looked at, such as linked above, how evolving the system code > itself in a bootstrapping way is easily doable (as opposed to evolving > the textual content). I'm not saying it is impossible, just that the > focus seems more on a great system to evolve populations of textual > content, as opposed to a great framework for the evolution of > populations of code. Granted, that is the need most people have for an > OHS and what atttracts most peopel to the concept. There is a lot of > content out there to deal with, not the least of which is this mailing > list. > > That self-reflective aspect of the system isn't emphasized, such as it > is with, say, Squeak Smalltalk (for all its other issues) or, say, Forth > (the premier Bootstrapping computer language in some ways). Naturally, > evolving code versus evolving content don't have to be in opposition > (since code is content). What I am talking about here is more just an > issue of focus and what aspects and levels of the system architecture > one is talking most about. > > Still, I think the fundamental contradiction would ideally be addressed > to lower the risk of any specific implementation approach. > > Just to give one tiny example in this direction (and to break my own > rule about not posting code here until licensing is resolved...) > > ==================== > > [The following lines of code disclaimed to the public domain in an > effort to be useful and to limit liability, and come with NO WARRANTY:] > > import org.python.util.*; > import org.python.core.*; > > ... > > void OnRunPython() > { > PythonInterpreter interp = new PythonInterpreter(); > String program = this.textEditor.getText(); > interp.exec(program); > } > > ==================== > > This the essence of a crystallized Java program that can bootstrap > itself using Jython (Python in Java), even to the point of launching new > windows, communicating over the internet, retrieving versions of its > source from a database, and so on. > > There are other approaches, say by bootstrapping IBM's Eclipse Java > development environment (or Sun's Netbeans, or GCC & Emacs, etc.). > > In any case, this is a code example related to resolving the > contradiction... > > -Paul Fernhout > == The Pointrel Foundation > == Helping people understand nature, technology, and society > == by developing networks of free digital libraries > == and free software and free content to put in them. > == > == http://www.pointrel.org











..
Sincerely,

THE WELCH COMPANY



Rod Welch
rowelch@attglobal.net




..
Copy to:
..

..
Post Script