Can IBIS be useful for individual/asynchronous collaboration? (was Re: [unrev-II] Visual stimuli & IBIS methodology)

Date: Tue Nov 06 2001 - 15:39:15 PST

  • Next message: "Re: [unrev-II] Visual stimuli & IBIS methodology"

    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

    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

    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
    (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

    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.



    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
      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. Once
          know the system, you can apply types proactively. But that choice
          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:
      List owner:

    Shortcut URL to this page:

    Your use of Yahoo! Groups is subject to

    This archive was generated by hypermail 2.0.0 : Tue Nov 06 2001 - 15:26:55 PST