Welcome to App::IBIS: We Have Issues.

If you are looking at this page, it is almost certain you have been directed here by its author, me.

This tool is something of a laboratory with half a dozen experiments running concurrently, and was never intended to be anything more. It has been dragged, kicking and screaming, into active service, because it has nevertheless turned out to be useful. Here are some of the major things going on:

The RDF-KV Protocol
I originally created this tool for the exclusive purpose of testing a protocol I designed. The purpose of this protocol is to facilitate the rapid development of RDF CRUD applications with the fewest possible moving parts, in particular the ability to modify server-side graph content without having to rely on client-side JavaScript. This simple protocol is embedded into HTML <form> fields, the name= attributes of which are specially-crafted to sum up to commands to add and remove RDF statements from a given graph database.
The IBIS Vocabulary
In order to test the protocol, I needed an RDF vocabulary. A year or two prior, I had created a vocabulary for representing instances of Kunz and Rittel's Issue-Based Information System. Feedback from using the tool has since stimulated a number of revisions to my initial interpretation of the system.
Visualizing Graph Data
While I believe that synoptic views are essential to comprehending complex data, I am sympathetic to Martin Krzywinski's position that hairball force-directed layouts are suboptimal in their information-carrying capacity—so much so that I implemented his hiveplot design in a very early prototype of this tool. I very quickly discovered that while it is an attractive visualization for static presentation graphics, the hiveplot was inadequate—at least for this particular—interactive application, as it turns out the aspect ratio of the image changes dramatically with the addition of new elements, making it impossible to design around. This led me to implement Krzywinski's Circos plot, which has its own set of shortcomings for the data in question: Circos appears to be better for shallower graphs, which IBIS is most definitely not. I have a semi-original idea for a third attempt which will look wildly different from the first two, but it will have to wait until I can sequester enough time to implement it.
Semantic Data Visualizations
Early on it seemed to me that it would be a very useful thing, if you were interested in actually sharing the data you visualize, to arrange for those visualizations to embed their constituent data such that it can be extracted intact. What obviously followed was to embed the data directly into the very elements that were being used to draw the corresponding points in the visualization. This coincided nicely with yet another experiment.
Visual Styling of Semantic Content
It turns out RDFa attributes are just as eligible as any other for CSS selectors, and in many cases can stand in for conventional class and id selectors, thus obviating the need to maintain a separate set of identifiers. In the handful of cases these attributes cannot be repurposed this way, they can be read by an RDFa-aware processor that transforms the markup into something more amenable to styling with CSS. In practice, this greatly increases the capacity for styling, since e.g. colour palettes can be identified to RDF types and predicates, and much less has to be maintained by hand.
Through-and-Through RDF Web Application
I designed this application from the ground up to be a thin skin overtop of an RDF graph database, the ultimate implementation of which it is intended to be agnostic. Indeed, the ultimate goal was to have the application produce data which could be removed and installed in a completely different implementation or applied to a completely different purpose. In concrete terms, implementation is only about 3000 lines of code, a third of which is for drawing the visualizations. This experience has been extremely insightful for identifying the kinds of traits which are desirable in an RDF application framework.

IBIS Itself

In , Werner Kunz and Horst Rittel, two professors of architecture, planning and design at Berkeley, published a paper describing a system for solving wicked problems—problems with a large number of mutually interacting concerns, often accompanied by a number of stakeholders whose interests are often divergent, if not diametrically opposed.

The important idea behind IBIS, although not unique to it, is a concept called structured argumentation, which involves limiting the available rhetorical manœuvres to the constraints of a formal system, thus turning the argumentation process into a kind of game. Argumentation here is not conflict per se, but rather in the context of developing a program and rationale for solving wicked problems: figuring out what issues exist, how to address them, and why one course of action should be carried out instead of another. To this effect, there are three recognized types of element in the IBIS ecosystem:

  • Issues: Factual statements regarding states of affairs in the world, that somebody would like something done about. In the tool, these are tinted red.
  • Positions: Value statements or statements of opinion, about what, if anything, should be done about a given issue. In the tool, these are tinted green.
  • Arguments: These are ultimately factual statements just like issues, even though they are motivated by convincing our interlocutors of the merits or demerits of a given position. In the tool, these are tinted blue.

