|
|
CXP-Powered I-MINDS Capabilities |
BuddyGroup
This BuddyGroup
capability was completed in February 2006.
It has advanced message management, statistics display, and student
group support. All messages are tracked
and themed using a message tree, allowing I-MINDS to track in fine resolution
every group discussion. It also computes
statistics on the fly, allowing a student to monitor how his or her buddies
(peers) have been doing in the group.
This capability
is the “bread-and-butter” of I-MINDS: it collects and analyzes data
automatically for our student agents.
This also provides wonderful opportunities as a testbed for educational
research studies.
As this is one
of our intelligent capabilities (which are usually significantly complex than
our other capabilities), here we provide a detailed discussion of the features
and requirements, including installation guideline.
1. BuddyGroup
1.1. Introduction
This capability
was originally modified from the Chat capability included with ConferenceXP. It has the same text boxes for displaying
received messages and entering new messages.
This capability also retains the Send button from the original. Improvements to Chat include an additional text
box where message you are responding two is displayed. This text box includes a
popup menu with two items: ‘History’ and ‘Clear’, whose functionality is
described in the next section. This
capability also contains an ‘Options’ menu with two items: ‘Display Statistics’
and ‘Manage Buddy’, each described in the next section. See figure 1.1 for
an example of the Buddy Group capability form.
Figure 1.1. The Buddy Group
capability form
1.2. Flow
of Control
Unlike our QuestionAnswering capability,
there is only one version of BuddyGroup.
This capability is designed to be used by both teachers and students
simultaneously. All instances of
BuddyGroup require a connection to the I-MINDS database. Students can send messages to each other by
using the chat capability. These
messages are composed into message strings by using the buddy group tags
described below. These message strings
are then multicast using the SendObject method to the rest of the
classroom. It is important to mention
that while several participants might be using BuddyGroup simultaneously, only
messages from students who are in your Buddy Group will be displayed.
In the BuddyGroup capability, it is
possible to select a previously received message by just clicking on it in the
message text box. The selected message
is added to the response text box. While
the response text box contains a message, any new messages sent by the user
will be 'in response' to this message. To clear the message just right-click
the response text box to bring up the menu and select 'Clear'. To view the Message Tree for the previously
received message just select 'History' from popup menu. See figure 1.2 for an example. This will cause the MessageTree form to
become visible, displaying the tree view for the Message Tree (figure 1.3).
Figure 1.2. The popup menu for the Respond To field
Figure 1.3: Message Tree for [16:58] Teacher: some
question.
The BuddyGroup capability also tracks a
wide range of statistics based on student message traffic. These statistics can be viewed by students
for anyone in their buddy group by selecting the ‘Display Statistics’ item in
the ‘Options’ menu. This will cause the
Statistics form to appear. For more
information on the statistics tracked consult the documentation in the
Statistics form class.
The ‘Manage Buddies’ item in the Options
menu is actually a drop down list containing all the students in the Venue
(except yourself). This list is updated
when students join or leave the Venue.
Students who are already in your buddy group will have checks in front
of their identifiers. Clicking on a
student who is checked will uncheck the menu item and remove the student from
your buddy group. Recall, that you will
not receive messages from students unless they are in your buddy group. Checking a student does the opposite, adding
that student to your buddy group.
1.3. New
Concepts
It is worth pointing out that messages
for this capability and questions for the QuestionAnswering capability are both
stored in the same table in the I-MINDS database. In fact, from a design point of view we
consider questions and messages to be the same thing. Said another way, each question is a message
in the I-MINDS database. Questions asked
to the teacher by students (in QuestionAnswering) have their recipient flag set
to 'TEACHER'. All messages sent by
BuddyGroup have their recipient flag set to 'BUDDIES'. In this way, we can guarantee backwards compatibility
with our QuestionAnswering capability.
For BuddyGroup we introduce the concept
of Message Trees. Message Trees provide
the ability for one message to initiate an expanding flow of dialog. According to our concept, a Message Tree
starts with a single message--a question asked by one of the students. This message forms the root of the Message
Tree. Questions are displayed in bold by
the BuddyGroup capability. When another
student responds to this question it this linkage is stored on the I-MINDS
database. New messages can respond to either the original message or any
previous response.
This leads to a tree-like data structure
and is why refer to them as Message Trees.
The above linkage is maintained in Message_Tree table in the I-MINDS
database. Because each message has a
unique Message_ID it is possible to construct a Message Tree at any time. The MessageTree class included in this
project file does just that. By using a
recursive algorithm on the I-MINDS database the stored messages can be
extracted and added to a tree view data object to facilitate display.
1.4.
Buddy Group Tags
The teacher message uses the following
format:
<to>toBuddies variable</to>
<message>message
string</message>
<ID>message ID</ID>
<from>sender
identifier</from>
The Buddy Group capability uses the same
type of message passing architecture as Question Answering. The only addition is the ID tag. This tag stores the unique Message_ID from
the database. We felt that this was more
compact and efficient to send both the message and its ID through the
ConferenceXP sendObject method. In this
way the message content is available to the other instances of the capability
without having to query it from the database but the ID (primary key) is
available when and if it is needed. This
allows the entire record to be extracted from the database through a simple
select query.
In Buddy Group, the toBuddies variable is
used instead of a specific identifier.
It is the responsibility of the individual instances of the capability
to filter the messages received. This is
done by considering the sender identifier.
This identifier is compared to the list of identifiers in Buddy Group
for this participant. If a match is
found the message is displayed, otherwise it is ignored.
2. Statistics
2.1.
Statistics Tracked
This class is designed to facilitate the
collection and display of the statistics that are tracked by the Buddy Group
capability. Currently, there are 14
statistics organized into 5 groups tracked by the Buddy Group capability. These are summarized below:
Buddy Messages Group
- The number of messages the student has sent this
session.
- The average number of messages the student has sent
over all sessions.
Teacher Messages Group
- The number of messages the student has sent to the
teacher this session.
- The total number of messages the student has sent to
the teacher.
Responsiveness Group
- The number of responses sent by each student. Here response is defined as a message
with a link to a previous message.
- The average amount of time it takes for the student to
respond to a question. This would
be measured by subtracting the timestamp of the response from that of the
question.
- The average number of responses each student receives
for each question.
Topics Started Group
- The number of questions asked by each student. Here question is defined as a message
with no link to a previous message.
- The average amount of dialogue each question asked by
the student creates. Here dialogue
is defined as sum of all messages all the messages nodes and leaves of the
message tree with each question as the root.
- The quality of the question if it were asked to the
teacher. Here quality is defined as
the score given to the question by the keyword ranking class based on its
keywords and length.
Dialog Involvement Group
- How involved each student is in dialogue for questions
they asked (both count and averages).
Here involved is defined as the number of messages found in the
message tree with each question as the root.
- How involved each student is in dialogue for questions
they did NOT ask (both count and averages). Here involved is defined as the number
of messages found in the message tree with each question as the root.
2.2. Statistics
Menu
The Statistics form contains two
Menus--'Statistics Visible' and 'Calculate'.
The first menu is nested and contains menu items for all the groups and
all the statistics tracked. Checking or
unchecking an item causes the column width for that item in the DataGrid to
toggle between visible and invisible.
There are 'select all' menu items at both the top and the group
level. Checking 'select all' at the top
level causes all menu items to be selected, while unchecking 'select all' at
the group levels merely unchecks all the items for that group.
The Calculate menu contains four options
to determine how many sessions should be considered by the Statistics queries. These options are--all, last 5, last 10, last
20 Sessions. Choosing a number of
sessions other than all reduces the amount of time required to compute the
Statistics. If there are fewer than X
sessions, choosing last X is equivalent to choosing all sessions. See figure 2.1 for an example of the Statistics
form.
Figure 2.1:
Statistics form for Buddy Group
3. Database
The I-MINDS
database is currently running MySQL version 4.1. In the future we intend to switch over from
MySQL to SQL Server or something similar.
The basic structure should easily transfer over to any relational
database. The database was designed
using a combination of DBDesigner4, an open source designer from fabForce, and
phpMyAdmin-2.6.3. For an illustration of
the I-MINDS database consult figure 3.1 below.
The mysqldump textfile of the database can be found in the same folder
as the source code.
On the C# side,
the database hook is contained in the ComponentTestLibrary.dll. This dll, whose source is provided, consists
of a ComponentModel class called DatabaseWrapper and another class called
DatabaseMethods, along with the dataset schema DataSet1.xsd. The DatabaseWrapper class consists of
numerous DataAdapters designed with the form editors. The dataset schema was generated from these
DataAdapters using the wizard.
Figure 3.1:
The DBDesigner model for the I-MINDS database
Wherever
possible we have tried to conform to the C# database connection model, filling
the dataset from multiple DataAdapters.
The tables in the dataset can then be hooked to DataGrids or DataViews
for display. We use OdbcCommand builders
to generate both the update and insert queries with two exceptions. We the Keyword_Ranking and Message
DataAdapters we experienced numerous DatabaseConcurrency exceptions which
claimed that 0 rows were updated.
Despite much experimentation we were unable to lock down this
exception. Our solution was to write our
own Update and Insert queries and run them on each row in the DataTables based
on row states. This seemed to eliminate
the problem.
4. Installation
This section
leads you through the installation for ConferenceXP and our capabilities. The first program to install is the
mysql-connector-odbc-3.51 driver. We
have included this with our source code.
Next, if you have not already done so download the CXP Client version
3.2. Before you install it make sure
that the Microsoft Journal Viewer has been installed. Please consult the ConferenceXP client
installation guide for more information.
We provide the
database dump file so that users can upload the I-MINDS database to their local
server. The installation is relatively
straight forward assuming you have access to MySQL server version 4.1 or
higher. Table 4.1 gives the console
command. If your machines do not have
access to the internet you will need to install your own venue service on one
of your machines. The Venue Service can
be downloaded from the ConferenceXP website.
mysql –uusername –ppassword <
iminds.sql
Table 4.1: console
command to upload database
Alternatively,
you could connect to the I-MINDS database running on cse.unl.edu. The user name and password are given in Table
4.2. A word of caution though, the I-MINDS database on CSE is our test bed and
is subject to design revisions which could break previous versions of Q&A
or Buddy Group.
Site: cse.unl.edu; Database: lmille;
MySQL user: lmille; MySQL password: GNEZWS
Table 4.2: connection
information for the I-MINDS database on CSE
To run either
capability you must first create an ODBC data source in Windows XP. This data source is what the C# code will use
to connect to the database. To do this,
open Administrative Tools/Data Sources (ODBC).
Add a new System DNS with the above information (see figure 4.1). If you are running your own MySQL server the
Server, User and Password entries may change from figure 4.1.
Figure 4.1: Data Source for
the I-MINDS database.
The Buddy Group or
Question Answering capabilities should be pasted into the CXPClient folder in
the manner of all capabilities. You
should also paste the ComponentTestLibrary.dll into the same folder. The Stemmer folder containing combiner.exe and
the licenseI-MINDS rtf file should each be pasted into the CXPClient
folder. Remember that there are two
separate versions of the Q&A capability (teacher and student). The Question Answering capability uses the
xApplication4 payload type while Buddy Group uses the xApplication5 payload
type.