Re: [ba-ohs-talk] Fixed ideas and polarization
Has anyone read any of these papers? (01)
Think Link, Invent, Implement, and Collaborate! Think Open! Think Change! Think
Keynote Speech Honoring Douglas Engelbart on Doug Engelbart Day in the state of
Oregon, at Oregon State University, January 24, 2002
< http://www.stanford.edu/~rhorn/images/spchThinkEngelbart.pdf > (03)
Horn, R. E., (2002) Infrastructure for Navigation of Interdisciplinary Debates;
Critical Decisions for Representing Argumentation . A draft chapter prepared for
the forthcoming book Visualizing Argumentation; Tools for Collaborative and
< http://www.stanford.edu/~rhorn/images/artclCmptrSpArgmttn.pdf > (04)
More info. < http://www.stanford.edu/~rhorn/ > (05)
"Garold (Gary) L. Johnson" wrote: (06)
> -----Original Message-----
> From: Jack Park
> > Are you able to translate your thoughts into, maybe, concrete use cases
> > and/or requirements? I am reading into your comments here that notions of
> > seamless linking between stories and issue-based arguments is a
> <glj> -- I am strongly convinced that collaboration (as opposed to
> "chatting") requires that we be able to refactor, restructure, summarize,
> propose, and dispose on a continual basis. This requires that I be able to
> go back to all of the material (I have started to keep my longer rants, for
> example), and formulate better explanations of what it is I think I know.
> This rework is a continual effort to provide an exposition that appears to
> have been developed in an organized manner no matter how chaotic the actual
> evolution may have been. The Topic Map book makes the point that complexity
> precedes simplicity in the development of systems, and our tools need to
> recognize and support this.
> This requires the ability to assemble the elements of the history that are
> relevant, paraphrase, integrate, restate, etc.
> It means that I should be able to add commentary, links, indexing or search
> information, etc. to existing documents without destroying the original
> work. Even in an email reply like this, much of the context of the
> conversations that lead up to it is lost because I cannot (won't?) take the
> time to go back to all of the emails that constitute the history of this
> Thus there is a requirement that the conversation record be captured,
> addressable, persistent, etc. These features are not needed all that much to
> carry on the conversations, but when it comes time to address the issues
> dealt with in the stories.
> The result of each really good restatement is a new baseline to work from.
> We have the most nearly coherent statement we can make of the state of what
> we have learned without having to read everything we wrote on the subject.
> Then we start with issue-based collaboration, refer to older stories with
> differing emphasis, add new stories, and the process goes on.
> This requires the ability to capture versions of the text and possibly the
> various organizations (I am reading the Topic Map book).
> For example, If I were to set about trying to reformulate the knowledge
> contained in this forum, I would want to start with the entire forum
> content, begin to develop an outline of the factors addressed, revisit the
> threads and edit them to remove all material not relevant to the view I am
> developing. The initial objective is to create a structure of the way the
> conversations might have evolved if we knew at the time what we know now.
> This involves telling longer and more organized stories based on the
> fragments of earlier tales, possibly restructuring the content into some
> issue-based structure or other form as needed. All of this should be linked
> to its origins with quotes and sources attributed as needed without getting
> in the way.
> I would like to go to the archive and ask for a thread outline. This would
> give me the threaded sort with topics only. I cold also get an author list
> with message counts and ratings, strictly date order, and search results of
> various sorts including my own and a public Topic Map of the archive.
> Then I would open a workspace to begin the work.
> As I find an interesting thread, I copy it's heading to my work area
> outline. The copy retains the link to the thread, even if I change the title
> of the item.
> When I find that a given thread already has a summary of the sort I want, I
> add a reference to it to topic in my work area.
> When I find an email that appears to have valuable information but not a
> structure I can work with, I open it for restructuring in my editor. In this
> mode, each segment remembers it source in the original document. I can break
> paragraphs up, form lists, correct spelling, etc. The result is a parallel
> to the email that has its own purple number references but where each
> element links to its origin in the original record. I can make this
> available publicly as a version of the original, and / or add it to a
> resource topic in my workspace.
> Now as I begin to develop my own summaries and content I can copy a section
> of text by reference, and the copy operation preserves one layer of history.
> If I need to follow the chain I can, but copied segments retain only their
> own source locations.
> For an entire message, a single element, or a selected text range choose
> candidate subject areas to add to the indexing. These are tracked as part of
> my workspace whether they refer to elements in the public archive or my own
> workspace. See Literary Machine at http://www.sommestad.com/LM_1_1.htm for
> how this idea works.
> When I am done, I can send any pieces to the archive for further discussion,
> continue to work on the elements, or publish the entire thing as one or more
> documents that can be linked to and used by others. Perhaps the workspace
> can be made available for collaboration before it is finalized.
> In any case, the result is a summary of all or part of the discussions which
> take into account all of the stories and discussions and can form the basis
> for a renewed discussion at higher levels.
> This is the way that Wikis are refactored, but they don't have tools to
> support this sort of access and edit with source attribution, it all has to
> be done by hand. This is done even with Wikis that are largely
> conversations. When the point of the discussion is the evolution of work
> products that can become the basis for implementation, this continual rework
> if even more necessary.
> > What is not yet clear to me is how close the NexistWiki experiment comes
> > developing that idea. My present experience is that the NexistWiki user
> > interface is far less adequate as an engineering platform than I had hoped
> > it would be, so we are not yet experiencing, I think, the kinds of results
> > required to get a real handle on the nature of seamless integration.
> <glj> -- The NexistWiki experiment is an excellent one. My take on it is
> that it places somewhat more burden on the conversational aspects (as does
> any Wiki) than is normal. Determining what is an "addressable resource" on
> the fly is not a trivial issue, and that will often need refactoring, which
> can be difficult if there are already blank discussion pages set up on the
> The sort of lazy evaluation that occurs in a Wiki when a topic is defined
> but doesn't exist until someone puts content in it is the sort of thing I
> have in mind.
> I confess that I haven't really given NexistWiki the workout that it
> deserves. My current take is that it can tend to fragment the discussion
> overly much, but then Wiki has that problem until indexing or outlining is
> Twiki supports the concept of a "parent" as the node that held the link
> followed when the topic was first created. This allows the construction of
> an outline using the topic name and the first line for text. By showing back
> links and "see also" links, there is some degree of coherence that emerges.
> > Jeff Conklin's point of view, if I might translate it into my own terms,
> > seems to be that the value of such an integration is not going to come
> > view until the visual element is brought into the user interface. For now,
> > all you get is a simple outline view, and that's just nowhere near
> > for displaying the structure of the argument space.
> <glj> -- I have yet to be convinced that visual interfaces are all that
> useful compared to a wide variety of searches, indexes, etc. I assume you
> are referring to graphs such as TouchGraph)
> When it becomes possible to integrate Topic Maps in such a way that we can
> produce different outlines for the base information, my opinion will change.
> >From what I read, the model of Topic Map evolution matches precisely what I
> am talking about. At this time, I don't think the interface is the problem
> so much as the fact that our underlying model is not yet rich enough to
> support the full range of operations involved in extracting and reformulate
> the knowledge contained in the discussion.
> > If I could jump ahead into implementation details, I think that we may not
> > be able to see what we are talking about here until the user interface is
> > interactive. An early goal in the present version of NexistWiki was to
> > remain as browser neutral as possible. Moving to SVG would nuke that
> I look forward to seeing what you have in mind.
> What I see as needed is a way to integrate email or something like it for
> conversations into a multi-structured form that can organize the information
> contained in the conversations. This means outlines, Topic Maps, searches,
> indexing, and anything else we can use to aid in locating, accessing, and
> working with the information that is generated.
> I would also like to see support for an approach similar to Information
> Mapping (www.infomap.com ) where different sorts of information structures
> have different representations in documents (list, trees, decision tables,
> action scripts, etc).
> Garold (Gary) L. Johnson (07)
Introducing NetZero Long Distance
Unlimited Long Distance only $29.95/ month!
Sign Up Today! www.netzerolongdistance.com (08)