The elements in the system can be connected in the following ways:

  • Any element can generalize, specialize, or replace an element of the same kind (replace is currently not implemented).
  • Any position can respond to any issue.
  • Any element can suggest an issue.
  • Any issue can question any other element.
  • Any argument can support or oppose any position.

The original formulation of this system was moderated by Kunz and Rittel and carried out on simple index cards. One can thus imagine additional faculties for annotation and attachment of evidence, which was essential part of any argumentation system. Such extensions were added in numerous digital implementations of IBIS dating back as far as .

Extensive Digital Pedigree

There have been numerous attempts spanning three decades to digitize IBIS, many of which are still extant. Conklin, the original, once a student of Rittel, is still in business. Nevertheless, these tools remain incredibly niche, which I suspect has to do with:

IBIS tools require at least a trained moderator, if not comprehensive training for all participants.
No matter how slick the user interface presented, IBIS will never be user-friendly—i.e., workable by novices—in one very important sense: These systems are ultimately text-based, and the formulation of the language is important enough that one can't just write anything in any slot. Like any precision instrument, there are consequences to their misuse.
They draw on, and lend themselves to reference by, copious external resources
Up until fairly recently, IBIS implementations have been stand-alone desktop applications. Attachments for evidence or notes thus had to be either embedded in the state mechanism of the tool itself (its save file or database), or linked to a computer's local file system. Argumentation elements within the tool itself were likewise not directly addressable. Until the Web came along, remedies for these problems would have spelled out enormous expansions in development scope; even with the Web they are not trivial.

IBIS tools are meant to solve hard problems, but are themselves hard problems, made harder by technical and paradigmatic constraints over their half-century history. Why try to make another one?

This Particular Implementation

As mentioned, this IBIS tool started life as a test bench for a mundane yet important piece of back-end infrastructure. That infrastructure doesn't know or care about what it's processing. What gives the tool its identity is the RDF vocabulary at its core.

Elements are First-Class Citizens

Under this design, the issues, positions and arguments that make up an IBIS instance are individually-addressable information resources. Indeed, operations are carried out from the point of view of a given element. Other systems typically render a single view of objects on a canvas, and only the canvas itself is addressable. It was important to me to show a situated view in addition to a synoptic one, and it has proven extremely useful to be able to link directly to individual IBIS elements.

Permeable Membrane

Whereas other IBIS systems attempt to encapsulate all of the attendant structures to support their core functionality, the strategy here is to try to delegate as much of that work as possible. Using RDF and linked data, we can outsource ancillary data representations to other vocabularies, and assets to other sites.

When designing the underpinning vocabulary, it was obvious that since IBIS elements are essentially conceptual entities, they ought to inherit the properties of SKOS concepts. It became clear very early on that the IBIS elements needed to interact with regular SKOS concepts, insofar as the latter helps group and identify the former. I have since added a rudimentary interface for creating and manipulating an ordinary SKOS concept scheme.

My Experience With IBIS

I bootstrapped the first working version of this tool around , and have been using it off and on ever since, although much more in the last couple years due to fixing and/or working around a few severe third-party performance and resource consumption problems. I have also made some sporadic changes to the user interface, but acknowledge that I am approaching the limit of what this particular implementation—and the framework it rests upon—can be reasonably teased out to do. Nevertheless, it has been serviceable enough to get a sense of what the IBIS experience is all about:

Versus Outliner

The first thing you will notice is that in contrast to an outliner, IBIS is only weakly hierarchical. IBIS structures do not have a root, although they may be understood to represent paths that begin with a single issue and traipse from position to argument and even loop around. What you get, in my opinion, is something ultimately more powerful than an outliner, if not quite as tidy: a much more topologically honest representation of a problem space: you don't have to mangle your work in order to fit it into a strict hierarchy.

The other item worth noting is the IBIS elements and the relations between them are typed: there is additional meaning attached to the element outside its textual content, and elements can only be attached to certain other types of elements, and only in specific ways. Here you lose some of the generality of an outliner, but in return the relationships between entries say more than sibling or child.

