Project

General

Profile

GIFT glossary

Jump to section: A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

AAR

See After-Action Review

<top>

ActiveMQ

Open Source Messaging server used by GIFT for communication between modules. See ActiveMQ

<top>

Affective State

The 'emotional state' of the learner, as opposed to the 'mental state'. Measures of affective states can include anger, anxiety, boredom, fear, stress, joy, happiness, frustration, and others.

In GIFT, the Learner Module determines this state and then communicates it along with cognitive and performance states in order to give a 'picture of the learner' to the pedagogical module. The pedagogical module can then make instructional strategy selections using the learner state.

<top>

After-Action Review (AAR)

In the GIFT context (at least as of GIFT 2.0), after-action review (AAR) refers to the display of the learner's performance, via the Tutor User Interface. The AAR is typically presented at the conclusion of the domain session; however for courses containing multiple training app sessions, intermediate AARs may be shown.

May also be known as a 'Hot Wash' or 'Debrief'.

<top>

Assessment

An assessment in GIFT is anything that can result in a change in learner performance as tracked by the GIFT learner state. Examples include conversations and DKFs. Performance is just one of three categories contained within a GIFT learner state (the others being Affective and Cognitive states). Assessments are normally calculated in real time while the learner is performing some interaction such as a VBS scenario or conversation tree.

<top>

Bookmark

Time-stamped instructor-created textual annotation created via the bookmark panel of the Monitor Module. Bookmarks are stored in a bookmarks file for each Domain Session and are stored in GIFT\output\logger\tools. Bookmark files are created on-demand, so domain sessions without bookmarks will not have a bookmarks file.

<top>

Camel

Open source integration framework integrated with ActiveMQ and used by GIFT to achieve transparent routing of messages to the Monitor Module and to the UMS (for logging). See http://camel.apache.org/

<top>

CAT

See Course Authoring Tool

<top>

Check on learning

This is another name for the recall phase of the adaptive courseflow course object. A check on learning is used to determine the level of knowledge a learner has on one or more course concepts. This can take the form of a question bank survey in a GIFT course.

<top>

Clusterer (sensor context)

A program (or program component) which is able to use artificial intelligence methods to draw similarity metrics between data. This program will typically make use of unsupervised learning. Examples of common clustering methods include k-Means, hierarchical, and density-based. More information is available at http://en.wikipedia.org/wiki/Cluster_analysis.

<top>

Cognitive State

The 'mental state', rather than 'emotional state' of the learner. Measures of cognitive states can include attention, engagement, drowsiness, workload, flow, and others.

In GIFT Learner Module messages, this is communicated along with affective state and performance state in order to give a 'picture of the learner' to the pedagogical module, and instructional strategy selection.

<top>

Collaborator

Individual or organization using or developing GIFT software without funding from ARL.

<top>

Condition

A condition is the lowest level (i.e. a child node if using a tree structure analogy) of the Task/Concept performance assessment hierarchy. A condition is responsible for assessing performance during a domain session.

GIFT configures conditions using a domain knowledge file (DKF) during runtime.

<top>

Contributor

Individual or organization using or developing GIFT Software with funding from ARL.

<top>

Course

A unit of instruction on an individual subject that usually has a set duration during which students are typically required to do various kinds of work in order to earn a certificate of completion, a grade, or simply a sense of accomplishment.

In GIFT, a course spans the length of a domain session. The list of available courses is shown to the learner for selection on the TUI. The default flow of a course is specified by a course XML file that should be authored using the CAT. Course XML files are stored in the Domain folder (as referenced by the 'DomainDirectory' Domain module property in domain.properties).

<top>

Course Authoring Tool (CAT)

XML editing tool used to create and edit GIFT course (i.e. *.course.xml) files. The course authoring tool is provided with GIFT as of version 2.0.

<top>

Courseware

A unit of instruction on an individual subject that usually has a set duration during which students are typically required to do various kinds of work in order to earn a certificate of completion, a grade, or simply a sense of accomplishment.

