CONTACTS 

SUBJECTS
Property Rights in Knowledge Organization
Commercial Viability
Ownership Investment Risk
Open Source Development Freeware
Time for DKR Limited, 000423
Participation Rights of Contributors
Agreement Developed Shared Meaning, Vision
Decisons on Differences in Design and PM
Business Venture Failed, 000510
Binary Forces Permeate Human Endeavors, Cause Stress, Conflict
Competition, Cooperation, Innate Conflict to Integrated Tools
Proposal on License

1914 -    ..
1915 - Summary/Objective
1916 -
191601 - Follow up ref SDS 15 0000, ref SDS 14 0000.
191602 -
191603 - Paul submits ideas for using the DKR project to exchange ideas, with
191604 - the understanding that Stanford and BI can use work product, along
191605 - with contributors to develop useful instruments owned by each.
191606 -
191607 - Sent ref DIT 1 0001 commending Paul's leadership proposing plan for
191608 - DKR team to remain intact, per below. ref SDS 0 0784
191609 -
191610 -      [On 000516 Paul Fernhout responds. ref SDS 16 0001
191611 -
191612 -      [On 000608 Eugene Kim proposes that the team commit to a license
191613 -      by 000706. ref SDS 18 6150
191614 -
191615 -
1917 -
1918 -
1919 - Progress
1920 -
192001 -  ..
192002 - Binary Forces Need Flixible Arrangements of Competion and Cooperation
192003 - Open Source Projects Need Revenue to Produce Useful Innovations
192004 -
192005 - Follow up ref SDS 15 0784, ref SDS 14 0784.
192006 -
192007 - Received ref DRT 1 0001 from Paul Fernhout providing constructive
192008 - suggestions on moving ahead with the DKR project without complete
192009 - agreement on an Open Source methodology.
192010 -
192011 -        [On 000531 Paul proposes license and open source model as
192012 -        agenda issue for project meetings. ref SDS 17 0583
192013 -
192014 - He offers a "fallback" plan...
192015 -
192016 -  ..
192017 -
192018 -     Drop the notion of BI/Colloquium developing any open source code
192019 -     -- since Stanford with its tradition for education for dollars and
192020 -     BI as a for-profit company are having trouble making the
192021 -     transition to open content and open source -- despite the best
192022 -     intentions. The continuance of the one-sided "permission to use"
192023 -     agreement shows this, since practically no cautious/experienced
192024 -     developer would release open source code under. No point in
192025 -     fighting that.  People who want to build proprietary stuff to sell
192026 -     on top of an open source base (SRI etc.) can make whatever deals
192027 -     they want with BI/Stanford or others. ref DRT 1 0765
192028 -
192029 -        Paul's frustration about tension between open source and need
192030 -        for revenue, reflects binary forces of competition and
192031 -        cooperation that POIMS seeks to balance, cited in letter to DKR
192032 -        contributors. ref DIT 1 0001
192033 -
192034 -  ..
192035 -
192036 -     Keep using this list as a place for individuals to point out to
192037 -     other individuals open source ideas and efforts related to OHS/DKR
192038 -     issues. Use it to provide pointers to their own open source code
192039 -     and new releases. This has been happening already to an extent,
192040 -     especially with all the wonderful pointers to various projects
192041 -     which I have enjoyed immensely. ref DRT 1 1829
192042 -
192043 -     Then let those projects be discused here, with code discussions
192044 -     handled privately via private emails or lists unrelated to the
192045 -     Colloquium (avoiding implicit "permission to use" for any code
192046 -     fragment), and with code improvement acceptance handled by
192047 -     individuals under their own terms. ref DRT 1 3773
192048 -
192049 -
192050 -
192051 -      ..
192052 -     Stanford May Make Claim to Work Product of Contributors
192053 -
192054 -     Individuals who have particiapted in the colloquium would have to
192055 -     make it clear that their own coding efforts were not an "extended
192056 -     activity of the colloquium" even if they were discussed on the
192057 -     list. Perhaps they would also need to start a legal defense fund
192058 -     for when Stanford (or BI) starts knocking on doors of anyone who
192059 -     has posted to this list, facing lawyers toting around a copy of
192060 -     "permission to use" asking for their salary and claiming
192061 -     warranty/indemnification protection for their clients use or
192062 -     sublicensing of such individuals code. :-(, ref DRT 1 0736
192063 -
192064 -     Code to become part of the Colloquium would then have to be
192065 -     explicity granted, by an individual signing a document something
192066 -     like: "I agree to submit this code under the 'Permission to Use'
192067 -     unlimited indemnification license -- something which I would never
192068 -     do.
192069 -
192070 -
192071 -  ..
192072 -
192073 -     This list then becomes a "meta"-NIC for discussing open source
192074 -     efforts related to the OHS/DKR concept (which in practice is what
192075 -     it is now, just not officially).
192076 -
192077 -     Over time, out of that, there very likely may arise some
192078 -     meaningful new or enhanced projects "owned" by their originators
192079 -     and contributors (and in no way by BI or Stanford). These might
192080 -     then grow to be something impressive. ref DRT 1 2622
192081 -
192082 -     If at some time BI or Stanford will then agree to allow some or
192083 -     all of the content of the list or videos to become part of any
192084 -     such a project under some terms acceptable to both, then so be it.
192085 -
192086 -     This is what will happen anyway unless/until BI or Stanford
192087 -     addresses the license issue. It may happen even then, given the
192088 -     social dynamics of open source programming. Creative people may
192089 -     have many things to contribute that may not yet be in "the spec".
192090 -     Implementing someone else's detailed spec is usually (but not
192091 -     always) done for pay not joy. The only times it is done for joy
192092 -     are usually when the coder is getting a lot out of a mentoring
192093 -     relationship or some other indirect benefit.
192094 -
192095 -     If all this happened (as it is happening now), I would still think
192096 -     Stanford & BI would have made a great contribution to an open
192097 -     source OHS/DKR by creating this forum -- even if they have not
192098 -     contributed a line of code under an open source license or a
192099 -     single email under an open content license.
192100 -
192101 - ..
192102 - Sent ref DIT 1 0001 commending Paul's leadership proposing plan
192103 - for DKR team to remain intact.  Cited need to explain KM with simple,
192104 - "elevator version," per Eric's suggestion on 000423. ref SDS 6 5096
192105 - Linked to Eric's explanation on 000503 that KM is difficult to define.
192106 - ref SDS 8 5033  Mentioned Paul's comments on 000405 that AI has
192107 - developed data structures for knowledge representation. ref SDS 5 0005
192108 - Cite Jack Park's notice that ontologies are hard to figure out.
192109 - ref SDS 4 7455
192110 -
192111 -      [On 000516 Paul Fernhout responds. ref SDS 16 0001
192112 -
192113 -      [On 000608 Eugene Kim proposes that the team commit to a license
192114 -      by 000706. ref SDS 18 6150
192115 -
192116 -
192117 -
1922 -

SUBJECTS
Augment Intelligence, Purpose DKR
Intelligence Augment Thinking with Computers
Augment Intelligence SDS Core Engine of Knowledge for DKR
Core Enterprise Knowledge Management Chronology SDS Intelligence
Open Source Enabled SDS Core Engine Knowledge Management
Development Path SDS Core Engine KM Augment Intelligence
KM Next Wave, Market Needs New Killer Application
Grove Technology Forecasts

2711 -
271101 -  ..
271102 - Augment Human Intelligence Big Issue
271103 -
271104 - Explain big issue is whether anything can be done to augment human
271105 - intelligence, ref DIT 1 4032, and if so, that needs to be developed
271106 - somehow, someway in order to provide a new path for civilization,
271107 - similar to the advance wrought by the alphabet, reviewed on 991108.
271108 - ref SDS 3 5628
271109 -
271110 - Once that path is formulated, then open source and other methods can
271111 - flourish, per discussion with Jack Park on 000503. ref SDS 7 6903
271112 -
271113 -     [On 020321 Kanisa has developed an "automated expert" and a
271114 -     "virtual knowledge network" to help people with technical support
271115 -     that saves money on call centers. ref SDS 23 V79I
271116 -
271117 -
271118 -  ..
271119 - Grove Next Wave Impelmenting Current Developments
271120 - Next Wave Technology Knowledge Management
271121 -
271122 - Andy Grove was interviewed by Charlie Rose the other day, and was
271123 - asked what is the next wave of technology, which is a way of asking
271124 - for the next "killer app"?
271125 -
271126 - Andy paused for a bit, and then offered up that "implementing what we
271127 - already have", or words to that effect. ref DIT 1 6298
271128 -
271129 -     [On 001207 too many people having too many problems using current
271130 -     technology of wordprocessing, spreadsheets, email, Internet,
271131 -     indicates a "killer app" is needed that improves productivity.
271132 -     ref SDS 19 V54M
271133 -
271134 -     [On 010223 Intel says there has never been a "killer app" for
271135 -     computers, cannot predict what customers want. ref SDS 20 FM6J
271136 -
271137 -     [On 010510 Steve Balmer with Microsoft says XML will be next
271138 -     "Killer App" in 5 years. ref SDS 21 8Y8H
271139 -
271140 -     [On 010622 alphabet technology makes people superhuman, the
271141 -     "killer app" of the ages. ref SDS 22 N668
271142 -
271143 - This conflicts with Larry Ellison's comments at the event in Paris
271144 - where he appeared with Bill Gates, and charged that the industry needs
271145 - a new compelling application beyond wordprocessing and spreadsheets,
271146 - ref SDS 2 3967, discussed previously at Intel on 950927. ref SDS 1
271147 - 8226
271148 -
271149 - Andy did not have the vision to see a new wave forming on the horizon
271150 - that not only will implement, but in fact extend existing capabilities
271151 - by an order of magnitude.
271152 -
271153 - A big task for the open source community is to help Andy and others
271154 - who know where to the get money needed for doing the work, that KM is
271155 - a good description to frame the future. Andy was right not to cite KM
271156 - because we have not yet given him the words to explain it, what Eric
271157 - calls the "elevator" version that works good on television.
271158 -
271159 -     [On 000615 DKR team at SRI gave up on KM.
271160 -
271161 -
271162 -
271163 -
271164 -
271165 -
271166 -
271167 -
271168 -
271169 -
271170 -
2712 -