Statements come from all kinds of places: content created in authoring tools, mobile apps, learning platforms and business systems. It’s not always immediately obvious which application the statement came from, which might be useful to know. This blog explains how you can tag the statements your tool or product generates and why that information is useful.
We’ve worked hard to make the Tin Can (xAPI) spec as clear as possible and have required Learning Record Stores (LRSs) to validate incoming data to ensure the same data structure is always used. There’s no way for statements to be sent to a conformant LRS unless they follow the prescribed data structure, and you’ll find that the major LRSs are strict with the data they accept.
There can still be variation between the content of statements sent from different tools, though. To enable tracking of any learning experience, xAPI allows the content of its data structure to be flexible. Recipes are then used to define the statements and data to be sent by activity providers for a particular use case. Recipes are designed to ensure that tools of the same type all send the same data so that tools receiving that data can work with any product in the same way.
That’s the theory. If you’ve worked with e-learning specifications, you’ll know that different tools interpret those specifications in slightly different ways. The same will be true of recipes. This is partly down to misunderstandings but can also be caused by genuine differences between the tools; if the learner experience is different, then different data is likely to be tracked. Often these differences are minor and don’t matter, but sometimes it’s useful for tools interpreting the xAPI statements to recognize which tool sent the statement and handle it in a slightly different way.
We’re encouraging products that adopt xAPI to tag their statements to show the source product of the statements, whether that’s an authoring tool, an LMS or some other type of product. This is done by adding a ‘category’ type of Context Activity to the statement, for example:
"context": {
"contextActivities": {
"category": [
{
"id": "http://example.com/url-representing-your-product-version/",
"definition": {
"type": "http://id.tincanapi.com/activitytype/source"
}
}
]
}
}
The activity id used here should be a URL representing a major version of your product. This will allow tools consuming the statement to best handle differences in your xAPI tracking between versions of your product.
This is a small addition to your tracking data, but it could wind up being really useful. Please contact us if you have any questions.
