Contact Us Support Forum Get Email Updates
 
 

Thanks! Someone will be in touch with you shortly.

Rather just email us? Email us here.
Rather speak with someone in person?
Call any time with Tin Can questions:

866.497.2676

Finding the Source

Posted by

Categories: APIs, Best Practices, Deep Dive, Ideas, Recipes, Standards, Statement Anatomy, Tin Can

Posted 25 August 2015

 

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, Tin Can 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 Tin Can statements to recognize which tool sent the statement and handle it in a slightly different way.

We’re encouraging products that adopt Tin Can 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 Tin Can 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.

 

Tin Can API Email Updates

* indicates required

Tin Can API Email Updates

Thanks for signing up for the Tin Can API newsletter!

Make sure to follow us on Twitter @ProjectTinCan,
and tweet this page to let others know about the Tin Can API.

Close