Domain Knowledge File 2024-1¶
Overview¶
This document contains information about the Domain Knowledge File (DKF) and its format. A DKF is an XML file which contains the information needed to execute on a single lesson. The DKF file is read by the Domain module and used by the Domain and Pedagogical modules. Each module is interested in specific sections of the file (more specifically the Pedagogical module uses only the state transitions section of the DKF).
The explanation below details how the DKF is parsed in each of the modules and offers insight into how the reader can author new DKF files or customize existing ones.
Important and quick reference information can be found in the green colored boxes throughout this document.
Schema¶
The DKF schema describes the format of the xml document in terms of constraints on the structure and content. The DKF schema is not yet complete but the goal is to support customization through generalized input parameters such as name/value pairs and/or specifying user created classes that can handle unique implementation details (e.g., a condition implementation class that knows how to assess a concept that GIFT doesn’t already know how to assess).
Schema location: GIFT\config\domain\dkf\dkf.xsd
The dkf.xsd file is useful for creating new entries in a DKF, in addition to creating a DKF from scratch. The schema is also used by jaxb to generate java classes for use by GIFT.
For more information about JAXB:
http://www.oracle.com/technetwork/articles/javase/index-140168.html
There is also a binding file (binding.xml) that is used to customize the generated classes.
Editing the Schema¶
In certain instances, such as when a new condition (type of class that assess) is created in GIFT, you will want to edit the dkf.xsd in order to allow a DKF to use that newly created element. There are dozens of xsd editors available to help with this effort.
After the xsd is finished being edited, build GIFT to generate the java classes (GIFT\generated\) and the jaxb jar used by GIFT.
Once the jar has been created/updated, the generated java class(es) associated with the changes made in the schema will be available for use in GIFT source development.
Validating DKF Content¶
There are two forms of DKF content validation, one using the dkf.xsd and the other using domain initialization logic scattered throughout the domain and pedagogical modules. The quickest way to validate a DKF is to use the DKF Authoring Tool (DAT) to validate against the schema and then validate using Domain module logic. For more information on the DAT refer to DKF Content (top-level) section or GIFT XML Authoring Tools.
DKF Content (top-level)¶
This section describes the top level elements of the DKF.
Currently, DKF files are authored by either directly editing the XML content using a text editor (should only be used by experienced GIFT developers) or the preferred method of using the DKF Authoring Tool (DAT). This is the dedicated DKF -authoring software tool with a high-level user-friendly interface that will shield the author from some of the low level details of XML editing. The suite of GIFT authoring tools is not an end all solution but rather a quick and simple solution that allows the user to develop and validate configuration files for GIFT without a simple text editor. Furthermore, the tools allow the user to validate configuration content without having to launch GIFT modules and possibly enter into a domain session.
Scenario Name¶
The scenario element specifies the display name of the scenario.
Version¶
The version attribute is now in all XML files that can be authored using one of the GIFT authoring tools. It provides a mechanism to better pinpoint when a particular instance of a GIFT authored XML file was saved. If the author used one of the authoring tools to save the file, the tool will auto-increment minor version number (it can also update the major version, e.g. 2.0.15 to 3.0.1).
Description¶
The DKF description element is where the author can provide information about the lesson being assessed. This could include (but is not limited too) a domain description, objectives and training application used.
Learner Identification¶
This element is used to identify the learner in the training application. For example, GIFT v1.0 was integrated with VBS (see GIFT Install Instructions and GIFT Configuration Settings for more information) which executed on scenarios where the learner would play the role of an actor in the game. GIFT was notified of entity movement, among other things, via DIS Entity State PDU messages sent from VBS. These messages contained entity identifier information that wasn’t guaranteed to be consistent across multiple executions of the scenario for every player. Therefore GIFT needed a way to identify which Entity State messages mapped to the learner and which represented other actors. One way to determine the learner’s DIS entity id was to provide the starting location of the learner in the scenario. Once GIFT received this location it is able to map the learner to the specific entity in the scenario.
In the future, there could be other implementations that offer the ability to identify the learner in a training application.
If the learner identification element is not provided, the assessment logic assumes there is no need to distinguish between learner messages and that of other players in the scenario (if any).
Start Location
The start location is the location of the learner’s actor in the training application at the start of the scenario.
EXAMPLE:
<startLocation>
<coordinate>
<GCC>
<x>3767068.5</x>
<y>-3163452.25</y>
<z>4046284.5</z>
</GCC>
</coordinate>
</startLocation>
This is the starting GCC location of the learner in this scenario. The location is used to identify the entity id of the learner as simulation packets (e.g., DIS entity state PDUs) are received. The location can be specified in other coordinate systems depending on the need/application (refer to Coordinates section for more information).
Resources¶
The resources element contains items used to manage the domain/lesson.
Survey Context¶
Survey Context value references the survey context unique key in the survey database for the lesson being assessed by a DKF. The survey context contains all the surveys used during the lesson (there can be multiple lessons in a domain session, refer to GIFT Domain Course File for more information). More about what a survey context means in terms of the survey database can be found by reading the Survey Authoring System document or viewing the UMS database.
Learner Actions¶
Learner Actions are actions (e.g. buttons) available to the learner on the TUI during the execution of a lesson (i.e. training application). Examples of these buttons include, but are not limited to, “Use Radio” and “Fill out Spot Report”. These actions can be specified in two ways for a DKF:
- List – specify the action to show and an optional change in display name.
- Files – specify learner action XML file(s) that contain references to learner action elements. These “external” files can be used to share learner actions across DKFs and follow the learnerActions.xsd schema.
Assessment¶
The assessment element contains the rules and configuration for the domain module to assess this domain based on the learner’s actions. Assessments are performed during a lesson (aka Training Application Transition) (i.e. while the learner is in a scenario like a VBS scenario). Assessments can change often during a lesson as the user choses different actions over the execution of the scenario. Real time assessments differ from Scoring which provides an overall score or assessment of how the learner did in the entire lesson.
Tasks¶
Contains the list of tasks/concepts (aka Performance Nodes) associated with assessing this domain. For more information refer to DKF Content (detailed).
Objects¶
Objects are items such as Waypoints that can be referenced throughout the tasks elements.
Waypoints¶
Contains the list of waypoints associated with this scenario and referenced throughout the DKF in tasks, concepts, conditions, etc.
Note: Waypoint name values must be unique within a DKF to allow references to be made through the tasks elements. The location can be specified in other coordinate systems depending on the need/application (refer to Coordinates section for more information).
Actions¶
This section contains the various states that should be detected and the corresponding instructional strategies to implement when appropriate to do so. Eventually we foresee this section being eliminated as learner and pedagogical models are developed that can determine this sort of information on their own without the help from a detailed, single-path configuration.
State Transitions¶
A state transition corresponds to a change in learner state from the current value to the next value. Currently, the DKF can handle various types of learner state transitions in the form of Performance, Affective and Cognitive attribute changes.
Note: In the case of Performance Nodes (i.e., Tasks and Concepts), possible assessment values for the previous and current state are taken from AssessmentLevelEnum.java.
For more information refer to DKF Content (detailed).
Strategies¶
This section contains the list of micro adaptive instructional strategies available for the Pedagogical module to select from and the Domain module to implement based on changes in learner state.
DKF Content (detailed)¶
This section describes the lower level elements in a DKF with examples.
Learner State Transitions: To add new transitions (or edit existing ones), find the explanations below on the transitions element. This includes changing the list of instructional strategies available for each transition.
Instructional Strategies: To add new strategies (or edit existing ones), find the explanations below on the strategies element. This includes changing the feedback message of an instructional intervention or the environment change of a scenario adaptation.
Task Start and End Triggers¶
Start and end triggers define when a performance node will start and end its assessment process for the domain. When any of the triggers under either section is fired the corresponding start/end logic for a performance node is executed.
Currently these are the types of triggers that can be authored:- Entity location – is triggered when an entity, who starts at a specified location, reaches a different specified location during the lesson.
- Learner location – is triggered when the learner reaches the specified location. This requires that the learner identification information be provided in the DKF as well.
- Concept Ended – is triggered when the specified concept (from the global list of concepts, not just children of this performance node) has been completed.
- Child Concept Ended – is triggered when the specified concept (a child concept of this performance node) has been completed.
- Task Ended – is triggered when the specified task has been completed/ended.
- Concept Assessment – is triggered when the specified concept reaches the specified assessment level enum.
- Learner Player dies – is triggered when the learner’s character in the game (e.g. VBS) dies.
- SIMAN.Stop – is triggered when the training application sends a SIMAN.Stop message with the following reasons: {3 = system fail, 6 = stop for reset, 7 = stop for restart}
Note: If no start trigger is specified, the performance node starts immediately upon the lesson starting.
The following is an example snippet of start and end triggers.
1. <assessment>
2. <tasks>
3. <task name="Patrol Compound Perimeter" nodeId="1">
4. <startTriggers>
5. <learnerLocation>
6. <coordinate>
7. <GCC>
8. <x>3767066.8535533906</x>
9. <y>-3163453.0857864376</y>
10. <z>4046285.810660172</z>
11. </GCC>
12. </coordinate>
13. </learnerLocation>
14. </startTriggers>
15. <endTriggers>
16. <learnerLocation>
17. <coordinate>
18. <GCC>
19. <x>3767086.7305224794</x>
20. <y>-3163449.4280285537</y>
21. <z>4046269.7597387605</z>
22. </GCC>
23. </coordinate>
24. </learnerLocation>
25. </endTriggers>
vbs2.persencepartrol.dkf.xml - <task name="Patrol Compound Perimeter" nodeId="1">
This is the start of a task node with a user defined node name (will also appear in scoring and AAR) and a unique node id which will be used to uniquely identify this node in the domain.
- <startTriggers> and <endTriggers>
Triggers are used to start and end a task.
- If there is no start triggers provided, then the task is automatically started.
- A task can’t end until it has been started. (i.e. the end triggers are only checked while a task is running)
- A task can’t start if it’s currently running. (i.e. the start triggers aren’t checked while a task is running)
- A task can start, end and then be started again.
- If all tasks have finished and no tasks are running, the scenario is deemed over.
- <learnerLocation>
The learner location trigger is used in this DKF to signal the start or end of this task when the learner has reached the specified locations. The location can be specified in other coordinate systems depending on the need/application (refer to Coordinates section for more information).
22. <endTriggers>
23. <conceptEnded nodeId="5"/>
24. </endTriggers>
vbs2.TSP 07-GFT-0137 ClearBldg.dkf.xml
The concept ended trigger is used to end the task when the concept identified by the node id has finished.
Concepts and Conditions¶
A concept is the lowest level performance node that is reported between modules and stored in the LMS. A concept is assessed via conditions. A condition is associated with a java class that contains logic which can assess the learner’s actions in the domain for the domain module.
The concept/condition hierarchy supports infinite nesting by specifying the “concepts” choice for a concept instead of “conditions”. An example of a DKF XML file, broken into snippets, is talked about in the remainder of this section.
To learner more about the source code for a condition, including how to build a new one from scratch, see Creating a performance assessment Condition.
For a detailed mapping of training applications, supported conditions classes and training application state messages, see Analysis of Training Applications and preferred condition classes.
1. <concepts>
2. <concept name="Stay close to wall" nodeId="2">
3. <conditions>
4. <condition>
5. <conditionImpl>mil.arl.gift.domain.knowledge.condition.CorridorBoundaryCondition</conditionImpl>
6. <input>
7. <CorridorBoundaryCondition>
8. <bufferWidthPercent value="10" />
9. <path>
10. <segment name="segment 1">
11. <width>4.0</width>
12. <bufferWidthPercent>10</bufferWidthPercent>
13. <start waypoint="1"/>
14. <end waypoint=”2”/>
15. </segment>
16. ...
vbs2.persencepartrol.dkf.xml
This is the start of a concept node with a user defined node name (will also appear in scoring and AAR) and a unique node id which will be used to uniquely identify this node in the domain.
- <condition>
A condition maps to a class which is responsible for doing assessments on specific pieces of information.
- <conditionImpl>mil.arl.gift.domain.knowledge.condition.CorridorBoundaryCondition</conditionImpl>
This element specifies the class that contains the implementation of the condition. The implementation class’s constructor must have a parameter for the generated class listed as part of this condition. In this example domain.knowledge.condition.CorridordBoundaryCondition.java has a constructor with generated.CorridorBoundaryCondition.java as a parameter.
- <CorridorBoundaryCondition>
The corridor boundary condition is used to determine if and when a learner is in a specified corridor made up of segments.- <bufferWidthPercent value="10" />
Describes the width of the buffer zone created around each segment in the corridor used by this condition. The value is a percent applied to each segment’s width (if the segment doesn’t specify its own buffer width percent). - <path>
Contains a list of linked segments comprising the corridor. - <segment name="segment 1">
Start of a segment of the path. The name uniquely identifies this segment in this path. - <width>4.0</width>
The width of the segment in meters. - <bufferWidthPercent>10</bufferWidthPercent>
This segment specifies its own buffer width, as opposed to using the global value specified in the condition. - <start waypoint="1"/>
The starting location of this segment is the waypoint identified uniquely by the id “1”. - <end waypoint="2"/>
The ending location of this segment is the waypoint identified uniquely by the id “2”.
- <bufferWidthPercent value="10" />
205. <CorridorPostureCondition>
206. <postures>
207. <posture>Crouching</posture>
208. <posture>Prone</posture>
209. <posture>Kneeling</posture>
210. <posture>Crawling</posture>
211. <postures/>
212. <path>
213. <segment name="segment 9">
vbs2.persencepartrol.dkf.xml
- <CorridorPostureCondition>
The Corridor Posture Condition is used to determine if the learner is in the correct posture in a specific corridor. The acceptable postures (mapped to the names in PostureEnum.java) are specified in the list of postures.
317. <concept name="Rules of Engagement" nodeId="4">
318. <conditions>
319. <conditionImpl>domain.knowledge.condition.RulesOfEngagementCondition</conditionImpl>
320. <input>
321. <RulesOfEngagementCondition>
322. <wcs value="Hold"/>
vbs2.persencepartrol.dkf.xml
- <RulesOfEngagementCondition>
The Rules of Engagement (RoE) condition is used to determine if the learner is following the doctrine associated with this concept. The weapon control status (wcs) value (mapped to the names in WeaponControlStatusEnum.java) dictates how this condition will be assessed.
342. <CheckpointProgressCondition>
343. <checkpoint windowOfTime="10" waypoint="2" atTime="00:01:00"/>
344. <checkpoint windowOfTime="60" waypoint="20" atTime="00:05:00”/>
345. <checkpoint windowOfTime="60" waypoint="37" atTime="00:10:00"/>
346. </CheckpointProgressCondition>
vbs2.persencepartrol.dkf.xml
- <CheckpointProgressCondition>
The Checkpoint progress condition is used to check absolute progress along a series of checkpoints.- <checkpoint windowOfTime="10" waypoint="2" atTime="00:01:00"/> (Line 343)
A checkpoint is defined with a location (waypoint), the time (after task is started) at which the waypoint location should be reached by the learner (atTime) and a window of opportunity (windowOfTime) amount of time in seconds. If the learner reaches the checkpoint before the “atTime” value an Above Expectation assessment is given. If the learner reaches the checkpoint within the window of time value after the atTime value an At Expectation assessment is given.
- <checkpoint windowOfTime="10" waypoint="2" atTime="00:01:00"/> (Line 343)
363. <conditions>
364. <CheckpointPaceCondition>
365. <checkpoint windowOfTime="10" waypoint="2" atTime="00:01:00"/>
366. <checkpoint windowOfTime="60" waypoint="20" atTime="00:05:00"/>
367. </CheckpointPaceCondition>
368. </conditions>
vbs2.persencepartrol.dkf.xml
- <CheckpointPaceCondition>
The checkpoint pace condition is used to check whether the learner is on pace to finish a task in the appropriate amount of time. This is used alongside the checkpoint progress condition in order to facilitate notifying the learner when he/she is falling behind. This notification can help prevent the learner from failing the checkpoint progress condition.- Notice how there is no scorer for this condition, due to the fact that its intention is to help the learner not fail the checkpoint progress condition.
30. <EliminateHostilesCondition>
31. <entities>
32. <startLocation>
33. <coordinate>
34. <GCC>
35. <x>3742092.75</x>
36. <y>3743767.5</y>
37. <z>3546489.25</z>
38. </GCC>
39. </coordinate>
40. </startLocation>
41. <startLocation>
42. <coordinate>
43. <GCC>
44. <x>3742098.75</x>
45. <y>3743770.25</y>
46. <z>3546489.0</z>
47. </GCC>
48. </coordinate>
49. </startLocation>
50. </entities>
51. <EliminateHostilesCondition>
52. <scoring>
53. <count name="Kill Count" units="count">
54. <evaluators>
55. <evaluator assessment=”AboveExpectation” value="-1" operator="Equals"/>
56. <evaluator assessment=”AtExpectation” value="2" operator="Equals" />
57. <evaluator assessment=”BelowExpectation” value="1" operator="LessThanEquals" />
58. </evaluators>
59. </count>
60. </scoring>
61. <default assessment="BelowExpectation" />
vbs2.TSP 07-GFT-0137 ClearBldg.dkf.xml
- <default assessment="BelowExpectation" />
This element is used to set the default assessment level for a condition.
Default Condition Assessment: If the default element is not provided the default assessment level for a condition is Unknown (unless the condition implementation class sets the default manually).
Scoring¶
The scoring elements contain the knowledge on how to score a condition based on certain criteria. A learner’s score is what is stored in the LMS for a lesson and is what is available on the AAR course transition and LMS course history GIFT webpage.
Scoring is an overall assessment of how a learner did on a particular condition during the execution of a lesson/scenario. It is not calculated during the execution of the lesson but rather at the end of the lesson. Assessments provides real time analysis of the user’s actions from moment to moment.
Currently scoring elements are optional in a GIFT DKF because you may not care (i.e. want to store the learners over score on their ‘permanent’ record in the GIFT LMS) about a particular training application course transition such as presenting a PowerPoint show. Furthermore, you may have a DKF in which only some of the conditions need to be score while other are there for internal purposes such as tracking, used as triggers or to provide helpful hints during scenario execution.
181. <scoring>
182. <count name="violation count" units="count">
183. <evaluators>
184. <evaluator assessment="AboveExpectation" value="0" operator="Equals"/>
185. <evaluator assessment="AtExpectation" value="2" operator="LessThanEquals" />
186. <evaluator assessment="BelowExpectation" value="2" operator="GreaterThan" />
187. </evaluators>
188. </count>
189. <violation_time name="violation time" units="hh:mm:ss">
190. <evaluators>
191. <evaluator assessment="AboveExpectation" value="00:00:00" operator="Equals"/>
192. <evaluator assessment="AtExpectation" value="00:00:30" operator="LessThanEquals" />
193. <evaluator assessment="BelowExpectation" value="00:00:30" operator="GreaterThan" />
194. </evaluators>
195. </violation_time>
196. </scoring>
vbs2.persencepartrol.dkf.xml
- <scoring>
Contains one or more scoring nodes used to describe how to score this condition’s assessments. The score for each scorer is what is shown in AAR and stored in the LMS db.
- <count name="violation count" units="count">
This is the count scorer used to count events. The name value is used to describe the event being scored. The “units” value details what the units for the score. Both name and units will appear in the score and AAR. After the type of scorer is specified, there must be at least one assessment level (i.e., Above, At, Below expectations) evaluator for the scorer.- <evaluator assessment="AboveExpectation" value="0" operator="Equals"/>
Here an Above Expectation assessment can only be given if the value is equal to zero. The “value” for a count scorer is constrained by java long. The operator value maps to the name values in OperatorEnum.java. - The following two evaluators with Assessments of “AtExpectation” and “BelowExpectation” follow the same pattern.
- <evaluator assessment="AboveExpectation" value="0" operator="Equals"/>
- <violation_time name="violation time" units="hh:mm:ss">
This is the violation time scorer used to maintain the amount of time a condition was violated.
Sequence of Events among Tasks/Concepts/Conditions
This section describes the ordering of when tasks, concepts and conditions are called upon in GIFT. The current algorithm uses a depth-first search approach replying, at each level, on the ordering authored in the DKF.
- Task 1
a. Concept 1.1
i. Concept 1.1.1
1. Condition 1.1.1.1
2. Condition 1.1.1.2
b. Concept 1.2
i. Condition 1.2.1 - Task 2
a. Concept 2.1
i. Condition 2.1.1
The sequence of initialization, starting and handling of game state messages would follow this sequence:
1, 1.1, 1.1.1, 1.1.1.1, 1.1.1.2, 1.2, 1.2.1, 2, 2.1, 2.1.1
- Task 1
a. Concept 1.2
i. Condition 1.2.1
b. Concept 1.1
i. Concept 1.1.1 (this is a subconcept)
1. Condition 1.1.1.2
2. Condition 1.1.1.1 - Task 2
a. Concept 2.1
i. Condition 2.1.1
The sequence of initialization, starting and handling of game state messages would follow this sequence:
1, 1.2, 1.2.1, 1.1, 1.1.1, 1.1.1.2, 1.1.1.1, 2, 2.1, 2.1.1
The above sequences assume that the all the conditions register for the game state message being delivered. Each condition class can register to receive different game state message types in order to filter the number of messages coming into that class. For example, let’s use the last example but this time Conditions 1.1.1.2 and 1.1.1.1 aren’t interested in the incoming game state message. The sequence would now be:
1, 1.2, 1.2.1, 2, 2.1, 2.1.1
In some cases a condition may receive the game state message in the depth first fashion mentioned above but then deliver that message to another process/system (e.g. SIMILE assessment engine). More often than not that logic is running in a different thread than the thread that provided the game state message to the condition. Therefore the handling of that message is not done in the depth first sequence because it could take an undetermined amount of time before an assessment is returned (if any) from that condition class.
State Transitions¶
As explained in a previous section on State Transitions, this section contains the various learner state transitions of interest. It is these transitions which can cause instructional strategies to be given to the learner. This section of the DKF is used by the Pedagogical module to configure micro adaptive strategy selection.
For each state transition element:- Logical Expression – a list of learner state attribute transitions compounded into a logical expression.
Note: currently all learner state attribute transition elements specified under a state transition element are evaluated using the AND operator only. In the future a more complex logical expression will be supported.
State Transitions: A state transition is “activated” when a logical expression evaluates to true based on specific learner state attribute changes from the previous value to the current value.
- State Attribute choice:
- Learner State Enum – a cognitive or affective state attribute.
Attribute – select a learner state attribute from the enumerated list (LearnerStateAttributeNameEnum.java.) - Previous – select the previous value which represents the previous learner state attribute value for the attribute specified. The list of possible values for this field is dependent on the attribute selected.
- Current – select the current value which represents the current learner state attribute value for the attribute specified. The list of possible values for this field is dependent on the attribute selected.
- Learner State Enum – a cognitive or affective state attribute.
Note: One of either the previous or current values can be left undefined. This choice represents a wildcard during evaluation of the logical expression.
- Performance Node – a performance node state.
- Name – a display name for this performance node attribute transition element for human readability/reference as to which performance node this attribute is a reference too.
- Node id – the unique node id of a performance assessment node used to map this attribute specification to the performance node in the learner state.
- Previous – an assessment level enumerated value which represents the previous learner state attribute value for the performance node specified.
- Current - an assessment level enumerated value which represents the current learner state attribute value for the performance node specified.
Note: One of either the previous or current values can be left undefined. This choice represents a wildcard during evaluation of the logical expression.
- Strategy Choices – list of instructional strategies to choose from if this transition is activated. A strategy is referenced by its unique name from the list of strategies in the strategies portion of the DKF.
Transitions and Strategies: A transition can reference multiple strategies. It is up to the Pedagogical module to determine which strategies to suggest for the Domain module.
Strategies¶
As explained in a previous section on Strategies, this section contains the various micro adaptive instructional strategies used for this domain.
For each strategy:- Name - A strategy has a unique name which identifies it. This unique value is referenced by strategy choices in the state transitions section of the DKF (refer to State Transitions section for more information)
- Strategy Choice:
- Instructional Intervention – This is usually some type of feedback presented to the user.
Specifying more than one type allows for an increase in strategy intensity (ascending order).- Types:
- Feedback
- Types of feedback:
- Message – a simple string containing the feedback to present to the user.
- Delivery – allows you to specify where the feedback should be sent and handled. The options are in the GIFT tutor user interface (TUI) and/or the training application (e.g. VBS).
If you choose the TUI you can also specify various text (e.g. flash the text, play beep sound) and message (e.g. use avatar) enhancements.
- Delivery – allows you to specify where the feedback should be sent and handled. The options are in the GIFT tutor user interface (TUI) and/or the training application (e.g. VBS).
- Audio – play the specified audio file through the TUI.
- Media Semantics – display the specified avatar and execute the message the avatar has authored logic to render.
- Message – a simple string containing the feedback to present to the user.
- Types of feedback:
- Feedback
- Types:
- Scenario Adaptation – to change the scenario or lesson is some manner.
- Types:
- Environment Adaptation - specify parameters used to augment a scenario.
Example: To change the environment of the training application scenario by modifying the amount of fog (supported in VBS) you would specify the following:
Name = “EnvironmentControlEnum”
Value = “FogLevel1”
- Environment Adaptation - specify parameters used to augment a scenario.
- Types:
- Instructional Intervention – This is usually some type of feedback presented to the user.
Scenario Adaptation: Currently, scenario adaptations are sent from the Domain module to the Gateway module. The Gateway module in turn hands over the implementation of specific scenario adaptations to the various interop plugins available.
In this example, this strategy eventually causes the Gateway VBS plugin to change the fog level using the VBS scripting language. The exact fog level value is specified by config/gateway/vbs.control.properties (more in VBS Control properties).
Request for Performance Assessment – The performance assessment strategy is used to request a performance assessment on a given performance node identified by the “nodeId” value. Refer to Assessment for more information.
- Strategy Handler- Used to specify the class that knows how to handle the implementation details of the instructional strategy. For example, the “DefaultStrategyHandler” class knows which interface method to call to send a display feedback request to the Tutor or to the Gateway for displaying on the TUI or in the training application game (e.g. VBS) respectively.
- Params (optional) – list of name/value pairs that can be used to configure the strategy handler’s implementation of this strategy.
Assessment¶
This section contains additional assessment logic for a performance node. Performance nodes are already assessed by conditions (at the lowest level) and this element allows for other types of assessments to be specified, such as give a survey and assess the results. The choice to add assessment information is available within every task and concept node.
For each Assessment element:- Types:
- Survey – The survey assessment type is used to give a mid-lesson survey in order to assess the performance node in greater detail.
- Survey key - The key value corresponds to a GIFT survey key as shown in the Survey Authoring system and the survey database. The GIFT survey key must be associated with the survey context for this scenario (also in the DKF).
- Questions list – allows the author to select questions from the survey referenced by the survey key that can provide additional assessment information for the performance node.
- Question
- Key – the unique id (key) of the survey question in the survey database.
- Reply list – allows the author to select which replies from the question can be assessed toward this performance node.
- Reply
- Key – the unique id (key) for the reply in the question.
- Result - If this reply option is selected for this question then the performance node assessment level will be changed to this performance assessment enumerated value.
- Reply
- Question
- Condition Assessment – this notifies the condition implementation class that additional assessment logic should be executed to, possibly, provide a different assessment value for this performance node.
- Survey – The survey assessment type is used to give a mid-lesson survey in order to assess the performance node in greater detail.
Coordinates¶
There are several coordinate systems supported by GIFT including GCC, GDC and VBS AGL. As GIFT evolves, support for other coordinate systems will be added. The ability to allow the DKF author to specify the coordinate system to use for various inputs provides more flexibility in support of training application specific implementations. For example, in GIFT v1.0 which was integrated with VBS v1.4, VBS scripting did not support using GCC/GDC coordinates with select commands. Therefore, we specify AGL coordinate values in the DKF in order to provide those commands the AGL coordinate values. However, in the DKF the coordinates were merely specified as a delimited string with no indication of a coordinate system.
Example DKF snippet:
<startLocation>
<coordinate>
<GCC>
<x>3742101.5</x>
<y>3743832.25</y>
<z>3546412.5</z>
</GCC>
</coordinate>
</startLocation>
The DKF Authoring Tool¶
GIFT provides a built-in authoring tool for creating and editing DKFs in both the online and desktop versions. The sections below will show you how to access the above-mentioned elements of the DKF Authoring Tool.
Opening the DKF Editor¶
Start by opening a course from the Take a Course GIFT Dashboard web page. To create a new course, click on the Create button in the top right corner of the Take a Course GIFT Dashboard web page (shown by red arrow above). To edit an existing course, click the edit button on the course tile on the Take a Course GIFT Dashboard web page (shown in red circle above).
To access the DKF editor, first drag the course object that relates to your intended training application into your course flow (shown by the red arrow above). Once the course object has been successfully added, a new panel will appear on the right side of the screen. Click on the "Edit" button in the Real Time Assessment box (shown in the red circle above) to open the DKF editor.
Adding a Strategy¶
To add a strategy in the DKF editor, open the second tab on the left side panel called “Strategies”. Click on the green plus sign in the top right corner (shown by the red arrow above). The panel on the right side of the screen will now appear as it is in the screenshot above. In this panel you can add strategies using the green bar labeled “Click here to add a new activity”.