A Declarative Specification Language for Learning Behavior Supervision

---

As we discussed in the main project, in order to facilitate the application of the scaffolding theory, we developed a declarative specification language. An instructor can use a graphical user interface to design a specification program, which allows adaptive course contents and adaptive distance-learning tools. The specification program is an underlying engine, which performs a bookkeeping duty, for the instructor to use to analyze individual learning behavior via the activities of students on a virtual campus. Even though the specification language looks complicated, the programming is through a dialogue window. Thus, users will not need to know the syntax of such a language. However, the dialogue box, which was carefully designed, will allow different options. The specification program is generated after the dialogue box is completed. We discuss the syntax and semantics of the declarative specification language, and will illustrate the dialogue box interface.

The declarative specification language controls two types of navigation super- vision:

• Course Content Navigation Supervision

• Campus Navigation Supervision

By course content navigation, while an individual student navigates through Web-based course content, a different sequence will be guarded by an underlying intelligent agent. The agent follows the rules defined in the specification program. On the other hand, campus navigation is also controlled by an intelligent agent, with a restriction of which communication tool, or campus location, that an individual can use or visit. Campus navigation will be implemented via a set of globally defined campus regularities, which can be declared in the specification program. In our discussion, literal constants (i.e., specific text constants) are given in between double quotes. Typed names (i.e., the characteristic of a variable) are in capital letters. And, “*” represents 0 or multiple occurrences of an instance. On the top level, a declarative specification program will look like the following:

Variable Declaration

DataType var-name (*)

Rule Declaration

if Condition then Action (*)

State Declaration

Declare “Open Plaza” as StateDeclarationSection

Declare “Classroom” as StateDeclarationSection

Declare “Faculty Office” as StateDeclarationSection

Declare “Discussion Room” as StateDeclarationSection

Declare “Library” as StateDeclarationSection

The first section is for variable declaration. Variables include system default variables and user-defined variables. The former is defined to control communication tools or state transitions of a virtual campus state machine. User variables are declared by an instructor. An instructor can use some campus rules to control the navigation of students. The second section is for rule declaration, which is a number of if–then like statements. A list of predefined conditions and actions will be provided. The third section consists of the declarations of five states. These five states represent the control strategy of the five scenes defined in our virtual campus. Basically, each of these five sections of state declarations is the same as the upper portion of a specification program. The upper portion of a program contains a set of “global” declarations. That is, the variables and rules declared in the upper portion should be followed and can be used in any of the five states. However, rules or variables in a state cannot be used by another state. Thus, the formal syntax of the StateDeclarationSection is as follows:

• StateDeclarationSection ==

  • Variable Declaration

    • DataType var-name (*)

  • Rule Declaration

    • if Condition then Action (*)

Note that, the sign “==” means “is defined as.” It is easy to see that the above syntax of a state is the same as the global portion. Thus, in our interface design, “global” means the global portion, while each state is indicated by the respective names.

There are a few types of declarations that define “what is the variable (or object).” The formal syntax of type declarations is as follows:

DataType ==

SCO

| MSG

| VAR

| SNAME

| CT

The symbol “|” means “alternative.” There are five types that can be used. Type SCO represents a sharable content object. Following the definition of SCORM, a SCO is a fundamental reusable object. In our system, we aim to follow the SCORM specification to design course contents. These content sections (i.e., SCOs) will be manipulated by the specification program. Thus, it is necessary for an instructor to define a few variables of SCOs such that some contents can be “dropped” or “loaded” upon demand. The “MSG” type allows an instructor to display a text message on the screen. Sometimes, a system administrator should issue a global warning, such as “Virtual campus will be temporarily shut down. Please back up your materials.” The “VAR” type allows an instructor to declare a variable that can hold a literal value (i.e., a simple ASCII string). Literal variables can be used as condition holders. With assignment statements (to be discussed) and conditional rules, the instructor can design action controls based on the inputs of students. The above three types of declarations are “external” types. That means that the above three types are used by the user(i.e., the instructor). The other two types (i.e., “SNAME” and “CT”) are “internal” types that can only be used by our system. There are a few variables predefined in our system of these two internal types. The type “SNAME” represents the name of states. Five state variables are defined:

StateName ==

“Open Plaza”

| “Classroom”

| “Faculty Office”

| “Discussion Room”

| “Library”

