Date: Thu, 01 Jun 2000 15:09:49 -0700
From: | Eric Armstrong |
eric.armstrong@eng.sun.com Reply-To: unrev-II@egroups.com |
To: | unrev2 unrev-II@egroups.com |
Subject: | Requirements 0.7 (chgs only) |
Apply this update to construct version 0.7 of the requirements document:
The Traction system probably presents that most clearly-thought out and well-implemented approach to Categories. In that system, categories are implemented as lists. When a category is applied to a node, the node acquires a link to the list, and also becomes a member of it. The fact that nodes are members of category lists allows efficient searches. The fact that each node links to the categories it belongs to allows all of the nodes categories to be displayed in a list (to the right of the paragraph, in Traction, in a light blue color).
In Traction, categories can also be hierarchical.
The colon- convention is used to separate categories, as in "logic:assert" or "logic:deny". Categories can also be changed in that system. In the demo that Chris Nuzum was kind enough to give me, he used the example of "ToDo" changing to "Feature:Scheduled" and "Bug:Open". When you invoke the change operation, all of the nodes currently marked "ToDo" are listed, and flagged as "subject to the change". You can then uncheck any nodes the change does not apply to before performing the operation. Then, when you change the remaining "ToDo" nodes, the list is all set to carry out the change.
In addition to those features, Traction realized that the impact of changes could be large, so they included an *audit trail* for every change. When a node is recategorized, the date, time, and author of the change are recorded. It may also be possible to undo such changes, though I'm not sure. But the important point is that changes in such a system can generate a significant amount of confustion. The audit trail makes it possible to see what happened. It would also be helpful to identify folks you would rather not have messing around in your data base.
RELATIONAL
It must be possible to add *relations* as first-class objects in the system, where a "first class" object is one that can be observed and manipulated like any other node in the system. Such relations will make it possible to link nodes in interesting ways, make it possible to add new connections over time, and allow for some forms of automated reasoning (or at least, " reasoning assistance"). In conjunction with categories, the addition of relations is likely to be the most important step in converting the system into a true DKR, of the kind that Jack Park describes.
Relations should work like much like categories, with the capacity for adding and changing relations, while keeping an audit trail of the modifications. However, while categories apply to single nodes, relations relate pairs of nodes, at a minimum, or possibly multiple nodes at one time. As Dewain Delp observed, the repository of information nodes in the system is more properly described as a "network", rather than a "hierarchy", because a single node may be simultaneously part of several document structures. (Even though any one view will most probably (and valuably) be hierarchical.) With the advent of relations, the system is immediately and obvisouly a true network.
An equivalence relation, for example, could be used to relate a new question to an existing thread. The sender of the question, now alerted to the equivalence relation, can then readily inspect the answers that have been previously been given. (There are likely to be several answers in the system. By giving high marks to the answer(s) that were found to be most helpful, the best answers "float to the top" in an organic, evolving FAQ.)
Another useful relation is "implies". The ability to add implications to the system lets the user create connections between nodes. The inverse of that relation (implied by) allows a user to trace back the rasion d'etre for a given node. In a software design network, implications allow functional requirements to be linked to each other and to design requirements, which can then be linked to specifications, and from there to code. If "not" is introduced at any stage (as in, "we can't do this) then the proposal under attack can be traced back to its roots -- with alternatives available at each stage. If the design proposal is invalid for example, perhaps one of the design alternatives that has been discussed will be usable. Failing that, the functional requirement can be reconsidered, etc.
The ability to add relations will provide the kind of "alignment" that Rod Welch talks about -- the ability to thread document sections together so that, for example, a section of a contract can be threaded back to the email discussions that prompted it, making it easier to ensure that the final contract accurately reflects the desired goals.
Although users can add relations at will, it makes sense for the system to come with a "starter set" of standard relations that everyone uses by convention. That initial set can come from the fields of logic, mathematics, and abstract reasoning:
negates/contradicts
equivalent to
iff (double implication)
set/subset, union/intersection
analagous to, similar to, like
abstraction of, general case of
Eric Armstrong
eric.armstrong@eng.sun.com