Tin Can API

The Tin Can API (Application Programming Interface), sometimes known as the Experience API or xAPI, is a brand new specification for learning technology that makes it possible to collect data about the wide range of experiences a person has (online and offline)^[1]. This API captures data in a consistent format about a person or group’s activities from many technologies. Very different systems are able to securely communicate by capturing and sharing this stream of activities using Tin Can’s simple vocabulary.

See also: SCORM

How does the Tin Can API work?

• People learn from interactions with other people, content, and beyond. These actions can happen anywhere and signal an event where learning could occur. All of these can be recorded with the Tin Can API.

• When an activity needs to be recorded, the application sends secure statements in the form of “Noun, verb, object” or “I did this” to a Learning Record Store (LRS.)

• The LRS is a new system that goes hand in hand with the Tin Can API ^[2] . As Tin Can-enabled activities generate statements, they’re sent to an LRS. The LRS is simply a repository for learning records that can be accessed by a Learning Management System (LMS) or a reporting tool. An LRS can share these statements with other LRSs. It can exist on its own, or inside an LMS.

The freedoms of the Tin Can API

Some capabilities that the Tin Can can provide us with are^[3]:

• Statement freedom: The structure of “statements” using nouns, verbs and objects lets you record almost any activity. Think: “I did this.”

• History freedom: The Tin Can API allows LRSs to talk to each other. LRSs can share data and transcripts with one another, and your experiences can follow you from one LRS (or organization) to another. Learners can even have their own “personal data lockers” with their personal learning information inside them.

• Device freedom: It removes the need for an internet browser. This opens up a lot of possibilities of how users experience your content and what your content can be. Any enabled device can send Tin Can API statements (mobile phones, simulations, games, the list goes on). A constant network connection isn’t necessary — occasional connectivity is fine.

• Workflow freedom: Tracking learning events doesn’t have to start or end in an LMS, it can start wherever the learner is and on whatever device they choose to use. Your content isn’t tied to an LMS.

Some Weaknesses:

There are also some areas which need attention keeping in mind the future prospects of Tin Can^[4]:

• Security/Privacy Complexity

The Tin Can API allows for the collection of a lot of data which makes it hard to draw the line between powerful reporting and what would be considered a breach of privacy. The natural question to ask is “who has access to the data, and how do we protect the privacy of learners?” Permissions will get more complex when we look at team-based and collaborative learning and decide whether learners should have access to each other’s data and the limit of that access.

Possible solutions: The accountability will largely be on the LRSs. Multiple user levels with different privileges will most likely be necessary, and an industry-wide list of best practices should be created.

• Activity Definition Agreement

One of the challenges is to make sure that an activity isn’t referred to twice in two different ways. It is also important to ensure that two different activities aren’t referred to in the same way. These questions need clear answers when we talk about activities as parts of statements.

Possible solution: Ideally, organizations would take control of the naming schemes. Domain names could be used to signify that a statement originated from a source, and statements might have to get more complex in order to make sure that they are as accurate as possible. URLs and URIs can be used to signify who really owns a resource and where it came from, but then whoever controls the domain used in a URL would have to make sure to take charge of not having duplicate names for different resources.

• Verb Variation

Another aspect to consider is about setting the standard for the verbs that are used in statements. Is a test completed or finished? Did John read chapter 1 or study chapter 1? In the context of e-learning, completed and finished mean practically the same thing, but for reporting purposes, they’re completely different. With the Tin Can API, we’re able to group certain verbs that mean the same thing and assign different logical results for them. Here are some examples:

 Verb -> Result

 experienced, read, watched, studied, reviewed, learned -> completion

 attempted, performed, played, simulated, answered -> completion, success, score, (interaction details)

 completed, passed, failed -> special

 interacted -> (interaction details)

 achieved -> completion, success, score(interaction details)

 attended -> completion

 taught (by), mentored (by) -> completion

 commented -> comment

 asked -> question

 created, authored, wrote, edited, blogged, shared, posted -> completion, success, score

Possible solution: This list of verbs and results is expected to grow when it needs to, and the long-term plan should be for having a governing body that handles all verbs, verb variations, and their results.