Click here to comment!
1...Does this solve concern on 000420 when Eric reported
2...Would be helpful to see this capability applied for buying
3...Does this supplement or duplicate the section explained in
4...Need example of how the above operation would be performed
5...Need example and estimate of cost savings using Eric's
6...Does this supplement or duplicate the section
CONTACTS
SUBJECTS
Open Source Development Freeware
Open Source Hyper-text Editors
DKR Specification
Attribution Text Nodes
Accountability by Linking
Attribution Credit, Links to Original Sources of Contributions, Sporh
CDS Eric Armstrong
1909 - ..
1910 - Summary/Objective
1911 -
191101 - Follow up ref SDS 61 0000, ref SDS 60 0000.
191102 -
191103 - Eric submits update to the spec he is preparing for OHS/DKR, and asks
191104 - contributors to incorporate into the prior v0.6 to create v0.7.
191105 - ref SDS 0 0782 New material supports what Eric is calling
191106 - catagories, which may be the same or similar to what others are
191107 - calling "ontology," and what is called "organic subject structure" in
191108 - SDS and POIMS. He cites Traction to exemplify desired funtionality.
191109 - ref SDS 0 5933 There is also a section for "Relational' which seems
191110 - like the AI type logic and mathematical operations that Jack has
191111 - discussed. ref SDS 0 4967
191112 -
191113 - [On 000605 received letter from Eric submitting additional
191114 - changes to create v0.8. ref SDS 67 0782
191115 -
191116 -
191117 -
191119 - ..
1912 -
1913 -
1914 - Progress
191501 - ..
191502 - Editor Specification Needs Alignment with Architecture
191503 - CDS v0.7 Requires Alignment to Reduce Boggling the Mind
191504 -
191505 - Follow up ref SDS 61 0782, ref SDS 60 0782.
191506 -
191507 - Received ref DRT 1 0001 transmitting changes to create v0.7 which Eric
191508 - says can be added to v0.6, ref DRP 2 0001, received on 000508,
191509 - ref SDS 61 0782, to update project requirements for a Collaborative
191510 - Document System (CDS), which Eric wants to create as the first step
191511 - for an OHS/DKR capability, per his letter to Jack Park on 000503.
191512 - ref SDS 57 5187
191513 -
191514 - [On 000605 received letter from Eric submitting additional
191515 - changes to create v0.8. ref SDS 67 0782
191517 - ..
191518 - There is no evident discussion of issues cited in the record on
191519 - 000505, ref SDS 60 0001, submitted to the DKR team on 000515,
191520 - reviewing the requirements in depth. ref SDS 63 0001
191522 - ..
191523 - An exception is that this submission makes attribution to Traction,
191524 - ref SDS 0 5933, Jack Park, ref SDS 0 4967, and to SDS, per below,
191525 - ref SDS 0 4997; however, it does not cite the record. Attribution was
191526 - suggested as helpful in the review on 000505, ref SDS 60 0375, based
191527 - on requirements in v0.5 to provide the ability to support this
191528 - feature. ref SDS 60 2079
191530 - ..
191531 - To accomplish Eric's suggestion of adding changes to create v0.7,
191532 - created a copy of his letter, ref DRT 2 0001, that incorporates all of
191533 - his submittal for v0.6, ref DRP 2 0001, and then posted following
191534 - changes...
191536 - ..
191537 - Eric says to...
191538 -
191539 - 1. Change the version number to 0.7. ref DRT 1 0001
191540 -
191541 - Did this. ref DRT 2 0001
191543 - ..
191544 - 2. Under Version History, add: 0.7 "Categorizable" section
191545 - expanded, "Relational" requirement added under "DKR
191546 - Requirements", ref DRT 1 0741
191547 -
191548 - Did this. ref DRT 2 0861
191550 - ..
191551 - 3. In the General Characteristics section, add "Relational" after
191552 - "Firewalled", ref DRT 1 0893
191554 - ..
191555 - Did this. ref DRT 2 5031
191556 -
191557 -
191558 -
191559 -
1916 -
SUBJECTS
Objectives, Catagorize
Design, Requirements, Catagorize
Traction, Journaling, by Twisted Systems, 000326
Catagorization, Search Engines Poor
Data Base Needs Organizing Retrieval Methods
Data Base Organizational Memory Capture Experience Defines Knowledge
340901 - ..
340902 - Traction Exemplifies Catagory Methods for CDS
340903 - Catagories for CDS Modeled after Traction
340904 - Linking Nodes to Catagory Lists Improves Searches
340905 -
340906 - Follow up ref SDS 60 5003.
340907 -
340908 - 4. Add the following paragraphs to the "Categorizable" section,
340909 - ref DRT 1 5083
340910 -
340911 - Did this. ref DRT 2 4951
340913 - ..
340914 - Implements recommendation by Joe Williams on 000508 to add
340915 - categories to specs. ref SDS 61 5972
340916 -
340917 - [On 000605 Eric amends this section. ref SDS 67 5933
340918 -
340919 - [On 000622 team plans to catagorize links. ref SDS 70
340920 - 3808
340921 -
340922 - [On 000623 Jack Park submits ideas for ontology.
340923 - ref SDS 71 9900
340924 -
340925 - [On 000810 considered universal subject management.
340926 - ref SDS 73 0001
340927 -
340928 - [On 000824 Eric reports meeting with Doug Engelbart
340929 - where Doug proposes email translating system into XML
340930 - and HTML, similar to SDS for accessing the record;
340931 - system omits catagories. ref SDS 74 PU5N
340932 -
340933 - [On 001017 Eric will release code soon for OHS that
340934 - supports catagories. ref SDS 75 0001
340935 -
340936 - [On 011003 Eric frustrated information overload
340937 - paralizes productivity; analysis hopeless quagmire;
340938 - wants system to categorize. ref SDS 78 SW9L
340940 - ..
340941 - Eric reports Traction has a clearly thought out and
340942 - well-implemented approach to Categories.
340943 -
340944 - Aligns with report on 000517 that Traction does a good
340945 - job managing catagories. ref SDS 64 1830
340946 -
340947 - • Categories are implemented as lists.
340949 - ..
340950 - • When a category is applied to a node, the node is linked
340951 - to the list, and also becomes a member of it, which The
340952 - fact that nodes are members allows efficient searches.
340954 - ..
340955 - • Categories for a node are displayed in a list (to the
340956 - right of the paragraph, in Traction, in a light blue
340957 - color).
340958 -
340959 - [On 000622 Augment + catagories = OHS. ref SDS 70 6652
340960 -
340961 - [On 000623 report of debate about catagories, documents
340962 - and nodes. ref SDS 71 5040
340963 -
340964 - [On 000718 pre-proposal to NASA does not discuss
340965 - catagories, but offers to organize information.
340966 - ref SDS 72 2166
340968 - ..
340969 - In Traction, categories can also be hierarchical. ref DRT 1
340970 - 1769
340971 -
340972 - Does this solve concern on 000420 when Eric reported
340973 - Traction needs stronger support for hierarchy? ref SDS 50
340974 - 3024
340976 - ..
340977 - Colon-convention separates categories, like logic:assert or
340978 - logic:deny. Categories can also be changed in that system. In
340979 - the demo that Chris Nuzum was kind enough to give Eric,
340980 - evidently to supplement the presentation to the SRI team on
340981 - 000413, ref SDS 49 4209, Chris used the example of "ToDo"
340982 - changing to "Feature:Scheduled" and "Bug:Open".
340984 - ..
340985 - When you invoke the change operation, all of the nodes
340986 - currently marked "ToDo" are listed, and flagged as "subject to
340987 - the change". You can then uncheck any nodes the change does
340988 - not apply to before performing the operation. Then, when you
340989 - change the remaining "ToDo" nodes, the list is all set to
340990 - carry out the change. ref DRT 1 2242
340992 - ..
340993 - Eric does not indicate explicitly addressing comments in
340994 - the record on 000505 concerning related ontology issue
340995 - citing work by Jack Park. ref SDS 60 1044
340996 -
340997 - [On 001017 Eric reports progress on OHS with catagory
340998 - features, but does not mention ontology. ref SDS 75 O94F
341000 - ..
341001 - Would be helpful to see this capability applied for buying
341002 - a computer, getting the car fixed, going to the dentist,
341003 - and sending mission critical information to NASA so the
341004 - rocket ship doesn't crash on Mars, as occurred on 991001.
341005 - ref SDS 4 3077
341006 -
341007 - [On 000622 team plans to catagorize links. ref SDS 70
341008 - 3808
341009 -
341010 - [On 000623 report of debate about catagories, documents
341011 - and nodes. ref SDS 71 5040
341013 - ..
341014 - Does Traction track the amount of time required to apply
341015 - this feature; have they done any studies showing cost
341016 - savings using this feature?
341018 - ..
341019 - In addition to those features, Traction realized that the
341020 - impact of changes could be large, so they included an *audit
341021 - trail* for every change. When a node is recategorized, the
341022 - date, time, and author of the change are recorded. It may also
341023 - be possible to undo such changes, though I'm not sure. But the
341024 - important point is that changes in such a system can generate
341025 - a significant amount of confustion. The audit trail makes it
341026 - possible to see what happened. It would also be helpful to
341027 - identify folks you would rather not have messing around in
341028 - your data base. ref DRT 1 0480
341030 - ..
341031 - Does Traction track the amount of time required to apply
341032 - this feature; have they done any studies showing cost
341033 - savings using this feature?
341034 -
341035 -
341036 -
3411 -
SUBJECTS
Alignment Avoid Meaning Drift
Reasoning Augmented by Technology
AI Has Not Succeeded in Augmenting Daily Work
Relational, AI, Mathematical, Logical Operations
Audit Trail Avoid Meaning Drift
Relational Mathematical Logical Operations AI
Mathamatics of Knowledge
Mathamatics of Knowledge
451101 - ..
451102 - Relational Functions for Logic, Mathematical Operations
451103 -
451104 -
451105 - 5. Add the following after "Firewalled" in the "DKR Requirements"
451106 - section, ref DRT 1 7512
451107 -
451108 - RELATIONAL
451109 -
451110 - Did this. ref DRT 2 8582
451112 - ..
451113 - It must be possible to add *relations* as first-class objects
451114 - in the system, where a "first class" object is one that can be
451115 - observed and manipulated like any other node in the system.
451116 - Such relations will make it possible to link nodes in
451117 - interesting ways, make it possible to add new connections over
451118 - time, and allow for some forms of automated reasoning (or at
451119 - least, " reasoning assistance"). In conjunction with
451120 - categories, the addition of relations is likely to be the most
451121 - important step in converting the system into a true DKR, of
451122 - the kind that Jack Park describes. ref DRT 1 7512
451123 -
451124 - Does this supplement or duplicate the section explained in
451125 - v0.5 for "Use Case Analysis"? ref SDS 60 2166
451127 - ..
451128 - On 000503 Jack feels SDS record may provide a basis for
451129 - mathematics to develop AI operations, as Eric proposes
451130 - today, on historical record. ref SDS 56 6860
451132 - ..
451133 - On 000505 Eric included mathematical operations in the
451134 - specs, along with support for IBIS style discussion.
451136 - ..
451137 - Relations should work like much like categories, with the
451138 - capacity for adding and changing relations, while keeping an
451139 - audit trail of the modifications. However, while categories
451140 - apply to single nodes, relations relate pairs of nodes, at a
451141 - minimum, or possibly multiple nodes at one time. As Dewain
451142 - Delp observed, the repository of information nodes in the
451143 - system is more properly described as a "network", rather than
451144 - a "hierarchy", because a single node may be simultaneously
451145 - part of several document structures. (Even though any one view
451146 - will most probably (and valuably) be hierarchical.) With the
451147 - advent of relations, the system is immediately and obvisouly a
451148 - true network. ref DRT 1 1935
451149 -
451150 - [On 000606 Jack Park submits source that explains ontology
451151 - extends to relational management covered in this spec.
451152 - ref SDS 68 2397
451153 -
451154 - [...table lists types of relations and assessments, which
451155 - is unsupported. ref SDS 68 3564
451157 - ..
451158 - An equivalence relation, for example, could be used to relate
451159 - a new question to an existing thread. The sender of the
451160 - question, now alerted to the equivalence relation, can then
451161 - readily inspect the answers that have been previously been
451162 - given. (There are likely to be several answers in the system.
451163 - By giving high marks to the answer(s) that were found to be
451164 - most helpful, the best answers "float to the top" in an
451165 - organic, evolving FAQ.), ref DRT 1 5394
451166 -
451167 - [On 000622 team plans to catagorize links. ref SDS 70
451168 - 3808
451170 - ..
451171 - Need example of how the above operation would be performed
451172 - in managing daily working information to augment human
451173 - intelligence for making a phone call, sending an email,
451174 - and so on.
451176 - ..
451177 - Another useful relation is "implies". The ability to add
451178 - implications to the system lets the user create connections
451179 - between nodes. The inverse of that relation (implied by)
451180 - allows a user to trace back the rasion d'etre for a given
451181 - node. In a software design network, implications allow
451182 - functional requirements to be linked to each other and to
451183 - design requirements, which can then be linked to
451184 - specifications, and from there to code. If "not" is introduced
451185 - at any stage (as in, "we can't do this) then the proposal
451186 - under attack can be traced back to its roots -- with
451187 - alternatives available at each stage. If the design proposal
451188 - is invalid for example, perhaps one of the design alternatives
451189 - that has been discussed will be usable. Failing that, the
451190 - functional requirement can be reconsidered, etc. ref DRT 1
451191 - 0594
451192 -
451193 -
451194 -
4512 -
SUBJECTS
Armstrong Cites SDS Alignment as Advanced KM Feature
Align Communications to Maintain Shared Meaning from Meetings, Calls
Align Communications, Testing Metrics
Align Meeting Understandings Feedback Metrics, Notes
Alignment Avoid Meaning Drift
Alignment Relational Operations
540901 - ..
540902 - Alignment Can Be Accomplished by Adding Relations
540903 -
540904 - The ability to add relations, per above, ref SDS 0 4967, will
540905 - provide the kind of "alignment" that Rod Welch talks about --
540906 - (see POIMS, ref OF 1 8316 and NWO... ref OF 2 1122) the
540907 - ability to thread document sections together so that, for
540908 - example, a section of a contract can be threaded back to the
540909 - email discussions that prompted it, making it easier to ensure
540910 - that the final contract accurately reflects the desired goals.
540911 - ref DRT 1 4967
540912 -
540913 - [On 000614 v0.9 received, omits pointers to changes
540914 - from v0.8, conflicts with requirement for alignment.
540915 - ref SDS 69 1664
540916 -
540917 - [...OHS specs need alignment with project priorities.
540918 - ref SDS 69 4396
540920 - ..
540921 - This is a constructive effort to use ideas in POIMS
540922 - discussed with Eric and Morris on 000517, moving beyond
540923 - initial concern Eric voiced. ref SDS 64 0825
540924 -
540925 - [On 010913 Eric recongized SDS ability to link related
540926 - events adds value to historical record. ref SDS 76 1U3O
540927 -
540928 - [On 010916 Eric amazed by SDS support for memory with
540929 - mechanisms that obviously work; would like better
540930 - interface. ref SDS 77 0001
540932 - ..
540933 - In another record today Eric noticed SDS support for
540934 - organizational memory on discussions for meetings.
540935 - ref SDS 66 0001
540937 - ..
540938 - Need example and estimate of cost savings using Eric's
540939 - proposal for accomplishing alignment, relative to current
540940 - ability to make connections.
540942 - ..
540943 - Explain, using this record as an example, what additional
540944 - steps are intended to connection information, and estimate
540945 - the amount of time required to accomplish those steps, and
540946 - the time expected to be saved by this additional front end
540947 - investment?
540949 - ..
540950 - At the project meeting sponsored by SRI today, Doug cited
540951 - addressability of email as an important milestone that
540952 - demonstrates a useful feature. ref SDS 65 2760
540953 -
540954 -
540955 -
540956 -
540957 -
5410 -
5411 -
SUBJECTS
Alignment Avoid Meaning Drift
Reasoning Augmented by Technology
AI Has Not Succeeded in Augmenting Daily Work
Relational, AI, Mathematical, Logical Operations
Audit Trail Avoid Meaning Drift
Relational Mathematical Logical Operations AI
Mathamatics of Knowledge
Mathamatics of Knowledge
651101 - ..
651102 - System Provides Initial Set of Relations
651103 -
651104 - Although users can add relations at will, it makes sense for
651105 - the system to come with a "starter set" of standard relations
651106 - that everyone uses by convention. That initial set can come
651107 - from the fields of logic, mathematics, and abstract
651108 - reasoning:, ref DRT 1 4851
651109 -
651110 - Good point, this is also a good strategy for catagories,
651111 - per above. ref SDS 0 5933
651113 - ..
651114 - • Logic
651115 -
651116 - implies
651117 -
651118 - negates/contradicts
651119 -
651120 - and/or
651122 - ..
651123 - Note: This needs thought. Are these separate
651124 - relations? Or are they (possibly optional) attributes
651125 - of a relation like "implies". For example, a design
651126 - idea might be "implied by" multiple functional
651127 - requirements. The fact that a single idea solves
651128 - multiple problems makes it an elegant solution. In
651129 - that sense, the relation is an "and" of the
651130 - requirements. But at the same time, dropping all but
651131 - one of those requirements would still imply the design
651132 - idea. In that sense, the relation would be an "or". In
651133 - general, (a*b) => c and (a+b) => c do not imply any
651134 - relation between a and b, but only between the a,b,
651135 - pair (in some particular configuration) and c.
651136 - However, even if and/or are *not* relations in their
651137 - own right, some mechanism for specifing such
651138 - connections may still be useful -- even if it is only
651139 - an attribute of a relationship. ref DRT 1 2976
651141 - ..
651142 - • Mathematics
651143 -
651144 - equivalent to
651145 -
651146 - iff (double implication)
651147 -
651148 - set/subset, union/intersection
651150 - ..
651151 - On 000505 Eric included mathematical operations in
651152 - the specs, along with support for IBIS style
651153 - discussion.
651155 - ..
651156 - Does this supplement or duplicate the section
651157 - explained in v0.5, per above? ref SDS 0 0621
651159 - ..
651160 - Here again is a situation similar to and/or. Is a set a
651161 - relation in its own right, or a collection defined by a
651162 - many:1, 1:many, or many:many relation? Should set
651163 - operations like union and intersection be expressed as
651164 - static relations, or are they dynamic properties of the
651165 - evolving network of nodes?
651167 - ..
651168 - • Abstract Reasoning
651169 -
651170 - analagous to, similar to, like
651171 -
651172 - instance of, special case of
651173 -
651174 - abstraction of, general case of
651175 -
651176 -
651177 -
651178 -
651179 -
651180 -
651181 -
651182 -
651183 -
651184 -