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

It’s Time for Profiles

Posted by

Categories: APIs, Best Practices, LRS, Standards, Statements, Tin Can

Posted 15 January 2013

 

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 Tin Can. 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 Tin Can statements. Tin Can 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 Tin Can 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 Tin Can 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 Tin Can, 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 Tin Can statements — basically a best practice guide for today. Such a profile makes it possible for the kinds of data SCORM content generates and Tin Can to work together. It outlines the verbs, results, and activities that should be expected from SCORM course that makes Tin Can 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 Tin Can 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 Tin Can profile, either would work with their system. The win here is that doing the work to hook in with their system through Tin Can 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.

 
  • http://twitter.com/mrdownes Andrew Downes

    Excellent post Megan. I expect this to be referenced for years to come. I am currently working on a blog about the State, Activity Profile and Agent APIs and this has got me thinking. Should Agent profile documents also be included In profiles such as the companion document.

    Your post is well timed and clearly outlines what needs to be done in defining a profile. I would be very interested to see examples and drafts of other profile documents and how they compare to the companion document.

    I’m also still waiting for your blog on Activity Definitions!

  • Meganbowe

    I think there are some interesting things to explore with how we identify agents and groups, especially in the case of a educational institutions with a lot of different models for courses and collaboration. Going to have to think on that for a bit. It would make sense that the companion document include agent profile, though.

    Thanks for your response! Stewing on activities, soon I’ll get that written 🙂

  • Ellen Meiselman

    Would something like the Medbiquitous Activity Report spec be relevant here?

    http://www.medbiq.org/working_groups/activity_report/ActivityReportSpecification.pdf

  • Meganbowe

    With a cursory glance, that looks very useful. I suspect that, since it’s you suggesting it Ellen, it’s very relevant 🙂

  • Pingback: Tell Your Own Learning Story through #xAPI | Classroom Aid()

  • Pingback: The Sauce Behind Recipes - Tin Can API()

  • Pingback: Deep Dive: Interoperability and the Document APIs - Tin Can API()

  • Ifeora Okechukwu

    Great post Megan! I really don’t understand the relationship between profiles data and tincan statements. is it that verbs, objects (Activities or Agents) are profiles in themselves ? I thought profiles where documents that contained information about activities and/or agents. or is it that by defining a new profile document (via the API on LRS), we can include new custom fields to statements or their parts (verbs, results, objects, extension e.t.c) ?


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