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 Experience API questions:

866.497.2676

Archive for the "LRS" Category

Recently, ADL (the Advanced Distributed Learning Initiative) launched the xAPI Adopter Registry, which lists xAPI Adopters and Conformant LRSs. We’re thrilled to be one of the first companies included on the xAPI Adopter Registry and the only company so far to have two conformant LRSs–both SCORM Cloud and SCORM Engine passed the LRS Test Suite.

So why is this so exciting?

The registry is a valuable resource for the eLearning community because it promotes adoption of the Experience API and provides a core list of xAPI conformant products. The LRS Test Suite is extensive, covering 1,300 strict criteria that ensures true adoption of the xAPI specification and therefore guarantees interoperability across eLearning systems.

Personally, we have been involved in the learning standards community since 2002 and in that time have come to understand the true value eLearning specifications provide in ensuring interoperability. With xAPI, we are excited about the possibilities for new ways of learning and are here to both encourage adoption and help add other companies and vendors to this growing list.

No Comments
 

Why cmi5?

Posted by

Categories: cmi5, Deep Dive, LRS, Recipes, Standards, Statements, xAPI

Posted 11 May 2017

 

The part of the xAPI community that loves the freedom to live outside of an LMS, the vast majority of it, loves cmi5. They just don’t know it yet.

This is the story of how I came back to an LMS, after having never really used one. The story about a little specification that took forever, but in the end provides a wandering community with just enough fencing to get them back on a path. But the part they’ll really like — it can be any path.

That fence is constructed between the following posts:

  • Launch: have to have it for endpoint + credentials
  • Statement Guidelines: have to be able to recognize a statement and understand how it was intended to be understood
  • Session: we always want start and end anyways
  • Flexibility: allows you to take any trail you like

Launch

Don’t think of the LMS as an LMS, instead, think of it as a “cmi5 launching” system.

Everywhere I looked there was launch staring me back in the face. I couldn’t get away from it. (Believe me, I’m the revolutionary in a company who lives and breathes SCORM and LMSs, and I tried to get away from launch.) Repeatedly on calls with clients wanting to create products with xAPI, I would say, “Sure you can capture any data you want, that isn’t a problem, but the hard part is getting the endpoint, and even harder, the credentials.”

It turns out that in practice, so many of the clients I was working with had these systems that told their learners what types of learning and training they should be participating in. These clients were excited about xAPI, and they were already bringing their learners to the list of tasks available to them. cmi5 is providing a standard way to handle this across different systems and experiences.

Statement Guidelines

Presuming you have your endpoint and credential problem solved and the data is flowing into your LRS from your content, as well as from all your other xAPI-enabled sources, then the next problem hits — the xAPI flexibility problem. This is the problem that an xAPI recipe was initially intended to solve. A consumer of xAPI data needs to have a way to identify the semantic meaning of a statement as a whole so that it can “understand” that statement. cmi5 pays particularly close attention to this concept and provides a means to identify statements with specific cmi5 meaning that the launching system (or any reporting system) can use to frame the context. Beyond specific cmi5 statements, it provides a templating system for how other statements can include basic information, allowing all of the statements in an experience to be tied together efficiently. Although sometimes we prefer a path less taken, most often we want a well worn path with a pre-defined destination. Spelling out how to detect and use a cmi5 statement in a massive pile of data makes it much easier to develop and much faster to execute for the reporting system.

Session

I work with and on eLearning standards every day, particularly xAPI, and despite the best efforts of the community to date, it feels like gaining widespread adoption of profiles and recipes has been a slow, uphill push. The thing that I found, however, is that every non-trivial type of experience we want to explain with profiles and recipes all start with the actor “initialized something” and end with the actor “finished something,” and it didn’t matter what the “something” was. The session concept in cmi5 has these markers and can provide a shell for other profiles and recipes that are defined in the future to live inside of. There is no reason for anyone else to worry about how to create those types of statements and indicate these types of events. We can just wrap them in cmi5.

Flexibility

