There are so many blog posts and technical documents on the internet telling you about TIN CAN, xAPI and the available products that they can leave your head spinning.
It seems every time you start reading information about TIN CAN and xAPI, within a short period the information starts getting technical and understandably confusing to most of us.
There are reasons for this…
The TIN CAN API (also known as the Experience API (xAPI)) is just that – an Application Programmer Interface (API) letting you programmatically make use of features and functions that the xAPI serves. In plain terms, this means;
TIN CAN API is a bunch of code level access points in a web service where a program can send and receive information to an application
That Application contains an entry point know as an Endpoint and that Endpoint is reflected as a URL out on the internet. The name of the application (in general) is Learning Record Store, or LRS.
The type of information the TIN CAN API can send and receive is known as an Experience. The DNA of an experience contains information about:
WHO did something: WHO is a PERSON
- What makes the TIN CAN API stand-out is that this person needs to be authenticated (proven to be a valid user) in the application they are using, not always in the server.
- As long as the TIN CAN Enabled application can capture the persons First and Last name as well as their email address, it can use this information and record it into an experience that is sent to the LRS for reporting.
- A USER is referred to in the TIN CAN API as an ACTOR (I assume this is simply because they are acting on, or reacting to, something that is available to them. An ACTOR will have a First and Last name, such as “John Doe responded to a question”.
An ACTOR:
- Must have a first and last name
- Must have an email address (example)
- Normally does not need to log into any system, but should at least be locally authenticated, to use your TIN CAN enabled content
- Normally does not need to be registered in any system to be a user of your TIN CAN Enabled content
What they DID: DID is an ACTION
- What makes the TIN CAN API stand-out is that the ACTION does not even have to actually exist (although it is best if it was a real action Here is a specification of a real action:
- The name of the action: responded
- The Description of the Action: Used to record a learner action of responding to some action or event.
- Examples include responding to a fire alarm or responding to a question.
- “responded” is actually a valid action, therefore you can actually see it at this link: http://adlnet.gov/expapi/verbs/responded
- The link above is located on the internet and can be accessed by a LRS
- This means that when a user interacts with an object in their learning path, and that object reports their interaction as “responded”, the LRS will report something like “John Doe responded to a question” Responded will be a clickable link that instructors, teachers, management and administrators can use in detailed reports.
- I use this one example; however, I could have used a non-existent example like “traversed”; where “John Doe traversed Mount Shasta”.
- Even in this made-up example, there actually is a real link to the verb on the internet at: https://en.wikipedia.org/wiki/Traverse. One of the descriptions could be used as the verbs definition. Having no formal verb in a web based library of verbs does not stop me from using it.
- If a verb does not exist, you should not expect to see a description of it, but it can still be a recorded and reportable ACTION.
On a side note: If John Doe traversed Mount Shasta, the proof could be validated in the experience recorded to the LRS.
The experience should contain a Latitude and Longitude of John Doe when this experience was acknowledged by John while standing at the top of Mount Shasta.
Did I mention that TIN CAN statements are stored locally on a device until they are able to be sent to an LRS?
There was no magic that occurred for this to happen; it’s a built–in feature of all TIN CAN enabled products.
What they did it TO: TO is a NOUN
As you may have guessed, TO is an object that a person can interact with.
-
- The object you refer to may be a question, a graphic item, a geographical location (Lat. and Long. or by name), or even a physical device.
- Continuing with our example, “John Doe responded to a question”, the object is a question. In our other non-existent verb example “John Doe traversed Mount Shasta”
- In this example, Mount Shasta has a descriptive resource on the internet at: https://en.wikipedia.org/wiki/Mount_Shasta
If you want an object to record someone’s interaction with it, it will need to be a TIN CAN Enabled object, meaning: It will need to have a name and should have a description somewhere on the internet. If you just used some existing generic name, it may not have much meaning.
Now you know the DNA of what is referred to as a XAPI Statement.
Let me finish this post by simply providing a short list of the most common features that the TIN CAN API used with a compliant LRS can provide you:
- Taking e-learning outside of the web browser
- E-learning in native mobile applications
- More control over learning content
- Solid security using Oauth
- Platform transition; e.g. start e-learning on a mobile device, finish it on a computer
- The ability to track games and simulations
- The ability to track real-world performance
- Team-based e-learning
- Tracking learning plans and goals
I hope you’ve both enjoyed reading this Blog post and have a better understanding of the details sent, received and recorded to a TIN CAN xAPI enabled learning system.
If your interested in finding out more, try our 30 days trial of TIN CAN Manager and your own LRS. During this time, we’ll help answer any questions you may have about your TIN CAN Manager products and services.
We also encourage all to reach out to your learning development software manufacturers and let them know your specific interest in TIN CAN.
Best Regards,
Dennis Hall
