This is the second of a two part article describing the different components of an xAPI statement. In part one we covered the Actor, Verb and Object components of an xAPI statement. Now we’ll continue by looking the Result and Context of a statement.
This is a true/false field indicating whether the Actor achieved success in the activity (see “Object” in part one of this article).
This is a true/false field indicating whether the Actor completed the activity.
This is the response given by the Actor to the activity. For example, if you write a statement about a test question you could include the answer selected by the student.
This is how long the student spent in the activity.
We’ll talk more about extensions later in this article.
Here are the some of the other properties of Context. As with the Result, all the properties of Context are optional.
This is a unique identifier representing a student “enrolling” in a course or signing up for a learning event.
This is an Agent object indicating the person (or persons) that instructed the activity (Object) of the statement.
The explanation of this is a bit involved, so we’ll cover it below.
A revision number for the activity.
This is the platform used to experience the activity. For example you could use “iPad” if the student performed the activity on an iPad.
As noted previously, we’ll cover extensions later in this article.
There are four types of contextActivities:
Consider a course that consists of many modules. When statements are written about the modules they can include the course identifier as the “parent” activity.
This is used to group activities together. For example, if you had several courses in a curriculum you my use the “grouping” to identify the curriculum.
This is generally used to identify an xAPI profile, such as cmi5. A profile is a kind of recipe for using xAPI in a particular “use case”.
A catch all for a context activity that does not fit with one of the other three.
Activities, Results and Context can all have Extensions. The purpose of Extensions is to provided a way to extend the data stored in an xAPI statement. Each extension must have a unique identifier and should include a data value. For example, in the cmi5 specification there is an extension for “masteryScore”. This is helpful in analyzing statements. If we see a cmi5 “Passed” statement, it is useful to know the passing score (masteryScore).
You should always try to use built-in properties of an xAPI statement before creating extensions. Otherwise you may sacrifice the analytical abilities of your LRS. For example, if you created an extension for score instead of using the built in score property of Result, your extension for score may not be included in reports.
In this two part article we have examined the major parts of an xAPI Statement.
Hopefully you gained an understanding of the kinds of data you can store in an xAPI statement and will find that knowledge helpful in designing your xAPI data strategy.