From: Eric Armstrong <eric.armstrong@eng.sun.com>
Dick Karpinski provided:
Many important ideas, most of which have responses below.
But one in particular made me sit bolt upright:
> Horst Rittel, the late UCB Architecture Prof,invented IBIS, .` the
Issue Based Information System. He had to implement an entire hypertext
system to support labeled links.
YES! HTML's signal weakness is the inability to type links,
so they can be treated differently and indentified when
read. That is a prime requirement for a DKR.
> From: Dick Karpinski <dick@cfcl.com>
>
> > Superfluous
> > ... able to remove superfluous information from a knowledge
> repository.
>
> You only have to be able to suppress it with a viewing option setting.
> Which is superfluous may differ from reader to reader. That's OK, we
> now have the means to customize for each reader, once we figure out
> just what we want.
It's a tricky problem, really. If there are different feelings about
what is superfluous, everyone has to mark their own copy. As the system
grows, that becomes more impractical. In general, the reduction and
abstraction mechanisms below will probably serve to adequately "digest
out" superfluous information. This design idea, then, can be marked
"superfluous" (i.e. not carried forward into a digest) in the DKR. :_)
> > Redundant
> > but a single information-model underlies them all.
>
> Boy, you'd have to convince me. I see a plethora of models. That's OK,
> ...
I think you're right. That observation drives us towards the model I
proposed in the "Towards a DKR" message, where many possible models can
be offered.
Interestingly, it should also be possible to refine an existing model.
The refined version and the original both need to remain available.
> > Non-Reductive
> > ... -- they should be tucked "under" the reduction, so
> > as to simplify the view presented by the archives.
>
> You can have it your way, and I can have it mine, from the same DKR.
Agreed.
> > Abstractable
> > difference is that the specific items don't disappear from the
> view,
>
> Why bother to be different? You can have it...
Yes. This makes sense. Having supporting information "under" the
digest/abstract/reduction (with a typed link) makes it available and
yet hidden from view unless accessed.
> > Negatable
> > ... by marking a theory or fact as invalid,
>
> There may be differences of opinion. We need not lose them. Again,
> ones viewing parameters might select for those facts agreed to by some
> particular editor, society, or metric, leaving the rest unseen.
Possibly. But the concept of "selection criteria" falls prey to the need
to mark things. It then requires a second system to handle differences
of opinion about
the markings. It probably makes more sense to use the same mechanisms
for everything. Perhaps negations could fall "under" a entry in the DKR.
Perhaps
all negations would be available at a high level under a "Dissenting
Opinions" category, Supreme Court style. Actual negation would take
place by way of
digesting. For example, creating by a "discredited theories" category
and tucking the original entry under it, along with any others.
> > and attaching the data to support that conclusion.
>
> Oh yes. Architects of buildings, in particular, recognize the need to
> remember in the log what decision was made and why. That's why it's
> not so very surprising that Horst Rittel, the late UCB Architecture
> Prof, invented IBIS, the Issue Based Information System. He had to
> implement an entire hypertext system to support labeled links. IBIS
> starts with a topic and then has links to issues, which have links to
> positions on those issues, which have links to arguments on those
> positions. Now IBIS can be expressed as a small set of guidelines for
> linking web pages.
We really need to look at this.
> > ... It must be possible to hide negated precepts so we can focus
>
> Viewing parameters ....
I think the digest/abstraction/reduction mechanism makes more sense,
but I agree the originals remain available.
> >Knowledge Mathematics
> >... to model the human nutrition >system requires the
> >ability to state relationships lik these: improves,
> >requires, enables, is required for, is enabled by,
> >causes, hinders, prevents, manifests as, etc.
>
> That sounds a lot like a hypertext system to me. Just like IBIS, you
> want links that have labels. No longer is this hard. Don't you come to
> a sort of relational database when you wish to extract information
> from a large
> collection of these related items?
Actually, the modeling problem is more complex than a hypertext system
can handle, imo. Arguments and propositions *about* the model can be
handled in a hypertext system, but the models themselves are a
time-dependent creatures that have multiple inputs, outputs, components,
interconnections, and feedback loops. In each time interval, the
accumulated result of all inputs and connections produces outputs which
are all but entirely unpredictable to the human mind. The modeling
system should be a "runnable" entity. In essence, a program.
> >... since it is unlikely that everything which needs to be expressed
> >could possibly be anticipated.
>
> We have done pretty well with 26 letters and a few odd marks. You're
> not
> constraining the content much by saying you want it in web pages or in
> a
> relational database, even if you add lots of guidelines.
>
> >... One
> >advantage of such a system would be the relative ease with which
> people
> >who speak different languages could interact with it.
>
> That would be nice but it's less than obvious to me that this posited
> system would have any particular properties.
>
> > ... In a natural language system, on the other
> > hand, such operations must necessarily be manual -- which raises
> the
> > the necessity for competing reductions and abstractions, with
> arguments
> > for and against tallied with each, until at last some resolution
> is
> > achieved.
>
> That would be TRUE KNOWLEDGE, but we imperfect creatures can only hope
> to
> make some sense of our current understandings, incomplete and
> tentative
> as they must forever be.
>
> > ... Most political
> > discussions therefore resolve around spurious logic and
> disfunctional
> > rhetoric. A true "knowledge repository" needs something better,
> however.
>
> This suggests to me that our political system needs attention, perhaps
> starting with campaign finance reform.
Agreed. I need to repost a message I sent to the bootstrap org after the
first colloquium -- Identifying the Critical Problems. The highest on
the list, to my
mind (although third in the presentation sequence) is a need for
"Separation of
Business and State"
> > The system should make model-building easier by providing
> something in
> > the nature of a "Model Construction Kit".
>
> You bet!
>
> > Like the EOE system, "attribution" is liable to be the most
> > profound motivator for contributions to the knowledge repository.
>
> > That makes autmomatic, accurate attribution a vital part of the
> > system.
>
> Agreed.
>
> > Feedback
> > The best argument for or against a given model will be based on
> real
> > world feedback.
>
> Just so.
>
> > Design Decisions
>
> I consult with "Principles of Software Engineering Management" by Tom
> Gilb
> for designing both the desired system and its method of construction.
> He
> has three profound things to say there:
> - Specify the goals of the effort so clearly that numerical targets
> and
> minimums can be established, along with specific tests to measure
> them.
> - Use document inspection to validate progress from the general to
> the
> specific so as to ensure adherance to the intentions of the
> project.
> - Deliver an improved working system every two to five percent of the
>
> project resources. Thus failures are small enough to be discarded.
>
> > ... recorded in a design journal, along with the reasoning.
>
> Try IBIS.
Love to. Great suggestion.
How does one find it?
META NOTES:
* This dialogue is essentially one that would ideally be taking place
in
the context of a DKR. Out of the last several messages, we have
begun to identify important requirements, eliminate superfluous
ones,
and move towards a general design. We need a digest of what we've
adduced to date!
* One major issue with email and even hypertext discussions like
this
is the inability to break up the original message into pieces. In
this
messsage we have a variety of thoughts, reactions to them, and
responses to the reaction. Each would ideally exist in its own
hierarchy. The system would then allow:
a) Creating a new digest for each point which "replaces"
(exists
at a higher level) than all of the items that preceded
it.
b) Creating a new proposal that collected the important
points,
left out the superfluous ones, and earmarked the points
that
were still being debated (for example, using an "open
issues"
category)
--------------------------- ONElist Sponsor ----------------------------
Independent contractors: Find your next project gig through JobSwarm!
You can even make money by referring friends.
<a href=" http://clickme.onelist.com/ad/jobswarm2 ">Click Here</a>
------------------------------------------------------------------------
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 2.0.0 : Tue Aug 21 2001 - 18:56:37 PDT