RE: [ba-ohs-talk] Fixed ideas and polarization
-----Original Message-----
From: Jack Park (01)
Gary, (02)
> 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
requirement. (03)
<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
discussion.
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. (04)
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. (05)
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). (06)
<story>
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.
</story>
</glj> (07)
> What is not yet clear to me is how close the NexistWiki experiment comes
to
> 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. (08)
<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
resource.
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
added.
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.
</glj> (09)
> 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
into
> 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
adequate
> for displaying the structure of the argument space. (010)
<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.
</glj> (011)
> 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
> painted in animated SVG with javascripting and is completely
> interactive. An early goal in the present version of NexistWiki was to
> remain as browser neutral as possible. Moving to SVG would nuke that
idea. (012)
<glj>
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).
</glj> (013)
Thanks, (014)
Garold (Gary) L. Johnson (015)