[ba-ohs-talk] Trying to accomplish KM Deploy SDS
Eric, (01)
Sorry to have taken so long to follow up on your letter talking about
using SDS, if a way could be found to deploy and support this
capability, per analysis on 020530.... (02)
http://www.welchco.com/sd/08/00101/02/02/05/30/201330.HTM#Y89F (03)
This issue arises in the larger context of what the OHS/DKR effort is
trying to accomplish. A threshold task is to begin linking the
record, as related on 020530 ... (04)
http://www.welchco.com/sd/08/00101/02/02/05/30/201330.HTM#WK4H (05)
...based on Doug's letter on 001025. If we could see a few links here
and there into the record, this would indicate people are ready to get
started on the journey from IT to a culture of knowledge. (06)
Unfortunately, in your case, this threshold task is objectionable. My
sense is that the objection comes from lack of experience "playing the
music", and so can be repaired by getting behind the wheel so to
speak; but, if not, SDS is not a good direction for you. SDS is
designed to aid organization and making connections that augment
intelligence, noted in your letter on 010916. Since intelligence is
used for everything, SDS supports a wide range of tasks, as shown in
the letter on 020708.... (07)
http://www.welchco.com/04/00070/61/02/07/0801.HTM#9M7J (08)
Let me know if you want to get started. That would shorten up the 50
year thing you asked about the other day. (09)
Thanks. (010)
Rod (011)
*************** (012)
Eric Armstrong wrote:
>
> 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...)
> :_)
>
> Rod Welch wrote:
>
> > 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 (013)