So far, a lot of adoption of xAPI has been from people that love to trailblaze, and they are critical to the process. But for every one of them, there are lots of people that like to start on a well traveled path, take small excursions into the thick, and then return to that comfortable path. cmi5 is perfect for both because it allows you to send nearly any statement you want (yeah, yeah, not voided; I said nearly). You can stick to the well defined statements associated with common LMS concepts such as completion, success (pass/fail) and score, or you can use cmi5’s concept of “allowed” statements which is virtually any other statement. You can have your cmi5 content send statements across several different profile types, or invent your own.

:::::::::::

The amazing thing about a path is that it is exciting for each new traveler, even though inherently none of it is new. The reason to love cmi5 is that all of these fundamental concepts necessary to start making robust end-to-end applications of xAPI have been codified in one succinct specification by original pioneers in the xAPI community. We’ve had four years of xAPI wandering, and now it is time for LMSs, rapid authoring tools and less traditional eLearning platforms to all find a path to success. cmi5 can be that path.

No Comments
 

How to share statements

Posted by

Categories: Experiments, Ideas, LRS, News, Use Cases, xAPI

Posted 30 April 2015

 

We recently collaborated on a project to share statements between three LRSs by three different vendors. This three part blog series outlines the project, explores some use cases for sharing statements and then dives into the technical details. You’ll find similar (but distinct) blogs by the other project collaborators on the Saltbox and Learning Locker websites.

In the previous blog in this series I outlined five realistic scenarios in which an organization might have multiple LRS to share data between. This last blog dives into some of the technical approaches to share statements between two LRSs. If you’re looking more for how to set up Statement Forwarding in SCORM Cloud or Watershed, take a look at the News to Me: Statement Forwarding blog too!

how-to-share

One way sharing

One approach is to have one LRS share its statements with another. This means that all statements in one LRS are transferred to another, but any statements already in the second LRS are not transferred back to the first. This can either be achieved by one LRS sending statements to another, or by one LRS querying another for statements.

Two way sharing

An extension of one way sharing is to additionally share statements in the other direction such that all statements in each LRS are shared with the other. This can be achieved by:

  • Both LRSs sending their statements to the other.
  • Both LRSs regularly querying the other LRS to fetch statements.
  • One LRS sending it’s statements to the other LRS and also querying that LRS for statements.

Man-in-the-middle application

It’s also possible to share statements using a 3rd party, man-in-the-middle application that sits outside the LRSs. This kind of application is configured to fetch statements from particular LRSs and send them on to other LRSs. The application doesn’t necessarily store the statements itself, it just fetches them and sends them on to their required destination.

Download and upload

Finally, statements can be between LRSs by downloading the statements as a JSON document from one LRS and uploading it to another. This method is particularly valuable for transferring statements where the LRSs are not able to directly connect to one another due to connectivity issues or security restrictions.

These methods of sharing are outlined in more detail in the whitepaper co-authored by the project collaborators. We’ve produced a screencast demonstrating the project proof of concept in action. You can also attend a webinar where we’ll discuss all of this in more detail!

We hope you’ll find the answer to any questions in the whitepaper, webinar and screencast, but if not, please do get in touch with any questions you have!

 

3 Comments
 

Why share statements?

Posted by

Categories: Experiments, Ideas, LRS, Use Cases, xAPI

Posted 23 April 2015

 

We recently collaborated on a project to share statements between three LRSs by three different vendors. This three part blog series outlines the project, explores some use cases for sharing statements and then dives into the technical details. You’ll find similar (but distinct) blogs by the other project collaborators on the Saltbox and Learning Locker websites.

In the previous blog in this series, I outlined an experiment we conducted to share statements between three different LRSs as a proof of concept. This blog outlines five realistic scenarios in which an organization might have multiple LRS to share data between.

why-share

LRSs owned by different stakeholders

One use case for sharing statements that’s already happening in the wild is product vendors maintaining their own LRS and also sending the data to the customer’s LRS. This might include authoring tool vendors, content vendors, LMS vendors, indeed any vendor with a product that generates statements.

