Much of what Compendium started from was a set of attempts to add many of
the features Eric advocates to the basic IBIS/QuestMap set of tools, in
part for many of the same reasons he writes about below.
Some definitions: "Compendium" is a methodology that incorporates, but
extends, IBIS; "Mifflin" is a Java-based software tool that implements the
Compendium methodology. The "we" of the below is mostly the core group that
has been working with Compendium for the last few years; a list of names
can be found at http://www.compendiuminstitute.org/community/people.htm.
To add retroactive categorization (a/k/a "incremental formalization" a la
Shipman), we developed a (manual in QuestMap, later automated in Mifflin)
method of adding categories to nodes.
To aid ease of use in adding structured information to unstructured
conversations, we developed templates and other structuring tools. These
were done semi-manually when we used QuestMap, and are being automated in
Mifflin.
To address the relative ease of entering text in an email, word processing,
outliner, or spreadsheet format, we developed conversion tools that
automatically converted text (in paragraph or cell chunks) into typed nodes
and links for import into QuestMap (and later Mifflin). The text could
either be free-form or semi-formalized. We also developed tools in Word or
Excel that allowed users to add metadata (tags/categories) within those
tools if they preferred. Both tools were also adapted to specialized
contexts (i.e. performing particular kinds of conversions based on
particular requirements).
To further 'glue' and leverage the IBIS-format discussions and other
material in a Compendium database, we developed export tools that created
formatted output in Word, Excel, HTML, and Visio formats. Each of these
could either be 'generic' or specialized. For example, a five team, ~60
person Compendium analysis of Bell Atlantic's Y2K contingency planning was
output in both a set of tabular "reports" and in dataflow diagrams in
Visio. These exports took advantage of many different combinations of
metadata (node types, link types, tags, transclusions, annotations, ...).
One of QuestMap's limitations as software was that its database was
inaccessible except through the tool's GUI. Mifflin's database is open,
allowing for much more sophisticated and flexible conversions of data into
and out of an IBIS or IBIS-like format. We're just beginning to explore the
possibilities there. We've also developed a draft DTD for this data model,
which can be found at
http://d3e.open.ac.uk/compendium/01/comp-dtd-v1/comp-dtd-v1-t.html
(comments enthusiastically welcomed!). For example, Maarten Sierhuis' group
at NASA Ames is investigating interweaving Compendium models built
collaboratively in Mifflin with the Brahms agent-based simulation
environment.
There are more such features that at least partially address the
requirements Eric outlines.
However, all of the above leave open the question of whether any of this
directly addresses the issue of individuals working alone, asynchronously.
Some thoughts on this follow.
Mifflin outputs maps as linked HTML maps, optionally preserving much of the
metadata (transclusions, tags and categories, node types, etc.) We've
experimented with exporting these maps into D3E, allowing asynchronous
discussion in a more web-friendly (and individual user-friendly?) format.
The D3E team is looking into re-importing such discussion back into Mifflin
when desired.
I'm pretty sure I agree that an IBIS form, like Compendium, is not the
right form for unstructured individual/asynchronous collaboration (I'm only
'pretty sure' because it's always possible that someone will come up with
better ways to do it). We have never had much success with it in that form
per se. However, we have had a fair amount of success using Compendium
asynchronously on highly focused project teams, such as software
development teams, especially when such use is interwoven with
public/synchronous use in meetings (whether face to face or virtual). Most
of the success, though, is not as a "discussion" per se, but rather adding
metadata, annotations, or other information to targeted portions of the
database in the service of relatively structured tasks (which are then
reviewed, discussed, and further edited in group meetings). An example
would be individuals adding updates to open issues or action items;
changing tags/categories on "bug" nodes to denote that the status has
changed (e.g. from "open bug" to "ready to test"), and so on. A lot of the
material that ends up in these databases, by the way, started life as
unstructured text in emails or other documents -- with formalization and
reuse added in all along the way.
I've started to think that an IBIS-like form is most useful when thought of
as a "meeting interface" -- something of especial use precisely when groups
of people are working through issues together. What Compendium tries to do
is to provide a set of tools and methods that allow this form to be
interwoven with other forms (D3E, MS-Office documents, etc.) when and as
appropriate -- preserving the both the raw data and the metadata both 'in'
and 'out' of those other forms. Structure and metadata can be brought to
unstructured material; informal and exploratory conversation can be brought
to structured material. The idea is to provide the right form for the right
use, the right structures at the right time, without limiting the user
community to one modality. So it's not a question of either meetings or
individual work, but bringing the two together in a continuum or cycle.
Al
====
Eric wrote:
That is one reason I favor systems that let you add categories and tags
later in the process. That way, you can stream out your thoughts, and
then go back later to tag
them, or someone else can do so.
As you say, people typically find it hard to maintain a logical thread
of reasoning
while at the same time endeavoring to:
* chop up discourse into nodes
* give those nodes types
* determine what types the links should be
* determine where the semantics go
Each of those areas constitutes a "weakness of the system" to precicesly
the degree
that people find it hard to do. I think there are answers to many of
them:
1) Education.
People find many things hard to do that they eventually learn to
do with ease.
Human adaptability being what it is, we can get used to most
anything. But we
need a standard playing field for that to happen.
2) Software Technology
In an outliner for example, "chopping into nodes" is automatic.
You don't
even think about it. So that hurdle can be minimized with the
right
software.
3) Retractive Cateorizing
Applying types to nodes and to links in a later step makes it
possible for
a moderator to have a significant impact on the proceedings. Once
you
know the system, you can apply types proactively. But that choice
should
not be forced on you at the outset. (That is the kind of system
that was
under discussion. The requirement to choose types at the outset
constitues
a true "weakness" of the system.)
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
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This archive was generated by hypermail 2.0.0 : Tue Nov 06 2001 - 15:26:55 PST