Learning plans, goals and targets are important. Setting goals for learning allows us to evaluate whether or not we are learning the things that we set out to learn. It’s standard practice for e-learning courses and qualifications to have learning outcomes attached to them, and these are used to measure if our learning has been successful. They are also used by educators and trainers to evaluate whether or not their teaching and training have been effective, and are used to inform interventions, further learning requirements and amendments to learning materials and lesson plans.
Learning Goals with Tin Can
Brian Miller touched on the use of sub-statements in Tin Can to represent future plans. The spec puts it this way: “One interesting use of sub-statements is in creating statements of intention.” and gives the following example:
{ "actor": { "objectType": "Agent", "mbox":"mailto:test@example.com" }, "verb" : { "id":"http://example.com/planned", "display": { "en-US":"planned" } }, "object": { "objectType": "SubStatement", "actor" : { "objectType": "Agent", "mbox":"mailto:test@example.com" }, "verb" : { "id":"http://example.com/visited", "display": { "en-US":"will visit" } }, "object": { "id":"http://example.com/website", "definition": { "name" : { "en-US":"Some Awesome Website" } } } } }
The identifiers used in this statement are examples and shouldn’t be copied. You should use identifiers from the registry instead, for example the ‘planned’ verb. This example is simply intended to show the structure of a statement of intent.
Explanation
There are a few important points to note about this statement, so let’s take it line by line.
The main statement
The actor and verb definitions of the main statement are normal actor and verb representations. There’s nothing special about the statement until we come to the object, except perhaps that the verb represents an intention to perform some future action.
The sub statement
The object property of the statement is where things get interesting. The “objectType” used here is “SubStatement” because it refers to a statement within a statement. Sub statements are not full statements so do not have their own “id”, “stored”, or “authority” properties and are considered to be a part of the statement that contains them. For the sanity of LRS vendors, sub statements can only go one level deep, and cannot themselves contain further nested sub statements.
The actor of the sub statement could be the same as the actor of its parent, or could be different. Bob might plan to do something himself, but could also set Joe a target of completing a piece of learning.
Marking statements of intention as fulfilled
The sub statement’s actor, verb and object should match exactly those of the expected future statement. A reporting system will then be able to compare this sub statement with future statements and flag up when the sub statement has been fulfilled. In this example, a future statement of “test@example.com visited Some Awesome Website” would show that the intention of the sub statement had been achieved.
The verb id of the sub statement should therefore be a normal xAPI verb, which is always in the past tense. This makes life easy for the reporting system, which can match verbs like for like rather than having to match up future and present forms of the verb. The form of this type of statement is “I planned (I did this)”, not “I planned (I will do this)”. The verb display property can be given in a future tense for a human reader, but the verb id should always be past tense.
When it comes to issuing the statement recording the intended experience, you should (where possible) include a reference to the relevant statement of intent. This information may be useful to help match the two statements. In practice though, the tool issuing the statement about the experience may not know about the statement of intent and therefore may not be able to include the reference. For that reason, tools reading these statements cannot rely on such a statement reference being present.
Additional Properties
It’s also possible for a sub statement to have result, context and timestamp properties if required. The exact use of these properties for sub statements is not defined in the specification, and I envisage these being used to further specify what is required to successfully fulfill the intention expressed by the initial statement. For example, a scaled score of 0.85 specified in the result property of a sub statement, might be used to imply that the stated intention is not fulfilled until a scaled score of at least 0.85 is reported. The “timestamp” property on the other hand might be seen as a maximum and used to specify that the intention must be fulfilled before a certain date and time. The details of this should be set out in recipes, describing the use of sub statements in a specific context.
So that’s how you can track planned learning and intended activities with xAPI. Please contact us if you have any questions.