The new ADL Experience API offers interesting opportunities. Yet, it challenges the integration with existing concepts and technologies. An example for these challenges is illustrated by the following question: how does the xAPI relate to Mozilla's Open Badges or E-Portfolio systems like Mahara? Because all these initiatives and tools are related to learning experiences there appears to be a significant overlap. In this article I explain how the xAPI fits into a framework with open learning badges and e-portfolio systems. 

At the first sight e-portfolios, learning badges, and the xAPI seem to cover the same use-case of documenting learning across platforms and learning environments. However, on closer inspection we  find that each concept only deals with one part of this use case. The following infographic illustrates how the xAPI can be used to link learning activities with e-portfolios. 

The Experience API (xAPI) and Learning Record Stores (LRS) serve the primary purpose of documenting and retrieving learning experiences from arbritary learning environments. Each "experience" in a LRS refers to one event in the learning process. Therefore, it provides an overview about what people have developed their knowledge, skills and competences. These events can be as simple as "accessed a resource", "watched a movie", "played a game", "passed a test" or "visited a location". They can also cover more complex events such as "completed a course by passing all necessary tests with 60%" or "Visited all waypoints of a treasure hunt", and even complex meta processes "passed all courses for a master degree and applied the concepts in professional practice" might be included as experiences. 

Learning badges share many characteristics of "certificates" for one or more learning experiences. In other words, a learning badge is a certificate that person has mastered a learning objective. Mozilla's Open Badges provide a framework for certifing that learners have completed a task or reached a goal in a learning environment, without much opportunities for autmated validation or integration into complex technology supported learning processes as the concept is based on the trust principle of certifying authorities.

Finally, there are e-portfolios (like Mahara). E-portfolios provide a place for storing, arranging and presenting learning outcomes. These learning outcomes can be learning badges and other certificates. They can also include all kinds of other material, such as essays that have been written in courses or software that has been developed as part of a job. In this context, systems like Mahara would store the learning badges for learners but does not necessarily require a direct link to a LRS. 

The mozilla OpenBadges project even has its own e-portfolio system: the mozilla Backpack. It allows learners to collect their badges in one place. As a web-service it also enables the learners displaying their latest learning badges in any online environment. One obvious limitation with Mozilla OpenBadges is that it does not provide a semantic (machine readable) description of what is certified by the badge.

With the xAPI this setup becomes slightly more exciting, because it allows to hook a learning badges issuer with a LRS using analytics on the learning experiences. When the LRS detects that a learning goal has been completed it triggers the learning badges with a related xAPI statement. Based on this statement the issuer can verify (or just blindly trust the LRS) if the requirements for a badge are met. In this case the learning badges issuer can issue the learning badge and send it to the learner's portfolio. Additionally, the issue of a learning badge is also a learning experience, so the issuer would inform the LRS whenever a badge has been issued with an appropriate xAPI statement. Such badge-related xAPI statements would then refer to "complex" experiences that summarize several experiences.

[Update, 10 Jul. 2013] From reading the xAPI specification it is not very obvious how this step could work. This is because the specification defines an LRS merely as a plain data store. Theoretically, the analytics function would be a consumer to the LRS that reads activity streams from it. By analysing these activity streams such a consumer could detect higher-order experiences and for each detected complex learning experience it would  send a learning experience statement to an badge issuer in order to initiate the certification. If the badge issuer aggrees with the certification, then the badge issuer sends a new activity statement to the LRS that indicates the achievement of the issued badge. 

In practice, however, such analytics often need to consider several hundred experience statements at a time. Even with the comparatively dense dataformat of the xAPI this could easily generate significant network traffic in addition to the processing overhead of coding and decoding the activity streams, if this would be done by explicity activity stream requests. Also, an LRS likely builds on a database of some kind and these databases are typically optimized for filtering and processing large amount of data. Therefore, a real world LRS would integrate this activity stream processing. Such integration allows faster data analysis than the formally correct activity stream processing by avoiding network traffic and coding/de-coding overheads. All what remains is the interaction between the LRS and the badge issuer as it is visualized in the graphic above.

Conclusions

This outline shows that the LRS, learning badges, and e-portfolios serve special purposes for documenting and creating visibility of learning. It also shows how the xAPI can be used to link learning experiences in different environments with more complex solutions for learning badges and e-portfolios.