Tin Can API new solution, same problem?

I’ve just caught up with the SoLAR webinar featuring Megan Bowe talking about the Tin Can API. Tin Can is being supported by ADL and is in many ways an evolutionary step from the SCORM heavily content driven approach to a specification that is much more flexible and context and activity driven.

It is being designed so that it can work with SCORM content but also pull in data from a multitude of other sources. The idea is that this data is stored in a Learning Record Store (LRS) on top of which reporting or visualisation (of particular interest of course to the SoLAR community) can sit. Being concerned with storing activity data it has used bits of the activity streams spec but is adding to that to make it more relevant for learning activity. There are also similarities between it and RDF. Tin Can is based on actor/verb/object statements which has a familiar subject/predicate/ ring to it and it also uses URIs. However Tin Can is as Megan put it not as “chatty” as RDF.

The spec is at very early stages and work on it has only really being going on for about a year. It is taking a very open development approach which is always good, and there does seem to be growing interest in it from vendors. But it does suffer from the age old problem of adoption. Megan was very up front about the difficulties in building LRS’, but if you have a lack of LRS’s then there is a following lack of reporting/visualisation layers for people to experiment with. The initial support (not surprisingly) seems to be coming from the commercial training sector. One example of this is MapDeck, a powerpoint aggregation and remix tool which uses the Tin Can API primarily in its search functionality. Megan also highlighted Tappestry (a mobile interface) which I have actually downloaded but to be honest never quite figured out how to incorporated into my daily activity. I think that might be more a personal #fail than a technical/UI one.

Of course. like any specification, to get traction takes time and as Megan said they are still at the “baby steps” stage just now, and I think the initiative should be given credit for taking a radical shift from the SCORM model. Getting past the baby steps stage is going to be quite a challenge and I do wonder if in education initiatives like iBloom which Lorna reported on recently might detract development activity away from building the kind of LRS’ advocated by Tin Can. There was also some discussion about the use of LTI (which connects systems and can pass limited amounts of data at the moment), but again it seemed that this is probably a next stage development. At the moment I think it’s fair to say that LTI and Tin Can are looking at slightly different types of system connections.

Anyway if you are interested in finding out more I would recommend having a listen to Megan’s presentation and looking at the Tin Can API website.

3 thoughts on “Tin Can API new solution, same problem?

  1. Hello Sheila, agree that it will take some time for the community to develop useful sorts of analysis and visualizations. While it is difficult to build an LRS (we know because we have built one, commercially available), we are confident that others will come along as the spec matures (v1.0 coming in the next couple of months).

    There is some interesting custom reporting work being done on Tin Can data, and I think the community will benefit from seeing practical use cases once it all comes together in the coming months.

  2. Hi Ali

    Thanks for your comments and yes hopefully we’ll see some more interesting use cases over the coming months.

    Sheila

  3. Pingback: continuously collating experiences and TinCanAPI | learn4kicks