<top>

DAT

See Domain Knowledge File (DKF) Authoring Tool

<top>

Debrief

See After-Action Review

<top>

DIS

See Distributed Interactive Simulation (protocol)

<top>

Distributed Interactive Simulation (protocol)

IEEE Standard for real-time network interoperability between simulations. See Distributed Interactive Simulation on Wikipedia.

<top>

Distribution Agreement

Formal documentation required for access to the GIFT software via the GIFT Portal. Before access to GIFT software is granted, a distribution agreement must be submitted and approved.

Current Distribution Agreement

Update: As of version 2.0, GIFT is being released under Distribution Statement A. Thus a distribution agreement is no longer required.

<top>

Distribution Statement A

Distribution Statement governing distribution of GIFT version 2.0, which reads as follows:

Distribution Statement A: Approved for public release; distribution is unlimited

<top>

Distribution Statement C

Distribution Statement governing distribution of GIFT version 1.1, which reads as follows:

DISTRIBUTION STATEMENT C: Distribution authorized to U.S. Government Agencies and their contractors. Administrative and Operational Use, 19 July 2012. Other requests may be referred to the Army Research Laboratory - Human Research and Engineering Directorate (HRED), ATTN: Associate Director for Science & Technology, 12423 Research Parkway, Orlando, Florida 32826.

Generally, the change for DIST-D to DIST-C represents the inclusion of a wide variety of other agencies outside the DoD.

Examples of Organizations able to use under DIST-D: DoE, DoEd, Mathematica (as a contractor for Institute for Educational Sciences), most postdocs (as contractors for NSF, or equivalent).

<top>

Distribution Statement D

Distribution Statement governing distribution of GIFT version 1.0, which reads as follows:

DISTRIBUTION STATEMENT D: Distribution authorized to the Department of Defense and U.S. DoD contractors only due to ctirical technology, effective due to critical technology. Other requests shall be referred to PCO.

Examples of Organizations able to use under DIST-D: USN, AFRL, Northrop Grumman (while under DoD contract).

<top>

DKF

See Domain Knowledge File

<top>

Domain

An area of instruction. Examples include conducting a presence patrol, firing a weapon with accuracy, giving first aid, and virtually any other skill/knowledge which can be taught.

<top>

Domain Module

The Module of GIFT which is responsible for providing assessments of user ability/knowledge, and responding to instructional strategy requests.

<top>

Domain Knowledge File (DKF)

XML file containing domain specific rules for performance assessment, strategies, actions, etc. Read during domain session initialization by the Domain and Pedagogical Modules.

Currently the best way to author a DKF is to use the DAT.

DKFs are stored in the Domain folder (as referenced by the 'DomainDirectory' Domain module property in domain.properties)

<top>

Domain Knowledge File Authoring Tool (DAT)

