By learning technology consultant, Craig Weiss, E-Learning 24/7
Editor’s Note: For years, learning organizations have sought better ways to understand and improve how people engage and interact with synchronous and asynchronous training content. However, they’ve struggled with tools that are proprietary, complex and limited in scope.
Now, a surge in content and device innovation is fueling renewed interest in tracking, analyzing and customizing diverse learning activities across applications, locations and time. This has opened the door for the new Experience API (the so-called Tin Can API or xAPI), which is gaining momentum as an open standard.
Increasingly, our customers and business prospects ask us to explain the xAPI, and its ability to enhance modern learning experiences in the ExpertusONE LMS. Because we support open standards, we see tremendous potential in the xAPI and related LRS (learning record store) capabilities going forward — in particular with mobile, social and game-based learning applications.
We’ll share more product-related specifics soon. However, for clarification about xAPI and LRS concepts, we recommend the following interview between two credible and highly knowledgeable sources — independent elearning technology analyst, Craig Weiss, and one of the authors of the xAPI specification, Aaron Silvers.
This Q&A is longer than most blog posts because it addresses many common xAPI/Tin Can misperceptions. We hope you’ll find it useful as a reference now and in the future.
CW: Aaron, can you tell me a bit about your background and how you became involved with ADL?
AS: In 2003, the e-learning startup I worked for shuttered its doors as our customers moved to adopt SCORM, and we had no idea how to do that. Two months after my layoff, a company called CTC recruited me to work for ADL. My job was to help author SCORM 2004, focusing on how to develop content that would work in SCORM systems. It was a no-brainer to take the job. Any innovation that could shut down as many companies as SCORM did was something I wanted to master.
I worked with ADL (Advanced Distributed Learning) from 2003-2006 and participated in the Technical Working Group afterwards. I helped with LETSI in 2008-2009 while I spent most of my working life at W.W. Grainger, Inc. I worked with business analysts, IT and communications teams on governance for these new technologies. We created a strategic framework that mapped knowledge sharing to measurable gains in productivity, quality and revenue. This work informed the conversations with several current and former ADL friends.
These conversations became something we called “BAQON” — a Brokered, Anonymous acQuaintance Open Network. In early 2010 we pitched BAQON architecture to Bob Kahn at the Center for National Research Initiatives. Bob Kahn is the same guy to whom Tim Berners-Lee pitched the World Wide Web. Bob Kahn thought we were crazy, but not so crazy that it couldn’t work. Over the next four months, ADL brought the team on board to work on what would become the Training and Learning Architecture, or TLA. The first technology in that architecture was the Experience API.
CW: What exactly is Tin Can?
AS: “Project Tin Can” was the name Rustici Software came up with to describe the work ADL contracted them to do. The project was to think about a new way to approach learning that based on current needs. Their work included user research.
They collected suggestions on a UserVoice site. They conducted one-on-one interviews with many eLearning professionals. They reviewed almost 100 white papers authored for LETSI, who in 2007-2008 was looking at what a “SCORM 2.0” might look like. The name “Tin Can API” stuck around once ADL advocated to use the prototype produced out of “Project Tin Can” as the basis for the Experience API (“xAPI”).
CW: I was told that xAPI and Tin Can are one in the same — correct?
AS: When talking about this technology, ADL, IEEE and many people and businesses call it xAPI. Right now, “Tin Can” refers to xAPI. They are one and the same. “Tin Can” is a trademarked name owned by Rustici Software. They have vowed to give up the rights to any organization taking stewardship of the specification. Unfortunately, since ADL is a U.S. Government organization, they can’t file for a trademark, so for now Rustici Software is stuck with the trademark for “Tin Can.”
That said, Rustici Software released the “Project Tin Can” work to open source. They continue to contribute much to the specification effort (open source code libraries) in many languages. They’ve authored a great deal of code for the xAPI Conformance Test. I have strong faith that, if there is an industry organization to steward xAPI, and it is willing to take the moniker of “Tin Can” from them, they’d be more than willing to grant it.
CW: Could you explain in layman terms what is xAPI? I know that many people were told that SCORM didn’t play well with mobile, and that is why xAPI came about. Is that true, or is there another reason?
AS: xAPI is a means of sharing a record of activity about some piece of content or media with another system. That sounds like a pretty dry and simple thing. Because it’s so straightforward, it is open-ended as to how many ways someone can use it. That’s what makes it so powerful.
What spurred us to seek data interoperability as opposed to straight-up focusing on making SCORM work for mobile was a few things:
1) With regard to mobile, SCORM could play well enough. As early as 2004, you could find demonstrations of SCORM running on COMPAQ PDAs. The problem was just that there was no ONE way to do it. The nature of mobile devices became too complex too quickly to wrangle a solution that industry could adopt. As much as SCORM content back in the day required futzing before it worked, it was a closer-to-turnkey solution than anyone had with mobile.
2) Our work at investigating SCORM and mobile revealed a bigger challenge. SCORM Version 1.2 was so popular and so widely adopted that people weren’t even bothering with SCORM 2004 — regardless of the resources that went into improving SCORM Version 1.2. And by 2008-2009, SCORM Version 1.2 was so entrenched that no vendor wanted to touch SCORM at all. If anyone was going to address mobile, social media, games, simulations, or any other use cases, it would need to be outside of SCORM.
Doing something “not SCORM” liberated us to think about such challenges differently. And that got my team thinking a lot about the interoperability of data. This focus, inspired by the ActivityStrea.ms working group, informed the team on Project Tin Can, and eventually the Experience API.
CW: I was told xAPI is in IEEE’s hands? What is IEEE?
AS: IEEE is the Institute of Electrical and Electronics Engineers — an international, industry standards body. In the elearning world, they’ve standardized things like the Learning Object Metadata model used in SCORM packages. IEEE also specifies USB and WiFi, and a host of other standards we take for granted but help ensure that things “just work” as expected.
I’m chair of the part of the IEEE-LTSC (Learning Technology Standards Committee) that is looking at standardizing xAPI. We are in the process of getting a stamp of approval from IEEE-SA standardizing the part of xAPI that deals with activity statements. That happens with what’s called a “Project Authorization Request” into IEEE’s New Standards Committee (or “NESCOM”). Currently, I’m helping organize an industry consortia called “Connections Forum” to help with making the PAR for xAPI.
It’s going to start with the information model and a data binding for it. In laymen’s terms, it’s the part that’s about what the data looks like in xAPI. It’s the piece that many people agree with, and are interested in using, even outside of learning industry contexts. In time, through the Connections Forum, we may write or adopt standards for other things currently described in the xAPI specification — for example, LRSs, and probably things that aren’t in there but are possibly closer to the scope of what is in ADL’s TLA.
CW: So, are you saying there are two standards doing the same thing, with two names?
AS: There is one specification group supporting one spec — xAPI. However, many people call it by two names. “Tin Can” has been well publicized and, in fairness, ADL used it quite often in the first months of the specification work.
The “dual” name issue is confusing to the industry and the market. For example, people miss conference sessions described as “xAPI” because they’re looking for sessions about “Tin Can.” That’s a challenge. But, it is not hindering progress on the specification work, itself.
The community is working on xAPI together. Recently, concurrent activities began related to xAPI. I am leading the effort to standardize xAPI, and that overlaps an effort within the current specification group to scope-out what Version 2.0 might address. At the same time, a large group of adopters is addressing conformance requirements for Version 1.0.3 of xAPI. The next bit of work for that group is to clean-up the document, so different functional parts of the spec are more distinct, so further work might be scoped to certain parts of the spec without necessarily impacting other parts.
There are always arguments about the minutiae of specification requirements, but the naming thing isn’t stopping collaboration on the spec. However, I would bet that if everyone used the same name, more people would be aware and get involved. It’s also probably worth noting that most people get confused — even about what I’ve tried to describe here.
For perhaps the next few years, there are not going to be many visible changes to xAPI — and even when big changes do happen, nothing will stop the current use of xAPI. That’s not to say what we do will be backwards compatible. More likely, from an implementation standpoint, the solutions you count on will find ways to work easily with everything, as they often do already.
CW: Can someone (a vendor) create their own form of something like xAPI, but not xAPI, per se?
AS: We intentionally licensed the specification Apache 2.0 so that derivative works would have no impediment. That’s the means by which I’m able to lead the effort in IEEE. The way government works, it’s very difficult to simply hand over control of a spec, even when it’s developed to be completely open source. This was a lesson learned as ADL attempted to transition SCORM to another party, but couldn’t.
To the spirit of your question, it is possible for a vendor to create their own spec based on xAPI. However, bigger questions come to mind. Why would they? What would they gain? Without the community in place, the adoption that’s pretty easy to follow from anywhere, the conformance testing being developed, the standardization activity — anyone who’d want to do this would be so much better served working with the existing community and the industry that’s coming together around xAPI.
CW: Conformance requirements? Standardization? Could you explain further?
AS: Absolutely. A lot of people talk about SCORM Compliance or xAPI Compliance, but that’s really not the right wording. Compliance means someone has to legally “comply” with something, like it’s a law. There’s no law for SCORM or xAPI — like there is for accessibility with 501c.
What people really want to know is if something conforms to the specification — meaning, “Does this product actually do xAPI the way the spec says it must?” Specifications, when done well, have conformance requirements that talk about all the things an implementation must or must not do. xAPI has this. So does SCORM.
Where it gets tricky — particularly with what’s on the market — is in all the things a spec says implementations should or should not or may do. Those aren’t must or must not rules. Technically, a vendor could ignore all the shoulds and mays. As long as they follow the musts and must nots, they’re conformant.
What we’re doing now with xAPI as a specification is filtering out as many shoulds and mays as we can, so there’s little ambiguity about what it means to be conformant. That makes it easier to create tests. When we have tests that can be run by third parties, then we can get into certified products — and that’s where we, as an industry, really need to go. This is why we’re working hard to get the Connections Forum rolling, even as the spec group is dealing with conformance and standardization on what’s been specified.
Standardization involves removing the ambiguities of the language in the specification for even broader, more massive adoption. Instructions have to be so precise that, in every case, implementation of xAPI “just works.” Light bulbs are standardized. You never buy a light bulb that doesn’t fit a standard light socket, unless it’s the wrong bulb. USB is a standard. You never find a USB device that doesn’t fit or work with your port, unless it’s the wrong type. We want xAPI to be just that reliable.
CW: Thank you. Now let’s jump into Learning Record Store (LRS), another term creating confusion. What is an LRS and why would I want to have one?
AS: A learning record store is how we describe a set of functionality for the part of a system (or a standalone system) that stores the activity data sent to it by whatever creates xAPI activity statements.
The LRS could be the part of an LMS that receives data from an e-learning course. It could be a part of a customer relationship management system (CRM) that does analytics with xAPI on the different sales and support staff using it, and what they do to close leads. An LRS could be a standalone system, like a hub, for a spoke model of a learning ecosystem, where many different courses, apps and enterprise systems are sharing data about one or more learning experiences.
CW: Some people have heard you must have an xAPI prior to having a LRS. Is this accurate? Can I have a LRS without having to use xAPI?
AS: It’s not necessary to use an LRS to do xAPI. A database will do, if you’re never going to share the information being sent to it, and you’re never going to send anything to that database except from whatever it’s built for.
However, the minute you want to add new activity providers, like Articulate, Captivate or Lectora courses, with almost zero configuration or redevelopment — or if you ever want to share that data across multiple systems, you will want an LRS. Endpoints just make it easy to use with solutions that create xAPI data.
CW: I know you can have a LRS without it being in a LMS or an authoring tool. Why would I want to do that?
AS: There are a lot of enterprises who bought into LMSs in the early 2000s as capital investments, and they’re looking to update their infrastructure without completely undoing what they’ve already established. But there’s significant demand by younger, smaller, mid-market organizations for a less siloed infrastructure.
They’re not looking at learning technologies as capital investments, but as services that can be updated and switched when their needs change. Disambiguating the LMS is likely what drives such use cases for an LRS as its own system — and looking at the market from my vantage point, there’s a good demand for that.
You’re not bound to the assumptions and workflows that come with an LMS. You can be more agile and ad-hoc with your learning approach and your content strategy. You can be more strategic to your company’s goals, rather than adopting the design assumptions baked into a given LMS.
I don’t know that route is for everyone. There are many things LMSs do that are hard to replicate, in a cohesive way, with separate systems — things like resource scheduling and certification management. That sounds like nothing but a database, but why build it all yourself when systems already do this for you in a variety of ways?
CW: When you say activity streams, what does that mean exactly? I mean what covers “activity streams”?
AS: An activity stream is a list of recent activities performed by an individual or group. Typically, with xAPI, a single piece of content or media generates this stream of data. For example, Facebook’s News Feed is an activity stream.
Many web services have similar implementations for their users, borrowing from the ActivityStrea.ms specification. When we were coming up with an approach for the Experience API back in summer of 2009, I talked at length with Chris Messina who was an author of the ActivityStrea.ms spec.
There were key differences in the approach we wanted to take with xAPI — which is why we ultimately didn’t just use ActivityStrea.ms outright:
- The vocabulary associated with the activities focused on commercial web use, and we were looking for something that could be generalized;
- The data never really was supposed to go anywhere with ActivityStrea.ms. It was meant to stay within the web service that generated the data. However, we were explicitly looking at interoperability — being able to move the data around was paramount.
CW: I’ve also heard that an LRS data record is “interoperable” — you can take the data record from one LRS and plug it into another LRS, and it works fine.
AS: That is indeed the value proposition for xAPI. We want a system to be able to interpret appropriately, consistently and reliably, the activity you performed and the context in which it was performed — no matter where it was recorded.
CW: Many of us remember that “interoperability” pitch with SCORM. As you’re aware, it often doesn’t happen. Can you definitely say this is not an issue with an LRS data record — even with a standalone LRS?
AS: Interoperability gets a bad rap from ten years ago. If you look at where interoperability is with SCORM today, it’s pretty damn solid for it not being an actual standard.
I’d be lying to you if I said you won’t find bumps in the road with xAPI’s data interoperability — especially from its earliest days. But compared to other options, which most people can’t even identify, we have a great track record. You’re not hearing the cries about interoperability that we had with SCORM adoption at a comparable time. In fact, in terms of adoption maturity, xAPI is on a wholly more advanced and accelerated curve.
Where people will get upset about interoperability will be in the spec’s shoulds versus its musts, and on implementation of specific things like access to data for analysis. We’re all new at this — learning and improving daily as this industry works across vendor interests in a way that’s unprecedented here and elsewhere.
CW: My next questions relate to privacy and security. Let’s say I work for company X and leave for Company Y. Company Y has no LRS. Where do I put my data record? Do I create a learning locker, or something else?
AS: Today and for the foreseeable future, that’s a tough question to answer. It’s entirely dependent on a couple of variables that would be hard to specify, let alone standardize, because every country has different privacy laws. Even different states in the U.S. have different data privacy laws.
Today, it really depends on which LRS Company X has, and what Company X’s policies are about your access to the data about you. As with Google, Facebook and other web-based services, there are no clear policies on the rights a person has with regard to data about them. This is an area I’m very keen on solving, but it’s a much bigger issue than xAPI alone. Still, it’s an issue I hope xAPI can improve and model for other data concerns.
CW: Recently, Sony servers were hacked, and all types sensitive information was exposed. Should people be concerned this could happen with an LRS, which captures a lot of individual information? Is there anything an organization can do to avoid data breaches?
AS: Data breaches are inevitable. The best a company or school can do is to be realistic about this, and follow current best practices. The reality is that what we’re doing with xAPI is far more secure than what LMSs had to do with SCORM. But just like companies and schools, the community needs to be vigilant as well. This will be helped immeasurably by an industry organization that can provide guidance for the evolution of the technology, as well as implementation by customers and end users.
CW: Finally, let’s talk about the future. What do you see ahead for xAPI, LRS in three years? What is the potential?
AS: Potentially, we have the beginning of a suite of standards, all collectively known as “xAPI.”
The information model and a JSON binding (something like what we use today), an XML binding (used by simulations and many other enterprise systems), and a Low Energy Bluetooth binding (used by beacons and sensors) will make it possible to support learning-as-a-practice.
This means hospitals, construction sites, laboratories, refineries, schools, offices, the military, power plants and the smart grid — all will benefit from learning-by-doing that is tied to competencies, as well as outcomes. We will begin to realize a way of meshing learning and performance in a way that respects a person’s dignity and intelligence, and is empowered by digital capacity, rather than simply serving it.
CW: Do you see something else — some other type of standard in the next five years?
AS: I see other standards emerging as part of xAPI that deal with how we describe and translate competencies, how we securely identify people, how we secure a given piece of data so it is able to be used only as intended. I can go on for a while on this question alone.
CW: Lastly, if there is one thing people should know now about xAPI and LRSs today, what would it be?
AS: xAPI is a transformational idea. It began as a means for people to realize self-actualization at scale. What began as a mission by a small group of us has grown beyond the community that created a technical specification. It is now inspiring industries to think differently about how to work better by sharing and directing information outside of a given context. LRSs and the systems that make use of LRSs are a means to that achieving that end.
To learn how the ExpertusONE LMS leverages industry standards for seamless integration with other business systems, content and resources, read about the ExpertusONE API library online, or contact us anytime to schedule a personalized consultation and demo.
This post is adapted, with permission, from the E-Learning 24/7 Blog.