THE WELCH COMPANY
440 Davis Court #1602
San Francisco, CA 94111-2496
415 781 5700
rodwelch@pacbell.net


S U M M A R Y


DIARY: May 5, 2000 02:43 PM Friday; Rod Welch

Eric submits specs for editor, collaborative doc requirements, v0.5.

1...Summary/Objective
2...Editor Specification Needs Alignment with Architecture
3...Collaborative Document System Requirements v0.5 - Boggles the Mind
4...Issues Needing Consideration for Inclusion in Specs
5...Listening Critical Communication Metric, Support Needed for DKR
6...Power of Microcosm Knowledge Management Dilemma Resolved by Experience
7...Knowledge Space Boggles the Mind - Experience Unboggles
8...Boggles the Mind Complexity Knowledge Space - Experience Unboggles
9...Diagnostics
10...Section Summary Analysis
....Long-Range Goals - Email is Short Range, KM is the Longer View
......Motivation - World Problems, Improve the Work, Save Time, Money
......Starting Points
......General Characteristics,
......General Functional Requirements,
......General Systemic Requirements,
......Extensible
......Secure,
.........Email Core Capability of DKR KM Collaboration
.........Garden of Eden Let's Managers Graze on Information Overload
.........Foraging on Information Overload Action Items Appear Naturally
......DKR Requirements,
.........Didactic - Learning is Hard Work
......Operational Requirements,
......Data Structure Requirements,
......Use Case Analysis Expanded in DKR Editor Spec
........•..IBIS-style discussions,
......Future: Using an Abstract Knowledge Representation,

ACTION ITEMS.................. Click here to comment!

1...Question - isn't improving email the "short" range goal, because
2...Why don't we start with Eric's goal to augment human intelligence

CONTACTS 

SUBJECTS
Open Source Development Freeware
Hypertext (Linking) Improves Productivity, Too Slow
Open Source Hyper-text Editors
OHS Open Hyperdocument System
Dynamic Knowledge Repository (DKR)
Binary Forces Permeate Human Endeavors, Cause Stress, Conflict
DKR Single Source Central Control Invades Privacy
Editing Core Capability
Version Control
DKR Specification
Editor Development, 000505
Specifications, DKR, OHS

