|
|
CXP-Powered I-MINDS Capabilities 3.0 |
BuddyGroup
3.0
This BuddyGroup
capability was completed in February 2006 and revised in May 2006, and revised
again in December 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. Buddy Group
1.1.
Introduction
In version 2,
buddy group was its own capability modified from the chat capability included
with ConferenceXP. In I-MINDS version 3,
buddy group is a capability mode of merged capability. It retains the same form as the original
capability with text boxes for displaying received messages and entering new
messages. This mode 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 three items: ‘Display Statistics’, ‘Database Search’ and
‘Manage Buddy’, the first two of which are described in the next section. The ‘Manage Buddy’ option is described, along
with its form, in section 2.4. In figure
2.1 we show an example of the Buddy Group capability form.
Figure 1.1. The Buddy Group
capability form
1.2. Flow of Control
Unlike the question answering mode in
merged capability, there is only one version of buddy group. This mode is designed to be used by both teachers
and students simultaneously. The buddy
group mode connects to the I-MINDS database through merged capability agent
class, described above. Participants can
send messages to each other by using the buddy group mode. These messages are composed into a Message
object using the methods in merged capability agent, described above. The tags used from table 1.1 are
Buddy_Message and Buddy_Response. These
Message objects are then multicast using the SendObject method to the rest of
the classroom. It is important to
mention that only participants running buddy group mode in merged capability
who are in the sender’s classroom will receive the message and only
participants in your buddy group will display it. This process is described in more detail in section
2.4, below.
In the buddy group mode, 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 2.2 for an example. This will cause the MessageTree form to
become visible, displaying the tree view for the message tree (figure 2.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 ‘Database Search’ item in the options
menu brings up a form where participants can search for specific messages. There are many filter options that the user
can specify including: message substrings, sender identifier, message type, and
even the dates received. The database
search form acts as an interface for users who wish to query the I-MIND
database for messages sent in previous sessions. This is helpful for users when they miss a
session or are trying to find new buddies.
In the current version, there is no provision for proprietary
information in the I-MINDS system; all logged messages are available to any
participant.
1.3. New Concepts
It is worth pointing out that messages
for this capability mode and those for the question answering mode 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 question answering) have their recipient flag
set to 'TEACHER'. All messages sent by
buddy group have their recipient flag set to 'BUDDIES'. In version 3, we have added two new recipient
flags and modified the existing ones.
These new recipient flags are summarized in table 2.1.
Table
2.1: Changes to Recipient Flags
|
BUDDY-MESSAGE |
--> |
Message starting new topic |
|
BUDDY-RESPONSE |
--> |
Response to existing message |
|
TEACHER-QUESTION |
--> |
Question to teacher |
|
TEACHER-RESPONSE |
--> |
Response to question |
For buddy group 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 buddy group form. 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 Manager
In the pervious
version of I-MINDS, we provided a dropdown menu of online participants for the
user to select his or her buddies from.
This had the disadvantages that both the user and her respective buddy
had to be online at the same time, for the buddy relationship to be
established. In the new version of
I-MINDS we have added an entirely new interface for adding buddies, called the
buddy manager. Figure 2.4 shows a
screenshot of the buddy manager form.
The buddy manager becomes visible whenever the user selected ‘Manage
Buddy Form’ from the options menu in the buddy group mode. The buddy manager form shows all the
participants who are currently stored in the I-MINDS database and indicates
whether they are on or offline. There
are two checkboxes for each participant, one for adding the participant as a
buddy and the other for adding her as a buddy, temporarily. Temp buddies are counted as buddies for
purposes of receiving messages, but the relationship is asymmetric rather than
symmetric.
Figure 2.4:
Buddy Manager Form
Maintaining the
symmetric relationship between buddies requires a fairly complicated
handshaking procedure between the two participants and the I-MINDS
database. When you remove a buddy a
message is created use the Remove_Buddy tag and that message is sent to your
old buddy. The database immediately
removes your old buddy from your buddy group.
When your old buddy receives the Remove_Buddy message, her agent will automatically
remove you from her buddy group as well and inform her of this fact. Adding a new buddy is somewhat more
complicated because we must wait until your new buddy accepts the invitation to
become buddies. When you check the Buddy
box for a participant, your agent sends an Add_Request message to your
potential buddy. When the message is
received, her agent will popup a confirmation box asking her if she would like
to add you as a buddy. Based on her
decision, her agent sends one of the following three response messages: Add_Buddy, Response_Not_Added,
Response_Cannot_Add. The first indicates
that she has added you as a buddy; your agent will then add her to your buddy
group. The second indicates that she has
declined your offer of being a buddy and the third indicates that she cannot
become your buddy because her buddy group is full.
In version 3, it
is possible to both add and remove buddies who are offline as well as
online. This is done by maintaining an
offline mailbox of messages in the I-MINDS database. If you try and add a participant as a buddy
who is offline, your agent will leave her a message in the offline
mailbox. The next time she logs on her
agent will check its mailbox and present her with the same confirmation
box. Depending on your status, her agent
will either send a message directly or leave your agent a message with her
decision.
5. Database
The I-MINDS
database is currently running MySQL version 5.
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 5.1 below.
The mysqldump textfile of the database can be found in the same folder
as the source code.
Unlike in
previous versions, in version 3 we have completely done away with the
ComponentTestLibarary.dll which contained DataAdapters. The merged capability class now has its own
database connection object, which is set to look at the DSN described in the
section 6 below. The merged capability
agent class now contains almost all of the database queries necessary to run
both merged capability and the buddy group and question answering modes. Certain peripheral classes such as the
MessageTree still maintain their own data tables, but use the database
connections stored in merged capability.
Figure 5.1:
The DBDesigner model for the I-MINDS database
As you can see
from figure 5.1, the database for I-MINDS version 3 has become fairly
complicated. It has grown considerably
from the one used in previous versions.
New tables were added to support the concept of classrooms. As a matter of fact, the classrooms table is
now the heart of the database replacing the sessions table from version 2. We have retained the message table but added
several new variables to support future work on agents. Several new tables have been added to support
the forthcoming structured group mode and the new buddy manager form in the
buddy group mode. There are several
satellite tables used for recording statistics on PGM experiments. The use of these tables will be addressed in
future technical reports.
6. 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.5. 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 6.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 6.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
6.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 the
capabilities.
Site: cse.unl.edu; Database: lmille;
MySQL user: lmille; MySQL password: GNEZWS
Table 6.2: connection
information for the I-MINDS database on CSE
To run the
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 DSN with the above information (see figure 6.1). If you are running your own MySQL server the
Server, User and Password entries may change from figure 6.1.
Figure 6.1: Data Source for
the I-MINDS database.
The merged
capability should be pasted into the CXPClient folder in the manner of all
capabilities. The Stemmer folder
containing combiner.exe and the licenseI-MINDS rtf file should each be pasted
into the CXPClient folder. There is also
an images folder used by the virtual classroom which should be pasted into the
same location. Remember that there are
two separate versions of the merged capability (one for teacher, another for
student).
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.
5. Change Log
This section
covers the changes the I-MINDS team has made to the BuddyGroup capability with
version 2. These changes include
additional features, bug fixes, and database structure changes. None of these changes break the functionality
described above.
5.1.
Data Adapters
One significant
change we made in this version is how the database is accessed by our source
code. In v1 most of our source code
other than the statistics class used C# DataAdapters to access the
database. In brief, DataAdapters select
all the records in a table and populate a C# DataTable with the results. This can be very convenient because once the
DataTable is populated you can manipulate the data (add, remove, update
records) without querying the database.
However, we encountered horrible concurrency issues with this
implementation (see figure 5.1). Because
of the way capabilities work, it was very difficult to synchronize all the
DataAdapters. This led to all sorts of
bizarre errors relating to database concurrency. The decision was made to remove all the
DataAdapters and replace them with SQL queries throughout the BuddyGroup
codebase. This eliminated the
concurrency errors because all the students were dealing directly with the
database (see figure 5.2).
Figure 5.1: Buddy Group v1 Design
Figure 5.2:
Buddy Group v2 Design
5.2. MAX(Session_ID)
In v1, the
Session ID was determined by simply taking the MAX(Session_ID) from the
database. This worked well until we
started using Question Answering at the same time. A scenario occurred where Buddy Group was
started and students joined and queried for their Session ID. A Question Answering capability was then
started incrementing the Session ID. If
additional students join the Buddy Group they will no longer receive the
correct Session ID.
In v2, the
Session ID is determined once when the capability is created. It is then broadcast to each participant when
they join the capability. In affect, the
Session ID is “buffered” for all participants.
Because of this, when the participant who started the capability leaves
the Session ID is not lost. This also
solves the problem where a student accidentally starts up another Buddy Group
capability. Now Buddy Group and Question
Answering can coexist peacefully without corrupting the database.
5.3. Students_In_Buddy_Group
and Students_In_Session
In v1, both
these tables were N:M linking tables connecting two other tables. The limitation on N:M linking talbes is that
each pair of values is a unique primary key.
The database will not allow us to have the same student in the same
buddy group twice, for example. In
affect, we knew which students were in which Buddy Group or Sessions, but that
is all we knew. We wanted to be able to
track which students where in a buddy group during an interval of sessions and
when students joined and left a session.
This required more than just N:M linking tables.
Both the above
tables were replaced with triply-linked tables.
Students_In_Buddy_Group now links with the Session table as well as the
previous two. Students_In_Session now
has a timestamp key for when the student joins the session. To reduce the amount of records triply-linked
tables often produce we wanted to store intervals. This was accomplished by adding a fourth
column to each table which was not a primary key. When records were added to either table this
fourth column was initially null. When
the interval was completed this fourth column would be set. For example when a student is initially added
to Students_In_Buddy_Group a record similar to table 5.1 is added. When and if the student is removed from the
buddy group this record is updated and the Session_Removed value is set (table
5.2). From this one record we deduce the
student with the identifier lmille@cs.eunl.edu
was a member of Buddy Group 22 from session 356 to 412. This saves us 55 records in the database, not
too shabby.
|
Student_Identifer |
Group_ID |
Session_Added |
Session_Removed |
|
22 |
356 |
NULL |
Table 5.1: Students_In_Buddy_Group record
|
Student_Identifer |
Group_ID |
Session_Added |
Session_Removed |
|
22 |
356 |
412 |
Table 5.2:
Students_In_Buddy_Group record
5.4. Load
Messages
In v1, each
message was broadcast to each student immediately after it was added to the
database. This worked fine in practice,
but happens if one of your buddies arrives late? We decided it would be nice to have the
option to ask the database for the messages sent to your buddies for this
session. We added the “Load Messages”
menu item to the Options menu. Pressing
it queries the database for the messages sent during this session. This list is filtered by who your buddies
are. It will not return messages for
students who are not currently your buddies.
These messages are identically formatted to those received in real time.
5.5
MessageTree
The MessageTree
class was modified so that it has the ability to generate a full message tree
for any message regardless of its position in the tree. This is done by first determining the root
for message tree (the message ID which started the topic) and then generating
the full subtree from this message. This
reduces the complexity of some of the queries in the Statistics class
considerably. The MessageTree class can
be configured to only generate the subtree for the given message ID.
5.6 Statistics
It was
determined through testing that several of the statistics queries in v1 where
not returning exactly the results we wanted.
A minor change to the way we stored messages in the database
considerably reduced the complexity of some of the queries while increasing the
validity of their results. This was done
by storing whether or not the message was a topic-starter or response in the
Message table. The Recipient column now
contains the value “BUDDIES-TOPIC” or “BUDDIES-RESPONSE” where
appropriate.
The queries in
v1 for Dialog Involvement only looked at the responses and their parents. Thus they only worked only for message trees
of max height 2. In v2, we can query for
all the messages that are “BUDDIES-TOPIC” and use the full message tree feature
described above in MessageTree to compute the statistics for message trees of
any height. We were also able to clean
up some of the statistics queries in v2 such as those for
ComputeAverageResponseTime. All queries
now check the same session interval. In
v1, ComputeSessionMessages and ComputeSessionMessageToTeacher (along with their
averages) did not use this session interval determined by the Calculate
menu. This has been fixed in v2.
5.7 Database
Search
The Database
Search form can be used by both students and teachers to look up both messages
and users in the database. Messages are
searchable based on the message itself, the sender, the group they were sent
to, by score, by session, and also by time and date the messages were received,
answered, or discarded. Any combination
of these properties can be used at once thanks to intelligent querying. Students are searchable by name and
identifier. The Database Search form is
accessible from the Options menu.