This week I had the privilege to work alongside Ben Betts, Jonathan Archibald, Andrew Downes, and Mark Aberdour at the xAPI barcamp run by LearnPatch. Over 40 of me gathered at the Cumberland Arms to spend an hour or so in conversation about xAPI (aka Tin Can API).
Each of the team spent 15 minutes chatting about my own take on xAPI at each table. Then I moved on. It was like consultant speed dating!
There was a great buzz in the place, with some of the great minds in learning and development grappling with the difficult questions around xAPI:
All of these questions deserved digging into in far more depth than was possible, given the available time.
During all my conversations with people, I was asked about the xAPI implementations Wyver Solutions is involved in. Some key points came out, which I thought I’d share here.
At the moment, many implementations of xAPI will be bespoke and unique, with their own vocabulary. Eventually, different communities/industries will start to develop their own particular flavours, which allow data to be moved between systems with relative ease.
For now, each time we implement xAPI in an organisation I have to work through the following thought process…
Most of the time, I don’t just want to collect data for the sake of collecting it. I’ll want to use it to help me make decisions. Usually these will be focussed on the core “business objectives” for my particular organisation. For example, in a sales-based organisation, I’d want to know what learning activities make a difference to the sales figures, so that I can decide which activities to invest in.
Here I think about the reports that might be used to help me decide. In my example sales organisation, I would want charts that show sales figures correlated with when different types of learning activities were undertaken.
This is when I start getting into the detail. In my example organisation, I’d want to be capturing data when an individual does a particular type of learning activity, and also capturing when they sold something, and how much for.
The Tin Can API registry contains a community generated set of vocabulary (verbs, activity types, extensions etc) that have recognised, generic definitions. Ideally I would limit my own vocabulary to this lists.
However, in many contexts, I need to create additional vocabulary so I can model the organisation more accurately.
For example, in a professional development organisation, which has annual CPD returns, I might want to create the following statement:
Joe Bloggs audited [another statement]
Audited doesn’t exist in the registry, so will need to be defined and possibly submitted to the registry. However, “audited” in this context means something very different to “audited” in an accountancy context. So it is likely to remain as a domain-specific definition.
Posted: 31 January 2015