Re: [ba-ohs-talk] What are we trying to accomplish?
Incredible, Rod. You continually amaze with your ability
to access the record. If we had tools of the kind you have
developed, I believe we *would* use them. (I've only
quarreled with having to link to everything, instead of
incorporating it, but hey...)
:_) (01)
Rod Welch wrote: (02)
> Paul,
>
> Specifically on 001025 Doug called for developing technology that
> implements the OHS Launch plan....
>
> http://www.welchco.com/sd/08/00101/02/00/10/25/095632.HTM#G3W8
>
> ...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 that
> "bootstraps" its expertise by using existing technology, primarily
> through email to create 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....
>
> http://www.welchco.com/sd/08/00101/02/00/10/25/095632.HTM#00VU
>
> So far these objectives have not been accomplished, except with SDS.
> On 001126 Eugene Kim recommended using IT with greater diligence to
> accomplish Doug's vision, rather than using SDS....
>
> http://www.welchco.com/sd/08/00101/02/00/11/26/214933.HTM#BY4K
>
> In addition, on 000623 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....
>
> http://www.welchco.com/sd/08/00101/02/00/06/23/114155.HTM#2915
>
> This "engine" would accomplish Eric's goal of augmenting intelligence,
> which he identified based on Doug's vision, reported on 000423....
>
> http://www.welchco.com/sd/08/00101/02/00/04/23/114819.HTM#5933
>
> 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 991222....
>
> http://www.welchco.com/sd/08/00101/02/99/12/22/104523.HTM#3696
>
> ...a new way of working with documents seems like a reasonable step to
> take.
>
> One approach that has evolved over the past 20 years or so is
> explained on 001219....
>
> http://www.welchco.com/sd/08/00101/02/00/12/19/071408.HTM#4W4L
>
> ...also, explained in POIMS...
>
> http://www.welchco.com/03/00050/01/09/01/02/00030.HTM#3742
>
> 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 961101...
>
> http://www.welchco.com/sd/08/00101/02/96/11/01/132459.HTM#L191740
>
> 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 second point.
>
> 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 (03)