The xAPI Specification Explained

The xAPI specification defines guidelines for capturing online learning experiences such as watch- ing a video, taking a quiz and others. Those guidelines are two-part: first the statement design or structure of the activity trace in its most basic form actor-verb-object, and the vocabulary (the word choice) which is used to write the statements describing each component. We start by explaining the parts of an xAPI statement through examples, then we move to detailing the guidelines for statement design and vocabulary.

Parts of an xAPI Statement

The parts of an xAPI statement are the building blocks which will form the activity trace describing an experience, for example watching a video or submitting a quiz. The xAPI specification specifies 7 fields: the actor, verb, object, context, results, extensions and attachments. Only the first three fields are mandatory for a valid xAPI statement, and are called the “core parts” of the statement, the rest is provided to support information granularity as detailed below [72]:

• Actor: the actor is the person doing the experience. An actor is uniquely identified by their ‘mbox’, making it an obligatory field for the Actor part of the statement. An example Actor is

shown below:

"actor": {

"name": "John Doe",

"mbox": "mailto:[email protected]" }

Listing 3.1 – An example Actor as formatted in an xAPI statement

• Verb: the verb describes what has happened between the actor and the object in a statement. It should be part of a statement, and it is identified with a resolvable URI. TinCan already provides a list of ready to use verbs in their registry12_{. This is an extracted example from the specification’s}

documentation for the verb ‘experienced’:

12_{https://registry.tincanapi.com/#home/verbs}

3.4. Infrastructure Vocabulary "verb": { "id": "http://adlnet.gov/expapi/verbs/experienced", "display": { "en-US": "experienced" } }

Listing 3.2 – An example Verb as formatted in an xAPI statement

• Object: it is the entity upon which the verb occurred. It is an activity such as video watching if we are describing the global interaction, a person if the actor mentions another student in a lesson, or an activity component such as the video if the video is paused. An object should be uniquely identified with a designated URI as in the example below for video watching being the object: "object": { "id": "https://registry.tincanapi.com/#uri/activityType/79", "name": { "en-US": "video" }, "description": {

"en-US": "Represents video content of any kind."

} }

Listing 3.3 – An example Object as formatted in an xAPI statement

• Context: a non-mandatory field to add contextual information to a statement. There are no constraints on what this field holds, in the example below extracted from the xAPI documentation, they include the instructor of the course:

"context": {

"instructor": {

"name": "Irene Instructor",

"mbox": "mailto:[email protected]" }

Listing 3.4 – An example Context as formatted in an xAPI statement

• Results: is a measurement of the outcome of an activity. For example, if John Doe watched a video in a given course and he completed the course successfully with a 95% of the full grade, this could be expressed as follow:

"result": { "completion": true, "success": true, "score": { "scaled": .95 }

Chapter 3. Activity Tracking Infrastructure for Embedded Cyber-Physical Labs

• Extensions: this field can be part of the activity, context or result fields. It is provided to allow for special use by an application or as a convention by a community. This field supports the xAPI acclaimed statement design flexibility, not to limit the granularity a statement holds. In the following example, the extensions to the results informs us that the average grade on the test is 70 points. "result": { "completion": true, "success": true, "extensions": { "http://example.com/course/averageGrade": 0.70 } }

Listing 3.6 – An example Extensions as formatted in an xAPI statement

• Attachments: this field serves to save files associated with an undergoing experience, it could be a certificate of completion as in the example below from the xAPI specification, or in our case, the experimental results the students would save.

{...

"attachments": [{

"contentType": "application/pdf",

"usageType": "http://id.tincanapi.com/attachment/certificate-of-completion",

"display": {

"en-US": "Completion of Experience API 101"

},

"description": {

"en-US": "Certificate provided as proof of completion of Experience API 101

course." }, "length": 63878, "sha2": "c2a36cbc4db66444d05e134b85a89681f65263cacd93eb4a544f0bef058a5649" }] }

Listing 3.7 – An example Attachments as formatted in an xAPI statement

Recipes and Profiles

Recipes and Profiles are meant to control the validity of statements’ vocabulary and structure respectively. A Recipe [71] is a standard vocabulary to be used in describing an experience, i.e. which xAPI statements are used to track a particular type of experience. The main reason for having recipes is to avoid the use of different vocabularies for tracking the same kinds of experiences, which would fragilize the consistency of the xAPI specification and promote redun- dancy. This would also result in different applications recording the same kinds of experience in different ways, which will lead to the need of constructing custom reports for each application, violating the main goals of xAPI: interoperability of the specification. The complete list of 74

3.4. Infrastructure Vocabulary xAPI-ready-to-use recipes can be found on their webpage13_{. While the Recipes are the set of}

statements which describe an experience, Profiles define the expected values and the possible combinations between verbs, results, and activities for a given experience. For example, if the verb is answered in a tracking a quiz experience, the result field should hold a value for the score for that answer and a success field.

There isn’t any Recipe for experimentation with a CPL as an online learning experience, and since we have two stakeholders in need of different answers from activity tracking, we define the Remote Experimentation Profile14with two Recipes corresponding to the lab owners and the students, as detailed in the next.