Activity Statements Make xAPI Flow
Imagine having a heart that beats but nothing to pump. That’s xAPI without an activity statement. Previously we spoke about the Learning Record Store (LRS) being the heart of xAPI. Think of the activity statement as the blood. Without an activity statement, an LRS has nothing to store, report on, or return. There’s no flow to the xAPI process.
What is an Activity Statement?
In its simplest form, a xAPI Activity Statement is a brief declaration that someone did something. It’s the way we create a record of an experience that a learner or user had. That statement is then sent to a Learning Record Store or handled in some other way.
So, in other words, the statement is a data record. The typical industry simple explanation is in the form of “I did this“. The purpose of the activity statement was to create a flexible way to record a variety of experiences. With SCORM you could record a bookmark or completion or scoring of an e-learning course. With activity statements in xAPI you can also record when someone reads a book, participates in a discussion, or meets a production deadline.
How do Activity Statements work?
When a statement is created it is sent to a destination (usually an LRS) for the purpose of storing and tracking.
How Do I Build an Activity Statement?
There are three essential elements to form a simple statement. You need an Actor, a Verb, and an Object. Just like in grammar class where you were told a sentence always had to have a noun and a verb, so an activity statement must have an actor, verb, and an object.
The Actor is the entity who is actually performing what the statement describes.
The actor can be an individual or a group. When it is an individual, it is referred to as an Agent. Either way, the actor must be uniquely identified somehow. With an agent, it could be an employee ID number, an email address, an OPEN ID login, Facebook profile, etc. With a group, it could be a group name or could be something similar to the agent ID.
The identification has to be a type of Inverse Functional Identifier (IFI). These are guaranteed to only and ever refer to the specific agent or group. In other words, it has to always be unique to that agent or group and never be reused. This makes each activity record “owned” more or less by the agent or group. It’s part of what makes activity statements portable. An IFI can only be one of four types:
- A linked email address (mailto:firstname.lastname@example.org)
- A hex encoded string of a linked email address
- An Open ID
- A system user account
The Verb describes the action performed during an experience. It is typically expressed as a past-tense verb, such as “viewed”, or “visited” or “read”. Unlike some standards or specifications, Experience API does not restrict verb usage to only a specific set of verbs. The reason for this is that it allows organizations or systems to have verbs that have real meaning to their specific situations.
However, it also creates some substantial challenges. The chief challenge would be creating understanding, especially if the data becomes portable; that is, moving from system to system. For example, if I use the word “fired” it could mean any one of multiple things. It could mean I “fired a gun”, or “fired a kiln”, or “fired an employee”.
To provide descriptive meaning to a verb, each one used in an activity statement must also include an International Resource Identifier, or IRI. The IRI is a reference to a location that defines the meaning of the verb for this usage. It is usually in the form of “http://domain.com/#fired” where it would link to the definition.
The Object identifies the target of the Verb that the Actor performed. The Object can be a specific activity such as a book or a video. For example, an activity statement might be “Jennifer Viewed Ethical Behavior for Managers“.
It can also be another agent or group and might be written as “Jennifer Counseled Frank“.
Still again, it could be a reference to another statement; e.g., “Joe Commented on ‘Jennifer Viewed Ethical Behavior for Managers’“.
Finally, it could be a substatement. This is where you might embed a statement inside a statement. One way to use this would be to state future behavior, such as “Frank planned to view Employee Ethics video.”
Putting It Together
Typically, we put these together into the Actor-Verb-Object arrangement such as in the examples above.
Think of it this way, I want to tell you about my recent visit to Brasstown Bald Mountain where I took the trail to the observation deck at the top. If I need to describe that in one brief sentence, I might say it as “I hiked the Brasstown Bald Trail.” This simple statement tells you who an Actor (me), acted a Verb (hiked), and the Object I performed it on (Brasstown Bald Trail).
Simple Isn’t It?
If only it was. When dealing with data, it is still important to be precise. There needs to be a complete understanding of the Actor, the Verb, and the Object. There can be so many of each.
So the technical specification details data structure much deeper and it includes references to details about each component of the statement.
We will explore that in another article.
Can’t wait for the next article. Contact JCA Solutions today (email@example.com) to see how we can help.