2714 -
2714 -    ..
2715 - Summary/Objective
2716 -
271601 - Follow up ref SDS 49 0000, ref SDS 48 0000.
271602 -
271603 - Updated specs for the editor, a Collaborative Document System (CDS),
271604 - shows strong rationale for email as the core capability of the DKR,
271605 - ref SDS 0 4392, and includes Use Case work developed since the prior
271606 - version. ref SDS 0 2623  "Reuse" is a new section added to v0.6 [on
271607 - 000508] to reuse information when needed rather than recreate it,
271608 - which saves time and avoids mistakes. ref SDS 0 1804  Due to limited
271609 - time, there is no attribution to contributors, ref SDS 0 0375, and no
271610 - express alignment between engineering specs and architecture issues,
271611 - ref SDS 0 4234, i.e., design has led architecture from the beginning.
271612 - "Long range goals" should plan for a "whole new way of thinking to
271613 - augment human intelligence," rather than recount near term objectives
271614 - to work around the lack of definition on concepts that inhibit
271615 - progress on a DKR. ref SDS 0 5124
271616 -
271617 -     [On 000508 Joe Williams notes need for ontology. ref SDS 71 5972
271619 -      ..
271620 -     [On 000508 Eric submits v0.6 that adds "reusable" requirement.
271621 -     ref SDS 71 0782
271623 -      ..
271624 -     [On 000511 not discussed at project meeting. ref SDS 74 5880
271626 -      ..
271627 -     [On 000515 submitted comments to project team. ref SDS 75 0001
271629 -      ..
271630 -     [On 000516 received comments from Paul Fernhout. ref SDS 76 0001
271632 -      ..
271633 -     [On 000601 Eric submits v0.7 without comments on action items in
271634 -     this record, ref SDS 81 0782, submitted to team on 000515, per
271635 -     above.
271637 -      ..
271638 -     [On 000605 Eric submits v0.8 adding categories. ref SDS 85 0001
271640 -      ..
271641 -     [On 000614 Eric submits v0.9. ref SDS 87 0782
271643 -      ..
271644 -     [On 000615 Eugene Kim proposes calling CDS the OHS. ref SDS 88
271645 -     2808
271647 -      ..
271648 -     [On 000711 SRI submits pre-proposal to NASA for 3 year project to
271649 -     develop OHS. ref SDS 91 0001
271651 -  ..
271652 - We need to get Eric, Jack, Lee, Joe and Eugene into a room for spec
271653 - review, with guidance from Doug.  We need people like Paul, Jon
271654 - Winters and others promoting open source to comment on specs, so the
271655 - entire burden is not on Eric.
271656 -
271657 -     [On 001015 Eugene reports spec review has been performed and
271658 -     comments to be issued by 001030. ref SDS 99 RI9J
271660 -  ..
271661 - We need a team to hammer out an architecture to guide engineering, per
271662 - Jack, which will define "knowledge" to support a whole new way of
271663 - thinking, per Doug, and KM per Eric and Eugene. ref SDS 0 2356
271664 -
271665 -     [On 000515 Mary Keeler's paper on Charles Peirce's philosophy
271666 -     correlates "knowledge" with experience. ref SDS 75 0042
271668 -      ..
271669 -     [On 000516 Jack Park submits definition of "knowledge",
271670 -     ref SDS 76 4723
271672 -      ..
271673 -     [On 000517 "knowledge" was defined during a meeting at Intel with
271674 -     Eric Armstrong and Morris Jones. ref SDS 77 0785
271676 -      ..
271677 -     [On 000524 Paul Fernhout submits Pointrel Data Repository System
271678 -     which is an information representation architecture. ref SDS 79
271679 -     0001
271681 -      ..
271682 -     [On 001017 Eric reports production code work is underway.
271683 -     ref SDS A0 0001
271685 -  ..
271686 - The team needs to proceed with Zope, SlashDot, Traction or other tools
271687 - to connect daily work with the larger course Doug has charted, in
271688 - order to gain experience with a connected environment that will
271689 - disclose the secret of converting information into knowledge.
271690 -
271691 -     [On 000518 Lee Iversion reports progress setting up Zope so the
271692 -     team can begin converting from conventional email. ref SDS 78 3944
271694 -      ..
271695 -     [On 000615 team discusses giving up on KM. ref SDS 88 2808
271696 -
271697 -
271699 -  ..
2717 -
2718 -
2719 - Progress
2720 -
272001 - Editor Specification Needs Alignment with Architecture
272002 - Collaborative Document System Requirements v0.5 - Boggles the Mind
272003 -
272004 - Follow up ref SDS 49 0782, ref SDS 48 0782.
272005 -
272006 - Received ref DRT 1 0001 from Eric Armstrong submitting Requirements
272007 - for a Collaborative Documents System (CDS) v0.5, explained in detail
272008 - below. ref SDS 0 4392
272010 -  ..
272011 - This updates prior versions, more fully listed in the record on
272012 - 000423. ref SDS 62 6306
272013 - ..
272014 - There is no evident record of anyone helping Eric with this
272015 - task; many talented people have noted slow progress, and suggest
272016 - different paths, but only Eric has produced an implementation spec.
272017 -
272018 -        [On 000509 Paul Fernhout commented on project crisis.
272019 -        ref SDS 72 4980
272020 -
272021 -        [On 000524 Paul Fernhout submits Pointrel Data Repository
272022 -        System which is an information representation architecture.
272023 -        ref SDS 79 0001
272025 -         ..
272026 -        [On 000718 pre-proposal to NASA expects to develop OHS that
272027 -        solves problem of complexity. ref SDS 93 6600
272029 -      ..
272030 -     There are two sections for history, one called version history and
272031 -     the other simply history.  Both seem to show the same thing.  So I
272032 -     combined them under the single heading of History.
272034 -      ..
272035 -     Eric might consider preparing a paragraph to highlight major
272036 -     changes and additions, particularly with respect to concept and
272037 -     functionality.  Since time is limited, it does not have to be
272038 -     comprehensive, but merely indicate the evolution of scope and a
272039 -     few major changes in direction to orient contributors in making
272040 -     review.
272042 -      ..
272043 -     The evolution of thinking is important to design, ref DRP 7 4698,
272044 -     as reported by Eric on 000424. ref SDS 63 0786 and ref SDS 63 4819
272045 -
272046 -               [On 000508 this was done for the "Reuse" section that
272047 -               was added to v0.6. ref SDS 71 0782
272048 -
272049 -               [On 000601 received changes for v0.7. ref SDS 81 0782
272051 -             ..
272052 -            v0.1 ref DRP 1 0001 dated 000125 ref SDS 19 3867
272054 -             ..
272055 -            v0.2 ref DRP 5 0001 dated 000306 ref SDS 49 0782 ,
272057 -  ..
272058 - Eric shows following additional prior versions...
272059 -
272060 -    These entries have no dates and no links to obtain materials for
272061 -    comparing with current submission.
272062 -
272063 -            0.3 Formatting, two additions
272065 -               ..
272066 -              Is v0.3 the presentation Eric made at the meeting on
272067 -              000406 which was not distributed to the team through the
272068 -              email system? ref SDS 57 0375
272070 -             ..
272071 -            0.4 Use Case Scenarios, see below. ref SDS 0 2623
272072 -
272073 -              On 000423 received Use Case Scenarios from Eric.
272074 -              ref SDS 62 4933
272075 -
272076 -
272078 -  ..
272079 - Issues Needing Consideration for Inclusion in Specs
272080 -
272081 - There is no express attribution in the specification presented today,
272082 - because of limited time (and contrary to section below calling out
272083 - need for attribution, ref SDS 0 2079), nor alignment with...
272084 -
272085 -       [On 000601 v0.7 includes attribution. ref SDS 81 1462
272087 -        ..
272088 -       [On 010217 attribution omitted on POIMS due to limited time and
272089 -       slow tools. ref SDS A1 FC6L
272091 -          ..
272092 -     1.  Open Source production plan impacts on design.
272093 -
272094 -         Some discussion of "open source" is presented under General
272095 -         Systemic Characteristics. ref DRT 1 5003
272097 -          ..
272098 -         Explain "Starter Technologies" will be used to gain experience
272099 -         with a connected environment that will inform project design.
272100 -         ref SDS 0 4524
272102 -          ..
272103 -         Explain core capability will be created and expanded, per
272104 -         issues in the record of project launch meeting on 000324.
272105 -         ref SDS 53 3055 and ref SDS 53 7371
272107 -          ..
272108 -     2.  Eric's innovation for core KM method reviewed on 000212,
272109 -         ref SDS 26 9790, per question on 000208, ref SDS 24 8960, and
272110 -         essential derivitive to preserve rationale, i.e., reasoning,
272111 -         which yields "lessons learned," through case studies, per
272112 -         Eric's letter on 000424 citing need for history of Augment.
272113 -         ref SDS 63 0786  On 000227 reviewed role and managment of case
272114 -         studies. ref SDS 42 0001  The section of Didactic objectives
272115 -         addresses result but not method, per below. ref SDS 0 0930
272117 -          ..
272118 -     3.  Requirements Doug Engelbart submitted on 000326, ref SDS 54
272119 -         5972 ...again on 000327. ref SDS 55 3971
272121 -          ..
272122 -     4.  Knowledge to augment human "intelligence," roughly described
272123 -         in Doug's 1972 paper reviewed on 000327. ref SDS 55 3971 (see
272124 -         "architecture. ref SDS 0 4234) requires specifications that
272125 -         explain correlation to the purpose of the project, otherwise
272126 -         there is no benefit of setting out a purpose, which was
272127 -         discussed at great length on 000426. ref SDS 64 2340  On
272128 -         000423 Eric described the goal to augment intelligence.
272129 -         ref SDS 62 5096
272131 -          ..
272132 -         On 000221 Jack Park reported need for an "ontology," related
272133 -         to expistomology, i.e, the study of knowledge, ref SDS 32
272134 -         8044, and supporting earlier suggestions by others.
272135 -         Categorizable, ref SDS 0 5003, and Queryable, ref SDS 0 2709,
272136 -         added in this version may intend to address ontology, but does
272137 -         not do so expressly.
272138 -
272139 -            [On 000508 Joe Williams notes need for ontology.
272140 -            ref SDS 71 5972
272142 -             ..
272143 -            [On 000601 Eric attributes Jack with ideas on mathematical
272144 -            relational processing. ref SDS 81 4967
272146 -             ..
272147 -            [...Eric does not cite Jack on ontology issue. ref SDS 81
272148 -            593M
272150 -          ..
272151 -         On 000504 Doug reported NSF denied support some years ago
272152 -         because the proposal did not define knowledge. ref SDS 70 5555
272153 -         Earlier, Doug requested work up similar to Bellinger, on
272154 -         000307, ref SDS 50 4820, and again on 000419. ref SDS 59 4964
272155 -         On 000423 Eric explained purpose of the project to augment
272156 -         human intelligence, ref SDS 62 5096; on 000424 Adam proposed
272157 -         including Doug's name in the explanation of the purpose;,
272158 -         ref SDS 63 0002; and on 000504 Eugene explained a working
272159 -         definition of "knowledge." ref SDS 69 5003  Let's use the
272160 -         intellectual capital being generated by the team, to build the
272161 -         project.
272162 -
272163 -            [On 000510 Joe Williams submits definition of knowledge.
272164 -            ref SDS 73 0004
272166 -             ..
272167 -            [On 000515 Mary Keeler's paper on Charles Peirce's
272168 -            philosophy correlates "knowledge" with experience.
272169 -            ref SDS 75 0042
272171 -             ..
272172 -            [On 000516 Jack Park submits definition of "knowledge",
272173 -            ref SDS 76 4723
272175 -             ..
272176 -            [On 000517 "knowledge" was defined during a meeting at
272177 -            Intel with Eric Armstrong and Morris Jones. ref SDS 77 0785
272179 -             ..
272180 -            [On 000518 Doug Engelbart requested a glossary to define
272181 -            project terms. ref SDS 78 3286
272183 -             ..
272184 -            [On 000518 Mary Keeler explained Charles Peirce's
272185 -            philosophy on "knowledge" to project tream. ref SDS 78 8439
272187 -             ..
272188 -            [On 000601 Bill Bearden submitted initial glossary to
272189 -            define project terms. ref SDS 82 0001
272191 -          ..
272192 -     5.  Use Case Joe Williams submitted on 000422. ref SDS 61 4933
272193 -
272194 -         Joe presents a framework for integrating DKR and OHS.  This
272195 -         needs attention.
272197 -          ..
272198 -     6.  Architecture Jack Park submitted on 000426. ref SDS 64 0304
272199 -
272200 -         Per Jack, specs need narrative and links to align vision,
272201 -         marketing and engineering.
272202 -
272203 -            [...see Long Range Goals below. ref SDS 0 2790
272205 -          ..
272206 -         The specs Eric submits today seem like the Engineering part of
272207 -         the architecture.  Engineering specs need a section to explain
272208 -         correlation between what is being specified, and what is
272209 -         called out in marketing and vision, so the work is guided by
272210 -         architecture, and issues to be resolved are clear, beginning
272211 -         with any gaps between what is being produced and the purpose
272212 -         of the project to augment human intelligence, point 4.
272213 -         ref SDS 0 2356
272215 -          ..
272216 -     7.  Requirements and Use Case scenarios Eugene Kim submitted on
272217 -         000504, ref SDS 69 6033, supported by Jack Park. ref DRP 9
272218 -         2115
272219 -
272220 -            Actually, Eugene's ideas on "comments" are incorporated
272221 -            into spec v0.5 under "Specific Use Cases," ref DRT 1 1925,
272222 -            see also below. ref SDS 0 5822
272224 -             ..
272225 -            Eugene's broader ideas about integrating time and contacts
272226 -            may warrant consideration, ref DRP 8 6660, relative to
272227 -            Eric's innovation in point 2, ref SDS 0 8256, along with
272228 -            observation that the alphabet is a tool system. ref DRP 4
272229 -            0001, reviewed on 000302, ref SDS 45 8975, which suggests
272230 -            it can be improved as the core technology for augmenting
272231 -            human intelligence, discussed on 000120.
272232 -
272233 -
272234 -
272235 -
2723 -

SUBJECTS
Listening Communication Metric of Understanding Alignment
Listening to Doug Alignment Doug's Writings Work of Colloquium
Listen Talk Fast and Easy
Align Metric Listening Avoids Meaning Drift
Align Communications Metrics Avoid Mis-Understanding
Listening & Dialog Inadequate, Need Preparation, Analysis with SDS

3608 -
360901 -  ..
360902 - Listening Critical Communication Metric, Support Needed for DKR
360903 -
360904 - Follow up ref SDS 63 5033.
360905 -
360906 - Over the past months calls for better listening have given visibility
360907 - to the advantage of stronger communications.  Consideration might be
360908 - given to building into the spec a requirement for "listening" support,
360909 - suggested by Adam and Jack on 000424, ref SDS 63 1590 and further
360910 - reviewed at ref SDS 63 5033  A communication "metric" of some kind,
360911 - cited by the US Army Corps of Engineers on 971205, ref SDS 5 3928,
360912 - helps people follow their best instincts in supporting the project
360913 - Doug has initiated.  SRI's elevated support, reported on 000419,
360914 - ref SDS 59 1540, and at the meeting on 000504, ref SDS 70 7743, may
360915 - help accomplish this.
360916 -
360917 -
360918 -
360919 -
3610 -

SUBJECTS
Starter Technologies, Start with What is Available, 000302
Software Programming Program Initial Product, 000406
Pilot Test New Capabilities, 000227
Pilot Test Email for Organizing and Thought Tracking, 000428
Knowledge Management Hard Work Needs People Tools Process
Boggles Mind Shocking Complexity SDS Web of Links
Pandora's Box Transition Exposure to Expanded Knolwedge
Microcosm Power to Organize, Link Complex Details
Knowledge Dilemma, Problem???
Serial Processing in Conscous Mind Conflicts with Parallel Processing
Experience Blinds People to Power of Microcosm, i.e., Knowledge
KM Difficult to Understand
Links Boggle Mind in Knowledge Space, Eric Armstrong

5315 -
531601 -  ..
531602 - Power of Microcosm Knowledge Management Dilemma Resolved by Experience
531603 - Knowledge Space Boggles the Mind - Experience Unboggles
531604 - Boggles the Mind Complexity Knowledge Space - Experience Unboggles
531605 -
531606 - This version continues to "wonder" what such a system will look like
531607 - when extended with thousands of relationships, i.e, the complexity of
531608 - a connected environment will "boggle the mind," ref DRT 1 2337, as
531609 - reported on 000125. ref SDS 19 3975
531611 -  ..
531612 - On 000120 the need to transition into a "knowledge" environment was
531613 - reviewed, ref SDS 17 2345 citing Prometheus and Pandora reviewed on
531614 - 991108. ref SDS 14 5810  This was presented again on 000317.
531615 - ref SDS 52 0005
531617 -  ..
531618 - On 000503 Eric reported he is printing SDS records, and finds that a
531619 - lot of links are confusing. ref SDS 68 5092 and ref SDS 68 1739  This
531620 - presents a challenge of overcoming initial shock, i.e., a "knowledge
531621 - management dilemma," that avers confusion and seeks simplicity of
531622 - serial processing one thing at a time, (see POIMS, ref OF 1 8774),
531623 - until experience is gained that makes people comfortable with the
531624 - power of the microcosm, reviewed with Intel on 950927. ref SDS 4 5412
531625 -
531626 -     [On 000824 Eric objects to links for accessing archives, what is
531627 -     called Knowledge Space in POIMS. ref SDS 96 FJ5H  He "hates"
531628 -     project record connected to relevant history in project archives.
531629 -     ref SDS 69 7O9I
531631 -  ..
531632 - Printing the record for off-line review reduces the power to augment
531633 - human intelligence.
531635 -  ..
531636 - But, people are comfortable with printed materials that present only a
531637 - limited field of issues which fit limited span of attention in the
531638 - conscious mind, posing another knowledge management dilemma that
531639 - blocks discovering the secret of KM under reasoning on 990527.
531640 - ref SDS 9 9711
531642 -  ..
531643 - Pilot testing new methods helps people become comfortable with an
531644 - enviroment that expands span of attention, called out by Doug in his
531645 - 1992 paper reviewed on 991222. ref SDS 15 5402  Experimenting with new
531646 - methods is supported by Andy Grove in his book "Only the Paranoid
531647 - Survive," reviewed on 980307, ref SDS 7 3416, however, experimenting
531648 - with counterintuitive methods is strongly resisted, and so requires an
531649 - express goal to meet the challenge of cultural viscocity cited on
531650 - 990527. ref SDS 9 1233
531652 -  ..
531653 - The section on Long Range Goals and Motivation should state a clear
531654 - objective to develop a DKR based on Knowledge Management practices
531655 - that will be discovered in performing the project, since none seem to
531656 - existence that warrant notice.  The DKR will help solve world
531657 - problems, etc, and may usher in a new work discipline based on a whole
531658 - new way of thinking, called by Doug Engelbart, per BI mission reviewed
531659 - on 991222. ref SDS 15 3696
531661 -  ..
531662 - The specification can therefore set out a plan to gain experience with
531663 - a connected environment by using "starter technologies" Lee Iverson
531664 - and others have examined and proposed...
531665 -
531666 -     1. WBI
531667 -     2. Zope
531668 -     3. SlashDot
531669 -     4. Traction
531670 -     5. Squeak
531671 -
531672 - ...reported beginning on 000427. ref SDS 65 5985  On 000504 project
531673 - team considering Zwiki as starter technology. ref SDS 70 9000
531674 -
531675 -     [On 000516 Eugene Kim reports Lee Iverson making progress setting
531676 -     up Zope/Wiki server for project. ref SDS 76 4971
531678 -  ..
531679 - Write up a narrative that this experience will inform future versions
531680 - of the spec, and eventually the deliverable of the spec will replace
531681 - these "starter technologies."
531682 -
531683 -
531684 -
531685 -
531686 -
5317 -

SUBJECTS
OHS Open Hyperdocument System
DKR Single Source Central Control Invades Privacy
Editing Core Capability
Version Control
DKR Specification
Editor Development, 000505
Specifications, DKR, OHS

6509 -
651001 -  ..
651002 - Diagnostics
651003 -
651004 - The new v0.5 has 946 lines, about 100 more than v0.2.
651005 -
651006 - Deleted Sections...
651007 -
651008 -     Link-typable in v0.3 seems to be deleted in this version.
651009 -     ref SDS 0 3400
651011 -  ..
651012 - New Sections Added...
651013 -
651014 -     Catagorizable, ref SDS 0 5003
651015 -
651016 -     Queryable, ref SDS 0 2709
651017 -
651018 -     Use Case Scenarios, ref SDS 0 2623
651020 -      ..
651021 -     Reuse, ref SDS 0 1804
651022 -
651023 -          [On 000508 this was added to create v0.6, which has 966
651024 -          lines. ref SDS 71 0782
651025 -
651026 -
651028 -  ..
651029 - Section Summary Analysis
651030 -
651031 - See comment above on need for a section to explain correlation (also
651032 - called alignment) with other two parts of architecture:
651033 -
651034 -
651035 -                   •  marketing
651037 -                       ..
651038 -                   •  vision
651039 -
651040 -
651041 - ...per Jack Park. ref SDS 0 0375
651043 -      ..
651044 -     "General Functional Requirements" appears several places, which
651045 -     seems confusing.
651046 -
651047 -         General Characteristics has a major subheading of General
651048 -         Functional Requirements. ref DRT 1 8019  There is a major
651049 -         section heading for "General Functional Requirements."
651050 -         ref DRT 1 1710  When time permits consideration might be
651051 -         given to changing these names.
651052 -
651054 -     ..
651055 -    Long-Range Goals - Email is Short Range, KM is the Longer View
651056 -    (today ref DRT 1 4550, 000306 ref DRP 5 4550)
651057 -
651058 -      Develop support for "collaborative documents."
651059 -
651060 -      This section adds that collaborative documents are implemented
651061 -      via email, ref DRT 1 1748, reflecting Eric's planning on 000423
651062 -      to augment human intelligence, ref SDS 62 5096, by email.
651063 -      ref SDS 62 5943
651065 -       ..
651066 -      Question - isn't improving email the "short" range goal, because
651067 -      that is what seems easiest to do and fund, as reported on 000504,
651068 -      ref SDS 67 5187  But the "long" range goal is to "augment human
651069 -      intelligence" with a DKR that we don't quite understand yet, but
651070 -      think is out there to be created some day? see 000423.
651071 -      ref SDS 62 5096
651073 -       ..
651074 -      Doug calls for a "Whole new way of thinking" in the Bootstrap
651075 -      mission, reviewed on 991222. ref SDS 15 3696  Wouldn't that be a
651076 -      long range goal, and fixing up current way of thinking using
651077 -      email is the short range goal, per below. ref SDS 0 4392
651079 -       ..
651080 -      Long Range goals may be a good place to discuss marketing and
651081 -      vision issues, i.e., architecture, per above. ref SDS 0 4234
651083 -       ..
651084 -      One approach would be to state a clear objective for developing a
651085 -      DKR that augments human "intelligence" based on Knowledge
651086 -      Management practices that will be discovered in performing the
651087 -      project, since none existence that warrant notice.  The DKR will
651088 -      help solve world problems, etc, and may usher in a new work
651089 -      discipline based on a whole new way of thinking, called out by
651090 -      Doug Engelbart. see 991222, ref SDS 15 3744, and analysis on
651091 -      000424. ref SDS 63 5033
651093 -       ..
651094 -      Defining KM begins with defining "knowledge" and "information" in
651095 -      a way that moves beyond marketing hype, and allows tools to
651096 -      augment human "intelligence."  The product spec for the core
651097 -      capability needs to aligned with this foundational work, per
651098 -      action item on 000407. ref SDS 58 2805
651099 -
651101 -       ..
651102 -      Motivation - World Problems, Improve the Work, Save Time, Money
651103 -      (today ref DRT 1 6156, 000306 ref DRP 5 6156)
651104 -
651105 -      This section seems unchanged.  Eric cites not changes.
651107 -       ..
651108 -      Vision and marketing elements of architecture seem like they
651109 -      should be discussed in this section, per above. ref SDS 0 4234
651111 -       ..
651112 -      On 000120 Eric indicated the motivation is to solve world
651113 -      problems. ref SDS 17 2688  On the same day some smaller problems
651114 -      were identified that require a solution, e.g., help a CEO write
651115 -      up the record and follow up; conduct a productive meeting, align
651116 -      product specs with original requirements. ref SDS 17 3071
651118 -       ..
651119 -      On 000504 Eugene Kim specified important motivations or needs in
651120 -      performing research. ref SDS 69 0007
651122 -       ..
651123 -      On 000504 Eric noted that SDS records are confusing because of
651124 -      links, ref SDS 68 1739, which aligns with expectations for the
651125 -      DKR system based on the editor spec. ref SDS 0 5475  Should this
651126 -      fact produce a motive for considering how to avoid being
651127 -      overwhelmed by knowledge, as discussed o 000407?
651129 -       ..
651130 -      Starting Points
651131 -      ref DRT 1 1015, 000306 ref DRP 5 1015
651132 -
651133 -      No evident changes, none cited by Eric from v0.3 which changed
651134 -      v0.1 by omitting detailed list of ideas for developing
651135 -      capability, e.g., in v0.1 Augment, IBIS, etc, are listed.  v0.2
651136 -      explains References, Bootstrap section shows possible "starting
651137 -      points," which is provided, also, today in Eric's 2nd letter,
651138 -      ref DRP 6 3283, reviewed below. ref SDS 49 8044
651140 -       ..
651141 -      Why don't we start with Eric's goal to augment human intelligence
651142 -      on 000423, ref SDS 62 5096, based on Doug's vision to augment
651143 -      human capabilities, and the record of meeting on 000324 calling
651144 -      out the human capability to augment is "intelligence,"
651145 -      ref SDS 53 0638, based on Doug's 1992 paper to augment collecting
651146 -      intelligence.? ref SDS 15 8064
651148 -       ..
651149 -      Might "Starting Points" cite some "Starter" technologies per the
651150 -      meeting on 000427, ref SDS 65 5985, and explain gaps between
651151 -      these starting points and Long Range Goals, and then explain this
651152 -      spec provides an important next step beyond the "Starter" tools.
651153 -
651155 -       ..
651156 -      General Characteristics,
651157 -      ref DRT 1 1512, 000306 ref DRP 5 1512
651158 -
651159 -      No evident changes, none cited by Eric from v0.3.
651160 -
651162 -       ..
651163 -      General Functional Requirements,
651164 -      ref DRT 1 1710, 000306 ref DRP 5 1710
651165 -
651166 -      Hierarchical, no evident changes. ref DRT 1 2205
651168 -       ..
651169 -      Reusable
651170 -
651171 -          [On 000508 this section added to create v0.6. ref SDS 71 0782
651172 -
651173 -          Underlying data structure will be a directed graph. In
651174 -          reality, it will be bidirectional, and it will typically turn
651175 -          out to have cyclic loops. Although it would be nice to avoid
651176 -          that, it is probably unavoidable.
651178 -              ..
651179 -             General concept of "reusable" in the sense of recycling
651180 -             intellectual capital by generating a resource once, and
651181 -             then citing it when needed, is an inherent property of
651182 -             Knowledge Space that saves a lot of time and avoids
651183 -             mistakes of transcription.  This is a major step toward
651184 -             "augmenting human intelligence," saving time and money,
651185 -             which adds a lot of value to daily knowledge work. as set
651186 -             out in POIMS. ref OF 1 6649
651187 -
651188 -                [On 000517 Eric reported challenges working with
651189 -                Knowledge Space that applies the "reusable" feature.
651190 -                ref SDS 77 5184
651192 -              ..
651193 -             Explain how this objective will be accomplished by current
651194 -             specification?
651196 -           ..
651197 -          The "network" nature of the graph results from the property
651198 -          that allows a document-segment (node or tree) to be used in
651199 -          multiple places. In each "document" that makes such an
651200 -          access, however, the view is hierarchical. The hierarchy is a
651201 -          view of the graph, and a "document" is really a structured
651202 -          collection of nodes from the data base.
651204 -              ..
651205 -             Need example and scenario of how this adds value to
651206 -             managing information, i.e., what steps does it save, how
651207 -             much time does it save, how long does it take to apply,
651208 -             what other resources are required to implement, etc.?
651210 -           ..
651211 -          Unlike HTML, where references to other documents occurs only
651212 -          with links, references to other nodes and trees in this
651213 -          system will typically occur as "includes". The effect of the
651214 -          inclusions will be to make the material will appear inline,
651215 -          as though it were part of the original document.
651217 -       ..
651218 -      Revisable, no evident changes. ref DRT 1 5280
651220 -       ..
651221 -      Versionable, no evident changes. ref DRT 1 2546
651222 -
651223 -          Seems to fleshed out under Differencable, below. ref SDS 0
651224 -          6237
651226 -       ..
651227 -      Mailable, no evident changes. ref DRT 1 8346
651229 -       ..
651230 -      Multiple-Containment, no evident changes. ref DRT 1 4131
651232 -       ..
651233 -      Distributed, no evident changes. ref DRT 1 9072
651235 -           ..
651236 -          This seems like a big point Eric has been discussing; need
651237 -          deeper explanation.
651239 -       ..
651240 -      Administrable, no evident changes. ref DRT 1 1890
651242 -       ..
651243 -      Differencable, no evident changes. ref DRT 1 3432
651244 -
651245 -         This sounds like version control, and it would be very, very
651246 -         helpful. ref SDS 0 9477
651248 -       ..
651249 -      Linkable, ref DRT 1 2881
651250 -
651251 -         Added -- Indirect links are needed to link a list of related
651252 -         nodes, and to the latest version of a node.
651254 -       ..
651255 -      Link-typable in v0.3, ref DRP 5 5328,
651256 -
651257 -         Deleted -- entire section on Link-typable removed.
651258 -
651259 -         Explain why it was deleted, e.g., incorporated elsewhere, it
651260 -         was a mistake, etc.
651262 -          ..
651263 -         Maybe was summarized under "Linkable."
651265 -       ..
651266 -      Categorizable, ref DRT 1 0364 (Ontology??)
651267 -
651268 -         Added -- support for gIBIS style discussions, which sounds
651269 -         like "analysis," called out by Drucker on 931130. ref SDS 2
651270 -         7911
651272 -          ..
651273 -         Categorizable could be part of "ontology" issue cited by Jack,
651274 -         per above, ref SDS 0 1044, but scope needs clarification.
651275 -
651276 -            [On 000508 Joe Williams notes need for ontology.
651277 -            ref SDS 71 5972
651278 -
651279 -            [On 000601 this section expanded. ref SDS 81 5933
651281 -          ..
651282 -         Need example to illustrate meaning of following...
651283 -
651284 -            [On 000623 debate about "catagories" and "nodes."
651285 -            ref SDS 89 5040
651287 -          ..
651288 -         For material that is included "in line" in the original
651289 -         document, typing implies the ability to choose which kinds of
651290 -         linked-information to include. For example, in addition to the
651291 -         current version, one might choose to display previous versions
651292 -         and/or all commentary. ref DRT 1 1770
651294 -          ..
651295 -         Need example to illustrate meaning of following...
651297 -          ..
651298 -         For material that is displayed in separate windows, typing
651299 -         allows the secondary windows to automatically display material
651300 -         of a given type. (For example, in Rod Welch's "contract
651301 -         alignment" example, the secondary window might automatically
651302 -         display the meeting minutes that are linked to particular
651303 -         phrases in a contract. Lines might be automatically drawn from
651304 -         sections of the minutes to sections of the contract. Other
651305 -         links in the documents, however, would be ignored. ref DRT 1
651306 -         4080
651308 -              ..
651309 -             Linking review of meeting notes to specs or authority is
651310 -             common in SDS, as in this record.  On 000503 Eric was
651311 -             confused by links in SDS records, ref SDS 68 1739, which
651312 -             is common when first seeing Knowledge Space, reported on
651313 -             980824. ref SDS 8 5977 (see also above on KM boggles the
651314 -             mind, ref SDS 0 4524)  Maybe an improvement can be made,
651315 -             which Eric called out on 000405 to use inline links.
651316 -             ref SDS 56 4823
651318 -       ..
651319 -      Queryable, ref DRT 1 2535  (Ontology??)
651320 -
651321 -         Added -- It should be possible to construct an initial design
651322 -         document using queries of the form "give me all design notes
651323 -         corresponding to the features we decided to implement in the
651324 -         current version of the functional specification.
651326 -          ..
651327 -         This applies an "innovation" Eric proposed, ref DRP 2 6370, on
651328 -         000212. ref SDS 26 9790  On 000219 this capability cited again
651329 -         for authoring requirements as part of para 3, ref DRP 3 6474,
651330 -         for "Automatic Destinations." ref SDS 29 0784
651332 -          ..
651333 -         Together with catagories, above, ref SDS 0 5003, this relates
651334 -         to ontologies cited by Jack per above. ref SDS 0 1044
651335 -
651336 -            [On 000508 Joe Williams notes need for ontology.
651337 -            ref SDS 71 5972
651339 -          ..
651340 -         Question -- why only "design" notes?  Marketing medical,
651341 -         procurement, distribution, construction, manufacturing, or
651342 -         notes on a book, a lecture, like Eugene needs for research,
651343 -         all need the same help the engineer needs. ref SDS 69 5003
651345 -          ..
651346 -         Let's organize the record to get whatever we need, whenever we
651347 -         need it...
651348 -
651349 -                        Anytime, anywhere intelligence
651350 -
651352 -       ..
651353 -      Evaluable, ref DRT 1 6970, 000306 ref DRT 1 6970
651354 -
651355 -         No evident changes.
651357 -       ..
651358 -      Collaborative, ref DRT 1 2448
651359 -
651360 -         No evident changes.
651361 -
651363 -       ..
651364 -      Attributive, ref DRT 1 1935, 000306, ref DRP 5 1904
651365 -
651366 -         No evident changes.
651367 -
651368 -         On 000227 Jim Sporher recommended that DKR support ability to
651369 -         preserve attributions to credit people with contributing
651370 -         toward progress. ref SDS 40 0987
651372 -          ..
651373 -         On 000423 attribution manages author for text nodes.
651374 -         ref SDS 62 2597
651376 -          ..
651377 -         [...above, attribution needs attention in this v0.5.
651378 -         ref SDS 0 0375
651379 -
651380 -           [On 000601 Eric applies attribution function in v0.7.
651381 -           ref SDS 81 1462
651382 -
651383 -           [On 000602 Bill Bearden supports attribution for glossary to
651384 -           define "knowledge," and other terms. ref SDS 83 0195
651386 -       ..
651387 -      Accelerative, ref DRT 1 4830, 000306, ref DRP 5 4216
651388 -
651389 -         No evident changes.
651391 -       ..
651392 -      General Systemic Requirements,
651393 -      ref DRT 1 5003, 000306 ref DRP 5 3584
651394 -
651395 -         Calls for XML standards, per Sandy Klausner's letter on
651396 -         000424, ref SDS 63 3051, following Eric's letter on 000423
651397 -         identifying atomic data structures. ref SDS 62 8568
651399 -          ..
651400 -         Eric's letter on 000129 began discussing using XML.
651401 -         ref SDS 20 0957
651403 -          ..
651404 -         No evident changes.
651406 -       ..
651407 -      Extensible
651408 -      ref DRT 1 0528, 000306, ref DRP 5 M3W8,
651409 -
651410 -         No evident changes.  It seems to relate to the custominzing
651411 -         functions and menus, as called out by Eric yesterday, on
651412 -         000504. ref SDS 69 0583
651414 -            ..
651415 -           [On 000831 Eric cites requirements for extensible in
651416 -           relation to discussion on managment methods for using open
651417 -           source software developers. ref SDS 97 V4A9
651419 -       ..
651420 -      Secure,
651421 -      ref DRT 1 5103, 000306, ref DRP 5 1862
651422 -
651423 -         Changed from "Security."
651424 -
651425 -         Added -- "Partionable" -- may intend "Partitionable" ???
651426 -
651427 -
651428 -
6515 -

SUBJECTS
Email OHS/DKR Knowledge Management Collaboration Core Foundation Act

8803 -
880401 -          ..
880402 -         Email Core Capability of DKR KM Collaboration
880403 -         Garden of Eden Let's Managers Graze on Information Overload
880404 -         Foraging on Information Overload Action Items Appear Naturally
880405 -
880406 -         Eric makes strong argument for email as core capability of
880407 -         OHS/DKR for Knowledge Management described as a...
880408 -
880409 -                     Collaborative Document System (CDS)
880410 -
880411 -         ..., ref DRT 1 0792, answering question on 000208, ref SDS 24
880412 -         8960, with original plan from 000120, ref SDS 17 3871, (but
880413 -         why under the heading "Secure," and why is argument in a
880414 -         spec???). This aligns with Eric's report on 000503 that their
880415 -         is not enough knowledge yet to create a dynamic knowledge
880416 -         repository (DKR), so the first step should be to enhance
880417 -         email, ref SDS 67 5187, and Jack Park contends that email is
880418 -         not an effective process for augmenting human intelligence.
880419 -         ref SDS 67 6138
880421 -          ..
880422 -         Eric's focus on improving collaboration aligns with Doug
880423 -         Engelbart's ideas in his 1992 paper on Groupware, cited during
880424 -         the Colloquium on 000120, ref SDS 17 1640, initially reviewed
880425 -         on 991222. ref SDS 15 0784
880426 -
880427 -            [On 000515 Charles Peirce's philosophy defining knowledge,
880428 -            and his view that collaboration is an effective path toward
880429 -            accurate understandings, supports Eric's design concept.
880430 -            ref SDS 75 0010
880432 -             ..
880433 -            [On 000601 Doug Engelbart gives priority to adding
880434 -            addressability to email archive. ref SDS 80 2760
880436 -             ..
880437 -            [On 000608 Sandy Klausner creating Collabrium to improve
880438 -            email. ref SDS 86 8446
880440 -             ..
880441 -            [On 000615 OHS/DKR team discouraged nobody knows what we
880442 -            are trying to accomplish, lack of progress causes engineers
880443 -            to give up on Knowledge Management; decide to improve email
880444 -            and call it OHS/DKR. ref SDS 88 6271
880446 -             ..
880447 -            [On 000623 Jack Park proposes collaboration to develop
880448 -            evolutionary epistomology for an ontology. ref SDS 89 4752
880450 -             ..
880451 -            [On 001008 Jack submits resource on Pattern Language for
880452 -            software engineerng communication. ref SDS 98 SZ3I
880454 -          ..
880455 -         Eric says email is the right interface for CDS, (CDS),
880456 -         ref DRT 1 0792, because...
880457 -
880458 -           •  information comes to you like "one stop shopping" for all
880459 -              of the information that needs attention.  The Web, on the
880460 -              other hand, provides nicer storefronts, but you have to
880461 -              go visit the store to find what you want. ref DRT 1 6006
880463 -               ..
880464 -              This seems like the "push" technology from a year or so
880465 -              ago, that alerts people to buy things, and was reviewed
880466 -              on 000503. ref SDS 67 MP3K
880468 -               ..
880469 -              POIMS lists email advantages and limitations supporting
880470 -              Knowledge Management. ref OF 1 CZ6K
880471 -
880472 -                 [On 000604 information overload is modern Garden of
880473 -                 Eden like cows grazing in a boutiful plain.
880474 -                 ref SDS 84 5893
880476 -                  ..
880477 -                 [On 000722 experience using Wiki DKR leads team to
880478 -                 recognize benefits of regular email. ref SDS 95 9000
880480 -                  ..
880481 -                 [On 010321 explained email advantages and issues of
880482 -                 information overload, cursory analysis in POIMS, based
880483 -                 on experience reported in SDS. ref SDS A2 ID6M
880485 -                  ..
880486 -                 [On 011003 Eric says email creates information
880487 -                 overload that paralyzes productivity, requests clues
880488 -                 for solution. ref SDS A6 EC5N
880490 -               ..
880491 -              A flaw in the CDS model is the hope that information
880492 -              needed to perform the work comes from what other people
880493 -              send, because email seems fast, easy, and cheap.  In an
880494 -              environment of information overload, getting 100+ email
880495 -              per day, we don't seem to have time to find things, nor
880496 -              construct correlations and implications, so it seems
880497 -              attractive just go with what we get in the mail, like
880498 -              herds of cattle foraging in vast fields of clover, just
880499 -              grazing on whatever comes naturally.  Joe Williams
880500 -              reported this experience on OHS/DKR project at SRI,
880501 -              reviewed on 000503. ref SDS 67 C48F
880502 -
880503 -                 [On 010408 email disadvantages for collaboration makes
880504 -                 knowledge management a lot of hard work.  Gary
880505 -                 Johnson. ref SDS A3 9H8H
880507 -                  ..
880508 -                 [On 010411 case study email limitations collaboration,
880509 -                 not effective medium for knowledge management.
880510 -                 ref SDS A4 627F
880512 -                  ..
880513 -                 [On 010420 Jeff Conklin explains similar defects in
880514 -                 email that make SDS a "killer application" by solving
880515 -                 these defects in a popular program. ref SDS A5 087F
880517 -               ..
880518 -              However, Email delivers what people want you to have at
880519 -              the moment, not what you need, per analysis on the high
880520 -              cost of medical mistakes, ref DIP 1 1045, on 000924.
880521 -              ref SDS 11 0715  See also analysis showing email caused
880522 -              crash on Mars, 991001. ref SDS 12 3077  The corollary to
880523 -              this hope is that by destroying email after 45 days, or
880524 -              some other arbitrary suspense date, the risk of
880525 -              accountability for erroneous, or otherwise actionable,
880526 -              conduct is reduced, as reported on 991021. ref SDS 13
880527 -              2695  This conflicts with Eric's analysis on 000424
880528 -              showing the value of history. ref SDS 63 4819
880529 -
880530 -                 [On 000720 Professor Joseph Ransdell relates worry in
880531 -                 400 BC by Socrates and Plato that early use of writing
880532 -                 would replace critical thinking. ref SDS 94 1457
880534 -               ..
880535 -              Actions taken should come from objectives, requirements,
880536 -              and commitments of the work, which is much broader than
880537 -              email.  What about meetings, calls, discussions,
880538 -              analysis, articles, media, thinking in the car, the
880539 -              shower, etc.  What about performance of the work that
880540 -              reveals ideas, constraints and opportunities???  We need
880541 -              a theory of knowledge that harmonizes all human
880542 -              experience in order to augment human intelligence, as
880543 -              called out in POIMS. ref OF 1 5820
880545 -               ..
880546 -              While it is true that information from others deserves
880547 -              notice, responsibility for getting needed information
880548 -              resides with the worker.  The system should support that
880549 -              requirement by facilitating management of information
880550 -              from others, which can surely benefit from the technology
880551 -              Eric has in mind; but, must further help synthesize
880552 -              information from all sources that has a material impact
880553 -              on the work.
880555 -               ..
880556 -           •  information is "organized" into threads
880557 -
880558 -              Eric also cites need for organizing information according
880559 -              to project and security issues.  He feels "firewall" give
880560 -              some structure. ref DRT 1 4424
880562 -               ..
880563 -              As explained in the record on Eric's letter received on
880564 -              000503, email has poor organization, ref SDS 67 TT68,
880565 -              evidenced by "threads" in the DKR project email, which
880566 -              rarely have anything to do with the content of the
880567 -              discussion.  Eric's proposal to improve email with
880568 -              "hierarchy" and "data structures" that avoid redundancy
880569 -              in email, ref DRT 1 8036, may be aimed at addressing this
880570 -              issue.  Joe Williams reported experience using email on
880571 -              OHS/DKR project at SRI shows this method reduces
880572 -              productivity due to poor organization. reviewed on
880573 -              000503. ref SDS 67 C48F
880575 -                   ..
880576 -                  [On 011003 Eric says email creates information
880577 -                  overload that paralyzes productivity, requests clues
880578 -                  for solution. ref SDS A6 EC5N
880580 -                   ..
880581 -                  [On 040113 Tom Munnecke submits requirements to
880582 -                  improve productivity of management and communication
880583 -                  with better organization of email. ref SDS A7 XP7J
880585 -               ..
880586 -           •  edit/reply within application used for view the
880587 -              information.
880589 -               ..
880590 -              Response is fast and easy, i.e., spontaneous, momentary
880591 -              impressions, rather than integrated into an organic
880592 -              subject structure for alignment with controlling forces.
880594 -               ..
880595 -              Ownership, responsibility and authority is not evident in
880596 -              a method that would modify another person's work product.
880597 -              Present email does this, yet is weak in other respects.
880598 -              Eric seems to propose solving the weaknesses of email by
880599 -              enabling anyone to modify another person's communication.
880600 -              This is "throwing the baby out with the bath."  If we
880601 -              modify, it becomes our separate communication, and our
880602 -              responsibility to avoid changing the meaning and intent
880603 -              of another person, while encouraging consideration of
880604 -              different views based on our reasoning and evidence. Eric
880605 -              may have in mind a method of providing "nodes" to
880606 -              accomplish this requirement.
880607 -
880609 -       ..
880610 -      DKR Requirements,
880611 -      ref DRT 1 0482, ref DRP 5 7031,
880612 -
880613 -         No evident changes.
880615 -          ..
880616 -         Didactic - Learning is Hard Work
880617 -
880618 -         This section is unchanged, but was not reviewed previously
880619 -         due to limited time; it states in total...
880621 -          ..
880622 -         Eventually, the system must become a *teaching* tool. It must
880623 -         follow the concept of "Education on Demand", intelligently
880624 -         supplying the user with the information needed, and educating
880625 -         that user, whatever their initial background. (Within
880626 -         reasonable limits.), ref DRT 1 2360
880627 -
880628 -            Generally this supports ISO criteria on continual learning
880629 -            reviewed on 950721, ref SDS 3 2846, reflecting traditional
880630 -            requirements for "lessons learned" using case studies in
880631 -            the management arena, precedents in the legal profession,
880632 -            "stories" in the Bible and the larger culture, including
880633 -            movies and television programming, per Rolf Jensen's work
880634 -            reviewed on 000307. ref SDS 50 0783
880636 -             ..
880637 -            The proposed concept of "Education on Demand" is unclear,
880638 -            since it conveys a sense of entitlement, whereas, KM is
880639 -            hard work, as reported on 000307, ref SDS 50 5182, which
880640 -            can be facilitated by a DKR system that provides command
880641 -            control of the record.   Eric's suggestion or formulation
880642 -            seems to be supported by Bellinger, recommended by Doug, on
880643 -            000307, who calls for information on demand.
880645 -             ..
880646 -            Above under a heading for issues to consider including in
880647 -            spec, discuss need to develop method for accomplishing case
880648 -            studies and identifying lessons learned that support goals
880649 -            for "didactic" capabilities. ref SDS 0 8256
880651 -       ..
880652 -      Operational Requirements,
880653 -      ref DRT 1 0104, ref DRP 5 1872
880654 -
880655 -         No evident changes.
880657 -       ..
880658 -      Data Structure Requirements,
880659 -      ref DRT 1 6128, ref DRP 5 5832
880660 -
880661 -         Not sure, but these may be "atomic data structures" supported
880662 -         by XML, also, SGML, per Sandy Klausner's letter on 000424,
880663 -         ref SDS 63 3051, following Eric's letter on 000423 identifying
880664 -         atomic data structures. ref SDS 62 4299
880666 -          ..
880667 -         Eric's letter on 000129 began discussing using XML.
880668 -         ref SDS 20 0957
880670 -          ..
880671 -         No evident changes.
880672 -
880673 -
880674 -
880675 -
8807 -

SUBJECTS
Use Case Analysis Editor
Use Case Scenarios DKR Design Ideas

9004 -
900501 -       ..
900502 -      Use Case Analysis Expanded in DKR Editor Spec
900503 -
900504 -
900505 -      Use Cases & Scenarios, ref DRT 1 4288,
900506 -
900507 -      Added -- this section from work on 000423. ref SDS 62 4933
900509 -       ..
900510 -      Eric proposes functionality to support the following "uses" for
900511 -      the system...
900513 -            ..
900514 -        •  Software Development discussions and docum, ref DRT 1 3182
900515 -
900516 -           This will have gIBIS capability.
900518 -            ..
900519 -        •  Strategic Decisions (combinations), ref DRT 1 8880
900521 -            ..
900522 -        •  Build a Product/Feature comparison chart, ref DRT 1 2769
900524 -            ..
900525 -        •  Build a Requirements/Technology evaluation, ref DRT 1 3969
900527 -            ..
900528 -        •  Project Management, ref DRT 1 8025
900530 -            ..
900531 -           This could encompass Eugene's ideas proposed on 000504 about
900532 -           integrating Contact and Time management. ref SDS 69 6033
900534 -            ..
900535 -           What about managing generally, other than projects?  Can we
900536 -           augment intelligence for all the managers, or just ones on
900537 -           projects?
900539 -            ..
900540 -        •  Multiple Software Versions, ref DRT 1 9945
900542 -            ..
900543 -        •  IBIS-style discussions,
900544 -           ref DRT 1 0288
900545 -
900546 -              Seems to reflect work on 000130, ref SDS 21 0866, later
900547 -              on 000212. ref SDS 26 9282
900548 -
900549 -              On 000218 concerns cited about IBIS. ref SDS 27 7050
900551 -               ..
900552 -              On 000223 Eric developed use case for IBIS to distinguish
900553 -              node types (??) ref SDS 35 4722
900555 -            ..
900556 -           How does this differ from the stuff for software?
900557 -           ref SDS 0 2720
900558 -
900559 -               [On 000602 Jack Park supports IBIS requirements for OHS
900560 -               (CDS) specs. ref SDS 83 6720
900561 -
900562 -               [On 000614 IBIS proposed to support Wiki. ref SDS 87
900563 -               4939
900565 -                ..
900566 -               [On 000630 Jack again supports IBIS. ref SDS 90 2040
900568 -                ..
900569 -               [On 000716 Joe Ransdell cautions about distinction
900570 -               between formal logic an practical reasoning. ref SDS 92
900571 -               2200
900573 -            ..
900574 -        •  Mathematical/Logical Reasoning, ref DRT 1 5780
900575 -
900576 -           This addresses Jack Park's objectives reported on 000503.
900577 -           ref SDS 66 6860
900578 -
900579 -              [On 000601 Eric adds a sub-section under "Looking Ahead"
900580 -              for Relational that seems to either implement this
900581 -              section, or there may be some duplication. ref SDS 81
900582 -              4967 and ref SDS 81 4200
900584 -         ..
900585 -        Specific Uses - lists common tasks, ref DRT 1 1925, people can
900586 -        accomplish with the system, e.g., commenting and outlining,
900587 -        suggested by Eugene on 000504. ref SDS 69 6205
900588 -
900589 -              [On 000508 Eric reported prior experience creating an
900590 -              outline program, which could be applied in the current
900591 -              editor as an optional format to accomplish Eugene's point
900592 -              that outlining helps research.
900594 -       ..
900595 -      Future: Using an Abstract Knowledge Representation,
900596 -      ref DRT 1 4003,
900597 -
900598 -        This section seems unchanged from v0.1.
900599 -
900600 -           Might cite cutting edge ideas that are not yet ready for
900601 -           incorporation into DKR, but may provide a path, if
900602 -           perfected, for accomplishing Long Range Goals, per above.
900603 -           ref SDS 0 5124
900605 -            ..
900606 -           Architecture "vision" and "marketing" will have some of
900607 -           this, but engineering needs to provide planning for avoiding
900608 -           near term design that seems fast and easy, but limits
900609 -           ability to accomplish Long Range Goals.
900611 -         ..
900612 -        System boggles the mind, ref DRT 1 2337, see "Knowledge Space"
900613 -        above. ref SDS 0 4524
900614 -
900615 -
900616 -
900617 -
900618 -
900619 -
900620 -
900621 -
900622 -
900623 -
900624 -
900625 -
900626 -
900627 -
9007 -