Getting data out of or into an LMS

An LRS can either sit inside an LMS or be a separate product outside of it. Some organisations may have both an LRS inside their LMS and an external LRS that connects to a variety of different data sources. In these cases there is a need to share statements between the LMS embedded LRS and the external standalone LRS.

Migrating to a new system

When choosing a shiney new learning platform, it can be tempting to think it will last forever. All things come to an end though, and having a plan to get your data out when the time comes is vitally important. If you store all your learning records as statements in an LRS, statements can be shared with the new LRS when the time comes, making that part of the data migration incredibly straightforward. You then only have to worry about data not stored in the LRS! This is an important use case of statement sharing.

Pushing statements to a non-LRS system

There are a number of systems other than LRSs that use statements in some way to do some thing. Here’s some examples:

  • A business information tool might use information contained in statements alongside other data to deliver business intelligence and provide other functions.
  • A Training Delivery System might deliver performance support materials to learners at the point of need based on their activity as tracked in statements.
  • A credentialing, certification or badging tool might award credentials, certificates or badges based on achievements reported in statements.

Multiple LRSs within an organization

There are a number of reasons why an organization might have multiple LRSs. For example:

  • Following a merger of two companies, where both companies had their own LRS.
  • In a large organization with autonomous departments that have their own systems.
  • An organization spread across multiple sites and/or countries.
  • An organization including sites or operations with limited or intermittent connectivity such as a disaster zone or a ship.

These scenarios are outlined in more detail in the whitepaper co-authored by the project collaborators. We’ve produced a screencast demonstrating the project proof of concept in action. You can also attend a webinar where we’ll discuss all of this in more detail!

We hope you’ll find the answer to any questions in the whitepaper, webinar and screencast, but if not, please do get in touch with any questions you have!

2 Comments
 

A Tale of Three LRSs

Posted by

Categories: APIs, Best Practices, Experiments, LRS, Use Cases, xAPI

Posted 16 April 2015

 

We recently collaborated on a project to share statements between three LRSs by three different vendors. This three-part blog series outlines the project, explores some use cases for sharing statements and then dives into the technical details. You’ll find similar (but distinct) blogs by the other project collaborators on the Saltbox and Learning Locker websites.

The main goal of the Experience API (xAPI) is interoperability; the sharing of learning records between multiple systems created at different times, by different people and organizations. We’ve worked hard to produce a specification that defines that communication between learning systems in detail so that any two systems that follow the specification will be able to interact.

That’s great in theory, but what about the practice? Does it actually work with real systems available on the market today?

Recently, with our friends at Saltbox (Wax LRS) and HT2 (Learning Locker), we set out to put this to the test.

three-LRS

Our experiment involved the set-up illustrated in the diagram above. Statements were sent from activity providers to both Learning Locker and to Wax LRS and we set up Moodle LMS to display statements pulled from Watershed. We then configured statements to be shared one way from Learning Locker to Watershed and two ways between Watershed and Wax.

On the first attempt, the process was broadly successful but revealed a few issues that had to be resolved. On the second attempt, the process worked seamlessly; all statements going where they were supposed to without error.

The project proved the robustness of the the Experience API (xAPI), showing that where the spec is followed correctly, systems will work together. It also illustrated the importance of testing products with other systems to highlight areas where interoperability requires a little more work.

You can read about the project in more detail, including the results and lessons learned, in the whitepaper co-authored by the project collaborators. We’ve produced a screencast demonstrating the final system in action. You can also attend a webinar where we’ll discuss all of this in more detail!

We hope you’ll find the answer to any questions in the whitepaper, webinar and screencast, but if not, please do get in touch with any questions you have!

7 Comments
 

Experience API Email Updates

* indicates required

Experience API Email Updates

Thanks for signing up for the Experience API newsletter!

Make sure to follow us on Twitter @ProjectTinCan,
and tweet this page to let others know about the Experience API.

Close