Bloomer IBIS UseCases

From Bloomer

Description
   (1)

In this page, the topic is defined as an enumeration of use cases for the IBIS MediaWiki Extension for the Bloomer project.
   (1A)

In this topic, we view an IBIS conversation as a collection of IBIS statements, which can be questions, answers, or arguments, and we use the following terms:    (1B)

• node: the same as an IBIS statement--that is, a question, an answer, or one of two kinds of arguments: pro or con. Each node is the equivalent of a wiki page    (1B1)
• conversation: an entire collection of nodes, each connected with an arc    (1B2)
• arc: the relation that ties one node to another. For instance, an answer or position responds to a question.    (1B3)
• statement: a short, very concise sentence or phrase. A statement must be about one and only one subject; it may not be a conjunctive sentence, as for example: "greenhouse gasses include CO2, Methane, ...". The reason for this is to ensure that each indivual assertion, such as "CO2 is a greenhouse gas" is a lone and addressable subject so that it, and it alone, can be talked or argued about.    (1B4)
• details:  while a statement is a short description of an idea, question, or argument, details can be much longer. Details are filled into a text editor that allows for a rich body of information, including images, to be included.    (1B5)
• portal: a Web site that is created to satisfy the needs of a particular collaborative community. A health care portal is distinct from a climate change portal.    (1B6)
• authenticated: All users who have access to any editing controls must be authenticated (logged in).    (1B7)

20091226 Note: a revision to the architecture found here is being explored; this revision may have impacts on the design of the IBIS Extension. The revised architecture envisions a local copy of a Federation Server attached (through AJAX communications) directly to an instance of MediaWiki. The point of this attachment is to handle creation of new topics, which include IBIS conversations.    (1C)

General Use Cases
   (2)

In the largest picture, the use cases for wiki users are these:    (2A)

• user visits portal    (2A1)
• user navigates to page with a conversation. For example, navigate here and scroll down to Challenge 1.    (2A2)
• user navigates (browses) the conversation (either in a graph view or jumping pages). For example, from Challenge 1, click on the challenge itself, which will navigate to the node for that question itself. Each such node will have links to any answers, questions, or arguments that relate to it.    (2A3)
• user picks a node to be answered with either a question, answer, or pro or con argument.    (2A4)
• user (if authenticated) gets a form to fill in: choose node type, add
  statement that makes the response, add details (further explanation)
  if desired, click submit button. That form could be on the page
  already, or it could be the result of clicking either a Respond button
  or one of several IBIS buttons (each of which pre-supposes a node
  type).    (2A5)

The IBIS extension's behavior must be to either paint the form and wait for
the reply, or take the information from the form and then:
1- create a new page in the wiki
2- put that new content there PLUS link back to parent node and link
back to parent map if available
3- notify the federation server of the new node

Advanced Use Cases
   (3)

The general use cases describe a minimal implementation of the IBIS Extension. They do not describe advanced behaviors of the extension that will be required for full operation. To understand what that means, consider this scenario in which two users are answering the same question, which asks: "which greenhouse gasses affect climate?":

• User A answers: "CO2"    (3A)
• User B answers: "Carbon Dioxide"    (3B)

The Bloomer project implements various ways to maintain the simplest possible IBIS conversation for purposes of making it easier for all participants to navigate the conversation without seeing redundant information. But, there do not yet exist computational facilities powerful enough to fact-check every entry into an IBIS conversation before it is saved and made available to users to view.    (3C)

In the example above, most humans will immediately recognize that CO2, technically written as CO₂, is the same molecule as has the name Carbon Dioxide. Thus, the two answers are technically the same answer to the same question. Bloomer seeks to merge those two answers (nodes) into one node, giving appropriate credit to both authors.    (3D)

We have options for the IBIS Extension. They include:    (3E)

• Remove nodes on computational command, unlinking them from other nodes as appropriate    (3E1)
• Adding nodes on computation command, linking them to other nodes as appropriate (this requirement is built into the general use cases)    (3E2)
• Detecting and performing merge operations, which means reading and comparing statements using various techniques to determine if they are saying the same thing, then performing the necessary merge operations if appropriate.    (3E3)

At the present time, we do not see a need for the IBIS Extension to perform merge operations in terms of detecting the need to merge. The Bloomer Federation Server is capable of detecting the need to merge. We envision that we may build a limited version of the IBIS merge system taken from the Federation Server and couple that directly to the IBIS Extension, meaning that the extension will eventually need to honor these advanced use cases:    (3F)

• Extension sends each node to a Merge Agent (to be created)    (3F1)
• Merge Agent must then use the MediaWiki database (or, perhaps, maintain its own IBIS conversation database) to compare nodes and suggest merge operations.    (3F2)
• Extension must be able to either remove and regenerate nodes (as described above), or to modify existing ones as suggested from the Merge Agent.    (3F3)

There is a background story to merging.We will cover that elsewhere <TODO link to merge story>    (3G)