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


S U M M A R Y


DIARY: August 12, 2000 04:22 PM Saturday; Rod Welch

DKR development plan proposed for SRI team, Grant Bowman.

1...Summary/Objective
2...Maintenance Difficult Using Servletts on Server Side
3...Alternate Views Challenging Design Using Servletts on Server Side
4...Knowledge Management Difficult to Design
5...DKR Proposal to Manage Archived Record NS4.0/MSIE4.0
........Zwiki Limitiations
6...Internet Acquisition New Software Engenders Rapid Acceptance
7...New Browsers Create Expectation for New Capability, Some Flaws
8...Early Adopters Tolerate Flaws
9...Import Email Archive into KM Program (OHS/DKR)
10...Stable Record Critical to Effective KM Technology
.....Knowledge Growth Requires History, Connections to Be Accessible
11...Email Archive for DKR Project


..............
Click here to comment!

CONTACTS 

SUBJECTS
OHS/DKR Development Plan for Target Audience, Grant Bowman
Audience Develop OHS to Meet Demand, Grant Bowman
Browser Requirements OHS Based on Target Audience, Grant Bowman
OHS Alternate Views, Grant Bowman, 000812
XML -> OHS Browser, Grant Bowman, 000812
Partitioning Application Plug-ins OHS, Grant Bowman, 000812
Flexible DKR Architecture between XML and Browsers, Grant Bowman, 000
WAP Voice Front End between Server Cellular Telephon Browser, Grant B
Difficult to Understand KM
DKR Difficult Design Not Enough Known about Knowledge
Alternate Views, OHS, Grant Bowman, 000812
Multiple Views Software Programming, Doug, 000601
Zwicki Not Accessible High Speed, Eric Armstrong
ZWiki-style Collaborative Document System, 000427
KM Methods Difficult to Implement, Eric Armstrong

