I wrote a post a while back on verbs and promised a follow up on the other parts of a statement that can be defined by a person implementing xAPI. It’s January, so I guess it’s about time… Alright, alright, it’s overdue. In a statement the verb, result, activity, and extensions can all be defined. What I said about verbs basically applies to each of those, in that we need to share. Though, the sum of the data should have greater meaning than it’s parts.
Profiles are a strategy to help systems more effectively use the data in xAPI statements. xAPI has a structured but incredibly open way of dealing with data. This is its greatest strength and weakness. You can do anything you need to do with it, and you can make a big mess of the data in the process.
Absorbing Variety
Image lovingly borrowed from @davegray‘s Connected Company Flickr
While some would call to limit what data can be included in a xAPI statement, this is not a good tactic. By limiting the data that can be transferred in a statement, we are putting ourselves in a box that will make the xAPI specification hard to use as technology evolves. This is why we’re here, now. SCORM did this to us (and probably killed Kenny.)
If we decided right now that all statements had to have a device field and the only options for that field are a list of devices that currently exist, the spec would be hard to use as soon as a new device came out. A device field, if required, would be a problem if no device was involved in the experience a person had. Maybe a teacher observes an excellent book report presentation by Sam, and the device the teacher uses to record that has little bearing on the fact that Sam delivered an excellent presentation. This would break systems that expect the device field to be accurately filled.
If we decided location had to be included and only GPS coordinates were allowed, we would have a really hard time collecting statements from Chewie as he’s experiencing things on the Millenium Falcon when it’s out of range.
Choosing to control what’s possible for data, at the level of the spec, will hinder the ability of systems to self correct in their unique environments. This follows the Law of Requisite Variety (Ashby’s Law). We have a responsibility to not assume that today, right now, is the only thing that matters. The more we embrace the variety of ways people will want to use xAPI, the more potential for innovation we open up.
What is a profile?
Right now there is one companion document to the spec. It’s a profile of what SCORM Run-Time data could look like in xAPI statements — basically a best practice guide for today. Such a profile makes it possible for the kinds of data SCORM content generates and xAPI to work together. It outlines the verbs, results, and activities that should be expected from SCORM course that makes xAPI statements. It also tells you which combinations are to be expected. A statement using the verb ‘attended’ should only have one result, which is completion. The result of a statement using the verb ‘answered’ should be a completion, score, or success.
It’s not that we should be constantly attempting to create our own data profiles, but when that’s the only option, engage communities that have a strong interest in the data to contribute to the profile. That way the profile has use to more systems. Right now, we’re doing this with the CMI-5 working group. We’re taking a very close look at what CMI-5 will need in order to work well with xAPI at the core spec level, then creating a CMI-5 profile that will be used to guide people who are building for CMI-5 in the future. I have talked to big players in the industry who want to start offering the option of using their proprietary API or following their xAPI profile, either would work with their system. The win here is that doing the work to hook in with their system through xAPI with their profile will make it so many more people can accept and use the data than would be able to if you went the proprietary route. It expands the sales options for a tool, with less custom work.
Find something that already exists
Do some research. If there are already people using a data model that works for your purposes, jump on board. There are more data initiatives out there than you may realize.
If you’re in corporate, you probably want to be able to provide data that makes sense to HR systems. Go check out HR XML’s schema for HR system interoperability.
If you’re in K12, your data should make sense to the systems they’re using. Start with the Common Core Standards, they even have URIs. Check out Ed-Fi — their model is based on the US DOE’s Common Education Data Standard (CEDS). Ed-Fi is what initiatives like the Shared Learning Collaborative, are using in their Shared Learning Infrastructure (SLI). Ed-Fi’s data model covers student demographics, staff, academic achievement, behavioral and organizational data.
There are a lot of good data models out there that we can build profiles around and I absolutely welcome you to suggest data models that are worth paying attention to. Please add them to the comments and I will keep this post updated with the list as it evolves.
