- Get Started
- Write Code
Posted by Kirsty Hughan
Posted 26 May 2017
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.
Posted by Brian Miller
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:
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.
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.
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.
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.
Posted by Tim Martin
Posted 14 February 2017
Today we’re excited to announce support for a new specification in SCORM Cloud- cmi5, which is something that doesn’t happen all that often in its history. Along with making cmi5 support readily available in SCORM Cloud, we’ve also added support for cmi5 to some of our other products including SCORM Engine and SCORM Driver.
Obviously, supporting a variety of specifications is a huge part of what we do well at Rustici Software. More than anything, though, I think it’s important for us to be conscious of, and to explain well to all of you, when and why we add support for a particular specification.
So, what is cmi5?
cmi5 is technically a profile of xAPI which means it piggy backs on top of things already well defined in xAPI, but adds specificity in others. For cmi5, this means that certain xAPI statements are required, and launch is handled in a very specific way.
For me, it’s the launch piece that’s so important. From xAPI’s advent years ago, there have been issues with launching content. In the earliest days, we at Rustici Software defined a very simple launch specification that several content vendors picked up on. It was good enough for the time being, but it wasn’t really good enough in practice.
So, over the last couple of years, many people including Bill McDonald (as Chair of the working group) and Art Werkenthin and others at RISC have put a lot of energy into considering how their AICC work could be applied to launch in the xAPI world. The result is that we have a good solution for launching content via xAPI.
Why it matters
Years ago, as we at Rustici Software and others around us started evangelizing xAPI, we made some mistakes. We talked about all of the things that could be enabled by xAPI, the things for which it was necessary but not sufficient. Over the last year or two, we’ve really started to fill in the gaps to make it sufficient as well. And while launch isn’t the dreamiest of capabilities for which xAPI is a solution, it is absolutely fundamental.
If content launch is ultimately going to transition from SCORM to xAPI, cmi5’s support for launch will be a requirement. And further, so many other activities actually benefit from having a well defined, implemented, and adopted specification for launch. So for now, we’re excited to share that Cloud now offers vendors and others a great place to test cmi5 based launchable activities. We hope this helps spur the development of many xAPI/cmi5 adopters.
Posted by Freddie O'Connell
Posted 8 February 2017
For years, we have relied on our products to be the solution to a number of complex problems facing companies that use learning standards. If you’re building an LMS or authoring tool and you need AICC or SCORM or, more recently, xAPI, we have a product that can do the heavy lifting. That’s been our bread and butter.
But we also have insights from years of thinking about experiential data and hearing how customers report on it. And we know that the problem isn’t always solved at the immediate boundary of our products.
It’s those considerations that brought our services group to life.
We help vendors and organizations consider how to use learning standards to accomplish their goals. These goals include delivering the learning material to their people and selling their products to discerning buyers.
We work on problems related to the learning standards AICC, SCORM, and xAPI.
In the case of xAPI, the newest of the standards, the off-the-shelf solutions are less mature. Listening carefully and collaboratively helps us build better products, but it also helps us get you the right solution now.
Of course, we haven’t stopped thinking about AICC and SCORM.
We want you to ask us a question. You can learn more about how we’re responding to the questions we’ve already heard here. These are things we anticipate. Maybe something on this list prompts a question you were getting ready to ask. So, ask away– we’re listening and ready to help.
Posted by Freddie O'Connell
Posted 24 January 2017
You’re going to hear us talk a lot about semantic interoperability this year. So we might as well present a working definition.
Semantic interoperability is when information—the meaning behind captured data—is portable and well understood by any subsequent system requesting and reviewing it.
Why will we be talking about it a lot? Because without semantic interoperability, the Experience API (xAPI) has a limited future.
For us, semantic interoperability in xAPI will be achieved when there is a generally accepted information model. We expect profiles to help with this a great deal. There’s a strong possibility that collaborative work between ADL and IMS could help a great deal.
Consider SCORM, the usage of which remains widespread in LMSs everywhere. The CMI data model leveraged by SCORM is closely linked to its information model. There is a finite set of data that can be recorded about the types of learning experiences common to online training, and summarizing information from that data is a relatively straightforward exercise. So straightforward, in fact, that practitioners have long cared primarily about a big four—score, completion, satisfaction (i.e., pass/fail), and duration. SCORM makes requesting and understanding the big four easy.
xAPI, on the other hand, is fundamentally a communication protocol applied as a specification for elearning. In xAPI, apart from a few familiar holdovers from SCORM (the big four, native support for interactions), there is no limit to what can be captured about a given learning experience. One could literally choose any verb available in any language. Or one could create a new activity definition to describe any type of experience.
Can you imagine how difficult it would be to report on data with so few constraints? We can. Because we’ve been trying.
Even when there is consensus that a concept has sufficient value to merit a profile, there can be difficulty. Take video, for instance. Not only is there a profile in our Registry, there’s also a Community of Practice still working on a version. If there are multiple working versions of what data to capture, then how is a reporting system attempting to derive meaning about “video” supposed to do so?
We think the answer right now is: leadership. The concept of Registry has utility to semantic interoperability in xAPI, and we have a feature roadmap for it. Still, we recognize the difficulty in a single industry participant to establish credibility and trust.
What would alternatives look like? We think ADL could assert an information model. As a subtle alternative, ADL could host a collaborative process with some authority. This might look like the establishment of a baseline with a community process similar to how the specification itself operates now—managed workflow in GitHub supported by regular calls.
Expect to hear more from us on this topic because we think it’s critical to the future success of xAPI.