3117 -    ..
3118 - Summary/Objective
3119 -
311901 - Follow up ref SDS 29 0000, ref SDS 19 0000.
311902 -
311903 - Received ref DRT 1 0001 from Grant Bowman dated 000812 early in the
311904 - morning, responding to a letter submitted to the DKR team by Eric
311905 - Armstrong.
311906 -
311907 - Strategy to develop initial code for version 1a based on defining
311908 - needs and desires of a target audience. ref DRT 1 E06H
311909 -
311910 -    [On 000920 letter to DKR team on defining customer. ref SDS 34 2V5F
311911 -
311912 -    [On 001004 letter to DKR team on defining customer. ref SDS 36 0A3H
311913 -
311914 - Architecture for flexibility between XML and browsers proposed.
311915 - ref DRT 1 G16O
311916 -
311917 -
311918 -  ..
311919 - Maintenance Difficult Using Servletts on Server Side
311920 - Alternate Views Challenging Design Using Servletts on Server Side
311921 -
311922 - Partitioning OHS application, described by Eric as servletts that
311923 - present problems to maintain, ref DRT 1 HS9F, using "plug-ins" to
311924 - allow different interfaces or alternate views. ref DRT 1 N87J
311925 -
311926 -      On 000601 multiple views set as DKR project priority. ref SDS 20
311927 -      7238
311928 -
311929 -      On 000608 DKR team identified possible multiple views for
311930 -      software programming. ref SDS 22 RP4K
311931 -
311932 -      On 000614 design ideas developed for multiple views. ref SDS 23
311933 -      7046
311934 - ..
311935 - Need to solidify how to get XML -> OHS compatible
311936 - browsers/software. ref DRT 1 E98H
311937 -
311938 - A sample of partitioning applications, is below; each item represents
311939 - a seperate physical box or computer.  We can confuse things later by
311940 - lumping functions onto fewer machines.  Using some kind of RMI or
311941 - CORBA between the database server, object server and Java servlets
311942 - should give scalability with a good object broker system. ref DRT 1
311943 - YG8M
311944 -
311945 -      Database or XML data
311946 -         |
311947 -         V
311948 -      Database Server, SQL
311949 -      servicing routines, DOM access(?), etc.
311950 -         |
311951 -         V
311952 -      "Object Server"
311953 -      Business Logic - if certain view selected, cut
311954 -      the XML up this way...
311955 -         |
311956 -         V
311957 -      Java Servlets that speak with the object server
311958 -      HTML code generated to send to the browsers
311959 -      Maybe there are XSL here
311960 -      Apache HTTPD
311961 -         |
311962 -         V
311963 -      Browser running HTML & Javascript
311964 -      GUI functioning performed.
311965 -      Maybe XML Direclty with XSL.
311966 - ..
311967 - This design can have one set of servers up to the object server
311968 - and have different architectures going forward.  It sounds like the
311969 - latest and modern browsers can skip the step between object server and
311970 - browser and link them directly. ref DRT 1 II6F
311971 -
311972 - A WAP Voice front end may be possible between the object server and a
311973 - cellular telephone browser or cellular telephone voice response.
311974 - ref DRT 1 HJ6M
311975 -
311976 -
311977 -  ..
311978 - Knowledge Management Difficult to Design
311979 - DKR Proposal to Manage Archived Record NS4.0/MSIE4.0
311980 -
311981 - Eric Armstrong in a letter on 000811, ref DRT 1 0002, included as an
311982 - attachment to Grant's letter received above, ref SDS 0 0001, relates
311983 - challenges of designing knowlege management capability,
311984 -
311985 -       [On 000824 Eric submits another letter on architecture and
311986 -       objects to OHS design like Rod Welch system. ref SDS 31 0001
311987 -
311988 -       [On 001012 Grant Bowman comments on Eric's concerns. ref SDS 37
311989 -       RI9J
311990 -
311991 - Eric reports the DKR team has plans for archived [record to] be
311992 - browsed with NS4.0/MSIE4.0, and raises following concerns...
311993 -        ..
311994 -     •  They offer a lower level of functionality than that
311995 -        offered by 6.0/XML-based versions.
311996 -
311997 -     •  They are not customizable or programmable.
311998 -        ..
311999 -        We want the system to evolve -- we want people developing
312000 -        more and better clients, all of which use the underlying system
312001 -        as a base, so it becomes a standard for information
312002 -        interchange.
312003 -        ..
312004 -     •  We say, on the one hand, that we want to deliver raw XML
312005 -        to the clients, so they can do the processing locally. On the
312006 -        other hand, we plan to implement the view-manipulation logic on
312007 -        the server side. But I don't see how we can do both, unless we
312008 -        have two virtually-identical systems. That's a maintenance
312009 -        headache.
312010 -
312011 -
312012 -
3121 -

SUBJECTS
Zwicki Not Accessible High Speed, Eric Armstrong
ZWiki-style Collaborative Document System, 000427
Starter Technologies Using Develops Experience to Create KM
Zwiki Slow Progress Toward OHS/DKR Objectives
Wiki Difficult to Use
Wiki Difficult to Implement

4109 -
410901 -  ..
410902 -
410903 -        Zwiki Limitiations
410904 -
410905 -     •  Peformance will, in a word, suck.
410906 -
410907 -        Zwicki proved that to me. I can't get to it from inside Sun's
410908 -        firewall. So I got to it from my 38.8 modem at home. *That*
410909 -        performance was terrible. If we implement OHS this way, it will
410910 -        be regarded as a somewhat interesting toy -- not as a usable
410911 -        application.
410912 -
410913 -          [On 000830 Zwiki proposed for marketing plan. ref SDS 33 FQ5L
410914 -
410915 -          [On 010218 Brint using Wiki for DKR. ref SDS 41 FC6L
410916 -
410917 -
410918 -
410919 -
410920 -
410921 -
4110 -

SUBJECTS
Early Adopters Tolerant Product Flaws, Armstrong, 000812
Browsers, New Create Market Early Adopters new tools, Armstrong, 0008
Market Conditions SDS
Market Conditions DKR
Disruptive Technology
Internet Enhances Ability Grow New Market Software because Ease of Ac

4709 -
470901 -  ..
470902 - Internet Acquisition New Software Engenders Rapid Acceptance
470903 - New Browsers Create Expectation for New Capability, Some Flaws
470904 -
470905 - If we were talking about a software package that cost several hundred
470906 - dollars, that had to be acquired on a CD, then yes, we could expect
470907 - that users would be slow to upgrade. But we live in Internet time,
470908 - nowadays. If these browsers are what they are cracked up to be, they
470909 - will effectively replace their predecessors in 12-18 months -- time
470910 - during which we will be doing most of our development anyway.
470911 - ref DRT 1 E55L
470912 -
470913 -     This seems to align with SDS business plan strategy developed on
470914 -     000802.
470915 -
470916 -
470917 -  ..
470918 - Early Adopters Tolerate Flaws
470919 -
470920 - In the early stages of this system, we really want the "early
470921 - adopters" -- people who like trying new technologies, who are
470922 - relatively tolerant of flaws. We really do NOT want people with high
470923 - expectations for flawless execution and rapid performance at the
470924 - outset. People who are using the new browsers fit that bill perfectly.
470925 - Our user base can grow right along with acceptance of those browsers,
470926 - our application will help push that acceptance curve. ref DRT 1 M56I
470927 -
470928 -
470929 -
470930 -
4710 -

SUBJECTS
Email Compatibility Prior Email with New System, Nicholas Carrol, 000
Email Core Capability DKR, Collaboration, Eric, 000505
Stable Record Import Legacy Compabitility History, 000227
History Case Studies, Root Causes
History Prior Work Useful Sometimes
History Experience Diary Intelligence
Stable Technology, Avoids Constant Change
Addressability Anchors Archived Record, Engelbart, 000601
Computer Aided Thinking Improves KM Handling Daily Working Informatio
Maintains Access Over Time Legacy Tools Essential Stable Access
Command and Control of the Record Maintains Access Over Time
History Chronology, Causation, Experience, Intelligence
Import/Export Legacy Document Support

6516 -
651601 -  ..
651602 - Import Email Archive into KM Program (OHS/DKR)
651603 - Stable Record Critical to Effective KM Technology
651604 -
651605 - Received ref DRT 2 0001 from Henry van Eykan responding to a letter
651606 - from Nicholas Carroll asking how to...
651607 -
651608 -     How do I bring all my old email into the OHS-EC (email client)?
651609 -     I'm pretty reluctant to leave it all behind. ref DRT 2 0002
651610 -
651611 -     How do I get my email *out* of the EC. After all, free email
651612 -     clients at Yahoo and Iname really suck, and maybe this is more of
651613 -     the same. What if I don't like your product, huh? You're not going
651614 -     to trick me with proprietary formats again, Bill Gates!
651615 -     ref DRT 2 P44L
651616 -
651617 -  ..
651618 - This is a primary objective Doug Engelbart has set for incorporating
651619 - the record of his prior work into a new OHS/DKR system.  On 000601 he
651620 - calls for adding addressability to the email archive. ref SDS 20 2760
651621 -
651622 -     [On 000824 Eric Armstrong reports Doug proposes a system like SDS
651623 -     of putting the record on the Internet with anchors added for
651624 -     addressability. ref SDS 31 PU5N
651625 -
651626 -     [On 000825 Eric argues import of other people's information adds
651627 -     minimal value to new tools; seems though to recognize importing
651628 -     the record is critical. ref SDS 32 0001
651629 -
651630 -     [On 001025 OHS launch plan calls for communities to develop
651631 -     translators to support Hyperscope. ref SDS 38 QI6K
651632 -
651633 -     [On 001121 Mindset supports import/export. ref SDS 39 BO6N
651634 -
651635 -     [On 001130 Jack Park proposes import/edit facilities for upper
651636 -     level of 3-layer KM architecture of OHS. ref SDS 40 KN9F
651637 -
651638 -  ..
651639 - Henry explains the problem is much bigger than email, stating...
651640 -
651641 -     It may well be true that many, if not most, of an ordinary user's
651642 -     files are of minor importance to him, but chances are that among
651643 -     those personal files there builds up a substantial stock of files
651644 -     that are intended to serve him a lifetime. ref DRT 2 WF5N
651645 -
651646 -         [On 000920 cited Henry's point today in relation to his call
651647 -         for education on KM. ref SDS 34 2V5F
651648 -
651649 -         [On 000921 Eric Armstrong cites the importance of longevity as
651650 -         a criteria people assess in deciding to invest time to learn a
651651 -         methodology. ref SDS 35 AF3L
651652 -
651653 -         [On 001025 OHS launch plan calls for communities to develop
651654 -         translators to support Hyperscope. ref SDS 38 QI6K
651655 -
651656 -         [On 001121 Mindset supports import/export. ref SDS 39 BO6N
651657 -
651658 -      ..
651659 -     Knowledge Growth Requires History, Connections to Be Accessible
651660 -
651661 -     People increasingly rely on their electronic memory and electronic
651662 -     thinking, which is critical as a provider, a professional, and a
651663 -     citizen.  Those files must therefore remain unscathed throughout a
651664 -     lifetime no matter what twists and turns the art of computing is
651665 -     bound to take. ref DRT 2 BH6K
651666 -
651667 -        This objective is summarized by Command and Control of the
651668 -        Record called out in POIMS, ref OF 1 1113, to maintain history
651669 -        that aids human thinking through writing. ref OF 1 3742  The
651670 -        value of this objective is seen from progress of civilization
651671 -        since the time of Thucydides in 400 BC, credited with starting
651672 -        the writing history, reported on 991108. ref SDS 2 3339
651673 -        ..
651674 -        On 000106 Communication Metrics supports computer aided
651675 -        thinking, ref SDS 3 1316, based on firepower of SDS cited on
651676 -        950204 that makes it fast and easy to capture the record and
651677 -        use the record of the past to plan the future, ref SDS 1 4995,
651678 -        as explained at Intel on 000517. ref SDS 15 5073
651679 -
651680 -        On 000327 this ideas was proposed in telecon with Doug
651681 -        Engelbart. ref SDS 5 8484
651682 -
651683 -        On 000723 Henry's call for stable knowledge storage and
651684 -        retrieval reflects history that led to SDS. ref SDS 26 2583
651685 -
651686 -        On 000725 explained need for stability in meeting with Pat
651687 -        Lincoln. ref SDS 27 0WD3
651688 -
651689 -        On 000731 propose consortium for KM that would maintain stable
651690 -        knowledge environment. ref SDS 28 0900
651691 -        ..
651692 -        On 000802 business plan addresses this issue. ref SDS 30
651693 -        3657
651694 -
651695 -        Morris mentioned recently that Microsoft and other vendors
651696 -        strongly support import capability, but not export, because
651697 -        they don't users to export the record created with their tools
651698 -        to another program.
651699 -
651700 -      ..
651701 -     Reliable software compatibility, emulators, etc.are of the
651702 -     essence. Global standards seem much in order. Also there must be
651703 -     public access to stores of older tools staffed by competent users
651704 -     of those tools so that one may access and use old files, perhaps
651705 -     personally evaluate those tools as well (case in point: Augment).
651706 -     ref DRT 2 SH7L
651707 -
651708 -      ..
651709 -     Learning curves need be shortened. I believe that public education
651710 -     ought include the inculcation of some fundamental skills
651711 -     (equivalent to, say, algebra) such as algorithmics either without
651712 -     emphasis on a particular language or along with a basic computer
651713 -     script that is universally used (interpreted BASIC?) such that no
651714 -     other language is considered complete without means of converting
651715 -     the script into an executable in that language. ref DRT 2 LA8J
651716 -
651717 -      ..
651718 -     And on the subject of languages, computers store memory _and_
651719 -     thought processes. Hence, computer literacy better include
651720 -     programming skill, but without every person having to be concerned
651721 -     about the latest fashion or specific uses of programming languages
651722 -     in general. I mean programming skill in the sense of writing skill
651723 -     - for everyday personal use throughout a lifetime. ref DRT 2 XA9I
651724 -
651725 -      ..
651726 -     In short, personal computing is by definition computing for
651727 -     Everyman and should be not so complex as to prevent every person
651728 -     to attend to other, individual concerns. As long as our
651729 -     bookstores' shelves are laden with two-inch-thick introductory
651730 -     texts to operating systems and executables there is something
651731 -     wrong with what we are doing. ref DRT 2 JB4H
651732 -
651733 -
651734 -
651735 -
6518 -

SUBJECTS
Email Archive for DKR Project

6604 -
660401 -  ..
660402 - Email Archive for DKR Project
660403 -
660404 - Received recently a link to a composite list of email submitted by
660405 - contributors on DKR project.
660406 -
660407 - It can be sorted chronologicaly, by author and by the subject
660408 - description, which is called a thread.
660409 -
660410 - Here is the chronological list....
660411 -
660412 -
660413 -       http://www.bootstrap.org/dkr/discussion/date.html
660414 -
660415 -
660416 -
660417 -
660418 -
660419 -
660420 -
660421 -
660422 -
660423 -
660424 -
660425 -
6605 -