where “Open Plaza” is a log-in state (the initial state of the state machine). These five states are for the five campus scenes discussed at the beginning of this document. The type “CT” denotes communication tools. We define five types of communication tools in this environment:

CommunicationTool ==

“SharedWeb”

| “ChatRoom”

| “Whiteboard”

| “AudioConf”

| “VideoConf”

where “SharedWeb” is the 3D campus, displayed via the shared Web. “SharedWeb” is a default tool, as is the “ChatRoom” tool. This indicates that these two types of tools will be used all the time. However, the remaining three types of tools—white board, audioconference, and videoconference—are optional. And, the specification program can enable or disable the tools upon the design of an instructor.

The second portion of a program section contains a number of conditional rules. A conditional rule consists of a condition and an action. There are conditions the user can use, as follows:

Condition ==

SStatus eq “Incomplete”

| SStatus eq “Complete”

| Var eq “literal-value”

| OnAgentSpecificTrigger

The two reserved words “Incomplete” and “Complete” indicate the status of a state (there are five states in total). It is up to an instructor to define whether a student completed some actions in a state (such as finished a discussion session or turned in an assignment). The third declarative statement means that a variable holds a literal value. A literal value can be assigned by an assignment statement. The last kind of statement allows intelligent agents in our system to generate specific signals. These signals include the following:

OnAgentSpecificTrigger ==

PublicAnnouncement-SystemMaintenance

CampusAlert-CapacityFull

CampusAlert-YouAreTooTalktive

CampusAlert-...

StudentViolation-ClassAbsent

StudentViolation-AssignmentDue

StudentViolation-LibraryBookDue

StudentViolation-...

For instance, while the administrator is about to perform a system backup of student states and log files of the chat room, the PublicAnnouncement- SystemMaintenance signal is generated. Other signals (such as the limitation of the number of students that can simultaneously log-in to the system, whether a student is always hanging around and chats with others, etc.) can be defined accordingly. In addition, classroom activities (such as whether a student had already turned in the homework, or if a student missed a class) can be defined in a similar manner.

With the above conditions, a number of action controls need to be implemented to guard students while they are in the virtual campus or visiting a Web site. We define a list of actions below:

Action ==

Drop SCO

| Load SCO

| Enable CT

| Disable CT

| Show ControlButton

| Hide ControlButton

| SStatus = “Incomplete”

| SStatus = “Complete”

| UserInput Var

| Display MSG

| Transit StateName

| Transit “Exit”

In a Web site navigation sequence, the instructor can decide whether to drop or load a particular section of course content (i.e., SCO). In a similar manner, the instructor can decide if a communication tool should be disabled or enabled. There is a set of predefined “control buttons” for students to use. These control buttons can be hidden to forbid their usage. The “SStatus = “Incomplete”” is an assignment statement used to set the value of a state to incomplete (another for “complete”). The “UserInput Var” statement will bring up a dialogue box and ask students to enter a literal value, which is assigned to the variable “Var.” In some situations, a message should be displayed by the “Display MSG” statement. In a state machine, the most important function is the “Transit” statement. The statement changes the current state of a student. The last state, the “Exit” state, is used before the student logs out of the system.

As we mentioned before, there is a set of predefined control buttons in each scene in the virtual campus. A few buttons that can be used are defined below:

• Virtual campus action buttons:

• Beckon: Make a signal to other students

  • Handshake: Shake hands with another student

  • ExchangeMaterial: Exchange a file or a short private message with another student

  • SitDown: Sit down on a chair

  • StandUp: Stand up

  • PositiveCountenance: Indicate that the student is happy

  • NegativeCountenance: The student is not happy

  • NextScene: This button depends on where the student may be; it is a destination-dependent button

  • [Navigation]: The student can use keys and mouse moves to decide which direction to navigate

• Action buttons to control communication tools:

  • InitiateWB: Start a white board

  • TerminateWB: End a white board

  • InitiateVC: Start a videoconference

  • TerminateVC: End a videoconference

  • InitiateAC: Start an audioconference

  • TerminateAC:: End an audioconference

  • AskQuestion: Ask a question to another student or the instructor; the button will start the recording

  • SaveAnswer: End the recording

These buttons are designed for all scenes in the virtual campus. In addition, there are specific buttons for each scene:

• Buttons for Open Plaza

  • CallForAttention

• Buttons for Classroom

  • RaiseHand

  • LowerHand

  • TurnInAssignment

