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 "Recipes" Category

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
 

Semantic Interoperability

Posted by

Categories: Best Practices, Ideas, Recipes, Registry, Standards, xAPI

Posted 24 January 2017

 

whatis-themeaning-meme-25449

 

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.

Then: Too Many Constraints

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.

Now: Too Much Flexibility

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.

Needed: Leadership

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.

No Comments
 

I Want This: Tin Can Plans, Goals and Targets

Posted by

Categories: Ideas, Recipes, Statements, xAPI

Posted 27 August 2015

 

Learning plans, goals and targets are important. Setting goals for learning allows us to evaluate whether or not we are learning the things that we set out to learn. It’s standard practice for e-learning courses and qualifications to have learning outcomes attached to them, and these are used to measure if our learning has been successful. They are also used by educators and trainers to evaluate whether or not their teaching and training have been effective, and are used to inform interventions, further learning requirements and amendments to learning materials and lesson plans.

Learning Goals with Tin Can

Brian Miller touched on the use of sub-statements in Tin Can to represent future plans. The spec puts it this way: “One interesting use of sub-statements is in creating statements of intention.” and gives the following example:

{
    "actor": {
        "objectType": "Agent",
        "mbox":"mailto:test@example.com"
    },
    "verb" : {
        "id":"http://example.com/planned",
        "display": {
            "en-US":"planned"
        }
    },
    "object": {
        "objectType": "SubStatement",
        "actor" : {
            "objectType": "Agent",
            "mbox":"mailto:test@example.com"
        },
        "verb" : {
            "id":"http://example.com/visited",
            "display": {
                "en-US":"will visit"
            }
        },
        "object": {
            "id":"http://example.com/website",
            "definition": {
                "name" : {
                    "en-US":"Some Awesome Website"
                }
            }
        }
    }
}

MORE…

No Comments
 

Statements come from all kinds of places: content created in authoring tools, mobile apps, learning platforms and business systems. It’s not always immediately obvious which application the statement came from, which might be useful to know. This blog explains how you can tag the statements your tool or product generates and why that information is useful.

We’ve worked hard to make the Tin Can (xAPI) spec as clear as possible and have required Learning Record Stores (LRSs) to validate incoming data to ensure the same data structure is always used. There’s no way for statements to be sent to a conformant LRS unless they follow the prescribed data structure, and you’ll find that the major LRSs are strict with the data they accept.
MORE…

1 Comment
 

I’m super excited about the latest recipe we’ve published on the registry! Not only is it a great recipe tackling an important use case, but it was written by adopters who needed it for a real project. It was written incredibly rapidly, going from first draft to ready-to-try in less than two weeks. This blog gives you the details.

Sometimes when I talk to people about recipes, they’re disappointed to hear that there isn’t yet a recipe for the use case they are interested in. “Don’t worry!” I always console them, “You can write your own.” TES took that advice to heart and one of the first things they did after hiring a developer to take xAPI further in their app was to draft up a recipe covering the events they wanted to track. In this case, attendance at events such as meetings, classroom sessions, conferences, etc.

The actual recipe can be found here in the registry. The recipe is split into ‘Simple Attendance’ which uses a single statement to record that a group attended the event, and ‘Detailed Attendance’ which is used to record more events such as scheduling, registering, joining and leaving. It’s envisaged that some recipe adopters will implement only Simple Attendance whilst others will compliment it with the nuances captured by Detailed Attendance statements.

The bulk of the recipe was written by Sean Donaghy of TES. I helped by reviewing each iteration and making a couple of edits where it was faster to make the change directly than write up an explanation. I’m very happy to help anybody who wants help with reviewing a recipe they’re working on.

This first release of the recipe is considered an alpha version. Aside from the TES developers who are busily implementing the recipe in their product, nobody else has tried the recipe yet. There are likely some changes to come as implementers run into challenges we couldn’t predict. If you do implement the recipe, we really appreciate your comments and feedback. You’ll use the recipe ids (http://xapi.trainingevidencesystems.com/recipes/attendance/0_0_1#simple and http://xapi.trainingevidencesystems.com/recipes/attendance/0_0_1#detailed) as a “category” Context Activity so that when you upgrade to the final release version of the recipe you can easily identify which statements used which version.

Recipes are really important to ensure your statements can be understood by other tools. If you’re working on a xAPI project and neither following nor writing a recipe, please do get in touch so I can help you.

You can expect this to be the Year of The Recipe for xAPI. We already had the Open Badges recipe last month and there’s a few more in the works that will pop up as the year progresses. Watch this blog for more news sometime soon!

No Comments