XML editing tool used to create and edit Domain Knowledge Files (DKF's). The course authoring tool is provided with GIFT as of version 2.0.

<top>

Domain Module

GIFT Module responsible for the following key functions:

  • Assessing learner performance.
  • Communicating learner performance to the Learner Module.
  • Implementing pedagogical requests given by the Pedagogical Module. GIFT 2.0 Pedagogical requests are:
  • Instructional Intervention (e.g. Feedback)
  • Scenario Adaptation
  • Request Performance Assessment

Domain specific rules for performance assessment are defined in the Domain Knowledge File (DKF) and read by the Domain Module at the start of a training application session.

<top>

Domain Session

A domain session describes the window of time from when a learner starts a course, to when that course is completed.

Currently we don't support unit training in the same GIFT session, therefore a domain session is unique to an individual.

<top>

Embodied Pedagogical Agent (EPA)

Either a 'talking head' or part of a 'virtual human' whose goal it is to aid instruction.

This differs from a 'virtual human', as virtual humans have emotive responses to learner actions, and are not necessarily inspired to aid learning.

<top>

Evaluation

A type of assessment which occurs at the end of training (if used in training context), or an in-depth examination of a system (if used in a system context). Evaluations differ from assessments in that they are summative (gauge final quality), product-oriented (aligned against a goal), prescriptive (externally imposed standards), judgmental (impose a final score/grade), comparative, and competitive.

<top>

Exercise

An activity consisting of a task or problem or some other effort to be performed that is intended to challenge a student mentally and/or physically. Exercises are usually an element of a course that is not "graded" but is used by the instructor and students to gauge student progress on a given topic.

<top>

ERT

See Event Reporting Tool

<top>

Event Reporting Tool (ERT)

An experimenter tool provided with GIFT for the purpose of the post-analysis of data which is collected as part of an experiment. The ERT provides a web-based interface to select important events from GIFT output and then create an output file that can be used in third party applications, such as Excel, for further analysis.

<top>

Filter (sensor context)

A program or programmatic component which takes in sensor data (either raw or from another filter), processes it, and outputs a single signal.

As an example, consider the following set of filters implemented for real time heart rate detection:
  • a raw QRS signal is taken by an ECG sensor
  • Filter1: a window is taken on the signal (only a certain part of the signal is moved down the filtering line)
  • Filter2: a derivative is taken of a relevant window segment (filter1)
  • Filter3: the square of the wave is taken
  • Filter4: the signal is integrated
  • Filter5: a threshold is applied to the total signal (for heartbeat detection)
  • Filter6: the counting of how often a 'threshold' is detected (per unit of time), and output as an estimation of a number of heartbeats per second (heartrate)

<top>

Filtered Sensor Data

Sensor data which has had one of two actions taken on it:
  • feature extraction (such as taking an ECG or blood pressure signal and determining heart rate from it)
  • basic classification (such as taking a EEG signal and processing it for a measure of 'engagement')

This data is communicated to the learner module for the analysis of correlates with the learner's performance.

<top>

Gateway Module

The primary function of the Gateway module is to listen for communication outside of GIFT and then convert it into GIFT messages and vice-versa.

When a message is received from outside of GIFT (e.g. VBS2 plugin or DIS connection), the Gateway module converts that message into a GIFT message and sends it to the Gateway Module’s topic (i.e. broadcasts the message). Domain module(s) are then free to retrieve that information and provided it to performance assessment logic at their own pace.

To configure the Gateway module and/or build your own training application interoperability interface, refer to the GIFT Configuration Settings document.

<top>

Generalized Intelligent Framework for Tutoring (GIFT)

GIFT is an empirically-based, service-oriented framework of tools, methods and standards to make it easier to author computer-based tutoring systems (CBTS), manage instruction and assess the effect of CBTS, components and methodologies. GIFT is being developed under the Adaptive Tutoring Research Science & Technology project at the Learning in Intelligent Tutoring Environments (LITE) Laboratory, part of the U.S. Army Research Laboratory - Human Research and Engineering Directorate (ARL-HRED).

<top>

GIFT

See Generalized Intelligent Framework for Tutoring

<top>

GIFT Host

A computing platform (hardware & OS) set up and running (or available to run) one or more GIFT Modules.

<top>

Google Web Toolkit (GWT)

Google Web Toolkit (GWT) is a development toolkit for building and optimizing complex browser-based applications. See: https://developers.google.com/web-toolkit/

GIFT web pages built using GWT:

  • Tutor User Interface (TUI)
  • Event Report Tool (ERT)
  • Survey Authoring System (SAS)

<top>

Guidance

An element within GIFT course.xml files that allows information to be presented to the user via the tutor interface to introduce a new section of the course, such as survey, training application session, etc.

<top>

GWT

See Google Web Toolkit

<top>

Hotwash or Hot Wash

See After-Action Review

<top>

Instructional Strategy (DKF context)

Instructional strategies, as referenced by DKFs, are tools available for facilitating learning. In GIFT there are three types of instructional strategies: Request for Performance Assessment, Scenario Adaptation and Instructional Intervention. The DKF instructional strategy context allows the author to configure the available strategies for different circumstances. The strategies in the DKF are loaded into the Domain module (during a domain session) which in-turn is responsible for implementing the necessary logic to present the strategy to the learner.

<top>

Intelligent Tutoring System (ITS)

From Intelligent Tutoring System definition on Wikipedia:

"An intelligent tutoring system (ITS) is a computer system that aims to provide immediate and customized instruction or feedback to learners,[1] usually without intervention from a human teacher."

<top>

Information Technology (IT)

A branch of knowledge concerned with the development, management, and use of computer-based information systems.

<top>

ITS

See Intelligent Tutoring System

<top>

Javascript Object Notation (JSON)

The lightweight data interchange format used by GIFT for inter-module communication. See http://www.json.org/

<top>

Jetty

Open Source pure Java implementation of an HTTP server and servlet container. Jetty is used by GIFT for the GIFT Administrative Server (GAS) and for the Tutor User Interface (TUI) Web Server. See http://www.eclipse.org/jetty/

<top>

JSON

See Javascript Object Notation

<top>

Latent Semantic Analysis (LSA)

A method for analysing the differences between texts. More information can be found at: http://en.wikipedia.org/wiki/Latent_semantic_analysis

<top>

LCAT

see Learner Configuration Authoring Tool

<top>

Learner Action

A learner action describes a specific set of events caused by the learner using the TUI during a domain session. An example of a learner action is when the learner selects the "Use Radio" learner action on the TUI during a domain session (more specifically while using a training application). This is used during the TSP Clear Building sample course provided with the GIFT TSP release. Learner actions are different than training application based information (e.g. DIS traffic such as entity state PDUs) that passes through the gateway module because these events are communicated between the Tutor and Domain modules. The domain module is responsible for handling the action.

<top>

Learner Configuration Authoring Tool (LCAT)

XML editing tool used to create and edit learner configuration files. The LCAT is provided with GIFT as of version 2.0.

<top>

Learner Configuration File

XML file used to configure the learner module. The contents of this file describe how sensor and performance data is classified and predicted upon in order to create a learner state. As research progresses and learner models are built, this file will become less important. For now, it allows for a high level of customization for research purposes.

<top>

Learner Module

GIFT Module responsible for maintaining Learner State.

<top>

Learner State

The learner state is determined by the Learner module and communicated via messages to the Pedagogical module.

The learner state contains the Affective, Cognitive and Performance state with temporal values for current, next and predicted states.

<top>

Learning

The acquisition of new, or modification of existing, knowledge, skills, values, or abilities. It does not happen all at once, but builds upon and is shaped by what we already know. It may happen consciously or subconsciously.

<top>

Lesson

A unit of instruction within a course. Often a single, continuous session of formal instruction.

<top>

Line-of-Sight

In the context of constructive and virtual simulation in a three-dimensional synthetic environment, line-of-sight is a term used to describe the condition that exists when two distinct objects (entities, objects, features, etc.) can "see" each other. Exactly what constitutes "seeing" depends on the line-of-sight algorithm used. In the simplest case a single point is chosen to represent each of the two objects. If a ray between those points is unimpeded (by other objects, entities, features, etc.) then those to entities are said to have line-of-sight.

<top>

LMS

Learning Management System. This is a system which traditionally stores the output of the learner actions. Different levels of LMS have been practiced (at the 'GPA' level, the 'class grade' level, or the 'assignment' level). The LMS, depending on the implementation, may or may not store other information about the learner. GIFT uses the output from course interactions in order to assign 'pass/fail' grades and interactions to an 'LMS' which is only currently limited to a mySQL database. It is envisioned that a more industry-standard LMS at a later time.

<top>

LMS Review

In the GIFT context, "LMS Review" refers to the screen/page presented to a GIFT user (via the Tutor User Interface) immediately after logging into GIFT as a learner. The LMS Review page provides a summary of the current user's prior GIFT sessions.

<top>

LMS Module

The primary function of the LMS module is keep track of a user’s training history. The GIFT LMS will save the scores of every lesson.

<top>

LOS

See Line-of-Sight.

<top>

LSA

See Latent Semantic Analysis

<top>

Metric

A metric is the element between a Concept (or sub-Concept) and a Condition in a DKF. Currently it provides little to the Task/Concept hierarchy and may possible be removed or combined with another element in the Task/Concept hierarchy to simplify discussions.

<top>

Milgaming / Games for Training

The milGaming portal supports the download of Army Games for Training. The milGaming/GfT lab operates out of PEO-STRI in order to meet current military training needs. See: https://milgaming.army.mil/ or http://www.peostri.army.mil/PRODUCTS/USAGFTP/ for more information

<top>

Module (GIFT Module)

GIFT Modules are the basic unit of architecture within the GIFT system. Each GIFT module has well-defined responsibilities and executes as its own process. Modules communicate with each other using JSON encoded messages sent across an ActiveMQ message bus.

Key modules within GIFT are:

  • Learner Module
  • Pedagogical Module
  • Domain Module
  • Sensor Module
  • Tutor Module
  • Gateway Module
  • LMS Module
  • UMS Module

Refer to the definitions of each for more details.

<top>

Monitor Module

This module can be used as an instructor operator station (IOS) and/or experimentor operator station (EOS). It provides, among other things, monitoring capabilities for a GIFT network of modules.

For more information refer to the GIFT Monitor Instructions document.

<top>

MySQL

Open Source SQL database used by GIFT for both the LMS and the UMS. See http://www.mysql.com/

<top>

Pedagogical Module

The primary function of the Pedagogical module is to use information about the learner’s state to select instructional strategies that better influence learning.

<top>

Pedagogical Request

Is the name of the message sent from the Pedagogical module to the Domain module when the Pedagogical model has selected an instructional strategy that needs to be implemented.

<top>

Performance Assessment

In general, a performance assessment is an evaluation of the current/past actions taken by the learner for a task or set of tasks. In GIFT, a performance assessment is determined by the Domain module and sent via a message to the Learner module.

<top>

Performance State

The performance state contains the learner's performance evaluation on the currently executing domain. This state is part of the learner state sent from the Learner module to the Pedagogical module.

<top>

Question Bank

A question bank is a collection of questions for a course that can be selected to build a dynamically generated survey during course execution. Each course can only contain a single question bank. Questions in a question bank are tagged with the course concepts it is assessing and the question difficulty. Question banks can be given as a course object or as part of the Recall phase of an adaptive courseflow course object. The number of questions and difficulty of those questions to provide in the survey can be authored. Assessments of the survey's response are also authored in order to categorize learners as novice, journeyman or experts per concept.

<top>

Remote Launch Service (RLS)

A Java program included with GIFT (as of GIFT version 2.0) that, when running, allows GIFT modules to be launched on the local host, from a GIFT Monitor Module running on remote host. Under GIFT 2.0 we support remote launch within a local area network only.

NOTE: In the initial (GIFT version 2.0) capability, the RLS is not a proper windows "service" but must be launched manually. Optionally, it may be configured to start automatically using facilities of the host operating system. In future versions it may be implemented as a true "Windows Service".

<top>

SAS

See Survey Authoring System

<top>

SCALE

The Soldier Centered Army Learning Environment (SCALE) program exists to provide individualized content to the soldier anywhere, anytime. It intends to do this through a wide variety of means.

<top>

SCAT

See Sensor Configuration Authoring Tool

<top>

Score

A piece of information, usually a number or letter, that conveys the performance of an individual or group on an examination or test.

<top>

Sensor Configuration Authoring Tool

XML editing tool used to create and edit sensor configuration XML files. The SCAT is provided with GIFT as of version 2.0.

<top>

Sensor Configuration File

XML file used to configure the sensors in an instance of a Sensor module.

<top>

State Transition (DKF context)

A state transitions, in a DKF context, refers to the change in learner state from one enumerated value to another for a single attribute in that state. This portion of the DKF is used by author to configure the Pedagogical module on which state transitions are important. As pedagogical models are developed, this portion of the DKF will become less important. For now it provides the researcher greater flexibility in identifying key state transitions and the available instructional strategies available for each transition.

<top>

Strategy

Strategy is the term used to describe the pedagogical action(s) that will occur as a result of a StateTransition.

<top>

Strategy Choice (DKF context)

The list of possible instructional strategy choices is provided to the Pedagogical module via the DKF. It is a sub-element of the state transitions portion of the DKF and provides a list of the available strategies for a particular learner state transition. Again, this allows the author to configure the Pedagogical module in absence of actual Pedagogical models.

<top>

Survey

A survey is a method for collection quantitative and qualitative information about the learner. A survey can be a quiz on domain knowledge.

<top>

Survey Authoring System

The SAS provides a means to author surveys that can be presented on the TUI during a domain session. The SAS provides a web based user interface that displays and allows the user to store surveys from the UMS database.

<top>

Survey Context

Construct used by the Survey Authoring System to provide a local context in which strings can be used to map to specific surveys. A course.xml will reference a specific survey context. Then survey requests are made using strings defined within that context to map to specific surveys.

<top>

Task

As defined by the Army, a task is "a single unit of specific work behavior with clear beginning and ending points that are directly observable or otherwise measurable. A task is performed for its own sake, that is, it is not dependent upon other tasks, although it may fall in sequence with other tasks in a duty or job."

<top>

Training

The acquisition of knowledge, skills, and competencies as a result of the teaching of vocational or practical skills and knowledge that relate to specific useful competencies.

<top>

Training Application (TA)

Any computer program which is used for training. Examples range from a flight simulator, to a web-based interaction environment, to PowerPoint. Part of the vision of GIFT is to support the addition of any/all training applications.

<top>

Transition

In the context of a course.xml file, Transition is an abstraction used to describe the fundamental building blocks of a course. Thus a course is defined more or less by its sequence of transitions. Examples of transitions are: "Guidance", "PresentSurvey", "LessonMaterial", and "Training Application".

Within the a dkf.xml context, Transition is also sometimes used as an abbreviated form of "State Transition".

<top>

TUI

See Tutor User Interface

<top>

Tutor User Interface

In general the TUI is the learner's interface to GIFT. Currently that is a web interface commonly referred to as the web-TUI or WTUI. The TUI can display LMS data, give surveys, present lesson material, display feedback and give AAR.

<top>

UMS Module

See User Management System Module

<top>

User Management System Module

The primary function of the UMS module is to manage a user session. It is responsible for storing information about the user such as biographical details, in addition to maintaining information about domain sessions. It does not, however, keep scoring records of user’s training history. That is handled by the LMS. The UMS also contains the message logger which is responsible for logging all messages sent on a single ActiveMQ network.

<top>

User Session

(from a system design perspective) All of the interactions which a user experiences after login, consisting of the presentation of content (Powerpoint, videos, game-based scenarios, etc.), assessments (quiz, 'practical exam', etc.), feedback (motivational, affective, metacognitive, corrective, scaffolded, etc.), and system-specific (logout, save data, etc.).

(from a software engineering standpoint) The launch of processes which are user-specific (like their own domain module?). Help me out here Dignitas...

<top>

VBS2

See Virtual Battlespace 2

<top>

Virtual Battlespace 2

Collaborative simulation program shared across US services and international collaboration. VBS2 is a simulator which can function with land/sea/air vehicles and in dismounted capability. More information is available at the wikipedia page (http://en.wikipedia.org/wiki/VBS2), or the project page (www.vbs2.com).

<top>