[ba-ohs-talk] What are we trying to accomplish?
Paul, (01)
Specifically on 001025 Doug called for developing technology that
implements the OHS Launch plan.... (02)
http://www.welchco.com/sd/08/00101/02/00/10/25/095632.HTM#G3W8 (03)
...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. (04)
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.... (05)
http://www.welchco.com/sd/08/00101/02/00/10/25/095632.HTM#00VU (06)
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.... (07)
http://www.welchco.com/sd/08/00101/02/00/11/26/214933.HTM#BY4K (08)
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.... (09)
http://www.welchco.com/sd/08/00101/02/00/06/23/114155.HTM#2915 (010)
This "engine" would accomplish Eric's goal of augmenting intelligence,
which he identified based on Doug's vision, reported on 000423.... (011)
http://www.welchco.com/sd/08/00101/02/00/04/23/114819.HTM#5933 (012)
Without being too long winded, there has been discussion about dialog
maps, topic maps, outlining, IBIS and XML. (013)
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. (014)
Today, Paul raises important conceptual issues both on technology and
on the business case relating to investing time. (015)
I like Paul's discussion about "documents." (016)
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.... (017)
http://www.welchco.com/sd/08/00101/02/99/12/22/104523.HTM#3696 (018)
...a new way of working with documents seems like a reasonable step to
take. (019)
One approach that has evolved over the past 20 years or so is
explained on 001219.... (020)
http://www.welchco.com/sd/08/00101/02/00/12/19/071408.HTM#4W4L (021)
...also, explained in POIMS... (022)
http://www.welchco.com/03/00050/01/09/01/02/00030.HTM#3742 (023)
Since everyone will not agree, Paul's second point about the practical
business considerations for creating a next generation technology is
critical. (024)
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. (025)
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... (026)
http://www.welchco.com/sd/08/00101/02/96/11/01/132459.HTM#L191740 (027)
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. (028)
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.... (029)
http://www.welchco.com/sd/08/00101/02/01/10/03/160603.HTM#O73F (030)
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? (031)
Accordingly, I largely agree with Paul's second point. (032)
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. (033)
Rod (034)
*************** (035)
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 (036)