RE: [ba-ohs-talk] Fixed ideas and polarization
Comments below.
Thanks, Gary.
Cheers, Jack (01)
At 03:57 AM 9/14/02 -0700, you wrote:
>-----Original Message-----
>From: Jack Park
>
>Gary,
>
> > 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.
>
><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.
>
>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).
>
><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. (02)
<jp>
Question: do you, Gary, or anyone else reading this have any experience
with Literary Machine? I've been playing with the free download. There
seems to be an enormous learning curve (probably rivals NexistWiki!);
whenever I try something, the screen paints with all kinds of little windows. (03)
Certainly the price is right ($20), but the product is a single-platform
product. I wish he would map it to a software environment that is cross
platform (read: linux, mac, wintel).
</jp> (04)
>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> (05)
<jp>
Great Story! Thank you. (06)
Most of the use cases explicit in that story cannot easily be accomplished
with an HTTP (browser) interface. There must be a way to perform the bulk
of those tasks on the desktop, then map those you want to share or
collaborate on to a Web portal that ends up (probably) using HTTP or
P2P. That idea, to make a powerful desktop that works in collaboration
with a Web presence, is the NexistWiki experiment, although only the Web
presence exists at this time.
</jp> (07)
></glj>
>
> > 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.
>
><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. (08)
<jp>
The specific nature of the addressable resource is, indeed,
troublesome. NW allows you to determine that all by yourself, which, I
suspect, is a bit too much freedom to have available. Logical partitions
are individual sentences and paragraphs. (09)
If we were to get to the kinds of power you mention elsewhere here with the
Literary Machine, we might want to look at the Grove concept, for which
there are (finally!) some open source projects:
http://sourceforge.net/projects/grove4j is one which is being designed
(just getting started) so that it can couple with
http://sourceforge.net/projects/tm4j the topic map engine. A Grove gives
us the ability to address any object in any document type for which there
is an adaptor written.
</jp> (010)
>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> (011)
<jp>
I confess, the whole notion of presentation ontology is one that is
confusing, and even disappointing at times. I, personally, simply *love*
the default interface at http://www.memes.net, but maybe that's because I'm
a passionate taxonomist. I am seeing some modicum of feedback that the use
of that interface is not really of value in NexistWiki. (012)
I suspect, however, some of the problem lies in the particular ontological
committment that NW makes: "parent", "child", "sibling" and "Related Page",
of which the least ontological committment would (should?) be simply to
"Related Page" and let users choose their own way of organizing pages. If
you browse the ScholOnto project http://kmi.open.ac.uk/projects/scholonto/
you can get the flavor of the idea behind "Related Page", which, when
applied to individual AddressableInformationResources, allows for the kinds
of linking proposed and developed in the SchoOnto project. (013)
Backlinks have yet to be implemented in NW, but they will be.
</jp. (014)
> > 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.
>
><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) (015)
<jp>
I have used Jeff Conklin's QuestMap in several classroom facilitation
exercises. The ability for participants to view the evolution of the
discussion in which they are engaged turns out to be a rather stunning
benefit. Several teachers, in a group for which I was using
"constructivist" techniques to introduce them to "constructivist"
techniques, came forward and asked to be given private coaching on how to
do what I just did; they saw immediately the value of using the shared
visual discussion space in learning situations.
</jp> (016)
>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>
>
> > 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.
>
><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. (017)
<jp>
The original concept from which NexistWiki was born was actually based on
Eric's notions of IBIS coupled with email. I actually began to consider
what kind of DTD would allow us to use tags to create IBIS
discussions. Ultimately, I decided that IBIS should meet XTM (XML topic
maps), which I discuss in the closing chapter of the _XML Topic Maps_ book
and at http://www.thinkalong.com/JP/ParkKT2001.pdf where I introduce the idea. (018)
I envisioned a Web portal where those emails would congregate and get cut
and pasted (automagically) into a coherent display. The notion was (and
still is) to provide the ability to use tools that people already
use. IBIS forms would be "stationary" forms that users would "ReplyWith",
selecting the particular form according to the desired response within the
IBIS ontology. (019)
Somewhere along the line, I set that on the back burner in order to explore
the notion that it may be more important to have people just tell stories,
as I mentioned earlier, and then augment those stories with IBIS arguments
(or, for that matter, any argumentation ontology desired, e.g.
http://www.austhink.org).
</jp> (020)
>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>
>
>Thanks,
>
>Garold (Gary) L. Johnson (021)