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.
Result
| The Result is an optional component of an xAPI statement. For example, in “Bob started test3” there is no result. Bob started the test, but we don’t know yet how well he’ll do. Later we might see the statement “Bob passed test3 with a score of 90”. Score is one of the properties of the Result object in an xAPI Statement. Let’s take a look at the other properties of a Result, all of which are optional. |  |
- success
This is a true/false field indicating whether the Actor achieved success in the activity (see “Object” in part one of this article). - completion
This is a true/false field indicating whether the Actor completed the activity. - response
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. - duration
This is how long the student spent in the activity. - extensions
We’ll talk more about extensions later in this article.
Context
| Context is another optional component of an xAPI Statement. In my opinion, however, it is one of the most valuable components of a statement. One of the great advantages of xAPI is that you can record information about activities and the context in which they occurred. For example, in the statement “Christie experienced the Great Wall in Second Life” the Context is very important. If we left it out you’d have “Christie experienced the Great Wall”, which is wildly different than the original statement. Without the Context it looks like Christie went to China to see the Great Wall, as opposed to experiencing a simulated version of the Great Wall. |  |
Here are the some of the other properties of Context. As with the Result, all the properties of Context are optional.
- registration
This is a unique identifier representing a student “enrolling” in a course or signing up for a learning event. - instructor
This is an Agent object indicating the person (or persons) that instructed the activity (Object) of the statement. - contextActivities
The explanation of this is a bit involved, so we’ll cover it below. - revision
A revision number for the activity. - platform
This is the platform used to experience the activity. For example you could use “iPad” if the student performed the activity on an iPad. - extensions
As noted previously, we’ll cover extensions later in this article.
contextActivities
There are four types of contextActivities:
- parent
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. - grouping
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. - category
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”. - other
A catch all for a context activity that does not fit with one of the other three.
Extensions
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).
Important Considerations
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.
Summary
In this two part article we have examined the major parts of an xAPI Statement.
- Actor
- Verb
- Object
- Result
- Context
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.
