|
|
CXP-Powered I-MINDS Capabilities 3.0 |
MergedCapability
In version 3, we
decided to merge both the buddy group and question answering capabilities into
one capability. We refer to these
capabilities as modes within merged capability.
There were two good reasons for doing this. The first is based on the underlying
functionality of capabilities in ConferenceXP.
Each capability instance was designed to run autonomously from any other
capabilities being run on the same machine.
ConferenceXP provides all the networking between the same capability
being run on multiple machines, but provides no way to communicate between
multiple instances or different capabilities running on the same machine. This created a good deal of work for us, as
we had to make sure that one or more machines running one or both of our
existing capabilities created no concurrency issues with the database. The second reason was scalability; suppose we
want to add a new I-MINDS capability or add new tables to the I-MINDS
database. In the first case we have to
extensively test all three capabilities working in tandem to make sure no
concurrency issues occurred. In the
second case, we would have to refactor all the database queries separately for
each capability. This was a time
intensive process and had the potential for introducing new bugs into one or
more I-MINDS capabilities.
1. Classrooms
In previous
versions of the I-MINDS capabilities, it was assumed that each group using
I-MINDS would have there own copy of the I-MINDS database. There was no way for the capabilities to
distinguish between two separate groups using I-MINDS at the same location if
both groups were connected to the same I-MINDS database. This caused all messages sent by either group
to be lumped together for purposes of generating statistics and natural
language processing. In version 3 we
have added separate classrooms to the merged capability. All messages sent in one classroom are
visible only to participants who are also in that classroom. The classroom is independent of the Venues in
ConferenceXP. Students in the same
Venue, but different classrooms, will not receive messages. Modifications to the I-MINDS database allow
messages to be logged and retrieved for specific classrooms. See section 6 for more information.
2. Classrooms
In previous
versions of the I-MINDS capabilities, it was assumed that each group using
I-MINDS would have there own copy of the I-MINDS database. There was no way for the capabilities to
distinguish between two separate groups using I-MINDS at the same location if
both groups were connected to the same I-MINDS database. This caused all messages sent by either group
to be lumped together for purposes of generating statistics and natural
language processing. In version 3 we
have added separate classrooms to the merged capability. All messages sent in one classroom are
visible only to participants who are also in that classroom. The classroom is independent of the Venues in
ConferenceXP. Students in the same
Venue, but different classrooms, will not receive messages. Modifications to the I-MINDS database allow
messages to be logged and retrieved for specific classrooms.
3. Message Object
In version 2 of
the I-MINDS capabilities messages were sent, through the ConferenceXP
networking code, as strings using XML tags to denote the sender, recipient,
etc. In version 3 we have completed
replaced message strings with a new serialized class called Message. This class acts as a wrapper for all messages
sent in the merged capability. This
includes messages sent in buddy group and question answering modes as well as
messages indicating that new participants have joined or left a classroom. In addition to the message itself, each
Message object contains information about the sender and recipient as well as
an enumeration indicating the message type.
Message objects are sent using the ConferenceXP networking code, which
multicasts them to other machines running merged capability.
4. Merged Capability Agent
In order to
facilitate future agent research, every effort was made to integrate agent
functionality into one base class for version 3. This Agent class contains three separate
regions controlling most of operations of the merged capability. The first is the switch region, whenever a
new message is received by the merged capability, the message switch decides
what to do with it based on its message type.
For a list of currently supported message types consult table 1.1. This allows new message types to be added
with relative ease, to support new capability forms, agent communication,
etc. The second is the message
composition region. This region contains
methods that are used to create new Message instances in preparation for
sending them through the CXP networking code.
The third region in the agent contains methods for running the database
queries. These methods build the SQL queries
that run select, update and insert operations on the I-MINDS database.
Table 1.1:
Message Types Supported
By storing all
the database queries in one class we eliminate the refactoring problems we
encountered in previous versions of I-MINDS.
Through the use of one centralized switchboard and methods for creating
Message objects we provide a comprehensive base class for future agent
development. For example, in order to
add the natural language processing and machine learning from the Q&A capability
we only needed to extend the merged capability agent. We didn’t even need to modify the switch
code, only overwrite the methods for handling messages from the Q&A
form. In this sense we regard version 3
of the I-MINDS capability as more than just a CSCL system, but the beginning of
a framework for the same.
5. Merged Capability Flow of Control
Figure 1.1 shows
the merged capability form in I-MINDS version 3. In the dropdown box, the user can select
which classroom he or she wants to join.
The checkboxes indicate capability modes the user would like to join in
the merged capability. There are
currently three capability modes: buddy
group, question answering and structured group.
Structured group, however, was disabled for version 3 as it was
implemented but not rigorously tested.
For more information on buddy group and question answering modes,
consult sections 2 and 3, respectively.
The merged capability maintains separate collections of which modes the
participants have joined. When a new
participant joins or leaves a capability mode, messages are sent to the other
participants so their collections can be updated. After the participant presses the join
button, the forms for the capability modes are automatically displayed. To leave a particular capability mode, the
participant can just close that mode’s form.
Closing the merged capability form will cause the participant to leave
all modes.
Figure 1.1:
Merged Capability Form