Wow!!! Congratulations on the progress you guys have made.
It seems clear that you guys are in a good position to know what
works well, and what has problems.
I find it particularly noteworthy that, having actually implemented
a system that will allow carring on an IBIS-style investigation, it
is still difficult to use that medium as a discussion tool. It seems
rather as a good mechanism for recording discussions after the
fact, and tying them to the decisions that result.
Is that an accurate summary?
> Much of what Compendium started from was a set of attempts to add many
> the features Eric advocates to the basic IBIS/QuestMap set of tools,
> 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
> Compendium methodology. The "we" of the below is mostly the core group
> has been working with Compendium for the last few years; a list of
> can be found at
> To add retroactive categorization (a/k/a "incremental formalization" a
> Shipman), we developed a (manual in QuestMap, later automated in
> 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.
> were done semi-manually when we used QuestMap, and are being automated
> To address the relative ease of entering text in an email, word
> outliner, or spreadsheet format, we developed conversion tools that
> automatically converted text (in paragraph or cell chunks) into typed
> 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
> 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
> formatted output in Word, Excel, HTML, and Visio formats. Each of
> could either be 'generic' or specialized. For example, a five team,
> person Compendium analysis of Bell Atlantic's Y2K contingency planning
> 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
> allowing for much more sophisticated and flexible conversions of data
> 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
> which can be found at
> (comments enthusiastically welcomed!). For example, Maarten Sierhuis'
> at NASA Ames is investigating interweaving Compendium models built
> collaboratively in Mifflin with the Brahms agent-based simulation
> 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
> directly addresses the issue of individuals working alone,
> 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?)
> The D3E team is looking into re-importing such discussion back into
> 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
> 'pretty sure' because it's always possible that someone will come up
> better ways to do it). We have never had much success with it in that
> 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).
> of the success, though, is not as a "discussion" per se, but rather
> metadata, annotations, or other information to targeted portions of
> 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
> material that ends up in these databases, by the way, started life as
> unstructured text in emails or other documents -- with formalization
> 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
> 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
> appropriate -- preserving the both the raw data and the metadata both
> and 'out' of those other forms. Structure and metadata can be brought
> unstructured material; informal and exploratory conversation can be
> to structured material. The idea is to provide the right form for the
> 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
> individual work, but bringing the two together in a continuum or
> Eric wrote:
> That is one reason I favor systems that let you add categories and
> 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
> the degree
> that people find it hard to do. I think there are answers to many of
> 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
> 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.
> know the system, you can apply types proactively. But that
> 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
> a true "weakness" of the system.)
> Community email addresses:
> Post message: unrev-II@onelist.com
> Subscribe: unrev-IIemail@example.com
> Unsubscribe: unrev-IIfirstname.lastname@example.org
> List owner: unrev-IIemail@example.com
> Shortcut URL to this page:
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Universal Inkjet Refill Kit $29.95
Refill any ink cartridge for less!
Includes black and color ink.
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIfirstname.lastname@example.org
Shortcut URL to this page:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This archive was generated by hypermail 2.0.0 : Wed Nov 07 2001 - 11:41:24 PST