• Buttons for Faculty Office

  • TurnInAssignment

  • MakeAnAppointment

  • CancelAnAppointment

• Buttons for Discussion Room

  • ReserveADiscussionRoom

  • CancelADiscussionRoom

• Buttons for Library

• SearchReference

• ReserveABook

• CheckOutABook

• CheckInABook

The meanings of the above buttons are as clear as their names. The above buttons (common buttons and scene-specific buttons) control the status of each student. Thus, each student will be controlled by an individual state machine, while they are in the campus or watching a Web course. Based on the log of students, the system will analyze student behavior. We will discuss the analysis procedure in the following sections.

Before we end this section, we give an example of a specification program that can be generated by the graphical user interface:

Variable Declaration /* Global specification */

MSG GlobMsg “Please save your chat room log.”

MSG Msg1 “Please turn in your assignment.”

Rule Declaration /* Global specification */

if PublicAnnouncement-SystemMaintenance then Display GlobMsg

if PublicAnnouncement-SystemMaintenance then Transit “Exit”

is StudentViolation-AssignmentDue then Display Msg1

State Declaration

Declare “Open Plaza” as /* Local specification */

Variable Declaration

SCO CourseUnitA

CT Whiteboard

CT VideoConf

Rule Declaration

• if StudentViolation-ClassAbsent then Load CourseUnitA

  if StudentViolation-ClassAbsent then Transit “Classroom”

  if CampusAlert-CapacityFull then Disable VideoConf

  if SStatus eq “Complete” then Enable Whiteboard

  if SStatus eq “Incomplete” then Display Msg2

Declare “Classroom” as ...

Declare “Faculty Office” ...

Declare “Discussion Room” ...

Declare “Library” as ...

As one can see, it is not easy for an instructor to type in the above example program. So, we designed a user-friendly interface that is shown in Figure 9. Because the amount of constants in our declarative specification language is limited to a small number, it is easy to incorporate all of the options for a particular instance by using a pull-down menu bar. However, some of the default values, such as the URL of a specific sharable content object (SCO), should be given in a text box by the designer. There are two internal data types: SNAME and CT. Five default states are designed, and five types of communication channels are implemented. The designer (i.e., the instructor) does not need to worry about these system-specific items. However, the designer should be aware of the concept of status inheritance, as all of the properties of the global state should be inherited by a local state (e.g., Library), while the student is in such state. Note that, for each student, the system keeps a transition state. In general, the state machine consists of five default states that comprise a nondeterministic finite state automata (NDFA). However, it is easy to use an algorithm to transfer a NDFA to a deterministic finite a declarative specification program.

Figure 9: The graphical user interface of the declarative specification

While a student navigates through the virtual campus, a few items will be recorded:

• The international states visited in the NDFA

• The types of communication tools used, including the frequency and duration

• The SCO (course units) visited, including frequency and duration

• The values of state variables

• The declarative rule fired by the action, which includes the following:

  • Completeness of state transitions

  • The Campus Alert types of agent triggers

  • The Student Violation types of agent triggers

  • The control buttons of virtual campus navigation pushed

In addition, chat room logs (discussed in Subproject 3) and question–answer logs (discussed in Subproject 2) will be recorded. A statistic summary will be generated after each session of navigation of each student (for an optional review by the student). This information can be used to find the popular locations (such as which class and which discussion room), popular communication channels, types of triggers fired by the system, and others.

The specification language defined so far is primitive. While we are implementing the project, additional rules and states may be introduced.

The virtual campus should have a few types of patrols. The concept is similar to the one used in a traditional university. For instance, an overdue periodical check-out is not returned, an assignment is not turned in, class is skipped, there are impolite discussions in a chat room session, an appointment with a professor (or a student) is missed, and so on. Virtual campus regularity will be designed. Yet, these are university policies. The actual definition of campus regularity is an open issue. However, as long as a rule is defined, there must be an underlying virtual patrol (as an intelligent agent program) running under the system. The virtual patrols can send an online message to a student (or instructor) or send an offline e-mail. More seriously, a virtual campus may prohibit the action of an individual. For instance, if a student always comes to the virtual university and just talks to friends, without attending any classes, the student may be restricted to access of the chat room. Regular violation will be summarized and analyzed. The outcome can be used as a reference for us when redesigning the virtual campus facility and policy.

---