Skip to content

Statements 1

  • Interface usada para enviar as ações e experiências do usuário
  • Usa o padrão2 xAPI (aka TinCan) - Experience API

Info

There are two key elements within the xAPI specification: Statements and the Learning Record Store (LRS). Statements dictate the format for specific learning activities and follow an “[actor] [verb] [object]” structure. The LRS is where xAPI statements are stored and its portion of the spec defines the communication method for sending, receiving and requesting data.

Statements

At the simplest level, xAPI statement structure can be expressed in the form of “actor verb object”. An example of this sort of statement is “Sally experienced ‘Solo Hang Gliding'”. In the technical introduction, we saw the JSON format of this statement as

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
{
  "actor": {
    "name": "Sally Glider",
    "mbox": "mailto:[email protected]"
  },
  "verb": {
    "id": "http://adlnet.gov/expapi/verbs/experienced",
    "display": { "en-US": "experienced" }
  },
  "object": {
    "id": "http://example.com/activities/solo-hang-gliding",
    "definition": {
      "name": { "en-US": "Solo Hang Gliding" }
    }
  }
}

Tip

É possível usar um assistente para montar os Statements no link xAPI Lab

Actor

In xAPI, people don’t have to be solely identified by one system or ID. That’s an important step in making xAPI person-centric. Imagine a consolidated view of your activity across all the systems with which you interact. Though you tweeted using @yourhandle on Twitter, when you see the whole of your activity, you see the experience more in the terms that you tweeted, the same “you” that took ‘Solo Hang Gliding’ and the same “you” that read Hang Gliding Training Manual. Due to privacy concerns, each statement will contain only one representation of “you”, however reporting systems that are aware of these multiple personas may aggregate them.

With that explanation in mind, let’s look at our example actor object:

1
2
3
4
{
  "name": "Sally Glider",
  "mbox": "mailto:[email protected]"
}

This actor object has two properties, “name” and “mbox”. Only “mbox” uniquely describes this Sally. There may be many people out there with the name Sally, but only one of them owns the email address [email protected]

Let’s consider another way to represent Sally:

1
2
3
4
5
6
7
{
  "name": "Sally Glider",
  "account": { 
    "homePage": "http://twitter.com",
    "name": "sallyglider434"
  }
}
In this case, we are identifying Sally by her twitter account with the handle “sallyglider434”. This flexibility in identifying people is an important feature of xAPI

Tip

More details about Actor/Agent Deep in the link: Deep Dive: Actor/Agent

Verb

Verbs in xAPI are URIs, and should be paired with a short display string. They are a crucial element of statements, as they describe just what has happened between the actor and object of the statement. The xAPI specification allows any full URI to be used as a verb. A basic verb example:

1
2
3
4
5
6
{
  "id": "http://adlnet.gov/expapi/verbs/experienced",
  "display": { 
    "en-US": "experienced"
  }
}

Tip

There's a place called "Experience API Registry", where you can find a list of already created verbs. It’s certainly a good idea to at least consider these verbs before creating your own. That list includes “experienced”, “attended”, “attempted”, “completed”, “passed”, “failed”, “answered”, “interacted”, “imported”, “created”, “shared”, and “voided”

Object

Wrapping up the core statement structure, let’s consider the “object” field. Typically the object will be a xAPI activity, though it might be another actor, and in the case of voiding, another statement. Let’s take another look at the object from our example statement:

1
2
3
4
5
6
{
  "id": "http://example.com/activities/solo-hang-gliding",
  "definition": {
    "name": { "en-US": "Solo Hang Gliding" }
  }
}
The definition for an activity object can be refined over time (though it shouldn’t ever be changed significantly enough to describe what should have been some other new activity). Descriptive fields in the activity definition offer a way for xAPI to natively support internationalization. Let’s add some more info to our example object as an example:
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
{
  "id": "http://example.com/activities/solo-hang-gliding",
  "definition": {
    "type": "http://adlnet.gov/expapi/activities/course",
    "name": { 
      "en-US": "Solo Hang Gliding",
      "es": "Solo Ala Delta"
    },
    "description": {
      "en-US": "The 'Solo Hang Gliding' course provided by The Hang Glider's Club",
      "es": "El curso de 'Solo Ala Delta' siempre por el Club de Planeadores Hang"
    },
    "extensions": {
      "http://example.com/gliderClubId": "course-435"
    }
  }
}
Here we’ve added a “type” field, indicating the activity is a course on solo hang gliding. We’ve also added a “description” field, which as expected, contains a short description of the course. In the case of “name” and “description”, we’ve added the Spanish version. This way, reporting tools or other display layers could automatically switch the language output based on a user’s preferences.

We’ve also added to the “extensions” field, where we can put arbitrary key (URI) / value pairs that are custom to a particular application (or convention). We’ll talk more about extensions below

More about Statments

What is a Learning Record Store (LRS)?

The LRS is the heart of any xAPI ecosystem, receiving, storing and returning xAPI statements. You’ll need an LRS in order to do anything with xAPI. Every other tool which sends or retrieves learning activity data will interact with the LRS as the central store.

The LRS, as defined by the xAPI specification2, is “a server (i.e. system capable of receiving and processing web requests) that is responsible for receiving, storing, and providing access to Learning Records.” Taking this a step farther, the LRS is designed to enable systems to store and retrieve xAPI statements, store xAPI state, and store various other xAPI metadata from other systems. When considering what an LRS actually is, it’s important to remember that the S stands for STORE, meaning that the most basic function of an LRS is to store and make available xAPI statements.


  1. Parte dos textos e referências são de autoria do site https://xapi.com 

  2. xAPI specification