For those of us who use an outliner as a to-do list, in IBIS we are encouraged to record what issue we are trying to respond to, in addition to the thing that needs doing. In collaborative environments we may also need to justify why the thing needs doing in the first place, either versus doing nothing, or versus doing some other thing. This is also recorded in the IBIS network.

Versus Bug Tracker

Many software bug-tracking packages already call their main content issues, and in some narrow sense these can be construed as exactly the same thing. The main difference is that the issues in bug trackers only concern themselves with some piece or other of software, while in IBIS an issue can pertain to anything.

Responses to issues in bug trackers tend to be implicit, as there is often only one response to a bug report, which is fix the bug. Only occasionally is there any discussion of how to fix the bug, and when there is, it is carried out in the bug report's comment section. In this way we can say bug trackers are semi-typed—with the main issue being typed and the commentary, implicitly full of positions and arguments, being untyped.

One way the two classes of system are similar is that modern bug trackers are capable of representing dependencies between two issues, which makes it possible to compute the essential procedure for resolving any given issue—an important ingredient for project planning. Given these comparisons, we can regard an IBIS tool as something like a bug tracker for everything.

How to Use IBIS

Using the tool itself is easy; the hard part is mastering how to write for it.

The main idea to keep in mind when writing entries into an IBIS network is that by using it you are agreeing to delegate aspects of your argument to the topological structure of the network. This would be the same whether the process was carried out on the original index cards, or on any other computerized version. For example, with an issue, the fact that it got into the system at all implies somebody wrote it and it didn't just appear out of nowhere, and the fact that it's marked as an issue implies something ought to be done about it. If the text of the issue contains a value judgment or even hints at a course of action, then the formal semantic relationships can't do their work. Here are some more concrete examples:

Bad issue (value judgment):
The rent is too damn high!
Bad issue (suggests course of action):
More housing supply will cause prices to come down.
Almost good; actually two issues:
Housing costs have risen faster than incomes and vacancy is at 0.5%.
Good issue (atomic factual statement):
Housing costs continue to rise faster than incomes.

The first two examples in this list are actually positions, for the reasons attached. The third example is resolved simply by cutting it in half. Only the last example takes an appropriate-enough form to use as an issue. That only leaves us to discuss the third class of element, the argument. It has become clear, both from the reference literature and from several years of use, that an argument only differs from an issue by the fact that it is being used to argue for or against a position. Otherwise they are exactly the same kind of thing: an atomic factual statement.

This is perhaps counterintuitive, and perhaps doesn't track with the formal idea of an argument, let alone the colloquial one. It might seem that it's the elements called positions that are the actual arguments, while the things called arguments provide the evidence for or against the position. The role of the issue is to anchor the position to a particular state of affairs. Under the IBIS rubric, issues and arguments are statements of fact; positions are the only elements permitted to contain an ought.

If an element A specializes another element B, this is saying that A is a special case of B, and the generalizes relation is the inverse. The only other real ambiguity is the distinction between questions and suggests, which are roughly inverse to one another. Through experience it seems that questions is a stronger variant of suggested by, while suggests is a weaker version of questioned by. Any element can suggest an issue, while any issue can question any other element. If an issue I questions an element J, this implies J suggests I.

As you can see, the role technology plays in this system is minimal, relegated to abridging the labour of arranging and connecting the constituent parts, and subsequently getting out of the way of what is ultimately a cognitive process that requires a certain amount of training and skill.

Implementation Status and Direction

This particular implementation I feel has served its initial purpose, which was to test the RDF-KV protocol. Its mission was extended by helping flesh out the IBIS vocabulary, and it continues to serve as a useful tool for project planning and similar forms of problem-solving.

Nevertheless, in order to take this tool to the next level, I need a fast reasoner, which doesn't exist in this implementation's programming language, and writing one from scratch is out of the question. It's much easier to just rewrite the tool in a different language. Major changes, like proper multi-user support and a proper data visualization régime, are not worth the effort to do in the current implementation, so they will have to wait for the rewrite.

Thankfully, the code is only 3000 lines long. No doubt there will be gaps in third-party libraries, my eyeball guess is I'm probably looking at a 10000-line job just to reach parity, albeit with a lot of the design decisions already taken care of. The only remaining question is how to sequester the time. Until then, enjoy App::IBIS.