Eric Armstrong wrote:
> Jack Park wrote:
> >
> > Damn good post, Eric.
> >
> Thank you, sir.
>
> > From: Eric Armstrong <eric.armstrong@eng.sun.com>
> > > --If, however, these issues (essentially interface issues)
> > > can be resolved, then a hierarchy can conceivably
> > > introduce a very *nice* mechanism for convergence, by
> > > *inverting* the hierarchy when the occasion demands it.
> > >
> >
> > Of course, the notion of *inverting* a hierarchy will need much more
>
> > elaboration, complete, IMHO, with examples.
> >
> Yeah. That's the part I still have a lot of trouble with. How
> does it work, exactly? When is it applicable? There is a vague
> glimmer of intuition there, but the details are still very
> hazy. When you add a comment that attaches to several nodes (notes),
> there are at least three reasonable "locations::
> * above (supercede with a summary)
> * below (tie together with an observation)
> * orthogonal (a parallel track)
>
> > > * I suspect we should be basing our initial efforts around
> > > the analysis presented in this paper -- if not its
> > > proposed solution. If email is just a way to put information
> > > in the system, let's dispense with the concept of capuring
> > > email messages and go here, instead.
> > >
> > Isn't this somewhat akin to turning the Titanic?
> >
> I suspect it may be. The question is, are we focused on problem,
> and designing the best means for solving that problem, or are
> we focused on an architecture?
As a case in point, I think we too need to improve on "directly
addressing the problem of divergence and the Tunnel Vison Effect" when
collaborating on the OHS/DKR project.
For instance, on 6/7/00, I submitted to [unrev-II] a proposal for
"Bootstrapping Knowledge Representations" based on a reference to an
outstanding paper from our colleagues at the Principia Cybernetica
Project that eloquently summarizes and synthesizes these important ideas
now under discussion and wrote:
So the next-step is a CoDIAK co-evolution of the THOUGHTSTICKER program
originally developed by the late Gordon Pask.
(http://www.c3.lanl.gov/~rocha/pask.html). Francis Heylighen
(http://pespmc1.vub.ac.be/HEYL.html) suggests in his paper
"Bootstrapping knowledge representations: from entailment meshes via
semantic nets to learning webs" (1997).
http://pespmc1.vub.ac.be/Papers/BootstrappingPask.html:
"Such an implementation at the planetary scale was probably not
envisaged by Gordon Pask. Yet, his conversational systems and the
present vision of an intelligent web share their view of knowledge as a
collective construction striving to achieve coherence, rather than a
mapping of external objects. By abandoning the correspondence
epistemology and its reliance on fixed primitives, bootstrapping
approaches open the way to a truly flexible, adaptive and creative
knowledge system. Of course, the systems sketched here are still in
their infancy, and need to be thoroughly tested under diverse
circumstances, and implemented on a sufficiently large scale to show
their practical usefulness. This will obviously require a very large
effort. I hope that the
work of Gordon Pask, myself and our colleagues will provide sufficient
inspiration for other researchers to take up these challenges."
So, relative to the questions and discussions below, I'm going to
provide important excerpts from the paper about solutions we need to
consider (please refer to the referenced link above to read the whole
paper, especially if illustrations for figures don't display below):
"To describe my own solution to the problem, however, I prefer the
metaphor of bootstrapping. As said, the problem with correspondence
epistemologies is that they lack grounding: everything is built on top
of the symbols, which constitute the atoms of meaning; yet, the symbols
themselves are not supported. The advantage of a coherence epistemology
is that there is no need for a fixed ground or foundation on which to
build models: coherence is a two-way relation. In other words, coherent
concepts support each other. The dynamic equivalent of this mutual
support relation may be called "bootstrapping": Model A can be used to
help construct model B, while B is used to help construct A. It is as if
I am pulling myself up by my own bootstraps: while my arms (A) pull up
my boots (B), my boots at the same time--through my legs, back and
shoulders--push up my arms. The net effect is that more (complexity,
meaning, quality, ...) is produced out of less. This is the hallmark of
self-organization: the creation of structure without need for external
intervention.
I will now show how this bootstrapping philosophy can be applied to the
practical problem of knowledge representation, first by reviewing Pask's
entailment meshes, then by extending the underlying formalism to my own
entailment nets.
3. ENTAILMENT MESHES and the THOUGHTSTICKER program
http://pespmc1.vub.ac.be/Papers/BootstrappingPask.html#Heading4
4. BOOTSTRAPPING IN GRAPHS
http://pespmc1.vub.ac.be/Papers/BootstrappingPask.html#Heading5
4.1. ENTAILMENT MESHES AS NON-DIRECTED GRAPHS
http://pespmc1.vub.ac.be/Papers/BootstrappingPask.html#Heading6
4.2 ENTAILMENT NETS AND THE BOOTSTRAPPING AXIOM
http://pespmc1.vub.ac.be/Papers/BootstrappingPask.html#Heading7
4.3. NODE INTEGRATION
http://pespmc1.vub.ac.be/Papers/BootstrappingPask.html#Heading8
5. BOOTSRAPPING SEMANTIC NETWORKS
http://pespmc1.vub.ac.be/Papers/BootstrappingPask.html#Heading9
5.1. ONTOLOGICAL DISTINCTIONS AS BASIC NODE TYPES
http://pespmc1.vub.ac.be/Papers/BootstrappingPask.html#Heading10
5.2. BASIC LINK TYPES
http://pespmc1.vub.ac.be/Papers/BootstrappingPask.html#Heading11
5.3. FRAMES AND INHERITANCE
http://pespmc1.vub.ac.be/Papers/BootstrappingPask.html#Heading12
6. Learning Webs
http://pespmc1.vub.ac.be/Papers/BootstrappingPask.html#Heading13
6.1. ASSOCIATIVE NETWORKS
http://pespmc1.vub.ac.be/Papers/BootstrappingPask.html#Heading14
6.2. ALGORITHMS FOR LEARNING HYPERTEXTS
http://pespmc1.vub.ac.be/Papers/BootstrappingPask.html#Heading15
6.3. EXPERIMENTAL RESULTS
http://pespmc1.vub.ac.be/Papers/BootstrappingPask.html#Heading16
7. Towards an Intelligent Web
http://pespmc1.vub.ac.be/Papers/BootstrappingPask.html#Heading17
>
>
> > > * "How a next-generation computer confercing system be
> > > designed? One appoach is to reconceptualize CC from a
> > > knowledge-centered, rather than conversation-based
> > > perspective."
> > > --I know Jack liked that. I find it scary, but interesting.
> > > Unfortunately, I wasn't able to intuit from the rest of
> > > the paper exactly what that meant in practice.
> > >
> > Yup.
> >
> I knew you would like it. :_)
> But can you tell me what he means by "reconceptualize CC from a
> knowledge-centered...perspective"?
>
> > > * Each note includes a list of "Notes that refer to this note"
> > > --ie. backlinks. Doug will like that.
> > >
> > Open question: are these links put in by the author while creating
> the post?
> > or are they added later, which implies the next question: do we add
> stuff to
> > a post after receipt, or do we do all referencing *above* the post
> space
> > (ala Topic Maps)?
> >
> I know they're added later. But I'm unclear on the two design options
> you describe.
>
> > > --I tend to distrust that they will do the job as
> > > intended, without becoming overly. I'm still inclined
> > > to pursue the concept of "superceding" nodes in the
> > > hierarchy.
> >
> > Overly what?
> >
> overly complex.
> The big weakness with graphical systems is that they represent
> small amounts of complexity well, but really don't do a good
> job with a lot of complexity. I recall a tool that showed
> class-library connections, I think it was. Small libaries --
> fine. Great stuff. With very large libraries, though, you
> would see miles and miles of lines, with the destinations
> nowhere in sight. Moving the browser around, you might even
> see a screen full of lines going in all directions, with
> no nodes anywhere. Or when centered on a node, you might
> see so many lines radiating from it that it was impossible
> to isolate one -- assuming you could tell which one was going
> somewhere interesting. Lattices of connections in a conceptual
> map are interesting, but there needs to be some way of
> limiting the displayed network to nodes that are somehow
> "germane", rather than all possible connections. Which
> introduces the problem of defining *that* concept.
>
> > I love to stand back 10 feet or more from a huge graph and try to
> see the
> > patterns or clusters in all the *dots*. I am also in favor of the
> notion of
> > *drilling down*, in which key topics are first exposed. Double-click
> any
> > node and you get a new plane with more detail surrounding that node.
>
> > Double-click again...
> >
> This is the usual mechanism for displaying nested graphic hierarchies.
>
> That mechanism is forced on us by limited screen real estate. But
> if we had a screen the size of a whiteboard -- or a wall -- and the
> text size automatically adjusted itself depending on the amount of
> information to display, then expanding a node *without* drilling down
> is a better option, imo.
>
> In the sort of view, the outer circle remains -- and possibly grows,
> while it's contents remain within it. The lines going to the node
> remain, but become bigger, fatter "pipes" that break off into
> thinner lines when the reach the node wall. The inner lines then go
> to the subnodes they connect to.
>
> That sort of expand/collapse capability is the same kind of thing you
> see in a directory tree, where you expand/collapse a directory. The
> "drill down" proposal is equivalent to visiting the directory and
> showing its contents without any of the surrounding context.
> (Sometimes
> that's useful. But more frequently it's helpful to keep as much of the
>
> big picture around as you can. For one thing, it makes easy to move
> subnodes to a new location.
>
> > Text nodes can generally be transformed into a named topic,
> assuming, of
> > course, that the text node does, indeed, represent a
> well-constructed
> > thought.
> >
> Granted. And if the number of named topics is small, that might be
> useful. Or would it? Does it help to know there are 5 paragraphs
> that discuss "turkey". Or do you really want to know whether the
> paragraphs are about Thanksgiving dinner, a sports team, a car,
> or the latest movie? To distinguish them, you need more topics,
> don't you. Eventually, you get a paragraph that has a whole lot of
> labels attached to it. That will be useful, but will graphics be
> really valuable, here? Show me a graphic illustration of the
> bootstrap mail archive, for example. (Seriously. Help me "see" it.)
> Labeled or not, how would I be better able to cope with it
> graphically than I can with straight text processing.
>
> > > --Beyond that, though, I'm not sure I see a lot of value.
> > > Even with categories, there are so many potential
> > > categories that the system easily expands beyond the
> > > 5-7 types that will allow human pattern-recognition to
> > > function well.
> >
> > So we get to do an IBIS on this?
> >
> If your asking "can we do a structured evaluation of graphic
> alternatives", I think we certainly should. My experience has
> so far led me to conclude that it's not a great path. But you
> may have a vision of what could be that would change my
> experience, and lead me to a different conclusion. To my mind,
> it should certainly be part of the discussion. (When you
> invoke IBIS, the basic ground rule is to allow *every*
> alternative to be proposed, and then evaluated.)
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:53 PDT