Eric,
Here are comments on the specs you have drafted for the OHS editor. The
comments recognize you have done a great job as the major contributor, with
limited time. The CDS model is an interesting and powerful extension of starter
technologies being considered. The record below reviews v0.5 received on
000505, and includes the update for v0.6 received on 000508 that added
"Reusable."
Thanks.
Rod
------------------------------------------------------------------------
Let us remember those important dates for you!
Check out eGroups' calendar at:
http://click.egroups.com/1/3937/4/_/444287/_/958380077/
------------------------------------------------------------------------
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
THE WELCH COMPANY
440 Davis Court #1602
San Francisco, CA 94111-2496
415 781 5700
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 2615 - Summary/Objective 2616 - 261601 - Follow up ref SDS 42 0000, ref SDS 41 0000. 261602 - 261603 - Eric Armstrong submits updated specs for the editor, a Collaborative 261604 - Document System (CDS). He provides strong rationale for email as the 261605 - core capability of the DKR, ref SDS 0 4392, and includes Use Case work 261606 - developed since the prior version. ref SDS 0 2623 Due to limited 261607 - time, there is no attribution to work from Doug, Joe, Jack, Lee and 261608 - Eugene. ref SDS 0 0375 Neither is there express alignment between the 261609 - engineering spec and architecture issues, ref SDS 0 4234, reflecting 261610 - design has led architecture from the beginning. "Long range goals" 261611 - seem more like near term objectives to work around lack of definition 261612 - on concepts that prevent work on a DKR. ref SDS 0 5124 261613 - 261614 - [On 000508 Joe Williams notes need for ontology. ref SDS 63 5972 261615 - 261616 - [...Eric submits v0.6 that adds "reusable" requirement. 261617 - ref SDS 63 0782 261618 - 261619 - We need to get Eric, Jack, Lee, Joe and Eugene into a room for 261620 - spec review, with guidance from Doug. We need people like Paul, Jon 261621 - Winters and others promoting open source to comment on specs, so the 261622 - entire burden is not on Eric. 261623 - 261624 - We need a team to hammer out an architecture to guide engineering, per 261625 - Jack, which will define "knowledge" per Doug, and KM per Eric and 261626 - Eugene. ref SDS 0 2356 261627 - 261628 - The team needs to procede with using Zope, SlashDot, Traction or other 261629 - desired tools, to connect daily work with the larger course Doug has 261630 - charted, in order to gain experience with a connected environment that 261631 - will disclose the secret of converting information into knowledge. 261632 - 261633 - Consideration might be given to building into the spec a 261634 - requirement for "listening" support, suggested by Adam and Jack on 261635 - 000424, ref SDS 55 1590 A communication "metric" of some kind helps 261636 - people follow their best instincts in supporting the project Doug has 261637 - initiated. SRI's planned elevated support may help accomplish this. 261638 - 261639 - 261640 - 261641 - 261642 - 2617 - 2618 - 2619 - Progress 2620 - 262001 - 262002 - Editor Specification Needs Alignment with Architecture 262003 - Collaborabive Document System Requirements v0.5 - Boggles the Mind 262004 - 262005 - Follow up ref SDS 42 0782, ref SDS 41 0782. 262006 - 262007 - Received ref DRT 1 0001 from Eric Armstrong submitting Requirements 262008 - for a Collaborative Documents System (CDS) v0.5, explained in detail 262009 - below. ref SDS 0 4392 262010 - 262011 - This updates prior versions, more fully listed in the record on 262012 - 000423. ref SDS 54 6306 262013 - 262014 - There is no evident record of anyone helping Eric with this task; many 262015 - talented people have noted slow progress, and suggested a different 262016 - direction, but only Eric has produced an implementation spec. 262017 - 262018 - [On 000509 Paul Fernhout commented on project crisis. 262019 - ref SDS 64 4980 262020 - 262021 - There are two sections for history, one called version history and 262022 - the other simply history. Both seem to show the same thing. So I 262023 - combined them under the single heading of History. 262024 - 262025 - Eric might consider preparing a small para that sets out the 262026 - highlights of major changes and additions, particularly with 262027 - respect to concept and functionality. Since time is limited, it 262028 - does not have to be comprehensive, but merely indicate the 262029 - evolutino of scope and a few major changes in direction. 262030 - 262031 - v0.1 ref DRP 2 0001 dated 000125 ref SDS 12 3867 262032 - 262033 - v0.2 ref DRP 10 0001 dated 000306 ref SDS 42 0782 , 262034 - 262035 - Eric shows following additional prior versions... 262036 - 262037 - These entries have no dates and no links to obtain materials for 262038 - comparing with current submission. 262039 - 262040 - 0.3 Formatting, two additions 262041 - 262042 - Is v0.3 the presentation Eric made at the meeting on 262043 - 000406 which was not distributed to the team through the 262044 - email system? ref SDS 49 0375 262045 - 262046 - 0.4 Use Case Scenarios, see below. ref SDS 0 2623 262047 - 262048 - On 000423 received Use Case Scenarios from Eric. 262049 - ref SDS 54 4933 262050 - 262051 - 262052 - There is no express explanation in the specification presented 262053 - today, because of limited time, showing alignment with... 262054 - 262055 - 1. Open Source production plan impacts on design. 262056 - 262057 - Explain "Starter Technologies" will provide experience with a 262058 - connected environment, that will inform project design. 262059 - ref SDS 0 4524 262060 - 262061 - Explain core capabilility will be created and expanded, per 262062 - issues in the record of project launch meeting on 000324. 262063 - ref SDS 45 3055 and ref SDS 45 7371 262064 - 262065 - 2. Innovation Eric developed for core capability on 000212. 262066 - ref SDS 19 9790 262067 - 262068 - 3. Requirements Doug Engelbart submitted on 000326, ref SDS 46 262069 - 5972 ...again on 000327. ref SDS 47 3971 262070 - 262071 - 4. Knowledge and Knowledge Management to augment human 262072 - intelligence (see also "architecture. ref SDS 0 4234) Specs 262073 - need to explain correlation to the purpose of the project, 262074 - otherwise there is no benefit of setting out a purpose. 262075 - 262076 - On 000504 Doug reported NSF denied support some years ago 262077 - because the proposal did not define knowledge. ref SDS 62 5555 262078 - Earlier, Doug requested work up similar to Bellinger, on 262079 - 000307, ref SDS 43 4820, and again on 000419. ref SDS 51 4964 262080 - On 000423 Eric explained purpose of the project to augment 262081 - human intelligence, ref SDS 54 5096; on 000424 Adam proposed 262082 - including Doug's name in the explanation of the purpose;, 262083 - ref SDS 55 0002; and on 000504 Eugene explained a working 262084 - definition of "knowledge." ref SDS 61 5003 Let's use the 262085 - intellectual capital being generated by the team, to build the 262086 - project. 262087 - 262088 - [On 000510 Joe Williams submits definition of knowledge. 262089 - ref SDS 65 0004 262090 - 262091 - 5. Use Case Joe Williams submitted on 000422. ref SDS 53 4933 262092 - 262093 - Joe presents a framework for integrating DKR and OHS. This 262094 - needs attention. 262095 - 262096 - 6. Architecture Jack Park submitted on 000426. ref SDS 56 262097 - 0304 262098 - 262099 - Per Jack, specs need narrative and links to align vision, 262100 - marketing and engineering. 262101 - 262102 - [...see Long Range Goals below. ref SDS 0 2790 262103 - 262104 - The specs Eric submits today seem like the Engineering part of 262105 - the architecture. Engineering specs need a section to explain 262106 - correlation between what is being engineered and specified, 262107 - and what is called out in marketing and vision, so the work is 262108 - guided by the architecture, and issues to be resolved are 262109 - clear, beginning with any gaps between what we are producing 262110 - and the purpose of the project to augment human intelligence, 262111 - per point 4. ref SDS 0 2356 262112 - 262113 - 7. Requirements and Use Case scenarios Eugene Kim submitted on 262114 - 000504, ref SDS 61 6033, supported by Jack Park. ref DRP 13 262115 - 2115 262116 - 262117 - Actually, Eugene's ideas on "comments" are incorporated 262118 - into the spec v0.5 under "Specific Use Cases." ref DRT 1 262119 - 1925 262120 - 262121 - Eugene's broader ideas about integrating time and contacts 262122 - may warrant consideration. ref DRP 12 6660 262123 - 262124 - 262125 - 262126 - Starter Technologies Give Designers Experience with Knowledge Space 262127 - Knowledge Space Boggles the Mind - Experience Unboggles 262128 - 262129 - This version continues to "wonder" what such a system will look like 262130 - after when extended with thousands of relationships, i.e, the 262131 - complexity of a connected environment will "boggle the mind," 262132 - ref DRT 1 2337, as reported on 000125. ref SDS 12 3975 262133 - 262134 - On 000503 Eric reported he is printing SDS records, and links in the 262135 - record are confusing. ref SDS 60 5092 and ref SDS 60 1739 262136 - 262137 - The section on Long Range Goals and Motivation should state a clear 262138 - objective to develop a DKR based on Knowlege Managment practices that 262139 - will be discovered in performing the project, since none seem to be 262140 - existence that warrant notice. The DKR will help solve world 262141 - problems, etc, and may usher in a new work discipline based on a whole 262142 - new way of thinking, called by Doug Engelbart. 262143 - 262144 - The specification can set out a plan to begin gaining experience with 262145 - a connected environment by using various tools Lee Iverson and others 262146 - have examined and proposed... 262147 - 262148 - WBI 262149 - Zope 262150 - SlashDot 262151 - Traction 262152 - Squeak 262153 - 262154 - ...reported beginning on 000427. ref SDS 57 5985 262155 - 262156 - Write up a narrative that this experience will inform future versions 262157 - of the spec. That eventually, the deliverable of the spec will 262158 - replace these "starter technologies." 262159 - 262160 - 262161 - 262162 - Diagonstics 262163 - 262164 - The new v0.5 has 620 lines, about 100 more than v0.2. 262165 - 262166 - 262167 - New Sections Added... 262168 - 262169 - Link-typable in v0.3 seems to be deleted in this version. 262170 - ref SDS 0 3400 262171 - 262172 - Use Case Scenarios, ref SDS 0 2623 262173 - 262174 - Reuse, ref SDS 0 1804 262175 - 262176 - [On 000508 this was added to create v0.6. ref SDS 63 0782 262177 - 262178 - 262179 - 262180 - 262181 - Section Summary Analysis 262182 - 262183 - See comment above on need for a section to explain correlation (also 262184 - called alignment) with other two parts of architecture: 262185 - 262186 - 262187 - • marketing and 262188 - 262189 - • vision 262190 - 262191 - 262192 - ... ref SDS 0 0375 262193 - 262194 - 262195 - "General Functional Requirements" appears several places, which 262196 - seems confusing. 262197 - 262198 - General Characteristics has a major subheading of General 262199 - Functional Requirements. ref DRT 1 8019 There is a major 262200 - section heading for "General Functional Requirements." 262201 - ref DRT 1 1710 When time permits consideration might be 262202 - given to changing these names. 262203 - 262204 - 262205 - 262206 - • Long-Range Goals 262207 - (today ref DRT 1 4550, 000306 ref DRP 10 4550) 262208 - 262209 - Develop support for "collaborative documents." 262210 - 262211 - This section adds that collaborative documents are 262212 - implemented via email, ref DRT 1 1748, reflecting Eric's planning 262213 - on 000423 to augment human intelligence, ref SDS 54 5096, by 262214 - email. ref SDS 54 5943 262215 - 262216 - Question - isn't improving email the "short" range goal, because 262217 - that is what seems easiest to do and fund, as reported on 000504, 262218 - ref SDS 59 5187 But the "long" range goal is to "augment human 262219 - intelligence" with a DKR that we don't quite understand yet, but 262220 - think is out there to be created some day? see 000423. 262221 - ref SDS 54 5096 262222 - 262223 - Doug calls for a "Whole new way of thinking" in the Bootstrap 262224 - mission, reviewed on 991222. ref SDS 8 3696 Wouldn't that be a 262225 - long range goal, and fixing up current way of thinking using 262226 - email is the short range goal, per below. ref SDS 0 4392 262227 - 262228 - Long Range goals may be a good place to discuss marketing and 262229 - vision issues, i.e., architecture, per above. ref SDS 0 4234 262230 - 262231 - One approach would be to state a clear objective for developing a 262232 - DKR that augments human "intelligence" based on Knowlege 262233 - Managment practices that will be discovered in performing the 262234 - project, since none existence that warrant notice. The DKR will 262235 - help solve world problems, etc, and may usher in a new work 262236 - discipline based on a whole new way of thinking, called out by 262237 - Doug Engelbart. see 991222, ref SDS 8 3744, and analysis on 262238 - 000424. ref SDS 55 5033 262239 - 262240 - Defining KM begins with defining "knowledge" and "information" in 262241 - a way that moves beyond marketing hype, and allows tools to 262242 - augment human "intelligence." The product spec for the core 262243 - capability needs to aligned with this foundational work, per 262244 - action item on 000407. ref SDS 50 2805 262245 - 262246 - 262247 - • Motivation 262248 - (today ref DRT 1 6156, 000306 ref DRP 10 6156) 262249 - 262250 - This section seems unchanged. Eric cites not changes. 262251 - 262252 - Vision and marketing elements of architecture seem like they 262253 - should be discussed in this section, per above. ref SDS 0 4234 262254 - 262255 - On 000120 Eric indicated the motivation is to solve world 262256 - problems. ref SDS 10 2688 On the same day some smaller problems 262257 - were identified that require a solution, e.g., help a CEO write 262258 - up the record and follow up; conduct a productive meeting, align 262259 - product specs with original requirements. ref SDS 10 3071 262260 - 262261 - On 000504 Eugene Kim specified important motivations or needs in 262262 - performing research. ref SDS 61 0007 262263 - 262264 - On 000504 Eric noted that SDS records are confusing because of 262265 - links, ref SDS 60 1739, which aligns with expectations for the 262266 - DKR system based on the editor spec. ref SDS 0 5475 Should this 262267 - fact produce a motive for considering how to avoid being 262268 - overwhelmed by knowledge, as discussed o 000407? 262269 - 262270 - 262271 - 262272 - 262273 - • Starting Points 262274 - ref DRT 1 1015, 000306 ref DRP 10 1015 262275 - 262276 - No evident changes, none cited by Eric from v0.3 which changed 262277 - v0.1 by omitting detailed list of ideas for developing 262278 - capability, e.g., in v0.1 Augment, IBIS, etc, are listed. v0.2 262279 - explains References, Bootstrap section shows possible "starting 262280 - points," which is provided, also, today in Eric's 2nd letter, 262281 - ref DRP 11 3283, reviewed below. ref SDS 42 8044 262282 - 262283 - Why don't we start with Eric's goal to augment human intelligence 262284 - on 000423, ref SDS 54 5096, based on Doug's vision to augment 262285 - human capabilities, and the record of meeting on 000324 calling 262286 - out the human capability to augment is "intelligence," 262287 - ref SDS 45 0638, based on Doug's 1992 paper to augment collecting 262288 - intelligence.? ref SDS 8 8064 262289 - 262290 - Might "Starting Points" cite some "Starter" technologies per the 262291 - meeting on 000427, ref SDS 57 5985, and explain any perceived 262292 - gaps between these starting points and where we want to get, and 262293 - then then explain this spec provides an important next step 262294 - beyond the "Starter" tools. 262295 - 262296 - 262297 - • General Characteristics, 262298 - ref DRT 1 1512, 000306 ref DRP 10 1512 262299 - 262300 - No evident changes, none cited by Eric from v0.3. 262301 - 262302 - 262303 - • General Functional Requirements, 262304 - ref DRT 1 1710, 000306 ref DRP 10 1710 262305 - 262306 - Hierarchial, no evident changes. ref DRT 1 2205 262307 - 262308 - Reusable, 262309 - 262310 - [On 000508 added this section to create v0.6. ref SDS 63 0782 262311 - 262312 - Underlying data structure will be a directed graph. In 262313 - reality, it will be bidirectional, and it will typically turn 262314 - out to have cyclic loops. Although it would be nice to avoid 262315 - that, it is probably unavoidable. 262316 - 262317 - General concept of "reusable" in the sense of recycling 262318 - intellectual capital by generating a resource once, and 262319 - thereafter citing it whenever needed, saves a lot of time 262320 - and avoids mistakes of transcription. 262321 - 262322 - How will this spec improve upon present practice. 262323 - 262324 - The "network" nature of the graph results from the property 262325 - that allows a document-segment (node or tree) to be used in 262326 - multiple places. In each "document" that makes such an 262327 - access, however, the view is hierarchical. The hierarchy is a 262328 - view of the graph, and a "document" is really a structured 262329 - collection of nodes from the data base. 262330 - 262331 - Need example and scenrio of how this adds value to 262332 - managing information, i.e., what steps does it save, how 262333 - much time does it save, how long does it take to apply, 262334 - what other resources are required to implement, etc.? 262335 - 262336 - Unlike HTML, where references to other documents occurs only 262337 - with links, references to other nodes and trees in this 262338 - system will typically occur as "includes". The effect of the 262339 - inclusions will be to make the material will appear inline, 262340 - as though it were part of the original document. 262341 - 262342 - Revisable, no evident changes. ref DRT 1 5280 262343 - 262344 - Versionable, no evident changes. ref DRT 1 2546 262345 - 262346 - Seems to fleshed out under Differencable, below. ref SDS 0 262347 - 6237 262348 - 262349 - Mailable, no evident changes. ref DRT 1 8346 262350 - 262351 - Multiple-Containment, no evident changes. ref DRT 1 4131 262352 - 262353 - Distributed, no evident changes. ref DRT 1 9072 262354 - 262355 - This seems like a big point Eric has been discussing; need 262356 - deeper explanation. 262357 - 262358 - Administrable, no evident changes. ref DRT 1 1890 262359 - 262360 - 262361 - Differencable, no evident changes. ref DRT 1 3432 262362 - 262363 - This sounds like version control, and it would be very, very 262364 - helpful. ref SDS 0 9477 262365 - 262366 - Linkable, ref DRT 1 2881 262367 - 262368 - Added -- Indirect links are needed to link a list of related 262369 - nodes, and to the latest version of a node. 262370 - 262371 - Link-typable in v0.3, ref DRP 10 5328, 262372 - 262373 - Deleted -- entire section on Link-typable removed. 262374 - 262375 - Maybe was summarized under "Linkable." 262376 - 262377 - Categorizable, ref DRT 1 0364 262378 - 262379 - Added -- support for gIBIS style discussions, which sounds 262380 - like "analysis," called out by Drucker on 931130. ref SDS 1 262381 - 7911 262382 - 262383 - Need example to illustrate meaning of following... 262384 - 262385 - For material that is included "in line" in the original 262386 - document, typing implies the ability to choose which kinds of 262387 - linked-information to include. For example, in addition to the 262388 - current version, one might choose to display previous versions 262389 - and/or all commentary. ref DRT 1 1770 262390 - 262391 - Need example to illustrate meaning of following... 262392 - 262393 - For material that is displayed in separate windows, typing 262394 - allows the secondary windows to automatically display material 262395 - of a given type. (For example, in Rod Welch's "contract 262396 - alignment" example, the secondary window might automatically 262397 - display the meeting minutes that are linked to particular 262398 - phrases in a contract. Lines might be automatically drawn from 262399 - sections of the minutes to sections of the contract. Other 262400 - links in the documents, however, would be ignored. ref DRT 1 262401 - 4080 262402 - 262403 - Linking review or meeting notes to specs or authority is 262404 - common in SDS, as in this record that links the editor 262405 - spec. We need something from Eric that says how this can 262406 - be improved. On 000503 Eric was confused by links in SDS 262407 - records, ref SDS 60 1739, which is common when first 262408 - seeing Knowledge Space, reported on 980824. ref SDS 3 5977 262409 - Maybe Eric is proposing an improvement, which he called 262410 - out on 000405 could be accomplished by inline links. 262411 - ref SDS 48 4823 262412 - 262413 - 262414 - Queryable, ref DRT 1 2535 262415 - 262416 - Added -- It should be possible to construct an initial design 262417 - document using queries of the form "give me all design notes 262418 - corresponding to the features we decided to implement in the 262419 - current version of the functional specification. 262420 - 262421 - This applies an "innovation" Eric proposed, ref DRP 3 6370, on 262422 - 000212. ref SDS 19 9790 On 000219 this capability cited again 262423 - for the authoring requirements as part of para 3, ref DRP 4 262424 - 6474, for "Automatic Destinations." ref SDS 22 0784 262425 - 262426 - 262427 - Question -- why "design" notes; what about marketing, medical, 262428 - procurement, distribution, construction, manufacturing, or 262429 - notes on a book, a lecture, like Eugene needs? ref SDS 61 5003 262430 - 262431 - Let's organize the record to get whatever we need, whenever we 262432 - need it... 262433 - 262434 - Anytime, anywhere intelligence 262435 - 262436 - 262437 - Evaluable, ref DRT 1 6970, 000306 ref DRT 1 6970 262438 - 262439 - No evident changes. 262440 - 262441 - Collaborative, ref DRT 1 2448 262442 - 262443 - No evident changes. 262444 - 262445 - 262446 - 262447 - Attributive, ref DRT 1 1935, 000306, ref DRP 10 1904 262448 - 262449 - No evident changes. 262450 - 262451 - On 000423 attribution manages author for text nodes. 262452 - ref SDS 54 2597 262453 - 262454 - Accelerative, ref DRT 1 4830, 000306, ref DRP 10 4216 262455 - 262456 - No evident changes. 262457 - 262458 - 262459 - • General Systemic Requirements, 262460 - ref DRT 1 5003, 000306 ref DRP 10 3584 262461 - 262462 - No evident changes. 262463 - 262464 - • Secure, 262465 - ref DRT 1 5103, 000306, ref DRP 10 1862 262466 - 262467 - Changed from "Security." 262468 - 262469 - Added -- "Partionable" -- may intend "Partitionable" ??? 262470 - 262471 - 262472 - 2625 - SUBJECTS Email Core Capability of DKR, 000505 Purpose DKR CDS Collaborative Document System DKR, Eric, 000505 3406 - 340601 - 340602 - Email Core Capability of DKR 340603 - 340604 - Eric makes strong argument for email as core capability of DKR 340605 - described as a... 340606 - 340607 - 340608 - Collaborative Document System (CDS) 340609 - 340610 - 340611 - ..., ref DRT 1 0792, answering his question on 000208, 340612 - ref SDS 17 8960, with his plan from 000120, ref SDS 10 3871, 340613 - (but why under the heading "Secure," and why is argument in a 340614 - spec???). This continues discussion on 000503, where Jack 340615 - Park contends that email is not the way to augment 340616 - intelligence. ref SDS 59 6138 340617 - 340618 - Eric says email is the right interface for CDS, (CDS), 340619 - ref DRT 1 0792, because... 340620 - 340621 - • information comes to you like "one stop shopping" for all 340622 - of the information that needs attention. The Web, on the 340623 - other hand, provides nicer storefronts, but you have to 340624 - go visit the store to find what you want. ref DRT 1 6006 340625 - 340626 - This seems like the "push" technology we heard about a 340627 - year or so ago, that alerts people to buy, which may be 340628 - fine. 340629 - 340630 - A deep flaw in the CDS model is the proposition, indeed 340631 - hope, that information needed to perform the work comes 340632 - from others, because it seems fast and easy. Email 340633 - delivers what people want you to have at the moment, not 340634 - what you need, per analysis on the high cost of medical 340635 - mistakes, ref DIP 1 1045, on 000924. ref SDS 5 0715 See 340636 - also email cause of crash on Mars, 991001. ref SDS 6 3077 340637 - The correllary to this hope is that by destroying email 340638 - after 45 days, or some other arbitrary suspense date, the 340639 - risk of liability for erroneous, or otherwise actionable, 340640 - conduct is reduced, as reported on 991021. ref SDS 7 340641 - 2695 340642 - 340643 - What is needed is governed by the requirements of the 340644 - work, which is much broader than email. What about 340645 - meetings, calls, discussions, analysis, articles, media, 340646 - thinking in the car, the shower, etc. What about 340647 - performance of the work that reveals ideas, constraints 340648 - and opportunities??? We need a theory of knowledge that 340649 - harmonizes all human experience in order to augment human 340650 - intelligence, as called out in POIMS. ref OF 1 5820 340651 - 340652 - While it is true that information from others deserves 340653 - notice, responsibility for getting needed information 340654 - resides with the worker. The system should support that 340655 - requirement by facilitating management of information 340656 - from others, which can surely benefit from the technology 340657 - Eric has in mind; but, must further help synthesize 340658 - information from all sources that has a material impact 340659 - on the work. 340660 - 340661 - • information is "organized" into threads 340662 - 340663 - Eric also cites need for organizing information according 340664 - to project and security issues. He feels "firewall" give 340665 - some structure. ref DRT 1 4424 340666 - 340667 - Email, however, has the poorest organization ever 340668 - conceived, as evidenced by "threads" in the DKR project 340669 - email, which rarelay have anything to do with the content 340670 - of the discussion. Eric's proposal improve email with 340671 - "hierarchy" and "data structures" that avoid redundancy 340672 - in email, ref DRT 1 8036, may be aimed at addressing this 340673 - issue. 340674 - 340675 - • edit/reply within application used for view the 340676 - information. 340677 - 340678 - Response is fast and easy, i.e., spontaneous, momentary 340679 - impressions, rather than integrated into an organic 340680 - subject structure for alignment with controlling forces. 340681 - 340682 - Ownershp, responsibility and authority is not evident in 340683 - a method that would modify another person's work product. 340684 - Present email does this, yet is weak in other respects. 340685 - Eric seems to propose solving the weaknesses of email by 340686 - enabling anyont to modify another person's communication. 340687 - This is "throwing the baby out with the bath." If we 340688 - modify, it becomes our seperate communication, and our 340689 - responsibility to avoid changing the meaning and intent 340690 - of another person, while encouraging consideration of 340691 - different views based on our reasoning and evidence. Eric 340692 - may have in mind a method of providing "nodes" to 340693 - accomplish this requirement. 340694 - 340695 - 340696 - 340697 - • DKR Requirements, 340698 - ref DRT 1 0482, ref DRP 10 7031, 340699 - 340700 - No evident changes. 340701 - 340702 - 340703 - • Operational Requirements, 340704 - ref DRT 1 0104, ref DRP 10 1872 340705 - 340706 - No evident changes. 340707 - 340708 - • Data Structure Requirements, 340709 - ref DRT 1 6128, ref DRP 10 5832 340710 - 340711 - No evident changes. 340712 - 340713 - 340714 - 340715 - 3408 - SUBJECTS Use Case Analysis Editor Use Case Scenarios DKR Design Ideas 3605 - 360501 - 360502 - Use Case Analysis Expanded in DKR Editor Spec 360503 - 360504 - 360505 - • Use Cases & Scenarios, ref DRT 1 4288, 360506 - 360507 - Added -- this section from work on 000423. ref SDS 54 4933 360508 - 360509 - Eric proposes to develop to functionality to support the 360510 - following "uses" for the system... 360511 - 360512 - • Software Development discussions and docum, ref DRT 1 3182 360513 - 360514 - This will have gIBIS capability. 360515 - 360516 - • Strategic Decisions (combinations), ref DRT 1 8880 360517 - 360518 - • Build a Product/Feature comparison chart, ref DRT 1 2769 360519 - 360520 - • Build a Requirements/Technology evaluation, ref DRT 1 3969 360521 - 360522 - • Project Management, ref DRT 1 8025 360523 - 360524 - This could encompass Eugene's ideas proposed on 000504 about 360525 - integrating Contact and Time management. ref SDS 61 6033 360526 - 360527 - What about managing generally, other than projects? Can we 360528 - augment intelligence for all the managers, or just ones on 360529 - projects? 360530 - 360531 - • Multiple Software Versions, ref DRT 1 9945 360532 - 360533 - • IBIS-style discusssions, ref DRT 1 0288 360534 - 360535 - How does this differ from the stuff for software? ref SDS 0 360536 - 2720 360537 - 360538 - • Mathematical/Logical Reasoning, ref DRT 1 5780 360539 - 360540 - This addresses Jack Park's objectives reported on 000503. 360541 - ref SDS 58 6860 360542 - 360543 - Specific Uses - lists common tasks, ref DRT 1 1925, 360544 - people can accomplish with the system, suggested by Eugene on 360545 - 000504. ref SDS 61 6205 360546 - 360547 - 360548 - • Future: Using an Abstract Knowledge Representation, 360549 - ref DRT 1 4003, 360550 - 360551 - This section seems unchanged from v0.1. 360552 - 360553 - System boggles the mind. ref DRT 1 2337 360554 - 360555 - 360556 - 360557 - 360558 - Distribution. . . . See "CONTACTS"
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 01:49:13 PDT