Click here to comment!
1...Question, Comment -- there is a need for redundancy on the
2...Why can't investors understand Eric's lucid explanation for
3...Question - need use case scenarios and diagram mock up showing
4...How does this explanation of "catagory" relate to ideas in
CONTACTS
SUBJECTS
Property Rights in Knowledge Organization
Commercial Viability
Ownership Investment Risk
Development Investment Risk
Open Source Development Freeware
Open Source License, 000421
Time for DKR Limited, 000423
Budget Planning, Need Revenue
Revenue Planning Needed for Budget
Grants Research
1412 -
1412 - ..
1413 - Summary/Objective
1414 -
141401 - Follow up ref SDS 42 0000, ref SDS 40 0000.
141402 -
141403 - Jeff Miller recommends DKR license support widespread use. ref SDS 0
141404 - 3055 Eric Armstrong comments on Paul Fernhout's concerns about DKR
141405 - license issue. ref SDS 0 0784; revenue is essential because part time
141406 - help cannot support effort required for creating capability to solve
141407 - world problem. ref SDS 0 2214 Eric submits revised explanation of DKR
141408 - objective to augment human intelligence, ref SDS 0 5933; he explains
141409 - this as combining email and web "documents." ref SDS 0 5943 Eric
141410 - submits "atomic data structures," updating Editor requirements.
141411 - ref SDS 0 4933
141413 - ..
141417 - ..
141418 - Submitted ref DIT 2 0001 to Eric commending this work. Ask how
141419 - editor improves handling of daily working information, for common
141420 - tasks, cited by Doug on 000327, note Eric's explanation of project to
141421 - augment human intelligence. ref SDS 0 1521
141422 -
141423 -
141424 -
141426 - ..
1415 -
1416 -
1417 - Progress
141801 - ..
141802 - License Objective Set Standard, Wide Use of DKR, Pilot Testing
141803 -
141804 - Follow up ref SDS 42 3055, ref SDS 40 3055.
141805 -
141806 - Received ref DRT 1 0001 from Jeff Miller commenting on Paul Fernhout's
141807 - letter, ref DRP 4 0834, received yesterday. ref SDS 42 5900
141809 - ..
141810 - Jeff asks.....
141811 -
141812 - What attributes are people looking for in the license?
141813 -
141814 - I think one of the most important is that the software spread and
141815 - be accepted widely. Especially if we are trying to create a
141816 - defacto standard and to spread the word about boot strapping
141817 - techniques and DKR. In that repect I don't think artistic license,
141818 - ala perl, would suit our needs nor BSD or X style as they make
141819 - forking easier. GPL while not denying forking makes it more
141820 - difficult.
141821 - ..
141822 - Qustion, Comment -- wide use and setting a standard are
141823 - the purpose of enterprise, which requires leadership, resources
141824 - and rewards.
141826 - ..
141827 - Quality, marketing and luck control widespread use, not
141828 - necssarily in that order. Doug's idea to promote pilot testing
141829 - reported on 991222 helps spread the word. ref SDS 4 5402
141830 -
141831 - [...see below for more on pilot testing. ref SDS 0 8342
141832 -
141834 - ..
141835 - Open Source Projects Need Revenue to Produce Useful Innovations
141836 -
141837 - Follow up ref SDS 42 3055, ref SDS 40 3055.
141838 -
141839 - Received ref DRT 3 0001 from Eric Armstrong responding to a letter
141840 - from Paul Fernhout received on 000422. ref SDS 42 3055 in which Paul
141841 - maintains that Eric's proposed license on 000421, ref SDS 40 3055,
141842 - needs to address following proposition...
141843 -
141844 - "Open Source" (TM) Licenses cannot discriminate among classes of
141845 - users. The system outlined [...in Eric's letter, ref DRP 3 0001, on
141846 - 000421, would not be considered "open source" or "Open Source"(TM).
141847 - ref DRP 4 0001
141848 - ..
141849 - Eric responds...
141850 -
141851 - I don't understand that. Why not? The reality is that unless a
141852 - revenue stream comes from somewhere, there is no way to "fill in
141853 - the picture" with little things like user documentation, customer
141854 - support, do interface usability studies, and do a dozen other
141855 - little things that produce a truly usable system. ref DRT 3 2720
141856 -
141857 - [On 011003 Eric feels payment is needed for hard work creating
141858 - DKR to make handling formation easier. ref SDS 66 O73F
141860 - ..
141861 - Eric wants to restrict the license terms to companies that are
141862 - making a profit -- so startups can use it. ref DRT 3 1680
141863 -
141864 - This seems to align with the report at the project meeting on
141865 - 000413 that open source projects never get completed.
141866 - ref SDS 35 3055
141867 - ..
141868 - Eric's analysis reflects planning on 000324. ref SDS 21
141869 - 1450 and ref SDS 21 4729
141871 - ..
141872 - Eric comments on Paul's concern about people paying for a useful DKR,
141873 - would dissapoint him and other talented developers, saying...
141874 -
141875 - That's important feedback to keep in mind. Its something we have to
141876 - make a conscious decision on, if it turns out we go that way. I'd
141877 - love to open source it to everyone, but I have yet to see a
141878 - business model that makes sense, other than one where your *real*
141879 - business is built on top of the software. ref DRT 3 2550
141880 - ..
141881 - Eric cites 80% drop in capitalization last week of ventures
141882 - using open source business models. He has not seen the open source
141883 - business model that makes a compelling enough case to support
141884 - venture capital risk. ref DRT 3 2208
141885 -
141886 - Aligns with analysis on 000422. ref SDS 42 0612
141887 -
141888 -
141889 - ..
141890 - Eric explains the need for revenue....
141891 -
141892 - The goal is to provide revenue to sustain future development, and
141893 - the freedom to pursue important projects when they become apparent.
141894 - There's only so much you can make from support contracts.
141895 - ref DRT 3 3250
141896 -
141897 - The primary goal is building a DKR, supporting it, and being able
141898 - to improve it and/or take on other projects, as needs dictate. The
141899 - only question is... "What is the best way to do that?". Open source
141900 - has advantages. Making money has advantages. What works best?
141901 - ref DRT 3 0988
141902 -
141903 - This addresses business model issue from action items on
141904 - 000407. ref SDS 31 6973
141905 -
141906 - [On 000426 discussed revenue needed for project management.
141907 - ref SDS 45 0187
141908 - ..
141909 - This aligns with preliminary analysis of Paul's concerns
141910 - in the record on 000422. ref SDS 42 3432 and ref SDS 42 6762
141912 - ..
141913 - Another goal is for people to use the DKR capability to augment
141914 - intelligence that solves world problems, as Eric notes below.
141915 - ref SDS 0 5933, and previously on 000120. ref SDS 5 2808
141917 - ..
141918 - If we solve world problems, like say poverty, there should be
141919 - added value. This added value is needed to maintain and
141920 - increase innovation, as Eric points out, see economics 101 and
141921 - Adam Smith.
141923 - ..
141924 - Eric further notes...
141926 - ..
141927 - Worthwhile Innovation Requires Investment
141928 - Foundations and Grants Not Effective Economic Engines for DKR
141929 -
141930 - Follow up ref SDS 42 3900.
141931 -
141932 - Doug has been pursuing foundation and government grants for 30 some
141933 - years. Where are the developers and funding agencies lining up to
141934 - back his vision? Making a vision a reality requires financial
141935 - resources, both individually and as an organization. Will open
141936 - source get us there? Possibly. What about 6 years from now, when an
141937 - equally important but slightly different opportunity comes along?
141938 - Will we still be doing it in our spare time? Or will we have the
141939 - freedom to devote all of our energies to it? ref DRT 3 0820
141940 - ..
141941 - This aligns with analysis yesterday. ref SDS 42 3900
141943 - ..
141944 - [On 000509 Paul Fernhout relates difficulties depending upon
141945 - government grants to finance major breakthroughs. ref SDS 55
141946 - 4902
141948 - ..
141949 - [On 000510 report that Doug was turned by NSF because they
141950 - wanted definition of knowledge. ref SDS 56 0784
141951 -
141953 - ..
141954 - Solving World Problems Requires Focused, Dedicated Talent
141955 -
141956 - Eric is investing a lot of time in the DKR project because it seems
141957 - necessary. This time does not pay the bills. Typically, he
141958 - produces on his regular job at 200% or 300% by writing programs to
141959 - perform a week's worth of work. Recently, his productivity has
141960 - been a fraction rather than a multiple, causing significant stress.
141961 - He comes in evenings and weekends hoping to make up for lost time,
141962 - and then finds another important intellectual challenge.
141963 - ref DRT 3 3328
141965 - ..
141966 - [On 000426 discussed revenue needed for project management.
141967 - ref SDS 45 0187
141969 - ..
141970 - [On 000509 Eric reports challenge of allocating resources to
141971 - create innovation breakthroughs without revenue. ref SDS 55
141972 - 0784
141974 - ..
141975 - Eric Limits Time on DKR Project to Earn a Living
141976 -
141977 - Received ref DRT 6 0001 from Eric has started filtering mail so
141978 - it gets put into folders. He plan is to review folders for DKR
141979 - project on Monday, Wednesday, Friday, and Sunday evenings, and
141980 - to avoid them at all costs during the day.
141981 -
141983 - ..
141984 - Focused, Dedicated Talent Requires Payment
141985 -
141986 - How can Eric, and others, keep working on the DKR project, and keep
141987 - a full time job? ref DRT 3 0840
141988 -
141989 - On 000324 this was addressed in record of initial project
141990 - meeting. ref SDS 21 7074
141992 - ..
141993 - On 000327 discussed with Doug. ref SDS 22 5402
141994 -
141995 - [On 000426 discussed revenue needed for project management.
141996 - ref SDS 45 0187
141997 -
141998 - [On 000509 Eric reports challenge of allocating resources to
141999 - create innovation breakthroughs without revenue. ref SDS 55
142000 - 0784
142001 -
142003 - ..
142004 - Zope Add-on Business Model Requires Core Capability
142005 - Core Capability Needs High Performance to Justify Add-ons
142006 -
142007 - Eric responds to Paul's proposal for DKR to generate necessary
142008 - revenue by providing add-on technologies, based on a business model
142009 - used by Zope, ref DRP 4 5166, by asking...
142010 -
142011 - ...what kinds of add-ons make sense in a DKR?
142013 - ..
142014 - He asks, what would be a small enough core to be useful, and yet
142015 - allow for Adonis and upgrades? ref DRT 3 2709
142016 -
142018 - ..
142019 - Bootstrap Development Model under Open Source for DKR
142020 - Add-ons for SDS Core Knowledge Management Capability
142021 -
142022 - Follow up ref SDS 2 0990.
142023 -
142024 - On 000419 Doug Engelbart suggested that SRI "seed" team work on
142025 - add on tools, ref SDS 38 1008, to implement Bootstrap model
142026 - planned on 000324. ref SDS 21 7482
142028 - ..
142029 - Planning on 950803, ref SDS 2 0990, indicates the following
142030 - features can be integrated to compliment SDS core capability, so
142031 - people could plug them into SDS, so long as the output is always
142032 - compatible....
142033 -
142034 - [On 000503 discussed with Eric. ref SDS 50 6903
142035 - ..
142036 - 1. Accounting and cost control support.
142038 - ..
142039 - 2. Macro schedule, CPM, PERT interface.
142041 - ..
142042 - 3. Marketing Intelligence and Communciation Metrics service
142043 -
142044 - Add on service could sell advertizing space to provide
142045 - low cost support service.
142047 - ..
142048 - 4. Wordprocessing specialities, like legal briefs.
142049 -
142050 - Big target is to replace wordprocessing with a new
142051 - process of "knowledge management," or "intelligence."
142053 - ..
142054 - 5. Contact modules
142055 - ..
142056 - 6. Subject management, Epistomology, Ontology
142057 -
142058 - Vendors provide organic subject structures for different
142059 - industries and professional disciplines.
142061 - ..
142062 - 7. Spreadsheets
142064 - ..
142065 - 8. Drawing capability.
142067 - ..
142068 - 9. Pictures.
142070 - ..
142071 - 10. Voice data entry
142073 - ..
142074 - 11. Calling other applications.
142075 - ..
142076 - 12. Document Managemnet
142077 -
142078 - [On 001027 Paul Fernhout raises some ideas. ref SDS 62
142079 - BO4J
142080 - ..
142081 - 13. Security, Privacy, Confidentiality
142082 -
142083 - Password protection
142085 - ..
142086 - 14. AI Intelligent Processing, see 000314. ref SDS 20 2394
142087 -
142088 - a. Subject Management
142089 - b. Alignment
142090 -
142091 -
142093 - ..
142094 - Pilot Test License Does Not Require Donating Added Value
142095 - Security Requires Ability to Control Public and Private
142096 - Dichotomy Between Me and You, Us and Them Requires Privacy
142097 -
142098 - Eric considers that a DKR browser must be given away, and so
142099 - concludes that the add-on has to be on the server. He suggests
142100 - corporations may want a server of their own, so that they can
142101 - keep their knowledge private. ref DRT 3 3360
142102 -
142103 - Question, Comment -- there is a need for redundancy on the
142104 - server issue in order to mitigate bumbling. Further, nobody
142105 - wants to relinguish control of vital information to others.
142106 - We let others transmit it, like the post office, but not
142107 - maintain it.
142108 - ..
142109 - Per above on desire to get widespread use, ref SDS 0
142110 - 3055, why can't people be provided a license to pilot test
142111 - for a period of 30 days, 90 days, 200 years, sufficient to
142112 - discover whether a KM capability improves their lives, and if
142113 - so, the pilot test license eventually runs out, and they pay
142114 - for added value? Why is this such a huge issue?
142116 - ..
142117 - If something doesn't add value, we certainly don't want
142118 - people to pay. If it adds value and people want it, let them
142119 - vote for that propoposition in the usual manner. If there
142120 - are not enough votes, then more work can be done to improve
142121 - it, or abandon it, like any other product.
142123 - ..
142124 - We can provide beta versions for market research, and these
142125 - can be given away, or charged a reduced rate.
142126 - ..
142127 - Eric anticipates the DKR would be a good library.
142128 -
142129 -
142130 -
142131 -
142132 -
142133 -
1422 -
SUBJECTS
Chronology, Cause and Effect, Sequence Complexity
Lessons Learned, Cass Studies Root Cause Analysis
Lessons Learned Failure Risk Management
Collaboration Common Basis 2 KM Groups Tools and People Skills
Collaboration Email AI Web Pages AI Use Software Tools for Collaborat
TQM Project Management Human Systems, and Software CPM, AI Web Site E
Elevator Version Marketing Summary of Requirements for OHS/DKR
Armstrong, Eric Proposes 20 Second Elevator Pitch for Selling OHS/DKR
Elevator Pitch for Selling OHS/DKR is to Augment Human Intelligence
Marketing Selling Practices Procedures
Armstrong, Eric Proposes 20 Second Elevator Pitch for Selling OHS/DKR
General
Armstrong, Eric Proposes 20 Second Elevator Pitch for Selling OHS/DKR
Elevator Sales Pitch 20 Seconds to Capture Customer
3416 -
341701 - ..
341702 - DKR Project Supports Lessons Learned and Continual Learning
341703 - Lessons Learned and Continual Learning Augment Human Intelligence
341704 - Augment Human Intelligence Purpose of Knowlede Management
341705 -
341706 - Follow up ref SDS 40 5933, ref SDS 39 5555.
341707 -
341708 - Received ref DRT 2 0001 from Eric Armstrong supplementing his letter
341709 - ref DRP 2 0001, received on 000421. ref SDS 40 5933, responding to
341710 - suggestion on 000420, ref SDS 39 5555, for the SRI "seed" team (see
341711 - Doug's letter on 000419, ref SDS 38 4964), to define the purpose of
341712 - the DKR....
341713 -
341714 - "An interactive tool for discussion and deliberation that records
341715 - the decisions and their rationales in way that allows the
341716 - knowledge gained in the process to be applied to future projects.
341717 - ref DRP 2 0001
341718 - ..
341719 - This is the powerful idea from 000421 to recycle
341720 - intellectual capital as lessons learned in case studies.
341721 - ref SDS 40 0832
341723 - ..
341724 - On 000227 Eric was concerned that case study information was
341725 - difficult to manage. ref SDS 16 0001
341726 -
341727 - ...also on 000227 Eric explained benefits of connecting daily
341728 - working information to relevant history in order to save time.
341729 - ref SDS 15 1248
341731 - ..
341732 - [On 000424 Adam Cheyer submits propossed explanation of DKR
341733 - project. ref SDS 43 0002
341735 - ..
341736 - [On 000224 Eric cites Doug's work on Augment as example showing
341737 - need for "intelligence" from prior work to expedite current
341738 - endeavors. ref SDS 43 0786
341740 - ..
341741 - [On 000515 Mary Keeler's paper on the philosophy of Charles
341742 - Peirce seems to support Eric's call for technology to support
341743 - collaboration as a means to seek "truth" as a component of
341744 - "knowledge." ref SDS 57 7380
341746 - ..
341747 - [On 00824 Eric objects to a record connected to relevant history
341748 - in the project archives. ref SDS 61 FJ5H
341750 - ..
341751 - [On 010321 POIMS explains KM has two branches. ref SDS 65 0001
341752 -
341754 - ..
341755 - Today, Eric suggests summarizing (he calls it the "elevator version")
341756 - the purpose of the DKR as...
341757 -
341758 -
341759 - "A tool to augment human intelligence." ref DRT 2 1120
341760 -
341761 -
341762 - ...below, Eric describes a system of improving email as the first step
341763 - to augment intelligence. ref SDS 0 5943
341764 -
341765 - [On 000426 Jack Park explains design requires continual alignment
341766 - with original narrative on architecture, which is a key part of
341767 - "intelligence." ref SDS 46 0304
341769 - ..
341770 - [On 000503 Eric reports more information is needed to understand
341771 - how to create KM that augments intelligence. ref SDS 51 5033
341773 - ..
341774 - [On 000505 Eric submits engineering specs that set long range goal
341775 - to improve email for collaborative document system. ref SDS 54
341776 - 2790
341778 - ..
341779 - [On 010321 POIMS explains KM has two branches. ref SDS 65 0001
341781 - ..
341782 - [On 000531 requires architecture human thought. ref SDS 59 4256
341784 - ..
341785 - [On 020718 Eric calls for analysis and organization (catagories)
341786 - using a work role he calls an "oncologist" that can help realize
341787 - objectives to augment intelligence. ref SDS 67 M74J
341788 -
341790 - ..
341791 - Summary Connected to Detail Intelligence Process for Knowledge
341792 -
341793 - Elevator "version" is the synopsis you give to say, a venture
341794 - cap, when you happen to find yourself on the same elevator. If
341795 - the response is "how do you do that?", showing mild interest,
341796 - it's an invitation to move into the sentence-level version, then
341797 - the paragraph-level version, etc. ref DRT 2 1120
341798 -
341799 - Providing different levels of summary is a strong example
341800 - showing the meaning of knowledge. This method is applied in
341801 - POIMS to explain the complexity of human cognition.
341802 - ref OF 1 2200
341804 - ..
341805 - [On 000424 Eric explains need for different summaries to
341806 - obtain, build and maintain investor interest. ref SDS 43 0037
341808 - ..
341809 - [On 000426 develop KM formula to make it easier for people to
341810 - grasp the concept. ref Sds 44 1674
341812 - ..
341813 - [On 000427 Lee Iverson submits use case planning guide that
341814 - is excellent for Project Management, but not for creating a
341815 - better program for software programming. ref SDS 48 1462
341817 - ..
341818 - "Augment" is a term of art adopted by the team from Doug Engelbart's
341819 - work, reviewed on 991222. ref SDS 4 3011 On 000324 "augment" was
341820 - associated with enhancing human intelligence, ref SDS 21 0638, based
341821 - on discussion with Doug on 991222. ref SDS 4 1140
341823 - ..
341824 - "Intelligence" as the purpose of KM aligns with Eric's letter on
341825 - 000404 aiming to augment human reasoning, ref SDS 26 7844, proposed on
341826 - 000120 for the Colloquium to augment human intelligence, ref SDS 5
341827 - 5976, answering Eric's question about scope of a DKR project.
341828 - ref SDS 5 3002 On 000208 submitted paradigm shift from documents to
341829 - Knowledge Space. ref SDS 11 4320 However, Eric does not explain in
341830 - his letter today the meaning of "intelligence" in relation to human
341831 - cognition, see POIMS, ref OF 1 0561, and his explanation of how to
341832 - augment intelligence shown below, reverts to a focus on documents and
341833 - email, ref SDS 0 5943, which was the perspective at the beginning of
341834 - the Colloquium on 000120. ref SDS 5 3871
341835 -
341836 - [On 000424 Jack Park reports Augment aims to enhance human
341837 - intellect. ref SDS 43 4602
341839 - ..
341840 - [On 000425 KM is a secret of SDS. ref SDS 44 0480
341842 - ..
341843 - Eric does not cite innovation of moving beyond "documents" on 000212
341844 - for the core capability of knowledge management, ref SDS 12 9790,
341845 - which was submitted to the DKR team on 000208, ref SDS 11 4905, in
341846 - response to Eric's request for help. ref SDS 11 8960
341848 - ..
341849 - Producing a tool to augment human intelligence, does not directly
341850 - support SRI "seed" team plan to create a tool that improves software
341851 - programming to bootstrap other solutions, discussed on 000324.
341852 - ref SDS 21 6992
341853 -
341854 - [...below Eric submits detailed design for editor, not clear how
341855 - "intelligence" is supported. ref SDS 0 4933 - sent letter to Eric
341856 - commending work, asking about "intelligence." ref SDS 0 1521
341858 - ..
341859 - [...below sent Morris letter asking his opinion. ref SDS 0 5642
341860 -
341862 - ..
341863 - Eric says the "paragraph explanation" for the purpose of the DKR is...
341865 - ..
341866 - Webmail Integrages Email with Web Documents
341867 -
341868 - Combine the simplicity and ease of use of an email system with the
341869 - expressive power of Web documents. In essence, remove the barrier
341870 - between email and documents, so you can comment on or even edit a
341871 - document as easily as sending a message. ref DRT 2 0828
341872 -
341873 - Eric's explanation today roughly aligns with his proposal on
341874 - 000120 to remove the barrier between documents and email to
341875 - provide webmail. ref SDS 5 3871
341876 -
341877 - [On 000424 Eric submits strong argument for capturing the
341878 - history of daily work, which conflicts with the aim today of
341879 - limiting the record to email. ref SDS 43 4819
341881 - ..
341882 - [On 000503 Eric proposes improving email, ref SDS 51 5187,
341883 - noting that "knowledge" is not yet well enough established.
341884 - ref SDS 51 5033 Jack proposes that DKR project reach higher
341885 - than email for core capability to augment human intelligence.
341886 - ref SDS 51 0748
341887 -
341888 - [On 000505 Eric submits updated specs calling for long
341889 - range plan to improve collaboration by improving email.
341890 - ref SDS 54 5208
341892 - ..
341893 - Why can't investors understand Eric's lucid explanation for
341894 - benefits of intellectual capital on 0000424, rather than have
341895 - to swallow with a straight face that email is going to
341896 - augment human intelligence????
341898 - ..
341899 - On 000420 Eric reported that CRIT which evidently created
341900 - something to accomplish some of Eric's objective, does not use
341901 - the system, and uses conventional email instead. ref SDS 39 4911
341903 - ..
341904 - Centering objective of DKR on email and the web conflicts with
341905 - the primary explanation reported on 000421, ref SDS 40 0920,
341906 - which is maintained today, ref DRT 2 0001, in that email, and
341907 - any other method that sends stuff to other people, is not
341908 - sufficiently robust to support the "deliberation" requirement of
341909 - human "intelligence," as set out in POIMS. ref OF 1 0561
341911 - ..
341912 - Paradigm shift from documents to Knowledge Space is explained in
341913 - POIMS. ref OF 1 1107
341915 - ..
341916 - Catagories Support Organized Discourse
341917 -
341918 - Eric wants DKR to categorize paragraphs (i.e. "messages") in order
341919 - to carry on a well- organized discourse. Preliminary categories
341920 - include...
341921 -
341922 - • question
341923 - • alternative
341924 - • argument for ,
341925 - • argument against, and
341926 - • endorsement
341928 - ..
341929 - Categories like those have been found to be helpful in mediated
341930 - discussion systems. We intend to put that thinking into software,
341931 - so remote collaborators can carry on the same kind of highly
341932 - reasoned discussions online. ref DRT 2 0756 98L
341933 -
341934 - This approach alings with Joe Williams who proposes using three
341935 - (3) levels of catagories, reviewed on 000422. ref SDS 41 0918
341937 - ..
341938 - Question - need use case scenarios and diagram mock up showing
341939 - how this would be implemented.
341940 -
341941 -
341942 -
3420 -
SUBJECTS
Data Structures, 000423
DKR Design Ideas
Atomic Data Structures for Editor, DKR, 000423
Software Programming Program Initial Product, 000406
Use Case Method Define Requirement, 000324
Use Case Analysis Editor
XML SGML Knowledge Representation Atomic Data Strucutres Strive to Pr
Atomic Data Structures Knowledge Representation
4910 -
491101 - ..
491102 - Use Case Analysis for DKR and OHS Design Atomic Data Structures
491103 - Atomic Data Strucutres for DKR Specification
491104 -
491105 - Follow up ref SDS 41 4933, ref SDS 39 4004.
491106 -
491107 - Received ref DRT 5 0001 from Eric submitting specifications for atomic
491108 - data structures. This work does not expressly align with objective to
491109 - augment human intelligence, cited above, ref SDS 0 5933, nor to
491110 - develop ideas Eric presented on 000212 for the core capability of
491111 - knowledge management. ref SDS 12 9790
491113 - ..
491114 - The data structures do not specifically support software programming,
491115 - which was set by Doug as the initial target objective in the meeting
491116 - on 000324, ref SDS 21 6992, and confirmed at the meeting on 000406.
491117 - ref SDS 29 5078
491118 -
491119 - [On 000427 use cases submitted by Lee Iverson provide an excellent
491120 - task list for project management, but nothing specific to software
491121 - development. ref SDS 48 1462
491123 - ..
491124 - [On 000505 received updated specs for Collaborative Document
491125 - Requirements, from Eric, ref SDS 54 0782, and called the document
491126 - received today on Use Case Scenarios v0.4. ref SDS 54 3825
491128 - ..
491129 - [On 001220 Gary Johnson proposed developing requirements for DKR
491130 - that can represent addressable atoms of information. ref SDS 63
491131 - TQ4H
491133 - ..
491134 - Submitted ref DIT 1 0001 to Morris asking for an opinion about how
491135 - these design requirement can improve SDS for delivering useful
491136 - intellignece, per Eric's goal stated above. ref SDS 0 5933
491137 -
491138 - [On 000425 received letter from Morris. ref SDS 44 0001
491140 - ..
491141 - On 000422 Joe Williams submitted use case analysis showing main
491142 - content structures for DKR, ref SDS 41 0918, following up report to
491143 - DKR team at SRI on 000420, ref SDS 39 4004, from which Eric noted
491144 - ideas on fundamental information unit and atomic data structures.
491145 - ref SDS 39 1872
491147 - ..
491148 - Joe's work on 000422 was the best effort so far to develop a strategic
491149 - model for a DKR. ref SDS 41 4933 Eric's submission today is the most
491150 - comprehensive effort to create the editor that supports a DKR.
491152 - ..
491153 - However, neither of these efforts moves the DKR project any closer to
491154 - a definition of intelligence, needed to design useful knowledge
491155 - management capability, as recommended on 000120, ref SDS 5 5063, and
491156 - requested by Doug Engelbart on 000307, ref SDS 18 4820, and again on
491157 - 000419. ref SDS 38 4964 On 000328 sent letter to project team
491158 - recommending presentation by cognitive science for foundation to
491159 - prepare work up on KM. ref SDS 23 0001
491160 - ..
491161 - Submitted ref DIT 2 0001 to Eric commending this work. Ask how
491162 - editor improves handling of daily working information, for common
491163 - tasks, cited by Doug on 000327 as objective of knowledge management.
491164 - ref SDS 22 3971 Note that editor capability supports general work for
491165 - "intelligence" rather than specifically improve computer programming,
491166 - which was discussed on 000406 by the team as the first deliverable of
491167 - the DKR team, ref SDS 29 5078, and by Lee Iverson at the meeting on
491168 - 000420 presenting use case support for software development.
491169 - ref SDS 39 4933
491170 -
491171 - [On 000424 received letter from Sandy Klausner. ref SDS 43 0002
491173 - ..
491174 - [On 000424 Eric confirms intial product is softare programming
491175 - program. ref SDS 43 0005
491177 - ..
491178 - [On 000504 Eugene Kim submits good examples of how technology can
491179 - improve specific Knowledge Mangement tasks for handling daily
491180 - working information, which may be another form of "use case"
491181 - analysis. ref SDS 53 0784
491183 - ..
491184 - [...Eugene provides examples of particular uses for an Editor in
491185 - performing KM. ref SDS 53 6205
491187 - ..
491188 - [On 000516 Eugene submits use cases for software programming that
491189 - seem useful for any kind of product development. ref SDS 58 4393
491191 - ..
491192 - Editor requirements have been previously submitted on...
491193 -
491194 - 000406, ref SDS 29 0375
491195 - 000306, ref SDS 17 0782
491196 - 000219, ref SDS 13 4892
491197 - 000130, ref SDS 8 0866
491198 - 000125, ref SDS 6 3867
491200 - ..
491201 - [On 000505 received v0.5. ref SDS 54 0782
491202 -
491203 - ...on each occassion names change, making it hard to follow
491204 - evolution of thinking on the same things. Below there is
491205 - discussion of data structures, ref SDS 0 8855 and data types.
491206 - ref SDS 0 4822
491208 - ..
491209 - Hopefully, before too long, a team and begin to settle on
491210 - consistent names for functionality, and assign codes, so that
491211 - even if the people use different names, the function can be
491212 - uniquely identified for understanding consistent associations.
491214 - ..
491215 - It isn't necessary to be terribly consistent at this ealry
491216 - stage, where creativity is spawning a range of development
491217 - paths. It is helpful though to clarify different development
491218 - paths being formulated, which simply have comment elements.
491219 -
491221 - ..
491222 - Background: Object-Oriented (O-O) Terminology
491223 -
491224 - A "class" is a template to construct an "object".
491225 -
491226 - Class defines behavior of data items
491227 -
491228 - Objects use the behaviors and have specific data values that
491229 - make them (usually unique) "individuals". ref DRT 5 0001
491230 -
491231 -
491232 -
491233 -
491234 -
4913 -
SUBJECTS
Design, Editor (DKR), Text Nodes
Headings Special Text Nodes
Attribution Text Nodes
Author Attribution Text Nodes
Operations, Split, Delete, Replace, Insert
Editing Operations, Split, Insert, Delete, Jack Park, 000131
Text Node Edit Operatrions, Eric Armstrong, 000423
Tuple Supports Extensibility
Atomic Data Structure Secret Knowledge Management
6111 -
611201 - ..
611202 - Headings Summarize Information Unit - Text Nodes
611203 - Paragraph Fundamental Information Unit - Text Nodes
611204 - Text Nodes - Fundamental Information Unit
611205 -
611206 - Follow up ref SDS 39 1872.
611207 -
611208 - Background on prior editor requirements is above. ref SDS 0 6306
611209 -
611210 - The fundamental unit of a DKR is an item of information.
611212 - ..
611213 - Since the ideal in writing is to have "one idea per paragraph",
611214 - an "information node" can be thought of as a paragraph of text.
611215 - Headings stand apart from other text, as well, so a heading is a
611216 - special (short) paragraph, or information node. ref DRT 5 3900
611217 - ..
611218 - On 000223 Eric proposed similar idea of a "label" for
611219 - each para. ref SDS 14 5325
611221 - ..
611222 - Node behaviors are defined in a class (object template).
611223 -
611224 -
611226 - ..
611227 - Data and Sublists Define Content of Text Nodes
611228 -
611229 - Eric lists elements of data structures. ref DRT 5 4030
611230 - ..
611231 - Are "Types" the same as "data strucutres" since they seem
611232 - to have similar elements ref SDS 0 4822 Are they different
611233 - things with common elements?
611234 -
611235 - [On 000505 Eric's specs for CDS list data structures that
611236 - seem to come from this work. ref SDS 54 5002
611237 -
611239 - ..
611240 - Text node contains sublists (or subtrees) for...
611241 -
611242 -
611243 - content
611244 -
611245 - comments, ref SDS 0 0468,
611247 - ..
611248 - evaluations (rating). ref SDS 0 5714
611250 - ..
611251 - author-list, ref SDS 0 2597
611252 -
611253 - People who are authorized to perform direct edits
611255 - ..
611256 - categories to which it belongs. ref SDS 0 0780
611257 - ..
611258 - Implementing categories as lists provides fast
611259 - searching, as demonstrated by the Traction system.
611261 - ..
611262 - substructure list. ref SDS 0 4977
611263 -
611264 - For a heading, for example, the "content" would be the
611265 - text of the heading while the "substructure" would be
611266 - subheadings and paragraphs.
611267 -
611269 - ..
611270 - Data items include a
611271 -
611272 -
611273 - Rating slot (for rated nodes), ref SDS 0 5714,
611274 -
611275 - Version identifier, ref SDS 0 5033
611276 -
611277 - Alternatively, one of the sublists could be a version
611278 - list.
611280 - ..
611281 - Virtual and Actual Node, ref DRT 5 1300, see also
611282 - below on versioning. ref SDS 0 5113
611283 -
611284 - ..
611285 - Reference count
611286 -
611287 - Needed in case nodes wind up with no links at all, so
611288 - they can be removed.
611290 - ..
611291 - Pointer to the previous revision
611292 -
611293 - Needed during editing until node is published.
611294 -
611296 - ..
611297 - Tuple Supports Extensible Data Structures
611298 -
611299 - Eric explains to make the structures extensible, the data
611300 - items may be kept in a tuple, where the nature of the tuple
611301 - depends on the type of the node. (A text node, for example,
611302 - would have a text string and an author identifier.),
611303 - ref DRT 5 1085
611304 -
611306 - ..
611307 - Types Added Dynamically for Question, Alternatives, Arugment
611308 -
611309 - Eric seems to restate in a section for "Types" the elements of
611310 - "atomic" data structure" listed above, ref SDS 0 4299, and calls
611311 - this "Type" and a list of of subtrees. ref DRT 5 0880
611312 -
611313 - He expects it should be possible to add lists dynamically that
611314 - allows a "question" node to have a sublist of "alternatives",
611315 - for example, and for each alternative to have a sublist of
611316 - "arguments" and/or "evaluations". ref DRT 5 0510
611317 - ..
611318 - Is this an extensible issue? ref SDS 0 5033
611320 - ..
611321 - The question is: What is the best way to represent those types?
611322 - They could be kept as a value in the node. (Then the list of
611323 - sublists would contain pairs: type, list.) Another possibility
611324 - is to keep them in a list header for each list. A third
611325 - possibility is to link to them, the same way that a node's
611326 - category sublist entries link to individual categories.
611327 - ref DRT 5 3816
611328 - ..
611329 - Need example to assess requirement and process of type
611330 - issue
611332 - ..
611333 - Node of type "Info" would have multiple sublists, including
611334 - content, structure, etc. A node with one of those types, on the
611335 - other hand, would have only one sublist. So a "Content" node
611336 - would have a single list containing "Text" (zero sublists) or
611337 - "Markup" nodes (one sublist with zero or more entries of type
611338 - Text or Markup). ref DRT 5 2380
611339 -
611340 -
611341 -
6114 -
SUBJECTS
Attribution Linking Traceability Original Sources Alignment Intellige
Attribute Credit Contributions, Link to Original Sources
630401 - ..
630402 - Attribution Assigned to Text Nodes
630403 -
630404 - Every text node must contain an....
630405 -
630406 - attribution -- a pointer to the...
630407 -
630408 - author, or an identifying string
630410 - ..
630411 - On 000125 Editor spec discussed author, ref DRP 1 2860, an
630412 - Administrable General Characteristic. ref SDS 6 4966
630414 - ..
630415 - On 000306 Editor spec on Admin unchanged. ref SDS 17 2773
630416 -
630417 - Attributive section discusses author. ref SDS 17 2079
630418 - ..
630419 - Operational Requirements added section for
630420 - Attribution which seems similar to attribution today.
630421 - ref SDS 17 6536
630423 - ..
630424 - [On 000505 updated editor spec v0.5 unchanged. ref SDS 54
630425 - 2079
630427 - ..
630428 - [On 000505 v0.5 does not attribute sources for ideas
630429 - incorporated into the requirements. ref SDS 54 0375
630431 - ..
630432 - [On 000601 v0.7 applies attribution function. ref SDS 60
630433 - 1462
630435 - ..
630436 - [On 010217 attribution difficult to accomplish due to
630437 - limited time and tools that take much time. ref SDS 64
630438 - FC6L
630439 -
630441 - ..
630442 - Editing Operations on Text Nodes
630443 -
630444 - A copy of that node may be edited, which suggests the need for a
630445 - split operation, for example. After node is split into one or
630446 - more fragments, and edit operation could replace some fragments
630447 - or insert new ones that have a different author.
630449 - ..
630450 - Some of the operations appropriate to a node might therefore
630451 - include...
630452 -
630453 - split,
630454 - delete,
630455 - replace, and
630456 - insert.
630458 - ..
630459 - [On 000131 Jack Park submitted information on XML editor,
630460 - Scholar's Companion (TSC), and explains editing operations.
630461 - ref SDS 9 1224
630462 - ..
630463 - Every node can be the root of a subtree. A node that
630464 - contains text must be capable of pointing to a list of text
630465 - elements. (That list might also include markup elements, like
630466 - HTML bold tags: (b).) Since each item in that list may itself
630467 - point to a list of subitems, the resulting structure is a tree.
630468 - ref DRT 5 2852
630469 - ..
630470 - Need example of node elements and pointers to
630471 - illustrate application and meaning.
630472 -
630473 -
630474 -
630475 -
630476 -
630477 -
6305 -
SUBJECTS
Catagorize
Comments on Text Nodes
6604 -
660501 - ..
660502 - Catagories for Text Nodes
660503 -
660504 - Every node will contain some kind of content (text initially,
660505 - but eventually media objects), the fundamental class should
660506 - allow for a tree-shaped substructure. ref DRT 5 2450
660507 -
660508 - How does this explanation of "catagory" relate to ideas in
660509 - Eric's earlier letter, reviewed above? ref SDS 0 0780
660511 - ..
660512 - Need example of "tree substructure" to show the objective.
660513 - ..
660514 - However, nodes may also acquire other subelements, such as
660515 - comments. So a node needs the ability to serve as the root of
660516 - multiple subtrees. ref DRT 5 0232
660517 - ..
660518 - This might be analogous to an SDS record segment that
660519 - comments on history, implications, objectives and planning of
660520 - information in a formal document.
660522 - ..
660523 - In addition, some categories require special behaviors and data
660524 - structures. For example, if a node is "rated" then it needs the
660525 - ability to acquire a subtree consisting of evaluations
660526 - (ratings). It also needs the ability to "average" the
660527 - evaluations it has received for presentations. ref DRT 5 1632
660528 - ..
660529 - Need example of "rated" node and "evaluations" to
660530 - illustrate application and meaning.
660531 -
660532 -
6606 -
SUBJECTS
Dynamic Behavior Text Nodes
6703 -
670401 - ..
670402 - Rating Text Nodes
670403 - Dynamic Behavior of Text Nodes Rating Issue
670404 -
670405 - Node-categorization (classification) is a dynamic process.
670406 -
670407 - If node is not "rated", then it should not be possible to add
670408 - evaluations to it. If it is "rated", it should be possible to
670409 - add evaluations, and to have the average of those evaluations
670410 - summarized as the node's rating. Once a rating has been added,
670411 - the node can no longer be unrated. But until then, the node
670412 - could be switched at will back and forth from "unrated" to
670413 - "rated". ref DRT 5 5280
670415 - ..
670416 - That dynamic classification poses problems for a static object
670417 - oriented class structure. Unless some language system exists
670418 - that allows behaviors to be added on and taken away in a dynamic
670419 - classification process, the only alternative is to build all of
670420 - the behaviors into the fundamental class -- making the
670421 - identification of an "atomic" data structure all the more
670422 - important. ref DRT 5 3380
670423 - ..
670424 - Need example of dynamic behavior and ratings to
670425 - illustrate meaning and application.
670426 -
670427 -
6705 -
SUBJECTS
Extensible Code Users Customize to Suit Preference
Extensibility
7004 -
700501 - ..
700502 - Extensibility - Create Nodes Using Factory Method
700503 -
700504 - If the behaviors are defined in a single class, then adds to the
700505 - system by extending that class. To put that class into effect, the
700506 - system must be designed to create nodes using a "factory method".
700507 - ref DRT 5 1353
700508 -
700509 - On 000129 Eric explained "extensible" as providing user the
700510 - ability to customize menus and key assignments. ref SDS 7 2064
700512 - ..
700513 - On 000130 Eric sets out customizing facilitates learning.
700514 - ref SDS 8 3828
700516 - ..
700517 - On 000309 Eric submits use case planning showing advantages of
700518 - support for User ability to customize information search.
700519 - ref SDS 19 2958
700521 - ..
700522 - [On 000504 Eugene Kim subits use cases showing benefits of
700523 - extensibility for OHS to customize work environment.
700524 - ref SDS 53 0583
700525 - ..
700526 - To create a new information object, then, you don't merely
700527 - use an existing class to make one. Instead, you ask the factory
700528 - method to create one and hand it back to you. Runtime parameters
700529 - can then configure the "factory" to tell it which class to use.
700530 - So, if the BasicNode class is the standard class for an
700531 - information node, and if you create an ExtendedNode class, then
700532 - the factory would be instructed (via a command line switch or
700533 - configuration file) to use the ExtendedNode class when
700534 - constructing an information object. ref DRT 5 0320
700535 - ..
700536 - Need example of extensibility relative to enabling
700537 - users to customize tools from the record on 000129.
700538 - ref SDS 7 2064
700539 -
700540 -
7006 -
SUBJECTS
Versioning Control
7403 -
740401 - ..
740402 - Versioning Requires Atomic Types for Virtual and Actual Nodes
740403 -
740404 - Node contains a pointer to a previous version of itself. Old links
740405 - acquire the newest version using an indirect link -- a "virtual
740406 - node". ref DRT 5 0868 Data structure must have two atomic types:
740407 -
740408 - 1. virtual node that points to the latest version, and the
740410 - ..
740411 - 2. node itself.
740413 - ..
740414 - Diagramed under "Atomic Structure." ref DRT 5 1300
740416 - ..
740417 - Explained also under Data and Sub-lists, ref DRT 5 0980, also
740418 - discussed above. ref SDS 0 4299
740420 - ..
740421 - Some actions like edits, rearranging sublist items, or deleting
740422 - those items would produce a new version. It should be possible to
740423 - perform multiple operations of that kind without having a separate
740424 - (persistent) version number. When "published", the node would have
740425 - the next sequential version number, regardless of the number of
740426 - changes. (For "undo", however, multiple non-persistent "revisions"
740427 - would be kept, so that changes can be backed out. When published,
740428 - all but the last revision would be removed.), ref DRT 5 2805
740429 -
740430 -
740431 -
740432 -
740433 -
740434 -
740435 -
740436 -
740437 -
740438 -
740439 -
740440 -
740441 -
740442 -
7405 -
SUBJECTS
OHS/DKR Meeting at SRI 000420
7503 -
750401 - ..
750402 - Augment Presentation Planning and Support, Joe and Sue
750403 -
750404 - Follow up ref SDS 39 5922.
750405 -
750406 - Received ref DRT 4 0001 from Eric reporting additional understandings
750407 - from the meeting at SRI on 000420. ref SDS 39 5922
750408 -
750409 - [On 000427 no record of presentation. ref SDS 49 5922
750410 -
750411 -
750412 -
750413 -
750414 -
750415 -
750416 -
750417 -
750418 -
750419 -
750420 -
750421 -
750422 -
750423 -
750424 -