xAPI / Tin Can to LRS to LMS

3.2k views Asked by At

I am trying to better understand how xAPI / Tin Can works (I'm going to call it xAPI henceforth)

Previously I was developing for a SCORM 1.2 LMS where there were 'records' such as: Raw Attempts, Status and Raw Score for each content package. The LMS wants to upgrade to xAPI but I am unsure about the theory behind how xAPI works.

On http://tincanapi.com/learning-record-store/ it states that:

The data stored in an LRS can be accessed by LMSs, reporting tools, or other LRSs, and can be stored as individual learning records and/or entire transcripts

Subsequently on http://www.learningsolutionsmag.com/articles/1271/the-xapi-and-the-lms-what-does-the-future-hold it also states that:

An LMS that has a built-in LRS supports the Experience API and also does all the other things LMS products do to manage learning delivery.

The question is,

What exactly does this relationship between an LMS and LRS entail? I need the ability to set the said LMS 'records' from an application that resides outside the LMS, how do you do this using xAPI?

Or maybe I've completely misunderstood the xAPI LRS and it is designed to completely replace LMS records?

Thanks for the help. Links to informative resources on this will also be greatly appreciated.

4

There are 4 answers

6
Mark On BEST ANSWER

A LRS is a Learner Record Store which is a series of statements about what the learner did or is doing. Someone can correct me, but I believe Activity Streams were created by Social Media entities around 2006, and different entities adopted/extended it for a flavor of e-learning standards.

If we deconstruct the two real quick (high level) -

An LMS was a portal with assignments, reports, maintenence/admin tools, forums etc ... sometimes a LCMS (learning content management system) and other variations of an all-in-one web based solution. AICC was developed during CBT (DOS - Disk Operating System), then browsers (pre-XML). SCORM came shortly after (post XML, pre JSON) around 2001 now living in the world of Browsers (HTML/CSS/JS, Macromedia/Adobe Flash, and others). So with SCORM you are essentially bundling up little portable websites, which later we were able to extend to use content media servers, or CDNs to keep the 'logic' and 'assets' externalized. SCORM was based upon sharing training via a CAM/PIF package, which included a manifest/table of contents, and your HTML files, which covered the packaging portion of the specification. The second part of this was the Runtime. The LMS will expose this runtime to manage the student attempt. This, in a way, is like the 'statements' only that it is the entire student attempt data or CMI object. This includes: scoring, Interactions, Objectives, and other data points. SCORM 2004 Extended this further to make much of the specification manditory, forcing the LMS to support richer Sequence and Navigation capabilities. These were often deemed too complicated, and hard to manage mainly due to a lack of tools and support. But people do use them.

A LRS via an 'endpoint' is much like you posting statements to a server. There are XML and JSON implementations of this. So in away, when you deploy your 'app' you're passing in a URL for it to communicate with. You can actually convert some of the SCORM centric stuff into an xAPI statement, but keep in mind xAPI doesn't control packaging, or sequence and navigation. All of this is now based on your Application (web, iOS, Android, etc ...) managing this. It mainly allows a non-HTML application to now take advantage of training, since SCORM was primarily a JavaScript communication standard.

So you have to take a pro/con look at what you're trying to do, how SCORM or xAPI, Activity Streams or some proprietary approach fits your needs.

A xAPI statement may look something like :

{
actor: {
    name: "Learner Name",
    objectType: "Agent",
    account: {
        homePage: window.location.href,
        name: "Learner ID"
    }
},
verb: {
    id: "http://adlnet.gov/expapi/verbs/completed",
    display: {
        "en-US": "completed"
    }
},
object: {
    id: "commonly a URI",
    objectType: "Activity",
    "definition": {
        type: "http://adlnet.gov/expapi/activities/lesson",
        "name": {
            "en-US": "Some Name"
        },
        "description": {
            "en-US": "Some Description"
        }
    }
},
result: {
    completion: true,
    success: true,
    duration: 'PTHMS'
    score: {
        scaled: 0.9        
    }
}

}

SCORM, is mainly locating the LMS Runtime (API_1484_11 or API) and then making method calls to Initialize, Set/Get Value, Commit and Terminate. CMI Object (for SCORM 2004) looks a bit more like this once its filled in. https://gist.github.com/cybercussion/4675334

8
Andrew Downes On

I'm not sure I completely understand the question, but will try to answer anyway.

There's a few different ways an LRS might relate on an LMS. I've listed these in order of how common they are amongst LMS vendors today and the order that many LMS vendors seem to be following.

  1. The LMS might launch learning experiences. When doing so, it might provide the learning experience with some security credentials and an endpoint url for an LRS so that the learning experience can track back to the LRS. These learning experiences might be packaged content uploaded to the LMS or external content.

  2. The LMS might include an LRS as part of the LMS application. See, for example here. LRSs included within an LMS should always have the functionality to connect to an external LRS.

  3. The LMS might pull data from the LRS, for example to use in dashboards and reports or to support completion tracking.

  4. Activity within the LMS e.g. forums, quizzes etc. might be tracked using Tin Can to an LRS.

It sounds like from your question that number three is what you're looking for? The high level approach here would be to have these external sources feed into an LRS and then push/pull that data from the LRS into the LMS.

2
Zze On

What I have learned

It is best practice to use the LMS for content delivery and the LRS for analytics. All reporting goes through the LRS which will track extended data, then the LMS will track its normal data (scorm1.2 etc) .

Let the LMS do what it does now - course completion, bookmarking and serving the content to the user. Then use LRS for more complex data capture - which path, how long on an interaction, answer given, selection of answers chosen - your "who did what how".

'Most people' using xAPI have ditched their LMS and everything is now done via the LRS i.e. They have dropped hybrid LMS/LRS structures - Why? Because this uncouples all possible learning mediums - apps, videos, face to face etc can now all be tracked in one system to form a more cohesive architecture for analysis / auditing / reporting.

When deploying an iPad app, this directly communicates with the LRS and at no point in time is the LRS able to communicate with the LMS unless YOU write some custom 'web hooks' / code to tie the 2 together - not consensually recomended.

When deploying browser based learning, you can jointly send data to both the LMS and LRS seperately - drawing from the LRS when we need additional analytics about what the learner has done and then leaving the LMS to retain its current functionality - "are we done yet".


Summary

To answer my original question. There is no default relationship between the LMS and LRS. If the content is outside the LMS - it is OUTSIDE the LMS permanently - it does not interact with it in anyway. Consider just mimicking the same data fields of the LMS into your LRS calls and run custom reports from the LRS's database.


Notes

Thanks to @Mark for his detailed explanation on the 2 systems and assisting my inital understanding of the systems.

This information has been gained from work related experiences - sorry no official sources.

2
Art Werkenthin On

I suggest you take a look at cmi5, a protocol for xAPI that defines communication between the LMS, LRS and learning content. The determination that a content module has been completed and/or passed is defined in this specification.