Experience API (Part 5)

Tin Can API/Experience API Concept

So, issues of nomenclature not withstanding, what were some of the key elements Rustici introduced with its Tin Can API? (For a copy of a slightly modified version of the Rustici deliverable to ADL [Tin Can API], cut and paste this link to your web browser: https://www.adlnet.gov/public/uploads/Experience-API-Release-v0.95.pdf )

Rustici addressed the reality and the administrative needs that exist in our increasing complex, disaggregated, and de-centralized technological world. As noted, yes, there are so many different types of technologies, and, yes, there are so many different types of platforms, and, yes, there are so many different sources of information. Moreover, not all of these learning experiences take place online. So how to capture the range of these “experiences” for modern learner . . .

The key concept and innovation for Tin Can API and Experience API is as follows.

Whenever a learning moment has to be recorded, documentation of this experience is sent to a Learning Record Store (LRS) using the following format:

The basic notion is “I did this.” This format permits administrators to track when learners begin educational courses/modules, review a given page, answer a question, and/or finish (or fail) a given course of study. While the information might have originated within a proprietary Learning Management System (LMS), the data ultimately is routed to an independent LRS, which then, in theory, could be accessed by other parties and software applications.

Since a LRS is the ultimate destination for learning data, individuals can learn off-line and simply upload their learning data once given an Internet connection. Now this does not mean that a learner could be reading a hardback book and an article on a PDF reader and magically that information is transmitted to the LRS. Rather, the learning still needs to take place through a digital format that tracks steps taken by the learner. (The reading of a hardback book, in fact, could be added to the LRS, but this would simply need to be documented and inputted by an administrator.)

Let’s look at some examples:

  1. Peter began the intermediate course for sommeliers
  2. Peter read module 1
  3. Peter scored 50% on module 1 questions
    1. Peter scored 100% on module 1 questions about white wine
    2. Peter scored 0% on module 1 questions about red wine
  4. Peter read a refresher on red wine for module 1
  5. Peter scored 95% on module 1 questions

     .  .  .  .  .  .

     27. Peter achieved competency in Burgundy style wines

This information could have originated from a cell phone, a tablet app, a desktop computer at home, or a school-based workstation. Imagine Peter began the class as an outside student at the US Department of Agriculture, and then received a job working at the U.S. Food and Drug Administration. While at FDA, he continued his study as a sommelier though using a different LMS. His old learning records are still accessible even though the FDA is using a new LMS, since the records are stored in a LRS that is universally accessible using protocols developed by Tin Can API/Experience API.

Another important feature of Experience API is that it can record learning data derived from simulations and virtual reality environments. This data, of course, is qualitatively different from other data given its dynamic nature. In this regard, too, Experience API can record data from “groups,” as distinct from individuals, that participate in a learning process. For example, ADL highlights one related element in its portfolio: Hyper-Personalized Intelligent Tutor (HPIT), which “is able to detect non-cognitive factors (e.g., determination, boredom, motivation) in a learner . . .”

(https://www.adlnet.gov/hpit).

Similarly, SAVE (Semantically Automated Assessment in Virtual Environments) “provides a framework for learning procedural skills (e.g., repairing a car, flying an airplane, or shooting/maintaining a weapon system) through simulation.

(https://www.adlnet.gov/save)

Apart from the sleek, sexy uses of xAPI [note the devolution into an abbreviation], there are basic, fundamental uses of value regardless of whether or not or an organization employs novel gaming training or the like. Welcome to the ADL/DOE Learning Registry (LR) Project. (https://www.adlnet.gov/learning-registry) There is a huge need for a tool like this—especially within the government or other large and multi-faceted organizations. Imagine an organization having a simple need, say, developing an emergency building evacuation training. Divisions on the east coast may have completely different missions and operations from divisions on the west coast, however the character of their building evacuation plans will likely be fairly similar discounting local elements. A training that one division develops can then be used and, perhaps, improved upon by another division. Maintaining a central LR valuable to leverage corporate expertise and intellect and minimize waste in expenses and time. In fact, many corporations have developed positions specifically for this function: Chief Knowledge Curators.

(http://www.clomedia.com/2017/05/22/organizations-need-chief-knowledge-curators/)

Credentialing increasingly is becoming an important element that is facilitated through xAPI, especially in government service. Witness the birth of MIL-CRED (Military Micro-Credentials), which is designed to create “a fully vetted, fully automated, personally controlled digital resume.” This project was developed to ease the transition from military to “civilian careers and educational opportunites.”

(https://www.adlnet.gov/mil-cred)

Administrators using xAPI can generate meta-data drawn across different groups of students over periods of time. This can be valuable in terms of fine-tuning elements of educational content and course focus. Ultimately, xAPI was built to document a relationship between training and job performance, which for administrators, managers, and supervisors is a key if not the key element in any program of workplace development.

Next Step: Actually, next and final step, is to look at the future of Experience API (xAPI) and the current collaborations and research initiatives of the ADL.

Experience API (Part 4)

O.K., last week we finished up with SCORM, which paved the way for a discussion about Tin Can API and, yes, Experience API.  Let’s get right into it . . .

SCORM had peaked in its level of development and value, and the ADL (Advanced Distributed Learning Authority) decided a newer version of SCORM would not meet its continuing need. As such, in 2011, ADL issued a contract to investigate, research, and basically re-think SCORM in order to advance its mission and goals. The Nashville-based business Rustici Software won this contract, and the firm initiated its work by starting a conversation, a conversation that became Project Tin Can.

Project/Tin Can

Rustici termed the research phase of the contract to be Project Tin Can. They embraced the image and notion of tin-can communication to convey the two-way communication between Rustici and the eLearning community.

Per Rustici, this process included seeking information through five different avenues:

  • nput from hundreds of xAPI stakeholders;
  • Interviews with key industry leaders;
  • LETSI SCORM 2.0 White Papers (this was, in many ways, a precursor of Project Tin Can; for an archive of these papers, see the Rustici site: https://scorm.com/tincanoverview/the-letsi-scorm-2-0-white-papers/;
  • Interactions with then current Rusti customers; and,
  • The ADL contract specifications.

A Rose By Any Other Name . . . Tin Can API/Experience API/xAPI

While the results of the Project Tin Can research produced Tin Can API, the latter was a qualitative successor to SCORM and an earlier version of the continually evolving Experience API.  xAPI, then, is simply an acronym for Experience [eXperience] API, neither a successor to nor a different version of Experience API.  

It really seems confusion arose and still arises from the period when Tin Can and Experience API virtually were synonymous. This was the period of and the immediate years following Rustici’s submission of its deliverables to the ADL. At that time, perhaps understandably, Rustici stated:

ADL will be transferring ownership of the spec to a public standards body after v1.0 is complete this spring. After that transfer, we don’t expect the official government name “Experience API” to last much longer [emphasis added].”

(https://experienceapi.com/we-call-it-tin-can/)

They had branded their process and deliverable with the “Tin Can” name, and their work was widely known by many in the industry as the Tin Can API.  Yet, the ADL used the name Experience API in their contract specifications and in their continuing usage. Experience API is the pervasive name that is used, and the name “Tin Can” is only formally used in reference to Rustici’s original contract work. Indeed, Rustici later called its response to the ADL contract “Project xAPI.”

(https://experienceapi.com/overview/)

Ownership versus Web Domains

The ADL awarded the contract—the BAA [Broad Agency Announcement, which in general, is for basic and applied research and development]—to Rustici and, as such, the work derived from that contract was and is the property of the United States Government. The issue of name “ownership” publicly arose in a May 2012 Google Group discussion:

https://groups.google.com/a/adlnet.gov/forum/?hl=en&fromgroups=#!topic/tincanapi-info/q87uy3XJXX8

The concern centered on the Rustici trademark petition for the names of “Tin Can” and “Project Tin Can.” No less a figure than Rustici President, Mike Rustici, weighed in on the concern to assure writers that the company had no proprietary claim on the use of “Tin Can” and sought to obtain trademark status to avoid it from being “pirated” by others who might be less community minded.

The continuing Google Group discussion continued on the topic as to whether or not Rustici would use the “Tin Can” moniker in any of its future commercial enterprises; to wit, Rustici replied that it would, however, the company would not prevent others from doing so.

Toward this end, while Tin Can, Experience API, and, for that matter, SCORM, are names under government “contract,” as it were, Rustici owns the web domains for www.tincanapi.com, which is redirected to another one of their web domains, www.experienceapi.com; they also own the web domain of www.scorm.com. In their separate domains, they clearly differentiate the administration, ownership, and stewardship of the respective names to the ADL, but that they also offer services for companies seeking to utilize the SCORM and/or Experience API specifications.  For a response by Rustici Software on this subject, please see:

https://experienceapi.com/we-call-it-tin-can/ and

https://experienceapi.com/tin-can-experience-api-xapi/

Note: To be clear, the above comments neither are intended nor take away from any of Rustici Software’s groundbreaking work in the field of eLearning; rather, the comments are included to simply clarify distinctions amongst terms and the like.

Next step: Finally, a focused discussion on the Tin Can API/Experience API Innovations and its evolution.

Craig Lee Keller, Ph.D., JAG Learning Strategist

Experience API (Part 3)

In our last blog, we further detailed the foundation for ADL and its areas of research.  One of these areas of research is Total Learning Architecture Structure, which provided the basis for interoperability between different systems. One of the results of this work was the Sharable Content Object Reference Model (SCORM). The initial edition of SCORM was released in January 2000 with a couple of SCORM iterations produced the following year in 2001. However, a new version of SCORM was introduced in January 2004, and DOD made SCORM use mandatory in 2006. In total, there have been four versions of SCORM 2004. The next generation of SCORM arose in 2010 with Project Tin Can, but we’re getting a little ahead of ourselves.

SCORM or What do you mean be a Sharable Content Object Reference Model?

To understand SCORM, let’s break it down into its constituent elements.

  • Sharable Content Object (SCO)—an object is the means of relating various pieces of data and their value.  For us, this refers to an element within a learning system, for example, a question or image. Each “object” is a part of the larger educational program. The desire and demand to make objects “sharable,” is linked back to our original quest for interoperability. In one sense, think of it as a specific lesson or module in an on-line course.
  • Reference Model—by reference, SCORM is referring to a computer term of art, that is, the means of finding specific data or datum located on a computer hard drive or, increasing, on a cloud-based server. In short, a reference provides the basis for discerning a physical location for information. Yes, there are all of these 0000s and 1111s out there in the digital world, so wouldn’t it be nice to be able to keep track of them. By reference model, SCORM is creating rules and protocols for references in the context of sharing that information with other Learning Management Systems (LMS).

To better understand let’s look how software designers create their programs. I remember writing programs in the defense industry. I already knew the languages of BASIC and easily learned FORTRAN in addition to LOCUS (an early spreadsheet proprietary program). My work was a mess, truly. LOL! I knew how to program, but insisted on writing my programs without a flowchart—breaking rule number 1. Anyway, you can imagine all of the problems I faced.

There are other rules in computer science that make it easier to write, track, and modify code. One of these approaches is object or class-based programming. Instead of lumping all the data together, in object-based programming, the programmer defines a group of fields or attributes, which then provides the basis for relating actual data values and associated operations and/or methods. This type of organization, then, provides the basis for generating a commonality that can be shared amongst different programs. That is, if data value, its characterization, and associated operations can be made uniform, then different programs can be capable of utilizing that same digital information. SCORM is about creating the basis for doing just that.

Now imagine trying to perform all of these functions while transmitting the information through the Internet in the context of a client-server relationship. Sharing information through a cycle of request and response from the client (you) to the server (the repository of data and generally the program) gets complicated enough. Imagine trying to force-feed your information into a different LMS. Whhhew! You get the picture. Yes the horror as it were. So, again, that’s the basis for creating SCORM.

SCORM Protocols

Let’s be clear. SCORM is neither a software program nor a programming language. Rather SCORM provides standards for data and programming that make it possible to have data sets that can be interchangeable amongst differing LMSs. So, software designers are extremely mindful to utilize SCORM when designing and coding their proprietary LMS. There have been numerous limitations to SCORM. Why? It’s simple: trial and error. Software designers within and without the government have found flaws or limitations to the SCORM protocols, which, of course, gave rise to successive iterations of SCORM. The SCORM protocols are the rules utilized by different Application Programming Interfaces (API). An API is the part of the programming language that facilitates a communication between different computer systems. API and software developers use SCORM to create the standard of interoperability for eLearning systems. Now there exists a SCORM API, but that is just one of many forms of an API.

A major SCORM component was adopted with the 2004 version. Researchers with the ADL created the notion of “sequencing.” The sequencing protocol specified that learners could only experience content objects in a specified order. Such can be valuable, but it also can be a limitation.

Next step: The movement away from SCORM toward Tin Can API and Experience API.

Craig Lee Keller, Ph.D., JAG Learning Strategist

Experience API (Part 2)

In our last blog we discussed the foundation for Experience API, Advanced Distributed Learning (ADL). Let’s reiterate the truly pressing need for ADL, because it’s so, so easy to get lost in the rapid pace of technological innovation and moreover system transformation.

Prior to ADL, and prior to eLearning, education that utilized computers, in many ways, was a solitary, alienating experience for both the user and the providers of educational content. How’s that? Education and training took place at a single computer station, prior to the days of networking. Looking backwards, that form of education has been termed Computer Based Training (CBT). Think of a painfully sad image of a bureaucrat in a cubical toiling away. Let’s look to Dilbert for insight:

In CBT, administrators purchased software packages—generally expensive software packages—that could be utilized by single or multiple users based on purchased licensing privileges. Proprietary packages, unlike today, were not cloud based, but utilized compact discs (CDs) to access programs. I remember an actor on television regaling the value and permanency of CDs pronouncing, “they can even be dropped in your goldfish bowl and nothing happens!” Information input through the software would be saved on the resident computer (or back in my day, on floppy disks ☺) and coded into a file structure that could only be accessed via proprietary software. When software was updated to fix glitches and to add additional functions, the educational administrator generally had to purchase next iteration of proprietary software in order to access old data and/or use it with the new functions. Software companies might offer mechanisms for translating the files of a competitor, but frequently the results were disappointing. As stated before, all of this was the problem that ADL set out to address.

ADL and the Need for SCORM Protocols

As noted in last week’s blog, the ADL was developed by the U.S. Department of Defense in the mid-1990s to streamline its technological approach to education and training. As one might suspect, though, other agencies within the federal government simultaneously were engaged in similar projects for their own programs in education and technology.  In order to avoid duplication and inevitable conflicts in integration, the array of federal ADL programs were consolidated within DoD ADL Initiative. It would not be surprising for private industry to fall in line with this program, as a large portion of their revenue is generated from government contracting.

Based on Congressional defense authorization and President William Clinton’s Executive Order 13111, DoD created a strategic plan for ADL with the the following areas of research:

  • eLearning (web-based learning)—Research technical components and techniques to develop and support electronic-based education and training . . . consistent and interoperable . . . best practices . . . learning management systems, content registries, and Massive Open Online Courses
  • Mobile learning and mobile performance support—Research focused on the use of commercially-available handheld computing devises to provide access to learning content and information systems . . .
  • Learning analytics and performance modeling—Research in collection, measurement, analysis and reporting of data, which may include “big data,” about learns and their contexts, for purposes of understanding, optimizing, and predicting learning success . . . competencies, credentialing, learner profiles, data visualization . . . associated privacy and information security concerns.
  • Learning Theory—Research focused on the application, evaluation, and embedding of efficient and effective, current, new, and emerging theories of learning, instructional technology . . .
  • Total Learning Architecture infrastructure (TLA)—Research focused on modernizing the platforms used for education and training, to interoperability of disparate systems so they can be used together as a Service Oriented Architecture (SOA) to securely share relevant learning data including, but not limited to, granular learning experience . . .
  • Web-based Virtual Worlds and simimulations (VWs)—Research into the emerging fields of serious games, simulations, and virtual reality (within a distributed learning context)  . . .[https://adlnet.gov/research]

Given the research mandates noted above, it became necessary to develop a language that facilitated the goals of accessibility, reusability, and interoperability. The Sharable Content Object Reference Model (SCORM) was the first solution.

Next step: the discussion of references in computer science and their relationship to and the development of SCORM and ultimately Experience API.

Craig Lee Keller, Ph.D., JAG Learning Strategist