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:
- If I can now collect data about everything that a person is doing, what about privacy?
- Who owns this data?
- If many implementation of xAPI are going to be bespoke and unique where does that place it as a “standard”?
- How do you know what data to collect?
- Is xAPI ever going to break out of the L&Dbubble and start to be used by operational systems?
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.
Bespoke & unique
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…
Why are you collecting data?
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.
What information do you need to make decisions?
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.
What data is required to produce that information?
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.
What bespoke vocabulary do I need?
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
Tags: Standards