Apply this update to construct version 0.7 of the
requirements document:
1. Change the version number to 0.7
2. Under Version History, add:
0.7 "Categorizable" section expanded,
"Relational" requirement added under "DKR Requirements"
3. In the General Characteristics section, add "Relational"
after "Firewalled"
4. Add the following paragraphs to the "Categorizable" section
==============================================================
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.
===============================================================
5. Add the following after "Firewalled" in the "DKR Requirements"
section
==================================================================
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:
* Logic
--implies
--negates/contradicts
--and/or
[Note: This needs thought. Are these separate relations? Or are
they (possibly optional) attributes of a relation like
"implies".
For example, a design idea might be "implied by" multiple
functional requirements. The fact that a single idea solves
multiple problems makes it an elegant solution. In that sense,
the relation is an "and" of the requirements. But at the same
time, dropping all but one of those requirements would still
imply the design idea. In that sense, the relation would be an
"or". In general, (a*b) => c and (a+b) => c do not imply any
relation between a and b, but only between the a,b, pair (in
some particular configuration) and c. However, even if and/or
are *not* relations in their own right, some mechanism for
specifing such connections may still be useful -- even if it is
only an attribute of a relationship.]
* Mathematics
--equivalent to
--iff (double implication)
--set/subset, union/intersection
[Here again is a situation similar to and/or. Is a set a relation
in its own right, or a collection defined by a many:1, 1:many,
or many:many relation? Should set operations like union and
intersection be expressed as static relations, or are they
dynamic properties of the evolving network of nodes?]
* Abstract Reasoning
--analagous to, similar to, like
--instance of, special case of
--abstraction of, general case of
===================================================================
------------------------------------------------------------------------
fnCentral.com: it's where you are! Be deskbound no more. No apps.
Use the web's first fully integrated personal finance manager
from any PC, Palm, phone, internet appliance! OPEN A FREE ACCOUNT NOW.
http://click.egroups.com/1/4647/4/_/444287/_/959897344/
------------------------------------------------------------------------
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
This archive was generated by hypermail 2b29 : Thu Jun 01 2000 - 15:17:22 PDT