Anatomy of an xAPI Statement – Part 2

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. xAPI Statement Result
  • 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. xAPI Statement (context)

 

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:

  1. 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.
  2. 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.
  3. 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”.
  4. 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.

Art Werkenthin
Art Werkenthin is president of RISC, Inc. and has over 30 years' experience working with LMS systems in the Oil & Gas, Retail, Finance and other industries. Mr. Werkenthin holds a B.S. in Electrical Engineering and an M.B.A. in Information Systems Management from the University of Texas. Mr. Werkenthin is a member of the ADL cmi5 committee and frequently presents on cmi5 and xAPI. Follow him on Twitter @AWerkenthin for xAPI and cmi5 updates, as well as blog post announcements.